大模型能读 1M Token，就真的读懂了吗？
大模型能读 1M Token，就真的读懂了吗？
来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 记忆系统, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/ImkyALC_vWUaiTZIFgRmxw
摘要
这是悟鸣的第 260 篇公众号文章。 大家好，我是悟鸣。 现在很多人选大模型，第一眼会看上下文长度。 32K、128K、200K、1M…… 数字越大，看起来越厉害。好像只要窗口足够长，一本书、几百页 PDF、一整个代码仓库，甚至一堆聊天记录，都可以直接丢进去。 但这里有个问题：模型没有报错，正常给你回答，只能说明它把这些内容“收下了”。 它有没有真的找到关键证据？有没有被无关信息带偏？有没有漏掉中间某个细节？有没有干脆凭自己的记忆在回答？ 这些才是我们真正应该关心的。 最近我重新读了 NVIDIA 的一篇论文： RULER: What's the Real Context S...
核心内容
这是悟鸣的第 260 篇公众号文章。
大家好，我是悟鸣。
现在很多人选大模型，第一眼会看上下文长度。
32K、128K、200K、1M……
数字越大，看起来越厉害。好像只要窗口足够长，一本书、几百页 PDF、一整个代码仓库，甚至一堆聊天记录，都可以直接丢进去。
但这里有个问题：模型没有报错，正常给你回答，只能说明它把这些内容“收下了”。
它有没有真的找到关键证据？有没有被无关信息带偏？有没有漏掉中间某个细节？有没有干脆凭自己的记忆在回答？
这些才是我们真正应该关心的。
最近我重新读了 NVIDIA 的一篇论文：
RULER: What's the Real Context Size of Your Long-Context Language Models?
直译过来就是：你的长上下文语言模型，真实上下文大小到底是多少？
这篇论文提出了一个叫 RULER 的评测框架。我觉得它最有价值的地方，其实不在于给模型重新排榜，重点在于提醒我们：
看长上下文能力，不能只看厂商写在参数表里的窗口大小，也不能只靠“大海捞针”判断模型好不好。
换句话说，长上下文的关键点可以压成一句话：别只看能塞多少，要看塞进去以后能不能用好。
1. “大海捞针”为什么不够了？
长上下文评测里有一个经典测试，叫 Needle-in-a-Haystack，简称 NIAH。
说人话，就是“大海捞针”。
做法不复杂：把一句关键信息藏进一大段文本里，然后问模型能不能找出来。
比如在一堆无关文字里塞一句：
long-context 的特殊魔法数字是 12345。
然后问：
long-context 的特殊魔法数字是多少？
模型答出 12345，就算通过。
这个测试当然有价值。至少它能看出模型在长文本里有没有基本的定位能力。
但我们平时用大模型，很少只是为了找一个孤零零的数字。
更常见的情况是：
- 从多份材料里找证据；
- 判断人物、事件和结论之间的关系；
- 从一堆用户反馈里归纳高频问题；
- 在很多干扰材料里回答一个需要理解上下文的问题；
- 从会议纪要、合同、需求文档里列出所有待办或风险项。
这些任务都比“找 12345”复杂。
NIAH 主要测的是检索能力。长上下文真正麻烦的地方在于，模型不仅要“看见”，还要能把看到的内容稳定用起来。
2. RULER 到底测了什么？
RULER 用的是合成 benchmark，不是传统的真实文章问答数据集。
“合成”在这里不是缺点。真实数据往往太复杂，模型可能靠训练阶段见过的知识回答，也可能被题目格式影响。合成任务的好处，是可以更干净地控制上下文长度、干扰信息和任务难度。
论文主要把长上下文能力拆成了几类。
第一类是检索。
它不只测最简单的 NIAH，而是把“针”变得更接近真实场景：
- 可能是一个 key-value；
- 可能是多个 key；
- 可能一个 key 对应多个 value；
- 也可能一次问多个 query；
- value 既可能是数字、单词，也可能是 UUID 这种更长、更容易抄错的字符串。
这就比“找 12345”难很多。真实文档里也常常不是只有一个答案，旁边还会有很多长得很像的干扰项。
第二类是多跳追踪。
论文里设计了一个 Variable Tracking 任务，大概长这样：
VAR X1 = 12345
VAR X2 = X1
VAR X3 = X2
然后问模型：哪些变量最终指向 12345？
看起来像编程题，本质上是在测模型能不能在长上下文里追踪关系链。
放到真实使用里，就像你让 AI 读一堆项目文档，判断某个需求是谁提出的，中间经历了哪些变更，最后影响到哪个模块。
第三类是聚合。
比如给模型一长串词，让它找出出现次数最多的词。
这时任务已经从定位某一句话，变成了在长上下文里统计、汇总。会议纪要总结、用户反馈归因、评论里提炼高频问题，都有类似影子。
第四类是问答。
作者把 SQuAD、HotpotQA 这类短文本问答任务扩展成长上下文场景：把包含答案的段落插入大量干扰段落里，再让模型回答问题。
这样一来，模型不仅要找到相关段落，还要理解问题，并且不能被旁边的干扰材料带跑。
所以 RULER 的思路其实很直接：
别只问模型能不能找到一根针。还要看它能不能在一大堆材料里检索、追踪、聚合、问答，并且尽量找全答案。
3. 标称长度和有效长度，中间差得不小
论文主实验评测了 17 个长上下文模型，包括 Gemini-1.5-Pro、GPT-4 和 15 个开源模型。
评测长度从 4K、8K、16K、32K、64K，一直到 128K。每个任务、每个长度生成 500 个样本。
作者还定义了一个“有效上下文长度”。
它的判断方式是：用 Llama2-7B 在 4K 上的表现，也就是 85.6%，作为阈值。如果某个模型在某个长度上超过这个阈值，就认为它在这个长度下表现还算满意。模型能通过的最大长度，就是它的 effective length。
这个定义当然不是唯一标准，但很直观。
它问的是：
你标称支持 128K，那到了 128K，表现还能不能维持在一个基本可用的水平？
结果不算乐观。
论文摘要里有个很关键的结论：被测模型都声称支持 32K 或更长上下文，但只有大约一半能在 32K 长度维持满意表现。
更刺眼的是，几乎所有模型在达到自己标称上下文长度之前，表现就已经跌破阈值。
论文表 3 里有几个例子：
- Gemini-1.5-Pro 标称 1M，在 4K 到 128K 上平均分 95.8，有效长度超过 128K；
- GPT-4 标称 128K，论文里的有效长度是 64K；
- Yi-34B 标称 200K，论文里的有效长度是 32K；
- 一些标称 32K 的模型，有效长度甚至低于 4K。
这里要特别补一句事实边界。
RULER 是 2024 年的论文，GitHub 仓库后来也补充了 Jamba-1.5、Qwen2.5/Qwen3、EXAONE 等更新模型结果。所以这些例子更适合用来理解“有效上下文”这个概念，不适合当成 2026 年最新模型排行榜来看。
新的模型还会不断出现，没必要死记谁排第几。
真正值得记住的是这个判断：上下文窗口是模型“最多能接收多少”，有效上下文才是模型“能稳定用好多少”。
4. 长上下文里，模型通常怎么出错？
论文还专门分析了 Yi-34B-200K 在更长输入和更复杂任务下的表现。
这些错误很有参考价值，因为我们日常用 AI 时也经常碰到类似情况。
第一种：看到了，但没找准
在简单 NIAH 任务里，模型可能接近满分。
但当“针”的类型变复杂，比如从数字变成 UUID，或者周围出现大量相似干扰项，错误就会变多。
论文提到，在很长的输入下，Yi 有时不能完整返回 32 位 UUID。
这说明模型不一定完全没看到。更可能是定位和复制精度不够。
我们让模型从长合同里抽合同编号、订单号、表格字段时，也会遇到这种问题：它大概知道答案在哪，但细节抄错了。
第二种：被干扰信息带偏
...(内容截断，完整内容请查看原文)
本页由自动化脚本生成，待人工审核补充