文章摘要

前两篇分别讨论了RAG质量问题的总体诊断，以及文档解析与Chunk工程。本篇进入检索核心：为什么企业知识库不能只依赖单一向量召回，Dense、Sparse、Metadata过滤、融合、重排和权限控制应如何组合，以及怎样通过黄金测试集和线上指标持续治理召回质量。本文给出一套可落地的生产级检索架构、数据结构、查询流程、评测指标和灰度发布方法。

一、企业RAG的检索目标不是“语义相似”

普通向量搜索关注：

问题与文档是否语义接近

企业RAG还必须同时满足：

内容相关 ＋用户有权限 ＋版本有效 ＋来源可信 ＋包含可回答证据 ＋上下文不过度重复

例如用户问：

型号ZX-880的标准接口是什么？

Dense向量可能召回：

设备接口设计原则 同系列ZX-860说明书 接口兼容性白皮书

但真正答案在：

ZX-880产品规格表第3.2节

这类精确型号、合同号、制度编号和缩写，是Sparse或关键词检索的优势。

因此，企业RAG通常需要：

权限过滤 → Dense召回 ＋ Sparse召回 → 融合 → 重排 → 去重和多样性控制 → 上下文构建

二、先明确检索流水线的每一层

完整架构：

用户问题 → 身份与权限解析 → 查询标准化 → 查询分类 → Metadata过滤 ├─ Dense Retrieval ├─ Sparse Retrieval ├─ 结构化检索 └─ 业务规则候选 → Fusion → Reranking → Version Selection → Deduplication → Diversity Control → Context Budget → LLM生成

每一层解决不同问题。

权限解析

决定用户能看什么。

查询标准化

处理：

• 拼写；
• 大小写；
• 全半角；
• 型号格式；
• 日期；
• 术语别名。

查询分类

判断是：

精确查询 语义查询 复杂组合查询

Metadata过滤

限制租户、部门、状态、版本和有效期。

多路召回

提高候选覆盖率。

融合与重排

把候选变成真正适合回答问题的证据。

三、Dense召回负责什么

Dense向量适合：

• 同义表达；
• 自然语言问题；
• 概念关系；
• 跨语言语义；
• 模糊描述；
• 用户不知道标准术语的情况。

例如：

如何防止经销商跨区域销售？

知识库可能使用术语：

防窜货 渠道流向控制 跨区预警

Dense检索能够理解语义联系。

但Dense的局限包括：

• 型号数字区分弱；
• 专有名词容易近似；
• 否定条件处理不稳定；
• 相似主题文档容易互相干扰；
• 同一产品不同版本难以区分。

因此，Dense是基础，但不是全部。

四、Sparse召回负责什么

Sparse检索可以是：

• BM25；
• 全文索引；
• SPLADE；
• 稀疏Embedding；
• 数据库文本索引。

它擅长：

• 产品型号；
• 合同编号；
• 人名；
• API字段；
• 错误码；
• 专业缩写；
• 精确短语。

例如：

E10042错误怎么处理？

Sparse可以直接命中错误码。

缺点：

• 同义词能力弱；
• 用户表达与文档词汇不同会漏召；
• 中文分词质量影响较大；
• 长问题中关键词权重可能失衡。

Dense与Sparse的组合可以互补。

五、结构化检索不能被向量搜索取代

部分问题本质上是数据库查询：

订单A1001当前状态是什么？

不应该在文档向量库中搜索订单