離線評估能告訴你哪個 AI 設定在測試資料上看起來較好。A/B 測試則告訴你哪個在生產環境中表現更好,面對真實使用者和真實輸入時。JieGou 的 bakeoff 系統兩者皆支援——而本指南著重在即時 A/B 測試的部分。
何時該使用 A/B 測試(相對於離線評估)
離線 bakeoff(在固定的輸入集合上比較輸出)適合用於:
- 發布前的初始模型選擇
- 開發期間的 prompt 迭代
- 比較根本上不同的方法
即時 A/B 測試較適合當:
- 你已經篩選出 2 個強勁的候選方案
- 生產環境的輸入在某些重要面向上與你的測試集不同
- 你想要衡量長期的真實世界表現
- 利害關係人需要生產環境資料來支持決策,而非測試結果
設置 A/B 測試
以下是在 JieGou 中的逐步流程:
步驟 1: 建立具有 A/B 路由的 bakeoff
進入 bakeoff 區塊並選擇「A/B Test Routing」作為模式。選擇你想比較的兩個變體——這些可以是兩個 recipe、兩個模型設定,或兩個 workflow。
步驟 2: 配置流量分配
預設情況下,流量在變體之間以 50/50 分配。如果你想保守一點,可以調整這個比例——例如 90/10 來限制實驗變體的曝光,同時仍能收集資料。
步驟 3: 設置自動停止條件
JieGou 使用卡方統計檢定來判斷何時一個變體明顯優於另一個。你可以配置:
- 最小樣本數 — 在每個變體至少執行 N 次之前不宣告勝者
- 顯著性門檻 — 宣告勝者的 p-value 門檻(預設值:0.05)
當達到自動停止條件時,JieGou 會自動將 100% 的流量路由到獲勝的變體並通知你。
步驟 4: 監控結果
測試執行期間,bakeoff 儀表板會顯示:
- 每個變體的執行次數
- 隨時間變化的 LLM judge 分數
- 目前的統計顯著性
- 根據目前流量估算達到顯著性的時間
步驟 5: 檢視並定案
當測試結束時(透過自動停止或手動決定),檢視完整結果:分數分布、信賴區間、成本比較,以及執行時間差異。然後將獲勝的變體提升為預設值。
一致性保證
A/B 路由決策會快取在 Redis 中。一旦特定的執行環境被分配到某個變體,它在測試期間會持續使用該變體。這避免了同一個 recipe 在連續執行時產生不同結果的混淆情況。
要測量什麼
LLM judge 分數是主要指標,但也要考慮這些額外的訊號:
- 執行成本 — 品質略低但成本少 60% 的變體可能是更好的生產選擇
- 執行時間 — 即使品質相同,更快的回應能改善使用者體驗
- 錯誤率 — 有 5% 失敗率的變體比從不失敗的變體差,即使成功時的分數較高
實用技巧
- 至少執行測試 48 小時以捕捉不同時段和星期幾的輸入模式變化
- 不要一次 A/B 測試太多項目 — 同時改變模型和 prompt 會讓你無法歸因差異來源
- 在開始前記錄你的假設 — 「我預期 Claude 變體在細膩度上得分較高,但成本是 2 倍」能幫助你評估結果是否可行
- 先使用離線 bakeoff 來縮小範圍,然後在生產環境中 A/B 測試前 2 名候選者
可用性
A/B 測試路由適用於 Enterprise 方案。離線 bakeoff(recipe 對 recipe、模型對模型)適用於 Pro 方案。深入了解所有 bakeoff 模式。