参考
错误
本页存在的意义在于这个区分：失败的运行和出错的运行是两回事，把其中一个呈现为另一个，就等于告诉开发者他们的变更有问题，而实际情况是评测框架自己崩了。
失败是一种结果，错误不是。
FAIL 表示门控已被评估，而证据低于阈值。这是关于这次变更的质量结果。
RUN_ERROR 表示运行没有完成。没有评估任何门控，也没有度量关于这次变更的任何东西。它不是决策状态，PARTIAL 和 CANCELLED 也不是——它们描述的是一次运行发生了什么，而不是对一个系统做出了什么决策。
未完成的运行会报告什么
对未完成运行的门控以 5 退出，而不是 1。证据是缺失，而不是糟糕，两者需要不同的应对：失败的门控要你去看你的变更，未完成的门控要你去看你的基础设施。
无法度量的用例
出错的用例会被纳入界限，而不是被丢弃。每个指标都记录四个计数——总数、符合条件数、已观测数和缺失数——而区间会把它无法看到的用例考虑在内。
这比听起来更重要。一个把未评分用例计为零的指标，会把系统自身的服务中断当作质量失败算到模型头上；而一个在系统开始出错时悄悄缩小的分母，正是一个出错的系统报告分数上升的方式。这两种情况都在一个线上助手上观测到过，该助手有 13.8% 的调用返回了 HTTP 500。
暂时性失败
系统可以声明某次失败是暂时性的，暂时性失败会被重试，而不是记录为质量结果。服务商超时并不是关于提示词的证据。
这种声明是显式的：可调用系统抛出带 retryable=True 的 TransientError。retryable 默认为 False，不带它的 TransientError 会像其他任何异常一样记录在用例上，因此该用例会被记为缺失，而不是被重试。HTTP 系统和评判器服务商无需声明：超时、连接中断、429 或 5xx 都会为它们自动重试。无论哪种方式，一次调用最多尝试四次，并带退避，仍然失败的用例记为缺失。进度与并发 展示了这两种情况。
配置错误
退出码 2 表示调用方式或配置有误，没有运行任何东西。配额拒绝也属于此类：它是带有具体原因的配置错误，在第一个用例执行之前就被拒绝，而且它从来不是决策状态。商业层面的事实不应以质量判定的面目出现。
诊断确实失败的部分
oloproof diagnose RUN_ID --intervention gold-context --criterion answer_correct干预是指在什么条件下重新运行失败的用例——gold-context、top-k 或 reranker——而 criterion 指定要取哪个评估器的失败。诊断会报告带计数的失败因素、其背后的场景 id，以及它所做的假设。它指出的是因素，而不是原因：引擎不会断言某件事导致了另一件事，渲染诊断结果的任何页面也不会这样断言。