模式矩阵 /模式白皮书/M2

M2 · RAG Pipeline · 检索增强生成

它解决什么问题

企业知识库动辄几十万份文档加历史工单，任何 LLM 的 context window 都装不下，但 agent 不能因此回答"我不知道"。它需要在每次提问时，从海量语料里挑出最相关的几份临时塞进 context。这就是 RAG 要解决的事：把 input 之外的事实按需拉进来。

2026 年生产级 RAG 的工程难点已经不是"能不能查到",而是"会不会查"。naive RAG 是一次查询一次返回，而真正能上生产的 RAG 让 agent 主导多步检索——看完第一批结果不满意就改写 query 再查，查到候选答案就主动找反例验证，跨多个语料做交叉对比。

为什么坐标是「记忆 × 路由」

• 纵轴 · 记忆：RAG 是外挂知识库，把 input 之外的事实拉进来，本质是"记下哪些事实、怎么把它调出来"，属于记忆模块里管 declarative knowledge 的部分。
• 横轴 · 路由：不同 query 要路由到不同的 retrieval source——语义查询走 vector，精确关键词走 BM25，结构化关系走 KG 或 SQL。选哪个源、怎么融合多个源的结果，是路由决策。

核心机制

1. 两条 pipeline 在向量库汇合：RAG 不是单一步骤。离线侧把文档 chunk、embed、建索引；在线侧把 query embed、召回 top-K、重排、注入生成。两条独立 pipeline 共享同一个向量库。
2. 混合检索：embedding 擅长语义（"ACME 财报"约等于"ACME 业绩"），但精确关键词（产品名、错误码、特定 ID）经常 miss。把语义检索和 BM25 关键词检索结合，再用 RRF（Reciprocal Rank Fusion）融合，是经典的"语义加关键词"姿态。
3. 上下文增强 chunking：chunk 一旦切开，原文上下文锚点就丢了。在每个 chunk 前 prepend 一段上下文摘要（用便宜模型生成）再 embed，能显著降低检索失败率。这是性价比最高的工程精雕，预处理一次终身受用。
4. agent 主导的多步检索：把 RAG 从一次性流水线升级为 agent 主导流程——拆子 query、迭代改写、找反例、跨语料三角验证、按证据强度加权合成。这五步合起来是人类研究员方法论的工程化版本。
5. 迭代硬上限：多步检索必须设硬上限，否则 agent 会一直觉得"还不够"连续检索把账单烧爆。

适合的生产场景

• 大规模自然语言知识库：学术文献综述、法律案例库、客服 FAQ。数据量大、含同义词和隐含关系、相对稳定、公开或半公开，是 RAG 的最佳场景。
• 跨多文档的复杂查询：需要从多个来源综合答案、需要可追溯引用的场景。
• 企业 know-how 组织：把散落在 wiki、Confluence、Slack、邮件、工单里的知识，组织成 agent 能五分钟取出来的形态。这是 RAG 在企业落地的真正命题。

容易出错的地方

• 知识源没治理就上 RAG：90% 企业 RAG 翻车的根因不是技术，是知识本身没整理过——wiki 里大量文档互相矛盾、关键决策不在文档里、版本全是过期的、同一概念有多个名字。把垃圾 embed 成 vector，检索回来还是垃圾，比不做 RAG 更糟。做 enterprise RAG 之前先做 ontology 和知识治理。
• 该走 Agentic Search 却硬上 RAG：dev workflow、代码搜索、内部敏感数据这三类场景多数不该上 RAG。代码每分钟在变，刚写的函数还没建索引就找不到（数据延迟）；索引本身是 attack surface，内部恶意人员可能越权偷看（安全隐患）。这类场景应该走 grep 加 glob 的 Agentic Search。
• 停留在一查一答：第一次没查到关键信息时，naive RAG 要么直接说不知道，要么 silently 编造。生产级 RAG 必须能改写 query 再查。
• 盲目追求召回精度：embedding 模型选型差几个点是边际优化，agent 多步检索像不像一个真会查的人才是质变。chunk 召回率上 80% 不一定有用，最终综合质量像 senior 研究员才是真价值。
• 引用不可追溯：学术、法律、医疗场景里，每个结论都要能追到原始 chunk 加页码，这是合规底线，不可省。

关键指标

• 检索失败率（健康区越低越好）：top-K 里没有相关 chunk 的比例。上下文增强加混合检索加重排三件套叠加，工业数据显示可把失败率降低约三分之二。
• 检索命中率 / 引用率（健康区 ≥ 70%）：召回的 chunk 里实际被 agent 引用的比例。过低说明召回噪声大或 query 写得太宽。
• 多步检索轮数（健康区 3-5 轮且有硬上限）：迭代检索的实际轮数。持续顶到上限说明任务确实难或单次召回太差。
• 最终综合质量（业务判定）：agent 输出像不像一个 senior 从业者的产出。这是 RAG 系统真正的判断标准，上 70% 已能改变团队工作方式。

最小骨架

离线索引侧：
    doc → chunk → 前置上下文摘要(便宜模型) → embed → 向量库 + BM25 索引

在线检索侧（agent 主导多步）：
    拆子 query
    每个子 query 迭代检索：
        语义 top-150 + BM25 top-150 → RRF 融合 → reranker 重排 top-20
        agent 评估是否够 → 不够则改写 query 再查（最多 N 轮）
    形成假设 → 取反作为新 query 找反例
    跨多语料三角验证（多组都出现的 chunk 加权）
    按证据强度加权合成
返回 answer + evidence + counter_evidence + 完整 trace（含 citation 可追溯）

工程落地四个要点：retriever 层做上下文增强加混合检索加重排；max_iterations 设硬上限加 token 预算硬上限；trace 完整记录每次检索；引用必须可追溯到原始文档加页码。

企业落地一例

某科研机构的学术文献综述 agent，要在百万级论文库里帮研究员回答任意问题。第一版用关键词检索返回五千篇已读过的，换 embedding 又只返回 2018-2020 的"经典"，研究员要的"过去三年进展"反而沉底。重写后五个 canonical 模式全上：拆子 query、迭代精化、假设取反找反例、跨 arXiv 加 bioRxiv 加 PubMed 三角验证、按证据强度加权合成。配套六个业务决策——多语料分库不分表（peer-reviewed 权重 1.5、预印本 1.0、未发表 0.5）、时间衰减权重（半衰期 18 个月让新论文自然浮上来）、强制开启反例检索、引用做到 chunk 级、跨语料作者关系图。落地后 agent 返回精准二十篇加五篇反例加三篇隐含相关，每篇都有 citation 可追，研究员一份综述从六小时压到一个半小时，质量还更高。

与其他模式的关系

• 分层保留（M1）：M1 解决"长期已知的记忆怎么按作用域加载",RAG 解决"作用域装不下的海量知识怎么现查现用"。分层管已知，RAG 管外挂。
• 程序性记忆（M5）：RAG 管 declarative memory（事实知识的检索），M5 管 procedural memory（会做活儿的复用）。RAG 检索"知道什么",M5 检索"过去做过的任务怎么做"。两者在企业 agent 落地里是合奏。
• 上下文分诊（感知模块）：RAG 把候选信息拉进来，分诊决定这些候选谁先入场。RAG 是召回，分诊是入场排序。
• 渐进发现（感知模块）：两者结构相似但目标不同。渐进发现是 agent 在陌生空间探索结构，RAG 是在已知大库里取相关片段。一个偏认知，一个偏检索。

一句话记住它

RAG 不是越精准越好，是越会查越好——它的工程天花板不在模型、embedding 或向量库，而在知识源本身的整理质量。

本页属于 ADPS 33 模式白皮书。返回 模式矩阵与白皮书目录， 或查看配套 可运行代码目录。