语音识别pipeline建设

简介: 和其他机器学习一样,语音识别是一个science和engineer美妙结合的任务。Science推动语音识别基本技术的升级,engineer扩充语音识别的场景和语言。本节主要讨论在机器学习的engineering方面我们做了什么。

语音识别技术经过三十几年的发展,识别率的提升使语言识别技术越来越贴近我们的生活。各大公司都在语音识别的产品和技术上大有投入。语音输入法成为IOS,Andriod,YunOS手机输入法是必不可少的按钮,智能助手如Siri,Google Now,Cortana,YunOS语音助手都把speech和NLP结合在一起作为智能助手的形式提供给大家。家庭娱乐如xbox,apple tv, 天猫魔盒语音的输入让人机交互更容易。

 

和其他机器学习一样,语音识别是一个science和engineer美妙结合的任务。Science推动语音识别基本技术的升级,engineer扩充语音识别的场景和语言。本节主要讨论在机器学习的engineering方面我们做了什么。

 

从语音识别内部的技术角度,大家已经逐渐的建立了以下的一些共识:

1.       真实场景的数据是王道。机器学习需要教科书,真实数据是最好的教科书。

2.       统计模型是state-of-the-art。

3.       先HMM训练再DNN模型是标准模式。


所以语音识别最标准的玩法就是下面这个循环:


e71b2f356c540201cb12ef64bc5e57feca889ffa


咱们先人工建立初始的数据库来build第一个模型。当然有市场的地方就有生意,所以有很多公司会卖自己录好的数据库,这样你就可以直接买现成的数据库。然后你训练好模型,测试发现没有问题,你就把你的模型上线做服务,然后你的用户用的时候就会有真实场景的录音,你选择需要的数据来标注,然后你就回到模型训练的过程。这个圈就转转转,然后在转的过程中你的识别率就提升了。

 

语音识别的当前技术对于不同的业务场景你需要业务场景匹配的数据你才能够拿到最好的识别。不同的语言我们需要建立不同的模型。所以你要是做M个业务的N个语言,然后每个场景里更新K遍模型,那么这个量就很大了。

 

我们建立pipeline的目的是为了强大的中后台来支持我们的业务需求,pipeline能够

  • 分布式:处理大规模数据需要分布式来加速,多业务模型需要分布式需要来支持。
  • 自动化: 提供数据处理,模型训练,测试等等的自动化。
  • 沉淀技术:固化我们在流程和算法上的提升。
  • 易扩展:易于扩展到新的业务和新的语音。

 

基于上面的图,pipeline需要支持下面的几种主要的功能:

  • 模型训练(AM:GMM+DNN, LM)
  • 模型测试
  • 自动化上线流程
  • 数据的筛选和处理

 

我们最终要达到的目标:用户给定配置文件说这是训练数据,这是我需要的模型的大小,这是我的测试集,我要用100台机器训练。然后pipeline就完成模型的训练和测试,然后发邮件告诉你模型好啦,识别率是多少,然后你点我要上线,然后模型就会在线上系统部署,然后线上测试自己完成,通过用户就有新模型用了。

 

这个最终的目的是庞大的,但是我们可以拆分成多个子步骤逐步完成。一套代码框架下写,然后就可以组合子步骤。在最终的任务完成之前,子步骤可以被单独调用。我们现在已经有不少子模块达到了自动化的程度,后面会继续完成其他子模块。

分布式的问题

语音识别的分布式是比较特殊的问题,所以这里单独讨论下。文本的分布式相对成熟,因为现在的很多分布式系统都是为文本处理而生的。但是语音是二进制文件,而且语音模型训练比较复杂,DNN模型需要GPU队列,DNN模型需要CPU队列,之间数据还要交换,如何把这些放到现有的分布式系统的框架里面是比较大的挑战。

我们在发展变化的过程中,经历几个阶段:

  • 第一阶段:基于物理机+ Gluster+OSS+GPU的模式
  • 第二阶段,基于MaxCompute集群+GPU集群的模式
  • 第三阶段,GPU集群和MaxCompute集群的合并 


第一阶段:基于物理机+ Gluster+OSS+GPU的模式

在这个模式下:

OSS用于存储数据和模型。

Gluster用于保存临时的计算数据,用于临时分布式计算交换使用。

CPU farm负责数据处理,GMM训练,DNN预处理,模型测试。

GPU farm用于DNN模型训练。

这个模式的好处是每块比较独立,开发成本小,在业务的早期可以满足我们的需要。但是问题是系统太杂,数据交换是问题,计算的可扩展性也是问题。

1bb6848e02a1da1cc133c9b90854da2cfd5df831

 

第二阶段,基于MaxCompute集群+GPU集群的模式

MaxCompute集群是分布式计算平台,但是如何让语音跑在上面是比较大的困难。比如Kaldi就有40多万行的代码,如果完全按照MaxCompute的框架重写是不现实的。

我们和MaxCompute团队合作基于MaxCompute volume的语音计算平台,关键的技术点当语音的job到MaxCompute运行的时候, scheduler先mount MaxCompute volume成为一个虚拟盘,然后现有的基于盘操作的代码就都可以已少量的改动来运行在MaxCompute里面了,还可以利用分布式的优势。基于这样的改动,我们系统的可扩展性有了很大的提升。

 

第三阶段,GPU集群和MaxCompute集群的合并

这个是我们希望将来达到的阶段。现在GPU集群和CPU集群式分别的系统,数据交换很麻烦。我们希望将来和其他团队合作完成这一步。

相关实践学习
达摩院智能语音交互 - 声纹识别技术
声纹识别是基于每个发音人的发音器官构造不同,识别当前发音人的身份。按照任务具体分为两种: 声纹辨认:从说话人集合中判别出测试语音所属的说话人,为多选一的问题 声纹确认:判断测试语音是否由目标说话人所说,是二选一的问题(是或者不是) 按照应用具体分为两种: 文本相关:要求使用者重复指定的话语,通常包含与训练信息相同的文本(精度较高,适合当前应用模式) 文本无关:对使用者发音内容和语言没有要求,受信道环境影响比较大,精度不高 本课程主要介绍声纹识别的原型技术、系统架构及应用案例等。 讲师介绍: 郑斯奇,达摩院算法专家,毕业于美国哈佛大学,研究方向包括声纹识别、性别、年龄、语种识别等。致力于推动端侧声纹与个性化技术的研究和大规模应用。
目录
相关文章
|
SQL 监控 druid
MySQL线程池导致的延时卡顿排查
## 问题描述 简单小表的主键点查SQL,单条执行很快,但是放在业务端,有时快有时慢,取了一条慢sql,在MySQL侧查看,执行时间很短。 通过Tomcat业务端监控有显示慢SQL,取slow.log里显示有12秒执行时间的SQL,但是这次12秒的执行在MySQL上记录下来的执行时间都不到1ms。 所在节点的tsar监控没有异常,Tomcat manager监控上没有fgc,Tomcat实
2542 0
MySQL线程池导致的延时卡顿排查
|
Java Windows
码神开源,War包反编译获得JAVA源码,竟然这样简单
码神开源,War包反编译获得JAVA源码,竟然这样简单
1331 0
码神开源,War包反编译获得JAVA源码,竟然这样简单
|
容器
【labview问题小集合】
【labview问题小集合】
469 0
【labview问题小集合】
|
图形学 开发者
《Unity 4 3D开发实战详解》一6.6 布料
本节主要向读者介绍布料的相关知识,布料是Unity内建物理引擎中另外一个很重要的概念。弄清楚布料的概念对于Unity开发新手来说是很重要的。通过本节的学习,读者将对布料有一个基本的认识。
2523 0
|
23小时前
|
云安全 人工智能 运维
阿里云SecOps Agent,全新安全跨产品执行体验
自然语言驱动 云安全中心/WAF/CFW/ 等多款安全产品联动
1556 0
|
11天前
|
缓存 测试技术 API
Qwen 3.7 Plus 与 Max 实测:性价比与多模态能力差异解析(2026)
2026 年 6 月 1 日,阿里悄无声息地发布了 Qwen 3.7 Plus,距 Qwen 3.7 Max 上线刚好 11 天。同样的 1M 上下文,同样的 35 小时自治上限。但价格才是头条:Plus 是 0.40/M输入,Max是 2.50/M——便宜约 6 倍——并且还能看图、看视频。Vision Arena 上 Plus 已经排到 #16。所以这周真正值得讨论的问题不是”要不要为视觉能力买单”,而是”Max 凭什么用 6 倍价格换来 2 个百分点的 benchmark 领先”。
|
12天前
|
JavaScript 定位技术 API
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
CodeGraph 是一款爆火的本地代码智能工具,通过 tree-sitter 解析 AST 构建结构化知识图谱(存于 SQLite),为编程 Agent 提前生成“代码地图”。它显著降低 Agent 在中大型项目中的探索成本——实测工具调用减少71%、Token 降57%、速度提升46%,支持19+语言及主流框架路由识别,完全离线、无需 API Key。
851 11
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
|
12天前
|
人工智能 运维 JavaScript
阿里云Qoder CN(原通义灵码)全解析 产品形态、版本划分与技术适配说明
在AI辅助开发与智能办公工具持续普及的当下,阿里云旗下原通义灵码正式更名为Qoder CN,同时延伸出QoderWork CN、Qoder CN CLI、Qoder CN Mobile等多款配套产品,形成覆盖代码开发、日常办公、终端交互、移动端使用的完整工具矩阵。Qoder CN核心定位为AI智能编码助手,深度适配主流代码编辑器、集成开发环境以及终端场景;QoderWork CN则偏向桌面端综合办公辅助,二者面向不同使用场景,划分了多个版本档位,搭配差异化资源配额、功能权限与计费规则,同时兼容多款主流大模型。
872 8