蜻蜓FM副总裁金鑫:积极应用ASR技术,打造智慧安全音频服务

早在2012年中国云服务起步时期,蜻蜓FM就开始尝试上云,蜻蜓FM副总裁金鑫认为,音频行业的发展和整个云服务的发展密切相关。

2019年9月25日,云栖大会在杭州云栖小镇召开。蜻蜓FM在大会生态合作伙伴颁奖仪式上获得天猫精灵金牌内容服务奖,副总裁金鑫受邀出席大会并进行演讲,分享蜻蜓FM在云计算领域的进展和经验。

对于蜻蜓FM而言,与阿里云的合作及其云产品的使用在音频内容产品的用户场景匹配和产品安全方面都起到了促进作用。

金鑫表示,目前的音频内容平台以长时间音频节目为主,相较于图文和视频内容平台,音频平台对节目的基础信息掌握较少,难以进行有效的内容分析和检索,这导致在内容分发和处理过程中不易匹配用户场景。而蜻蜓FM摒弃了传统人工打标签的分发方式,最终选择与阿里云合作,经过了三次迭代后完成了比较完善和适合蜻蜓FM的音频转文字服务模型,即ASR服务产品,再通过应用蜻蜓FM自主研发的标签体系,实现内容和用户、场景的精准匹配。

目前蜻蜓FM已经建立其云上音频数据库以用于音频内容的自动文字转化,在提高平台内容检索效率的同时也助力其音频内容的标签化和场景匹配,最终提升平台的用户体验和运营效率,打造智慧音频服务。

另一方面,蜻蜓FM与阿里云也就企业和产品安全问题展开合作。安全领域是现在各 互联网 公司都在逐渐重视的方向,根据金鑫的介绍,蜻蜓FM和阿里云关于安全问题的的合作主要集中在两方面,其一是阿里云相关专家讲述安全领域基础常识,提高蜻蜓FM技术团队的安全认知;其二是双方就蜻蜓FM核心服务的技术架构和部署体系进行沟通,以避免架构上的安全漏洞。

现在蜻蜓FM正在全面拥抱云计算,充分利用云服务的同时在音频处理分析方面坚持自研和内容升级,在云服务助力下运营效率提高的同时,关注企业核心技术需求,提高团队技术能力。

以下摘录自蜻蜓FM副总裁金鑫在云栖大会演讲速记:

我想说的另外一点,整个音频行业的发展和整个云服务的发展,密切相关。因为我来之前,昨天百度了一下阿里云,百度百科讲2011年7月份,阿里云官网正式上线。从我的角度来讲,这是整个中国云服务的标志性事件。蜻蜓刚才也介绍了,我们2012年上云,整个蜻蜓建立时间是2011年9月份,从蜻蜓和蜻蜓代表中国的音频行业,跟整个云服务的产业发展,从时间周期来讲是一脉相承的。

我们后续整个音频行业的发展,也是基于整个云服务的迭代和变革的。随着使用云服务越来越多,我们使用云服务的各种各样的产品也在越来越丰富。

最开始我们在2012年上云的时候,尽管我们称之为上云,实际我们把阿里云当成一个虚拟的IDC机房,只是解决一些基础运维和虚拟机采买的事情。

后来整个云服务发展越来越完善,基础设施不管是存储、数据库缓存等等,我们也越来越去用阿里云的服务。随着技术和产品业务的需求变更,我们到后期开使用阿里云更多PaaS的各种各样服务的产品,我们希望在技术交流或者产品一些沟通,进行更多交流。从我们今年的一些使用和更长期的发展来讲,后面也会预期SaaS的服务,更多接入整个蜻蜓FM各种各样的服务体系。

刚才大概整体介绍了一下蜻蜓云服务的发展变革的过程,对我们来讲,可能不存在上云,我们只是选择在云上怎么用的过程。下面讲一下,音频行业的一些基础特点和我们面临的一些问题,包括一些案例来去讲云服务,加了一个产品+服务。我认为阿里云不是只卖产品,背后的服务是相当有价值的。我们会举几个例子,怎么跟阿里云合作,解决我们实际典型遇到的产品和技术的一些问题。

国内、国外所谓音频内容平台,其实更多是长时间的音频内容。它带来的问题是尽管是一个长时间的音频内容,内容制作成本跟我们长视频相比,还是知识量偏低,门槛也偏低。带来的一个好处,内容量会多,但同样弊端内容的基础信息差很多。在我们平台上通过其它方式进行版权采买,能拿到的基础信息就两个:音频介质物理文件、节目的标题,其它信息都非常少。这对于内容的分析、把握来讲,基本是一个比较困难的事情。

这是我们说音频行业做内容的分发跟处理的时候,遇到的一个典型困境。在更早期的时候,不管音频领域还是更早期的视频领域,大家解决问题的方法是靠人工的方法打标签来解决问题。

这种方法显然人力成本比较高,效率比较低,因为靠人,很难保证最后源数据和标签质量的一致性和质量的保证。我们当时想了一个问题,是不是能够通过一些机器的方法来解决。我们也不是第一个来提出这样一个方案,整个技术路径也比较简单。

第一,我们需要把音频的介质文件,通过语音识别的方法,变成文字,这是所有事情前置的基础。

第二,在文字基础之上,通过语义分析和理解的方式,来提取标签,实体识别,建设各种各样的图谱,再基于文字标签图谱的方式做具体的B端、C端的产品应用。

对于整个里面前置条件,我们说把音频转成文字这一个地方,因为音频刚刚讲了,跟其它 媒体 有一些特别的差异。但这些差异还有音频本身的一些特点,我们大家不是都讲普通话,而且普通话的标准程度其实不一样。有的人语速快,有的人语速慢,主播再去做内容或者生产者做内容的时候,会存在噪音的、背景音乐等等一系列的影响,对于音频转成文字这件事情,没有想象的那么简单。这个技术也是比较成熟的一个技术,当时蜻蜓做整个技术路径第一步的时候,我们选了跟阿里和其它三家,一共四家服务商,来一起做这件事情。

最后,我们依然选择了阿里,这其实给阿里也算打一个小广告。我们选择阿里是综合比较了质量和成本。因为确实当时阿里质量并不是最好的,我刚才说最后选择阿里,还有另外一个原因,就是整个过程中的合作。我为什么讲阿里的质量最开始并不是最好的,我们合作了四家服务厂商,去做音转文服务的时候,其实我们遇到的同样一个问题。大家做这个音转文的服务,最开始并不是为了蜻蜓做的,是为一个通用场景来做。我们用蜻蜓内容来应用到服务的时候,发现这个模型可能不一样。因为你的场景可能会有区别,你的训练语料数据不一样,因为蜻蜓的音频跟大家日常讲话或者说话的音频语料有一些差异。

再加上语速或者是方言或者噪音,遇到大量的问题。最开始我们合作第一期的质量,其实并不太让人满意。这时候我们也跟阿里的技术和算法的同学一起来探讨,我们迭代了三轮,每一次会看究竟中间的错误是什么原因,因为语料的问题,还是模型的问题,还是分类的问题,还是噪音的问题,每一次我们也会针对具体问题,具体分析,这个东西是应用层做一些调整,还是阿里在语料上做一些更新。

反复经过了三次迭代,期间有比较密切的沟通,包括一些内容数据的交换。从最后的结果来讲,经过几轮迭代,跟第一期的结果,在准确性等各方面,有非常明显的提升。

所以,我们在整个合作过程中,除了看之后的质量效果和成本以外,会非常重视中间的合作细节。这是整个技术路径的第一部分。

第二部分,拿到文字之后,我们自己的分析理解,构建自己的标签体系等等,这是跟蜻蜓自己的内容和业务,贴的比较近的事情,我们选择了自研的过程。我们在自研过程里,还是保持跟阿里的技术、算法、产品的交流,这种交流的过程,不能直接解决我们的研发代码问题,但其实对我们的一些事情的看法,还有经验来讲,有比较多的帮助。

其实我们都是2018年做这件事情,已经把整个路径都跑通。跑通之后,已经在自己内部,不管是内容的审核、个性化的推荐、内容搜索等等,已经有了比较好的一些落地场景。

尽管蜻蜓和整个音频行业发展还处在一个快速发展、中期或者早期的阶段,我们在整个发展过程中,需要云服务的各个厂商,跟我们比较密切的配合。

刚才讲是音频行业比较特别的一个点,这在其它行业或者其它公司大概率不应该发生。下面想分享一下,我们认为在80%甚至90%的企业,特别是互联网企业,可能都会面临的一个问题,就是安全。

刚才阿里的同事也讲过安全,对于安全,大家都很重视。实际讲我认为80%、90%的企业,哪怕是中级的一些企业,在安全上的投入都不够。再反过来讲,我自己总结,可能是三个原因:

原因1:对于早期的互联网公司,大家比较在意我的产品,我的业务是不是可以快速迭代,我去验证整个业务模式和产品的市场需求。我们不管是在外乎体验、服务质量,包括安全来讲,我们自己的容忍度比较高,这是第一点原因。

原因2:所有互联网公司,大家都会讲我们技术团队资源就是不够的。无论怎么加人,都是不够的。一方面我们业务有需求,第二方面稳定性有需求,第三方面安全上也有考虑的时候,每个公司的技术团队,或者说公司在安全上能够投入多少资源,或者重视程度怎么样,很大程度上取决于这个公司的技术团队对安全这件事情本身的认知跟重视程度。

原因3:安全这件事情是一个专业性比较强的事情,不是说通过短期的培训或者是比较短时间的经验积累,就可以变成这个领域的人才。这个领域的人才比较少,而且大家安全领域的人才,自己有一个圈子,进行招聘的时候,没有像我们去招产品经理或者开发人员那么容易。

我们在重新注重蜻蜓自己安全问题的时候,发现这三个问题我们都有,而且每个地方的坑都挺多的。

我们怎么来解决的呢?也是三个方面:

第一,我们直接从阿里云购买安全方面的相关产品,保证我们有基础的安全兜底,不会出太大的问题。

第二,我们除了说买产品,为什么说产品+服务?我确实觉得阿里云的服务比产品价值要更多。我们跟整个阿里云技术同学或者安全领域的专家,进行比较多的沟通。沟通会沟通两方面:

(1)专家或者是技术人员跟我们讲安全领域的一些基础常识,帮助我们整个技术团队,加强对安全的认知。

(2)我们也会把自己核心服务的技术架构或者部署体系,跟阿里云进行沟通,他们也会帮我们来针对性去看一下,整个技术架构上有没有一些安全隐患和漏洞,包括一些最佳实践应该怎么去做。

其实这两方面是帮我们整个团队有一个基础的安全。因为可能假装我们认为原来大家整个团队对安全的认知或者能力是零的话。那通过这个,我们可能达到一个30分、40分的水平,至少它是从0-30的一个变化。

那通过这两种,一是解决了我们自己短期的安全性漏洞;第二,其实给我们赢得了更长的时间去解决我们自己的安全团队招聘问题。