前言
在之前的文章中，我们介绍过RAG相关的内容，这种通过外挂知识库的方式能够有效的更新模型知识，减轻模型幻觉。目前LLM应用的一个发展方向就是RAG。但同时，RAG也会带来一部分挑战：可能会有比较高的检索延迟、选择的文本中可能存在潜在的错误、引入RAG带来的系统复杂度。最近，一篇新的论文《Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks》对此进行了讨论，并提出了一种CAG(Cache-Augmented Generation)的方式来尝试解决。缓存增强生成（CAG）消除了检索延迟并最小化了检索错误，同时保持了上下文相关性。今天我们来看一看这篇论文中的一些先进的解决方案。
思路
利用长上下文大型语言模型的扩展上下文能力，将所有相关资源预加载到LLM的扩展上下文中，并缓存运行时参数。在推理时，模型利用这些预加载的参数来回答查询，从而实现无检索知识集成。
图片取自论文中
整体架构
架构上主要分成三个部分：外部知识预加载、推理和重置。
外部知识预加载
在外部知识预加载阶段，需要将上下文文档集合交给LLM进行处理，编码成KV Cache。这些KV Cache会被用于在推理阶段进行生成。处理之后的计算结果被存储在磁盘或者内存中，以供后续流程使用。
推理
在推理阶段，需要将已经处理好的KV Cache从磁盘加载到内存（如果之前是存在磁盘的话）。之后，利用已有的KV Cache和新的请求进行结合，提交给LLM进行后续的继续生成（即从请求开始继续往后生成KVCache）。当此次请求处理完毕，KVCache的内容变更为新的KVCache。
重置
在处理多个请求时，由于原先的KVCache已经变更，为了获取原先的KVCache，需要对内存中新的KVCache进行截断（论文中认为从磁盘重新加载的成本更高），重置成原来的KVCache，然后和新的请求一起进行进一步的处理。
总结
看论文的时候我的心里是存在一些疑惑的：如何找到每个请求对应的文档？如何确定这些文档对应的相关性顺序？看完之后基本有了答案：这里直接对文档集合按固定的顺序进行编码，后续所有请求用的都是所有文档的信息。这种做法其实相当于引入了大量的无关信息，如果模型能力不行，理论上处理效果应该会更差。并且感觉这种方式更加适合中小型数据集，对于大数据集的应用来说可能效果不一定会更好（有待实践确认）。而针对中小型数据集的话，一个可行的应用方向是个人知识库助手？
另外，处理多个请求的场景下，感觉这里的处理方式有一些串行。如果是面对多个并行的请求，是否将内存中的KVCache复制多份应用于不同请求然后用完丢掉更快一些？当然这么做空间占用会比较大，可能这里还是时间和空间上的权衡吧。
