厂商公布的上下文窗口数字一年比一年大——32K、128K、200K，甚至到了 100 万 token。但”能接收多长”和”能记住多少、用得对不对”是两回事。本文不重复讲 Needle-in-a-Haystack 的测试原理（这部分可参考 NIAH 实测方法与结果解读），而是聚焦一个更实际的问题：在同一套横向对比标准下，主流模型的长上下文召回能力到底差多少，衰减规律是什么样的。

免责声明：本文涉及的具体分数为行业公开测试与社区评测的量级整理，不代表任何厂商官方数据，仅作横向对比参考，请以实际业务场景测试为准。

一、为什么”上下文窗口”和”召回能力”要分开看

上下文窗口是一个硬件/架构指标：模型的注意力机制和位置编码方案能否处理这么长的输入序列。召回能力是一个效果指标：在这么长的输入里，模型能不能准确定位并使用某个具体信息。

两者不是线性关系。常见的几种偏差模式：

• 窗口够大，但中段丢失：经典的”lost in the middle”现象——文档开头和结尾的信息召回率高，中间部分显著下降
• 单针召回好，多针召回差：只测一条孤立信息时表现很好，但如果需要同时召回并综合多条分散信息，正确率大幅下滑
• 格式敏感：同样的信息，放在结构化表格里比放在自然语言段落里更容易被召回
• 干扰项敏感：haystack 中如果包含与 needle 主题相近的干扰句，召回率会明显下降，这比纯随机文本背景更接近真实业务场景（比如从多份相似的合同里找一条条款）

单纯看”支持 100 万 token”这个数字，完全无法判断这些偏差模式是否存在。

二、横评设计：四个维度

为了让对比有意义，横评需要控制变量。以下是一套可复现的设计思路：

维度	具体设置	目的
上下文深度	10% / 30% / 50% / 70% / 90% 位置插针	检测位置偏差
上下文长度	8K / 32K / 128K / 500K / 1M token	检测长度衰减曲线
针的数量	单针 / 3 针分散 / 3 针需综合回答	检测多信息整合能力
干扰强度	无干扰 / 同主题干扰句	检测抗噪能力

真正拉开模型差距的往往不是”单针在 8K 里能不能找到”（这个几乎所有主流模型都能做到接近满分），而是长度拉到窗口上限附近、且需要多针综合的组合场景。

三、几个行业观察（基于公开评测量级）

以下结论综合自公开的评测报告和社区复现结果，具体分数会随模型版本更新变化，重点看相对差距和规律而非绝对数字：

观察一：单针召回已经不是差异化指标。 目前主流一线模型（Claude、GPT、Gemini 系列）在标准单针 NIAH 测试上普遍能做到 95% 以上，这项测试的区分度已经很低，不适合作为选型依据。

观察二：多针综合是真正的分水岭。 当需要同时召回 3 条分散信息并综合回答时，各模型的分数开始明显拉开，部分模型会出现 20–30 个百分点的下降。这更接近真实业务场景——比如”从这份 200 页的年报里，找出三次提到营收指引的地方，并判断是否前后矛盾”。

观察三：窗口上限附近的表现普遍打折扣。 不管厂商宣称支持多长的上下文，实测中，接近窗口上限（比如声称支持 100 万 token，实测在 80–100 万区间）的召回准确率往往比窗口中段（比如 30–50 万）更低。这意味着”能用”和”好用”之间有一个安全余量，实际生产场景不建议长期跑在窗口上限附近。

观察四：中文长文档的召回率普遍低于英文。 在同等 token 长度下，中文文档（尤其是包含大量专有名词、古文引用或代码混排的场景）的召回准确率通常比纯英文场景低几个百分点，这和训练语料的语言分布有关。

关于具体某个模型的 1M 上下文实测数据，可参考 Claude Opus 1M 上下文真实测试 和 Claude 1M 上下文使用指南。

四、常见的评测陷阱

做横评或者看别人的横评结果时，容易踩这几个坑：

陷阱一：不同模型用不同的 haystack

如果 A 模型测试用的干扰文本是维基百科条目，B 模型用的是小说，两者的召回难度天然不同。公平对比必须用完全相同的 haystack 文本和插针位置。

陷阱二：忽略输出长度限制

有些”召回失败”其实是模型输出被截断导致的，不是真的没找到信息。测试时要确认 max_tokens 设置足够大，且检查是否命中了模型的输出长度上限。

陷阱三：把”一次性通过”当作稳定表现

长上下文任务的输出具有一定随机性，同一个 prompt 跑 5 次，分数可能波动 5–10 个百分点。可靠的横评应该多次采样取平均，单次结果不能代表真实水平。

陷阱四：忽略成本维度

100 万 token 的输入，即便召回率很高，单次调用的成本和延迟也可能高到不适合生产环境。召回能力横评应该和 长文本处理的 token 成本 一起看，脱离成本谈”哪个模型长上下文最强”意义有限。

五、自建横评的最小实现思路

如果想针对自己的业务场景（而不是通用 haystack）做横评，可以按这个思路搭一个最小版本：

1. 准备业务真实文档（脱敏后），而不是通用背景文本
2. 在文档不同位置插入 3-5 条业务相关的"针"信息
   （比如合同里的违约条款、财报里的关键数字）
3. 设计需要综合多条针才能正确回答的问题
4. 对每个候选模型，固定 prompt 模板和 temperature，跑 5 次取平均
5. 记录：准确率 + 平均延迟 + 单次调用成本
6. 按业务场景权重，给准确率/延迟/成本加权打分

这套流程比直接套用公开 benchmark 更有参考价值，因为它反映的是你的文档类型和你的问题模式下的真实表现，而不是通用测试集的表现。

六、给不同场景的选型建议

• 单据/合同关键信息提取（信息量小，位置固定）：主流模型都能胜任，优先看成本和延迟
• 长会议纪要/客服记录摘要（信息分散，需要多点综合）：优先选多针召回测试中表现稳定的模型，必要时结合 RAG 方案 分段处理，不要完全依赖单次超长上下文
• 代码库级别的问答（结构化强，但上下文极长）：可以参考 向量数据库对比，用检索增强而非纯堆上下文的方式降低成本和提升准确率
• 法规/年报等严肃文档分析：务必自建横评（第五节的方法），不要直接信任厂商宣传的窗口大小

七、相关阅读

• LLM 长上下文 Needle-in-a-Haystack 实测方法与结果解读
• Claude Opus 4.7 1M 上下文真实测试
• Claude 1M 上下文使用指南
• 向量数据库对比 2026
• RAG 国内最佳实践

想横向测试不同模型在长上下文场景下的真实表现，YoTradeApi 提供 Claude、GPT、Gemini 等主流模型的统一 API 中转，一套 key 即可快速搭建自己的横评脚本。