很多情况下，我们需要使用LLM对长文本进行处理，比如超长的聊天记录、几个小时的会议纪要或者一本书的提炼总结。但受限于LLM的上下文窗口和费用问题，我们往往希望能把刚刚好足够的上下文传给LLM，使其能完成期望的任务。OpenAI的ChatGPT plus就提供了记住历史对话的功能。想象一下，如果是一个AI助理能记住你所有说过的话，总能在你需要的时候，做成符合需求的响应，感受还是非常棒的。本文我们讨论一下LLM对长文本进行处理方法，以及MemGPT核心Memory是怎么实现的，不足之处，欢迎留言指正。
01
—
MemGPT是什么
MemGPT（Memory GPT）是一个开源项目，https://github.com/cpacker/MemGPT，由加州大学伯克利分校的研究团队开发。旨在智能管理大型语言模型（LLM）中的不同记忆层级，以有效扩展模型的上下文窗口。MemGPT参考计算机内存管理的原理，采用了虚拟上下文管理技术，通过在快速和慢速内存之间移动数据，使其能够处理长篇对话、分析复杂文档，并跨多个信息源进行操作。核心功能包括：
长期记忆/状态管理：MemGPT能够为LLM代理提供长期记忆和状态管理功能，使其能够处理长篇对话和复杂文档。
自编辑记忆：该系统支持自编辑记忆，允许模型根据当前上下文更新和搜索其记忆。
无限上下文窗口：通过智能分析文档的结构和内容，MemGPT能够识别关键信息和上下文，从而有效地扩展了LLM的上下文窗口。
外部数据连接：MemGPT可以连接到外部数据源（如RAG），并定义和调用自定义工具（函数）。
02
—
长文本总结的方法
虽然越来越多的LLM支持更大的上下文窗口，108K已经是很多LLM的常规操作，但更大的窗口必然需要更大的算力，很可能也是更多的费用。LLM支持更大的上下文窗口也有很多的研究，这里我们就不讨论了，虽然我也很好奇他们是怎么做到成本和体验的平衡的。在应用层面管理上下文，常用的方式就是压缩，把长文本变短，主要分为两个阶段，分块和总结。LangChain封装了一个类ConversationSummaryBufferMemory，用于处理长对话的Memory。实现的逻辑，
判断当前的对话历史长度 + SystemPrompt 的Token数是否超过LLM的窗口限制。
否，则把所有的内容当上下文发给LLM。
是，则会把多出来的历史对话剪裁出来，在用另外一个对话对剪裁出来的对话，进行总结压缩，再把压缩后的内容作为上下文内容的一部分，一起发给LLM。
每次重复第前3步，把已经存在的总结 + 新剪裁出来的对话，生成新的总结。
除此之外，对于长文本总结，还有一些方法
Map-Reduce，这个很好理解，就是一个分布式处理的概念，把长文本切分成多个分块，对每个分块进行总结，再对所有的总结进行总结。
Refine，把长文本切分成多个分块，顺序对每个分块进行总结，每次都把之前的总结带入到上下文中。这种方式优点是，每个分块的总结都不是完全独立的，而是结合了上面分块总结的信息，缺点是不能像Map-Reduce那样并行处理。
Clustering，适合处理大量的问题或客服聊天记录，通过把内容分块进行聚类，总结每个聚类，再汇总做最终总结。
这些方法在处理长文本上都有优缺点和适用场景，只能算的上是一些基础的方法，在实际的业务流程中做参考。
03
—
MemGPT的工作原理
主上下文（Main Context）：这是LLMs用于处理当前任务的“工作”区域，相当于操作系统中的物理内存。它包含当前活跃的对话或文档分析任务所需的信息。 外部上下文（External Context）：这是超出主上下文大小限制的所有信息的存储区域，相当于操作系统中的虚拟内存或磁盘存储，包括Archival Storage和Recall Storage。 分页操作：当主上下文中的信息超过LLM的上下文窗口限制时，MemGPT会执行分页操作，即将一些不活跃或较旧的信息“换出”到外部上下文中，从而为新的或更重要的信息腾出空间。 数据检索：当需要之前被换出的信息时，MemGPT会执行“分页入”操作，即从外部上下文中检索所需的数据，并将其放回主上下文中。 队列管理器（Queue Manager）：负责管理FIFO队列和召回存储中的消息，控制上下文溢出，并通过队列驱逐策略来管理主上下文中的空间。 功能执行器（Function Executor）：解释LLM生成的输出字符串作为函数调用，执行数据在主上下文和外部上下文之间的移动。
#基于信息相关性搜索def text_search(self, query_string, count=None, start=None):results = self.storage.query_text(query_string, count, start)results_json = [message.to_openai_dict_search_results() for message in results]return results_json, len(results)#基于信息时间新鲜度搜索def date_search(self, start_date, end_date, count=None, start=None):results = self.storage.query_date(start_date, end_date, count, start)results_json = [message.to_openai_dict_search_results() for message in results]return results_json, len(results)
MemGPT可以进行迭代检索，当一个查询需要多个步骤或涉及多个文档时，系统会逐步检索和分析信息，直到找到答案。在更复杂的任务中，如嵌套的键值检索（nested key-value retrieval），MemGPT可能需要执行多跳检索，即从一个文档中检索到的信息将作为下一个检索的起点。
04
—
跟RAG对比
内存管理：MemGPT特别强调内存管理，模仿操作系统的内存层次结构和分页机制。RAG则侧重于检索和生成的集成，而不特别强调内存管理。 架构：MemGPT引入了一个更为复杂的多层次内存架构，而RAG通常依赖于检索器和生成器的直接集成。 控制流：MemGPT具有基于事件的控制流，可以响应各种输入并触发LLM的推理。RAG的控制流通常与检索和生成过程紧密集成。 自指导能力：MemGPT提供了自指导编辑和检索的能力，而RAG则侧重于检索器与生成器之间的协作。 应用场景：MemGPT的设计使其更适合处理长对话和长文档分析任务，而RAG则更通用，适用于需要检索和生成结合的各种任务。
05
—
MemGPT的局限性
为了实现自动化能力让其功能更强大，不可避免的，设计就会变得比较复杂。这些限制了其通用性和灵活性，如果你的业务场景跟MemGPT非常贴合，那使用它肯定会节省大量的开发工作量。但如果需要修改才能用，那需要详细阅读源码，修改的工作量也不小。比如就我自己而言，我只需要MemGPT对内存管理的部分，能让我自定义内存分页的策略，那不得不深入到源码。性能开销，由于动态内存管理可能影响响应时间和处理速度，同时复杂的处理过程会产生额外的Token开销，好在现在LLM的接口费用是越来越低。
