为何企业级RAG需要混合搜索，而非仅靠向量技术
嵌入模型会遗漏发票编号和错误代码。企业级RAG需要混合搜索方式：结合BM25与密集检索并通过排名融合来弥补标识符缺失的问题。
来源: Hybrid Search Beats Pure Vector Search: Why Semantic Search Alone Isn’t Enough for Enterprise RAG
企业级RAG最大的误解在于认为更优秀的嵌入模型就能自动生成更好的答案。实际上，答案的质量更多地取决于检索到的内容，而非所使用的聊天模型。
简介
检索增强生成技术允许助手在回应之前先从外部知识库中获取信息。大多数演示都将以向量搜索为核心：
Documents
│
Chunking
│
Embedding Model
│
Vector Database
│
Top-K Retrieval
│
Large Language Model
对文档进行嵌入处理，存储向量，然后为每个查询检索最近的相似项。这种模式在演示中表现优异，但在实际应用中往往会出现问题——尤其是在那些充斥着各种标识符的企业环境中。单纯的向量搜索很少能满足需求，混合搜索已成为专业RAG系统默认的检索策略。
向量搜索为何流行
关键词引擎通过匹配词元来工作。查询“如何重置密码？”会找到包含“重置/密码/账户”等词的文档；而尽管意图相同，“无法访问账户”这样的查询却可能完全找不到关于密码的文档。嵌入模型虽能将含义映射到向量空间，但同义表述仍可能产生冲突。对于常见问题解答和叙述性文档而言，这无疑是一项突破。
纯向量模型的局限性
企业语料库中充斥着发票编号、员工ID、错误代码、SKU、合同编号、政策编号以及版本字符串。这些字符串对用户而言很重要，但对密集型模型来说处理起来却很困难。
以如下记录为例：
Invoice Number : INV-93842
Status : Paid
Customer : ABC Corporation
当用户查询“发票INV-93842的状态如何？”时，嵌入模型往往因为更侧重“发票/支付”这类概念而非确切的编号，而返回账单相关指南而非该发票的信息。
更多失败场景
数据库错误搜索时会遇到：
ORA-12514
可能会返回通用的连接指南，而非 ORA-12514 错误页面。
类似产品查询的情况包括：
RTX-9000 Switch
可能会显示网络概览，而非 RTX-9000 手册。
关于版本的查询则：
Version 4.3.12
通常会获取通用的版本说明，而非专门针对 4.3.12 的内容。
医疗相关查询时：
Patient ID: P-482731
可能会返回注册操作流程文档，而非该患者的病历记录。
每当精确的标识符至关重要时，仅依靠语义相似度已无法保证准确性。
为何嵌入模型在此处表现不佳
模型学习的是“医生↔医师”以及“汽车↔机动车”这样的对应关系。而像：
INV-93842
或
RTX-9000
这样的字符串几乎不包含语义内容。将：
INV-93842
改为
INV-93843
在嵌入向量几乎保持不变的情况下改变了业务实体。这是密集检索的固有特性，而非某个供应商的缺陷。
企业级检索的分类
语义信息（保单政策、理赔流程、密码重置）——向量检索表现更佳。 精确信息（编号、代码、SKU、版本）——关键词/BM25检索更有效。
仅使用一种策略意味着在某一维度上表现优异，而在另一维度上则表现不佳。混合搜索正是为了解决这一问题而存在的。
引入混合搜索
不必只使用BM25或向量检索，而是同时运用两者并加以融合：
User Query
│
┌────────────────┴────────────────┐
│ │
▼ ▼
Keyword Search (BM25) Vector Search
│ │
└──────────────┬──────────────────┘
▼
Merge & Score Fusion
▼
Cross-Encoder Re-ranker
▼
Top Relevant Context
▼
Large Language Model
关键词检索能够保护标识符和罕见词汇，而向量检索则能处理同义词及不同表达方式。通过重排序机制（或互反排名融合）可以对用户查询得到的候选结果进行排序。
为何混合搜索更胜一筹
对于“为何发票 INV-93842 仍待审批？”这类问题，混合检索方式可以通过关键词匹配精确的标识符，利用向量技术获取相关的工作流文档，并重新排序，从而使发票记录处于首位的同时保留流程文档。每种技术都能发挥其最大优势。
总结
向量数据库依然是基础。它们无法完全取代传统的信息检索方式。企业知识包含散文、代码和记录等多种形式，混合检索正是为应对这种多样性而设计的。
再强大的聊天模型也无法弥补薄弱的候选集。与其在更复杂的生成模型或华丽的提示词上投入预算，不如优先投资于能够反复呈现正确内容的检索技术——在 RAG 系统中，答案的质量首先取决于检索质量。
在操作层面，需记录每条查询是由哪种检索方式产生的（关键词检索还是密集向量检索），在包含释义类问题与标识符查询的测试集上调整融合权重，并且对于仅涉及简单语义问题的演示，绝不能就宣布“RAG技术已实现”。实际上，企业们在生产环境中常常失败的就是处理标识符查询这类测试。
高效构建混合检索系统
在现有的向量索引之外，先使用BM25（或类似的词汇搜索算法）——许多向量数据库已经提供了混合检索接口。确保分块标识符保持一致，这样融合操作就会非常简单。在训练交叉编码器重排模型之前，可以先采用互反排名融合方法；这种方法的计算成本较低，通常已经足以证明标识符查询的差距正在缩小。
创建一个包含两个数据组的评估集：释义类问题（语义层面）和标识符类问题（精确匹配）。分别计算recall@k得分。只有当两个数据组的性能都有提升，或者至少其中一个有所提升且未拖累另一个时，才使用混合检索方式。注意延迟问题：并行运行两个检索器通常没有问题，但对大量候选项进行串行重排序则不可行。
分块策略依然很重要。埋藏在巨大数据块中的标识符会削弱BM25算法及密集得分的效果。应选择能够保持发票标题、错误代码名称和SKU行完整性的分块边界。在数据融合之前，通过元数据过滤器（产品线、地区、文档类型）可进一步减少错误匹配。
最后，需向产品相关方阐明：“我们已嵌入所有信息”并非一种有效的检索策略。混合检索方式才是符合企业实际提问方式的策略——一半是自然语言，另一半是从屏幕上输入的工单编号。
部署检查清单
- 从生产日志中提取查询内容，标记哪些需要精确匹配，哪些需要意译。
- 在与向量索引相同的语料库和分块ID基础上构建词汇搜索功能。
- 与RRF结合使用，为每次匹配记录来源信息。
- 分别测量两个数据集的recall@k值，据此调整权重。
- 只有在延迟预算允许的情况下，才考虑使用学习型重排序器。
- 在元数据中保留标识符字段，以便在用户界面已知晓发票号或SKU时进行可选的严格过滤。
那些直接选择“更大嵌入模型”的团队，往往只会用更精美的向量重新遇到同样的ID识别问题。混合搜索这种解决方案虽然乏味，却能适应工单的表述方式。