把语音里的数字实时变成标准数字：减少工单返工、提升内容审核命中率，并支持在同一实时流中随时开关数字格式化。
实时数字格式化：语音转文本少犯错的诀窍
客服录音里最“贵”的错误，往往不是把一句话听错，而是把数字写错：订单号少一位、金额多一个零、手机号漏掉最后两位、航班号把“two one”听成“to one”。在社交平台与内容审核场景里，这类错误同样致命——你可能需要从直播、语音房、语音私信里快速提取金额、时间、地址、验证码、联系方式，任何一个数字偏差都会让自动化流程失效，甚至引发合规风险。
这篇文章把 Deepgram 的一个很“工程化”的更新（在实时流中随时开/关 numeral formatting）翻译成更实用的语言：让语音助手在需要时把“one hundred”变成“100”，不需要时保持原样。我更想强调的是它背后的工作流价值：当你把语音识别接到工单系统、订单系统、风控/内容合规审核管线里，数字格式化不是锦上添花，而是减少返工和误判的底层能力。
一句话立场：如果你的语音自动化链路里包含“数字字段”（金额、电话、订单号、地址门牌、时间日期），就应该把“实时可切换数字格式化”当作必配能力，而不是最后再补救。
数字格式化到底解决什么问题？
**数字格式化（numeral formatting）解决的是“语音里表达数字的方式”和“系统需要存储/计算的数字格式”之间的断层。**人说数字有很多种说法：
- “一百二十三”“一二三”“one twenty three”“one two three”
- “九点半”“9:30”“today at nine thirty”
- “一千零八”“1008”“ten oh oh eight”
而系统通常只认结构化字段：amount=123.00、time=09:30、order_id=1008。
在“人工智能在社交平台与内容审核”里，数字为什么更敏感？
社交平台的音频内容审核不只是识别脏话。很多风险点藏在数字里：
- 诱导私下交易：报“价格/转账金额/收款码/手机号/微信号”
- 诈骗与灰产：报“验证码”“银行卡号”“刷流水金额”
- 合规要求：直播带货报“优惠金额”“限时截止时间”
这些信息往往要进入后续自动化：命中规则→打标签→截断传播→生成证据链→工单流转。数字一旦识别成了口语文本或格式混乱，就会出现两类常见故障：
- 规则匹配失败：风控规则期望
\b\d{11}\b，结果识别成“one three eight…” - 人工复核成本上升：审核员需要反复回听确认数字，吞掉处理吞吐量
真正实用的点：实时流中随时开/关数字格式化
Deepgram 的变化很直接：过去你通常只能在建立实时转写连接时，通过查询参数决定是否启用 numerals。现在可以在同一个实时音频流里，随时发送一条 Configure 消息来切换。
这意味着你可以把“数字模式”当成一种状态机：当对话进入“报号码/报金额/报地址”阶段，打开；回到自由对话、情绪分析、内容理解阶段，关闭。
为什么“中途切换”比“一开始就开”更好？
答案是：开着 numerals 并不总是你想要的输出。
- 内容审核/舆情分析常常需要保留原话语气与表达方式。把“one oh one”统一成“101”有时会丢掉说法差异（例如刻意拆分数字规避审核的行为）。
- 订单/客服场景则更关注结构化字段：订单号、金额、数量、门牌号。这里数字越标准越好。
所以更合理的策略是：默认保留自然语言，检测到“数字槽位”再短时开启格式化。
小业务也能用：三个可落地的自动化工作流
**把数字识别做对，小团队也能立刻省时间。**下面是我见过最常落地的三种。
1) 客服工单：自动抓取订单号、金额与电话
关键点：客服对话里“自由对话”和“报数字”是交替出现的。
一个好用的流程是：
- 语音实时转写默认 numerals=off（保留自然语言，便于质检/情绪分析）
- 当检测到意图：
提供订单号/报手机号/退款金额，发送Configure→ numerals=on - 用正则/NER 抽取字段：
order_id、phone、amount - 字段落库后再切回 numerals=off
这样做的效果通常很实际：字段抽取更稳定、工单自动填充更准确，减少“客服边听边打字”的手工步骤。
2) 直播与语音房审核：捕捉“报价/转账/联系方式”
很多平台的灰产会故意把数字拆开说（“一 二 三 四”）来绕过文本规则。如果你的 ASR 输出仍是口语数字，后端很难统一检测。
你可以设计一个“双轨输出”思路：
- 轨道 A：原话文本（numerals=off），用于还原语境和取证
- 轨道 B：数字规范文本（在检测到数字段时 numerals=on），用于规则命中
同一段音频在不同阶段切换输出策略，能同时满足“可解释的证据”和“可计算的检测”。
3) 内部语音助手：口述报销/库存盘点
小公司很爱用语音助手做轻量自动化：
- “今天打车报销 48 块 5，发票号 1038”
- “A 仓库入库 12 箱，每箱 24 件”
这里 numerals=on 的价值是：让下游系统直接得到可用数字，减少 OCR/手填校对。
怎么在实时转写里切换：最小实现思路
核心就是在 WebSocket 实时转写过程中，发送一条 JSON 的 Configure 消息。
JavaScript 示例（与 RSS 内容一致）：
socket.send(JSON.stringify({
type: "Configure",
features: {
numerals: false
}
}))
Python 示例（与 RSS 内容一致）：
await ws.send(json.dumps({
"type": "Configure",
"features": {
"numerals": False
}
}))
把 numerals 设为 true 就开启，设为 false 就关闭。你可以在一个会话里发送多次配置消息。
什么时候切？两种常见触发方式
**触发逻辑越明确，体验越稳。**一般有两种：
-
意图触发（推荐）：
- 识别到“订单号/手机号/金额/地址/时间”等意图或关键词
- 进入“填槽位”状态 → numerals=on
- 槽位填完/用户确认 → numerals=off
-
按键/指令触发（最省事）：
- 坐席或审核员按快捷键“开始记号码”
- 或者用户说“开始报数字/结束报数字”
如果你在做语音助手与自动化工作流，我个人更偏向意图触发，因为它能减少人为操作，但一定要加“退出条件”，否则会长期处于 numerals=on。
常见坑：别让“数字更标准”反而影响审核与取证
**数字格式化是把双刃剑。**尤其在内容审核与舆情分析里，过度格式化会让你丢掉一些“行为线索”。
坑 1：拆分数字的规避行为被抹平
灰产喜欢说“1 3 8 …”或“幺 三 八 …”。如果你只保存格式化后的“138…”，你会失去“对方在刻意规避”的证据。
建议：
- 保存两份：原话转写 + 格式化转写
- 或至少保存音频时间戳与片段，便于复核
坑 2：不同数字类型需要不同校验
手机号、金额、订单号的校验规则完全不同。格式化只是第一步，后面要做字段级校验：
- 手机号：长度/号段/国家码
- 金额：范围（例如 0–100000）、币种、两位小数
- 订单号：校验位/固定前缀/长度
**审核系统最怕的不是识别错，而是“识别错还被当成真”。**所以要把校验当成工作流的一部分。
坑 3：中英文混合、单位词导致的解析误差
真实语音常常混单位：“one twenty five dollars”、“48块5”、“12 point 5”。你可以把 numerals 打开，但仍要在后处理里处理单位与小数表达。
我常用的做法是：数字格式化负责把数字变成数字；单位、币种、时间日期交给下游的解析器（规则或小模型）统一处理。
把它放进“内容合规审核”大叙事里：更少误判，更快闭环
在“人工智能在社交平台与内容审核”这条主线上，语音识别的价值不止是把音频变成文字，而是让平台的治理链路真正跑起来：识别→结构化→命中策略→留痕→处置。而数字恰好是最常进入结构化字段的内容。
实时可切换的 numeral formatting 给了你一个很实用的工程抓手：
- 需要理解语境时，保留自然表达
- 需要落库计算时，输出标准数字
- 需要取证时，保留可解释的原始文本或时间戳
如果你正在搭建 AI 语音助手与自动化工作流，把“数字字段的准确率”当成一条硬指标去看：**数字错 1 次，自动化就会在最关键的一步断掉。**你更愿意把时间花在规则调参和人工复核上，还是在数据入口处就把数字处理干净？
文章最后留个更值得做的下一步：你的审核/客服/运营语音里，最常出现的三个数字字段是什么（金额、电话、时间、地址、订单号）？把它们列出来，再决定哪里该开 numerals、哪里该关——你的自动化链路会立刻清爽很多。