生活分享

模型與代理評測(Evals)是什麼

模型與代理評測把任務、輸入、執行條件和成功標準固定下來,觀察 AI 是否真的符合需求。本文用志工排班助理為例,說明案例、重複嘗試、評分器與外部結果的差別,比較程式、人類與模型評分,解釋為何單次答對和平均高分都不足以證明可靠。讀完能建立一組小而實用的評測,讓提示詞或模型更新有可比較的證據,也能保留尚未驗證的限制。

更新日期: 閱讀時間約 7 分鐘

不同形狀的結果卡經過量尺與勾選板核對,旁邊保留一張待確認卡,象徵多面向評測。
圖片:Mokaair (© Mokaair)

Evals 是 evaluations 的常見簡稱,指對模型或代理系統進行有結構的評測:給定任務與輸入,在清楚的條件下執行,再依預先定義的標準判斷結果。它把「這次感覺不錯」轉成能重做、能比較的觀察。好的評測不只提供分數,也幫助指出失敗發生在哪裡。

以下用志工排班助理的原創案例,從一項需求走到案例、執行與結果分析。這個助理可以提出班表,也可能把確認後的安排寫入系統;兩種能力需要不同證據。資料查證截至 2026 年 9 月 14 日。

先定義成功,才知道要測什麼

Anthropic 的評測文章把任務、嘗試、評分器、執行紀錄與最終環境結果分開;MLflow 官方文件則展示用案例資料與評分器管理模型和代理評估。共同重點是將可觀察行為連到成功條件,而不是把模型最後一句自我評價當成答案。

志工排班的需求可以是:每個時段有人值班、不能安排明確請假的人、同一人不能同時出現在重疊時段。語氣親切不是這個任務的首要正確性條件;排班文字再好讀,若把請假者排進去,仍然失敗。先釐清哪些條件必須全部成立,才能避免平均分掩蓋重大問題。

還要明確設定不足情況。如果某個時段沒有任何人可到,合格結果可能是標示缺口並請求補人,而不是硬湊出一張完整表。評測若只獎勵每格都填滿,就會鼓勵不符合限制的行為。成功標準本身也需要接受審查,否則模型可能忠實達成錯誤目標。

案例要包含正常、缺漏與衝突

原創輸入包含志工名單、可出席時段、請假記錄和需要覆蓋的班次。先準備一般可排滿的情況,再加入同名志工、臨時取消、時段重疊以及人力不足。每筆案例都保留必要條件與預期行為,不必要求答案逐字和參考文字一樣,只要符合有效安排與說明規則。

例如小林只能上午、小陳只能下午,而午後有一個未覆蓋時段,模型應明確指出缺口。若它把小林安排到下午,就違反可用時間;若它拒絕處理全部班表,也可能沒有盡到整理已知部分的任務。把這些差異寫出來,評分才能反映使用者真正需要的幫助。

測試集還要避免只收集容易題。真實使用者常給不完整名稱、口語日期或前後矛盾的更正。可以使用去識別化或人工建立的代表性資料,保留實際困難格式。資料量再大,如果都來自相同簡單樣式,也不能支撐對所有使用情境的結論。

評分器要對應要檢查的事

程式檢查很適合固定約束,例如人員識別是否存在、是否安排在可出席時段、是否有重疊。人類可以判斷說明是否足夠清楚、是否合理處理模糊要求。模型評審則能協助大量語意評估,但需要明確準則與人工校準,不應因它能寫出評語就假定評分正確。

如果代理會把班表寫進系統,還要查實際儲存的資料。對話裡顯示成功、工具曾被呼叫、資料庫真的出現正確班表,是不同證據。評測可以先在隔離的測試環境提供假資料,執行後直接查狀態,確認沒有重複寫入或改到其他活動。

過程紀錄也有用途,但不要把某一條固定工具路徑當成唯一正解。只要權限與結果都符合要求,代理可能選擇不同但有效的順序。相反地,即使最後結果正確,若中間存取了不該看的資料,也需要被評測發現。結果與過程應各自檢查需要保障的條件。

案例包含人員時段和限制,執行後分別檢查班表約束、說明品質及系統中儲存的狀態,再彙整不同失敗型別。
模型說完成與系統確實儲存正確班表,必須分開驗證。 · 圖片:Mokaair (© Mokaair)

多次嘗試與平均值都有解讀限制

模型輸出可能有變異,工具與環境也可能影響結果,因此單次成功不一定能代表穩定性。可以在相同條件下重複嘗試重要案例,保留每次結果與失敗原因。重複次數應依風險和成本安排,沒有一個適用所有任務的神奇數字。

分析時除了整體通過率,也要分開看缺漏、衝突和同步操作等類別。整體表現提高,可能同時伴隨少見但重要的請假條件退步。若只挑最好的那次展示,會誤導使用者對日常可靠度的期待;如果報的是多次中至少成功一次,也應明確說明不是每次都成功。

評測環境故障還要和代理能力分開。資料服務無法啟動、工具憑證失效或測試程式本身有錯,可能使所有嘗試失敗。先辨識這些原因,才能決定是修環境、修評分器還是修代理。把每個紅色結果都算成模型不會做,同樣會得到失真的判斷。

讓評測成為更新的依據

調整提示詞或更換模型後,用相同案例和評分條件比較,再人工檢視新增失敗。若已修正某個請假案例,應保留成回歸測試,確保下次改版不再出現。另可保留較難的新題探索能力邊界,避免測試集只剩系統早就熟悉的題型。

評測與基準測試相關,但 evals 的範圍較廣,可以完全針對自己的產品規則。公開基準適合提供共同參考,卻未必涵蓋社團的排班條件。服務上線後還需觀察真實使用回饋,將確認過的問題補入案例,而不是把離線通過當作永久保證。

一般使用者或小團隊可以先整理最常見的任務與最不能接受的錯誤,做成一組可重做的案例。每次改動附上比較結果、重要失敗與未驗證範圍。這樣評測就不是額外的形式,而是讓人知道目前版本可以信任到哪裡,以及下一步應改善什麼。

不同證據不能互相代替(2026 年 9 月查證)
評估方式適合檢查限制
程式評分固定欄位與排班約束不擅長含糊語意
模型評審語意與表達條件需要校準並檢查偏差
外部狀態查核班表是否真正儲存需有可控制且可信的測試環境

  • 生活分享

    世界模型(World Model)是什麼:讓 AI 預測「接下來會怎樣」

    世界模型指 AI 內部用來預測「這樣做之後會怎樣」的模型,但這個詞至少有三種用法:強化學習代理在想像中練習用的環境模型、LeCun 主張預測抽象表示的架構路線,以及能隨操作即時生成畫面的互動環境。內容用示例說明怎麼在想像中規劃,並列出大型語言模型有沒有世界模型的正反研究,附讀新聞時的檢查問題。

  • 生活分享

    視覺語言模型(VLM)是什麼:讓 AI 讀圖片、再用文字回答

    視覺語言模型(VLM)能同時接收圖片與文字,再用文字回答。內容拆解視覺編碼器、連接層與語言模型三段結構,說明 CLIP、Flamingo、LLaVA 三篇論文各補上哪一塊,並和多模態 AI、文字生圖分清楚;也整理它常犯的錯:數錯數量、搞混位置、說出圖裡沒有的東西,附上讀收據時逐行核對的步驟。

  • 生活分享

    溫度(Temperature)是什麼:AI 回答變化程度的取樣參數

    溫度(temperature)是文字生成時調整取樣的參數,讓模型從下一個 token 的機率分布裡抽得更集中或更分散。用假想的台南早餐示例算出低溫與高溫的差別,說明 top-p 的來源和它與 top-k 的差別,並依官方文件與論文指出:調低溫度不代表更準,設成 0 也不保證每次相同,部分模型還不開放調整。

  • 生活分享

    合成資料(Synthetic Data)是什麼:兩種用途、品質控管與模型崩潰

    合成資料是由演算法或模型產生、模仿真實資料特徵的資料,常見用途有兩種:訓練模型,以及在隱私需求下替代真資料。內容依 Self-Instruct、模型崩潰研究(替換與累積資料的差別)與 NIST、ICO 的隱私文件,說明做法、抽查流程,以及它不能保證的事。

最新旅遊情報攻略

資料來源

生活分享