原创 孔某人 2025-01-15 14:15 北京
下一步的Memory能力提升会来自于模型层
TL;DR：下一步的Memory能力提升会来自于模型层。
0、前言
最近一段时间我也并没有在思考Memory或者Long Context相关的内容，但前一阵被人问了这方面的问题。所以就来谈下目前我对应用层需要的Memory相关技术的发展预判。
首先还是名词解释：并没有一种具体的技术叫做LLM应用的Memory，它跟Agent一样是一类很模糊很模糊的概念，某种意义上它描述的是一种理想，而不是某种已经达到60分的技术方案。
1、回顾过去的Memory发展
目前实现Memory的方式大概有几种类型的方案：
完全依靠Long Context
BabyAGI（2023.4）的Memory
针对场景设计的半结构化Memory
狭义的RAG类方案
以上这几种方案的边界并不是非常明确的，其中后3种再更抽象的意义来看是一大类的。
这4类思路其实在1.5年之前就已经有了，过去的1.5年中并没有明显的发展。要说的可能也就是RAG方面的GraphRAG作为一个有些独特性的方案是新的。
在Long Context方面，在2024年1月（也就是一年前）大家就已经基本实现了128k context，一些1M context也已经宣发。但一年过去了，大部分模型也仍然只有128-200k context的水平。只有Gemini仍然坚守前沿模型1-2M context的能力。
当然也不是完全没有新的可能性，真正能够长期记忆并能内化的方案大概只有AlphaProof使用的方式，但这种方式目前对于应用层来说成本还太高。
某种意义上，可以说2024年的Memory是一潭死水，至少从公开的方案来说是这样的。可能会有一些团队会在本文评论区宣称自己实现什么什么NB的方式，但我对此都表示怀疑。
2、最可能的增长点
本节开始讨论对未来的预测，首先这个预测是对于未来中短期的，大概1-2年尺度。再远我就感觉很难看清了。
预测需要基于一些条件和判断，本文的预测基于以下基础判断：
应用层对于Memory的新尝试已经陷入泥潭，前进缓慢，愿意大量投入研发的团队也很少。
模型层总体仍然在发展，并且由于多模态模型、推理模型和对Agent应用场景的重视，模型层后续会更加重视在long context上的投入。
模型层已经普及的Context Cache已经可以视为一种粗糙的Memory方案。
人和组织几乎都会沿着其最舒适的路径前进。
据我推断，未来下一步最可能的增长点来自于：模型层在Long Context方面的能力的进一步发展，以及Cache Context方面的进一步成本优化和功能拓展。
Long Context方面的能力提升是目前看起来最能被有效分摊成本的路线，特别是一些模型层重视的其他需要Long Context的功能会支撑模型层在这方面继续投入和竞争。
Context Cache已经事实上成为了一种更符合大家对于Memory（相对于Long Context）更低成本的期望，目前只是这个Cache的成本和延迟降低并不能保证一定命中。
应用层在Context之上还能做一些工作，但这方面的工作很难继续推进。特别是在通用场景方面，适合应用层能做的事情很有限。而且这方面的积累大概率会随着模型层能力的提升而被颠覆，这更加削减了应用层在这方面的投入意愿。
我目前对那些面向通用场景Memory的中间件层方案并不看好，这方面产品也并不多。我并没有去具体调研他们，这只是我的偏见，也没有看到他们在业内被广泛传播和推荐。
在这些条件下，我觉得2025年的局面就已经基本确定了，甚至2026年大概率也会如此。
3、模型层的Memory优化思路
我已经不关注LLM模型层的技术细节挺久了，所以并不能确认本节的判断都是适合的，我尽量谈一些能够普适各种架构方案的思路。
首先从视角来看，Memory仍然是一种Context，考虑到实际应用需求，它是一种Long Context，而且很多场景会明显长于目前的1M context，我估计模型层大概需要以10-100M context为目标。
但Memory确实还有一些普通Long Context没有的独特需求：
比请求新prompt时明显更低的成本，包括推理成本、Cache存储成本、延迟等。
能够在请求时组合多块Memory，而不是像现在Context Cache一样只能匹配完全相同的prompt前缀。
较低的Memory局部更新成本。这方面的具体应用方式还有些模糊。
对于Memory内的新信息能够更加泛化地应用，举一反三。
目前的Context Cache方案我认为是一个合适的Memory优化起点，它的一个最大问题是，KV Cache的成本很高。虽然已经有了DeepSeek MLA这样的方案来降低Cache成本，但幅度距离应用的需求还远远不够。我猜目前这方面做得最好的仍然是Gemini，但我无法猜测它的具体实现方式。
Cache方案的下一步突破我认为是有损地保留部分信息，实现O(Sqrt(L))甚至O(Log(L))的存储复杂度，其中L是输入prompt的token长度。并不是所有token的信息量都是一样的，很多内容的主要信息其实并不多。
但这里的一个问题是：如何“选择”哪些token/信息是应该重点保留的，哪些不是。但很遗憾，这是无法对于一般场景都有效实现的。这个问题不止对于模型层存在，在应用层一样存在。如果要记忆的数据是一篇文章，且要保持任何对于原文章的query都能在其存储之后被准确还原，那么最小存储成本的方案几乎就是完整存储该文章本身。当然还可以套一层无损压缩算法，但我们几乎无法从中丢弃任何信息，任何信息都可能被某个query使用。
模型层适合做的是通用方案，不适合对于具体场景进行特化，那么它必然要存储所有原始信息作为最差情况的兜底策略，但确实有可能做出某种高熵信息选择方案，构造出1级甚至多级的Cache来满足大部分常见情况的请求。如果能够确定被忽略的信息的总影响也不会影响到当前输出的token，那么就可以忽略那些信息。毕竟token是一种离散化的表达方式，影响低于一定水平后，就不再回影响token输出。
实际上我们还可以更进一步，让用户来提供一些示例query，来更准确地判断哪些信息需要保留在较高的cache层级，哪些可以放在较低的cache层级中。具体就是看这些query在计算中主要依赖哪些信息，那么这些信息都应该被优先保留。
关于Memory组合的问题，这方面模型层的同学应该能够自己设计出不少方案，这里就从略。简单介绍一种思路作为baseline：调整position mask，让各个Memory块之间不是相互可见的，各个Memory的耦合计算在这些Memory之后的token上进行。
A、结语
本次的文章就到此为止了。
一方面是给应用层的同学一个展望，或者说抛一个视角，该如何考虑自己的架构设计和模型层的未来演化。避免被未来的泥头车碾过。
另外一方面，也是给模型层的同学整理一下需求信息，疏通一下模型层和应用层之间的信息交流。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，获取联系方式请点击 -> 联系方式。
本文于2025.1.13首发于微信公众号和知乎，知乎链接：
https://zhuanlan.zhihu.com/p/18414341439
