RAG检索老召回不相关片段，是chunk切法问题还是embedding模型选错了？

说实话你这情况我大概率也踩过坑，建议先别急着怪embedding，bge-m3对中英混语料其实够用了。我当时的排查顺序是：先看召回片段在原文里的位置和上下文，如果它们确实涉及“退货”但没带出“流程”，那多半是chunk切太碎导致语义断了，试着按章节或二级标题切，别死守固定长度。另外query改写很关键，你说的“退款流程”和文档里的“退货政策”字面差太多，可以加个简单的同义扩展试试，比如把“退款”映射到“退货/售后”再检索，效果会立竿见影。最后才轮到调embedding模型，换jina或e5-mistral对比下，但通常前两步改完就稳了。

这问题八成出在chunk切法上，产品手册和工单混着切，语义早被切碎了，先按文档结构切试试。

说实话你这个问题我太有共鸣了，之前调本地知识库也卡在类似的地方。我个人排查顺序会先看query改写，因为“退款流程”和“退货政策”在语义上确实近，但如果能把用户问题拆成“操作步骤”和“政策说明”两个意图维度，召回会准很多。chunk切法我觉得影响没那么大，512和256你都试过还不行，说明问题可能出在检索粒度上——你切的是固定长度，但工单记录里一个完整流程可能横跨好几个chunk，这时候更建议按段落或按语义边界去切，比如检测到“步骤一”“接下来”这种词就断开。embedding模型我倒觉得bge-m3对中英混合还行，但你这种情况可以试试混合检索，就是向量召回和BM25关键词召回各拿一部分结果再融合，因为“退款流程”这种词在文档里可能字面上就是标题，传统关键词反而能直接命中。另外你提到擦边内容排前面，我怀疑是文档里“退货政策”这种段落本身写得又长又详细，embedding容易给高相似度，可以试试给不同来源的文档加metadata权重，比如工单记录权重高于产品手册。最后问一下，你检索回来的片段有没有做rerank？如果没加的话，光靠向量相似度排前面的确实经常是语义泛泛的段落，加个cross-encoder重排一下往往立竿见影。

说实话我觉得你这情况大概率不是embedding模型的问题，bge-m3对中英混合已经算友好了。更像是chunk切分太机械，产品手册里“退款流程”和“退货政策”本来就在相邻段落，512的窗口很容易把语义边界糊在一起。建议先看下召回结果里是不是总带着相近标题的片段，如果是，试试按文档结构（比如标题层级）来切，而不是死守固定长度。另外query改写值得查一下，你原问句挺明确的，但如果系统自动扩写成了“退款退货怎么处理”，那检索方向就跑偏了。我一般会先打印出召回的top10原文，肉眼对比下到底是切块截断了关键步骤，还是embedding本身没拉开距离，这样能省不少排查时间。

说实话你这情况我太熟了，之前调工单系统RAG时也卡在类似坑里。我第一反应不是切块或embedding，而是你先看看召回片段里的“退货政策”是不是跟“退款流程”在原文里就挨得近——很多产品手册喜欢把退款和退货写在同一章节，512的chunk一框进去语义就糊了。这种时候我一般先试128或者更小的块，配合50%重叠，至少能把“政策”和“操作步骤”物理隔开。但你这还混着中英文，bge-m3对混合语料其实还行，我更怀疑是query本身太口语化，比如“怎么走”这种说法跟手册里的书面用词“退款流程指引”匹配度很低，embedding模型对短query的语义泛化能力有限。我建议你先别急着换模型，拿几个典型问题跑一下query改写，看看是不是把“退款流程怎么走”扩写成“退款操作步骤说明”之类再检索，召回质量会不会明显变化。如果改写后还是不行，再回头检查chunk边界，用句号或标题做硬切分，别单纯按字符数切。另外top_k你调了但没提是不是只看前几段，有时候真正的步骤藏在第4、5位，你可以先不调k，把召回前十都打印出来人工看一眼，定位是排序问题还是压根没召回。我自己的排查顺序是：先打印检索结果看相关性，再试query改写，然后调chunk策略，最后才怀疑embedding模型。你那个“擦边内容”如果每次都出现在前面，很可能是相似度阈值太低，加上“退货”“退款”这种词向量距离太近导致的，可以试试看加一点MMR或重排模型，哪怕是个简单的cross-encoder也能把真正步骤顶上来。

先别急着换模型，把query和文档都过一遍中文分词和同义词扩展，大概率是退款和退货没映射上。

我之前也踩过这个坑，后来发现query改写没做对占很大原因。“退款流程怎么走”这种口语化问法，跟手册里“退款操作步骤”的措辞差挺远，embedding再强也难对齐。你可以先加个轻量query改写，把口语转成关键词再检索试试。另外chunk建议按标题层级切，别只按字数硬切，产品手册这种结构化文档尤其明显。bge-m3对中英混合其实还行，先别急着换模型。

我之前也踩过这个坑，感觉更像是query和文档在语义空间里没对齐，不是单纯chunk大小的问题。产品手册和工单混在一起，术语表达差异挺大的，embedding模型再好也容易被“退货政策”这种高频词带偏。建议先别急着换模型，拿几条bad case手动看看query和召回片段的向量相似度分布，大概率能看出是切分粒度还是语义漂移的问题。另外你试过在检索前加一层query改写或者同义词扩展吗，这块对中文混合语料提升挺明显的。

我踩过类似的坑，最后发现是query和文档语义空间没对齐，尤其你这种中英混着的手册，bge-m3其实够用，但直接拿原始query去搜容易偏。可以试试先做一步轻量query改写，把“退款流程”扩成“退款操作步骤 申请入口 审核”，再检索会稳不少。另外chunk别光看大小，按标题层级切、让每个片段自带小标题，召回的相关性提升很明显。