基礎模型雖已有進步，但真正令人有信心投入生產環境的關鍵轉變，來自嚴謹有序的評估實務
設計周全的評估有助產品經理、AI 管治主管及技術總監安全地大規模部署 AI 智能代理，令 AI 從各自為政的玩具變成競爭優勢。
這份信心來自以真實用戶查詢、邊緣個案及切合實際業務情境的領域特定場景，評估 AI 智能代理的行為，而不是靠公開基準聲稱「這個模型最好」
目標是以可量度的成果證明這份信心有理有據。成功意味以具體、可量度且切合業務需要及風險承受能力的方式定義「良好」表現，不論指事實準確度、合適語調、速度還是成本效益。
把評估融入整個系統，包括檢測、記錄、A/B 測試及防護機制，並兼顧嚴謹與效率，團隊便可更迅速地部署，並提升系統穩健性。
大多數企業都不介意員工試用 ChatGPT 或 Gemini。然而，在高風險工作流程或環境中實際運用 LLM，仍不常見。
箇中原因往往合理：品質表現不一，而產生幻覺或不當行為的風險，也一直高於這項技術可能帶來的效益。
過去一年，風險與回報之間的平衡已明顯轉變。這部分歸因於基礎模型效能提升，但很大程度也有賴日益嚴謹的評估方法。評估讓我們和客戶有信心在數星期內部署大規模、面向客戶的智能代理。
本指南將說明評估的基礎要素，以及如何針對生產環境的使用情境設計、實施和運作評估。
評估的目的不是找出完美模型，而是建立有理有據的信心，確定模型行為符合業務需要、用戶期望及機構的風險承受能力。
任何評估策略都建基於一個簡單問題：怎樣才算「良好」？答案必須具體。對某機構而言，「良好」可能代表事實準確度須嚴格控制在指定誤差範圍內；另一機構則可能更重視速度、成本效益或鮮明語調。從可使用哪些數據到適用的監管責任，營運所受的每項限制都會影響這個定義。
關鍵是，「良好」必須包含真正可量度的元素。若成功代表提供實用的財務指引，便要以不同屬性體現實用程度，包括事實正確、免責聲明恰當、推理切合個人情況，以及設有安全界線。以可量度的方式定義「良好」後，下一個問題就是如何分析及解讀結果。根據結果採取行動，才能令評估成為一套方法，而非單憑主觀判斷。
每套評估流程都建基於三個互相關連的支柱：
輸入／基準：以具代表性的現實例子測試整體效能，並以精心整理的內部數據集測試特定領域的可行性。
模型行為：如何調用模型（檢索增強生成、摘要、結構化資料檢索及工具使用）。
指標：如何量度及解讀效能。
輸入必須能代表系統實際面對的情況。最有價值的見解來自真實例子，例如客戶查詢、財務情境或業界特定個案。只有以這些例子測試，才能了解模型是否真正掌握用戶所需的細微差異，並滿足業務需要。
模型如何接收提示、如何協調檢索或工具使用，以及如何輸入情境等行為，與模型本身同樣重要。兩個相同的模型可因部署方式不同而表現迥異。因此，評估設計必須涵蓋這一層。
最後是指標。單憑數字很少能反映全貌，但適當選取的指標可讓系統行為清晰可解讀。延遲、準確度、安全性、連貫性、偏差、成本和用戶滿意度，結合起來便能呈現生產系統的多維面貌。選取指標的竅門，是讓它們配合項目或業務的關鍵績效指標，並突顯用戶最重視的特質。較簡單的指標通常更準確、成本更低；選錯指標則可能誤導團隊。選取指標時可從以下角度考慮：
合適指標範例：
客戶服務聊天機械人：首次聯絡解決率（用戶問題能否在不升級處理的情況下解決？）、平均處理時間、用戶滿意度評分、轉交真人客服的比率
財務研究工具：引文準確度（附有恰當來源的陳述百分比）、經標準答案驗證的事實準確度、檢索相關性（有否找到正確文件？）、由領域專家評分的推理連貫性
程式碼生成助手：語法正確度、測試通過率、安全漏洞數量、得出可行解決方案所需時間
不當指標範例：
僅以回應長度代替品質指標（越長不等於越好）
量度速度時沒有考慮準確度上的取捨
追蹤模型信心評分，卻沒有按實際正確程度加以驗證
只依賴模型內部的困惑度，沒有進行面向用戶的驗證
應避免的常見指標陷阱：
指標互相衝突：同時優化速度與全面程度，卻沒有正視兩者之間的取捨
過度配合基準：在測試集取得 95%，卻因真實用戶行為不同而在生產環境失效
我們有一名金融服務客戶受到高度監管，因此其深度研究方案以準確度為首要考慮。我們結合專家編製及工具生成的問答數據集，以評估準確度，以及系統能否選取合適工具並檢索正確資料，從而兼顧準確度與推理品質。關鍵是量度多個維度：事實準確度（專家驗證）、檢索品質（相關文件的精確率／召回率）及推理連貫性（以結構化方式評估邏輯脈絡）。
何時使用 LLM 評審判斷細緻的品質差異
LLM 評審以另一個 AI 模型擔任評估者，以可擴展的自動品質評分取代人手審核。即使較簡單的指標已可達到所需準確度，LLM 評審仍經常遭到濫用。若確定性檢查無法反映品質，例如指標涉及語義（實用程度、依據充分程度、推理品質、語調或政策詮釋），而確定性評分並不可行，LLM 評審便可能有用。您可能需要就大量提示詞／模型版本取得可擴展的意見，並訂立清晰的評分準則及結構化輸出內容的結構定義。要讓這種方法發揮作用，請依循以下步驟：
明確界定評分準則的各個維度：正確度、依據充分程度、政策合規、可行性及語調。
評審回應應使用結構化輸出內容（JSON 結構定義）。
同時記錄二元門檻評分及診斷文字，以便分析失敗原因。
每個發佈週期都以人手標註樣本校準評審輸出。
高風險領域應採用雙評審或定期共識檢查。
持續追蹤評審偏移及意見分歧率。
基準數據集是一組固定、經整理且已有標準答案的測試例子，用於一致地評估模型，並公平比較各版本的結果。當中通常包括輸入（例如用戶查詢）、預期輸出或參考判斷，以及用於評分的評估準則／標籤。公開基準測試用於比較最先進模型的效能。設計系統初期，可參考這些測試，初步判斷哪些模型適合採用。
然而，就自家系統而言，您不能依賴這些基準代替實際業務情境下的效能，因為它們存在一些已知問題：
污染：模型的訓練數據可能包含基準數據；再以同一數據集評估，猶如讓考生拿着答案評分。
飽和：所有頂尖模型的分數都已接近上限，因此效能升跌只會相差數個百分點，而且往往落在測試結果的自然波動範圍內。
範圍狹窄：基準數據經過高度整理及清理，無法反映您的實際工作。部分數據甚至由 LLM 生成，無法反映您數據中的複雜情況和邊緣個案，例如錯字、不尋常措辭或雜訊影像。
學生要求應用程式協助解答應用題。
可使用的公開基準範例：GSM8K（小學程度的數學推理）
可選用難度較高的數據集：MATH。
這項基準的用途：
快速比較哪個模型較擅長一般數學推理，
在投資進行全面產品評估前，作為良好的初步篩選工具。
仍須建立自家數據集的原因：
您的應用程式有一些 GSM8K 不會測試的要求：
課程採用的措辭及主題次序，
適合目標年齡組別的解釋方式，
如何處理含糊不清或錯字甚多的學生問題，
政策規則（例如何時給予提示，何時提供完整答案）。
有效驗證的關鍵，在於建立應用程式專屬的評估基準。這些數據集應取材自真實互動、常見邊緣個案及可能出現的失敗模式。實施新產品或流程時，這項工作可能相當困難。不過，大多數情況下仍可從現有產品收集數據，或盡早開始收集，甚至在初步測試階段進行。應用程式開發完成後，這些基準應隨產品一同演進，逐漸變得更豐富、更具代表性。
個案研究：為零售銀行助理建立自訂基準
銀行聊天機械人會回答有關預算、消費及交易的問題。公開問答基準／文字轉 SQL 測試未能涵蓋 SQL 注入、數據洩漏或多輪情境延續等核心銀行風險。我們建立了一套反映此產品智能代理流程的自訂基準。
此程式碼庫中的自訂基準組件：
由惡意提示詞組成的紅隊測試套件，涵蓋 SQL 注入、個人識別資料擷取、提示詞覆寫及跨工作階段洩漏
安全問題零容忍：必須拒絕任何 SQL 注入、個人識別資料擷取或跨工作階段洩漏。
情境延續準確度：改寫後的查詢必須保留用戶意圖及實體。
重點：把建立基準視為一項產品功能。目前的任務執行框架證明端對端評估已接通，但涵蓋範圍及樣本數量仍須擴大，才能反映真實銀行風險，包括多重意圖攻擊、繞過防護機制及依賴情境的查詢。基準應隨新增的智能代理及防護機制一同擴展。
應用程式專屬基準與模型選擇之間的關係至關重要。基準不但揭示方案是否可行，也能找出最具成本效益並符合效能需要的模型大小與後訓練技術組合。預訓練模型最強大的改良方式，並非重新訓練，而是「後訓練」方法（ChatGPT 中的「PT」）。
這些方法着重調整模型可存取哪些資料、資料如何組織，以及模型在推理時如何獲得引導和協調。後訓練技術包括：
思路鏈提示及動態運算分配（遇到較難的問題便進行更多思考）
自洽性，即生成多個輸出並選出最佳結果
情境建構與協調，例如檢索增強生成（RAG）、少範例示例及智能代理工作流程
使用工具及存取外部知識，讓模型能執行超越其內部參數的工作
知識表示及儲存策略，旨在有效檢索結構化及非結構化數據，並據此推理
這些後訓練技術雖可大幅提升系統效能，但也會帶來取捨。每增加一層協調、檢索或推理，都會提高系統複雜度、推理時間及營運成本。然而，只要審慎運用，合適的後訓練技術組合往往能讓較小、更快、成本更低的模型同樣符合效能要求。效能不必靠擴大模型，而可透過更佳的系統設計達成。
這種平衡必須因應個別應用程式而定，並依靠應用程式專屬評估找出最佳技術組合。這些評估有助找出增加協調已無法帶來實質效益的臨界點，讓團隊選擇達到目標效能所需的最低後訓練複雜度。
AI 方案應視為一套完整系統，包括數據庫、API、用戶介面、協調層及監察基礎設施等。因此，評估必須涵蓋整個技術堆疊。您應監察系統的關鍵部分，以掌握潛在問題並負責任地加快進度。
監察系統關鍵部分包括：
在流程加入檢測工具，以量度成果。
記錄實驗，以了解每項調整的影響。
部署重大變更前先作簡單 A/B 比較，測試有否潛在效能倒退。
數據驅動的迭代可縮短從原型到生產的路程，同時避免盲點。記錄及監察對了解應用程式的真實使用情況也十分重要。以下範例說明如何確保系統可觀測：
步驟 1：用戶要求連同 request_id、user_segment、intent 輸入系統。
步驟 2：追蹤記錄模型版本、提示詞版本、檢索文件及工具調用。
步驟 3：LLM 評審為回應評分（正確度、依據充分程度、policy_risk）。
步驟 4：規則引擎評估門檻。
步驟 5：若違反門檻，觸發警報，並轉至後備方案／人手審核。
步驟 6：把失敗個案加入分類處理佇列，再加入基準待辦清單。
真實用戶很少會完全按照設計者的預期行事。部分用戶會誤解指示。另一些則會刻意試探弱點。這些邊緣個案並非異常，而是極具價值的訊號。妥善實施的評估流程會擷取並分析這些個案，再將其納入日後測試。只有從一開始便把評估內建於系統，而非開發後才附加，才能在不留盲點下快速迭代。
我們建議從第一天起便加入防護機制及監察：
使用應用程式專屬基準，定期追蹤模型指標及效能倒退。
擷取並審視邊緣個案或對抗性輸入（並將其加入應用程式專屬的基準數據集）。
確保這些評估指標與核心關鍵績效指標一致。
定期檢視並質疑數據集與基準，確保沒有忽略新風險或受偏差影響。
針對指標下滑設定自動警報（例如準確度跌至 85% 以下時觸發審核）。
涉及高風險決定（法律意見、醫療指引、金融交易）時，應保留人手審核程序。
每次運行基準都會耗用運算資源和能源。每項重複實驗都會增加成本。負責任的評估應兼顧嚴謹與效率。
以下實務措施可避免能源用量及成本失控：
盡可能使用較小的模型，以成本較低的模型進行初步實驗，待方法獲驗證後才擴大規模。
快取提示詞及 API 調用。
採用顧及能源用量的排程方式（批次處理、競價型執行個體、彈性優先級）。
在追蹤效能的同時監察運算資源用量。
同樣地，也要留意新興的 AI 法規。即使沒有專門法例，現有框架及必要措施仍然適用，例如：
數據保障：
確保基準數據集未經適當同意不會包含個人識別資料
為已記錄的查詢實施數據保留政策
提供處理數據刪除要求的機制
平等與偏差：
測試不同人口群組的效能
建立基準時納入多元代表
人權與透明度：
向用戶清楚說明模型限制
就高風險決定提供解釋
讓關鍵應用程式接受人手監督
評估並非一次性工作，而是一套持續演進的系統。在瞬息萬變的領域，優勢取決於測試、學習和調整的速度，讓模型及新方案發揮更大成效。
把評估納入工程及產品管理的核心工作，團隊便能更快速、更安全地創新。首先因應 AI 應用情境定義何謂良好表現，建立評估平台並持續改進，逐步形成應用程式專屬基準，讓每次迭代都能確認產品已準備好投入生產。