指南
對另一個工具的分數提出第二意見
你的評測分數上升了。這是真的嗎？你能信任量測它的評審嗎？如果你已經在用另一個工具做評測，就把它在一次變更前後逐案例的結果匯出，Oloproof 會根據這些結果回答這兩個問題，而不必再執行任何東西。
它讀取什麼
每個系統版本一個檔案，格式為 CSV 或 JSON Lines，每個案例與判準各占一列：
| 欄位 | 內容 |
|---|---|
| case_id | 案例的 id。兩個檔案只在雙方都包含的 id 上配對 |
| criterion | 指標的名稱，它會成為規則所指名的指標 |
| score | 指標量尺上的一個數值；如果該工具沒有為該案例評分，則留白 |
| passed | 以 true 或 false 取代分數，或留白 |
| score_min, score_max | 分數所在的量尺（多數工具為 0 與 1），有分數時為必填 |
| judge, judge_version | 做出評判的模型（如果由模型評判）。選填 |
除此之外不讀取任何內容，任何含有其他欄位的檔案都會被拒絕：檔案只包含案例 id 與分數，絕不包含問題、答案或任何其他內容。下方的轉換腳本會把每個工具的結果轉成這種檔案。
執行它
oloproof init --example second-opinion second-opinion
cd second-opinion範例包含一個客服助理在 150 個問題上的忠實度（faithfulness）的兩份匯出，分別在一次提示詞變更之前與之後，由另一個工具的評審評分：一個介於 0 到 1 的分數，以及以 0.7 為界的通過或失敗。make_exports.py 是寫出它們的模擬程式。平均分數上升了約 0.02。
oloproof scores import before.csv after.csv --policy release.yamlfaithfulness: +0.023 [-0.024, +0.068] · 150 paired · 0 missing · 0 excluded
faithfulness_passed: +5.3 points [-6.9, +18.0] · 150 paired · 0 missing · 0 excluded
Decisions
score-went-up faithfulness superiority INSUFFICIENT_EVIDENCE evaluator_not_validated
more-answers-pass faithfulness_passed superiority INSUFFICIENT_EVIDENCE evaluator_not_validated
Gate: BLOCK (exit 3)
score-went-up, more-answers-pass: the judge (or model or custom evaluator) behind these rules has not been measured against people yet, so it may not decide.每個檔案都成為一次執行，兩次執行逐案例進行比較。答案分成兩半。
- 這是真的嗎？還不能確定。分數上升了 0.023，但區間從低 0.024 到高 0.068：只有 150 個問題時，這麼小的變化無法與雜訊區分開來。評審判為通過的答案所占比例上升了 5.3 個百分點，區間從低 6.9 個百分點到高 18.0 個百分點。
- 你能信任這個評審嗎？還沒有人檢查過它。release.yaml 只有在人工標註量測過某個評審之後才讓它決定發布（require_validated_evaluators: true），因此兩條規則都在到達區間之前就停在 evaluator_not_validated。
若要單獨查看前一半，就像評審已經檢查過一樣：
oloproof scores import before.csv after.csv --policy statistics-only.yaml score-went-up faithfulness superiority INSUFFICIENT_EVIDENCE interval_overlaps_zero
more-answers-pass faithfulness_passed superiority INSUFFICIENT_EVIDENCE interval_overlaps_zero在 CI 中加上 --summary markdown >> "$GITHUB_STEP_SUMMARY"：拉取請求隨後以「Is it real?」和每條規則一行開頭，寫明「not established」及其原因，結束碼不變。匯入本身的輸出寫到標準錯誤，因此摘要只收到答案（CI）。
不帶 --policy 時，該命令回報比較結果，不做任何判定。只給一個檔案時，它回報那次執行，而 --policy 依政策中的執行規則對它把關。
檢查評審
由人為一次匯入執行的案例隨機抽樣做標註，標註時看不到評審的判定，Oloproof 再以這些標註量測評審：
oloproof labels export RUN_ID --criterion faithfulness_passed --sample 60 --out sample.csv
oloproof labels import sample.csv
oloproof evaluators validate EVALUATOR_ID --by NAME樣本顯示每個案例的 id，不顯示評審判定的任何資訊。標註者在保存該案例的工具中依 id 閱讀該案例，並在 passed 中填入 pass 或 fail。oloproof evaluators list 會提供評估器的 id。一旦通過驗證，讀取該評審的規則就只依據證據做出判定。
標註是通過或失敗，因此它們檢查的是評審的通過或失敗判定，而不是它的分數。請將判定與分數一併匯入，就像範例中的 faithfulness_passed 那樣：這才是人可以驗證的判準。
從你的工具匯出
範例的 recipes/ 資料夾為每個工具提供一個簡短的腳本。每個腳本讀取該工具的結果並寫出上述檔案，只保留 id 與分數。每個版本執行一次，然後匯入這兩個檔案。
| 工具 | 轉換腳本 | 在兩次執行之間識別一個案例的是什麼 | 備註 |
|---|---|---|---|
| DeepEval | deepeval_results.py RESULTS_JSON OUT | 測試案例的 name | 以 DisplayConfig(results_folder=...) 儲存結果，並為每個 LLMTestCase 命名。每個指標提供其分數，並以 <metric>_passed 提供其通過或失敗，同時附上評審模型 |
| Braintrust | braintrust_experiment.py PROJECT EXPERIMENT OUT | 實驗所執行的資料集紀錄（origin.id） | 分數介於 0 到 1；如果所有分數都由同一個模型評判，以 --judge 指名該模型 |
| LangSmith | langsmith_experiment.py EXPERIMENT OUT --scale LOW HIGH | 資料集範例（reference_example_id） | true 或 false 的分數會變成通過或失敗；數值分數需要給出其量尺 |
| Langfuse | langfuse_experiment.py EXPERIMENT SINCE OUT | 資料集項目（experiment_item_id） | Langfuse 5 的實驗；數值分數採用其分數設定的範圍，或以 --scale 指定 |
這些轉換腳本依循各工具在 2026 年 10 月 16 日發布的 SDK（DeepEval 4.3.1、braintrust 0.46.1、langsmith 0.14.11、langfuse 5.0.2），並在該結構的結果上測試過，而不是針對真實帳戶。某個工具重新命名了欄位，壞掉的是它的轉換腳本，而不是匯入：腳本寫出的檔案才是契約。
檔案必須做對的事
- 只出現在一個檔案中的案例，在另一側視為缺失，會被計數並以最壞情況界定；它絕不會與另一個案例配對。
- 同一案例與判準的第二列、超出 score_min 與 score_max 的分數、同時帶有分數與通過或失敗的列，以及在一個檔案中是分數、在另一個檔案中是通過或失敗的判準，都會被拒絕，並指出是哪一列。
- 被比較的檔案必須在每個判準的量尺與評審上一致：來自兩個評審的分數是兩件量測儀器，它們的差異有一部分會來自儀器本身。
- 每個檔案都是一個以其內容識別的系統版本。再次匯入同一個檔案會重用已儲存的內容；從不執行任何東西，因此任何重新執行都無法重現或改變一個匯入的分數。
- --tool 記錄分數的來源，--name 為每個檔案的系統命名；兩者都隨執行一起保存。
尚未建置的功能
- 直接讀取某個工具自身的匯出格式：轉換腳本會把它轉成上方的檔案。
- 不必安裝任何東西即可將檔案上傳到託管網站。
- 驗證評審的分數，而不是它的通過或失敗判定。
下一步
- 將候選版本與基準比較：配對比較讀取的是什麼。
- 比較規則：優越性、不劣性與等效性。
- 評審：評審在可以設閘把關之前，如何與人比對量測。