1. 某類回報最多，不代表設備問題最嚴重

Day 28 先處理了平均與比例的分母。接下來，我想把 Gemini 對操作回報的情緒判讀與內容分類整理成圖表，讓值班人員知道哪些內容值得優先查看。但「告警處理」回報較多，究竟代表設備的告警問題多，還是這批回報較常提到告警？這兩種解讀不能混在一起。

我沿用告警處理、操作介面、校正資訊、其他／待判四個回報類別，將情緒與內容分類分開呈現。情緒描述文字表達，回報類別說明文字主要在談什麼，設備狀態則需要事件與其他檢查證據；三者不能互相代替。

在 Data Studio（原 Looker Studio），我規劃新增回報分析來源與頁面，保留原有設備事件來源。每張圖各自核對來源，以情緒或回報類別作為分組欄位，計算回報數，分類圖再按數量遞減排序。以下仍是設計情境，不預先指定 N201～N203 的實測分類，也不宣稱圖形已完成驗收。

2. 圖表先讀選定結果，不重新呼叫 Gemini

若只是為了畫圖，又讓 Gemini 重新分析一次回報，圖表就可能混入新的輸出。我因此規劃讓報表讀取已保存的分析結果，另以 BigQuery 邏輯檢視整理可供統計的資料。

官方支援以 CREATE VIEW 搭配查詢建立邏輯檢視。我可以把選定文字版本、分析設定版本與結果的規則寫在查詢裡，但檢視本身不會替我決定哪個版本適合使用。

重試紀錄也要先處理。對同一組回報編號、文字版本與分析設定版本，我需要明確指定採用哪次執行結果，保留其他嘗試供追查。BigQuery 的 QUALIFY 可以篩選視窗函式的結果，但分組、排序及同時間紀錄的判定，仍是我要設計的規則。

我不會因為最新嘗試失敗，就悄悄改採舊結果。若允許沿用先前結果，必須另訂規則並標示。最後仍分開確認呼叫成功、內容有效與入表成功，避免把「有一筆紀錄」當成「有一筆可用分類」。

3. 有效分類之外，我還保留未完成數

分類圖的分母，規劃只包含選定版本中內容有效且成功入表的回報。這樣可以看清各類有效結果的數量與比例，卻也可能讓尚未完成的資料消失。

因此，我會從回報清單出發，核對每則回報是否有可採用結果，再另外顯示未分析、呼叫失敗、待驗證或驗證失敗等狀態。這些數量不能直接把所有嘗試相加，而要依選定版本與目前處理狀態計數；同一次分析的重試歷史另外保留。

「其他／待判」仍是業務分類，用來表示內容無法歸入既有類別或需要人工判斷。API 失敗、缺少必要欄位或標籤不合法，都不能塞進這一類。

若要使用 Record Count，來源必須先整理成每則回報的一筆選定結果。我也會在圖旁交代有效回報數、未完成數與採用版本，避免使用者把有效結果的比例，誤當成全部回報的比例。

4. 各類數量算對，不代表 Gemini 分類正確

總數與各類數量對得上，只能驗收統計。即使 Gemini 與人工標準得到相同的各類數量，也可能有回報互相判錯，讓總分布維持不變。

所以，品質檢查要回到同一則回報、同一文字版本，逐筆比較 Gemini 結果與人工標準。我會固定驗收題、分類定義及評分設定，記錄錯在哪一類，以及人工標準是否也有模糊之處，不能只看一張比例圖就說分類正確。

官方評估文件提供依任務制定評分準則，以及保存、重用準則來比較輸出的做法。我借用這個思路，延續 Day 25 對指令遵循、證據支持與未授權承諾的檢查；這些是我的驗收要求，不代表本次已啟用官方評估服務。

內容分類與回覆草稿也要分別驗收。即使 Gemini 正確將回報歸為「告警處理」，它寫出的回覆仍可能在維修人員尚未確認時，就承諾「明天下午前完成修復」。因此，自動評分可以協助比較結果，但回覆是否包含未經確認或授權的承諾，仍需要人工檢查。

5. 摘要之下，我保留可辨認版本的明細

當使用者看到某類回報數量較多，我希望他能查到是哪幾則回報，而不只停在長條圖。

我規劃明細表保留回報編號、文字版本、分析設定版本、情緒、回報類別與必要的審核狀態；涉及草稿時，再辨認草稿版本。原文與遮罩文本依存取需要分開，不能因為加入明細，就把完整原文提供給所有使用者。

官方表格會依所有維度的組合分組，指標則依設定彙總。如果只放情緒與回報類別，不放回報編號與版本，畫面可能把不同結果合成一列。表格看起來像逐筆清單，不代表它真的保留逐筆身分。

我的驗收方式是用識別欄位逐筆對照 SQL，並核對分頁、排序與顯示範圍。只看到前幾列，不能當成全部資料；設定正確，也要等實際圖形與數值對照完成，才能說報表通過驗收。

6. 有設備關聯，也不能直接把兩張明細硬接

沿用既有設計，N201 對應 Q17，但 N202、N203 沒有可靠設備關聯，我不能替它們補上 Q17，也不能按列號或出現順序配對。

即使設備鍵可靠，一台設備仍可能有多則回報與多筆事件。只按設備連接，會讓每則回報配到多筆事件；若直接數連接後的列，回報數與事件數都可能被放大。SQL 的 JOIN 依條件配對資料列，CROSS JOIN 更會產生兩邊所有列的組合。

Data Studio 的混合來源也不是直接照搬原始明細：官方說明指出，各表會先依選定維度分組及彙總，再進行連接。我需要同時確認連接前每列代表什麼，以及連接後是否重複計數。

目前我優先讓事件與回報各自呈現。未來若要合併摘要，先確定共同設備、時間範圍與計數方式，各自彙總成可核對的資料，再比較連接前後數量。即使兩種數量同時增加，也不能直接推論因果。

7. 我讓使用者追查問題，而不是直接下診斷

這張報表的用途，是指出哪些回報需要追查，並提供回到文字、版本與事件紀錄的路徑。

N201 說「溫度顯示已恢復，但告警一直重複」，即使被歸為告警處理，也不能證明感測器故障。Q17 的 E501 觸發、E502 恢復與 E503 再次觸發，提供的是設計中的事件脈絡；事件數也不等於通知數。

N202 的肯定回饋不能證明設備長期可靠。N203 詢問校正時間，若查不到紀錄，下一步是確認資料範圍與紀錄來源，不能寫成設備從未校正。

我會讓圖表標明採用版本、有效結果與未完成資料，讓每個觀察都能追查依據。接下來要處理的是交付：誰可以看這些摘要與明細？資料多久更新？來源、分類設定或報表改動時，又由誰接手核對？

參考資料

1. Create logical views
2. Define your evaluation metrics
3. Table reference
4. How blends work in Data Studio
5. Query syntax