一、对比背景：当知识库问答遇到重复访问
在企业知识库、产品手册问答、政策法规咨询等场景中，经常出现大量用户询问高度相似的固定内容，例如“如何重置密码”“退货政策是什么”“API接口调用规范”等。传统做法是每次查询都走完整的检索增强生成（RAG）链路：先向量化资料、建索引，再检索片段，最后拼接上下文交给大模型。然而，当资料固定且高频访问时，重复进行向量检索与上下文构建会造成明显的计算浪费和响应延迟。
于是，一种结合缓存思想的方案进入视野——缓存增强生成（CAG）。它并非要取代RAG，而是与RAG协同，将“高频固定资料”提前处理并缓存，动态或低频资料仍走检索。本文围绕RAG与“RAG+CAG组合”展开对比，厘清二者在架构、性能、适用边界与选型上的实质差异。
二、对象定义：两种技术路径的基本含义
RAG（检索增强生成）
RAG是一种将信息检索与生成模型结合的架构。其核心流程分为离线与在线两个阶段：
- 离线阶段：将文档集合切分为片段，通过嵌入模型转化为向量，建立向量索引（也可同时建立关键词索引）。
- 在线阶段：用户查询到达后，将查询编码为向量（或进行关键词转换），在索引中检索Top-K相关片段，再将片段拼入提示词上下文，交给大模型生成答案。
RAG擅长处理动态变化、规模庞大或长尾化的知识库，能够按需获取最新信息，但每次查询都需完成检索和上下文拼接，存在重复计算。
CAG（缓存增强生成）
CAG指缓存增强生成，其核心思想是提前对高频固定的资料进行预计算，缓存模型处理该资料时产生的键值状态（KV），后续相同或相似前缀的查询可直接复用这部分KV，避免重复处理同一段固定资料。注意，CAG缓存的是“中间计算状态”，并非缓存现成答案，也不是把资料写入模型权重。用户问题仍需实时处理，答案仍由生成模型产出。
三、相同点分析：目标一致，路径互补
虽然RAG与CAG在实现细节上差异明显，但二者存在根本性的共同点：
- 目标一致：都是为了在不更新模型权重的前提下，让生成模型接入外部知识或私有资料，提升回答准确性和时效性。
- 依赖基础模型：两者均以生成式模型为核心，模型的上下文理解与生成能力决定最终答案质量。
- 共同服务“知识增强”：都试图解决“模型不知道私有资料”的问题，只是处理方式不同。
- 可组合使用：在实际系统中，二者并非二选一，而是经常协同——高频固定资料用CAG缓存，动态资料用RAG检索。
四、核心差异分析：从五个维度深入对比
1. 技术架构与计算模式
| 维度 |
RAG |
CAG（与RAG组合） |
| 离线预处理 |
文档切分、嵌入向量化、建立索引 |
对固定资料执行一次前向计算，保存KV缓存 |
| 在线处理 |
查询编码、索引检索、上下文拼接 |
查询直接拼接缓存前缀，跳过固定资料重算 |
| 核心存储 |
向量索引/倒排索引 |
KV缓存存储（内存/磁盘） |
| 计算冗余 |
每次查询重复处理全部上下文 |
固定资料只计算一次，大幅降低冗余 |
论述：RAG的在线流程中，即使固定资料从未改变，每次查询仍需将其从存储中检索出来，并与查询拼接后重新输入模型。对于动辄数千token的固定手册，这部分计算成本线性叠加。而CAG通过预计算KV缓存，将固定资料的“上下文编码”结果保存，新查询只需编码查询部分，再与缓存前缀拼接，显著减少重复计算。
2. 性能表现与资源消耗
- 延迟：CAG在固定资料场景下，因省去固定部分的前向计算，首字延迟通常更低；RAG的检索过程本身具有毫秒级开销，但大上下文处理时间占比更高。
- 吞吐量：CAG缓存占用显存/内存，但带来更高的请求吞吐；RAG则依赖索引检索能力，查询量大时需扩展检索集群。
- 资源均衡：CAG将计算压力转移为存储压力；RAG将存储压力（向量库）与计算压力（模型推理）分离。实际系统需根据既有资源瓶颈选择。
3. 功能能力与使用边界
RAG的优势与边界：
- 适合知识库频繁更新、新增文档场景，无需重新缓存全部资料。
- 擅长处理超大规模语料（百万级文档），因为缓存全部KV不现实。
- 检索可融合关键词、向量、混合搜索，灵活性高。
- 边界：固定高频内容反复检索时，存在计算浪费；上下文长度受限时，拼接大量检索片段可能超出窗口。
CAG（组合方案）的优势与边界：
- 适合内容高度稳定、重复咨询频繁的资料（如FAQ、产品手册、合规文档）。
- 需要预计算与缓存管理，文档更新后需重新生成对应缓存。
- 缓存占用与固定资料大小成正比，超大资料集下成本上升。
- 边界：纯CAG无法处理未缓存的新资料，必须依赖RAG兜底。
4. 安全与一致性控制
- RAG：每一次查询都基于最新索引，数据更新后检索结果即时一致；可通过检索权限控制片段可见性。
- CAG：缓存的是资料处理后的计算状态，一旦资料内容调整，缓存必须同步失效或重建，存在短暂的不一致窗口；权限控制需在缓存生成阶段处理。
5. 运维与成本结构
- RAG运维：需要维护文档管道、向量索引更新、检索服务高可用、索引版本管理。
- CAG运维：需要缓存管理机制（生成、失效、重建、容量监控），同时保留RAG链路以应对动态查询，因此运维复杂度实际上是“1+1”。
- 成本差异：RAG的主要成本在索引存储与检索计算；CAG的增量成本在KV缓存存储（显存/内存昂贵），但省去大量重复计算，在固定资料占比高时综合成本更优。
五、对比表格：关键差异一目了然
| 对比维度 |
RAG（纯检索） |
RAG+CAG（缓存协同） |
| 资料固定性要求 |
无要求，动态亦可 |
固定资料效果最佳 |
| 重复查询计算量 |
每次重复 |
缓存后显著降低 |
| 上下文拼接延迟 |
较高（受检索+编码影响） |
较低（缓存前缀复用） |
| 存储开销 |
向量索引 |
向量索引 + KV缓存 |
| 资料更新便利性 |
更新索引即可 |
需重建缓存 |
| 适用资料规模 |
可扩展至超大规模 |
缓存总量受存储约束 |
| 失败兜底能力 |
具备完整检索能力 |
依赖RAG覆盖新资料 |
| 系统复杂度 |
中等 |
较高（多一套缓存管理） |
六、典型场景选择：什么样的业务更适合哪种方案？
更适合RAG的场景：
- 知识库每天新增或修改大量文档（如新闻资讯、技术社区）。
- 语料规模达千万级，全量缓存不现实。
- 查询内容高度个性化，难以命中固定前缀。
- 对资料实时性要求极高（如即将发布的政策、股票公告）。
更适合RAG+CAG组合的场景：
- 产品操作手册、员工手册、合规条例等“一年改不了几次”的固定资料。
- 支持中心高频重复问答（如“忘记密码”“如何退款”）。
- 面向大并发查询且响应速度要求苛刻的场景，希望通过缓存降低延迟。
- 固定资料约占总体查询覆盖率的60%以上。
混合架构是最常见落地形态：将固定资料前缀缓存为主路径，动态资料走检索为兜底路径，两者通过路由层根据查询内容自动分流。
七、选型建议：中立、条件化的判断
- 先统计查询分布：通过日志分析，统计查询覆盖的文档范围。若Top5%的文档覆盖80%的查询，优先考虑对这些文档启用缓存。
- 评估存储与算力成本：KV缓存需要高速存储（如显存），若固定资料超过可承受容量，则需权衡只缓存最高频的前缀部分。
- 考虑团队运维能力：组合方案意味着多一套缓存生命周期管理，团队能力有限时，可先用纯RAG，待瓶颈明显再逐步引入缓存。
- 明确更新频率：若固定资料允许定期批量更新（如每周一次），则CAG的缓存重建成本可控；若资料每分钟都在变，则缓存收益极低。
八、迁移与使用注意事项
若从纯RAG架构向RAG+CAG组合演进，需重点关注以下风险：
- 缓存失效流程：建立清晰的资料版本管理，内容变更后自动触发缓存重建任务，避免用户读到旧状态。
- 上下文拼接一致性：缓存前缀必须与当前模型的上下文格式严格匹配，模型升级后需重新验证缓存有效性。
- 容量规划：监控KV缓存的内存占用，设置淘汰策略（如LRU）避免OOM。
- 路由逻辑：设计查询分类器，决定请求走缓存路径还是检索路径，避免所有请求都尝试命中缓存导致浪费。
- 回退机制：缓存服务异常时，必须能自动降级为纯RAG模式，保障服务可用性。
- 测试灰度：先在低流量时段启用缓存，对比延迟、准确率、首字时间等指标，确认稳定后再全量推送。
总结
RAG与CAG并非替代关系，而是解决不同侧重点的技术分工。RAG擅长应对动态、庞大、不可预知的知识查询，保证资料的实时性与完整性；CAG则针对高频固定内容进行预计算与复用，显著降低重复计算开销与响应延迟。在实际架构中，将二者结合，让固定资料“缓存化”、动态资料“检索化”，是在知识密集型场景下的务实选择。
选型的核心不在于追逐新概念，而在于分析自身业务中资料的稳定性、查询的重复度、资源成本结构以及团队运维能力。先评估数据分布，再决定是否需要缓存，以及缓存哪部分资料，往往比盲目采用新方案更能解决实际问题。