rag-">固定资料反复问，RAG 之外还能缓存什么？

在知识库问答系统的架构讨论中，检索增强生成（RAG）长期占据主流位置。但当业务中大量问题反复指向同一批固定资料时，单纯依赖每次查询都重新检索、重新组织上下文的做法，会带来明显的重复计算与延迟开销。于是，缓存增强生成（CAG）作为一种补充思路被提出。本文围绕这两种方案展开对比，帮助读者理解它们的核心差异、适用场景与选型逻辑。

需要先澄清一个常见误解：CAG 并不是要取代 RAG，也不是用一个新缩写淘汰所有知识库方案。二者更像是分工不同的两套机制——一个负责“找到资料”，一个负责“复用已算过的资料”。理解这一点，是做出合理架构决策的前提。

一、对比背景：为什么需要区分这两种方案

RAG 的典型流程是：文档经过嵌入模型形成向量并建立索引；查询到来后，系统检索相关片段，组织成上下文，再交给大模型生成答案。这条链路在资料规模大、内容频繁变化的场景下非常有效，但它隐含了一个成本假设：每次提问都值得重新走一遍检索与上下文组装。

现实业务中，这个假设并不总成立。例如产品手册、规章制度、FAQ 标准答案、合同模板说明等资料，长期稳定且被高频反复询问。如果每次提问都重新检索同一批内容，系统就在做大量重复工作。CAG 的思路正是针对这部分“固定资料”做提前计算与状态复用，从而降低重复开销。

因此，本文对比的对象可以明确为：以检索为核心的 RAG 方案，与以固定资料预计算复用为核心的 CAG 方案，以及二者组合使用的形态。

二、对象定义：RAG 与 CAG 分别解决什么问题

RAG（检索增强生成） 的核心是“先找再答”。它通过向量索引、关键词检索或混合搜索等方式，从知识库中定位与查询相关的片段，再把这些片段作为上下文交给大模型。它解决的问题是：模型本身不知道最新或私有知识，需要外部资料动态补充。

CAG（缓存增强生成） 的核心是“先算再复用”。它通常的做法是：提前把经常使用的固定资料交给模型处理，保存对应的 KV 状态（键值缓存），后续查询直接复用这部分计算，而不必重新对同一批资料做前向计算。它解决的问题是：固定资料的重复计算成本高，希望通过缓存换取出更快、更省的响应。

需要注意，图例式的流程简图容易产生两个误会：一是文档一般不需要每次提问都重新生成向量，索引是一次性构建、长期复用的；二是问题通常也要经过查询编码或其他检索处理，而不是原始文字直接与向量比较。这两个细节说明，RAG 本身已经包含了一定的复用设计，CAG 是在此之上进一步把“模型对固定资料的计算”也缓存下来。

三、相同点分析

尽管机制不同，两者在目标和基础逻辑上有明显共性：

• 目标一致：都是为了让大模型在回答时能够利用外部知识，减少幻觉、提升准确性。
• 都依赖资料预处理：RAG 需要嵌入与索引构建，CAG 需要预先对固定资料做模型前向计算并保存状态，二者都不是“零准备”的方案。
• 都面向问答与生成场景：典型落地都是知识库问答、客服助手、文档助手等。
• 都需要考虑资料更新问题：RAG 要处理索引刷新，CAG 要处理缓存失效与重建，二者都存在一致性维护成本。
• 都可与混合检索、权限控制、上下文管理等工程能力配合使用。

四、核心差异分析

1. 技术架构与计算位置

RAG 的计算重心在“检索阶段”，系统边界包括嵌入模型、向量库或搜索索引、上下文组装模块。CAG 的计算重心在“预计算阶段”，系统边界包括模型前向计算、KV 状态存储与复用机制。前者是查询时检索，后者是提前算好、查询时复用。

2. 功能能力与使用限制

RAG 的能力覆盖范围更广，能处理大规模、动态变化、长尾分布的资料；缺点是每次查询都要走检索链路。CAG 擅长高频、固定、相对集中的资料复用；缺点是缓存容量与资料规模受限，资料一旦变化就需要重建缓存，不适合频繁变动的知识源。

3. 接入方式与改造成本

RAG 的接入相对成熟，常见做法是接入嵌入模型、建立索引、改造查询链路。CAG 的接入需要评估模型是否支持 KV 状态保存与复用、缓存存储如何管理、失效策略如何设计，工程改造点集中在预计算与缓存管理层。

4. 性能表现（通用维度）

RAG 的延迟主要来自检索与上下文组装，资料规模增大时检索开销上升，但可通过索引优化、混合搜索缓解。CAG 在缓存命中时能显著减少重复前向计算，首字延迟和吞吐表现通常更优；但缓存未命中或资料更新时，需要回退到重新计算或走 RAG 链路。

5. 安全与合规

两者都需要考虑身份认证、权限控制、数据隔离与审计。RAG 的权限通常作用在检索结果过滤上；CAG 则需要额外关注缓存状态的访问控制，避免不同租户或权限级别的资料在缓存层发生越权复用。

6. 运维成本与成本结构

RAG 的运维重点是索引监控、检索质量评估、容量规划；CAG 的运维重点是缓存命中率监控、失效策略、存储成本与重建开销。成本结构上，RAG 偏向查询时的检索与上下文成本，CAG 偏向预计算与缓存存储成本，需要结合业务查询分布来评估。

7. 适用场景与使用边界

RAG 适合资料规模大、更新频繁、查询分布长尾的场景；CAG 适合固定资料占比高、重复提问密集、对延迟敏感的场景。二者都不适合在资料完全无结构、权限极其复杂且无法预处理的情况下单独使用。

五、对比表格

对比维度	RAG（检索增强生成）	CAG（缓存增强生成）
核心机制	查询时检索相关资料并组装上下文	提前计算固定资料并保存 KV 状态复用
计算位置	检索阶段为主	预计算与缓存阶段为主
资料规模适应性	适合大规模、长尾资料	适合高频、固定、相对集中的资料
资料更新处理	刷新索引即可	需重建或失效缓存
延迟特征	受检索与上下文组装影响	缓存命中时延迟更优
运维重点	索引质量、检索评估	缓存命中率、失效策略、存储
权限控制点	检索结果过滤	缓存状态访问控制与隔离
典型场景	动态知识库、文档问答	固定手册、标准答案、高频 FAQ

六、典型场景选择

• 资料频繁更新、查询分散：优先考虑 RAG，配合关键词与混合搜索提升召回。
• 固定资料占比高、重复提问密集：可在 RAG 基础上引入 CAG，对高频固定资料做预计算缓存。
• 对延迟敏感且资料稳定：CAG 的缓存命中收益更明显，但需设计好未命中回退链路。
• 多租户、权限复杂：无论哪种方案，都要先明确数据隔离边界，CAG 需额外评估缓存层的权限复用风险。

七、选型建议

选型不应做绝对化判断，而应条件化评估：

• 若业务查询分布长尾、资料变化快，RAG 是更稳妥的基础方案；
• 若业务中固定资料反复被问、延迟与计算成本压力明显，可在 RAG 之上叠加 CAG，形成“固定资料先计算、可变资料仍检索”的组合；
• 若团队运维能力有限，应优先评估方案的可观测性与失效处理是否可控，而不是只看理论收益；
• 若缓存存储与权限隔离难以保障，应谨慎引入 CAG，避免一致性或越权问题。

八、迁移与使用注意事项

从纯 RAG 迁移到 RAG+CAG 组合时，需要关注：

• 数据一致性：固定资料变更后缓存如何失效、如何重建，需有明确策略；
• 接口与流程适配：查询链路要增加缓存命中判断与回退逻辑；
• 权限与隔离：缓存状态不能绕过原有权限模型；
• 稳定性与降级：缓存服务异常时应能回退到检索链路；
• 成本评估：预计算与缓存存储成本需要与查询节省做对比；
• 监控告警：缓存命中率、重建耗时、回退比例都应纳入监控。

总结

RAG 与 CAG 并非替代关系，而是分工关系。RAG 解决“资料在哪里、怎么找到”，CAG 解决“固定资料算过一次、能否复用”。理解二者在计算位置、资料适应性、运维重点与权限控制上的差异，结合业务查询分布与资料稳定性做条件化选型，才是合理的架构决策路径。对于固定资料反复问的场景，在 RAG 基础上引入缓存复用，往往比单纯替换方案更务实。