人工審查

你自己的團隊成員可以在 Oloproof 中為系統的回答加上標籤，這些標籤既可以單獨決定一次發布，也可以檢驗做出發布決定的評審。本頁彙整現有功能，並指出每一部分的完整說明在哪裡。

人可以標註什麼

• 針對一個標準，逐個案例標註通過、不通過或無法判斷。
• 在你選定的量表上給出分數，例如 1 到 5。
• 在兩次執行對同一案例的回答之間給出偏好，回答以 A 和 B 顯示，順序由工作區透過一次有紀錄的擲硬幣決定，因此審查者無法分辨哪次執行是哪個。
• 對同一案例的兩個回答都給出通過或不通過，用於依人的判定比較兩個版本。

為佇列撰寫的評分準則會顯示在每個案例旁邊。

在哪裡標註

在瀏覽器中。 在託管工作區中，Owner 或 Admin 從專案的 Review 頁面開啟一個審查佇列並指派審查者。每位審查者看到指派給自己的佇列，並用按鈕或 P、F、C 鍵標註。來自未指派到該佇列之帳戶的判定會被拒絕，每筆判定都記錄在審查者自己的帳戶下。

在終端機中。 oloproof review RUN --criterion NAME --by YOU 每行標註一個案例。不加其他選項時，它一次完成對評審的檢驗：依你的門檻決定大小的盲樣本、以你的標籤衡量評審，以及重新判定這次執行。

在試算表中。 oloproof labels export RUN --criterion NAME --sample 50 寫出一個待填寫的 CSV，oloproof labels import 要麼記錄所有已填寫的列，要麼一列都不記錄。可將它用於在 Oloproof 之外工作的審查者，包括標註供應商。來自檔案的標籤在你的機器上計入，但不計入工作區對其自行抽取之樣本所做的檢驗。

運作佇列

當 Owner 或 Admin 開啟一個佇列時，每位審查者都會收到被指派的電子郵件，除非他們關閉了審查郵件。佇列可以設定截止日期，顯示在佇列和電子郵件中；它不決定任何事，到期時也不會寄出任何內容。在佇列頁面上，Owner 和 Admin 可以看到每位審查者的進度（已完成的案例及其最近一次判定），並可以修改截止日期。

審查佇列的審查者可以隨時更改，每位新增的審查者都會收到電子郵件。測量佇列的審查者不能更改：他們是其隨機樣本的一部分，且只有他們的標籤在該佇列中計數，因此其他審查者需要接手一個擁有自己樣本的新佇列。

兩種佇列

測量佇列讓工作區抽取隨機樣本，並隱藏評審的判定。其標籤用於衡量評審，或僅由人來判定一條規則。已標記案例的審查佇列顯示評審的判定，並在不測量任何東西的情況下處理這些案例。只有第一種能代表整個測試套件。

審查者意見不一致時

專案可以要求每個抽樣案例有兩名或更多審查者，依帳戶計數。當他們在通過或不通過上意見不一時，工作區不做任何判定，直到一位未標註過該案例任何部分的 Owner 或 Admin 在佇列頁面或執行頁面上將其裁定。人與人之間的一致程度顯示在每個評估器旁邊，表示為意見一致的審查者配對所占比例，並附上其區間，同時也表示為 Krippendorff 的 alpha：它在大多數回答都通過的標準上，從該比例中扣除僅憑偶然就會產生的一致，1 表示完全一致，0 表示偶然。當有 300 個案例由兩人或更多人標註時，alpha 會附上區間；不足時只顯示 alpha 本身，並說明原因。它不做任何判定。

有三名或更多審查者的通過或不通過量測佇列，也可以改為依多數讀取，這在開啟佇列時選擇。每位審查者的第一個判定就是其投票；當一個案例超過半數的審查者意見一致時即計入，平手則等待一位 Owner 或 Admin 裁定。一次執行在同一標準上的通過或不通過佇列都以相同方式讀取。

分數、偏好以及兩次執行上的通過或不通過無需這種選擇：每個案例的值是標註過它的所有審查者的平均值，因此分歧會移動該值，而不是等待裁定，嚴格或寬鬆的審查者也是回答所衡量內容的一部分。

來自供應商的標籤

通過或不通過量測佇列或分數量測佇列可以由供應商的評分員而非成員來標註。開啟佇列時選擇「由供應商標註」並填寫評分員的姓名。在佇列頁面下載表格（每個抽取的案例和每位評分員一列，填寫通過或不通過，或依佇列量表給出的分數），連同要顯示的回答交給供應商，然後上傳傳回的 CSV 或 XLSX。每一列都會被檢查：佇列未抽取的案例、佇列未列名的評分員，或同一評分員對同一案例的第二個判定，都會使整個檔案被拒絕。

此後每位評分員都依姓名計為一名審查者，因此一致率、alpha、答案鍵上的準確率和多數都會讀取他們。在依賴供應商的評分員之前，先為幾個案例設定答案鍵來檢驗他們；他們的準確率會被回報，但不做任何判定。工作區知道它收到的檔案，而不知道是誰看過：每個標籤都記錄上傳它的帳戶。

答案鍵與審查者準確率

Owner 或 Admin 可以為通過或失敗佇列中的部分案例設定答案鍵：開啟一個案例，將其鍵設為通過或失敗。只有未被該佇列指派的 Owner 或 Admin 能看到答案鍵，因此審查者不知道哪些案例設有答案鍵。隨後，審查頁面向 Owner 和 Admin 顯示每位審查者設有答案鍵的回答中與答案鍵一致的比例及其區間，並按月顯示同樣的資料。

計入的是審查者對設有答案鍵的回答給出的第一個通過或失敗；「無法判斷」顯示在旁邊，裁決和答案鍵作者本人的判定不計入，且一個答案鍵只針對一個回答，因此對另一次執行就同一案例給出的回答所作的判定不參與比較。答案鍵絕不是標籤，也不決定任何事。該區間把設有答案鍵的案例視為同類案例的隨機樣本；手工挑選的答案鍵並非如此，因此請把它理解為在這些案例上的準確率。

人的標籤決定發布

• human_score：根據人已評分的案例，人對整個測試套件給出的分數。
• human_preference：人是否較偏好候選版本而非基準，以及偏好多少。
• human_difference：人判定候選版本通過的頻率比基準高多少。
• judge_bias_bar：由評審判定的比較會交給人處理，除非人的標籤顯示評審對兩個版本一視同仁。

每一項都在 release.yaml 或 compare.yaml 中宣告，其方法以及它不能宣稱的內容在評審中說明。無人標註的案例依其最差值計入，因此不標註困難案例永遠不會有幫助。

尚未建置

以下內容目前尚不存在：

• 由供應商標註審查佇列、偏好或兩次執行上的通過或不通過：它們都依工作區為每位審查者決定的順序向審查者顯示兩個回答，而在 Oloproof 之外製作的檔案無法維持這個順序。

Oloproof 不提供審查者，也不連接供應商自己的工具。