衡量、評估與歸因：實作與驗收指南

本課內容

01先把定義說清楚
02現場情境
03實作範例
04照著做，每一步都有檢查點
05動手實作
06故障診間
07正式上線前的邊界
08資料來源與主張限制

這一課會完成什麼

從真實 trace 與重大失敗建立版本化評估集、grader 與人工校準。
設計同時涵蓋品質、流程、成本、採用、傷害與商業結果的 scorecard。
分清楚離線通過、線上觀察、增量實驗與只能描述的歸因限制。

開始前先準備

• 至少帶一批第 1–7 堂留下的輸入、輸出、reason code、人工修改與最終結果。
• 能說明目前的商業指標定義、資料延遲、去重與主要干擾因素。

先把定義說清楚

衡量與評估

AI 行銷評估是一套持續決策系統，平均分數只占其中一部分。離線 eval 檢查固定案例上的事實支持、格式、政策、工具使用與成本；線上監測觀察真實流量中的延遲、失敗、人工接管與傷害；商業實驗則在可行時估計相對基準或 holdout 的增量。歸因描述接觸與結果如何被規則分配，不能自動證明某次 AI 輸出造成營收。成熟做法會保存資料集版本、grader、人工爭議、發布門檻與回復規則，模型、prompt、資料或工作流程一改就重跑。

只測幾個順利範例，最危險的錯誤通常上線後才出現：來源支持錯句、同意規則被繞過、重試造成重複、代理把資料裡的指令當命令。把實際退件、事故與邊界案例轉成 eval，可以讓團隊的教訓不只停在會議紀錄。

LLM grader 便宜而快速，卻可能偏好較長文字、對特定語氣過寬，或跟領域專家意見不一致。grader 本身也要有 rubric、已知案例、重複試驗與人工校準。若一個分數從 0.82 變 0.85，先確認差異是否穩定且有營運意義，再決定發布。

商業儀表板常把同時發生的活動全算給最後一次點擊，或把產出量當採用價值。AI 流程可能讓內容增加，但也讓審核、客訴與完整成本上升。scorecard 要把領先指標、品質門檻、流程健康、傷害與落後商業結果並排，才不會用一個好看的數字掩蓋代價。

現場情境

Pulse Scorecard 評估

教學用合成案例。資料集、分數、成本與轉換均為教材設定，不構成任何模型或行銷渠道基準。

負責人: Marketing Analytics Lead，要決定是否將新的模型與 prompt 發布到內容、CRM 與研究工作流程。
要做的決策: 建立 120 案例的 versioned eval set：50 個內容與研究、30 個 CRM、20 個自動化、20 個代理；其中 35 個來自真實退件或事故去識別版本。每項分成 hard gate、graded quality 與 operational metric，發布時不只看平均。
目前狀態: Pulse 每月只抽看 10 個輸出，主管用 1–5 分評「看起來好不好」。儀表板顯示草稿量增加 140%，卻沒有來源支持率、誤送、人工分鐘或模型成本。新版本在 10 個案例平均 4.4 分，高於舊版 4.1；但其中一筆 CRM 測試把已退訂者判成可發送。
預期成果: 新版本若通過所有 hard gates、品質信賴區間沒有實質退步、成本與延遲在上限內，才進 10% canary。線上 scorecard 能把模型品質、流程健康、傷害、採用與商業結果分層呈現。

限制條件

• 個資、同意、錯誤對外主張與不可逆副作用屬阻斷條件，不能被平均分抵銷。
• 評估集至少涵蓋正常、邊界、攻擊、拒答、資料缺失與外部系統失敗。
• LLM grader 不得單獨判定高風險政策與事實爭議；要保留人工樣本。
• 線上發布先走小流量 canary，品質或傷害門檻觸發就回復。

實作範例

平均 4.4 分仍然不准發布

證據類型: 具名模擬情境

Pulse 的新版本在短摘要與標題上更流暢，因此人工平均從 4.1 升到 4.4；不過 10 個抽樣裡只有一個 CRM 同意邊界，模型恰好判錯。若把 10 題平均，這個錯誤只拉低少量分數，看起來仍是升級。正式流量每天可能處理數千筆，稀少但嚴重的誤送不能用文案更順來交換。

團隊把 consent、unsupported-claim、PII exposure、duplicate-side-effect 與 unauthorized-tool-call 設為 hard gate，任何一例失敗都阻擋。流暢度、完整性與可讀性才使用 1–5 rubric；來源支持則由 claim-level 對照判定。每個 grader 在 30 個人工金標案例校準，重跑 3 次觀察變異。新版本修正同意規則後，需重跑完整 120 題，不只補跑失敗那一題。

第一次新版本因 1 個 consent failure 被拒絕。修正版通過 hard gates，內容可讀性中位數持平，source support 從 91% 到 94%，每筆中位成本增加 12%，p95 延遲增加 18%。團隊同意進 10% canary，但設定成本與延遲警示，沒有把離線提升直接換算成營收。

主張限制

120 題仍不涵蓋所有真實分布，去識別也可能移除重要脈絡。91%、94%、12%、18% 與 10% 都是教材數字。LLM grader 可能隨模型更新變動，人工評分也有歧見；資料集若長期不刷新，會過度適合已知問題。線上商業結果受活動、季節、銷售及渠道改動影響，不能由 eval 單獨歸因。

做法

照著做，每一步都有檢查點

現場情境

建立 120 案例的 versioned eval set：50 個內容與研究、30 個 CRM、20 個自動化、20 個代理；其中 35 個來自真實退件或事故去識別版本。每項分成 hard gate、graded quality 與 operational metric，發布時不只看平均。

01從決策與失敗建立評估地圖
02把硬門檻與品質分數分開
03校準 grader 與重複試驗

驗收條件

完成品能讓發布者看到候選版本在哪些案例變好、在哪裡仍不穩、最嚴重失敗是什麼，以及線上發生哪些訊號就要回復。評估資料也能持續吸收新的退件與事故，無須等到上線前才臨時抽看。

這張圖要幫你看懂什麼離線 eval、canary、線上流程健康、傷害與商業結果有先後與不同推論強度，適合用分層 scorecard 和發布閘門圖。

01
從決策與失敗建立評估地圖
列出系統必須做對的決策、可能傷害與常見分布，再對照手上案例。正常、邊界、攻擊、缺資料、拒答、timeout 與部分成功都要有 slice；重大事故優先加入。
檢查點 · 至少 24 題橫跨 6 種 slice，每題有來源、風險、預期結果與資料集版本，沒有只靠順利範例填數。
02
把硬門檻與品質分數分開
同意、個資、未支持主張、重複副作用與越權採 pass/fail；語氣、完整性與可讀性才用 rubric。定義哪些欄位可程式比對，哪些需模型或人評。
檢查點 · 任一 hard gate 失敗都會阻擋發布，不會被其他題高分平均掉；rubric 每個等級有可觀察描述。
03
校準 grader 與重複試驗
以人工金標比較規則、LLM grader 與實際審核者；記錄誤判與歧見。對非確定輸出重跑至少 3 次，報分布、最差切片與案例，不只報平均。
檢查點 · 30 個或可行的人工校準樣本有一致率與爭議清單；grader prompt、模型、版本與執行設定可重現。
04
比較基準、候選與完整成本
在相同資料集跑 production baseline 與 candidate，對照 hard gate、各 slice 品質、中位與尾端延遲、token、工具呼叫、人工分鐘與每次成功成本。
檢查點 · 報告可看到哪個 slice 改善或退步；資料缺失與失敗重試成本沒有從分母消失。
05
設計 canary 與商業解讀
離線通過後，只將小比例真實流量送入新版本。監測品質抽樣、流程錯誤、傷害、成本與採用；商業結果若沒有 holdout 或對照，清楚標成描述性趨勢。
檢查點 · 10% 或自訂 canary 有分流、停止、回復、值班與通知；報告沒有把離線分數直接換算成營收歸因。

動手實作

建立版本化 eval set 與發布 scorecard

用 Pulse 的 120 題結構設計自己的小型評估集，至少實作 24 題可重跑 fixture。

準備項目

• 收集正常輸出、人工退件、事故、攻擊與資料缺失案例，先去識別並確認使用權限。
• 記錄目前 production 版本、基準品質、成本、延遲與主要傷害事件。
• 指定資料集、grader、人工校準、發布與事故回復的負責人。

本課產出

一份評估地圖、至少 24 題資料集、rubric 與 grader、人工校準表、版本比較報告、10% canary 計畫及回復門檻。

起始模板: Eval case 與發布門檻範本

JSONL

{"case_id":"consent-001","slice":"crm","input_fixture":"fixtures/consent-001.json","expected":{"decision":"suppress","reason_code":"unsubscribed"},"hard_gates":["no-send","no-pii"],"graders":["exact-decision","policy-check"],"source":"deidentified-incident","dataset_version":"2026-08-20-v1"}
{"case_id":"source-001","slice":"research","input_fixture":"fixtures/source-001.json","expected":{"required_source_ids":["s01"],"unsupported_claims":0},"hard_gates":["no-unsupported-claim"],"graders":["claim-support","completeness"],"source":"review-rejection","dataset_version":"2026-08-20-v1"}

release:
  candidate_version:
  baseline_version:
  repeated_runs: 3
  hard_gate: 100%
  quality_non_regression:
  max_cost_per_success:
  p95_latency:
  canary_percent: 10
  rollback_owner:
  online_stop_conditions: [policy-error, duplicate-side-effect, cost-cap, error-rate]

預期結果

留給下一課

保留 eval set、baseline、scorecard 與 canary runbook。第 9 堂會用它們定義 30 天導入的成功、停止與交接條件。

驗收條件

01至少 24 題涵蓋正常、邊界、攻擊、缺資料、拒答與外部失敗，且都有版本與預期。
02hard gate、graded quality、operational metric 與 business outcome 分層，嚴重錯誤不能被平均。
03grader 經人工校準並重跑至少 3 次；版本比較包含 slice、尾端延遲與完整成本。
04canary 具分流、停止、回復與值班責任；增量、歸因與描述性趨勢沒有混用。

常見故障

故障診間

F1平均分上升，但正式環境出現同意錯誤或未支持主張。

先檢查: 查看資料集 slice、hard gate、事故是否入集、平均計算與失敗案例權重。
可能原因: 高嚴重度低頻錯誤被可讀性高分稀釋，或資料集沒有真實邊界。
修復方式: 立即回復候選版本，把事故去識別後加入 hard gate，重跑完整資料集。
下次怎麼避免: 風險採 pass/fail 且獨立報告；每次重大退件與事故都有轉入 eval 的責任與期限。

F2同一候選版本重跑分數差很多，團隊仍用小數點差異決定發布。

先檢查: 比對 temperature、seed、模型快照、grader 版本、執行次數與各 slice 分布。
可能原因: 只跑一次非確定評估，且沒有人工校準或差異門檻。
修復方式: 固定可固定的設定，增加重複次數並報信賴區間；小於實務門檻的差異視為持平。
下次怎麼避免: 版本報告固定包含重跑、變異、最差案例與人工爭議，不只顯示單一平均。

F3儀表板宣稱 AI 帶來營收，但同期換了活動、價格與銷售流程。

先檢查: 檢查分流、holdout、曝光定義、歸因窗、同期變更、遺漏接觸與資料延遲。
可能原因: 把最後點擊或前後差異寫成因果，沒有對照與假設。
修復方式: 把結論降級為描述性關聯，列出干擾；下一輪設計 holdout、分階段推出或其他可行對照。
下次怎麼避免: 每張商業圖表標註估計方法、分母、觀察窗、限制與不可推論事項。

展示版之後

正式上線前的邊界

01eval set 有資料來源、去識別、使用權限、slice、風險、預期、版本與刷新負責人。
02hard gate 與品質 rubric 分開；同意、個資、未支持主張、越權和重複副作用採零容忍門檻。
03grader 的 prompt、模型、設定與版本被鎖定，經人工金標校準並監測漂移。
04baseline 與 candidate 在相同資料集重跑多次，報告分布、最差 slice、延遲與完整成本。
05線上監測輸入漂移、失敗、人工修改、接管、傷害、成功成本與資料品質。
06canary 有穩定分流、採樣、停止、回復、值班與通知；回復後保存待查 trace。
07商業指標附分母、窗期、去重、對照與限制；歸因規則不被描述成因果證明。
08新退件、事故與未知失敗定期整理進資料集，避免只對既有題目最佳化。

證據類型

資料來源與主張限制

資料來源只支撐本課標示的主張，不代表換一個系統也會得到相同結果。

[1]
Evaluate agent workflows
OpenAI · 官方文件 · 2026-08-20
從 trace 建立資料集、grader 與版本回歸測試
[2]
NIST AI RMF: Measure
NIST · 官方文件 · 2026-08-20
評估指標、風險量測與監測責任
[3]
Demystifying evals for AI agents
Anthropic · 已發表研究 · 2026-08-20
任務集、重複試驗、結果 grader 與人工校準
[4]
What is Generative Engine Optimization (GEO)?
Seer Interactive · 公開案例 · 2026-08-20
假設、基準、測試設計、分析與限制的公開實驗框架
[5]
Triple Whale drives business growth with Claude
Anthropic / Claude · 公開案例 · 2026-08-20
分析代理使用規劃、專用工具、平行工作與人工決策的公開案例