论ASR服务商提供的SDK、HTTP、MRCP服务

阅读 777 次  0 条评论
之前本想写一篇各ASR服务商比较的,但最后一想,还是算了吧!付多少钱得多少钱的果,即使都是车,那么多不同品牌的车,价格、性能、口碑都相差很大,更何况软件这种车,有的都不需要考虑安全性、实用性、使用性,只要号称有车,那么就会有大批的“流氓”去当倒爷,所以我们去夸ASR中的BBA,他们觉得理所应当,我们去实话实说有些只有方向盘和座椅的ASR“车”,又是得罪人的事,何必多说。 之所以改成对SDK、HTTP、MRCP进行评论,这也是使用这些服务几年来一点心得,同时也分享给对ASR服务有需求的人们,谨供参考!花钱是你花,也是花的你的钱,只能以我的思路带着你捋一捋! 我把ASR的三种服务方式有以下比喻(比喻中只是正常的情况,不含特效): SDK:对应自行车,灵活、适应各种路况、成本低廉,但对综合技术有一定要求。 HTTP:对应摩托车,也比较灵活、适应的路况比自行车少一些、成本低但要烧油,同时对开摩托车有驾照要求,综合技术比SDK要求少一些,但对HTTP类的服务的技术要多些。 MRCP:对应汽车,对路况要求相对苛刻,成本高,烧油高,汽车一中,时刻烧钱中,不光有驾照要求,综合技术也要求比较多。 按以上分类,我们在具体应用场景中,不光需要去了解技术问题,也要想好自己钱包少多少。而不是拍脑袋,为难着自己去采购一些不着调的产品。 一、对业务场景进行分析,对自己的擅长技术进行分析,明确到自己能不能完成自己想要干的事。 二、在小段语音识别情况下,SDK和HTTP方式一般够用了。因为都是按照类似我们这种自己进行了VAD或完成录音的情况下送到ASR引擎那边,但按技术规范来说,SDK响应速度要比HTTP快些,因为SDK大部分可以理解成自定义的Socket通信来完成整个事,而HTTP的还要对HTTP协议进行解析和处理,如果说HTTP快,那只能说明ASR服务商花了更大代价在HTTP那块。 三、在大段语音实时识别要求中,MRCP应是当前不多的选择之一。选择这种方式是因为这是在RFC4487和RFC4463中定义了,不断地把实时流传给ASR引擎,所以对识别通道的占用和对硬件资源的消耗是非常大的。在大多数情况下,不提供标准的MRCP协议的一些引擎也会要求必须以实时流形式送到引擎来完成。 四、在自建ASR服务环境下,对土豪公司我们不过多讨论,但在成本预算和维护各方面不足的情况下,使用自建服务,就是给自己添堵,硬件配置不够,跑不动怎么办?维护人员素质跟不上,维护不了怎么办?明明想买辆豪车,想什么时候走就什么时候走,结果因为被销售人员忽悠着,只给了个豪车的壳,发动机是五流模具厂商压出的外形,开动不起来怎么办?所以各方面不到位的话,建议用比较好的公有云服务就好了,别总想着自建。 五、虽然我在以上的例子中举例ASR为车,但实际上,我们在具体应用中,真正的ASR只是作为汽油使用。好比我们的智能交互平台中,在业务场景中,场景话术是发动机,播放的语音是车轮,ASR作为汽油使用,而我们的平台应用是车架,由车架承载着发动机,经过汽油提供的动力,驱使着车轮走向正确的道。也许比喻中还缺些内容,但这个不重要,重要的是,作为平台系统,各部件都好用才行,特别是车架需要更加的健壮和包容,才能让不同的车轮,发动机,燃油结构相互配合达到一个好的效果。 按以上所说的,其实有一个好的平台应用,在应对相对状况稍简单的场景中,成本低廉的云的SDK、HTTP服务已可以满足一般性的呼入呼出场景需求,而复杂的场景,则是靠成本往起堆的。在同一类的服务中,需要考察的方方面面比较多,很多小的ASR服务商,只是突出其在几百个关键点中的某个点而已,只能作为小的参考之一,而不是综合的考虑。 整个应用场景中,考察和考虑到的不能只是ASR这一点,同时要考虑基础平台的扎实度和功能及性能等,而我们宁卫的产品在经过多年呼入呼出磨砺后,稳定性、并发性、实用性、易用性、逻辑性等各方面都有很棒的表现,希望大家一起合作!

0条回复

主题回复:

(您需要 登录 后才能回复 没有账号 ?)
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet