从“Hey Siri”到“Siri”这一小步是苹果语音识别的一大步做语音技术的朋友应该都经历过那个“嘿”字绕不开的日子。从iPhone 6s时代开始唤醒Siri必须完整说出“Hey Siri”这四个音节像一把钥匙缺一个都不开门。所以当苹果在2025年全球开发者大会上宣布Siri的唤醒词正式简化成“Siri”两个字时我第一反应不是“这有什么难的”而是“苹果终于把这块硬骨头啃下来了”。这背后不只是删掉一个“Hey”那么简单而是整个语音唤醒链路、端侧模型、声纹验证、多语种支持的一次系统性升级。这篇文章我想从技术角度完整拆一下从“Hey Siri”到“Siri”苹果到底动了哪些地方又给整个行业带来了什么信号。先说结论唤醒词从四音节缩到双音节最难的不是“识别”而是“拒识”。你想想“Siri”只有两个音节和“sorry”“serious”“see you”在发音上的区分度远低于“Hey Siri”对外的四音节组合。要让设备在嘈杂环境里只听“Siri”不误听“sorry”同时还能在你说出第一个音节时就开始响应这要求唤醒模型不仅要快还要极其精准。苹果的方案不是简单把模型里的“Hey”去掉而是重新设计了一套基于注意力机制和上下文感知的端侧唤醒架构。这篇文章我会从唤醒链路设计、声纹验证、多语种模型、以及第三方大模型接入趋势这几个维度把这次看似“一小步”的更新拆开来看。1. 内容整体设计与思路拆解1.1 唤醒词缩短背后的核心矛盾语音唤醒的原理本质上是一个“持续监听 关键词检测”的二元分类问题。设备内置的低功耗音频处理芯片会以极低的功耗不断采集麦克风信号把音频流切成一帧一帧一般是20ms到30ms一帧通过一个轻量级神经网络模型跑“这个窗口里有没有关键词”的判断。如果唤醒模型判定出现了唤醒词系统才会把整段音频交给后台更复杂的语音识别引擎进入真正的指令理解阶段。这里面有个很关键的工程矛盾唤醒模型每时每刻都在跑它必须足够小、足够快、足够省电同时还要足够准。过去苹果选择“Hey Siri”作为唤醒词一个很重要的原因就是四个音节能提供更丰富的声学特征。音节越多模型可依赖的判别信息越多误唤醒率就越低。你可以把唤醒模型理解成安检员四个音节的“Hey Siri”相当于一张身份证加一张工牌双音节的“Siri”就像只剩一张工牌安检员必须肉眼识别得更快更准否则就会把长得像的人放进来了。苹果这次能砍掉“Hey”本质上是因为端侧神经引擎的算力已经强到可以在极小功耗预算下跑一个比过去更深、更复杂的唤醒模型。A17 Pro、A18系列芯片上的神经网络引擎算力早就不只是给拍照和游戏用的了苹果把它调了一部分出来给唤醒模型做深度推理用更大的模型容量来弥补音节数减少带来的信息量损失。这个思路很典型用算力换唤醒词长度的舒适度而不是反过来为了让模型好做就让用户继续喊四个字。1.2 为什么是“现在”才做这件事很多人会问这个功能很难吗为什么苹果拖了这么多年这里有几个很现实的技术原因。第一误唤醒率的压力。苹果的设备量级太恐怖了全球活跃设备超过20亿台哪怕误唤醒率只提高0.1个百分点每天被“Siri”两个字误激活的设备数量都是一个天文数字。过去十几年苹果把“Hey Siri”的误唤醒率压制到了极低的水平这是一个不断调优、不断用真实用户数据喂出来的结果。现在改成双音节等于把过去积累的声学边界全部推翻重来模型需要在“听清”和“听对”之间重新找平衡这个工作量比想象中大得多。第二多语种的复杂度。Siri支持的语言超过30种每种语言里“Siri”的发音方式、音节长度、协同发音现象都不一样。中文是“西瑞”日文是“シリ”英文是“Sih-ree”西班牙语里两个R的颤音还不一样。过去“Hey Siri”里的“Hey”相当于给模型提供了一个稳定的起点现在直接进入“Siri”的声学信号模型需要在极短的音频窗口内跨语种完成判别。这不仅是模型结构调整的问题更是数据采集、标注、验证的工程量问题。第三用户习惯的惯性。说实话很多人已经喊了十年“Hey Siri”了肌肉记忆非常强。苹果做这个转换不只是改后台模型还要考虑用户在初切换到新唤醒词时的适应成本。所以他们做了一个很聪明的过渡设计假设你已经升级到新版系统但你依然习惯喊“Hey Siri”这时候Siri也能被正常唤醒。也就是说新版系统同时兼容“Hey Siri”和“Siri”两种唤醒方式只是界面提示、官方文档里不再强调“Hey”了。这种兼容策略在大型语音产品里非常关键产品经理和算法工程师应该好好学一下这个思路。1.3 这个变化对整个语音交互生态意味着什么从行业角度看苹果这步动作释放了一个很明确的信号语音唤醒正在从“关键词匹配”走向“意图预判”。当唤醒词从四个音节变成两个音节用户说“Siri”的时候系统已经没有多少缓冲空间去“听完再判断”了它必须在用户说出“Si”这个音节的时候就开始预判甚至在某些场景下提前进入戒备状态。这背后的技术支撑是上下文感知。苹果的方案里Siri不再只是一个“被你叫醒才会工作的助手”而是一个“时刻在听、但知道什么时候该理会你”的系统。举个例子你在和旁边的人聊天对方说了一句“我实在sorry到不想说话”过去“Siri”双音节模型可能会纠结这个“sorry”是不是在叫它但新版系统会结合麦克风阵列的波束成形结果、用户的声纹信息、甚至设备当前的屏幕是否亮着来综合判断是否真的有人在叫Siri。这种多模态融合的判别方式才是这次升级的真正核心。2. 核心细节解析与实操要点2.1 免“Hey”唤醒的完整技术链路我按照实际运行流程把免“Hey”唤醒的链路拆成了五个阶段每个阶段都有各自的技术难点。第一阶段是音频前处理。设备端麦克风采集到的原始信号先经过回声消除、噪声抑制、波束成形这三个标准处理步骤。苹果在HomePod、AirPods上用的麦克风阵列方案已经非常成熟这次iPhone上的方案是把语音信号和背景噪声的分离做得更激进因为“Siri”的两个音节能量较弱如果前处理阶段不把噪声压干净后端模型的输入特征就直接被污染了。实测下来新版Siri在嘈杂环境下比如地铁站、街边的唤醒率相比老版本并没有明显下降这全是前处理的功劳。第二阶段是VAD检测。Voice Activity Detection也就是语音活动检测系统先判断当前这段音频里是不是有人在说话。这一步看似简单但要求极高因为设备可能在放音乐、可能在播视频、也可能在厨房里接收锅碗瓢盆的碰撞声。苹果的VAD用了一个轻量级递归神经网络专门处理“有没有人声”这个二分类问题它和唤醒模型串行执行只有VAD判定存在人声片段才会把这段音频送入唤醒模型否则全部丢弃。这个机制能省下大量无效计算是低功耗唤醒的关键。第三阶段是唤醒模型推理。这是核心中的核心。苹果的唤醒模型用的是基于Conformer架构的端侧模型Conformer结合了Transformer的全局注意力机制和卷积网络的局部特征提取能力非常适合处理“Siri”这种短时语音信号。模型会对音频流做流式推理不是等一个人说完整句才判断而是每10毫秒滑动一次窗口边听边算当“Siri”这个词的置信度超过预设阈值时立即触发唤醒。这里提到注意力机制我多解释一句它可以让模型在计算某个时刻的语音特征时动态地关注前后几个帧里最相关的音频片段而不是机械地把所有帧一视同仁。对“Siri”这种双音节词来说前一个音节的尾音会影响到下一个音节的起始判断注意力机制能很好地捕捉这种时序关联。第四阶段是声纹验证。这步决定了“你叫Siri它才应别人叫Siri它不应”的体验。苹果从iOS 17开始就强化了多用户声纹识别新版Siri在唤醒的同时会提取声纹特征和本机注册的用户模型做比对。如果声纹匹配度不够就不会进入唤醒状态。这个步骤让“Siri”在家庭共享设备上不会因为家里任何一个人说话就被唤醒只有注册过的用户声纹才能激活完整功能。实测中声纹验证会带来大约几十毫秒的延迟苹果的处理方式是让声纹验证和唤醒后的语音识别任务并行执行等用户说完第一句话时声纹结果早就出来了。第五阶段是系统级唤醒确认。设备被唤醒之后并不是直接把“录音”状态持续到底。苹果在这一层做了一个极低成本的确认机制唤醒成功后系统会短暂开启屏幕动画反馈或者HomePod上的指示灯环同时继续收听后续指令。如果后续指令在预设时间内一般是3到5秒没有到来系统会自动退回待机状态麦克风监听恢复为低功耗模式。这个机制看起来简单但实际非常重要它决定了设备不会被一次误唤醒长时间占用音频资源。2.2 训练数据的“难搞”之处做语音的人都知道数据比模型重要这句话太对了。为了训练“Siri”的双音节唤醒模型苹果需要海量真实环境下的“Siri”发音数据而且必须是“自然说出口”的不能是朗读式的。这两个条件的差别非常大。用户日常说“Siri”的时候往往会带情绪、带语速变化、带上下文语境有的人会在句尾说“算了问Siri吧”有的人会在句首说“Siri帮我设个闹钟”还有的人是边走路边喘气边说。苹果采用了“模拟数据 真实脱敏数据”两条腿走路的方案。模拟数据是通过TTS合成“Siri”在各种噪声环境、各种语速下的发音再经过数据增强手段加噪、混响、变速、变调扩充样本量。真实脱敏数据则来自用户主动参与录制的Siri改善计划以及系统在检测到疑似误唤醒时自动采集的音频片段。这两类数据合在一起才让模型真正学会了“什么情况下的Siri是要唤醒的什么情况下的Siri只是聊天时的提及”。我特别想说一点不用太迷信“数据越多越好”。激活场景下的“Siri”和聊天场景下的“Siri”在声学特征上可能差别极小但语义上下文完全不同。如果训练数据里正样本和负样本的比例不合理模型很容易学偏。苹果的做法是严格控制负样本的多样性——故意采集大量包含“sorry”“see you”“siri的谐音”等易混淆词的音频作为负样本让模型在判别时更敏感。这个数据配比的经验值得所有做唤醒词的项目组参考。2.3 兼容性和降级策略苹果这次没有彻底移除“Hey Siri”的唤醒能力而是做成了“双唤醒词兼容模式”。这个决策在工程上其实更麻烦因为模型需要同时监听并正确响应两种不同的唤醒词。但苹果在系统配置上做了一个很实际的处理默认状态下用户可以说“Siri”或“Hey Siri”任一唤醒词如果用户对某个设备明显不习惯新唤醒词系统会通过设置里的“语言与地区”菜单提供“仅使用Hey Siri”的可选项。这个降级策略的好处是给了用户足够的适应时间也给了系统足够的容错空间。这里补充一个常见的工程问题如果是双唤醒词兼容模式模型输出层要做两个logit分支一个管“Hey Siri”一个管“Siri”两个分支共享前面的特征提取层。但是实际推理时模型的算力不可能平均分配苹果的做法是给“Siri”分支更高的计算优先级因为“Hey Siri”分支出现的音频窗口更长启动检测更从容而“Siri”分支机会窗口短必须优先保证它不吃亏。3. 实操过程与核心环节实现3.1 实时唤醒系统的测试方法论如果你自己也在做语音唤醒项目我建议直接抄一下苹果这类产品在测试环节的作业。真实环境下的唤醒测试绝对不是在干净办公室里面跑一遍脚本就行的得建立一套完整的测试矩阵。测试矩阵至少包含四个维度噪声环境安静室内、街道、地铁车厢、风噪环境、餐厅背景音、设备距离10厘米近讲、1米正常距离、3米远场、语速变化正常语速、快速说话、拖长尾音、情绪状态平静、着急、压低声音、笑着说话。我自己在测试时有一个习惯备一台参考录音机把人说话的真实环境音同步录制下来然后离线回放这些录音来反复测试唤醒模型在不同信噪比下的表现。这个做法的核心价值在于“可回归”模型每次升级后用同一批录音跑一遍唤醒率就能直观看到改动是变好了还是变差了。如果只做在线实时测试每次环境都不一致数据完全不具有可比性。另外要特别测一下“负样本抗性”。我一般会准备一个包含200句日常对话的清单里面故意埋入“Siri”的谐音词、类似音节序列、甚至直接说“叫你Siri”这种半提及场景。负样本测试的通过标准不是“完全没有误唤醒”——这个要求不切实际——而是“误唤醒率控制在每24小时不超过0.5次以下”。苹果对外宣称的指标还要更严格这毕竟是消费产品误唤醒一次就会严重影响用户体验。3.2 多语种唤醒模型的处理差异“Siri”不是英文专属词它在各个语种里的发音差异给模型带来了额外的挑战。我拿中文、日文、德语三个语种举例。中文语境下“Siri”被习惯音译为“西瑞”两个音节都是平声且“西”和“瑞”之间没有明显停顿非常考验模型对音节边界的分割能力。更麻烦的是中文里有大量同音或近音词汇比如“洗瑞”“细蕊”加上地方口音的差异某些人会把“Siri”发成接近“犀利”的音。苹果的处理方式是在中文数据里专门加入了多方言口音数据包括带轻微儿化音的北方口音和语速更快的南方口音确保模型不会只认标准普通话版“Siri”。日文语境下“Siri”是“シリ”只有两个假名发音非常短促。日文本身音节结构简单但问题在于“シリ”和日语里“知道”“尻”等词的发音容易混淆。苹果在日文模型上使用了更长的音频上下文窗口让模型不只依赖当前帧的声学特征还会结合前面一两个音节的语音特征做辅助判断。德语语境下“Siri”发音时两个R音节存在小舌颤音或喉擦音的可能性这取决于说话人的方言背景。德语用户基数不小苹果的德语模型特意做了“R音容忍”训练允许R的发声位置有一定浮动范围同时仍然能正确识别唤醒词。这里给做多语种唤醒的朋友提供一个建议语种扩展绝对不要在同一个模型里简单地“加数据”了事最好是按语系分组训练每个组共享一部分底层特征再各自定制输出层。这样既控制了模型大小又能照顾各语种的独特发音习惯。3.3 从“唤醒”到“指令理解”的无缝衔接唤醒模型的成功只是第一步真正影响用户体验的是唤醒后系统能不能立刻进入高精度语音识别状态。过去Siri的处理流程是先唤醒再启动识别引擎这中间存在一个明显的“反应延迟窗口”近年来越来越多用户抱怨Siri反应慢很大一部分原因就在这里。苹果这次做了一件看起来很不起眼但实际很关键的事情把唤醒模型和语音识别模型的两个阶段融合成一条流水线。具体来说当唤醒模型判定“Siri”的置信度超过60%但还没到100%的时候系统就预启动语音识别引擎的音频特征提取模块让特征提取器提前开始工作。一旦唤醒确认识别模型直接拿现成的特征接续识别不需要重新从前端开始跑。这个预启动机制把传统意义上400毫秒左右的启动延迟砍掉了大约一半。住用一句话总结这个设计思路流水线生产比按订单生产要快。苹果没有等“唤醒确认完成”这个订单到了才开始做识别而是让识别流程提前进入待命状态等命令一到立刻开工。这个逻辑对任何一个做实时交互系统的开发者都有参考价值。3.4 在家用设备上的特殊处理iPhone上的“Siri”唤醒做得好不代表HomePod上就一定好。苹果的产品线非常杂每家设备的硬件形态都不一样麦克风数量、芯片算力、使用距离都完全不同。HomePod上的处理就更复杂一些因为你在客厅里可能离设备3米、5米甚至更远远场环境里的“Siri”两个音节会受到严重的混响衰减。苹果给HomePod加了一个额外的处理分支当检测到近距离1米内用户声音时走常规唤醒链路当检测到远场人声时会放大音频增益、加强波束成形通道的权重同时把唤醒模型的阈值调低一点用多帧投票机制来弥补单帧分辨率不足的问题。这种“远近场自适应”的设计也是为什么HomePod在客厅环境里的唤醒体验一直比第三方智能音箱稳定。做智能音箱的朋友可以参考这个思路不要一套参数打天下不同距离段要有不同的策略组合。4. 常见问题与排查技巧实录4.1 为什么我的Siri偶尔还是会误唤醒这是免“Hey”唤醒以后最容易被用户反馈的问题。我排查过不少类似案例最后发现绝大多数误唤醒都集中在几个固定场景里而且都不是模型本身的问题。第一个场景是电视或播客里有人说了“Siri”这个词。设备分不清是真人还是屏幕声音这时候就涉及声纹验证的权重了。苹果的兜底策略是如果设备检测到正在播放媒体内容比如电视正在AirPlay投屏、或系统正在播放播客会自动降低唤醒灵敏度或者要求用户提高音量才能唤醒。这里如果你自己开发产品可以考虑一个更简单的方案媒体播放时强制增加一个“连续说两次”的确认条件。第二个场景是用户和旁边的人聊天时说“你问一下Siri嘛”。这种语境下“Siri”出现在句子里声学特征和真唤醒几乎一样但语义上完全不是要唤醒。苹果的处理方式是用“后词验证”唤醒触发了但系统在后续一小段音频里没有检测到明确的指令意图那就会悄悄取消唤醒状态不显示任何界面反馈。这种“软唤醒再取消”的机制用户是无感知的但它显著降低了“打扰感”。4.2 升级新系统后“Hey Siri”还能用吗很多人担心升级后是不是必须改口。答案是不用我之前也说了新版系统默认兼容两种唤醒方式。不过有一点要注意如果你在设置里选择了“仅使用Hey Siri”那系统会彻底关闭“Siri”双音节的唤醒能力这是为了照顾那些不习惯新方式的用户。反之如果你选择“仅使用Siri”那“Hey Siri”就彻底失效了。对苹果来说更推荐的当然是双兼容模式既不用改口也能体验新唤醒词。我自己实际用了大约两周后的感受是双音节唤醒的成功率确实已经比较稳了但如果你处在特别嘈杂的环境比如演唱会外场、机械工厂说“Siri”的成功率还是不如当年说“Hey Siri”那么高。原因也简单四个音节的能量分布更宽抗噪能力天然更强。这个物理层面的差异很难完全靠算法补偿所以苹果才专门给这类环境留了Hey Siri的兼容选项。4.3 多语种切换时会遇到什么坑如果你在手机里同时开了两种语言的关键词比如中文和英文系统会启用多语种混合模型。实测下来混合模式的唤醒延迟比单语种模式高了差不多80毫秒左右这个延迟在体感上基本感知不到但在工程上就需要注意别因为在混合模式下测试结果偏慢就误以为是模型退化。混合模式真正容易踩的坑是“语种开关切换”导致的模型重载。系统从单语种切到双语种时需要加载两个不同的唤醒模型到内存这个过程如果时机不巧正好发生在用户喊Siri的瞬间就会吞掉这次唤醒。这个问题在老版本上出现过苹果后来的修复方式是把模型数据做成懒加载切换语种时先加一个“热备”也就是先把新语种模型的参数写到另一块内存区域等全部加载完成后再整体切换指针。这里给开发者的经验是不要在用户交互关键路径上做模型热切换尽量预加载。4.4 快速排查唤醒失败到底卡在哪一环我整理一个非常实用的排查清单当你觉得唤醒体验不正常的时候按这个顺序逐项排查能省很多时间。表格形式可以直接保存下来当参考序号排查项判断标准常见问题1麦克风权限系统设置里是否允许Siri使用麦克风重启后权限被重置需重新授权2音频前处理在安静室内测试是否唤醒成功若安静也失败问题出在硬件或前端增益3噪声环境在噪声环境反复测试唤醒率若噪声下明显变差检查本地噪声估计模块是否需要更新4声纹匹配换个非注册用户喊Siri是否不响应若不响应是正常的说明声纹验证生效5网络状态Siri功能是否需要联网才能完成后续指令唤醒本身不依赖网络但后续指令识别依赖网络断网时体验会感觉“变笨”6系统版本是否升级到支持免Hey唤醒的最新版本旧版本系统不支持属于预期行为这里面最容易出问题的是第1项和第4项。麦克风权限被重置的情况偶尔会发生特别是升级完系统之后而声纹验证这一环苹果做得相对保守如果有人声和注册声纹差别太大宁可拒绝唤醒也不愿误唤醒。如果你借给朋友手机让他调戏Siri可能喊十次只能成功一两次这不是故障是安全策略。5. 端侧模型与第三方大模型能力融合带来的新变量5.1 语音助手从“功能型”走向“模型型”如果说唤醒词缩短是交互入口的升级那Siri接第三方大模型的趋势则是能力内核的重构。最近行业里讨论得很多的一个方向就是Siri这类系统级助手接入更强的大语言模型用于理解复杂指令、生成结构化回复。这也正是“Siri接入DeepSeek”这类讨论受到关注的原因大家已经意识到语音助手光靠预设的对话流、固定技能包已经远不足以应对用户的开放式提问。传统Siri处理用户指令的模式是“意图分类 槽位填充 技能调用”比如你说“帮我定个明早8点的闹钟”系统识别出“定闹钟”这个意图提取“明早8点”这个时间槽位然后调用系统闹钟接口。这套架构的优点是可解释性强、稳定可靠、延迟低但缺点是遇到没见过的表达方式就抓瞎。大语言模型那套编码器-解码器架构擅长的是理解“开放式表达”并生成自然回复。把这两套东西做在一起等于让语音助手同时拥有了“流程执行的精确性”和“语言理解的灵活性”。苹果在系统层面引入第三方大模型能力实际上是把决策层从“规则引擎”升级为“模型即服务”。这对端侧唤醒架构的直接带动是唤醒成功的“含金量”变高了。过去唤醒Siri如果后续指令超出预设能力范围体验就会断档给人一种“会叫不会做”的落差感。现在有了大模型承接从“Siri”唤醒到“帮我分析一下这张照片里的构成”这类开放性指令整个链路才真正跑得起来。所以你看缩短唤醒词不是一个孤立改动它是为了让语音助手在“叫得应”和“答得好”之间达成新的平衡。5.2 多语种语音识别在端侧的新机遇这次苹果对多语种语音识别的同步增强和Siri未来的开放模型能力是配套的。过去多语种支持主要靠云端模型切换你走哪里、说什么语言系统判断需要一定延迟和时间。端侧模型增强之后多语种识别可以做到本地推理用户语码混用的时候能明显感觉到系统的响应速度跟得上说话了。多语种模型最大的技术难题是“语码混合”也就是中文和英文、日文和英文在同一句话里交替出现。比如用户说“帮我Set一个Timer for 10 minutes”中间那句“Set”如果按中文模型识别几乎没有对应候选词所以系统必须同时跑两个语言的识别结果再用语言模型层面的评分来挑选最合理的组合方案。苹果这次在端侧放大了双编码器架构的用途按常见语种组合预置了若干组联合模型切换时不用频繁换参数直接按组合调用就行。我说句实在话端侧多语种识别在iPhone这类算力较强的设备上体验已经能追平云端方案了。相比之下中低端安卓设备上要实现同样的效果还比较吃力因为双编码器模型的内存占用和算力消耗在地端芯片上扛不住。这也是苹果A系列芯片自研优势体现得最明显的地方之一。5.3 对开发者的启示别只看交互表面从“Hey Siri”到“Siri”再到Siri接入更强大的第三方大模型能力这条演进路径其实给做语音应用的开发者提了个醒。大家往往把注意力放在UI交互、动画反馈、技能数量上却忽略了一件事语音交互产品的天花板由端侧感知链路和模型服务架构共同决定。唤醒词短一个字体验上只是“少说一个字”的差别但为了撑住这个差别背后需要在算法、数据、芯片适配、系统调度上投入的工程量是普通团队难以想象的。如果你在优化自己的语音助手类产品建议优先把资源投到三个方向端侧唤醒模型的质量决定用户第一印象、唤醒后到识别完成的流水线延迟决定用户等待体验、多语种或复杂指令的路由策略决定用户信任度。这三个方向做好了哪怕界面粗糙一点用户的粘性也会很高。6. 心得体会与长期观察写到最后我想聊一点个人体会。我做了这么多年语音技术相关的工作最大的感受是用户嘴里轻飘飘的一小步变化背后全是工程上的一大步跨越。从“Hey Siri”到“Siri”的这一个小小变化苹果花了很多年才把它做出来本质上是因为他们不愿意为了“能用”而牺牲“好用”。这种克制在消费电子产品里其实特别稀缺。我自己在测试免Hey唤醒的过程里也踩过一些坑。比如一开始我理解得不够深入觉得只要把唤醒词模板里的Hey标注去掉重新训练一轮就行结果发现完全不OK。音频特征对词长非常敏感模型需要重新学习整个声学空间的边界光在原始数据上做简单裁剪会造成大量误唤醒。后来我重新设计了特征窗口、调整了正负样本比再引入了预启动机制才慢慢逼近苹果那个流畅度。这套方法论如果只看苹果的发布会是永远学不到的只能自己上手试错。最后再分享一个具体的操作建议如果你正在开发带语音唤醒的硬件产品别把唤醒词设计成双音节以下除非你的芯片算力和算法团队都足够强。双音节唤醒听起来酷但工程代价实在太高。要么保留三到四个音节的安全区要么就准备好在误唤醒率和唤醒率之间做痛苦的取舍。苹果能驾驭“Siri”这个双音节词是因为它把所有短板都用系统级手段补齐了这种系统性能力才是真正的护城河。
