Agent丨为什么要使用 RAG（检索增强生成）技术？

type

Post

status

Published

date

May 18, 2026

slug

agent43

summary

一、先说结论：RAG 解决的不是“让模型更聪明”，而是“让模型有依据地回答”

大模型本身像一个经过大规模预训练的“压缩知识库”，但它有几个天然问题：

不知道你的私有数据：企业文档、项目代码、内部 SOP、合同、工单、知识库并不在模型训练数据里。

知识更新慢：模型参数更新成本高，不适合每天同步业务数据。

容易幻觉：模型会生成看起来合理但没有依据的答案。

难以追溯来源：纯 LLM 回答通常很难说明“这句话来自哪份文档、哪一页、哪一段”。

上下文窗口有限：即使模型支持长上下文，也不适合把全部资料都塞进去，成本高、噪声大、延迟高。

RAG 的核心价值就是：在生成答案之前，先从外部知识源中检索出相关证据，再让 LLM 基于这些证据回答。 原始 RAG 论文将其描述为把模型参数中的“参数化记忆”与外部索引中的“非参数化记忆”结合起来，用于知识密集型任务，并指出它有助于知识更新和答案可追溯等问题。(arXiv)

二、RAG 的本质：把“记忆”从模型参数里拆出来

传统 LLM 的回答路径大概是：

RAG 的回答路径则变成：

LlamaIndex 对 RAG 的解释非常直接：LLM 并没有训练在你的数据上，RAG 通过加载、索引、查询你的数据，把最相关的上下文和用户问题一起交给 LLM。LlamaIndex 也把 RAG 流程拆成 Loading、Indexing、Storing、Querying、Evaluation 五个阶段。(Developer Documentation)

所以，RAG 不是一个单点技术，而是一套上下文工程系统：

RAG = 数据接入 + 文档切分 + 向量化/索引 + 检索 + 重排 + Prompt 组装 + 生成 + 引用 + 评估

三、为什么不能只靠 Prompt？

很多初学者会问：既然大模型这么强，为什么不直接 Prompt？

原因是：Prompt 只能约束模型的输出风格，不能凭空补齐模型不知道的事实。

比如你问：

“我们公司最新的退款政策是什么？”

如果退款政策昨天刚改，模型参数里不可能知道。你在 Prompt 里写“请准确回答，不要幻觉”，也只能降低乱编概率，不能提供事实来源。

更糟糕的是，LLM 在缺少信息时并不总是说“不知道”，而是可能根据相似模式补全一个看似合理的答案。这就是 RAG 要解决的问题：让模型先拿到证据，再组织语言。

OpenAI 的 Retrieval API 文档也强调，语义检索可以在几乎没有关键词重合的情况下找出语义相关结果，并且和模型结合后可以用于综合回答；其底层依赖 vector stores 作为数据索引。(OpenAI开发者)

四、为什么不能只靠 Fine-tuning？

Fine-tuning 适合让模型学习：

输出格式

领域表达风格

固定任务模式

分类、抽取、结构化输出习惯

但 Fine-tuning 不适合频繁注入动态知识。

原因有四个：

问题	Fine-tuning	RAG
知识更新	需要重新训练或增量训练	更新索引即可
来源追溯	很难知道答案来自哪里	可以返回文档、段落、页码
私有数据接入	成本高、治理复杂	可按权限检索
动态业务数据	不适合	很适合

RAG 原始论文之所以强调“参数化记忆 + 非参数化记忆”，本质就是把长期稳定能力留在模型参数中，把可更新知识放在外部检索系统中。(arXiv)

一句话总结：

Fine-tuning 解决“模型怎么说”，RAG 解决“模型依据什么说”。

五、为什么不能直接把所有文档塞进长上下文？

现在很多模型支持长上下文，于是有人会问：既然上下文很长，为什么还需要 RAG？

因为长上下文不是免费的，也不是越长越好。

直接塞全部资料会带来几个问题：

成本高：每次请求都要付大量输入 token。

延迟高：上下文越长，推理越慢。

噪声大：无关内容越多，模型越容易被干扰。

权限难控：不同用户不应该看到同一批全部资料。

难以评估：不知道模型到底用了哪段上下文。

Claude Code 的 Agent SDK 文档强调，它把 Claude Code 的工具、agent loop 和 context management 做成可编程能力，让 agent 能读文件、跑命令、搜索 web、编辑代码等；这说明成熟 Agent 系统不是简单“塞长上下文”，而是围绕工具和上下文管理构建工作流。(Claude Code) Anthropic 也在上下文工程文章中提到，Claude Code 会压缩历史消息，保留关键架构决策、未解决 bug 和实现细节，同时丢弃冗余工具输出。(Anthropic)

所以，RAG 的意义不是因为模型上下文不够长，而是因为：

生产系统需要“按需取证据”，而不是“无脑塞资料”。

六、从源码/框架角度看：成熟 RAG 系统一般长什么样？

以 Haystack 的官方 RAG 教程为例，一个基础 RAG pipeline 通常包含四个核心组件：

Text Embedder：把用户问题转成 embedding。

Retriever：从 DocumentStore 检索相关文档。

Prompt Builder：把问题和检索文档组装成 Prompt。

Chat Generator：调用 LLM 生成答案。

Haystack 文档明确将这个流程描述为：为用户查询创建 embedding、检索相关文档、构造模板 prompt、再由 ChatGenerator 生成最终答案。(Haystack)

简化源码如下：

Haystack 官方教程中的 pipeline 连接方式也是：text_embedder.embedding -> retriever.query_embedding -> prompt_builder -> llm.messages，并通过 run() 同时传入问题给 embedder 和 prompt_builder。(Haystack)

这个结构非常典型：

七、RAG 在 Agent 系统里为什么更重要？

Agent 和普通 Chatbot 的区别是：Agent 不只是回答问题，还要执行任务。

比如 coding agent 要完成：

读代码

搜索文件

理解依赖

修改文件

跑测试

根据报错继续修复

总结变更

这类任务对“上下文准确性”的要求更高。如果 Agent 找错了文件、理解错了接口、拿到了过期文档，就可能直接改坏代码。

Claude Code 官方介绍中说，它能理解代码库、编辑文件、运行命令，帮助开发者更快交付；Agent SDK 也提供读文件、运行命令、编辑代码等内置工具。(Claude) OpenCode 也将自己定位为开源 coding agent，支持终端、IDE、桌面端，并支持多模型接入；其 GitHub README 中还区分了 build 和 plan 两类 agent，plan 是偏只读分析和代码探索的模式。(OpenCode)

这说明成熟 Agent 的核心不是“模型一次性知道全部”，而是：

模型通过工具和检索逐步获得必要上下文，再决定下一步动作。

八、OpenClaw / OpenCode 给 RAG 的工程启发

OpenClaw 的 GitHub README 将它描述为运行在自己设备上的个人 AI assistant，可连接多个消息渠道，并作为本地、快速、常驻的个人助手使用。(GitHub) 这类常驻 Agent 会遇到一个典型问题：用户历史、文件、任务、记忆越来越多，不可能每次都全部塞入上下文。

OpenClaw 社区 issue 中有一个“pre-message retrieval hook”的提案，核心诉求是在每条用户消息进入 LLM 前，自动查询外部 memory/vector database，并把检索结果注入上下文；提案里也指出，没有这个机制时，用户只能手动调用 memory_search，或者在会话开始时加载全部 memory 文件，后者成本更高。(GitHub)

另一个 OpenClaw issue 讨论了 memory search 的 rerank hook：现有流程是 vector + BM25 检索与加权融合，但缺少 rerank 阶段；提案认为 bi-encoder 检索快但不够精细，cross-encoder rerank 更慢但更精准，retrieve-then-rerank 是现代检索管线常见模式。(GitHub)

这对生产 RAG 很有启发：

也就是说，Agent 场景下的 RAG 不只是“问答检索”，而是可以变成：

任务记忆检索

代码上下文检索

工具文档检索

历史决策检索

用户偏好检索

权限范围内的业务数据检索

九、RAG 到底带来了哪些核心收益？

1. 降低幻觉：让答案有证据边界

RAG 不保证 100% 没有幻觉，但它显著改变了模型生成的约束条件：模型不再完全依赖参数记忆，而是基于检索片段回答。

如果 Prompt 设计得当，可以要求模型：

“只基于给定 Context 回答；如果 Context 中没有答案，就说不知道。”

这会把问题从“模型会不会乱编”转化为“检索是否召回了正确证据、生成是否忠实于证据”。

2. 支持私有知识：让 LLM 进入企业数据

LlamaIndex 明确指出，RAG 让 LLM 能够在查询时访问你的私有数据，而不是把这些数据训练进模型；为了避免每次发送全部数据，RAG 会索引数据并只选择相关部分发送给 LLM。(Developer Documentation)

这正是企业落地最常见的需求：

企业制度问答

客服知识库

合同审查

研发文档问答

代码库问答

BI 数据解释

医疗、法律、金融资料辅助检索

3. 支持知识更新：更新索引比更新模型便宜

如果公司政策每天变化，用 Fine-tuning 更新模型非常重；但 RAG 只需要：

新文档入库

文档切分

生成 embedding

更新向量索引 / 倒排索引

下次查询即可生效

Google Gemini File Search 文档也将 File Search 描述为一种 RAG 工具：它会导入、切分、索引数据，并在用户提示时检索相关信息作为模型上下文。文档还说明，导入文件时会自动 chunk、embedding、index，也可以配置 chunk 大小和 overlap。(Google AI for Developers)

4. 支持引用与审计：答案可以追溯

在企业系统中，“答案正确”还不够，还要能回答：

这句话来自哪份文档？

文档版本是什么？

是哪一页？

哪个用户有权限看？

这次回答用了哪些 chunk？

为什么这个 chunk 被召回？

Gemini File Search 文档提到，使用 File Search 时，模型响应可以包含 citation 信息，帮助事实核查和验证；对于 PDF 等带页码文档，还可以访问引用页码信息。(Google AI for Developers)

这就是 RAG 相比纯 LLM 的巨大工程价值：可解释、可审计、可回放。

5. 降低上下文成本：只取相关片段

RAG 的检索层本质上是一个“上下文筛选器”。

与其把 1000 页文档全部塞给模型，不如先检索出最相关的 5～20 个片段，再交给模型生成。

这带来三点收益：

输入 token 更少

响应更快

噪声更少

Haystack README 也强调其面向生产级 RAG 和 Agents，支持对 retrieval、routing、memory、generation 进行显式控制。(GitHub)

十、RAG 的典型生产架构

一个生产级 RAG 通常不是“向量库 + LLM”这么简单，而是下面这种分层架构：

其中最容易被低估的是三个模块：

1. Chunking

切分太大，召回不精准；切分太小，语义不完整。生产中通常要根据文档类型设计：

FAQ：按问答对切

Markdown：按标题层级切

PDF：按段落、页码、标题切

代码：按函数、类、文件结构切

合同：按条款切

表格：按行、区域或语义块切

2. Hybrid Retrieval

单纯向量检索容易漏掉精确关键词，比如：

API 名称

错误码

变量名

订单号

法律条款编号

配置项名称

所以生产中常用：

BM25 / keyword + vector search + metadata filter + rerank

OpenClaw rerank issue 中也提到，纯 embedding + BM25 可能仍会返回词汇或语义上看似相关但实际无关的 chunk，因此需要 reranking。(GitHub)

3. Evaluation

RAG 没有评估就很难上线。至少要评估：

Recall@k：正确证据有没有被召回？

MRR / NDCG：正确证据排得靠不靠前？

Faithfulness：答案是否忠实于证据？

Answer Correctness：最终答案是否正确？

Citation Accuracy：引用是否真的支撑答案？

Latency：检索和生成耗时是否可接受？

Cost：embedding、rerank、LLM token 成本是否可控？

LlamaIndex 也把 Evaluation 列为 RAG 的关键阶段，用于检查准确性、忠实性和速度。(Developer Documentation)

十一、RAG 不适合什么场景？

RAG 很重要，但不是万能药。

不适合或不应优先使用 RAG 的场景包括：

场景	原因
纯创作类任务	不需要外部证据
固定格式改写	Prompt 或 fine-tuning 更直接
简单分类任务	小模型 / 规则 / fine-tuning 可能更便宜
数据高度结构化且需要精确计算	应优先查数据库或调用 BI / SQL 工具
强实时事务操作	需要工具调用、权限控制和事务系统，不只是 RAG
高风险医疗/法律/金融决策	RAG 只能辅助，不能替代专业审核

一句话：

需要“事实依据”的生成任务适合 RAG；需要“确定性执行”的任务通常还要结合工具调用。

十二、RAG 与 Agent、Tool Calling 的关系

RAG、Agent、Tool Calling 不是互斥关系，而是三层能力：

可以这样理解：

RAG：解决“我应该参考什么信息？”

Tool Calling：解决“我应该调用什么能力？”

Agent：解决“为了完成任务，下一步该做什么？”

Claude Code / OpenCode 这类 coding agent 的实践说明：成熟 Agent 往往会把文件读取、搜索、命令执行、编辑、上下文压缩、权限控制结合起来，而不是只靠一次性生成。(Claude Code)

在企业系统中，常见组合是：

十三、一个生产级 RAG 的最小实现模板

下面是一个工程上更接近生产的伪代码：

这个模板体现了 RAG 的工程本质：

不是把检索结果随便塞给模型，而是要控制召回、排序、权限、上下文、引用和失败边界。

十四、RAG 的常见失败模式

1. 检索不到

原因可能是：

chunk 切得不好

embedding 模型不适合领域

query 太短或太口语化

只用了向量检索，没用关键词检索

metadata filter 过严

解决方式：

query rewrite

hybrid search

parent-child chunk

增加同义词/术语表

调整 top-k

rerank

2. 检索到了，但答案仍然乱编

原因可能是：

Prompt 没有限制“只能基于上下文”

context 太多，模型忽略关键证据

chunk 之间互相冲突

没做时间优先级

没做引用校验

解决方式：

强制引用

加入“无证据则拒答”

使用 answer-grounding 检查

对冲突文档按时间、版本、权限排序

生成后做 citation verification

3. 召回结果看似相关但实际无关

这是向量检索常见问题。比如查询“如何配置模型路由”，可能召回“网络路由配置”，语义相似但领域不同。

解决方式：

metadata filter

BM25 + vector hybrid

cross-encoder rerank

domain classifier

query decomposition

OpenClaw 社区关于 rerank hook 的讨论也正是围绕这个问题：bi-encoder 快但可能不够精细，cross-encoder 慢但能捕捉 query-document 的细粒度交互。(GitHub)

十五、RAG 选型建议

1. 快速原型

适合：

LlamaIndex

LangChain

Haystack

OpenAI Vector Store / Retrieval

Gemini File Search

LlamaIndex 适合快速把私有数据接到 query engine、chat engine、agent 中；Haystack 更强调显式 pipeline 和生产级控制；LangChain/LangGraph 更适合和 Agent workflow 结合。LlamaIndex 文档明确说 query engines、chat engines 和 agents 经常使用 RAG 来完成任务。(Developer Documentation) LangChain README 则将其定位为构建 agents 和 LLM 应用的框架，并可结合 LangGraph 构建可控 agent workflow。(GitHub)

2. 企业生产

建议关注：

文档解析质量

权限模型

metadata schema

hybrid retrieval

rerank

evaluation

observability

citation

灰度发布

数据更新链路

成本控制

3. Agent 场景

建议增加：

memory retrieval

tool documentation retrieval

codebase retrieval

conversation summarization

pre-message retrieval hook

post-retrieval rerank hook

context compaction

Claude Code 的 context management、OpenCode 的 plan/build agent 分层、OpenClaw 社区对自动 memory retrieval hook 的讨论，都说明 Agent 系统会越来越依赖“按需检索上下文”的机制。(Claude Code)

十六、最终总结

RAG 的价值可以概括成一句话：

让 LLM 从“凭记忆回答”变成“查证据后回答”。

它解决了大模型落地中的几个核心问题：

私有知识接入：让模型回答企业内部数据。

知识实时更新：更新索引比训练模型更轻。

减少幻觉：让回答受到检索证据约束。

来源可追溯：支持引用、页码、审计。

降低上下文成本：只把相关片段送给模型。

支撑 Agent 长任务：为 Agent 提供动态记忆和任务上下文。

但要记住：RAG 不是“向量数据库 + LLM”这么简单。真正生产级的 RAG 是一个完整系统：

所以，为什么要使用 RAG？

因为在真实业务里，我们需要的不是一个“会说话的模型”，而是一个能基于企业知识、最新数据和可验证证据进行回答与行动的系统。RAG 正是把 LLM 从“通用生成器”变成“可信知识应用”的关键桥梁。