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

CAG 与 RAGLLM 知识架构怎么选很多团队做 LLM 应用都会撞上同一堵墙模型本身挺聪明但它不了解你的业务。它没读过你的内部制度、产品文档也不知道上周客户到底吐槽了什么。你要做的就是把模型和你的知识接起来。现在主流做法有两类RAGRetrieval-Augmented Generation检索增强生成和 CAGContext-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.338answer 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 加到前面。两条路不冲突能配合。