1. 先說清楚，為什麼改用 SQL

Day 22 我把 Gemini 的議題分類結果送進 BigQuery，並分開檢查生成、內容驗證與寫入狀態。接著我想知道：如果回報原文已經在表格裡，能不能直接用 SQL 分類，減少匯出、逐則呼叫與重新載入的步驟？

這次操作的核心，是先對單則文字呼叫 AI.GENERATE，再將相同方式套用到表格欄位，指定輸出格式並保存結果。設備回報則延續前面的設計情境，尚未完成真實設備資料驗證。

對我而言，改用 SQL 的理由是讓分析接近既有資料與查詢流程。它是否更快、更省錢，或分類得更準，仍要另外比較；不能因為少寫了 Python 迴圈，就把這些優點一起算進去。

2. 先試一則，再核對身分、位置與模型

我會先取出 N201：「溫度顯示已恢復，但告警一直重複，值班時很困擾。」提示要求仍沿用 Day 22：從「告警處理、操作介面、校正資訊、其他／待判」選出主要議題，說明理由並摘錄原文依據。

呼叫前，我先核對讀取資料、建立查詢工作、呼叫模型及保存結果所需的權限。若採用 connection，還要確認它的服務帳戶權限，以及 connection 與資料集的位置；官方操作文件要求兩者位於相同位置。

AI.GENERATE 也支援不指定 connection、使用終端使用者憑證的方式。模型端點則應明確選定並留下紀錄，因為省略端點時，函式會使用官方當時指定的預設模型。

我在編輯器中能執行，不代表排程使用的身分也能執行。換成自動工作前，必須用實際執行身分再次驗收。

3. 用 output_schema 接欄位，也保留 status

Day 22 在程式裡接收 JSON；這一步改用 output_schema，指定需要的 SQL 欄位：

官方文件說明，AI.GENERATE 每列回傳一個 STRUCT；指定輸出 Schema 後，自訂欄位會取代原本的 result，另外保留 full_response 與 status。成功時 status 為空字串，因此不能只看 SQL 工作完成，就認定每列都分析成功。

即使 N201 回傳「告警處理」，我還會檢查理由是否只根據本文，以及依據是否確實出現在原文。若它寫成「感測器故障造成告警」，就加入了人員沒有提供的原因。
欄位接得進來，與內容值得採用，是兩次檢查。 呼叫失敗或缺值要另列；「其他／待判」則是有效回應中的分類，不能拿來包住技術錯誤。

4. 生成結果先存下來，統計再讀這張表

把呼叫套用到整批之前，我會先選出本次需要分析的回報，固定文字版本與分析設定版本，再將輸出寫入結果表。
假設 N201、N203 已取得有效結果，N202 尚未成功，補跑時就針對符合重試條件的 N202。若提示或模型已改版，則建立新的分析版本，不能把新版結果直接混入舊版統計。

結果表保留回報編號、文字版本、分析設定版本、生成時間、輸出欄位與狀態；每次嘗試另外留下紀錄。這延續 Day 18 的原則：重試同一份輸入，和重新分析新版輸入，要分得出來。

後續計算議題占比時，我會查詢已保存、通過驗證的結果表，而不是讓每次開啟報表都重新呼叫 Gemini。否則，同一份原文可能得到不同分類，也難以追問上次報表究竟採用了哪一份結果。

5. Gemini 寫出的 SQL，逐項核對再執行

使用 Gemini 產生 SQL 時，我會核對函式名稱、參數、輸入欄位、目的表與寫入方式，尤其留意是否覆寫既有結果，以及是否讓已完成的回報再次送去生成。

看起來相近的函式，也不能只替換名稱。官方比較指出，AI.GENERATE 是純量函式，可直接用於查詢；AI.GENERATE_TEXT 是資料表值函式，使用前需要建立 remote model。兩者的呼叫與輸出方式不同。

因此，Gemini 若改用另一個函式，我會重新檢查它需要的資源與結果欄位。原本想接 topic、reason、evidence，卻拿到另一種回應結構，後面的 SQL 即使能修改到執行成功，也可能已經偏離原先的處理流程。

6. 兩條路徑結果不同，先查條件再談能力

如果 Python 路徑把 N201 分成「告警處理」，SQL 路徑卻分成「操作介面」，我不會立刻判定其中一條比較差。

我會先確認兩邊是否收到完整的相同文字，使用相同模型、提示、類別定義與生成設定。SQL 裡若少了「以人員主要困擾為準」的要求，模型就可能更重視前半句的溫度顯示。

條件核對後，再用未參與提示調整的人工標記資料比較。N201 的狀態改善與值班困擾同時存在；N203 詢問校正時間，也不代表設備尚未校正。驗收要看分類是否符合定義，理由有沒有越過原文。

即使將情緒與議題放在同一次呼叫，也要分別評估。一次取得兩個欄位，不能證明兩項判斷都更可靠。

7. 把快取、資料處理與模型用量分開看

SQL 改得更簡潔後，成本也不能只看掃描了多少資料。官方文件列出 BigQuery 資料處理與模型呼叫兩項費用；生成式 AI 工作資訊還可查看輸入、輸出及適用的思考 token 用量。

快取則要分清楚：BigQuery 的查詢結果快取，是重用先前的查詢結果；模型的輸入內容快取，是另一回事。官方文件說明，查詢快取有適用條件，可從工作資訊的 cacheHit 確認是否命中，不能只憑 SQL 文字相同就宣稱這次沒有重新計算。

若要比較新的生成結果，我會關閉查詢結果快取、確認工作資訊並保存本次輸出；日常統計則讀取已驗收的結果表。

走到這裡，SQL 讓我減少搬運資料的步驟，卻仍須為每列的狀態、版本與判斷依據負責。下一步若要回答「告警為什麼一直重複」，分類結果只能指出待查議題；我還要把設備事件與處理紀錄帶進來，讓回答有可核對的事實。

參考資料

1. The AI.GENERATE function
2. Generate text with the AI.GENERATE function
3. Choose a text generation function
4. Use cached query results
5. Generative AI overview