企业官网建设流程全解析

本篇速览

• 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 这两类进阶语音应用的搭建思路。

硬件上以**犀牛派 A1（QCS6490）**为主——单纯的语音识别算力需求不高，入门板即可跑通，也延续了"高低搭配"里入门能力的演示。涉及"语音 + 大模型"的较重组合（如会议纪要、RAG），算力更高的犀牛派 X1 体验更从容，文中会注明。

1.4 语音链路的全景：从声波到回答

在动手前，先把"语音交互"这条链路的全貌看清楚，免得只见树木不见森林。一个完整的语音问答，大致是这样一条流水线：

麦克风采到声波，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 / 翻译 / 会议纪要 / RAG

AidVoice 覆盖的几类能力，可以按"复杂度递进"理解：

• 语音识别（ASR）：基础能力，把语音实时转成文字。这是一切语音应用的地基。
• 语音翻译：在 ASR 之上加一层翻译，把一种语言的语音转成另一种语言的文字。
• 会议纪要：对长段语音（如一场会议）做识别，再借助大模型做分段、提炼、总结，产出结构化纪要。
• RAG（检索增强生成）：让大模型回答时"参考你给的资料"——先识别问题语音，再从你的文档库里检索相关内容，最后让大模型基于这些内容作答，避免它凭空乱编。

这四者里，ASR 是本讲的实战重点，后三者是"ASR + 大模型"的组合应用，理解思路即可，具体支持范围以 AidLux 官方文档为准。

2.4 端侧语音与云端语音的边界

和端侧大模型一样，要清醒看待端侧语音的边界。云端语音服务在嘈杂环境、强口音、专业词汇上的识别率，往往仍好于端侧小模型；端侧则赢在即插即用、离线、隐私。所以这还是"云端补充"的关系：网络好、数据不敏感、追求极致识别率的场景可以用云端；数据敏感、要离线、要低延迟的场景交给端侧。选型时先问自己：这段语音敢不敢出本机？这网络靠不靠得住？

2.5 端侧语音的典型落地场景

装了"耳朵和嘴巴"，到底用在哪？几个典型场景：一是语音控制——产线设备、智能家居，工人/用户张口下指令（“启动”“调高一档”），设备照做，解放双手；二是语音问答助手——导览机、就诊前分诊、设备故障咨询，用户问、设备答；三是会议与记录——会议室里的设备自动把讨论转成文字、整理成纪要（3.3）；四是跨语言沟通——展会、旅游的实时翻译（3.2）。这些场景的共同点是"免动手"或"数据敏感"，恰是端侧语音的主场。想清楚你的产品属于哪一类，才知道该把识别率、延迟还是离线能力排在第一位。

2.6 一张表看懂端侧语音助手的技术栈

把"语音助手"拆成层，每层该找谁、关注什么，一张表说清：

这张表也是一张排障地图：体验不好时先定位问题出在哪一层，再用对应层的指标去量化、去调。比如"叫不应"查唤醒层、"识别错"查识别层、"答非所问"查理解层。后文会逐层展开，但先有这张全景图，你就不容易在某一层的细节里迷路。

三、核心能力拆解

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）：怎么知道"你说完了"

流式识别里有个细节很关键：系统怎么判断你"说完了一句"，从而把这句话定稿、交给下游？靠的是端点检测（VAD，Voice Activity Detection）——持续分析音频，区分"有人在说"和"静音/噪声"。检测到说话开始就收音，检测到一段足够长的静音就判为"说完"，输出这句的最终结果。VAD 的灵敏度直接影响体验：太迟钝，你说完了它还在等，显得反应慢；太敏感，你中间停顿一下就误判结束，把一句话截成两段。调 VAD 就是调这个"判停"的时机，通常要结合 RTF（8.2）与端点静音阈值一起权衡。

四、环境调研：安装与模型

4.1 安装 AidVoice

AidVoice 通过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# 示意包名asr=aidvoice.ASR(model="/home/aidlux/models/asr-zh",sample_rate=16000)text=asr.transcribe("/home/aidlux/audio/test.wav")# 对整段音频识别print("识别结果:",text)

要点：指定和模型匹配的采样率（常见 16kHz）、给出正确的音频路径。识别不准时，先查采样率/格式对不对。

6.2 流式识别

流式识别按小块持续喂音频、持续取增量文字：

# 流式识别示意，API 以官方文档为准asr=aidvoice.ASR(model="/home/aidlux/models/asr-zh",sample_rate=16000)stream=asr.create_stream()forchunkinmic_chunks():# 从麦克风持续读小音频块stream.feed(chunk)# 喂给识别流partial=stream.partial_result()# 取当前增量/部分结果ifpartial:print(partial,end="\r")# 边录边刷新显示print("\n最终:",stream.final_result())

核心是"边喂边取"：每喂一小块，就能拿到当前识别到的部分文字，说完一句取最终结果。延迟和断句体验，就在这个循环里调。

6.3 ASR + AidGenSE 串成语音助手

把识别结果发给第 8 讲的本地大模型服务，串成问答：

# 语音 → 文字 → 大模型回答（依赖第 8 讲的 AidGenSE 服务）importrequests,aidvoice asr=aidvoice.ASR(model="/home/aidlux/models/asr-zh",sample_rate=16000)LLM_URL="http://127.0.0.1:8888/v1/chat/completions"defvoice_qa(wav_path):question=asr.transcribe(wav_path)# 1) 语音转文字print("你问:",question)resp=requests.post(LLM_URL,json={# 2) 发给本地大模型"model":"qwen2.5-0.5b-instruct","messages":[{"role":"user","content":question}],},timeout=120)answer=resp.json()["choices"][0]["message"]["content"]print("它答:",answer)returnanswer

看，两个组件一接，"能听会想"的助手就出来了。这正是工具链"模块化、可组合"的好处——每个组件各管一段，串起来就是产品。

6.4 RAG 检索增强骨架

RAG 的关键是"先检索、再生成"。骨架示意（检索库与向量实现以实际选型为准）：

# RAG 骨架：检索 + 喂给大模型，向量库实现以实际方案为准defrag_qa(question,kb,top_k=3):docs=kb.search(question,top_k=top_k)# 1) 从知识库检索相关段落context="\n".join(docs)prompt=f"基于以下资料回答问题，不要编造：\n{context}\n\n问题：{question}"resp=requests.post(LLM_URL,json={# 2) 把资料+问题一起喂给大模型"model":"qwen2.5-0.5b-instruct","messages":[{"role":"user","content":prompt}],},timeout=120)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.asr=aidvoice.ASR(model=asr_model,sample_rate=16000)self.llm_url=llm_urldefask(self,wav_path):importrequests q=self.asr.transcribe(wav_path)r=requests.post(self.llm_url,json={"model":"qwen2.5-0.5b-instruct","messages":[{"role":"user","content":q}],},timeout=120)returnq,r.json()["choices"][0]["message"]["content"]

把模型路径、服务地址、异常处理都收口在这里，别处assistant.ask("xx.wav")就能用。

6.6 唤醒词：让助手"随叫随到"

语音助手若一直竖着耳朵全程监听，既费电又容易误触发，工程上普遍用唤醒词：一个轻量模型持续监听，只在检测到唤醒词（如"你好小犀"）时才唤醒完整的 ASR 链路。骨架示意：

# 唤醒 + 识别 两段式示意，API 以实际选型为准whileTrue:ifkws.detect():# 轻量唤醒词检测，常开、低功耗beep()# 提示已唤醒wav=record_seconds(5)# 录一段指令q=asr.transcribe(wav)# 完整 ASR 识别answer=ask_llm(q)# 交给大模型speak(answer)# 播报回答（若接 TTS）

唤醒词模型要"小而灵"：够轻才能常开不费资源，够灵才能既不漏唤醒（叫不应）也不误唤醒（没叫它自己跳）。这两率的平衡，是唤醒体验的关键。

6.7 会议纪要实战：长音频转写 + 大模型总结的完整流程

把 3.3 的思路落成代码。一场会议转写出来可能几万字，远超上下文长度 cl，所以要"分段转写 → 分段总结 → 汇总"：

# 会议纪要：分段转写 + 分段总结 + 汇总，API 以实际为准defmeeting_minutes(long_wav):segments=split_by_silence(long_wav)# 1) 按静音切成若干小段transcript="".join(asr.transcribe(s)forsinsegments)# 2) 逐段转写后拼接chunks=split_text(transcript,max_len=1500)# 3) 按 cl 切成文本块partials=[ask_llm(f"总结这段会议内容的要点：\n{c}")forcinchunks]# 4) 分段总结final=ask_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

语音识别的核心性能指标是RTF（Real-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 给识别率打个分

“识别挺准的"是感觉，工程上要量化。语音识别通用的指标是WER（Word Error Rate，词错误率）：把识别结果和标准答案逐词比对，数出"替换 + 插入 + 删除"的错误词数，除以总词数，WER 越低越准（中文常按字算，称 CER）。验收时准备一批覆盖真实场景（不同人、不同语速、含专业词汇）的录音，测出 WER/CER，就有了可对比、可回归的基线——以后换模型、换参数，用同一批音频重测，便知是变好还是变差。把"感觉准"变成"测得准”，是语音从 Demo 走向产品的分水岭。

8.6 端到端语音问答的延迟分解与达标线

“语音助手反应慢"要拆开看：总延迟 ≈ ASR 识别延迟 + 大模型首 token 延迟 +（若有）TTS 合成延迟 + 各段衔接开销。逐段打点计时，才知道时间花在哪。一般经验：从说完到开始出声，控制在 1~2 秒内体验尚可，超过 3 秒就明显"肉”。达标手段也对应三段：ASR 用流式、压 RTF（8.2）；大模型压首 token（换小模型、调小 cl，见第 7、8 讲）；TTS 选更快的方案或边合成边播。把延迟拆到段、对段下药，比笼统"优化"有效得多。

8.7 搭建一套可回归的语音测试集

语音效果会随模型、参数、环境变化，靠"每次随便说两句听听"没法保证质量。建议搭一套固定测试集：收集覆盖真实场景的录音（不同人、不同语速、安静/嘈杂、近讲/远讲、含专业词汇），配上标准文字答案，固定存放。每次改模型、调参数、升级版本后，用这套音频跑一遍，自动算 WER/CER（8.5）和 RTF（8.2），与上一版基线对比。有了它，“这次改动是变好还是变坏"立刻有答案，回归也有保障。这套测试集和检测模型的"固定测试图”、大模型的"固定问答"是同一思路——都是把"验收"从感觉变成数据。

九、FAQ

Q1：AidVoice 只能做语音识别吗？
不止。它覆盖 ASR、语音翻译、会议纪要、RAG 等语音相关能力（2.3）。ASR 是地基，其余多是"ASR + 大模型"的组合应用，具体支持范围以官方文档为准。

Q2：离线能用吗？
能。端侧识别的意义之一就是离线可用（2.4）。但如果你把识别接到的是云端大模型 API，那断网时那半截就断了——全离线要把大模型也放本地（第 8 讲的 AidGenSE）。

Q3：识别支持哪些语言？
取决于所选识别模型。中文、英文通常都有对应模型，多语言/方言支持以 Model Farm 与 AidVoice 文档为准。

Q4：为什么识别率不如手机上的语音助手？
手机助手多走云端大模型 + 海量数据训练，端侧受算力和模型尺寸限制，识别率有差距是正常的（2.4）。端侧的价值在隐私、离线、低延迟，不是替代云端追求极限识别率。

Q5：TTS（语音合成）也包含吗？
"语音出"需要 TTS 把文字读出来。是否在 AidVoice 范围内、如何用，以官方文档为准。本讲重心是 ASR 与问答链路。

Q6：怎么提升专业领域的识别率？
看模型是否支持自定义词表/热词，把产品名、术语加进去；同时保证音频质量（近讲、降噪）。实在不行，专业场景可评估云端识别。

Q7：RAG 一定要向量数据库吗？
小规模资料可以用简单的关键词/相似度检索，不一定上完整向量库。核心是"检索出相关段落喂给大模型"这个思路，实现可繁可简。

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 与官方文档为准。