原贴链接

看到关于‘CAG’的东西，心想看看是什么新鲜玩意儿……这不一样，这将改变现状。有个GitHub（我与之无关联）已经有解决方案了，是hhhuang/CAG。也已经有关于4位优化、模型和系统级优化的研究。我很兴奋，也许我能让它在我的手机上高效运行。祝好。

讨论总结

原帖宣称CAG将改变事物，引发众多评论。评论者从不同角度探讨CAG，包括其技术实现（如对KV缓存的预处理）、优势（如检索优势、特定场景下的性能优势）、局限性（如存储和I/O限制、运行模式的问题、大小限制），还将其与其他模型（如RAG）进行对比，也有部分评论者对原帖标题表述不满，还有很多人对CAG能否像原帖所说的那样改变事物持怀疑态度。

主要观点

1. 👍 CAG的实现是对KV缓存用文档预处理，并非新奇。
   • 支持理由：llama.cpp已有相关未被充分利用的功能，评论者自己的应用也有类似功能。
   • 反对声音：无。
2. 🔥 CAG在文档大小有限时是较好的方法。
   • 正方观点：原帖相关内容中的关键句子表明这点，适用于小型/本地应用。
   • 反方观点：无。
3. 💡 CAG目前使用时存在运行模式相关的问题。
   • 解释：要么本地运行，要么每条消息要发送数兆字节数据，Deepseek自动缓存每次需发送整个上下文。
4. 🤔 CAG在特定模型执行特定任务且需特定信息时有价值。
   • 解释：如预计算系统提示、从预计算文档提取信息等场景，但在特定用例之外用处不大。
5. 😕 对原帖标题使用“is all you need”的表述反对。
   • 解释：认为标题不应采用这种夸大的表述方式。

金句与有趣评论

1. “😂 The tl;dr is to preprocess the KV cache with a document.”
   • 亮点：简洁概括CAG的实现方式。
2. “🤔 The key sentence in the abstract: “when the documents are of a limited size”. Still, seems like a better approach for smaller/local apps. TY for sharing”
   • 亮点：指出CAG在文档大小有限时适用于小型/本地应用。
3. “👀 This is way, way better than RAG for model coherence and retrieval.”
   • 亮点：强调CAG在模型连贯性和检索方面比RAG好。
4. “😒 Stop with the “is all you need” titles!”
   • 亮点：表达对标题表述的不满。
5. “🤨 It’s basically just “stuff everything into the context window, but faster”.”
   • 亮点：对CAG改变事物的说法表示质疑。

情感分析

总体情感倾向较为复杂。一部分评论者对CAG表示看好，认为它具有一定的优势和价值，有积极的情感倾向。但也有很多评论者持怀疑态度，对原帖中CAG将改变事物的说法不认同，还有部分评论者对原帖标题表述不满。主要分歧点在于CAG是否真的像原帖宣称的那样有重大意义和影响力。可能的原因是原帖的表述较为夸张，而评论者基于自己对CAG的理解和过往类似事物的经验进行判断。

趋势与预测

• 新兴话题：CAG与混合RAG的比较可能成为新兴话题，因为已有评论者提出想看到两者的比较。
• 潜在影响：如果CAG真的如看好它的评论者所说具有众多优势，可能会对模型优化、本地应用等相关领域产生积极影响，推动技术朝着更高效、性能更好的方向发展；如果CAG被证明没有那么大的价值，可能会让人们对类似宣称改变一切的新技术更加谨慎对待。

详细内容：

标题：CAG——是变革还是噱头？

近日，Reddit 上一则关于“CAG”的帖子引发了热烈讨论。该帖子提到“CAG 将要改变一切”，并附上了相关链接https://arxiv.org/abs/2412.15605，还提到了已有的解决方案 hhhuang/CAG 等，吸引了众多网友的关注和参与，目前已有大量评论。

讨论的焦点主要集中在 CAG 的原理、优势、局限性以及与其他相关技术的比较等方面。有人指出，CAG 的关键在于使用预处理器处理 KV 缓存，例如 llama.cpp 已具备导入和导出 KV 缓存的功能，但存储 KV 缓存需要大量空间且受 I/O 限制。

有用户分享道：“CAG 检索是基于上下文的，能充分利用 LLM 的能力进行推断和模式匹配，更接近让模型在你的数据上进行训练。”但也有人认为，CAG 与直接将整个文档粘贴到聊天中让 LLM 处理并无太大区别，只是建议在上下文长度大幅增加的情况下，直接将文档放入上下文并保存预处理的 KV。

对于 CAG 的性能表现，有人通过数据对比指出：

不过，也有人认为 0.826 的 SQuAD 分数并不令人印象深刻。

关于 CAG 的应用，有人认为在特定场景下很有用，比如已知模型要执行特定任务且始终需要某些信息时。但也有人质疑，认为 CAG 目前存在一些问题，比如对于本地运行或消息传输，可能需要发送几兆字节的数据，存在大小约束。

尽管有人对 CAG 充满期待，认为这是未来的发展方向，因为它性能更好，能解决 RAG 的复杂和错误问题，还有很大的优化空间。但也有人对此持谨慎态度，认为每周都有人声称某些技术会改变一切，但真正做到的很少。

总之，关于 CAG 的讨论呈现出观点的多样性和复杂性。它究竟是引领未来的变革性技术，还是仅仅是一时的噱头，还有待时间和更多实践的检验。