用來衡量AI模型表現的方法。這遠遠超出基準測試—它包括人工評估（讓人類評分輸出結果）、A/B測試（在真實流量中比較模型）、紅隊測試（對抗性測試）、特定領域測試（醫療準確性、程式碼正確性），以及社群排行榜（Chatbot Arena、LMSYS）。良好的評估難度甚至高於建立模型本身。
若無法衡量，便無法改進。但AI評估獨特地困難，因為任務是開放式的，品質主觀。基準測試常被操縱，人工評估成本高昂，而紙上得分最高的模型，往往在實際應用中並非最佳選擇。建立良好的評估方法是一種超能力。
在AI領域中，評估工作看似簡單，實際上卻極具挑戰性，因為你試圖衡量的東西——「這個輸出是否良好？」——往往具有主觀性、依賴於情境，且是多維度的。一個模型對「解釋量子糾纏」的回應可能正確但過於技術性，不適合目標受眾；或者易懂但稍有錯誤；或者完全正確但令人乏味。傳統軟體測試有明確的通過/失敗標準，而AI評估卻很少如此。這就是為什麼這個領域發展出多種互補的方法：用自動化基準測試廣泛能力，用人工評估判斷品質，用LLM作為評審來實現人類判斷的可擴展近似，以及針對特定任務的指標來處理窄領域問題。沒有單一方法足夠。評估得好的團隊會將所有方法層層疊加使用。
像MMLU、HumanEval、MATH和GPQA這樣的公開基準，為你在明確任務上比較模型提供了標準化方式。它們有助於粗略了解模型的能力，並追蹤隨時間的進步。但你在依賴它們之前，必須了解它們有嚴重的限制。基準污染現象非常普遍——訓練數據通常包含基準問題，因此高分可能反映的是記憶能力而非真正能力。基準飽和意味著一旦大多數前沿模型在測試中得分超過90%，它就不再具備資訊價值。而最根本的問題是，基準測試的是狹窄且明確的技能，而實際應用卻需要廣泛、混亂且依賴情境的推理。一個在MMLU得分92%、在HumanEval得分87%的模型，可能在你特定的應用場景中（例如撰寫Symfony控制器、總結法語法律文件，或為你特定的資料庫結構生成SQL）表現得非常糟糕。基準告訴你模型一般能做什麼，而你自己的評估則告訴你它能為你做什麼。
你能做的最有價值的評估工作，就是為你的應用建立一套特定的測試套件。首先，收集50到100個你系統實際會遇到的輸入範例，以及對應的正確輸出形式。這些範例可以是實際的用戶查詢、人工合成的邊界案例，或是探測已知失敗模式的對抗性輸入。對於每個範例，盡可能具體地定義「正確」的含義——預期的關鍵字、必要的結構、必須存在或不存在的事實聲明、語調標準等。然後自動化評估：將你的提示詞套用於每個範例，對輸出進行評分（使用精確匹配、正則表達式或LLM作為評審），並追蹤隨時間的結果。Braintrust、Langfuse和Promptfoo等工具可以讓這項工作更容易，但你也可以用電子試算表和腳本來實現。重點是要有可重複的流程，這樣當你修改提示詞、更換模型或更新檢索流程時，可以立即看出情況是變好了還是變差了。
使用一個LLM來評估另一個LLM的輸出——也就是「LLM作為評審」的模式——已成為可擴展評估的預設方法。你會讓一個強大的模型（通常是GPT-4或Claude）看到原始問題、模型的回應以及評分標準，並請它根據準確性、幫助性與安全性等標準對回應進行評分。這種方法在許多任務中驚人地有效，特別是當你提供詳細的評分標準和校準範例時。但它也有盲點：LLM評審傾向偏好較長的回應，可能忽略細微的事實錯誤，並表現出位置偏見（在成對比較中傾向於選擇先出現的回應）。人工評估仍然是對品質敏感應用的黃金標準。Scale AI和Surge等服務提供受過訓練的註釋員，但即使非正式的人工審查——讓三位團隊成員獨立評估50個輸出——也能發現自動評估所錯過的失敗模式。最穩健的評估流程會使用自動化指標作為快速篩選，LLM作為評審處理中等信心的決策，並在高風險或有歧義的情況下使用人工審查。
評估中最困難的部分不是技術性的——而是文化性的。成功推出優秀AI產品的團隊會將評估視為一等一的工程學科，而非後補措施。他們在撰寫提示詞之前就會先撰寫評估，就像優秀的開發者在寫程式碼之前會先寫測試一樣。他們維護活著的評估套件，隨著在生產環境中發現新的失敗模式而持續擴展。他們也會抵制為了基準分數而犧牲實際表現的誘惑。如果你的模型在你的評估套件中表現完美，但用戶卻在抱怨，那麼問題出在你的評估，而不是用戶。最好的評估框架是那些能讓你誠實面對系統實際所做之事的框架，尤其是在它失敗的情況下。