
有效上下文长度问题:为什么100万Token其实没有100万Token
宣传具有100万或1000万Token上下文窗口的模型,并不能在整个范围内保持有用的检索准确率。本文讲解"有效上下文"究竟意味着什么、为什么它对生产部署很重要,以及如何针对这一差距进行设计。
到2026年,多款主要的开放权重模型都宣传具备100万Token或更长的上下文窗口。Llama 4 Scout声称1000万。DeepSeek V4、MiMo V2.5 Pro、Llama 4 Maverick以及多款Qwen变体都宣称支持1M Token。在面向全代码库推理、长文档分析、多文档综合等用例的营销之下,这些数字听起来颇具变革性。
现实更为微妙。宣传的上下文长度并不等同于有效上下文长度,而二者之间的差距在每一款现有模型上都很可观。在不理解有效上下文的情况下,依据宣传数字 搭建生产部署的团队,往往会发现他们的用例在狭义的技术意义上"能跑通",但实际效果显著低于他们的预期。
本文讲解"有效上下文"究竟意味着什么、推动这一差距的"中段迷失"现象的研究证据,以及在生产部署中针对这一限制进行设计的实用指南。
"有效上下文"是什么意思
有效上下文长度,是指模型在长上下文任务中仍能保持可用检索准确率的那一部分宣传上下文窗口。衡量它的标准方法是大海捞针(Needle-In-A-Haystack,NIAH)基准:把一段特定信息插入长上下文中的某个已知位置,然后让模型把它检索出来。通过将插入信息的位置在不同点上变化,可以把检索准确率作为位置的函数测量出来。
几乎所有当前模型上的结果都遵循一个一致的模式:
- 位于上下文开头的信息以接近100%的准确率被检索
- 位于上下文末尾的信息以接近100%的准确率被检索
- 位于上下文中段的信息检索准确率显著下降——通常比开头/末尾的基线低10-25%
这一模式有时被称为"中段迷 失"(lost in the middle),在多个模型家族上都有充分文献记载。它不是某个具体实现的怪癖——它似乎是基于注意力的架构在标准数据分布上训练时的根本性特征。
实践含义是:宣传支持1M Token的模型,其有效上下文可能在10万至30万Token之间(即在所有位置上都能保持90%以上检索准确率的范围)。超出这个范围后,中段信息丢失会严重到让真正需要长上下文推理的生产用例产生比宣传上下文长度所暗示更糟的结果。
为什么会这样
中段迷失的模式有几个促成因素:
训练数据分布。 多数预训练数据具有自然结构,关键信息出现在开头附近(引言、标题、摘要)或末尾附近(结论、行动事项)。模型在训练中学会更激进地关注开头与末尾位置,这种注意力模式即便应用到关键信息位于中段的人为构造长上下文上也会保留。
位置编码的局限。 RoPE(旋转位置编码)以及类似的位置编码会随上下文长度增长而质量下降,尤其是接近最大训练长度的位置。这影响所有位置,但在位置歧义最关键的中段往往表现得更明显。
有效秩限制。 深层Transformer注意力矩阵呈现有限的有效秩——模型 用于跨Token关系的"工作记忆"被限制在一个不会随原始上下文长度线性扩展的范围内。随着上下文增长,模型越来越依赖启发式模式(邻近性、结构线索)而非完整的注意力覆盖,导致缺乏强结构锚点的中段信息丢失。
量化的叠加效应。 多数生产部署使用4位(Q4_K_M)量化。量化误差在深层注意力中累积,且这种累积往往对中段检索的劣化大于对开头/末尾检索的劣化。在FP16上长上下文NIAH表现尚可的模型,在Q4_K_M下表现可能显著变差,而这种效应在基准报告中很少被传达。
架构改进:DeepSeek 稀疏注意力及其他
若干2026年代的模型引入了能在不改变宣传上限的前提下显著提升有效上下文长度的架构创新。最显著的例子是DeepSeek稀疏注意力(DeepSeek Sparse Attention,DSA),首次出现在DeepSeek V3.2中并延续至V4。
DSA是一种学习得到的稀疏注意力机制——不再让每个查询Token关注所有键Token(标准模式),而是让模型学习哪些键Token对每个查询是相关的,并仅向该子集路由注意力。这产生两个效果:大幅降低长上下文注意力的计算成本,同时由于模型不再尝试同时维持对整个上下文的注意力覆盖,有效上下文保持也得到改善。
DeepSeek V4在1M宣传Token下的有效上下文, 明显优于在相同宣传长度下采用朴素RoPE扩展的模型。我们没有恰好在1M边界上、值得作为权威结论的公开NIAH测量值,但真实生产部署中的定性表现与架构预测一致:V4在其宣传上下文中保持可用检索质量的范围更深。
这一领域还有其他正在出现的架构创新——Mamba-Transformer混合体(Falcon H1R)、配合全局注意力汇点的滑动窗口机制(多款模型)、能更干净扩展已训练上下文长度的位置插值方法。它们都没有彻底填平宣传与有效上下文之间的差距,但每一项都在缩小它。
对生产部署而言,这意味着正确的比较不只是"哪个模型宣传的上下文最长",而是"在我具体的用例上,哪个模型的有效上下文最长"。在真实长上下文检索任务上,DeepSeek V4配DSA的1M经常胜过没有类似架构创新的Llama 4 Scout的1000万。
如何为你的用例进行测量
最有用的评估是为你具体工作负载测量有效上下文,而不是依赖合成的NIAH基准。基本方法:
第1步:构造具有代表性的长上下文输入。 使用你生产工作负载中的真实样本——实际的文档、代码库、转录或任何与你用例相关的内容。不要使用为以人为方式给模型施压而设计的合成输入。
第2步:在不同位置范围内确定检索目标。 针对每个长上下文输入,确定一组事实陈述或具体细节,模型必须检索它们才能正确处理输入。记录每条事实在上下文中出现的位置(以Token为单位)。
第3步:运行模型并按位置测量检索准确率。 对每个检索目标,在完整上下文上运行模型,并提出一个需要检索该目标才能作答的问题。对回答打分,看其是否正确检索到目标。把准确率作为目标位置的函数进行追踪。
第4步:找到拐点。 你用例的"有效上下文长度",约等于检索准确率仍高于你可接受阈值(通常为90%或95%)的最长位置。超过这一位置后,模型的劣化会带来明显的生产质量问题。
这套方法比看宣传数字繁琐,但它是了解模型在你真实工作负载上将如何表现的唯一可靠方式。模型在不同内容类型上的有效上下文可能差异显著——在自然语言文档上有效上下文很强的模型,在代码上可能表现不佳,反之亦然。
围绕差距进行设计
一旦你了解了自己工作负载的有效上下文,几个设计模式能在输入超过该范围时仍维持质量:
把关键信息放在长提示的开头与 末尾。 这是最重要也最容易应用的模式。如果你在执行长上下文RAG查询,把最相关的检索片段放在上下文开头与末尾,把不那么关键的信息(或摘要)放在中段。模型对开头与末尾位置更强的注意力会放大放在那里的关键信息的重要性。
用摘要替代拼接。 不要把完整的长文档塞进上下文,而是为不太关键的部分生成摘要,并仅在长上下文提示中包含这些摘要。这能减少总上下文长度,缓解中段迷失效应,同时保留模型处理查询所需的信息密度。
使用分级检索。 不要把所有检索内容放进单个长上下文提示,而是采用分级检索模式:先在粗粒度上识别最相关的部分,然后仅从这些部分中检索详细内容,并把聚焦的细节内容放进模型的有效上下文窗口。
把长程任务分散到多次智能体运行中。 对于确实需要在超出有效上下文容量的信息上进行推理的工作流,使用多智能体或多调用模式:让每次单独调用都在有效上下文范围内运行,再由协调者模式聚合结果。Kimi K2.6的Agent Swarm是这一模式特别激进的范例,但其总体思路适用范围更广。
针对长上下文模式进行微调。 如果长上下文性能对你的生产用例至关重要,把长上下文样本纳入微调训练数据可以可量度地改善真实世界的有效上下文。这是领域特定微调能显著超越基础模型能力的领域之一——模型会学到你工作负载的具体模式,包括关键信息在你真实文档中是如何 组织的。
实用建议
对多数关注长上下文的生产部署,我们的建议是:
-
把宣传的上下文长度视为上限,而非操作范围。 一个1M Token模型对需要20万至50万Token有效上下文的用例确实有用。它很少适合真正需要1M Token有效上下文的用例。
-
优先考虑架构创新而非宣传的最大值。 一个采用DSA或类似有效上下文保持创新、宣传1M的模型,在真实生产工作负载上通常优于一个朴素架构、宣传1000万的模型。
-
承诺前为你的工作负载测量有效上下文。 上面的方法虽然繁琐,但在部署质量与运维可预测性上的回报相当可观。
-
针对中段迷失模式来设计提示。 关键信息放开头与末尾、摘要放中段、合适场景下用分级检索。这些模式相对朴素拼接而言基本是免费的质量提升。
-
针对长上下文模式进行微调。 Ertas Studio支持长上下文微 调工作流,包括法律、金融与工程应用中常见的结构化内容模式。在你具体工作负载上,有效上下文的提升通常超过你换用一个上下文宣传值更大但未微调的模型所能获得的提升。
宣传的上下文长度数字对理解模型的大致能力档次有用,但它们不是你应据以设计的运维规格。有效上下文——在你的工作负载、你的量化等级、你的提示结构下测量出来的——才是决定真实生产质量的指标。围绕它做设计,中段迷失问题就会变得可控,而不再神秘。
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading

Mixture of Experts in 2026: From Mixtral to DeepSeek V4
MoE has become the default architecture for flagship open-weight models in 2026 — DeepSeek V4, Kimi K2.6, MiMo V2.5 Pro, GPT-OSS, Mistral Small 4 all use it. Here's why, how the design choices have evolved, and what it means for production deployments.

RAG Pipeline Failure Modes: A Field Guide for Production Debugging
A comprehensive catalog of RAG failure modes with symptoms, root causes, and fixes. Built from real production incidents and community discussions.

Bad Chunks Poison RAG Answers: A Debugging Guide to Chunking Quality
How poor chunking strategy degrades RAG output quality. Real examples of bad chunks, diagnosis techniques, and fixes for common chunking failures.