本篇速览AidVoice 是 AidLux 工具链中负责声音模态的组件核心能力是端侧语音识别ASR并向上延伸到语音翻译、会议纪要与 RAG 检索增强。端侧语音助手的标准链路是麦克风采集 → 音频前处理降噪/回声消除/唤醒→ ASR 转文字 → 大模型理解生成 → 文字或语音TTS返回。衡量端侧语音的两个关键指标是 RTF实时率流式交互需明显小于 1和 WER/CER词/字错误率越低越准验收要用固定测试集量化而非凭感觉。单纯 ASR 可在犀牛派 A1 上运行ASR 大模型的较重组合会议纪要、RAG建议评估算力更高的犀牛派 X1。一、给系统装上耳朵和嘴巴1.1 视觉和语言之外还缺听觉第 9 讲结尾我们留了个话头到目前这套系统的看AidCV/AidStream 的视觉和想AidLite 推理、AidGen 大模型已经跑通连跨系统的神经网络AidConnect也打通了。但回想一下人和人打交道最自然的方式——不是看也不是打字而是说话。对一个要摆在真实场景里的端侧产品“能听懂人话、能开口回答往往是最低门槛的交互产线工人戴着手套不方便点屏幕、车载场景不能低头看手机、老人孩子更习惯张口就问。这一讲我们就给系统装上耳朵和嘴巴”。1.2 端侧语音的价值语音识别ASR和语音处理不是新鲜技术云端方案一抓一大把。那为什么要在端侧做逻辑和端侧大模型一脉相承一是隐私语音是高度敏感的数据对话、会议、家庭环境能不出本机就不出本机二是离线可用车载、野外、车间这些网络不稳的地方云端语音识别一断网就哑三是低延迟本地识别省去了上传音频、等云端返回的往返响应更跟手。这三点叠加让端侧语音在很多数据敏感或网络不稳的场景里成为必选项。1.3 本讲目标与硬件准备读完本讲你应该能第一理解 AidVoice 在工具链里管哪条线、和 AidGen/AidLite 怎么配合第二跑通端侧语音识别把一段语音变成文字第三把 ASR 和前面的大模型串起来做一个语音进、语音/文字出的问答雏形第四理解会议纪要和 RAG 这两类进阶语音应用的搭建思路。硬件上以**犀牛派 A1QCS6490**为主——单纯的语音识别算力需求不高入门板即可跑通也延续了高低搭配里入门能力的演示。涉及语音 大模型的较重组合如会议纪要、RAG算力更高的犀牛派 X1 体验更从容文中会注明。1.4 语音链路的全景从声波到回答在动手前先把语音交互这条链路的全貌看清楚免得只见树木不见森林。一个完整的语音问答大致是这样一条流水线麦克风采集语音识别 ASR语音转文字大模型理解/生成AidGen文字回答 / 语音播报麦克风采到声波ASR 把它转成文字文字交给大模型理解并生成回答回答再以文字或语音合成 TTS返回。本讲的重心是ASR 这一环也是 AidVoice 的核心以及它和大模型的衔接。理解了这条链你就知道每一环该找哪个组件、坑可能出在哪一环。二、AidVoice 在工具链中的位置2.1 它管声音这条线如果把工具链按模态分工AidCV/AidStream 管图像和视频AidGen 管语言文本那么 AidVoice 管的就是声音——语音的采集处理、识别、以及围绕语音的几类应用。它和前面那些组件是并列又互补的关系各自负责一种模态最终在第 11 讲的综合实战里汇合。2.2 与 AidGen / AidLite 的关系AidVoice 不是孤岛。它的几种典型用法都要和前面的组件搭伙最典型的是ASR AidGen——语音转文字后交给大模型就成了能对话的语音助手第 7、8 讲的大模型在这里有了嘴和耳朵而 ASR 本身的推理底层同样落在 AidLite 的 NPU 加速能力上。所以你之前建立的AidLite 是统一推理底座、AidGen 管生成的认知在语音这条线上依然成立只是输入从图像/文本换成了声波。2.3 能力矩阵ASR / 翻译 / 会议纪要 / RAGAidVoice 覆盖的几类能力可以按复杂度递进理解语音识别ASR基础能力把语音实时转成文字。这是一切语音应用的地基。语音翻译在 ASR 之上加一层翻译把一种语言的语音转成另一种语言的文字。会议纪要对长段语音如一场会议做识别再借助大模型做分段、提炼、总结产出结构化纪要。RAG检索增强生成让大模型回答时参考你给的资料——先识别问题语音再从你的文档库里检索相关内容最后让大模型基于这些内容作答避免它凭空乱编。这四者里ASR 是本讲的实战重点后三者是ASR 大模型的组合应用理解思路即可具体支持范围以 AidLux 官方文档为准。2.4 端侧语音与云端语音的边界和端侧大模型一样要清醒看待端侧语音的边界。云端语音服务在嘈杂环境、强口音、专业词汇上的识别率往往仍好于端侧小模型端侧则赢在即插即用、离线、隐私。所以这还是云端补充的关系网络好、数据不敏感、追求极致识别率的场景可以用云端数据敏感、要离线、要低延迟的场景交给端侧。选型时先问自己这段语音敢不敢出本机这网络靠不靠得住2.5 端侧语音的典型落地场景装了耳朵和嘴巴到底用在哪几个典型场景一是语音控制——产线设备、智能家居工人/用户张口下指令“启动”“调高一档”设备照做解放双手二是语音问答助手——导览机、就诊前分诊、设备故障咨询用户问、设备答三是会议与记录——会议室里的设备自动把讨论转成文字、整理成纪要3.3四是跨语言沟通——展会、旅游的实时翻译3.2。这些场景的共同点是免动手或数据敏感恰是端侧语音的主场。想清楚你的产品属于哪一类才知道该把识别率、延迟还是离线能力排在第一位。2.6 一张表看懂端侧语音助手的技术栈把语音助手拆成层每层该找谁、关注什么一张表说清层级作用对应组件/技术关键指标采集层拾取声波麦克风 / 麦克风阵列采样率、信噪比前处理层净化音频降噪、回声消除(AEC)、波束成形降噪量、回声抑制唤醒层随叫随到唤醒词(KWS)、端点检测(VAD)误唤醒率、漏唤醒率识别层语音转文字AidVoice ASR底层走 AidLite NPURTF、WER/CER理解层理解并生成回答AidGen / AidGenSE 大模型首 token 延迟、正确性表达层输出回答文字显示 / 语音合成(TTS)合成延迟、自然度这张表也是一张排障地图体验不好时先定位问题出在哪一层再用对应层的指标去量化、去调。比如叫不应查唤醒层、识别错查识别层、答非所问查理解层。后文会逐层展开但先有这张全景图你就不容易在某一层的细节里迷路。三、核心能力拆解3.1 ASR把语音变成文字ASR 的本质是把连续的声波信号映射成对应的文字序列。现代端侧 ASR 多是深度学习模型先把声波切成帧、提取声学特征再由模型逐帧识别、对齐成文字。你不必手写这些但要理解两个影响体验的关键一是采样率与格式模型认特定的采样率和位深喂错了识别率骤降二是流式 vs 整段——流式识别边录边出字适合实时对话整段识别录完再一次性转适合录音转写。端侧做实时交互通常要流式。3.2 语音翻译语音翻译 ASR源语言→源文字 机器翻译源文字→目标文字。端侧做翻译的价值在于出国/跨语言沟通时无网也能用。它的难点是两级误差的叠加ASR 识别错一个字翻译就跟着错。所以翻译场景的验收要把识别准和翻译顺分开测定位误差来自哪一级。3.3 会议纪要ASR 大模型总结会议纪要是ASR 大模型的典型组合先把整场会议的语音转成长文本ASR再把长文本喂给大模型做提炼——分议题、抓决议、列待办。这里的工程要点是长文本处理一场会可能几万字远超大模型的上下文长度 cl回忆第 7 讲所以要先把转写文本切段、分段总结、再汇总而不是一股脑塞进去。这也是第 8 讲客户端历史管理思想的延伸——只是这里管理的是长文档而非多轮对话。3.4 RAG让大模型基于你的资料回答RAG检索增强生成解决的是大模型知识陈旧、会瞎编的痛点。思路是把你的资料产品手册、故障文档、内部知识提前切成小段、算成向量存起来当用户提问语音经 ASR 转成文字时先按问题去库里检索最相关的几段再把这些段连同问题一起喂给大模型让它看着资料回答。这样大模型的回答就有了依据不会凭空捏造。端侧做 RAG 的意义是资料留在本机保密、离线也能问答。它的关键环节是检索质量——找得准不准直接决定答得对不对。3.5 音频前处理降噪、回声消除与唤醒真实环境不是录音棚麦克风采到的声音往往混着噪声和回声直接喂给 ASR识别率会大打折扣。所以识别之前通常要一道音频前处理降噪滤掉恒定的背景嗡鸣回声消除AEC——若设备自身在放音麦克风会把扬声器的声音也收进来形成回声必须消掉否则设备会被自己吵醒波束成形多麦克风阵列聚焦说话人方向。还有一个让体验质变的前置环节是唤醒词设备平时休眠只在听到唤醒词后才启动识别既省电又避免误触发。这些前处理的具体支持以官方文档与选型为准但理解原始音频 → 前处理 → 干净音频 → ASR这条前置链是做好语音产品的必修课。3.6 端点检测VAD怎么知道你说完了流式识别里有个细节很关键系统怎么判断你说完了一句从而把这句话定稿、交给下游靠的是端点检测VADVoice Activity Detection——持续分析音频区分有人在说和静音/噪声。检测到说话开始就收音检测到一段足够长的静音就判为说完输出这句的最终结果。VAD 的灵敏度直接影响体验太迟钝你说完了它还在等显得反应慢太敏感你中间停顿一下就误判结束把一句话截成两段。调 VAD 就是调这个判停的时机通常要结合 RTF8.2与端点静音阈值一起权衡。四、环境调研安装与模型4.1 安装 AidVoiceAidVoice 通过aid-pkg安装具体包名以 AidLux 官方文档为准sudoaid-pkg updatesudoaid-pkginstallaidvoice# 包名以文档为准装完用aid-pkg installed确认 AidVoice 在列、版本正确。部分语音能力可能还需单独下载识别模型按官方文档指引备好。4.2 语音模型与版本ASR 模型和前面的大模型、检测模型一样有模型 → 组件版本 → 底层 QNN 版本的对齐关系。从 Model Farm 或 AidVoice 自带渠道获取识别模型时确认它适配你的板型A1 是 QCS6490和当前 AidVoice 版本。把这行也并进你那张版本总表——到这一讲表里已经有 QNN、AidLite、AidGen、模型等多行了统一管理能省去大量版本对不上的玄学问题。4.3 麦克风与音频输入语音的源头是麦克风。犀牛派上接麦克风有几种方式USB 麦克风、3.5mm 音频、或板载/阵列麦具体看板型与外设关键是让系统认出这个输入设备。在 Linux 侧可用arecord -l列出录音设备、用arecord录一段测试音确认能采到声。还要确认应用有访问音频设备的权限。采不到声后面全是白搭——所以这一步务必先验证。4.4 单麦 vs 麦克风阵列拾音硬件直接决定识别上限。单个麦克风便宜简单但只能近讲、抗噪弱麦克风阵列多个麦克风按几何排布能做波束成形、定向拾音与降噪远场几米外也能听清是会议、客厅这类远距离场景的刚需。选型按使用距离与环境噪声定近场、安静、低成本用单麦远场、嘈杂、重体验用阵列。阵列还牵涉多路音频的同步采集硬件与驱动要配套。别指望靠算法弥补拾音硬件的硬伤——听清永远排在识别准前面。五、操作步骤跑通语音识别下面以在犀牛派 A1 上把一段语音实时识别成文字为例讲流程。具体命令、API、参数以 AidVoice 当前版本文档为准这里讲不变的逻辑。5.1 准备音频输入先确认麦克风被系统识别arecord -l应能列出你的录音设备。录一段 3 秒测试音arecord -d 3 -f cd test.wav之类再回放确认采到了清晰的声音。这一步过了才往下走。5.2 跑一次 ASR用 AidVoice 提供的识别能力对一段音频或实时流做一次识别。先用一段内容已知的录音比如你清晰地说一句今天天气不错跑确认识别输出和你说的一致。用已知答案的音频做首次验证能立刻判断是识别不准还是链路没通——这和第 9 讲的探针调试是同一思路。5.3 实时 / 流式识别整段识别跑通后切到流式边说边出字。流式是语音助手这类实时交互的必需。观察两件事一是延迟说完多久出字二是断句能不能在你说完一句时给出稳定结果。流式识别通常涉及按小块音频持续喂给模型、持续取回增量文字具体接口以文档为准。5.4 接大模型做问答识别出文字后把它交给第 8 讲起好的 AidGenSE 本地服务ASR 出的文字作为用户输入POST 给/v1/chat/completions拿回大模型的回答。到这一步“语音进、文字出的问答雏形就成了。如果还要语音出”可再接一层语音合成TTS把回答读出来——TTS 是否在 AidVoice 范围内以官方文档为准。5.5 把语音链路接进 Android呼应 AidConnect第 9 讲的 AidConnect 在这里正好派上用场如果语音助手的界面在 Android 侧而 ASR、大模型在 Linux 侧跑那么识别文字上行、回答文字下行就走 AidConnect。Android 侧管采集/展示Linux 侧管识别/理解两侧用第 9 讲的通道交换文本。文本是小数据走 AidConnect 的轻量通道即可不必动用为零拷贝准备的大通道。这样第 9 讲的跨系统能力和本讲的语音能力就衔接上了——你在 Android App 里说一句话Linux 侧识别加大模型作答回答再回到 App 显示。这也为第 11 讲的综合实战埋好了线。六、关键代码语音 → 文字 → 回答6.1 ASR 最小调用AidVoice 识别的最简骨架API 以官方文档为准这里用 Python 示意# AidVoice ASR 最小调用示意类名/方法以官方文档为准importaidvoice# 示意包名asraidvoice.ASR(model/home/aidlux/models/asr-zh,sample_rate16000)textasr.transcribe(/home/aidlux/audio/test.wav)# 对整段音频识别print(识别结果:,text)要点指定和模型匹配的采样率常见 16kHz、给出正确的音频路径。识别不准时先查采样率/格式对不对。6.2 流式识别流式识别按小块持续喂音频、持续取增量文字# 流式识别示意API 以官方文档为准asraidvoice.ASR(model/home/aidlux/models/asr-zh,sample_rate16000)streamasr.create_stream()forchunkinmic_chunks():# 从麦克风持续读小音频块stream.feed(chunk)# 喂给识别流partialstream.partial_result()# 取当前增量/部分结果ifpartial:print(partial,end\r)# 边录边刷新显示print(\n最终:,stream.final_result())核心是边喂边取每喂一小块就能拿到当前识别到的部分文字说完一句取最终结果。延迟和断句体验就在这个循环里调。6.3 ASR AidGenSE 串成语音助手把识别结果发给第 8 讲的本地大模型服务串成问答# 语音 → 文字 → 大模型回答依赖第 8 讲的 AidGenSE 服务importrequests,aidvoice asraidvoice.ASR(model/home/aidlux/models/asr-zh,sample_rate16000)LLM_URLhttp://127.0.0.1:8888/v1/chat/completionsdefvoice_qa(wav_path):questionasr.transcribe(wav_path)# 1) 语音转文字print(你问:,question)resprequests.post(LLM_URL,json{# 2) 发给本地大模型model:qwen2.5-0.5b-instruct,messages:[{role:user,content:question}],},timeout120)answerresp.json()[choices][0][message][content]print(它答:,answer)returnanswer看两个组件一接能听会想的助手就出来了。这正是工具链模块化、可组合的好处——每个组件各管一段串起来就是产品。6.4 RAG 检索增强骨架RAG 的关键是先检索、再生成。骨架示意检索库与向量实现以实际选型为准# RAG 骨架检索 喂给大模型向量库实现以实际方案为准defrag_qa(question,kb,top_k3):docskb.search(question,top_ktop_k)# 1) 从知识库检索相关段落context\n.join(docs)promptf基于以下资料回答问题不要编造\n{context}\n\n问题{question}resprequests.post(LLM_URL,json{# 2) 把资料问题一起喂给大模型model:qwen2.5-0.5b-instruct,messages:[{role:user,content:prompt}],},timeout120)returnresp.json()[choices][0][message][content]要点检索kb.search找得准大模型才答得对prompt 里明确基于资料、不要编造能显著减少幻觉。资料要预先切段、建索引段太长会吃 cl。6.5 封装语音助手模块把录音 → 识别 → 问答 → 播报收进一个模块业务层只调一个入口# voice_assistant.py —— 语音助手封装classVoiceAssistant:def__init__(self,asr_model,llm_url):importaidvoice self.asraidvoice.ASR(modelasr_model,sample_rate16000)self.llm_urlllm_urldefask(self,wav_path):importrequests qself.asr.transcribe(wav_path)rrequests.post(self.llm_url,json{model:qwen2.5-0.5b-instruct,messages:[{role:user,content:q}],},timeout120)returnq,r.json()[choices][0][message][content]把模型路径、服务地址、异常处理都收口在这里别处assistant.ask(xx.wav)就能用。6.6 唤醒词让助手随叫随到语音助手若一直竖着耳朵全程监听既费电又容易误触发工程上普遍用唤醒词一个轻量模型持续监听只在检测到唤醒词如你好小犀时才唤醒完整的 ASR 链路。骨架示意# 唤醒 识别 两段式示意API 以实际选型为准whileTrue:ifkws.detect():# 轻量唤醒词检测常开、低功耗beep()# 提示已唤醒wavrecord_seconds(5)# 录一段指令qasr.transcribe(wav)# 完整 ASR 识别answerask_llm(q)# 交给大模型speak(answer)# 播报回答若接 TTS唤醒词模型要小而灵够轻才能常开不费资源够灵才能既不漏唤醒叫不应也不误唤醒没叫它自己跳。这两率的平衡是唤醒体验的关键。6.7 会议纪要实战长音频转写 大模型总结的完整流程把 3.3 的思路落成代码。一场会议转写出来可能几万字远超上下文长度 cl所以要分段转写 → 分段总结 → 汇总# 会议纪要分段转写 分段总结 汇总API 以实际为准defmeeting_minutes(long_wav):segmentssplit_by_silence(long_wav)# 1) 按静音切成若干小段transcript.join(asr.transcribe(s)forsinsegments)# 2) 逐段转写后拼接chunkssplit_text(transcript,max_len1500)# 3) 按 cl 切成文本块partials[ask_llm(f总结这段会议内容的要点\n{c})forcinchunks]# 4) 分段总结finalask_llm(把以下分段要点汇总成会议纪要议题/决议/待办\n\n.join(partials))# 5) 汇总returnfinal要点音频按静音切别从句子中间剁开文本按 cl 切块给 prompt 留出余量先分段后汇总两层摘要防超长。这套切—转—分—汇的流程是处理一切超长大模型输入的通用套路。6.8 实战把嘈杂环境的识别率拉回可用线实验室里识别很准、一到车间或展会就崩是语音产品的常态。把识别率从实验室可用拉到现场可用有一套组合拳按代价从低到高一是靠近与定向——让使用者离麦更近或用麦克风阵列定向拾音这是最便宜也最有效的一招二是前处理拉满——确认降噪、回声消除真正开启并调到位很多识别差其实是前处理没开三是热词/自定义词表——把产品名、行业术语加进词表专业词汇的识别率会立竿见影地改善四是模型升级——在前三步都做到位后仍不够再考虑换更大的识别模型或评估云端方案。顺序很关键先物理距离/指向、再前处理、再词表、最后才换模型——多数人跳过前三步直接怪模型其实是把最便宜的办法漏掉了。七、坑点7.1 麦克风采不到 / 权限最常见的坑是根本没采到声。按顺序查设备有没有被识别arecord -l、应用有没有音频权限、麦克风是不是插对了口/被系统独占。先用arecord录一段回放确认有声再谈识别。7.2 识别不准采样率 / 格式 / 噪声识别出来驴唇不对马嘴多半是音频参数不匹配模型要 16kHz你喂了 44.1kHz或声道、位深不对。其次是环境背景噪声大、离麦太远、口音重识别率都会掉。对策严格按模型要求准备音频参数尽量在安静环境、靠近麦克风测试专业词汇多的场景看模型是否支持自定义词表。7.3 实时性不够延迟边说边等半天才出字体验就垮了。实时性受模型大小、板子算力、喂音频的块大小影响。对策用流式而非整段、块大小取折中太小频繁调用开销大、太大延迟高、算力紧张时换更小的识别模型。实时性指标看 8.2 的 RTF。7.4 模型 / 版本不对加载失败或识别结果乱回到版本对齐识别模型是否适配板型与 AidVoice 版本、QNN 版本是否满足4.2。语音模型对版本同样敏感别拿不匹配的模型硬用。7.5 长音频的内存与分段会议纪要这类长音频一次性加载整段既吃内存又可能超模型处理上限。对策把长音频按静音点或固定时长切段逐段识别再拼接转写文本喂大模型总结时同样要切段、分段总结再汇总3.3。“长的问题思路都是切”。7.6 误唤醒 vs 漏唤醒一对此消彼长的矛盾唤醒词调不好会有两种极端误唤醒没人叫它自己跳烦人和漏唤醒叫了却不应更烦人。调高灵敏度能减少漏唤醒却往往增加误唤醒调低减少误唤醒又容易漏。二者此消彼长。调法先用真实环境音含电视声、旁人聊天这类易误触发的干扰测出当前两率再按产品容忍度定阈值——家用场景宁可偶尔误唤醒也别叫不应工控场景宁可偶尔叫不应也别误动作。没有完美阈值只有适合场景的权衡。八、验证识别正确率与延迟8.1 识别正确性用一组内容已知的录音不同语速、不同内容跑识别逐句比对输出和标准答案算个大致正确率。重点看你场景里的关键词汇产品名、术语能不能识别对。正确性是语音验收的第一关。8.2 实时率 RTF语音识别的核心性能指标是RTFReal-Time Factor实时率 识别耗时 ÷ 音频时长。RTF 1 表示说得比识别慢能跟得上实时RTF 越小花得越快。流式交互通常要求 RTF 明显小于 1。测法给一段定长音频记录识别耗时相除即得。以你的真机实测为准和模型大小、算力强相关。8.3 端到端语音问答把 6.3 的链路完整跑几遍对着麦克风提问 → 识别 → 大模型回答。验证三件事识别准不准、回答对不对、整体延迟可不可接受。这是语音助手能否用的最终判据。若某环不达标回到对应环节调识别差看 7.2、回答差看模型、延迟高看 7.3。8.4 异常对照表语音链路出问题现象能反推病因。速查表“完全没识别出东西” → 麦克风/权限/音频参数7.1、7.2“识别内容乱” → 采样率格式不匹配或模型版本错7.2、7.4“出字特别慢” → 模型太大或非流式7.3、8.2“长音频崩” → 未分段、内存不足7.5“识别对但回答离谱” → 大模型或 RAG 检索问题6.3、6.4“离线就哑” → 误用了云端接口2.4。先对号入座再排查。8.5 用 WER 给识别率打个分“识别挺准的是感觉工程上要量化。语音识别通用的指标是WERWord Error Rate词错误率把识别结果和标准答案逐词比对数出替换 插入 删除的错误词数除以总词数WER 越低越准中文常按字算称 CER。验收时准备一批覆盖真实场景不同人、不同语速、含专业词汇的录音测出 WER/CER就有了可对比、可回归的基线——以后换模型、换参数用同一批音频重测便知是变好还是变差。把感觉准变成测得准”是语音从 Demo 走向产品的分水岭。8.6 端到端语音问答的延迟分解与达标线“语音助手反应慢要拆开看总延迟 ≈ ASR 识别延迟 大模型首 token 延迟 若有TTS 合成延迟 各段衔接开销。逐段打点计时才知道时间花在哪。一般经验从说完到开始出声控制在 1~2 秒内体验尚可超过 3 秒就明显肉”。达标手段也对应三段ASR 用流式、压 RTF8.2大模型压首 token换小模型、调小 cl见第 7、8 讲TTS 选更快的方案或边合成边播。把延迟拆到段、对段下药比笼统优化有效得多。8.7 搭建一套可回归的语音测试集语音效果会随模型、参数、环境变化靠每次随便说两句听听没法保证质量。建议搭一套固定测试集收集覆盖真实场景的录音不同人、不同语速、安静/嘈杂、近讲/远讲、含专业词汇配上标准文字答案固定存放。每次改模型、调参数、升级版本后用这套音频跑一遍自动算 WER/CER8.5和 RTF8.2与上一版基线对比。有了它“这次改动是变好还是变坏立刻有答案回归也有保障。这套测试集和检测模型的固定测试图”、大模型的固定问答是同一思路——都是把验收从感觉变成数据。九、FAQQ1AidVoice 只能做语音识别吗不止。它覆盖 ASR、语音翻译、会议纪要、RAG 等语音相关能力2.3。ASR 是地基其余多是ASR 大模型的组合应用具体支持范围以官方文档为准。Q2离线能用吗能。端侧识别的意义之一就是离线可用2.4。但如果你把识别接到的是云端大模型 API那断网时那半截就断了——全离线要把大模型也放本地第 8 讲的 AidGenSE。Q3识别支持哪些语言取决于所选识别模型。中文、英文通常都有对应模型多语言/方言支持以 Model Farm 与 AidVoice 文档为准。Q4为什么识别率不如手机上的语音助手手机助手多走云端大模型 海量数据训练端侧受算力和模型尺寸限制识别率有差距是正常的2.4。端侧的价值在隐私、离线、低延迟不是替代云端追求极限识别率。Q5TTS语音合成也包含吗语音出需要 TTS 把文字读出来。是否在 AidVoice 范围内、如何用以官方文档为准。本讲重心是 ASR 与问答链路。Q6怎么提升专业领域的识别率看模型是否支持自定义词表/热词把产品名、术语加进去同时保证音频质量近讲、降噪。实在不行专业场景可评估云端识别。Q7RAG 一定要向量数据库吗小规模资料可以用简单的关键词/相似度检索不一定上完整向量库。核心是检索出相关段落喂给大模型这个思路实现可繁可简。Q8语音 大模型A1 跑得动吗单纯 ASR 在 A1 上没问题ASR 大模型尤其 RAG、会议纪要对算力和内存要求高A1 偏紧建议评估 X1。具体以真机实测为准。Q9实时对话的延迟主要来自哪三段ASR 识别延迟、大模型首 token 延迟、若有TTS 合成延迟。逐段测哪段高调哪段——ASR 看 7.3大模型看第 7、8 讲的调优TTS 看其自身配置。Q10怎么把语音和前面的视觉结合起来那就是多模态应用了——比如看到画面 听懂问题 → 综合回答。这正是下一讲综合实战要做的把视觉、语音、大模型、跨系统通信装配成一个端到端应用。十、结论这一讲我们给系统装上了耳朵和嘴巴用 AidVoice 跑通了端侧语音识别把声波变成文字又把它和第 8 讲的本地大模型接起来做出语音进、文字出的问答雏形并理清了会议纪要、RAG 这两类ASR 大模型进阶应用的搭建思路。你也摸清了语音链路特有的坑——采样率格式、流式实时性、长音频分段。把视野再拉远一层到这里这套系统的感知模态基本齐了——能看视觉、能听语音、能想推理与大模型、还能跨系统传AidConnect。每一块你都单独跑通过。但每块都会依然不等于能攒成一个产品。真实的产品是这些模态的协同摄像头看着、麦克风听着、大模型想着、屏幕和扬声器反馈着。怎么把这些零件编排成一个稳定、清晰、可维护的端到端应用这正是下一讲的主题——多组件协同的综合实战我们把前九讲的所有零件真正装配成一个完整作品。本文 AidVoice 的定位、ASR/翻译/会议纪要/RAG 能力划分、端侧语音方案等来自 AidLux 官方文档RTF、流式识别、RAG 检索增强等原理为语音与 NLP 领域通用知识识别率与延迟等指标随模型、算力与环境而异精确值以真机实测与当前版本文档为准。文中 API、类名、代码为结构示意具体以 AidVoice SDK 与官方文档为准。