1. 分類指出問題，設備紀錄才讓我往下查

Day 23 我在 BigQuery 裡呼叫 Gemini，將回報分成約定的議題並保存結果。但 N201 被分成「告警處理」之後，仍有一個問題沒有回答：人員說告警一直重複，設備紀錄是否也呈現相同情況？

Day 19 我曾提出把文字與設備事件一起查。這一步，我想將查證過程整理成可重複執行的流程：先準備背景資料測試問答，再用 SQL 取得相關紀錄，將查詢結果放進提示，檢查回答是否遵守資料範圍。

以下延續設備回報的設計情境，尚未完成真實設備資料驗證。我希望 Gemini 協助閱讀與整理證據，設備是否故障、應如何處置，仍要由紀錄與負責人確認。

2. 先決定要查哪台設備、哪一段時間

N201 的本文是「溫度顯示已恢復，但告警一直重複，值班時很困擾。」文字沒有設備編號，也沒有完整時間，不能只把這句話送給模型，就期待它知道該查哪裡。

我會先從回報欄位取得設備識別、回報時間與班別，再確認要查的區間。若缺少設備識別，就先請人補充；「一直重複」也需要明確範圍，不能自行理解成整個月。

查詢由程式使用已確認的參數執行，只讀取使用者有權查看的紀錄。結果除了事件時間，也保留資料更新時間與查詢範圍；若系統尚未收到補送資料，回答就需要說明資料截至何時。

這呼應 Day 13～16：設備歸屬、事件時間與去重規則若沒有先處理好，模型讀到的背景資料就可能已經失真。

3. SQL 負責整理事實，Gemini 負責說清楚

假設 N201 對應設備 Q17，查詢區間內取得以下已去重紀錄：

這裡要先分清楚：E503 是另一次觸發事件，還是來源重送 E501？我會依事件識別與來源定義判斷，不能只因告警名稱相同，就全部算成重複資料。

事件數、先後順序與間隔由 SQL 計算，Gemini 接收的是整理好的事實與必要明細。若還要知道值班人員收到幾次通知，就得另查通知紀錄；告警觸發次數與通知次數不能直接畫上等號。

Google Cloud 的提示文件說明，背景資訊可以用文字或表格提供，讓模型在生成時參照。我的做法是先由查詢取得背景資料，再將它連同問題送出，不讓模型自行補出缺少的事件。

4. 要求回答附上依據，也逐句核對

對上面的紀錄，我期待的回答可以是：
在本次查詢區間內，Q17 的告警曾恢復後再次觸發，依據為 E501、E502、E503。這支持「告警再次出現」的描述；目前提供的紀錄不足以確認觸發原因，也無法判定操作人員收到多少次通知。

這段是我設定的驗收目標，並非已取得的模型輸出。

Google Cloud 將 grounding 說明為讓模型輸出連結到可驗證的資訊來源，以降低憑空生成內容的機會。這提醒我，回答的價值不只在文字順暢，還在於結論是否有可核對的來源。

我會要求模型使用提供的事件識別，程式再檢查這些識別是否真的存在於本次資料中，人工則核對紀錄是否支持那句結論。列出 E503，卻說它證明感測器損壞，仍是錯誤回答。

這種手動組合查詢結果與提示的方式，也不能直接寫成已啟用官方 grounding 服務或自動產生來源連結。

5. 查不到紀錄時，不讓回答順著錯誤前提走

N203 問的是「請確認這台設備最近一次校正的時間。」假如查詢沒有取得校正紀錄，我希望回答先說：
目前提供的資料未找到校正紀錄，無法確認最近一次校正時間。需要再核對校正管理系統或由負責人補充。

「沒有找到」可能是資料尚未匯入、查詢範圍不足，或使用者無權查看，不能改寫成「這台設備從未校正」。

如果問題進一步變成「這台設備一直沒校正，為什麼還能使用？」，模型也不能直接接受這個前提。我會在系統指示裡要求：只依提供資料回答；資料不足時指出缺項；問題前提與紀錄不符時先澄清；將已確認事實與待查事項分開。

官方文件支持用系統指示設定行為、格式與任務規則，但也指出它不能完全防止越獄或資訊洩漏。因此權限檢查必須在取資料時完成，不能只靠一句「不得透露」來保護資料。

6. 把「找對資料」與「說對意思」分開驗收

回答錯誤時，我會先拆成兩個檢查點。

第一個是資料取得：設備是否選對？時間是否正確？有沒有漏掉恢復事件、混入其他設備，或把重送資料算成新事件？

第二個是回答解讀：模型是否忠於紀錄？有沒有補出故障原因？是否在資料不足時保留不確定性？N202 說更新後操作順暢，也不能被延伸成設備長期可靠。

Google Cloud 的評估文件提供 GROUNDING，用來檢查回答與給定來源文字的事實一致性；也能評估是否遵守指示。我借用這些評估原則，先訂出可觀察的驗收條件，並不代表本篇已建立自動評估服務。

驗收資料會包含紀錄完整、資料缺漏與問題前提錯誤等情況，另保存查詢條件、背景資料、提示版本、模型與回答。這樣才能分辨問題出在查詢，還是生成。

7. 先完成可追查的問答，再評估是否擴大檢索

目前要找的是明確設備與時間範圍內的事件，SQL 可以直接篩選、排序與彙總。我會先把這條路徑做好，確認回答能追溯到當時提供的紀錄。

若後續還要查維修手冊、交班紀錄與大量處理文件，再評估文件檢索。官方 RAG Engine 文件將流程拆成資料匯入、轉換、嵌入、建立索引、檢索與生成；檢索取得的資料會成為模型回答的背景。這表示擴大檢索時，也增加了資料更新、索引維護與檢索品質的責任。

對 N201，我現在希望交付的是一份能回答「查了什麼、紀錄支持什麼、還缺什麼」的說明。當它要進一步成為給操作人員的回覆草稿，下一步還須檢查措辭、承諾與審核責任。

參考來源

1. Grounding overview
2. RAG Engine overview
3. Define your evaluation metrics
4. Introduction to prompting
5. Use system instructions