为什么看似合理的回答还不够
看似合理的结果并不能证明 AI 智能体遵循了流程。为此，不仅要检查回答，还要检查执行证据。
在 ContractEval 研究中，程序遵循情况被视为一个独立的检查对象。在一个受控数据集中，LLM 评判者漏掉了许多人为植入的结构性故障。无论只评估回答，还是将执行轨迹纳入考量，都会出现这种情况。
- 回答显示系统报告了什么。
- 执行轨迹包含有关执行动作的证据。
- 程序检查会将这些证据与要求进行比对。
**标准：**不要将回答的说服力视为遵循流程的证据。
程序检查如何运作
ContractEval 将指令表示为一组针对特定请求生效的义务。然后，系统将这些义务与回答或执行轨迹中的证据进行比对。
检查包括三个要素：
- 请求决定哪些义务生效。
- 回答或轨迹作为证据来源。
- 比对用于识别符合项和违规项。
**实用标准：**检查应将要求与回答或轨迹中的具体证据关联起来。
可以区分哪些违规
ContractEval 会区分不同类型的程序性故障。这样的划分可以指出要求与执行具体在哪些方面不一致。
- 遗漏——缺少必需的动作或要求。
- 错误分支——执行进入了不适用的程序分支。
- 顺序错误——动作未按要求的顺序排列。
- 多余动作——执行中包含规定之外的动作。
- 不变量违规——未能满足必须始终保持的条件。
- 输出要求不符合——结果不满足规定的格式或内容要求。
**标准：**分类应指出故障类型，而不是将所有违规都归结为对回答的总体评价。
研究发现了什么
ContractEval 论文的作者在一个受控的程序契约数据集上比较了不同的检查方法。预期执行图与实际执行图的对照，能够发现并定位所有人为植入的结构性故障。
| 检查方法 | 结果 |
|---|---|
| LLM 评判者评估回答或考虑执行轨迹 | 漏掉了许多植入的故障 |
| 对照预期图与实际图 | 发现并定位了所有这类故障 |
| 使用 LLM 提取数据 | 保留了很大一部分信号，但依赖于校准 |
Praphul Singh、Shanu Kumar、Akshat Agarwal 和 Ganesh Kumar 的论文于 2026 年 9 月 8 日提交至 arXiv：ContractEval.
**结论：**这些结果适用于受控数据集；不能将其直接推广到所有场景。
检查的边界在哪里
ContractEval 并不能保证系统遵循了流程。这项工作让遵循情况变得可审计，而不是将其视为最终回答理所当然具备的品质。
选择检查方法时，有两个条件很重要：
- 是否存在对预期执行的基准表示。
- 能否将其与实际轨迹或回答中的证据进行比对。
如果使用 LLM 提取数据，就需要考虑结果对校准的敏感性。最终回答本身不能替代对程序性证据的检查。
**实用标准：**只有在要求与可观察到的执行情况完成比对后，才将遵循情况视为已验证。
