Day 08 到 Day 12 一路用 SQL、機器學習和 Gemini 從合成資料裡找出了不少東西，Meta 重訓襪專案的點擊成本變貴、8/27 追蹤碼失效、素材疲乏、四種顧客類型、通路在購買路徑上的位置、秋日棉織專案的商品占比，每一篇的結論讀起來都很合理，但合理和正確是兩回事，真實資料沒有標準答案，分析的人永遠不知道自己漏掉了什麼，也不知道找到的東西有幾分是真的。
這個系列從 Day 05 起用的是合成資料，合成器產生資料時把七個訊號藏了進去，寫在 ground_truth.json 裡，這幾篇分析都沒有讀過這份答案表，只在揭曉時拿出來對照，今天把它拿出來當考卷，把前面五篇的結果整理成一張成績單，看哪些訊號找回來了、差多少、是靠 SQL、機器學習還是 AI 找到的。
成績單之外還要再考一次，Day 09 讓 Gemini 判讀異常原因時，是先用 SQL 挑出四筆異常、再給它六個候選原因選，題目已經把答案圈得很小，今天反過來，把整季的週報一次交給 Gemini，不挑異常、不給候選，看它自己能找回幾個，兩種考法的規則相同，判準要在看成績之前寫死、先 commit（把檔案連同時間記進 git 版本紀錄），今天的雲端費用都以 1 美元約 32 元換算成新台幣。
今日核心目標：
| 步驟 | 做什麼 | 產出 |
|---|---|---|
| 出考卷 | 每個訊號寫成一到兩個檢查項目與數字門檻，先 commit | martech_gt.acceptance_criteria，12 列 |
| 算成績 | 讀 Day 08、09、11、12 的結果表算實測值，最後才對照判準 | martech_gt.acceptance_scorecard |
| 寫盲測判準 | 每個訊號三組關鍵字，呼叫 Gemini 前先 commit | martech_gt.blind_criteria，4 列 |
| 出盲測題 | 把整季的廣告與訂單週報寫成一段文字，不挑異常、不給候選原因 | martech_dw.blind_prompt |
| 盲測 | 兩個模型各問三次，回答鎖成 JSON 的發現清單 | blind_result、blind_findings |
| 評分 | 每一項發現對照三組關鍵字 | martech_gt.blind_scorecard，24 列 |
💡 核心工程理念：
martech_gt，分析用的 martech_dw 裡沒有答案，run.sh 會用 grep 確認題目與呼叫 Gemini 的 SQL 沒有讀到答案資料集run.sh 會比對判準檔最後一次 commit 的時間與評分時間，順序不對就算檢查不通過，判準有沒有被改過則要看 git 紀錄裡那個檔案有幾次 commit答案表有七個訊號，S4 是圖片屬性對點擊率的影響，要等 Day 17 分析素材屬性才會考，這次標成待考，其他六題每一題都要回答「怎樣算找到」，找到不能是主觀判斷，要是一個查詢就能算出來的數字加上一個範圍：
| 訊號 | 藏了什麼 | 檢查項目 | 怎樣算找到 |
|---|---|---|---|
| S1 | Meta 重訓襪專案開發新客的點擊成本 8/12 起變兩倍 | S1a 8/12 前後的點擊成本倍數（SQL）、S1b Day 09 flash-lite 的判讀（AI） | 倍數 1.6–2.4、判讀是「競價變貴」 |
| S2 | 8/27 整天沒送出 purchase 事件 | S2a 當天追蹤到的事件數 ÷ 後台訂單數（SQL）、S2b Day 09 的判讀（AI） | 比值 ≤ 0.1、判讀是「追蹤碼失效」 |
| S3 | 素材 cr-meta-evg-p1 的點擊率每週衰退 8% | S3a 每週點擊率的變化畫成一條線、換算成每週乘多少（對數線性迴歸，SQL）、S3b Day 09 的判讀（AI） | 倍數 0.88–0.96、判讀是「素材疲乏」 |
| S5 | 四種顧客類型 | S5a Day 11 分群後，每種類型落在「自己是多數」的群的比例，取最低的（ML）、S5b Day 12 高頻買襪客的平均預測 ÷ 其他三種（ML） | S5a ≥ 0.6、S5b ≥ 1.5 |
| S6 | Meta 在路徑開頭、Google 搜尋在最後一步 | S6a Day 08 Meta 第一次接觸功勞 ÷ 最後接觸、S6b Google 搜尋最後 ÷ 第一次（SQL） | 都 ≥ 1.2 |
| S7 | 秋日棉織專案期間專案商品占比上升 | S7a 專案期間的件數占比減專案前三週的占比（SQL） | ≥ 5 個百分點 |
S1a 的範圍是答案值的正負兩成，S3a 容許每週衰退 4% 到 12%（答案是 8%），S2a 容許零星漏報，其他幾題只要求方向對、幅度明顯，門檻寫在 acceptance/criteria.sql，9/24 就 commit 了，成績單 scorecard.sql 讀 martech_dw 裡各篇的結果表算實測值，只有 S5 兩項要用答案表裡的顧客類型算命中比例，其他實測值都只讀 martech_dw，最後一段才 JOIN 判準表判定，每個檔案做什麼、讀不讀答案表都列在 acceptance/README.md。
這裡要老實說一件事，判準 commit 的時候 Day 08 與 Day 09 已經發表，Day 11 與 Day 12 的模型那天也已經跑過一輪、揭曉表看過了，S5a 的門檻寫 0.6 的時候我已經知道 Day 11 的分群過不了，所以這張成績單的判準是看過結果之後才寫死的，它能證明的只有一件事，判準寫下之後沒有再改，criteria.sql 在 git 紀錄裡只有這一筆 commit，算實測值的 scorecard.sql 在 9/25 改過一次，是把 Day 11 分群的輸入固定成 Day 11 文章採用的那一次（揭曉前決定的版本），數字沒有變，真正從頭到尾先寫判準再看結果的是 3.3 的 AI 盲測，盲測的題目與關鍵字在呼叫 Gemini 之前 commit，也沒有對照任何一次 Gemini 的回答調整過，run.sh 的第 17 項檢查會比對判準的 commit 時間和評分時間。
bash acceptance/run.sh 先印出成績單，12 個檢查項目如下，實測值是這次重跑的數字：
| 項目 | 方法 | 判準 | 實測 | 判定 |
|---|---|---|---|---|
| S1a 點擊成本倍數 | SQL | 1.6–2.4 | 2.014 | 找到 |
| S1b flash-lite 的判讀 | AI | 競價變貴 | 競價變貴 | 找到 |
| S2a 追蹤事件 ÷ 後台訂單 | SQL | ≤ 0.1 | 0.0 | 找到 |
| S2b flash-lite 的判讀 | AI | 追蹤碼失效 | 追蹤碼失效 | 找到 |
| S3a 點擊率週倍數 | SQL | 0.88–0.96 | 0.921 | 找到 |
| S3b flash-lite 的判讀 | AI | 素材疲乏 | 素材疲乏 | 找到 |
| S4a 圖片屬性乘數 | — | Day 17 再考 | — | 待考 |
| S5a 分群最低命中比例 | ML | ≥ 0.6 | 0.172 | 沒找到 |
| S5b 高頻買襪客預測倍數 | ML | ≥ 1.5 | 2.322 | 找到 |
| S6a Meta 第一次 ÷ 最後接觸 | SQL | ≥ 1.2 | 1.584 | 找到 |
| S6b Google 搜尋最後 ÷ 第一次 | SQL | ≥ 1.2 | 2.271 | 找到 |
| S7a 專案商品占比上升 | SQL | ≥ 5 百分點 | 12.818 | 找到 |
同一題的檢查項目全部找到才算那一題找到，S1、S2、S3、S6、S7 找到，S5 只找到一半，S4 待考，合成器植入的參數用 SQL 幾乎可以完全還原，點擊成本倍數算出來是 2.014，答案是 2.0，素材點擊率的週倍數 0.921，答案是 0.92，8/27 追蹤到的購買事件是 0 筆、後台訂單 37 筆，這三個數字是今天的 scorecard.sql 照答案表指定的對象與日期直接算的，Day 09 當時是拿每一筆和前幾週的基準比，把這三筆異常挑出來，再交給 flash-lite 判讀原因，三題都選對。
S6 兩個比值來自 Day 08 的歸因，只算首購且回溯完整的訂單、直接流量不算觸點，Meta 的第一次接觸功勞是最後接觸的 1.58 倍，Google 搜尋的最後接觸功勞是第一次接觸的 2.27 倍，S7 是秋日棉織專案商品的件數占比從專案前三週的 53.8% 升到 66.6%，多了 12.8 個百分點。
S5 是四種顧客類型，Day 12 的預測那一半找到了，驗證集裡高頻買襪客的平均預測是其他三種類型的 2.32 倍，Day 11 的分群那一半沒找到，判準要求四種類型各自至少六成落在以自己為多數的群，高頻買襪客與浴巾大量客都是 100%、新手組合客 73%，沉睡客卻只有 17%，518 位觀察滿 30 天的沉睡客散在四群裡，只有洗臉巾那一群（100 人）以沉睡客為多數，裡面的 89 位沉睡客才算命中，這件事 Day 11 揭曉時就知道了，成績單的價值是把它變成一個留得下來的數字，之後改了分群方法可以直接比。
Day 09 的考法等於已經告訴 Gemini「這裡有問題」和「答案在這六個裡面」，今天把兩個提示都拿掉，題目只有一段 6/15 到 9/14 的週報，內容是：
背景只給活動名稱、期間、主打商品和廣告群組的命名規則，然後請它找出值得注意的異常或變化，每一項寫對象、期間、數字、最可能的原因和建議確認的事，只列有把握的，題目共 60 行、9,379 字、8,262 個 Token，兩個模型各問三次，看每次的回答是否一致，回傳格式用 response_schema（回傳欄位的定義）鎖成 JSON 的發現清單，每一項固定有對象、期間、觀察、原因、建議確認五個欄位，thinking_budget 設 0，max_output_tokens 給 4,096，思考 Token 也算在輸出上限裡，關掉才好控制長度與費用。
評分的判準寫在 acceptance/blind_criteria.sql，週報看得到的只有 S1、S2、S3、S7 四題，S5 的顧客類型和 S6 的路徑位置週報裡沒有這種資料，不考，每一題三組關鍵字，一項發現同時命中三組才算找到，例如 S1 要同時出現 meta-trn-prospecting、點擊成本、上升這三類詞，關鍵字判定一定有誤差，六次呼叫的每一項發現原文都留在 blind_findings，report.sql 第六段會全部印出來，下面只摘關鍵的幾段，結果如下，數字是三次裡找到幾次：
| 訊號 | gemini-3.5-flash-lite | gemini-3.6-flash |
|---|---|---|
| S1 點擊成本變兩倍 | 3 | 3 |
| S2 8/27 追蹤事件沒送出 | 3 | 3 |
| S3 素材點擊率逐週衰退 | 3 | 3 |
| S7 專案商品件數上升 | 0 | 1 |
S1、S2、S3 兩個模型六次全中，flash-lite 三次都剛好只列這三項，flash-lite 第一次對 S1 的描述是「平均每次點擊花費從8/3的7.5元飆升至8/10的13.4元，隨後在8/17至9/14期間持續維持在14.8元至15.7元的高點，花費也從每週約1.2萬元暴增至2.3萬至2.6萬元」，3.6-flash 有一次多寫「而點擊率與點擊數並未顯著提升」，這正是植入的樣子，點擊成本翻倍而點擊量沒變，對 S3 兩個模型六次都寫出點擊率從 2.49% 一路滑到 0.77%，3.6-flash 有一次拿同群組的另一支素材當對照，寫出 cr-meta-evg-p2 的點擊率一直維持在 1.40% 到 1.74% 之間，這等於指出問題只在單一素材。
S2 是最值得看的一題，週報裡追蹤事件和後台訂單每一週都相等，只有 8/24 那週是 247 對 284，六次都抓到這個落差，但原因寫得不一樣，3.6-flash 三次都先寫追蹤碼或轉換事件在那週出了問題，並強調其他週兩個數字完全一致，flash-lite 三次都把追蹤碼漏報和其他平常就會有的損耗（跨裝置購買、瀏覽器阻擋追蹤、非直接點擊的轉化）並列，沒有一次指出其他週完全一致，如果平常就有損耗，其他週也該對不上，它沒有去看這一點。
S7 只有 3.6-flash 第一次列出「9/1 秋日棉織專案（autumn-cotton）上線後，日常中筒襪銷量從 8/24 週的 163 件大幅跳升至 8/31 週的 282 件與 9/7 週的 331 件；純棉洗臉毛巾也從 14 件跳升至 35 件與 27 件」，另外五次完全沒有碰第四段的商品件數，這不是判準太嚴，是模型沒有列出來，原因放到 3.4 談。
3.6-flash 有一項沒對到任何一題，它有一次把 9/14 那週兩支 Google 搜尋素材的點擊率下滑列成異常，那一週只有三天資料，另外兩次把 meta-evg-prospecting 整個群組的點擊率下滑另列一項，並說明是被 cr-meta-evg-p1 拖累，關鍵字把它算成 S3，我認為是同一件事的延伸，不算誤報。
把成績單和盲測放在一起看，沒找回來的地方有三種型態。
第一種是首購長得一樣，Day 12 的預測分不出買襪子的沉睡客和高頻買襪客，兩種人的第一筆訂單幾乎相同，差別在之後有沒有回來，只看首購的方法都看不到，Day 11 的分群用了回購次數與間隔，本來有機會，S5a 沒過是因為 Day 11 用指標選出的 4 群照「買什麼」切，沉睡客散在四群裡，同一批特徵改成 5 群時 Day 11 就看過沉睡客會自成一群，用全部顧客訓練的對照模型也一樣（Day 11 只寫了它對新顧客的結果），套今天的判準最低命中比例分別是 0.66（這時最低的變成新手組合客）與 0.67，都會過，所以這半題反映的是群數與訓練範圍的選法，不是資料裡沒有訊號。
第二種是雜訊蓋過訊號，答案表對 S1 寫的是點擊成本翻倍、轉換機率不變、ROAS 理論上腰斬，但這個廣告群組每週只有個位數到十幾筆訂單，Day 09 算出來的追蹤 ROAS 反而從 0.56 升到 0.62，所以判準只考點擊成本，S7 也有類似情況，答案表裡專案商品占比上升有兩個來源，專案素材帶進來的新客權重和商品被選購的權重，成績單只能判斷占比有沒有上升，兩個成因分不開。
第三種是模型沒有列出來，盲測的 S7 資料放在題目最後一段，六次只有一次提到，放在前面的廣告數字卻六次全中，一個可能是題目太長、後面的資料被略過，另一個可能是題目背景已經說了秋日專案主打這三項商品，模型把件數上升當成預期中的事而不是異常，這次的設計分不出是哪一種，Day 24 做 AI 助理的系統化評測時會拆開來測。
AI.COUNT_TOKENS 數 Token 不算 Gemini 的輸入費，遠端模型只是指向 Gemini 的捷徑，建立本身不收費blind_cost.sql 先算出最壞情況，每次都輸出滿 4,096 個 Token 合計約新台幣 3.6 元，實際輸出 flash-lite 每次 508 到 596 個、3.6-flash 777 到 1,226 個，依 Token 數與非 global 端點的單價算出 flash-lite 新台幣 0.41 元、3.6-flash 1.04 元，合計新台幣 1.45 元（遠端模型的 ENDPOINT 只寫模型名稱時 BigQuery 會送到非 global 的端點，單價比 global 高一成，發表時誤用 global 單價算成 1.32 元，9/29 更正），thinking_budget 設 0 是這個數字的關鍵，思考 Token 以輸出計價，Day 09 實測預設會多出四百多個，同一份 9,379 字的題目問了六次，如果問三十次就要 6 元以上，題目重複的部分適合用 Day 10 的快取Day 08 到今天六篇分析加起來，BigQuery 的查詢都在免費額度內，實際付費的是 Day 09 呼叫 Gemini 不到 1 元、Day 10 含開工驗證約 4.5 元、Day 11 與 12 建模型各約 0.4 元，加上今天的 1.45 元，整個分析階段的雲端費用不到新台幣 8 元。
martech_dw 裡有 fct_ad_daily、fct_events、fct_orders、dim_product、mart_attribution、mart_diagnosis、mart_customer_segment、mart_customer_ltv
us.vertex_ai_conn 還在，盲測要透過它呼叫 Geminimartech_gt：Day 11 或 12 載入過就直接用，沒有的話 Cloud Shell 裡要有 Day 05 合成器的答案檔 synthesizer/out/ground_truth/，run.sh 會自動載入gcloud auth list，帳號前面要有星號cd ~/ai-driven-martech-pipeline && git pull && bash acceptance/run.sh
畫面先印出兩個判準檔最後一次 commit 的時間，接著建判準表、印成績單、印盲測題目的前 10 行，然後數 Token 並印出兩個模型各三次的最壞費用，輸入 yes 才會呼叫 Gemini，之後依序是盲測評分、17 項檢查與六段報表，在數 Token 那一步直接按 Enter 就會停下來，成績單已經建好可以先看。
cd ~/ai-driven-martech-pipeline
bash scripts/load_ground_truth.sh
cd acceptance
bq query --nouse_legacy_sql < criteria.sql
bq query --nouse_legacy_sql --format=pretty < scorecard.sql
第二行載入答案表，Day 11 或 12 做過可以略過，criteria.sql 建 12 列判準表，scorecard.sql 讀各篇結果表算實測值，最後印出 3.2 的成績單，兩段都只是查詢，不呼叫 Gemini，scorecard.sql 的 S5a 讀的是 mart_customer_segment_official，那是我把 Day 11 文章採用的那一次分群另存的副本（K-means 每次重建分法可能不同，驗收要固定輸入），你的環境沒有這張表的話先執行 sed 's/mart_customer_segment_official/mart_customer_segment/' scorecard.sql | bq query --nouse_legacy_sql --format=pretty，改讀最近一次的分群結果，走路線 A 的話 run.sh 會自動改讀，S5a 的數字可能和文章不同。
bq query --nouse_legacy_sql < blind_criteria.sql
bq query --nouse_legacy_sql --format=pretty < blind_prompt.sql
bq query --nouse_legacy_sql --format=pretty < blind_cost.sql
blind_prompt.sql 把整季週報寫成題目、存三列相同內容，blind_cost.sql 數題目的 Token 並印出兩個模型各三次的最壞費用，看到數字再決定要不要往下。
bq query --nouse_legacy_sql --format=pretty < blind.sql
bq query --nouse_legacy_sql --format=pretty < blind_score.sql
blind.sql 呼叫 6 次、原始回答存進 blind_result、再拆成一列一項的 blind_findings，blind_score.sql 把每一項發現對照三組關鍵字，印出每個訊號兩個模型各找到幾次。
bq query --nouse_legacy_sql --format=pretty < check.sql
bq query --nouse_legacy_sql --format=pretty --max_rows=100 < report.sql
check.sql 是 15 項流程檢查，run.sh 再補兩項，report.sql 六段分別是成績單、每題判定、盲測命中、每次呼叫的 Token、實際費用、每一項發現的原文與它命中的訊號。
acceptance_scorecard 12 列，11 項有判定、1 項待考，沒有「沒有資料」blind_result 6 列、status 全部是空字串、JSON 都解析得出來、沒有一次用到思考 Tokenrun.sh 的 17 項檢查全部通過，其中一項確認題目與呼叫 Gemini 的 SQL 沒有讀 martech_gt，另一項確認判準檔的 commit 時間早於評分時間bq rm -f -t martech_dw.blind_prompt
bq rm -f -t martech_dw.blind_result
bq rm -f -t martech_dw.blind_findings
兩張成績單很小，建議留著當紀錄，之後改了分析方法重跑 run.sh 就能直接比，遠端模型 gemini_flash_lite 與 gemini_flash 只是指向 Gemini 的捷徑，放著不收費，Day 11 的分群每次重建結果可能不同，mart_customer_segment_official 是 Day 11 文章採用的那一次分群另存的副本（做法見 5.3 步驟 1），S1b 到 S3b 讀的是 Day 09 的 mart_diagnosis，Day 09 的 run.sh 重跑一次 Gemini 就會重建，判讀如果變了這三項會跟著變。
run.sh 用 grep 確認題目與呼叫 Gemini 的 SQL 沒有出現 martech_gt，Day 11、12 的 run.sh 對特徵與模型也做同樣的檢查，這比靠自己記得不要讀答案可靠今天把 Day 05 藏進合成資料的訊號當成考卷，判準先寫死、答案表和分析分開放，Day 08 到 Day 12 的結果整理成一張成績單，六題找回五題半，用 SQL 算的三題幾乎把植入的參數原封不動找回來，沉睡客那半題沒過反映的是 Day 11 選群數與訓練範圍的方式，資料裡的訊號其實都存在。
回到篇名，把整季週報一次交給 Gemini、不給任何提示，點擊成本翻倍、追蹤碼失效、素材疲乏三題兩個模型六次全中，3.6-flash 有時還會拿其他週和其他素材當對照，商品占比那一題放在題目最後一段，六次只有一次被列出來，AI 找得回幾個，答案是四題裡有三題每次都找回來，第四題是沒讀到還是判斷不算異常，這次還分不出來，這些都是要先把答案藏好才量得出來的事。
明日預告：Day 14《點擊率看不出來的秘密，全都藏在廣告圖裡》，Day 08 到今天分析的都是數字，廣告報表只記得 creative_id，記不得圖長什麼樣子，明天把素材圖放進 Cloud Storage、在 BigQuery 建物件表，第一次讓 Gemini 直接看圖，看它能不能把圖片變成查得到的資料。
iThome鐵人賽
看影片追技術