「哪個 prompt 比較好?」聽起來是個簡單的問題。實際上,評估 AI 輸出結果是應用 AI 領域中最困難的問題之一。人工評估既昂貴又緩慢。像 BLEU 或 ROUGE 這樣的自動化指標會遺漏細微差異。而單一評審的 LLM 評估會受到位置、冗長程度和評審模型本身偏好的影響。
我們建立了一個 bakeoff 系統,透過多評審評分、位置隨機化和統計信賴區間來解決這些問題。本文將介紹其架構、統計方法以及我們學到的經驗。
什麼是 Bakeoff?
Bakeoff 是一種結構化的比較方式,用於比較兩個或多個 AI「選項」——不同的 prompt、模型、recipe 或 workflow——並對相同的輸入進行評估。可以把它想像成 AI 輸出結果的 A/B 測試,但使用的是自動化評分而非使用者點擊率。
JieGou 支援 6 種 bakeoff 模式:
- Prompt vs. prompt — 相同 recipe,不同 prompt 範本
- Model vs. model — 相同 recipe,不同 LLM 供應商
- Recipe vs. recipe — 完全不同的 recipe
- Workflow vs. workflow — 不同的多步驟 workflow
- Workflow model vs. model — 相同 workflow,不同模型
- A/B test — 即時生產環境路由與使用者回饋
每個 bakeoff 最多可以有 8 個選項和 10 個輸入,總計上限為 40 個單元格(選項數乘以輸入數),以控制成本。
LLM-as-Judge 評估
每個單元格都由 LLM 評審使用清單式比較方法進行評估。評審不是獨立評分每個輸出(這會失去相對脈絡),而是同時看到所有選項的輸出結果,並根據定義的標準進行評分。
評估標準有加權,分數範圍為 0 到 100。預設配置使用:
| 標準 | 權重 |
|---|---|
| 相關性 | 30% |
| 完整性 | 25% |
| 清晰度 | 20% |
| 準確性 | 15% |
| 格式 | 10% |
使用者可以自訂這些標準或建立自己的標準。權重總和必須為 100%。
評審 prompt 會為每個選項的輸出結果標上隨機標籤(A、B、C…),並要求提供結構化分數。我們使用 invokeLLMStructured() 搭配 Zod schema,確保評審回傳有效、可解析的分數。
位置隨機化
LLM 評估中一個已知的偏差是位置偏好——模型傾向於偏好最先或最後呈現的輸出結果。我們在每次評估呼叫時都會隨機化選項到標籤的對應關係。選項 1 可能在某次執行中標記為「C」,在下一次則標記為「A」。
這不會消除位置偏差,但會將其隨機分布到各個選項中,而不是系統性地偏好某一個選項。經過多個輸入後,這種效應會平均化。
多評審共識
單一評審的評估本質上是有雜訊的。不同模型有不同偏好,即使是相同模型在相同輸入上也可能給出不同分數。我們在同一評估上並行執行 2-3 個獨立評審,並衡量他們的一致性。
Kendall’s tau 透過計算一致和不一致配對來衡量排名相關性。如果兩位評審都將選項 A 排在選項 B 之上,這是一個一致配對。如果他們意見不同,則是不一致配對。係數範圍從 -1(完全不一致)到 1(完全一致)。
Spearman’s rho 提供了補充性的衡量指標:1 - (6 * 排名差異平方和) / (n * (n^2 - 1))。
我們將一致性分類為:
- 高度一致 — Kendall’s tau ≥ 0.7
- 中度一致 — 0.4 ≤ tau < 0.7
- 低度一致 — tau < 0.4
低度一致性本身就是一個有用的訊號。這通常表示標準不夠明確、輸出結果太相似難以區分,或任務沒有明確的「更好」答案。
共識排名是透過平均所有評審的分數來計算,並彙總每個選項的獲勝次數。
統計信心度
對於每個選項,我們計算平均分數的 95% 信賴區間:平均值 +/- 1.96 * 標準差 / sqrt(n),其中 n 是輸入數量。
當兩個選項的信賴區間重疊時,我們會標記出來——這種差異可能沒有統計意義。這可以防止團隊基於雜訊做出決策。在 3 個輸入上的 2 分差異可能只是隨機的。在 10 個輸入上且信賴區間不重疊的 15 分差異則值得採取行動。
A/B Test 整合
Bakeoff 回答「理論上哪個更好」。A/B test 回答「在生產環境中哪個表現更好」。
當 A/B test 啟動時,傳入的 workflow 執行會隨機路由到不同選項(50/50 分配)。使用者對每個輸出結果提供星級評分(1-5)作為回饋,我們執行卡方檢定來確定統計顯著性。
測試在滿足兩個條件時自動停止:p 值 < 0.05 且每個選項至少有 30 個回饋回應。這可以防止過早下結論和不必要的長時間測試。
路由決策在 Redis 中快取,TTL 為 30 秒以保持一致性——同一使用者在快取視窗內重複存取端點時會獲得相同的選項。
成本管理
多評審評估會將執行成本乘以評審數量(2-3 倍)。我們在 bakeoff 開始前提供預估成本,使用歷史 token 使用量中位數作為基準,並考慮評審乘數。
40 個單元格上限(8 個選項乘以 10 個輸入)和 10 個標準限制使個別 bakeoff 保持在可控範圍內。對於 workflow 選項,我們使用多步驟 token 預測,考慮每個步驟的模型和預期的輸入/輸出大小。
我們學到的經驗
位置隨機化是必要的,而非可選的。 在我們早期測試中沒有隨機化時,無論品質如何,首先呈現的輸出結果在 60-65% 的評估中獲勝。隨機化將這個比例降至 48-52%,這在雜訊範圍內。
兩位評審可以捕捉到大多數分歧。 從 1 位增加到 2 位評審大幅提升了可靠性。從 2 位增加到 3 位評審進一步改善,但報酬遞減。對於大多數使用案例,2 位評審配合 Kendall’s tau 報告是最佳選擇。
信賴區間改變行為。 在我們加入信賴區間報告之前,團隊會針對 1-2 分的分數差異進行優化。現在他們看到重疊的區間,並正確地將其解釋為「沒有有意義的差異」。這節省了原本會花在追逐雜訊上的工程時間。
結構化輸出 schema 使評估更可靠。 早期版本使用自由格式的評審回應,並用正規表示式解析分數。這經常失敗——模型會添加解釋、使用不同格式或跳過標準。切換到 Zod 驗證的結構化輸出完全消除了解析失敗。