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

 之前本想写一篇各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这一点，同时要考虑基础平台的扎实度和功能及性能等，而我们宁卫的产品在经过多年呼入呼出磨砺后，稳定性、并发性、实用性、易用性、逻辑性等各方面都有很棒的表现，希望大家一起合作！