AI 给来电客户报错价格，怎么办？

先说结论

AI 通话中出现错误答复，原因通常不难找。错误答复无非从五个入口进来：信息源过期、信息源缺失、问题听错、查询出错或越权承诺。其中四个的源头在模型之外：信息源过期和信息源缺失出在信息源上，问题听错出在语音识别环节，查询出错出在系统查询环节。只有越权承诺源于智能体本身：它答应了权限范围以外的事。

所以，预防主要靠管好信息源和权限。每个答复都要过同一道关口：出自核准信息源，信息源是最新的，答复在权限范围之内，每个数字、日期和金额都经过复述确认。任何一项检查不通过，答复就转入安全兜底：智能体转人工，或者安排回电。

即便如此，仍会有错误答复漏网。应对办法是一套固定的应急处置流程：遏制、排查、更正、登记、复测。一次事件有多大，要看它的风险暴露期：从错误答复有可能出现的那一刻，到问题修复的那一刻。风险暴露期有多长，取决于信息源多快跟上业务变化、您多快发现问题、多快遏制住问题，而不取决于模型。

本文中的示例数字都是为本文编写的，既不是 DRING 的数据，也不是行业数据。

错误答复的五个入口

每个入口都有对应的防控措施。

只有越权承诺这个入口，要靠权限范围来堵。其余四个，要在信息源、复述确认和查询上下功夫。信息源缺失的错误虽然以智能体的猜测告终，起因却是信息源留了空白，而答复关口的第一项检查就能拦下这种猜测。查询超时等失败情况怎么处理，请看我们的文章：为什么工具调用不等于自动化。

预防：一道答复关口

答复关口是每个答复都要走的一套固定步骤。来电客户听到答复之前，先过三项检查：答复在核准信息源里吗？信息源是最新的吗？答复在权限范围之内吗？接着，在做出任何承诺或办理任何事项之前，智能体把每个数字、日期和金额复述确认一遍。三项检查中任何一项不通过，这通电话就转入安全兜底。

核准信息源：各有负责人，各有生效时间

把智能体可以用来作答的信息源全部列出来：价目表、退货政策、知识库文档、订单查询。每一项都是一个核准信息源。给每个信息源指定一位信息源负责人，业务一有变化，就由这个人更新。给每个版本标明生效时间，也就是这个版本从什么日期、什么时刻开始有效。

每个主题只保留一个核准信息源。在下文的示例事件中，官网价目表和智能体的信息源是两份独立的文档，只有一份按时更新了。

检查 1：答复在核准信息源里吗？

答复不在核准信息源里，智能体就转入安全兜底。即使是出于好意的猜测，也算一次信息源缺失错误。

检查 2：信息源是最新的吗？

每个新版本都要连同生效时间，在变更发生之前录入。这样，价格一变，信息源就已经是最新的，不必等到有人想起来才去改。如果变更在即，新版本却还没准备好，就先把这个主题转入安全兜底，直到新版本就绪。

检查 3：答复在权限范围之内吗？

权限范围规定了智能体在没有人工参与时可以说什么、做什么。按主题分三级写清楚：

必须转人工，就是转入安全兜底：要么由人工坐席当场接过电话，要么稍后通过回电确认。人工坐席接电话时应该拿到哪些信息，请看我们的如何设计转人工指南。

最后一步：复述确认每个数字、日期和金额

信号不好时，“十四”和“四十”很容易听混。所以，凡是智能体说出口或要据此操作的数字、日期和金额，都要复述一遍，等来电客户确认后，才做出承诺或办理。复述确认还能拦下问题听错，因为来电客户能听出智能体说的是哪一项。下面这段对话，发生在下文示例事件修复之后：

• 来电客户：“保障服务现在一个月多少钱？”
• 智能体：“保障服务现在是每月 14 欧元，十四欧元。您问的是这项服务，对吗？”
• 来电客户：“对，十四，就是这个。”

同一个智能体碰到权限范围的边界时，是这样说的：

• 来电客户：“上周你们官网上写的还是十二欧，能按十二给我吗？”
• 智能体：“价格我在电话里改不了，不过我的同事可以帮您看看。现在就给您转过去，还是稍后让同事给您回电？”

版本发布前，先测试答复关口

每个入口至少测试一个用例：

• 信息源过期：设置一个带生效时间的新价格。生效前的通话报旧价格，生效后的通话报当前价格。
• 信息源缺失：提出核准信息源没有涵盖的问题。智能体应转入安全兜底。
• 问题听错：发音相近的产品名称，再加上背景噪音。复述确认要拦下听错的那一个。
• 查询出错：查询失败、查不到结果，或者查到了另一个订单。智能体不编造结果，而是转入安全兜底。
• 越权承诺：来电客户要求折扣或退款。智能体转人工。

完整的测试集怎么搭建，请看我们的指南：上线前如何测试语音 AI 智能体。

示例事件：智能体漏掉的一次调价

示例，并非真实数据。一家零售商把保障服务的价格从每月 €12 上调到 €14，周一 09:00 起生效。官网价目表按时改了。智能体的核准信息源是另一份独立的文档，调价时没有人去更新。周三 10:30，接到第一条投诉：一位来电客户听到的是 €12，实际却被扣了 €14。这份文档在周三 14:00 修正，这一步就是遏制。风险暴露期从周一 09:00 持续到周三 14:00，共 53 小时。

遏制是在第一条投诉之后 3 小时 30 分钟才完成的，这段时间里，来电客户仍可能听到 €12。如果在接到投诉后几分钟内，就把这项服务的价格问题改为转人工，文档修正期间就不会再有人听到错误价格。

14:00 之后，团队开始排查。先在风险暴露期内的通话转写文本中搜索这项服务，再逐通查看提到它的通话：

后三行加起来，正好是提到这项服务的 120 通电话：46 加 61 再加 13。所以受影响来电客户是 46 位，不是 900 位。如果 900 位全部联系，就会让 854 位从没听到过 €12 的客户一头雾水。如果只联系投诉的那一位，另外 45 位受影响来电客户就仍然以为价格是 €12。周四，团队联系了这 46 位受影响来电客户，告知当前价格。

有两项改变本可以缩短风险暴露期。如果在周一之前，就把新价格连同生效时间录入核准信息源，风险暴露期就会是 0 小时。如果有每日检查，把每通电话中报出的价格和当前价目表逐一比对，周二 08:00 的第一次检查就能发现报价 €12 的通话。如果当时就修正信息源，风险暴露期就会是 23 小时，而不是 53 小时。

应急处置流程：五个步骤

只要有来电客户听到了错误答复，就按同样的顺序，走同样的五步。遏制排在排查之前：您在查通话的时候，新的来电客户仍可能听到错误答复。

排查找的是受影响来电客户，不是所有来过电话的人。从风险暴露期入手，缩小到相关主题，再逐通查看。如果您的人工团队也依据同一个信息源答复，他们的通话也要一并核查。

更正所依据的处理方案，要在第一次事件之前定好。是按错误报价兑现，还是向客户说明当前价格？这是一项业务决策。要事先定下来，写成书面规则，交给负责打更正电话的同事。报出的价格是否对您有约束力，要由您的法律顾问判断，本指南不作解答。

登记时，每次都用同一套事件台账字段，这样不同事件之间才能比较。示例事件的登记内容如下：

衡量哪些指标

三个数字能说明答复关口和应急处置流程是否有效：

• 已复核通话的错误答复率：存在信息错误的已复核通话数，除以已复核通话数。它就是我们语音 AI 试点成功标准一文中错误操作率里的信息错误部分，所以两者可以相互比较。给每个错误答复归一个入口，按入口计数，就知道下一步该在哪里下功夫。
• 风险暴露期时长：每次事件单独计算，以小时为单位。示例中是 53 小时：到第一条投诉用了 49 小时 30 分钟，从投诉到修复又用了 3 小时 30 分钟。
• 从首个信号到遏制的时间：从第一条投诉、第一个复核发现或第一次检查告警算起，到完成遏制为止。示例中是 3 小时 30 分钟。

任何关口都无法保证错误答复率为零，一个月平安无事，也证明不了关口有效。正如试点那篇文章所说，复核 300 通电话没有发现一次错误操作，真实比率仍可能高达约 1%。

随机复核还可能漏掉范围很窄的问题，或者发现得太晚。在示例中，风险暴露期内的 900 通电话里有 46 通受影响，约每 100 通中有 5 通，而且全都集中在同一项服务上。每日检查把每通电话中报出的价格与当前价目表比对，看的是这个主题下的每一通电话，而不是抽样。

DRING 能帮上什么

安全护栏、转人工、通话后分析、测试和监控，都属于每个 DRING 套餐共用的基础能力。在本指南中，权限范围就是一道安全护栏，安全兜底依靠转人工，每日检查依靠通话后分析。

通话后分析可以按您的定义输出额外字段，并通过 API、您的 CRM、数据看板和报表返回。其中一个字段可以是每通电话中报出的价格，这样就能每天和当前价目表做比对。我们的通话分析页面展示了数据看板和报表。

每个 DRING 智能体在接第一通真实电话之前，都会跑 1,000 至 10,000 次专为您企业生成的模拟对话。模拟对话在上线前测试答复关口，但不能取代真实通话中的应急处置流程。

如果您的线路即将调价或调整政策，可以申请 AI 回电。提前准备好价目表，以及智能体用来作答的文档。我们的团队可以和您一起，对照五个入口逐一检查。