Django 框架创始人：LLM 本质上是无状态函数，并非真正有记忆

框架的创始人之一、著名开发者最近发表了一篇博客文章，核心观点是——虽然很多LLM看起来有记忆，但本质上是无状态函数。

文章地址：

和的联合创始人、发明者也在推特上称赞这篇博客。

似乎有记忆的LLM

从计算机科学的角度来看，最好将LLM的推理过程视为无状态函数调用——给定输入文本，它会输出接下来应该做什么。

然而使用过或者的人会明显感觉到，LLM似乎可以记住之前的对话内容，好像模型有记忆能力。

然而这并不能归功于模型本身。

事实上，用户每次提出一个问题时，模型收到的提示都会包含之前所有的对话内容，这些提示就是我们经常说的「上下文」。

如果不提供上下文，LLM将完全不知道之前讨论的内容。

所以，重新打开一个对话界面时，对LLM而言就是一个「从头再来」的全新文本序列，完全独立于你和其他用户之前发生的对话。

从另一个角度看，这种「失忆」也有好处。比如，模型开始胡说八道，或者拒绝回答你的合理问题时，就可以试试重置对话窗口。也许在新的对话中，模型的输出就能回到正轨。

这也是为什么LLM的上下文长度是一个重要的指标。如果对话过长、超出了上下文窗口，最早的那部分对话就会从提示中移除，看起来就像是模型的「遗忘」。

将上下文窗口准确地形容为「LLM工作记忆的有限宝贵资源」。

但是，有很多方法可以为LLM外置记忆能力，来满足产品使用的需求。

将之前的对话作为提示，和当前问题一起输入给LLM是最直接的方法，但这依旧是「短期记忆」，而且扩展模型的上下文长度成本很高。

GPT-4o免费版支持8k上下文，付费版可以达到128k，已经比之前的32k提升了3倍，但仍然无法保存单个网页的原始HTML。

也可以递归地总结之前的对话内容，将历史对话摘要当作LLM提示。虽然可能会丢失细节，但相比直接截断的方法，更高程度上保留了内容的完整性。

另一种方法是外接矢量数据库，为LLM添加「长期记忆」。

在进行对话时，先从数据库中检索相关内容，再将其添加进上下文窗口，也就是检索增强生成（RAG）。

但如果数据库内容过多，检索过程很可能增加模型的响应延迟。

实际开发中，检索、摘要这两种手段常常搭配使用，以求在成本和性能、长期和短期记忆之间取得平衡。

推理无法记忆，但训练可以

LLM的推理过程虽然等效于「无状态函数」，但训练过程并不是这样，否则它也无法从语料中学习到任何知识。

但我们对于LLM记忆的分歧之处在于，它到底是用「机械」的方式复制了训练数据，还是更像人类的学习过程，用理解、概括的方式将数据内容集成在参数中。

近期发表的一篇论文或许可以从另一个角度揭示这个问题。

论文地址：

他们使用与训练语料相似的攻击LLM，看它能否逐字逐句地输出训练数据。

但、Llama、这种常用的半开放LLM，以及GPT系列都没有公开训练数据，要怎么判断模型的输出是否包括在训练集中？

论文使用了一种巧妙的方法进行判断：首先，从、、Pile等常用的LLM预训练数据集中选取了9TB的文本作为辅助数据集。

如果模型输出的文本序列足够长、信息熵又足够大，而且还和辅助数据集内容重合，那么基本可以断定模型在训练时见过这条数据。

这样的判断方法会存在假阴性，因为辅助数据集不可能涵盖所有模型的训练数据，但几乎没有假阳性，因此得到的结果可以作为模型「复现」训练内容的比例下界。

结果发现，所有的模型都能逐字逐句地输出训练数据，只是概率有所差异。

从结果可以发现，参数量越大的模型似乎记住的内容越多，越有可能在输出中让训练数据回流。

不同系列的模型之间差异比较显著。比如7B参数的相比，有将近10倍的概率原样吐出训练数据。

但可能的原因有很多，既能解释为模型记忆能力的差距，也能归因于为辅助数据集的偏差。

有趣的是，如果的要求是一直持续输出某个单词，有些单词更有可能触发模型吐出训练数据。

最有效的一个单词是「」

作者指出，从安全的角度来看，这说明对齐过程没有完全模糊模型的记忆，这些可提取的训练数据会带来版权纠纷与隐私泄露问题。

但从另一个角度来看，这证明，一定比例的训练数据被无损压缩而且存储在了模型参数中。模型的记忆方式，果然是有些「机械化」的成分。

更进一步思考，如果改进LLM的记忆方式，让训练数据以更概括、更抽象的方式存储在参数中，能否带来模型能力的持续提升？

参考资料：

@/how--fools-us-into--were--a--