RAG召回准确率上不去，重排序也试了，还能从哪优化？

你这数据量直接上微调embedding性价比真不高，先把父子分块和元数据过滤试了再说。

别急着微调，先试试parent-child拆分，小chunk召回大chunk喂给reranker，提升往往很明显。

你这情况我太熟了，之前做合同审查也卡在top5召回60%出头。固定500切分其实挺伤的，PDF转出来段落长短差异大，强行500字会把一个完整知识点劈成两半，或者把不相关内容缝在一起。我后来改成按标题层级和段落语义边界切，长段落再递归拆，召回直接涨了8个点。元数据过滤确实容易被忽略，比如把文档来源、章节路径、页码存进chunk的metadata，检索时按业务范围先过滤一轮，比纯靠向量相似度高效率多。parent-child结构我个人觉得值得试，但别用得太重，child负责精准匹配，parent负责给上下文，对回答质量提升明显，对召回率本身帮助有限。微调embedding这事，如果你领域词特别专，比如法律条款、设备型号，可以搞几百条标注数据试下，但几千份PDF的企业库，大概率是查询和文档表述差异太大，微调未必能救。倒是可以查查reranker的输入，是不是把top100里已经漏掉相关文档了，有时候问题出在召回阶段候选集太窄，reranker再强也没用。另外你试过query改写具体怎么改的吗？是只做同义替换还是加了推理扩展？这块我觉得比换模型性价比高。

几千份PDF固定500切分太糙了，先按标题层级切再合并试试，这块提升往往比换模型大。

固定chunk 500对PDF来说坑挺大的，表格和跨页段落很容易被切碎，召回阶段就已经丢信息了，后面重排再牛也救不回来。建议先拿badcase看看是切分问题还是语义匹配问题，别急着上微调。parent-child结构确实值得试，用小块召回、大块喂给LLM，配合元数据过滤（章节、页码）能砍掉不少噪声。微调embedding投入产出比一般，除非你有大量领域标注对，不然先把切分和检索链路捋顺更划算。

PDF切500太粗暴了，试试按标题层级切再补父子块，召回能涨一截。

几千份PDF固定切500其实挺伤的，表格和标题很容易被拦腰截断，检索时语义直接散了。建议先别急着微调embedding，把parent-child或小chunk检索+大chunk喂给LLM跑一版，再补上元数据过滤（部门、时间、文档类型），这块收益往往比换模型明显。微调embedding投入不小，除非你领域词特别偏，不然先做query改写和混合检索更划算。另外可以看看召回失败的badcase，是压根没召回到还是排序排掉了，定位清楚再动手。

几千份PDF固定500切分这个点其实挺关键的，PDF转出来的文本本身噪声就大，表格、页眉页脚、跨栏都可能混进chunk里，召回差有时候不是模型的问题而是底料就脏。我之前做类似项目时先花时间做了清洗和按语义段落切，光这一步召回就涨了十几个点。parent-child结构确实值得试，用小块做召回、大块喂给模型，能兼顾定位精度和上下文完整度。元数据过滤也别小看，比如按文档类型、时间、部门先缩范围，尤其企业知识库这种场景效果比调模型明显。微调embedding我踩过坑，如果领域术语特别重、通用模型明显语义漂移那可以上，但标注成本高，建议先用难例挖掘看看bad case到底集中在哪再决定。还有个容易被忽略的是query侧，用户问法和文档表述差太远时，光靠改写不够，可以试试加一步假设性答案生成再检索。

固定500切分太粗暴了，试试按语义或标题切，元数据过滤也能救不少。

几千份PDF固定切500这个策略我觉得问题挺大的，PDF转出来的文本质量本身参差不齐，表格、页眉页脚、跨页段落这些如果不做清洗，embedding再强也是在噪音上算相似度。可以试试按语义切分，比如用句向量相邻相似度找断点，或者按文档结构（标题层级）来切，chunk size也可以做成动态的。元数据过滤这块确实容易被忽略，如果知识库有部门、时间、文档类型这些字段，检索前先做一层硬过滤，候选集干净了准确率提升会很明显。parent-child结构我也在用，小块做召回、大块喂给LLM，对上下文完整性帮助不小，但要注意parent块别太大不然会稀释相关性信号。微调embedding的话，如果你有标注好的query-doc pair，哪怕几百条，用对比学习微调一下收益还是挺直接的，比盲目换模型强。另外可以查一下是不是召回阶段就把正确文档排到top20之外了，如果是那重排序再强也救不回来，这种情况得从query改写或者多路召回入手。

chunk固定500太糙了，按标题层级切加小模型摘要再召回，比调topk管用。

几千份PDF固定500切分太粗暴了，先按标题层级切再合并小chunk试试。微调embedding投入产出比一般，不如先把元数据过滤和parent-child做起来。