推理、有效上下文与结构化输出
本节目标
把三个容易被宣传参数替代的能力——推理、长上下文和结构化输出——变成任务级测试。
核心概念
- 推理能力：在给定工具、预算和信息下，产生能通过外部 verifier 的结果；不以冗长“思考文本”为指标。
- 上下文窗口：接口可接受的最大输入/输出边界。
- 有效上下文：模型在目标长度、证据位置、干扰和多轮状态下仍能正确利用信息的能力。
- 结构化输出：provider 返回可解析结果只是第一层；业务 schema、交叉字段约束、枚举、权限和值域仍由 runtime 验证。
为什么需要
HELM Long Context 明确区分“支持长输入”和“具有强长上下文能力”。同一个窗口上限，在检索、跨段推理、长对话指代和全局摘要上的表现可能完全不同。类似地，结构化输出 99% 可解析仍可能在高风险字段上失败；单看平均通过率会隐藏严重错误。
怎样实现
推理测试
使用能外部判定的题：代码测试、约束规划、数值答案或环境终态。固定最大调用次数、工具和时间；同时记录成功率、无效动作、token、延迟与停止原因。
有效上下文测试
按真实长度分桶，控制证据位置与干扰：
- 短输入 baseline；
- 证据位于开头、中间、结尾；
- 单跳与多跳；
- 相关证据、冲突证据和无答案；
- 多轮状态覆盖与过期信息。
不要用一个 needle 测试代表所有长文任务。
结构化输出测试
用版本化 JSON Schema 约束语法，再用业务 validator 检查：订单总额、资源归属、时间先后、工具 allowlist 等跨字段规则。明确 parse error、schema error、semantic error 和 policy rejection，避免都记成“模型失败”。若结构化输出是该任务的 required capability，最终输出未通过 validator 的 trial 不能同时标为 task_success=true；其聚合通过率也必须先过行为 gate，不能由成本或延迟补偿。
常见失败
- 用模型自述的推理过程作为正确性证据。
- 看到窗口上限就把全部历史塞入 context。
- 只测简单 JSON，不测嵌套、可选字段、拒答和未知字段。
- 自动“修复”非法输出后只统计修复结果，掩盖原始失败。
- 候选使用不同 token budget 或 retry，比较不公平。
怎样验证
每个能力至少准备一个成功用例、一个边界用例和一个预期失败；报告按长度、任务和严重度切片的多 trial 结果。结构化输出必须由独立 parser/schema/业务 validator 判定。
实践任务
为“从长合同中生成审批 JSON”构造 12 个 case：三种长度、三种证据位置、冲突条款和缺失条款。定义哪些字段允许 null，哪些情况必须拒绝，并记录原始输出与 validator 原因。