在候选之间选择

oloproof select 在一个系统的多个版本中，选出满足每项要求的最佳版本，并单独说明它是否真的领先于下一个。比如你有三个智能体、两个提示词或四种检索设置，以及一组要求时，就可以用它。

为什么不直接选数字最好的

选择数字越过门槛的最便宜候选有两个问题。在 90% 的门槛下测得 91%，只高出一个点，落在一千个用例的噪声之内。而当你同时查看多个候选时，靠运气越过门槛的那个恰恰是你会选中的。所以每个候选必须先独立确立每条规则，并且因为查看了多个候选而使用更严格的置信水平：三个候选、95% 的策略时，每个候选按 98.33% (1 - 0.05/3) 判定。只有通过所有规则的候选才参与排名，更便宜的候选永远不能用成本换取一条安全规则。

声明一次选择

在项目旁边写一个选择文件，并在项目的 release.yaml 下判定它：

select:
  candidates:
    agent_a: run_01JC8Q2X7D
    agent_b: agent_b.yaml
    agent_c: agent_c.yaml
  objective:
    metric: cost_per_task
    direction: minimize

候选可以是一个已存储的运行 id，也可以是 oloproof select 会先运行的项目文件。可以复用的运行不会产生新成本。策略只能包含运行规则，且必须关闭提前停止。

oloproof select select.yaml
oloproof select select.yaml --save

--save 还会把这次选择写入本地 workbench 的 Candidates 下。

解读答案

有三种结果：

• 选出了一个候选，且它对第二名的领先已确立：两者在目标上的配对比较为 PASS。
• 选出了一个候选，但它的领先未确立：基于这些证据，第二名同样是站得住的选择。
• 没有候选合格：会列出每个候选的规则及其答案，让你看到缺了什么。

选出候选时命令以 0 退出，没有候选合格时以 3 退出。

一个完整示例

三个智能体必须达到至少 90% 的成功率和至多 1% 的违规率；目标是每任务成本最低。

每个都按 98.33% 判定。在 1,000 个用例时没有智能体合格：A 的违规率尚未证明低于 1%，B 的 91% 离 90% 太近而无法确立，C 突破了违规上限。答案是“没有候选合格”，并附上每个候选缺少的内容。在 3,000 个用例时，A 确立了两条规则并被选中。B 更便宜，但它的成功率仍未确立，所以从不参与排名：凭数字选 B，等于发布一项无人证明过的要求。

分享一个选择

oloproof select select.yaml --save 为工作台保存选择。oloproof push --selection ID 通过项目的 egress 策略，将它与每个候选的运行一起发送到托管工作区；ID 是 .oloproof/bundles/ 下的文件夹名，或选择的摘要。工作区在保存之前，会依据这些运行判定时所用的策略，从它持有的运行重新做一次选择，只有结果相同时才保存：结果或文字被修改过的选择、指向项目没有的运行的选择，或者引擎从这些运行中不会做出的选择，会被拒绝，并且不保存任何内容。因此，推送之前请先按选择的策略判定候选的运行。项目的 Candidates 页面会列出它，它的页面与本地工作台的显示完全相同。

Owner 或 Admin 可以在选择的页面上为它创建证据页面：结果、水平，以及每个候选的名称、运行 id 和在校正水平下的规则，标注 "Reported by the developer"，从不包含用例内容。

下一步

• 比较规则 介绍判定领先的配对比较。
• Gating 介绍每个候选需要满足的规则。