如何寫出你的第一組 AI 評估——SallyAnn DeLucia，Arize AI

Arize AI 產品經理 SallyAnn DeLucia 主張，靠主觀「感覺檢查」無法規模化，AI 代理需要正式、可追溯的評估機制，才能在 CI 中偵測效能退化、比較提示與模型，並為發布把關。在一場實作工作坊中，她把大部分時間花在撰寫第一份評估的實務操作：讀取追蹤（trace）、定義什麼叫「好」、把 span 篩選成資料集，以及在 Arize 的 playground 裡建構 LLM-as-a-judge 提示。相較之下，各種評估方法的整體盤點與結尾的生命週期指引著墨較少。

DeLucia 在 Arize 從事評估相關工作約四年，她最早的專案之一就是實作公司產品內的 AI 代理 Alex，如今她負責開發評估產品的一大部分。這讓她在這場論證中具備實務者的立場：她說 Alex 一開始只有幾項簡單的評估，現在已執行 32 項。讀者應該帶走一套可重複操作的配方，把觀察到的代理行為轉化為具體、可測試的判準，並清楚理解 LLM-as-a-judge 與程式碼檢查、分類器模型、人工標註、agent-as-judge 及生產環境訊號之間的定位差異。

主觀品質檢查之所以失效，是因為偵測不到效能退化

DeLucia 反對「感覺檢查」的核心論據，是一條漂移的時間軸。團隊週一改了提示，覺得「變好了」；週二又發布一次；一週後原本的修正壞了；再下一週更糟，而沒有人能證明到底修好了什麼。她說，沒有評估，你在改動提示後就偵測不到效能退化，無法客觀比較提示或模型版本，無法判斷新模型是否適合你的情境，也無法在 CI 中設定正式的品質關卡。

她把傳統單元測試與 AI 評估劃出清楚界線。單元測試有一個輸入、一個正確輸出，邏輯可讀。代理的邏輯在程式碼中讀不出來——只有執行之後、以追蹤的形式才看得見。她貫穿全場的範例是旅遊規劃代理：同一個需求可以產出許多預算分配不同的合格行程，單一預期輸出根本無法涵蓋正確性。

「追蹤是 AI 的日誌，評估才是真正的測試。」

她強調，這個依賴關係是單向的：你必須先有追蹤與可觀測性，才談得上評估。單一追蹤可能同時包含根 span、一個研究子代理、抓取天氣或網路資料的工具呼叫，以及多個 LLM span——一個負責選工具，另一個負責摘要工具輸出。這種複雜度正是單元測試看不見的部分。

六種評估方法，以及各自適用之處

DeLucia 盤點評估方法的整體樣貌，並把可貫穿開發到部署全程使用的方法，與只能在生產環境使用的方法分開。她的實務建議是優先選用能「跟著你一起成長」的方法，以免日後的努力白費。

她特別點出分類器模型近來重新受到重視：相對於這場演講的時間點，OpenAI 才在「上週」發布了決策模型的 API，大約是 2026 年 10 月中，她並把這件事與約兩週前的「Jevus 風暴」連結起來。她的判斷是，這類模型將成為評估的重要一環，因為它們便宜又快速，代價是少了 LLM 評審所提供的說明。她也把 agent-as-judge 列為大約前六個月才出現的方法。

把「好」定義成具體條件，一次一項判準

DeLucia 說，任何評估的第一步都是定義什麼叫「好」——而這正是大家卡關的地方。她的訣竅是把「有用、準確、回答得好」這類抽象詞彙，換成具體條件。以旅遊代理為例：回覆要納入使用者釐清問題時給的答案、符合指定的天數、並落在所說的預算內。

她建議每份評估只評一項品質指標。當然有例外——分類器模型與代理評審可以合併多項判準——但就 LLM-as-a-judge 而言，她引用研究指出，它一次只對一項判準表現得好。評估是迭代的，不是設好就放著：先從少數幾項開始，上線後再依真實生產資料擴充。Alex 就是她的實證，從一套簡單的評估（問答準確度、使用者挫折感、毒性與其他安全檢查）成長到 32 項。

在「通用 vs. 專屬」的取捨上，她採取務實立場：專屬勝過通用，但有任何評估都勝過沒有。Arize 的評估中心內建現成範本——問答準確度、幻覺、對話一致性等——是不錯的起點，尤其在整個組織共用時更是如此，前提是團隊要隨時間調整它們。

工作坊的學習單要求學員在動手之前先記錄六件事：被評估的任務、成功長什麼樣子、失敗長什麼樣子、究竟在評估什麼，以及通過與失敗各三點。這些條列之所以重要，是因為它們會直接變成 LLM 評審的提示——她的說法是，這就像向同事或利害關係人解釋什麼叫成功。

從追蹤到資料集，再到可用的評審提示

整個建構流程是固定的，DeLucia 現場示範。

flowchart TD
    A["在 Arize 讀取追蹤"] --> B["決定要評估哪個 span"]
    B --> C["篩選 span，例如以 parent ID 為 null 找根 span，或依工具名稱"]
    C --> D["把選中的 span 加入資料集"]
    D --> E["開啟提示 playground 並建立新提示"]
    E --> F["依六點判準撰寫評審提示"]
    F --> G["把變數對應到資料集欄位"]
    G --> H["對資料集執行，讀取標籤與說明"]
    H --> I["調整提示後重跑"]
    I --> J["儲存 estimator，供平臺上各處使用"]

篩選這一步決定了你實際在測什麼。要評估行程是否反映使用者輸入，就存下根 span，以 parent ID 為 null 來辨識。要測工具呼叫是否回傳正確資料，就存下工具呼叫的 span，依工具名稱篩選。在 span 檢視中選取後，加入新的資料集。

在 playground 裡，她建立一個名為「AI Engine Scores」的提示，寫入評審範本：開頭說明評審的職責（評估助理的輸出是否準確反映輸入中所要求或提供的細節），接著放資料，再放從學習單抄來的通過／失敗判準。她刻意不把變數名稱寫死。Arize 用變數對應把提示中的佔位符綁到實際資料欄位，因此即使資料集的欄位名稱與追蹤不同，評估也能直接執行，不必重寫——只要在使用該評估的地方更新對應關係即可。

標籤設定很有彈性：二元的是非對錯、三級的正確／部分正確／錯誤，或加上「不適用」選項。在 Alex 中，她採用部分給分的標籤，因為差一點點的情況確實有差。每份評估還有一個最佳化方向設定，宣告分數越高越好還是越低越好。她先用 GPT-4o mini（逐字稿中稱「41 mini」）跑第一次測試，讀標籤與說明，調整提示後重跑，然後儲存 estimator，讓它在平臺上供示範專案及其他任何應用程式使用。

說明與校準，是評估有別於指標的關鍵

DeLucia 對指標與評估的區分，是全場最犀利的一段框架：指標告訴你某個東西可能壞了；評估告訴你壞掉的原因。說明欄位——也就是評審為其標籤陳述的理由——正是讓標籤值得信任、而不是照單全收的關鍵。

她也把 Arize 產品內的代理 Alex 當成加速建構的利器：它可以操作 playground、讀取結果、更新提示、再重複一輪，她特別建議在最初撰寫判準的階段之後使用。除了建構之外，她也勾勒生命週期的其餘環節——對齊（標註資料集範例，檢查評估結果是否與人工回饋一致）、線上評估（自動讓每一筆送出的追蹤對所有判準執行，並發布結果供監控），以及 Arize 託管的「signal」代理，它會分析追蹤、找出問題，並能提出修正建議。

她在組織層面的重點是：評估不是一個人的工作。產品、工程、客服、領域專家和資安都應該一起定義成功，因為每個人看到的失敗模式都不一樣。

從二十筆追蹤與一位評審開始

結尾的建議刻意壓得小：先從約 20 筆追蹤、一項指標、一位評審開始；讀說明、調整說明，再逐步增加評估。她建議做一個值得一試的實驗——把現有的 LLM-as-a-judge 評估改寫成一連串是非題，交給分類器評審，比較兩者表現，看看哪一種更適合你的情境。

她指出的資源包括 Arize 關於 LLM-as-a-judge、分類器，以及決策模型基準測試的檔案，另有一份以 QR code 連結的 Notion 指南，以及當天下午四點開幕的展位。

整場演講留下的未解張力，正是她提出卻沒有定論的那一點：分類器更便宜、更快，但不給說明；LLM 評審會自我說明，但一次只處理一項判準，且每次呼叫成本更高。她提出的答案——兩者都跑、互相比較——是一套工作流程，還稱不上定案的最佳實務。未來幾季在建置評估套件的團隊，應該觀察兩件事：以分類器為基礎的評審，能否把說明能力的落差補到足以在例行檢查中取代 LLM 評審；以及「一份評估一項判準」的做法，在面對每筆追蹤都要跑數十位評審的成本時，是否還能維持。