如果只看一些演示效果，向量检索真的很容易让人上头。语义相近的问题能召回，看起来比关键词检索聪明很多。我一开始也有过这种判断，觉得把 embedding 和向量库接好，RAG 这件事就算走上正轨了。
但真正把它放进客服场景之后，我很快就被现实教育了。
为什么我后来不再迷信单一路径
客服问题和普通问答有个很大的不同，就是它特别“杂”。用户会把商品名、规则名、活动名、型号、单号和口语化描述混在一起问。这个时候，如果你只依赖向量检索，很多强关键词问题会飘；如果只依赖 BM25，语义改写又会漏掉很多本该命中的答案。
我就是在这个阶段慢慢意识到，检索这件事不能押宝在某一种方案上。它更像是做一条组合拳，而不是找一个“最强组件”一把梭。
我为什么最后选了这套组合
在 aibotchat 里，我更认可的方向是把 BM25、向量检索、RRF 和 Reranker 组合起来用。原因很简单，它们解决的其实不是同一个问题。
- BM25 更擅长抓住关键词、术语、规则名、编号这类强文本信号。
- 向量检索 更适合处理“用户虽然换了个说法，但问的还是同一件事”。
- RRF 能把不同召回结果揉到一起，尽量降低某一边失手时的波动。
- Reranker 则负责最后那一步，把“看起来都差不多”的候选重新排一遍，让真正相关的片段往前走。
这套组合对我来说最有价值的地方，不是看起来高级，而是它更稳。客服系统最怕的不是偶尔不惊艳，而是经常不稳定。
做着做着，我最在意的反而不是召回率
一开始我会盯着召回结果看，想的是“有没有搜到”。后面做久了，我更在意的是：为什么搜到了还答不好，为什么这次走了检索，为什么那次没有走。
这会逼着你去认真看职责边界。文档导入怎么切片，检索器怎么融合，重排器怎么做最后判断，路由器什么时候该让请求进入 RAG，这些问题如果不拆开看，系统一旦答错，你连该从哪一层排查都不清楚。
这也是为什么我越来越觉得，RAG 真正的工程价值不只是“把知识接进模型”，而是把“应该给模型什么上下文”这件事从玄学变成可分析、可迭代的链路。
我踩过的几个坑
这块我自己印象比较深的几个坑，基本都和“过度简化检索”有关：
- 以为向量检索可以通吃，结果关键词问题频繁失手。
- 为了省事把所有请求都塞进 RAG，最后延迟和噪声一起上来了。
- 只看最终回答，不看召回链路，出了问题根本解释不清。
- 把重排当可有可无，结果候选一多，真正相关的片段排不上来。
这些坑让我慢慢接受一件事：检索不是外挂，也不是附属模块，它本身就是客服系统里最需要认真经营的一条链路。
我现在怎么理解这件事
如果现在让我再做一次，我不会再问“该不该上 RAG”，而会直接问“这条检索链路要怎么做得足够稳”。因为对客服来说，稳定命中、可解释、可优化，通常比单次回答特别惊艳更重要。
从这个角度看，aibotchat 给我的启发并不只是某几个技术名词，而是它让我更认真地去看待检索系统的工程边界。RAG 只有真的落进这种边界里，才会从概念变成能力。