CAG 与 RAG：LLM 知识架构怎么选？-二趣网

CAG 与 RAG：LLM 知识架构怎么选？

很多团队做 LLM 应用，都会撞上同一堵墙：模型本身挺聪明，但它不了解你的业务。它没读过你的内部制度、产品文档，也不知道上周客户到底吐槽了什么。你要做的，就是把模型和你的知识接起来。

现在主流做法有两类：RAG（Retrieval-Augmented Generation，检索增强生成）和 CAG（Context-Augmented Generation，上下文增强生成）。它们解决的是同一个问题，但走的路完全不同。选对了，系统又快又稳。选错了，延迟、成本、维护复杂度都会上来。

下面把这两套架构拆开讲。

一、RAG 是什么

RAG 的思路很直接：用户提问时，先去外部知识库检索，再把检索到的内容塞进 prompt，让模型基于这些证据回答。

它的流程大致分四步：

入库。文档被切成 chunk，做成向量，存进向量数据库。
检索。用户问题也做 embedding，然后用近似最近邻搜索召回 top-k 个最相关的 chunk。
增强。把这些 chunk 和用户问题一起拼进 prompt。
生成。LLM 基于检索到的上下文生成答案。

RAG 最大的特点是：每次查询都重新检索。知识层不缓存结果。因为每次只加载一小部分知识进上下文，所以它能扩展到非常大的语料库。

RAG 在 2020 年由 Lewis 等人的论文正式提出，之后成了企业级 LLM 落地最主流的模式。知识助手、内部搜索、客服系统，很多都在用。

二、CAG 是什么

CAG 走的是另一条路。它不在查询时检索，而是提前把整个相关知识语料加载进模型的扩展上下文窗口，并在用户提问之前就把 KV Cache 算好。

可以这样理解：RAG 像图书管理员，你每次问问题，他去帮你找书。CAG 像把所有书都摊在桌上，模型已经提前读完了。

CAG 的流程分三个阶段：

预加载。把整理好的文档加载进 LLM 的上下文窗口。
KV Cache 计算。模型为这些预加载内容计算并保存内部注意力状态。这个过程只做一次。
无检索推理。用户查询直接用预加载上下文处理。没有搜索步骤，没有文档选择，也没有检索延迟。

CAG 在 2024 年 12 月 Chan 等人的论文《Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks》之后受到大量关注。真正让它变得可行的，是长上下文模型和 prompt caching 的成本下降。上下文窗口从 400K 到 2M token，缓存读取价格又远低于普通输入，这才让“一次加载，多次复用”有了工程意义。

需要说明的是，CAG 在一些资料里也被叫作 Cache-Augmented Generation。名字不同，核心思路接近：预加载上下文，复用 KV Cache。

三、核心取舍

RAG 每次查几个 chunk。CAG 一次加载整个语料，然后反复用。这个根本差异会影响所有工程指标。

延迟。RAG 每次查询都要加一次检索跳转，通常 100 到 500 毫秒，具体看语料规模和索引硬件。CAG 没有这一步。缓存命中时，响应可以做到亚秒级。有 benchmark 显示，小语料下 CAG 能把 TTFT 降低最多 15 倍。某大学部署切到 CAG 后，响应时间改善了 49%。
成本结构。RAG 每次查询都要付 embedding、rerank 和生成 token 的钱。CAG 前期付一次 cache 写入成本，之后每次读取都吃 cached input 折扣。Anthropic 的 prompt caching 对缓存读取大约收标准输入价的 10%，OpenAI 是 50%。如果查询频率高、语料稳定，摊薄后的成本会低很多。
新鲜度。这是 RAG 的主场。知识库一变，重新索引，查询马上能看到新数据。CAG 的缓存一改就失效，写入成本要重新付。如果文档每小时都更新，CAG 的经济账很难算。
语料规模。RAG 能扩展到数十亿 token。CAG 被模型上下文窗口硬限制。2026 年常见窗口从 GPT-5.1 的 400K 到 Gemini 2.5 的 2M。500K token 的语料已经能覆盖大多数产品知识库、内部制度库和 B2B 客服内容。再大，单靠 CAG 就不行。
检索错误。RAG 容易因为召回错 chunk 导致答案跑偏或幻觉。CAG 直接把完整上下文给模型，绕开了检索这一步。

四、各自适合什么场景

RAG 更适合

知识库又大又动态。金融数据、新闻流、持续更新的商品目录，都需要实时检索。
查询稀疏且不可预测。大多数查询只碰到巨大语料里的一小部分，把全部内容塞进上下文很浪费。
需要引用和可追溯。RAG 天然能给出 chunk 级引用。在受监管行业，你要证明某个结论来自哪份文档，这一点很关键。
多租户环境。不同用户能访问的知识不同。CAG 的共享缓存很难处理这种权限隔离。

CAG 更适合

语料边界清晰且稳定。公司 HR 制度、产品 FAQ、内部 wiki、合规手册，都很适合。
延迟要求高。面向客户的聊天、实时支持、交互式工具，不能每轮都多花 300 毫秒去检索。
查询量高，知识集固定。一次 cache 写入成本可以摊到几千次读取上。
想要架构简单。不需要向量数据库，不需要 embedding 管道，不用调 chunk size，也不用优化 top-k。系统更好搭、好部署、好维护。

五、实际应用场合

企业 HR 与制度助手。把员工手册、福利文档、差旅政策预加载进 CAG。员工问“我们的育儿假怎么休”，能马上拿到一致答案，还不用维护向量库。

客服知识库。客服团队通常围绕一组有限的产品文档、排障指南和 FAQ 工作。CAG 把这些预加载进上下文，客服坐席可以在一秒内拿到答案。有实现的知识包大约 80K token，正好落在 CAG 的甜点区。

端侧教育 and 辅导。树莓派部署可以用 CAG 把一本教材或一份讲义变成可离线查询的知识源，不依赖云。多轮辅导、出题、文档问答都能跑在同一份缓存内容上。

医疗健康助手。个人情绪支持助手会混合使用 RAG 和 CAG。CAG 负责稳定的治疗知识库，RAG 拉取当前用户上下文和近期互动，用来做个性化回复。

网络运维支持。本地 agent 可以用混合 CAG-RAG 路由：CAG 服务高频、范围内的运维查询，把延迟压到最低；RAG 处理新问题，需要明确证据查找。相比纯 RAG，混合方案能明显降低平均延迟和尾延迟。

六、怎么落地

RAG 落地

建一条入库管道，负责切 chunk 和生成向量。
部署向量数据库，比如 Qdrant、Pinecone 或 pgvector。
查询时，先 embed 用户问题，召回 top-k，再拼 prompt。
重点调 chunk size 和 top-k，这两个参数对质量影响最大。
维护重新索引计划，保证向量库不过期。

CAG 落地

整理并预处理知识语料。这里质量更重要，因为所有内容都会进上下文。
把文档加载进模型上下文窗口，触发 prefill 计算。
保存生成的 KV Cache，在多次查询之间复用。
写缓存失效逻辑，源文档变化时要能重建。
可以考虑自适应压缩，把更大的语料塞进有限上下文窗口。

混合模式

大多数生产团队最后用的其实是混合方案：

先用本地 RAG 打基线。
在评估里盯住检索 miss 和延迟模式。
只在领域足够稳定、值得做预整理上下文包的地方引入 CAG。
查询动态路由：高频、范围内的请求走 CAG；新问题、不确定的请求走 RAG。

混合 CAG-RAG 架构相比纯 RAG，通常能拿到 3 到 5 个百分点的 F1 提升，同时让大多数查询保留缓存级延迟。

七、效率对比

首 token 时间。CAG 去掉了检索跳转，小语料下 TTFT 最多降低 15 倍。
端到端延迟。有评估框架发现，原生前缀缓存这种 CAG 风格的做法，把延迟降低了 37.4%，TTFT 降低了 65.7%，faithfulness 没有损失；标准 RAG 则让延迟增加 70.4%，faithfulness 降低 11.6%。
单次查询成本。缓存命中时，CAG 只付 cached input 价格。RAG 每次都要付完整输入 token，还要加上检索基础设施成本。
上下文相关性。一项对比研究里，CAG 的 context relevancy 是 0.338，answer relevancy 是 0.709，超过 Adaptive-RAG 的 0.334 和 0.613。而且 CAG 用的是轻量统计路由，不需要额外 LLM 做决策。

CAG 的效率优势很真实，但它有硬边界。超过上下文窗口限制后，CAG 会快速退化。所以混合方案才会成为生产标准。

八、怎么选

可以问自己几个问题：

知识库有多大？低于 500K token 且稳定，CAG 很值得考虑。几百万 token 还在涨，RAG 是底座。
内容多久变一次？每周或更久才更新，CAG 的缓存经济性很好。每小时都在变，还是 RAG。
延迟预算紧不紧？要求亚秒级响应，就更偏向 CAG。
需要 chunk 级引用吗？RAG 天然有。CAG 要做细粒度归因，得额外花功夫。
查询可预测吗？如果一小批查询占了大部分流量，CAG 的摊薄成本优势会非常明显。

答案很少是“只选一个”。现在效果最好的团队，通常都在做混合路由：稳定、高频的查询交给 CAG，其余走 RAG。架构也在往这个方向走，效率提升会在这里叠加。

先上 RAG，把基线跑通。测出哪些查询最热、哪些内容最稳，再把 CAG 加到前面。两条路不冲突，能配合。

企业官网建设流程全解析