這是個沒有標準答案的取捨

Day 8 設計結構化日誌時提到「不建議把完整 Prompt 與回應塞進日誌」，但實務上團隊經常會問：可是不記錄的話，出問題時要怎麼重現？這篇要處理這個取捨，因為兩邊的訴求都合理。

兩邊的理由都成立

支持記錄的理由：LLM 應用有個特性是同樣的輸入不保證同樣的輸出，如果沒有記錄當時的完整輸入與參數，事後幾乎無法重現問題。對除錯來說，Prompt 與回應內容是最有價值的資訊。

反對記錄的理由：Prompt 與回應可能包含使用者的個資、企業機密、或其他敏感內容。一旦寫進日誌系統，這些內容就散布到一個通常存取控制較寬鬆、保存期較長、且可能被大量人員查詢的地方——等於為了除錯方便，開了一個資料外洩的側門。

實務上的中間路線

分級處理，而不是全有全無：

做法一：預設不記錄完整內容，只記錄摘要與特徵。 例如記錄 Prompt 的長度、Token 數、意圖分類，但不記錄原文。多數的效能與行為分析用這些就夠。

做法二：完整內容走獨立的儲存路徑，套用更嚴格的存取控制。 Google Cloud 官方對多模態的 Prompt 與回應有一種設計是不直接附在 trace 資料裡，而是存放在獨立的 Cloud Storage bucket，這樣做的好處是可以對這個 bucket 單獨套用更嚴格的 IAM 權限與保存期限。

做法三：寫入前先做敏感資料處理。 在日誌寫入管線加上遮罩處理，把個資類型的內容遮蔽後再存。這呼應團隊 GCP Security 系列 Day 15 談的 Sensitive Data Protection——那篇強調「推論輸出寫入 log 前也要遮罩，別只顧輸入端」，正是這個場景。

做法四：利用 OpenTelemetry 的事件機制。 Day 5 提過，GenAI 語意慣例建議把內容放在 Span 的事件而非屬性，因為事件可以在 Collector 層級被過濾丟棄，不需要改應用程式碼就能控制是否保留。

一個實務建議：讓「保留多久」跟「保留什麼」分開決策

即使決定要記錄完整內容，也不代表要跟其他日誌保存一樣久。完整內容可以設計成短期保存（例如 7 天，足夠處理大部分即時的除錯需求），過期自動刪除；而結構化的欄位摘要則依 Day 10 的分級策略保存較久。

這篇的檢查清單

• [ ] 是否已明確決定 Prompt/Completion 的記錄政策，而非默默地全記或全不記？
• [ ] 若記錄完整內容，是否有獨立的存取控制與較短的保存期？
• [ ] 日誌寫入前是否有敏感資料遮罩機制？