SAG、RAG、CAG：大模型获取外部知识的三种策略

大模型的知识截止于训练数据。GPT-4 不知道昨天的新闻，你公司内部的客服文档它也没见过。要让模型回答训练数据之外的问题，必须给它一个获取外部知识的机制。

SAG、RAG、CAG 是当前三种主流的外部知识接入方式。它们共享同一个目标——让模型”看到”它原本不知道的信息——但实现路径和适用场景差异很大。这篇文章面向刚接触这个概念的人，把三种策略的工作原理、关键差异和选择逻辑讲清楚。

先把问题说清楚：模型为什么不直接”记住”新知识#

一个直观的想法是：既然模型不知道新信息，那就训练它、微调它，让模型自己记住。这条路对于”改变模型的风格和行为”是有效的，但对于”让模型知道新事实”有两个根本问题。

第一，成本。每次有新信息都要重新微调，对大多数场景来说不现实。第二，可靠性。微调本质上是让模型学会一种模式，而不是精确存储事实。模型可能在微调后”大概知道”某个知识点，但在关键细节上仍然出错。

外部知识接入的思路是：不试图让模型记住所有信息，而是在需要的时候把相关信息”递到面前”。模型只负责阅读和理解——知识存储和检索交给外部系统。

可以把模型理解为一个阅读理解能力很强的人，但不给它带参考书进考场。RAG、CAG、SAG 是三种不同的”递小抄”策略。

RAG：先检索，再生成#

RAG（Retrieval-Augmented Generation，检索增强生成）是目前最主流的外部知识方案。它的工作流程可以分为准备阶段和查询阶段。

准备阶段做的是”把知识库变成可检索的格式”。具体步骤：把文档切成小块（chunking）→ 用嵌入模型把每个 chunk 转成向量（embedding）→ 存到向量数据库里。向量之间可以根据语义相似度做近邻搜索——“苹果公司”和”Apple Inc.”在向量空间里会很近，即使字面上完全不同。

查询阶段做的是”找到相关内容再回答”。用户提问 → 同样转成向量 → 在向量库里找到最相似的几个 chunk → 把这些 chunk 和用户问题一起塞进 prompt → 模型基于参考资料生成回答。

用一个场景来理解：你有一份 200 页的产品手册，想用 AI 回答用户问题。你不能每次都把 200 页全部塞进 prompt（太贵太慢），RAG 的做法是先判断”这个问题大概跟手册里哪几段相关”，只把最相关的段落给模型看，让模型根据它们作答。

RAG 的优点是经过了两三年的工业验证，工具链成熟（LangChain、LlamaIndex、各类向量数据库），对知识库规模和查询类型的适应范围最广。代价是架构复杂——需要维护嵌入 pipeline、向量数据库、检索策略和重排序模块，任何一个环节出问题都会影响最终效果。

CAG：把检索步骤省掉#

CAG（Cache-Augmented Generation，缓存增强生成）是 2024 年底从一篇论文开始引起关注的替代方案。论文标题很直接：《Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks》。

CAG 的思路是：如果知识库本身不大，为什么不全部塞进上下文窗口？长上下文模型（128K、1M token）的出现让这件事成为可能。CAG 把所有相关文档一次性预加载到模型里，预先算好 KV cache，查询时直接从缓存中推理，完全跳过检索步骤。

这样做有三个好处。第一，速度快——省掉了检索环节（向量搜索 + 重排序），在基准测试中比 RAG 快 40 倍以上。第二，不会出现”检索错误”——RAG 的一个常见失败模式是检索到了看起来相关但其实不对的文档片段，CAG 直接让模型看到全部信息，不存在检索偏差。第三，架构简单——不需要向量数据库、嵌入模型、chunking 策略这些组件。

但它的限制同样明确：知识库必须能塞进上下文窗口。假设你的产品手册有 500 页、几十万字，CAG 就不适用了。即使模型支持 1M token 的上下文，把所有文档每次都塞进去，推理成本会大幅上升。

CAG 适合的场景是：知识量有限（比如一个 FAQ 页面、几十份产品说明）、查询模式重复（大部分用户问类似的问题）、对速度敏感（客服场景要求秒回）。

值得补充的是，CAG 不是一个”取代 RAG”的方案。论文的标题带着一点论战的姿态，但实际应用中更常见的选择是混合模式：高频查询走缓存（CAG），低频或未命中时回退到检索（RAG）。

SAG：去网页上现搜#

SAG（Search-Augmented Generation，搜索增强生成）的检索源和 RAG 不同。RAG 的数据源是你自己准备的知识库——内部的 PDF、文档、数据库。SAG 的数据源是整个互联网——它调用搜索引擎 API（Google、Bing 等），实时抓取搜索结果页面，把相关内容喂给模型。

这使得 SAG 天然适合需要最新信息的场景：今天的股票价格、刚发布的政策变动、正在进行的体育比赛。因为知识库不需要提前准备，SAG 也适合长尾问题——用户问了一个冷门话题，你的内部文档库里没有相关内容，但互联网上可能有人讨论过。

SAG 的流程和 RAG 类似但更复杂一些：判断问题是否需要搜索 → 提取关键词 → 调用搜索 API → 抓取结果页 → 从 HTML 中提取正文 → 重排序 → 拼入 prompt → 模型生成回答。每一步都引入了新的不确定性：搜索关键词提取不准怎么办？抓取的页面质量太低怎么办？搜索引擎本身的排序偏差会影响结果怎么办？

SAG 还有一个 RAG 没有的优势：可验证性。RAG 的检索来源是内部文档，用户看不到原始资料，只能选择是否信任系统的回答。SAG 引用的是公开 URL，用户可以直接点击验证。“我不确定这个回答对不对，点一下链接看看原文”——这种体验在 AI 产品中越来越重要。

代价也很直接：延迟更高（搜索请求 + HTML 解析的时间）、结果不可复现（同样的查询两次可能返回不同结果，因为网页内容变了）、以及对外部搜索 API 的依赖。

一张表看清三种策略#

实际选择往往是混合的#

这三种策略在实践中不是非此即彼的关系。一个成熟的知识增强系统通常会组合使用它们。

最常见的模式是分层路由：先判断用户问的是什么类型的问题。高频、知识域固定、速度要求高的问题走 CAG（“退货政策是什么”——答案基本不变，每天被问几百次）。需要内部文档但查询模式不可预测的问题走 RAG（“上季度的销售报告里提到了哪些竞品”）。涉及最新信息或内部知识库没有覆盖的问题走 SAG（“昨天的产品发布会在业内引起了什么反应”）。

更深的一层是，三种策略可以互为 fallback。CAG 未命中 → RAG 检索 → RAG 返回的片段置信度太低 → 触发 SAG 去互联网上补充信息。这种链式 fallback 的设计在要求高可用性的生产系统中越来越常见。

最后#

对于刚开始接触外部知识增强的人，一个实用的入门路径是：先用 RAG 理解”检索 → 增强 → 生成”的基本范式，因为它的工具链最成熟、参考资料最多。然后自然会遇到两个延伸问题——“能不能更快？“（引向 CAG）和”能不能获取实时信息？“（引向 SAG）。

三种策略的边界也正在模糊。长上下文模型越来越便宜，CAG 的适用范围在扩大。RAG 系统越来越多地集成实时搜索作为补充能力。SAG 也在吸收缓存机制来降低延迟。从”选哪个”到”怎么组合”，这个问题的答案在持续变化。