摘要：企业在选择对话式人工智能平台以集成到业务中时需要考虑许多因素，其中包括局限性、创造力空间等。

   企业在选择对话式人工智能平台以集成到业务中时需要考虑许多因素，其中包括局限性、创造力空间等。
　　
　　很多企业正在迅速认识到对话式人工智能对提高客户参与度和收入的重要性。企业面临的问题不再是是否部署对话式人工智能，而是使用哪个平台以及如何利用其功能。
　　
　　本文提供了关于对话式人工智能平台的一些重要见解和视角。例如，语言支持的真正含义是什么?什么是本地化?不同的部署模型如何影响总体拥有成本(TCO)?也许最重要的是——对话式人工智能平台如何不仅在第一个开发期间为企业提供帮助，而且在机器人整个生命周期中都能提供帮助?
　　
　　提高机器人开发人员生产力的经验教训
　　
　　在过去的六个月中，对话式人工智能提供商ArtificialSolutions公司首席创新与客户服务官DanielEriksson与构建对话式机器人的公司(客户)和系统集成商(合作伙伴)进行了很多对话。并与对话式机器人开发人员、数据语言学代表、集成工程师、对话人工智能设计师、项目经理、高级利益相关者、产品负责人等进行了交谈。
　　
　　与此同时，他与现有的和潜在的客户进行了交谈。这些交谈包括制定了雄心勃勃的计划并取得成功的人员，以及制定计划并努力产生影响的其他人。
　　
　　Eriksson进行这些讨论的目标之一是找到问题的答案。他说，“作为对话式人工智能技术提供商，我们如何帮助你提高工作效率?”他指出，这是ArtificialSolutions公司面临的一个问题，因为机器人开发者社区对其产品的反馈对于开发可以提高机器人开发者生产力的产品至关重要。
　　
　　然而在这些对话中，引发了另一个讨论主题，也是本文的重点：企业如何看待他们对对话式人工智能平台的选择?他们在选择对话式人工智能平台进行机器人开发时会考虑哪些方面?
　　
　　有人可能会争辩说，这个问题最好由独立第三方来回答，确实如此。然而，这是一个值得进行公开探讨的问题。因为Eriksson分享了一些从这些讨论中学到的东西，并提供了一些在人工解决方案公司工作20多年后在该行业中获得的经验和教训。
　　
　　Eriksson将这些见解分为四个主题，这些主题可能对企业在审查用于机器人开发的对话式人工智能工具时提供帮助。以下是选择对话式人工智能平台时不应错过的4个视角：
　　
　　(1)选择一个可以让企业的开发团队成长的工具。
　　
　　(2)语言支持和本地化。
　　
　　(3)总体拥有成本。
　　
　　(4)做好横向和垂直领域的准备。
　　
　　以下逐一进行分析和探讨：
　　
　　1.选择一个可以让企业的开发团队成长的工具
　　
　　人们可能了解一些流行术语，例如“意识”、“理解”和“自学”。而对话式人工智能是一个更具吸引力的领域，仍然有很多潜力有待探索。然而，大多数拥有对话式人工智能工具使用经验的企业表示，对话式人工智能工具与常规软件或流程开发有很多相似之处，并不是一种开创性的新事物。
　　
　　当然，有一些对行业领域有用且特定的术语，例如“意图识别”、“实体”和“场景”。这些术语与对话式机器人的自然语言理解(NLU)部分有关。
　　
　　这都是一些复杂的概念，但对话式机器人开发人员通常会使用这些功能，而这些功能并不是他们自己开发的。对于对话式机器人开发人员来说，这些类型的功能被认为是有效的，事实上，大多数工具都支持强大的意图识别，如今它更像是一种商品功能。可以假设一个工具包有足够好的意图引擎并继续前行。
　　
　　但是需要注意的是，选择的工具是否使用过多的类似人工智能的流行术语来描述功能，例如“意识”、“理解”或“自学”。这些不是开发人员用来描述他们开发的对话机器人的措辞(除非他们急需资金)。因此，建议避开这些流行术语，并选择使用更接近于开发人员看待世界的方式的概念和术语的工具。
　　
　　可以更具体一些吗?当然。Eriksson更喜欢将诸如局部或全局变量(变量范围)之类的成熟概念来构建机器人的开发人员所熟悉的术语。
　　
　　(1)在编码和无代码之间找到平衡
　　
　　听说过低代码或无代码吗?简而言之，这些概念描述了一个用户界面，开发人员可以在其中配置或以图形方式设计流程而不必编写代码。这是可视化程序如何执行的一种好方法，并且可以是快速构建某些东西的快捷方式。但对于构建一个有效的对话式人工智能解决方案，仍然需要编码。企业的团队需要使用某种脚本语言编写代码。否则将无法完成希望机器人完成的任务。因此不要回避这个事实，脚本和编码对于让机器人变得伟大是非常重要的。因此，当查看工具集时，需要从“编码部分将如何工作?”的角度对其进行评估。
　　
　　另一方面，如果企业只编写代码而从不使用图形表示，那么将遇到另外一些问题：“将如何与客户合作?如何让具有成功实施机器人所需的重要见解的团队成员参与其中，而这些团队成员会编码吗?”
　　
　　因此，企业需要考虑在编码和无代码之间取得平衡。因为大多数企业的对话式人工智能项目都需要这两种技术。
　　
　　(2)考虑可能遇到的问题
　　
　　目前市场上有很多对话式人工智能工具可供开发人员使用。企业的工作是确保选择一种工具，它不仅可以快速构建第一个最小化可行产品(MVP)，而且对开发的每一代机器人都很有用。当企业考虑如何提供更好的机器人用户体验的见解时，可能会意识到所选择的工具可能阻碍开发。
　　
　　对于每一代对话机器人的开发需要考虑多个因素。如果企业构建模式流程(以及更多意图)将会遇到一些问题。如果想让流程更高级，可能会遇到对工具集中功能的其他需求，而在那时意识到该工具不适合这项工作可能为时已晚。
　　
　　尝试从已经部署了相当广泛的机器人的场景中评估工具集。有了这些，可以考虑现在可能想要执行的不同任务。企业如何并行执行重构和发布一些小改进?如何组织所有流程/意图并执行版本控制?如何确保可重用性?可能想要探索哪些技术特性?
　　
　　(3)获得创造力
　　
　　当然，优秀的团队会构建出色的机器人。企业需要选择一种工具，其工程师可以使用该工具进行创造性开发和迭代。就像一个优秀的网站需要不断更新一样，随着新功能的测试、探索、扩展或删除，对话机器人也需要不断改进。探索、测试、发布的自由是释放团队创造力和雄心的关键。对话式机器人的程序也不例外。企业要考虑其专家想要做什么，并确保他们有能力在工具中实现他们的目标。伟大的团队将会构建伟大的机器人，除非工具阻碍了他们。
　　
　　2.语言支持和本地化
　　
　　(1)什么是语言支持?
　　
　　语言支持在对话式人工智能世界中的真正含义是什么?在评估对话式人工智能工具之前，这实际上是一个需要考虑的重要问题。
　　
　　对话式机器人的输出(机器人在说什么)几乎总是由实现者编写。机器人生成的输出可能会发生变化，从而允许更自然的对话，但大多数客户都有一些用于特定领域或目的的机器人，因此自由度相当小。机器人对用户说的话主要是由机器人开发团队设计的。因此，机器人的输出非常可控。因此就输出而言，语言支持并不意味着什么，可以简单地说，特定的语言字符不会在输出中变成乱码。为了帮助输出，机器人开发工具可能有一些库可用于一些通用的输出，比如社交谈话和标准响应。
　　
　　简而言之，语言支持与机器人向企业的用户所“说”的内容几乎没有关系。
　　
　　语言支持几乎完全是关于机器人如何支持和映射特定语言的输入。例如，机器人可以接受西里尔字母而不发出错误消息吗?机器人能否用日语拆分句子来识别动词、名词和形容词?机器人可以在没有训练的情况下对西班牙语句子中的单词或短语进行分类吗?
　　
　　对于机器人开发人员来说，重要的是语言支持帮助他们为特定语言构建机器人。特定语言的机器人平台也可以接受输入并注释(添加元数据)，以便开发人员可以利用它来设计良好的对话式机器人的体验。
　　
　　不同的对话式人工智能平台可能声称支持德语。但对于一个平台来说，它可能意味着“机器人接受德语字符”。而对于另一个平台，机器人具有广泛的单词、短语、概念、实体和预构建知识的注释。始终尝试阅读产品语言支持的简单说明。企业需要考虑使用哪些语言来部署机器人。
　　
　　(2)什么是本地化及其价值?
　　
　　如今，大多数企业都希望以一种以上的语言推出成功的对话式机器人。发生这种情况的原因不同。有时，企业在使用多种官方语言的瑞士等国家或地区开展业务，或者他们想扩大国外市场并部署机器人。甚至可以说在两个不同的渠道(如电话和Facebookmessenger)中部署同一个机器人可能需要两种不同的语言。
　　
　　现在有一些问题需要解决：企业如何开发和维护一个几乎相同但使用两种或多种语言的机器人?是否只是复制它并尝试维护两个或多个并行解决方案?任何尝试过这种方法的人都知道，这是一种失败的方式，或者至少是一种非常低效且需要资源的工作方式。
　　
　　解决这一问题的一种解决方案称为“本地化”。本地化意味着企业可以创建一个主解决方案，然后针对每种特定语言/地区对其进行本地化。本地化解决方案链接到主解决方案，以便更新和更改可以传播(在更改控制下)到本地解决方案。
　　
　　本地化不仅仅与语言有关。如果同一个对话机器人流程需要支持两个不同区域的两个不同后端系统，那么本地化也应该支持该功能。企业需要能够对本地实现进行修改，同时又不会失去与主解决方案链接的好处。
　　
　　对于大多数具有国际市场目标的企业来说，需要考虑要求对话式人工智能开发平台支持本地化的好处。企业需要考虑哪些语言支持和变体，并确保选择的工具集提供了发展空间。
　　
　　3.总体拥有成本
　　
　　(1)确定部署模型的隐藏成本
　　
　　什么是部署模型?大多数对话式人工智能平台都可以通过不同的方式提供：SaaS、内部部署、托管、开源等。假设企业和其安全团队在所有部署模型进行选择，那么在成本方面重要的考虑因素是什么?
　　
　　预付费模式是否涵盖隐藏成本?预付费模型是一种商业模型，通常与部署模型相关联，在这种模型中，客户需要承诺一定的资源消耗或目标。预付费模式通常是“为采用某种服务支持固定的费用，如果采用更多的服务就需要支付更多的费用，如果消费较少仍然支付固定的费用”。建议企业考虑的一个方面是，对话式人工智能项目通常难以估计，然后可能比预期的更慢或更快。它们可以影响比目标受众更多的受众。事后看来，预付费模式实际上很容易变得非常昂贵。
　　
　　另一个隐藏成本是企业运行和维护安装的IT管理成本。即使为本地版本的许可证和支持付费，仍然需要为硬件、日常管理、监控工具或随叫随到的支持付费。还要考虑一下企业的团队将花费时间做什么。如果确定团队进行建设，但他们将大部分时间花在基础设施问题上，那将会产生高昂的费用。
　　
　　企业需要考虑每个模型的隐藏成本，以便能够估算总拥有成本。考虑在整个生命周期中首次部署维护和测试等后需要多少成本。不要忽视这样一个事实，即对话式人工智能平台在采用之后也需要支持所有阶段。这就是版本控制、发布标志、重构、回归测试、分析、性能仪表板、改进仪表板等发挥作用的地方。如果选择的工具仅能帮助企业进行第一次构建，那么最终会由于以后提高效率而付出更多的代价。始终考虑程序的整个生命周期以及不同阶段需要什么。因此需要确保选择适合工作的工具。
　　
　　(2)资源是否会将时间花在正确的事情上?
　　
　　以上提到了这一点，但需要再次提醒。企业需要确保团队成员可以专注于他们最擅长的事情——构建一个成功的对话式机器人。在人工智能行业中，企业的开发团队40%～60%的时间花在技术支持、基础设施和连接上而不是花费在设计、构建和改进机器人上的情况并不少见。因为如果团队需要大量时间来构建支持性工具，或者只是让解决方案得以运行，那么大多数想要在用户体验方面开发的东西都会被遗忘。因此，在选择对话式人工智能时，必须特别注意在构建出色的机器人时最大限度地提高资源和员工效率。
　　
　　(3)资源在整个程序生命周期中是否高效?
　　
　　每个人都希望变得富有成效，所有的学科和行业都是如此，对于对话型人工智能开发人员来说也是这样。很多开发人员都喜欢构建和部署对话式人工智能技术，他们希望在自己的领域内富有成效。
　　
　　所以要问这个问题——这个工具会让团队更有效率吗?这不仅要在项目应用之后的1～2个月内富有成效，而在两年内，当扩大规模并变得更加包容时也具有更高的效率。企业在选择对话式人工智能工具时，其工作是帮助团队在整个程序生命周期中尽可能高效。
　　
　　4.做好横向和垂直领域的准备
　　
　　很多企业正在探索多个用例，需要确保其工具没有被锁定在垂直领域。每家企业采用了多少个对话式机器人?人们可能会惊讶地发现，每家企业通常部署了不止一个对话式机器人。大多数企业在内部(面向员工)和外部(面向客户和供应商)用例中采用对话式人工智能。因此，在选择对话式人工智能平台时，提前考虑一些问题很重要：例如想在什么领域采用?确定只构建一种解决方案吗?
　　
　　建议考虑选择的工具集是水平的还是垂直的——这意味着它是针对用例或行业(垂直)进行优化的，还是针对跨行业和用例的敏捷性进行优化的(横向)。
　　
　　因为内部和外部用例实际上是非常不同的，即使是在同一个行业。在这里，重要的是要考虑哪些模型的优势大于劣势。横向解决方案有一些优势：一是可以在不同的用例中使用相同的开发平台。与寻求所有竞争对手都在使用的行业特定解决方案相比，这可以从更大的技术社区获得支持。需要记住的是，对话式人工智能空间就是关于构建的，企业在开发过程中需要找到提供最大优势的工具。
　　
　　可以换个角度思考这个问题。针对特定用例的预训练解决方案的优势是什么?企业通常可以节省获取训练数据的时间，也可能拥有可以重复使用的预先构建的知识。这可能是有益的，但也有局限性。如果想进行更改，或者需要添加对企业来说独一无二的特定训练数据，需要考虑能够这样做吗?特定于用例的包是否可以帮助处理另一个用例?
　　
　　可能有一些例外，但简单的规则很可能是对话式人工智能平台或者是预先构建的但在定制方面遇到限制，或者是更灵活但必须构建更多。而这是一个构建者的世界，并建议考虑选择横向解决方案的长期利益。
　　
　　它实际上是关于构建的，因此可以跨垂直领域重复使用的包通常比特定于用例的包更有价值。
　　
　　预先构建的知识可以节省时间。技术社区能够开发优秀的技术是有原因的，每个人都从他人的贡献中受益。因此毫无疑问，预构建的软件包很好。但令人惊讶的是，在对话式人工智能中，预先构建的打包需要非常小才能有用。Salesforce的集成包如果只包含与Salesforce的API连接的基本构建块，则可以很容易地重用。因为这样它可以很容易地合并到许多不同的用例中——内部销售支持、内部报告、外部客户支持等。但是预先训练的外部客户支持包甚至可能需要更多时间来适应不同的用例。因为需要审查和调整包的每个组件，如果最终需要重组，最好从头开始。所以企业要和供应商讨论预构建的包，但要确保它们是模块化并且相当小。此外要记住的是，企业可以向社区分享自己构建的模块，而这通常是分享工作和寻找改进的好方法。
　　
　　Eriksson提出的一个建议是：尝试构建机器人以反映企业价值，并选择有助于建立品牌的方法。这可能并不容易，因为不确定是否真的能从外部得到很多帮助。企业需要让文化和品牌推广者参与进来。
　　
　　Eriksson建议企业的不同部门进行协作，并且处于控制之中，以便可以准确地设计客户应该拥有的体验。客户将会与企业的机器人交互，这是企业与客户群进行的双向交互之一，因此不要浪费时间，并致力打造品牌。
　　
　　编辑：Harris