AI 纪元 追踪人工智能最新进展,深度解读前沿技术

GPT-5.6 Sol 的 150 万 Token,衰减曲线还缺证据

公开资料能确认 GPT-5.6 Sol 的基准成绩,也有媒体提到 150 万 token 窗口;但现有素材无法证明 OpenAI 发布过具体的注意力衰减曲线。合同、代码库和多 Agent 任务仍需按位置、长度与多跳关联做业务测试。

0 次阅读 约 2283 字 5 分钟 AI 生成
A minimalist editorial still life showing a magnifying glass inspecting a complex, fading gradient chart on a clean desk, symbolizing the scrutiny of unverified
A minimalist editorial still life showing a magnifying glass inspecting a complex, fading gradient chart on a clean desk, symbolizing the scrutiny of unverified

先把能核对的信息摆出来。提供的知乎专栏摘要称,7 月 9 日,OpenAI 向全球用户开放 GPT-5.6 系列,Sol、Terra、Luna 三款同时上线。关于旗舰 Sol,钛媒体的一篇发布前报道提到 150 万 token 上下文;华尔街见闻则报道了 Ultra 多智能体模式,以及 Terminal-Bench 2.1 上 91.9% 的成绩。

OpenAI 官方页面里最明确的一组数字来自 Agents’ Last Exam。这项长周期专业工作流评估覆盖 55 个领域,Sol 得分 53.6,比 Claude Fable 5(自适应推理)高 13.1 分。中等推理强度下,页面称 Sol 的预估成本约为 Fable 5 的四分之一,仍领先 11.4 分。

这些信息可以支撑 Sol 的产品定位和公开基准表现,却不足以证明 OpenAI 团队已经发布长上下文衰减曲线。

那张曲线,来源对不上

围绕 Sol,有一组非常具体的衰减数据:前 80 万 token 的注意力权重波动在 5% 以内;超过 100 万后开始下降;到 130 万附近,深层网络的注意力峰值降低约 30%;末尾 10% 区间的权重中位数只有头部 10% 的 65%。

问题在于,提供的 OpenAI 摘要没有出现这些数字,现有素材里也找不到对应的技术博客、原始图表和测试方法。没有这些信息,就无法判断曲线测的是信息召回、注意力权重、长程推理,还是某个特定任务下的结果,更不能据此划出 80 万或 100 万 token 的“安全线”。

同样需要暂缓引用的,还有 Sol 使用改进版 RoPE、Flash Attention 和累积注意力掩码的说法,以及所谓官方 transformers 脚本和 vLLM、TensorRT-LLM 测试建议。Claude Mythos 与 Gemini 2.0 Ultra 的具体拐点和百分点对比,也没有对应来源。

位置编码、注意力稀疏化和缓存策略都可能影响长序列任务,但在模型架构说明缺席时,把 Sol 的表现归因于某一种机制并不稳妥。

150 万 Token 只回答了容量

窗口长度说明模型一次能够接收多少输入。它没有回答另一组更接近生产环境的问题:同一条信息放在开头、中间和末尾,召回是否稳定;相隔很远的两段内容能否正确关联;回答能否准确引用原文位置。

这几类任务尤其值得单独测试:

  • 合同审查:担保、违约和补充条款常出现在附件或文档后段。输出结论之外,还应要求模型返回对应原文和位置。长文档可先做语义分块与元数据过滤,再把命中内容送入模型,相关工程细节可参考《RAG 检索精度上不去,先检查这三个工程细节》。
  • 代码库分析:跨文件排查需要追踪调用关系、配置项和异常栈。测试结果不能只看模型有没有给出解释,还要核对文件路径、函数名和引用片段。
  • 多 Agent 工作流:如果多个 Agent 的执行记录持续汇入同一任务历史,早期决策、工具返回值和最新状态可能相隔很远。除了正确率,还要记录输入 token、延迟和任务中断情况。

用自己的数据画一条曲线

在拿到官方原始数据前,业务团队可以先做改进版 Needle-in-a-Haystack 测试。下面是一套起始配置,不代表 OpenAI 的官方测试方法。

  • 拉开上下文长度:在接口允许范围内,依次测试 10 万、50 万、100 万、130 万和 150 万 token。
  • 改变信息位置:把关键信息放在全文 0%、20%、40%、60%、80% 和 95% 附近。同一长度比较不同位置,同一位置再比较不同长度。
  • 同时放入多条信息:每次插入 5—10 个信息点,长度控制在 50—100 token。可以使用“激活码:7A3B-20C6”“截止日期:2027-03-15”这类明确标为虚构的字段,但格式不要过分醒目。
  • 加入跨段关联:除了单条召回,还要测试多跳问题。例如把用户邮箱和支付账户信息放在相距较远的位置,要求模型先找到身份关系,再返回关联字段。
  • 记录完整结果:至少保留精确召回、错误引用、无依据补全、响应延迟和输出 token 数。模型版本、推理强度与提示词应保持一致。

第一轮可以用平淡的填充文本排查位置效应,随后要换成真实业务语料。重复文本上的单针命中,只能说明模型找到了一条醒目的信息,无法代表合同审查或代码溯源能力。

基准高分不能代替业务验收

Agents’ Last Exam 的 53.6 分,以及媒体报道的 Terminal-Bench 2.1 最高 91.9%,对应的是特定基准任务。它们没有给出信息位于长上下文不同位置时的稳定性结论。

依赖超长输入的产品,仍要根据业务测试划定有效工作区。一旦某个长度或位置频繁出现漏召回、错误关联和引用偏移,就应触发分块、检索、截断或人工复核。多 Agent 任务还要设置 token 配额和熔断条件,可参考《Agent FinOps:预算护栏要卡在执行前》。

在补到官方原始曲线和测试方法之前,可以确认的是 Sol 的公开基准成绩,以及媒体披露的 150 万 token 参数。80 万、100 万和 65% 这些衰减数字,暂时不宜写成确定结论。

参考资料

相关阅读