融合𝗥𝗔𝗚 (检索增强生成) 和𝗖𝗔𝗚 (缓存增强生成) - 𝗖𝗥𝗔𝗚 。您如何从中受益？ 最近，一种名为 CAG 的技术引起了广泛关注。虽然它本身就很强大，但真正的魔力在于将 CAG 与常规 RAG 结合起来。让我们看看它会是什么样子，以及应该考虑哪些其他因素。 以下是实现 CAG + RAG 架构的示例步骤： 𝘋𝘢𝘵𝘢 𝘗𝘳𝘦𝘱𝘳𝘰𝘤𝘦𝘴𝘴𝘪𝘯𝘨 ： 𝟭 。我们仅使用很少变化的数据源进行缓存增强生成。除了数据很少变化的要求之外，我们还应该考虑哪些源经常被相关查询命中。一旦我们掌握了这些信息，我们才会将所有选定的数据预先计算到 LLM 的 KV 缓存中。将其缓存在内存中。这只需要执行一次，以下步骤可以多次运行，而无需重新计算初始缓存。 𝟮对于 RAG，如有必要，预先计算并将向量嵌入存储在兼容数据库中，以便在步骤 4 中进行搜索。有时更简单的数据类型对于 RAG 来说就足够了，常规数据库可能就足够了。 𝘘𝘶𝘦𝘳𝘺 𝘗𝘢𝘵𝘩 ： 我们现在可以利用预处理后的数据。 𝟯 . 编写一个提示，包括用户查询和系统提示，并说明 LLM 应如何使用缓存上下文和检索到的外部上下文。 𝟰 . 嵌入用户查询，用于通过向量数据库进行语义搜索，并查询上下文存储以检索相关数据。如果不需要语义搜索，请查询其他来源，如实时数据库或网络。 𝟱 . 利用步骤 4 中检索到的外部上下文来丰富最后的提示。 𝟲 .将最终答案返回给用户。 𝘚𝘰𝘮𝘦 𝘊𝘰𝘯𝘴𝘪𝘥𝘦𝘳𝘢𝘵𝘪𝘰𝘯𝘴 ： ➡️上下文窗口不是无限的，即使某些模型拥有巨大的上下文窗口大小，但大海捞针问题尚未解决，因此请明智地使用可用的上下文并仅缓存真正需要的数据。 ✅对于某些业务案例，将特定数据集作为缓存传递给模型非常有价值。想象一下，一个助手必须始终遵守存储在多个文档中的一长串内部规则。 ✅虽然 CAG 最近才开始在开源中流行起来，但它已经通过 OpenAI 和 Anthropic API 中的 Prompt Caching 功能实现了一段时间。在那里开始原型设计真的很容易。 ✅您应该始终分离热数据源和冷数据源，仅在缓存中使用冷数据（很少更改的数据），否则数据将变得陈旧并且应用程序将不同步。 ❌请非常小心您缓存的内容，因为所有用户都可以查询这些数据。 ❌除非您有一个具有每个角色自己的缓存的单独模型，否则很难确保缓存数据的 RBAC。 您已经使用过 CAG 和 RAG 的融合吗？请在评论中告诉我您的结果👇 LLM AI MachineLearning编程严选网
