系列：30 天用 Google AI 打造臺灣防災速報 App（Day 14/30）

第二週完成 AI 核心的四項功能：速報摘要、警報分級、問答、多語速報；其中問答拆成工具查詢與知識庫兩個部分。這一篇整理它們目前的狀態、這週最重要的一條教訓，以及用實測的 token（模型計算文字量的單位，一個中文字大約一到兩個 token）數算出來的費用。

四項功能怎麼接在一起

圖上是預定的串接方式。一則新示警進來，先分級，決定要不要推播、標什麼顏色；要推的話產生速報，再寫成多語版本。使用者的問題先分辨類型：問即時的示警或地震報告，走工具查詢；問防災知識，走知識庫。目前這幾段各自驗證過，還沒有接在一起，「推不推播」的規則和「分辨問題類型」的規則也還沒寫。四項功能都在同一個原則下：模型只讀規則和資料，判斷由規則決定。

各功能做到哪裡

問答拆成工具查詢和知識庫兩列，所以四項功能有五列。「主要的缺口」只列重點，各篇文末的清單更完整。

每一項都有程式和實測紀錄，也都有明確寫下來的缺口。第三週上線時，這張表加上各篇文末的清單就是待辦事項。

這週最重要的教訓：規則裡出現的文字，模型會當成該有的內容

同一件事這週發生了四次：

1. Day 8 的速報規則寫「若報告中有『無海嘯威脅』等官方判定，必須保留」。報告裡完全沒有提到海嘯，模型十次有十次自己寫出「無海嘯威脅」。
2. Day 13 的規則寫「原文開頭如果有括號標記（例如「（測試文字）」），每一種語言都要保留」。原本沒有標記的速報，三種語言都被加上了一個。
3. Day 13 的術語表有「中央氣象署＝Central Weather Administration」這一條。原文沒有提到氣象署，三種語言的結尾都多了一句「中央氣象署發布」。
4. Day 12 的規則寫「查無資料時建議撥 119」。情緒類的問題，模型有一次把 119 用在回答的結尾。

四次的修法不同，原則一樣：不要讓和這一次無關的固定文字出現在模型看得到的規則或資料裡。Day 8 刪掉那條規則，官方判定改由程式附加；Day 13 的標記改由程式加上；Day 13 的術語表只附原文用得到的條目；Day 12 則是把情緒類問題的求助電話另外寫清楚，不讓它和查無資料的規則混在一起。

另外兩條也是這週實測出來的：

• 情緒類的問題不能只靠相似度排序。 Day 12 一般的問題仍然用相似度找、用門檻取捨；但情緒類的問題，具體的自我照顧那一塊只靠相似度排第 6，抽象的口訣排第 1，改由規則固定用哪幾塊、什麼順序之後才對。
• 要確認資料真的送進了模型。 Day 12 有一輪，規則選出的三塊資料被後面的門檻過濾掉兩塊，模型只拿到一塊，回答卻寫出了另外兩塊的內容，因為那些字在規則裡。回答看起來完全正確，直到檢查「資料來源」那一行只列出一塊才發現。

費用：用實測的 token 數算

9/24 把五項功能各呼叫一次，讀 API 回傳的 usage_metadata（每次呼叫的用量）：

單價依 Google 官方定價頁（2026-09-23 更新）的標準付費層：gemini-3.1-flash-lite 每百萬輸入 token 0.25 美元、輸出 1.50 美元。這五種呼叫每一次都不到 0.0005 美元。

用兩種情境估算：

• 平常日：每小時 5 則新示警，每則都做摘要、分級、多語（實際上有官方等級的示警不會呼叫分級模型，這裡算的是上限）；問答每天 200 次，工具查詢和知識庫各半。合計每天約 0.18 美元，每月約 5 美元。
• 颱風天：示警和問答都是平常的十倍，每天約 1.8 美元。

防災速報的模型呼叫都很短，一次幾百個 token。還沒算進去的費用有 Cloud Functions 每 10 分鐘的執行和 Firestore 的讀寫，小流量可能落在免費額度內，第三週上線後再用帳單核對。

另外兩項也沒有算：知識庫建向量是一次性的（29 塊，可以忽略）；每一次知識庫問答要把問題算成向量（gemini-embedding-2 每百萬 token 0.20 美元，一個問題約十幾個 token，可以忽略）。

這週沒做到的事

• 原本計畫收錄日本的防災資料，沒有做，先把臺灣官方的資料做好。
• Day 10、12、13 的測試問題或案例都只有三個到九個，只能確認程式可以執行、規則有作用，不算品質評估。正式的評估集之後再做。
• 上面「主要的缺口」那一欄，每一項都是實測後留下的，第三週要一邊上線一邊補。

下週預告

第三週上線：把這兩週在本機上執行的程式搬上 Cloud Functions 與 Firestore，然後做 App 的畫面。明天 Day 15 從 Firestore 的資料模型開始。