大模型长文本能力评测要测什么，怎么用同一批长文样本比出真实差距
大模型长文本能力评测的核心不是看厂商宣传的上下文窗口有多大，而是用同一批固定长度、固定任务的长文样本去测模型“真正用上了多少信息”。
如果只比较参数或窗口数字，很容易被误导：窗口标称 128K 的模型，在 64K 输入下实际回答准确率可能明显下降。
下面按“准备样本、设计任务、执行对比、识别干扰、验证结论”的顺序讲清楚。
先固定输入长度和样本来源
长文本评测的第一个变量是输入长度。
建议至少准备三档：约 8K、32K、64K token（token 可以粗略理解为模型处理文本的最小单位，中文一个字大致对应 1 到 2 个 token）。
每档用同一批文档，只改变长度，才能看出模型在不同长度下的衰减曲线。
样本来源优先选你实际业务会遇到的文档：合同、技术手册、会议纪要、客服对话记录。
不要只用小说或新闻，因为不同文体对信息密度的要求不同。
每篇文档需要人工标注好“关键事实”，例如某个条款的金额、某个故障的处理步骤，作为评分依据。
准备时记录清楚：文档总 token 数、关键事实在文档中的大致位置（开头、中段、结尾）。
这一步是为了后面排查“位置偏差”——有些模型对文档开头的召回明显好于中段。
长文任务要拆成可判分的类型
长文本能力不是单一指标，建议至少覆盖三类任务，每类给不同的评分方式：
- 跨段信息检索：提问需要综合文档前后两处信息才能回答，例如“合同第 3 条的违约金比例与附件 B 的付款节点是否冲突”。评分看是否同时引用两处并给出正确结论，可以按正确、部分正确、错误三档人工判分。
- 长文摘要：要求模型用固定字数概括全文，并保留指定数量的关键事实。评分时检查关键事实覆盖率，而不是看摘要是否通顺。
- 带约束的长文问答：在长文档后追加一个与文档无关的指令，例如“只根据文档回答，不确定时说明找不到”。这能测出模型是否会被长上下文带偏。
每类任务准备 20 到 30 条样本，数量不必多，但要覆盖不同位置和不同问题类型。
样本和标准答案提前固定，不要评测中途修改。
用同一套调用条件跑对比
对比多个模型时，除了模型本身，其他条件必须一致：
- 输入文本完全相同，包括标点和换行；
- 温度参数固定，例如统一设为 0 或 0.2，减少随机性；
- 每个样本重复跑 2 到 3 次，记录结果是否稳定；
- 记录每次调用的输入 token 数和输出 token 数，方便后续算成本。
如果通过 API 调用，建议把请求封装成脚本，把样本文件、模型名、参数写进配置，避免手工复制导致样本不一致。
下面是一个最小化的请求结构示意（字段名以你使用的接口文档为准）：
{
"model": "your-model-name",
"messages": [
{"role": "user", "content": "<长文内容>\n\n问题：<固定问题>"}
],
"temperature": 0.2
}跑完后把输出整理成表格：模型、样本编号、任务类型、输入长度、判定结果。
人工判分时建议两人独立打分，分歧样本再复核，避免单人标准漂移。
截断和位置偏差是最常见的干扰
长文本评测里两个坑最容易让结论失真：
一是静默截断。 有些接口在输入超过限制时会直接截断而不报错，模型只看到前半段，回答自然差。
评测前先用一段带唯一标记的长文本做探针：在文档末尾放一个特殊编号，提问该编号是什么。
如果模型答不出，先检查是不是输入被截断了，而不是急着下“长文本能力差”的结论。
二是位置偏差。 同一份文档，把关键事实放在开头和放在中间，模型得分可能差很多。
设计样本时要把关键事实均匀分布在文档前、中、后三段，分别统计得分。
如果某个模型在“关键事实位于中段”时准确率明显下降，这个信息比一个总分更有用。
另外，长文输出容易变慢，评测时把响应时间也记下来。
对于需要实时回答的场景，首 token 延迟和总耗时可能比准确率更影响可用性。
结果怎么读才不误导选型
拿到评分后，不要只看平均分。
按输入长度画一条衰减曲线：如果模型 A 在 8K 时准确率 90%，到 64K 掉到 55%，而模型 B 从 85% 掉到 75%，选型结论取决于你的业务平均输入长度。
业务文档大多在 16K 以内，就重点看那一档的表现。
还要把成本和稳定性放进来一起看。
同样准确率下，输入 token 计费更高的模型在长文场景成本差距会被放大；
重复跑结果波动大的模型，不适合对一致性要求高的场景。
最后提醒一点：厂商公布的“支持 1M 上下文”是能力上限，不等于在该长度下回答质量不下降。
评测报告里写清楚测试长度、任务类型和评分口径，结论才可复现。
如果你还在选型阶段，可以先用 8K 和 32K 两档做快速筛选，再对候选模型补测更长输入。
