開始使用
核心概念
Oloproof 量測 AI 系統的方式，就像一項研究量測任何事物的方式：同樣的案例、同樣的評審、同樣的亂數種子，在每一次變更時執行。它在測試套件之上增加的，是每個數字都附帶其不確定性，而發布決策是依據區間而非估計值做出的。
證據鏈
共七個環節，每一個都是可以單獨閱讀的紀錄。
| 環節 | 內容 |
|---|---|
| 觀察 | 系統做了什麼，以執行產物的形式擷取 |
| 量測 | 評估器對它所做的判斷 |
| 推論 | 在明確的分母上、附帶區間的指標 |
| 診斷 | 聚類成因素的失敗，附帶計數與假設 |
| 決策 | PASS、FAIL、INSUFFICIENT_EVIDENCE 或 MANUAL_REVIEW |
| 建議 | 一個發布動作，它是一個欄位，而不是第五種狀態 |
| 證據 | 讓其他人能夠核對這一切的來源紀錄 |
每個環節都分開儲存，並且可以獨立重複使用。對未變更的候選版本重新執行套件時，會重複使用它已有的執行結果與判斷，這就是為什麼重複執行幾乎不花成本。
四種決策狀態
恰好有四種，而其中一種正是這個產品存在的理由。
- PASS —— 區間的下界達到最低門檻。
- FAIL —— 區間的上界低於它。
- INSUFFICIENT_EVIDENCE —— 兩者皆非，因此證據無法做出決定。
- MANUAL_REVIEW —— 由於方法拒絕回答，因此交由人來判斷。
對於最低門檻 T 與區間 [L, U]：當且僅當 L >= T 時通過，當且僅當 U < T 時失敗，否則為證據不足。最高門檻規則則是其鏡像。
INSUFFICIENT_EVIDENCE 不是一種較輕微的失敗。當套件太小、或效應太接近門檻而無法與雜訊區分時，它是誠實的答案；而把它當成通過，是評估誤導執行它的團隊最常見的一種方式。
什麼不是決策狀態
RUN_ERROR、PARTIAL 與 CANCELLED 描述的是一次執行發生了什麼，而不是對一個系統做出了什麼決定。發生錯誤的執行完全不帶任何品質結果，而把它呈現為失敗，等於告訴開發者他們的變更不好，但事實是測試框架自己倒下了。
這個區別在最不方便的時候最重要。一個把未評分案例算成零的指標，會把系統自身的停機當成品質失敗記在模型頭上，這是以這個引擎對一個上線中的助理進行測試時得到的真實發現。
分母
比率是一個數字除以一個分母，而分母正是評估悄悄出錯的地方。Oloproof 為每個指標記錄四個計數——總數、符合資格、已觀察與缺失——而無法量測的案例會被界定範圍，而不是被丟棄。
一個在系統開始失敗時縮小的分母，正是失敗中的系統回報分數上升的方式。
下一步
- 撰寫套件：案例、系統與評估器是什麼，以及如何宣告它們。
- 在 CI 中設閘：把決策轉換成結束代碼。
- 評審：LLM 評審在可以為發布設閘之前必須通過什麼。
- 叢集案例：當案例彼此不獨立時會有什麼改變。