AI打车Agent的「自作主张」正在引发用户投诉风暴。当系统自信满满地将用户送往错误机场时，背后暴露的是置信度机制的致命缺陷。本文揭秘如何通过四档分级策略，将投诉率从2.1%直降至0.4%，并深入解析3秒弱确认、历史偏好衰减等关键设计细节，展现AI产品在「自信」与「保守」间寻找平衡的艺术。

上个月，我朋友公司的打车 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 类的产品，希望这些经验对你有帮助。

置信度分级不是什么高深的技术，核心就是一个原则，根据把握程度决定行动方式。但要把这个原则落地，需要很多细节的打磨。

欢迎在评论区讨论，我们可以聊聊具体的实现。