更大的上下文窗口只是让你中间有个更大的死区

一位r/LocalLLaMA的开发者追踪了847次代理运行，测量了代理在上下文窗口填满时遵循指令的情况。准确率从94%开始，窗口满时降到41%。它不是慢慢下降，而是保持稳定然后急剧下降，这就是人们说代理在长对话中变笨了的意思，但实际上代理没有变笨，只是周围的上下文变差了。为什么更大的窗口没有修复这个问题？注意力是U形的，所以模型关注开头和结尾，忽略中间，更大的窗口只是意味着更大的中间部分被忽略。我见过一些团队，他们超过60%的token预算每轮都注入相同的东西，因为没有机制决定哪些仍然需要。压缩陷阱：显而易见的修复是随着历史增长压缩它，但激进的总结保留了故事的概要却丢失了细节，当你的代理需要基于具体事实行动时这是适得其反的。我将一个18,282 token的对话压缩到122 token，结果比完全没有记忆还要差，因为代理听起来正确但实际上不正确。静默失败：一个团队在他们的记忆层中有3000多个文档，仪表盘上显示91个记忆，但每次API搜索调用都返回空结果，没有任何提示告诉他们系统坏了。至少注意力悬崖你能看到，但这个你看不到。我在Synap中如何处理：代理不是每轮重放历史，而是调用Synap，获取一组排序的记忆，符合token预算。检索跨向量图和文件存储，填充到预算，任何不值得token的内容被剪切。压缩在每次调用时运行，并检查有多少事实存活，所以如果丢失太多，我可以减少激进程度重试，而不是只希望压缩没有破坏任何东西。检索在P75下运行在15ms以内，而且在代理请求之前就已经完成，所以没有等待。在生产工作负载中，它大约将token使用减半，但真正的重点是代理在处理有用的上下文，而不是一个正在崩溃的完整窗口。我会检查什么：在同一个任务上，测量第5轮和第50轮的准确性，如果有下降，检查是注意力悬崖还是压缩丢失了重要信息，因为它们从外部看起来相同，但修复方法不同。（附注：我在Maximem Synap工作。847次运行的数据来自r/LocalLLaMA的一位开发者，不是我的测量。）