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投入产出比一般，除非你有大量领域标注对，不然先把切分和检索链路捋顺更划算。