什么是 RAG？为什么需要它？ — RAG 和 AI 代理

收益：

解释 RAG 在不改变模型权重的情况下注入上下文，并采用“开卷考试”逻辑
根据成本、及时性和使用场景将 RAG 与微调和长上下文方法进行比较
列出由索引和查询阶段组成的典型 RAG 管道的步骤

无论语言模型（理解并生成文本的人工智能；我们从现在开始简称为模型）有多么强大，它都不知道你的公司昨天签署的合同，你的内部 wiki（内部知识库）页面，或者今天早上发布的发行说明。该模型仅限于截至其训练之日的一般知识；这称为“教育截止日期”。 RAG（检索增强生成）恰好填补了这一空白：它找到与问题相关的公司文档，将其作为上下文提供给模型（即，它将在生成答案时读取的附加文本），并根据此上下文生成答案。

在本单元中，我们将清楚地了解 RAG 是什么、何时优先选择哪些替代方案以及典型 RAG 管道的步骤。后续的所有单元都会对这张地图的各个部分进行一一加深。

RAG的基本理念：开卷考试

让我们用一句话来解释 RAG：“首先找到相关文档，然后让模型读取该文档并相应地打印答案。”

最有用的类比是：RAG 将模型从“闭卷考试”转变为“开卷考试”。在闭卷考试中，学生仅凭记忆作答；编造你不记得的内容的风险很高。在开卷考试中，学生通过查看放在他面前的来源来回答。在 RAG 中，模型不再根据自己的记忆进行回答，而是根据您提供的当前特定文本进行回答。

关键点：RAG 不会改变模型的权重，即模型已经学习的数十亿个数值参数。您无需重新训练模型。对于每个问题，您将与该问题相关的文本块注入到提示中（发送到模型的指令文本）。因此，当文档更新时，您不必重新训练模型；您只需刷新搜索数据库中的相关记录即可。

提示：有两个问题决定 RAG 的质量： (1) 您是否找到了正确的文档？ (2) 模型读取正确吗？第一个是“检索质量”，第二个是“生成质量”。两者分别进行衡量和改进。

RAG、微调还是长上下文？

在寻找组织问题的解决方案时，经常会混淆三种路径。让我们澄清一下它们的差异。微调是用您的数据更新模型的权重并教授它新的行为/风格。长上下文意味着将所有文档直接填写到提示中，无需任何选择。

方法

什么是

什么时候合适？

成本/风险

RAG

注入相关文档作为上下文

经常变化、广泛、具体的信息

低；易于更新，可引用来源

微调

使用新数据更新权重

固定风格/格式/语言教学

高；每次更新都需要重新培训

仅长上下文

将所有文档填写到提示中

小型固定文档集

代币成本和“失去中间部分”的风险增加

通常：微调教会模型如何说话； RAG 告诉模型要知道什么。在大多数企业场景中，首先尝试RAG，因为它便宜、可更新、并且可以显示答案的来源。如果文档集确实很小且固定（例如，一本 20 页的手册），那么长上下文是合理的；但对于数千页来说，成本高昂，而且模型可能会错过长文本中间的信息。

典型的 RAG 管道

RAG 包含两个主要阶段：索引（准备，一次或定期完成）和查询（针对每个用户问题运行）。

逐步索引（离线，无需用户等待）：

收集：从来源（PDF、wiki、票证系统、数据库、电子邮件）中提取文档。
分块：将长文本分成更小的易于管理的片段。
Embed：将每个部分转换为嵌入（承载文本含义的数字向量）。
保存：将矢量连同文本和元数据（来源、日期、授权信息）写入矢量数据库。

逐步查询（在线，用户等待时）：

将用户的问题转化为嵌入。
从矢量数据库中检索最相似的部分。
将这些片段+问题放入提示模板中。
从模型中获取上下文答案及其来源。

# 询问阶段的概念大纲（不依赖于语言）question = "有多少天年假？"question_vektor = embed(question)parts = vektor_db.search(question_vektor, top_k=4) # 最相似的 partsprompt = f"""使用下面的上下文回答问题。如果答案不在上下文中，请说“我对此没有任何信息。” Fitting.CONTEXT:{parts}QUESTION: {question}"""answer = model.uret(prompt) # 例如型号：claude-opus-4-8

这个流程就是每个阶段的图，我们会在后续单元中一一解压。

弱提示/强提示

即使具有相同的 RAG 上下文，提示的质量也会改变答案。

弱提示（开放模型拟合，不需要资源）：

使用此信息并说出年假：{parts}。问题：{问题}

强力提示（接地气+“我不知道”权限+资源请求）：

仅根据以下上下文回答。如果上下文中没有明确的答案，请写“我在文档中找不到有关此内容的信息”；别猜了。在答案末尾添加您所依赖的文章的 [Source: file_name] 标签。上下文：{件} 问题：{问题}

三个迷你箱

案例 1 — 人力资源助理（人力资源）。一家公司有一本 340 页的人力资源手册，员工平均每天会问 90 个问题。尝试过微调，但由于手册每月更新，每次都需要重新培训；每个月的费用达到数千美元。改用 RAG 后，更新减少到“重新索引文档”步骤（分钟），手动测量的正确答案率从 71% 提高到 93%。

案例 2 — 客户支持。支持团队拥有 12,000 个已解决的票证和 800 篇帮助文章。代表手动查找答案平均需要 4 分钟。当 RAG 助理带来 5 条最相关的记录并生成回复草案时，时间减少到 40 秒；但该团队意识到“因提交错误的文章而显得不确定”的风险，并强制引用来源。

案例 3——法律。有承包团队询问“哪些合同的保密条款有效期为5年？”他问了这个问题。在长上下文试验中，单个提示中填写了 60 个合同；该模型跳过了中间的两个合同。当仅通过 RAG 引入相关项目时，代币成本降低了 80%，并且重置了缺失的跳过。

为什么需要 RAG？

当前性：您可以在培训截止日期之后访问信息。
特别说明：您的内部文档不包含在任何模型的训练中；只有你能给予。
可验证性：您可以引用答案的来源（引用）——这对于审核和信任至关重要。
幻觉控制：它依赖于放置在其前面的文本而不是构建模型。
成本：投入运行比微调要便宜得多，速度也快。

注意：RAG 不是魔法。如果你输入了错误的部分，模型就会得出错误的答案，看起来“自信”。请记住“检索质量 = RAG 质量”这句话。

常见错误

误认为 RAG 是微调：RAG 不会改变权重；它只是添加上下文。混淆这两者将导致选择错误的架构。
不允许“我不知道”：如果提示让模型可以自由填写空白，它就会弥补。
不引用来源：没有来源的答案无法检查；用户无法注意到该错误。
将所有内容塞进一个提示中：长上下文看起来很便宜，但价格昂贵，并且会错过中间信息。
陷入生成而不测量检索：如果答案不好，首先问“正确的部分到达了吗？”应该问。

综上所述

RAG 是一种将与问题相关的文档作为上下文注入模型的方法；不改变权重（“开卷考试”）。
微调教授风格/格式，RAG 提供当前和具体信息；长上下文适用于小型固定集。在大多数场景中，首先尝试RAG。
该管道有两个阶段：离线索引（分块+嵌入+保存）和在线查询（检索+提示+生成）。
RAG提供及时性、信息具体性、可验证性、幻觉控制和低成本。
系统的质量直接取决于检索的质量：错误的部分意味着错误的答案。

应用任务

从您自己的团队中选择真实的信息来源（例如程序文档或常见问题解答页面）。 (1) 写出 5 个关于该来源的事实问题。 (2) 注意文档的哪一部分包含每个问题的正确答案——这将成为您的“黄金答案”列表。 (3) 使用上面的“强提示”模板，手动粘贴相关部分作为上下文并询问模型。 (4) 将模型给出的答案与黄金答案进行比较，并标记为真/假。这是评估的第一个手动版本，您将在未来的单元中实现自动化。

清单

[ ] 我可以用一句话解释，RAG 不会改变权重，它只是添加上下文。
[ ] 我可以区分 RAG、微调和长上下文以及何时合适。
[ ] 我可以按顺序计算索引（collect-shred-embed-save）和查询（embed-fetch-prompt-generate）阶段。
[ ] 我知道为什么我在提示中添加了“如果不在上下文中，就说我不知道”和“引用来源”说明。
[ ] 我可以将“检索质量= RAG质量”的原则应用到我自己的案例中。