中英文混说时识别总跳语种？闪电智能VoiceAgent 如何稳定切换

中文客服电话里出现英文，并不等于用户把整段会话切到了英文。用户会说“帮我查一下 Mango X3 的 order status”，也会在中文句子里夹一个产品型号、App 名称或邮箱。要是 ASR 的某一次 partial 把 language=en-US，后面的 NLU、话术和 TTS 就全部跟着改成英文，体验往往会比一个错字更糟：用户还在讲中文，系统突然用英文追问。

我不建议把识别器每一次语言判断直接写进会话状态。语言识别是一个组件输出；“本轮该用哪种语言理解、回复和朗读”是会话编排的决策。两者混在一起，置信度再高也会把专有名词、短语和流式 partial 放大成全局切换。

这篇只讨论中文客服中 zh-Hans 与 en-US 的混说治理：怎样定义语言状态、怎样避免误切换、怎样在确实切换后恢复，以及 TTS 如何保留英文专名。它不评测任何 ASR 或 TTS 厂商，也不据此声称识别准确率或线上效果。

目录

• 一次 partial 为什么不该改写整轮会话
• 先分清三种“语言”
• 稳定切换的状态机：显式优先，隐式要累积证据
• 一份可运行的最小路由器
• TTS 不要跟着整轮翻译
• 该记录哪些日志，怎样判断恢复真的有效
• 适用边界：何时不能只靠策略层
• 参考资料

一次 partial 为什么不该改写整轮会话

下面是一段合成事件，目的是说明状态冲突，不是线上故障日志：

09:42:10.120 asr.partial text="Mango" language=en-US confidence=0.94
09:42:10.430 asr.final text="我要查 Mango X3 的订单" language=zh-Hans confidence=0.91
09:42:10.610 nlu intent=order_status

如果编排层在第一条 partial 到来时就设置 session.language = en-US，后续很容易出现两个副作用：中文意图路由改用英文话术模板；TTS 把“我为您查一下”交给英文声线。看起来像是“识别跳语种”，其实是状态更新时机错了。

partial 的职责是降低交互等待，不是作为用户语言偏好的最终证据。即使某个 ASR 服务提供稳定的语言置信度，它也只能说明这个片段更像某种语言；它不能证明用户希望接下来的客服流程、更不能证明朗读语言应整体变化。另一种容易误判的情况是：识别器没有变，词典中没有产品名，导致英文专名被转写坏了。此时先改会话语言，通常治不到根因。

对中文客服而言，更稳妥的规则是：partial 可以驱动 UI 或预取，但不得驱动会话语言切换；隐式切换只接受连续、足够置信的 final 事件。

先分清三种“语言”

“语言切换”在系统里至少有三层，很多实现把它们合成了一个字段：

这里的 zh-Hans、en-US 应被当作明确的数据契约，而不是散落在提示词里的自然语言。IETF 的 BCP 47 定义了语言标签及其匹配机制；项目至少要把上游别名如 zh、zh-CN 归一为内部允许的标签。这个归一动作只解决“同一语言被如何命名”，并不能替代语言识别本身。

闪电智能VoiceAgent 的工程接入可以把它们放在同一条 trace 上，但不要让一个字段兼任三个角色：

audio segment
-> ASR: detected_language + confidence + partial/final
-> dialog: session_language + candidate evidence
-> NLG: response_language
-> TTS: span_language[]

这样做的好处很实际：当用户说“我的 iPhone 16 Pro 维修单在哪”，系统可以保持 session_language=zh-Hans，只给 iPhone 16 Pro 一个英文或产品词典确认过的朗读 span。整句中文不用被迫转到英文 TTS。

稳定切换的状态机：显式优先，隐式要累积证据

真正的语言切换应该是一个受控状态转移，而不是一次字段赋值。我会先区分两条路径：

这不是说“两条 final”在任何系统里都正确。它是一个可配置的、偏保守的起点。客服流程短、用户会频繁中英夹杂时，可以干脆不做隐式全局切换，只把语言当作每个回复的局部选择；长会话且有完整音频、人工标注样本时，才值得离线比较一条、两条或带时窗的证据规则。

状态可以写成：

LOCKED(zh-Hans)
— final(en-US, confidence >= floor) –> CANDIDATE(en-US, 1)
— second final(en-US, confidence >= floor) –> LOCKED(en-US)

CANDIDATE(en-US, 1)
— partial(any) –> CANDIDATE(en-US, 1) # 不计入证据
— final(zh-Hans) / low confidence –> LOCKED(zh-Hans)
— explicit "English" –> LOCKED(en-US)

其中有两个容易被省掉的约束：

• 任务级作用域：上一通电话里用户用过英语，不代表下一张工单也要默认英语；新任务必须清掉猜测状态。
• 幂等事件：电话链路重放回调时，同一个 event_id 不能被累计两次，否则一次 final 会被误当成两次证据。

一份可运行的最小路由器

项目中的 examples/language_router.py 不做音频识别，而是把“识别组件输出”与“编排决策”拆开。核心代码如下：

if not event.is_final:
return Decision(state.current_language, False, "partial_never_switches_session")
if event.confidence < self.confidence_floor:
self._clear_candidate(state)
return Decision(state.current_language, False, "low_confidence_final")

if state.candidate_language == detected:
state.candidate_final_count += 1
else:
state.candidate_language = detected
state.candidate_final_count = 1

if state.candidate_final_count < self.required_finals:
return Decision(state.current_language, False, "awaiting_second_final")
return self._switch_now(state, detected, "two_high_confidence_finals")

这段代码验证的是状态契约，不验证 ASR 性能。它刻意留下了三个生产替换点：

• confidence_floor 要由真实的中英混说样本校准，不能从 Demo 音频照搬；
• “显式语言请求”应来自可靠的意图/按钮输入，不能只凭包含 English 的转写文本；
• 支持更多语种时，语言集合、回退话术、模型可用性和 TTS 声线必须一起扩展，不能只放开标签白名单。

在项目目录运行：

PYTHONPATH=. python3 -m examples.run_demo
PYTHONPATH=. python3 -m unittest discover -s tests -v

测试覆盖 partial 不切换、单个 final 不切换、连续 final 切换、低置信恢复、显式偏好、重复回调、任务重置和 TTS span 保留。它们通过只能说明规则在合成输入上的边界一致，不能推出真实电话中的识别效果。

TTS 不要跟着整轮翻译

语言切换的第二个坑出在朗读。客服通常需要的是“中文主句 + 英文专名或型号”，而不是把整轮 TTS 引擎改成英语。W3C 也指出，语言标注可帮助语音合成器选择合适的语言模式；这启发我们把语言信息保留在可定位的文本片段上，而不是只保存一份会话全局值。W3C：Why use the language attribute?

例如响应文本可以在 NLG 后变成明确的 span：

build_tts_plan([
TtsSpan("好的，", "zh-Hans"),
TtsSpan("Mango X3", "en-US"),
TtsSpan("的地址我先为您核对。", "zh-Hans"),
], session_language="zh-Hans")

这个设计要求上游词典、知识库实体或工具返回的产品名携带可信标签。不要让 TTS 再从一整句文字里“猜”哪几个字应该英文朗读；那会把读音问题重新变成另一个不可审计的分类问题。

涉及手机号、订单号、金额、地址或身份核验时，语言策略更不能替代字段确认。中英文转换可能改变数字读法或地址断句，关键字段仍应走逐段复述、屏幕确认或人工兜底，而不是因为“语种已锁定”就自动执行。

该记录哪些日志，怎样判断恢复真的有效

要判断“总跳语种”有没有改善，先别看一个笼统的语言识别准确率。至少记录能复盘状态转移的字段：

指标也要分层：

• 组件层：final 语言标签与人工标注的一致率。分母应是带标注的 final 片段，而不是所有音频包。
• 流程层：误切换率 = 被用户纠正或人工复盘确认的错误切换次数 / 发生隐式切换的会话次数。这里需要明确人工复盘口径，不能把“没有投诉”当作正确。
• 业务与风险层：因语言不一致触发的重复澄清、转人工、关键字段确认失败。它们受话术、业务复杂度和线路质量共同影响，不能反推为 ASR 的单独表现。

一个常见替代解释是网络抖动造成 final 乱序，或者客服平台重放了事件，表面看像语种来回跳。先按 event_id 去重、按音频时间而非到达时间排序，再评估语言策略；否则你会花时间调语言阈值，却没有解决事件时序问题。

适用边界：何时不能只靠策略层

这套状态机适合已经能获得 partial/final、语言标签和置信度的流式 ASR 链路，也适合以中文客服为默认服务语言、偶尔需要英文切换的任务。

它不适合直接处理以下问题：

• ASR 本身没有可靠的 final 事件、语言置信度或重复事件标识；应先补齐协议和日志契约。
• 用户本来就逐词中英混说，且回复要逐句跟随；这更像多语 NLG/TTS 的 span 编排，不应强推会话默认语言。
• 医疗、金融争议、身份、支付等高风险流程；语言策略只能帮助理解，关键决定和字段确认仍需受控验证或人工处理。

最终的可执行规则很简单：把“检测到哪种语言”保留为证据，把“系统要用哪种语言服务”作为可回滚的会话决策；只有用户明确要求或连续 final 支持时，才改变默认状态。

参考资料