Claude 200K上下文信息召回率实测与分析

如果你把一份接近20万字的文档直接扔给Claude，然后指望它能精准地找出某个藏在中间的关键信息，结果可能会让你有点意外。实际情况是，它的“记忆力”并不均匀。

一系列独立测试揭示了其中的规律：模型对文档开头和结尾的内容记得更牢，而对中间部分的信息，召回率会出现显著下降。这并非偶然，而是长上下文处理中的一个结构性挑战。

一、文档位置如何影响信息召回？

记忆强度随位置变化的现象非常明显。简单来说，信息在文档中的“住址”决定了它被模型“想起”的几率。这种衰减在文档长度超过9万字后开始加速，成为召回率下降的主因。

为了量化这一点，测试人员在一份长达20万字的文档中设置了三个标记：开头放“START-TEST”，结尾放“END-TEST”，在大约第10万字处插入“MID-TEST”。随后，分别要求模型仅输出这三个字符串。

结果颇具戏剧性：开头和结尾的标记几乎被完美召回，成功率分别高达98.7%和96.4%。然而，位于中间的那个标记“MID-TEST”，召回率骤降至32.2%。这中间的落差，直观地展示了信息在长文本中“沉没”的风险。

二、不同模型版本的长上下文召回能力对比

要系统评估这种能力，业界常用MRCR v2（多范围上下文召回）基准，特别是@1M这个指标，它专门衡量模型在百万字级别输入下，对分散关键事实的精确复现能力，直接反映了对文档中段信息的保真度。

对比发现，Claude Opus 4.6版本在该测试中得分为78.3%。而到了4.7版本，这个分数被主动调整至32.2%，降幅接近一半。值得注意的是，与此同时，模型在SWE-bench Verified编程任务上的得分却从80.8%提升到了87.6%。这一降一升，似乎暗示着开发团队在资源分配策略上做出了明确的权衡——可能将更多计算资源倾向了复杂推理任务，而非纯粹的长距离信息检索。

三、真实场景下的考验：从学术论文中提取数据

理论测试是一回事，实际应用又是另一回事。研究人员模拟了一个常见场景：从长篇学术论文中定位一个特定的数据点。他们使用了100份平均长度约18.5万字的PDF论文，要求模型统一提取“方法章节中首次提到的实验温度值”。

测试方法很直接：将整篇PDF提交给Claude 3 Opus的API，不做任何分段提示。然后，人工核对全部100次响应。

最终的结果是，准确提取出目标温度值的成功率仅为41.5%。进一步分析错误案例发现，高达73%的失误是因为模型将其他章节中间出现的、看似相近的数值，错误地当成了目标值。这说明在长文档中，模型不仅可能“遗忘”信息，还可能产生“混淆”。

四、架构差异带来的性能分野

那么，这是所有大模型共有的问题吗？对比测试给出了答案。在相同的A100集群硬件上，搭载了Engram架构的DeepSeek模型与Claude 3 Opus被安排了同样的任务：处理一份50万字的学术论文，并生成摘要，重点考察它们对分散在文中关键数据点（如样本量、p值）的一致性保持能力。

测试聚焦于文档中段（第5万到15万字区间）。数据显示，DeepSeek模型对这些关键数据点的召回率达到了89.1%，而Claude 3 Opus在同一区间的召回率为53.7%，差距明显。有趣的是，在文档的开头（0-2万字）和结尾（48万-50万字），两者的召回率差距不到4%。核心差异，恰恰集中在了最考验长程依赖能力的中段区域。

五、一个实用的技巧：分段调用提升召回率

面对这种结构性局限，有没有可行的应对策略？实测发现，调用API的方式本身就能影响结果。虽然Claude官方未公开其内部上下文切片机制，但测试表明，将长文档切分成较小的片段进行多次请求，比一次性提交整个文档更能稳定地召回中段信息。

这背后可能涉及模型内部动态的token资源重分配策略，而不仅仅是简单的缓存问题。一个实验将一份19.2万字的文档，按每6.4万字切分成三段，分别调用API提取“结论段落的核心主张”。

之后，将三次的响应结果合并、去重并进行逻辑校验。采用这种分段策略后，对文档中段核心主张的召回率提升到了76.9%，相比一次性提交整个文档的单次调用方式，提升了超过35个百分点。这为处理超长文档提供了一个简单却有效的思路。