一、问题：用户问什么，AI答非所问
售后知识库上线第一周，业务员反馈最多的一句话是：“我问的它怎么答不上来？”我去翻日志，发现两类典型问题：
第一类：用户输入“CONC1600”，AI去向量库里搜“CONC1600”，搜不到。因为手册里写的是“CONCEPTc系列计量泵”，没有“CONC1600”这个字符串。向量模型不认识型号这种“短码”，把它当成噪音滤掉了。
第二类：用户输入“泵头漏液怎么办”，AI搜出来一堆“安装说明”“保养周期”，就是没有“漏液原因”。因为手册里“漏液”这个词出现得少，大部分写的是“密封圈老化导致泄漏”。
纯向量检索，语义泛化能力强，但对“精确匹配”不敏感。用户输型号，它当没看见；用户输口语，它找不着北。
二、尝试：换个模型，效果也没好到哪去
我一开始以为是Embedding模型不行，换了好几个——百炼、OpenAI、Cohere，效果差不多。后来才意识到：问题不在模型，在检索方式本身。向量检索擅长“找相似”，不擅长“找精确”。用户要的是“CONC1600”这个字符串，它却去找“和CONC1600语义相似”的东西。型号哪有语义？它就是一行代码。
三、解法：混合检索，关键词+向量一起上
纯关键词检索（BM25）擅长精确匹配，但不理解语义；纯向量检索擅长语义泛化，但不认识短码。两个都有短板，那就拼在一起。
流程改成这样：
关键词召回：用户输入“CONC1600 泵头漏液”，先用BM25在文档里匹配关键词，召回Top50。这一步保证“CONC1600”这种精确词不会漏。
向量重排：把Top50的结果再用向量检索算一遍相似度，取Top3。这一步把“泵头漏液”这种口语表达，和手册里的“密封圈老化”匹配上。
合并输出：把Top3送给大模型生成答案。
BM25负责“准”，向量负责“全”。两个拼在一起，各补各的短板。
四、效果：两种场景都稳住了
改完跑了半个月，两类问题明显改善：
用户输“CONC1600”，BM25直接从文档里把包含这个字符串的段落拽出来，向量再按相关性排个序，不会漏了。
用户输“泵头漏液”，BM25能捞到带“漏液”的文档（虽然不多），向量再从这些文档里找到“密封圈老化”的段落。
之前两类问题的错误率降了一大截，业务员没再抱怨“答非所问”。
五、还有哪些坑没填平
参数调优：BM25和向量的权重怎么配？目前是简单拼接，后面可能要调一下，不同场景侧重不同。
长文本截断：检索回来的段落太长，超过模型输入限制，还得切。
速度：两阶段检索比纯向量慢了一点，还在接受范围内。如果数据量再大，可能要换更快的检索库。
六、总结
RAG检索不准，不一定是模型不行，可能是方式不对。纯向量检索适合“模糊找”，纯关键词检索适合“精确查”。两个都有短板，那就拼在一起。混合检索不是什么新技术，但它是目前能落地、成本低、见效快的方案。如果你也遇到“用户输型号搜不到”“输口语找不着”的问题，不妨试试。
