RAG系统跑通了但效果很差，chunk和embedding怎么调才有效？

产品手册这种PDF直接切确实容易翻车，因为表格和参数列表混在一起，按字数切经常把不相关内容拼一块。你先别急着换embedding，建议把召回的前几个chunk打出来看看，大概率是切分把“售后流程”那段拆散了或者埋在产品参数堆里了。可以试试按标题层级切，或者先用unstructured把PDF结构解析出来再分块，比纯sentence splitter靠谱不少。另外召回差也可能是因为ada-002对中文手册的语义区分度一般，换个bge-m3之类的中文embedding对比下就知道了。

你这个情况大概率是召回阶段就崩了，先别急着换模型。产品手册里“售后服务流程”这种词可能只在某一页出现，chunk切太大会把参数表和流程混在一起，embedding根本抓不住重点。建议你把每份PDF按标题层级先粗切，再在段落内用语义切分，别硬套固定size。另外可以手动抽20个query测一下top5召回，看看到底是没召回到还是排太后了，这比瞎调参快多了。

你这个情况八成是召回阶段就出问题了，别急着怪生成模型。产品手册这种PDF往往有大量表格、页眉页脚和跨页段落，直接按固定字数切很容易把“流程”拆成碎片，或者把参数表格跟流程说明混在一个chunk里。你可以先做个简单验证：拿几个你预期应该被召回的问题，手动去FAISS里看top5的chunk到底长什么样，如果里面压根没有流程相关的句子，那跟gpt-3.5没关系。ada-002对中文产品手册其实不算差，但它对短query和长chunk之间的语义匹配有时候偏弱，尤其你问“售后服务流程”这种偏抽象的词，chunk里如果全是“步骤1、步骤2”反而可能匹配不上。建议试试在embedding前给每个chunk加一句上下文摘要，比如用标题层级拼成“售后服务 > 流程 > 退换货”，或者换bge-m3这类中文更强的模型对比一下。另外chunk size别只盯着500到1000，产品手册可以按标题切，再对超长段落做二次切分，overlap给50到80就够，太大反而稀释语义。还有个小技巧是给query做改写，比如把“售后服务流程”扩成“售后 服务 流程 退换货 维修 申请”，再拿去检索，召回会明显不一样。你先确认召回是不是真的把相关段落排到前面了，再决定要不要动生成端。

先别急着调参，把召回的chunk打出来看看，很可能文档里就没有“流程”这类词，换bge或加个重排试试。

先别急着调参，拿几个问题手动看看召回的chunk到底长啥样，大概率是PDF解析把表格和正文混一起了。

产品手册这种文档光靠固定长度切分确实容易翻车，表格和参数列表被切碎后语义全乱了。建议你先别急着调chunk size，拿几个bad case看看召回的chunk到底是切歪了还是embedding压根没抓住“流程”这类词。可以试试按标题层级做结构化切分，或者用small-to-big的思路，检索用小块但喂给模型时带上父级上下文。另外确认下你query有没有做改写，直接拿“售后服务流程”去匹配，跟手册里的表述可能差挺远的。