简介面向安卓开发者和语音交互技术学习者的智能语音对话机器人项目工程完整覆盖从语音采集、识别转写到自然语言理解与回复生成的常规链路可支撑快速搭建具备“机器人接口/语音助手”形态的App原型或进阶研究人机对话实现。压缩包共179个文件大小约6.46MB涵盖Java源码、安卓布局与图片资源、编译后的类文件、依赖库、底层动态库以及工程配置文件文本与属性配置便于对接机器人接口界面布局与图片素材负责展示依赖库与动态库支撑核心能力扩展。包内包含主界面、聊天消息适配、网络请求等关键实现组件配合预置示例对话与接口调用逻辑可以较为直观地理解语音助手应用的模块划分、服务调用方式以及大脑接口接入流程方便后续替换为自身对话服务或增加提醒、播放等具体操作。当前已有2627人学习下载适合作为安卓语音交互项目入门参考和二次开发起点。 去年我帮朋友做了个智能语音对话机器人放在门店门口当迎宾讲解员客人进来对着它说话它就能回答关于产品的问题。当时想着不就是一个麦克风加音箱再加个聊天模型嘛结果从硬件选型到语音识别、对话生成、语音合成一路做下来踩了不少坑也搞明白了一件事一个真正能用的智能语音对话机器人难点根本不在“对话”而在“语音”这一进一出两条链路。这篇就把整个项目从思路到落地完整拆开来讲包括技术选型、核心代码以及哪些地方是纯坑。如果你想做类似的东西不管是放展厅、书房还是想给业务系统加一个语音入口这篇可以直接照着走。1. 项目定位与整体思路拆解1.1 三个核心模块听懂、想明白、说出口任何一个智能语音对话机器人都可以拆成三段式流水线语音识别ASR把用户说的话转成文字→ 对话模型LLM或规则引擎根据文字生成回复→ 语音合成TTS把回复的文字转成语音播出来。听起来很简单但实际做起来你会发现三个模块之间的关系特别微妙。先说语音识别。这个模块决定了用户的门槛——别指望每个人都对着麦克风字正腔圆地说标准普通话。我测试时候遇到最多的场景是客户随口说半句话、带方言口音、背景里有商场音乐。如果ASR识别错了后面模型再聪明也没用因为喂进去的就是一段错误文本。再说对话模型。这里有一个关键矛盾用大模型API效果确实好但响应时间不稳定用本地小模型速度快但回答质量参差不齐。我的做法是结合场景来做——如果机器人只需要回答固定产品信息优先用规则或检索速度快、可控性高如果需要开放闲聊或复杂多轮问答再上大模型。最后是语音合成。很多人会忽略TTS的重要性其实用户对机器人“像不像真人”的感知70%来自声音而不来自回答内容。一个机械感很强的声音哪怕内容无比准确用户也会觉得“这玩意儿不太聪明”反之一个自然温暖的声音能明显拉高用户容忍度。1.2 先跑通再优化还是先规划再动手我见过很多做这类项目的新手一上来就想做到“全双工、可打断、情感识别”还没开始就给自己挖了一堆大坑。我的建议永远是第一版只做最朴素的“按键-说话-回复”模式不搞唤醒词不加打断不做多模态先把主链路跑通。为什么要这么做因为智能语音对话机器人的主链路涉及至少三个独立子系统任何一个环节有延迟或报错排查范围就会扩大好几倍。如果你一上来就叠buff——唤醒词本地唤醒引擎、语音活动检测VAD切掉静音、半双工/全双工切换、流式识别、多轮对话状态管理、情感合成——那项目会无限期卡在bug里。所以我的整体方案是分三个版本迭代V1按键触发 在线ASR 大模型API 在线TTS验证场景是否成立。V2加唤醒词、加本地离线ASR兜底、加入打断机制提升体验。V3针对业务场景微调对话策略做声音定制和个性化。这篇文章重点讲V1怎么落地因为这是你后面所有优化的地基。2. 关键技术选型求稳还是求新取决于目标场景2.1 语音识别ASR方案对比ASR方案目前主流就是三类云端API、本地开源模型、端侧专用芯片方案。我直接把当时对比的表格放出来方案代表优点缺点适合场景云端API讯飞、阿里、腾讯、字节识别率高、支持方言多、不用自己维护模型需要网络、按量付费、有延迟大部分商用场景本地开源FunASR、Whisper、WeNet免费、数据不出本地、可定制需要GPU或调优、中文效果需要微调对隐私要求高、网络不稳定的场景端侧专用部分离线语音模块功耗低、不占系统资源效果差、词库死板极简单交互玩具我当时选的是FunASR的本地模型做主力。原因很现实门店语音环境比较杂云端API虽然有现成的模型但是每秒钟都在烧钱而且一旦并发一高账单有点吓人。FunASR在中文识别上表现不错最关键的是开源免费还能热加载自定义热词——比如客户品牌名、产品型号这种专有名词可以塞进去提高识别率。如果你是纯新手不想折腾模型部署那就直接用云端API现在各家都有免费额度先跑通流程再说。2.2 对话模型LLM的选择逻辑对话模型的选型直接决定了机器人的“情商”和“知识量”。我当时面临两个选择用大模型API如GPT系列、通义千问、文心一言、Kimi等——效果好但是有网络延迟而且按token收费。用本地开源模型如Qwen-7B、ChatGLM、InternLM等——免费隐私安全响应速度取决于你的显卡。我最后采用了“混合策略”简单的问题走预设知识库规则复杂问题才请求大模型API。这样既保证了大部分请求有毫秒级响应又不会让API账单失控。具体实现上我给机器人灌了一份门店的FAQ文档先做检索。命中FAQ直接返回预设回答没命中再走大模型。这里有一个经验给大模型的系统提示词要写得非常细包括“你是门店导购助手”“回答不超过50个字”“不确定就引导客户找人工”等等不然模型会自由发挥经常一本正经地胡说八道。2.3 语音合成TTS别小看这一步TTS这个环节被很多人低估。我第一版用的是系统自带的pyttsx3音色很机械测试时自己都懒得听。后来换成云端TTS好很多但延迟高、每月免费额度有限。于是又试了开源TTS方案。现在开源TTS里比较火的有Edge-TTS微软的免费接口、ChatTTS、还有各种基于VITS的模型。Edge-TTS胜在部署简单、延迟低、音色自然缺点是需要联网获取tokenChatTTS本地跑支持声音克隆但生成速度和稳定性还差点意思。如果你不追求本地离线用Edge-TTS是性价比极高的选择。还要特别注意“流式播放”这个细节不要等整段话合成完再播那样会让用户等很久。应该把文本切成短句合成一部分播一部分这样体感延迟会大幅降低。这点在后面的代码里也会体现。3. 实操过程从麦克风到扬声器的完整链路3.1 硬件环境与准备我做这套用的是最基础的配置树莓派4B4GB版本 USB麦克风阵列 3.5mm音箱。为什么用树莓派因为项目要部署到门店现场树莓派体积小、功耗低、安静24小时开机不心疼。如果你只是在电脑上测试完全不用额外买硬件直接用笔记本的麦克风或耳机麦克风就行。系统方面Windows / macOS / Linux都可以代码是跨平台的注意一下音频设备的输入输出索引就好。为了方便演示下面所有代码我都用Python写。3.2 录音与语音识别麦克风数据怎么变成文字录音这一步的核心是用pyaudio采集麦克风数据保存成wav文件然后喂给ASR模型。import pyaudio import wave def record_audio(duration5, sample_rate16000, device_indexNone): chunk 1024 p pyaudio.PyAudio() stream p.open(formatpyaudio.paInt16, channels1, ratesample_rate, inputTrue, frames_per_bufferchunk, input_device_indexdevice_index) frames [] for _ in range(0, int(sample_rate / chunk * duration)): data stream.read(chunk) frames.append(data) stream.stop_stream() stream.close() p.terminate() with wave.open(temp.wav, wb) as wf: wf.setnchannels(1) wf.setsampwidth(p.get_sample_size(pyaudio.paInt16)) wf.setframerate(sample_rate) wf.writeframes(b.join(frames)) return temp.wav注意采样率设置成16000就够了ASR模型基本都支持16k音频采样率太高反而浪费存储和带宽。录音时长我建议设置成5秒左右——太短用户说不完太长等待时间太煎熬。如果用了VAD语音活动检测就可以实现“用户不说话时自动停止录音”这个属于进阶优化后面会讲。录音完成后调用FunASR识别from funasr import AutoModel model AutoModel(modelparaformer-zh, model_revisionv2.0.4) res model.generate(inputtemp.wav, batch_size_s300) text res[0][text] print(识别结果:, text)这里用到的paraformer-zh是阿里开源的中文语音识别模型在普通话和带口音的语音上表现都不错CPU也能跑。首次运行会自动下载模型权重网络好的话等几分钟就行。你还可以通过hotword参数传入热词比如model.generate(..., hotword门店名称 产品型号)能明显提升专有名词的识别准确率。3.3 对话生成带知识库的LLM调用对话模块是核心。我采用的是“FAQ检索优先 LLM兜底”的策略。第一步先维护一个简单的知识库用句子向量检索选出最接近的问题如果相似度超过阈值直接返回预设答案from sentence_transformers import SentenceTransformer import numpy as np # 示例知识库 faq [ 你们的营业时间是几点, 产品保修多久, 这款产品多少钱, 有哪些颜色可以选择, 可以开发票吗 ] answers [ 我们的营业时间是每天早上9点到晚上9点。, 产品保修一年主要部件可以保修两年。, 这款产品目前售价是2999元。, 目前有白色、银色和深空灰三种颜色。, 可以的购买后联系客服即可开具电子发票。 ] encoder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) query_embedding encoder.encode([text]) faq_embeddings encoder.encode(faq) scores np.dot(faq_embeddings, query_embedding.T).flatten() best_idx np.argmax(scores) if scores[best_idx] 0.6: # 置信度阈值 reply answers[best_idx] else: # 走LLM兜底 reply call_llm(text)为什么阈值设0.6太小会把无关问题硬匹配到FAQ上太大则大部分问题都跑到LLM去失去了缓存的意义。这个值要根据实际测试微调我当时在真实问答集上调到0.58~0.65之间最舒服。call_llm函数我用的标准OpenAI SDK格式因为国产大模型大多兼容这套协议换模型只需要改base_url和api_keyfrom openai import OpenAI client OpenAI( base_urlhttps://your-llm-api.com/v1, api_keyyour-api-key ) SYSTEM_PROMPT 你是一个门店智能导购助手请用简洁、友好、口语化的方式回答客户问题回答尽量不超过50个字。如果不确定就说需要帮客户联系人工。 def call_llm(user_text): resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_text} ], temperature0.3, max_tokens150 ) return resp.choices[0].message.contenttemperature参数建议设低一点0.2~0.4这样回答更稳定、更可控。如果是闲聊场景可以适当调高但作为客服导购稳定大于创意。3.4 语音合成与播放让回复“说”出来语音合成我用的是Edge-TTS。它虽然是微软接口但目前的调用方式非常轻量音色自然度也不输付费产品import asyncio import edge_tts async def text_to_speech(text, output_file): tts edge_tts.Communicate(text, voicezh-CN-XiaoxiaoNeural) await tts.save(output_file) asyncio.run(text_to_speech(reply, reply.mp3))然后播放就简单了用PlaySound或者mpv都行from playsound import playsound playsound(reply.mp3)这里有一个实战经验如果对响应速度要求高不要等整段文字合成完而是把LLM返回的完整回复按标点切分成短句每句合成后立即播放用户听到第一句话的时间能压缩一半以上。切分逻辑并不复杂就是按。\n这几个符号做split合成和播放用子线程队列串起来。这个优化实测能把“用户说完到听到首个回复”的时间从2.5秒降到1.2秒左右体感差异非常明显。3.5 串联主循环一次完整对话主循环就是把上面几段串起来。为了不让程序卡死我用的是最简单的“按键触发”模式——按回车开始录音录完自动识别、对话、播放import threading if __name__ __main__: print(按回车开始说话CtrlC退出) while True: input() print(录音中...) wav_file record_audio(duration5) user_text asr(wav_file) print(你说:, user_text) reply get_reply(user_text) # FAQ优先LLM兜底 print(机器人:, reply) tts_and_play(reply)到这里一个最简单的智能语音对话机器人就已经能跑起来了。把它塞进树莓派接好音箱和麦克风就是一个能听会说的实体设备。4. 常见问题与排查技巧实录4.1 识别不准确问题往往不在模型而在音频很多人发现ASR识别得不准第一反应是换更强的模型但实际上“音频质量”才是第一问题。我在门店调试时发现麦克风离人太远、音箱声音串进麦克风导致回声、环境底噪太大这三者才是罪魁祸首。简单排查顺序把录音文件保存下来自己听一遍。如果人耳都听不清就别指望模型了。检查麦克风增益是不是太高太高容易削波削波后语音特征被破坏比声音小更严重。检查是不是音箱播报时麦克风还在录音V1阶段最简单的方式是播放回复期间把麦克风静音避免回声进入录音。测试时在安静环境下先跑一遍确认链路没问题再慢慢引入噪音环境。另外记得利用ASR热词表这个前面提到过。把场景中专有名词、产品型号、地名都塞进去识别率能提升几个百分点属于投入产出比极高的优化。4.2 延迟太大提升体感速度的三个做法智能语音对话机器人最影响体验的就是延迟。用户按下说话键、说完话如果两三秒还没听到回复就会觉得“坏了”“卡了”。我实测下来的延迟分布大概是ASR 0.5秒、LLM 0.8~2秒、TTS 1秒。整体串行下来感知特别明显。解决办法有三个第一ASR用流式识别在用户说话的同时就出识别结果而不是等录音结束后再识别。FunASR支持流式模型paraformer-streaming效果可以但部署复杂度高一些。第二TTS改成短句边合成边播放前文已说响应体感能好很多。第三如果走云端API选一个网络延迟低的接口地址尽量把服务部署在离目标用户近的机房。这里记住一句话用户感知不到“你快”但一定能感知到“你慢”。宁可回复质量略降也要先保证首句快速响起。4.3 常见问题速查表现象可能原因解决方案录音文件是空白/silence麦克风没选对、权限没开启检查设备索引和系统权限ASR结果乱码或空文本音频采样率不对、太短统一为16k单声道录制3秒以上LLM长时间无响应网络问题、模型负载高设置超时和重试加入流式输出TTS播放断断续续网络波动导致合成卡顿启用本地音频缓存、预合成常用回复机器人听到自己的播报回声问题播放时关闭麦克风或使用回声消除模块程序运行几小时就崩内存泄漏、pyaudio流没关闭检查线程和资源释放加看门狗脚本4.4 进阶优化唤醒词、打断与多轮对话V1跑通之后你再考虑体验升级。唤醒词我建议用开源方案比如openWakeWord或snowboy虽然snowboy已停更多年但还有人在用。唤醒词的作用是让机器人从“按键触发”变成“随时听令”。注意唤醒词模型吃CPU树莓派上要选轻量模型不然会影响ASR的实时性。打断机制是另一个体验升级点就是用户说话时可以随时插话机器人自动闭嘴听用户新指令。实现逻辑不难TTS播放线程检测到VAD检测到新语音就停止播放然后切换到识别流程。难的是处理好状态机避免“自己说话触发自己打断”这类死循环。多轮对话则要看场景。如果只是问答机器人每轮独立反而更稳定不会出现上下文跑偏的问题。如果要做深度多轮比如“帮我比较下这款和那款的区别”这种有指代的话那就要在LLM调用时传入多轮历史消息同时控制历史长度太长了之后既慢又贵还容易让模型混淆身份。最后说几句实在话这套玩意做完我最深刻的体会是智能语音对话机器人真正难的不是单个模型有多聪明而是三个环节之间的衔接稳不稳。很多方案单独测试效果都不错一连起来就各种问题——音频没采到、识别太慢、模型答非所问、TTS机械音。建议你做的时候一定按“主链路优先、花活靠后”的节奏来。另外一个小建议不管用什么方案记得把每一轮的语音、识别文本、回复文本都打日志存下来。这些数据是最宝贵的测试集后面优化任何环节都靠它。项目交付之后整理这些语料也可以用来做场景化微调。做这个机器人最开心的瞬间是看到真实用户第一次听到它答复时眼睛一亮的样子。那一刻你就会觉得前面那些跟回声、跟延迟、跟断句较劲的时间都值了。本文还有配套的精品资源点击获取 智能语音对话机器人实战：从ASR到TTS的完整链路搭建与踩坑记录
简介面向安卓开发者和语音交互技术学习者的智能语音对话机器人项目工程完整覆盖从语音采集、识别转写到自然语言理解与回复生成的常规链路可支撑快速搭建具备“机器人接口/语音助手”形态的App原型或进阶研究人机对话实现。压缩包共179个文件大小约6.46MB涵盖Java源码、安卓布局与图片资源、编译后的类文件、依赖库、底层动态库以及工程配置文件文本与属性配置便于对接机器人接口界面布局与图片素材负责展示依赖库与动态库支撑核心能力扩展。包内包含主界面、聊天消息适配、网络请求等关键实现组件配合预置示例对话与接口调用逻辑可以较为直观地理解语音助手应用的模块划分、服务调用方式以及大脑接口接入流程方便后续替换为自身对话服务或增加提醒、播放等具体操作。当前已有2627人学习下载适合作为安卓语音交互项目入门参考和二次开发起点。 去年我帮朋友做了个智能语音对话机器人放在门店门口当迎宾讲解员客人进来对着它说话它就能回答关于产品的问题。当时想着不就是一个麦克风加音箱再加个聊天模型嘛结果从硬件选型到语音识别、对话生成、语音合成一路做下来踩了不少坑也搞明白了一件事一个真正能用的智能语音对话机器人难点根本不在“对话”而在“语音”这一进一出两条链路。这篇就把整个项目从思路到落地完整拆开来讲包括技术选型、核心代码以及哪些地方是纯坑。如果你想做类似的东西不管是放展厅、书房还是想给业务系统加一个语音入口这篇可以直接照着走。1. 项目定位与整体思路拆解1.1 三个核心模块听懂、想明白、说出口任何一个智能语音对话机器人都可以拆成三段式流水线语音识别ASR把用户说的话转成文字→ 对话模型LLM或规则引擎根据文字生成回复→ 语音合成TTS把回复的文字转成语音播出来。听起来很简单但实际做起来你会发现三个模块之间的关系特别微妙。先说语音识别。这个模块决定了用户的门槛——别指望每个人都对着麦克风字正腔圆地说标准普通话。我测试时候遇到最多的场景是客户随口说半句话、带方言口音、背景里有商场音乐。如果ASR识别错了后面模型再聪明也没用因为喂进去的就是一段错误文本。再说对话模型。这里有一个关键矛盾用大模型API效果确实好但响应时间不稳定用本地小模型速度快但回答质量参差不齐。我的做法是结合场景来做——如果机器人只需要回答固定产品信息优先用规则或检索速度快、可控性高如果需要开放闲聊或复杂多轮问答再上大模型。最后是语音合成。很多人会忽略TTS的重要性其实用户对机器人“像不像真人”的感知70%来自声音而不来自回答内容。一个机械感很强的声音哪怕内容无比准确用户也会觉得“这玩意儿不太聪明”反之一个自然温暖的声音能明显拉高用户容忍度。1.2 先跑通再优化还是先规划再动手我见过很多做这类项目的新手一上来就想做到“全双工、可打断、情感识别”还没开始就给自己挖了一堆大坑。我的建议永远是第一版只做最朴素的“按键-说话-回复”模式不搞唤醒词不加打断不做多模态先把主链路跑通。为什么要这么做因为智能语音对话机器人的主链路涉及至少三个独立子系统任何一个环节有延迟或报错排查范围就会扩大好几倍。如果你一上来就叠buff——唤醒词本地唤醒引擎、语音活动检测VAD切掉静音、半双工/全双工切换、流式识别、多轮对话状态管理、情感合成——那项目会无限期卡在bug里。所以我的整体方案是分三个版本迭代V1按键触发 在线ASR 大模型API 在线TTS验证场景是否成立。V2加唤醒词、加本地离线ASR兜底、加入打断机制提升体验。V3针对业务场景微调对话策略做声音定制和个性化。这篇文章重点讲V1怎么落地因为这是你后面所有优化的地基。2. 关键技术选型求稳还是求新取决于目标场景2.1 语音识别ASR方案对比ASR方案目前主流就是三类云端API、本地开源模型、端侧专用芯片方案。我直接把当时对比的表格放出来方案代表优点缺点适合场景云端API讯飞、阿里、腾讯、字节识别率高、支持方言多、不用自己维护模型需要网络、按量付费、有延迟大部分商用场景本地开源FunASR、Whisper、WeNet免费、数据不出本地、可定制需要GPU或调优、中文效果需要微调对隐私要求高、网络不稳定的场景端侧专用部分离线语音模块功耗低、不占系统资源效果差、词库死板极简单交互玩具我当时选的是FunASR的本地模型做主力。原因很现实门店语音环境比较杂云端API虽然有现成的模型但是每秒钟都在烧钱而且一旦并发一高账单有点吓人。FunASR在中文识别上表现不错最关键的是开源免费还能热加载自定义热词——比如客户品牌名、产品型号这种专有名词可以塞进去提高识别率。如果你是纯新手不想折腾模型部署那就直接用云端API现在各家都有免费额度先跑通流程再说。2.2 对话模型LLM的选择逻辑对话模型的选型直接决定了机器人的“情商”和“知识量”。我当时面临两个选择用大模型API如GPT系列、通义千问、文心一言、Kimi等——效果好但是有网络延迟而且按token收费。用本地开源模型如Qwen-7B、ChatGLM、InternLM等——免费隐私安全响应速度取决于你的显卡。我最后采用了“混合策略”简单的问题走预设知识库规则复杂问题才请求大模型API。这样既保证了大部分请求有毫秒级响应又不会让API账单失控。具体实现上我给机器人灌了一份门店的FAQ文档先做检索。命中FAQ直接返回预设回答没命中再走大模型。这里有一个经验给大模型的系统提示词要写得非常细包括“你是门店导购助手”“回答不超过50个字”“不确定就引导客户找人工”等等不然模型会自由发挥经常一本正经地胡说八道。2.3 语音合成TTS别小看这一步TTS这个环节被很多人低估。我第一版用的是系统自带的pyttsx3音色很机械测试时自己都懒得听。后来换成云端TTS好很多但延迟高、每月免费额度有限。于是又试了开源TTS方案。现在开源TTS里比较火的有Edge-TTS微软的免费接口、ChatTTS、还有各种基于VITS的模型。Edge-TTS胜在部署简单、延迟低、音色自然缺点是需要联网获取tokenChatTTS本地跑支持声音克隆但生成速度和稳定性还差点意思。如果你不追求本地离线用Edge-TTS是性价比极高的选择。还要特别注意“流式播放”这个细节不要等整段话合成完再播那样会让用户等很久。应该把文本切成短句合成一部分播一部分这样体感延迟会大幅降低。这点在后面的代码里也会体现。3. 实操过程从麦克风到扬声器的完整链路3.1 硬件环境与准备我做这套用的是最基础的配置树莓派4B4GB版本 USB麦克风阵列 3.5mm音箱。为什么用树莓派因为项目要部署到门店现场树莓派体积小、功耗低、安静24小时开机不心疼。如果你只是在电脑上测试完全不用额外买硬件直接用笔记本的麦克风或耳机麦克风就行。系统方面Windows / macOS / Linux都可以代码是跨平台的注意一下音频设备的输入输出索引就好。为了方便演示下面所有代码我都用Python写。3.2 录音与语音识别麦克风数据怎么变成文字录音这一步的核心是用pyaudio采集麦克风数据保存成wav文件然后喂给ASR模型。import pyaudio import wave def record_audio(duration5, sample_rate16000, device_indexNone): chunk 1024 p pyaudio.PyAudio() stream p.open(formatpyaudio.paInt16, channels1, ratesample_rate, inputTrue, frames_per_bufferchunk, input_device_indexdevice_index) frames [] for _ in range(0, int(sample_rate / chunk * duration)): data stream.read(chunk) frames.append(data) stream.stop_stream() stream.close() p.terminate() with wave.open(temp.wav, wb) as wf: wf.setnchannels(1) wf.setsampwidth(p.get_sample_size(pyaudio.paInt16)) wf.setframerate(sample_rate) wf.writeframes(b.join(frames)) return temp.wav注意采样率设置成16000就够了ASR模型基本都支持16k音频采样率太高反而浪费存储和带宽。录音时长我建议设置成5秒左右——太短用户说不完太长等待时间太煎熬。如果用了VAD语音活动检测就可以实现“用户不说话时自动停止录音”这个属于进阶优化后面会讲。录音完成后调用FunASR识别from funasr import AutoModel model AutoModel(modelparaformer-zh, model_revisionv2.0.4) res model.generate(inputtemp.wav, batch_size_s300) text res[0][text] print(识别结果:, text)这里用到的paraformer-zh是阿里开源的中文语音识别模型在普通话和带口音的语音上表现都不错CPU也能跑。首次运行会自动下载模型权重网络好的话等几分钟就行。你还可以通过hotword参数传入热词比如model.generate(..., hotword门店名称 产品型号)能明显提升专有名词的识别准确率。3.3 对话生成带知识库的LLM调用对话模块是核心。我采用的是“FAQ检索优先 LLM兜底”的策略。第一步先维护一个简单的知识库用句子向量检索选出最接近的问题如果相似度超过阈值直接返回预设答案from sentence_transformers import SentenceTransformer import numpy as np # 示例知识库 faq [ 你们的营业时间是几点, 产品保修多久, 这款产品多少钱, 有哪些颜色可以选择, 可以开发票吗 ] answers [ 我们的营业时间是每天早上9点到晚上9点。, 产品保修一年主要部件可以保修两年。, 这款产品目前售价是2999元。, 目前有白色、银色和深空灰三种颜色。, 可以的购买后联系客服即可开具电子发票。 ] encoder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) query_embedding encoder.encode([text]) faq_embeddings encoder.encode(faq) scores np.dot(faq_embeddings, query_embedding.T).flatten() best_idx np.argmax(scores) if scores[best_idx] 0.6: # 置信度阈值 reply answers[best_idx] else: # 走LLM兜底 reply call_llm(text)为什么阈值设0.6太小会把无关问题硬匹配到FAQ上太大则大部分问题都跑到LLM去失去了缓存的意义。这个值要根据实际测试微调我当时在真实问答集上调到0.58~0.65之间最舒服。call_llm函数我用的标准OpenAI SDK格式因为国产大模型大多兼容这套协议换模型只需要改base_url和api_keyfrom openai import OpenAI client OpenAI( base_urlhttps://your-llm-api.com/v1, api_keyyour-api-key ) SYSTEM_PROMPT 你是一个门店智能导购助手请用简洁、友好、口语化的方式回答客户问题回答尽量不超过50个字。如果不确定就说需要帮客户联系人工。 def call_llm(user_text): resp client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_text} ], temperature0.3, max_tokens150 ) return resp.choices[0].message.contenttemperature参数建议设低一点0.2~0.4这样回答更稳定、更可控。如果是闲聊场景可以适当调高但作为客服导购稳定大于创意。3.4 语音合成与播放让回复“说”出来语音合成我用的是Edge-TTS。它虽然是微软接口但目前的调用方式非常轻量音色自然度也不输付费产品import asyncio import edge_tts async def text_to_speech(text, output_file): tts edge_tts.Communicate(text, voicezh-CN-XiaoxiaoNeural) await tts.save(output_file) asyncio.run(text_to_speech(reply, reply.mp3))然后播放就简单了用PlaySound或者mpv都行from playsound import playsound playsound(reply.mp3)这里有一个实战经验如果对响应速度要求高不要等整段文字合成完而是把LLM返回的完整回复按标点切分成短句每句合成后立即播放用户听到第一句话的时间能压缩一半以上。切分逻辑并不复杂就是按。\n这几个符号做split合成和播放用子线程队列串起来。这个优化实测能把“用户说完到听到首个回复”的时间从2.5秒降到1.2秒左右体感差异非常明显。3.5 串联主循环一次完整对话主循环就是把上面几段串起来。为了不让程序卡死我用的是最简单的“按键触发”模式——按回车开始录音录完自动识别、对话、播放import threading if __name__ __main__: print(按回车开始说话CtrlC退出) while True: input() print(录音中...) wav_file record_audio(duration5) user_text asr(wav_file) print(你说:, user_text) reply get_reply(user_text) # FAQ优先LLM兜底 print(机器人:, reply) tts_and_play(reply)到这里一个最简单的智能语音对话机器人就已经能跑起来了。把它塞进树莓派接好音箱和麦克风就是一个能听会说的实体设备。4. 常见问题与排查技巧实录4.1 识别不准确问题往往不在模型而在音频很多人发现ASR识别得不准第一反应是换更强的模型但实际上“音频质量”才是第一问题。我在门店调试时发现麦克风离人太远、音箱声音串进麦克风导致回声、环境底噪太大这三者才是罪魁祸首。简单排查顺序把录音文件保存下来自己听一遍。如果人耳都听不清就别指望模型了。检查麦克风增益是不是太高太高容易削波削波后语音特征被破坏比声音小更严重。检查是不是音箱播报时麦克风还在录音V1阶段最简单的方式是播放回复期间把麦克风静音避免回声进入录音。测试时在安静环境下先跑一遍确认链路没问题再慢慢引入噪音环境。另外记得利用ASR热词表这个前面提到过。把场景中专有名词、产品型号、地名都塞进去识别率能提升几个百分点属于投入产出比极高的优化。4.2 延迟太大提升体感速度的三个做法智能语音对话机器人最影响体验的就是延迟。用户按下说话键、说完话如果两三秒还没听到回复就会觉得“坏了”“卡了”。我实测下来的延迟分布大概是ASR 0.5秒、LLM 0.8~2秒、TTS 1秒。整体串行下来感知特别明显。解决办法有三个第一ASR用流式识别在用户说话的同时就出识别结果而不是等录音结束后再识别。FunASR支持流式模型paraformer-streaming效果可以但部署复杂度高一些。第二TTS改成短句边合成边播放前文已说响应体感能好很多。第三如果走云端API选一个网络延迟低的接口地址尽量把服务部署在离目标用户近的机房。这里记住一句话用户感知不到“你快”但一定能感知到“你慢”。宁可回复质量略降也要先保证首句快速响起。4.3 常见问题速查表现象可能原因解决方案录音文件是空白/silence麦克风没选对、权限没开启检查设备索引和系统权限ASR结果乱码或空文本音频采样率不对、太短统一为16k单声道录制3秒以上LLM长时间无响应网络问题、模型负载高设置超时和重试加入流式输出TTS播放断断续续网络波动导致合成卡顿启用本地音频缓存、预合成常用回复机器人听到自己的播报回声问题播放时关闭麦克风或使用回声消除模块程序运行几小时就崩内存泄漏、pyaudio流没关闭检查线程和资源释放加看门狗脚本4.4 进阶优化唤醒词、打断与多轮对话V1跑通之后你再考虑体验升级。唤醒词我建议用开源方案比如openWakeWord或snowboy虽然snowboy已停更多年但还有人在用。唤醒词的作用是让机器人从“按键触发”变成“随时听令”。注意唤醒词模型吃CPU树莓派上要选轻量模型不然会影响ASR的实时性。打断机制是另一个体验升级点就是用户说话时可以随时插话机器人自动闭嘴听用户新指令。实现逻辑不难TTS播放线程检测到VAD检测到新语音就停止播放然后切换到识别流程。难的是处理好状态机避免“自己说话触发自己打断”这类死循环。多轮对话则要看场景。如果只是问答机器人每轮独立反而更稳定不会出现上下文跑偏的问题。如果要做深度多轮比如“帮我比较下这款和那款的区别”这种有指代的话那就要在LLM调用时传入多轮历史消息同时控制历史长度太长了之后既慢又贵还容易让模型混淆身份。最后说几句实在话这套玩意做完我最深刻的体会是智能语音对话机器人真正难的不是单个模型有多聪明而是三个环节之间的衔接稳不稳。很多方案单独测试效果都不错一连起来就各种问题——音频没采到、识别太慢、模型答非所问、TTS机械音。建议你做的时候一定按“主链路优先、花活靠后”的节奏来。另外一个小建议不管用什么方案记得把每一轮的语音、识别文本、回复文本都打日志存下来。这些数据是最宝贵的测试集后面优化任何环节都靠它。项目交付之后整理这些语料也可以用来做场景化微调。做这个机器人最开心的瞬间是看到真实用户第一次听到它答复时眼睛一亮的样子。那一刻你就会觉得前面那些跟回声、跟延迟、跟断句较劲的时间都值了。本文还有配套的精品资源点击获取