模型发布信息里“支持超长上下文”几乎成了标配表述，但标称的窗口长度只说明单次请求能容纳多少输入、历史对话、工具调用信息与部分输出，并不说明模型能否稳定用上这些内容。企业真正要衡量的是有效上下文容量——在自身材料长度和任务类型下，模型仍能保持准确率、完整性与一致性的那一段范围。
评测的第一步不是找最大长度，而是找拐点。把同一类任务做成短、中、接近业务上限三档材料，问题类型保持一致，观察关键事实遗漏是否增加、摘要是否过度概括、对文档中部信息的引用是否减少、多份材料之间的结论是否矛盾、输出格式与回答步骤是否变得不稳定。出现系统性下滑的位置，就是有效容量的边界，也是业务可接受区间的上限。
定位与推理必须分开测
检索准确率是长上下文任务中最容易被高估的能力。模型能复述文档主题，不代表能找到藏在中间章节、附件或表格里的关键条款。评测应拆成两类任务：单点定位检查明确事实能否被找到，跨段推理检查模型能否结合多个位置的信息作出完整判断。对合同审核、财务分析和合规审查而言，漏掉一个限定条件的代价，远高于措辞不够通顺。
任务完成率要按业务流程设定评分标准，把正确性、完整性、可追溯性分别计分，用人工评分加规则核验，而不是只看回答是否流畅。
延迟、并发与成本同属容量问题
长输入会抬高处理负担，单次测试表现良好不代表多人并发时不排队。首字响应时间、完整响应时间、随长度变化的延迟曲线以及并发稳定性都应记录。交互型场景对响应速度更敏感，批量文档处理则更看重吞吐与排队时间。
成本核算不能只按一次请求的输入量估算，要覆盖输入、输出、检索与存储、失败重试、人工复核和系统运维。若长上下文省去了文档切分，却让每次请求携带大量无关内容，总成本未必下降。安全与部署条件同样需要在采购前核对：数据流向、权限隔离、调用日志、敏感信息脱敏、服务异常时的替代方案，以及是否支持私有化或专属部署。
参数本身不是结论。核查发布信息时，先确认输入输出是否合并计算、测试用的是哪类任务、是否采用特定提示词、材料是否为人工构造、结果来自单次演示还是重复实验；再用本企业脱敏样本做多轮验证，看模型是否每次都能命中相同事实、给出相近结论。走完这条路径得到的数字，才能写进采购评估表，而不是停留在发布页上。