模型分數不能直接等於產品價值

直接答案是：模型評估測量模型本身的能力，系統評估則測量使用者能否完成工作。前者可用 MMLU、GSM8K 或 HumanEval 比較知識、數學與程式能力；後者還必須納入提示詞模板、檢索器、權限、介面與人工覆核。公開高分模型放入錯誤流程，仍可能造成低完成率。

以知識問答為例，模型即使知道答案，RAG 系統仍可能取回過期規範、排序錯誤或截斷關鍵段落。使用者看到的是最終答案，因此驗收必須同時追蹤檢索命中、引用覆蓋、答案正確與任務完成，而非將問題全部歸咎於模型參數。

實務上建議先寫出決策問題：要選模型、改善提示詞、驗證 RAG，還是判斷是否開發？每個問題都應有對應樣本、判分規則與門檻。這能避免團隊蒐集大量分數，最後仍無法回答「是否能上線」或「哪個方案值得投資」。

• 模型層：能力、格式遵循、知識與推理表現
• 系統層：完成率、延遲、成本、可用性與風險
• 業務層：節省工時、錯誤成本、採用率與投資效益

先將成功條件寫成可判定的 KPI

直接答案是：成功條件必須在測試開始前量化，否則結果容易被事後解讀。客服摘要可設定必要欄位完整率、禁止編造率與人工修訂時間；內部知識問答則可設定有引用回答的比例、引用是否支持結論，以及使用者一次解決問題的比例。

KPI 需要同時涵蓋品質、速度、成本與風險。例如答案正確率即使提升，若 P95 延遲拉長、每次推論費用超出預算，或高風險錯誤未受控，整體方案未必較佳。每項 KPI 都要標明量測單位、母體、期間與負責人。

可編輯的評估規格至少應記錄資料版本、模型版本、系統提示詞、解碼參數、工具版本與執行時間。這些欄位看似行政工作，卻是重現結果的關鍵；少了其中一項，下一次分數變動時，團隊往往無法判斷是模型、資料或流程造成。

• 將「回答好」改寫為可觀察的通過條件
• 為每一指標設定目標值、警戒值與不通過條件
• 保存提示詞與資料版本，避免無法重現

用任務風險決定驗收嚴格度

直接答案是：風險越高，越不能只靠平均分數。行銷文案可接受多種合格表述，適合看偏好評分與品牌語氣；法務、醫療或財務輔助則需將關鍵事實、引用來源與拒答行為逐題檢查，並保留人工核准機制。

建議把測試案例分成正常、邊界與失敗模式。正常案例確認常見工作是否流暢；邊界案例檢查長文件、模糊提問、繁體中文術語與多輪對話；失敗模式則刻意測試未知問題、衝突指令、敏感資料與不完整來源。三類比例需貼近實際流量。

若任務會影響外部客戶或正式決策，請設定阻擋型規則，例如不得捏造引用、不得跨權限揭露資料、不得執行未授權工具操作。平均品質再高，只要阻擋型錯誤出現，就應列為修正項，而非用總平均掩蓋。

• 低風險：偏好、風格、產出速度
• 中風險：正確性、格式、人工修訂量
• 高風險：來源忠實度、權限、安全與人工覆核

以正確性與語義品質共同判分

直接答案是：封閉答案任務可用 Exact Match、精確率、召回率與 F1；開放生成任務則應加入語義與人工判斷。F1 分數范围为 0–1，其中 1 表示出色的召回率和精确度。對抽取式問答而言，這能兼顧漏答與誤答，但不能判斷解釋是否清楚。

BLEU、ROUGE 適合檢查輸出與參考答案的詞彙重疊，常用於翻譯與摘要；BERTScore、MoverScore、語義相似度與餘弦相似度較能容忍同義改寫。然而，文字相似不代表事實正確，尤其企業問答若把數字或條件寫錯，語義分數仍可能偏高。

可用 Hugging Face Datasets 的 evaluate 庫建立可重複的自動評測；摘要或翻譯的環境可從 `pip install evaluate sacrebleu rouge_score` 開始。若要做多語言語義比對，可評估 `paraphrase-multilingual-MiniLM-L12-v2`；英文輕量情境則常見 `all-MiniLM-L6-v2`。

• Exact Match：固定答案或結構化欄位
• F1：抽取式答案的精確率與召回率平衡
• ROUGE、BLEU：與參考文本的重疊程度
• BERTScore：語意接近程度，不等同事實查核

不同任務要配對不同基準

直接答案是：應依產品任務選基準，不應把單一綜合分數當作全部能力。MMLU（大規模多任務語言理解）適合觀察廣泛知識；其基準涵蓋了57個主題，包括STEM、人文學科、社會科學等，難度從初級到專業級別，測試世界知識和問題解決能力。

程式生成可用 HumanEval / MBPP (Mostly Basic Programming Problems)，並以測試案例是否通過為主要判準；數學推理可用 GSM8K 與 MATH；閱讀理解可參考 SQuAD（斯坦福問題解答資料集）；真實性風險則可用 TruthfulQA。這些資料集各自反映能力切面，而非完整產品表現。

通用語言理解評估 (GLUE)、SuperGLUE、ARC、HellaSwag、Winogrande、TriviaQA 與 Big-Bench 可補足語言理解、常識與推理觀察。Big-Bench 包含超過200個任務，但公開題目可能被訓練資料污染，因此它們較適合作為篩選線索，不是企業採購的唯一證據。

• 問答：SQuAD、TriviaQA、Natural Questions
• 推理：GSM8K、MATH、ARC、HellaSwag
• 程式：HumanEval、MBPP
• 安全與真實性：TruthfulQA、ToxiGen

將延遲、吞吐與成本納入同一張成績單

直接答案是：模型選擇應以品質門檻後的效率比較為準。若兩個模型都能達成正確性目標，才比較平均延遲、P95、P99、每次請求成本、輸入輸出 token 與每分鐘吞吐量；否則便宜但常需人工重做的模型，實際總成本可能更高。

測試時請固定併發數、輸入長度分布、輸出上限與快取策略，並分別記錄首 token 時間與完整回應時間。只看平均值容易掩蓋尖峰體驗；客服或互動式工具通常更應關注 P95 與 P99，因為少數長等待最容易破壞使用者信任。

每筆結果最好保留請求 ID、模型名稱、提示詞雜湊、檢索文件版本、token 用量、錯誤碼與人工結果。這能讓團隊在成本異常或品質下降時回溯原因，也能把離線測試結果對照線上的完成率、轉人工率與重試率。

• 先設定不可退讓的品質與安全門檻
• 再以 P95、P99 與單次任務成本比較方案
• 用線上完成率驗證離線分數是否有效

參數量與分數沒有簡單的線性關係

直接答案是：較大模型通常有更高能力上限，但不是每個任務都勝出，也不保證符合成本與延遲需求。Mixtral 8\*7B 採用多專家架構，總量可寫為 56B；但單次啟用的概念不能直接用總參數推論，類似 2\*7b = 14B 的算式只適合說明稀疏啟用與總容量不同。

公開比較中可看到 MPT (7B)、Falcon (7B)、LLaMA-2 (7B)、Llama-2 (13B)、MPT (30B)、Falcon (40B)、LLaMA-1 (65B) 與 LLaMA-2 (70B) 的能力曲線不完全一致。模型大小、資料品質、訓練方法、提示格式與評測污染，都可能改變名次。

因此，採購或自建決策不宜問「哪個模型最強」，而應問「哪個模型在我們的繁體中文、領域術語、流量與預算限制下最穩定」。公開資料適合縮小候選清單，真正的決策仍要回到私有測試集與實際工作流程。

• 總參數不等於每次推論的實際啟用量
• 同一模型可能在不同資料集呈現不同優勢
• 比較前固定提示模板、溫度與輸出限制

用跨基準結果辨識模型的強項與盲點

直接答案是：跨基準結果最有價值的地方，是揭露模型能力並不均勻。LLaMA-2 70B 尤其脫穎而出，在 10 項基準測試中的 6 項中獲得最高分。這代表它在該組比較條件下具有廣泛競爭力，但仍不能推論所有企業任務都最佳。

同一份比較也顯示，LLaMA 65B 在 BoolQ 和 QuAC 上的表現優於 LLaMA-2 70B。這正說明模型選擇不能只讀總排名：BoolQ 偏向是非判斷，QuAC 涉及對話式閱讀理解，若產品任務與這些能力接近，就應提高相關測試的權重。

以 MMLU、TriviaQA、Natural Questions、GSM8K、HumanEval、AGI/Eval、BoolQ、HellaSWAG、OpenBookQA、QuAC、Winogrande 組成能力矩陣時，請標記每一欄與產品任務的關聯度。無關分數可作為風險訊號，但不應壓過真正影響使用者成功率的任務。

• 總冠軍不一定是特定任務的冠軍
• 以任務關聯度設定基準權重
• 將公開排名視為候選篩選，不是上線驗收

零樣本與少樣本條件必須固定記錄

直接答案是：提示示例數量會顯著改變結果，評測報告必須清楚區分零樣本、少樣本與 n-shot。零樣本檢查模型原始指令遵循能力；少樣本則能透過示例指定格式、語氣與解題模式，較貼近許多商業應用的提示工程做法。

例如 5-shot 評測代表每題前提供 5 個示例；示例的排序、內容與是否與測試題相似，都可能影響分數。若甲模型採 5-shot、乙模型採零樣本，表面比較並不公平；更糟的是，示例若含有近似測試題，結果會高估泛化能力。

數學或邏輯任務也要檢查最終答案與推理可靠性。例如 `False or not ( True ) and False is` 的答案是 `False`；這類簡短題可驗證基本邏輯，但無法代表長上下文、多工具與企業規範的整體可靠度，因此不能過度延伸解讀。

• 固定 n-shot 數量、示例順序與提示模板
• 將示例與測試集嚴格隔離
• 另測零樣本與少樣本，確認提示依賴程度

人工評估最適合處理複雜與高風險品質

直接答案是：人工評估仍是檢驗高風險內容的基準，因為人能判讀語境、文化脈絡、隱含前提與業務可用性。繁體中文客服回答即使語法流暢，也可能誤用台灣慣用詞、忽略制度例外或語氣不當，這些問題往往無法由詞彙重疊指標準確捕捉。

有效的人評不應只問「好不好」，而要提供具體標註規範。例如正確性可分完全正確、部分正確、錯誤；忠實度可分有來源支持、部分支持、無支持；風格則檢查是否直接回答、是否避免不必要冗長。每個等級都需附正反例。

為降低主觀性，可讓至少 2 位評分者獨立判讀，再處理分歧案例。若一致性偏低，通常不是模型必然不穩，而是規則太模糊、案例太複雜或評分者訓練不足。先修訂標註指南，再用同一批題目重新校準，遠比急著比較模型更有價值。

• 定義可觀察的等級與正反例
• 使用配對比較降低絕對分數偏差
• 保留分歧理由，作為下一輪規格修訂素材

LLM-as-a-Judge 應是加速器而非唯一裁決者

直接答案是：裁判員模型可大幅擴充評測量，但需要用人工校正其偏差。OpenAI 的 Chat GPT-3 和 GPT-4 以及 Meta 的 Llama 常被用於生成或評判流程；當模型能依明確量規輸出理由與結構化分數時，確實能加快大量候選答案的初篩。

G-Eval、OpenAI Evals 與 `deepeval` 等工具可協助建立裁判流程，但裁判也會出現位置偏差、冗長偏差、自我偏好與提示詞敏感度。把較長回答排在前面，或改變「請嚴格評分」的指令，可能就讓結論改變，因此不可只保留單一裁判提示。

實務做法是從人工已標註的保留集抽樣，計算裁判與人工的一致程度，並觀察不同模型版本與答案順序下的穩定性。若裁判在某類繁體中文術語、法規引用或數字題上經常失準，該類案例應回到人工評分，而非用自動分數直接放行。

• 讓裁判輸出分數、理由與引用依據
• 交換答案位置，檢查位置偏差
• 以人工保留集持續校正裁判可靠性

配對比較與統計區間讓結論更穩健

直接答案是：兩個模型接近時，應報告信賴區間與配對結果，而不是宣稱小數點差距代表勝負。對同一批案例讓評分者選 A、B 或平手，再計算勝率與不確定性；若區間重疊，就應表述為證據不足，而非強行選出冠軍。

Elo 評分適合多模型、多輪配對比較，可將主觀偏好轉為可排序訊號，但它依賴配對樣本與評分者品質。當案例過度集中在簡單題、某一類語言或單一產品情境，Elo 可能反映的是題目分布，而非模型在所有工作上的能力。

評估報告應區分統計顯著與業務顯著。即使某模型勝率略高，若它的 P95 延遲、成本或安全失敗率明顯較差，也未必值得替換。將結果連回預先定義的 KPI，才能避免團隊為了漂亮分數而忽略真正的營運代價。

• 使用相同案例做配對，減少題目難度干擾
• 報告平手率、信賴區間與樣本數
• 同時判讀品質差距與業務成本差距

私有測試集要反映真實工作而且可持續更新

直接答案是：企業最有價值的測試集，來自去識別化後的真實工作案例與明確標註規範。公開資料集可協助比較通用能力，但難以涵蓋公司專有術語、既有流程、產品規則與台灣繁體中文的語境差異，因此不能取代私有驗收資料。

建議依難度、部門、任務類型與風險分層，並將資料切成開發、驗證與最終保留集。保留集不可拿來反覆調提示詞或挑模型，否則會逐漸變成訓練資料；每次更新題目、答案或引用來源，都應有版本號、變更原因與審核紀錄。

以需求預測為例，可將過往銷售、庫存與例外事件轉成驗證案例，分別測試模型是否正確解讀資料、提出可執行建議與說明限制。這比只問通用知識更貼近投資判斷，也能直接對照缺貨、庫存過剩與人工規劃時間等業務結果。

• 以真實案例建立繁體中文與領域語料
• 保留集不得用於反覆調校
• 每題保存答案、可接受範圍、證據與風險標籤

RAG 必須分開評估檢索與生成

直接答案是：RAG 的答案失敗不必然是模型幻覺，必須分別量測檢索、上下文與生成。第一層看正確文件是否進入前 K 筆；第二層看文件是否足以支持回答；第三層才看答案是否正確、是否忠於內容，以及是否完整引用關鍵依據。

若檢索沒有找回正確文件，應優先改善切分策略、嵌入模型、metadata、查詢改寫或排序器；若文件已存在但答案錯誤，才檢查提示詞、上下文長度與模型行為。將所有錯誤都標成幻覺，會讓團隊修錯地方，也會拖慢改善週期。

引用完整性不只是附上連結，而是每個重要主張都能追溯到實際來源。測試時可設計衝突文件、過期條款、沒有答案的問題與跨文件整合題，確認系統是否能指出不確定性、拒絕猜測，並將使用者導向正確流程。

• Retrieval：正確文件是否被找回
• Context：提供內容是否足以支持答案
• Generation：答案是否正確、忠實且有完整引用

安全測試應模擬攻擊與多步驟失敗

直接答案是：安全驗收要以可重複的攻擊案例測量，而不是只要求模型「保持安全」。測試集應涵蓋 prompt injection、越獄、資料外洩、仇恨或有毒內容、未授權工具使用，以及 Agent 在多步驟規劃中偏離目標的情境。

對有工具權限的 Agent，除了檢查最終文字，還要記錄工具呼叫序列、參數、授權狀態、失敗恢復與停止條件。例如模型是否在使用者要求下跳過核准、是否把機密內容送到外部工具、是否在找不到資料時持續重試而產生成本。

安全指標可包含攻擊阻擋率、錯誤拒答率、誤拒正常請求率、敏感資料洩漏率與未授權操作率。ToxiGen 可作為有毒內容的通用測試參考，但企業仍需加入自身角色權限、文件分類與工作流程，才有足夠的上線代表性。

• 將攻擊提示與正常業務提示一起測試
• 量測阻擋攻擊，也量測避免誤拒
• 對 Agent 保存完整工具軌跡與權限判定

PoC 的目標是取得 Go 或 No-Go 證據

直接答案是：PoC 不應做成縮小版正式產品，而要用最小範圍驗證最重要的不確定性。ALION 的做法從現場調查與訪談開始，先將「要釐清什麼」轉成 KPI，再以貼近實際資料與實際業務環境的原型，驗證精度、使用體驗與效益是否足以支持下一步。

一個好的 PoC 應先界定不做什麼，例如不處理全部文件類型、不開放外部客戶、不串接正式寫入權限。如此可將時間集中於高風險假設：資料是否足夠、RAG 是否找得到依據、模型能否正確遵循規範，以及現場人員是否願意使用。

驗證結束時，交付物不只是展示畫面，而應包含資料範圍、測試結果、失敗案例、成本假設、ROI 試算與 Go／No-Go 建議。即使結論是暫緩開發，仍可避免後續投入錯誤方向；這正是以小成本換取決策證據的價值。

• 先驗證最高風險假設，而非一次做滿功能
• 以實際資料與現場情境判斷可用性
• 將不做的建議視為有效成果

建立可執行的上線門檻與回歸規則

直接答案是：上線門檻應由多項必過條件組成，而不是總分達標即可。建議將核心任務正確性、引用忠實度、阻擋型安全案例、P95 延遲、單次任務成本與人工覆核流程分別設定下限；其中任一阻擋條件失敗，就不得以其他高分抵銷。

每次改模型、調系統提示詞、更新檢索索引、修改工具或更換嵌入模型，都應觸發回歸測試。測試結果要與前一個已核准版本比較，標示改善、退步與無顯著差異；若核心案例退步，即使新增功能表現更好，也應先釐清原因。

在 CI/CD 或 LLMOps 流程中，可將固定保留集、自動指標與安全案例設為合併前檢查，再定期抽樣進行人工審查。這使品質控制從上線前一次性活動，變成隨資料、模型版本與使用行為持續運作的治理機制。

• 採用必過條件，不以平均分掩蓋高風險失敗
• 任何提示詞、資料或模型異動都跑回歸測試
• 將自動檢查與人工抽查納入發版流程

將評估報告轉化為管理決策

直接答案是：管理階層需要的是可比較的投資選項，而不是難以解讀的技術分數。報告首頁應先回答：方案是否達標、主要風險是什麼、預估節省或增加多少作業量、下一步需要的預算與期間；技術細節、案例清單與統計結果可放在附錄供團隊追溯。

若企業尚未有專職 AI 技術主管，可採小規模訂閱方式累積證據。ALION 的 AI 上游工程訂閱服務為月費 20 萬日圓起，包含每週一次定期會議、需求定義、設計文件與示範製作；相較於聘僱 CTO 級人才月薪 80〜150 萬日圓，能降低一開始的人事承諾。

對於預算尚未明朗的團隊，先以可編輯的需求清單、私有測試集與原型報告取得共識，再決定正式開發、再次驗證或中止，通常比直接支付啟動費約 300 萬日圓起的外包開發更能控制風險。重點不是保證 AI 必成，而是及早取得可信的投資判斷。

• 以 Go／No-Go、風險、成本與效益作為報告首頁
• 先完成需求定義與可量測原型，再擴大開發
• 保留測試資產，讓 PoC 成果能延續到正式系統

參考來源

評估方法與資料集可查閱 Hugging Face Evaluate：https://huggingface.co/docs/evaluate/；MMLU 論文：https://arxiv.org/abs/2009.03300；BIG-bench：https://github.com/google/BIG-bench；TruthfulQA：https://github.com/sylinrl/TruthfulQA；OpenAI Evals：https://github.com/openai/evals。