面经策

什么混合检索？在基于大模型的应用开发中，混合检索主要解决什么问题？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

混合检索指向量（语义）检索与关键词（BM25 等）检索并行执行、结果融合（如 RRF 倒数排序融合）的方案。

它解决的业务问题很具体：纯语义检索对"行话"无能为力。用户搜"订单 RB20260314 退款进度"，向量检索会把语义上相似的"退货流程"都捞回来，却抓不住订单号这种精确标识；反之纯关键词检索又理解不了口语化提问"东西还没到咋退钱"。企业知识库里 SKU 编码、产品型号、法条编号、人名地名这类精确信号占比很高，单一检索方式的召回缺口会直接转化为客服答非所问、用户投诉。

落地建议：以我经验，混合检索是 RAG 从 Demo 走向生产的分水岭，成本低（ES/开源 BM25 + 向量库并行）、收益确定性高，属于"必做项"而非"优化项"。真正要权衡的是后续是否加 Rerank 精排——那才涉及延迟与成本的取舍。

🏗 系统架构师 ​

核心结论：混合检索 = 向量语义检索 + 关键词（BM25）检索（常再加结构化过滤）多路并行，RRF 或加权融合后统一排序。它解决单一检索模态的覆盖缺陷。

解决的三个问题：

  • 专有名词/型号/错误码：Embedding 对低频精确 token 不敏感，BM25 恰好擅长精确词匹配，两者互补；
  • 语义改写：用户问"怎么退款"，向量能召回"售后流程"文档，BM25 召不回，向量补位；
  • 跨语言：多语向量模型可跨语言检索，BM25 不行，混合后鲁棒性更好。

架构上的取舍：多一路检索就多一倍检索延迟和一倍存储（向量库 + 倒排索引），融合层（RRF 最常用，免调参）是额外的故障点。我的做法：QPS 低的场景直接上，高 QPS 场景两路并发 fan-out + 短超时降级到单路。

量级：向量检索 P99 通常 10~50ms，BM25 5~20ms，融合层 1ms 级，整体增加的延迟可接受；收益是 recall@50 通常能提 10~20 个点，是 RAG 优化里 ROI 最稳定的手段之一。ES 8.x 同时支持 kNN 和 BM25，一套系统搞定两路，是省运维成本的常见选型。

💻 全栈开发专家 ​

混合检索 = 语义向量检索 + 关键词（BM25）检索并行跑，再用 RRF（Reciprocal Rank Fusion）或加权融合结果。它主要解决两个问题：一是词表不匹配——用户查「Q3 毛利率」，文档写「第三季度 Gross Margin」，纯向量可能召不回；二是专有名词/型号/缩写——「WSS-4500 型号故障码 E12」这种精确词，Embedding 反而不如倒排索引准。

我们的实现（Elasticsearch 8 一站式）：

json
GET /docs/_search
{
  "retriever": { "rrf": { "retrievers": [
      { "standard": { "query": { "match": { "content": "WSS-4500 E12" } } } },
      { "knn": { "field": "embedding", "query_vector": [/* ... */], "k": 20, "num_candidates": 200 } }
  ], "rank_constant": 10, "window_size": 50 } }
}

坑：两路分数尺度完全不同（BM25 无界、余弦 0~1），直接加权没意义，一定用 RRF 或先各自归一化；另外关键词路要做同义词词典维护，否则中文分词质量会拖后腿。上线后长尾 query 的命中率提升明显，这是 RAG 里必做的一步。