为长期运行代理构建上下文修剪管道
本文介绍了如何为长期运行的AI代理实现上下文修剪管道,通过语义相似度动态管理对话记忆,降低成本并提高效率。涵盖了使用句子变换器嵌入模型计算相似度、构建修剪后的上下文窗口等步骤。
在大型语言模型(LLM)基础上构建的现代AI代理被设计为持续运行。因此,它们的对话历史会无限增长。将整个历史作为LLM的上下文窗口会导致高昂的令牌成本、延迟瓶颈以及推理能力的下降。构建一个上下文修剪管道可以通过动态管理近期对话记忆来解决这一问题。本文介绍了实现长期运行代理上下文修剪管道的基本原则,并使用完全可访问且免费运行的本地解决方案,基于开源嵌入模型而非付费API。
提出的记忆策略
经典的代理记忆策略依赖于滑动窗口,会遗忘旧信息,包括可能关键的细节。超越这一方法,可以构建一个选择性、更智能的管道,为LLM提供恰好所需的上下文。本质上,上下文可以被修剪为以下基本元素:当前提示(包含用户的请求或问题)、最近一轮对话(即上一轮输入-输出交换,对保持对话连续性至关重要)、以及基于相似度分数的Top-K语义相关匹配(通过向量嵌入检索与当前提示密切相关的历史轮次)。对话历史中不属于这三者的内容将从活动提示的上下文中丢弃,从而节省计算和内存。
基于模拟的实现
我们的示例实现逐步构建了上下文修剪窗口。使用句子变换器模型模拟长期运行管道,并配合模拟的对话历史。首先,导入必要的库并加载预训练的嵌入模型(all-MiniLM-L6-v2)。然后创建模拟的代理历史。核心逻辑封装在prune_context()函数中,该函数接收当前提示、完整交互历史和要检索的语义相关轮次数k。函数首先处理基础情况(历史太短时返回完整历史),然后进行语义修剪:嵌入历史轮次,计算与当前提示的余弦相似度,排序并选择Top-K轮次,最后组装修剪后的上下文。示例中,当用户询问“Can we go back to the fleet math?”时,修剪后的上下文包含了与车队路线效率相关的历史轮次。
总结
本文展示了如何基于模拟的代理对话历史实现上下文修剪管道,利用语义相似度选择最相关的上下文部分。这对于长期运行的代理至关重要,有助于减少内存使用和计算成本,同时提高效率。