#上下文窗口

1周前

DeepResearch Agent 有一个很大的问题就是多次的搜索阅读很容易就把上下文窗口用光了，常规的做法是像 Claude Code 一样，超过阈值就触发记忆压缩。通义的论文《ReSum》提出了一种在 RL 中让模型学会更好地利用压缩内容的方法。这个方法我们之前也考虑过，但这样做在强化学习的时候会有一个问题：一旦触发记忆压缩，整个历史记录都会变成压缩后的内容，此时模型就只能看到压缩后的 token，压缩前的就丢掉了，此时模型就学不到压缩前的动作了。我们当时没想到好的解法，而 ReSum 提出一种可行的方案：把压缩前和压缩后的轨迹分成两条分别给奖励。举个例子：正常的轨迹是这样的：“用户查询 → AI 助手 → 工具调用 → AI 助手 →... → AI 助手 → 答案” 加入了 summary 工具之后，当轨迹接近上下文窗口的时候，系统就会触发总结。接近上下文窗口长度的轨迹 A：“用户查询 → AI 助手 → 工具调用 → AI 助手 →... → AI 助手 → summary” 新的轨迹 B：“用户查询 + 摘要 → AI 助手 → 工具调用 → AI 助手 → 答案” 关键点来了，当 B 答对时，B 的奖励会复制给 A。为什么要这样做？尽管 A 没有直接得出答案，但它找到了一个有用的摘要，最终导向了正确的答案，所以 A 中的所有动作也得到了正向的激励。这样模型能通过 A 学会收集能够产生优质摘要的关键信息。而模型则通过 B 学会了利用摘要信息来高效地完成任务。这就是一箭双雕。

#多智能体之争：Anthropic生态VS单智能体· 49 条信息

#DeepResearch Agent #记忆压缩 #ReSum #强化学习 #上下文窗口

1个月前

最先进的一批AI模型写代码不烂，模块级别远超人类程序员平均水平，写出来烂代码先看看选的啥模型，上下文是不是充分，提示词是不是要优化。跨模块的代码，受限于上下文窗口长度，可能需要人类辅助设计规划一下，如果项目结构合理，AI一样可以重用现有代码保持DRY

深度学习模型升级引发AI能力大跃进，行业迎新变革· 95 条信息

#AI模型 #代码生成 #模块级别 #人类程序员 #上下文窗口

2个月前

特别是第5点，用文件系统解决了大模型的上下文问题，让Agent拥有无限记忆和灵活操作能力。文件系统是人类文明最伟大的发明之一。让 Agent 能用文件系统作为记忆存储，是Manus团队最大的发明之一。为什么用文件系统？传统AI Agent最大的问题是“记性差”——上下文窗口再大，也有极限。比如128K tokens听起来很大，但遇到复杂任务、长文档、网页、PDF，分分钟就爆了。而且，长上下文不仅贵，还会让模型“迷糊”，性能下降。 Manus的思路是：既然大脑（上下文）装不下，就用“硬盘”——也就是文件系统，来当外挂记忆！文件系统的创新用法 1. 无限扩展的记忆文件系统没有上下文窗口的限制，Agent可以随时把重要信息写进文件，需要时再读出来。比如，遇到大文档、复杂网页，Agent只要记住文件路径或URL，内容可以随时查，不用全塞进上下文。 2. 结构化、分层管理文件系统天然支持分层、分类。Agent可以把不同任务、不同阶段的信息分门别类地存储，像人类整理文件夹一样，查找和管理都很高效。 3. 可恢复的压缩 Manus的压缩策略很巧妙：不是简单丢弃信息，而是“可恢复”——比如只保留网页的URL，内容需要时再拉回来。这样既节省上下文空间，又不会丢失关键数据。 4. Agent间共享与版本控制虚拟文件系统还能让多个Agent共享信息，像团队协作一样。还可以支持版本控制，记录每一步的变化，方便回溯和纠错。 5. 让Agent学会“用文件” Manus的Agent不只是被动存取文件，而是主动学会用文件来规划任务、记录进度、复述目标。比如，Agent会自动生成文件，随着任务推进不断更新，把目标“复述”到上下文末尾，防止“迷失在中间”。 Manus团队认为，文件系统其实是AI Agent的“外部化记忆”。模型不用什么都记在脑子里，而是像人类一样，学会查资料、做笔记、整理档案。这样，Agent就能处理更复杂、更长远的任务，甚至有点像“神经图灵机”——把短期记忆和长期记忆结合起来。未来如果有更高效的序列模型（比如State Space Model），配合文件系统这种外部记忆，AI Agent的能力会有质的飞跃。

#大模型Agent #文件系统 #上下文窗口 #记忆存储 #Manus团队

3个月前

很久没聊 RAG 了，随便说点。 RAG 里的分块技术，某种程度上看起来确实显得越来越过时了。不是说完全抛弃不要，只是分块带来的弊端越来越明显，多高超的技巧都救不回来“信息完整度”的缺失。当然总有上下文窗口不够的情况，完整的大型文档丢进去，确实吃不下怎么办？凉拌。你就用最简单粗暴的方法，按长度来，丢过去做点预处理，总结，然后差不多行了。这种方法下，切割的问题依然存在，会有把完整信息切错乱，让上下文不精准的可能。但首先，影响真的不大。这种方法会有信息折损，但不会比你以前精妙的各种分块技术，各种组合，效果差到哪里去。不同的场景下会有差别，肯定有赶不上传统方案的时候，但——无伤大雅。以前的 RAG 到底做到了个什么水准，那么多雕花，最后的成果如何，大家心里都有数。其次，你要相信今天的模型。论聪明程度，这个意义不大。但论长上下文的处理，对超长文本的高维关系分析，人类已经连 LLM 的尾灯都看不到了。不会差到哪里去的。节省下来的时间力气，都足以在其他方面做很多新的探索。比如 PDF 不做 OCR，不分块，而是直接转图片给多模态。也不是说传统 chunk 技术就有什么问题，那里面其实已经诞生了很多可靠的实践，可以对不少效果兜底。但大多数情况下，做的就还是雕花的工作。原始数据有多脏，各种格式有多奇葩，各位应该多少有耳闻。雕花的事，少干点，有这技术就行，没必要天天弄。你看 Apple 刚 WWDC 上端出来的顶级雕花，真的一言难尽。

#RAG #分块技术 #信息完整度 #上下文窗口 #预处理 #切割问题

8个月前

问：模型支持的TOKEN数量是模型本身的限制还是调用模型的程序限制的呢？答：模型会有上下文窗口长度限制，AI聊天应用也会有会话长度限制。举例来说你的模型最大上下文窗口长度限制是 128K，但是通常应用程序不会让你输入的内容到128K，可能输入内容最多16K就不让你输入了，因为这个上下文窗口长度是针对输入和输出加起来的长度，所以要留一些空间给输出。另外输入内容越长，模型生成的质量会下降，成本也会增加很多，所以应用要限制最大输入的长度。

#模型 #TOKEN数量 #限制 #上下文窗口 #AI聊天应用 #会话长度 #输入内容 #生成质量