第20章 RAG 工程与高级检索¶
RAG 很容易做出“能回答”的演示，却很难做到企业要求的“答案有据、引用可查、错了能定位”。一次制度问答漏掉金额阈值，根因可能不在生成模型，而在解析、chunk、召回、排序、上下文组装或引用校验。
生产 RAG 应被视为一条证据工程链路，而不是“向量库 + Prompt”。 它的目标不是尽可能多地找材料，而是把足以支持结论、符合权限和版本要求的证据稳定送到模型，并在证据不足时知道如何停下来。
20.1 RAG 的完整链路：每一层都要可诊断¶
企业 RAG 至少包括文档解析、索引、查询理解、候选召回、排序过滤、上下文组装、生成和引用校验。
图20-1：企业 RAG 工程体系。来源：本书自绘。Alt text：分层图含离线侧（解析、分块、嵌入、入库）与在线侧（查询改写、混合检索、重排、引用校验、生成），两侧通过向量库衔接，展示 RAG 的完整工程组成。
表20-1：RAG 链路职责分解。来源：本书整理。
| 环节 | 输入 | 输出 | 质量风险 |
|---|---|---|---|
| 文档解析 | PDF、网页、PPT、图片 | chunk、表格、citation span | 文本顺序错、表格丢失 |
| 索引构建 | chunk、metadata、embedding | 向量/关键词索引 | 权限缺失、版本混用 |
| 查询理解 | 用户问题、会话上下文 | rewrite、filter、子问题 | 改写过度、权限条件丢失 |
| 候选召回 | query、filter、top-k | 文档/字段候选 | 召回漏、相似但不可答 |
| 排序融合 | 多路候选 | reranked evidence | 正确证据排序靠后 |
| 生成与引用 | evidence、prompt、policy | 答案、引用、拒答 | 幻觉、引用不支持答案 |
图20-2：企业 RAG 证据生产线。来源：本书自绘。Alt text：横向流水线从用户问题出发，经检索得到候选片段、重排筛选、附带来源标注，最终生成带引用的答案，箭头强调每个结论都挂上可追溯的证据片段。
平台化的触发条件是多个业务都需要解析、检索、重排、权限和引用校验，而不是“大家都用了向量库”。高风险 RAG 的最小门槛应先放在权限过滤、引用覆盖、拒答和失败回放上，再考虑复杂多跳和 GraphRAG。
RAG 的排障顺序应该沿链路向前追，而不是默认在最后一层改 Prompt。
20.2 Chunk 与上下文组装：召回单元小，证据上下文要完整¶
固定 500 字切分只是 baseline。制度、合同、FAQ、表格、代码和字段说明需要不同 chunk 策略。
表20-2：chunk 策略取舍表。来源：本书整理。
| 方案 | 优势 | 代价 | 适用场景 | mini-platform 选择 |
|---|---|---|---|---|
| 固定长度 | 实现简单 | 易切断语义和表格 | 纯文本 baseline | 仅作 baseline |
| 结构化 chunk | 保留标题、段落、表格和页码 | 依赖解析质量 | 制度、合同、手册 | 默认策略 |
| Parent-child | 小 chunk 召回，大 parent 补上下文 | 索引/组装更复杂 | 长文档、章节层级清晰 | 高价值知识库 |
| Small-to-big | 先精确召回，再扩邻近上下文 | 依赖 source span/邻接 | 精确引用 + 完整上下文 | 高级策略 |
图20-3：chunk 与上下文组装示意。来源：本书自绘。Alt text：文档被切成带重叠的片段，检索命中的片段连同相邻上下文、标题路径一起组装进 Prompt，示意分块粒度与上下文窗口的关系。
合同付款条件可能需要定义条款 + 附件表格，制度里的“十五个工作日”必须带标题路径，runbook 的命令不能和前置条件、回滚步骤拆开。
上下文组装应区分：直接支持答案的证据、背景材料、冲突材料和不可用材料。上下文越长不等于越可信；无关但相似的材料越多，模型越容易把噪声组织成确定结论。
20.3 混合检索与重排：精确词和语义表达需要互补¶
企业问题常同时包含自然语言、字段名、条款号、错误码和业务别名，纯向量或纯关键词都不够稳定。
表20-3：检索路线对比。来源：本书整理。
| 路线 | 优势 | 风险 |
|---|---|---|
| 纯向量 | 语义召回强、适合口语 | 专有名词、编号、字段名可能漏 |
| 纯关键词 | 精确词、编号、错误码强 | 同义表达和口语召回弱 |
| 混合 + RRF | 兼顾语义和精确匹配，易解释 | 去重和融合需评测 |
| 混合 + reranker | 前排证据质量更好 | 增加延迟和成本 |
RRF 用排名而不是不可比的原始分数融合 BM25 与向量结果，通常是稳定起点；再用 reranker 提升前排证据质量。
但混合检索还要处理 source diversity、权限、时间和业务 intent。例如 DataAgent 字段检索应该偏向 schema、指标和历史 SQL；合同问答则优先当前有效制度和条款。
RAG 不应只在最终回答前补资料。对于 DataAgent，证据应该更早进入指标识别、字段选择、SQL 生成和工具决策。
20.4 Query understanding 与多跳：复杂度必须有停止条件¶
用户问题可能同时携带时间、地区、实体、权限、比较和隐含指标。Query understanding 的职责是把问题转成检索计划，而不是简单“改写得更正式”。
表20-4：查询理解能力。来源：本书整理。
| 能力 | 示例 | 输出 |
|---|---|---|
| Query rewrite | “报销多久到账”→“费用报销付款周期” | 改写 query |
| Metadata filter | “华东区今年” | region=华东、year=2026 |
| HyDE | 生成假想文档后检索 | synthetic query |
| 多跳拆解 | “续约和付款风险一起看” | 子问题 + 合并策略 |
| Schema linking | “高客单门店” | 指标、维度、字段候选 |
多跳不应默认打开。简单 FAQ 只需 rewrite，DataAgent 更需要 schema linking，跨合同/客户/风险的问题才适合拆解多跳。
图20-4：多跳检索状态机。来源：本书自绘。Alt text：状态机含"提出子问题、检索、判断是否够答、继续追问或收敛生成"等节点，循环边表示在证据不足时多轮检索，直到满足回答条件。
每一跳都要检查证据是否足够；缺实体、时间或口径时先澄清，存在冲突时展示冲突，而不是不断扩展检索。
过度 query rewrite 和无限多跳都会悄悄改变用户原问题。原始问题、改写、filter 和子问题都必须进入 Trace。
20.5 可信回答：引用存在不等于引用支持结论¶
表20-5：可信回答门禁。来源：本书整理。
| 门禁 | 检查方式 | 失败处理 |
|---|---|---|
| 引用覆盖 | 关键结论是否有 citation | 缺引用则拒答/降级 |
| 引用一致 | 答案是否被引用文本支持 | 标记 hallucination risk |
| 权限有效 | source 是否对用户可见 | 移除并重新生成 |
| 时间有效 | 制度、合同、价格是否仍生效 | 提示版本或人工确认 |
| 冲突证据 | 是否存在矛盾材料 | 展示冲突，避免单边结论 |
RAG 评估要区分 context recall/precision 与 faithfulness，因为“找到了正确材料”和“模型忠实使用材料”不是一件事。
{
"answer": "出差返回后应在十五个工作日内提交报销申请。",
"citations": [
{
"chunk_id": "travel-policy#p12#c03",
"page": 12,
"span": "返回后十五个工作日内提交申请",
"source_version": "v3"
}
],
"confidence": "high",
"fallback": null
}
图20-5：可信回答引用校验界面。来源：产品界面截图。Alt text：界面中每条结论旁标注来源片段链接，鼠标悬停可高亮原文出处，未找到支撑的句子被标红提示，体现答案逐句可校验。
可信回答最好把答案拆成 claim，再逐条验证引用是否支持、是否当前有效。“有链接”不是证据链，只有“结论—证据—来源版本”能互相对应，引用才真正成立。
20.6 弱证据是正常状态：设计拒答、澄清与补证¶
企业 RAG 必须正式建模弱证据，而不是把它们都当异常日志。常见状态包括：
insufficient_evidence：关键材料缺失；conflicting_evidence：多个来源冲突；stale_evidence：证据过期；permission_blocked：当前角色看不到必要材料；partial_coverage：只能回答一部分。
不同状态对应不同动作：请求上传材料、扩大检索范围、展示冲突、申请权限、转人工或只回答已被支持的部分。
新补充的材料也不能自动成为全局知识。它应先记录来源、权限、有效期和 Owner，决定是仅当前会话使用，还是经过解析/治理后进入知识库。
“证据不足”是生产 RAG 的正常输出。能安全停下来，比强行生成一个完整答案更重要。
20.7 RAG 与工具调用：规则证据和实时事实要分开¶
RAG 适合稳定文档知识；实时状态和外部动作应调用业务工具。
- “政策如何解释”→ RAG；
- “我的订单当前到哪一步”→ 业务系统工具；
- “把合同发给客户”→ Tool + 审批；
- “先解释政策，再判断我的订单是否满足条件”→ RAG + Tool 组合。
最终回答中，文档证据说明规则，工具结果说明当前事实，两者不能混成一种 citation。这样报告和 Trace 才能解释结论究竟来自知识还是实时系统。
20.8 发布与运营：失败样本应指向具体责任层¶
上线前至少要经过离线评测、shadow traffic、高风险人工复核和小流量灰度。样本集应按失败阶段分类：解析、召回、重排、权限、生成、引用。
Shadow 评测不能只比较最终答案，要比较候选、filter、rerank、上下文和 citation。新链路回答更流畅但证据更弱，不应被视为升级。
线上持续观察的指标包括：证据覆盖率、无答案率、知识更新延迟、引用错误、用户追问、人工纠正和权限拦截。每个指标都要能触发动作，而不是只用于看板。
争议反馈应绑定完整 Trace，分成：证据缺失、口径冲突、排序问题、权限问题和表达问题，再交给不同 Owner。不要把所有用户投诉都沉淀成“再调一版 Prompt”。
高风险知识库在制度大更新、权限模型变化、parser/索引重建时可以进入“冻结窗口”：允许原文检索和人工复核，但暂时限制自动确定性回答，直到关键样本重新通过。
RAG 的运营对象不是“答案”，而是整条证据链及其版本。
本章小结¶
RAG 应按证据工程建设：解析、索引、query understanding、混合检索、reranker、上下文组装、生成和引用校验缺一不可。
Chunk 要从文档结构与引用需求出发；混合检索兼顾语义和精确实体；多跳要有停止条件；可信回答必须逐项验证引用、权限、时间和冲突；弱证据要能触发拒答、澄清和补证。
企业 RAG 的成熟度不看“多少问题能回答”，而看每个重要结论是否能证明自己为什么可以回答，以及证据不够时能否正确停止。
参考文献¶
- Azure AI Search Hybrid Search: https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview
- Azure AI Search Reciprocal Rank Fusion: https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking
- LangChain Parent Document Retriever: https://python.langchain.com/docs/how_to/parent_document_retriever/
- LlamaIndex Query Transformations: https://docs.llamaindex.ai/
- Ragas Metrics: https://docs.ragas.io/