关于记忆系统的一些思考

最近在搞LLM(Large Language Model,大语言模型)相关的开发，在开发过程中遇到一些问题，不是很想得通，记录下来给未来的自己看。
以下内容不一定完全正确，我的个人理解存在许多局限性，如有错漏，还请海涵。

每天都想变得更厉害，做更多对社会有意义的事情。

LLM的记忆

在正文的最开始，要先说明LLM对话的实现。

我们在调用API的时候发生了什么事

• 在API后面挂着的LLM只保留着训练数据中包含信息，其它更新鲜的知识是一概不知道的。当然，也有些供应商的API后面还挂着知识库，这个我们在下文来讨论。
• LLM和用户唯一的交互就是上下文(Context)，上下文是由很多条Message依序拼接而成的，每条Message中包含着多模态的Content。
• 你在对话框里面输入的提示词(Prompt)、上传的图片等，都属于Content。Content带上发送者的角色(Role, 比如system、user、assistant)等信息，就构成了Message。
• 本质上LLM是对Context进行计算，根据预设的参数，作出相应的响应，然后以流式或者非流式的方式从API里返回给客户端，然后再由客户端作出一系列的处理。

那LLM是怎么知道原有知识以外的信息

答案是：他不知道，全靠你告诉他。你可以通过提示词或者Tools的方式传递给他，然后他在输出的时候会附带上引用的来源(可选实现)。
你可以通过在提示词里注入或者让它使用tool_calls调用工具返回信息。

为什么要记忆系统

LLM不知道你的对话历史，它只能看到一坨被堆叠到一起的上下文。而上下文是有长度限制的，比如DeepSeek V4系列的限制是1M tokens，有些更小的比如32K、128K，总之就是有个上限，你没办法把所有的内容都塞进上下文里面，过长的上下文也会导致推理的时间和占用的资源暴涨。
那怎么办？只有天知道这个时候记忆系统就可以派上用场了。

短期记忆

最简单的实现方式就是滑动窗口法，只记录最近几条Message。

• 好处是简单粗暴有效，能适应绝大多数聊天场景，毕竟不是谁都喜欢煲电话粥。能有效节省上下文空间以及减少Tokens的消耗，而且在对话的流畅性上也不会损失太多。
• 坏处是鱼的记忆，讲两句就啥也不知道了，对于我这种喜欢叨逼叨的来说很难受，总不能老是往事重提，很是消耗精力。

那还有没有救呢？有的！还是有的。这个时候就可以使用总结大法了，通过把被截掉的部分进行总结，并塞到系统提示词(System Prompt)或者别的什么地方，就能非常轻松的实现记忆了。

• 好处是非常容易实现，在总结字数有限的情况下也能有很不错的记忆效果。
• 坏处是会破坏缓存(Cache)的实现，在一些处理不是很好的后端，比如说被我诟病无数次的某某某，会导致输入缓存命中率大幅下降甚至无法命中缓存，使得账单迅速膨胀。而且上下文总结可能需额外调用LLM来进行处理，最后的效果也未必尽如人意。

不过在我看来，单会话的聊天场景直接全塞上下文的效果是挺好的，你聊个一个多小时也就一两百万Tokens毛毛雨了。

中期记忆

比如说你要实现一个项目，期间你可能要有多次的会话，你不能读到隔壁会话的内容，这时候就需要跨会话的记忆，我这里称之为中期记忆。
在一些智能体(Agent)的实现里，可以把会话总结到文档里，比如以Markdown的形式，你在那个会话里让LLM根据当前会话内容，总结到对应的文档里面。这样就可以非常简单的实现跨会话的信息传递和记忆实现。
但是在群聊场景下这个就有点复杂了，因为你可能会面对多个用户发来的消息，但是在上下文里面都是以user角色(Role)的Message存在的，还得作区分。

长期记忆

在多个项目之间总结技术栈、技术路线，或者建立用户画像，就需要建立长期记忆。

记忆系统的实现

这个没啥好讲的，为啥呢？现在的技术框架日新月异，你可能刚刚想到一套方案搞完，隔天就有人提出更优的方案，你又得改。这玩意儿紧跟行业潮流就完事了，市面上这么多框架，一个个试下来，总有一个适合你，就算不适合你，在你思考哪里有问题的时候，就会有新方案提出来了，最后总结归纳，说不定你又能自己搞一个方案出来。
如果真想做的话，还不如直接问LLM来得实在。

记忆系统的局限性

在上面的讨论中，已经提到过了，上下文的空间是有限制的，你的钱包也是有限制的，所以势必要对记忆进行优中选优，精挑细选，而且还要照顾到缓存命中率。这就给记忆系统的实现带来很多挑战了。

• 记忆塞在哪里？要既能保证LLM能理解到这个是记忆，又要保证上下文中重复的内容要精确命中缓存，毕竟不是哪一家都像DeepSeek那样，把缓存做到极致，甚至连Claude Code的随机插入字符串(如何修复Claude Code给第三方大模型用户挖的坑)都能在后端优化掉，以提升缓存命中率，比某某某厂商强太多了。
• 留多少近期对话？
• 记忆要提取哪些相关信息？什么才是相关信息？相关信息的相关信息要不要也放进来？
• 总结要总结到什么程度？多模态信息要不要也总结上？
• ……

这些种种问题都是你在设计或者部署记忆系统的时候会遇到的。最终还是以实际生产环境效果为准。
不管你在网上查多少资料，都不如在业务场景多试试。

记忆系统存在的必要性

为什么会出现记忆系统，主要还是因为LLM没有自我学习的能力，只能靠微调等方式让它继续学习新知识。
但是LLM的自我学习的能力真的是我们想要的吗？这样会不会带来伦理问题，甚至安全问题？这个我是持有怀疑态度的。
而且这样也会带来十年前的AI比如微软小冰等曾遇到的问题，“模型投毒”。
用户的输入不一定都是高质量的，甚至是有毒的。你要是说在前面加一道审核机制。拜托，要是真的有用，网上就不会那么多啥比发言了，每天看啥比已经够力竭的了，别让我还要对着LLM力竭，比如什么包，我肯定不会用的。
根据前人的经验，LLM训练的样本质量的重要程度远大于数量，所以自我学习这条路还是有限制的。所以现在都还是采用外挂知识库等方式进行知识的补充了，然后就涉及到RAG(Retrieval-Augmented Generation, 检索增强生成)，把知识向量化，然后再根据LLM的实际需求提取对应的向量发送给LLM，也存在很多局限性。
不过现有的记忆系统方案在我的开发工作流中已经很够用了，因为真正调配知识的人，还是用户本身。起码现在用户还是有不可替代的作用。
那未来呢？未来又会是什么样子？只有天知道