把字母数字串念给智能体听

你仪表盘上的那个指标看不见这种失败。

词错误率是在词上算的，而词背后有语言模型：上下文、搭配、形态，以及一个在你看到之前就把被糟蹋的音素修好的先验。RK4T-92B 一样都没有。每个字符取自一个 36 符号、先验近乎均匀的集合，声学证据只有几百毫秒被限带的电话音频，而下游没有任何东西能纠正一处错误——因为每一串都同样说得通。

直接把后果建模出来，因为这就是本页的全部论证。对一个十字符的标识符，在每字符准确率 p 下，完全匹配率是 p¹⁰：

# Exact-match rate for a 10-character identifier

  per-character 95%   ->   0.95^10  =  59.9%
  per-character 97%   ->   0.97^10  =  73.7%
  per-character 99%   ->   0.99^10  =  90.4%

# A 6-character reference is much kinder:

  per-character 97%   ->   0.97^6   =  83.3%

# Doubling accuracy per character does not halve the failure rate.
# Removing characters does.

已公布的厂商数字落点与这笔算术相符。某家语音厂商称其为字母数字调优过的模式在纯数字串上达到 98.0% 的序列准确率，在混合字母数字上是 85.4%——混合才是难的那一档，而每一个订单号、SKU 与预订号实际上就是混合的。同一篇材料还引用了一组对比：96.6% 的词级准确率，与 77% 的标识符完全匹配率并排——同一通电话里，一份出色的转写，和一次失败的查询。

那三个便宜的识别改进要做，但也要知道它们的天花板。

这些都是实打实的改进，花一个下午就能做完，而且没有一个能改变那个指数：

• 按轮次打开厂商的字母数字／拼读模式。多数流式 STT 厂商都提供一种压制词级语言模型、逐字符解码的模式。只在你预期会出现标识符的那一轮开启它——整通电话都开着，会把对话那一半严重拖垮。
• 朝「可能存在的那些串」做偏置。关键词加权、短语提示与自定义词表几乎处处都支持，而在候选集很小的时候效果惊人。如果你知道这位来电者有三张未完成订单，就把那三串加权。
• 把解码约束到你真正的格式上。如果你的编号永远是四个字母、一个连字符、三个数字，那就别接受不符合这个形状的解码结果。拒绝不可能，是免费的准确率；它还把一个无声的错误答案，换成了一次你能处理的重新提问。

然后要清楚你还在跟什么搏斗。字母名称的声学混淆是再怎么调参都消不掉的：E 集合——B、C、D、E、G、P、T、V 与 Z——彼此只差共享元音之前那一小段爆破，而在 8 kHz 的电话通道里，区分它们的那些线索在模型看到任何东西之前就基本没了。M 与 N、F 与 S、以及字母 A 对数字 8，失败方式一样。这个通道约束是结构性的；关于 8 kHz 如何在你的所有选择之上游就改变了一切，见语音栈。

真正管用的那一步：拿一个你本来就有的集合去解析它。

这是本页其余部分为之服务的那条建议。来电者念出来的标识符，几乎每一个你本来都能用别的方式查到，而且你手里已经握着一个很小的候选集——这个号码下的订单、这个账号下的预订、这位客户的三张未结工单。一旦集合很小，你就不再是在转写一串任意字符，而是在拿含噪的证据给几串已知字符排序——而两个字符对上，往往就已定胜负。

落到通话里是这样：

• 先确定人，再确定物。主叫号码、他们认证进来的那个账号、存档的邮箱。标识符于是从主键降格为两三个候选之间的区分器。至于怎么做好前半段而不把智能体变成一台预言机，见来电者认证。
• 对候选做模糊匹配，而不是对字母表做精确匹配。用一个按已知混淆加权的编辑距离给每个候选打分——把 B／D／P 之间的替换几乎算作免费，把元音变化算得很贵——当某个候选明显领先时就接受。
• 问一个描述性问题，而不是一个拼读性问题。「是周二那张单，还是寄往曼彻斯特那个地址的那张？」一轮就解决两个候选，完全不需要字符级识别，而且这是整段交互里来电者觉得最轻松的一轮。
• 只有当集合确实无界时才退回到逐字符采集——第一次打来的人、来自另一家公司的编号、一个你从没见过的文件号。

值得记住的重构是：那个你正试图「听清」的 36¹⁰ 搜索空间，通常是一个你本就有数据可做的「三选一」。团队在该去查一次数据库（只是查得晚了一轮）的时候，伸手去换了一家更好的 STT 厂商。

确实必须采集自由串时，用协议，别用一句提示。

有时候集合确实是无界的。那么采集就成了一个交互设计问题，而管用的设计不是「问、听、最后确认一遍」：

• 切成三到四个字符一组，每组确认。「我们分段来——前四位？」一个已确认分组内的错误，代价是重问四个字符。一个十字符、最后才确认的朗读里的错误，代价是整串；而来电者第二遍会用不同的方式念，于是在新的位置产生新的错误。
• 带消歧地复述，而且只朝一个方向。「B，bravo 的 B，四，七，D，delta 的 D。」在你自己的复述里提供字母解释法；绝不要求来电者使用它。要求一个普通人用军用字母表拼读，是让他挂断电话最可靠的一招。
• 永远不要让人把整串再念一遍。「抱歉，能再说一次吗？」正是把一个糟糕的轮次变成一通被放弃的电话的那种失败。请重问那个具体的分组，并说清是哪一个：「我这边是 B-4-7；后面两位我没听清。」
• 把 DTMF 当作对等的一条路，而不是惩罚。在第一次失败之前就说出「您也可以用键盘输入」，其转化率远高于第二次失败之后才说同一句话。数字走 DTMF 近乎完美；字母不是——这又是 STEP 6 那个格式决定的一条论据。
• 有数据通道时就发个链接。如果这通电话伴随着一个 app 或一条短信会话，点一下胜过任何形式的说话。这不是语音的失败；这是用与载荷相配的那个通道。

确认的门槛按后果定，不按置信度定。

本能是把识别置信度高于某个阈值的都确认一遍。这条轴选错了：置信度讲的是音频，而你需要知道的是「万一错了会怎样」。按误接受的代价给字段排序：

• 不可逆或涉及钱——每一次都显式确认。退款打到哪个账户、换货寄往哪个地址、金额是多少。多一轮对话，对比一笔打错账户的退款，是便宜的。
• 可逆且可见——概率性地解析，并说出你做了什么。「我调出的是尾号 7-4-D 那张单，寄往曼彻斯特。」错了的话来电者会立刻纠正，而这比开口去问是更便宜的一次确认。
• 只读且无关紧要——干脆不要确认。把错的那张单的送达日期念出来，是来电者免费就能抓到的错误。为它做确认，等于让每一位来电者多花一轮去防一个无害的错误。
• 绝不要用「把一串数字念回去、让来电者在脑子里核对」的方式确认。人们会对自己并没有完全听明白的东西说「对」，赶时间时尤其如此。请用一个他们认得的属性来确认——日期、目的地、商品——而不是把那串键背诵回去。

被念回去的数字还带着一个按语言各不相同的归一化问题——「double seven」、「七十七」、分组习惯——这在多语言语音智能体里处理，而它确实是一类「读起来没错、含义却不对」的确认的来源。

把采集当成一条独立漏斗来量——然后去改那个标识符。

按字段类型分的四个数字，能告诉你上面这些有没有起作用：

• 首次尝试的字段完全匹配率。头号指标。按通道切分——手机、固话、VoIP、免提——因为差距很大，而对策也不同。
• 采集所需轮数。这是体验指标。为念一个编号花三轮，正是人们开始要求转人工的那个点，而它往往比放弃通话早一轮。
• DTMF 回退率，按「主动提供」与「对方要求」分开统计。提供了并被采用，是一次成功。失败之后才被要求，是一个带时间戳的设计缺陷。
• 第二次重问之后的放弃率。那道悬崖。如果它很陡，说明你的重问策略是在让人重念整串；回到 STEP 4。

然后把结论往上游带，因为最有效的那次干预根本不在语音栈里。标识符格式是由当初建订单系统的人定的，通常压根没想过会有人把它念出来——而它是可以改的：

• 把易混淆的字母去掉。一个 Crockford 风格、排除 I、L、O、U 的字母表消掉了最糟的视觉碰撞；再排除 E 集合的那些辅音，就消掉了最糟的声学碰撞。你在每个字符上少了一点熵，多加一个字符就买回来了。
• 加一位校验字符。一位校验位能把多数单字符误识变成一个「被检测到的错误」，而不是一次错误的查询——而被检测到的错误可以被精确地重问，不必悄无声息地返回错的那张订单。
• 缩短它，或者拆开它。六个字符在 97% 下胜过十个字符在 99% 下；而把一个对外的短编号映射到一个很长的内部主键，成本不过是一张表。