最小可行架构实践：创建家庭保险聊天机器人—

前言

即使像聊天机器人这样的简单应用也需要一个最小可行产品（MVP）和最小可行架构（MVA），因为正确开发聊天机器人应用并不容易，而开发失败可能会极大地影响客户满意度。
MVP是产品开发策略的一个有用组成部分，与单纯的原型不同，MVP并不打算被“抛弃”。
对于更复杂的应用程序，MVA需要解决的问题因MVP的目标而异。虽然MVP测试了产品是否从客户的角度具有价值，但MVA通常会检查是否在技术和经济上能够交付该解决方案给客户，并在其预期寿命内支持该解决方案。
MVA还必须超越MVP，至少提供处理问题的选项，如果MVP成功，否则成功的MVP可能导致组织无法负担长期维护产品的费用。

我们之前的文章最小可行产品需要最小可行架构探讨了最小可行架构（MVA）的概念。本文探讨了如何运用最小可行架构概念，以一个虚构的例子——一个与传统保险系统（如保单管理系统）以及可能在企业外部的其他数据源（如重建成本数据、房屋估价）进行交互的聊天机器人——来回答房主可能对其保单和保险范围感兴趣的问题。为了说明问题，我们将专注于涉及住宅重建成本的房主问题。

使用MVA方法实现聊天机器人

我们选择了聊天机器人作为示例，因为它具有简单的用户界面，隐藏了一系列涉及数据完整性、并发性、延迟和响应性的复杂问题。聊天机器人是一种软件服务，可以通过文本或文本转语音提供在线聊天对话，作为现场人类代理的替代品。

这是许多软件系统范围内的一个很好的候选对象，比如被保险人使用的家庭保险系统。保险机构和保险公司的家庭保险专家通常会接到大量来自客户的电话和电子邮件查询，尤其是在受到野火等自然灾害影响时。受自然灾害影响的房主希望及时得到答案，但大量的电话意味着代理人无法及时回答紧急房主的问题。在更正常的时候，房主通常有一些简单但不紧急的问题要问，但不想给代理人添麻烦。聊天机器人可以通过提供更及时的信息来提高客户满意度，同时让代理人处理需要非常规决策能力的更复杂的任务。

初始 MVA：一个简单的菜单驱动的聊天机器人

我们创建 MVA 的第一步是就聊天机器人的工作方式做出基本的选择，这些选择足以实现最小可行产品（MVP）。在我们的示例中，MVP 只具有必要的最小功能，以测试聊天机器人能否实现我们为其设定的产品目标的假设。如果没有人想使用它，或者它不能满足他们的需求，我们就不希望继续构建它。因此，我们打算将 MVP 部署到有限的用户群体中，采用简单的基于菜单的界面，我们假设由于访问外部数据源收集数据可能会引起的延迟是可接受的。因此，我们希望避免添加更多的需求，无论是功能性需求还是质量属性需求（QARs），都不需要来验证我们对要解决的问题的假设。这导致了一个初始设计，如下所示。如果我们的 MVP 被证明有价值，我们将在后续步骤中为其添加功能，并逐步构建其架构。MVP 是产品开发策略的一个有用组成部分，与仅仅是原型不同，MVP 不打算被“抛弃”。

一个开源、可重用的框架（如 RASA）可以用于实现一系列客户服务聊天机器人，从简单的基于菜单的机器人到使用自然语言理解（NLU）的更高级机器人。使用这个框架，初始的 MVA 设计支持实现一个基于菜单的单一用途聊天机器人，能够处理简单的查询。这个简单的聊天机器人向用户呈现一个简单的选择列表，在智能手机、平板电脑、笔记本电脑或台式电脑上都可以使用。其架构如下图所示：

聊天机器人与以下后端服务进行交互：

被保险覆盖范围：这项服务是保险公司内部的。它将通过 API 进行访问，其延迟预计为低到中等。
重建成本：这项服务是外部的，与保险公司无关，将通过 API 进行访问。其延迟未知。
房屋估值：这项服务也是外部的，与保险公司无关，同样通过 API 进行访问。其延迟也未知。

正如我们在之前的文章中最小可行产品需要最小可行架构所描述的，我们通过做出一系列关于解决方案的基本选择来启动MVA过程，并使用一个简单的检查清单来确保我们做出了适当的架构决策。我们的检查清单包括以下项目：

安全性 —— 对于MVP，需要考虑安全性要求。用户应被授权访问聊天机器人正在检索的信息，因此聊天机器人应捕获用户凭据并将这些凭据传递给后端服务进行访问验证。
监控 —— 我们认为每个应用程序都应提供基本的监控功能，以监控性能并收集有关在初始部署期间可能遇到的大多数潜在系统问题的信息。
平台 —— 我们决定MVP将托管在商业云平台上。
用户界面 —— 我们认为一个简单的基于菜单的界面对于MVP来说是足够的，但这一项目可能需要根据我们最初用户的反馈进行重新评估。MVP用户界面可在智能手机、平板电脑、笔记本电脑和台式电脑上使用。
延迟和响应速度 —— 虽然我们暂时不太担心延迟和响应速度，因为MVP的部署将仅限于一个小用户群，但我们知道如果MVP成功，我们将需要扩大其用户群。延迟和响应速度可能成为潜在问题，需要解决。延迟指标将作为基本监控功能的一部分包含在内。

目前以下选择并不引起关注，但如果用户基数和使用量显著增长，可能会在以后成为问题。

并发性 —— 目前没有担忧，假设用户基数不会变得太大。
吞吐量 —— 目前没有担忧，因为查询处理的数据量非常小。
可扩展性 —— 目前没有担忧，但如果聊天机器人的用户基数显著扩大，可能会成为问题。
持久性 —— 目前没有担忧，因为聊天机器人存储的数据量非常少。

对于你自己的应用程序，将这个清单视为一个合理的起点，根据你正在探索的技术问题，可能需要进行调整或扩展。

在MVP交付后，用户似乎对产品的功能比较满意，但表达了他们对基于菜单的界面过于受限的观感；即使是MVP中使用的简单菜单也相当繁琐，扩展菜单选项只会加剧用户的体验，特别是在智能手机和平板电脑上。他们希望能够更熟悉地与聊天机器人交流，使用自然语言。

实现自然语言接口

用于MVP实现的开源聊天机器人框架包括对自然语言理解（NLU）的支持，因此我们将继续使用它来为聊天机器人的功能添加NLU。使用NLU将简单的聊天机器人转变为一个机器学习（ML）应用程序。

切换到NLU接口会改变聊天机器人的架构，如下图所示。离线模式下的数据摄入和数据准备用于训练数据，这两个是架构上重要的步骤，还有模型部署和模型性能监控。对语言识别准确度以及吞吐量和延迟的模型监控尤为重要。业务用户使用某些“行业术语”，随着时间的推移，聊天机器人在理解这些术语方面变得更加精通。

演进的架构包括两个需要在沙盒环境中进行训练，并部署到一组IT环境中以供最终在生产中使用的模型。这两个模型可以看作是与用户问题相关的NLU模型，以及与聊天机器人回答相关的对话管理（DM）模型。更具体地说，NLU模型用于聊天机器人理解用户的意图，而DM模型用于构建对话，使得聊天机器人可以满意地回应消息。这两个模型及其使用的数据应被视为一流的开发工件，并进行版本控制。

访问后端延迟

重建成本和房屋估价数据，至少在最初阶段，由其他组织维护和存储；只有投保范围信息在保险公司的控制之下。即使在低水平的使用情况下，用户可能会在聊天机器人从两个外部数据服务中收集必要数据时经历不良的延迟。假设延迟是可接受的，这一点可以并且应该在MVP阶段的早期进行测试，使用最初的基于菜单的用户界面。

如果由于访问外部服务而导致的延迟似乎不受欢迎，那么架构必须进行调整，将外部服务数据缓存在本地（或者至少与投保范围数据位于相同的位置），并定期更新缓存数据。假设房屋估价和重建成本在短时间内几乎不会变化，对这些数据进行缓存似乎是一个合理的权衡。然而，这一假设也需要进行测试，并且应该比较延迟对客户体验的影响成本与保持缓存一致性的成本，以确定缓存是否值得投入时间和精力。此外，应经常重新审查MVA检查表，以确保在此过程开始时所做的假设仍然有效，并且随着MVP发展为完整的产品，架构选择仍然令人满意。

总结

乍一看，聊天机器人应用似乎不需要太多的架构思考；提供大量构建块的框架层出不穷，开发应用似乎只需要训练一些自然语言理解模型并集成一些现成的组件。但是，任何经历过从许多聊天机器人获取有用信息的挑战的人都会知道，要正确开发聊天机器人应用并不容易，而出错的成本可能会极大地影响客户满意度。即使是像聊天机器人这样的简单应用也需要MVP和MVA。

对于更复杂的应用程序，MVA需要解决的问题将根据MVP的目标而异。虽然MVP测试的是产品从客户角度是否值得，但MVA通常会考虑从技术角度是否可行地将解决方案交付给客户，并且是否可以进行有效支持。MVA还必须超越MVP，至少提供处理必须处理的问题的选项，以防MVP的成功导致组织无法长期维护产品的情况出现。