Claude的标记限制让我重新思考记忆:为什么“更多上下文”并不等同于“更好的记忆”
摘要
一篇观点文章,认为像Claude这样的模型中更大的标记窗口并不等同于更好的长期记忆;真正的记忆需要超越上下文大小的结构化、总结和检索。
我最近一直在思考Claude的标记窗口,尤其是在构建代理工作流时,模型可以在短期内“记住”很多东西,但在较长的交互中仍然会失去线索。让我印象深刻的是 **标记和记忆不是同一个问题**。更大的上下文窗口可以帮助你在单个提示中传递更多信息,但它并不会自动解决:* 哪些应该长期保留,* 哪些应该总结或压缩,* 哪些应该被遗忘,* 以及如何跨会话保留有用的用户偏好或决策。在实践中,我发现很多“记忆”问题实际上是 **检索和结构** 问题,而不仅仅是上下文大小问题。我看到的几点:* 标记密集的提示可以掩盖糟糕的记忆设计。* 长上下文可以让模型感觉更聪明,但并没有让它更持久。* 真正的挑战在于决定哪些内容值得放在提示之外。我很好奇其他人怎么看待这个问题:* 你是否将Claude的标记窗口视为记忆的替代品?* 还是你完全将记忆视为一个独立的系统?* 你用什么策略来保持代理在多个会话中持续有用?很想听听其他开发者如何处理这个权衡。
相似文章
@_avichawla: 更聪明的 Claude 模型消耗的 tokens 更多,而不是更少!而且这不是 3-5% 的微小差异,而是高出 54% 的 token 使用量。…
本文分析了为何像 Claude 这样更智能的 AI Agent 在与 Supabase 等以人类为中心的后端交互时会消耗更多 Token,主要原因在于上下文发现效率低下。文章引入了 InsForge,这是一款专为 Agent 设计的开源后端工具,通过提供结构化的上下文来显著降低 Token 用量和人工干预。
AI是否真正需要长期记忆,还是扩大上下文窗口就足够了?
本文讨论了AI模型是否需要专门的长期记忆系统(如RAG)还是扩大上下文窗口就足够了,提出了两种方法的论点,并寻求社区反馈。
@N01ennn: 更大的上下文窗口是死路一条。这篇论文证明了这一点。一项新的CS调查悄然重新定义了整个游戏:事情…
一条推文重点介绍了一篇CS调查论文,该论文认为更大的上下文窗口是死路一条,而记忆工程——将智能体的记忆视为操作系统——才是将真正的AI智能体与自动补全区分开来的关键,使无状态模型能够自我进化。
@mvanhorn: https://x.com/mvanhorn/status/2070966613994795489
作者认为,AI代理的内存膨胀会降低性能,并建议将memory和CLAUDE.md文件控制在200行以内,使用按需检索而非将所有内容加载到上下文中。
更大的上下文窗口并未解决企业记忆问题——原因如下
本文批评了LLM中不断扩大上下文窗口的趋势,认为由于检索退化、数据量和缺乏结构,这并不能解决企业知识问题。文章主张在检索之前建立知识建模层,以映射关系和意图。