AO2 FIELD GUIDE · N059 · AI 問答與 RAG 應用
聊天機器人紀錄設計先從需要回答的改善問題出發，串起請求、來源、流程版本與結果，附最小事件欄位表及紀錄驗收表。分清營運指標和錯誤追查，避免大量保存完整對話卻仍無法還原問題。
聊天機器人每天產生很多訊息，出了問題卻只剩「回答不對」的截圖。紀錄不是越多越好，而是要能連回同一次請求、當時版本及實際來源，同時避免把不需要的客戶內容長期收進資料庫。
聊天機器人紀錄設計，先列要查清楚的問題
先問上線後要回答什麼：誰在什麼範圍遇到失敗、哪段變慢、哪個資料版本造成錯用，以及是否需要補問或人工接手。不同問題需要不同欄位。總使用量可看需求變化，卻不能單獨解釋答案為何錯；完整聊天文字也不會自動告訴你，當次模型實際拿到了哪些片段。
先決定要追查的問題，再決定留哪些紀錄。本篇交付欄位與保存責任，不重做錯誤定位指南。若目前沒有檢索與上下文紀錄，應明確標為不可觀測，不用最後答案反推當時流程。欄位中的空值、未蒐集與不適用也應分開，避免報表把缺資料誤當成沒有事件。
白話例子：包裹出問題，需要同一張追蹤單
假想產品問答回覆遺失重要限制，客服只有一張聊天截圖。像包裹沒送到，若只有「有人寄了一箱」的描述，還不知道在哪站出問題；有同一追蹤識別、站點與時間，才可把經過連起來。問答也需要把請求、檢索、上下文與輸出串成一次路徑。
追蹤單對應請求識別，站點對應流程階段，包裹內容不必全印在每一站的紀錄上。這個假想比喻不代表軟體流程一定線性，也不表示識別碼就能證明資料匿名。系統可能有重試、分支或人工接手，應額外記相互關係；不必要的原始輸入可不留，必要細節則按用途分級存取。
建立最小事件契約，讓欄位可對得起來
先有請求識別、時間、流程版本、結果狀態與階段識別，再依用途補來源 ID、修訂版、索引發布、延遲及用量。來源引用與上下文可以用受控識別連接，詳細文字留在適合的受限位置，不一定複製進所有報表。欄位要寫型別、單位、產生時點及空值意義，避免不同元件把秒和毫秒混用。
下列格式為假想事件示例，待量測字樣只是教學占位，正式事件應使用約定的數值型別或明確缺值。request_id 要能串起階段，卻不應直接使用可辨認客戶的資料。是否保留查詢原文、模型輸入與輸出，需要用途和存取安排，不能把設定名稱叫去識別就預設已沒有識別風險。
| 欄位組 | 內容與限制 | 支援用途 |
|---|---|---|
| 請求與階段 | 識別、時間、父子關係 | 串起重試與流程 |
| 資料與流程版 | 來源、索引與組裝版本 | 辨認當時依據 |
| 結果與接手 | 完成、補問、失敗或轉接 | 區分不同結果 |
| 延遲與用量 | 單位、量測點與缺值 | 解讀速度及成本 |
| 存取與保存 | 用途、角色與清理責任 | 限制不必要的暴露 |
去識別的事件示例
以下為假想資料格式，不是可直接連到正式系統的設定。
{
"request_id": "demo-021",
"test_case": "Q-008",
"role_class": "public",
"source_ids": [
"D-008@v2#s3"
],
"context_set": "ctx-demo-014",
"index_release": "idx-demo-04",
"outcome": "needs_clarification",
"latency_ms": "待量測",
"input_tokens": "待量測"
}區分營運彙總、錯誤追查與內容改善
營運彙總看量、延遲分布、失敗或接手狀態及用量；錯誤追查看同一請求的階段與來源；內容改善則整理重複缺口及責任人。三者可以連接，但不必讓所有閱讀報表的人都看到原始對話。先用聚合或範例識別描述問題，真正需要個案時，再按職責取得必要內容。
以 AWS Bedrock 的模型調用紀錄為例，官方列出可記錄的輸入、輸出與中繼資料，以及可設定的目的地；不能假設任一聊天平台預設就提供完整路徑。平台紀錄也未必包含你的檢索、業務接手與資料修訂，仍需核對實際欄位。先確認蒐集能力與責任，不為了報表漂亮就補造不存在的數值。
把保存、存取與刪除驗收納入上線
為每一組紀錄指定用途、可看角色、保存安排與清理責任，按組織及適用要求決定，本文不設定通用保存天數。測試錯誤訊息與附件是否意外含有敏感內容；清理時也要確認匯出副本及備援範圍，不把刪掉主表當成所有副本已同步消失。這是紀錄治理的工作提醒，不是個別法規判斷。
紀錄要能支持下一步處理，也要知道誰能看、何時該清理。用一筆假想錯誤走完整查詢，確認能從事件找到當時來源與流程版本，並把缺口交給合適的人。若核心資料只在某人電腦或即將輪替的短期紀錄中，先處理接續方式，再宣稱已具備可追查能力。
| 要驗什麼 | 實際走法 | 完成證據 |
|---|---|---|
| 可追查 | 以同一請求找來源與階段 | 不靠猜測還原 |
| 可判讀 | 查單位、缺值與狀態 | 報表口徑一致 |
| 可改善 | 將缺口交回內容或技術窗口 | 有接手及回查 |
| 可治理 | 查閱權限與清理副本 | 責任與範圍明確 |
常見問題
完整保存所有對話，之後再分析可以嗎？
先確認分析用途與必要資料，不以全部保留代替設計。大量原文可能包含客戶資訊，卻仍缺檢索、上下文與版本，無法定位錯誤。先定最小欄位、存取角色及保存清理安排，必要個案再按範圍保留。彙總報表與詳細追查也可分開，不讓只需要趨勢的人同時取得所有對話。
把使用者姓名改成雜湊值，就算匿名嗎？
不能只因改了識別方式就認定匿名。原始訊息、附件、時間與其他欄位仍可能連回個人或客戶，也可能存在可對照的識別表。按實際用途減少資料、分開存取與保存安排，並核對組織要求。假想示例中的 request_id 只用來連接流程，不代表任何實際系統已完成匿名化或合規驗證。
只看使用量、滿意度和平均延遲夠嗎？
這些指標可描述部分營運狀況，卻不足以還原某次錯答。還要能連到當時來源、流程版本及實際上下文，並分清補問、失敗和人工接手。平均延遲也可能蓋住少數很慢的請求。先按改善問題選欄位與分布，再用實際事件確認可追查，不因有儀表板就預設問題都能分析。
白話總結：留追蹤單，別把每個包裹都拆開影印
用必要欄位連起一次問答，分開彙總與個案追查，再明確安排誰可看及何時清理。
- 定問題：列出需要追查的失敗、延遲、來源與接手問題。
- 定欄位：約定識別、版本、狀態、單位與缺值，確認實際可蒐集。
- 走驗收：用假想事件查到底，測接手、存取及清理範圍。
完成條件：有權處理的人能找到當次依據並採取下一步，其他角色不必取得不需要的原始內容。
來源與方法範圍
資料查核：2026 年 10 月 24 日。來源支持文中對應的準則與平台說明；工作表、判斷步驟及已標示的假想情境由 AO2 整理，實際使用時依產品資料與現行設定核對。
