更大的上下文窗口对智能体来说其实是错误的方向吗?
摘要
作者质疑将注意力集中在扩大AI智能体的上下文窗口上是否适得其反,认为积累的垃圾信息会拖慢长时间会话,并建议保持工作上下文小巧、使用外部记忆。
我构建编码智能体已有数月,但总有一个奇怪的想法挥之不去:我们是不是在智能体记忆问题上找错了方向?大量精力似乎都花在扩大上下文窗口上——更多历史记录、更多摘要、更多重放、提示中塞入更多内容。诚然,更大的上下文很有用。但我参与过的每个长期运行智能体,最终都开始拖累垃圾信息:旧的调试尝试、几小时前就被放弃的计划、不再成立的假设、无关紧要的闲聊。到某个节点,这更像是杂乱而非记忆。因此近来我怀疑,更好的方法几乎恰恰相反:保持工作上下文精简,将记忆存储在其他地方,仅按需拉取智能体当前真正需要的内容。本质上就是把模型当作无状态来对待——因为它本就是如此。也许我忽略了某些显而易见的东西,但直觉告诉我,长时间会话的失败更多源于积累的垃圾,而非缺乏上下文。对于那些运行智能体成百上千次迭代的人而言,你们觉得这个思路会在哪里失效?最先出问题的是什么?
相似文章
更大的上下文窗口只是让你中间有个更大的死区
对847次AI代理运行的分析显示,较大的上下文窗口会导致性能下降,原因是注意力悬崖,而Synap被介绍为一个工具,可以高效地管理上下文并减少token使用量。
@N01ennn: 更大的上下文窗口是死路一条。这篇论文证明了这一点。一项新的CS调查悄然重新定义了整个游戏:事情…
一条推文重点介绍了一篇CS调查论文,该论文认为更大的上下文窗口是死路一条,而记忆工程——将智能体的记忆视为操作系统——才是将真正的AI智能体与自动补全区分开来的关键,使无状态模型能够自我进化。
@GergelyOrosz: 试图弄清楚,在上下文窗口中使用更多上下文(我称之为上下文深度),在更长的运行中,错误会如何累积/代理会如何漂移……
Gergely Orosz 指出,在AI代理的上下文窗口中使用更多上下文进行更长的运行会增加错误和漂移,建议使用更短的运行和更少的上下文以提高可靠性。
上下文至关重要,但上下文腐烂才是AI智能体的真正上限,更大的上下文窗口只会让情况更糟而非更好
文章认为,上下文腐烂(即随着上下文填充导致推理质量下降)是AI智能体的真正上限,而非上下文窗口大小。它提倡采用架构方法分解任务并使用独立验证来超越限制。
我认为长上下文代理的失败方式非常无聊
一篇观点文章,认为长上下文窗口并不等同于记忆,代理失败通常很普通,比如忘记约束或重新读取文件,强调可靠性取决于上下文架构决策。