企业级RAG性能优化与质量治理（3）：混合检索、重排与权限过滤的生产级设计

文章摘要

前两篇分别讨论了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当前状态是什么？

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

正确架构：

问题分类
├─ 知识问题 → RAG检索
├─ 实时业务数据 → API/SQL工具
└─ 混合问题 → 业务数据＋RAG

例如：

A1001为什么还未发货？

需要：

订单API查询当前状态
＋物流制度知识库解释规则

不要把所有问题都塞进向量数据库。

六、Metadata过滤是检索的硬边界

Metadata不仅用于提高相关性，还承担：

  • 租户隔离；
  • 权限控制；
  • 当前版本；
  • 文档状态；
  • 有效日期；
  • 产品线；
  • 地区；
  • 语言。

建议Chunk Metadata：

{
  "tenant_id": "T001",
  "document_id": "DOC-1001",
  "chunk_id": "DOC-1001-C05",
  "document_version": "V3.2",
  "status": "EFFECTIVE",
  "effective_at": 1782864000000,
  "expired_at": null,
  "department_ids": ["D01", "D02"],
  "security_level": 2,
  "source_type": "PRODUCT_MANUAL",
  "authority_score": 0.9
}

过滤应在召回前执行。

七、查询分类与动态检索路由

定义：

public enum QueryType {
    EXACT,
    SEMANTIC,
    COMPLEX,
    STRUCTURED
}

EXACT

特征：

  • 型号；
  • 编号；
  • 错误码；
  • 精确术语。

策略：

Sparse优先
Dense补充

SEMANTIC

特征：

  • 原因；
  • 方法；
  • 概念解释；
  • 用户表达模糊。

策略：

Dense优先
Sparse补充

COMPLEX

特征：

  • 多条件；
  • 多文档综合；
  • 比较与分析。

策略：

混合召回
＋更强重排
＋可选查询分解

STRUCTURED

特征：

  • 实时状态；
  • 数值；
  • 交易记录。

策略：

工具或数据库查询

八、查询改写不是越多越好

查询改写可以：

  • 补充同义词；
  • 展开缩写；
  • 提取实体；
  • 转换为检索式；
  • 拆解复杂问题。

例如：

用户：渠道费用为什么花了却没效果？

改写：

渠道费用核销
动销数据
费用投入产出
虚假核销

风险是模型改写可能改变原意。

因此要保存：

original_query
rewritten_query
rewrite_reason

精确编号查询通常不应该被自由改写。

九、多路召回的候选数量

示例：

Dense Top50
Sparse Top50
结构化候选Top20

不要直接把三路全部传给模型。

融合后：

Top30

重排后：

Top10

最终上下文：

Top3到Top8

候选数量需要通过评测决定。

关键指标：

Candidate Recall@50
Reranked Recall@10
Context Recall@5

十、融合方法选择

RRF

适合作为默认基线。

优势：

  • 不要求分数同量纲；
  • 稳定；
  • 参数少。

DBSF

适合原始分数分布可信、但缺少标注集。

加权融合

适合有评测集，可调：

Dense权重
Sparse权重
标题权重
权威来源权重

业务Formula

适合增加：

  • 新鲜度；
  • 权威度；
  • 地域；
  • 产品匹配；
  • 用户偏好。

权限不能通过加权实现。

十一、为什么需要Reranker

初级检索器追求：

快速找出可能相关的候选

Reranker追求：

判断候选是否真正回答问题

例如问题：

五码中哪个码用于消费者查询？

候选：

A：五码整体架构介绍
B：消费者查询码的字段定义
C：经销商物流码规则

Dense可能认为A最相关，因为语义覆盖全面；Reranker更可能把B放在第一位。

十二、Cross-Encoder重排设计

输入：

query
＋candidate chunk

输出：

relevance_score

生产建议：

候选Top20
→ 批量重排
→ Top5

需要限制：

  • 每个Chunk最大长度；
  • 候选数量；
  • 超时；
  • 批处理大小；
  • 降级策略。

重排器不可用时可以降级到融合排序，但要记录：

rerank_status = DEGRADED

十三、重排后的版本治理

即使相关性高，旧版本文档也不能优先。

版本规则：

同一document_id
→ 只保留当前有效版本

如果用户明确问历史版本：

2025年的报销标准是什么？

才允许检索历史有效区间。

建议：

默认查询当前时间
历史查询解析目标日期
按有效期过滤

不要把版本判断完全交给重排器。

十四、去重与多样性控制

检索结果可能来自：

  • 同一文档相邻Chunk；
  • 同一内容不同格式；
  • 新旧版本；
  • 重复上传；
  • 引用文档与原文。

如果Top5全部来自同一小节，模型会缺少其他必要证据。

去重策略：

chunk_id去重
content_hash去重
document_id限额
相邻Chunk合并

多样性策略：

每个文档最多N条
MMR
不同来源覆盖
不同章节覆盖

但多样性不能强行降低关键证据排名。

十五、上下文预算

最终上下文不是结果越多越好。

需要控制：

最大Token
最大Chunk数
单文档最大占比
表格完整性
证据顺序

建议优先顺序：

最直接答案证据
→ 必要条件
→ 补充说明
→ 例外规则

上下文模板：

[E1]
来源：产品手册V3.2
章节：五码身份
内容：……

[E2]
来源：消费者查询流程
章节：扫码入口
内容：……

十六、线上召回治理需要哪些指标

离线指标

Recall@K
MRR
nDCG
Hit Rate
Answer-Bearing Recall

在线指标

零结果率
平均候选数
权限过滤后候选数
Dense/Sparse重叠率
重排变化率
Top1稳定性
检索P95
重排P95
单次成本

业务指标

用户追问率
人工转接率
答案采纳率
引用点击率
纠错率

十七、建立检索Trace

每次请求保存：

request_id
original_query
rewritten_query
query_type
permission_version
filter_expression_hash
dense_candidates
sparse_candidates
fusion_scores
rerank_scores
final_context
retrieval_version

这样才能回答：

为什么这次把文档A排在文档B前面？

十八、检索版本化

检索系统也应有版本：

retrieval-v1：Dense only
retrieval-v2：Dense＋BM25＋RRF
retrieval-v3：混合＋Cross-Encoder

每次上线记录：

  • Embedding模型；
  • Sparse模型；
  • Top K；
  • Fusion算法；
  • 权重；
  • Reranker；
  • 过滤规则；
  • Chunk版本。

否则线上效果变化后无法复现。

十九、灰度发布

新检索策略不能直接全量上线。

影子评测

生产请求
→ 旧检索正常返回
→ 新检索并行执行但不影响用户
→ 对比候选与指标

小流量灰度

1%
→ 5%
→ 20%
→ 50%
→ 100%

回滚条件

例如：

P95增加超过30%
零结果率上升
权限异常
MRR下降
用户追问率上升

二十、降级设计

Sparse服务不可用

Dense only

Dense Embedding不可用

Sparse only

Reranker超时

使用Fusion结果

权限服务不可用

拒绝检索

权限不能降级为全库检索。

二十一、常见错误架构

1. 只使用Dense

型号和编号查询效果差。

2. 全库召回后再过滤权限

存在泄露风险和候选不足。

3. Top K不断增大

噪声和Token成本上升。

4. 重排所有候选

延迟和费用不可控。

5. 权重靠经验固定

缺少评测，容易对某类查询过拟合。

6. 不保留Trace

线上错误无法复盘。

7. 新旧文档同时召回

答案出现版本冲突。

二十二、推荐的生产默认方案

认证与权限上下文
→ 查询分类
→ Metadata硬过滤
→ Dense Top50
＋ Sparse Top50
→ RRF Top30
→ Cross-Encoder Top10
→ 版本与去重
→ 多样性控制
→ Top5上下文
→ 生成与忠实度检查

对于低延迟场景：

RRF直接Top5

对于高价值复杂任务：

增加查询分解
＋更强Reranker
＋多轮证据检查

二十三、实施顺序

阶段一：建立基线

Dense only
＋黄金测试集

阶段二：加入Sparse与RRF

验证精确术语和编号查询。

阶段三：加入权限与版本自动化测试

把安全边界固定下来。

阶段四：加入Reranker

只针对Top候选精排。

阶段五：上线Trace和持续评测

建立检索版本治理。

总结

企业级RAG的检索质量不是由某一个Embedding模型决定，而是由完整链路共同决定：

查询理解
＋权限过滤
＋Dense召回
＋Sparse召回
＋融合
＋重排
＋版本治理
＋去重
＋上下文预算

最稳妥的生产策略不是一次堆满所有高级技术，而是先建立评测基线，再逐步增加混合检索和重排，每次变更都可观测、可灰度、可回滚。

下一篇将继续讨论：

企业级RAG性能优化与质量治理（4）：多租户权限、版本管理与增量更新。

延伸阅读

如果你正在关注企业级 AI 应用、RAG、Agent、MCP 与大模型工程化落地，欢迎访问 智元界：

https://www.zyentor.com/

智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。