RAG范式演进与系统全景

第 1 章 RAG 范式演进与系统全景

1.1 大模型落地的四重矛盾：为什么需要 RAG

大语言模型在 2022 年之后迅速从实验室走向产业，但任何把通用大模型直接接入生产系统的尝试，几乎都会撞上同一组墙：模型的知识停在训练截止日，回答里会凭空捏造事实，企业内部的私有资料根本无法进入模型参数，而要为每个细分场景从零训练一个专用模型，成本又高到难以承受。RAG（Retrieval-Augmented Generation，检索增强生成）正是为了同时缓解这四组矛盾而逐步走向成熟的工程范式。我们逐条展开。

第一重矛盾是知识陈旧。 大模型的知识完全来自训练数据，而一次完整预训练要消耗数百万 GPU 小时，企业事实上不可能按周甚至按日重训模型。即便采用继续预训练（continued pre-training），从数据采集、清洗、对齐到部署的全周期通常也要数周时间。但企业面对的业务环境是动态的：产品手册每周迭代、行业法规实时更新、客户合同条款变更、股价财报分钟级刷新。任何"以模型截止日作为知识截止日"的系统，都会在业务侧出现明显的滞后。RAG 把"知识"从模型参数里外置到可独立更新的检索库，知识更新的边际成本从"重训一次模型"降到"刷新一批文档"，时间从数周压缩到分钟级。

第二重矛盾是幻觉。 大模型的本质是"在已有 token 序列条件下的下一个 token 概率分布"，它并不内建事实校验机制。当模型被问到训练语料中稀疏或完全不存在的事实时，它倾向于用最合理的"看起来对"的语言继续生成，而不是承认不知道。这种幻觉（hallucination）在开放域问答、法律条文引用、医学诊断建议、金融数据查询等高风险场景里是不可接受的。RAG 通过在生成前强制注入检索到的证据片段，把模型的生成行为约束到"基于给定上下文回答"，从机制上大幅降低无中生有的概率。即便不能 100% 消除幻觉，也至少让模型有了"可被审阅的事实依据"。

第三重矛盾是私域知识无法内化。 企业内部沉淀了大量非公开资料：产品设计文档、客服工单、代码仓库、会议纪要、客户案例、合规手册。这些数据既不能上传到第三方闭源模型的训练流水线，也不适合直接拼到 prompt 里塞给超大上下文窗口。RAG 提供了第三条路：让检索库运行在企业自己的基础设施上，文档不出域，模型只读到"被授权的相关片段"，既保护了数据主权，又让模型具备了回答私域问题的能力。这是 RAG 在企业市场迅速成为默认选项的核心原因。

第四重矛盾是私有化部署成本。 要让一个 70B 级别的模型在企业内部稳定服务 A 类、B 类、C 类不同业务，硬件、推理优化、运维监控的总投入动辄百万级。而 RAG 架构允许"用相对较小的开源模型 + 高质量检索库"达到接近超大模型的领域问答效果，把单次推理的算力开销降低一个数量级。即便必须使用闭源大模型作为生成器，RAG 也通过"先检索再生成"把 prompt 长度从整本手册压缩到若干片段，显著节省 token 成本。

这四重矛盾——时效、事实、隐私、成本——共同决定了 RAG 不是某一种可选技术，而是企业大模型落地的事实标准路径。理解了这四点，就理解了为什么过去两年 RAG 工程化会以如此惊人的速度从一篇论文演化为一整套基础设施。

1.2 四条技术路径的能力边界：RAG / 微调 / 提示工程 / 长上下文

要让大模型使用外部知识，并不是只有 RAG 一条路。摆在工程师面前的常见选择至少包括四条路径：提示工程（Prompt Engineering）、检索增强生成（RAG）、微调（Fine-tuning）、长上下文（Long Context）。它们并非互斥，而是各自解决了不同维度的问题，错误的组合往往比"什么都不做"更糟糕。

提示工程 是成本最低、迭代最快的路径。它通过精巧的指令设计、Few-shot 示例、思维链（Chain-of-Thought）引导，让模型在不动参数、不外接知识库的情况下发挥更强的推理与格式遵循能力。提示工程擅长解决的是"模型的输出形态"问题：让模型学会按 JSON 输出、学会分步骤思考、学会扮演某种角色。但它无法解决"模型不知道的事实"——再精巧的提示也不能让 GPT-4 在它训练截止日之后告诉你今天的股价。所以提示工程的角色是 RAG 系统的"表达层"，而不是"知识层"。

微调 通过在特定数据集上继续训练模型的参数，让模型"内化"某种行为模式、风格偏好或领域语言习惯。它擅长解决"输出风格与行为对齐"问题，比如让模型学会用法律文书的措辞回答、学会生成符合公司代码规范的函数、学会在多轮对话中保持特定人设。微调也可以注入新知识，但这是一种"用参数承载知识"的昂贵方式：知识与权重耦合后无法精确更新、容易产生灾难性遗忘、且对算力和数据量都有较高要求。更关键的是，当业务知识每周变化时，微调完全跟不上节奏。微调的真正用武之地是"行为与风格的稳定内化"，而不是"动态知识注入"。

长上下文 是 2023 年下半年以来兴起的一种"用窗口换知识"的路径。Claude、GPT-4 Turbo、通义千问等模型陆续把上下文窗口扩展到 128K、200K 甚至百万 token 级别。理论上，可以把整本手册、整份合同、整个代码仓库直接塞进 prompt，让模型基于全量上下文回答。长上下文的优势在于实现简单、保留了文档的完整结构，对结构化引用尤其有效。但它有三方面局限：第一是成本，长上下文按 token 计费，把 100 万 token 的文档每轮都完整传入会让单次问答的成本达到 RAG 方案的几十倍；第二是"中间迷失"（Lost in the Middle）现象，研究表明即便模型能容忍长输入，对中间位置信息的检索精度仍显著低于开头和结尾；第三是"知识更新"问题，一旦业务变化就要重新构造整个 prompt，且没有检索阶段的细粒度控制。长上下文的最佳定位是"对单份结构化文档的深度阅读与推理"，而非"对企业级知识库的持续问答"。

RAG 走的是另一条路：通过运行时检索，把与当前问题最相关的若干片段动态拼入 prompt。这让"知识的存储"与"模型的推理"解耦——知识以可独立更新的形式存在于检索库中，模型专注于生成。RAG 的优势是知识新鲜度高、token 成本可控、对长文档友好、便于做权限隔离与审计；劣势是工程复杂度高、检索质量直接决定生成质量、对文档预处理质量高度敏感。

我们用一张取舍矩阵来对比四条路径的核心能力维度：

| 维度 | 提示工程 | RAG | 微调 | 长上下文 | |------|---------|-----|------|----------| | 注入新知识 | 否（仅引导） | 是（外挂） | 是（参数内化） | 是（一次性传入） | | 知识更新成本 | 极低 | 低（重建索引） | 高（再训练） | 中（重建 prompt） | | 输出风格控制 | 中 | 中 | 高 | 中 | | 推理算力开销 | 低 | 低-中 | 低 | 高 | | Token 成本 | 低 | 低-中 | 低 | 高 | | 数据隐私可控 | 取决于模型 | 高（库可私有） | 中（数据进训练） | 取决于模型 | | 工程复杂度 | 低 | 中-高 | 高 | 低 | | 适合场景 | 格式与推理引导 | 动态知识问答 | 风格与行为内化 | 单份长文档阅读 |

判断准则可以总结成四条经验法则：第一，凡是"知识每周/每天都在变"的场景，RAG 优先；第二，凡是要让模型"学会某种说话方式或做事方式"，微调优先；第三，凡是问题必须基于"一份完整长文档内部细节"回答，且该文档稳定不变，长上下文优先；第四，凡是要控制输出格式、引导分步推理，提示工程是所有方案的"乘法因子"。

真实场景的选择示例： 一个在线法律咨询系统需要同时满足三类需求——援引最新司法解释（知识高频更新，应走 RAG）、生成符合律所风格的文书（风格稳定，应走微调）、对单份合同做条款风险审查（一份长文档的深度阅读，应走长上下文）。最合理的方案是"RAG 检索证据 + 微调控制风格 + 必要时叠加长上下文处理完整合同"，而不是赌一条路径通吃。理解了这套组合规则，就理解了为什么 RAG 是企业落地的"主路径"而不是"唯一路径"。

1.3 RAG 范式的四代演进

RAG 并非一夜之间成为今天的样子。从 2020 年 Lewis 等人在 Facebook AI 的原始论文，到 2024 年开始出现的 Agentic RAG，RAG 范式经历了四代清晰的演进，每一代都在试图解决上一代暴露出来的具体痛点。

第一代：Naive RAG（朴素 RAG）。 原始 RAG 的形态非常直接——把文档切成等长片段，用嵌入模型编码成向量存入向量库；用户提问时把问题也编码成向量，做一次最近邻检索取出 Top-K 个片段，连同问题一起塞进 prompt 让模型回答。这条链路在演示场景里效果惊艳，但在生产里几乎立刻暴露三个问题：第一是检索质量差，"语义相似"和"问题相关"之间有显著鸿沟；第二是缺乏对生成质量的反馈机制，错答无人察觉；第三是端到端能力被严重耦合，任何一个环节改进都要全链路重写。Naive RAG 让我们看清了"原始形态的可行性与局限"。

第二代：Advanced RAG（高级 RAG）。 这一代引入了大量针对检索-生成链路的优化技术。在检索前，通过查询改写（Query Rewriting）、查询扩展（Query Expansion）、HyDE（Hypothetical Document Embeddings，用假设性回答反向检索文档）等技术弥补"用户提问的语义噪声"；在检索中，引入混合检索（Hybrid Retrieval，把 BM25 关键词检索与向量语义检索并行或融合），用元数据过滤、文档结构化字段过滤提升召回精度；在检索后，引入重排序（Reranking）阶段，用更精细的交叉编码模型对初检结果做二次排序；在生成阶段，引入引用追踪（让模型在回答中标注信息来源）、自反思（Self-Reflection，让模型先评估答案再输出）等机制。Advanced RAG 的核心思想是"承认链路中每一步都可能引入噪声，因此要在每一步都加上显式的纠偏机制"。

第三代：Modular RAG（模块化 RAG）。 当 Advanced RAG 积累了足够多的优化点后，工程团队开始意识到：把这些优化点塞进一条线性的脚本里是难维护的。Modular RAG 把整条链路拆解成一组可独立替换、可自由组合的模块——查询理解模块、检索模块、重排模块、压缩模块、生成模块、验证模块——每个模块有明确的输入输出契约，可以按业务需求灵活插拔。例如在某些场景里我们希望跳过重排（成本敏感），在另一些场景里希望叠加多路召回（精度敏感），在涉及多模态时希望把视觉模块也接入链路。Modular RAG 不仅是工程架构上的进步，也是认知上的进步：它承认 RAG 不存在"标准链路"，只有"针对场景定制的模块编排"。

第四代：Agentic RAG（智能体化 RAG）。 进入 2024 年后，RAG 开始与 Agent 范式深度融合。Agentic RAG 的核心变化是"从单轮问答走向多步推理"：用户提问后不再直接检索，而是先由一个 Agent 拆解问题、决定要不要检索、检索几路、用什么检索策略；检索回来后再决定信息是否充分，不充分就再次检索或调用其他工具（如计算器、SQL、API）；最终把多步证据汇总后再让模型生成。这种范式让 RAG 从"回答知识型问题"扩展到"完成需要规划的复杂任务"，例如"对比三份合同的差异并给出风险评分"，需要 Agent 自主决定先读哪份、再读哪份、怎样对齐条款。Agentic RAG 解决了 Naive/Advanced RAG 无法处理的"多跳推理"与"工具协同"问题，但代价是系统复杂度上升到一个新的台阶，对框架（如 LangGraph、AutoGen）的依赖也显著增强。

我们用一张对比表总结四代 RAG 的关键差异：

| 维度 | Naive RAG | Advanced RAG | Modular RAG | Agentic RAG | |------|-----------|--------------|-------------|-------------| | 检索策略 | 单路向量检索 | 混合检索 + 改写 | 模块化编排 | Agent 动态决策 | | 链路结构 | 线性 | 线性 + 旁路优化 | 可插拔模块 | 多步循环 + 工具调用 | | 多跳推理 | 不支持 | 弱支持 | 中等支持 | 原生支持 | | 工具调用 | 无 | 有限 | 可扩展 | 一等公民 | | 工程复杂度 | 低 | 中 | 中-高 | 高 | | 典型框架 | 早期 LangChain | LangChain + Reranker | LlamaIndex / LangChain Expression | LangGraph / AutoGen / CrewAI |

理解这四代演进，最重要的不是记住时间线，而是抓住"每一代在解决什么具体问题"。Naive RAG 解决了"能不能做"，Advanced RAG 解决了"做得好不好"，Modular RAG 解决了"能不能灵活定制"，Agentic RAG 解决了"能不能完成复杂任务"。这个演进逻辑会贯穿后续章节对每个具体技术的展开。

1.4 RAG 系统全栈架构：离线、在线、评测三闭环

把 RAG 看作一个"问答函数"是远远不够的。在生产环境中，RAG 实际上由三条相对独立又彼此咬合的子链路组成：离线摄入流水线（把杂乱的原始文档变成可检索的知识库）、在线检索生成主链路（把用户问题变成有据可依的回答）、评测反馈系统（量化系统表现并驱动迭代）。三者共同构成一个完整的闭环。

离线摄入流水线是整个系统的"上游水厂"。它的起点是来自四面八方的原始数据：PDF 合同、Word 报告、HTML 网页、Markdown 文档、Slack 消息、数据库记录、Confluence 页面。这些数据形态各异、质量参差，需要经过四道工序。第一道是解析（Parsing）：把不同格式的原始文档还原成结构化文本流，同时尽量保留标题层级、表格、列表、代码块、图片等结构信息。第二道是切块（Chunking）：把过长的文档切成粒度适中的片段，粒度太粗会引入无关上下文干扰模型判断，粒度太细又会切断必要的语义连贯。第三道是嵌入（Embedding）：用嵌入模型把每个切块映射成高维向量，向量的几何距离会反映语义相似度。第四道是索引（Indexing）：把向量、元数据（来源、时间、权限、章节）、可选的关键词倒排索引一并写入检索引擎（向量数据库或混合检索引擎）。离线流水线的产出是一个"可被检索的、可被审计的、可被更新的"知识库。离线侧的工程难点在于：解析质量天花板由文档格式的多样性决定；切块策略直接决定检索召回率；嵌入模型的选择决定语义匹配能力；索引结构决定检索延迟与并发能力。

在线检索生成主链路是用户感知的"前端"。它从用户问题开始，经过五道工序。第一道是查询理解（Query Understanding）：识别用户意图、提取关键实体、改写或扩展查询、决定走哪一路检索策略。第二道是检索（Retrieval）：在知识库中并行执行向量检索、关键词检索、结构化过滤等，召回候选片段。第三道是重排（Reranking）：用更精细的模型对初检片段做二次排序，剔除表面相似但语义无关的"假阳性"。第四道是上下文组装（Context Assembly）：把经过筛选的片段与系统指令、用户问题一起拼装成最终 prompt，要处理片段去重、引用标注、长度截断等细节。第五道是生成（Generation）：把组装好的 prompt 送入 LLM，得到回答，并根据需要叠加引用、流式输出、安全过滤等后处理。在线侧的工程难点在于：每一步都可能引入新的噪声与延迟，五步串联后的端到端质量受最差环节约束；任何对延迟敏感的场景（实时客服、语音助手）都对这五步的累计耗时提出严苛要求。

评测反馈系统是 RAG 区别于"一次性 demo"的关键。它通过持续运行的评测流水线衡量系统的真实表现，驱动离线与在线链路的迭代。评测的核心挑战是：RAG 是端到端系统，但错误可能来自检索阶段、生成阶段或两者协同，必须有可拆解的指标体系。常见的评测维度包括：检索侧的召回率（Recall@K、MRR）、生成侧的忠实度（Faithfulness，回答是否忠于检索证据）、回答的答案相关度（Answer Relevance）、上下文利用率（Context Utilization）、端到端的语义准确率（基于标注集或 LLM-as-a-Judge）。评测反馈的结果要以可视化的形式回流到工程团队，并最终驱动离线侧（重建索引、换嵌入模型、调整切块）与在线侧（优化查询改写、调整重排权重、增加 Agent 步骤）的具体动作。

下面用一张系统全景图展示三条子链路的协同关系：

```mermaid flowchart TB subgraph offline[离线摄入流水线] A1[原始文档<br>PDF/Word/HTML/DB] --> A2[解析器<br>Parser] A2 --> A3[切块器<br>Chunker] A3 --> A4[嵌入模型<br>Embedder] A4 --> A5[向量索引<br>Vector Index] A5 --> A6[知识库<br>Knowledge Store] end

subgraph online[在线检索生成] B1[用户查询] --> B2[查询理解<br>Query Understanding] B2 --> B3[多路检索<br>Hybrid Retrieval] A6 --> B3 B3 --> B4[重排序<br>Reranker] B4 --> B5[上下文组装<br>Context Assembly] B2 --> B5 B5 --> B6[生成器<br>LLM Generator] B6 --> B7[回答与引用] end

subgraph eval[评测反馈闭环] C1[评测集<br>Eval Dataset] --> C2[指标计算<br>Recall/Faithfulness] B7 --> C2 A6 --> C2 C2 --> C3[反馈信号<br>Insights]