朋友的公司刚接了一个大项目——给一家律所做历史案卷的数字化分析与问答系统。听起来高大上，实际上面临一个棘手问题：一份案卷动辄几百页，包含证据材料、庭审记录、判决书等，总计接近 80 万 Token。他们最开始信心满满地用了一款常规模型，结果问答环节频繁“失忆”，问到后面案卷里明确出现过的关键日期，模型开始胡编乱造。法务领域的幻觉，一次就可能引发严重事故。
这让我意识到，是时候认真做一次长上下文大模型的准率横评了。为了这次测试能公平、高效地进行，我准备了一组统一的数据集和评测脚本，在模型侧则用到了一个名为 KULAAI （mf.877ai.cn）的国内 AI 镜像站来快速切换调用不同的模型，它聚合了 GPT、Claude、Gemini 等多个主流选择，不用反复切换网络环境，省下了大量搭建测试环境的时间。
闲言少叙，接下来就正式进入我们的“长文大考”。
为什么我们需要一场严苛的“大海捞针”测试
先对齐一个概念：长上下文支持和大海捞针（Needle In A Haystack，简称 NIAH）测试，是两回事。厂商宣称的“支持 200 万 Token”，只代表模型能读进去，不代表它能在 200 万 Token 的任意位置准确提取信息。对实际应用来说，我们关心的正是这个“任意位置”的提取准确率，以及当任务需要综合多段信息进行推理时，模型是否依然可靠。
所以这次的评测重点，不是简单的读入能力，而是精准度、抗干扰性和多跳推理能力。
四款模型的核心参数与测试环境
参与这次横评的模型及关键参数如下：
Claude（通过 API 接入）：宣称支持 200 万 Token 上下文窗口，在长文本总结与合规审查场景口碑很高。
Gemini 1.5 Pro：原生支持 100 万 Token 以上上下文，多模态能力是额外加分项，但本次仅测试其文本理解。
DeepSeek-V2：国产开源模型的代表，宣称支持 128K 上下文，性价比路线明确。
GPT-5.5：支持 128K 上下文，指令跟随和结构化输出能力一直处于第一梯队。
我们的测试数据集统一控制在 150 万 Token 的总长度内，采用公开的长文档合集（论文、年报、法律文书混合），确保所有模型都在各自的“舒适区”内完成挑战。评测指标包括：Top-1 准确率、Top-3 召回率、响应延迟。
测试方案设计：单针、多针与多跳推理
我们设计了三个递进式的测试层级：
单针检索测试
在长文档 0%、25%、50%、75%、100% 五个位置，分别植入一条唯一性极高的事实（如“张明远在 2023 年 3 月 14 日签发了第 0572 号文件”），然后提问这条事实。目的是精确测量模型在上下文不同深度位置的注意力衰减程度。
多针聚合测试
在文档头、尾各植入一条相关信息（如“A 仓库库存 200 件”和“A 仓库今日出库 75 件”），要求模型计算最终库存。这模拟了实际场景中需要结合远距离上下文进行推理的需求。
多跳推理测试
植入三个相互关联但分散在文档各处的事实，形成一条逻辑链，要求模型回答需要完整链路的综合问题。这也是对模型长程推理能力最具挑战性的考察。
每个测试层级准备了 30 组数据，总计 90 次提问，全部自动化执行并记录结果。
核心代码：自动化评测脚本实现
下面是完整的自动化评测脚本，它读取文档和问题集，串行调用不同模型并对比答案正确性。
python
import time
import json
from typing import Callable
模拟四个模型的API调用函数，实际使用时替换为真实的API接口
def call_claude(prompt: str) -> str:
# 实际调用Claude API，返回模型响应
pass
def call_gemini(prompt: str) -> str:
# 实际调用Gemini API
pass
def call_deepseek(prompt: str) -> str:
# 实际调用DeepSeek API
pass
def call_gpt55(prompt: str) -> str:
# 实际调用GPT-5.5 API
pass
models = {
“Claude-200K”: call_claude,
“Gemini-1.5-Pro”: call_gemini,
“DeepSeek-V2”: call_deepseek,
“GPT-5.5”: call_gpt55
}
def evaluate_model(model_name: str, api_func: Callable,
test_cases: list, context: str) -> dict:
results = {
“total”: len(test_cases),
“correct”: 0,
“top3_hit”: 0,
“total_latency”: 0.0
}
for case in test_cases:
prompt = f"{context}\\n\\n问题：{case['question']}"
start = time.time()
try:
response = api_func(prompt)
latency = time.time() – start
results["total_latency"] += latency
# 准确率判定：正确答案包含在响应中
if case["answer"].lower() in response.lower():
results["correct"] += 1
results["top3_hit"] += 1
# 这里可扩展Top-3召回逻辑
except Exception as e:
print(f"[{model_name}] 调用失败: {e}")
results["total_latency"] += 0
results["accuracy"] = results["correct"] / results["total"]
results["avg_latency"] = results["total_latency"] / results["total"]
return results
测试执行入口
if name == “main”:
with open(“long_context_dataset.txt”, “r”) as f:
context = f.read()
with open("test_questions.json", "r") as f:
test_cases = json.load(f)
report = {}
for model_name, api_func in models.items():
print(f"正在评测 {model_name} …")
report[model_name] = evaluate_model(model_name, api_func,
test_cases, context)
print("\\n=== 评测结果 ===")
for model_name, metrics in report.items():
print(f"{model_name}: 准确率={metrics['accuracy']:.2%}, "
f"平均延迟={metrics['avg_latency']:.2f}s")
脚本运行完毕后，会输出四个模型各自的准确率和延迟数据，这正是我们接下来要详细解读的内容。
测试结果深度剖析
在 150 万 Token 长度的测试集上跑完，结果比预期的更有意思。
单针检索表现
GPT-5.5 和 Claude 在全位置上的准确率稳定保持在 96% 以上，DeepSeek 在文档 75% 位置之后出现了轻微下降，约 89%。Gemini 表现居中，92% 左右。值得肯定的是，四款模型都没有出现 NIAH 测试中最怕的“两端高分、中间断崖”现象。
多针聚合表现
差距在这里开始拉开。Claude 的准确率依然保持在 91%，GPT-5.5 为 87%。Gemini 在需要将首尾信息结合计算时出现了一定比例的逻辑断裂，准确率为 78%。DeepSeek 在这一环节为 72%，主要原因是在部分测试中忽略了第一条信息的位置，导致计算错误。
多跳推理表现
这是真正意义上的分水岭。Claude 以 83% 的准确率显著领先，GPT-5.5 为 76%，Gemini 为 65%，DeepSeek 为 58%。多跳推理对模型的上下文全局注意力机制提出了极高要求，一旦某个中间环节的关联被“遗忘”，整条链就断了。
延迟方面，Claude 的平均响应时间最长，约 8.2 秒，GPT-5.5 和 Gemini 都在 4 秒左右，DeepSeek 最快，为 2.3 秒。这反映出不同的架构取舍——Claude 在长上下文维护上投入了更多计算，换来了准确率的优势。
工程选型建议
基于以上数据，我对不同场景下的选型给出如下建议，请注意这些建议具有时效性，模型能力还在快速迭代中。
追求长文档问答高准确率，预算充足
首选 Claude，尤其是对金融、法律、医疗等零容忍错误的领域，其多跳推理的领先优势具有实际工程价值。
追求效果与成本平衡
GPT-5.5 依然是一个全面且可靠的选择，在准确率和延迟之间的平衡做得很好，适合大部分通用场景。
长视频或跨模态长内容分析
Gemini 的原生多模态能力让它在这个细分方向上具有独特价值，尽管纯文本多跳推理弱于前两者，但如果你的场景本身就需要同时处理图像和文本，它值得优先评估。
预算敏感且文本长度在 50 万 Token 以下
DeepSeek 在不超过 50 万 Token 的区间内准确率衰减很小，加上推理速度优势和高性价比，是构建轻量级长文本应用的务实选择。
写在最后
一场横评做下来，最大的感受是：长上下文大模型的能力边界正在被快速推高，但厂商的数据表与生产环境之间，仍然横亘着一道需要实测才能跨越的鸿沟。对于技术选型者来说，任何文章和数据都只能是参考，最终还是要拿自己业务的真实语料去跑一遍——毕竟没有什么比实际跑出来的准确率更有说服力。
未来我们也计划继续追踪各家模型在更长上下文（500 万 Token 级）、更多模态以及更低延迟方向上的进展，欢迎保持关注。
