1. 資料能順利寫入，仍不代表我理解現場

Day 16 我從另一條寫入路徑，思考什麼時候需要 Dataflow，以及增加管道後要承擔哪些責任。接下來，我想把注意力移到資料內容：即使設備事件已能寫入 BigQuery，單看溫度與告警紀錄，是否足以理解現場發生了什麼？

假設操作人員回報：「溫度顯示已恢復，但告警一直重複，值班時很困擾。」這段文字同時包含設備狀況、系統行為與使用感受。讀數可以讓我確認溫度變化，卻不能直接告訴我重複告警造成多少困擾。

我因此開始思考如何把文字回報納入分析。設備情境是我延伸設計的方向；這次先練習的是 Cloud Natural Language API 的呼叫與回應閱讀，尚未完成真實設備回報的驗證。

2. 我先確認一則文字能完整送進 API

操作時，我先確認專案已啟用 Natural Language API，再從 Cloud Shell 使用 gcloud ml language analyze-sentiment 分析文字。接著改用 REST 請求，查看端點、認證標頭、JSON 輸入與回應之間的關係。

Google Cloud 文件說明，情感分析透過 analyzeSentiment 執行，每份文件需提交個別請求。這讓我先把驗收範圍縮小：確認一段文字能完整送出，成功取得回應，再考慮批次處理。

我也會核對實際送出的中文、引號與標點。如果使用 AI 協助產生指令，就檢查它是否改寫原文、換成其他語言，或選用了不同端點。指令能執行，只代表請求成立；送出的內容仍要由我確認。

3. 同一次回應，我分開看整段與逐句結果

收到 JSON 後，我先看 documentSentiment，再看 sentences。前者提供整段文字的情感結果，後者保留各句文字與對應結果。v2 的回應也包含 languageCode 和 languageSupported，讓我確認語言資訊及是否屬於官方支援範圍。

回到操作人員的回報，「溫度顯示已恢復」描述改善，「值班時很困擾」表達負面感受。整段結果可能把不同傾向合在一起，因此我不能只拿一個數字，就認定整段話沒有問題。

但逐句結果也不是自動完成的問題診斷。API 如何切句，要查看實際回應；一句話若同時包含改善與抱怨，仍可能需要人工閱讀。我會先保留完整回應，避免過早只留下兩個分數，失去後續檢查的線索。

4. 情緒方向和強度，都不能代替故障嚴重度

官方文件指出，score 介於 −1 與 +1，表示文字的整體情緒傾向；magnitude 表示正面與負面情緒的整體強度。整段文字的 magnitude 未依長度正規化，較長的文字可能具有較大的值。它也不是模型對答案有多確定的信心值。

這個差別會直接影響使用方式。一段詳細描述處理經過的回報，可能比一句簡短抱怨具有更大的 magnitude，卻不代表設備故障更嚴重。反過來，「設備已停機，等待檢修」語氣平淡，也可能描述需要立即處理的狀況。

因此，我會把設備狀態與文字情緒分開判斷。停機、讀數超限與告警是否持續，要查設備事件；操作人員是否困擾，則可由文字分析協助整理。兩種資訊可以一起閱讀，但不能互相取代。

5. 我先確認功能與語言，再比較版本結果

我原本容易以為，服務既然支援中文，裡面的功能就都能處理中文。查閱官方語言表後，我才確認支援範圍會隨功能改變：繁體中文列在情感分析與實體分析中，目前實體情感分析則列出英文、日文與西班牙文。

這表示分析中文設備回報時，不能直接假設 API 能替每個設備或零件給出情緒判斷。先确认需要回答什麼問題，再核對該功能的語言支援，才能避免把不同能力混在一起。

比較 CLI 與 REST 的結果時，我也會先記錄實際使用的 API 版本、輸入內容及回應欄位。一次分數不同，還不足以推論某版本必然具有固定的數值關係；API 版本也不應直接當成可永久固定的模型版本。若日後更換呼叫方式，我需要重新驗收，而不是沿用舊門檻就認為結果可比。

6. 手動呼叫成功之後，還要決定正式工作由誰執行

Cloud Shell 的互動操作，讓我可以先完成一次呼叫。但若未來每天處理操作人員回報，就要決定程式在哪裡執行、使用哪個身分，以及如何取得必要權限。

Google Cloud 的用戶端認證文件介紹 Application Default Credentials（ADC）：用戶端程式可以透過這套機制，依執行環境取得憑證。這讓我理解，正式工作的認證設計，應配合執行環境，而不是長期靠人工複製存取權杖。

我會分開驗收兩件事：目前登入的身分能否完成測試，以及正式執行身分能否讀取輸入、呼叫服務並保存結果。手動成功不能直接證明排程後也會成功；換成自動執行時，仍須確認身分與權限。

7. 我留下的是可追查的分析結果

如果未來有人問「這則回報為什麼被列為負面」，我希望查得到的不只是一個分數，還包括回報識別資訊、實際送出的文字、API 版本、分析時間與原始回應。若文字曾經過遮罩或其他處理，也應記錄處理方式。

設備識別資訊則負責連接文字與讀數。時間也要分清楚：人員回報時間、回報所描述的事件時間，以及 API 分析時間，未必相同。這延續了前面對來源、時間與資料品質的要求。

走到這裡，我開始把文字分析理解為一份需要驗收的衍生資料。它能協助整理使用感受，仍要保留讓人追問的依據。下一步處理整批回報時，我要確認的，就是每一則文字是否完整送出，以及成功、失敗與尚未處理的結果能否被辨認。

參考資料

1. Google Cloud, Analyzing Sentiment
2. Google Cloud, Natural Language API Basics
3. Google Cloud, Language Support
4. Google Cloud, Method: documents.analyzeSentiment — v2
5. Google Cloud, Authenticate with client libraries