做打車 Agent 半年，我終于搞懂了置信度這個東西

AI打車Agent的「自作主張」正在引發用戶投訴風暴。當系統自信滿滿地將用戶送往錯誤機場時，背后暴露的是置信度機制的致命缺陷。本文揭秘如何通過四檔分級策略，將投訴率從2.1%直降至0.4%，并深入解析3秒弱確認、歷史偏好衰減等關鍵設計細節，展現AI產品在「自信」與「保守」間尋找平衡的藝術。

———— / BEGIN / ————

上個月，我朋友公司的打車 Agent 出了一個事故。

用戶說了一句「幫我叫個車去機場」，Agent 很自信地叫了一輛去浦東機場的車。

結果用戶要去的是虹橋機場。

用戶投訴了。還發了微博。

這不是個例。我們統計了一下，類似的「AI 自作主張」投訴，每天有二三十起。

占比不高，但每一起都很傷用戶體驗。而且，這種事一旦上了社交媒體，傳播起來比好評快多了。

我們花了三個月時間，重新設計了 Agent 的「置信度分級」機制。投訴率從 2.1% 降到了 0.4%。

這篇文章記錄一下我們踩過的坑，以及最后是怎么解決這個問題的。

01

先把問題說清楚。

用戶說「幫我叫個車去機場」這句話，對人來說很簡單，但對 AI 來說，信息是不完整的。

去哪個機場？上海有兩個，浦東和虹橋。

從哪里出發？當前位置還是另一個地址？

要什么車型？快車還是專車？

現在叫還是預約？

這些問題，用戶沒說，AI 怎么辦？

我們最初的方案很樸素，AI 自己猜。

根據用戶歷史數據，這個用戶之前 80% 的時候去的是浦東機場，那就默認浦東。車型默認快車，時間默認現在。

聽起來很合理對吧。

但實際跑下來，問題大了。

02

我們最初的方案是「二元判斷」。

意圖識別出來了，就執行。識別不出來，就問用戶。

非常簡單粗暴。

效果怎么樣？

很差。

第一個問題是，太多「確定」其實是錯的。

AI 覺得自己識別出來了，置信度很高，直接執行。結果執行錯了。

比如用戶說「去機場」，AI 根據歷史數據默認了浦東機場，因為歷史數據里浦東更多。但用戶這次實際要去虹橋。

高置信度不代表高準確率。

這個道理我們是交了學費才懂的。

第二個問題是，太多「不確定」影響體驗。

另一個極端是，AI 太保守，動不動就問用戶。

• 你要去哪個機場？你從哪里出發？

• 你要什么車型？

• 你要現在叫還是預約？

用戶會崩潰的，我就說了一句話，你問我四個問題？

反復確認會嚴重影響用戶體驗。

所以我們陷入了一個兩難，執行太多會出錯，問太多會煩人。

03

后來我們引入了「置信度分級」。

核心思路是，根據置信度高低，采取不同的處理策略。

我們把置信度分成四檔。

第一檔，90% 以上，直接執行。用戶感知是秒響應，無確認。

第二檔，70% 到 90%，弱確認。顯示選項，3 秒無異議默認通過。

第三檔，50% 到 70%，強確認。必須用戶選擇才能繼續。

第四檔，50% 以下，主動詢問。讓用戶提供更多信息。

04

具體怎么操作呢。

第一檔，直接執行。

條件是意圖明確，關鍵信息完整，沒有歧義。

比如用戶說「幫我叫個快車從公司到浦東機場 T2」，這句話信息量很完整，意圖很明確。AI 直接呼叫快車，從用戶設置的公司地址到浦東機場 T2。

這種情況不需要任何確認，直接執行就行。

第二檔，弱確認。

條件是意圖明確，但有一定默認值需要確認。

比如用戶說「去機場」。

AI 會說，好的，為您呼叫快車從當前位置到浦東機場 T2，3 秒后自動確認，點擊可修改目的地。

如果用戶 3 秒內沒有操作，默認確認。如果用戶點擊了修改，展示其他選項，虹橋機場、其他航站樓。

這種方式既給了用戶反悔的機會，又不會讓用戶覺得太啰嗦。

第三檔，強確認。

條件是存在明顯歧義，需要用戶選擇。

比如用戶說「去機場」，但歷史數據顯示用戶去過浦東和虹橋的次數差不多。

這種情況 AI 就不能自己猜了，必須讓用戶選。

AI 會說，請選擇您要去的機場，然后給出選項，浦東國際機場，虹橋國際機場。

必須等用戶選擇才能繼續。

第四檔，主動詢問。

條件是關鍵信息缺失，無法合理默認。

比如用戶說「我要趕飛機」。

這句話表達了一個意圖，但關鍵信息完全缺失。去哪個機場，什么時候走，都不知道。

AI 會說，好的，請告訴我您的航班信息或目的地機場，我來幫您叫車。

05

說到這里可能有人會問，置信度怎么算？

這個問題我們也糾結了很久。

最開始我們直接用大模型輸出的 confidence 值，發現不靠譜。大模型的 confidence 跟實際準確率對不上。

后來我們改成了綜合計算，考慮四個因素。

第一是意圖識別的置信度，模型對意圖分類的把握程度。

第二是槽位完整度，必填信息是否都有了。

第三是歧義程度，關鍵詞是否有多個可能的解釋。

第四是用戶歷史，這個用戶以前的偏好是否明確。

舉個例子。

用戶說「去機場」。

意圖識別置信度 95%，明確是叫車。槽位完整度 70%，缺少具體機場。歧義程度高，有兩個機場可選。用戶歷史 90%，大部分時候去浦東。

綜合置信度大概是 71%，落入弱確認檔位。

這個計算方式不一定是最優的，但至少比單純用模型的 confidence 靠譜多了。

06

還有幾個細節問題需要處理。

第一個是弱確認的 3 秒怎么定的。

這個時間是測試出來的。

太短，1 秒，用戶來不及反應。太長，5 秒，用戶等得不耐煩。

我們做了 A/B 測試，發現 3 秒是最優的。用戶有足夠時間看到信息，如果要修改來得及點擊，如果沒問題不會覺得等太久。

第二個是用戶歷史怎么用。

我們會記錄用戶的偏好。常用地址，公司、家、機場。車型偏好，快車多還是專車多。時間偏好，通常什么時間叫車。

這些偏好會影響默認值的選擇。

但有個坑，偏好會過時。

用戶換工作了，公司地址變了。用戶搬家了，家的位置變了。

我們的處理方式是，偏好有時效性，超過 3 個月不用的偏好權重下降。偏好出現變化的時候，比如連續兩次選了不同的地址，主動詢問是否更新。

第三個是兜底策略。

不管置信度多高，有些情況必須做兜底。

金額超過閾值，預估費用超過 200 元，必須確認。距離超過閾值，目的地超過 50 公里，必須確認。異常時間，凌晨 2 點到 5 點叫車，必須確認。

這些是高風險場景，錯了代價很高，寧可多問一句。

07

說說效果。

上線一個月后的數據。

首次成功率，優化前 65%，優化后 72%。最終完成率，優化前 82%，優化后 91%。平均交互輪次，優化前 3.2 輪，優化后 2.1 輪。用戶投訴率，優化前 2.1%，優化后 0.8%。

后來又迭代了幾個版本，投訴率降到了 0.4%。

幾個關鍵變化。

首次成功率提升，更多用戶一次就成功，因為弱確認減少了不必要的詢問。

最終完成率提升，更少用戶中途放棄，因為體驗更流暢。

交互輪次減少，從 3.2 輪降到 2.1 輪，效率提升明顯。

投訴率下降，錯誤執行的情況大幅減少。

08

聊聊我們踩過的坑。

第一個坑是置信度閾值拍腦袋定的。

我們最初的閾值是直接拍腦袋，90%、70%、50%。

后來根據用戶反饋不斷調整。

有用戶說「明明我說得很清楚，怎么還要確認」，說明直接執行的閾值可以調高一點。

有用戶說「我沒說去浦東，怎么默認浦東」，說明機場選擇的確認需要加強。

收集反饋，分析原因，調整閾值，觀察效果。這個循環要持續做。

第二個坑是不同業務場景閾值不一樣。

打車場景，錯了可以取消重新叫，代價不算太高，可以適當激進。

支付場景，錯了可能造成資金損失，必須非常保守。

沒有通用的閾值，要根據業務特點調整。

第三個坑是忽略了極端情況。

大部分用戶的請求是正常的，但總有一些極端情況。

用戶輸入了一個不存在的地址。用戶要求去一個 500 公里外的地方。用戶的請求自相矛盾，幫我叫個車但我不要坐車。

這些極端情況要單獨處理，不能讓系統崩潰或者給出荒謬的響應。

09

做完這個項目，我有一個很深的感觸。

AI 的智能，不在于它多聰明，而在于它知道自己多不聰明。

什么意思呢。

好的 AI 產品，是知道什么時候該直接執行，什么時候該問一句，什么時候該多問幾句的。

這種分寸感，才是好產品的核心。

太自信的 AI 會出錯，太謙虛的 AI 會煩人。找到那個平衡點，需要大量的數據、測試和迭代。

我們做了三個月，還只是剛剛摸到一點門道。

如果你也在做 Agent 類的產品，希望這些經驗對你有幫助。

置信度分級不是什么高深的技術，核心就是一個原則，根據把握程度決定行動方式。但要把這個原則落地，需要很多細節的打磨。

本文來自公眾號：鳴老師 作者：鳴老師