两年前,上下文窗口大小是每次模型发布的头条参数,支持团队围绕"无法将客户完整历史记录塞进单个 prompt"这一限制,构建了整套架构——分块、检索、激进的摘要处理。如今这一限制已基本消失。但它一直掩盖的那个更难的问题,却并未随之消失。

新的瓶颈是相关性,而非容量

当上下文容量足以同时容纳客户的完整对话历史、购买记录和产品使用数据时,失败模式就从"模型不知道这个"转变为"模型知道这个,但权重没算对"。一个装有 50,000 个 token、其中大部分是无关历史信息的模型,表现可能不如一个只拿到精心筛选的 2,000 个 token 的模型——因为相关信号被稀释了,而不是被凸显出来。

检索没有消失——只是换了工作内容

旧任务(2023-2024) 新任务(2026)
约束条件 上下文容量有限 容量充裕,但注意力有限
检索的角色 在 token 预算内塞入相关数据 即使空间富余,也要排序和挑选优先呈现的内容
失败模式 “模型从未看到过这个” “模型看到了,但权重没算对”

衡量相关性本身就是一个难题

一旦"该呈现什么"取代"能塞下什么"成为设计层面的问题,团队就需要一种方法来真正衡量自己的信息筛选是否有效——这比听起来更难,因为一个筛选系统在孤立的评审中可能看起来很合理,却仍然可能系统性地低估某一类信息的权重,而这类信息恰恰比预期更重要。专门为上下文筛选质量建立一套评估集,并将其与评估模型最终答案质量的评估集区分开来,是一种正在兴起、但在业内仍未被充分采用的最佳实践。

这对你的 Memory 架构意味着什么

如果你的 Agent memory 系统最初主要是为了解决"如何塞下所有信息"而搭建的,那么现在值得用一个新问题重新审视它:"在我们能够展示给模型的所有信息中,哪些真正能够预测出针对这条具体消息的优质答案。"这是一个排序和筛选问题,而不是存储问题,它需要独立于原始上下文容量的专属评估。把这个问题当作一次性架构重构、而非持续调优工作的团队,往往会看到初期改善后趋于停滞,因为相关性模型本身也需要像 Agent 其他部分一样,经历同样的迭代和监控。

更大的上下文窗口消除了一个真实存在的限制,但并没有消除"该向模型展示什么"这一判断力需求——而如今,竞争差距正体现在这种判断力上,而非原始容量上。它理应获得团队过去一贯只留给模型选型本身的那种审慎衡量与迭代,而不该在上下文窗口不再是限制因素之后,就被当作一个已经解决的问题束之高阁。

一个真正违反直觉的结果

对于过去两年一直把"更多上下文"当作毫无疑问的改进的团队来说,这是一个真正违反直觉的结果,它要求架构决策的方式发生真正的转变。每当 Agent 似乎遗漏了什么信息时,就下意识地想换用更大的上下文窗口,这种本能是可以理解的,毕竟这个限制曾经确实存在。但到了 2026 年,更有成效的本能通常是去追问:究竟是什么挤占了真正重要的信号,而不是模型还需要多大的空间。