语音助手这个品类过去几年一直处在一个挺尴尬的位置。你说它没用吧查天气、设闹钟、放音乐确实方便你说它聪明吧稍微复杂一点的问题就开始答非所问多轮对话超过两轮就彻底迷失上下文。我自己用过的几款语音助手从车载场景到智能音箱再到手机内置的体验基本停留在能听懂指令但听不懂人话的阶段。后来大语言模型火了之后我一直在琢磨一件事如果把大语言模型的语言理解和生成能力接到语音助手这条链路上它到底能变多聪明哪些环节是真正被改善的哪些环节其实还是老样子这篇文章就把我自己的实践和踩坑过程完整拆开从架构、选型、实操到效果验证一步步讲清楚。1. 语音助手不聪明的根因到底在哪1.1 传统语音助手的三段式流水线大多数人对语音助手的理解就是我说一句话它回我一句话。但拆开看传统语音助手其实是一条三段式流水线语音识别ASR→ 意图理解与对话管理NLUDM→ 语音合成TTS。这三段每一段都是独立模块各自有各自的模型和规则库。问题就出在这个独立上。ASR把你说的话转成文字但它只负责转文字不负责理解你真正想表达什么。NLU拿到文字后靠的是预先定义好的意图模板和槽位填充规则。比如你说帮我订明天下午三点的会议室NLU会去匹配订会议室这个意图然后抽取时间明天下午三点这个槽位。但如果你说我下午要跟团队开个会帮我找个地方传统NLU就懵了——因为它没有开会到订会议室的映射规则。对话管理DM更是个重灾区。传统DM靠的是状态机或者填槽式对话对话路径是预先设计好的。你偏离了预设路径它就不知道怎么接。这就是为什么传统语音助手多轮对话能力极差——它根本没有真正的上下文记忆只有当前槽位还缺什么。1.2 大语言模型改变了哪个环节大语言模型带来的最大变化是它把理解和生成这两件事统一到了一个模型里。你不需要再单独训练一个NLU模型去识别意图也不需要单独设计对话状态机。你给大语言模型一段系统提示词把用户的历史对话和当前输入一起塞进去它自己就能理解上下文、推断意图、生成回复。这意味着语音助手的架构可以从三段式流水线变成ASR → LLM → TTS的简化链路。中间的NLU和DM模块被大语言模型替代了。这个变化听起来简单但实际落地时涉及的问题非常多延迟怎么控制、上下文怎么管理、工具调用怎么设计、幻觉怎么抑制每一个都是坑。1.3 为什么更聪明不等于更好用这里要先泼一盆冷水。大语言模型确实让语音助手在语言理解上有了质的飞跃但更聪明和更好用之间还有一道鸿沟。语音交互和文字交互有本质区别文字交互你可以慢慢打字、反复修改语音交互是线性的、一次性的用户说完就等着回复延迟超过两秒体验就崩了。我实测下来纯大语言模型驱动的语音助手在开放域问答上确实强了很多但在一些传统语音助手做得很好的场景——比如打开客厅的灯把音量调到50%——反而可能变慢因为大语言模型需要推理时间而传统指令匹配几乎是瞬时的。所以真正合理的方案不是用大语言模型替换一切而是大语言模型负责它擅长的部分传统模块负责它擅长的部分。2. 把大语言模型接进语音链路的架构选型2.1 三种主流接入方式对比在实际动手之前我先梳理了三种可行的接入方式每种都有各自的适用场景和代价。接入方式核心思路优势劣势适用场景全替换方案ASR→LLM→TTS中间全部交给大语言模型架构简单理解能力强延迟高成本高工具调用需额外设计开放域问答为主的场景混合路由方案先判断指令类型简单指令走传统链路复杂请求走大语言模型兼顾速度和智能路由判断本身需要设计边界情况多智能家居、车载等混合场景大语言模型增强方案保留传统NLU大语言模型只做兜底和复杂意图补充改动小风险低智能提升有限两套系统维护成本高已有成熟语音助手想快速升级我最终选的是混合路由方案。原因很直接我的测试场景里既有关灯调音量这类高频简单指令也有帮我总结一下今天收到的邮件里有哪些需要回复的这类复杂请求。全替换方案在简单指令上延迟太高全保留方案又体现不出大语言模型的价值。2.2 路由判断的设计逻辑路由判断是整个方案的核心。我的做法是在ASR输出文字之后先过一个轻量级的分类器判断这句话属于指令型还是请求型。指令型的特征很明显动词开头、目标明确、参数可枚举。比如打开关闭设置播放暂停这些。请求型则通常是疑问句、描述性语句、或者包含多个子任务的复合句。分类器我没有用大语言模型来做而是用了一个基于规则加小模型的方式。规则部分覆盖了高频指令的动词白名单小模型部分用了几百条标注数据微调了一个文本分类模型。为什么不用大语言模型做路由因为路由判断本身要快用大语言模型做路由等于把延迟问题提前了得不偿失。这里有个经验路由分类器的准确率不需要做到100%做到90%左右就够了。因为即使路由错了大语言模型链路也能处理简单指令只是慢一点传统链路遇到复杂请求也会给出我不太明白的兜底回复。关键是不要让用户感觉到这个助手一会儿聪明一会儿笨。2.3 上下文管理的具体实现大语言模型链路最大的优势是上下文理解但上下文不能无限塞。我的做法是维护一个滑动窗口保留最近N轮对话同时用一个摘要机制把更早的对话压缩成一段简短描述。具体实现上我用了一个双缓冲结构recent_turns存最近5轮完整对话summary存更早对话的摘要。每次新对话进来先把最老的一轮从recent_turns移出追加到summary的生成队列里。摘要生成是异步的不阻塞主链路。class ContextManager: def __init__(self, max_turns5): self.recent_turns [] self.summary self.max_turns max_turns def add_turn(self, user_input, assistant_reply): self.recent_turns.append({ user: user_input, assistant: assistant_reply }) if len(self.recent_turns) self.max_turns: oldest self.recent_turns.pop(0) self._async_summarize(oldest) def build_prompt_context(self): context if self.summary: context f之前的对话摘要{self.summary}\n for turn in self.recent_turns: context f用户{turn[user]}\n助手{turn[assistant]}\n return context这个结构实测下来很稳。5轮完整对话加上摘要token消耗可控上下文理解也够用。如果你做的场景对话轮次特别多可以把max_turns调到3把更多内容压到摘要里。3. 工具调用让语音助手真正能做事3.1 为什么工具调用是分水岭大语言模型本身只能说不能做。你问它今天天气怎么样它只能根据训练数据瞎编除非你给它一个天气查询工具。工具调用Function Calling是让语音助手从聊天机器人变成能办事的助手的关键。我一开始没重视这块觉得大语言模型理解能力强直接让它生成回复就行了。结果测试的时候发现用户说帮我设一个明天早上七点的闹钟大语言模型回复好的已为您设置明天早上七点的闹钟——但实际上它什么都没做。这就是典型的幻觉执行。3.2 工具定义与调用链路工具调用的核心是你把可用的工具以结构化格式告诉大语言模型大语言模型判断是否需要调用工具、调用哪个工具、传什么参数然后你的系统执行工具调用把结果返回给大语言模型大语言模型再生成最终回复。工具定义我用的是JSON Schema格式每个工具包含名称、描述、参数定义。这里有个关键点工具描述要写得非常清楚因为大语言模型完全靠描述来判断什么时候该用这个工具。{ name: set_alarm, description: 设置闹钟。当用户明确要求设置闹钟、提醒或定时任务时使用。, parameters: { type: object, properties: { time: { type: string, description: 闹钟时间格式为ISO 8601例如2025-01-15T07:00:00 }, label: { type: string, description: 闹钟标签例如起床开会 } }, required: [time] } }调用链路是这样的用户语音输入 → ASR转文字 → 路由判断为请求型 → 大语言模型带工具定义生成回复 → 如果回复中包含工具调用请求 → 执行工具 → 把结果返回大语言模型 → 大语言模型生成最终自然语言回复 → TTS播报。3.3 工具调用的常见坑第一个坑是参数格式错误。大语言模型生成的参数格式经常和你的工具定义不一致。比如你定义时间格式是ISO 8601它可能给你返回明天早上七点这种自然语言。解决办法是在工具描述里给明确的格式示例同时在执行工具前加一层参数校验和转换。第二个坑是多工具冲突。用户说帮我设个闹钟然后查一下明天天气大语言模型可能只调用了一个工具或者两个工具都调用了但顺序不对。我的做法是在系统提示词里明确要求如果用户请求包含多个任务按顺序依次调用工具每个工具调用完成后等待结果再继续。第三个坑是工具调用失败后的处理。工具执行可能失败网络问题、参数错误、权限不足这时候不能让大语言模型瞎编一个成功的结果。我的做法是把错误信息返回给大语言模型让它在系统提示词的约束下生成一个诚实的失败回复比如抱歉闹钟设置失败了请稍后再试。实测经验工具调用的延迟主要来自大语言模型的推理时间。如果一次对话涉及多个工具调用延迟会累加。我的优化方式是把可以并行执行的工具调用并行化比如查天气和查日历可以同时进行不需要串行等待。4. 延迟优化语音交互的生死线4.1 延迟预算怎么分配语音交互对延迟极其敏感。我做过一个简单的用户测试延迟在1.5秒以内用户基本无感1.5到2.5秒用户能感觉到稍微有点慢超过3秒用户就开始怀疑是不是坏了。所以整个链路的延迟预算要控制在2秒以内。延迟预算的分配大概是这样的ASR占300到500毫秒路由判断占50到100毫秒大语言模型推理占800到1200毫秒TTS占200到300毫秒网络传输和其他开销占100到200毫秒。加起来差不多2秒左右已经比较紧张了。4.2 流式输出与分段TTS降低感知延迟最有效的手段是流式输出。大语言模型不需要等整段回复生成完再返回而是生成一个token就返回一个token。TTS也可以做流式合成收到第一个句子就开始播报不用等整段文字。我实测下来流式输出能把感知延迟降低40%到50%。用户听到第一个字的时间可能只有800毫秒左右虽然后面还在继续生成但用户已经觉得它在回应我了。实现上大语言模型的流式接口一般返回SSEServer-Sent Events流你需要逐块读取并拼接。TTS这边要支持流式输入收到足够合成一个短句的文字就立即合成并播放。async def stream_response(user_input, context): full_reply buffer async for chunk in llm.stream_generate(user_input, context): full_reply chunk buffer chunk if _is_sentence_end(buffer): await tts.speak_async(buffer) buffer if buffer: await tts.speak_async(buffer) return full_reply4.3 缓存与预判另一个优化手段是缓存高频请求。像今天天气怎么样现在几点这类高频请求可以把结果缓存起来短时间内重复请求直接返回缓存不走大语言模型。预判则是更激进的优化在用户还在说话的时候ASR已经在实时输出部分识别结果你可以用这部分结果提前开始路由判断甚至提前触发大语言模型推理。等用户说完大语言模型可能已经生成了一部分回复。这个方案实现复杂度高但在延迟敏感的场景下效果很好。5. 实测效果与典型问题复盘5.1 哪些场景提升明显我做了两组对比测试一组是传统语音助手链路一组是接入大语言模型后的混合链路。测试集包含200条语音指令覆盖简单指令、复杂请求、多轮对话三类。场景类型传统链路准确率混合链路准确率提升幅度简单指令开灯、调音量等96%95%基本持平复杂请求多条件、多任务42%81%提升明显多轮对话上下文依赖28%74%提升显著开放域问答15%78%提升巨大简单指令基本持平因为传统链路在这块本来就做得很好。复杂请求和多轮对话提升非常明显这正是大语言模型的强项。开放域问答从15%到78%基本是从不能用到能用的跨越。5.2 仍然没解决好的问题第一个是响应延迟的波动。大语言模型的推理时间不稳定同样的请求有时候800毫秒返回有时候2秒才返回。这个波动用户能明显感知到。我目前的缓解方式是设置超时阈值超过2.5秒还没返回就降级到传统链路的兜底回复。第二个是幻觉问题。大语言模型在开放域问答上虽然强但偶尔会编造信息。比如问我昨天设的闹钟是几点它可能编一个时间出来。解决办法是在系统提示词里严格约束涉及个人数据的问题必须通过工具调用查询不允许直接回答。第三个是多音字和口音问题。ASR本身的准确率在嘈杂环境下会下降大语言模型再强也救不回错误的识别结果。这块目前没有特别好的解法只能靠ASR模型本身的优化。5.3 成本核算接入大语言模型后成本是绕不开的问题。我算了一笔账按每次请求平均消耗500个token计算如果每天有1000次请求一个月就是1500万token。这个量级下API调用成本其实不低。我的优化策略是分层处理简单指令走传统链路零大语言模型成本复杂请求走大语言模型但通过缓存和摘要控制token消耗。实测下来大概只有30%的请求会走大语言模型链路整体成本可控。6. 从Demo到可用产品的几个关键决策6.1 系统提示词的设计原则系统提示词是整个大语言模型链路的大脑。我踩过的坑是一开始提示词写得太简单只写了你是一个语音助手结果大语言模型回复风格飘忽不定有时候太正式有时候太随意有时候还会加一堆解释性文字。后来我把系统提示词拆成了几个模块角色定义、能力边界、回复风格、工具使用规则、安全约束。每个模块都有明确的约束。比如回复风格里明确要求回复控制在两句话以内不要使用列表和markdown格式因为这是语音播报。一个实用技巧在系统提示词里加一句如果不确定就说不知道不要编造。这句话能显著降低幻觉率。我实测下来加了这句话之后编造类回复减少了大概60%。6.2 降级策略的设计任何依赖外部服务的系统都要考虑降级。大语言模型API可能超时、可能限流、可能返回错误。我的降级策略分三级一级降级是超时后重试一次二级降级是重试失败后走传统链路的兜底回复三级降级是传统链路也失败时返回一个通用的抱歉我暂时无法处理这个请求。降级策略的关键是用户无感。用户不需要知道背后发生了什么只需要得到一个合理的回复。所以降级回复也要写得自然不能是系统错误这种技术性描述。6.3 持续迭代的数据闭环上线不是终点。我建了一个简单的数据闭环每次对话都记录用户输入、路由结果、大语言模型回复、用户反馈如果有。每周review一次bad case把典型问题补充到系统提示词或者路由规则里。这个闭环跑了两周之后路由准确率从90%提升到了94%大语言模型回复的满意度也有明显提升。关键是要坚持review不能上线就不管了。7. 我个人的一些实操体会这套方案跑下来最大的体会是大语言模型不是银弹它改变的是能力边界不是所有问题。传统语音助手在确定性任务上的效率优势依然存在大语言模型的价值在于处理那些传统方法搞不定的模糊、复杂、开放域请求。混合方案不是妥协而是当前阶段最合理的选择。另一个体会是延迟优化要贯穿始终。从ASR的流式识别到路由的轻量化到大语言模型的流式输出到TTS的分段合成每一个环节都要抠延迟。语音交互的用户耐心比文字交互低得多慢一秒就是慢一个数量级。最后说一个容易被忽略的点测试集要覆盖真实场景。我一开始用自己设计的测试集效果很好上线后发现真实用户的表达方式千奇百怪很多测试集里没覆盖的情况。后来我专门收集了一周的真实语音输入重新标注了测试集才发现问题所在。真实场景的噪声、口音、省略、指代远比实验室环境复杂。
语音助手这个品类过去几年一直处在一个挺尴尬的位置。你说它没用吧查天气、设闹钟、放音乐确实方便你说它聪明吧稍微复杂一点的问题就开始答非所问多轮对话超过两轮就彻底迷失上下文。我自己用过的几款语音助手从车载场景到智能音箱再到手机内置的体验基本停留在能听懂指令但听不懂人话的阶段。后来大语言模型火了之后我一直在琢磨一件事如果把大语言模型的语言理解和生成能力接到语音助手这条链路上它到底能变多聪明哪些环节是真正被改善的哪些环节其实还是老样子这篇文章就把我自己的实践和踩坑过程完整拆开从架构、选型、实操到效果验证一步步讲清楚。1. 语音助手不聪明的根因到底在哪1.1 传统语音助手的三段式流水线大多数人对语音助手的理解就是我说一句话它回我一句话。但拆开看传统语音助手其实是一条三段式流水线语音识别ASR→ 意图理解与对话管理NLUDM→ 语音合成TTS。这三段每一段都是独立模块各自有各自的模型和规则库。问题就出在这个独立上。ASR把你说的话转成文字但它只负责转文字不负责理解你真正想表达什么。NLU拿到文字后靠的是预先定义好的意图模板和槽位填充规则。比如你说帮我订明天下午三点的会议室NLU会去匹配订会议室这个意图然后抽取时间明天下午三点这个槽位。但如果你说我下午要跟团队开个会帮我找个地方传统NLU就懵了——因为它没有开会到订会议室的映射规则。对话管理DM更是个重灾区。传统DM靠的是状态机或者填槽式对话对话路径是预先设计好的。你偏离了预设路径它就不知道怎么接。这就是为什么传统语音助手多轮对话能力极差——它根本没有真正的上下文记忆只有当前槽位还缺什么。1.2 大语言模型改变了哪个环节大语言模型带来的最大变化是它把理解和生成这两件事统一到了一个模型里。你不需要再单独训练一个NLU模型去识别意图也不需要单独设计对话状态机。你给大语言模型一段系统提示词把用户的历史对话和当前输入一起塞进去它自己就能理解上下文、推断意图、生成回复。这意味着语音助手的架构可以从三段式流水线变成ASR → LLM → TTS的简化链路。中间的NLU和DM模块被大语言模型替代了。这个变化听起来简单但实际落地时涉及的问题非常多延迟怎么控制、上下文怎么管理、工具调用怎么设计、幻觉怎么抑制每一个都是坑。1.3 为什么更聪明不等于更好用这里要先泼一盆冷水。大语言模型确实让语音助手在语言理解上有了质的飞跃但更聪明和更好用之间还有一道鸿沟。语音交互和文字交互有本质区别文字交互你可以慢慢打字、反复修改语音交互是线性的、一次性的用户说完就等着回复延迟超过两秒体验就崩了。我实测下来纯大语言模型驱动的语音助手在开放域问答上确实强了很多但在一些传统语音助手做得很好的场景——比如打开客厅的灯把音量调到50%——反而可能变慢因为大语言模型需要推理时间而传统指令匹配几乎是瞬时的。所以真正合理的方案不是用大语言模型替换一切而是大语言模型负责它擅长的部分传统模块负责它擅长的部分。2. 把大语言模型接进语音链路的架构选型2.1 三种主流接入方式对比在实际动手之前我先梳理了三种可行的接入方式每种都有各自的适用场景和代价。接入方式核心思路优势劣势适用场景全替换方案ASR→LLM→TTS中间全部交给大语言模型架构简单理解能力强延迟高成本高工具调用需额外设计开放域问答为主的场景混合路由方案先判断指令类型简单指令走传统链路复杂请求走大语言模型兼顾速度和智能路由判断本身需要设计边界情况多智能家居、车载等混合场景大语言模型增强方案保留传统NLU大语言模型只做兜底和复杂意图补充改动小风险低智能提升有限两套系统维护成本高已有成熟语音助手想快速升级我最终选的是混合路由方案。原因很直接我的测试场景里既有关灯调音量这类高频简单指令也有帮我总结一下今天收到的邮件里有哪些需要回复的这类复杂请求。全替换方案在简单指令上延迟太高全保留方案又体现不出大语言模型的价值。2.2 路由判断的设计逻辑路由判断是整个方案的核心。我的做法是在ASR输出文字之后先过一个轻量级的分类器判断这句话属于指令型还是请求型。指令型的特征很明显动词开头、目标明确、参数可枚举。比如打开关闭设置播放暂停这些。请求型则通常是疑问句、描述性语句、或者包含多个子任务的复合句。分类器我没有用大语言模型来做而是用了一个基于规则加小模型的方式。规则部分覆盖了高频指令的动词白名单小模型部分用了几百条标注数据微调了一个文本分类模型。为什么不用大语言模型做路由因为路由判断本身要快用大语言模型做路由等于把延迟问题提前了得不偿失。这里有个经验路由分类器的准确率不需要做到100%做到90%左右就够了。因为即使路由错了大语言模型链路也能处理简单指令只是慢一点传统链路遇到复杂请求也会给出我不太明白的兜底回复。关键是不要让用户感觉到这个助手一会儿聪明一会儿笨。2.3 上下文管理的具体实现大语言模型链路最大的优势是上下文理解但上下文不能无限塞。我的做法是维护一个滑动窗口保留最近N轮对话同时用一个摘要机制把更早的对话压缩成一段简短描述。具体实现上我用了一个双缓冲结构recent_turns存最近5轮完整对话summary存更早对话的摘要。每次新对话进来先把最老的一轮从recent_turns移出追加到summary的生成队列里。摘要生成是异步的不阻塞主链路。class ContextManager: def __init__(self, max_turns5): self.recent_turns [] self.summary self.max_turns max_turns def add_turn(self, user_input, assistant_reply): self.recent_turns.append({ user: user_input, assistant: assistant_reply }) if len(self.recent_turns) self.max_turns: oldest self.recent_turns.pop(0) self._async_summarize(oldest) def build_prompt_context(self): context if self.summary: context f之前的对话摘要{self.summary}\n for turn in self.recent_turns: context f用户{turn[user]}\n助手{turn[assistant]}\n return context这个结构实测下来很稳。5轮完整对话加上摘要token消耗可控上下文理解也够用。如果你做的场景对话轮次特别多可以把max_turns调到3把更多内容压到摘要里。3. 工具调用让语音助手真正能做事3.1 为什么工具调用是分水岭大语言模型本身只能说不能做。你问它今天天气怎么样它只能根据训练数据瞎编除非你给它一个天气查询工具。工具调用Function Calling是让语音助手从聊天机器人变成能办事的助手的关键。我一开始没重视这块觉得大语言模型理解能力强直接让它生成回复就行了。结果测试的时候发现用户说帮我设一个明天早上七点的闹钟大语言模型回复好的已为您设置明天早上七点的闹钟——但实际上它什么都没做。这就是典型的幻觉执行。3.2 工具定义与调用链路工具调用的核心是你把可用的工具以结构化格式告诉大语言模型大语言模型判断是否需要调用工具、调用哪个工具、传什么参数然后你的系统执行工具调用把结果返回给大语言模型大语言模型再生成最终回复。工具定义我用的是JSON Schema格式每个工具包含名称、描述、参数定义。这里有个关键点工具描述要写得非常清楚因为大语言模型完全靠描述来判断什么时候该用这个工具。{ name: set_alarm, description: 设置闹钟。当用户明确要求设置闹钟、提醒或定时任务时使用。, parameters: { type: object, properties: { time: { type: string, description: 闹钟时间格式为ISO 8601例如2025-01-15T07:00:00 }, label: { type: string, description: 闹钟标签例如起床开会 } }, required: [time] } }调用链路是这样的用户语音输入 → ASR转文字 → 路由判断为请求型 → 大语言模型带工具定义生成回复 → 如果回复中包含工具调用请求 → 执行工具 → 把结果返回大语言模型 → 大语言模型生成最终自然语言回复 → TTS播报。3.3 工具调用的常见坑第一个坑是参数格式错误。大语言模型生成的参数格式经常和你的工具定义不一致。比如你定义时间格式是ISO 8601它可能给你返回明天早上七点这种自然语言。解决办法是在工具描述里给明确的格式示例同时在执行工具前加一层参数校验和转换。第二个坑是多工具冲突。用户说帮我设个闹钟然后查一下明天天气大语言模型可能只调用了一个工具或者两个工具都调用了但顺序不对。我的做法是在系统提示词里明确要求如果用户请求包含多个任务按顺序依次调用工具每个工具调用完成后等待结果再继续。第三个坑是工具调用失败后的处理。工具执行可能失败网络问题、参数错误、权限不足这时候不能让大语言模型瞎编一个成功的结果。我的做法是把错误信息返回给大语言模型让它在系统提示词的约束下生成一个诚实的失败回复比如抱歉闹钟设置失败了请稍后再试。实测经验工具调用的延迟主要来自大语言模型的推理时间。如果一次对话涉及多个工具调用延迟会累加。我的优化方式是把可以并行执行的工具调用并行化比如查天气和查日历可以同时进行不需要串行等待。4. 延迟优化语音交互的生死线4.1 延迟预算怎么分配语音交互对延迟极其敏感。我做过一个简单的用户测试延迟在1.5秒以内用户基本无感1.5到2.5秒用户能感觉到稍微有点慢超过3秒用户就开始怀疑是不是坏了。所以整个链路的延迟预算要控制在2秒以内。延迟预算的分配大概是这样的ASR占300到500毫秒路由判断占50到100毫秒大语言模型推理占800到1200毫秒TTS占200到300毫秒网络传输和其他开销占100到200毫秒。加起来差不多2秒左右已经比较紧张了。4.2 流式输出与分段TTS降低感知延迟最有效的手段是流式输出。大语言模型不需要等整段回复生成完再返回而是生成一个token就返回一个token。TTS也可以做流式合成收到第一个句子就开始播报不用等整段文字。我实测下来流式输出能把感知延迟降低40%到50%。用户听到第一个字的时间可能只有800毫秒左右虽然后面还在继续生成但用户已经觉得它在回应我了。实现上大语言模型的流式接口一般返回SSEServer-Sent Events流你需要逐块读取并拼接。TTS这边要支持流式输入收到足够合成一个短句的文字就立即合成并播放。async def stream_response(user_input, context): full_reply buffer async for chunk in llm.stream_generate(user_input, context): full_reply chunk buffer chunk if _is_sentence_end(buffer): await tts.speak_async(buffer) buffer if buffer: await tts.speak_async(buffer) return full_reply4.3 缓存与预判另一个优化手段是缓存高频请求。像今天天气怎么样现在几点这类高频请求可以把结果缓存起来短时间内重复请求直接返回缓存不走大语言模型。预判则是更激进的优化在用户还在说话的时候ASR已经在实时输出部分识别结果你可以用这部分结果提前开始路由判断甚至提前触发大语言模型推理。等用户说完大语言模型可能已经生成了一部分回复。这个方案实现复杂度高但在延迟敏感的场景下效果很好。5. 实测效果与典型问题复盘5.1 哪些场景提升明显我做了两组对比测试一组是传统语音助手链路一组是接入大语言模型后的混合链路。测试集包含200条语音指令覆盖简单指令、复杂请求、多轮对话三类。场景类型传统链路准确率混合链路准确率提升幅度简单指令开灯、调音量等96%95%基本持平复杂请求多条件、多任务42%81%提升明显多轮对话上下文依赖28%74%提升显著开放域问答15%78%提升巨大简单指令基本持平因为传统链路在这块本来就做得很好。复杂请求和多轮对话提升非常明显这正是大语言模型的强项。开放域问答从15%到78%基本是从不能用到能用的跨越。5.2 仍然没解决好的问题第一个是响应延迟的波动。大语言模型的推理时间不稳定同样的请求有时候800毫秒返回有时候2秒才返回。这个波动用户能明显感知到。我目前的缓解方式是设置超时阈值超过2.5秒还没返回就降级到传统链路的兜底回复。第二个是幻觉问题。大语言模型在开放域问答上虽然强但偶尔会编造信息。比如问我昨天设的闹钟是几点它可能编一个时间出来。解决办法是在系统提示词里严格约束涉及个人数据的问题必须通过工具调用查询不允许直接回答。第三个是多音字和口音问题。ASR本身的准确率在嘈杂环境下会下降大语言模型再强也救不回错误的识别结果。这块目前没有特别好的解法只能靠ASR模型本身的优化。5.3 成本核算接入大语言模型后成本是绕不开的问题。我算了一笔账按每次请求平均消耗500个token计算如果每天有1000次请求一个月就是1500万token。这个量级下API调用成本其实不低。我的优化策略是分层处理简单指令走传统链路零大语言模型成本复杂请求走大语言模型但通过缓存和摘要控制token消耗。实测下来大概只有30%的请求会走大语言模型链路整体成本可控。6. 从Demo到可用产品的几个关键决策6.1 系统提示词的设计原则系统提示词是整个大语言模型链路的大脑。我踩过的坑是一开始提示词写得太简单只写了你是一个语音助手结果大语言模型回复风格飘忽不定有时候太正式有时候太随意有时候还会加一堆解释性文字。后来我把系统提示词拆成了几个模块角色定义、能力边界、回复风格、工具使用规则、安全约束。每个模块都有明确的约束。比如回复风格里明确要求回复控制在两句话以内不要使用列表和markdown格式因为这是语音播报。一个实用技巧在系统提示词里加一句如果不确定就说不知道不要编造。这句话能显著降低幻觉率。我实测下来加了这句话之后编造类回复减少了大概60%。6.2 降级策略的设计任何依赖外部服务的系统都要考虑降级。大语言模型API可能超时、可能限流、可能返回错误。我的降级策略分三级一级降级是超时后重试一次二级降级是重试失败后走传统链路的兜底回复三级降级是传统链路也失败时返回一个通用的抱歉我暂时无法处理这个请求。降级策略的关键是用户无感。用户不需要知道背后发生了什么只需要得到一个合理的回复。所以降级回复也要写得自然不能是系统错误这种技术性描述。6.3 持续迭代的数据闭环上线不是终点。我建了一个简单的数据闭环每次对话都记录用户输入、路由结果、大语言模型回复、用户反馈如果有。每周review一次bad case把典型问题补充到系统提示词或者路由规则里。这个闭环跑了两周之后路由准确率从90%提升到了94%大语言模型回复的满意度也有明显提升。关键是要坚持review不能上线就不管了。7. 我个人的一些实操体会这套方案跑下来最大的体会是大语言模型不是银弹它改变的是能力边界不是所有问题。传统语音助手在确定性任务上的效率优势依然存在大语言模型的价值在于处理那些传统方法搞不定的模糊、复杂、开放域请求。混合方案不是妥协而是当前阶段最合理的选择。另一个体会是延迟优化要贯穿始终。从ASR的流式识别到路由的轻量化到大语言模型的流式输出到TTS的分段合成每一个环节都要抠延迟。语音交互的用户耐心比文字交互低得多慢一秒就是慢一个数量级。最后说一个容易被忽略的点测试集要覆盖真实场景。我一开始用自己设计的测试集效果很好上线后发现真实用户的表达方式千奇百怪很多测试集里没覆盖的情况。后来我专门收集了一周的真实语音输入重新标注了测试集才发现问题所在。真实场景的噪声、口音、省略、指代远比实验室环境复杂。
