长上下文模型的验收，不能从“能否输入百万 Token”开始，而应从业务任务倒推指标。最大上下文窗口只是理论容量，实际效果还取决于模型能否定位证据、处理冲突信息、保持多轮一致，并在可接受的延迟、成本和风险范围内完成任务。
先定义验收对象
评测应将四个概念分开：理论上下文窗口、实际可用长度、有效利用能力和业务完成率。采购或系统验收时，需要确认输入与输出是否共享窗口，超长内容是否会被截断或压缩，以及不同接口、模型版本和并发条件下是否存在限制。若这些条件没有明确，所谓“支持超长上下文”就无法转化为容量规划依据。
测试材料不能只使用整理干净的示例文档。应建立可重复的业务评测集，覆盖制度文件、合同附件、代码文件或多轮业务记录，并人为保留真实数据中的版本差异、相似章节、失效规则和分散条款。关键事实应分别放在文档开头、中段、结尾及多个相似位置，测试模型是否真正找得到，而不是凭主题猜答案。
将“找到”与“答对”拆开
验收至少分为三层：
- 信息定位：相关段落、条款或代码是否被命中，引用位置是否准确。
- 内容理解：是否正确识别条件、例外、版本和冲突，是否遗漏关键事实。
- 任务完成：能否完成跨文档比较、风险审阅、调用链分析或问题解释，并通过人工复核。
其中，检索准确率和推理能力必须分别记录。没有找到证据时，流畅回答并不构成通过；找到了正确材料，也不代表模型能够完成复杂判断。
用有效区间而非最大值验收
相同任务应在常规长度、业务高频长度和接近上限的压力长度下重复测试，记录事实准确率、引用完整度、结论一致性、首字节延迟、完整响应时间、失败率、重试率及并发表现。成本也应按任务单元核算：
任务单元成本 = 模型调用费用 + 检索与存储费用 + 重试费用 + 人工复核成本 + 错误处理成本
最终验收应形成“能力—成本—风险”三维判断。只有当模型在真实输入规模下稳定完成任务，并满足权限、溯源和人工复核要求时，长上下文能力才算真正交付，而不是演示环境中的容量数字。