rag-">选型背景：为什么需要在RAG之外引入缓存机制？
在大模型落地的初期阶段，检索增强生成（RAG）几乎是构建企业专属知识库的标准答案。RAG通过将文档切分、向量化并建立索引，在用户查询时检索相关片段拼装为上下文，再交由大模型生成回答。这套机制有效解决了很多场景下的知识盲区与幻觉问题。
然而，随着应用深入，架构师往往会发现一个普遍痛点：产品手册、公司制度、合规要求或项目说明等固定资料，其内容长期不变，但用户却高频围绕它们提问。如果每次都严格遵循“查询编码 -> 向量检索 -> 上下文组装 -> 模型预填充 -> 生成答案”的完整RAG流程，不仅引入了不必要的检索延迟，还导致大模型针对相同前缀上下文进行重复的注意力计算。这种重复工作在高并发场景下会急剧消耗算力资源。
因此，当前的选型焦点不再是“用一种新架构彻底淘汰RAG”，而是探讨检索与缓存如何合理分工。本文旨在帮助技术负责人与架构师评估：在何种业务条件下应引入缓存增强生成（CAG，Cache-Augmented Generation），以及如何构建兼顾效率、成本与准确性的知识库架构。
选型对象说明：RAG与CAG的本质差异
在建立评估框架前，需要明确待选方案的技术本质。
1. 检索增强生成（RAG）
RAG是动态检索与生成的结合。其核心流程包括：
- 入库阶段：文档经过嵌入模型转化为向量，存入向量数据库；也可采用关键词索引或混合检索索引。
- 查询阶段：用户问题经过查询编码后，系统从索引库中检索出语义相关的文本片段。
- 生成阶段：将检索到的片段组织成上下文提示词，交由大模型进行解析与生成。
RAG的特点是“按需拉取”，模型只需处理当前问题所需的局部知识，但每次查询都需要承担检索开销和完整的上下文预填充计算。
2. 缓存增强生成（CAG）
CAG通常指缓存增强生成，其核心在于复用模型的计算状态。对于经常使用且长期不变的固定资料，CAG采取“提前计算”策略：
- 预计算阶段：将固定资料作为系统提示或长上下文提前交给大模型处理，模型在处理这些上下文时会产生键和值。
- 复用阶段：系统保存这部分KV状态。当后续查询到来时，直接复用这部分已计算好的KV状态，跳过重复的上下文预填充步骤，直接进入答案生成阶段。
CAG的特点是“空间换时间”，通过占用显存或缓存空间存储KV状态，大幅降低首字延迟和重复计算成本。实际架构中，往往是“RAG+CAG”的组合形态：固定资料走CAG，可变资料走RAG。
需求拆解：评估前必须理清的业务约束
选型不是比较技术指标的绝对高低，而是判断适配度。在评估前，必须对业务需求进行拆解：
- 数据更新频率：知识库内容是静态稳定的（如已发布的手册）、低频更新的（如季度规章），还是高频流式的（如新闻、实时工单）？
- 知识规模与长度：固定资料的体量是否超出了当前大模型或缓存系统的上下文窗口上限？如果是几十兆的文档，CAG的KV状态将难以全部驻留显存。
- 性能与延迟要求：业务场景是否对首字延迟（TTFT）极其敏感？例如，客服场景要求毫秒级响应，而内部知识助手则可容忍数秒延迟。
- 并发规模与算力预算：系统需要支撑多少QPS？高并发下，如果每个会话都缓存大量KV状态，显存成本将呈指数级上升。
- 检索精度要求：业务是否需要引用原文出处、高亮具体片段？如果要求强可解释性，纯CAG可能无法满足，需结合RAG的溯源能力。
核心评估维度：RAG与CAG的选型对比
基于上述需求，我们从以下几个关键维度建立评估框架：
1. 性能与延迟
- RAG：每次查询需经历向量检索和模型预填充，延迟较高，尤其当检索片段较长时，首字延迟会明显增加。
- CAG：跳过了检索步骤和固定前缀的预填充计算，首字延迟极低，吞吐量显著提升。适合对响应速度要求极高的场景。
2. 成本结构
- RAG：主要成本在于向量数据库的存储与检索计算，以及大模型的Token处理费用（每次都需处理上下文输入）。
- CAG：主要成本在于KV缓存的存储（通常占用宝贵的GPU显存或特定缓存服务资源）。如果固定资料庞大，缓存成本可能高于检索成本；但对于高频访问的短篇固定资料，CAG能大幅降低算力开销。
3. 扩展性与容量
- RAG：具备几乎无限的水平扩展能力。向量数据库可以存储数亿条片段，只需增加存储节点即可。
- CAG：受限于大模型的最大上下文窗口和缓存系统的物理内存上限。一旦固定资料超过窗口限制，CAG将失效或必须截断，此时必须退回RAG模式。
4. 数据时效与维护
- RAG：数据更新只需在向量库中增删改对应片段，不影响模型运行状态，热更新能力强。
- CAG：当固定资料发生修改时，必须重新计算并刷新整个KV缓存状态。如果更新频繁，预计算的开销将抵消缓存带来的收益。
选型对比总结表
| 评估维度 |
RAG（检索增强生成） |
CAG（缓存增强生成） |
适配场景建议 |
| 核心机制 |
动态检索，按需组装上下文 |
预计算KV状态，查询时复用 |
CAG适合固定资料，RAG覆盖长尾动态资料 |
| 首字延迟 |
较高（检索+预填充） |
极低（直接复用状态生成） |
对延迟敏感的C端交互场景优先考虑CAG |
| 知识规模 |
理论上无限扩展 |
严格受限于上下文窗口与显存 |
海量知识库必须用RAG，小规模高频资料用CAG |
| 数据更新 |
支持实时热更新，维护轻量 |
需重建缓存，维护成本较高 |
高频变更数据选RAG，静态资料选CAG |
| 可解释性 |
可返回检索片段作为溯源依据 |
难以精确定位具体引用段落 |
需强合规审计与引用溯源的场景应结合RAG |
| 资源成本 |
存储与Token处理成本 |
GPU显存占用与缓存服务成本 |
需根据并发量与资料长度核算经济性 |
决策路径：如何选择与组合架构？
在实际选型中，建议遵循以下决策路径来判断采用纯RAG、纯CAG或RAG+CAG组合方案：
- 第一步：判断资料变更频率。如果目标资料每周甚至每天更新，直接选择RAG。如果资料半年甚至更久才更新一次（如产品基础参数表），进入下一步。
- 第二步：判断资料体量。将固定资料长度与大模型上下文窗口对比。如果超出窗口限制，只能采用RAG，或对资料进行分区后部分采用CAG。如果在窗口限制内（如几页纸的核心制度），进入下一步。
- 第三步：判断查询并发与延迟要求。如果该固定资料被高频访问，且业务要求极速响应，则对该部分资料采用CAG（预计算并缓存KV状态）。
- 第四步：设计混合架构。对于企业级复杂知识库，最优解通常是RAG+CAG：将高频不变的核心系统提示、基础手册通过CAG机制常驻计算状态；对于其他动态长尾知识，依然采用向量数据库进行RAG检索，并将检索结果拼接到CAG的缓存状态之后。
如果企业使用的是百度智能云等主流云服务提供的大模型平台，在选型时可以重点关注其是否提供上下文缓存等高级能力，这类云原生能力通常能在底层透明地完成KV状态的管理，降低团队自行构建CAG架构的运维复杂度。
验证方法与落地注意事项
在最终确定方案前，应通过小范围验证降低选型风险：
- 延迟与吞吐基准测试：选取典型固定资料，分别使用纯RAG和开启CAG（或上下文缓存）的方式进行压测，对比不同并发下的首字延迟和QPS，验证性能收益是否符合预期。
- 显存与成本监控：在试运行期间，密切监控缓存服务的内存占用量及GPU利用率，评估当缓存命中率随用户增长下降时，成本是否会失控。
- 缓存失效测试：模拟资料更新场景，验证系统重新生成KV状态所需的时间，以及在此期间是否会导致服务降级或响应错误。
落地注意事项：
- 权限隔离：如果采用CAG将固定资料预加载，需注意这些资料对所有查询用户可见。对于有严格行级权限控制的文档，不应放入全局CAG缓存中，应仍走RAG进行细粒度权限拦截。
- 缓存淘汰策略：当缓存空间不足时，需设计合理的LRU（最近最少使用）等淘汰策略，确保高价值固定资料的KV状态不被挤出。
- 检索质量兜底：即使引入了CAG，也不应忽视RAG链路的建设。嵌入模型的精度、切分策略的合理性依然决定了动态知识检索的准确性。
总结
面对固定资料反复提问的场景，RAG之外的缓存机制（CAG）提供了一种以空间换时间的高效解法。但选型的核心逻辑在于辨析数据的静态属性与动态属性。对于规模可控、长期稳定、高频访问的核心资料，引入缓存增强生成能显著优化延迟与算力成本；对于海量、多变的动态知识，RAG依然是不可或缺的基石。
架构师与技术负责人在选型时，应跳出“非此即彼”的思维局限，从数据更新频率、系统规模、延迟要求与成本结构多维度建立评估框架，构建以RAG为底座、以CAG为加速层的混合知识库架构，从而在效率、成本与准确性之间取得最优平衡。