1. 前言：抽樣幾題體感良好的回答無法作為企業級AI助理上線的信心指標

前三天我們把行銷助理做出來了，Day 21 教它查資料，Day 22 讓它記得上下文，Day 23 替它裝上護欄，每一天我都是把回答一題一題讀過才敢寫進文章，可是哪天主管問起這個助理講的數字能不能直接放進週報，我能回的只有「我試過幾題還不錯」，這句話沒有題目清單、沒有標準答案、沒有分數，下次換了模型或改了工具，也沒辦法知道它是變好還是變差。

有系統地替 AI 的回答打分數這件事叫評測，做評測要先有三樣東西，題目、標準答案、評分的方式，標準答案的來源我們在 Day 05 就準備好了，當時藏進合成資料的那幾個訊號就是現成的依據，今天麻煩的是第三樣，評分的方式本身也會出錯，用關鍵字比對會被換個說法騙過，請人來評又貴又慢，請另一個模型來評很便宜，但它評得準不準也要有人驗過。

所以今天要考的對象有兩個，先考助理，再考替助理打分數的方式。

今日核心目標：

1. 用 Day 05 藏好的訊號出 8 個問題，同一題在有工具和沒有工具兩種情況各問一次
2. 同一批 16 個回答用三種方式評分：規則、人、Gen AI evaluation service 的評分模型
3. 把三種分數放在一起，看哪幾題不一樣、為什麼不一樣，找出哪些地方非人來判斷不可

2. 系統架構全景與設計理念

整個流程分四段，每一段的結果都寫進 BigQuery，花錢的只有第一段和第四段。

這個設計有三個刻意的安排：

第一，題目、標準答案、規則、評分標準全部寫死在 evaluation/eval_run.py，問模型之前要先 commit，run.sh 會檢查，這些內容還會算出一個指紋跟著每一個回答、每一筆分數寫進表裡，看完回答再回頭改題目或改標準答案，指紋就對不起來檢查會直接報錯。

第二，人的分數要在評分模型開始之前寫好，而且 human_labels.csv 要先 commit，run.sh judge 才肯往下跑，順序反過來的話，人看過評分模型給的分數和理由很難不被影響，要先說明的是，這一次人的分數是先請另一個 AI 助手打草稿、我再逐則審過定案的，所以這個基準並不是完全獨立於模型的判斷，3.2 和 3.5 會交代這件事對結論的影響。

第三，給人評分的 16 則是打亂順序的，檔案裡只有編號，沒有標出哪一則是有工具的回答，這只遮得住標籤，有工具的回答帶著精確的數字，讀內容多半還是猜得出來。

3. 核心技術深度拆解

3.1 題目從訊號答案表來，但標準答案要寫成工具查得到的版本

8 個問題分成三種。

e6、e7 兩題是故意出的，訊號確實藏在資料裡，但助理手上的三個工具（通路歸因、成效異常診斷、素材特徵）查不到，這時候正確的回答是老實說查不到，最後一題則是答案表裡根本沒有放的東西，正確的回答是沒有。

寫標準答案的時候我踩了一個坑，第一版直接抄答案表，例如 e1 寫「8/12 起每次點擊成本變成 2 倍」，可是助理查得到的是 Day 09 的診斷結果，那裡寫的是「8/10 到 8/16 那一週增加 78%」，兩邊講的是同一件事，數字卻對不上，照第一版去評，答得越忠於工具的回答越容易被扣分，花錢之前我請另一個 AI 做獨立審查它就抓到這一點，之後標準答案全部改成工具查得到的版本，藏進資料的設定寫在後面當成容許範圍，像 e1 就註明日期回答 8/10 那一週或 8/12 都算對、倍數回答約 1.8 倍或 2 倍都算對。

3.2 三種評分方式用同一份評分標準

分數只有 0、1、2 三種，三種評分方式看的是同一段文字。

2 分：重點和標準答案一致。對象、日期、方向都對，數字和標準答案相差在兩成以內算一致，日期落在同一週內算一致。多給了標準答案沒提到、但不矛盾的細節不扣分。標準答案說正確的回答是查不到，而回答也清楚說明查不到，同樣給 2 分。
1 分：部分正確。少了關鍵的一項，或是有一項和標準答案不符。標準答案有內容，回答卻只老實說自己查不到、沒有編造，也給 1 分。
0 分：和標準答案矛盾、答非所問，或是編出和標準答案矛盾的數字、日期或原因。標準答案說正確的回答是查不到，回答卻自己給了數字，一律 0 分。

規則是把每一題的關鍵事實寫成比對條件，例如 e2 要同時出現日期（8/27）、追蹤出問題、其實有訂單三項才給 2 分，寫規則時有一個原則，關鍵事實只能挑題目裡沒有出現過的字，第一版我把「疲乏」「點擊成本」這些題目本來就有的字也算進去，結果一個回答只要把題目照念一次再說不知道，就能拿到 1 分。

人的部分，16 則回答打亂順序之後，先由 AI 助手（Claude，不是今天那兩個評分模型）照評分標準評一遍當草稿，我再逐則讀過定案，最後改了一則的分數，這一則後面會細講，它是今天最有意思的地方，也因為 16 則裡有 15 則我同意草稿的分數，下面凡是寫「人的分數」，指的都是這種 AI 草稿加人審核的分數。

評分模型用的是 Gen AI evaluation service，下一節說明。

3.3 Gen AI evaluation service：把評分說明和資料交給它，它回分數和理由

Gen AI evaluation service 是 Google Cloud 上專門做評測的服務，今天用的是 pointwise 指標，一次評一個回答，另外還有 pairwise 指標用來比較兩個回答哪個好（今天沒有用到），評分說明是自己寫的，內容就是 3.2 那份評分標準，加上問題、標準答案、回答三個欄位，我直接呼叫它的 REST 端點 evaluateInstances，一次送一筆。

body = {
    "pointwiseMetricInput": {
        "metricSpec": {"metricPromptTemplate": JUDGE_TEMPLATE},   # 評分說明，裡面有 {prompt}、{reference}、{response}
        "instance": {"jsonInstance": json.dumps(
            {"prompt": 問題, "reference": 標準答案, "response": 助理的回答}, ensure_ascii=False)},
    },
    "autoraterConfig": {
        "samplingCount": 1,
        "autoraterModel": f"projects/{project}/locations/global/publishers/google/models/{judge}",
        "generationConfig": {"temperature": 0, "maxOutputTokens": 768},
    },
}
resp = session.post(
    f"https://aiplatform.googleapis.com/v1beta1/projects/{project}/locations/global:evaluateInstances", json=body)
result = resp.json()["pointwiseMetricResult"]   # {"score": 2, "explanation": "..."}

幾個設定值得說明：

• metricPromptTemplate 是自己寫的評分說明，大括號裡的變數由服務用 jsonInstance 的內容代入
• autoraterModel 可以指定用哪個模型來評，今天用了兩個，一個是和助理同一個模型的 gemini-3.6-flash（等於自己評自己，這也是限制之一），一個是比較便宜的 gemini-3.5-flash-lite
• samplingCount 是同一筆要問評分模型幾次，依 SDK 裡的欄位定義，沒有指定時是 4 次（預設的行為我沒有實測），今天設成 1 次省錢，代價是每筆分數只是一次抽樣
• generationConfig 把溫度設成 0、輸出上限設成 768 個 Token，這個服務不回報用掉多少 Token，不設上限的話連估價都沒辦法估

3.4 助理的成績：有工具 8 題全對，沒有工具 8 題裡有 6 題拿 0 分

先看人定案的分數（滿分 2 分）。

有工具的 8 個回答全部滿分，查得到的 5 題數字和日期都和工具結果一致，查不到的 2 題都老實說查不到，其中 e6 模型先要求了一個清單裡不存在的工具 get_project_impact，程式沒有執行並把錯誤交回去，模型接著回答目前的工具查不到，沒有硬掰。

沒有工具的那一邊值得一題一題看：

• e1 說系統裡沒有八月的資料，請同事提供報表，沒有編，拿 1 分
• e2 說是 8 月 31 日追蹤碼斷線，後台依然有訂單，原因和結論都對，日期是錯的
• e3 編出一支叫「夏日新品優惠_短影音B」的素材，點擊率從 2.8% 掉到 0.9%，整段都是編的
• e4 給了三組範圍很寬的倍數，還說按鈕放右下幫助最大，和資料相反
• e5 說 Meta 常是第一次接觸、Google 搜尋廣告常是最後一次接觸，方向全對，拿 2 分，但它沒有任何數字，看起來靠的是一般行銷常識，剛好和我們藏的訊號方向一致
• e6 編出占比從 25% 提升到 38%
• e7 先說要看訂單報表，接著還是給了「一般電商 60% 至 80%」
• e8 說 LINE 曾經因為追蹤碼修訂和大檔期競價出過異常，兩件事都沒有發生過

8 題裡有 6 題拿 0 分，其中 5 題編出了我們資料裡不存在的事（e2 的日期、e3 的素材與數字、e4 的倍數、e6 的占比、e8 的兩件異常），e7 沒有編公司的數字，但拿產業的一般值來回答，同樣是 0 分，這些回答我讀起來語氣和有工具時一樣肯定，光看回答的樣子分不出哪一個是查出來的，e5 則是另一種提醒，答對不代表有依據，這一題沒有工具也答中了，像這樣答案和常識方向一致的題目，測不出助理有沒有真的去查。

3.5 評分方式的成績：規則有 4 個回答和人不同，兩個評分模型都在同一則和人不同

把人的分數當基準，另外三種方式的結果如下。

規則的 4 個不同，原因各不相同，除了下面會講的 e2，另外三個是這樣：

• e5 有工具的回答寫的是「meta (paid_social) 佔了 23.88% 的訂單（789 筆），高於 google / cpc 的 10.65%，比較常是客人第一次接觸的通路」，完全正確，規則卻給 0 分，因為規則要找的是 meta 後面 25 個字以內出現「第一次」這類字眼，而且中間不能有逗號，這個回答先講數字再下結論，距離超過了，中間也隔了逗號，講對了但換一種句型，規則就不認得
• e4 沒有工具的回答是編的，規則卻給 1 分，因為它說暖色系「約 1.1 至 1.3 倍」，規則抓到 1.1 這個數字落在容許範圍內，就算它講對一項
• e8 沒有工具的回答編了 LINE 的異常，規則給 1 分，因為回答裡出現「追蹤碼」三個字，規則把它當成有提到全站追蹤問題

兩個評分模型都給 e2 沒工具的回答 1 分，人給 0 分（規則也是 1 分，但那是因為它只認出追蹤碼這一項，日期和訂單都沒有認出來，只是剛好同分），評分模型的理由很清楚，gemini-3.6-flash 寫的是「助理正確說明了是追蹤碼問題且當天實際上仍有訂單產生，但解答的日期（8月31日）與標準答案（8月27日）不符」，三項對兩項、錯一項，照 1 分那一條的字面是 1 分，AI 助手打草稿的時候也是給 1 分。

我最後把它改成 0 分，理由是站在使用者的角度看，這個回答把一個錯的日期講得很肯定，同事拿去查 8 月 31 日的紀錄很可能什麼都查不到，甚至以為追蹤沒有問題，比起老實說不知道，講錯的傷害更大，e1 沒有工具時說查不到都有 1 分，e2 講錯日期不該和它同分。

回頭看評分標準，1 分那一條寫的是有一項和標準答案不符，0 分那一條寫的是編出和標準答案矛盾的數字、日期或原因，這個回答兩條都符合，標準本身有模糊的地方，評分模型選了寬的那一邊，人選了嚴的那一邊，這不是評分模型看錯，是「講錯比不知道更糟」這個判斷沒有被寫進標準裡，而這個判斷來自對使用情境的理解，這裡也要老實交代，e2 這一則正是我唯一推翻 AI 草稿的一則，其餘 15 則的基準本來就出自模型，評分模型和它一致，有一部分只是模型和模型一致，所以評分模型和人的一致率會偏高，不一致集中在這一則也和做法有關。

gemini-3.5-flash-lite 另外把 e5 沒工具的回答評成 1 分，理由是缺少標準答案裡的具體筆數，評分標準只寫了多給細節不扣分，沒有寫少給數字要不要扣，它把少了筆數當成少了關鍵的一項，這也說得通，這一次它在這一題比另一個評分模型嚴。

今天非人不可的地方有三件事：

• 標準答案由誰確認：答案表是人設計的，改寫成工具查得到的版本之後，也要由人確認每一條寫得對不對
• 模稜兩可的回答怎麼判：像 e2 這種對一半錯一半的回答，錯的那一半有多嚴重，要懂業務的人來決定，決定之後再寫回評分標準
• 評分方式之間不一致時由誰裁決：16 個回答裡有 5 個至少有一種方式和人不同，每一個都要有人讀過原文才知道誰對

再往專業的題目走，例如歸因模型該怎麼選、異常的原因判斷合不合理，我的看法是最後的審核更需要該領域的專家來做，評分模型適合拿來做第一輪的大量篩選，把分數不一致和分數偏低的挑出來給人看。

這些數字的限制也要講清楚，只有 16 個回答、每題只問一次、評分模型每筆只抽樣一次、其中一個評分模型和助理是同一個模型、做基準的分數是 AI 草稿加一個人審核而且 16 則裡只有 1 則被改過，15 / 16 和 14 / 16 只差一個回答，不能拿來說哪個評分模型比較準，12 / 16 和 15 / 16 也不能當成評分模型一定比規則準的證據，今天能說的是每一個不一致各自是什麼原因。

4. FinOps 成本防護實踐：三道防線體系

1. 第一道防線：善用 Google Cloud 每月免費額度：三個工具查的都是小表，在 BigQuery 每月 1 TiB 的查詢免費額度內，規則評分、匯出、寫入人的分數、檢查與報表都不呼叫模型
2. 第二道防線：架構層被動成本防護：問問題沿用 Day 21 的上限（每題最多呼叫模型 4 次、輸入最多 4,000 個 Token），評分模型的輸出上限設成 768 個 Token、每筆只問 1 次，Day 24 所有步驟累計估到新台幣 5 元就停，兩個花錢的步驟都先印估價，輸入 yes 才開始，評分模型還多一個 --one，每個模型先試一筆、印出原始回應，確認分數讀得到再跑完整的
3. 第三道防線：Cloud Billing 預算警報：沿用 Day 03 由 Terraform 建立的預算警報，50%、80%、100% 三段通知，今天的金額本身不足以觸發

問問題那一列是實際用量算出來的，16 個回答呼叫模型 24 次，事前印出的預期是 1.14 元、最壞是 13.67 元。

評分那兩列只能給上限，因為 evaluation service 的回應裡沒有 Token 用量，輸入是送出前自己數的再多估三成，輸出當成每一次都寫滿 768 個 Token，實際金額要等帳單，另外找出評分模型路徑寫法的時候多打了一次 gemini-3.5-flash-lite，沒有記在表裡，約 0.07 元以內。

單價用官方定價頁 global 端點的價格（gemini-3.6-flash 每百萬 Token 輸入 0.75、輸出 3.75 美元，gemini-3.5-flash-lite 輸入 0.30、輸出 2.50 美元），匯率以 1 美元約 32 元計。

5. Cloud Shell 實戰演練：考助理，再考評分的方式

5.1 事前準備

• 先在 ~/ai-driven-martech-pipeline 執行 git pull，取得 Day 24 新增的 evaluation/ 目錄
• gcloud config get-value project 要印出你的專案 ID
• 已完成 Day 08、Day 09、Day 17 與 Day 21（助理的三個工具），Token 用量表 ops_llm_usage 是 Day 16 建的
• 需要 google-genai、google-cloud-bigquery、requests 三個 Python 套件，缺少時 run.sh 會提示安裝指令
• 儲存庫裡的 evaluation/human_labels.csv 和 answers_to_label.md 是我這一次的紀錄，你的模型回答不會和我的一字不差，要自己重評，開始前先把這兩個檔案改名留存

cd ~/ai-driven-martech-pipeline/evaluation
git mv human_labels.csv human_labels.jimmy.csv && git mv answers_to_label.md answers_to_label.jimmy.md
git commit -m "keep the original labels for reference"

5.2 路線 A｜四個指令走完

cd ~/ai-driven-martech-pipeline
bash evaluation/run.sh answers
# 讀 evaluation/answers_to_label.md，把 0、1、2 填進 evaluation/human_labels.csv 的 score 欄
bash evaluation/run.sh human
git add evaluation/human_labels.csv evaluation/answers_to_label.md && git commit -m "my labels"
bash evaluation/run.sh judge --one
bash evaluation/run.sh judge

answers 會問 16 次、做規則評分、匯出給人評分的兩個檔案，human 把你填好的分數寫進表，judge --one 每個評分模型只試一筆，judge 跑完剩下的並印出檢查與報表，answers、judge --one、judge 三個步驟都會先印估價再停下來，輸入 yes 才開始，我這次的估價合計最多約新台幣 4.05 元，累計估到 5 元會自動停，問過的問題、評過的分數再執行都不會重複收費，兩次 git commit 需要 Cloud Shell 已經設定過 git 的 user.name 與 user.email，另外因為本機多了 commit，之後的 git pull 會變成合併。

5.3 路線 B｜一步一步看

路線 B 是把路線 A 拆開來看每一步在做什麼，實際執行的指令仍是 5.2 那幾個。

步驟 1：不呼叫模型先看規則怎麼評

cd ~/ai-driven-martech-pipeline
python3 evaluation/eval_run.py selftest
python3 -c "
import sys; sys.path.insert(0, 'evaluation')
import eval_run as E
q = {x['id']: x for x in E.QUESTIONS}
print(E.rule_score(q['e2'], '8/27 是追蹤碼失效，後台其實有 37 筆訂單'))
print(E.rule_score(q['e5'], 'google 比較常是第一次接觸，meta 比較常是最後一次接觸'))
print(E.rule_score(q['e7'], '查不到，但一般電商約三到四成'))
"

這一步要先裝好 5.1 列的 Python 套件，第一行是 27 個例子的自我檢查，後面三行會印出分數和說明，分別是答對、把方向講反、嘴上說查不到卻還是給了數字，分數依序是 2、0、0。

步驟 2：只看估價

bash evaluation/run.sh answers --dry

會先做預檢（實際查一次三個工具，確認查得到資料、最長的結果放得進輸入上限），再印出預期金額與最壞金額，沒有呼叫模型，judge --dry 要等有了 16 個回答、人的分數也 commit 之後才印得出估價。

步驟 3：填分數時的注意事項

answers_to_label.md 開頭就是評分標準，16 則的順序是打亂的，同一個問題會出現兩次，human_labels.csv 可以用試算表軟體開，只填 score 和 note 兩欄，n 和 fingerprint 不要動，fingerprint 是用來確認這份分數評的是這一批回答。

步驟 4：只看檢查與報表

bash evaluation/run.sh report

5.4 驗證成果

• check.sql 的 12 項都是 OK，第 6 項確認人的分數比第一次呼叫評分模型早寫進表，第 10 項確認回答和每一筆分數用的是同一版題目與評分標準
• 報表第 2 段是每一題四種分數攤開的樣子，第 4 段列出每一筆和人不一樣的分數與當時的理由，這一段要自己讀過
• 你的結果不會和我的完全一樣，沒有工具的那一邊編出來的內容可能不同

5.5 用完後怎麼處理

eval_answers、eval_calls_log、eval_scores 三張表都很小，留著不會產生費用，三張表都是只加不刪，之後換模型或改工具再跑一次，就能和今天的分數比，Day 25 的成本儀表板會用到 ops_llm_usage 裡今天寫進去的 24 列，評分模型的用量因為服務不回報，沒有寫進那張表。

6. 工程實務避坑指南

1. 標準答案要寫成助理查得到的版本：答案表上寫 2 倍，工具查到的是增加 78%，兩個都對，但直接拿答案表去評，答得越忠於資料的回答越吃虧，標準答案要以助理實際看得到的資料為準，原始設定寫成容許範圍
2. 規則別拿題目裡的字當關鍵事實：題目問素材疲乏，規則又把「疲乏」當成答對的證據，回答只要把題目複述一次就有分數，關鍵事實要挑題目沒有給的東西，日期、編號、數字、原因
3. 評分模型的地區要實際打一次才知道：官方範例用 us-central1，我照著寫，事前故意送一個內容不完整的請求去探測，也回了預期的 400，真的送出去才發現兩個評分模型在那裡都回 404，把端點和模型路徑都改成 global（不指定地區的端點）才通，404 沒有跑到模型，照理不計費，實際以帳單為準
4. 評分模型的輸出要設上限：evaluation service 不回報 Token 用量，評分模型如果有思考，照一般的計費方式也算輸出，不設 maxOutputTokens 的話每一筆可能花多少完全沒有底，samplingCount 沒有指定時依定義還會同一筆問 4 次
5. 人要先評，而且要留下證據：先看過評分模型的分數再來評，很容易跟著走，至少要在看到評分模型的分數之前定案，今天的做法是把評分表 commit 之後才允許呼叫評分模型，commit 紀錄和寫進表的時間可以佐證，今天的草稿是 AI 打的，下次更好的做法是人先獨立評完再和 AI 的草稿對照
6. 評分標準裡的模糊地帶會直接變成不一致：e2 那一則同時符合 1 分和 0 分的條件，兩個評分模型都選了 1 分，人選了 0 分，遇到這種情況要回頭把判斷寫進標準，例如「把錯的日期或數字講得很肯定，一律 0 分」，下一輪再評
7. 16 個回答只能找問題，不能下結論：15 / 16 和 14 / 16 只差一個回答，樣本這麼小的時候，一致率拿來排名沒有意義，有價值的是每一筆不一致的原文和理由
8. 答對不代表有依據：e5 沒有工具也拿滿分，因為答案剛好和常識一致，出題時要留意這種題目，它量不出助理有沒有真的查資料，要搭配工具呼叫紀錄一起看

7. 總結與明日預告

今天用 Day 05 藏好的訊號出了 8 個問題，有工具和沒有工具各問一次，再用規則、人、評分模型三種方式替 16 個回答評分，有工具的助理 8 題全部滿分，查不到的也老實說查不到，沒有工具時平均只有 0.38 分，8 題裡有 6 題拿 0 分，其中 5 題編出了資料裡不存在的事，三種評分方式裡，規則有 4 個回答和人不同，兩個評分模型分別是 1 個和 2 個，記在表裡的模型呼叫共 56 次，費用最多約新台幣 4.05 元。

回到篇名，今天的答案分兩層，有工具的時候 8 題都答對，其中 3 題是正確地說查不到或沒有，沒有資料可查的時候它照樣答得很肯定，所以該信的不是它的語氣，而是它查了什麼，至於替它打分數這件事，在這 16 個回答上，評分模型和人不同的地方比規則少，而且每一筆都有說得通的理由，可以拿來做第一輪篩選，但樣本太小、基準又是從 AI 的草稿審出來的，不能當成它比較準的證據，今天規則和兩個評分模型都和人不同的那一則，正好是需要理解使用情境才能判斷的地方，講錯比不知道更糟，這種判斷要由人來下，再寫回評分標準裡，越專業的問題越需要專家做最後的審核。

明日預告：Day 25《每天用了多少 Token？打開儀表板一目了然》，從 Day 16 開始，拿得到用量的每一次模型呼叫都寫進了同一張表，明天把它變成看得到的儀表板。