一份虛構家具店錄音稿入面，說話人零話「我去確認星期五可唔可以送貨」。摘要卻變成「店長已承諾星期五送到」。呢度跨過咗兩道未核實嘅關口：呢個係邊個，同埋佢講嘅話係咪構成承諾。本文係一張錄音稿編輯單，唔係實際錄音分析。先保留匿名說話人標籤，唔好直接將摘要寫入客戶訂單。

Amazon Transcribe 嘅說話人分離功能，會畀唔同說話人嘅文字獨特標籤，亦會提供發言時段。 文件例子入面嘅 spk_0 係輸出標籤，唔係員工帳戶。我哋建議分開記錄「呢把聲分到邊組」同「呢位員工係邊個」；唔好因為出現次序、座位，或者有人提過某個名，就自動認定身份。

AWS 嘅輸出說明包括逐字時間同置信分數。 呢啲欄位可以幫手定位核對，但唔係業務承諾嘅批准記錄。就算「確認」轉寫正確，都唔可以將「去確認可唔可以送貨」改成「已確認送貨」。呢個係我哋對業務使用嘅分析：將原句、解釋同確認狀態放喺唔同欄位，唔好用一份漂亮摘要覆蓋晒三樣嘢。

我哋建議每條重要結論附上受控錄音引用、開始同結束時間、原始標籤、經人工核實嘅姓名同核實人。姓名未確定就留空，重疊發言或者聽唔清就標示待核對。只喺已獲錄音同使用許可嘅範圍處理資料，並限制存取同保留時間。唔好為咗畀更多人覆核，就將成段客戶錄音散發到無關群組。

呢間虛構店嘅安全改稿係：某位身份未核實嘅參與者提出去確認星期五可唔可以送貨，交貨日期仍然等負責人確認。覆核者應該重聽相關片段，有需要就問參與者；確認身份之後，再分開確認交貨日期嘅權限同結論。更正姓名亦要重新檢查根據嗰個姓名產生嘅任務，唔只係改稿入面一個字。

今次建議驗收要分開睇文字、說話人對應同業務意思。用已授權嘅短片段，請覆核者檢查否定句、條件句、插話同身份未明嘅片段；記錄更正同未解決項目。呢度冇做真實錄音測試。上線前要確定邊個可以確認身份、邊個可以批准承諾，同埋錯誤點樣回傳，先可以令自動摘要成為協助，而唔係代人認領責任。