ASR

你跟一个语音 AI 说完话,它停顿了一下,才开口回答。 那一下"停顿",就是它不像人的地方。 人类对话的轮次间隔(turn-taking gap)中位数只有约 200ms,熟悉的人之间还经常"抢话"——下一句在上一句结束前就接上了。一旦 AI 的回应超过 500ms,你会明显感觉到"它在想";超过 800ms,对话就开始别扭,你会忍不住重复自己,或者以为它没听见。 所以做语音 Agent,延迟不是"优化项",是及格线。这篇把从【用户说完最后一个字】到【AI 喇叭里出第一个音】之间发生的事,拆到毫秒。 这条流水线长什么样 flowchart LR A[用户说话] --> B[轮次判定VAD + 端点] B --> C[ASR语音转文字] C --> D[LLM首 token] D --> E[TTS首包音频] E --> F[AI 出声] style B fill:#fde7c2,stroke:#e8b23c style D fill:#fde7c2,stroke:#e8b23c 橙色的两块——轮次判定和 LLM 首 token——是预算里最大的两笔开销,也是最值得花力气的地方。 一份现实的延迟预算 环节 它在做什么 典型耗时 轮次判定(VAD + 端点) 判断"用户真的说完了" 50–250 ms ASR(语音转文字) 把语音转成文字 ~0–150 ms* LLM 首 token(TTFT) 想出第一个字 250–500 ms TTS 首包 合成出第一段音频 75–200 ms 网络往返 客户端 ↔ 服务端 30–80 ms 合计(可感知) 约 500–900 ms * ASR 与用户说话并行进行,大部分转写在用户说完之前就做完了,所以它对预算的增量很小——前提是你用的是流式 ASR。 ...

两年前你做语音功能,绕不开 Whisper。把音频丢进去,拿一段文字出来,干净利落。 今天你再去看,会发现一个有点反常识的事实:在不少新产品里,那一段文字根本不存在了。语音进去,语音出来,中间没有任何一步是"文本"。Whisper 这种纯 ASR 模型,正在从"语音 AI 的地基"退化成"一个还在用、但不再激动人心的工具"。 这不是 ASR 变差了——它一直在变好。是语音模型这条线,这一两年走完了一次三级跳。我想把这三级讲清楚:每一步解决了什么、赔进去了什么,以及 2026 年的此刻,你手里的场景到底该站在哪一级。 三级跳:一张时间线 timeline title 语音模型的三代演进 第一代 专用 ASR : Whisper 系 / 各家流式 ASR : 语音 → 文字,只做识别 第二代 多模态语音理解 : Qwen-Audio / Qwen3-Omni : 语音直接进 LLM,听懂语气与事件 第三代 端到端语音 : Moshi / Sesame CSM : GPT-Realtime / Gemini Live : 语音进语音出,中间不落文字 这三代不是互相取代的关系——更像三层楼,新楼盖起来了,旧楼还有人住,而且住得挺好。下面一层一层说。 第一代:专用 ASR,把语音"压扁"成文字 ASR 模型只干一件事:把声波转成最可能的那串字。Whisper large-v3 仍然是这条线上的标杆,多语言、抗噪、开源、便宜,2026 年依然是无数转写流水线的默认选项。 它解决的问题很实在:语音是连续的、模拟的、信息量巨大的信号,文字是离散的、规整的、好处理的符号。ASR 在两者之间架了一座桥。有了这座桥,语音才第一次能接进所有为文字设计的系统——搜索、数据库、传统 NLP、LLM。 代价也恰恰在这座桥上。ASR 是一次有损压缩,而且丢掉的东西,常常正是你最想要的。 同一句"你这是什么意思",可以是真诚发问,可以是压着火,可以是开玩笑。转成文字之后,这九个字一模一样,语气全没了。一段录音里有人在笑、有人在哭、背景有玻璃碎掉的声音——ASR 给你的还是那行字,这些"非文字信息"在转写的瞬间被抹平。 对"我要把会议录音变成文字稿"这种任务,这种丢失无所谓,甚至是好事。但对"我要做一个能察言观色的语音助手",这就是地基上的裂缝:你的下游模型再聪明,也只能在 ASR 留下的那点信息里打转。 ...

你试用一个 ASR 模型,拿手机对着它念一段稿子,转写结果几乎一字不差,你心里想:这事成了。 然后你把它接进真实业务。客户在马路边打来电话,背景是车流声;他说到你公司的产品名,转写出来是三个完全不相干的字;他报了一串订单号"一三幺零",屏幕上是"一三妖灵"。Demo 里的惊艳,到这里一点都不剩。 问题不在模型菜。开源的 Whisper、各家的流式 ASR,安静环境下的中文字错率早就压到了 3% 以下,这已经接近人工转写的水平。坑全在"安静环境、念稿子"这八个字之外——真实的语音是脏的,而工程的活,就是处理这些脏东西。这篇把落地之后才会碰到的坑,一个一个拆开。 第一个岔路口:流式还是非流式 这是接 ASR 之前必须想清楚的第一件事,选错了后面全是返工。 非流式(批量):把一整段音频丢进去,等它整段识别完,返回结果。流式:音频一边录一边送,模型一边听一边吐字,你能拿到不断更新的"中间结果"。 差别不只是"快一点慢一点"。它们是两类不同的产品形态: 维度 流式 ASR 非流式 ASR 典型延迟 首字 200–300ms,说完即出 等说完后再算,3 秒话约多等 0.5–2 秒 准确率 略低(只能看到左边的上下文) 略高(能看到整句,甚至整段) 成本 贵(常见 $0.016/分钟级别) 便宜(常见 $0.008/分钟级别) 适用 语音 Agent、实时字幕、点单 会议录音转写、客服质检、播客字幕 记住一个核心事实:流式之所以准确率低,是因为它在"说完之前"就得交答案。它做"我想订一张去——“的转写时,根本不知道后面是"北京"还是"报告”。非流式没这个包袱,它能等整句听完再回头修正,所以同样的模型,非流式版本的字错率往往低一两个百分点。 这里有个 2026 年很常见、但容易踩反的折中:用 VAD 把长音频切成"准句子",每段当成一个 mini-batch 走非流式模型。这套做法在"实时字幕"这种场景里很香——它不需要逐字滚动,用户能接受"一句一句往外蹦",于是你既拿到了非流式的准确率,延迟又只是一句话的长度。但如果你做的是语音 Agent,用户在等 AI 回话,那这套就不行——你必须真流式,让 ASR 和用户说话并行跑,说完文字基本也就好了。 别被"我两个都要"骗了。 一个产品里通常只有一条主链路。先确定用户是不是在"等",再选。 专有名词、中英混读、数字:错得最离谱的三类 通用 ASR 在通用语料上训练,所以它对"通用的话"很强,对"你的话"很弱。落地后用户投诉最集中的,永远是这三类。 专有名词。 你公司叫"声析",模型从没见过这两个字的组合,它会按发音找一个最像的常见词——“声息"“生气"“省吃”。这不是模型蠢,是它在做概率上最合理的猜测。人名、产品名、内部黑话、行业术语,全是重灾区。 中英混读。 中文工程师说话天然混英文:“这个 bug 我提了个 PR"“把 latency 压下来”。问题是很多 ASR 在"语种判定"上是僵的——它先猜你这句是中文还是英文,再用对应的解码路径。猜错了,“PR"变成"批 R”,“latency"变成一串看不懂的拼音。2026 年好一些的方案(比如 Gladia、Deepgram Nova-3)做了句内 code-switching,语种切换不需要整句重判;但便宜的、老的模型,中英混读仍然是硬伤。 ...

Voice Agent 是什么 一句话：能听会说的AI助手。 graph LR A[用户说话] --> B[ASR语音识别] B --> C[LLM理解+生成] C --> D[TTS语音合成] D --> E[播放给用户] 看起来简单，但要做好有三个核心挑战： 延迟 - 用户说完到AI回复，要控制在1-2秒内 打断 - 用户随时可以打断AI说话 自然度 - 不能像机器人一样僵硬 核心架构 方案一：串行流水线 1 用户说话 → [等说完] → ASR → LLM → TTS → 播放 优点：实现简单 缺点：延迟高（3-5秒） 适合：对延迟不敏感的场景（如语音留言） 方案二：流式处理 1 用户说话 → [边说边识别] → [边生成边合成] → [边合成边播放] 优点：延迟低（1-2秒） 缺点：实现复杂，需要处理中间状态 适合：实时对话场景 关键组件 1. ASR（语音识别） 方案 延迟 准确率 成本 Whisper API 1-2s 95%+ 按时长计费 Deepgram 200ms 90%+ 按时长计费 本地Whisper 500ms-2s 95%+ 需要GPU 实时识别关键： ...