LLM 評測實戰：如何在使用者之前測試 AI 功能

AI 功能第一次讓團隊尷尬時，通常不像一次 benchmark 失敗。它更像是客服機器人自信地套錯退款政策，程式碼助手修改了明明不該碰的檔案，或銷售 copilot 因為 CRM 欄位為空就編造客戶細節。示範沒問題，提示詞審查沒問題，模型介紹也很亮眼，但真實使用者找到了你從未測試過的輸入。

這正是 LLM 評測存在的意義。它不是刷榜，也不是把每個新模型填進綠色表格的表演。實用的 LLM 評測是產品團隊的早期預警系統：把混亂的使用者期望轉化為可重複測試、回歸閘門和複審閉環。

為什麼 LLM 評測不同於普通 QA

傳統 QA 通常檢查已知輸入是否返回預期輸出。LLM 產品更難，因為正確答案可能是一組可接受行為。評分標準必須匹配產品風險：摘要工具要看事實一致性、完整性、語氣和拒答；能呼叫工具的 Agent 還要看任務成功率、工具選擇、權限安全和是否知道該停下。這也呼應我們在 AI Agent 更需要可靠性 中的觀點：產品不只是模型輸出，還包括控制系統。

先建立黃金資料集，再調提示詞

黃金資料集是一組真實或高度仿真的輸入，包含期望行為、評分說明和元資料。起步不必很大，50 到 200 條就能覆蓋常見任務、高成本失敗和邊界情況。客服 copilot 應包含憤怒訊息、多語工單、資訊不完整和需要升級人工的案例；開發者工具應包含小 bug、模糊重構、失敗測試和權限邊界。

每一行都要記錄任務類型、風險等級、所需來源、允許動作和通過理由。Hamel Husain 的 LLM evals 實踐文章 提醒團隊從產品真實案例和人類判斷出發，而不是崇拜抽象 benchmark。

像產品實驗一樣比較提示詞和模型

提示詞和模型比較應像受控實驗。用同一資料集跑生產提示詞、候選提示詞和候選模型，並按任務、語言、風險和使用者群體切片。ChainForge 適合比較多組 prompt 和模型輸出；Vellum 提供 prompt 管理、評測和部署工作流；DeepEval 提供面向 LLM 應用的開源測試框架。

工具之外，更重要的是記錄每次評測的提示詞版本、模型名、檢索設定、工具 schema 版本和系統指令。若你採用多模型流程，可搭配閱讀 用 LLM 寫軟體的實踐流程。

把回歸閘門接入 CI/CD

有了黃金資料集後，先把小型 smoke 集合接入 CI/CD。任何修改提示詞、模型配置、檢索管線、工具 schema 或 Agent 路由的 PR，都應跑關鍵 evals。高風險案例失敗時阻止合併，低風險波動可先警告。

先做 deterministic checks：schema 是否有效、是否給出必要引用、是否觸發禁止動作、是否在不允許請求上拒答。再加入 rubric 或 LLM-as-judge 處理語氣、完整性和有用性。對 Agent 系統，可借鑑 MCP 生產整合模式 和 Operator 風格網頁自動化架構：記錄工具呼叫、分類錯誤、版本化 schema，並測試失敗路徑。

人工複審把失敗變成更好的測試

評測集不會自動保持優秀。定期複審抽樣輸出、使用者差評、升級工單和差點出事的案例，並把最代表性的失敗提升為新測試。標籤不要只有好壞，還要記錄上下文缺失、工具錯誤、無依據聲明、語氣不當、不安全動作、來源過期、過度拒答或拒答不足。

PM、客服、銷售、法務或領域專家都應參與高風險場景。若已有營運看板，可把 eval failure 接進去；我們的 Agent 營運漏斗設計 就是相近的觀察框架。

何時需要開放式遊戲世界評測

多數團隊應從黃金資料集和回歸閘門開始。開放式環境更重，只在功能需要長程規劃、從意外狀態恢復或連續互動時才值得投入。Factorio Learning Environment 用 Factorio 作為沙盒，評估 Agent 的規劃、資源取得、建造和適應能力。它不適合 FAQ bot，卻可能適合瀏覽器 Agent、編碼 Agent 或運維 copilot。

好的 LLM 評測不會讓功能完美，但會讓取捨更早可見。真正成熟的團隊知道哪些失敗最重要，能在 CI/CD 中抓住回歸，並在需要判斷和責任時讓人類留在閉環中。