RAG召回效果不理想，是不是我Embedding模型选错了？

操作步骤这种强流程性的内容，光靠向量相似度确实容易跑偏，bge对概念性描述更敏感。建议先别急着换模型，试试把chunk里带动作词和参数的句子单独抽出来建索引，或者给每个chunk人工打两三个“操作标签”再检索。另外FAISS只用dense的话，对精确数字和动词匹配很吃亏，可以加个BM25的分数融合，两者按权重rerank一下，效果往往比单换embedding明显。你那边chunk切分是按段落还是按语义窗口切的？有时候步骤被截断成两半也会导致召回碎片化。

说实话你这个情况我上个月刚经历过一轮，最后发现真不全是embedding的锅。bge-large-zh-v1.5本身对通用语义理解没问题，但企业内部知识库那种操作手册，很多关键信息藏在“点击右上角设置”这种动作描述里，跟用户问的“怎么改密码”在向量空间里距离其实挺远的。我后来是把chunk策略改成按步骤切，一个操作流程单独成一个块，而不是按固定字数硬切，召回率立刻上来了。另外你说的dense+sparse混合检索我强烈建议试一下，faiss配BM25做结果融合，很多术语和编号类查询都是靠sparse救回来的，尤其你们文档里如果有很多产品型号或者内部系统名，纯dense很容易漏。还有个小坑，HyDE对操作类问题其实帮助不大，它更适合概念解释型问答，你生成的假设文档如果本身就泛，反而会把检索带偏。我建议你先别急着换模型，拿几个失败case看看chunk是不是把关键步骤截断了，或者相邻段落语义太像导致faiss返回了一堆重复内容。如果调完还不行，再考虑换m3e或者OpenAI的embedding对比一下，但大概率不是模型单方面的问题。

实操类问题用向量检索本来就吃亏，建议先试试把标题和步骤单独抽出来建索引，比换模型见效快。

说实话我不太觉得是你embedding选错了，bge-large-zh-v1.5在中文通用场景下已经算很能打的了。你描述的这个现象，更像是chunk的语义边界跟用户问题粒度不匹配——用户问“具体操作步骤”，但你的chunk可能把步骤和概念解释揉在一起了，导致向量空间里它们离得太近。我建议你先手动看几个召回失败的case，对比一下命中的chunk和真正该命中的chunk在内容结构上差在哪，多半会发现是chunk里混入了太多无关上下文。

另外你提到HyDE提升有限，这其实挺正常的，因为HyDE对“问题本身描述清晰”的场景更有效，而企业内部知识库的问题往往隐含了业务上下文，你生成假文档的时候也容易偏。我倒是觉得可以试试把chunk再切细一点，比如按操作步骤的每个动作来切，而不是按固定字数，然后检索的时候用multi-vector或者重排序模型（比如bge-reranker）把分数拉一下。dense+sparse混合检索确实值得加，尤其你们如果有很多专有名词、设备型号这种，BM25能帮你把精确匹配的片段捞回来，但别指望它单独解决语义粒度问题。

还有个思路你可能没试过，就是给每个chunk加一个“标题”或者“摘要”字段，单独用这个字段做一次检索，再拿原文去重排序。我之前在一个工业文档项目里这么干过，效果比单纯调chunk size明显。你现在这个阶段，别急着换模型，先把bad case的分布统计一下，看看是“查得到但排错”还是“根本就没进候选集”，这决定了你是该调检索策略还是该调索引结构。

说实话我觉得你大概率不是embedding模型的问题，bge-large-zh-v1.5在通用中文语义上已经挺能打了。企业知识库这种场景，真正卡脖子的往往是chunk的语义边界，你按固定字数切，很可能把“操作步骤”和“概念解释”硬塞进同一个片段里，检索时向量被概念部分带偏了。我建议你先手动抽几个用户query，把召回结果挨个看一遍，确认是“语义相近但内容不对”还是“字面都离得远”——前者说明切块粒度该按段落或标题来切，后者才考虑换模型。另外你试HyDE提升有限，可能因为生成伪文档本身质量就不高，对领域术语反而引入噪音。混合检索确实值得试，但别一上来就上dense+sparse，先试试在bge向量基础上加BM25的分数融合，用rrf或者简单加权，很多情况下能救回一批精确术语匹配。还有个小细节，faiss检索时你有没有做查询侧的指令前缀，bge的中文模型对query和document不对称训练，有时候在query前面加个“为这个句子生成表示”之类的提示词，效果会差很多。我自己踩过类似的坑，最后发现是chunk里标题信息丢太多，把每个片段的父级标题拼回去，召回直接涨了一截。你先别急着换模型，把排查重心放在数据切分和索引结构上，大概率能突破。

说实话我觉得你大概率不是embedding模型的问题，bge-large-zh-v1.5在中文语义理解上已经够用了，尤其针对“具体操作步骤”这种强指令型query，dense向量天生就容易把“怎么打开设置”和“设置功能介绍”混在一起。我自己做过类似的知识库项目，最后发现卡点往往在chunk的切分逻辑上——单纯按字数切会把操作步骤的上下文拦腰斩断，比如“点击右上角”和“然后选择高级选项”被分到两个片段里，那召回当然只能命中泛泛的概念。建议你先仔细看看那些失败case的原文，是不是步骤类内容经常分布在chunk边界附近，如果是的话，可以试试用结构感知切分，比如按markdown标题或者列表项来切，让每个chunk内部是一个相对完整的动作流。另外你提到HyDE效果一般，我猜是因为生成的伪文档太抽象，反而拉远了和具体步骤的距离，不如直接用query里的关键词做BM25和dense结果做fusion，像RRF这种简单方法有时候比换模型立竿见影。当然也不排除你的知识库本身文档风格比较概括，如果原文就没写清楚步骤，那召回再准也没用。可以先跑几个典型的步骤类query，把top10结果挨个看一遍，定位是切分问题还是原文信息缺失，再决定要不要上混合检索。

说实话我觉得你这个问题未必全出在embedding上。bge-large-zh-v1.5对通用语义理解已经挺强了，但企业内部知识库那种操作步骤，往往是“动作+对象+条件”的强逻辑结构，跟模型训练时见到的自然语言问法差异很大。我自己踩过类似的坑，后来发现是chunk切得太“整”了，把步骤拆散了，检索时只匹配到概念句，反而漏了关键操作句。

你可以先试试按标题或段落语义来切，而不是固定字符数，比如把“如何导出报表”这类操作说明单独当成一个chunk。另外，HyDE对长尾query有用，但如果是高频操作问题，它反而会把问题泛化，建议对比一下不用的效果。

混合检索确实值得试，但别一上来就上sparse，可以先在faiss里加一个bm25的权重融合，用rrf简单合并结果，看召回率有没有明显变化。如果还是不行，再考虑领域微调embedding，不过那需要标注数据，成本高一些。

还有个小排查点：你用户问的时候，query本身是不是太口语化？比如“怎么把那个表导出来”和“导出报表的操作步骤”检索效果可能差很多，可以试着做一下query改写，把代词和模糊词补全，往往比换模型见效快。

说实话操作步骤这种query，本身就很吃关键词精确匹配，bge这种稠密向量对长尾词和动作序列天然不敏感。我建议你先别急着换模型，在faiss里加个bm25的并行召回通道，做个简单的rrf融合，大概率能救回来不少。另外你chunk切法是不是按固定长度硬切的？操作步骤经常被拦腰截断，试试按markdown标题或者步骤编号作为边界来切，语义粒度会比单纯调大小靠谱得多。

bge-large-zh-v1.5本身对中文通用语义没问题，但企业内部的缩写、流程名它真不一定见过，建议先拿几条badcase去算一下query和正确chunk的相似度，看是排序靠后还是压根没进候选。如果分数本身就很低，那大概率是领域词没被模型理解，微调embedding或者加个同义词词典比换检索策略更直接。混合检索能救一部分关键词精确匹配的场景，比如步骤里带具体参数名那种，但别指望它解决语义漂移。

我之前也遇到过类似情况，bge-large-zh对通用语义没问题，但你们内部那些操作步骤里的专有名词和缩写它可能真没怎么见过。可以先拿几条召回失败的query手动算一下和正确chunk的相似度，看是排序靠后还是压根没进候选。如果相似度本身就不高，那大概率是embedding对领域词不敏感，试试用业务数据微调一下或者换bge-m3这种多粒度支持的。另外dense+sparse混合确实值得试，操作步骤这种query关键词匹配往往比纯语义更管用。

我之前也踩过这个坑，bge-large-zh其实不算差，问题大概率出在chunk把操作步骤切碎了，语义不完整检索自然抓不住。你可以先别急着换模型，拿几条bad case把召回片段打出来看看，是不是关键步骤被切到隔壁块去了。另外dense+sparse混合确实值得试，BM25对步骤类里的具体动词和参数名很敏感，经常能补上embedding漏掉的那部分。HyDE对这种流程性query帮助有限，它更擅长概念扩展而不是精确定位。