AI模型評測
一句話定義
AI 模型評測是用明確任務、固定輸入、可比較輸出與可回看的紀錄，判斷哪個模型在特定使用場景中最可靠、最划算、最適合的實驗流程。
核心要點
真實任務優先
不要用「寫一篇貓的故事」這類泛用題目判斷模型；評測題目應來自實際工作流，例如常寫的 email、常摘要的文件、常見的客服問題、實際專案的程式片段或研究問題。
真實任務的好處是評測結果能直接回答「我下次該用哪個模型做這件事」，而不是只知道某模型在抽象 benchmark 上得分高。
控制變因：同一提示、並排比較、多次重跑
- 同一提示：不同模型要吃完全相同的輸入，否則很難分辨是模型差異還是 prompt 差異。
- 並排比較：把輸出放在一起看，比隔天憑記憶比較更容易看出語氣、結構、遺漏、跑題與可用性差異。
- 多次重跑：LLM 具有機率性，同一模型同一提示也可能產生不同品質；穩定性本身就是評測指標。
評測標準要跟任務綁定
常見評估維度包括：
- 回答品質：有沒有回答問題、是否完整、是否能直接使用。
- 準確性與可查證性：事實性任務需檢查引用來源、數字、產品功能與外部事實。
- 語氣與風格：是否符合品牌、讀者、文件或使用者期待。
- 深度 vs 簡潔：有些任務需要一步步拆解，有些任務需要短答案。
- 成本與速度：高量產品或內部工作流不能只看最佳輸出，也要看 token 成本、延遲與可承受的錯誤率。
- 邊緣案例：真實工作常壞在奇怪輸入、含糊要求、長文件、跨語言、專有名詞與領域脈絡，而不是基本題。
幻覺檢查是事實性任務的基本閘門
如果模型會被用來研究、決策、出版、法律、醫療、財務或技術選型，評測流程要包含 AI-幻覺 檢查：
- 問自己已知答案的問題，看模型是否會自信編造。
- 要求模型提供來源，再檢查來源是否存在、是否真的支持該主張。
- 設計「容易誘惑模型亂答」的邊緣題，測試它是否能標示不確定性。
沒有抽象最佳模型，只有任務到模型的對應表
健康的評測結果通常不是「永遠用某個模型」，而是形成一張任務對應表：哪個模型適合創意發想、哪個適合長文件摘要、哪個適合程式碼解釋、哪個適合高量低成本呼叫。
因為模型版本、價格、上下文長度、工具能力與安全政策都會變，重要任務應定期重測，而不是把某次評測當永久結論。
與其他概念的關係
- 與 模型刷榜 是反向互補：模型刷榜 警告公開 benchmark 可能被過度最佳化；本頁描述使用者如何建立自己的本地任務評測，避免被榜單或行銷宣稱牽著走。
- 與 AI-幻覺 形成可靠性閘門：事實性任務的評測不能只看答案漂亮，還要驗證引用、數字、功能與不確定性標示。
- 與 Prompt-Engineering 互相影響：提示語要提供清楚任務與成功標準；但評測時又要固定 prompt，避免每個模型收到不同題目。
- 與 AI輔助開發 對位：開發任務有測試、型別檢查、文件與執行結果可作為 ground truth，較適合自動化 eval。
- 與 AI輔助創意 對位：創意任務較難有單一正解，評測標準更依賴品牌語氣、可修改性、驚喜度與人類主觀判斷。
- 與 推理模型 相關：推理模型可能更適合多步規劃與複雜問題，但仍需用自己的任務驗證，不應把模型類型當成品質保證。
- 與 LLM-Evaluation 分工：本頁偏向使用者 / 團隊在模型快速變動下做任務到模型的選型表；LLM-Evaluation 偏向 production agentic system 上線後的 end-to-end、component、objective / subjective 與 LLM-as-Judge 評估系統。
- 與 MOC-LLM-應用設計 的關係：本頁補上 LLM 應用設計中的「模型選型與評估」入口，連接模型行為、成本、幻覺與下游工作流。
相關來源
- 2026-05-13-Zemith-AI模型評測指南 — 非技術使用者的 6 步模型比較流程：真實任務、同提示、並排、多次、查證、記錄；明確反對只依賴 benchmark 或社群口碑選模型。
備註
- 本頁目前是「使用者 / 團隊的實務評測」入口，不是正式 ML evaluation / eval harness 入口。未來若 ingest OpenAI / Anthropic / EleutherAI / HELM / MT-Bench / LMSYS arena / red teaming / model observability 等來源，可再補「自動化 eval」「安全評測」「benchmark 老化」「人評 rubric」等層次。
- 來源本身有 Zemith 產品導向，引用時採用方法論，不採用個別模型優劣作為長期事實。