2026 年最快將 AI 推上生產環境的企業，並非採用了最強模型的那一批。真正的分別在於：他們在寫下第一句提示詞之前，就已經界定清楚什麼算是錯誤答案，以及由誰有權簽署放行。
這個機制有一個名字，叫做 eval（評測）。而幾乎每一個停滯不前的企業 AI 項目，跳過的正是這一步。
如果你的機構曾經跑過一個看似成功、卻始終無法正式上線的 AI 試點，真正的障礙多數不是模型。而是沒有人能拿出證據，證明系統的表現足夠好。而任何委員會都不會批准一個無法量度的系統。
什麼是 AI Evals？
AI eval 是一套可重複執行的測試：以一組已知正確答案的固定輸入，按既定標準為 AI 系統的輸出評分。與示範不同，eval 產出的是一個數字，可以跨版本追蹤、可以用來比較供應商，也可以直接呈交風險委員會。
對決策者而言，關鍵分別在於：基準測試（benchmark）告訴你模型在別人的問題上表現如何，eval 告訴你它在「你的」問題上表現如何。
公開排行榜的分數最多只是採購訊號。它完全無法說明模型能否正確讀懂你的租賃合約、你的索償表格，或你客戶的粵語通話紀錄。
為什麼沒有 eval 的企業 AI 試點會卡住？
試點卡住，是因為審批需要證據，而示範不是證據。缺少 eval，唯一可用的品質訊號就只是傳聞：某人試過，感覺不錯。這足以支持一次實驗，卻永遠不足以授權一個接觸客戶、金錢或受規管紀錄的系統。
麻省理工學院（MIT）的《The GenAI Divide: State of AI in Business 2025》研究，基於 52 場高層訪談、153 位管理者問卷，以及 300 個公開部署案例的分析，發現 95% 的生成式 AI 試點沒有帶來可量度的損益影響。這句話真正的關鍵詞是「可量度」。
我們在 為什麼 95% 企業 AI 試點會失敗 一文中討論過更宏觀的失敗模式。Evals 正是把試點的個別經驗，轉化為董事會可以據以行動的數字的具體機制。
還有一項較少被提及的代價。沒有 eval，每一次模型升級都變成一次風險事件。當供應商推出新版本，你無從判斷你的流程是變好了，還是悄悄變差了。
AI eval 實際上如何運作？
Eval 把一組固定的測試輸入送進你的 AI 系統，按預期結果或品質評分表為每個輸出評分，再匯報整體通過率。它會在每次提示詞修改、模型升級或資料更新時自動執行，就像軟件測試套件在程式碼發布前執行一樣。
其運作可拆成四個部分，而管理者必須有能力在供應商會議上逐一點名。
資料集。一組真實輸入，配上已經取得共識的正確輸出。2026 年的實務指引大致收斂在 200 至 500 個範例，而且應該來自真實的生產失誤，而非虛構個案。
評分器。判定通過或失敗的機制。可以是精確比對、規則、程式檢查、人工審核，或由另一個模型擔任裁判。
指標。最終被匯報的那個數字。準確率是最直覺的選擇，但更成熟的做法是針對成本最高的那一種失誤評分，例如捏造數字、遺漏法定披露字句，或洩露個人資料。
關卡。低於此門檻就不得放行的界線。沒有約束力的關卡，只是一塊儀表板，不是控制。
什麼是 LLM-as-a-judge？可以信任嗎？
LLM-as-a-judge 是以第二個 AI 模型，按書面評分表為第一個模型的輸出評分。它是唯一能夠大量評估語氣、完整度、忠實度等主觀品質的方法。它只有在經過人工判斷校準之後才值得信任，校準之前並不值得。
2026 年公開的實務指引，把校準門檻設在裁判與人工標註參考集之間約 85% 至 90% 的一致率，達標後才容許裁判無人監督地運行。部分團隊偏好採用與專家判斷相關係數高於 0.7 的量度方式，理由是單純的一致率會過度美化一個懶惰的裁判。
最後這一點值得你在供應商會議上原句提出。若一個資料集中只有十分之一的輸出理應被判失敗，那麼一個把所有輸出都判為通過的裁判，一致率高達 90%，卻毫無用處。任何供應商向你報出一致率數字，請追問底層資料集的失敗比率是多少。
這也是 eval 與監控的分別所在。觀察生產環境流量，即我們在 Agent 可觀測性 一文中談過的做法，告訴你已經發生了什麼。而 eval 在發布之前，告訴你即將發生什麼。
如何為你的機構建立黃金資料集？
黃金資料集，是你的機構共同認可、代表正確行為的一組測試個案。它應該建立在真實失誤而非人工虛構的例子之上：收集試點期間出錯的輸出，由一位領域專家逐項判定通過或失敗並寫下理由，然後把這位專家的判斷視為標準。
能夠把這件事做成的團隊，實務步驟其實很短。
從 50 個真實失誤開始。而不是 500 個虛構個案。來自你自己試點的失誤，價值遠高於任何公開基準測試，因為它們編碼了你的業務認為什麼是不可接受的。
用一位專家，而非一個委員會。在這個階段，一致性比共識更重要。兩位互相矛盾的審核者，只會產出一份無法用來校準任何東西的資料集。
寫下理由，而不只是判決。那段書面評語，日後會成為裁判的評分表。一份只有通過或失敗標籤的資料集，無法轉化為自動評分器。
讓它從生產環境持續生長。每一個在實際使用中出現的新失誤，都成為一個永久測試案例。這是會複利累積的資產。一年之後，這份資料集就是一份沒有任何供應商能夠複製的、屬於你機構的品質標準說明書。
一項提醒：檢索品質與答案品質是兩個獨立問題，需要各自的測試案例。如果你的助理之所以自信地答錯，是因為它從未找到正確文件，那是接地（grounding）失誤，而不是推理失誤。兩者的分別，我們在 什麼是 AI 接地 一文中已有詳述。
2026 年，受規管的香港企業面對了什麼改變？
兩項發展把 eval 從工程實務推向治理要求。歐洲高風險 AI 系統的義務，涵蓋風險管理、品質管理與上市後監察，原定合規日期為 2026 年 8 月 2 日。其後的 Digital Omnibus 程序提議把獨立的 Annex III 系統延後至 2027 年 12 月 2 日，但「必須提出證據」這項要求本身並未改變。
日期押後不是重點。無論哪一個版本的制度，都要求一套有文件紀錄、持續進行的流程，用以證明系統的表現與宣稱一致。那就是一套 eval 機制，不論日曆怎樣寫。
更貼近本地的是，個人資料私隱專員公署於 2026 年完成第二輪 AI 循規審查，涵蓋 60 間香港機構。其中 57 間在日常營運中使用 AI，約 79% 使用超過一年，約 51% 同時運行三套或以上的 AI 系統。是次審查並未發現違反《個人資料（私隱）條例》的情況。
請仔細讀這項發現。香港大多數企業，如今已是多系統 AI 營運者。如果你同時運行三套或以上 AI 系統，卻對其中任何一套都拿不出品質紀錄，那個缺口就不是技術問題，而是一項擺在部門主管桌面上的審計風險。
建立一套 eval 機制要花多少成本？
Eval 機制的成本主要是專家時間，而非軟件。第一套可運作的測試套件，通常需要一位領域專家花兩至三天，為初始失誤集評分，再加上把評分接入發布流程的工程時間。經常性成本很低：每次改動執行數百個測試案例所需的運算資源而已。
這對預算討論很重要，因為直覺總是先買平台。平台是便宜的部分。昂貴而且無法轉讓的，是你機構內部那位知道正確答案應該長成什麼樣子的人的判斷力。
面對財務總監，可以這樣表述：eval 機制決定了你手上的 AI 系統，是一套可以安全修訂的系統，還是一套只能整個換掉的系統。沒有它的代價，最終會以「一個無法升級、因此必須重建的項目」的形式出現。
企業的 eval 機制通常錯在哪裡？
多數失敗屬於組織問題而非技術問題。四種反覆出現的模式分別是：資料集建立在想像而非真實的失誤之上、沒有人校準過裁判、指標量度了錯的東西，以及一道任何項目經理在死線壓力下都能推翻的關卡。
風險不在準確率，卻只量度準確率。一個準確率 96% 的合約助理，如果每 25 份文件就捏造一次條款，那不是 96% 的成功，而是一個法律審查問題。請為成本最高的失誤評分，而不是為最容易計算的失誤評分。
讓供應商擁有 eval。同時提供系統與系統測試的供應商，等於在批改自己的功課。資料集必須留在你手上，而且必須能在更換供應商之後繼續存活。
只在採購時做一次 eval。一次性的驗收測試，只能告訴你模型在你購買當日的狀態。模型會更新、提示詞會漂移、你的文件會改變。價值在於重複執行。
設了關卡卻沒有負責人。如果沒有指名誰有權叫停發布，那麼第一次遇上發布日期壓力時，門檻就會被豁免。
策略重點
Evals 不是一項可以下放給技術團隊的測試細節。它是把 AI 投資轉化為「董事會可以監督、監管機構可以查閱、繼任者可以承接」的資產的機制。
本季度值得向團隊提出的問題很窄，也很可答：對我們運行的每一套 AI 系統而言，測試集是什麼？誰校準了評分器？哪一個門檻可以阻止發布？誰擁有那個門檻？如果這四個答案並不存在，你手上就還不是一套已經上線的 AI 系統，而是一個剛好在承接實際流量的試點。
在一間已經有既有系統、既有紀錄、既有監管要求的機構內建立這套能力，比任何供應商簡報所描述的都要慢，也更牽涉內部政治。這正是一個做過同樣事情的夥伴能夠發揮價值的地方。懂AI，更懂你 UD相伴，AI不冷。
本文由 UD 企業 AI 團隊（香港）審閱。2026 年 8 月 13 日發表。
準備好找出你的起點？
知道要量度什麼是第一步，知道你的機構實際站在哪個位置是下一步。UD 團隊手把手帶你完成每一步，由 AI 準備度評估、應用場景選型，到部署上線、品質關卡設定與成效匯報，28 年服務香港企業的經驗，全程陪你走。
