模型撰寫，裁判測量：LLM裁判剖析

本文探討了如何構建一個獨立的LLM裁判來評估AI助手在解釋鑽石時的輸出質量。作者Sam Wen指出，AI助手可能生成流暢但誤導性的陳述，例如“在這樣的淨度級別下，肉眼什麼也看不到”——這句話看似合理，但實際上淨度級別SI1是在10倍放大鏡下評定的，並不直接決定肉眼可見性。這種問題無法通過簡單的關鍵詞過濾解決，因為它是句子與證據之間關係的錯誤。

為了解決這個問題，團隊設計了三個層次的防護機制。第一層是預防，通過代碼在管道中阻止模型提出無法從證據中回答的問題。例如，當助手生成關於鑽石的後續問題時，必須指明從哪條證據路徑獲取答案，若沒有可用路徑，問題會被代碼直接拒絕。第二層是捕捉，使用確定性驗證器檢查腳本中是否出現禁止詞彙，如“驚人”、“必須擁有”等。這些規則基於領域專家的風格指南，但需要謹慎處理上下文相關詞彙——例如“flawless”在鑽石領域是專業等級而非空洞讚美，因此交由裁判判斷而非簡單過濾。第三層是裁判，由另一個LLM負責檢查那些看似合理但缺乏支持的陳述。

裁判的設計非常獨特。它不返回簡單的1-10分，而是提供詳細的裁決：逐句分類，區分關於此石頭的聲明和一般性知識，並檢查是否有證據支持。它還能處理歸屬錯誤——例如將實驗室的評級歸功於商家。裁判必須列出所有聲明及其分類，形成可審計的記錄。此外，裁判還測量語氣和格式，但保持正交信號互不干擾，温暖語氣不能掩蓋不支持的聲明。

為了保持裁判本身的誠實，團隊採用了多種方法。裁判與作者共享同一套規則文檔，確保標準一致。裁判從不評價自己的輸出，而是使用不同的模型（最初用GPT-5.5，後改用Claude Opus 4.8）。裁判僅在開發環境中使用，不會增加生產環境的延遲或成本。團隊還通過校準循環處理裁判的錯誤——例如，針對“flaw”一詞的過濾規則曾錯誤地攔截了“not a flaw”這一誠實表述，於是規則被修正為僅禁止聲稱無瑕疵的絕對化表達。

最後，作者分享了引入裁判後結束的三個爭論：選擇哪個模型（Claude Sonnet 5明顯優於Haiku 4.5，前者平均0.8個違規而後者約10個）、提示詞的長度（更長不一定更好）、以及如何測量質量（裁判提供客觀基準）。裁判不僅解決了質量問題，更讓團隊能夠基於數據而不是個人偏好做出決策。