RAG检索老是召回不相关片段，是切分粒度问题还是embedding选型不对？

我之前也踩过类似的坑，问题不一定在切分粒度，bge对操作步骤这种强指令性文本确实容易“抓偏”。建议先试试对召回结果加个基于关键词或规则的过滤，比如把含“步骤”“点击”“按”这种词的片段权重拉高。另外重排序（rerank）非常值得上，尤其用bge-reranker，对中文技术文档效果提升挺明显的。如果还不行，再考虑换模型也不迟。

说实话你这问题我去年也踩过一模一样的坑，最后发现根子不在切分粒度，而是bge对“操作步骤”这种强指令性文本的语义重心抓不准。我后来换成了m3e-large，配合一个简单的规则：把包含“点击/输入/选择”这类动词的句子单独切成小块，召回准确率直接上了一个台阶。重排序强烈建议加，用bge-reranker-base就行，成本不高但能把真正讲步骤的段落顶上前面，比反复调chunk参数管用多了。

建议先看下chunk切分是不是把操作步骤和说明文字混在一起了，分开存效果会好很多。

重排序确实值得加，尤其你这种技术文档，bge对短句召回本来就一般。

说实话我觉得你这问题大概率不是切分粒度的事儿，bge-large-zh对操作步骤这种强指令性文本本来就偏弱，它更擅长匹配语义相近的泛化描述。我之前做类似手册问答时，把embedding换成bge-m3或者text2vec-large-chinese，召回准确率明显上来了。另外重排序强烈建议加，用bge-reranker-base跑一遍，能把“重置密码”和“操作步骤”的相关性权重拉正，成本也不高。你试试先换模型，如果还不行再调chunk大小，别一上来就动切分参数。

说实话我觉得你这个情况大概率不是embedding选型的问题，bge-large-zh在中文语义上已经算第一梯队了，换模型收益可能没那么明显。问题更可能出在切分粒度上，500调到200看起来是变小了，但产品手册里“重置密码”这类操作步骤往往是一段带编号的流程，如果切分点刚好落在步骤中间，那语义就被打散了。建议你先看看召回片段的实际内容，是不是经常出现“前半段是概述、后半段是操作”这种割裂情况。另外可以试试按文档结构切分，比如把标题和正文绑定成一个chunk，或者用markdown的层级来定位段落，这样比单纯调chunk_size更有效。重排序我觉得值得加，尤其对技术文档来说，用bge-reranker或者cross-encoder做二次过滤，能把那些“提到关键词但没讲核心操作”的片段压下去。不过也别指望reranker能救一切，它更擅长在候选集里排序，如果初始召回就没覆盖到真正的步骤段，后面再怎么排也白搭。还有个小建议：你可以针对“如何重置密码”这类高频问题，手动给几个标准答案片段加权重，或者做一层简单的规则匹配，比如识别“步骤1、步骤2”这种模式，能快速兜底。

我之前也踩过类似的坑，后来发现很多时候不是模型不行，而是检索链路的问题。bge对语义相似度敏感，但“如何重置密码”和“忘记密码时可通过管理员重置”这种句子在向量空间里确实太近了，单纯调chunk_size效果有限。建议你先加个重排（比如bge-reranker），把召回的前20条再精排一下，操作步骤的段落通常关键词更具体，重排后位置会明显提升。另外切分时试试按标题或章节边界来切，而不是纯按字数，产品手册里“操作步骤”这类小标题本身就是很好的语义锚点。如果换模型，可以看看gte-large-zh或者m3e，但我觉得重排的优先级更高，先别急着换embedding。

重排基本是必须的，你这问题更像检索链路缺了rerank，光调切分解决不了语义漂移。

先加个rerank试试，bge对操作步骤这种短句确实不敏感，换个m3e或微调下可能更管用。

先别急着换模型，试试给“操作步骤”类文档单独建索引，再加重排序，bge对短指令确实不太敏感。