最近一轮模型发布里，几乎所有主流实验室都把「1M token 上下文」写进了规格表。
看起来像是同一赛道，实际却不是同一能力。
如果把问题改成更工程化的一句：
在多长上下文下，模型还能以接近 90% 的准确率完成信息定位与诉求理解？
答案会非常现实：大约在 256K 这一档，只有少数模型还接近 90%；到 1M，差距会急剧拉开。
先说结论（给忙人）
- “接近 90% 正确率”的有效区间，当前大致在 256K（而不是 1M）。
- 在 MRCR v2 这类“长上下文检索”测试里：
- Opus 4.6：91.9%（256K）→ 78.3%（1M）
- Sonnet 4.6：90.6%（256K）（文中未给 1M 最终点）
- GPT-5.4：约 79.3%（128K~256K平均）→ 36.6%（1M）
- Gemini 3.1 Pro：25.9%（1M）
- 对“单次超长对话”场景，你该关心的不是标称窗口，而是窗口放大后的检索保持率（retention under length）。
- 如果你的业务要靠一次会话吃下海量上下文（法务长文档、整仓代码、长时 Agent），1M token 本身不是护城河，稳定检索能力才是。
为什么“1M token”常常让人误判
在产品宣传里，context window 是最容易比较的参数：
- 大小直观（128K、256K、1M）
- 看起来客观
- 容易做成一行对比表
但在工程里，这个参数只回答了一个问题：
“最多能塞多少”
而我们真正需要的是另一个问题：
“塞满以后，它还能不能稳定找到你要的那一条信息？”
两者差距很大。
一个模型可以“吃下”1M token，但如果在 1M 时只剩下 30% 左右的检索准确率，它在真实业务里就会变成高成本、低确定性的系统部件。
这组数据到底测了什么
这次讨论引用的是 MRCR v2（OpenAI 公布过的长上下文检索基准）。
它的思路并不复杂：
1. 在超长文本里埋入多个相似信息块（如 8 份近似线索）
2. 提一个有明确目标的检索问题
3. 看模型能否命中正确目标
它本质是压力测试：
- 不是“会不会写漂亮答案”
- 而是“在噪声和规模上来之后，还能不能定位对”
这类能力，和我们日常的 Agent、RAG、法律/财务文档问答、代码仓级 Copilot 直接相关。
回到核心问题：多少 token 才能接近 90%？
如果只看这组对外数据，可得出一个务实判断：
1) 256K 是当前“接近 90%”的关键分水位
在 256K 档位，Opus 4.6（91.9%）与 Sonnet 4.6（90.6%）都接近或达到 90%。
这说明：
- 当上下文规模在 256K 量级时，顶级模型仍可能维持接近生产可用的检索稳定性。
2) 1M 会放大差异，而不是抹平差异
同样宣称 1M，上 1M 后表现完全不是一回事：
- Opus 4.6 仍有 78.3%
- GPT-5.4 降到 36.6%
- Gemini 3.1 Pro 为 25.9%
也就是说，模型能力曲线不是线性衰减，而更像“谁先掉崖、谁更抗衰”。
3) 对 GPT-5.4，这组数据下看不到“90%区间”
文中给的是 GPT-5.4 在 128K~256K 区间的平均值 79.3%。
从这一个统计口径，不能证明其在 256K 接近 90%。
如果要精确回答“GPT-5.4 在多少 token 达到 90%”，需要更细粒度分点（例如 32K/64K/128K）公开曲线。
“context rot” 对业务意味着什么
研究社区常把这种随长度增大而检索能力衰退的现象叫 context rot（上下文腐蚀）。
这件事对业务的影响，不是“答错一次”那么简单，而是三层连锁：
- 准确率风险：关键引用、约束条件、边界条款被错取或漏取
- 流程风险：Agent 在多轮执行中基于错误事实继续推理，误差累积
- 成本风险：token 越长、调用越贵，结果反而越不稳定
当你把模型放进“长流程自动化”时，context rot 会直接吞掉系统可控性。
价格维度：更贵，不代表更稳
另一条容易被忽略的线是价格机制。
如果长上下文需要加价，而检索准确率又随长度显著下降，那么你得到的是：
- 更高单次成本
- 更低有效命中
- 更差的单位结果成本（cost per correct retrieval）
工程上真正该优化的指标，应该从“每百万 token 单价”转向：
每一次正确检索/正确决策的综合成本
这也是为什么“价格 × 长度衰减曲线”必须一起看。
给团队的落地建议（可直接执行）
如果你在做长对话 Agent、长文档分析、全仓代码助手，建议直接落这 5 条：
1) 把“检索保持率”设为准入门槛
- 采购或选型时，不只看窗口上限
- 必测 128K / 256K / 512K / 1M 四档准确率
- 输出衰减曲线，而不是单点分数
2) 单次会话优先控制在“高可靠区间”
- 当前经验上，将核心任务尽量收敛在 256K 左右更稳妥
- 超长内容采用分层摘要 + 分段检索 + 关键证据回填
3) 关键任务引入“双通道校验”
- 主模型给结论
- 副通道做证据定位复核（引用段落、页码、代码路径）
- 无证据不落盘、不过审
4) 监控从 token 计费升级为“正确率计费”
- 记录每个任务的检索命中率
- 跟踪单位正确结果成本
- 模型切换决策由这两个指标驱动
5) 对 1M 场景做架构分流
- 非必须，不要“一锅端”塞满上下文
- 采用 memory 分层：热上下文（近期关键）/ 冷上下文（可检索）
- 让模型“看见需要的”，而不是“看见所有的”
一个更现实的判断框架
以后再看到“我们也支持 1M token”，建议直接追问三件事：
- 在 256K、512K、1M 的检索准确率分别是多少？
- 准确率曲线是缓降还是指数衰减？
- 长上下文加价后，单位正确结果成本是多少？
只要这三问答不清，1M 就更像营销参数，而不是生产能力。
结尾
回到最初的问题：
在多少 token 下，单次对话模型几乎可以做到 90% 的正确诉求分析？
基于当前这组公开数据，可落地的答案是：大约 256K 档位，且只在少数模型上成立。
到了 1M，真正决定胜负的不是“能装多少”，而是“还能不能找对”。
对于做 AI 系统的人，这可能比任何发布会上的参数都更重要。
注：本文结论基于公开 benchmark 描述与对比数据解读，具体结果会受任务类型、提示策略、评测集构造与版本迭代影响。生产环境请务必做自有基准复测。