文件
撰寫套件，以它設立閘門。
Oloproof 依據信賴區間而非點估計來決定發布。這些頁面說明如何宣告要量測的內容、如何把決策轉換為結束代碼，以及 LLM 評判模型在獲准為任何事設立閘門之前必須達到的要求。
快速入門安裝引擎、建立專案骨架，並在你自己的機器上完成第一次執行、取得第一個閘門決策。除非你主動推送，否則任何資料都不會離開這台機器。核心概念Oloproof 量測 AI 系統的方式，就像一項研究量測任何事物的方式：同樣的案例、同樣的評審、同樣的亂數種子，在每一次變更時執行。它在測試套件之上增加的，是每個數字都附帶其不確定性，而發布決策是依據區間而非估計值做出的。撰寫測試套件一個測試套件由兩個檔案和一個資料集組成。oloproof init 會為兩者產生骨架，而骨架中附有註解，因為第一次新手引導演練有四次嘗試是卡在一個缺少的字串，而不是缺少的功能。Python APICLI 能做的一切，函式庫都能做。當評估應該放在腳本、notebook 或測試套件裡，而不是放在設定檔旁邊時，就使用它。Recording what a system didA system's output is what an evaluator reads by default. Everything else it did — the prompt it built, the passages it retrieved, the tools it called, the tokens it spent — is recorded alongside the output as artifacts and usage, and every artifact is stored content-addressed with the execution that produced it.進度與並行針對線上模型執行一個套件需要數分鐘，其中大部分時間都花在等待模型。本頁說明 Oloproof 同時保持多少個進行中的呼叫、在呼叫執行期間向你顯示什麼，以及如何得知還需要多執行多少，才能讓一條未能判定的規則得出結論。Gating CIA gate compares measured evidence against a threshold you declared, and exits with a code your CI understands. The decision is made on the interval, not on the estimate.在 CI 中執行CI 把關 說明發布政策以及每個結束代碼的意義。本頁談的是在 CI 工作內部發生的部分：如何在其中安裝 Oloproof、工作執行期間證據存放在哪裡、如何不解析表格就讀取結果，以及如何將拉取請求與其目標分支進行比較。Comparing a candidate to a baselineThe workflow the rest of this product exists for: you changed something, and you want to know whether it helped. A comparison pairs two runs case by case and reports the difference with an interval, so a two-point move is never mistaken for a win.比較規則將候選版本與基準版本比較 示範了工作流程。本頁是比較據以做出決策的規則之參考：有哪些種類、各自提出什麼問題、差距（margin）以什麼單位量測，以及是什麼在影響判讀它們所依據的區間。叢集案例大多數區間計算都假設每個案例彼此獨立。同一段對話的三個回合並非如此：當對話出錯時，三個回合往往一起出錯。將它們視為獨立的測試套件，會回報比證據所能支持的更窄的區間，而關卡可能因此放行。切片整體比率可能維持穩定，而測試套件的某一部分卻已崩潰。切片是測試套件中經過宣告、單獨量測的一部分，讓這種崩潰變得可見。切片附帶兩條紀律，因為同時檢視測試套件的許多部分，正是評估把雜訊誤當成發現的方式。JudgesAn LLM judge is one kind of evaluator, not all of them. Oloproof has three kinds — deterministic, LLM judge, and custom — and the rules on this page are about the second, because a model's verdict is the one that needs measuring against a human's.RAG 評估一個檢索增強的回答可能因為四種不同的原因而出錯：正確的段落從未被檢索到；它被檢索到了，但排名太低；它的排名夠高，之後卻從脈絡中被捨棄；或者它送到了模型面前，而模型仍然答錯。單一的準確率數字無法區分這些情況。Oloproof 將 RAG 系統當作兩個它看得見的階段來執行，分別量測每個階段，並在受控的變更下重新執行失敗的案例，以找出適用的是哪一種原因。代理與工具Oloproof 不會驅動代理。你的代理執行自己的迴圈、呼叫自己的工具，並將發生的事情記錄為一個 agent_trajectory/v1 產出物。每一項代理指標都是從這份記錄中讀出的，因此這份記錄就是整個整合。分類器與迴歸模型預測模型的評估方式與任何其他系統相同：一個可呼叫物件為每個案例回傳一個預測，再由評估器讀取。不同之處在於分母。準確率、召回率與精確率是針對三組不同資料列的三種比率，一個模型可能在其中一項上看起來很好，卻答不出業務真正在問的問題。通知通過的執行不會通知任何人。當 Oloproof 發送通知時，代表有某件事需要做出決定，或即將停止運作：被關卡阻擋的發布、已結束的託管執行、即將用完的額度。錯誤本頁存在的目的在於一個區別：失敗的執行與出錯的執行是兩回事，把其中一種呈現為另一種，就等於告訴開發者他們的變更不好，而實際上是測試工具倒了。CLI 參考Oloproof 註冊的每一個指令，以及它的作用。每個指令都接受 --help，它會印出這些摘要所依據的完整說明。