RAG 工程与检索系统设计

第1章为什么 RAG 是 AI 应用的第二大脑

作者杨艺韬 · 11,455 字 · 发布于 2026-04-24 · 更新于 2026-08-18

"A language model knows patterns. A retrieval system knows where the evidence lives."

本章要点

大模型的参数记忆不适合承载快速变化、强权限、强溯源的业务知识
RAG 的核心价值是把"生成"和"证据"分离，让 AI 应用拥有外部知识系统
生产级 RAG 不是单次向量相似度搜索，而是一条离线索引、在线检索、上下文打包、答案验证、反馈评估的流水线
RAG 的主要失败模式可以归纳为四类：找不到、找错、塞不下、答不准
RAG 与微调不是替代关系：微调改变模型行为，RAG 注入可更新知识

1.1 模型已经很强，为什么还要 RAG

先看一个真实业务场景。

你在公司内部做了一个 AI 助手，希望它回答员工的问题：

"海外员工申请 MacBook Pro 的审批流程是什么？如果预算超过 2 万人民币，需要谁额外批准？"

这个问题看起来简单，实际牵涉四类知识：

资产采购制度：哪些岗位可以申请什么设备。
海外实体政策：不同国家的采购主体和财务审批链。
预算阈值：金额超过某个线后是否需要 VP 或财务负责人审批。
当前时间：制度是否已经在本季度更新。

通用大模型可能知道"公司采购通常需要经理审批"，但它不可能天然知道你公司 2026 年 4 月 1 日刚更新的海外采购制度。即便你把这些制度贴进 prompt，它也只能回答这一次；下一次用户问另一个政策，你又要重新找资料、重新拼上下文。

这就是参数记忆的边界。

大模型的知识主要以参数形式存储。训练完成后，参数里的知识很难快速更新；即便通过微调更新，也很难保证只改变某条制度而不影响其他能力。更关键的是，参数记忆没有天然的来源标注。模型说"超过 2 万需要财务总监审批"，你很难知道这句话来自哪份制度、哪一页、哪一版。

RAG 的出发点不是"模型不够聪明"，而是"模型不应该把所有知识都背在参数里"。

一个生产 AI 应用需要两类能力：

能力	大模型擅长	RAG 系统擅长
语言理解	理解问题、改写查询、综合证据	提供候选证据
推理组织	归纳、解释、生成自然语言	保留来源与结构
知识更新	依赖训练或微调	文档更新后重建或增量索引
权限控制	不天然理解企业 ACL	在检索前后做过滤
可追溯性	参数无法直接溯源	chunk、文档、版本、链接可记录
成本控制	长上下文昂贵	只取相关证据进入上下文

RAG 的核心价值，是把"模型会说话"和"系统知道证据在哪里"连接起来。

1.2 RAG 不是把文档塞进 prompt

很多人第一次实现 RAG，会写出这样的流程：

graph LR
    A[文档] --> B[切块]
    B --> C[Embedding]
    C --> D[向量数据库]
    U[用户问题] --> E[Embedding]
    E --> F[top-k 相似度搜索]
    D --> F
    F --> G[拼 Prompt]
    G --> H[LLM 回答]

这张图没有错，但它只描述了 RAG 的最小形态。最小形态能做 demo，却解释不了生产问题。

比如，用户问：

"我们现在的退款 SLA 是多久？"

向量检索返回了 5 个 chunk：

2024 年客服手册：普通退款 7 个工作日。
2025 年支付团队 FAQ：银行卡退款 3 到 10 个工作日。
2026 年最新服务协议：普通退款 5 个工作日。
一封历史公告：春节期间退款可能延迟。
一个产品 PRD：退款状态页显示预计时间。

如果系统只是按相似度拼 prompt，大模型很可能把这些材料混在一起，生成一句看似合理但不可执行的答案："通常为 5 到 10 个工作日，节假日可能延迟。" 这句话不一定错，却不能满足业务问题。用户要的是"现在的 SLA"，系统应该优先使用最新正式协议，并指出特殊支付渠道另有规则。

这时需要的不是更大的 top-k，而是更完整的 RAG 工程：

flowchart TD
    A[用户问题] --> B[意图识别与查询改写]
    B --> C[权限与租户上下文]
    C --> D[多路召回]
    D --> E[元数据过滤]
    E --> F[重排序]
    F --> G[证据聚合]
    G --> H[上下文打包]
    H --> I[答案生成]
    I --> J[引用校验]
    J --> K[反馈与评估]
    D1[向量召回] --> D
    D2[BM25 召回] --> D
    D3[结构化过滤] --> D

这里的每个节点都承担一个明确职责：

查询改写：把"现在的退款 SLA"改写成更适合检索的表达，如"最新服务协议退款 SLA 普通退款工作日"。
权限上下文：确认用户所在地区、租户、部门，避免召回无权查看的材料。
多路召回：向量召回负责语义相近，BM25 负责精确词命中，结构化过滤负责时间和文档类型。
重排序：让最新、正式、覆盖问题条件的证据排在前面。
证据聚合：把同一文档相邻 chunk 合并，避免上下文碎片化。
上下文打包：在 token 预算内保留最关键证据和来源。
引用校验：确保答案里的关键结论能对应到证据。
反馈评估：记录这次回答是否解决问题，后续用于调优。

所以，RAG 不是"检索 + 生成"两个动作，而是一个围绕证据流动设计的系统。

1.3 参数记忆、上下文记忆与外部记忆

要理解 RAG 的位置，需要区分三种记忆。

第一种是 参数记忆。模型在训练中吸收的知识都压缩在权重里。它的优点是调用时不需要额外检索，回答速度快，语言组织自然；缺点是更新困难、来源不可见、权限不可控。

第二种是 上下文记忆。你在当前对话里提供的消息、工具结果、文件片段，都在上下文窗口里。它的优点是立即生效，可以覆盖参数记忆；缺点是窗口有限，成本随长度上升，对话结束后通常不会自动沉淀。

第三种是 外部记忆。文档库、数据库、代码仓库、工单系统、向量索引、知识图谱都属于这一类。它的优点是可更新、可授权、可追溯；缺点是需要检索系统把相关材料找出来，并压缩成模型能消费的上下文。

RAG 连接的是外部记忆和上下文记忆：

graph TD
    A[参数记忆<br/>模型权重] --> D[生成答案]
    B[上下文记忆<br/>当前会话] --> D
    C[外部记忆<br/>文档/数据库/代码/图谱] --> R[RAG 检索]
    R --> B
    D --> O[用户答案]
    style A fill:#fef3c7,stroke:#f59e0b
    style B fill:#dbeafe,stroke:#3b82f6
    style C fill:#dcfce7,stroke:#22c55e
    style R fill:#f3e8ff,stroke:#8b5cf6

这个划分能解释很多架构决策。

如果某类知识稳定、通用、无权限边界，比如"HTTP 状态码 404 表示资源不存在"，让模型依赖参数记忆就够了。如果某类知识只在当前任务中有效，比如用户刚上传的一段日志，可以直接放进上下文。如果某类知识变化快、规模大、需要授权、需要引用，比如企业制度、项目文档、客户资料、代码仓库，就应该进入外部记忆，通过 RAG 注入。

《Harness Engineering》第 11 章讨论短期记忆时，重点是如何管理上下文窗口；本专栏第 18 章会把这个问题向外扩展：哪些会话信息应该被沉淀为长期记忆，沉淀后如何被检索，检索出来后又如何避免污染当前上下文。

1.4 RAG 解决的不是"知识不足"，而是"知识治理"

很多团队把 RAG 当作给模型补知识的办法。这个理解只说对了一半。

RAG 更深层的价值是知识治理。它让 AI 应用中的知识具备五个工程属性。

第一，可更新。 政策改了、代码合并了、合同模板替换了，系统可以通过增量索引更新外部知识，而不是等待下一次模型训练。更新不是简单追加：旧版本是否删除、是否保留历史、哪些索引需要重建、缓存如何失效，都是第 8 章要处理的问题。

第二，可授权。 企业知识不是所有人都能看。RAG 必须把 ACL、租户、部门、角色、文档密级带进检索链路。权限过滤不能只在最终答案阶段做，因为模型一旦看到了无权证据，就可能泄露。第 7 章会专门讨论检索前过滤、检索后过滤和索引分区的取舍。

第三，可追溯。 一个答案如果影响业务决策，就必须能回答"依据是什么"。RAG 系统要保存文档 ID、chunk ID、版本、页码、标题层级、URL、检索分数、rerank 分数和最终使用状态。没有这些字段，引用只是装饰。

第四，可评估。 大模型答案的好坏很难直接测，但 RAG 可以拆开测：有没有召回 gold document、相关证据排在第几名、最终上下文是否包含关键段落、答案是否被证据支持。第 20 章会把这些指标拆成独立层级。

第五，可运营。 知识库不是一次性资产。哪些文档长期被召回但用户反馈差？哪些问题经常找不到答案？哪些 chunk 被频繁使用但来源已经过期？这些信号应该反向推动文档治理，而不是只调 prompt。

这五个属性加起来，RAG 就不再是一个模型调用技巧，而是 AI 应用的数据基础设施。

1.5 RAG 的四类失败模式

生产中遇到"RAG 答得不好"，不要先改 prompt。先判断它属于哪一类失败。

1.5.1 找不到：召回失败

用户问的问题明明在知识库里有答案，但系统没有把相关 chunk 找出来。

常见原因包括：

chunk 切得太碎，关键实体和结论被拆开。
chunk 切得太大，embedding 被多个主题稀释。
用户问题和文档措辞不同，向量模型无法对齐领域术语。
只用向量检索，错过了 SKU、错误码、函数名这类精确匹配。
top-k 太小，相关证据排在第 15 名却只取前 5。
metadata 过滤条件过严，把正确文档过滤掉。

找不到的问题，要从文档解析、chunking、embedding、召回策略查起。直接换大模型通常无效，因为模型根本没看到证据。

1.5.2 找错：排序失败

系统召回了相关材料，但更关键的证据没有排到前面，或者被噪声挤掉。

比如用户问"新版 SDK 初始化参数"，召回结果里既有新版文档，也有旧版迁移指南，还有 GitHub issue 里的历史讨论。向量相似度可能认为这些都相关，但业务上最新正式文档应该优先。

找错的问题通常需要 rerank、metadata 加权、文档类型权重、时间衰减和查询意图识别。第一阶段召回追求"别漏"，第二阶段排序追求"别乱"。这也是为什么 RAG 系统通常不能只有一个相似度分数。

1.5.3 塞不下：上下文打包失败

系统找到了正确证据，但上下文窗口有限，最终塞给模型的材料不完整。

这类失败很隐蔽。日志里看起来 top-k 命中了正确文档，但 prompt 里可能只保留了开头几段，关键结论被截断；或者多个 chunk 顺序被打乱，模型看不到因果链；或者引用信息被压缩掉，答案无法溯源。

解决塞不下的问题，要从 context packing 入手：相邻 chunk 合并、按问题维度组织证据、保留标题层级、压缩重复内容、把低价值材料移出主上下文。长上下文模型能缓解这个问题，但不能消灭它。上下文越长，成本、延迟和注意力稀释都越严重。

1.5.4 答不准：生成与验证失败

证据已经进入上下文，模型仍然答错。

原因可能是证据互相冲突，模型没有被要求按版本优先级判断；也可能是 prompt 没有约束"只能依据材料回答"；还可能是模型把证据外的常识混进来，生成了更顺口但不被材料支持的结论。

答不准的问题需要生成约束、引用校验、冲突处理和必要时的二次验证。对于高风险场景，系统应该允许回答"材料不足"，而不是强行生成。

这四类失败模式可以形成一个诊断表：

失败模式	现象	优先检查
找不到	正确文档不在候选集	解析、分块、embedding、召回 top-k
找错	正确文档在候选里但排名低	rerank、metadata、时间和文档类型权重
塞不下	候选正确但 prompt 缺关键证据	上下文打包、合并、压缩、token 预算
答不准	prompt 有证据但答案错误	生成约束、引用校验、冲突处理

这个表是后续章节的总索引。每章都在解决其中一种或几种失败。

1.6 RAG 与微调：不是二选一

讨论 RAG 时，经常有人问：为什么不直接微调模型？

这个问题要拆开看。微调和 RAG 改变的是系统的不同部分。

微调主要改变模型的行为模式。比如让模型学会某种客服语气、某种输出格式、某个垂直领域的表达习惯，或者学会遵循特定工具调用协议。它适合稳定、重复、可以通过样本学习的模式。

RAG 主要改变模型可访问的知识。比如最新政策、客户资料、项目文档、代码仓库、事故记录、会议纪要。它适合变化快、规模大、有权限边界、需要引用的内容。

一个简单判断是：

问题	更适合微调	更适合 RAG
希望模型按固定 JSON schema 输出	是	可辅助
希望模型掌握今天刚发布的制度	否	是
希望模型语气像公司客服	是	否
希望回答附带文档引用	否	是
希望模型学会领域术语表达	是	可辅助
希望不同用户看到不同权限内容	否	是
希望降低某类固定任务的 prompt 长度	是	不一定

很多生产系统最终会同时使用两者：微调让模型更擅长遵循任务格式，RAG 提供实时知识和证据。比如一个法律问答系统可以微调模型学会"先列适用条款、再给结论、最后提示风险"的回答结构，同时用 RAG 检索最新法规和内部案例。

不要用微调解决知识更新，也不要用 RAG 解决模型行为不稳定。边界清楚，系统才容易调。

1.7 RAG 的边界：它不能解决什么

讨论 RAG 的价值容易变成"凡是 AI 应用都该上 RAG"。这是过度承诺。RAG 解决了真实问题、但也有自己的边界——认清这些边界、才不会把 RAG 用在错的地方。

RAG 不解决"模型不会这门领域"

RAG 注入的是外部知识、不是模型的推理能力或领域理解深度。如果模型本身不懂法律术语、RAG 把法条塞给它也读不懂推理出结论；如果模型不擅长数学、RAG 找到公式也算不对题。

常见误区："用 RAG 把医学教材都索引好了、模型就会诊断了"——错。模型需要经过医学数据训练或微调才有领域能力、RAG 只是补充最新信息。知识不等于能力。

RAG 不解决"生成不稳定"

模型本身不可靠（冗长、走题、风格不稳定）不是 RAG 能修的问题。RAG 让证据可控、但不控制生成过程本身。生成的稳定性靠 prompt 工程、微调、结构化输出约束——这些和 RAG 是并列的工程手段。

混用会增加复杂度：先修 generation 稳定性、再加 RAG、再调 retrieval——分层解决。

RAG 不解决"延迟敏感的低价值查询"

RAG 典型延迟 1-2 秒。对"回个客套话"、"翻译一个单词"这类简单查询、RAG 反而拖后腿——模型直接答更快。

判断：如果用户问题不需要外部知识、就让模型直接答。RAG 前加 classifier 判定是否需要检索、能省掉 30-50% 的低价值检索调用。

RAG 不解决"知识质量本身差"

RAG 的上限是源文档的质量上限。如果企业知识库里的文档本来就矛盾、过时、错误——RAG 不会 magically 修复。恰恰相反——RAG 会把烂文档找出来喂给 LLM、然后 LLM 一本正经地复读错误。

GIGO（Garbage In Garbage Out）在 RAG 时代变成 GIRO（Garbage In Rag Out）——RAG 放大了知识库质量的重要性、没减弱它。所以 RAG 项目的前 30% 精力应该在文档治理上（文档 review、过期清理、结构化规范）、而不是优化检索算法。

RAG 不解决"用户期望不合理"

用户期望 RAG 给"完美答案"——但 RAG 只保证"基于检索到的证据的答案"。如果检索不到、RAG 只能说"资料不足"——用户可能仍然不满意。

产品层面要管理期望：

UI 明示 "答案来自企业知识库、未覆盖部分不会回答"
允许用户标记"这不是我想要的"、走兜底（人工、其他系统）
不要营销 "AI 无所不知"——设置合理期望比追求完美覆盖更重要

什么时候 RAG 反而有害

几种场景 RAG 不仅没帮助、还可能伤害系统：

创意生成：写诗、创意广告、发散 brainstorm——RAG 限制在已有素材里、抑制创造力
实时数据 + 低延迟：股价、体育比分——走直接 API 更准更快、RAG 反而过时
完全私密对话：不涉及企业知识的纯闲聊——RAG 只会把无关资料强塞进去
探索性对话：用户自己还不清楚要什么、在和 AI 逐步梳理——过早 RAG 可能把对话带偏

这些场景要么不上 RAG、要么让 RAG 作为可选 tool（Agent 自己决定是否检索）而非默认路径。

边界清楚 → 价值明确

认清边界反而让 RAG 的价值更突出：

flowchart LR
    classDef yes fill:#dfd,stroke:#080
    classDef no fill:#fdd,stroke:#c00
    RAG[RAG]
    RAG --> Y1[企业知识问答]:::yes
    RAG --> Y2[合规 / 可溯源场景]:::yes
    RAG --> Y3[变化快的业务信息]:::yes
    RAG --> Y4[权限敏感的企业检索]:::yes
    RAG -.不适合.-> N1[创意生成]:::no
    RAG -.不适合.-> N2[实时数据流]:::no
    RAG -.不适合.-> N3[纯闲聊]:::no
    RAG -.不适合.-> N4[模型不会的领域]:::no

RAG 是企业 AI 数据基础设施——不是 AI 的万能前缀。在它擅长的地方投入、在它不擅长的地方承认边界、才是成熟的工程判断。

1.8 RAG 项目的成熟度模型

§1.7 讲了 RAG 的边界——不是所有场景都适合。另一个上线前必须想清的问题：我们当前适合做到哪一档 RAG。直接上来就做 GraphRAG + Agent memory + 多模态、在团队能力和业务需求不匹配时几乎一定失败。成熟度分阶段、每阶段投入和收益要对齐。这节给出五级成熟度模型、帮读者自诊断项目所处位置。

五级成熟度

flowchart LR
    classDef l1 fill:#fee,stroke:#c00
    classDef l2 fill:#fed,stroke:#c60
    classDef l3 fill:#fef,stroke:#808
    classDef l4 fill:#def,stroke:#06c
    classDef l5 fill:#efe,stroke:#080
    L1[L1 MVP<br/>跑通 demo]:::l1 --> L2[L2 稳定<br/>离线链路扎实]:::l2
    L2 --> L3[L3 可观测<br/>评估闭环]:::l3
    L3 --> L4[L4 优化<br/>质量和成本双升]:::l4
    L4 --> L5[L5 智能化<br/>Agent + 个性化]:::l5

L1 MVP：单一 embedding + 向量检索 + 直接送 LLM。100 份样本文档、内部 demo 能跑
L2 稳定：离线索引链路工程化、增量更新、权限过滤、版本管理（本专栏前 8 章）
L3 可观测：完整 trace、gold set 评估、故障归因、四层评估指标（ch 20）
L4 优化：Hybrid + rerank + 微调、prompt cache、模型分层、延迟成本精调（ch 13-16、21）
L5 智能化：Agent memory、GraphRAG、个性化检索、多轮对话（ch 18-19）

每级的投入与收益

等级	典型投入	典型答对率	典型用户规模
L1	1-2 人 × 1 月	50-65%	内部 demo 5-50 人
L2	2-3 人 × 2-3 月	65-75%	早期客户 100-1000 人
L3	3-5 人 × 3-6 月	70-80%	稳定用户 1K-10K
L4	5-10 人 × 6-12 月	80-90%	规模用户 10K-100K
L5	10+ 人 × 持续	85-95%	海量用户 100K+

跨级跳跃（L1 直接跳 L4）几乎必然失败——底层工程能力不足、上层优化无从下手。

每级的核心问题

L1 问题："能跑吗？"——让 RAG 出一个能用的答案
L2 问题："能稳定提供服务吗？"——索引不丢、更新能跟、权限不漏
L3 问题："为什么有时候不对？"——建立评估、找出 badcase、定位根因
L4 问题："怎么更准 / 更快 / 更便宜？"——在 L3 基础上有数据驱动地优化
L5 问题："怎么超出单轮问答的能力边界？"——Agent、memory、complex reasoning

每级解决前一级的核心问题后、才有资格问后一级——顺序颠倒会浪费。

怎么判断当前等级

自检清单：

L2 就绪：

离线索引能增量更新
权限过滤下推到向量库 filter
回滚索引版本演练过
有文档解析 / 分块 / embedding 的工程化 pipeline

L3 就绪：

每请求有完整 trace
有 500+ 条 gold set
每日跑自动回归
能按四类失败模式归因 badcase

L4 就绪：

跑过 hybrid search 和 rerank 的 A/B 比较
用过 prompt cache
有成本 / 延迟看板
做过多目标 rerank（ch14）

L5 就绪：

有明确需要 agent 或 memory 的场景
团队里有 ML 工程师能维护 memory / graph pipeline
业务能支持 +50% 的基础设施成本

选中 > 80% 表示该级就绪、可以进入下一级。

典型跨级反模式

L1 → L4：没有稳定离线链路就上 rerank + 微调——数据都不稳、优化无意义
L1 → L5：POC 阶段就上 GraphRAG——成本翻 10 倍、效果未必比 chunk RAG 强
L3 → L5：看到 GraphRAG / Agent 火、跳过 L4 优化——上层复杂、底层不稳、运维地狱
永远停在 L2：做完离线链路就满足、不建评估——质量永远不知道
L4 过早追 SOTA：最新模型 / 最新算法一上线就试——稳定性和成本都不可控

跨级的典型节奏

从 0 到 L4 的健康节奏：

第 1 月：L1 MVP
第 2-3 月：L2 稳定化（§22.3 阶段 2）
第 4-6 月：L3 可观测（§22.3 阶段 3）
第 7-12 月：L4 持续优化（§22.3 阶段 4）
第 13+ 月：L5 看业务需求、不强求

L5 不是必达——多数 RAG 项目停在 L3-L4、已经商业成功。L5 是某些特定场景的上限、不是所有项目的必经之路。

组织 vs 技术

成熟度不只是技术——是技术 + 团队 + 运营的综合：

L1-L2 技术驱动、团队小
L3 开始需要专门的评估 / 运维角色
L4 需要 ML 工程师 + 数据工程师分工
L5 需要跨功能团队（产品 / ML / 工程 / 业务）深度协作

团队能力跟不上技术雄心、RAG 项目会在 L3-L4 间反复。扩团队比升技术早规划、避免瓶颈在人而不在方案。

这个专栏和成熟度的对应

各章大致对应的等级：

ch1-4：全等级基础
ch5-8（第二部分）：L2 稳定
ch9-12（第三部分）：L2-L3
ch13-17（第四部分）：L3-L4
ch18-19（第五部分）：L5
ch20-22（第六部分）：L3-L4 运营

按当前等级选重点章节——不要强求全专栏通读后再动手。

1.9 RAG 和 Agent 的关系：从检索增强到智能体

2023 年后 "Agent" 热度上涨——很多读者会问："RAG 会不会被 Agent 取代"、"做 Agent 是不是就不用 RAG 了"。这两个问题都基于一个误解——Agent 不是 RAG 的替代品、RAG 是 Agent 的核心能力之一。两者是递进关系不是并列关系。这节把三种形态讲清楚、帮读者定位自己的项目在哪一档。

三种形态

flowchart LR
    classDef simple fill:#dfd,stroke:#080
    classDef mid fill:#fed,stroke:#c60
    classDef full fill:#def,stroke:#06c
    F1[朴素 RAG<br/>单轮检索增强]:::simple
    F2[Agentic RAG<br/>LLM 控制检索]:::mid
    F3[完整 Agent<br/>RAG 是工具之一]:::full
    F1 --> F2 --> F3

三种形态不是谁取代谁——是能力递增：

朴素 RAG：query → 检索 → 生成。单轮、固定流程
Agentic RAG：LLM 自己决定"要不要再检索一次"、"换什么 query 再查"、"证据够了吗"。LLM 是检索过程的控制者
完整 Agent：LLM 决定"调哪个工具"——RAG 只是工具之一（还有 code execution、web search、API 调用、甚至另一个 LLM）

朴素 RAG 的边界

朴素 RAG 擅长：

单跳事实查询（"企业版价格"）
已有明确答案的知识问答
固定 pipeline 高 QPS 场景

朴素 RAG 的边界：

多步推理（"对比三个方案的总成本"）
条件分支（"如果是企业版就查 SOP、否则查 FAQ"）
需要外部动作（不止查、还要执行——下单、发通知）

遇到这些场景、朴素 RAG 开始吃力——不是 RAG 坏了、是朴素不够。

Agentic RAG：LLM 做检索决策

Agentic RAG 让 LLM 主动参与检索决策：

User: 企业版和专业版在 2026 年的总拥有成本对比

LLM (内部思考): 这个问题需要：
1. 企业版 2026 定价
2. 专业版 2026 定价  
3. 两者的年运维差异

(自主检索 3 次)
→ query: "企业版 2026 定价"  
→ query: "专业版 2026 定价"
→ query: "企业版 专业版 运维成本"

(获得 3 组 context)

(综合生成答案)
LLM: 基于三份文档对比如下...

Agentic RAG 的核心能力：

Self-RAG：LLM 判断自己答案是否需要更多证据、不够就再检索
CRAG（Corrective RAG）：LLM 判断当前 retrieval 结果质量、不好就改 query 再试
Multi-step retrieval：复杂问题拆成多步、每步检索
Adaptive top-k：简单问题 top-3、复杂问题 top-20、LLM 动态决定

技术栈：LangGraph、AutoGen、自建 Agent loop。

完整 Agent：RAG 是工具之一

完整 Agent 不只有 RAG——RAG 是它的一个工具：

Agent 工具箱:
- retrieve_kb(query) : RAG 查公司知识库
- web_search(query)  : 搜公网信息
- run_code(code)     : 执行代码
- send_email(...)    : 发邮件
- query_db(sql)      : 查业务数据库
- call_api(...)      : 调外部 API

LLM 根据任务决定调哪个:
用户: "2026 年企业版的销售情况怎么样、给 CEO 发个报告"
  1. Agent 调 query_db 查销售数据
  2. Agent 调 retrieve_kb 查产品信息
  3. Agent 调 web_search 查行业数据
  4. Agent 调 run_code 生成图表
  5. Agent 调 send_email 发报告

这时候 RAG 是整个 Agent 的 1/6——而不是核心。Agent 的复杂性在决策、不在单次检索。

三种形态的对比

维度	朴素 RAG	Agentic RAG	完整 Agent
单次请求 LLM 调用	1 次	2-5 次	5-20+ 次
延迟	1-2s	3-10s	10s-几分钟
成本	低	中	高
可预测性	高	中	低（LLM 决策不稳）
适合场景	知识问答	复杂查询	跨系统任务
评估难度	低	中	高

延迟、成本、不可预测性呈阶梯上升——能力也递增。

选型判断

先问问题是什么形态：

单跳事实查询 → 朴素 RAG
多步推理 / 条件分支 → Agentic RAG
跨系统任务 + 需要执行动作 → 完整 Agent

不要"因为 Agent 酷就上 Agent"——多数企业问答 80% 的 query 是单跳、朴素 RAG 够了。把朴素 RAG 做好、再针对 20% 复杂 query 加 Agentic——分层设计比通吃 Agent 稳。

RAG 技术对 Agent 的持续价值

即使升级到完整 Agent、RAG 的所有机制仍然有用：

Agent 调 retrieve_kb 时、内部是完整的 chunk / embed / rerank pipeline
Agent 的"memory"是一个 RAG（§18.1）
Agent 的 tool selection 可能也是 RAG（tool 库向量化、按 query 检索最相关 tool）
Agent 的 planning 也可以参考历史 trace（RAG over past plans）

所以学好 RAG 不会过时——Agent 的检索内核仍然是 RAG。

在本专栏的位置

本专栏前 17 章讲朴素 RAG 的全链路——这是 Agent 的必要基础。第 18 章讲 Memory——Agent 的记忆层。但不展开完整 Agent 编排——那是另一个专栏（《LangGraph 设计与实现》）的话题。本专栏的定位：把 RAG 的工程做扎实、为上层 Agent 打好地基。

Agent 不是 RAG 的对立面、是 RAG 的消费者——消费者不能好过生产者。基础不稳、Agent 也做不好。

技术演化的历史参照

这个"朴素 → Agentic → 完整 Agent"的演化路径在其他 AI 技术也见过：

搜索：关键词搜索 → 个性化搜索 → 智能问答
推荐：协同过滤 → 深度学习 → 生成式推荐
客服：规则机器人 → 意图分类 + 知识库 → 完整对话 Agent

每一步都是给底层加一层控制——底层能力是前提、控制层是价值放大。RAG 现在在同样的演化轨道上。

1.10 典型 RAG 产品解剖：公开产品在做什么

前 9 节讲了 RAG 的概念和抽象——具体的产品长什么样？这节拿四个 2026 年最有代表性的 RAG 产品剖析——Perplexity、Claude Projects、GitHub Copilot Chat、Notion AI——让读者把本专栏概念对到真实产品上。每个产品的架构选型不同、背后考虑不同——理解这些让读者知道自己的产品该像谁。

四类典型 RAG 产品

flowchart TB
    classDef search fill:#fed,stroke:#c60
    classDef proj fill:#def,stroke:#06c
    classDef code fill:#efe,stroke:#080
    classDef doc fill:#fef,stroke:#808
    P[Perplexity]:::search
    CP[Claude Projects<br/>Custom GPT]:::proj
    CC[GitHub Copilot Chat]:::code
    NA[Notion AI]:::doc
    P --> P1[公网实时搜索<br/>+ 答案合成]
    CP --> CP1[用户上传文档<br/>+ 问答]
    CC --> CC1[代码仓库<br/>+ 编程助手]
    NA --> NA1[用户内部文档<br/>+ 智能助手]

Perplexity：公网 RAG 的代表

核心架构：

Query 进来 → 重写 + 关键词搜索（用 Bing / Google API）
抓取 top 搜索结果的完整网页
实时 chunking + embedding（基本上全 on-the-fly）
送 LLM 生成带引用答案

特点：

索引是公网 + 实时抓取、不是预建
Citation 是核心价值主张（每句话带来源链接）
多路召回（keyword + 向量）
延迟相对高（3-8 秒正常）、用户接受

借鉴点：

对实时性要求高的场景可参考——不预建索引、临时 embed
Citation 做到极致、产品差异化
UI 上边生成边显示 sources

本专栏对应章节：ch12 稀疏（关键词搜索）、ch13 hybrid、ch17 引用

Claude Projects / ChatGPT Custom GPT：用户自带知识库

核心架构：

用户上传文件（PDF / docx / 图片）
系统后台 ingest + chunking + embedding
用户在对话里提问、RAG 从用户知识库检索
每个 Project / GPT 隔离、用户间不共享

特点：

用户自管理知识库、不是厂商提供
Long context 和 RAG 混用（小文件直接进 context、大文件走 RAG）
隐私隔离强（per-user namespace）
支持代码 / 图像等多模态

借鉴点：

多租户隔离做到极致（每个 Project 独立索引）
Long context + RAG 的 hybrid 切换逻辑
用户友好的 ingest UI（拖拽上传）

本专栏对应章节：ch5 解析、ch11 多租户、ch16 long context

GitHub Copilot Chat：代码 RAG

核心架构：

工作区的代码（当前文件 + 附近文件 + import 依赖）
按符号 / 函数切 chunk（AST-based）
召回偏重精确符号匹配（BM25 主力）
IDE 集成、上下文敏感

特点：

Chunk 策略是代码特化（§6.11）
工作区作为动态 context、不是静态索引
低延迟（< 1s）——用户等不了
质量和生产代码直接挂钩（建议的代码要能编译）

借鉴点：

代码场景 BM25 优先（精确符号重要）
AST chunking（§6.11）
工作区上下文的 dynamic retrieval

本专栏对应章节：ch6 分块、ch12 BM25、§12.12 代码搜索

Notion AI：文档助手

核心架构：

Workspace 里所有文档都预 embed
用户问答时按 workspace scope 检索
答案可直接转成 Notion 块插入文档
多租户、协作友好

特点：

Workspace scope 是天然的权限边界
答案 UI 和产品深度集成（不是独立 chat UI）
批量 ingest、支持大 workspace
结构化输出（能插入 Notion 表格等）

借鉴点：

权限和 workspace 的天然映射
答案的结构化输出（§16.19）
和产品深度集成、不是 "贴上去" 的 chat

本专栏对应章节：ch7 权限、ch16 结构化输出

四类产品的关键差异

维度	Perplexity	Claude Proj	Copilot Chat	Notion AI
数据源	公网	用户上传	代码仓	Workspace 文档
索引	动态抓取	预建 per-user	动态 + 预建	预建 per-workspace
延迟	3-8s	2-5s	< 1s	1-2s
Citation	核心	有	有	有
多租户	-	强	强	强
主要 chunk 策略	动态	结构化	AST	结构化
检索偏重	Dense + BM25	Dense	BM25 + AST	Dense + metadata

每个产品的架构选型都反映核心场景的约束——不是随便选的。

产品定位决定架构

借鉴时最大的错误是"照搬 Perplexity 的架构做企业 RAG"——两者场景完全不同：

Perplexity：公网数据、用户匿名、延迟容忍
企业 RAG：内部数据、用户可标识、延迟敏感

场景决定架构、不是反过来。先想清自己做的是哪类产品、再看对应的参考架构。

背后的商业模式也不同

每类产品的商业模式影响技术决策：

Perplexity：免费 + Pro 订阅——追求用户规模、高级功能分层
Claude Projects：订阅内嵌——追求用户黏性
Copilot Chat：开发者 SaaS——按 seat 收费
Notion AI：workspace 内 addon——捆绑销售

商业模式决定能花多少钱在 RAG 基础设施——Perplexity 免费用户跑得便宜、企业 SaaS 则有更多预算做精细化。

2026 年 RAG 产品的共同趋势

不同产品但有共同方向：

Citation 必备：没有引用的 AI 产品已经失去信任
Multi-source：单一数据源时代结束、整合多个源是常态
Agentic 元素：自主决定检索策略、不只是单轮 RAG
结构化输出：JSON / 表格 / 链接、UI 深度集成
透明降级：系统不确定时明确告诉用户

这些趋势定义了"什么是好 RAG"——不是单指某个技术指标。

学习策略：找最接近的对照

开始做自己的 RAG 项目前、找一个最像的现有产品：

做代码助手 → 学 Copilot 的模式
做公司知识库 → 学 Notion AI / Claude Projects
做研究 / 公网搜索 → 学 Perplexity
做垂直领域（医疗 / 法律 / 金融）→ 可能没完全对照、找最接近的作基础

对照产品公开的技术博客 + 本专栏各章节——架构思路和工程细节都能找到。

产品解剖的持续学习

RAG 产品每季度都在演化——定期看公开资料：

Perplexity / Anthropic / OpenAI / Notion 的技术博客
产品发布会的技术披露
员工的 Twitter / blog（有时比官方更深度）
公开论文（如 Anthropic 的 Contextual Retrieval）

这些不是"课外读物"——是RAG 工程师的必修课。一年能从中学到的、比闭门造车三年多。

产品解剖和本专栏的关系

本专栏把通用 RAG 工程拆解到章节——这些产品是具体的组合案例。每读一章、都问"Perplexity / Copilot / Claude Projects 在这块怎么做"——两者对照能加深理解。

最后、对本专栏读者的建议：挑最接近自己场景的产品作"参考目标"——学它的公开架构、结合本专栏的细节、走自己的路。不是抄袭、是借鉴。

1.11 读这个专栏的建议：按角色和场景导航

这个专栏 22 章、每章一万字上下——不建议全量通读后再动手。不同角色、不同场景有不同的切入点——这节给导航指南、让读者能按自己的需求高效用这个专栏。

为什么要导航指南

flowchart TB
    classDef reader fill:#fed,stroke:#c60
    B[本专栏读者]
    B --> R1[研发工程师<br/>要写代码]:::reader
    B --> R2[架构师<br/>要做选型]:::reader
    B --> R3[产品经理<br/>要设计 feature]:::reader
    B --> R4[运维 / SRE<br/>要上线稳定]:::reader
    B --> R5[合规 / 安全<br/>要审查]:::reader
    B --> R6[CTO / 管理<br/>要战略判断]:::reader

每类角色关心的维度不同——统一阅读路径效率低。

按角色的阅读路径

研发工程师（想写代码实现）：

必读：ch1（概念）、ch2（lifecycle）、ch4（架构）
重点：ch5-16（各组件工程细节）
选读：ch17-22（产品和运营）

典型节奏：2-3 周过一遍、边读边搭 MVP。

架构师（做选型和设计）：

必读：ch1（边界）、ch4（架构）、ch22（reference architecture）
重点：ch9-13（检索核心）、ch21（成本延迟）
选读：ch18-19（高级话题）

典型节奏：先快读全专栏、再深入自己关注的层。

产品经理（设计 RAG 产品体验）：

必读：ch1（定位）、ch17（引用）、ch22（KPI）
重点：ch3（失败模式）、ch20（评估）
选读：ch14-16（看底层能力）

典型节奏：和工程师一起读 ch2-4、自己深入产品相关章节。

运维 / SRE（保证稳定运行）：

必读：ch2（lifecycle）、ch3（失败模式）、ch22（组件 + playbook）
重点：ch4（部署）、ch8（index ops）、ch21（成本延迟）
选读：ch11-12（具体组件运维）

典型节奏：从上线前的章节开始、补足事故响应能力。

合规 / 安全（审查系统）：

必读：ch7（权限）、ch17（引用审计）、ch22（合规灾备）
重点：ch9 §9.15（隐私）、ch18 §18.16（memory 中毒）
选读：ch3 / 14 / 20 的 red team 部分

典型节奏：作对话对象、不必写代码、但要理解风险。

CTO / 管理层（战略判断）：

必读：ch1（定位和边界）、ch21 §21.16（FinOps）、ch22（整体）
选读：ch19（决定是否上 GraphRAG）、ch18（决定是否上 memory）

典型节奏：1 周过一遍、和团队对齐方向。

按场景的重点章节

场景 A：要开始一个新 RAG 项目

ch1（理解）
ch22 §22.3 四阶段交付路线
ch4 + ch22 §22.1 参考架构
回到 ch5-16 深入各组件

场景 B：现有 RAG 质量不好

ch3 失败模式归类
ch20 评估驱动优化
按归因深入对应组件章节

场景 C：要上线 high-stakes 场景（合规 / 法律）

ch7 权限
ch17 §17.14 法务级溯源
ch20 §20.17 red team
ch22 §22.14 合规灾备

场景 D：规模化（从 DAU 1K 到 100K）

ch22 §22.5 演进路径
ch21 成本延迟
ch10 §10.12 大规模索引
ch11 §11.12 多租户

场景 E：团队建设

ch22 §22.10 组织学
ch22 §22.18 新人 onboarding
ch22 §22.17 KPI

按问题的查询索引

"chunk 多大合适" → ch6 §6.3 / §6.10 / §6.13

"BM25 还有用吗" → ch12 全章、§12.1 /§12.16 重点

"应该自托管还是用 API" → ch21 §21.19 + ch22 §22.16

"怎么防 prompt injection" → ch16 §16.14 + ch18 §18.16 + ch14 §14.19

"引用怎么做" → ch17 全章

"为什么答错" → ch3 失败归类 → 对应章节

"GraphRAG 要不要上" → ch19 §19.7 / §19.18

"多轮对话怎么做" → ch2 §2.14 + ch18 + ch20 §20.16

难度分层与学习节奏

内容按需要的背景分四层：入门（任何背景都能读）ch1、ch3、ch22；中等（需要软件工程基础）ch2、ch4、ch5–8、ch13–17；进阶（需要 ML / IR 基础）ch9–12；高级（需要深入经验）ch18–19，以及 ch14、ch21 的部分节。新手先啃入门建立全局，再按兴趣深入。

节奏按目标选，不是越深越好：

快速上手（2–3 周）：读 ch1–4 建立全局、读 ch22 当 reference、动手搭 MVP，遇到问题再查对应章节。
系统学习（2–3 月）：按顺序通读，每章做笔记，做一个 practice project，对照真实项目理解。
深度掌握（6 月以上）：加上外部论文精读，在自己项目上实战，参与社区贡献，最终对本专栏的内容能有自己的判断。

怎么用它，以及它不能给你什么

动手是核心——只读不写代码，效果大打折扣；带着具体问题读某一章，比抱着"学习"的目的通读有效得多。读完一章就对照自己的项目看差距、列出 action item（我们要加 rerank、我们要建 evaluation）、和团队定优先级、实施后再回来读相关章节——这一步不做，读了等于没读。

放到整个 RAG 资料生态里，各类材料的定位不同：学术论文前沿但窄，官方文档权威但分散，博客快但片面，LangChain / LlamaIndex 的文档偏工具用法。本专栏做的是把散的东西系统化——不追最新论文、不抄工具文档，沉淀相对长寿的工程框架。所以它和外部资源是配合关系：论文（Contextual Retrieval、Lost in the Middle 等）用来精读原始结论，Anthropic / LangChain / Qdrant 的技术博客用来跟进最新动态，开源实现用来看具体代码，社区用来交换实战经验。

也要说清楚它的局限：具体数字会过时（价格和模型版本一直在变，概念不变）；通用框架覆盖不了所有业务场景的特殊性；技术前沿变化快，2027 年可能出现这里没覆盖的新方向；例子偏中文语境。这些只能靠持续学习和实战补——这是起点，不是终点。

最后，这个专栏预设的读者是：有软件工程基础（不要求 ML 零基础起步）、有 RAG 项目经验或即将开始、愿意深入工程细节而不只停在概念、并且看重长期可持续而不只是短期上线。发现错误或有不同意见，欢迎通过 GitHub issue、邮件或社区讨论反馈。

1.12 RAG 在 AI 应用栈中的位置

把一个生产 AI 应用拆开看，通常有五层：

graph TD
    A[交互层<br/>Web / CLI / IDE / API]
    B[Harness 层<br/>任务编排 / 权限 / 状态 / 工具]
    C[RAG 层<br/>知识检索 / 记忆 / 上下文注入]
    D[模型层<br/>LLM / Embedding / Reranker]
    E[数据层<br/>文档 / DB / 代码 / 工单 / 日志]
    A --> B
    B --> C
    C --> D
    C --> E
    B --> D

RAG 层一边连接模型，一边连接数据。它不是数据层的简单读接口，也不是模型层的 prompt 模板。它负责把原始知识转化为模型可用的证据。

这也解释了为什么 RAG 会同时涉及搜索、数据库、机器学习、后端工程和产品设计：

搜索视角关注召回、排序、索引和查询理解。
数据库视角关注一致性、过滤、权限、更新和事务边界。
机器学习视角关注 embedding、rerank、评估和训练数据。
后端工程视角关注延迟、吞吐、缓存、降级和可观测性。
产品视角关注引用展示、用户反馈、答案置信度和失败体验。

一个 RAG 系统如果只由模型工程师设计，容易忽略权限和数据治理；如果只由后端工程师设计，容易低估语义匹配和评估；如果只由产品驱动，容易把"答案看起来不错"误判成"系统可信"。

好的 RAG 架构必须承认它是跨学科系统。

1.13 一个最小但正确的 RAG 心智模型

本章最后给出一个最小但正确的 RAG 心智模型。后续所有章节都会展开这张图。

flowchart TD
    subgraph Offline[离线索引链路]
      D0[原始文档] --> D1[解析]
      D1 --> D2[清洗与结构化]
      D2 --> D3[分块]
      D3 --> D4[元数据与权限]
      D4 --> D5[Embedding]
      D5 --> D6[索引写入]
    end
    subgraph Online[在线检索链路]
      Q0[用户问题] --> Q1[查询理解]
      Q1 --> Q2[多路召回]
      D6 --> Q2
      Q2 --> Q3[过滤与重排序]
      Q3 --> Q4[证据组织]
      Q4 --> Q5[上下文打包]
      Q5 --> Q6[模型生成]
      Q6 --> Q7[引用与校验]
    end
    subgraph Feedback[反馈闭环]
      Q7 --> F1[用户反馈]
      Q7 --> F2[日志与指标]
      F1 --> F3[评估集]
      F2 --> F3
      F3 --> D3
      F3 --> Q1
    end

这张图里有三个关键分界。

离线与在线的分界。 文档解析、分块、Embedding 和索引写入通常在离线链路完成；查询理解、召回、重排序、上下文打包和生成发生在在线请求中。离线链路追求质量和一致性，在线链路追求延迟和稳定性。把耗时解析放进在线请求，是早期 RAG 系统常见错误。

召回与生成的分界。 召回阶段产生候选证据，生成阶段组织答案。两者之间必须有明确的数据契约：每个证据片段的文本、来源、位置、权限、分数、版本都要保留。否则生成阶段拿到的只是一团文本，无法做引用和验证。

答案与反馈的分界。 用户看到答案不是链路终点。生产 RAG 必须记录这次请求的候选、排序、上下文、答案、引用和反馈。没有反馈闭环，系统只能靠作者直觉调参。

这就是为什么 RAG 是 AI 应用的第二大脑。大模型提供语言和推理能力，RAG 提供可更新、可授权、可追溯的外部记忆。两者结合，AI 应用才从"会聊天"走向"能处理真实知识工作"。

下一章会沿着一次用户提问的完整旅程，把这张图里的每个节点放进真实请求链路中。