语音识别技术三十余年发展历程及其在现代智能设备中的应用
原文链接：
//24259
语音识别技术历经三十几年发展，识别率提升致使语言识别技术愈发贴近我们生活，各大公司在语音识别的产品与技术方面投入巨大，语音输入法成为IOS、YunOS手机输入法中不可或缺的按钮，智能助手像Siri、Now、云OS语音助手都将与NLP结合以智能助手形式提供给众人，家庭娱乐如xbox、apple tv、天猫魔盒语音输入让人机交互更便利。
犹如其他机器学习那般，语音识别乃是一项同美妙相互结合的任务 ，促使语音识别基本技术加以升级 ，拓展语音识别的场景以及语言 ，本节着重探讨于机器学习这一方面我们所开展的作为 。
从语音识别内部技术的角度而言，大家业已渐渐构建起了如下的某些共识，。
王道是真实场景的数据，机器学习需要教科书，最好的教科书是真实的数据。
2.统计模型是state-of-the-art。
3.先HMM训练再DNN模型是标准模式。
所以语音识别最标准的玩法就是下面这个循环：
咱先通过人工方式构建起初始的数据库，以此来搭建第一个模型，当然，只要是有市场存在的地方，便会有生意产生，因而存在不少向外界售卖自己录制好的数据库的公司，借此你能够直接购买现成的数据库，随后你对模型展开训练，经测试发觉不存在问题后，你将自己所训练的模型投放至线上供人使用，当你的用户在使用时便会出现源自真实场景的录音，你从当中挑选出所需的数据开展标注，接着你又回归到模型训练的进程当中，这个循环持续不断运转，在处于不断转动的过程里，你的识别率得以提升 。
对于语音识别的当前技术而言，针对不同的业务场景，你得有与业务场景相匹配的数据，方可夺取最佳的识别效果。面对不同的语言，我们必须构建各异的模型。因而，倘若你从事M个业务的N种语言工作，并且在每个场景里将模型更新K遍，那么这个数量就会极为庞大了。
我们建立的目的是为了强大的中后台来支持我们的业务需求，能够
基于上面的图，需要支持下面的几种主要的功能：
我们最终要达成的目标是，用户给出配置文件表明这是训练数据，声明这是我所需模型的大小，指出这是我的测试集，宣称准备依靠100台机器训练。接着完成模型的训练以及测试，之后发邮件告知你模型已完成，说明识别率是多少，随后你点击我要上线，于是模型会在线上系统进行部署，进而线上测试自行完成，通过后用户便拥有新模型可使用了。
虽然这个颇为庞大的最终目的存在着，然而我们可将其拆分成多个能够逐步予以完成的子步骤，在一套代码框架之下进行编写，随后便能够对子步骤加以组合，在最终任务达成之前，子系列步骤能够被单独调用，当下我们已然拥有不少达到自动化程度的子模块，后续会持续完成其他子模块。
分布式的问题
语音识别的分布式属于较为特殊的问题，故而在此单独予以讨论。文本的分布式相对成熟些，这是由于当前许多分布式系统皆是为文本处理而诞生的。然而语音属于二进制文件，并且语音模型训练颇为复杂，其中DNN模型需要GPU队列，DNN模型还需要CPU队列，与此同时两者之间数据也得进行交换，那么怎样将这些放置到现有的分布式系统网络框架之中是相较而言较大的挑战。
我们在发展变化的过程中，经历几个阶段：
第一阶段：基于物理机+ +OSS+GPU的模式
在这个模式下:
OSS用于存储数据和模型。
用于保存临时的计算数据，用于临时分布式计算交换使用。
CPU farm承担着数据运算处理的职责，进行GMM训练这项工作，开展DNN预处理的操作，还要实施模型测试的活动。
GPU farm用于DNN模型训练。
这个模式具备这样的好处，即每一块部分相对比较独立，其开发所需承担的成本较小规模低下，在业务开展进行的早期阶段能够满足我们所具有的需要。然而存在的问题在于，系统整体显得过于繁杂多样，数据之间的交换构成了一个问题状况，计算方面所拥有的可扩展性同样也是一个问题情形。
第二阶段，基于集群+GPU集群的模式
处于分布式计算平台状态的集群，然而，要使得语音在其上得以运行这样一种情况，是存在着颇为巨大的困难的。举例来说，像Kaldi这样的，具备40多万行动代码的情况，要是完全依照相应框架去重新编写是不具备现实可行性的。
和我们合作的团队所基于的语音计算平台，在语音的job运行时，关键技术点是先将其mount成一个虚拟盘，如此一来，现有的基于盘操作的代码，仅需少量改动就能在其中运行，并且还能借助分布式的优势。基于这种改动，我们系统的可扩展性得到了大幅提升。
第三阶段，GPU集群和集群的合并
这是我们期望在未来达成的阶段，当下，GPU集群与CPU集群属各自独立的系统，数据进行交换的时候颇为麻烦，期望未来能与其他各个团队携手合作来完成这一进程 。
欢迎 你 发表评论: