老胡茶室
老胡茶室

LLM 外部知识集成架构策略：RAG 和 CAG 的比较分析

胡键
#ai #deep-report #agent #rag

Disclaimer: this is a report generated with my tool: https://github.com/DTeam-Top/tsw-cli. See it as an experiment not a formal research, 😄。

摘要

本报告对将外部知识集成到大型语言模型 (LLM) 应用程序中的两种主要架构模式进行了比较分析：检索增强生成 (RAG) 和缓存增强生成 (CAG)。RAG 是更成熟的方法，擅长通过检索机制处理大量、动态和多源数据语料库，尽管引入了潜在的延迟和复杂性。CAG，通常被称为“长文本”或预加载上下文，利用了 LLM 上下文窗口和 KV 缓存的不断增长的大小和效率，通过将静态、可管理的数据集直接预加载到模型的活动上下文或缓存中。这种方法提供了显著更低的查询时间延迟和潜在的实现简单性，但从根本上受到 LLM 的上下文窗口容量的限制，并且不太适合高度易变或非常大的数据集。RAG 和 CAG 之间的最佳选择，或混合架构的设计，关键取决于知识库的特征（大小、易变性）、性能要求（延迟容忍度、吞吐量）、操作复杂性和可用的 LLM 功能（上下文窗口大小、KV 缓存效率）。

引言

大型语言模型的有效性和事实准确性通过其访问和整合超出其原始训练数据的信息的能力而得到显著增强。这种必要性出现是因为训练数据是静态的，通常会过时，并且很少包含许多企业应用程序所需的特定领域或专有知识。已经出现了两种突出的架构范式来应对这一挑战：检索增强生成 (RAG) 和缓存增强生成 (CAG)。

RAG 的运行方式是基于用户查询动态查询外部知识库（通常是索引数据），检索相关片段，并将这些片段添加到 LLM 的提示词中。然后，模型生成一个以原始查询和检索到的上下文为条件的响应。这种方法对于处理大量且频繁更新的信息非常有效。

相比之下，CAG 涉及将外部知识直接预加载到 LLM 的输入上下文中，或者更有效地，在初始设置或预热阶段利用模型的键值 (KV) 缓存机制。这有效地使外部知识成为模型在推理期间的“活动记忆”的一部分，避免了 RAG 中固有的每次查询检索步骤。随着支持极大上下文窗口的 LLM 的出现，这种方法特别有吸引力。

本报告系统地比较了 RAG 和 CAG 的各个维度，包括性能、可扩展性、数据处理能力、复杂性和最佳用例，并借鉴了该领域最近的讨论和分析。研究方法主要包括综合提供的学习要点中的见解，并将其与参考文献进行交叉引用，以构建对每种方法的机制、优势、局限性和权衡的全面理解。

检索增强生成 (RAG)

RAG 是一种广泛采用的框架，它通过从外部知识库检索相关文档或数据片段来增强 LLM 的生成过程。这种机制解决了 LLM 的静态训练数据和参数记忆的局限性。

机制

核心 RAG 流程通常包括：

  1. 索引： 处理外部知识语料库，通常将其分块为更小、语义上有意义的单元，并嵌入到向量空间中。这些向量嵌入存储在向量数据库或索引中。
  2. 检索： 收到用户查询后，该查询也会嵌入到同一向量空间中。对索引嵌入执行相似性搜索，以检索最相关的文档块。
  3. 增强： 检索到的文档块与原始用户查询组合以形成增强的提示词。
  4. 生成： 增强的提示词被馈送到 LLM 中，LLM 生成一个以查询和检索到的上下文为条件的响应。

高级 RAG 实现可能涉及复杂的检索策略（例如，混合搜索、重新排序、提示词重写）和生成技术（例如，在增强数据上微调 LLM，基于源出处控制生成）。

主要发现和分析

  • 处理大型动态数据： RAG 本质上是为大型知识库设计的。索引机制允许从远远超过任何 LLM 上下文窗口容量的语料库中进行高效存储和检索。无需重新训练甚至重新启动 LLM 推理服务即可更新知识库（通过索引新的或修改的文档）的能力使 RAG 成为动态信息的理想选择。
  • 多源能力： 只要可以索引和检索，RAG 就可以轻松地集成来自不同来源（数据库、文档、API）的信息。
  • 可解释性和信任： 通过呈现检索到的来源以及生成的响应，RAG 提供了一定程度的可解释性，允许用户验证 LLM 输出的事实依据。
  • 延迟： RAG 的主要缺点是检索步骤引入的固有延迟。对于每个查询，系统都必须执行数据库查找（通常是向量相似性搜索），这与所有必要信息都已位于 LLM 活动上下文中的情况相比，增加了显著的延迟。这种延迟可能会因索引的大小和性能以及检索查询的复杂性而异。
  • 复杂性： 构建和维护强大的 RAG 系统涉及管理索引流程、检索服务、向量数据库，并确保整个工作流程中的数据一致性和质量。这增加了运营开销。
  • 检索质量依赖性： 生成响应的质量在很大程度上取决于检索到的文档的质量和相关性。糟糕的索引、无效的分块或次优的检索算法可能会导致向 LLM 提供不相关或不充分的上下文，从而导致不准确或幻觉输出。

建议措施

  • 对于需要访问大型（> 上下文窗口容量）和/或频繁更新的知识库的应用程序，RAG 是默认且最具可扩展性的方法。
  • 优化检索流程（索引、分块、嵌入模型、向量数据库调整、重新排序）以最大限度地减少延迟并最大限度地提高检索相关性。
  • 实施来源归属和验证策略以利用 RAG 的可解释性优势。
  • 考虑对高度重复的查询采用并行检索或缓存检索结果等技术，以减轻延迟。

风险和挑战

  • 性能瓶颈： 在高查询负载下，检索步骤可能会成为瓶颈，需要为向量数据库和检索服务提供强大的基础设施。
  • 成本： 维护索引流程、存储（向量数据库）和检索基础设施可能成本高昂。
  • 检索相关性漂移： 随着知识库的发展或用户查询模式的变化，初始索引和检索策略的有效性可能会降低，需要监控和潜在的更新。
  • 数据新鲜度与延迟： 虽然 RAG 可以处理动态数据，但实现实时新鲜度取决于索引流程的速度，这增加了复杂性。

缓存增强生成 (CAG)

缓存增强生成 (CAG)，通常被概念化为利用“长文本”或预加载上下文，将外部知识直接放置在 LLM 的工作记忆中——通过将其包含在非常长的输入提示词中，或者更有效地，通过在初始设置或预热阶段预先计算和缓存 LLM 的 KV 缓存中外部知识令牌的键值状态。

机制

核心 CAG 概念包括：

  1. 预处理： 准备外部知识（假设为相对稳定且在容量限制内）。这可能涉及令牌化和潜在的结构化。
  2. 预加载/缓存： 处理后的知识可以是：
    • 包含在初始提示词中作为前缀（由于注意力复杂性，对于非常长的文本效率较低）。
    • 由 LLM 处理一次以计算和存储其 KV 缓存条目。后续查询可以重用这些缓存的 KV 状态。这是对“缓存增强生成”的更高级和性能更高的解释。
  3. 生成： LLM 处理用户查询，现在 LLM 的注意力机制或 KV 缓存中有效地提供了外部知识。模型利用此预加载的知识生成响应，而无需每次查询都进行外部检索步骤。

这种机制在很大程度上依赖于 LLM 有效处理长上下文的能力，无论是在处理复杂性（通常是二次或接近线性的注意力机制）方面，还是在有效利用分布在长上下文窗口中的信息的能力方面。专门利用 KV 缓存来缓存外部知识是实现初始缓存预热后显著加速的关键技术。

主要发现和分析

  • 更低的延迟： CAG 的主要优势在于消除了每次查询的检索步骤。一旦加载了知识（在上下文或 KV 缓存中），就可以以最小的延迟进行生成，与 RAG 相比，可能提供显著更快的响应时间。
  • 潜在的简单性（在某些情况下）： 如果知识库足够小且静态，可以舒适地容纳在上下文窗口中，则基本的 CAG 实现可能比设置具有索引和检索基础设施的完整 RAG 流程更简单。利用 KV 缓存增加了复杂性，但提高了性能。
  • 利用大型上下文窗口： CAG 特别相关且强大，尤其是在支持非常大的上下文窗口（例如，>100k 个令牌）的 LLM 出现之后。这些模型理论上可以在其工作记忆中直接保存大量信息。
  • 静态/可管理数据的更高准确性： 一些实验表明，对于静态、可管理的数据集，CAG 在准确性方面可以优于 RAG，因为 LLM 可以同时获得整个相关上下文，而不是依赖于可能不完善的块检索。该模型可以跨整个预加载的知识建立联系并综合信息。
  • 上下文窗口限制： CAG 最显著的限制是 LLM 的有限上下文窗口大小。可以有效预加载的外部知识量受到此容量的严格限制。纯 CAG 方法对于非常大的知识库是不可行的。
  • 数据易变性约束： CAG 最适合静态或不经常更新的知识。对预加载的知识的任何更改都需要重新处理和重新缓存，这可能会造成中断并增加动态数据的复杂性。
  • 模型依赖性： CAG 的性能和可行性高度依赖于特定 LLM 的架构、其上下文窗口大小及其处理长上下文或利用 KV 缓存的效率。并非所有模型都同样适用。

建议措施

  • 对于知识库相对静态、大小可管理（在 LLM 的有效上下文容量内）且低查询时间延迟是关键要求的应用程序，请评估 CAG。
  • 使用 CAG 时，优先考虑具有大型且有效实现的上下文窗口和 KV 缓存功能的 LLM。
  • 当底层数据发生变化时，实施一个强大的流程来更新缓存的知识，并考虑开销和潜在的中断。
  • 如果总语料库略微超过上下文窗口，请仔细地对知识进行分段或优先级排序，或者探索混合方法。

风险和挑战

  • 上下文过载/稀释： 即使使用大型上下文窗口，在相关知识旁边塞入太多不相关的信息也可能会稀释 LLM 的注意力，并导致性能或准确性下降（“迷失在中间”现象）。
  • 长上下文处理的成本： 虽然查询时间更快，但长上下文的初始处理或 KV 缓存步骤可能计算成本很高。
  • 知识更新开销： 管理对缓存知识的更新，即使对于适度动态的数据，也可能变得复杂，可能需要缓存失效和重新处理策略。
  • 数据量可扩展性有限： 从根本上来说，无法扩展到明显大于最大有效上下文窗口大小的知识库。

比较分析：RAG vs. CAG

特征检索增强生成 (RAG)缓存增强生成 (CAG)注释
数据大小可扩展到非常大的语料库（TB 级以上）受 LLM 上下文窗口/KV 缓存容量的限制RAG 可扩展到数据量，CAG 可扩展到上下文的数据密度。
数据易变性非常适合动态、频繁更新的数据最适合静态或不经常更新的数据更新需要重新索引 (RAG) 与重新缓存/重新提示 (CAG)。
查询延迟由于每次查询的实时检索而增加延迟设置后延迟更低；知识已预加载/缓存对于延迟敏感的应用程序，性能差异显著。
查询速度由于检索步骤而较慢初始加载/缓存后生成速度更快“速度”指标取决于包含的内容（设置与每次查询）。
设置复杂性较高（索引流程、数据库、检索服务）对于简单情况可能较低；对于 KV 缓存较高KV 缓存需要更高级的 LLM 交互和管理。
运营开销显著（监控索引、检索、数据库）对于静态数据较低；如果频繁更新缓存则较高取决于数据动态。
可扩展性（数据）优秀对于大型语料库较差对于海量数据量，RAG 是明显的赢家。
可扩展性（查询）可能是检索层的瓶颈；需要分布式数据库LLM 推理可扩展，但初始加载/缓存可能无法很好地并行化取决于基础设施和具体实现。
对 LLM 的依赖较少依赖于极端的上下文长度；依赖于提示词的生成高度依赖于大型、高效的上下文窗口和 KV 缓存模型选择对于 CAG 的可行性和性能至关重要。
知识集成通过提示词中检索到的片段通过直接上下文包含或缓存的 KV 状态CAG 将知识更根本地集成到模型的“状态”中。
每次查询的知识范围受检索结果的限制可能是整个预加载的语料库如果有效预加载，CAG 可以利用更广泛的上下文。
可解释性通过来源归属很容易更具挑战性，除非构建自定义机制RAG 在这方面具有内置优势。
错误模式检索不佳、不相关的上下文、幻觉上下文过载、信息稀释、缓存过时、上下文窗口限制基于机制的不同故障点。

建议措施

  • 数据特征化： 在 RAG 和 CAG（或混合方法）之间进行选择的主要因素必须是对知识库的大小、易变性和增长率进行彻底分析。
  • 性能要求： 量化可接受的查询延迟和吞吐量。对于具有静态数据的低延迟、高 QPS 场景，CAG 是首选。如果检索延迟对于数据规模是可以接受的，则 RAG 是必需的。
  • 基础设施和运营能力： 评估团队构建、部署和维护复杂的 RAG 流程与管理与 LLM 的大型上下文/KV 缓存交互的能力。
  • LLM 能力评估： 验证所选 LLM 是否具有足够大且性能良好的上下文窗口和 KV 缓存机制，以支持用于预期数据量的 CAG。

风险和挑战

  • 次优选择： 基于对数据特征或性能需求的不充分理解而选择错误的架构将导致糟糕的系统性能、可扩展性问题或过高的成本。
  • 低估 CAG 的复杂性： 虽然概念上很简单，但利用 KV 缓存的高效 CAG 是一项先进的技术，需要深入了解 LLM 内部结构和基础设施。
  • 供应商/模型锁定： 过度依赖特定 LLM 的大型上下文窗口进行 CAG 可能会导致对该模型提供商的依赖。

混合方法

认识到检索增强生成 (RAG) 和缓存增强生成 (CAG) 的互补优势和劣势，混合架构正成为一个有前景的方向。这些方法旨在结合 RAG 的可扩展性和动态数据处理能力与 CAG 的低延迟和潜在的准确性优势。

机制

混合模型可以有多种表现形式：

  1. CAG 用于核心知识，RAG 用于更新/边缘情况：使用 CAG/KV 缓存预加载一个稳定的核心知识集，以便低延迟地访问常用信息。对于不太常见的查询、尚未缓存的最新更新或位于非常大或动态源中的信息，则使用 RAG。
  2. 分层知识：使用 CAG 缓存知识库的摘要或更高级别的索引，并使用此缓存的概述来告知和指导后续的 RAG 步骤以进行详细检索。
  3. 检索增强缓存：最初使用类似 RAG 的检索步骤来识别潜在大型知识库中与特定用户会话或上下文最相关的部分，然后使用 CAG/KV 缓存为该会话中的后续查询缓存这些特定部分。
  4. 组合提示词：虽然不如 KV 缓存有效，但混合方法可能涉及在同一提示词中组合一个长的静态上下文（CAG 部分）和动态检索的片段（RAG 部分）。

主要发现与分析

  • 平衡权衡：混合方法有潜力平衡 RAG 的可扩展性和 CAG 的速度，从而解决纯粹实现的局限性。
  • 复杂性增加：设计和实现混合系统本质上比纯粹的 RAG 或 CAG 系统更复杂，需要协调多个组件和策略。
  • 优化挑战：优化混合系统涉及调整检索和缓存机制，以及决定何时使用哪种机制或如何组合其输出的逻辑。

建议措施

  • 当面临既庞大又包含大量稳定、频繁访问数据的知识库，或者当核心功能对低延迟至关重要但总体数据量需要 RAG 时，请探索混合架构。
  • 仔细建模数据访问模式和波动性，以确定缓存层和检索层之间知识的最佳划分。
  • 为特定用例原型化不同的混合策略，以评估性能和复杂性之间的权衡。

风险与挑战

  • 系统集成：集成和协调 RAG 和 CAG 组件会增加显著的架构和工程复杂性。
  • 缓存一致性和陈旧性：管理更新并确保缓存知识（CAG）和动态知识库（RAG）之间的一致性具有挑战性。
  • 成本增加：混合系统可能会产生与 RAG 基础设施相关的成本，以及处理更长上下文或管理 CAG 的 KV 缓存可能导致更高的计算成本。

适用性和用例

RAG、CAG 或混合方法之间的选择高度依赖于具体的应用需求。

  • RAG 通常更适用于：
    • 拥有庞大且不断变化的文档的企业知识管理系统。
    • 需要访问实时信息（例如，新闻、市场数据）的聊天机器人或应用程序。
    • 需要高透明度和来源归属的应用程序。
    • 知识库太大，即使是最大的可用上下文窗口也无法容纳的情况。
  • CAG 是以下情况的有力候选者：
    • 拥有相对较小、静态、特定领域的知识库的应用程序（例如，产品手册、特定团队的内部策略文档）。
    • 查询延迟极低的场景（例如，实时对话式人工智能、特定类型的专家系统）。
    • 优化针对稳定数据集的频繁查询的性能。
    • 利用具有巨大上下文容量的最先进的大型语言模型的全部潜力来完成专注的任务。
  • 混合方法适用于：
    • 同时包含稳定核心知识和动态更新的企业应用程序。
    • 需要快速访问常用信息并能够搜索庞大的长尾知识库的系统。
    • 尝试缓解频繁查询的 RAG 延迟，同时保持其对整个语料库的可扩展性。

洞察

大型语言模型 (LLM) 的外部知识集成领域正在发展，不再仅仅是 RAG 与微调之间的简单争论。CAG 提供了一种可行的替代方案，尤其是在 LLM 上下文窗口大小和 KV 缓存管理方面取得进展的支持下。核心权衡在于 RAG 的数据可扩展性、动态处理和可解释性与 CAG 在其约束范围内潜在的更低查询延迟和可能更高的准确性之间的权衡。

架构师和开发人员的决策矩阵必须考虑：

  1. 知识库特征：大小、波动性、结构和更新频率至关重要。
  2. 性能要求：目标延迟、吞吐量以及可接受的设置时间与查询时间。
  3. 运营和开发开销：构建和维护基础设施的复杂性。
  4. 可用 LLM 能力：候选模型的有效且高效的上下文窗口大小和 KV 缓存功能。

推测而言，随着 LLM 上下文窗口持续增大且上下文处理变得更加高效，CAG 可以管理的“可管理”数据范围将扩大。然而，上下文窗口不太可能完全涵盖典型企业知识库的规模，这确保了 RAG 在大型和动态数据方面的持续相关性。混合架构通过结合两种范式的优势，代表了未来发展的一个复杂方向，可以基于知识库不同部分的具体特征和不同的性能要求进行细粒度的优化。“长文本”增强的概念正在从仅仅附加长提示词转变为利用 LLM 通过 KV 缓存进行的内部状态表示等更先进的技术。

结论

检索增强生成 (RAG) 和缓存增强生成 (CAG) 代表了使用外部知识增强 LLM 的两种根本不同的方法。RAG 是一种鲁棒、可扩展的解决方案，适用于大型、动态和多源知识库，它依赖于外部检索，但代价是查询延迟。CAG 或预加载上下文/KV 缓存通过利用 LLM 的内部上下文容量，为静态、可管理的数据集提供了显著更低的查询延迟和可能更高的准确性，但受限于上下文窗口大小和数据波动性。

最佳的架构选择并非通用，而是关键取决于应用程序的特定需求，特别是知识库的性质和性能要求。混合架构提供了一条有希望的前进道路，使开发人员能够结合 RAG 的可扩展性和 CAG 的性能优势，尽管复杂性有所增加。随着 LLM 技术的进步，CAG 的能力和适用性将扩大，这需要不断评估这些架构模式，以设计有效且高效的 LLM 驱动的系统。

References

Report generated by TSW-X Advanced Research Systems Division Date: 2025-05-16