长音频转写的三个坑：切分、VAD 与说话人分离的工程实录

接上篇 OCR 的账本系列，这次记录语音转写线的一个真实项目：把公司两年积压的内部分享录音（单场 90 分钟上下，总计 400 多小时）批量转成可检索的文字稿。项目不大，坑位密集，按踩坑顺序记录。

坑一：切分不是切西瓜

最初的脚本很朴素：按固定 30 秒切段，逐段转写，拼接输出。跑第一场分享就露馅了——切分点经常落在句中，「接下来我们看这个接口的」和「返回值设计」被切进两段，第二段的转写因为缺上文，「返回值」识别成「饭回值」。

固定切分的问题在于它对内容一无所知。改进方案是按静音切：先用能量检测找低电平窗口，在静音处下刀。这招对吐字清晰的讲座有效，但对内部分享这种「抢话、叠话、咳嗽、翻桌子」的现场，能量阈值很难调——调高了把正常语音当静音，调低了整段音频找不到切点。

最后落地的方案是 VAD（语音活动检测）加窗口保护：VAD 标记有效语音段，切分点只落在 VAD 判定的静音区，且保证每段不短于 5 秒、不超过 30 秒；如果一句超长，宁可超限也不硬切。中文里长句多，这个「宁可超限」的取舍减少了一半的拦腰斩。

坑二：说话人分离的「谁在说话」没有想象中准

会议纪要的需求里，「谁说了什么」比「说了什么」更重要。我们试了开源的说话人分离方案，双人对话场景准确率不错，一旦到圆桌讨论（6 人以上、有远程接入），错误率陡增：把同一个人切成两个说话人是常态，隔壁工位路过的闲聊被算成正式发言人。

工程上的补救是「不追求全自动，做半自动对齐」：分离结果只作为草稿，配合会议的发言顺序常识（主持人开场、逐人汇报、QA 环节）做规则校正，最后人工抽查 5%。这个折中把可用性从「不可用」拉到「可交付」。

坑三：批处理的水位控制

400 小时存量的批量转写，一开始我并发开满，结果触发限流，任务排队雪崩。改成漏斗控制：并发 4、失败退避重试、单任务超时熔断，一夜稳定跑完 80 小时。做批量管线的话，水位控制比速度参数重要得多。

存量跑完后，增量部分我改用了算邻坊的语音识别服务做兜底——500MB 内的长音频整文件直传，服务端处理切分和长音频转写，省掉自维护 VAD 管线的精力，按量每小时 5 毛，转写 6 种格式输出（含 SRT 和带时间戳逐句稿）。内部分享这种非实时场景，自建管线的边际收益已经不明显了。

一点架构层面的感想

这套踩坑走完，我对「转写管线」的认知从一堆组件变成一句话：它是一条把音频折算成文字的算力流水线。自建的本质是自己运维这条流水线上的每一块算力；用服务则是把流水线外包——比如我现在用的算邻坊，背后就是把闲置算力池化调度成按量 API 的平台，按小时计费，不用不花钱，余额永不过期。工程选型的分界线也就清晰了：实时内网场景自建，存量批量与日常增量交给按量服务。

400 小时跑完，检索系统上线那天，团队里最常被搜索的关键词是「下周」——大家都在找自己上次答应过什么。这大概是转写工程最真实的价值：让说过的话可被追责。

---

写文里这些转写场景，来自我日常在用的算邻坊（suanlinfang.cn?from=cnblogs-stt）——把闲置算力池化成按量 API 的平台：语音识别/语音合成/文字识别/智能决策/随心翻译，不用不花钱，余额永不过期，新用户送 ¥10 体验金。