語音AI點餐中人類究竟應該確認什麼？
在一個合成語音點餐示例中，一個重複的語音標記變成了三個漢堡。系統提供了一個合理的修正建議：將數量更改為一個。對於產品團隊而言，棘手的問題在於該建議與提交訂單的許可之間發生了什麼。看似有用的替換並沒有確定客戶真正想要的是什麼。
說明：以下示例是Veriprajna的Drive-Thru Order Firewall中的合成訂單，該防火牆在模擬廚房顯示屏之前驗證結構化供應商輸出。它既不識別人類的真實音訊，也不向餐廳的POS系統發送訂單。
我希望人工確認能夠解決特定的不確定性。這需要將三項判斷分開來：客戶的真實意圖、餐廳策略是否允許該訂單，以及所提議的精確訂單是否滿足各項檢查。將這些判斷合併到一個批准按鈕中，會導致很難明確一次批准究竟意味著什麼。
修正只是關於意圖的假設
重複標記的測試夾具包含一段不流暢的轉錄文本、三個完全相同的原始標記以及三個漢堡的數量。其提供的置信度得分為0.71，低於配置的審核閾值0.85。因此，重複規則和低置信度規則將該訂單置於HOLD狀態。重複規則建議改為一個漢堡。
對於呈現在操作員面前的選項而言，一個漢堡是一個合理的候選值。但它並不是預期數量的證明。重複標記或許能解釋結構化輸出，但檢測到重複的規則無法詢問客戶究竟是什麼意思。自動將三個替換為一個，只是用未經確認的解釋取代了存疑的解釋。
拒絕訂單則伴隨著不同的代價。這相當於把需要澄清的解釋當成了無法挽回任何可接受訂單的情況。在這一步我更傾向於擱置（hold），因為這樣可以保留原始證據，並將預期的數量保持開放。在生產環境中，確認應當針對數量本身提出詢問，而不是要求操作員背書系統的整體置信度。
這是一種設計立場，而非此應用中已完成的工作流程。展示中的Approve Correction和Escalate按鈕會改變自身標籤並被停用。它們不會重新提交、放行、記錄人工操作或更改收據。生產團隊仍需構建能夠使回答產生實際效力的對話機制和狀態轉換。
非同尋常的要求也可能被準確理解
意圖解釋只是暫停處理的原因之一。另一個合成夾具包含18,000個水杯，其提供的置信度得分為0.97，且客戶功能表價格為零。由於該數量超過了配置的八杯水上限，關卡對其進行了擱置。無論是較高的輸入得分還是零價格，都無法回答是否允許該數量繼續推進。該得分只是來自夾具的輸入，並非經過校準的許可概率。
極端的數量使這種區分顯而易見。更困難的產品決策在於客戶確實想要的異常數量。假設有一份超出餐廳常規自動限制的團體訂單。如果客戶確認了該數字，解釋可能已經明確，但許可依然懸而未決。將其壓縮到常規上限會篡改客戶要求。而直接拒絕則可能扼殺合法需求。
在策略允許特例的情況下，我更傾向於使用例外閾值來觸發審核。此時操作員需要決定餐廳是否可以接受已確認的訂單，這可能需要通過獨立授權的途徑。旨在限制自動提交的閾值，不應悄然變成改寫客戶意圖的規則。
這需要消耗注意力。更寬鬆的自動閾值會放行更多異常訂單；更嚴格的閾值則會帶來更多的審核工作。展示無法為餐廳做出這種權衡選擇。其上限源自預設的合成訂單歷史，其分佈反映了該歷史中的數據表現。它既不能確立真實門店的接待能力，也無法確定合法團體訂單的發生頻率。在採納此類策略之前，團隊需要關於可接受例外情況及其實際確認負擔的充分證據。
確認必須精確適用於下一筆訂單
即使經過確認的修正，其結果仍可能無效。大額訂單夾具初始包含40份薯條和40杯汽水。數量規則提議將薯條減少到四份，但保持40杯汽水不變。汽水的上限是六杯。因此，即便同意將四份薯條作為合適替代，提議的訂單中依然存在另一項數量違規。
這就是我堅持將確認與驗證嚴格區分的原因。客戶確認解決的是意圖問題。授權操作員的例外決策解決的是策略問題。檢查提議的完整訂單解決的是下一筆交易是否符合適用規則。這些結論中的任何一個都無法從其他結論中安全推斷出來。
對於生產工作流程，我要求確認的提議在提交前必須重新通過驗證。如果操作員可以推翻策略，該權限應當明確聲明，並綁定到所接受的特定規則與訂單上。寬泛的批准不應抹去不相關的違規。這些是未來實現的要求，而非當前修正控制項所展示的功能。
建議可以提供幫助而無需賦予許可
解釋性模型批註具有實用但更為狹窄的作用：它可以使擱置的原因更易於閱讀。在隨附的創始人錄像中，該批註使用了快取的真實諮詢響應。它並非在每次重播時都進行全新的推理。引擎首先使用確定性規則做出決策；隨後的諮詢文本無法改變該決策。諮詢調用在處理流程中是同步的，因此這種權限分離並不證明模型處理不會增加請求延遲。
這份訂單驗證詳細解析展示了這一邊界和合成示例。它們支援了一個可審查的設計論點，但並非表明預設策略或未完成的操作員工作流程已具備部署條件。
以下是關於訂單審核示例的創始人錄像。
對我而言，決定性的產品評審在於跟蹤提議訂單直至其下一個被允許的操作。誰確認了其含義？誰可以批准特例？是什麼檢查了完整結果？在這些答案完全指向同一筆精確訂單之前，令人寬慰的修正和批准標籤只會讓交易處於未完成狀態。
