指南
一次改动，从头到尾
一次改动之后，你的分数上升了。本页跟随一次真实的改动，走过 Oloproof 在允许它发布之前提出的每一个问题：评判模型是否可信，改动本身是否达到门槛，按评判模型和按人的判断它是否优于被替换的版本，以及下一步该尝试什么。系统是一个基于 40 份文档作答的小型客服机器人，在你的机器上用本地模型运行；下面的每个数字都是引擎打印出来的。从 examples/one_change 复制它，然后运行 REVIEWER=yourname ./run_demo.sh。
改动
基线提示词要求机器人保留确切的数字、名称和单位。候选版本要求一两句温暖、自然的句子。两者在同样的 120 个问题上运行，配有一个确定性检查（answer_correct，答案是否包含预期的事实）和一个本地模型评判（judge_correct，是否以同一事实作答）：
oloproof run --policy release.yaml
oloproof run --config candidate.yaml --policy release.yaml答对的比例从 80.0% 升到 82.5%，评判模型的通过率从 82.5% 升到 83.3%。这就是表面上的改进。两次运行目前都还不决定任何事：发布规则读取评判模型，而评判模型尚未经过检查，所以规则给出 INSUFFICIENT_EVIDENCE，原因是 evaluator_not_validated。
评判模型可信吗？
人对候选版本答案的一个盲随机样本打标签，看不到评判模型的结论，引擎再拿这些标签来度量评判模型：
oloproof review CANDIDATE --criterion judge_correct --by you在记录的会话中，评判模型在 79 个已标注案例中的 77 个上一致（97.5%，下限 91.2%），偏差为 -2.5 个百分点，在默认门槛之内（一致性 0.70，偏差 0.35），因此通过验证，可以做决定。在那次会话中，标签由一个代替审阅者的智能体给出，这展示了工作流程，并不是人的判断；当你运行时，审阅者就是你。
候选版本本身达到门槛了吗？
release.yaml 要求评判模型通过率至少为 80%：
oloproof gate CANDIDATE --policy release.yaml --config candidate.yaml83.3% 的区间为 75.4% 到 89.6%，横跨 80%，因此规则为 INSUFFICIENT_EVIDENCE，引擎表示大约 592 个案例可以做出决定。可信的评判模型并不会让一个接近的结果变得明确。
它比基线更好吗？
compare.yaml 提出两个问题。按评判模型，候选版本是否更好，且仅当人证明评判模型在两个提示词上犯错方式相同时（judge_bias_bar: 0.10）才保留这个结论？以及按人自己对同一案例两个答案的标签（people_pass_diff，一个 human_difference 指标），它是否不比基线低超过 10 个百分点？
oloproof review CANDIDATE --against BASELINE --criterion judge_correct --by you --sample 40
oloproof compare CANDIDATE BASELINE --policy compare.yaml --config candidate.yaml审阅把两个答案显示为 A 和 B，顺序由抛硬币决定，不标出是哪次运行。在记录的会话中，评判模型的差异为 +0.8 个百分点（-5.1 到 +7.3）：INSUFFICIENT_EVIDENCE，大约需要 3,690 个配对案例才能决定。在 40 对中，人让候选版本通过 36 次、基线通过 35 次：+2.5 个百分点（-11.1 到 +17.7），所以“不差于 10 个百分点”也是 INSUFFICIENT_EVIDENCE。门禁拦下了它。这次改动是分数几乎察觉不到的风格改动，而 120 个案例无法区分 1 个百分点的变化和没有变化。
它为什么在失败的地方失败？
oloproof diagnose CANDIDATE --intervention gold-context --criterion answer_correct --config candidate.yaml引擎把正确的段落交给模型，重新运行了 21 个失败案例，并在不提供段落的情况下再运行一次作为对照。对照一个也没有恢复；正确的段落恢复了 14 个：7 个是检索从未找到该段落，7 个是找到了但排在前 3 名之后，另有 7 个无论如何都失败了。它提出更大的 top_k 作为假设，然后在同样的案例上进行了测试：
oloproof diagnose CANDIDATE --intervention top-k --top-k 8 --criterion answer_correct --config candidate.yaml7 个排名靠后的案例全部恢复，而对照一个也没有恢复。
后续
followup.yaml 是带 top_k: 8 的候选版本，一个完整运行的新系统版本：
oloproof run --config followup.yaml --policy release.yaml
oloproof compare FOLLOWUP CANDIDATE --policy followup_compare.yaml --config followup.yaml它的评判模型通过率为 90.0%（83.1% 到 94.8%），因此 80% 的下限为 PASS。与候选版本相比，答对更多（+3.3 个百分点）仍为 INSUFFICIENT_EVIDENCE，而评判模型通过率不差超过 5 个百分点为 PASS。评判模型是在候选版本的答案上检查的，而不是后续版本的答案，也没有人标注过后续版本的配对，所以那里人的差异不决定任何事。
这无法告诉你的
一个小机器人、一次改动、120 个案例和本地模型。它展示了引擎如何在一次真实改动上得出每个决定；它对其他系统什么也没说。本地样本属于善意：只有工作区抽取的样本才会在那里得到检查。包含每个运行 id 的完整记录是 docs/audits/DOGFOOD_LARKSPUR_2026-10-26.md。参见 评判模型、比较规则、RAG 评估 和 局限。