AI打车Agent的「自作主张」正在引发用户投诉风暴。当系统自信满满地将用户送往错误机场时，背后暴露的是置信度机制的致命缺陷。本文揭秘如何通过四档分级策略，将投诉率从2.1%直降至0.4%，并深入解析3秒弱确认、历史偏好衰减等关键设计细节，展现AI产品在「自信」与「保守」间寻找平衡的艺术。
上个月，我朋友公司的打车 Agent 出了一个事故。
用户说了一句「帮我叫个车去机场」，Agent 很自信地叫了一辆去浦东机场的车。
结果用户要去的是虹桥机场。
用户投诉了。还发了微博。
这不是个例。我们统计了一下，类似的「AI 自作主张」投诉，每天有二三十起。
占比不高，但每一起都很伤用户体验。而且，这种事一旦上了社交媒体，传播起来比好评快多了。
我们花了三个月时间，重新设计了 Agent 的「置信度分级」机制。投诉率从 2.1% 降到了 0.4%。
这篇文章记录一下我们踩过的坑，以及最后是怎么解决这个问题的。
先把问题说清楚。
用户说「帮我叫个车去机场」这句话，对人来说很简单，但对 AI 来说，信息是不完整的。
去哪个机场？上海有两个，浦东和虹桥。
从哪里出发？当前位置还是另一个地址？
要什么车型？快车还是专车？
现在叫还是预约？
这些问题，用户没说，AI 怎么办？
我们最初的方案很朴素，AI 自己猜。
根据用户历史数据，这个用户之前 80% 的时候去的是浦东机场，那就默认浦东。车型默认快车，时间默认现在。
听起来很合理对吧。
但实际跑下来，问题大了。
我们最初的方案是「二元判断」。
意图识别出来了，就执行。识别不出来，就问用户。
非常简单粗暴。
效果怎么样？
很差。
第一个问题是，太多「确定」其实是错的。
AI 觉得自己识别出来了，置信度很高，直接执行。结果执行错了。
比如用户说「去机场」，AI 根据历史数据默认了浦东机场，因为历史数据里浦东更多。但用户这次实际要去虹桥。
高置信度不代表高准确率。
这个道理我们是交了学费才懂的。
第二个问题是，太多「不确定」影响体验。
另一个极端是，AI 太保守，动不动就问用户。
你要什么车型？
你要现在叫还是预约？
用户会崩溃的，我就说了一句话，你问我四个问题？
反复确认会严重影响用户体验。
所以我们陷入了一个两难，执行太多会出错，问太多会烦人。
后来我们引入了「置信度分级」。
核心思路是，根据置信度高低，采取不同的处理策略。
我们把置信度分成四档。
第一档，90% 以上，直接执行。用户感知是秒响应，无确认。
第二档，70% 到 90%，弱确认。显示选项，3 秒无异议默认通过。
第三档，50% 到 70%，强确认。必须用户选择才能继续。
第四档，50% 以下，主动询问。让用户提供更多信息。
具体怎么操作呢。
第一档，直接执行。
条件是意图明确，关键信息完整，没有歧义。
比如用户说「帮我叫个快车从公司到浦东机场 T2」，这句话信息量很完整，意图很明确。AI 直接呼叫快车，从用户设置的公司地址到浦东机场 T2。
这种情况不需要任何确认，直接执行就行。
第二档，弱确认。
条件是意图明确，但有一定默认值需要确认。
比如用户说「去机场」。
AI 会说，好的，为您呼叫快车从当前位置到浦东机场 T2，3 秒后自动确认，点击可修改目的地。
如果用户 3 秒内没有操作，默认确认。如果用户点击了修改，展示其他选项，虹桥机场、其他航站楼。
这种方式既给了用户反悔的机会，又不会让用户觉得太啰嗦。
第三档，强确认。
条件是存在明显歧义，需要用户选择。
比如用户说「去机场」，但历史数据显示用户去过浦东和虹桥的次数差不多。
这种情况 AI 就不能自己猜了，必须让用户选。
AI 会说，请选择您要去的机场，然后给出选项，浦东国际机场，虹桥国际机场。
必须等用户选择才能继续。
第四档，主动询问。
条件是关键信息缺失，无法合理默认。
比如用户说「我要赶飞机」。
这句话表达了一个意图，但关键信息完全缺失。去哪个机场，什么时候走，都不知道。
AI 会说，好的，请告诉我您的航班信息或目的地机场，我来帮您叫车。
说到这里可能有人会问，置信度怎么算？
这个问题我们也纠结了很久。
最开始我们直接用大模型输出的 confidence 值，发现不靠谱。大模型的 confidence 跟实际准确率对不上。
后来我们改成了综合计算，考虑四个因素。
第一是意图识别的置信度，模型对意图分类的把握程度。
第二是槽位完整度，必填信息是否都有了。
第三是歧义程度，关键词是否有多个可能的解释。
第四是用户历史，这个用户以前的偏好是否明确。
举个例子。
用户说「去机场」。
意图识别置信度 95%，明确是叫车。槽位完整度 70%，缺少具体机场。歧义程度高，有两个机场可选。用户历史 90%，大部分时候去浦东。
综合置信度大概是 71%，落入弱确认档位。
这个计算方式不一定是最优的，但至少比单纯用模型的 confidence 靠谱多了。
还有几个细节问题需要处理。
第一个是弱确认的 3 秒怎么定的。
这个时间是测试出来的。
太短，1 秒，用户来不及反应。太长，5 秒，用户等得不耐烦。
我们做了 A/B 测试，发现 3 秒是最优的。用户有足够时间看到信息，如果要修改来得及点击，如果没问题不会觉得等太久。
第二个是用户历史怎么用。
我们会记录用户的偏好。常用地址，公司、家、机场。车型偏好，快车多还是专车多。时间偏好，通常什么时间叫车。
这些偏好会影响默认值的选择。
但有个坑，偏好会过时。
用户换工作了，公司地址变了。用户搬家了，家的位置变了。
我们的处理方式是，偏好有时效性，超过 3 个月不用的偏好权重下降。偏好出现变化的时候，比如连续两次选了不同的地址，主动询问是否更新。
第三个是兜底策略。
不管置信度多高，有些情况必须做兜底。
金额超过阈值，预估费用超过 200 元，必须确认。距离超过阈值，目的地超过 50 公里，必须确认。异常时间，凌晨 2 点到 5 点叫车，必须确认。
这些是高风险场景，错了代价很高，宁可多问一句。
说说效果。
上线一个月后的数据。
首次成功率，优化前 65%，优化后 72%。最终完成率，优化前 82%，优化后 91%。平均交互轮次，优化前 3.2 轮，优化后 2.1 轮。用户投诉率，优化前 2.1%，优化后 0.8%。
后来又迭代了几个版本，投诉率降到了 0.4%。
几个关键变化。
首次成功率提升，更多用户一次就成功，因为弱确认减少了不必要的询问。
最终完成率提升，更少用户中途放弃，因为体验更流畅。
交互轮次减少，从 3.2 轮降到 2.1 轮，效率提升明显。
投诉率下降，错误执行的情况大幅减少。
聊聊我们踩过的坑。
第一个坑是置信度阈值拍脑袋定的。
我们最初的阈值是直接拍脑袋，90%、70%、50%。
后来根据用户反馈不断调整。
有用户说「明明我说得很清楚，怎么还要确认」，说明直接执行的阈值可以调高一点。
有用户说「我没说去浦东，怎么默认浦东」，说明机场选择的确认需要加强。
收集反馈，分析原因，调整阈值，观察效果。这个循环要持续做。
第二个坑是不同业务场景阈值不一样。
打车场景，错了可以取消重新叫，代价不算太高，可以适当激进。
支付场景，错了可能造成资金损失，必须非常保守。
没有通用的阈值，要根据业务特点调整。
第三个坑是忽略了极端情况。
大部分用户的请求是正常的，但总有一些极端情况。
用户输入了一个不存在的地址。用户要求去一个 500 公里外的地方。用户的请求自相矛盾，帮我叫个车但我不要坐车。
这些极端情况要单独处理，不能让系统崩溃或者给出荒谬的响应。
做完这个项目，我有一个很深的感触。
AI 的智能，不在于它多聪明，而在于它知道自己多不聪明。
什么意思呢。
好的 AI 产品，是知道什么时候该直接执行，什么时候该问一句，什么时候该多问几句的。
这种分寸感，才是好产品的核心。
太自信的 AI 会出错，太谦虚的 AI 会烦人。找到那个平衡点，需要大量的数据、测试和迭代。
我们做了三个月，还只是刚刚摸到一点门道。
如果你也在做 Agent 类的产品，希望这些经验对你有帮助。
置信度分级不是什么高深的技术，核心就是一个原则，根据把握程度决定行动方式。但要把这个原则落地，需要很多细节的打磨。
欢迎在评论区讨论，我们可以聊聊具体的实现。
本文由 @鸣老师 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。