RAG召回效果差，是切分粒度问题还是embedding模型选错了？

合同条款这种场景光靠调chunk_size确实很难搞，因为关键信息经常跨段落甚至跨页，切碎了语义就断了。你可以先试试按条款标题做结构化切分，别让固定长度硬切，这个改动成本最低。另外bge-small对长文本和数字类细节本身就不太敏感，换个bge-m3或者加个reranker可能比继续调参见效快，reranker其实不贵，值得试。

你这情况我踩过一模一样的坑，合同条款这种带具体数字的问题，光调chunk_size基本没用。bge-small对长句和数字的语义区分度确实一般，但先别急着换模型，建议你先看看切分是不是把“违约责任”和金额硬生生切到两个chunk里了。按条款结构切、保住完整语义单元，再配个bge-reranker-base，成本很低但召回排序会明显好转。

你这个情况我太熟了，去年做合同问答踩过一模一样的坑。先说结论：你这种“具体金额”查不到的问题，八成不是embedding的锅，而是切分把关键信息切碎了。技术手册和合同条款最要命的就是表格和长句，按固定字数切很容易把“违约责任”和后面的金额拆到两个chunk里，那检索再强也白搭。你可以先别急着换模型，把PDF解析出来的文本打印几段看看，大概率会发现表格变成了一堆乱序的数字。bge-small其实对中文短句还行，真正拖后腿的是chunk里塞了太多无关上下文，把语义稀释了。至于reranker，我觉得在你切分修好之前上它性价比不高，它只能帮你从候选里挑好的，候选本身就是错的它也没辙。建议先试试按标题层级或者条款编号做结构化切分，每个chunk带上前置的章节标题，这个改动成本最低但效果往往立竿见影。等切分干净了还不行，再考虑换bge-m3或者加个轻量reranker也不迟。

我之前也遇到过类似问题，后来换了方案。

写得挺好，建议补充一些性能数据。

你这个情况我太熟了，合同条款类文档问具体金额召回不准，八成不是embedding的锅。bge-small在中文上其实够用，问题是PDF和Word转出来的文本经常带着表格、页眉页脚、跨页断句这些脏东西，切出来的chunk本身就是残的，再好的模型也救不回来。建议先别急着调参数，把解析后的文本捞出来人肉看几个召回失败的case，大概率能发现chunk里条款被拦腰截断或者金额和条款标题分家了。切分上可以试试按结构切而不是按固定长度切，合同这种有条款编号的，拿编号当分隔符比chunk_size靠谱得多。overlap调太大反而会引入噪音，让相似度算出来虚高。reranker值得上，但别一上来就整大的，bge-reranker-base这种轻量的先跑跑看，对“具体金额”这种细粒度匹配提升挺明显的。另外可以给chunk加点元数据，比如所属章节标题拼到chunk前面再embed，召回命中率会好不少。

感觉你这个问题大概率出在切分上，合同条款这种结构化强的内容，固定chunk_size很容易把一条完整条款拦腰截断，金额关键词可能落在相邻chunk里。建议先试试按条款编号或段落标题做语义切分，别死磕参数调优。bge-small其实够用，但配个轻量reranker（比如bge-reranker-base）性价比很高，能明显拉回相关性。也可以先拿几个badcase手动看看召回的chunk到底缺了什么，比盲调参数快多了。

你这个“具体金额”召回不准的问题，我觉得八成是切分把关键信息切碎了，技术手册和合同条款这种结构化内容，固定chunk_size很容易把一条完整的违约责任拆到两个块里，调大小治标不治本。建议先换成按标题/条款层级切，或者用recursive切分加一点上下文补全，再试试bge-small先别急着换。reranker倒是可以上一个轻量的，对召回排序提升挺明显，成本也没你想的那么高。另外可以查下query和chunk的相似度分布，看看是召回阶段就没捞到还是排序排错了，定位清楚再动手。