长上下文评测的五个时代：
从 NIAH 到状态、Agent 与评测科学

第一遍：这条评测路线到底在解决什么

1. 起点不是“长”，而是“检索”

2023 年流行的 Needle in a Haystack（NIAH）把一句事实藏进很长的无关文本，再要求模型把这句话找出来。它简单、可扩展、几乎不需要人工标注，因此迅速成为模型卡上的常客。问题也正出在这里：模型只要做字面匹配，就能在大多数位置拿到接近满分。高分证明的是“能找到”，不是“读懂了”。

Lost in the Middle 进一步把“位置”变成变量。它构造多文档问答和 key-value 检索，发现相关信息放在开头或结尾时效果最好，放在中间时显著下降，形成后来被反复引用的 U 形曲线。这个结果说明，长上下文能力至少包含“检索”和“利用位置”两个不同问题；单一平均分会把它们混在一起。该工作也是整个方向上影响力最大的论文之一，OpenAlex 引用约 3,460 次。

于是，评测设计开始分叉：一条路继续压榨合成检索，用多针、多跳、计数、干扰项和更长的 haystack 提高难度；另一条路转向真实文档，希望用自然任务补上生态效度。两条路后来并没有互相取代，而是变成了互相校准的工具。

2. RULER 把“长度”变成可调变量

NVIDIA 的 RULER 是第二代的分水岭。它把任务扩成 13 个、4 大类：检索、多跳追踪、聚合、问答；长度按 4K、8K、16K、32K、64K、128K 分档，同一套任务可以在不同长度上重复。这样一来，“模型在 128K 上还行”就不再是一句孤立的口号，而是一条可以画出来的曲线。

RULER 提出 effective context length：模型宣称支持多长，不等于它在这个长度上还能保持可用性能。论文评测 17 个长上下文模型，发现 NIAH 接近满分的同时，很多模型一旦长度增加就大幅掉点；宣称至少 32K 的模型里，只有约一半在 32K 仍能保持满意表现。这个结论后来被大量模型卡、技术报告和后续 benchmark 引用，也让“有效长度”成为长上下文讨论的常用词。

3. 真实文档套件补上生态效度

LongBench 是这一代的代表。它收集 21 个数据集，分成单文档问答、多文档问答、摘要、few-shot 上下文学习、合成任务、代码补全六类，英中双语；英文平均约 6,711 词，中文平均约 13,386 字符。它的价值不只是“更大”，而是把长上下文放回了真实任务分布：摘要、代码、多文档比较，和 NIAH 完全不是同一种能力。

L-Eval 走得更远。它用 20 个子任务、508 篇长文档、2,000 多个人工标注的 query-response，长度覆盖 3K 到 200K；同时指出 n-gram 指标和人类判断相关性很差，主张用 LLM judge 和更细的评分。ZeroSCROLLS 则把 SCROLLS 的零样本设定固定下来，只保留测试集和小验证集，避免训练集泄漏。BAMBOO 加入噪声鲁棒性，LooGLE 强调 2022 年之后的文档和长依赖，InfiniteBench 把平均长度推到 100K 以上。

这些套件共同暴露了一个新问题：真实任务不等于难度可控。不同数据集的长度、领域、问题类型、答案格式差异很大，平均分容易被某一类任务主导。HELMET 因此改成 7 个应用中心类别，把长度控制在 128K，评测 59 个长上下文模型；它发现 NIAH 分数不能预测下游表现，各类别之间相关性也不高，开源模型在全文推理和复杂指令上落后闭源，而且差距随长度扩大。LongBench v2 则把题目改成 503 道多项选择题，覆盖 8K 到 2M 词、六类场景；人类专家 15 分钟基线为 53.7%，直接回答的最佳模型为 50.1%，o1-preview 通过更长推理达到 57.7%。

4. 应用中心与长输出把评测拆开

2024 年之后，长上下文开始被当作产品能力，而不是单一模型属性。HELMET 用应用类别组织评测；AA-LCR 用 100 道高难题、约 72K 到 115K token 的真实文档，考多文档整合；Stanford HELM Long Context 用 5 个任务、每任务 100 个实例、上限 128K，对 10 个近期模型做统一比较。HELM 的结果很能说明问题：GPT-4.1 平均 0.588 最高，但最难的 MRCR 只有 0.256；长上下文排名与 HELM Capabilities 排名的 Spearman 相关为 0.90，说明它确实捕捉到了一部分通用能力，但远没有覆盖全部。

另一条线是长输出。LongWriter 发现模型很难稳定生成超过 2,000 词，提出 AgentWrite 做“计划 + 分段写作”，把输出推到 20,000 词以上，并构造 LongWriter-6k 训练数据和 LongBench-Write 评测。LongGenBench 把输出长度固定为 16K 和 32K，发现模型在 RULER 上很强、长文生成却很弱，输入长上下文能力与输出长文能力并不相关。LongProc 进一步把“长过程生成”拆成 6 个程序化任务，输出上限设为 500、2K、8K；HelloBench 用 5 类、58 个子类评长文生成，发现多数模型无法生成超过 4,000 词且保持质量。

领域套件也在同步出现：LongHealth 用 20 个虚构病例、400 道 MCQ 测临床长文档；DocFinQA 把金融问答的上下文从不到 700 词扩到平均 123K 词；MedOdyssey 覆盖 10 个医学数据集、7 个长度档（4K 到 200K）；CURIE 用 10 个任务、580 道题覆盖 6 个科学学科，最佳模型仅约 32%；MMLongBench-Doc 和 LongDocURL 把多页 PDF、跨页布局和不可答问题纳入评测；MTOB 则用一本语法书在上下文中学习极低资源语言 Kalamang，测试的是“从材料里学规则”，不是“从材料里找句子”。

5. 第五代：推理、状态、Agent 与评测科学

2025 年之后，最关键的变化是：评测对象从“能不能找到信息”转向“能不能使用信息”。Oolong 要求模型先对长文本做原子级分析，再聚合成分布性答案；它覆盖 4K 到 1M，合成与真实两个 split，GPT-5、Claude Sonnet 4、Gemini 2.5 Pro 在 128K 上都不到 50%。这类任务不能靠检索几个片段解决，必须做全局聚合。

MRCR 把“多针”推进到多轮共指：在 4K 到 1M 的上下文里放 2、4、8 个近似重复的请求，要求模型复现第 i 个请求的答案；评分用前缀命中和序列相似度。Context Arena 用 8-needle 变体做排行榜，52 个模型的 AUC@1M 最高仍不到 50%。这说明即使是最“检索”的能力，在百万 token 和多干扰项下也远没有解决。

状态跟踪是另一条更硬的分支。StateBench 用 Krohn-Rhodes 理论把状态跟踪分成四层：r-trivial、aperiodic、soluble、general finite；它证明 transformer 认为可以长度泛化的类并不包含全部 aperiodic，而 GDN 的正特征值可以表达所有 aperiodic。预训练模型没有人能稳健解决 soluble 层，前沿模型在最难、最长的设置下掉到 13% 以下。LEAPS 用 12 个新数据集把能力拆成 recall、state tracking、pattern learning，发现 recall 接近满分，但后两者随长度显著退化；thinking 模型有时因为耗尽生成预算或简化任务，反而低于 base 模型。

Agent 评测把上下文和环境合并。HANDBOOK.md 用 65 个 agentic 任务、5 个领域、10 家虚构公司、20 到 124 页的 SOP，配 82 个工具和 6 个 MCP server，构造 824 条程序化 rubric；严格评分下最强模型只有 36.2%，多数前沿模型低于 25%。LongSocialBench 用 94 个完整讨论串、1,462 道人类验证 MCQ，中位约 73K token，要求跟踪 parent-reply、转折点、子树和参与者轨迹；最佳模型 63.0%，人类 72.4%，给 gold evidence 后也只有 55.0%。LOCA-bench 和 AgentLongBench 则把上下文长度做成可控变量，分别从环境复杂度和 lateral puzzle rollout 切入。

最后是评测科学本身。Context Rot 用 18 个模型、8 个输入长度、11 个 needle 位置、194,480 次调用证明：任务不变，只是输入变长，性能也会下降；needle 与问题的相似度越低、干扰项越多、haystack 越结构化，退化越明显。100-LongBench 用 8 个任务、2K 到 256K、每个长度 100 个样本，提出 LongScore 剥离短上下文基线。LURCH 用 6,550 道题把难度拆成 evidence scope、evidence dispersion、reasoning depth；Positional Failures 审计 11 个流行 benchmark，发现它们没有同时控制任务位置、filler 内容和上下文长度；REALHOP 用 Behavioral Necessity Rate 检查“移除证据后答案是否真的失效”；KEEP-Bench 则专门测 context compression 是否保留了完整证据。

6. 影响力证据：三种读数不能混在一起

本文使用三类影响力信号。第一类是学术引用：OpenAlex 与 Semantic Scholar 的口径不同，前者更保守，后者通常更高；例如 RULER 在 OpenAlex 约 1,058 次、Semantic Scholar 约 1,616 次，LongBench 分别是约 1,108 和 1,926。第二类是工程采用：GitHub stars、模型卡、排行榜、后续论文是否把它当作默认套件。第三类是社区讨论：X/Twitter、Hacker News、Reddit、LinkedIn 上是否有可定位的帖子，以及讨论的是“方法新颖性”还是“实践痛点”。

这三类信号经常不一致。HELMET 的引用不算高，却被 Phi-4、Jamba 1.6 和 Stanford HELM 采用；NoLiMa 的引用不到 100，却在 r/LocalLLaMA 拿到 468 points、92 条评论；Context Rot 没有正式论文，却在 HN 拿到 260 points、59 条评论。反过来，一些引用很高的套件在社交媒体上几乎没有声音，因为它们是“基础设施”，不是“新闻”。因此，本文在每一节都尽量把“论文声称”“榜单采用”“社区反应”分开写，避免把三者压成一个分数。

以上是按材料顺序做的连续讲解。下面进入本文自己的结构化抽象、证据审计与独立判断。

第二遍：核心判断

长上下文不是一种能力，而是一组能力。检索、聚合、状态跟踪、长文生成、Agent 执行、抗干扰、位置鲁棒性，彼此相关但不等价；单一 128K 分数无法代表它们。

问题背景：为什么固定题库会失效

长上下文评测的核心困难不是“造更长的问题”，而是构造效度（construct validity）：分数上升，究竟说明模型更会读长文，还是说明它更会做这种题型、更会猜答案、更会利用位置先验？一个 benchmark 只要在这三个问题上说不清，分数越高反而越危险。

第一层失效是饱和。NIAH、早期多针检索和部分合成任务，在模型学会字面匹配后迅速接近满分；继续加长度只增加成本，不增加区分度。第二层失效是污染。真实文档和公开测试集可能进入预训练语料，模型不是“读懂了”，而是“见过”。第三层失效是长度与难度混杂。把同一道题从 4K 复制到 128K，可能只是增加 filler，难度并没有上升；反过来，一道 8K 的全局聚合题可能比 1M 的单针检索更难。

第四层失效是位置偏差。Lost in the Middle 的 U 形曲线说明，模型对开头和结尾更敏感；如果 benchmark 只把证据放在固定位置，分数会高估真实能力。第五层失效是评分。长文答案往往没有唯一形式，n-gram 与人类判断相关性差，LLM judge 又可能偏好风格；程序化 verifier 更硬，但构造成本高，而且可能只检查“最终文件存在”，不检查“过程是否正确”。第六层失效是波动。同一个模型、同一套题，换 seed、换 prompt、换 harness，排名就可能变化；Benchmark Volatility 这类工作正是把这种波动当成研究对象。

因此，一个可用的长上下文评测至少要回答四个问题：任务来源是合成还是自然？长度是固定档位还是可调？难度由什么属性驱动？评分由人、模型还是程序完成？这四个问题决定了分数的含义，也决定了它能不能迁移到产品。

五代图谱：从“找针”到“评测评测”

把 2023 到 2026 的工作按“它想解决的上一个方法留下的问题”排序，可以得到五代。代际不是严格时间线，很多工作跨两代；但它能解释为什么 benchmark 越做越复杂。

这条演进线有一个清楚的规律：每一代都在把上一代的“隐含假设”变成“显式变量”。NIAH 假设“找到就等于理解”，RULER 把长度和任务类型拆开；LongBench 假设“真实任务就等于真实能力”，HELMET 把应用类别和长度控制拆开；HELMET 假设“平均分能代表模型”，Oolong 和 StateBench 把聚合与状态拆开；Context Rot 则进一步把“长度本身”变成需要控制的变量。

评测机制：一个 benchmark 到底在测什么

把任何长上下文 benchmark 拆开，都能看到六个设计轴。它们的组合，比“多少道题、多长上下文”更能决定分数的含义。

最容易混淆的是“长度”和“难度”。把一道单针题从 4K 拉到 1M，增加的是搜索空间和位置干扰，不是推理深度；把一道多文档聚合题从 8K 拉到 128K，增加的是证据分散和整合成本。两者都叫“更长”，但对应不同机制。LURCH 把后者拆成 evidence scope、evidence dispersion、reasoning depth，并用固定长度实验证明：即使长度不变，这三个属性也与性能强负相关。StateBench 则把“状态跟踪”拆成形式语言层级，用 Krohn-Rhodes 理论解释为什么某些状态机天然更难。

评分同样不是中立的。精确匹配适合短答案，但会惩罚合理改写；LLM judge 适合开放式答案，但可能偏好长、流畅、格式漂亮的回答；rubric 更细，却依赖评分项设计；程序化 verifier 最硬，但如果只检查最终状态，模型可能学会绕过过程。HANDBOOK 用 824 条 rubric 把“期望输出”和“错误行为”分开，REALHOP 用 BNR 检查“移除证据后答案是否失效”，KEEP-Bench 用证据保留率检查压缩是否丢信息——这些都是把评分从“像不像”推向“是否真的做到”的尝试。

关键证据：80 余项工作怎么读

下面按任务族分组。表格负责覆盖面和横向比较，随后的“六个深读”负责机制和争议。引用量是 OpenAlex 口径（2026 年 11 月 9 日），与 Semantic Scholar 的差异在影响力一节说明；新论文引用为零通常只反映时间窗口，不构成质量判断。

6.1 合成检索与压力测试

这一族的共同点是“可控”：长度、针的位置、干扰项数量、证据链深度都可以调。它们最适合做机制分析和长度扫描，但最容易饱和，也最容易被字面匹配短路。

6.2 真实文档与统一套件

这一族用自然文档、人工标注和统一评测协议补生态效度。它们的强项是“像真实工作”，弱项是“变量太多”：长度、领域、题型、答案格式一起变化，平均分很难归因。

6.3 推理、状态、记忆与 Agent

这一族把“上下文”从静态文本变成状态、对话或环境。评测问题也随之变化：不是“答案在不在”，而是“模型能不能在多步交互中保持状态、更新信念、发现证据不足”。

6.4 长输出、指令跟随与安全

长输入是“读”，长输出是“写”。这一族把输出长度、结构、指令覆盖和安全放在同一张表里，补上了 LongBench 类套件不测的生成能力。

6.5 领域、代码、多模态与跨语言

领域套件的价值不在“再做一个 LongBench”，而在把领域约束变成评分：临床否定、金融表格、代码仓库结构、多页 PDF 布局、极低资源语言的语法规则，都会让“通用长上下文能力”暴露出不同侧面。

6.6 方法论审计：评测本身成为对象

这一族不新造任务，而是检查已有 benchmark 是否真的在测它声称的东西。它们往往引用不高，却会改变你读榜的方式。

6.7 六个深读：争议、数字与边界

RULER：把“有效长度”变成公共语言

RULER 的贡献不只是 13 个任务，而是把“长度”从模型卡的一个数字变成了可测曲线。它的四类任务覆盖检索、多跳追踪、聚合、问答；每一类都可以在 4K 到 128K 重复。NIAH 在短长度上接近满分，但一到长长度和多跳，模型就开始掉点；这说明“能找针”与“能用多条针推理”不是同一件事。

它最常被引用的是 effective context length：宣称 128K 的模型，可能在 32K 或 64K 就已经明显退化。论文里“宣称至少 32K 的模型中只有约一半在 32K 保持满意表现”这个结论，后来被大量技术报告复述。需要注意的是，RULER 的任务是合成的，分数不能直接外推到真实办公文档；它更像“压力测试”，不是“能力终点”。

HELMET：NIAH 不能预测下游

HELMET 用 7 个应用类别、至少 128K 的输入、59 个长上下文模型，做了一次系统对照。它最重要的结论不是“谁第一”，而是“NIAH 分数不能预测下游表现”：在 NIAH 上接近满分的模型，到了全文推理、复杂指令、应用问答上可能完全不同；不同类别之间的相关性也不高。这意味着“长上下文能力”不是一个单因子，至少要多轴报告。

HELMET 还发现，开源模型在全文推理和复杂指令上落后闭源，而且差距随长度扩大。这个结论后来被 Phi-4、Jamba 1.6 等模型采用为评测依据，也被 Stanford HELM 列为参考。它的局限是应用类别仍偏英文办公，model-based 评分有成本，base model 兼容性也需要额外处理。

LongBench v2 与 LongBench Pro：真实感与可控性之间的拉扯

LongBench v2 用 503 道 MCQ、六类场景、8K 到 2M 词，把“真实长上下文”做得更接近工业使用。它的人类专家基线是 53.7%，直接回答的最佳模型 50.1%，o1-preview 通过更长推理达到 57.7%。这个结果很微妙：模型在“直接答”上还不如人类，但一旦允许长推理，就能超过人类基线；说明“长上下文”与“长推理”经常纠缠在一起。

LongBench Pro 则把规模推到 1,500 个自然样本、11 个主任务/25 个子任务、8K 到 256K、46 个模型。它的结论更像产品建议：长上下文优化比参数规模更重要；有效长度普遍短于宣称，而且跨语言不一致；thinking 主要帮原生 reasoning 模型，mixed-thinking 是 Pareto 折中。它和 v2 的差异，正好说明“真实样本”与“可控长度”很难同时最大化。

NoLiMa 与 MRCR：检索还没有结束

NoLiMa 的做法很巧：去掉 needle 与 haystack 的字面重叠，要求模型做一步联想。结果在 32K 就出现大幅掉点：GPT-4o 从 99.3% 降到 69.7%，Llama 3.3 70B 从 97.3% 降到 42.7%。这说明很多“长上下文能力”其实是“关键词匹配 + 位置先验”；一旦需要语义关联，曲线就塌了。它在 r/LocalLLaMA 拿到 468 points、92 条评论，说明工业界对“32K 就崩”这件事有强共鸣。

MRCR 则把多针推到多轮共指：2/4/8 个近似重复请求，4K 到 1M，要求复现第 i 个请求的答案。Context Arena 用 8-needle 变体做排行榜，52 个模型的 AUC@1M 最高仍不到 50%。社区里有人用开源 Qwen2.5-32B 栈在 1M 8-needle 上跑到 0.601–0.688，接近 SubQ 的 0.659；这类实测比论文更能说明“百万上下文”在工程上有多脆弱。

Oolong 与 StateBench：从“找”到“聚合/状态”

Oolong 的任务设计是“先分析、再聚合”：模型需要判断大量原子事实的分布，再回答一个全局问题。它覆盖 4K 到 1M，合成与真实两个 split；GPT-5、Claude Sonnet 4、Gemini 2.5 Pro 在 128K 上都不到 50%。这比 NIAH 难得多，因为答案不在某个片段里，而在整个分布的统计中。它的局限是构造复杂、真实 split 规模有限，但方向很清楚：长上下文的下一阶段是“全局计算”，不是“局部检索”。

StateBench 则把状态跟踪做成形式语言层级：r-trivial、aperiodic、soluble、general finite。它用 Krohn-Rhodes 理论解释为什么某些状态机天然更难，并证明 GDN 的正特征值可以表达所有 aperiodic。实验里，预训练模型没有人能稳健解决 soluble 层，前沿模型在最难、最长的设置下掉到 13% 以下。这个结果的重要性在于：它不是“再多几条数据”能解决的，而是涉及模型架构与算法能力。

HANDBOOK 与 LongSocialBench：Agent 评测的“真实工作”

HANDBOOK.md 用 65 个任务、5 个领域、10 家虚构公司、20 到 124 页的 SOP，配 82 个工具、6 个 MCP server、824 条 rubric，把“长上下文”放进真实工作流。最强模型 36.2%，多数前沿模型低于 25%；失败模式包括被环境内请求诱导覆盖政策、检查后违背结果、长程丢失规则细节、谎报合规。这些失败不是“读不懂”，而是“在长流程中保持约束”。

LongSocialBench 把评测放到真实讨论串：94 个 HN/Stack Exchange/r/ChangeMyView 讨论，1,462 道人类验证 MCQ，中位约 73K token。模型要跟踪 parent-reply、转折点、子树、跨分支对比、参与者轨迹；最佳模型 63.0%，人类 72.4%，给 gold evidence 后也只有 55.0%。这说明“长上下文理解”不仅是文本长度，还包括对话结构、参与者意图和上下文指代。

影响力：引用、采用与社区

影响力不是一个数。下面把三类证据分开：学术引用、工程采用、社区讨论。引用量取自 OpenAlex（2026 年 11 月 9 日），GitHub stars 为同一时间窗口；两者都只是快照，不是终局。

引用量：基础设施型工作占据顶部

GitHub stars：工具与数据比论文更容易传播

采用：模型卡、排行榜和后续论文比引用更早说明问题

RULER 和 LongBench 是最典型的“基础设施型”影响：它们不一定有 viral 帖，但模型卡、技术报告和后续 benchmark 会把它们当作默认对照。HELMET 被 Microsoft Phi-4、AI21 Jamba 1.6 和 Stanford HELM 采用；MRCR 被 OpenAI 数据集、Context Arena 和 HELM 采用；AA-LCR 有独立排行榜；Context Rot 被工业界用来解释“为什么长上下文产品会变差”。这些采用信号通常比引用量更早出现，也更接近工程决策。

反过来，一些引用很高的论文并没有形成持续的工具生态。例如 Lost in the Middle 的影响力主要是概念性的：它改变了所有人对位置偏差的认知，但很少有人直接拿它的代码做产品评测。评价一个 benchmark 时，最好同时看“是否被模型卡引用”“是否有维护中的排行榜”“是否有后续工作用它做对照”，而不是只看一个数字。

X/Twitter、HN 与 Reddit：实践痛点比学术新颖性更容易出圈

选型建议：按能力目标，而不是按榜单排名

如果你要选一套长上下文评测，先明确目标：是模型研发、产品验收、Agent 训练，还是学术研究？不同目标对“真实感、可控性、成本、可复现”的权重完全不同。

一套最小可落地评测协议

1. 定义能力剖面。至少分检索、聚合、状态跟踪、长输出、抗干扰五类；不要用一个总分代替。
2. 做长度网格。4K、8K、16K、32K、64K、128K、256K；同一任务重复，画曲线，不只看单点。
3. 合成 + 自然混合。合成任务控变量，自然任务补生态效度；两者分数不一致时，优先信自然任务的方向，但用合成任务解释机制。
4. 控制位置与干扰。关键证据至少放开头、中间、结尾；加入 1 个和 4 个 distractor；报告位置敏感性。
5. 评分双轨。程序化/精确匹配 + LLM judge/人工抽检；对 judge 做一致性检查，报告评分器版本。
6. 污染检查。时间截止、动态构造、私有测试或 canary；至少做一次“删掉证据”的反事实。
7. 报告成本与方差。token 数、调用次数、金额、重复次数、置信区间；不要只报最好一次。
8. 系统级复现。固定 harness、prompt、RAG/上下文管理策略；同一模型换 harness 也要重测。

术语与概念

边界与风险

• 合成与真实的缺口。RULER、BABILong、NoLiMa 等合成任务能控变量，但不能直接代表真实办公、法律、医疗文档；LongBench、HELMET 等自然任务更真实，却难以分离长度、领域和题型。
• 论文声称与独立复现。表中的规模、通过率、提升幅度多来自论文或项目方；本文只对少量差值做算术复算，没有重跑大规模训练或评测。尤其是 Agent 环境、LLM judge 和长输出评分，复现成本很高。
• 引用滞后。2026 年的新工作（StateBench、HANDBOOK、LURCH、LEAPS、LongSocialBench 等）引用几乎为零，但社区/工业关注可能已经发生；不能用引用量判断其价值。
• 榜单自报。AA-LCR、Context Arena、HELM 等榜单的提交结果可能由厂商自报，配置、prompt、成本口径不一定完全一致；跨榜比较要谨慎。
• 社区证据不穷尽。X/Twitter 完整搜索需要登录或 API，Altmetric 需要密钥；本文只收录可定位的代表性帖子，不能据此估计总讨论量。
• 语言与模态偏差。英文/中文覆盖最多，低资源语言、长视频、长音频、多模态文档仍不足；多语言 token 数也不可直接比较。
• 系统混淆。同一个模型换 harness、RAG、上下文压缩策略，分数和成本都会变化；把“模型能力”与“系统能力”混为一谈，会高估或低估模型。

研究启发：下一步该做什么

第一，把评测从“数据集”变成“能力剖面”。一个模型在 128K 检索上很强，不代表它能做全局聚合、状态跟踪或长文生成。ATLAS、LEAPS、LURCH 的思路值得借鉴：用多个能力维度、多个长度档位和难度属性，画出一张剖面图，而不是一个总分。

第二，把难度从长度里剥离出来。LURCH 的 evidence scope/dispersion/reasoning depth、StateBench 的状态机层级、REALHOP 的证据必要性，都是把“难”拆成可解释变量。下一步需要更多“等长但不同难度”的对照实验，否则我们无法判断分数提升来自能力，还是来自更多 token。

第三，把长输出和长输入分开建榜。LongGenBench、LongProc、HelloBench 已经证明两者不相关；但多数模型卡仍只报长输入。一个完整的长上下文模型报告，至少应包含：长输入理解、长输出生成、长上下文指令跟随、长上下文安全四个维度。

第四，把评测科学做成基础设施。位置控制、污染检测、方差报告、成本核算、harness 固定，应该像单元测试一样默认执行。Context Rot、100-LongBench、Positional Failures、Benchmark Volatility 已经给出方法；下一步是把它们产品化，而不是每篇论文重新发明。

第五，关注三个开放问题。状态跟踪的理论边界（哪些结构 transformer 天然学不会）、Agent 环境的真实性与可验证性（如何避免“出题人已经把活干完”）、多语言/多模态的评测公平性（token 数、文化语境、解析质量）。这三个问题都比“再把上下文拉到 10M”更有信息量。

证据边界与资料索引

本文综合 arXiv 论文、ACL/ICLR/NeurIPS 论文页、官方项目页、公开排行榜与可定位的社区帖子。规模、通过率、训练提升和成本多为论文或项目方报告；本文只做少量算术复算，没有重跑大规模训练或 benchmark。引用量为 OpenAlex 口径（2026 年 11 月 9 日），与 Semantic Scholar 存在差异；GitHub stars 为同一时间窗口。新论文引用为零通常只反映时间窗口，不构成质量判断。社区讨论只选取可定位的代表性材料，不代表穷尽。

综述、榜单与评测科学

• A Comprehensive Survey on Long Context Language Modeling
• Is It Really Long Context if All You Need Is Retrieval?
• Lost in the Middle: How Language Models Use Long Contexts
• Positional Failures in Long-Context Benchmarks
• Benchmark Volatility in Long-Context Evaluation
• A Survey of Benchmark Compression
• Context Rot: How Increasing Input Tokens Impacts LLM Performance
• Stanford HELM Long Context
• Context Arena
• Artificial Analysis

合成检索与压力测试

• RULER: What's the Real Context Size of Your Long-Context Language Models?
• NVIDIA/RULER
• BABILong: Testing the Limits of LLMs with Long Context Reasoning-in-a-Haystack
• Counting-Stars: A Multi-evidence, Position-aware, and Scalable Benchmark
• NeedleBench: Can LLMs Do Retrieval and Reasoning in 1 Million Context Window?
• NoLiMa: Long-Context Evaluation Beyond Literal Matching
• adobe-research/NoLiMa
• Michelangelo: A Natively Multimodal Foundation Model
• OpenAI MRCR dataset
• Needle Threading: Can LLMs Follow Threads through Near-Million-Scale Haystacks?
• NeedleChain: Benchmarking Long-Context Reasoning
• U-NIAH: Unified RAG and Long-Context Evaluation
• Oolong: Evaluating Long Context Reasoning and Aggregation Capabilities
• LongReason: A Synthetic Long-Context Reasoning Benchmark
• MIR-Bench: Benchmarking LLM's Long-Context Intelligence via Many-Shot In-Context Inductive Reasoning
• PRELUDE: A Benchmark for Global Understanding and Reasoning
• GraphNIAH: Contamination-Resistant Long-Context Evaluation
• ATLAS: A Capability Atlas for Long-Context Models
• LEAPS: Recall, State Tracking, and Pattern Learning
• LURCH: Beyond Context Length
• PredicateLongBench
• 100-LongBench

真实文档与统一套件

• ZeroSCROLLS
• LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding
• THUDM/LongBench
• L-Eval: Instituting Standardized Evaluation for Long-Context Language Models
• BAMBOO: A Comprehensive Benchmark for Evaluating Long Text Modeling Capacities
• LooGLE: Can Long-Context Language Models Understand Long Contexts?
• LooGLE v2
• Loong: Synthesize Long Contexts from Scratch
• LV-Eval: A Balanced Long-Context Benchmark
• InfiniteBench: Extending Long Context Evaluation Beyond 100K Tokens
• CLongEval: A Chinese Benchmark for Long-Context Language Models
• LongBench v2: Towards Deeper Understanding and Reasoning on Realistic Long-Context Multitasks
• LongBench v2 project page
• HELMET: How to Evaluate Long-Context Language Models Effectively and Thoroughly
• princeton-nlp/HELMET
• LongBench Pro
• LOFT: Can Long-Context Language Models Subsume Retrieval, RAG, SQL, and More?
• Ada-LEval
• MLRBench: Multilingual Long-Context Reasoning Benchmark
• MGAL: Multilingual Granularity-Aware Long-Context Benchmark
• Ref-Long: Benchmarking Long-Context Referencing
• AA-LCR

推理、状态、记忆与 Agent

• LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory
• xiaowu0162/LongMemEval
• LoCoMo: Evaluating Very Long-Term Conversational Memory of LLM Agents
• snap-research/locomo
• MemoryAgentBench: Evaluating Memory in LLM Agents
• BEAM: Beyond a Million Tokens
• DiaLong: Long Dialogue Memory Benchmark
• HANDBOOK.md: Agentic Tasks from Realistic SOPs
• LongSocialBench: Long-Context Understanding of Online Discussions
• AgentLongBench
• LOCA-bench: Controlling Context Growth for Agents
• StateBench: A Fine-Grained Hierarchy and Benchmark for State Tracking
• Ai2 StateBench blog
• allenai/state-bench
• LongHarness Bench
• REALHOP: Behavioral Necessity in Multi-Hop Reasoning
• KEEP-Bench: Evidence Preservation in Context Compression
• LongPIBench: Prompt Injection in Long Contexts

长输出、指令与安全

• LongWriter: Unleashing 10,000+ Word Generation from Long Context LLMs
• THUDM/LongWriter
• LongGenBench: Long-Context Generation Benchmark
• LongProc: Benchmarking Long-Context Language Models on Long Procedural Generation
• HelloBench: Evaluating Long Text Generation
• LongEval: A Plan-Based Framework for Long Text Generation
• ExpertLongBench
• WritingBench: A Comprehensive Benchmark for Generative Writing
• LIFBench: Evaluating Long-Context Instruction Following
• LIFEBench: Length Instruction Following
• LongIns: A Challenging Long-Context Instruction Following Benchmark
• LongSafety: Evaluating Long-Context Safety

领域、代码、多模态与跨语言

• RepoBench: Benchmarking Repository-Level Code Auto-Completion
• Long Code Arena
• DocFinQA: A Long-Context Financial Reasoning Benchmark
• LongHealth: A Question Answering Benchmark with Long Clinical Documents
• MedOdyssey: A Medical Long-Context Benchmark
• CURIE: Scientific Long-Context Understanding
• MTOB: Machine Translation from One Book
• LongDocURL: A Comprehensive Multimodal Long Document Benchmark
• MMLongBench-Doc: Benchmarking Long-Context Document Understanding with Multimodality
• LongBanana: Multi-Reference Image Generation in Long Context
• NoCHA: Benchmarking Long-Context Understanding with Books

公开讨论样本

• r/LocalLLaMA: NoLiMa discussion
• Hacker News: Context Rot discussion
• Hacker News: NoLiMa discussion
• @abertsch72 on HELMET model gap
• @no_stp_on_snek on MRCR v2 1M
• RLM thread on Oolong