Name: Potato
Author: Potato

一旦你開始大規模評估智慧體，瓶頸就不再是"我們能不能標註它"，而是"我們把注意力花在誰、花在什麼上"。你有成千上萬條生產環境軌跡，卻只有寥寥幾名審查者。LLM 評判者可以對所有內容進行預篩，但它並不完美，而它判斷錯誤的那些情況，恰恰是值得人工花時間處理的情況。

Potato 2.6 中有兩項功能協同應對這種稀缺。基於訊號的分流佇列決定人工最先看到什麼。評判者—人工對齊衡量你能在多大程度上依賴評判者，並使其不斷改進。把兩者一起執行，你就得到一個主動評估閉環：評判者處理大量簡單內容，可疑案例插隊送達人工，而分歧又反饋回去，造就更好的評判者。

本文將介紹這兩個部分以及它們如何銜接。

標註過程中的優先順序徽章，說明某條目為何被標記為待審查 Potato 中的分流佇列徽章

分流部分：最糟糕的優先，而非先進先出

預設情況下，標註佇列是 FIFO（先進先出）：條目按載入順序被分發。當審查時間稀缺時，這是錯誤的順序。一條幹淨的軌跡和一條智慧體丟擲錯誤的軌跡，所值得的人工注意力截然不同，而 FIFO 對它們一視同仁。

分流佇列按每個條目的品質訊號對佇列重新排序。該訊號可以是智慧體錯誤、生產環境中的點踩、較低的自動評分，或你資料中的任何欄位：

yaml

triage:
  enabled: true
  order: desc            # high priority first (default)
  show_badge: true       # banner during annotation explaining the priority
  rules:                 # evaluated in order; highest matching priority wins
    - name: "Agent errored"
      priority: 100
      when:
        field: status
        equals: error
    - name: "Negative feedback"
      priority: 80
      when:
        field: feedback
        in: [thumbs_down, negative]
    - name: "Low quality score"
      priority: 60
      when:
        field: score
        lt: 0.5
 
assignment_strategy: priority

規則自上而下評估，匹配到的最高優先順序勝出，因此一條既出錯又帶有負面反饋的軌跡仍會落在 100。如果你完全省略 rules，Potato 會回退到一套合理的預設規則（錯誤狀態為 100，負面反饋為 80，評分低於 0.5 為 60），所以在你調優之前，開箱即用的行為就已經很合理。

條件運算子覆蓋了你實際需要的各種比較：

Operator	含義
`equals`	精確匹配（字串不區分大小寫）
`in`	值是列表中的某一項
`contains`	列表包含，或子串匹配
`lt` / `lte` / `gt` / `gte`	數值比較
`exists`	欄位存在或不存在

當訊號本身就是數字時，你可以直接從欄位讀取，而無需編寫規則：

yaml

triage:
  enabled: true
  signal_field: quality_score
  invert_signal: true           # lower score => higher priority

An item's fields are matched against priority rules in order; the highest matching rule wins and places the item at the top of the queue How an item gets its triage priority

它同樣適用於即時流量

優先順序分數在條目載入或被攝取時計算一次，隨後儲存在條目上，因此分配過程始終很輕量。同樣的設計意味著執行時攝取可以直接生效：通過 webhook 端點或 Langfuse 輪詢器在會話中途推入的軌跡，會在到達時被評分，並按優先順序順序就位。一條在下午兩點到達的低分或出錯軌跡，會插到今早就在等待的那些乾淨軌跡之前。設定 assignment_strategy: priority 才能讓佇列真正按該順序分發；show_badge 是獨立的，因此即使你保留另一種策略，"為何被標記"的橫幅也會顯示。

對齊部分：該多大程度上信任評判者

分流決定人工看到什麼。對齊決定其餘部分有多少可以無人監督地交給評判者，並隨時間收緊評判者。

評判者對齊會在標註者已經標註過的實例上執行一個可配置的 LLM 評判者，然後報告 Cohen's κ（科恩 kappa 一致性係數）、一個混淆矩陣，以及一份針對人工金標準的分歧列表。標準做法（讓評判者對齊約 100–200 條金標準標籤、檢查它在哪裡產生分歧、改寫 rubric 評分標準，然後重新執行）正是這套機制所圍繞的閉環。

yaml

ai_support:
  enabled: true
  endpoint_type: "ollama"
  ai_config:
    model: "llama3.2"
    temperature: 0.0
 
judge_alignment:
  enabled: true
  schemas:
    correctness:
      rubric: >
        Label 'correct' only if the agent's answer is factually right and fully
        satisfies the request; otherwise 'incorrect'.
  inline:
    enabled: true                # show the judge verdict beside the human label
    schemas: [correctness]

你可以從管理 API 執行評判者，預測結果會按提示詞版本快取，因此重新執行成本很低：

bash

curl -X POST localhost:8000/admin/api/judge-alignment/run \
  -H "X-API-Key: <admin-key>" \
  -H "Content-Type: application/json" \
  -d '{"max_per_schema": 200}'

當你想要校準時，傳入一個編輯過的 rubric。這會建立一個新的提示詞版本，因此你可以跨多輪比較 κ，真正看出你的改寫是否有幫助：

bash

curl -X POST localhost:8000/admin/api/judge-alignment/run \
  -H "X-API-Key: <admin-key>" -H "Content-Type: application/json" \
  -d '{"rubrics": {"correctness": "Stricter rubric text..."}}'

該報告可以 JSON 形式獲取，或在 /admin/judge-alignment 檢視渲染頁面，它會顯示帶 Landis–Koch 解讀的 κ、混淆矩陣、一份附帶評判者推理的分歧表格，以及一段提示詞版本歷史，從而讓校準進展跨多輪可見。

內聯模式將其呈現在標註者面前

啟用 inline.enabled 後，每個標註頁面都會在人工標籤旁邊顯示評判者的快取裁決（它的選擇、置信度，以及可展開的推理），並附上該任務的即時 κ。點選"接受"會填入相匹配的選項。每一次人工儲存都會記錄一次人工↔評判者的比較，並匯入即時一致性，因此你正在調優趨近的那個 κ 會隨著人們工作而更新。

將兩者結合起來

這兩項功能在設計上可以組合成一個閉環：

生產訊號匯入優先順序佇列；人工審查頂部條目；他們的標籤衡量評判者 kappa；改進後的 rubric 反饋回去主動評估閉環：分流、人工審查、評判者對齊、rubric 改進

分流將出錯和低置信度的軌跡推到人工佇列的最前面。
人工審查這些高價值條目，恰好在系統最不確定的地方產出新鮮的金標準標籤。
對齊用這些金標準為評判者打分，分歧列表精確顯示評判者與人工在何處產生分歧。
你改進 rubric、重新執行、觀察 κ 的變化，然後讓校準更好的評判者吸收更多簡單內容，使人工時間持續流向困難案例。

閉環的每一次迴圈都把人工注意力花在最有價值的地方，並將其轉化為一個你可以更進一步信任的評判者。這正是全部要點：不是把人從智慧體評估中移除，而是為他們指明方向。

這兩項功能都包含在 Potato 2.6 中。完整參考請參閱分流佇列文件和評判者對齊文件，以及用於快速閱讀優先軌跡的 eval_trace 顯示。