LLaMA 4 Scout,和那个「事实上无限」的上下文窗口承诺,咱们该从哪儿说起?
它是真的。它也能用,某种意义上。但它有用吗?
超长上下文窗口的真正挑战,不只是召回。是推理。你往模型里灌一整墙信息,它不能光记下来,它得 理解这份上下文.
如果模型能摸到先前的内容,却没法有意义地加工它,那我们到底解决了什么问题?
最新的 LLaMA 4 一代,吹的是一千万 token 的窗口。听着很唬人,直到你把它带进一个真实的工作流——比如一次产品开发或编码会话——指望一点非结构化的召回和连续性。
而且没错,你可以把模型引回先前内容。但像样的性能,大约在 200k token 附近就开始往下掉。对 LLaMA 而言仍是巨大的一步……但离「无限」差得远。
LLaMA 4 Scout 不是 reasoner。它是混合专家模型——为效率优化的,不是为复杂度。对话里它干得不错,但跨领域推理、递归、多步任务就摇摇晃晃。它不会打转,但它会以不该有的方式犯糊涂。
这是架构问题,不是上下文问题。
到了某个时刻,我亲爱的宝贝们,我们得坐下来好好谈谈,上下文窗口到底是什么——以及它不是什么。
召回不是有用的记忆
最重要的一条:引导召回,不等于有用的记忆。
🌀 引导召回,是你提示模型去取它见过的东西时发生的事。它有效——有时还挺灵——但它完全依赖人的把舵。
🧠 有用的记忆是结构化、有意图、往往在体外的。它做摘要、做整理、知道该露面的是什么——不用你开口。它让任务和会话之间有连续性。它让过程踩在地上。
先结构,后容量
巨大的上下文窗口不是记忆。这些系统从头就不是照着聪明数据库设计的。上下文更该当成一个工作区——一块缓冲。它装得下更多眼前的信息。这不自动带来更好的推理或更有效的产出。更多 token ≠ 更多智能。而且丰富的上下文,仍然替代不了检索系统或微调。
如果你在用正经的智能体工具,你需要的不只是空间——是结构。一套动态上下文系统,给相关信息排优先级——撑住智能体,而不是把模型撑爆。摘要。索引。划定范围的任务。
一百万 token 以内,你可以走很远,前提是你知道自己在干什么。
这里的问题是那种最基础、最容易的系统设计。不需要的信息,别加载,别缓存。关注点分离。想清楚你到底要干什么,并且永远把清晰度排在容量前面。
如果你的活儿依赖精度、递归或长期规划——用动态上下文管理。让智能体快、聚焦、能变形。
块头说明不了一切。