最近语音 AI 圈子里有两件值得放到一起琢磨的事Neuphonic 开源了 43MB 的语音决策模型 NeuDecide主打不经过 ASR直接把用户语音变成工具调用另一个是法国 Mallow 团队推出的儿童无屏语音游戏音箱靠 AI 实时听孩子说话、接住每一句回答驱动游戏剧情往前走。前者面向开发者后者面向家庭用户表面看一个是模型、一个是硬件但它们指向同一个趋势语音交互正在从“先听懂、再思考、再回答”的老三段往“听见就行动”的方向塌缩。这两件事适合谁读如果你是做语音助手的、做 IoT 产品的、或者正在纠结“要不要把 ASR 从链路里拿掉”的这套拆解应该能帮你想清楚。如果你是做儿童内容或教育硬件的Mallow 的产品定义也会给你一个参考样本无屏不是功能缺失而是一种主动选择的交互约束。1. 为什么把这两件事放在一起看1.1 传统语音代理管线里ASR 不是免费的过去几年我们聊语音代理默认的链路都长这样麦克风采集音频 → 唤醒词 → ASR 转写成文本 → NLU 理解意图 → 对话管理 → 决策 → TTS 说出来。这个架构成熟、工具多、调试直观但它有几个被大家默默接受的问题。第一是延迟叠加。ASR 本身要等一个完整句子的边界一般要攒到 300 到 600 毫秒的音频才敢出结果转写又需要几百毫秒后面 NLU 再跑一次一轮对话的“思考时间”轻松超过一秒。用户只感受到一个字慢。尤其在做工具调用时中间每多一跳延迟预算就要多一分。第二是错误级联。ASR 一旦转错后面全错。有些场景里用户说“帮我定明天七点的闹钟”ASR 听成“明天七点钟”意图层可能就懵了。这种错误不是靠 NLU 优化能完全解决的因为信息已经在转写那一步丢了一部分。第三是韵律信息被抹掉。语音里除了词还有停顿、语气、重音、迟疑。文本化以后这些全没了。用户说“嗯……那好吧”和“好的”转写出来可能都是“好的”但意图强度完全不一样。ASR 后端模型做得再好原始音频里的这些线索也拿不回来。所以当 NeuDecide 这类“语音决策模型”出现的时候我第一反应不是“又多了一个模型”而是“终于有人把 ASR 从决策路径里请出去了”。1.2 从儿童无屏音箱反推产品需求无屏带来了什么再看 Mallow 的这款无屏语音游戏音箱。很多人第一眼会问都做 AI 音箱了为什么不加个屏加了屏看起来信息量更大、玩法更多。但如果你真的在家庭场景里待过就会发现屏幕恰恰是最大的干扰源。儿童产品面对的竞争对象是平板、手机、电视上的视频内容。屏幕意味着高刺激孩子看着屏幕注意力就被吸过去了。无屏设计把交互压缩到“听”和“说”两个通道孩子必须在脑子里建立空间想象和推理而不是被动接收画面。这其实是刻意在产品能力上做减法。但做减法不意味着技术也做减法。正因为没有屏幕语音就成了唯一的交互通道。孩子说“我要红色的龙”音箱就不能显示“红色龙”三个字而是直接推动游戏草丛里钻出一条红龙它希望你帮它找到三颗火石。所有的状态、道具、剧情反馈都必须通过语音呈现这要求 AI 对每一句输入的响应都足够快、足够准。实时听孩子语音这件事不是为了炒作“AI 实时”而是这种产品形态的基本功。从另一个角度看这是在消费者硬件里验证语音决策模型的价值低延迟、低算力、端侧或近端侧部署、口语化指令直接驱动逻辑。和 NeuDecide 面向的场景高度重合。1.3 两条线交汇语音模型开始直接“行动”我会把这两个项目放在一起主要是因为它们代表了语音 AI 的一种范式变化语音不再必须先变成文字再变成意图最后变成行动。初级版本是直接学习“声音 → JSON 动作”的映射高级版本是让模型在音频语义空间中做推理。这对开发者的影响很大。以前你要打磨 ASR 的领域专名、同音字、口音还要写规则把文本映射到参数槽位。如果语音决策模型能把“音频 → 结构化动作”这件事做稳很多中间工程就可以省掉。Mallow 这类团队从第一天起就不用管“ASR 是不是把儿话音丢了”只要把“孩子说了这句话之后应该触发什么剧情节拍”做好就行。当然这也不是说 ASR 就该被淘汰。后面我会详细分析端到端方案的局限但至少从趋势上看语音交互的软件栈正在变薄这是好事。2. NeuDecide 核心拆解43MB 的语音决策模型怎么工作2.1 模型定位从语音到意图而不是从语音到文本NeuDecide 这个模型给我的第一印象是两个词小、快。43MB 的权重体积说明它设计之初就是奔着“低资源设备可跑”去的而不是那种只能在数据中心里烧卡的大模型。它做的事情可以理解为输入一段语音直接输出工具调用的结构化结果。比如“帮我把客厅灯关掉”模型输出的不是“帮我把客厅灯关掉”这句文本而是一个意图动作{action: turn_off_light, room: living_room}这样的一件事。这种能力的关键在于训练目标。传统模型的训练目标是预测下一个 token也就是字符或词NeuDecide 这类语音决策模型的目标是预测决策结果。它可以学习“用户语音的声学特征 → 语义嵌入 → 工具动作”的映射。模型内部可能仍然有一个语义表示层但它不需要把词序完整还原。换句话说它抓住的是“你要干什么”而不是“你嘴里说的每个字是什么”。这个思路听起来简单实践上有门槛语音里包含说话人特征、背景噪声、音调变化模型必须学会忽略与决策无关的信息只保留任务相关语义。要做到这一点需要在训练数据里构造大量的“换说法、换口音、换环境但动作不变”的样本让模型自己学出稳定的决策表示。2.2 43MB 背后的压缩逻辑很多人看到 43MB 第一反应是“这能智能吗”实际上模型体积小不代表能力弱关键是看它的任务边界被压缩到什么程度。一个通用语音助手可能需要认识几十万个词但一个工具调用模型的词表可能只要覆盖几千个核心词和上百个动作名称就够了。从工程角度推测43MB 大概率是这样组成的一个紧凑的语音编码器负责把音频变成语义向量一个小型决策头负责把语义向量映射到工具参数空间。编码器可以用类似蒸馏的方式从一个更大的语音理解模型中压缩而来决策头则根据具体工具集训练。如果再做 int8 量化体积还会下降推理速度也能提升。这给开发者的启发是别追求一个模型什么都能干先定义清楚“我要让它决策什么”。比如一个音箱只需要十几种动作那模型的有效词表就是这十几类参数规模完全不需要到 B 级。模型体积和场景广度是直接挂钩的。以下是典型的压缩方向对比维度传统语音助手模型轻量语音决策模型参数量级0.5B ~ 7B通常 50M ~ 300M输入文本来自 ASR音频特征或语义嵌入输出自由文本结构化动作/参数部署目标云端 GPU边缘设备/低功耗 SoC目标词表开放受控/按领域裁剪延迟数百毫秒到秒级百毫秒级2.3 工具调用的输入输出设计端到端语音决策模型的输出格式直接决定了它好不好用。NeuDecide 如果只是输出一个“动作 ID”那其实是把复杂问题简单化了。实际工具调用往往需要参数时间、地点、名称、数量等。合理的输出设计应该是一段结构化 JSON或者一组受限的 token 序列模型在解码时被约束只能生成给定 schema 内的字段。比如闹钟工具schema 是{time, label}音乐工具schema 是{playlist, device}。模型听到“放点爵士乐”就应该输出动作play_music参数playlistjazz。参数槽位怎么填是关键。传统的槽位填充是从文本中抽取实体而语音决策模型要直接从音频特征中映射出槽位值。这对训练数据的要求很高因为“五点半”和“五点四十”在听感上只有细微差别模型必须对数字、时间这类精确信息格外敏感。我建议如果你要复现或微调类似模型一定要把数字、时间、人名、地名这类实体强化合成到训练音频里。输出端的另一个问题是怎么处理“不确定”。模型给一个动作要附带置信度比如confidence: 0.92。开发者拿到这个值应该设两个阈值低于 0.6 直接不执行转向澄清话术在 0.6 到 0.85 之间执行前先让用户确认一遍。这个策略能避免很多尴尬的误操作。2.4 不经 ASR 的真实收益与代价先说收益。最直接的是延迟。端到端模型输入是音频特征不需要等待完整转写通常可以边听边推。模型输出结构化的动作 token也省去了 NLU 这一步。整体下来一个“听懂到行动”的延迟可以从传统方案的 1.2 秒左右压到 400 到 600 毫秒这是体感上“立即响应”和“慢半拍”的分界线。其次是可靠性。ASR 可能听错词但这种模型直接学习“哪段音频对应哪个动作”。在动作类别固定的场景里它能学会对同义词、口音、背景噪声的鲁棒性而不是依赖某个转写结果刚好命中规则。举例用户说“把灯灭了”和“关灯”传统链路可能依赖两个不同意图模板端到端模型只要训练数据覆盖了这两种说法就能学到同一个动作。代价也明显可解释性差。ASR 出错了你能看到转写文本定位是哪几个词错了语音决策模型出错你只能拿到一个意图结果不知道它是哪段音频特征让你走偏的。调试时需要大量回放音频和标注工程体验不如老链路。还有领域泛化的问题。传统链路在 ASR 后面加一个新意图只要追加几个文本模板就行端到端模型要加一个新动作通常得准备一批新音频样本重新微调。所以它不是万能的更适合动作集合相对稳定的场景。3. 从硬件角度看 Mallow 的无屏语音游戏音箱3.1 无屏交互的适用边界Mallow 把音箱设计成无屏我认为不是偷懒而是保护交互重心。但无屏也不是所有内容都适合。适合无屏的场景有几个共同点目标单一、需要持续口语对话、不太依赖视觉验证。讲故事、角色扮演、语言游戏、猜谜这些都可以在大脑里完成画面构建适合无屏。反之如果孩子需要看选项、做选择题、识别图片那没屏就非常难受。所以 Mallow 的产品逻辑应该是把游戏内容严格限定在“听力理解 口语表达 逻辑推理”这三类上。孩子说“我选择走左边那条路”音箱就描述左边的森林里有什么而不是弹出一张地图。这种体验用声音驱动是顺畅的。从开发者角度我的建议是如果你要做无屏语音产品先把“必须通过视觉才能理解的信息”列清楚。任何需要孩子盯住屏幕才能继续的节点都是在和产品形态作对。要么改造内容让它变成纯口头描述要么放弃这个功能。3.2 实时语音链路唤醒、聆听、决策、回复这类实时语音设备的技术链路比手机 App 复杂不少。它要一直开着麦克风但又不能把所有声音都传给云端或模型否则功耗、隐私、带宽都撑不住。一个典型的端侧链路是这样前端拾音与降噪麦克风阵列做波束成形锁定孩子的位置压制电视声、空调声、家里人说话声。唤醒词检测专用低功耗唤醒模型常驻运行检测“你好小 Mallow”之类的唤醒词其他时候不启动主链路。语音活动检测 VAD唤醒后判断孩子是否开始说话区分静音、噪声和有效语音段。流式语音识别或语义编码把音频流切成小块边采边处理不等整句说完。Mallow 如果要做到“实时”就得同时依赖流式输入和增量推理。游戏逻辑决策把识别出的语义或转写结果送入决策模块触发角色反应。语音合成播放用 TTS 生成角色台词或音效打断和重新播放都要顺滑。整个链路的核心要求是“低中断”。孩子语音游戏跟成人用语音助手不一样成人愿意等儿童一旦超过两三秒没有反馈注意力就开始漂。我见过一些儿童语音产品的测试数据响应超过 1.5 秒孩子就会重复说话或者直接放弃。所以 Mallow 这类设备的实时性不是参数上的炫技是维持孩子参与感的必需品。3.3 儿童语音识别的难点与调整儿童语音与成人语音的声学差异很大。孩子发声器官还没长成音调偏高、音长不稳、气声重很多词发音并不标准这给声学模型带来天然挑战。如果直接把成人 ASR 模型搬过来识别率会肉眼可见地下降尤其是低龄儿童。针对儿童语音常规做法是这几类用儿童语音数据做声学模型适配。但儿童语音语料稀缺且隐私敏感。提高系统对“半句话”的容忍度。孩子经常说一半就停或者把“我要”说成“我要要”决策模块要做容错而不是傻等。增加澄清机制。识别置信度低时游戏角色反问“你是说红龙还是蓝龙”用二选一缩小范围这样即使用户发音模糊系统也能通过约束选项把任务完成。扩大允许说法集合。孩子会说“那个红色的”也可能说“火龙”还可能说“我要那条红色的龙”训练数据一定要覆盖不同的口语表达习惯。还要注意多说话人的问题。孩子可能和兄弟、父母同时在场设备需要分辨“谁在跟音箱说话”。前端声源定位可以帮一部分忙但对语义层来说最好是能检测到多人对话时暂时不触发决策避免把父母之间的闲聊当成孩子的指令。3.4 产品体验细节从语音设计反推内容工程很多人低估了无屏音箱的内容制作成本。屏幕产品可以用画面交代剧情无屏设备所有信息都只能通过语音和音效来传达。设计角色台词时要说人话不能像念说明书。举例屏幕游戏里道具栏会显示“火焰石×3”无屏音箱就必须让角色说出来“你已经找到了两颗火焰石再找一颗我就能带你飞过火山口啦。”这种口播状态提示要频繁但不能啰嗦。每一次对话都承担两个任务推进剧情 状态反馈。这是儿童语音游戏内容工程的核心。另外音频反馈必须多样。同一个“回答正确”可以有好几种表达方式“太棒了”“就是这样”“红龙点点头”避免孩子听多了麻木。情绪表达要夸张TTS 要用有一定表现力的音色最好能支持带情感的 SSML 标记让模型在句尾拖长音或提高音调。Mallow 如果真想做出“游戏感”这块比模型结构更重要。4. 动手实践把“语音决策”思路搬进自己的项目4.1 先明确场景适不适合端到端我在测试过几类端到端语音模型之后的一个结论是别跟风替换先看你自己的场景。适合用语音决策模型的典型特点动作集合有限。比如开关设备、设定闹钟、选择菜单、控制游戏角色。需要超低延迟。用户说完马上要有反馈。部署环境算力紧张。内存和 CPU 都有限。隐私敏感。不愿把原始音频直接送云端或者不想保留中间文本日志。不太适合的场景包括需要开放域知识问答的需要逐字记事的比如听写、记录电话号码或者需要多种工具任意组合的。这些场景里 ASR LLM 的链路还是更有优势。4.2 一个最小可跑的本地决策流程这里我写一个示意性的流程方便理解。具体接口以你落地的模型为准。假设模型加载方式类似这样from speech_model import SpeechDecisionModel, ToolRegistry registry ToolRegistry() registry.register( nameset_alarm, description设定一个闹钟, params{time: HH:MM, label: 闹钟名称(可选)} ) registry.register( nameplay_music, description播放指定风格的歌, params{playlist: 歌曲风格或歌单名称} ) model SpeechDecisionModel.from_checkpoint(checkpoints/neu-decide-43m) # 从麦克风或音频文件读取一段语音 audio load_audio(user_request.wav, sample_rate16000) result model.decide(audioaudio, toolsregistry.schema()) print(result.action) # set_alarm print(result.params) # {time: 07:00, label: 明天起床} print(result.confidence) # 0.94关键点是registry.schema()把工具的 JSON Schema 传给模型让模型在受限动作空间里选择。如果没有这个约束模型输出很容易跑飞。拿到结果之后的处理逻辑我也建议统一if result.confidence 0.6: reply 我没太听清你是想调闹钟还是放音乐 elif result.confidence 0.85: reply f你是想定 {result.params.get(time)} 的{result.params.get(label, 闹钟)}吗 else: execute_tool(result.action, result.params) reply 已经帮你定好啦这个三段式处理帮我在实验里省了大量跟误触发搏斗的时间。4.3 延迟预算怎么算语音交互的延迟感知是个系统性的预算问题。设计目标建议定在用户说完话后 800 毫秒内给出反馈。这对很多产品已经比较舒适。接着把所有时间开销拆开看环节典型耗时优化思路麦克风采集与前端20 ~ 50ms低延迟音频驱动环形缓冲端点检测 VAD10 ~ 50ms用流式 VAD不等完整停顿语音编码/特征提取30 ~ 80ms小步长、并行计算决策模型推理100 ~ 250msint8 量化、ONNX/TensorRT 优化工具参数仲裁10 ~ 50ms规则校验不放大模型回复话术拼接10 ~ 30ms预置模板TTS 首包合成150 ~ 300msstreaming TTS不等全句合成完加起来大概 500 到 800ms体感上是“这个人反应很快”。如果其中 ASR 环节占掉 400ms整体就会突破一秒只能靠提前打断和抢话术来缓解体验打折。所以我做语音决策模型实验时惯性做法是先把音频队列和推理线程分开。采集线程只负责往队列塞音频块推理线程消费队列优先拿最近一包数据。不要让采集和推理在同一线程里互相等。4.4 接入工具时的鲁棒性设计语音决策模型比文本模型更容易出现“幻觉动作”。用户说了句“今天天气怎么样”你模型里没这工具它可能会硬输出一个不相干的 action。要抑制这种问题有几个操作层面的手段。第一在 schema 里显式加入一个拒绝类别。除了真实工具再加一个 action 叫no_action或clarify训练时把领域外请求的样本也放进去让模型学会“我不该处理”。这比单纯依赖阈值判断更可靠。第二参数值要做类型校验。模型输出time: abc时不要直接往闹钟模块传。先用解析函数验证格式不合规就进入澄清流程。第三对不可逆操作设置二次确认。比如“删除录音”“解锁关卡”高置信度也建议确认。设备语音是很轻量的操作多问一句不会太烦人。第四保留文本影子链路用于日志。虽然主链路不依赖 ASR但在开发调试阶段可以并行跑一个 ASR 把音频转写成日志。这样模型出错时你至少知道音频里的真实内容是什么。我在本地实验时就是这样定位问题的。5. 常见问题与避坑记录5.1 实测中的排查速查表症状可能原因处理方向模型频繁把无关语音识别成动作训练数据缺少领域外样本加入负样本和“不回应”类别换个口音/方言就失效声学多样性不足扩充多口音训练麦克风前端预处理数字、时间参数经常错决策模型对精确数字敏感度不够强化数字样本后接轻量槽位校验端侧推理卡顿模型未量化或线程未优化做 int8 量化调低采样并行度响应太慢但推理不慢VAD 等完整句尾才出结果改成流式半句推理或缩短端侧静音判定儿童音箱误唤醒唤醒模型被儿童音调触发调高唤醒阈值加入说话人方向校验连续对话后答非所问缺失角色记忆或状态重置维护短时上下文 buffer定期清理输出 JSON 偶尔语法不完整解码约束失效用约束解码不要说开放文本再解析5.2 几条独家实操心得第一录音回放是永远的神。我在做任何语音模型评测时会先录五十条真实场景语音存成 wav然后批量跑一遍模型把结果和音频一起列表对比。绝对不要在模型调试阶段用麦克风实时测试因为环境变量太多你根本分不清是模型的问题还是采集的问题。第二儿童语音场景必须做“预设答案收敛”。孩子在无屏游戏里自由表达时输入空间近乎无限但游戏推进只需要几个选项。不要指望模型能理解所有表达而是让游戏角色主动把范围缩小“你想先去湖边还是去山洞”把自由度收敛到两个选项决策模型准确率会大幅上升。第三延迟和准确率要放在一起调。只看准确率不管速度很容易把模型越调越大只看速度不管准确率又会陷入反复澄清。我建议先定延迟上限再在预算里找准确率最大的那个模型尺寸。比如目标端侧 150ms 推理那就把 43MB、100MB、300MB 的候选模型都压测一遍挑一个能同时在延迟和准确率两个指标达标的。第四TTS 的情感表达比想象中重要。语音决策模型再怎么强最终用户感知的是音箱说出来的那句话。普通 TTS 念“你好厉害呀”和带孩子声音说“你好厉害呀”是完全两种体验。Mallow 这类产品一定需要可控制韵律的 TTS至少要能调整语速、音高、停顿。我见过太多项目在 NLU 上花大力气最后栽在一句僵硬的语音反馈上。第五状态管理是这类系统的隐藏复杂度。多轮对话不是每一次都从零开始音箱必须记住孩子已经走到哪个剧情节点、答对了几道题、任务目标是什么。语音决策模型只负责“当下这句话怎么理解”游戏状态机要单独做。把状态存内存里不行断电重启就丢。最好落盘或走云端账户否则孩子第二天重新开机游戏进度全没了产品口碑会一夜崩塌。第六做真实设备测试时噪声源要覆盖完整。电视背景音、厨房水声、另一个孩子玩玩具的声音这些在实验室里想不出来的场景都会在家庭测试里出现。前端降噪和 VAD 参数一定要留出余量否则演示当天模型被旁白背景音干扰决策结果东一句西一句基本无法看。最后分享一个我自己的习惯每次接入新语音决策模型先不要直接替换老链路而是让它两条路并行跑一段时间。同一个音频流同时走旧的“ASRNLU”和新的“端到端决策”对比它们的动作输出、置信度和响应时长。这样能很快找出新模型的盲区也能给团队一个平滑切换的余地。语音交互的变化来得比大多数人想象中快但方法论还是老一套多测、多录、多复盘。