缓存增强生成CAG：用预加载KV缓存突破RAG实时检索瓶颈

检索增强生成已成为大语言模型接入外部知识的主流方案，广泛应用于知识助手、内部搜索工具和客户支持等生产场景。通过从向量数据库检索相关文档并注入提示，RAG让模型能在不重新训练的情况下生成更准确、更及时的回答。

但RAG并非银弹。每次推理前都需要执行检索操作，系统架构复杂，响应延迟随着知识库规模的扩大而显著增长。在时间敏感的应用场景中，这些局限可能成为不可忽视的性能瓶颈。

缓存增强生成提供了一条不同的技术路径。CAG将相关知识预加载到LLM的扩展上下文中，并将预处理好的KV缓存保存下来，推理时直接利用缓存生成回答，彻底省去了实时检索的步骤。对于数据相对固定、更新频率较低的场景，这种方案在速度、可靠性和架构简洁性上展现出了显著优势。

一、RAG在实时检索中的性能瓶颈

RAG通过三个步骤增强大模型的回答能力：检索阶段从向量数据库或搜索引擎返回与查询语义相关的文档；增强阶段将这些文档与用户输入组合；最终将构造好的提示传递给语言模型生成结果。

这套机制在以文档为中心的场景中表现良好，但存在几个系统性缺陷。

首先是实时检索带来的延迟问题。每一次查询都需要执行检索操作，在复杂或多步查询场景中延迟尤为明显。根据实测数据，标准RAG在处理80份以上的文档语料时，首Token延迟会超过200毫秒的服务水平目标，并且随着语料规模的增长呈超线性增长态势。

其次是检索质量影响最终效果。RAG的效果高度依赖检索器能否找到相关且高质量的信息。如果检索到的文档与查询不相关，或检索结果不够精准，最终生成的答案质量就会受到直接影响。检索过程本身存在固有的不准确性，可能导致与问题无关的文档被选入上下文。

第三是系统架构的复杂性。RAG需要开发和维护检索器、向量数据库、文档切分管道等多个额外组件，系统复杂度的增加会拖慢开发进度，也提高了运维成本。

二、CAG的核心机制：用KV缓存替代实时检索

2.1 KV缓存为什么能替代检索

KV缓存是现代大模型推理中的核心机制。在Transformer架构中，每一层注意力机制都会为输入文本生成键和值矩阵，这些矩阵在自回归生成过程中被反复使用。KV缓存将注意力层产生的键和值状态保存下来，避免了在每次生成新token时重新计算它们。

CAG正是基于这一机制提出的增强生成范式。其工作方式是：预先将所有相关知识文档打包成提示，一次性送入模型进行处理。此时，模型为这些知识生成的KV缓存被保存下来，而不产生最终回答。当用户提出问题时，系统直接将预加载的KV缓存与用户查询拼接，模型在已有知识状态的基础上快速生成答案。

在RAG中，知识在每次查询时被动态检索和加载。而在CAG中，知识被提前加载到模型的推理状态中，查询过程完全不需要外部数据获取步骤。这种差异在响应速度上带来了明显区别：CAG的首Token延迟在85到115毫秒之间，且几乎不随知识库规模的增加而显著增长。

2.2 CAG的三个核心优势

基于预加载KV缓存的机制，CAG在多个维度上展现出优于RAG的特性。

响应速度更快。由于省去了实时的检索步骤，CAG的推理速度显著优于RAG。在标准基准测试中，CAG在大型数据集上的推理速度比传统RAG快出近40倍。这对于需要低延迟响应的用户交互场景至关重要。

架构更简洁。CAG不需要构建复杂的检索管道，无需维护向量数据库，也不依赖文档切分和索引构建流程。系统整体复杂度降低，开发和运维成本随之减少。

回答一致性更高。所有回答基于同一份预加载的知识来源，避免了因多源信息冲突可能产生的矛盾答案。在数据相对固定的场景中，这种一致性尤为重要。

2.3 CAG的边界与局限

CAG并非适用于所有场景。其核心局限在于：所有知识必须能够装入模型的上下文窗口。受限于LLM的上下文长度，可预加载的知识量存在上限。知识一旦超出模型窗口就无法使用。

此外，由于知识在推理前就已固定，CAG无法适应需要频繁更新或动态变化的内容。对于新闻资讯、实时数据等场景，RAG的动态检索能力仍然不可或缺。

三、CAG和RAG的效果对比

3.1 基准测试的量化结果

多项研究在不同基准上对CAG和RAG进行了系统性对比。在SQuAD和HotPotQA等广受认可的问答基准测试中，CAG在大部分情况下的表现都优于RAG。在BERTScore准确率指标上，CAG在小、中、大型数据集上均保持了较高的准确率，与RAG相比优势明显。

值得注意的是，CAG在多跳推理任务上面临更大的挑战。在MuSiQue这类需要跨文档推理的组合型问答基准上，CAG比标准RAG低了1.4个F1分数。多跳查询需要模型在多个文档之间进行关联推理，而这种能力往往受益于检索提供的聚焦式上下文。

RAG在事实检索类任务上表现更为突出，在某些评测中展现了约23%的事实正确性提升。这表明CAG与RAG各有擅长的领域，而非简单的优劣关系。

3.2 混合架构的可能

针对CAG在多跳推理等复杂场景下的短板，研究者提出了CAG-RAG混合架构。其核心思路是：对大部分查询使用CAG的预加载缓存快速响应，当查询置信度低于阈值时，系统判断需要外部信息补充，自动切换到实时检索模式。

在混合架构中，一个自适应上下文压缩层可以在不产生统计显著性精度损失的前提下，将预加载文档的KV缓存占用降低30%到45%，从而在有限内存预算内扩展有效的知识规模。实验数据显示，混合架构在所有基准测试上都优于单独的CAG或RAG，在MuSiQue上的提升最为明显，比标准RAG高出5.6个F1分数。

四、CAG的工程实现路径

4.1 以HuggingFace为例的实现步骤

使用HuggingFace Transformers实现CAG的流程相对直接。

第一步是环境准备。安装必要的库并加载模型：

python 复制代码

from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig
from transformers.cache_utils import DynamicCache

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_use_double_quant=True,
    bnb_4bit_quant_type=nf4,
    bnb_4bit_compute_dtype=torch.bfloat16
)

model_id = meta-llama/Meta-Llama-3.1-8B-Instruct
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, quantization_config=bnb_config)

第二步是知识预处理。将所有相关知识文档格式化为提示，一次性通过模型处理，保存生成的KV缓存：

python 复制代码

def preprocess_knowledge(model, tokenizer, prompt: str) -> DynamicCache:
    input_ids = tokenizer.encode(prompt, return_tensors=pt).to(device)
    past_key_values = DynamicCache()
    outputs = model(input_ids=input_ids, past_key_values=past_key_values, use_cache=True)
    return outputs.past_key_values

第三步是推理。保存好预加载的KV缓存后，后续用户查询可直接利用缓存状态进行推理，无需重新处理知识文档。

4.2 实际落地场景建议

CAG最适合企业内部知识问答、标准化流程指引、产品手册查询等场景。在这些场景中，知识内容相对固定，更新频率不高，而对响应速度和结果一致性有较高要求。

在工程设计上，CAG的知识规模受限于模型的上下文窗口大小和内存预算。当前模型如Llama-3.1-8B支持128K上下文窗口，对于中等规模的知识库已经具备可用性。随着上下文窗口的持续扩展，CAG的适用范围还将进一步扩大。

结语

CAG并非RAG的终结者，而是针对特定场景的性能优化方案。它通过预加载KV缓存的方式，消除了实时检索的延迟瓶颈和检索质量的不确定性，在知识相对固定的场景中实现了更快的响应、更简洁的架构和更一致的输出。

对于需要考虑响应时间和系统复杂度的企业级AI应用，在内部知识问答、政策解读、产品指南等知识更新频率低的场景中，CAG提供了一条值得尝试的技术路径。当内容需要频繁更新或动态变化时，RAG的动态检索能力仍不可替代。在可预见的未来，CAG与RAG的混合架构可能成为兼顾速度与准确率的最优解。