RAG 二路召回(向量召回+ES)
目录
一、结论先行(非常重要)
在 智能客服(带销售能力) 场景下:
- 大多数团队:初期不需要 ES 二路召回
- 中后期、规模化后:ES 二路召回几乎一定会出现
但它出现的原因,不是为了提升“整体准确率”,而是为了兜住 向量检索天然不擅长的那一类 query。
二、你当前方案的能力边界
你现在是:
MiniLM / LLM
↓
RAG 前置过滤(标签 / 风险 / 场景)
↓
向量化检索(Milvus / Faiss)
↓
RAG → LLM
这个架构非常合理,但它天然有 4 个盲区。
三、向量检索的 4 类“硬伤场景”
1️⃣ 精确词 / 结构化信息查询(ES 擅长)
典型例子:
- “合同编号 A-2023-019 的付款条件”
- “iPhone 15 Pro Max 256G 蓝色”
- “退款多久到账 7 天还是 14 天”
- “SKU: ZX-88 是否有现货”
🔴 向量问题:
- embedding 会把编号、SKU 当噪声
- 相似度语义很近,但关键信息错一个就全错
🟢 ES 优势:
- keyword / term / phrase 精准命中
- 对“数字 + 专有名词”极其友好
2️⃣ 否定 / 对比 / 条件组合类 query
例子:
- “不需要发票的情况下能退款吗”
- “不包含售后的套餐有哪些”
- “除了企业版,还有什么方案”
🔴 向量问题:
- embedding 对 “不 / 除了 / 排除” 极不敏感
- 相似度高,但逻辑完全反了
🟢 ES:
- bool query / must_not / filter 非常稳
3️⃣ 高频短 query(信息密度太低)
例子:
- “退款”
- “合同”
- “价格”
- “售后”
🔴 向量问题:
- embedding 非常模糊
- TopK 随机性强
🟢 ES:
- 可以直接命中 FAQ / 标题 / keyword
4️⃣ 冷启动知识 / 新增文档
- 新产品刚上线
- 新合同模板
- 新促销政策
🔴 向量:
- embedding 未覆盖
- ANN recall 波动大
🟢 ES:
- 文档一进索引即可命中
四、那你现在“要不要”加 ES?
用下面这个决策表判断(建议你真的对照跑指标):
| 现象 | 是否需要 ES |
|---|---|
| TopK 召回中,经常“语义对,但细节错” | ✅ 强烈建议 |
| 查询中包含 SKU / 编号 / 型号 / 数字 | ✅ |
| 大量单词 query(1–2 个词) | ✅ |
| 投诉“明明文档有,但答非所问” | ✅ |
| query 以自然语言为主,长句为主 | ❌ |
| 知识变化不频繁 | ❌ |
五、推荐的「正确」二路召回方式(重点)
⚠️ 不推荐你现在就搞复杂的 Learning to Rank
你可以用极简、工程友好的方式:
方案 A:条件触发 ES(推荐)
query
↓
规则判断:
- 是否包含数字 / SKU / 型号
- 长度 < N
- 命中“精确类 intent”
↓
是 → ES + 向量
否 → 仅向量
召回合并策略(简单有效)
docs = []
docs += vector_docs[:K1]
docs += es_docs[:K2]
docs = dedup(docs)
docs = rerank_by_llm(docs)
方案 B:ES 做兜底(更稳)
向量 TopK 低于阈值
↓
启用 ES
这和你现在的 T_MIN / T_MULTI → 走 LLM 思路是一致的。
六、对你当前架构的明确建议
结合你前面的所有问题(敏感标签、LLM 兜底、MiniLM 回流):
我给你的建议是:
-
短期(现在)
-
不强制上 ES
-
先监控:
- 向量 TopK 覆盖率
- 命中但答案错误率
- 数字/型号类 query 占比
-
-
中期(出现以下任一)
- 明确引入 ES 二路召回
- 用规则或 intent 触发,不要全量并发
-
长期
- ES = 精确召回
- 向量 = 语义召回
- LLM = rerank + 推理
- MiniLM = 前置路由
七、一句话总结(给你对外解释用)
向量检索解决“意思像不像”,ES 解决“是不是它本身”。
在智能客服中,二者不是竞争关系,而是分工关系。
如果你愿意,下一步我可以帮你:
- 直接列一个 “哪些 intent 一定要 ES” 白名单
- 或给你一个 Python 级别的双路召回伪代码模板
你更想看哪一个?

浙公网安备 33010602011771号