BluePrism-智能自动化-全-

BluePrism 智能自动化（全）

原文：annas-archive.org/md5/2f8059e0c6c259396db3b43f33d9255e

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

在过去十年中，两种自动化趋势已经改变了公司的运营方式。第一种趋势是使用机器人流程自动化（RPA）技术来自动化后台办公室的计算机任务。第二种趋势，目前正在进行中，旨在自动化以前被认为无法自动化的工作。这是智能自动化（IA），它将 RPA 与机器学习（ML）相结合，以自动化工人智能和复杂决策。

IA 这个术语的含义取决于其使用的地方。对一些人来说，IA 意味着将 AI 功能集成到 RPA 产品中，以简化自动化开发，或添加自我修复功能，以帮助数字工作者从错误中恢复。在这本书中，IA 意味着在自动化过程的执行过程中使用 ML 来替代人类认知工作。虽然帮助开发者更有效地工作是有价值的，但 IA 应该主要定义为它通过大规模使用 ML 来转型运营和推动商业利益的能力。

目前市面上已经有几本关于 IA 的书。它们大多侧重于推销 IA 的高层次愿景和好处。然而，随着机器学习的惊人发展，大多数公司已经接受了 IA 的想法，并分配预算用于机器学习。这表明我们需要开始从 IA 的为什么转向如何。

这本书旨在弥合这一差距，向读者展示如何通过使用Blue Prism（BP），一家在 RPA 和 IA 领域的先驱软件公司，通过实际案例将 IA 付诸实践。许多技术书籍都是通过结合现有资源，如在线文章和课程拼凑而成的。这本书与众不同；它是我在麻省理工学院关于 IA 及其风险管理的研究论文的扩展。我将这项研究与我在 BP 领域的专业知识相结合，编写了一本以实践者为导向的 IA 书籍，其内容据我所知在别处无处可寻。

对于公司来说，IA 不仅仅是一个“锦上添花”的东西。将机器学习预测应用于日常工作的能力可能会成为未来大多数公司生存的条件。那些对 IA 有细微理解，而不是高层次理解的人，将在市场上脱颖而出。这本书将为你提供这种对 IA 的细微理解，并指导你和你所在的公司实现更好的 IA 成果。

这本书面向的对象

这本书是为探索 IA 或希望改进现有 IA 程序的 BP 实践者而写的。无论你是开发者、公民开发者、解决方案设计师还是 COE 团队成员，这本书中都有适合你的内容。

专注于实施的读者将学习到设计 BP 解决方案以实现 IA 的不同方法。流程控制器和 IA 项目管理人员也可以阅读这本书，了解机器学习如何增加他们的自动化程序复杂性，以及如何管理它*。

这本书涵盖的内容

第一章，作为服务的机器学习 – 数字交易所和 Web API，讨论了您如何通过从数字交易所下载的连接器在 BP 过程中实现 ML。

第二章，从命令提示符和 PowerShell 进行预测，展示了您如何通过命令行调用 ML 预测并捕获 BP 中的输入。

第三章，代码阶段，展示了如何将 C# ML 程序移植到代码阶段，以便它可以直接从 BP 运行。

第四章，审查预测和人工参与，解释了为什么人工审查 ML 预测很重要，并实现了两种可以用来启用审查的方案。

第五章，HITL 的 IA 流程和工作队列设计，探讨了多个不同的 IA 解决方案设计，其中 BP 流程和工作队列的数量各不相同。

第六章，可重用 IA 组件，展示了在任意 IA 解决方案设计中普遍有用的 BP 设计组件。

第七章，IA 模板和工具 – IA 对象，将前几章中展示的设计结合成可重用的模板，以加快您的 IA 解决方案和实施。

第八章，LAM、用户角色和 MTE，讨论了 IA 所需的新用户角色以及他们应该拥有的 BP 权限。

第九章，机器学习部署和数据库操作，描述了当前的机器学习模型部署方法以及它们如何影响在 BP 中的模型部署和回滚。

第十章，IA 对机器人操作模型的影响，讨论了 IA 可能对机器人操作模型产生的影响。

第十一章，处理退款，通过一个场景，重点关注设计 IA 解决方案并使用模板实现其整体结构。

第十二章，电力服务中断，通过一个场景，说明了 ML 预测审计的重要性。

第十三章，其他智能 Blue Prism 产品，介绍了四个其他与 IA 相关的 BP 产品以及一些未来的 IA 趋势。

附录，IA 风险管理，总结了关于 IA 风险的论文研究。

为了充分利用这本书

您应该在 BP 大学网站上完成 BP 基础培训课程。理想情况下，读者也应该至少有三个月的 BP 实践经验。

本书重点是 IA，即如何以管理不确定 ML 预测对您的自动化业务流程影响的方式将 RPA 与 ML 连接起来。不需要 ML 经验，并且了解如何构建模型超出了本书的范围。

然而，本书将使用一些基本的 ML 术语。首先，我们有 回归 与 分类。这两个术语广泛地划分了我们试图进行的 ML 预测类型。对于 回归 问题，我们试图预测一个数值，例如，预测销售数字。

对于 分类 问题，我们试图对某些事物进行分类。我们试图预测的不同类别被称为 标签。例如，我们可能试图将客户支持工单分为不同的类别：投诉、退款和销售咨询。这三个是 分类 问题的 标签。

置信度分数是一个与几乎每个 ML 预测一起返回的数字，它表示服务对该预测的信心程度。此区间将在 0 到 1 之间，或 0 到 100 之间。例如，如果您向 ML 模型发送一张动物的图片，它可能会回复说标签“猫”有 0.96 的 置信度，而标签“老虎”有 0.99 的 置信度。

本书以示例为主，编写目的是使其能够使用免费工具完成。这包括 BP 和 ML 服务的版本，它们都具有免费每月使用限制。本书需要以下要求。其他每个章节也可能有自己的要求。

本书涵盖的软件/硬件	操作系统要求
Blue Prism Trial 或 Enterprise Edition，版本 6.4 及以上	Windows
SQL Server Management Studio
Python 3
ML.NET / C#
AWS Comprehend
Azure Form Recognizer
Google Cloud Vision

作为所有章节的先决条件，请导入 BP 安装路径下的所有标准 BP VBO 子文件夹。默认路径为 C:\Program Files\Blue Prism Limited\Blue Prism Automate\VBO。对于大多数章节，将会有需要下载和导入额外 BP 发布文件的动手实践示例，这些文件来自 GitHub。具体说明将在那些章节中提供。

如果您使用的是本书的数字版，我们建议您亲自输入代码或从本书的 GitHub 仓库（下一节中提供链接）获取代码。这样做将帮助您避免与代码的复制和粘贴相关的任何潜在错误。

下载示例代码文件

您可以从 GitHub 下载本书的示例代码文件，网址为github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism。如果代码有更新，它将在 GitHub 仓库中更新。

我们还有其他来自我们丰富的图书和视频目录的代码包，可在github.com/PacktPublishing/找到。查看它们吧！

使用的约定

本书使用了多种文本约定。

文本中的代码：表示文本中的代码单词、数据库表名称、文件夹名称、文件名和文件扩展名。当引用 BP 术语时，它指的是页面名称，如主页面，以及数据类型，如文本和数字。

代码块设置如下：

using System;
using System.IO;
using Microsoft.ML;

当我们希望将您的注意力引到代码块的一个特定部分时，相关的行或项目将以粗体显示：

using System;
using System.IO;
using Microsoft.ML;

粗体代码：当用于 BP 术语时，这指的是数据项和环境变量名称。

任何命令行输入或输出都应如下编写：

> mkdir build

粗体：表示新术语或重要词汇。当用于 BP 术语时，这指的是动作名称（实用程序 – 环境::启动进程）和数据项值。

斜体：当用于 BP 术语时，这指的是阶段名称、组名称、块名称、队列名称以及 BP 软件中的其他标题，例如控制室。

小贴士或重要注意事项

看起来是这样的。

联系我们

我们始终欢迎读者的反馈。

一般反馈：如果您对本书的任何方面有疑问，请通过 customercare@packtpub.com 给我们发邮件，并在邮件主题中提及书名。

勘误：尽管我们已经尽一切努力确保内容的准确性，但错误仍然可能发生。如果您在这本书中发现了错误，如果您能向我们报告这一点，我们将不胜感激。请访问www.packtpub.com/support/errata并填写表格。

盗版：如果您在互联网上以任何形式遇到我们作品的非法副本，如果您能提供位置地址或网站名称，我们将不胜感激。请通过版权@packtpub.com 与我们联系，并提供材料的链接。

如果您有兴趣成为作者：如果您在某个主题上具有专业知识，并且您有兴趣撰写或为书籍做出贡献，请访问authors.packtpub.com。

分享您的想法

一旦您阅读了《使用 Blue Prism 的智能自动化》，我们很乐意听到您的想法！请点击此处直接进入此书的亚马逊评论页面并分享您的反馈。

您的评论对我们和科技社区都很重要，并将帮助我们确保我们提供高质量的内容。

下载此书的免费 PDF 副本

感谢您购买此书！

您喜欢在路上阅读，但无法携带您的印刷书籍到处走？您的电子书购买是否与您选择的设备不兼容？

别担心，现在每购买一本 Packt 图书，你都可以免费获得该书的 DRM 免费 PDF 版本。

在任何地方、任何设备上阅读。直接从您最喜欢的技术书籍中搜索、复制和粘贴代码到您的应用程序中。

好处不止于此，您还可以获得独家折扣、时事通讯和每日免费内容的专属访问权限。

按照以下简单步骤获取好处：

1. 扫描二维码或访问以下链接

packt.link/free-ebook/978-1-80324-969-8

1. 提交您的购买证明

2. 就这样！我们将直接将免费 PDF 和其他好处发送到您的电子邮件。

第一部分：连接 Blue Prism 到 ML 模型

第一部分 讨论了三种将 BP 与 ML 模型接口连接的不同方法，以便 ML 预测可以在自动化过程中使用。第一章 讨论了如何使用 BP 数字交易所的预构建资产连接到基于云的 ML-as-a-service 服务。这是开始使用 ML 的最快方式，因为模型已经准备好使用。我们还将概述目前可用的 ML 服务以及它们可以潜在满足的 IA 用例。

第二章 展示了如何通过触发 ML 程序在 Windows 命令提示符或 PowerShell 中运行来将 BP 连接到 ML。我们将介绍哪些 BP VBOs 可以用来调用这些程序，以及如何在 BP 中捕获结果的不同方式。

最后，第三章 展示了如何在对象代码阶段直接运行 C#或 VB.NET 代码来将 BP 连接到 ML。在这里，我们将讨论如何将现有 ML 程序源代码移植，以便它可以直接从对象中运行。本章中使用的 ML 程序是由 Microsoft 的 ML 框架 ML.NET 构建的。

本部分包含以下章节：

• 第一章，作为服务的机器学习 – 数字交易所和 Web API

• 第二章，从命令提示符和 PowerShell 进行预测

• 第三章，代码阶段

第一章：机器学习即服务：数字交换和 Web API

我们今天与 ML 互动的大部分方式都是通过Web API。即使是通过 Web 浏览器使用大型语言模型（LLM）聊天机器人，也会在后台进行 Web API 调用以给我们回复。通常情况下，您的 BP 流程也将使用 Web API 来获取在线托管 ML 预测的结果。

在本章中，我们将探讨 IA 中最流行的 ML Web API，如何在 BP 的数字交换（DX）上找到它们，如何将它们连接到 BP，以及如何自己构建一个，以便在自动化用例中进行预测。更具体地说，我们将涵盖以下内容：

• 了解最常见的 ML 服务、它们的一些常见用例以及如何在 DX 上找到它们

• 通过两个示例说明如何使用 DX 中预构建的可下载资产进行 ML 预测

• 从头开始构建 BP Web API 服务以连接到 DX 上目前不可用的 ML 服务

到本章结束时，我们将涵盖三个最常用的机器学习即服务（MLaaS）平台：亚马逊网络服务（AWS）、Azure和谷歌云平台（GCP）的示例。这些示例还涵盖了某些最常见的 IA 用例：从非结构化文本中提取数据、从表格中提取数据以及从图像中提取文本。我们还将涵盖一些关键概念，这些概念将指导我们未来的解决方案设计：单次与批量以及同步与异步预测。

技术要求

对于本章，请确保以下条件满足：

• 一个有效的 Blue Prism Portal (portal.blueprism.com) 账户。这是从 DX 下载资产所必需的。账户可以免费创建。

• 在 AWS、Azure 和 GCP 上有一个活跃的账户。在本章中，我们将使用每个供应商的示例。所有示例都可以在服务提供的免费层中运行。

• 从 GitHub github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch1/Ex_1_to_3.bprelease 下载以下文件。将.bprelease文件导入 BP。这包含将在我们的示例中使用的示例流程。

使用 DX

DX 是 BP 的市场，包含许多 BP 开发和社区提交的.bprelease、.bpskill、.bpobject、.bpprocess和.xml文件。DX 上的大多数资产都可以免费下载和集成；然而，使用 ML API 服务本身可能存在成本。如果服务符合您的用例，使用 DX 中的预构建资产是最快和最简单的方法来将 ML 集成到您的自动化业务流程中。

在本节中，我们将了解 DX 上可用的流行机器学习服务以及潜在的使用案例。在可能的情况下，将提供真实世界的使用案例示例，这些示例来自我对超过 100 个 IA 用例和技术的研究。

访问 DX

可以通过digitalexchange.blueprism.com访问 DX。你需要使用你的 BP 门户账户凭据登录以下载资产。

DX 上可用的不仅仅是 Web API。由于我们只对本章中的 Web API 感兴趣，请点击更多过滤器并根据连接器过滤以缩小搜索结果：

图 1.1 – 在 DX 上过滤 Web API

可以使用搜索资产搜索框来查找特定的 ML 服务，如果你已经知道服务名称。稍后，我将提供所有最流行的搜索术语的摘要，你可以根据它们的使用案例在 DX 上找到 ML 资产。但首先，让我们讨论一些使用 ML Web API 所需的基本知识。

机器学习 Web API 基础知识

在传统的 RPA 中，BP 通过网页浏览器与桌面应用程序或网站交互。通常无法通过这两种方法连接到机器学习算法。相反，超过 90%的商业可用算法，包括 AWS、Azure、GCP、OpenAI 等，都作为 Web API 公开。

以下图像显示了从 BP 数字工作者发出的标准 Web API 调用。首先，数字工作者发起 API 请求，通过互联网到达 API 端点。做出机器学习预测后，端点返回包含预测的 API 响应，返回到 BP。

图 1.2 – 使用 RPA 与 ML 最常见的方式：通过互联网进行 Web API 调用

许多机器学习模型是专有的。供应商希望通过在自己的服务器上托管模型来保护他们的知识产权，这些服务器具有受保护的 API 端点。如果你的 BP 环境不允许连接到互联网，你需要咨询你的网络和安全团队，看看是否可以做出例外。

如果不行，那么使用公开托管的机器学习 API 将不可行。你将不得不在 Intranet 上开发和托管自己的模型，或者直接在数字工作者上做出预测。请注意，是数字工作者发起机器学习请求。有些人错误地认为 BP 应用程序服务器会调用 API 端点。

注意区分Web API，这是我们连接以获取机器学习预测的 API，以及Web API 服务，这是 BP 产品的一个功能。Web API 服务功能用于定义和设置与 Web API 的连接。我们将在这个章节的最后创建一个 Web API 服务作为最后一个示例。

关于此产品功能的官方文档可以在此处找到：bpdocs.blueprism.com/bp-7-1/en-us/Web%20API/HTML/configure-api-definition.htm

在本节的剩余部分，我们将从 IA 集成角度探讨了解 Web API 的重要信息。这包括认证、JSON、定价、单次与批量预测，以及同步与异步预测。

认证

大多数 Web API 服务在使用前都需要你注册。注册后，你会得到一个或多个唯一的 ID，类似于用户名和密码，以唯一地识别你。根据具体的服务，这些唯一的 ID 可能足以直接获取访问权限并调用你的 ML API 以接收你的预测。这如图图 1**.3所示：

图 1.3 – 当唯一 ID 作为认证凭证有效时

例如，Azure 就是一个这样的例子。你可以传入一个唯一的 ID，在 Azure 术语中称为订阅密钥，以访问你的预测端点。

然而，大多数服务将要求你在调用 ML API 之前使用你的 ID 请求一个临时访问令牌。首先，你使用你的唯一凭证发送一个请求以接收一个临时访问令牌。然后，将这个临时令牌连同输入数据一起传递给你的 ML API 请求以获取你的预测结果。例如，AWS 将他们的唯一 ID 称为访问密钥 ID和秘密访问密钥。在 GCP 中，它们被称为客户端 ID和客户端密钥。AWS 和 GCP 都要求在 ML API 调用中传递一个临时访问令牌。

图 1.4 – 两部分 API 调用：获取访问令牌和调用 ML API

这种工作方式的具体方式因供应商而异。例如，一些供应商会让你将唯一 ID 作为查询参数提交，而另一些则要求你在请求头中提交。一些使用专有算法生成你的临时访问令牌（包括 AWS），而另一些则使用开放标准，如 OAuth2（包括 GCP）。

你需要查阅供应商的文档以获取具体细节。使用 DX 中预构建资产的主要好处之一是，认证逻辑通常已经为你处理！你所需要做的就是从 ML 提供者那里生成你的唯一凭证，并且（如果有的话）临时访问令牌处理逻辑也已经为你处理。

JSON

JSON 是用于在 Web 服务之间交换数据的最流行的数据格式之一。几乎所有机器学习 Web API 都期望接收 JSON 作为输入数据，并返回 JSON 作为输出数据。当使用来自 DX 的 Web API 时，BP 的数据类型与 JSON 之间的几乎所有转换都将为您自动完成。

可能存在需要手动将 BP 数据转换为 JSON 的情况。这种情况最可能发生在“实用工具 – JSON”VBO 上，该 VBO 可在 BP 安装目录下的VBO子文件夹中找到。

以 JSON 格式发送文件需要您首先对其进行编码，通常使用 Base64 格式。BP 在 DX 上提供了三个 VBO 来帮助完成这项工作：实用工具 – 编码解码、实用工具 – 文件操作和Base64Encoder。

定价

MLaaS 提供的通常在达到一定限制内是免费的。使用免费限额后，您将开始按交易付费。这些限制通常每月重置。例如，让我们看看 Azure 的计算机视觉 API (azure.microsoft.com/en-us/pricing/details/cognitive-services/computer-vision/)。在撰写本书时，它每月提供 5,000 次免费交易。对于接下来的 1,000,000 次交易，每次交易的费用是 10 美分。在 1 到 10 百万次交易之间，每次交易的费用是 6.5 美分。随着您每月交易次数的增加，每次交易的成本会降低。

定价取决于许多因素，例如您所在的地区、您在计算机视觉库中使用的特定服务，以及您是否愿意预先承诺使用最低数量的交易。

需要注意的是，一次交易并不等同于一次 API 调用！例如，可能有一种服务允许您一次性发送多个文档。每个文档可能被视为单独的交易，尽管它们是在一个 API 调用中提交的。魔鬼在于细节，因此在评估 MLaaS 提供是否适合您的用例时，您需要仔细查看定价页面。这代表了 IA 解决方案运营的持续成本，必须权衡其带来的好处。

单个与批量预测

在使用 API 之前，通过阅读其文档来理解 API 是非常重要的。在查看文档时需要注意的一个重要事项是，API 是否仅允许每个 API 请求进行一次预测，或者是否可以接受单个 API 调用中的批量多个输入。可能存在针对这两种情况的不同端点。

图 1.5 – 批量预测

对于批处理预测，您将首先在单个请求中将多个预测的输入数据发送到 API 端点（图 1.5中的第一步）。预测将被执行（第二步），响应将返回所有预测结果（第三步）。在单次预测的情况下，每个 API 请求调用只能进行一次预测。

注意图中显示的“单个请求”和“单个响应”并不是单次与批量之间的特性；这是一个同步与异步的问题，将在下一节讨论。

同步与异步预测

单次与批量指的是在单个 API 调用中可以请求的预测数量。另一方面，同步与异步指的是预测结果是否在同一个 API 调用中作为请求返回。

对于同步（也称为在线）调用，预测结果在同一个请求中返回。这用于预测可以相对快速完成的情况，例如短文档和单张图片。图 1.5也显示了一个在线案例，其中响应在同一个 API 调用中返回。

对于异步（也称为离线）调用，您不会在同一个 API 调用中收到预测结果。相反，您将首先收到一个用于查询预测作业状态的唯一 ID。想象一下，如果您需要处理一个大的视频作为输入，ML 服务可能需要几分钟甚至几小时才能返回其预测。以下以 AWS 的 Rekognition Video API 为例：

图 1.6 – AWS 的 Rekognition Video API：异步调用

首先，您通过提供一个视频的 S3 链接来创建一个预测的 API 请求。在这个第一个 API 调用中，您将收到一个JobId。对于第二个 API 调用，您将JobId传递给GetLabelDetection端点，该端点返回JobStatus。如果视频仍在处理中，您将收到JobStatus为IN_PROGRESS。

根据视频的大小，您可能需要等待几秒钟甚至几分钟，直到预测完成。在这段时间内，您可以继续调用GetLabelDetection API 端点来检查作业状态。当它完成时，JobStatus 将变为SUCCEEDED，并且预测的标签将与请求一起返回。

虽然“批处理”通常意味着异步，但这并不总是如此！单个预测可以是异步的（例如在 AWS Rekognition Video 示例中），而批处理预测可以是同步的（正如本章最后的一个示例所示）。

现在我们已经介绍了 ML Web API 的基础知识，让我们看看我们如何使用 DX 下载预构建的资产，并快速进行 ML 预测，而无需自己开发 ML 模型。

DX 上 MLaaS 的概述

机器学习即服务（MLaaS）提供的产品，如 Azure、AWS、GCP 和 IBM 的产品，允许你快速将预训练的机器学习算法集成到业务流程（BP）中。你将能够使用智能自动化（IA）的机器学习部分，而无需处理机器学习生命周期中的复杂性，如训练、选择算法、调整、托管、维护等。然而，MLaaS 通常不太灵活，因为模型是预训练的，通常不能根据你的特定用例进行定制。这些服务中的大多数提供的是通用而不是特定的机器学习功能。

为了节省你搜索 DX 的时间，我已经整理并总结了目前最流行的机器学习即服务（MLaaS）提供的产品列表，按你打算提供给算法的输入数据类型进行分组。这将给你一个关于你可以快速简单地实现的智能自动化案例的感觉。输入数据类型被分类为图像、视频、语音和文本。

能够接受不同类型输入的多模态机器学习模型开始出现。GPT-4 就是这样一个例子，它可以接受文本和图像作为输入。这些模型在本节中不会涉及，因为它们在本书撰写期间尚未完全可用。

注意，数值数据并未列为输入项。数值输入通常用于回归问题，而且提供足够通用的机器学习模型以用于回归的服务并不多。如果你试图预测数值数据，你可能需要构建自己的机器学习模型。

从开发或概念验证的角度来看，大多数机器学习（ML）供应商提供其预测服务的慷慨免费使用层。这使你能够在短时间内评估是否值得追求特定的智能自动化（IA）项目。

在调查我的论文研究中的 122 个智能自动化（IA）用例时，我发现其中 75%有可能通过机器学习即服务（MLaaS）来实现，因此调查这些服务和数字化转型（DX）非常值得你的时间。基于文本的服务是最常见的，占所有智能自动化用例的 66%以上。

图像服务

图像服务可以提供关于图像中内容的洞察。这些服务中的大多数对可以提交给其服务的图像有具体要求。这可能包括文件大小要求、图像格式（PNG 和 JPG 是最常见的）、图像分辨率、最小和最大尺寸以及图像方向。

一些服务可能要求你将文件作为 API 请求体内容的一部分上传，而其他服务可能要求你首先将文件上传到某个地方，并提供图像的 URL。许多这些 API 提供单次和批量操作，通常是同步的，在同一个请求中返回检测到的标签和初始响应。

基于图像的机器学习服务仅占我发现的人工智能用例的 10%。这些类型服务的问题在于预测返回的通用对象不够具体，无法发挥作用。然而，许多这些服务也允许您自定义标签，这意味着您可以使用供应商的模型作为起点，进一步训练机器学习模型，以匹配您感兴趣寻找的内容。这正是许多潜在基于图像的使用案例得以解锁的地方。

预测完成后，您将获得以下信息：

• 图像中找到的标签列表

• X 和 Y 坐标表示发现对象的边界

• 确信度分数显示对象属于特定标签的确定性程度

基于图像的服务及其潜在用例包括以下内容：

• 对象检测：这允许您在来自通用类别的图像中找到标签，例如动物、人、汽车、建筑物等。在许多情况下，这可以进一步定制，以检测特定对象，例如通过 AWS 的DetectCustomLabels和 Azure 的Custom Vision。一些现实生活中的人工智能用例包括在工厂中用于计数和查找产品缺陷以及分发处方药物的质量保证。

• 面部及面部特征检测：这预测图像中是否存在面部，以及面部显示的性别、估计年龄和整体情绪。这可以用于监控和处理包含照片的申请。我发现的唯一实现面部识别的人工智能用例是在在线学习课程中记录出勤和量化学生参与度。

• 图像内容审查：这允许我们确定图像是否包含成人或暴力主题。这通常用于社交媒体上的用户上传内容审查。我在人工智能中没有找到这个功能的实际用例。

• 文本检测：这返回图像中文字的位置和文字内容。这是最常见的基于图像的人工智能用例之一。

• 表单检测：这告诉我们图像中是否包含可提取的表单字段或表格。这对于人工智能来说具有通用性，可以用于处理发票、收据和财务报告数据。一个现实生活中的例子是从手写银行账户申请表扫描中提取数据。

	DX 技能的搜索词
功能	AWS
对象检测	Rekognition
面部及面部特征检测	Rekognition
内容审查	Rekognition
文本检测	Rekognition, Textract
表单检测	Textract

表 1.1 – DX 上基于图像的 ML 服务的搜索词

从供应商处提供，但不在 DX 上，因此您必须自行构建 web API。

视频服务

以视频为输入的服务具有与图像服务类似的功能。它们允许在几乎实时的情况下分析视频。根据服务不同，您可能需要提供输入作为流 URL，或者上传您的视频文件到预指定的区域。

几乎实时是一个需要记住的关键点。大多数处理视频的 ML 服务都是异步的，不会立即给出预测结果。首先，您需要调用 API 请求预测。然后，您必须进行进一步的调用以检查预测是否准备就绪。

通常会对视频长度（3-6 小时）和文件大小（10-50 GB）的处理设置最大限制。这些限制因供应商而异。请检查他们的 API 文档，并遵循他们关于这些限制、分辨率、摄像机角度、视频比特率等方面的指南。在我的研究中，我没有找到任何使用视频作为输入源的用例。相反，可能更有意义的是在固定间隔（例如，每 5 秒）对视频进行快照，并使用基于图像的 ML 服务。

预测完成后，您将获得以下信息：

• 视频中找到的标签列表

• 表示发现对象边界的X和Y坐标

• 每个检测到的标签的开始和结束时间范围或时间戳

• 显示对象属于特定标签的置信度分数

基于图像的服务及其潜在用例包括以下内容：

• 对象检测：此功能可以用于检测通用标签，如动物、人、汽车、建筑物等。示例用例包括监控、无人机视频分析和质量保证。

• 场景变化检测：此功能用于检测视频流是否从一个摄像头切换到另一个摄像头。这可以用于视频编目、存档和剪辑。

• 内容审核：此功能预测视频是否包含成人或暴力主题。它通常用于社交媒体上的用户上传内容审核。

• 标志检测：此功能用于检测视频中的标志。它可以用于自动标记或检测视频中的品牌和标志，或用于监控用户提交的内容。

• 人脸检测：此功能用于检测视频中的人脸。它可以用于自动化设施访问控制、跟踪移动和监控。

• 文本提取：这用于从视频中提取文本。即使文本在视频的部分时间段被遮挡，这些服务也可以在摄像头移动足够覆盖整个文本的过程中重建完整的文本。这可以用于从现场活动提取演示文稿幻灯片内容。

	DX 技能的搜索词
特性	AWS
物体检测	N/A*
场景变化	N/A*
内容审核	N/A*
标志检测	N/A
人脸检测	N/A*
文本提取	N/A*

表 1.2 - DX 上基于视频的机器学习服务的搜索词

*由供应商提供但不在 DX 上，因此您必须构建自己的 Web API。

语音服务

这些允许您从直播音频和保存的音频文件中提取数据。这可以是同步的，也可以是异步的，具体取决于音频的长度或文件的大小。通常，较短的文件会同步处理。

根据 API，供应商可能要求您直接将音频文件上传到机器学习端点或上传到云存储。他们还会对音频的长度和使用的语言有要求。在我的研究中，我没有找到任何使用语音作为输入的 IA 实现案例。

基于语音的机器学习服务的典型输出如下：

• 转录文本

• 转录文本的间隔时间戳

• 置信度分数

语音机器学习的常见功能和用例如下：

• 语音转录：这会将语音音频转换为文本。

• 文本到语音：这允许文本被大声朗读出来。

• 购买、修改或取消``一张票。

• 说话人识别：这有助于您识别不同的说话人。当将预测的说话人数目作为输入传递给算法时，效果最佳。它还会为每个说话人分配一个唯一的标识符。如果您已经知道说话人的身份，可以使用唯一标识符手动将音频映射回人类说话人。这可以用于自动添加包含说话人名字的子标题。

• 语音翻译：这允许您将音频转录成不同语言的文本。这也可以通过将语音转录服务链接到文本翻译服务来实现。

	DX 技能的搜索词
特性	AWS
语音转录	Transcribe
文本到语音	Polly
意图识别	N/A*
说话人识别	N/A*
语音翻译	N/A

表 1.3 – 在 DX 上基于视频的机器学习服务的搜索词

*由供应商提供但不在 DX 上，因此你必须构建自己的 Web API。

文本服务

基于文本的机器学习服务是目前人工智能中最常用的机器学习服务。在我发现的 122 个人工智能用例中，大约三分之二都是基于文本的，其中 52%的案例涉及使用翻译、自然语言处理（NLP）、命名实体识别（NER）、OCR 和文档分类，15%的用例使用聊天机器人作为触发人工智能的接口。

文本服务通常是同步的，并且根据服务不同，预测请求可以逐个发送或批量发送。基于文本的机器学习服务接收要分析的文本和语言作为输入参数。

从文本机器学习收到的典型输出如下：

• 预测标签

• 置信度分数

以下是一些常见的文本机器学习的使用方式：

• 文档分类：这允许你区分不同类型的文档。这通常会导致进一步的机器学习处理，例如实体识别。一个例子是发票处理。文档分类可以用来根据供应商对发票进行分类。另一个例子是将文档分为发票和采购订单，因为它们通常看起来很相似。

• 实体识别：这将从预定义的类别中提取文本，例如名称、日期、数字和事件。这可以用于对文本进行分类、过滤简历和从非结构化报告中提取数据。这是最受欢迎的使用案例之一，尤其是在处理发票、索赔和其他标准化表格时。许多供应商允许你自定义实体列表以匹配你的特定用例。

• 我等了 45 分钟才轮到我，关键短语可以是“等了”和“45 分钟”。

• 情感分析：这可以找到在一段文本中表达的高层次观点或态度。一些常见的返回标签包括正面、中性、负面和混合。大多数模型无法在同一标签下区分更细微的情感；例如，“兴奋”和“快乐”都会被返回为正面，尽管在现实中它们是不同的。这种方法的常见用途是对电子邮件或客户支持工单进行分类，以及在社交媒体和产品评论中检测情感。

• 语言检测：这通常在将文本发送到其他基于文本的机器学习算法之前作为第一步使用。

• 翻译：这可以在实时或按需将文本从一种语言翻译成另一种语言。所有供应商都支持超过 50 种语言。

• 聊天机器人：这些服务允许公司为其应用程序创建对话式界面。例如，一个政府机构使用聊天机器人作为人们请求社会保障福利的接口，这进一步触发了人工智能来完成处理。

• 问答：这是 LLMs 的主要功能之一。由于这项技术相对较新，我还没有遇到任何在 IA 中使用此技术的用例。

• 文本生成：这是由 LLMs 启动的一个相对较新的用例。这可以作为一种创建对用户投诉或电子邮件的回复的方式。

	DX 技能的搜索词
功能	AWS
文档分类	N/A*
实体识别	AWS 的 Comprehend 功能
关键词提取	AWS 的 Comprehend 功能
情感分析	AWS 的 Comprehend 功能
语言检测	AWS 的 Comprehend 功能
翻译	AWS 的翻译功能
聊天机器人	N/A*
问答	N/A
文本生成	N/A

表 1.4 - DX 上基于视频的 ML 服务的搜索词

从供应商处提供，但不在 DX 上，因此您必须自行构建 web API。

^OpenAI 并非完全由微软拥有，尽管他们有一个 强大的合作伙伴关系。**

随着 GPT-4、Bard 和其他大型语言模型（LLM）的发布，发生了一些有趣的发展。这些模型天生具有执行文本翻译、实体提取、语言检测、情感分析等任务的能力，尽管它们并没有被明确训练来做这些事情。我预计，随着 LLM 的日益成熟，它们将成为许多基于文本和基于图像的机器学习 API 的可行替代品。

供应商选择

在上一节中，我们探讨了四个主要的机器学习即服务（MLaaS）供应商：AWS、Azure、GCP 和 IBM。选择其中一个而不是另一个的决定是复杂的，并且高度依赖于您公司可能已经存在的限制。选择标准可以包括以下内容：

• 在特定供应商处的现有偏好或折扣

• 在使用一个平台而不是另一个平台时，现有的组织或团队知识

• 只由一家供应商提供的必备服务

• 服务在理想地理位置的可用性

• 服务本身的成本

• 根据您的输入数据，服务的准确性

• 服务是否支持您期望的单个与批量或同步与异步处理

• 数据保留和安全策略

• 上线 SLA 和 API 使用限制

• 服务作为 DX 上的现成资产的可用性

在继续进行实际示例之前，让我们总结一下我们刚刚学到的内容。DX 是 BP 的“应用商店”，在这里可以找到许多连接到 ML 服务的连接器。这些连接器中的大多数都是使用 JSON 作为数据交换格式的 Web API。使用 ML Web 服务（如身份验证）和特定 API 要求的一些最具挑战性的部分已经包含在 DX 资产中，这使得您能够快速将 ML 集成到 BP 流程中。

接下来，我们研究了主要 ML 服务提供商（AWS、Azure、GCP 和 IBM）的 ML 的常见用例。每个供应商为其 ML 服务都有营销名称。仅根据其名称了解每个服务做什么并不直接。我已经根据它期望接收的输入类型（图像、视频、语音和文本）对所有的服务进行了分类。我还列出了它们的营销名称以及您可以在 DX 上使用的搜索词，如果它们存在的话。最后，我们研究了可能影响我们选择一个 ML 供应商而不是另一个供应商的一些因素。

示例

在本节中，我们将通过三个使用 Web API 进行 ML 预测的示例来演示。在前两个示例中，我们将从 DX 下载并使用两个不同的资产。在第三个示例中，我们将从头创建一个 Web API 服务。我们将使用每个主要供应商的一个 Web API：AWS、Azure 和 GCP。这些示例将需要您注册免费账户以使用他们的服务。如果您没有每个供应商的账户，请跟随您有账户的供应商进行操作。

从 AWS，我们将使用 Comprehend 对电子邮件服务请求进行文本分析。使用 Azure，我们将使用表单识别器从发票中提取数据。最后，从 GCP，我们将使用 Cloud Vision API 从基于图像的 PDF 中提取文本。这三个服务被选中是因为它们是最受欢迎的 ML 服务供应商，具有不同的身份验证方法，并且涵盖了在 IA 中遇到的最常见的用例，包括处理文本数据、表格和图像。

使 Web API 正常工作的最具挑战性的部分如下：

• 身份验证：这部分是在 MLaaS 供应商门户上完成的，以生成正确的密钥。另一部分是将这些密钥输入 BP 的正确部分，通常是凭证。DX 资产的文档将指导您如何进行此操作。

• 格式化输入数据：这通常需要阅读 API 的文档，但这是由 Web API 服务或对象提供的。

• 格式化输出数据：这通常需要阅读 API 的文档，但这是由 Web API 服务或对象提供的。

我们将要讨论的三个示例以及它们之间的差异总结在下表中：

服务	BP 中 API 的实现	身份验证	批量/单次	同步/异步	用例
AWS Comprehend	对象 + 网页 API	暂时访问令牌（对象）+ 访问密钥 ID + 密钥	单个	同步	从支持票文提取实体
Azure 表单识别器	对象 + HTTP 和 JSON VBOs	单个订阅密钥	单个	异步	从数字发票中提取数据
GCP 云视觉	自定义构建的 Web API 服务	暂时访问令牌（OAuth2）+ 客户端 ID + 客户端密钥	批量	同步	从图像中提取文本

表 1.5 – 我们将经历的三个示例的摘要

示例 1 – AWS Comprehend 用于文本实体提取、关键短语提取和情感分析

AWS Comprehend 是一种机器学习服务，可以从文本中提取信息并理解数据。在本例中，我们将使用 Comprehend 对电子邮件支持案例进行分类。与通过网页表单或聊天机器人提交支持请求不同，你可以要求用户为你分类问题，直接通过电子邮件发送的问题分类必须手动完成、通过规则或通过机器学习来完成。

在 Comprehend 中，你可以构建一个自定义模型来直接将文本分类到所需的类别，但这超出了本例的范围。相反，我们将使用 AWS 预构建的模型来提取支持请求中的实体、关键短语和情感。即使没有自定义模型，这些预构建模型的预测对客户支持代理仍然很有用。本例中使用的支持请求如下：

我写信请求帮助我的 iPhone 14，它的屏幕已经破裂。我的客户 ID 是 abcd@email.com。我非常感谢您帮助解决这个问题。我明白该设备可能由保修或保险计划覆盖，并且我想探索所有可用的维修或更换手机的选择。如果可能的话，您能否提供有关我应采取的下一步来启动维修或更换请求的信息？此外，请告知此过程中是否有任何费用。

Comprehend 目前每月每个 API 提供免费使用额度为 500 万字符。DX 资产提供的操作在 单 和 同步 模式下运行。

AWS 网页 API 使用专有算法来实现刷新令牌身份验证。一旦你导入了 DX 资产，你会注意到既有 Web API 服务又有对象。对象的主要目的是作为实现自定义身份验证的网页 API 的包装器。在本例中，我们将执行四个高级步骤：

1. 从 DX 下载资产

2. 将资产导入 BP

3. 配置 BP 凭证

4. 通过进行机器学习预测来测试 DX API 资产

从 DX 下载

在此步骤中，我们将访问 DX (digitalexchange.blueprism.com/dx/search) 以搜索和下载 AWS Comprehend 资产：

1. 访问 DX 并在搜索栏中输入 comprehend capability aws（大小写不敏感）。搜索并点击结果中的 Comprehend Capability AWS 云 资产。

2. 点击屏幕右侧的绿色下载按钮，并将 .bprelease 资产保存到您的计算机上。如果您尚未登录，DX 网站将要求您登录。此 .bprelease 包含一个网络 API、一个对象和一个凭证。

3. 在 Comprehend Capability AWS Cloud 连接器 页面上继续向下滚动并下载 AWS Comprehend 用户指南。

图 1.7 – 下载资产和 AWS Comprehend 用户指南

重要提示

AWS Comprehend 用户指南提供了如何设置您的 AWS 账户以允许从 BP 进行 API 调用的链接和详细信息。请按照用户指南中的步骤正确设置您的 AWS 账户和身份验证详细信息。我们不会在这里介绍设置 AWS 账户的步骤。

将 Comprehend 资产导入到 BP 中

让我们将下载的资产导入到 BP 中并检查导入的内容：

1. 打开 BP 并登录。点击 文件 | 导入 | 发布 / 技能。导入 AWS Comprehend 发布。导入时接受所有默认设置。

2. 验证 .bprelease 是否已成功导入到 BP 中。应该有一个对象、一个网络 API 服务和一个凭证。对象可以在 BP 的 工作室 部分找到。

图 1.8 – 在工作室部分找到对象

1. 在 系统 | 对象 | 网络 API 服务 下找到 Comprehend 网络 API。

图 1.9 – 在系统 | 对象 | 网络 API 服务下找到 AWS: Comprehend

1. 在 系统 | 安全 | 凭证 下找到凭证。

图 1.10 – 在系统 | 安全 | 凭证下找到 AWS 凭证

配置 AWS 凭证

在此步骤中，我们将导入 AWS 凭证（如果您还没有创建这些凭证，请查看下载的用户指南）到 BP 中。然后，我们将设置凭证的权限，以便我们可以在流程中测试它：

1. 将您的 AWS 访问密钥 ID 复制到 AWS 凭证中。将您的秘密访问密钥复制到两个 密码 字段中。

图 1.11 – 输入 AWS 访问密钥 ID 和秘密访问密钥

1. 在凭证的 访问权限 选项卡上，将 安全角色 设置为 所有角色，流程（旧版） 设置为 所有流程，资源（旧版） 设置为 所有资源。虽然这不是最佳实践，但我们只为测试目的这样做。

测试 AWS Comprehend 对象

最后，让我们测试 DX 资产并做出预测！注意在测试流程中，操作使用的是对象而不是 Web API 服务。直接使用 Web API 服务不会工作，因为它不包含身份验证部分。请按照以下步骤操作：

1. 在 Process Studio 的Ch1组中打开“示例 1 - 测试 AWS Comprehend”流程。此流程还需要导入“Utility – General”VBO。这可以在 BP 安装目录下的VBO子文件夹中找到。

2. 在 Process Studio 中运行流程。此流程执行三个 API 调用：1）检测实体，2）查找关键词，3）检测情感。如果成功，预测块中的“主页面”上的三个集合将被填充。

图 1.12 – 来自三个 API 调用的三个预测集合

查看“实体响应”集合显示 AWS 的通用模型可以提取电子邮件和电话型号：

图 1.13 – 将电话型号和客户 ID 提取为实体

即使没有自定义模型来将电子邮件分类到精确标签，Comprehend 的预训练模型也能提取高级信息，这可以简化客户支持代理的工作。我们还看到预测结果带有分数。这个置信度分数将作为本书第二部分 IA 解决方案的设计元素。

在本例中，我们使用了 AWS Comprehend 从非结构化文本中提取数据。由于 AWS 使用自定义身份验证方案，DX 资产包含一个 Web API 服务和一个对象。通常处理身份验证是复杂的，但对象为我们处理了一切。导入资产后，我们只需设置凭据即可使一切工作。这就是将 BP 与 AWS 的 Comprehend API 连接起来的简便方法。

让我们继续到下一个示例，该示例使用 Azure。

示例 2 – Azure 表单识别器用于发票提取

Azure 的表单识别器包含预构建的模型，允许您从收据、发票、税务表格、名片和通用文档中提取数据。以可用的格式从发票和收据中提取数据是一个非常常见的 IA 用例。如此常见，以至于 BP 和大多数其他 RPA 供应商都有专门针对发票提取的产品。有关 BP 文档提取产品 Decipher 的更多信息，请参阅本书最后一章。Form Recognizer 提供免费定价层以供测试。

本例中使用的发票可以在此处下载以供参考：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch1/ex2_invoice.pdf

这个 PDF 直接嵌入到本例的流程中作为二进制数据项，因此下载它是可选的。

你也可以在表单识别器内部构建自定义模型来识别你特定的文档类型，例如银行或信用卡对账单。这些自定义模型可以为你的业务解锁更多用例，并且可以通过本例中使用的 DX 资产由 BP 调用。

除了 API 的目的之外，这个 Azure API 与 AWS Comprehend 有两个主要区别。第一个区别是使用的认证方案。对于 Azure，我们只需要在每个请求中传递一个订阅密钥。这比 AWS 简单，AWS 需要单独的对象来刷新临时访问令牌。与 AWS Comprehend 不同，表单识别器的调用是异步的，需要你反复检查预测是否完成。

表单识别器的 DX 资产存储为.bprelease文件，包含一个 BP 对象。这与 DX 上大多数其他打包为.bpskill文件并在 BP 的系统 | 对象 | Web API 服务部分显示的 Web API 不同。

表单识别器被选为示例之一，因为表单处理也是主要的人工智能应用案例之一。表单识别器的 DX 资产还展示了实现 Web API 连接器的一种不同方式——直接作为对象使用 HTTP 和 JSON VBO，而不是 Web API 服务。作为对象实现允许运行旧版本 BP（< V6.4）的公司调用 Web API。

在本例中，我们将执行四个高级步骤：

1. 从 GitHub（或 DX）下载资产

2. 将资产导入 BP

3. 配置表单识别器对象

4. 通过进行预测来测试 API 调用

从 DX 下载

重要提示

微软自 DX 上的表单识别器资产发布以来已经更改了 URL 端点。因此，DX 上的资产如果不更改其中的 URL 将无法工作。已经修改的版本可以在github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch1/Ex_2_Azure_Form_Recognizer_Client_Service.bprelease找到。我建议下载这个 GitHub 版本，而不是 DX 上的版本。

虽然我们不会从 DX 下载资产，但我们仍然需要下载文档，以便配置 Azure API。在这里，我们将访问 DX (digitalexchange.blueprism.com/dx/search)以下载文档：

1. 在 DX 搜索栏中输入form recognizer client（大小写不敏感）进行搜索。点击表单识别器 客户端资产。

2. 在表单识别器客户端连接器 – 1.0.0页面向下滚动并下载用户指南。

图 1.14 – 下载资产和用户指南

重要提示

用户指南提供了如何设置 Azure 账户以允许从 BP 进行 API 调用的详细信息。请按照指南中的步骤正确设置 Azure。指南还列出了两个必须导入到 BP 中的其他 VBO：Utility - JSON 和 Utility – HTTP VBO。这两个都包含在之前的 GitHub 链接中。如果您希望单独下载它们，它们也可以从 DX 获取。

导入到 BP

下载资产后，必须将其导入到 BP 中。这一步骤无论您是从 DX 还是 GitHub 下载资产都是相同的：

1. 打开 BP 并登录。点击 文件 | 导入 | 发布 / 技能 并导入资产。

2. 验证 表单识别客户端服务 对象是否存在。还要验证 HTTP 和 JSON VBO 的正确版本是否存在，这是用户指南所要求的。

图 1.15 – 验证三个对象是否存在

配置表单识别客户端服务对象

DX 资产的作者选择将身份验证 ID 作为对象中的数据项存储。这 不是最佳实践，因为这些应该作为凭据存储。但由于对象就是这样设计的，让我们编辑这些数据项以配置连接到 Web API 所需要的身份验证详细信息。如果您没有订阅密钥，请按照资产文档创建一个。

重要提示

配置对象所需的访问令牌和基础 URL 可以从 Azure 网站的 表单识别 页面获取。图 1.15 中显示的用户指南提供了更多关于如何找到此页面的详细信息。

1. 在对象工作室中打开 表单识别客户端服务 对象。在 访问令牌 集合和需要填写的数据项 基础 URL 上。

图 1.16 – 在初始化页面填写访问令牌和基础 URL

1. 打开 访问令牌 集合并点击 初始值 选项卡。在 Ocp-Apim-Subscription-Key 字段中填写您的订阅密钥并保存。

图 1.17 – 将订阅密钥填写到访问令牌中

1. 打开 基础 URL 数据项并将 初始值 设置为 Azure 网站上的端点 URL。不要在 URL 末尾包含尾部斜杠。

图 1.18 – 在没有尾部斜杠的情况下填写基础 URL

现在我们已经配置了 Azure 对象，我们可以对其进行测试。

测试表单识别客户端服务对象

在章节开头“技术要求”部分导入的发布文件中包含了一个测试流程。此流程需要导入 Utility – General 和 Utility – File Management。这两个都可以在安装文件夹的 VBO 子文件夹中找到。

1. 在 Process Studio 的 Ch1 组中打开 示例 2 – 测试 Azure 表单识别器客户端服务 流程。

2. 在 Process Studio 中运行流程。此流程至少进行两次 API 调用。第一次调用将发票文件发送到请求处理。这会返回一个 结果 ID。第二次 API 调用通过引用 结果 ID 检查最多六次是否完成了 异步 机器学习预测。当预测完成时，预测 块中的集合和数据项将变得充实。您可以验证提取的内容与实际的 PDF 文档非常接近。

图 1.19 – Azure 发票表单识别器的预测结果

现在我们已经看到了两个示例，涉及两种不同类型的 Web API 身份验证，以及同步和异步 API 调用案例。在本章的最后一个示例中，我们将从头开始创建一个用于 GCP 批量 PDF 处理的 Web API 服务。

示例 3 – GCP 云视觉批量 OCR 处理

Google Cloud 的 Cloud Vision 允许您从图像中提取标签和文本。在 IA 中，这最常用于基于图像文本的 OCR，例如文档和收据的照片。如果文档被扫描，GCP 建议使用其 Document AI 服务。在本例中，我们将从带有少量手写的基于图像的 PDF 中提取文本。我们还将展示一个同步批量案例，其中一次处理基于图像文档的五页 PDF，并收到这五页的预测结果。

本例中使用的开源 PDF 文档可以在 github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch1/ex3_pdf.pdf 找到。此 PDF 已经作为二进制数据项嵌入到测试流程中，因此下载它是可选的。

GCP 使用 OAuth2 进行身份验证，这同样是一种临时访问令牌方法，类似于 AWS Comprehend 在第一个示例中所做的那样。OAuth2 和 AWS 方法之间的区别在于 AWS 的身份验证是专有的。OAuth2 是许多厂商采用的开放标准，BP 的 Web API 服务功能可以直接处理它。与 AWS Comprehend 的情况不同，不需要对象包装器。

在这个第三个示例中，我们将从头开始构建一个 Web API。我们将使用的 API 端点没有 DX 资产。从头开始构建 Web API 所需的关键技能是能够仔细阅读和理解供应商的 API 文档。GCP 的 API 文档的相关部分将与 BP Web API 服务的配置并排显示，以供参考。

与前两个示例相比，本例的步骤非常不同。从高层次上讲，我们将执行以下四个步骤：

1. 访问 GCP 网站以设置 API 认证所需的密钥

2. 将 API 认证密钥保存到凭证中

3. 在 BP 中创建 Web API 服务

4. 通过进行预测来测试 Web API

设置服务帐户和密钥

本节包含在 GCP 网站上执行的操作步骤。目的是生成可以下载并在 BP Web API 服务内部使用的认证凭证。如果这些步骤过时了，请使用步骤 1中的链接作为参考：

1. 访问cloud.google.com/iam/docs/service-accounts-create#creating_a_service_account并按照说明创建您的服务帐户。确保您的服务帐户有权访问Vision API。

2. 在IAM & Admin的服务帐户部分下，点击密钥选项卡，然后点击添加密钥：

图 1.20 – 为您的服务帐户创建密钥

1. 选择JSON作为密钥类型并按创建：

图 1.21 – 创建 JSON 密钥

1. 在按创建后下载出现的 JSON 文件。

将服务帐户电子邮件和私钥保存为凭证

我们已创建认证凭证并以 JSON 格式下载。现在我们需要将相关信息保存到 BP 凭证中：

1. 在任何文本编辑器中打开 JSON 文件。您会看到一个private_key行。将两个双引号之间的所有内容复制到您的剪贴板。这在 GCP 文档中被称为客户端密钥。

   "type": "service_account",
   "project_id": "project_id_here",
   "private_key_id": "abcdefg",
   "private_key": "-----BEGIN PRIVATE KEY-----\n
   PRIVATE KEY HERE
   \n-----END PRIVATE KEY-----\n",
   

2. 在 BP 中访问系统 | 安全 | 凭证。点击新建以创建新的凭证。

3. 设置GCP Cloud Vision。将类型设置为OAuth 2.0 (JWT Bearer Token)。将发行者设置为服务帐户电子邮件地址，对于私钥，粘贴在步骤 1中复制的部分：

图 1.22 – 使用 GCP 门户信息保存凭证

1. 点击凭据的访问权限选项卡。将安全角色设置为所有角色，进程（旧版）设置为所有进程，资源（旧版）设置为所有资源。虽然这不是最佳实践，但我们只是在测试，并没有将任何东西部署到生产环境中。保存凭据。

创建 Web API 服务

在这里，我们将从头开始创建一个 Web API 服务。在这次练习中，将频繁查阅 Google 的 API 文档（cloud.google.com/vision/docs/file-small-batch）。

在从头开始构建一个 Web API 时，一个需要考虑的关键提示是查看供应商是否已经在 DX 上提供了一种不同的服务。如果是这样，请下载它，导入它，并将其用作参考。每个供应商都试图保持其 API 的内部一致性。在一个供应商内部，它们的 API 可能使用相同的认证方法，并且它们的输入和输出具有相似的 JSON 结构。你很可能会将一个工作的 Web API 服务的一部分复制到自己的 API 中！

1. 访问系统|对象|Web API 服务。点击添加服务。

2. 设置Google Cloud Vision Batch Annotation Online。这是一个任意名称，它将作为一个可选择的选项出现在动作阶段。将基本 URL设置为vision.googleapis.com/，包括尾随斜杠。在这个步骤结束时，你的 Web API 应该看起来像这样：

图 1.23 – 设置名称和基本 URL

基本 URL 取自 GCP 的文档：

图 1.24 – GCP 文档中的基本 URL

1. 点击Content-Type和application/json; charset=utf-8。公共头信息部分应该看起来像这样：

图 1.25 – 设置公共头信息

这些公共头信息来自 GCP 文档中显示的示例 API 请求：

图 1.26 – GCP 文档中的头信息（其他头信息可以忽略）

1. 点击GCP Cloud Vision，这是在步骤 2中保存服务账户电子邮件和私钥作为凭据部分创建的。取消选中暴露给****进程框。

重要提示

令牌端点数据来自accounts.google.com/.well-known/openid-configuration，作用域端点来自developers.google.com/oauthplayground。

公共认证部分应该看起来像这样：

图 1.27 – 设置公共认证

1. 点击 Annotate Batch。这是将在 BP 中作为可选项目出现的操作名称。每个操作相当于一个 Web API 端点。完成此步骤后，您的 操作 部分应如下所示：

图 1.28 – 创建操作

1. 点击 mimeType、pages 和 content。将 初始值 留空，并为所有三个选项勾选 暴露。完成此步骤后，您的 参数 部分应如下所示：

图 1.29 – 设置操作参数

这三个参数是从 GCP 请求 JSON 主体中期望接收的示例中提取的。我们将这些作为 Web API 的输入参数公开，以便它们可以根据流程的需求传递和更改。

图 1.30 – GCP 文档的参数

1. 点击 /v1/files:annotate，将 Body Content 转换为 模板。在 模板 文本框中，输入以下内容：

   {
     "requests": [[
       {
         "inputConfig": {
           "content": "[content]",
           "mimeType": "[mimeType]"
         },
         "features": [[
           {
             "type": "DOCUMENT_TEXT_DETECTION"
           },
           {
             "type": "LABEL_DETECTION"
           }
         ],
         "pages": [[
           [pages]
         ]
       }
     ]
   }
   

   注意，我们使用 [parameter name] 将参数插入到模板中，类似于 BP 数据项。在 [ 的一些区域。这就是我们如何转义开方括号字符的方法。我们还 硬编码 提取类型为 DOCUMENT_TEXT_DETECTION 和 LABEL_DETECTION。

   本节所做的操作是设置将发送到 API 端点的确切 JSON 结构。我们希望这个结构与 图 1.30 完全匹配。完成此步骤后，请求 部分应如下所示：

![图 1.31 – 设置请求图 1.31 – 设置请求 1. 点击 responses、$.responses。这部分定义了 Web API 将作为输出参数发送给操作的什么内容。在我们的例子中，我们只是将整个 JSON 响应保存为一个集合。完成此步骤后，您的 响应 配置应如下所示：

图 1.32 – 设置响应

1. 我们的单个输出 responses 集合相当于 GCP 文档样本响应输出中突出显示的项目：

图 1.33 – GCP 文档的响应

1. 保存 Web API 服务。

现在我们已经完成了新 Web API 的设置。让我们用一个流程来测试它。

测试批处理图像 Web API 服务

样本流程应已从 技术要求 部分导入。我们还需要导入一个额外的 VBO 来将我们的 PDF 文件转换为 Base64 格式，这是 GCP 视觉 API 的要求：

1. 从 DX 中下载并导入Utility – File Manipulation资产，链接为digitalexchange.blueprism.com/dx/entry/9648/solution/utility---file-manipulation。这个工具用于将 PDF 文件转换为 Base64 格式。

2. 在流程工作室的Ch1组中打开Example 3 – Test GCP Batch PDF流程。

3. 在流程工作室中运行流程。此流程进行一次 API 调用，批量处理五个 PDF 页面。该调用是同步的，因为五个页面的预测在同一个请求中返回。一旦成功，预测块中的集合和数据项将变得完整：

图 1.34 – 新创建的 Web API 的预测

在这个第三个示例中，我们查看了一个从文档中提取文本的批处理/同步处理案例。我们还从头开始构建了一个使用 OAuth2 认证的 Web API 服务。这是一个将现有 API 信息输入 BP 的 Web API 服务正确部分的练习。在示例流程中，我们还使用了 Base64 对 PDF 文件进行编码，以便在 API 请求体中以纯文本形式发送。

摘要

在本章中，我们讨论了 DX 以及如何下载 Web API 连接器以极大地加快我们的开发时间。当使用 Web API 时，人们经常遇到的问题包括认证以及根据供应商的 API 文档正确映射输入和输出 JSON 数据。

ML web API 在两个影响 IA 解决方案设计的领域也有所不同。这些是单次与批量以及同步与异步预测。我们将在本书的后面重新讨论这些特性。

接下来，我们考察了四个主要的 MLaaS 供应商：AWS、Azure、GCP 和 IBM。我们探讨了他们在 DX 上提供的 ML web API。每个供应商都为其服务使用营销名称，掩盖了这些服务实际上做什么。我已经将营销名称背后的服务进行了分组和总结，提供了你可以在 DX 上搜索它们的搜索词，并给出了它们可以满足的用例的想法。

最后，我们通过三个实际操作示例进行了学习。我们选择了不同的供应商、API 实现方法、认证方法和用例，以覆盖你将在现实生活中遇到的大部分场景。在我的研究过程中，我发现的大多数实际生活中的 IA 示例都与文本处理有关。我们的示例展示了三种不同的 IA 文本案例：从非结构化文本中提取数据、从表格中提取数据以及从图像中提取文本。

在下一章中，我们将不再从 Web API 调用 ML 预测，而是更多地探讨 BP 如何直接从 Digital Worker 的命令行界面调用模型。

第二章：从命令提示符和 PowerShell 进行预测

Web API 是与机器学习服务通信的最常见方式。然而，有许多原因可能无法使用外部 Web API。例如，合规性和监管要求可能阻止你将数据发送到公司外部，或者可能没有适合你用例的机器学习服务。即使是内部开发的机器学习模型，也有不使用 Web API 作为通信方式的原因。一个例子是直接在 Digital Worker API 上运行模型，因为这不需要额外的 Web 服务器基础设施。

本章向您展示了如何通过BP以不同的方式在本地运行机器学习模型。我们将通过使用Windows 命令提示符（WCP）和PowerShell（PS）的示例来展示如何做到这一点。

在我对IA的研究过程中，我试图发现正在使用的底层技术、库和机器学习算法。Python是唯一在生产环境中使用的编程语言（除了在RPA中使用的内置 C#和 VB.NET），尽管 R 和 Julia 是学校中用来教授机器学习的流行语言。在本章的最终示例中，我们将在 BP 中调用一个 Python 脚本。

在本章中，我们将涵盖以下主要主题：

• 命令行基础

• 使用Object Utility - Environment从命令行进行预测

• 将预测结果返回到 BP

• 长时间预测超时

• DX VBOs – Utility PowerShell和Script Execution VBO

技术要求

在我们开始之前，请确保满足以下要求：

• 从 DX 下载并导入Utility - Powershell资产：digitalexchange.blueprism.com/dx/entry/9648/solution/utility---powershell

• 从 DX 下载并导入Script Execution VBO资产：digitalexchange.blueprism.com/dx/entry/3439/solution/blue-prism---script-execution-vbo-2

• 安装 Python 3+：www.python.org/downloads

• 从 GitHub 下载并导入本章的示例，这些示例包含在一个单独的版本中：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/tree/main/ch2

命令行基础

当在 Digital Worker 机器上进行预测时，你需要调用命令行，除非你能够通过Code Stage（下一章的主题）或通过图形界面以编程方式与之交互。BP 能够通过 WCP 和 PS 启动独立程序或脚本。

可以通过运行命令提示符应用程序或从 Windows开始菜单中的cmd.exe来启动 WCP。它可以以当前登录到 Windows 的用户身份启动，也可以以管理员用户身份启动，通过右键单击命令提示符并选择以管理员身份运行。

可以通过运行 PS 应用程序或从 Windows 的pwsh.exe来启动 PS，或powershell.exe/pwsh.exe。pwsh.exe是 PS Core 的可执行文件，它是 PS 的新版本，是一个跨平台版本（v6 及以上），必须手动安装，因为它默认情况下并未安装在 Windows 上。powershell.exe是旧版本（v5.1 及以下），它是预安装在 Windows 上的。

对于 IA 目的，没有强有力的论据来选择 WCP 而不是 PS，或者反过来。WCP 总体上更简单，功能更少，而 PS 更复杂，功能更全面。然而，这些细节是命令行脚本内部的，这些脚本可能会由 ML 解决方案的开发者提供。BP 可以主要将这些脚本视为黑盒。

当本地预测时，你可能会需要通过一个独立的可执行文件、批处理脚本、PS 脚本或直接运行源代码（通常是 Python）来部署 ML 模型。

接下来，让我们看看三个对于将命令行程序连接到 BP 非常重要的概念。这些是输出流、输出重定向和阻塞执行。

输出流

从 WCP 和 PS 中执行的程序可以将文本输出到两个不同的流。第一个流被称为STDERR，它被使用取决于脚本的作者。有时，开发者会决定将错误消息打印到STDOUT而不是使用STDERR。

重要提示

PS 有更多的输出流可用，例如警告和调试消息，但 STDOUT 和 STDERR 是最常用的。

例如，让我们打开cmd.exe并输入以下内容（不包含>字符）：

> echo "Hello Blue Prism"

我们将通过 STDOUT 在屏幕上看到"Hello Blue Prism"被打印出来：

图 2.1 – 命令行窗口中显示的输出是 STDOUT

让我们尝试一个我们知道会生成错误的命令。让我们打印一个不存在文件的目录内容：

> type "C:\Users\Public\non existent file.txt"

这会显示“系统找不到指定的文件。”错误消息：

图 2.2 – 这条消息是 STDOUT 还是 STDERR？

显示文本的目的是为了展示一个错误，但它是否被写入到 STDOUT 流或 STDERR 流？仅凭窗口中显示的打印文字，我们无法判断，但我们可以通过将 STDOUT 和 STDERR 重定向到文件来找出这一点。

输出重定向

STDOUT 和 STDERR 都可以相互重定向，并且可以将它们写入文件。这是将命令行输出捕获到 BP 的主要方法之一。这部分是通过使用重定向，即 WCP 和 PS 中的“大于”字符（>）来实现的。在 BP 中，你最常见的使用方式是将 STDOUT 重定向到文件，以便可以使用文件管理VBO 来读取。

重要提示

>字符用于重定向并覆盖任何之前的内容，而>>重定向则用于追加内容。由于追加内容需要更多的开发逻辑来区分之前和当前的内容，因此我们更频繁地使用>来将 STDOUT 和 STDERR 重定向到 BP。

让我们将之前命令中的一个 STDOUT 重定向到文件，并在cmd.exe中打印该文件的目录内容：

> echo "Hello Blue Prism" > "C:\Users\Public\ch 2 echo.txt"
> type "C:\Users\Public\ch 2 echo.txt"

第一个命令不再将"Hello Blue Prism"打印到控制台窗口。输出被重定向到了一个文件。只有在第二个命令执行后，文本才会被打印出来，而这个命令没有进行任何重定向：

图 2.3 – 将 STDOUT 重定向到文件

让我们再次尝试打印不存在文件的目录内容，但这次我们将 STDOUT 重定向到文件。然后，我们将打印重定向文件的输出：

> type "C:\Users\Public\non existent file.txt" > "C:\Users\Public\ch 2 redirect.txt"
> type "C:\Users\Public\ch 2 redirect.txt"

你会看到错误文本被打印到屏幕上，这与我们之前的例子不同。为什么没有重定向？这是因为“系统找不到指定的文件。”消息不是来自 STDOUT，所以重定向 STDOUT 没有效果：

图 2.4 – 重定向 STDOUT 未捕获消息

由于消息不是 STDOUT，我们可以合理地猜测它是 STDERR。STDERR 可以使用2>而不是>（这是用于 STDOUT 的）进行重定向。让我们尝试重定向 STDERR：

> type "C:\Users\Public\non existent file.txt" 2> "C:\Users\Public\ch 2 redirect stderr.txt"
> type "C:\Users\Public\ch 2 redirect stderr.txt"

我们现在看到第一个命令没有在屏幕上打印任何内容，而第二个命令则打印了内容。这证实了“系统找不到指定的文件。”消息被写入 STDERR 而不是 STDOUT：

图 2.5 – 重定向 STDERR 捕获消息

到目前为止，我们只看到了重定向 STDOUT 或 STDERR 流中的一个示例，但没有同时重定向两个流。有两种方法可以同时重定向两个流。第一种选择是将 STDOUT 和 STDERR 合并到一个流中，并将该单个流重定向到单个文件。第二种选择是将两个流重定向到单独的文件。

让我们看看如何使用 PS 而不是 WCP 来完成这两件事。幸运的是，我们之前看到的所有重定向命令在 WCP 和 PS 之间都是可互换的。使用 PS 还有一个小的优点，就是将 STDERR 消息的字体改为红色，以便立即识别。打开powershell.exe并输入以下命令：

> &{echo "Blue Prism";Write-Error "IA"}

这实际上是两个由分号分隔的命令。第一个echo命令写入 STDOUT，而第二个Write-Error命令写入 STDERR。周围的&{…}字符表示在 PS 中将其作为单个脚本块执行。

运行此命令会产生以下输出。我们在 PS 控制台屏幕上看到 STDOUT 消息Blue Prism和 STDERR 消息（红色）：

图 2.6 – 红色文本是 STDERR，而正常颜色的文本是 STDOUT

接下来，让我们将 STDERR 合并到 STDOUT 流中，将其重定向到单个文件，并打印该文件的内容：

> &{echo "Blue Prism";Write-Error "IA"} > "C:\Users\Public\ch2 redirect both.txt" 2>&1
> type "C:\Users\Public\ch2 redirect both.txt"

在第一个>实例之后，我们指定 STDOUT 应该重定向到的文件路径。2>&1表示我们想要将 STDERR 重定向到 STDOUT 流。在打印文件时，我们可以看到 STDOUT 和 STDERR 消息都存在：

图 2.7 – 将 STDOUT 和 STDERR 重定向到单个文件

接下来，让我们将标准错误输出（STDERR）和标准输出（STDOUT）重定向到单独的文件。

> &{echo "Blue Prism";Write-Error "IA"} > "C:\Users\Public\ch2 redirect stdout2.txt" 2> "C:\Users\Public\ch2 redirect stderr2.txt"
> type "C:\Users\Public\ch2 redirect stdout2.txt"
> type "C:\Users\Public\ch2 redirect stderr2.txt"

再次，>让我们指定我们想要 STDOUT 重定向到的路径。在2>之后是我们想要 STDERR 重定向到的位置。当文件被打印出来时，只会显示它们对应流的内容：

图 2.8 – 将 STDOUT 和 STDERR 重定向到不同的文件

在选择将流合并并重定向到单个文件与将 STDOUT 和 STDERR 重定向到单独文件之间，后者更合理。这允许我们将错误消息与非错误消息隔离开来。这也是我们为什么更喜欢覆盖之前的输出（>）而不是追加（>>）的原因。追加需要我们添加更多逻辑，以将最新运行的命令的输出与之前的输出分开。

我们现在已经介绍了将命令行输出重定向到文件的不同方法。这使得我们能够轻松地将基于命令行的机器学习（ML）程序的输出接收进 BP。接下来，让我们看看本节命令行基础的最后一个主题，即阻塞与非阻塞执行。

阻塞与非阻塞执行

当 BP 启动一个命令行程序时，BP 中的执行可以是阻塞或非阻塞。如果执行被阻塞，BP 将在程序退出之前等待，然后继续到下一个阶段：

图 2.9 – BP 等待阻塞程序完成

如果脚本不阻塞，它将在 BP 进展的同时在后台继续运行。除非脚本可以显式等待并检查外部条件，例如磁盘上写入的文件的存在，否则 BP 将不知道脚本何时实际完成：

图 2.10 – BP 在非阻塞程序执行时继续运行

作为 BP 开发者，决定你希望触发的程序以阻塞或非阻塞方式运行至关重要。在几乎所有情况下，我们更喜欢 BP 等待脚本完成，即使非阻塞脚本正在运行。这使得过程开发和调试变得更加简单。本章后面将讨论实现这一点的不同方法。

阻塞与非阻塞 的概念类似于我们在讨论 Web API 时提到的 同步与异步。Web API 调用有一个内置的超时概念。如果一个 API 请求在 BP 中运行时间过长，它最终会被终止，并抛出一个异常。同样，我们还需要考虑如果从命令行触发的程序运行时间过长，我们应该如何超时。我们将在本章后面看到如何实现这个功能的示例。

在本节中，我们探讨了与 BP 相关的命令行基础知识。首先是输出流的概念。STDOUT 用于向控制台屏幕显示常规输出，而 STDERR 用于显示错误消息。接下来，我们讨论了如何使用 > 重定向运算符在 WCP 和 PS 中将这两个流重定向到文件中。重定向使我们能够在 BP 中捕获命令行程序输出。

然后，我们探讨了阻塞与非阻塞脚本之间的区别，并指出我们更喜欢暂停 BP 执行直到脚本完成，这是出于可预测性的原因。最后，我们介绍了超时的概念，以停止命令行进程运行时间过长。

在下一节中，我们将通过示例回答以下问题：

1. 我应该使用哪个 VBO 和操作来触发预测？

2. 我如何将预测结果返回到 BP？

3. 我如何停止运行时间过长的脚本？

使用 Utility – Environment 从命令行进行预测

在 BP 安装子文件夹中的 VBO 子文件夹中找到的 Utility - Environment VBO 有三个可以用来启动命令行脚本和外部程序的操作：启动进程、启动进程读取 Stderr 和 Stdout 和 运行进程 直到结束。

无论你使用哪个操作，你都必须在 BP 中至少填写两个不同的输入参数。一个输入参数指定你想要运行的 程序，另一个输入参数指定 该程序的附加参数。

让我们看看使用 Start Process 和 Run Process Until Ended 操作运行简单批处理脚本的两种不同方法。

示例 1 – 使用 Start Process 运行程序

让我们运行一个从 BP 接收两个参数作为参数的批处理文件。为了简化示例设置，批处理文件内容在流程开始时保存在磁盘上。这个批处理文件本身负责将两个输入参数写入输出文件，C:\Users\Public\ch2_ex1_output.txt，这样我们就不需要进行任何重定向。流程结束时，我们删除创建的批处理文件。按照以下步骤操作：

1. 在流程工作室中打开Ch2组。

2. 在橙色块中打开Utility Environment::Start Process操作。注意我们提供批处理文件的路径作为应用程序输入参数，以及两个通过空格分隔的数据项作为参数值：

图 2.11 – 将脚本路径作为应用程序，并将两个参数通过空格分隔作为参数

1. 通过按下Go按钮或F5来运行示例一次。

2. 通过验证输出文本文件的内容，C:\Users\Public\ch2_ex1_output.txt来验证批处理脚本是否正确运行。它应包含文本1234和5：

图 2.12 – 预期的输出文件

我们已经完成了运行批处理文件并检索其输出的最基本示例。由于批处理文件本身将数据写入文件，我们不需要自己进行任何重定向。注意，我们的流程图中有一个睡眠 1 秒操作。这是必需的，因为Utility - Environment

::Start Process操作是非阻塞的。如果没有睡眠操作，批处理文件可能在完成执行之前就被删除了！

示例 2 - 使用运行进程直到结束运行程序

现在，让我们修改之前的示例，以去除可能不可靠的 1 秒睡眠，并使脚本阻塞。这次，我们的输出文件将保存在C:\Users\Public\ch2_ex2_output.txt：

1. 在流程工作室中打开示例 2 – 使用运行进程直到结束运行程序 BP 流程。

2. 在橙色块中打开Utility - Environment::Run Process Until Ended操作。注意参数和应用程序输入与示例 1相同。不同之处在于操作已从Start Process更改为Run Process Until Ended。此外，请注意超时输入为空。当为空时，默认为 10 秒：

图 2.13 – 此操作配置与示例 1 相同

1. 验证流程图中已移除睡眠阶段。

2. 通过按下Go按钮或 F5 来运行示例一次。

3. 验证脚本是否正确运行，请打开 Windows 文件资源管理器，查看 C:\Users\Public\ch2_ex2_output.txt 文件是否包含文本 abcd 和 e。

我们将动作从 示例 1 中的 启动进程 更改为 示例 2 中的 运行进程直到结束。在 示例 1 中使用 启动进程，BP 以非阻塞方式执行进程步骤和批处理脚本。在 示例 2 中使用 运行进程直到结束，BP 等待最多 10 秒脚本完成，然后继续执行进程步骤。尽管大多数时候更喜欢阻塞执行，但可能存在需要非阻塞执行的情况。

在 实用工具 - 环境 中还有一个我们尚未看到示例的动作：启动进程读取 Stderr 和 Stdout。正如其名称所暗示的，此动作允许我们直接捕获两个输出流，STDOUT 和 STDERR，作为 BP 中的数据项。接下来，我们将讨论从命令行脚本捕获输出到 BP 的不同方法。

将预测结果返回到 BP

从命令行启动的 ML 程序可能会以两种方式提供输出：要么是将预测输出打印到屏幕上，要么是将结果写入文件。当然，还有其他选项，例如将结果发送到单独的系统供您检索，但这些选项超出了本章的范围。表 2.1 列出了获取 ML 预测输出的最常见方式，以及您可以使用哪些对象/操作将其读取回 BP：

预测输出方法	输入方法到 BP	使用对象	操作
写入屏幕	使用直接读取屏幕输出的 VBO 动作	实用工具 – 环境	启动进程读取 Stderr 和 Stdout
实用工具 – PowerShell	运行脚本
脚本执行 VBO	执行脚本
写入屏幕	重定向到文件并读取文件	实用工具 - 环境	启动进程
实用工具 - 环境	运行进程直到结束
写入文件	读取文件	实用工具 – 环境	启动进程
实用工具 - 环境	运行进程直到结束

表 2.1 – 将预测输出读取回 BP 的不同方式

如果预测结果打印到控制台屏幕，有两种方法可以将结果返回到 BP。第一种，也是最简单的方法是使用 VBO 操作直接捕获输出作为 BP 中的数据项。第二种方法是将打印的输出重定向到一个文件，然后读取该文件到 BP 中。让我们看看第一种情况的一个例子。

示例 3 – 将 STDOUT 和 STDERR 保存为数据项

在这个例子中，我们将从头开始构建一个进程，该进程使用来自实用工具 - 环境 VBO 的启动进程读取标准错误和标准输出动作。此动作允许我们直接将标准错误和标准输出保存为数据项。本章节的发布中提供了此示例的完整版本供您参考。

此示例还展示了从 BP 运行命令提示符的内部命令所需的特殊语法，以防您将来需要这样做。请按照以下步骤操作：

1. 在Ch2组中创建一个名为示例 3的新进程。在 Process Studio 中打开它。

2. 在图中添加一个动作阶段。选择实用工具 - 环境作为业务对象，并将启动进程读取标准错误和标准输出作为动作。

3. 设置"cmd.exe"（包括双引号）和"/c dir"。dir命令列出了 BP 安装文件夹内的所有文件和目录。BP 安装文件夹是我们从 Process Studio 内部启动cmd.exe命令提示符的位置。/c表示在dir命令执行完毕后终止cmd.exe。

重要提示

为了从 WCP 使用dir、echo、copy等内部命令，我们需要将cmd.exe作为进程名称，而我们要在 WCP 中运行的命令作为参数。

1. 点击动作的标准输出和标准错误数据项。

2. 在开始和结束阶段之间链接动作。完成的进程应如下所示：

图 2.14 – 示例 3 的完成测试进程

1. 从 Process Studio 运行进程。标准输出数据项将包含内容，而标准错误数据项将保持为空。这是因为dir命令成功执行且无错误：

图 2.15 – 标准输出已填充

1. 修改动作的"/c dir *.xyz"。此更改意味着我们想要列出所有具有.xyz文件扩展名的文件，这些文件不应存在于 BP 安装文件夹中。

2. 再次运行测试进程。标准输出和标准错误数据项都应填充，因为有错误：

图 2.16 – 标准输出和标准错误都已填充

注意，在运行示例 3时，实际的控制台窗口没有弹出，但我们能够捕获打印到控制台屏幕上的数据。假设 ML 预测将输出打印到屏幕上，捕获这些数据的第二种方法是重定向 STDOUT 和 STDERR 流到 BP 可以读取的文件。让我们看看在下一个示例中如何做到这一点。

示例 4 – 将内部命令（dir）重定向到文件

我们已经在示例 2中使用了实用工具 - 环境 VBO 中的运行进程直到结束操作。这个操作不允许我们直接将 STDOUT 和 STDERR 捕获为数据项；然而，示例 2中的批处理脚本本身创建了一个可以读入 BP 的文件。

在本例中，我们将再次使用此对象和操作创建一个新的进程，除了批处理脚本将输出打印到 STDOUT 和 STDERR。我们需要将 STDOUT 和 STDERR 流重定向到文件，以便它们可以被读入 BP。本章节的发布中提供了此示例的完整版本，供您参考。请按照以下步骤操作：

1. 在Ch2组中创建一个名为示例 4的新进程。在流程工作室中打开它。

2. 创建两个具有Text数据类型的数据项。这些是我们重定向输出将保存的文件路径。按照以下设置：

数据项名称	初始值
Stdout File	C:\Users\Public\ch2_ex4_stdout.txt
Stderr File	C:\Users\Public\ch4_ex4_stderr.txt

表 2.2 – 配置两个数据项以保存我们的文件路径

1. 将一个操作阶段添加到图中。选择实用工具 - 环境作为业务对象，并选择"cmd.exe"（包括双引号）和"/c dir *.xyz > " & Chr(34) & [Stdout File] & Chr(34) & " 2>" & Chr(34) & [Stderr File] & Chr(34)。

   "/c dir *.xyz"尝试列出不存在的文件。下一部分> " & Chr(34) & [Stdout File] & Chr(34)将 STDOUT 重定向到我们定义的文件。正如你所知，>字符表示重定向。Chr(34)实例用于在文件路径周围放置双引号，以防有空格。最后一部分" 2>" & Chr(34) & [Stderr File] & Chr(34)将 STDERR 重定向到不同的文件。

2. 将操作阶段之间的动作链接起来。完成的流程应如下所示：

图 2.17 – 示例 4 的完成测试流程

1. 在流程工作室中运行进程。

2. 检查C:\Users\Public文件夹，并验证是否已从重定向创建了两个输出文件。

在本例中，我们将 WCP 内部命令dir的 STDOUT 和 STDERR 流重定向到两个单独的文件。由于该命令是内部的，我们必须将"cmd.exe"作为应用程序输入。为了执行重定向，我们只需在参数输入的末尾添加必要的重定向语法。要将实际输出放入 BP 中，我们需要读取创建的文件。

到目前为止，我们已经涵盖了实用工具 - 环境中允许我们从命令行启动外部程序的三个操作。我们看到了它们在阻塞和捕获输出方面的不同。以下表格对此进行了总结：

操作	是否阻塞？	输出保存方法	是否有超时功能？
启动进程	否	无。必须使用重定向并在 BP 中读取文件。	否
运行进程直到 结束	是	无。必须使用重定向并在 BP 中读取文件。	是
启动进程读取 Stderr 和 Stdout	是	输出以数据项的形式保存。	否

表 2.3 – 使用三个动作启动命令行程序的总结

表格的最后一列，是否存在超时功能？是下一节的主题。这指的是是否存在内置方法来停止外部程序运行时间过长。

超时长时间运行的预测

如果命令行脚本遇到问题，它可能会挂起并永久阻止 BP 流程。只有一个动作具有内置功能来超时运行时间过长的脚本：运行进程 直到结束。

重要提示

可以通过将其他脚本包装在脚本中并使用start、timeout和taskkill命令来向任何命令行脚本或程序添加超时功能。然而，与仅使用运行进程直到结束加上重定向相比，这些方法更为复杂。

示例 5 – PS 脚本超时

让我们看看一个更现实的机器学习例子。在这里，我们有一个 PS 脚本，它调用一个算法来预测客户是否会取消零售店的会员计划。输入从 BP 传递到 PS 脚本，然后到模拟的 ML 程序。模拟的 ML 程序为两个标签返回置信度分数：流失和不流失。

在这个例子中，我们有一个包含八个客户的集合，以及一些定义性的特征，例如年龄、职业类别、自上次交易以来的天数以及平均购买金额（美元）。我们的流程将遍历所有客户，调用 PS 脚本，并读取预测的流失标签的置信度分数。

本例的目标是检查并运行此 PS 脚本，并查看如果它运行时间过长我们如何超时。

1. 在Ch2组中打开示例 5 – PowerShell 脚本超时 BP 流程。我们将一起查看重要细节。

2. 打开powershell.exe。尝试将 PS 脚本路径放入应用程序输入实际上不会执行脚本，而是使用默认应用程序打开文件，这通常是记事本。参数输入应该对你来说很熟悉，因为它包含 PS 脚本参数和重定向文件路径。此外，请注意超时输入为空，这意味着脚本最多可以运行 10 秒。

3. 通过按播放以运行来运行示例一次。你会看到当脚本运行时 PS 窗口会弹出，之后会关闭。

4. 打开预测集合，查看它包含八个客户的置信度分数：

图 2.18 – 成功预测的置信度分数

1. 将MakeTimeSpan(0, 0, 0, 3)打开到Timeout输入。现在我们允许脚本运行的最大时间是 3 秒：

图 2.19 – 将 MakeTimeSpan(0, 0, 0, 3)添加到 Timeout 输入

1. 重置，然后再次运行示例。当 PS 窗口打开时，您应该在屏幕上看到异常显示，确认超时正在工作：

图 2.20 – PS 脚本已超时

运行进程直到结束是唯一一个具有阻塞和超时功能的操作。虽然它没有自动将 STDOUT 和 STDERR 读取到数据项中的能力，但我们可以通过重定向来解决这个问题。因此，运行进程直到结束是用于 IA 的首选操作，假设您不想自定义构建新的操作或使用第三方 VBO。

用于触发命令行进程的其他两个操作更为特定。如果启动的命令行程序具有内置的超时方法或它创建的任何底层进程，可以使用启动进程读取 Stderr 和 Stdout操作。

您可能还会遇到没有良好估计的适当超时值的情况。例如，如果您在批量预测，其中一些批次可能需要几秒钟，而其他批次可能需要几小时，那么使用非阻塞的启动进程操作并检查预测是否完成通过其他方法是有意义的。

重要提示

部署的机器学习模型并非一次性构建，永久运行。与所有软件一样，它们应该被更新和重新部署；例如，用更多的训练数据更新模型，以不同的方式调整模型参数，应用对所使用的库的安全修复，等等。由于机器学习模型可以独立于 BP 解决方案而改变，因此超时值也应该在进程或对象图中进行更改。我建议在真实解决方案中将超时值存储为环境变量。

现在我们已经介绍了内置的实用工具 - 环境 VBO 的三个操作，让我们看看其他两个可以用来启动命令行程序的 VBO。它们都可以在 DX 上下载。

DX VBOs – 实用工具 - PowerShell 和脚本执行 VBO

在 DX 上有两个显著的资产可用于调用命令行程序。它们提供了简化接口以触发程序，以及其他一些您可能希望选择它们的附加功能，例如，与实用工具 - 环境相比。

实用工具 – PowerShell

这个第一个 VBO 专门用于 PS，并包含两个动作，运行脚本 和 使用 PowerShell Core 运行脚本。PS Core 是 PS 的最新版本；然而，它并不完全与旧版本的 PS 兼容。旧版本的 PS 脚本可能在 PS Core 下无法正确运行。PS Core 也不是大多数 Windows 版本默认安装的。为了避免兼容性问题，我们将在下一个示例中使用 运行脚本 动作。

示例 6 – 通用 – PowerShell 运行脚本

让我们回顾一下 示例 5，在那里我们触发了一个 PS 脚本，它为我们提供了用户流失的预测。这次，我们将使用 DX VBO：

1. 在 Ch2 组中打开 示例 6 – 通用 PowerShell 运行脚本 BP 流程。此示例已经为您构建好了，但我们将一起查看重要细节。

2. 打开 parameter_name=parameter_value。多个参数应以逗号分隔。请注意，此动作直接将输出流保存为数据项，因此不需要重定向。

3. 在 Process Studio 中运行此示例一次。与在 示例 5 中运行 PS 脚本不同，你不会注意到任何 PS 窗口弹出！

4. 验证 Predictions 集合是否包含八个客户的 churn 和 no churn 的置信度分数。这些分数应与 图 2**.18 中的相同。

使用此 DX VBO 的 运行脚本 动作，你将获得不需要输出重定向且不会在 Utility - 环境 中的动作上看到弹出窗口的好处，这可能对您的用例很重要。然而，也没有内置的超时功能（尽管在 使用 PowerShell Core 运行脚本 中有）。如果您有能力安装 PS Core，我建议您这样做，这样您就可以使用具有超时功能的动作。

脚本执行 VBO

DX 上可用的第二个资源是 脚本执行 VBO。本版本包含两个对象。第一个，脚本执行 VBO，是用 C# 实现的，第二个，脚本执行 VBO Visual Basic，是用 VB 实现的。这两个对象在功能上没有区别，所以我们将使用 C# 版本在我们的下一个示例中。每个 VBO 只包含一个动作，执行脚本。

你可能想要使用此 VBO 的一个表面原因是你的 BP 动作输入将看起来更整洁。正如你所注意到的，添加重定向和完整文件路径，用双引号 Chr(34) 包围等，可以使动作的输入参数变得混乱且难以理解。此 VBO 通过为脚本引擎、脚本路径和脚本名称提供单独的输入参数来在一定程度上减少这种混乱。更实际的原因是，它使用期望的默认值启动外部程序，例如阻塞、不弹出命令窗口并将输出捕获到数据项中。然而，它缺少超时功能。

示例 7 – 调用一个 Python 程序

让我们称一个基于面积、卧室数量、浴室数量、先前售价和年龄（年）预测房屋售价的 Python 脚本。由于这是一个回归问题，Python 脚本返回一个数值预测，而不是标签和置信度分数。按照以下步骤操作：

1. 在Ch2组中打开示例 7 – 脚本执行 VBO 调用 Python 脚本 BP 过程。这个示例已经为您构建好了，但我们将一起查看重要细节。

2. 打开命令行，cmd.exe，并找到您的 Python 可执行文件位置。这可能被命名为py.exe或python.exe。在 WCP 中，输入以下内容（或者如果您找不到结果，将py.exe替换为python.exe）：

   Python Executable Full Path Data Item in the red block:
   

图 2.21 – 使 Python 可执行完整路径数据项与您的 Python 位置匹配

1. 在橙色块中打开Script Execution VBO::Execute Script Action，注意它看起来相对更干净，因为输入被分离，并且不需要重定向：

图 2.22 – 输入参数被很好地分隔

1. 在 Process Studio 中运行一次 Process。注意，Action blocks 并且不会弹出任何窗口。

2. 验证从 Python 预测的值是否已保存为数据项：

图 2.23 – 预测的房产价格

我们现在已经在本章中介绍了如何启动命令行程序的七个示例。每个示例都旨在展示以下方面的不同：

• 运行的脚本类型

• 哪个 VBO 和 Action 被使用

• 如何将输出读回到 BP 中

• Action 是否阻止或不阻止

• Action 是否允许超时

下一个表格总结了所有示例：

示例	脚本类型	调用 脚本 VBO/Action	读取 输出方法	阻塞？	超时？
1	.``bat	实用工具 - 环境/ 启动过程	脚本将输出写入文件	N	N
2	.``bat	实用工具 - 环境/ 运行过程直到结束	脚本将输出写入文件	Y	N (尽管留空参数意味着 10 秒)
3	内部命令（dir）	实用工具 - 环境/启动过程读取标准错误 和标准输出	VBO Action 将输出保存为数据项	Y	N
4	内部命令（dir）	实用工具 - 环境/运行过程直到结束	文件重定向	Y	N (尽管留空参数意味着 10 秒)
5	.``ps1	实用工具 - 环境/运行过程 直到结束	文件重定向	Y	Y
6	.``ps1	实用工具 - PowerShell/ 运行脚本	VBO Action 将输出保存为数据项	Y	N (尽管 PS Core Action 有超时)
7	.``py	脚本执行 VBO/执行脚本	VBO 动作将输出保存为数据项	是	否

表 2.4 – 所有示例差异的总结

摘要

你可能需要通过可执行文件、批处理脚本、PS 脚本或直接执行源代码将 BP 连接到 ML。本章介绍了在 BP 中通过命令行运行程序背后的三个重要概念。第一个是 输出流 的概念。STDOUT 用于在命令行窗口显示常规输出，而 STDERR 用于显示错误。第二个概念是 重定向，它允许我们将 STDOUT 和 STDERR 捕获到文件中，以便可以在 BP 中读取它们。第三个概念是 阻塞与非阻塞 执行。BP 将在继续进行进一步的自动化步骤之前等待阻塞程序完成。如果我们能够以阻塞方式触发外部程序运行，进程逻辑将更容易理解。

我们还介绍了三个 VBO：一个内置在 BP 中，两个来自 DX。内置的 VBO，实用工具 - 环境，有三个可用的动作，但运行进程直到结束 是首选的，因为它是唯一一个可以原生超时长时间运行的脚本的动作。其他两个动作有更专业的用途。启动进程 可以在不希望阻塞的情况下使用，而启动进程读取 Stderr 和 Stdout 可以在脚本知道如何超时的情况下使用。

实用工具 - PowerShell DX 资产可以专门用于 PS 脚本。它能够在不显示 PS 窗口的情况下执行脚本，并且 使用 PowerShell Core 运行脚本 动作也具有超时功能。脚本执行 VBO 更倾向于启动具有复杂可执行输入参数的程序，例如来自 Python 的那些。

在 第一章 和 第二章 中，我们介绍了如何通过 Web API 和命令行界面将 BP 连接到 ML。在下一章中，我们将探讨将 BP 连接到 ML 的第三种方式，即通过代码阶段。

第三章：代码阶段

虽然 Python 是用于 ML 的主导语言，但微软正在大力投资 AI，而不仅仅是通过其对 OpenAI 和 ChatGPT 的投资。微软正在通过开源的 ML.NET 框架积极扩展对 VB.NET 和 C# 中 ML 开发的支持。在本章中，我们将探讨如何通过 代码阶段 设置 BP 以使用 ML.NET。

在我的研究中，随机森林是 IA 中最常引用的算法家族，其次是深度学习和梯度提升。所有这些算法在 ML.NET 中都有实现。随机森林和梯度提升算法可以在数字工作者上实际使用以产生及时预测。由于计算和 GPU 要求，深度学习可能不是训练和预测数字工作者的良好候选者。

本章包含三个相互关联的示例。它们是根据现实生活中的场景构建的。想象一下，数据科学家使用 ML.NET 建立了一个 ML 模型（用于情感分析的二元分类）。该模型已经经过审查并被接受用于 IA 用例，IA 团队需要从现在开始负责模型维护和源代码。在我们的示例中，我们将介绍在 BP 中成功运行 ML 代码的步骤。

我们在本章中将涵盖以下主题：

• 在 BP 中设置 ML.NET

• 导入 C# 代码

• 提高 BP 集成

技术要求

下载并导入 GitHub 上 ch3 文件夹中的三个文件，网址为 github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/tree/main/ch3。请注意，其中两个文件具有 .bpobject 文件扩展名，它们需要作为 Process / Object 导入。示例中还将执行其他设置步骤。

在 BP 中设置 ML.NET

ML.NET 可以在 BP 代码阶段原生使用。虽然你在 BP 中可以选择 C# 或 VB.NET，但互联网上的几乎所有文档都是用 C# 编写的。本章中的示例也将使用 C#。

开发者在尝试使用 ML.NET 时可能面临的最大挑战之一是导入项目中的所有 .dll 文件及其 .dll 依赖项。不幸的是，BP 没有这样的功能。在 BP 中，获取程序集导入和命名空间的工作主要是通过试错和检查文档来完成的。我们迭代地添加新的 .dll 文件或命名空间，并检查 BP 中显示的错误是否有变化。

由于只有业务对象（而不是流程）可以有代码阶段，因此本章的内容仅适用于对象。

在 BP 中添加引用和命名空间

添加 .dll 文件和命名空间的区域位于 代码选项 选项卡中的对象的属性中。要访问对象的属性，请访问 初始化 页面。默认情况下，在 开始 阶段左侧有一个包含对象名称、创建日期和最后更改日期的矩形。右键单击此矩形并选择 属性。

图 3.1 – 从初始化页面访问对象的属性

打开对象属性的另一种方法是双击白色矩形。当 属性 窗口打开时，您将看到一个 代码选项 选项卡。代码选项 选项卡是添加外部程序集和命名空间的地方。也可以在此处选择代码语言（C#、Visual Basic 或 Visual J#）。

图 3.2 – 对象属性的 代码选项 选项卡

虽然 图 3.2 显示了 .dll 文件，但您也可以通过提供完整路径来指定它们。如果您看不到 .dll 的完整路径，这意味着该程序集存储在 BP 安装文件夹中或 Windows 路径的某个位置。在 C# 中，using 语句通常在添加相应的程序集后。

接下来，让我们看看我们的第一个示例，我们将向一个对象添加 外部引用 和 命名空间导入。我们将进行五个高级步骤：

1. 检查源代码中的现有 using 语句

2. 从 NuGet 下载 ML.NET 包

3. 从 NuGet 包中提取 .dll 文件

4. 将 .dll 文件复制到 BP 安装文件夹

5. 在 代码选项 选项卡中添加引用和命名空间

本例的总体目标是尽可能在添加实际 C# 代码到代码阶段之前，让 BP 与 ML.NET 一起工作。

示例 1 – BP 之前的准备工作

回想本章开头介绍的情景。我们负责将 C# ML 代码移入 BP。有两种方法来确定需要导入哪些 .dll 库。第一种方法是将所有源代码复制到一个代码阶段，并查看出现的错误消息。另一种（可能更聪明）的方法是首先检查项目的源代码。这将使我们熟悉代码库，并给我们一个需要添加哪些 .dll 文件和命名空间的思路。我们在这里将采用后者。

我们的起始源代码来自微软的 GitHub：

github.com/dotnet/machinelearning-samples/tree/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis

检查 C# 源文件中的 using 语句

在 Microsoft GitHub 项目中，只有三个 C# 源文件。让我们逐一检查并注意可能需要导入的任何 .dll 文件：

1. 打开第一个源文件 github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/Program.cs。该文件的第一个六行包含 using 语句：

   using System;
   using System.IO;
   using Microsoft.ML;
   using SentimentAnalysisConsoleApp.DataStructures;
   using Common;
   using static Microsoft.ML.DataOperationsCatalog;
   

Microsoft.ML 和 Microsoft.ML.DataOperationsCatalog 是 Microsoft.ML 的组成部分。SentimentAnalysisConsoleApp.DataStructures 是对当前项目的自引用，而不是外部库。

1. 打开第二个源文件 github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/DataStructures/SentimentIssue.cs。对于 Microsoft.ML.Data 只有一个 using 语句。

2. 打开最后一个源文件 github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/DataStructures/SentimentPrediction.cs。我们再次只看到 Microsoft.ML.Data。

通过检查源文件，我们发现了三个显著的 using 语句：Microsoft.ML、Microsoft.ML.Data 和 Microsoft.ML.DataOperationsCatalog。

检查 .csproj 文件中的 PackageReferences

.csproj 文件也可以包含需要导入的外部库引用。打开 github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/SentimentAnalysisConsoleApp.csproj 并搜索术语 PackageReference。你会看到只有一行包含 Microsoft.ML。

到目前为止，我们已经完成了对 C#项目代码中using语句的检查。这揭示了需要添加Microsoft.ML、Microsoft.ML.Data和Microsoft.ML.DataOperationsCatalog。.csproj文件再次确认了需要添加Microsoft.ML。现在我们已经知道了需要添加哪些库，让我们从 NuGet 下载它们。

从 NuGet 下载 ML.NET

NuGet 是.NET 的包管理器。在传统的软件开发中，.dll管理和依赖通常由您的 IDE 处理。这个功能很遗憾在 BP 中缺失，因此我们需要从 NuGet 网站手动下载包：

1. 在您的网页浏览器中打开www.nuget.org/。搜索ML.NET。点击名为Microsoft.ML的结果。

2. 点击版本.nupkg文件。此文件可以用.zip提取程序打开，包括默认的 Windows 程序。

1. 使用 zip 提取工具打开.nupkg文件。导航到lib\netstandard2.0文件夹。将所有七个.dll文件提取到方便的位置，例如您的桌面。我们稍后会使用这些文件。

在我们需要导入的三个库中，有两个包含在Microsoft.ML包中：Microsoft.ML位于Microsoft.ML.dll中，而Microsoft.ML.Data位于Microsoft.ML.Data.dll中。

我们不清楚在哪里可以找到Microsoft.ML.DataOperationsCatalog。从 API 文档中，可以在learn.microsoft.com/en-us/dotnet/api/microsoft.ml.dataoperationscatalog?view=ml-dotnet找到，我们看到它属于Microsoft.ML.Data.dll程序集，这意味着Microsoft.ML的.dll文件涵盖了迄今为止我们所知的所有using语句。

现在我们已经从 NuGet 包中提取了一些必要的.dll文件，让我们将它们移动到 BP 可以访问的位置。

将.dll 文件复制到 BP 安装文件夹

默认情况下，BP 安装在C:\Program Files\Blue Prism Limited\Blue Prism Automate。我们需要将.dll文件复制到安装文件夹。如果这不是您的安装路径，请替换为您自己的路径：

1. 将从 NuGet 包中提取的七个.dll文件复制到 BP 安装文件夹中。

2. 如果您已经打开了 BP 应用程序，请重新启动。BP 需要重新启动才能加载新的程序集。

重要提示

您可以将程序集复制到多个位置，以便与 BP 一起使用。这包括 Windows 目录、Windows 系统目录以及系统路径环境变量中的任何文件夹。为了使这个例子更不容易出错，我们将它复制到 BP 安装文件夹中。在生产环境中，一个更易于维护的解决方案是将.dll文件复制到一个自定义文件夹中，并将该文件夹包含在 Windows 环境路径变量中。

现在库已经被复制到一个 BP 可访问的文件夹中，让我们创建一个示例对象并导入它们。

创建一个 BP 对象并添加外部引用和命名空间导入

在这个第一个示例的最后一部分，我们将创建一个 BP 对象，添加所需的.dll文件作为引用，添加命名空间，并将语言设置为 C#：

1. 在工作室 | 对象内创建一个名为Ch3的新组。

2. 在Ch3组内创建一个名为Example 1 – 用户评论的情感分析的新对象。

3. 在初始化页面，双击带有对象名称的白色框。这会打开业务对象的属性。

图 3.6 – 双击打开业务对象的属性

1. 点击Microsoft.ML.dll。点击Microsoft.ML.Data.dll。

2. 点击Microsoft.ML。点击Microsoft.ML.Data。

3. 在语言下拉菜单中选择C#。

4. 确认代码选项选项卡看起来如下：

图 3.7 – 在第一个示例末尾的代码选项卡

1. 保存对象。

在这个例子中，我们在将 C#代码移动到代码阶段之前完成了所需的前期准备工作。首先，我们检查了项目的代码，以确定所需的某些程序集导入。这些程序集本身以及我们需要添加到代码阶段的进一步代码可能还有尚未导入的附加依赖项。接下来，我们从 NuGet 下载了 ML.NET 包，并提取了.dll文件。最后，我们将 ML.NET 程序集复制到 BP 安装文件夹中，并在对象的属性中添加了它们作为引用。在下一节中，我们将专注于将源代码移植到 BP 中。

将 ML.NET C#移植到代码阶段

将代码移植到 BP 更像是艺术而非科学。这需要了解 C#的工作原理，并在必要时深入研究 ML.NET API 文档。我们已经讨论了对象的属性中的代码选项部分。对象的属性还有一个全局代码选项卡，它将在下一个示例中使用。

全局代码

全局代码选项卡通过对象的属性访问，类似于代码****选项选项卡：

图 3.8 – 通过对象的属性访问全局代码标签

全局代码部分用于放置需要在多个代码阶段中使用的通用代码。这在概念上类似于需要在不同操作或页面中使用的全局数据项（取消选中“在过程中隐藏其他页面”的复选框），类似于通用数据项。通用代码可以包括变量、类和函数。

您还会注意到一个检查代码按钮。此按钮从全局代码部分的编译器角度以及对象中的任何其他代码阶段验证代码。我们将频繁使用此按钮来帮助我们确定哪些程序集缺失。

在下一个示例中，我们将使用全局代码部分和检查代码按钮来帮助将 C#代码移植到 BP。示例将通过五个高级步骤进行：

1. 将两个 C#类移动到对象的全局代码部分

2. 将主要源代码复制到代码阶段

3. 通过使用检查 代码按钮迭代修复编译错误

4. 修改 C#控制台打印命令，以便将输出到文件

5. 测试移植的 ML 程序

示例 2 - 将源代码移植到 BP

在本例中，我们将把所有源代码移动到一个代码阶段，并修复更多的汇编和命名空间错误。我们的目标是达到一个可以接收 C#代码阶段预测的点。

重要提示

此示例是在 BP 版本 7.1.1 和 7.1.2 上创建和测试的。然而，如果您使用的是 BP 的不同版本，可能需要额外的步骤才能使此示例正常工作。这是因为 BP 的不同版本捆绑了不同版本的 Microsoft 的.dll 库。如果您查看 BP 的安装文件夹，许多这些.dll 文件都是以System.*或Microsoft.*为前缀。本例中显示的步骤在最坏的情况下应该能让你非常接近通过代码阶段进行预测。您可以通过应用我们下面将看到的技巧来获得一个可工作的解决方案。

将类定义移动到 BP

在第一个示例中，我们看到了只有三个.cs源文件。其中两个源文件，SentimentIssue.cs和SentimentPrediction.cs，是类定义。让我们将它们移动到对象的全局代码部分：

1. 打开第一个示例中创建的对象。如果需要，一个名为Example 1 - Sentiment Analysis for User Reviews (Completed)的完成版对象应该已经导入到Ch3组中。

2. 通过双击初始化页面上的带有对象名称的白色框来打开对象的属性。

3. 点击全局 代码标签。

4. 将类定义代码从github.com/dotnet/machine learning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/DataStructures/SentimentIssue.cs复制到public class SentimentIssue { … }。

5. 对github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/DataStructures/SentimentPrediction.cs中的文件重复此操作。这包括public class SentimentPrediction { … }之间的所有内容。

6. 确认全局代码部分包含如图所示的两个类定义：

图 3.9 – 全局代码部分包含两个类定义

1. 点击“类型 'Attribute' 在未引用的程序集中定义。您必须添加对程序集 'netstandard, Version=2.0.0.0, Culture=neutral' 的引用。”

2. 点击netstandard.dll。

3. 返回到全局代码选项卡并再次点击检查代码。确保没有编译器错误。

4. 点击确定以保存业务对象的属性。

5. 保存对象。

到目前为止，我们已经成功将两个类添加到对象的全局代码部分。接下来，让我们将主程序代码导入到一个代码阶段。

将机器学习程序代码移植到代码阶段

机器学习程序的主要代码在这个文件中：github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/Program.cs。

让我们将其移动到一个代码阶段：

1. 导航到“动作 1”页面并添加一个代码阶段。

2. 链接它们在开始和结束之间。

图 3.10 – 向动作 1 添加代码阶段

1. 查看Program.cs的第 12-20 行。注意它包含多个private static readonly string语句。这些语句定义了训练数据文件（第 15 行）和模型输出文件（第 20 行）的路径。在对象图中添加两个Text来表示这些。将一个数据项命名为DataPath，另一个命名为ModelPath。

2. 将DataPath设置为C:/Users/Public/wikiDetoxAnnotated40kRows.tsv，将ModelPath设置为C:/Users/Public/ch3_SentimentModel.zip：

图 3.11 – 设置 DataPath 和 ModelPath 的初始值

1. 双击Code1。添加两个与数据项DataPath和ModelPath对应的输入。

图 3.12 – 将两个数据项作为输入添加到代码阶段

1. 点击代码窗口中的Main(string[] args) { [Copy the text here] }。这些是Program.cs的第 24 行到第 68 行。你的代码窗口中应该有 45 行代码。

图 3.13 – 应该在窗口中的 45 行代码

1. 点击.dll缺失。例如，你可能会遇到你必须添加对程序集'Microsoft.ML.Core'的引用或你必须添加对程序集'Microsoft.ML.DataView'的引用。关闭检查代码窗口并按确定保存代码阶段。

2. 通过在 NuGet 网站上搜索lib\netstandard2.0\Microsoft.ML.DataView.dll文件从 NuGet 包到 BP 安装文件夹位置找到Microsoft.ML.DataView.dll文件。关闭并重新启动 BP。

3. 在Microsoft.ML.Core.dll和Microsoft.ML.DataView.dll上打开对象的属性作为外部引用。按确定关闭对象的属性。

图 3.14 – 将两个新的外部引用添加到对象的属性中

1. 返回到Code1阶段并再次点击检查代码。应该仍然有四个编译器错误，它们没有给出需要导入哪个程序集或命名空间的明确指示。

图 3.15 – 剩余的四个编译器错误

到目前为止，我们还没有一个工作的代码阶段，但我们已经接近了！让我们逐一调查和解决剩余的编译器错误。

修复单个编译器错误

没有编译器错误有明显的解决方案。我们需要依赖 API 文档来找出需要添加哪些命名空间或程序集。让我们按照错误发生的顺序来处理它们：

1. 查看第 8 行的编译错误。它显示“找不到类型或命名空间名称 'TrainTestData'”。让我们参考 API 以找出TrainTestData是什么。在learn.microsoft.com/en-us/dotnet/api/microsoft.ml.dataoperationscatalog.traintestdata?view=ml-dotnet的文档显示它属于DataOperationsCatalog。回想一下，DataOperationsCatalog是Project.cs文件开头的一个using语句之一：

   using static Microsoft.ML.DataOperationsCatalog;
   

   using语句通常通过将它们添加到using static语句中移植到 BP，但不能以这种方式添加。相反，我们需要在源代码本身中提供整个命名空间。

2. 在第 8 行打开Code1阶段，并在TrainTestSplit前加上Microsoft.ML.DataOperationsCatalog。现在第 8 行应该是这样的：

   Microsoft.ML.DataOperationsCatalog.TrainTestData trainTestSplit = mlContext.Data.TrainTestSplit(dataView, testFraction: 0.2);
   

3. 点击检查代码。查看第 8 行的编译错误是否已消失。

4. 查看第 13 行的编译错误。它显示：“'TransformsCatalog.TextTransforms' 没有定义 'FeaturizeText'”。在learn.microsoft.com/en-us/dotnet/api/microsoft.ml.textcatalog.featurizetext?view=ml-dotnet的 API 参考中查找FeaturizeText。它显示需要Microsoft.ML.Transforms.dll程序集：

图 3.16 – Microsoft.ML.Transforms.dll 中的 FeaturizeText

1. 在对象的属性中将Microsoft.ML.Transforms.dll添加为外部引用，并通过按确定按钮关闭对象的属性窗口。

图 3.17 – 添加 Microsoft.ML.Transforms.dll 作为外部引用

1. 验证第 13 行的编译错误是否已消失。

2. 查看第 16 行的编译错误。它显示“'BinaryClassificationCatalog.BinaryClassificationTrainers' 没有定义 'SdcaLogisticRegression'”。在learn.microsoft.com/en-us/dotnet/api/microsoft.ml.trainers.sdcalogisticregressionbinarytrainer?view=ml-dotnet的 API 页面显示，SdcaLogisticRegression 位于Microsoft.ML.StandardTrainers.dll中：

图 3.18 – Microsoft.ML.StandardTrainers.dll 中的 SdcaLogisticRegression

1. 在对象的属性中将Microsoft.ML.StandardTrainers.dll添加为外部引用。按确定按钮关闭属性窗口。

2. 验证第 16 行的编译错误是否已消失。

剩下的第 26 行的最后一个编译错误是关于一个帮助将结果打印到控制台窗口的实用程序 (ConsoleHelper.PrintBinaryClassificationMetrics)。由于我们的目标是让这个程序从 BP 运行，我们将不会看到任何控制台窗口。让我们将 C# 代码更改为将输出写入文件。

将控制台输出更改为文件

ConsoleHelper.cs 文件位于 github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/common/ConsoleHelper.cs。我们可以将那个函数的代码复制到我们的对象的属性中的 全局代码 部分，并将第 26 行更改为从我们的代码阶段调用该函数。然后，我们将更改打印到控制台窗口为写入文件：

1. 在 GitHub 上打开 ConsoleHelper.cs 文件，并将第 41-57 行的 PrintBinary ClassificationMetrics(…) 函数复制到你的对象的属性中的 全局代码 部分：

图 3.19 – 将 PrintBinaryClassificationMetrics() 复制到全局代码

1. 打开 Code1 阶段，在第 26 行删除 Console.Helper. 前缀。第 26 行应显示 PrintBinaryClassificationMetrics(trainer.ToString(), metrics);。

2. 点击 检查代码 并确认没有更多的编译错误。

3. 打开对象的属性，并将 System.IO 添加到 命名空间导入。这是写入文件所需的。

图 3.20 – 将 System.IO 添加到命名空间导入

1. 返回到 Code1 阶段，并在代码窗口的开始处添加以下行：

   FileStream ostrm;
   StreamWriter writer;
   TextWriter oldOut = Console.Out;
   try {
       ostrm = new FileStream("C:/Users/Public/ch3_output.txt",     FileMode.OpenOrCreate, FileAccess.Write);
       writer = new StreamWriter(ostrm);
   }
   catch (Exception e) {
       return;
   }
   Console.SetOut(writer);
   

2. 删除代码窗口底部的最后两行。它们如下所示：

   Console.WriteLine($"================End of Process.Hit any key to exit==================================");
   Console.ReadLine();
   

   可以安全地删除它们，因为它们的作用是暂停控制台窗口，以便你可以查看打印的文本，这现在不再是必要的。

3. 将以下三行粘贴到代码窗口的底部：

   Console.SetOut(oldOut);
   writer.Close();
   ostrm.Close();
   

4. 按 确定 保存代码窗口。

现在所有编译错误都已解决，我们可以下载训练数据并测试 ML.NET 代码阶段。

运行 ML.NET 程序

我们接近终点线了！我们需要下载训练数据，将其复制到正确的位置，并运行我们的模型：

1. 从 github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/Data/wikiDetoxAnnotated40kRows.tsv 下载训练数据。确保文件以 .tsv 文件格式下载，而不是 .txt 文件。

2. 将 .tsv 文件复制到由 DataPath 数据项指定的位置，C:/Users/Public/wikiDetoxAnnotated40kRows.tsv。

3. 点击“操作 1”页面，并在对象工作室中运行它。

4. 注意到有一个错误：“内部：无法执行代码阶段，因为代码阶段抛出异常：无法加载文件或程序集System.Collections.Immutable, Version=1.2.3.0”。

5. 通过在 NuGet 网站上搜索lib\netstandard2.0\Systems.Collections.Immutable.dll文件从 NuGet 包中找到，将其放入 BP 安装文件夹位置。关闭并重新启动 BP。

6. 再次从对象工作室运行“操作 1”页面。注意到有一个错误：“Shuffle 输入游标读取失败，异常”。这个错误不是很有用，但我们可以将代码阶段包裹在 try / catch 语句中，以获取完整的堆栈跟踪。完整的堆栈跟踪揭示了另一个缺失的依赖项，Microsoft.ML.CpuMath。

7. 通过在 NuGet 网站上搜索“lib\netstandard2.0\Microsoft.ML.CpuMath.dll”文件从 NuGet 包中找到，将其放入 BP 安装文件夹位置。实际上，此程序集还依赖于一个名为 CpuMathNative.dll 的文件。这个文件通常由机器学习工程师提供，因为它将作为他们代码项目的一部分构建。

8. 从 GitHub 下载CpuMathNative.dll（假设这是由机器学习团队提供的）：github.com/PacktPublishing/Intelligent-Process-Automation-with-Blue-Prism/blob/main/ch3/CpuMathNative.dll，并将其复制到 BP 安装文件夹。关闭并重新启动 BP。

9. 再次从对象工作室运行“操作 1”页面。

10. 打开C:\Users\Public\ch3_output.txt并确认其外观类似于以下图示：

图 3.21 – 包含在 ch3_output.txt 中的重定向控制台输出

此文件显示了句子的训练准确性和对“我爱这部电影！”的样本预测结果。

1. 确认存储在ModelPath数据项中的文件C:/Users/Public/ch3_SentimentModel.zip已创建。文件大小应约为 13 MB。此文件可以加载进行预测，而无需再次训练模型。

我们已经完成了将机器学习代码移植到 BP 的过程。克服的最大困难是知道应该包含哪些程序集和命名空间导入。我们能在编译器错误和 ML.NET API 文档中找到这些信息。

作为参考，第二个示例的完整对象应该已导入到Ch3组中的“Example 2 - 用户评论情感分析（完成）”。现在我们已经训练了模型并且预测工作正常，让我们重构这个示例，使其遵循 BP 最佳实践。

改进 BP 集成

虽然第二个例子中的代码从功能角度来看是可行的，但它并没有很好地集成到 BP 中。它被放在一个单独的代码阶段中，这既不可维护也不可重用。数据科学家不一定有软件设计经验，因此你可能会收到一个完整的 ML 程序，它包含在一个源文件或 ML 笔记本中，以便将其导入 BP。

第二个例子中存在的一些问题包括以下内容：

• 日志记录的精确度较低。在添加代码阶段时最大的担忧之一是，你可能完成了许多重要步骤，但没有任何日志发送回 BP 数据库以供记录。

• 每次我们想要进行预测时，都需要重新训练整个模型，这是一项耗时且重复的工作。

• 只有一个动作，这不利于重用。

• C#代码中缺少异常处理。

让我们看看我们如何在下一个例子中改进列出的四个要点。

示例 3 - 重构

在本章的最后一个例子中，我们将查看第二个例子的重构版本，它改进了功能、可重用性和日志记录：

1. 在对象工作室的Ch3组中打开Example 3 – Sentiment Analysis for User Reviews (Refactored)对象。

2. 无需编辑对象图即可访问.zip文件。

图 3.22 – 训练数据路径和保存的模型路径存储为环境变量

1. 注意，训练模型路径现在与预测模型路径分开。通过保持这些分开，你可以在继续使用之前的模型进行预测的同时重新训练模型。这是至关重要的，因为新训练的模型在使用生产之前需要经过审查。

图 3.23 – 训练模型路径和预测模型路径不同

1. 注意，如果需要更改而不编辑对象图，训练数据与测试数据的比例将作为环境变量暴露出来。构建模型的一部分是围绕训练参数的大量实验。最好不在对象的代码阶段中硬编码训练/测试分割，以防需要更改。另一种有效的设计是将此作为动作的输入。

2. 注意，训练、评分、模型保存和预测制作都已拆分为单独的动作。最重要的是，我们现在可以预测而无需每次都训练模型。这也提高了会话日志的精确度。

图 3.24 – 每个机器学习阶段都有自己的动作以改进日志记录和可重用性

1. 在每个代码阶段中添加了try…catch块，将错误消息和成功标志输出回 BP。

图 3.25 – 添加 try…catch 块以改进错误处理

每一页在结束阶段都将这些内容作为输出返回给调用者，而不是将文本写入文件。

1. 访问初始化页面，打开对象的属性，查看全局代码。你会看到为了适应所有这些变化，已经添加了许多新的静态变量：

图 3.26 – 添加到全局代码中的静态变量，可在其他代码阶段中使用

这第三个例子到此结束。这是对第二个例子的重构版本，可读性、可重用性和可维护性都得到了提升。将整个 ML 程序完全包含在一个或几个源文件中是非常常见的。将 C#程序移植到单个代码阶段会导致的结果远远不符合 BP 的最佳实践。我们需要额外走一步，改进所提供的内容，使其符合 IA 卓越中心的行业标准。

摘要

ML.NET 是微软的开源、跨平台机器学习框架。它基于.NET 构建，可以通过代码阶段在 BP 中本地使用。在本章中，我们面临了一个常见的 IA 场景。我们得到了一个用 ML.NET 构建的工作 ML 项目，我们的任务是让源代码在 BP 中工作。

在第一个例子中，我们检查了源代码，以了解需要导入哪些.dll库。我们从 NuGet 下载了 ML.NET 包，并将程序集复制到 BP 安装文件夹中。

在第二个例子中，我们开始将代码移动到 BP 代码阶段。一些代码，包括类定义，属于.dll或命名空间错误。我们通过阅读编译器错误消息并在必要时查找 API 中的关键术语来解决每个错误。一个需要理解的关键点是，你不需要是 ML 专家，也不需要对你正在使用的 ML 框架有经验，就可以成功将其移植到 BP！我们可以通过使用检查代码和文档来成功移植代码。

最后，ML 代码通常以单个源代码程序的形式提供。在第三个例子中，我们将单个代码阶段拆分为多个动作，这些动作更接近 ML 生命周期。主要目标是使我们的对象在未来更具可重用性和可维护性。

这本书的第一部分到此结束，我们主要关注了 BP 如何触发 ML 预测。实现这一目标的主要方式是通过 Web API、命令行界面和代码阶段。接下来是本书的第二部分，我们将重点转向 IA 解决方案设计。

第二部分：设计 IA 解决方案

在本书的第一部分中，我们学习了三种将 BP 连接到 ML 模型进行预测的不同方法：Web API、命令行界面和代码阶段。

第二部分描述了围绕 ML 预测的 BP 解决方案设计元素。虽然这里的设计概念是通用的，可以与任何 RPA 工具一起使用，但它们在 BP 中得到了展示。在第四章中，我们将介绍将回顾 ML 预测作为管理 IA 风险的方法。我们将讨论并设计两种触发人工审查的不同方式：随机抽样和阈值。

第五章探讨了通过改变 BP 流程和工作队列的数量来设计 IA 解决方案的不同方法。改变流程和工作队列的数量会影响 IA 解决方案的可审计性和可扩展性。在建立这个更大的解决方案结构后，第六章讨论了一些较小、可重用的元素，这些元素可以用于所有不同的设计。

最后，第七章将本书这一部分的工作整合成可重用的 IA 流程模板和一个 IA VBO，这些模板可以作为您 IA 解决方案设计和开发的起点。

本部分包含以下章节：

• 第四章，回顾预测和人工参与

• 第五章，HITL 的 IA 流程和工作队列设计

• 第六章，可重用 IA 组件

• 第七章，IA 模板和工具 – IA 对象

第四章：审查预测和人工参与

RPA 和 IA 之间最大的区别之一在于，以前确定的自动化工作结果可能变得不确定。由于 ML 预测的不确定性，我们不再 100%确信数字工作者采取了正确的行动。了解 ML 算法表现如何以及降低 IA 的整体风险水平的主要方法之一是对 ML 预测进行部分手动审查。本章讨论了通过将人工参与（HITL）添加到自动化过程中来设计这种手动验证的两种不同方式。

在本章中，我们将涵盖以下主要内容：

• 为什么我们应该审查预测？

• 在 IA 的背景下，HITL 代表什么？

• 可以使用哪些标准来触发人工干预？

• 我们如何共享预测数据在预测审查员和 Blue Prism 之间？

技术要求

下载并导入 GitHub 上ch4文件夹中的三个.bprelease文件：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/tree/main/ch4

本章的第二个示例也需要导入第三章（B18416_03.xhtml#_idTextAnchor048）的示例 3发布。GitHub 文件夹中还有一个 Excel 文件，它将作为示例 2的一部分下载。

为什么我们应该审查预测？

自动化爱好者不喜欢必须审查 ML 预测的想法。毕竟，结合 ML 和 RPA 的目的不是为了进一步减少人们在业务流程中的参与吗？在 IA 的背景下，ML 模型就像任何其他软件一样。它们不能永久使用。它们需要监控和更新，因为 ML 模型随着时间的推移而漂移是已知的，导致准确性下降。漂移可能由许多原因引起，例如底层输入数据特征的变化，或者模型未训练的新数据的暴露。不仅审查预测可以帮助检测漂移，而且还有一些 IA 特定的原因需要审查预测。

降低商业风险

当第一次将流程移入生产时，通常需要密切监控处理过程，并且只允许一小部分总工作量被处理。这些做法是管理将新事物部署到生产中固有的风险的方法。

在大多数情况下，引入 ML 会增加自动化流程的风险水平。尽管如此，我们仍然继续追求 IA，因为我们相信使用 ML 的好处超过了这些风险。审查 ML 预测并在必要时进行纠正，是减轻这种增加的商业风险的最直接方式之一，这种风险是基于持续、运营、个案处理的。

减少 IA 的商业风险还有其他方法，例如，通过故意选择下游保证人工审查的过程，或者选择可以容忍错误结果的用例。然而，这类风险缓解通常决定了哪些 IA 流程会被批准。它们不能在生产后用于操作层面的风险控制。

事先解决监管问题

自动化和人工智能在全球监管者和立法者心中占据核心位置。例如，巴西、中国和美国等国家正在积极制定立法，以规范社会中对人工智能的使用。例如，2023 年 10 月，拜登政府发布了一项行政命令，重点关注如何管理人工智能的风险。

欧洲在制定相关立法方面走在前列，有两个相关框架：目前正在开发的欧盟人工智能法案，以及已经生效的通用数据保护条例（GDPR）。欧盟人工智能法案将人工智能应用案例分为四个风险类别：最小、有限、高和不可接受。存在指导方针来定义哪些应用案例属于每个类别，并且有相应的立法来覆盖每个级别。例如，在不可接受风险类别下，使用人工智能寻找犯罪受害者是明确禁止的。法案的第 14 条讨论了人工监督。高风险系统必须设计成在人工智能系统使用期间，可以由自然人进行监督。虽然根据欧盟人工智能法案，很少有应用案例会被归类为高风险，但将人工监督纳入我们的 IA 解决方案设计作为一种预防措施是值得的。

GDPR的第 22 条规定，欧盟公民有权不受仅基于自动处理的决定的影响，以及有权获得人工干预。虽然欧盟人工智能法案和 GDPR 仅适用于欧盟，但其他国家可能会在其自己的 AI 立法中采用类似的规定。如果我们设计我们的流程，使得机器学习预测可以被人工审查（即人工监督），我们可以减轻未来可能出现的监管风险。

欧盟人工智能法案和 GDPR 都暗示，我们的 IA 流程中应该设计以下机制：

• 允许由人类验证机器学习预测

• 根据请求完全或选择性地禁用机器学习决策

本章重点介绍第一个要点，这是一种 HITL（人机交互）的形式。第二个要点将在后续章节中介绍。

在 IA 的背景下，HITL 是什么意思？

HITL 广泛地意味着人类应以某种方式与自动化互动。在传统的 RPA 中，可能需要人类输入的原因有很多。例如，可能需要人类输入以进行双因素认证，以便登录网站。

由于 IA 意味着将 ML 引入自动化过程，因此在此上下文中的人机交互特指某人查看 ML 预测的结果，如有必要进行纠正，并将审查后的预测提供给 BP。添加 HITL 来完成这一过程极大地影响了我们的流程设计。它需要确定以下事项：

• 应该使用哪些标准来触发自动化过程中的人工干预？

• 应该使用哪种用户界面来显示预测并接收关于预测是否正确的反馈？例如，这可以通过电子邮件、共享电子表格、网站等方式实现。

• 审查预测是否需要近乎实时完成以满足服务水平协议。

当面对一个需要审查的预测时，审查员必须决定以下事项：

• 是否接受或更改预测结果。

• 是否继续或暂停工作案例的自动化处理。

这些问题的答案将通过本章的示例进行说明。

可以使用哪些标准来触发人工干预？

记住，ML 预测将给出一个预测值，无论是数字、标签、图像还是生成的文本，以及一个置信度分数。一个明智的干预决策通常会考虑这两个因素，但仍有理由仅基于其中一个因素进行干预。

随机抽样

决定哪些工作案例应该手动审查的最简单方法是通过随机抽样：

1. 要使用随机抽样，选择一个您希望用于手动验证的目标百分比，例如，10%。

2. 在 ML 预测之后生成一个介于 1 到 100（包括 100）之间的随机数。如果随机数低于所选目标（本例中为 10），则自动化处理将停止，等待对预测的人工审查。

3. 在审查过程中，审查员可以纠正预测并允许工作案例继续，或者完全暂停自动化处理。

在一个实际案例中，IA 团队选择了 25%的随机抽样目标。随机抽样 25%案例进行手动审查的主要目的是跟踪预测准确性。尽管随机抽样并没有明确指出是为了降低风险而使用的，但它绝对可以用于这个目的。

随机抽样不使用任何预测或置信度分数。这是随机抽样与阈值之间的主要区别，这是一种不同的 HITL 触发器，将在本章后面讨论。请注意，如果我们将目标百分比设置为 100%，我们实际上使得每个预测都必须由人员进行审查。

让我们通过一个示例来看看如何实现随机抽样。我们将经历的四个高级步骤如下：

1. 检查示例的发布文件内容。

2. 了解如何在 BP 中生成随机数。

3. 理解如何通过随机采样触发 HITL 审查来定义使用随机采样的流程的流程。

4. 运行示例，在控制室中查看结果。

示例 1 – 随机采样

随机采样的概念很简单。首先，生成一个随机数。然后，检查随机数是否符合您的人工审查标准。尽管这个逻辑很简单，但在 BP 流程中实现随机采样需要使用许多 BP 功能。在此示例中，我们将查看使用单个工作队列、状态和延迟的单个随机采样实现。

此示例已基于 BP 的流程模板开发。我们的目标是检查和理解用于实现随机采样以供人工审查的 ML 预测的设计元素。第一步是导入发布文件。

检查.bprelease 内容

在开始之前，让我们检查示例 1的.bprelease内容。验证是否已导入一个流程、一个工作队列和一个环境变量：

图 4.1 – 示例 1 的.bprelease 文件内容

环境变量名为Ch4 Example 1 Random Sampling Target的默认值为33.33，这意味着在此流程中，大约三分之一的 ML 预测将被选择进行人工审查。

接下来，让我们打开流程并检查与随机采样相关的 BP 阶段。

生成随机数

在本节中，我们将了解随机采样逻辑是如何实现的。BP 没有直接生成随机数的方法。在 BP 中，大致有三种生成随机数的方法。第一种是在 DX 上下载具有随机数功能的新版发布（见digitalexchange.blueprism.com/dx/entry/3439/solution/utility---mathnet---random）。此 DX 资产需要从 NuGet 下载一个单独的.dll文件。第二种方法是在新对象中创建一个，并将随机数生成代码添加到代码阶段。第三种方法，即在此示例中使用的方法，是通过 PowerShell 的Get-Random函数。请注意，我仅使用 PowerShell 以保持.bprelease内容简单。首选的解决方案是在对象中实现它。

1. 在流程工作室中打开示例 1 – 随机采样流程的Ch4组。

2. 找到名为Main Page的块。所有流程的主要步骤都应该属于这里。让我们将注意力集中在包含执行随机采样的逻辑的03 Random Sampling页面上：

图 4.2 – 主页上的工作块中的随机采样

1. 打开 03 随机抽样 页面。双击 Get-Random 函数，并传入最小值和最大值 1.0 和 100.0。添加的小数点 .0 非常重要，因为它允许生成小数。如果省略，Get-Random 返回整数值。由于我们的随机抽样目标是小数，33.33，因此需要小数：

图 4.3 – 使用 PowerShell 的 Get-Random 生成随机数

1. 双击 需要手动审查？ 决策阶段。在这里，我们将 PowerShell 生成的随机数与环境变量的值进行比较。如果比较是 主页面：

图 4.4 – 确定是否需要手动审查的标准

我们已经完成了对随机抽样逻辑的审查。接下来，让我们看看如何在等待 HITL 审查完成的同时，防止工作队列项目工作。

推迟、选择和状态

主页面 包含三个重要的阶段，这些阶段构成了防止工作队列项目在待审期间继续进行的逻辑。在本例的这一部分，我们将检查这三个阶段——检查状态、手动审查和将项目推迟至手动审查：

图 4.5 - 阻止项目在审查待定期间继续进行的阶段

1. 返回到 主页面 并双击 手动审查？ 决策阶段。这个阶段检查在 03 随机抽样 页面上设置的标志。如果需要手动审查，执行将继续到 推迟项目至手动审查 页面。

2. 打开 推迟项目至手动审查 页面。这里只发生两件事。首先，当前工作队列项目的 状态 被设置为 手动审查所需。接下来，工作队列项目被推迟 10 分钟。10 分钟的推迟时间是任意的，可以根据您的喜好进行调整：

图 4.6 – 推迟项目至手动审查页面设置项目状态并推迟

1. 返回到 主页面 并双击 检查状态 选择阶段。在本例的上下文中，选择阶段主要用于不断推迟具有 手动审查所需 状态的项目，直到状态变为 手动审查完成：

图 4.7 - 如果项目未被审查，状态检查将阻止推迟的项目继续进行

还要注意，第三个选项总是将手动审查标志设置为 True，以便将尚未审查的推迟工作队列项目再次推迟：

图 4.8 – 延迟持续到状态变为手动审查完成

如果手动审查标志为False（随机生成的数字大于或等于 33.33），或者如果工作队列项状态被更改为手动审查完成，自动化处理可以继续。

运行流程

现在，让我们运行一次流程。该流程将九个项目加载到名为第五章 示例 1 队列的工作队列中。由于我们的采样率为 33.33%，我们预计每次运行流程时，大约有三项被延迟以供 HITL 审查：

1. 从控制室运行名为示例 1 – 随机抽样的流程，在Ch4组中。你将看到每次做出预测时都会弹出 PowerShell 窗口。

2. 在队列管理下的Ch4组中点击第四章 示例 1 队列。希望你会看到一些工作队列项已完成，而那些随机选择进行人工审查的项目已被延迟，状态设置为手动审查所需。具有手动审查所需状态的项目也有一个延迟时间，从现在起 10 分钟：

图 4.9 – 确认需要手动审查的项目已被延迟

我们已经完成了示例 1。在这里，我们看到了如何使用状态、选择和延迟来实现一种防止项目在手动审查之前被处理的随机抽样策略。我们还看到了如何通过 PowerShell 生成随机数。

在示例 1中，我们没有涵盖的一个问题是，如何实际更改项目的状态，以便在延迟后可以再次提取该项目进行处理。这一点将在本章的示例 3中进行讨论。

随机抽样的另一种策略是使用预测值和置信度分数来选择需要人工审查的案件。这被称为阈值化，将在下一节中讨论。

阈值化

阈值化使用置信度分数和有时使用标签来确定哪些预测需要人工审查。想法是选择置信度分数的阈值值。如果预测的置信度分数低于阈值，则将案件标记为需要人工审查，如果高于阈值，则自动化处理可以继续。

在实际的 IA 中，有许多使用阈值化的例子。在一种情况下，一家公司决定设置三个阈值范围。第一个阈值范围是 0%到 90%，选择完全停止自动化处理，转而采用手动处理。90%到 99.5%的置信度分数被标记为需要人工审查。得分高于 99.5%的工作项可以继续 IA 而无需任何审查。这是一个例子，说明我们不仅可以有一个阈值，还可以有多个阈值。

不仅可能存在多个阈值，不同的标签也可以有自己的阈值。在一个不同的实际 IA 用例中，有一个 ML 算法预测了超过 70 个类别。其中一些类别预测精度较高（> 90%），而其他类别预测精度较低（<75%）。IA 团队决定为低精度类别的预测设置较高的置信度分数阈值，以便使人工验证更有可能。对于高度精确的标签预测，置信度分数阈值设置为 0，允许完全自动化处理，因为没有东西会被标记为需要审核。

选择阈值值

阈值处理要求 IA 团队决定以下事项：

• 哪些标签（回归的数值范围）需要阈值处理？

• 需要多少个阈值区间？

• 阈值的截止点应该是多少？

如何设置阈值值没有简单的指导方针，因为它们与业务可以接受的风险程度密切相关。一种合理的方法是通过实验来估计在特定阈值水平下设置阈值所产生的错误预测数量。然后，量化错误预测的影响。

假设我们有一个从发票中提取发票 ID 的 NLP 模型。在测试了 10 张发票后，我们得到了以下结果：

#	置信度分数	发票 ID 是否正确
1	87	是
2	57	否
3	46	否
4	67	否
5	78	是
6	93	是
7	72	是
8	53	是
9	62	是
10	43	否

表 4.1 – 从 10 张发票中尝试提取发票 ID 的结果

总体而言，该模型在这小样本集中正确提取发票 ID 的次数为 6/10 次（60%的时间）。IA 团队决定使用阈值处理并通过人工审核低置信度分数的预测来提高准确性。置信度分数高于阈值的预测将由 BP 自动处理，无需审核。置信度分数的阈值值应该是多少？

如果人工审核总是能正确提取出发票 ID（请注意，这并不总是情况），选择不同的阈值值会给我们以下结果：

置信度分数阈值	低于阈值的预测需要人工审核的数量	高于阈值的预测无需审核的数量	未审核处理案例的准确性	包括人工审核的所有案例的准确性
40	0	10	6/10 = 60%	6/10 = 60%
45	1	9	6/9 = 66.7%	7/10 = 70%
50	2	8	6/8 = 75%	8/10 = 80%
55	3	7	5/7 = 71%	8/10 = 80%
60	4	6	5/6 = 83.3%	9/10 = 90%
65	5	5	4/5 = 80%	9/10 = 90%
70	6	4	4/4 = 100%	10/10 = 100%
75	7	3	3/3 = 100%	10/10 = 100%
80	8	2	2/2 = 100%	10/10 = 100%

表 4.2 – 置信度分数不同阈值水平的自动化部分准确性和整体准确性

对于置信度分数设置一个高阈值通常可以提高准确性，但也导致更多案例被标记为需要人工审查。看看前表中80的阈值值。我们可以看到，基于 10 个样本（第 5 列）有完美的准确性，但我们需要手动审查 10 个预测中的 8 个（第 2 列）。

设置低阈值允许更多案例通过 BP 自动处理；然而，需要采取行动的错误预测的数量也增加了。例如，如果阈值设置为45，只需要审查一个预测（第 2 列），但基于错误预测处理的案例占 30%（第 5 列）。

设置阈值值是在所需准确性、基于错误预测处理案例的影响以及您希望不进行人工干预处理的案例数量之间进行权衡。我们已经看到整体准确性如何与通过表 4.2的自动化案例数量相关。接下来，我们将讨论允许自动化基于错误预测处理案例的影响。

具有错误 ML 预测的案例自动化的影响

在提取发票 ID 的示例中，继续处理固有的风险性取决于许多因素：

• 一个错误提取的发票与真实的发票 ID 匹配的可能性有多大？

• 自动化完成后，是否需要进行人工审查，以便捕捉到更下游的 ML 预测错误？

• 在它持久化的系统中修改错误的发票 ID 有多难？是否需要在许多不同的地方进行修改？

• 发票 ID 会被提交到第三方系统吗？

商业和 IA 团队将需要根据列出的标准以及更多内容来评估需要多少人工审查。

在多标签分类案例中，每个标签也可以有其自己的风险程度。例如，如果发票的 NLP 模型也提取数值，将一个数字错误地标记为价格可能比错误地将一个数字标记为发票的年份风险更大。

应该仔细考虑所选的阈值值，通过评估使用错误预测继续处理的风险。不同类型的错误预测可能具有不同的风险特征，这意味着在许多情况下，准确性不足以确定阈值。

现在我们应该了解阈值是如何工作的，以及如何可能选择一个置信度分数的阈值值。接下来，让我们通过一个示例来实现 BP 中的阈值。在以下示例中，我们将执行三个高级步骤：

1. 检查示例的 Release 文件内容，并下载一个存储阈值标签和值的 Excel 文件。

2. 看看阈值逻辑如何在 BP 中实现。

3. 运行示例以在控制室中查看结果。

示例 2 – 阈值

假设我们为一家通过亚马逊、eBay 和沃尔玛等电子商务平台销售产品的公司工作。我们的公司使用 RPA 收集那些市场网站上留下的用户评论。作为改善客户关系和产品质量的倡议的一部分，公司希望确定用户反馈是否为正面。如果反馈是负面的，评论将被发送到客户服务和产品开发团队进行分析和跟进。

回想一下，在 第三章，示例 3 中创建的 Object 做了类似的事情。它使用 ML.NET 来检测用户评论中的 有毒 与非有毒情绪。随机抽样方案在这里不是一个好选择，因为我们希望更多地关注负面情绪而不是正面情绪。我们将改用阈值，以更频繁地审查可能为负面的评论。

在阈值方面，IA 团队与业务用户进行了一些测试，以确定阈值范围，并选择了以下内容：

标签	阈值 区间 1	阈值 区间 2
无毒	0 <= 置信度分数 < 75 手动审查	75 <= 置信度分数 <= 100 允许自动化处理
有毒	总是手动审查

表 4.3 – 选定的阈值

在这个示例中，BP 流程的高级布局与我们在上一个示例中的随机抽样流程大致相同。区别主要在于我们处理阈值值的方式，因此我们的注意力将集中在那里。

检查 .bprelease 内容并下载一个 Excel 文件

让我们熟悉一下发布的内容。有一个流程，一个工作队列和一个环境变量。名为 Ch4 Example 2 Thresholds Excel File Full Path 的环境变量存储了包含 表 4.3 中显示的阈值值的 Excel 文件的路径。默认情况下，它设置为 C:/Users/Public/Ch4 Example 2 Thresholds.xlsx。如果尚未下载，我们需要从 GitHub 下载此 Excel 文件。

图 4.10 – 发布文件内容

1. 从 github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch4/Ch4%20Example%202%20Thresholds.xlsx 下载 Excel 文件。

2. 将 Excel 文件复制到 C:\Users\Public 文件夹，并确保文件名为 Ch4 Example 2 阈值.xlsx。

3. 打开 Excel 文件。此文件存储了不同标签的所有阈值。根据 表 4.3 中选择的阈值，非有毒 标签的阈值设置为 75，有毒 标签的阈值设置为 100。100 表示所有内容都需要人工审核。虽然可以使用环境变量来存储阈值值，但如果存在多个标签，管理起来可能会变得困难：

图 4.11 – 存储在 Excel 文件中的阈值值

接下来，让我们在流程工作室中查看流程并检查与阈值化相关的 BP 阶段。与延迟和状态相关的流程部分将不会在本章的 示例 1 中讨论。

阈值化

在这里，我们将查看 BP 流程中与阈值化逻辑相关的区域。这包括一个将阈值 Excel 文件转换为集合、一个全局数据项和一个检查阈值值的决策阶段：

1. 在流程工作室的 Ch4 组中打开 示例 2 – 阈值化 流程。

2. 注意到有一个名为 Convert Thresholds to Collection 的页面。这个页面将 Excel 文件中保存的阈值映射到集合中。这个 Threshold 集合存储在 Main Page 上作为一个全局数据项：

图 4.12 – Excel 阈值被转换为集合

1. 打开 03 阈值化 页面。有两点需要注意。首先，我们正在通过预测为这个工作队列项目运行所预测的标签来过滤 Threshold 集合。这允许我们按标签设置阈值。其次，在结束阶段之前有一个 决策 阶段，其中包含确定此项目是否需要人工审核的逻辑：

图 4.13 – 决策阶段的阈值化逻辑

运行流程

示例 2 将 10 个静态用户评论加载到工作队列中。有一个有毒用户评论被正确标记为有毒。还有一个用户评论被预测为非有毒，但置信度低，需要 HITL 审核。

1. 在 Control Room 的 Ch4 组下运行名为 示例 2 – 阈值化 的流程。等待会话完成。

2. 在 队列管理 下的 第四章 示例 2 队列 中点击 Chapter 4。

3. 注意到有两个项目因为需要人工审核而被延迟：

图 4.14 – 确认需要人工审核的项目已被延迟

我们已经看到如何将随机抽样和阈值设计到 BP 流程中。这两种方法都使用相同的基本设计结构，包括使用状态和延迟。在随机抽样和阈值之间进行选择是一个商业决策，而不是技术决策。

到目前为止，我们方便地忽略了审阅者如何将审阅过的预测数据提交回 BP。这是下一节的主题。

我们如何共享预测数据在预测审阅者和 BP 之间？

在前两个示例中，我们没有展示如何将纠正过的预测反馈到 BP 中，以便案件可以继续。为了实现这一点，我们需要一个在 BP 和审阅者之间共享数据的地方。有四种常见的方法可以实现这一点：

1. 通过将预测数据复制到共享文件夹位置

2. 通过程序化调用或 API 调用上传预测数据

3. 通过将预测数据存储在数据库中

4. 通过电子邮件或其他消息服务发送数据

上述列表并不全面；例如，可以使用 FTP。然而，使用共享文件夹和 API 调用是共享 BP 和审阅者之间纠正预测所需数据的最常见方式。

我们还需要考虑是否存在服务等级协议（SLA）的担忧，这意味着审阅必须在一定时间内完成，以确保其余的处理可以按时完成。如果是这样，我们可能希望选择具有内在通知功能的审阅方法，例如电子邮件或即时消息。

通过共享文件夹审阅预测

通过共享文件夹在人类和数字工作者之间共享数据是常见的 RPA 实践。然而，当使用共享文件夹来审阅机器学习预测时，设计变得更加复杂，因为需要考虑更多因素。以下是一些例子：

• 什么文件格式（用户界面）最合适？例如，包括纯文本文件、Excel 文件、HTML 文档等等。这取决于需要向审阅者展示多少种类型的数据。如果我们正在验证一段文本是否被正确标记，一个文本文件可能就足够了。如果我们有表格形式的输入数据，例如商店 ID、产品 ID、价格等等，Excel 可能更合适。如果我们需要向审阅者展示图像，我们可以考虑使用基于网络的界面。

• 每个文件中应该包含多少预测？是只有一个，还是我们可以将批量审阅合并在一起？这取决于审阅案例的数量、审阅过程的复杂性、服务等级协议（SLA）以及可供审阅预测的人数。

• BP 如何知道审阅是否已经完成？

让我们通过扩展示例 1 – 随机抽样流程，包括共享文件夹作为界面，在审阅者和 BP 之间传输预测数据来探讨这些设计考虑因素。

示例 3 – 通过共享文件夹复制数据

在示例 1 – 随机抽样流程中，我们根据客户的特点，如职业类别和忠诚度计划中的积分数量，预测客户是否会流失。由于这是表格数据，我们将选择通过Excel来展示这些数据以供复查。

随机抽样率为 33.33%时，许多预测都需要进行复查。业务也认为审查单个案例并不简单。基于这两个因素，团队决定将预测批量分成每个 Excel 文件五个，以便将复查工作分散到多个复查员之间，同时避免让任何一位复查员一次性进行过多复查而感到压力。

我们这个示例的目标是看看我们如何构建一个涉及使用共享文件夹并将多个预测批量放入 Excel 文件的预测复查方案。从高层次来看，我们将进行以下六个步骤：

1. 检查示例的发布文件内容。

2. 看看需要复查的预测是如何首先写入临时文件夹中的 Excel 文件，以及一旦达到批量大小，如何将 Excel 文件移动到“准备复查”文件夹。

3. 看看复查员如何在 Excel 文件中复查预测，并通过将文件复制到“完成复查”文件夹来通知 BP 复查已完成。

4. 理解 BP 逻辑以识别并进一步处理已完成人工复查的项目。

5. 看看如果在会话结束前未达到完整的批量大小，如何复制临时文件夹中剩余的复查。

6. 运行示例，在控制室中查看结果。

检查.bprelease 内容

此示例是预构建的，与示例 1 – 随机抽样中的流程等效，并增加了一些内容。在共同分析此示例时，我们将突出显示这些重要新增内容。

确认您已导入一个流程、一个工作队列和五个环境变量。其中五个环境变量之一，Ch4 Example 3 Random Sampling Target与示例 1中的相同。它存储了我们想要复查的预测百分比（33.33）。Ch4 Example 3 Review Batch Size存储我们想要写入每个 Excel 文件的预测数量（5）。其他三个环境变量是文件路径，用于在 BP 和复查员之间促进数据共享：

图 4.15 – 发布文件内容

将 Excel 文件写入共享文件夹

五个环境变量中的两个是用于存储将展示给复查员的 Excel 文件的文件路径。Ch4 Example 3 To Review Folder Path是一个文件共享文件夹，应该可供复查员访问。流程将 Excel 文件复制到这个文件夹，表示需要复查预测。复查员应定期检查此文件夹，看是否有 Excel 文件在其中。

Ch4 Example 3 Temporary Review Folder Path 是一个由于将多个评审合并到一个 Excel 文件中而引入的复杂情况所需的文件夹。评审人员不需要访问此文件夹，因此它可以是 BP 可以写入的任何 本地文件夹。此临时文件夹的目的是防止评审人员在所有五个评审都写入文件之前打开和锁定 Excel 文件。每个预测将首先写入此临时路径，直到达到批量大小，之后 Excel 文件将移动到评审人员可以访问的文件夹。

重要提示

在将预测写入 Excel 文件时，我们包括所有输入数据，这些数据被输入到机器学习算法中。此外，我们还需要提供 项目 ID，以便我们可以将此预测映射回 BP 工作队列中的项目。需要通知评审人员不要修改电子表格中出现的 项目 ID。

接下来，让我们看看流程图：

1. 在流程工作室的 Ch4 组中打开 Example 3 - Random Sampling with Shared Folders。

2. 打开 Defer Item for Manual Review 页面。

3. 查看名为 Do not Reset to Initial Value 的块。在将不同工作队列项目之间的相同 Excel 文件进行批量写入时，需要两个在页面重新运行时不重置其初始值的 Data Items。当前批量计数跟踪已写入当前 Excel 文件中的预测数量。Excel 文件名存储一个包含运行时资源名称和时间的唯一文件名。在 Excel 文件名中包含运行时资源的名称是逻辑设计的重要部分，因为它允许数字工作者知道它在共享文件夹中创建了哪些文件。

图 4.16 – 两个未重置其值的数据项

1. 检查名为 Writing the Temporary Excel file 的块。块内的逻辑将一个预测写入一个 临时 文件。此临时文件应不可访问给评审人员：

图 4.17 – 将一个预测写入临时文件

Create New Excel File? 决策阶段的 Yes 路径用于创建新的 Excel 文件。No 路径用于将现有 Excel 文件写入以批量合并评审。这些都在 临时 文件夹中完成。

1. 查看紧随 Writing the Temporary Excel File 块之后的四个阶段。在将临时文件写入共享文件夹后，我们增加 Current Batch Count 并检查是否达到了所需的批量大小（存储为环境变量）。如果是这样，我们将文件从 Ch4 Example 3 Temporary Review Folder Path 移动到 Ch4 Example 3 To Review Folder Path，这是评审人员可以访问的共享文件夹：

图 4.18 – 将文件从临时本地文件夹移动到可由审阅者访问的文件夹

理解审阅者所做的工作

本节示例解释了期望审阅者执行的操作。我们在此处不会执行任何操作。审阅者应定期监控Ch4 Example 3 待审阅文件夹路径以查找新的 Excel 文件。审阅者应打开文件并将标签列（以下图中列 I）更改为正确的标签。如果他们认为预测是准确的，他们可以保留标签不变：

图 4.19 – 审阅者应打开 Excel 文件并编辑标签列

编辑并保存 Excel 文件后，审阅者应将文件剪切/粘贴到由Ch4 Example 3 完成审阅文件夹路径环境变量指定的路径。BP 流程将检查此文件夹，遍历所有 Excel 文件及其行，并将每个项目的状态更改为允许处理继续。

如果我们需要允许工作队列项目绕过 HITL 审阅，我们可以在控制室手动更改其状态并修改其延期时间到一个更早的日期时间。

检查已审阅预测并更新项目状态

让我们了解检查已完成审阅的逻辑：

1. 访问流程的“主页面”。注意，在“获取下一个项目”之前有一个名为“检查已审阅预测”的页面：

图 4.20 – 在处理工作队列项目之前检查已完成审阅的情况

1. 打开“检查已审阅预测”页面。此页面遍历Ch4 Example 3 完成审阅文件夹中的所有 Excel 文件并读取所有行。然后，它尝试根据项目 ID 来锁定每个项目，以便更新其状态。更新状态后，项目被解锁，允许它再次被工作队列选中。

2. 定位以下图中所示的四个阶段：

图 4.21 – 锁定项目，更新状态，然后解锁

如果我们成功更新了项目的状态，将设置一个重写 Excel 文件所需标志，表示流程需要从 Excel 文件中删除一些行（已审阅预测）。从完成后的 Excel 文件中删除一行意味着项目可以在审阅后继续处理步骤。

如果我们无法锁定项目，我们将设置一个不同的标志，Failed to Lock，表示我们遇到了这个 Excel 文件的问题。任何我们无法锁定的项目都将添加到一个新的集合中，用于跟踪目的。那些我们未能更新状态的项目将不会从 Excel 文件中删除，以便在未来的会话运行中再次进行检查。

图 4.22 – 将无法锁定到集合中的项目存储

1. 定位以下图中显示的两个阶段。如果Failed to Lock标志表示我们已经成功更新了此 Excel 文件的所有项目状态，则从文件夹中删除 Excel 文件：

图 4.23 – 如果我们成功更新所有五个预测的状态，则删除文件

1. 定位以下图中显示的六个阶段：

图 4.24 – 删除状态成功更新的 Excel 行

如果流程未能更新某些项目的状态，则覆盖 Excel 文件，使其仅包含那些失败的行（这些行已在图 4.22中单独保存）。这从 Excel 文件中删除了状态成功更新的预测。在下一个会话运行时，将执行此检查已审查预测页面，流程将尝试再次更新这些项目的状态。

清理临时文件夹中的文件

Excel 文件可能会卡在关闭``下页面：

1. 打开关闭下页面。注意在结束前有一个移动临时文件页面。

2. 打开移动临时文件页面。此页面遍历临时文件夹中的所有文件，并且只有在它们是由这个特定的运行时资源创建的情况下才会移动它们。此文件夹中由其他运行时资源创建的文件将不会移动。这是通过在 Excel 文件名中检查完整的运行时资源名称来实现的。

图 4.25 – 移动临时文件页面

运行流程

我们现在已经看到了使用 Excel 和共享文件夹实现的 HITL 审查的示例。接下来，我们需要测试该流程。当运行时，将随机生成 30 名客户，算法将预测他们是否会流失。在 33.33%的随机抽样率下，我们预计大约需要手动审查 10 个预测。

重要提示

在测试Example 3时，不要在控制室和流程工作室之间混合运行。这是因为流程工作室会将_DEBUG添加到运行时资源名称的末尾。在移动临时文件和手动审查项延迟页面中，我们使用 Excel 文件名中的运行时资源名称。如果我们一次在流程工作室中运行一次，一次在控制室中运行，运行时资源名称将不会匹配，并且移动临时文件页面不会将一些 Excel 文件移动到审查文件夹。

1. 从控制室开始Example 3 – 使用共享文件夹的随机抽样流程的Ch4组。等待会话完成。

2. 打开控制室并点击第四章 Example 3 队列。应该有许多项目正在等待手动审查。记下需要审查的项目数量。在以下图中，有七个：

图 4.26 – 计算等待手动审查的项目数量

1. 在 Windows 中打开对应于Ch4 Example 3 To Review Folder Path的文件夹。该文件夹中 Excel 文件的数量应该是**(需要审查的项目数量)/5*，向上取整。例如，如果你有七个需要手动审查的项目，我们应该有两个 Excel 文件。

2. 打开每个 Excel 文件，确保每个文件中（不包括标题）的累积行数等于需要审查的项目数量。根据步骤 2中的屏幕截图，我们的第一个文件应有五行，我们的第二个文件应有两行。

3. 将Ch5 Example 3 To Review Folder Path中的所有 Excel 文件剪切并粘贴到Ch5 Example 3 Completed Review Folder Path。这模拟了完成所有机器学习预测审查的过程。

4. 访问 BP 的系统区域。将Ch4 Example 3 Random Sampling Target环境变量从 33.33 更改为 0 并点击应用。这将在下一次会话运行时关闭随机抽样，这意味着 30 个新项目都不需要手动审查。

5. 等待所有延迟的工作队列项的延迟时间通过。

6. 再次从控制室运行流程。将创建一个新的包含 30 名客户的批次并对其进行预测。等待会话完成。

7. 打开控制室并点击第四章 Example 3 队列。所有 60 个工作队列项应标记为完成，没有项目需要手动审查。

8. 在 Windows 中打开对应于Ch4 Example 3 To Review Folder Path、Ch4 Example 3 Temporary Review Folder Path和Ch4 Example 3 Completed Review Folder的每个文件夹。这三个文件夹都应该为空。

在这个例子中，我们展示了如何使用 BP 中的共享文件夹来实现 HITL 审查。由于预测输入数据的表格格式，我们选择了 Excel 作为审查预测的界面。多个预测审查被批量组合并保存到一个文件中。我们还设计了一个共享文件夹结构，以防止数字工人和人工审查员同时打开相同的 Excel 文件。

审查后，审查员将 Excel 文件手动移动到完成文件夹。BP 读取完成的 Excel 文件并更改工作队列项的状态，以便它们可以再次被提取进行处理。最后，我们还展示了如何将随机抽样环境变量设置为 0，完全关闭随机抽样。

摘要

RPA 和 IA 之间的关键区别在于 IA 使用机器学习算法。这使我们的过程从具有确定性结果转变为非确定性结果。随着自动结果的不可预测性增加，我们的业务风险也随之增加。

这导致了一个想法，即让人类重新进入循环，以验证和纠正一部分（不一定全部）的机器学习预测。这使我们能够持续衡量机器学习预测的准确性——鉴于准确性已知会随时间推移而漂移。它还为我们提供了一种操作上降低风险和规避未来监管风险的方法。

在现实生活中，有两种主要方法用于确定哪些预测需要审查。第一种是随机抽样，其中选择所有预测中固定百分比进行审查。随机抽样不会以任何方式查看预测值。接下来是阈值法，它查看置信度分数和有时预测标签。如果一个预测的置信度分数低于阈值值，它会被标记为需要审查。如果置信度分数高于阈值，则自动处理继续进行。

选择合适的阈值是一个复杂的话题。单个标签可以有多个阈值区间。我们也可以为不同的标签设置不同的阈值。通过实验和与业务用户讨论来设置阈值值是一种合理的方法。阈值值永远不会完美——在所需的准确性、基于错误预测处理案件的影响以及您希望不进行人工干预处理的案件数量之间必须做出权衡。

我们可以设计其他方案来确定哪些案件需要人工审查。例如，如果我们有固定数量的审查员和 SLA 来满足，我们可以有一个公式根据工作队列中挂起的项的数量来改变随机抽样率。然而，在我审查了超过 100 个实际的 IA 应用案例之后，我没有遇到比标准随机抽样和阈值法更复杂的。

提供了随机抽样和阈值法的示例，并讨论了它们的设计元素。在我们的设计中，我们使用了状态、延期、共享文件夹以及单个工作队列，以实现一个端到端的人机交互式任务（HITL）解决方案，用于审查机器学习预测。在下一章中，我们将从单个工作队列的设计转向，并讨论我们为何以及如何想要设计一个具有多个工作队列的智能代理（IA）流程。

第五章：HITL 的 IA 流程和工作队列设计

RPA 和 IA 之间的主要区别在于结果的确定性和风险。在某些情况下，人们实施所谓的“IA”，不会产生任何风险。一个将人类输入分类的聊天机器人界面，进而触发传统的 RPA 运行，就属于这一类。虽然聊天机器人部分有 ML，但风险在 RPA 开始之前就被控制并解决了。对于这类 IA 流程，你实际上只需要知道如何与 ML 部分接口（参见第 1、2、3 章），本章可以省略。

对于那些通过创建非确定性流程结果来改变风险配置的 IA 案例来说，你可能会相信，设计一个 IA 流程以适应 HITL 应该是标准做法，即使团队决定保持 HITL 关闭。可能会有预测模型的更新、监管变化、新的业务需求等，这将导致再次启用 HITL 审查。

进程数量和工作队列数量是 IA 解决方案设计师必须做出的两个基本设计决策。几乎所有其他设计元素，例如是否使用标签、状态、延期等，都取决于这两个决策。本章讨论在 BP 中实施 IA 时，何时选择“一个进程与多个进程”以及“一个工作队列与多个工作队列”。重要的是要记住，这次讨论专门针对 IA —— 意味着一种能够实现后续 ML 预测和 HITL 审查的设计。其他涉及工作队列的特定用例设计主题，如父子队列，将不会介绍。

更具体地说，我们将探讨以下内容的优缺点：

• 单 BP 流程、单工作队列设计

• 多 BP 流程、单工作队列设计

• 多个 BP 流程、多个工作队列设计

技术要求

下载并导入 GitHub 上 ch5 文件夹中的三个 .bprelease 文件：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/tree/main/ch5

GitHub 文件夹中还有一个 Excel 文件，它将作为本章的 示例 1 的一部分保存。

单进程、单工作队列设计

如果存在所谓的“默认”解决方案设计，那将是从“蓝 prism 流程模板”创建的单个 BP 流程和单个工作队列。正如我们在第四章的例子中看到的那样，这种“简单”的设计绝对可以用于 IA。

在本节中，我们将讨论涉及单个进程和单个工作队列的两个主要 IA 解决方案设计，包括它们的优缺点以及何时选择它们。

异步（非阻塞）审查

在异步审查设计中，BP 流程不等待当前项目被审查，以便它可以继续处理。相反，流程暂停对当前需要 HITL 审查的项目的工作，并继续处理下一个项目。这可能是大多数 IA 流程应该被设计的方式，因为审查者通常无法预测何时需要审查项目或项目实际审查需要多长时间。

三个例子都来自第四章，它们都被设计成异步操作。状态决定项目何时处于待审查状态，而延期防止项目被获取下一个项目操作选得太快。

让我们从功能性、可维护性（从未来修改的难易程度来看）和可操作性的角度来评估这种异步审查设计。我们将使用这三个标准来评估本章中所有设计。

功能性

此设计允许工作队列项目无限期地延期，直到它们被人工审查。未延期的项目可以继续自动化处理。

流程不断在两个不同的操作周期之间切换。第一个周期是创建审查数据和检查完成的 HITL 审查。下一个周期是选择项目进行传统的 RPA 处理。

可维护性

在可维护性方面，所有逻辑，无论是业务逻辑还是 IA 相关的逻辑，都包含在一个单一的 BP 流程中。这并不明显是好事还是坏事，因为有些人认为它比多流程解决方案更容易维护。我的观点是，在单一流程中包含太多内容——在我们的案例中，业务逻辑、ML 调用代码和 HITL 逻辑——会使解决方案的可维护性降低。将所有内容都包含在一个流程中，防止多个开发者同时编辑它，这在逻辑很多的情况下是不理想的。

可操作性

控制器需要知道如何检查项目状态，以便找出哪些项目尚未被审查。他们需要确切知道哪些状态存在，这样他们就可以在控制室中手动编辑状态。这样他们就可以强制项目继续自动化处理，即使它被标记为需要审查。无论选择的具体流程和工作队列设计如何，从 RPA 迁移到 IA 时，总会增加操作复杂性。

控制器还需要找出等待审查的项目是否陷入僵局。有可能数字工作者和审查者之间共享的数据，无论是共享文件夹中的 Excel 文件、数据库记录还是网络界面，被错误生成或意外删除。

优点

异步审查设计的优点在于所有内容都包含在一个流程中，这使得会话使用（许可证消耗）易于预测。调度管理也相对简单。这对需要仔细控制许可证使用方式的公司来说是有益的。由于我们只有一个工作队列，所以从控制室中可以清楚地看到关于案件总工作时间的统计数据。

缺点

这种设计的缺点之一是，工作队列项目在审查后不能立即开始工作（假设这是可取的）。它必须等待延期时间过去，才能由获取下一个项目来获取。

这种设计的另一个缺点是，为了更新已审查预测的状态，检查应可能发生在流程模板的工作块之外。在下面的图中，我们看到流程在处理新项目之前检查了已完成的人工审查：

图 5.1 – 检查已审查的预测应仅在项目之间进行

这是因为检查已完成审查的逻辑与被获取下一个项目锁定的项目特定的逻辑无关。我们不希望审查检查逻辑中发生的异常导致正在处理的项目也成为异常。将检查逻辑放在工作块之外所做的妥协是，如果那里发生异常，流程可以终止。一个双流程设计可以将审查检查逻辑与实际业务流程逻辑解耦，从而减轻这个问题。

关于这种设计的另一个担忧在于执行审查检查与实际处理案件所花费的时间量。它们是两个相对独立的活动，需要在同一会话中运行。根据实际情况，你可能会在审查检查逻辑上花费大量时间，从而负面影响处理案件的处理能力。想象一下，检查已完成审查需要登录到自定义网站。如果这个网站速度慢或需要在多个页面之间进行大量导航，由于检查已完成审查而使用获取下一个项目来获取案件之间的差距可能会变得非常大。

一个完整的单一流程、单一工作队列、异步设计的例子可以在第四章，示例 3中找到。

既然我们已经讨论了异步审查设计的优点和缺点，让我们看看一种不同的单一流程、单一工作队列设计，用于同步审查。

同步（阻塞）审查

如果我们有SLA 要求，需要手动审查在短时间内完成，我们应该考虑同步审查设计。在这个设计中，流程会阻塞并等待工作队列项目审查完成后再继续。

功能性

在同步审查流程中，我们必须完成当前项目，包括等待 HITL 审查，然后才能继续处理其他项目。当 IA 支持实时客户互动时，这通常是所希望的。回想一下，有一个真实的 IA 用例，其中 ML 被用来帮助验证药物处方。根据这种设置的使用情况——例如药店、医生办公室或医院——客户对收到药物的需求可以被认为是“实时”的，时间短至几分钟。

在同步审查设计下，BP 流程进入轮询循环，阻塞并持续检查预测是否已审查。如果审查在 SLA 期限内完成，则自动处理继续。如果 ML 审查没有在 SLA 期限内完成，则案件被标记为异常。

可维护性

与异步设计类似，所有内容都包含在一个单个进程中，这对大多数开发者来说可能是可维护的。实现轮询循环的逻辑比异步设计的逻辑简单，即使是新开发者也能轻松掌握。

可操作性

与异步设计相比，控制室操作简单。在时间限制内未审查的项目被标记为异常。控制器实际上不需要与非 IA 解决方案不同的操作。

优点

除了解决方案的整体简单性之外，这种设计没有太多优点。它易于理解，修改轮询逻辑，安排和预测许可证使用。选择这种设计的最强理由是能够实现实时审查。

缺点

这种设计的最大缺点是显著降低的案件吞吐量，这是为了满足个别案件 SLA 而做出的权衡。如果案件数量也很大，需要同时运行更多的 BP 会话，从而导致使用更多许可证。在轮询循环中不可避免地会浪费时间，而且这种浪费随着 SLA 期限的延长而增加。

让我们来看一个医院设置中这种单进程、单工作队列阻塞设计的例子。从高层次来看，我们将进行以下四个步骤：

1. 检查示例的发布文件内容并导入额外的依赖项。

2. 理解创建带有图像的.html审查文件的逻辑。

3. 检查用于实现同步审查的轮询逻辑。

4. 运行示例，在控制室中查看结果。

示例 1 - 轮询已审查的预测

在本例中，我们将使用之前描述的处方药场景。想象一下，我们正在为一个每天处理约 200 名患者的私人医院项目工作。预计每位患者都需要从医院药房获取药物。为了缩短患者等待时间并提高药房的患者满意度，医院正在寻求使用基于图像的机器学习来自动 计数常用处方的药片数量。

机器学习团队已经为多种药物类型构建了模型，并确定了需要人工干预进行手动审阅的阈值。为了满足项目的目标（减少患者等待时间），我们决定采用阻塞过程设计，其中数字工作者最多等待 两分钟 进行预测审阅。一支由受过培训的远程工作人员组成的小团队将负责使用简单的 Web 界面进行手动审阅。选择 Web 界面是因为审阅者需要查看药物图片。

数字工作者会将 .html 文件保存到网络共享文件夹中。一个 .html 文件包含处方药的图片和一个下拉列表，供审阅者选择图片中显示的药物剂量。.html 文件名将包含项目 ID。批量大小的概念在此情况下不适用，因为我们不希望在单个 .html 文件中审阅多个预测。

我们的第一步是验证 .bprelease 文件的内容，并导入本例所需的额外文件。

验证发布内容并导入依赖项

在这里，我们将检查 .bprelease 文件内容，并从 DX 导入第三方资产。然后，我们将下载包含人工审阅阈值的 Excel 文件，并确保将其保存到正确的位置：

1. 验证是否已导入 一个 流程、一个 工作队列和 四个 环境变量：

图 5.2 – 示例 1 的发布内容

1. 下载并导入 .html 文件。注意，如果您已经完成了第二章中“示例 3，GCP Cloud Vision 批量 OCR 处理”部分，则此步骤已完成。如果实用工具 – 文件操作已经导入，则忽略此步骤。

2. 从 github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch5/Ch5%20Example%201%20Thresholds.xlsx 下载 Excel 文件。该文件包含触发不同药物类型审阅的阈值。

3. 将 Excel 文件复制到名为 C:/Users/Public/Ch5 Example 的环境变量指定的路径中 1 Thresholds.xlsx。

4. 打开 Excel 文件。此文件存储不同类型药物（如果我们有更多药物类型，我们可以在电子表格中添加更多行）的阈值：

图 5.3 – 阈值配置 Excel 文件

1. 定位名为.html文件的环境变量，作为审查预测的接口。在审查者审查完预测后，他们预计会按下名为提交已审查预测的按钮，这将触发浏览器文件下载对话框弹出或自动将文件下载到您的 PC 上。该行为取决于您的浏览器设置。

图 5.4 – 静态.html 审查界面

在更现实的情况下，我们不会使用静态的.html文件。我们会使用一个提供审查网页的 Web 服务器，按下提交按钮会自动将必要的文件复制到共享位置。这将消除用户下载文件的需求。然而，设置 Web 服务器超出了本书的范围，并且对于说明同步审查设计的概念是不必要的。

接下来，让我们看看流程图。大部分流程结构与第四章中的示例 2 – 阈值相同。这里将突出显示重要的差异。

检查.html 文件创建逻辑

解决方案的一个重要部分在于我们如何在数字工作者和审查者之间实现数据共享接口。由于图像是审查数据的一部分，我们选择了一个网页浏览器和 HTML 表单作为审查界面。让我们看看这是如何实现的：

1. 在流程工作室的Ch5组中打开示例 1 – 轮询已审查预测。

2. 定位并打开03b 将图像写入 HTML 模板页面。此页面在我们知道需要手动审查预测之后执行。

3. 查看启动后的前三个动作阶段。第一个动作将药物图像写入文件。第二个动作将图像内容以 Base64 字符串的形式读回 BP。第三个动作删除由动作 1 创建的图像文件。其目的是将图像转换为 Base64 编码，以便可以直接嵌入到.html文件中。

4. 查看 Multi Calc 阶段。在这里，Base64 图像字符串被替换为包含选择列表 HTML 模板的Text数据项，一个Text数据项被保存为.html文件，以项目 ID 作为文件名，存入由Ch5 Example 1 To Review Folder Path环境变量指定的路径：

图 5.5 – 将图像作为 Base64 嵌入到 HTML 文件中

1. 打开存储在 CDN 上的.js文件，这意味着这个例子需要互联网连接才能运行。

2. 检查以下 JavaScript 代码，这是 HTML 模板数据项的一部分。当在 HTML 表单中按下提交按钮时，JavaScript 被触发，显示文件下载对话框。此文件下载对话框默认将文件名命名为当前项的 ID，并将已审查的预测值作为文件内容存储：

   document.getElementById('saveFile').addEventListener('click', function(e) {
   var text = document.getElementById("reviewed").value;
         var filename = document.title + ".txt";
         var file = new File([text], filename, 
        {type: "text/plain;charset=utf-8"});
         saveAs(file);
   });
   

我们现在应该了解数字工作者如何与审查者交换数据。BP 在由Ch5 Example 1 To Review Folder Path环境变量指定的路径中创建一个以当前项 ID 命名的.html文件。

审查者手动监控此文件夹，并在他们的默认网络浏览器中打开任何出现的.html文件。.html文件包含药物的图片，一个供审查者选择正确药物剂量的下拉列表，以及一个提交表单的按钮。.txt文件被写入磁盘，其中包含下拉列表的值（人工审查的药物量）作为内容。

检查轮询逻辑

现在我们来检查使轮询逻辑工作起来的两个主要部分。第一部分是一个等待循环，如果超过最大等待时间，则抛出异常；第二部分是清理.html和.txt文件：

1. 前往主页面。注意在工作块内部，我们添加了一个名为等待审查预测的新页面。此页面包含轮询审查预测的逻辑，如果需要审查，则通过轮询来阻止执行：

图 5.6 – 等待审查预测页面包含轮询逻辑

1. 打开等待审查预测页面。

2. 定位名为当前项 ID 的.txt文件块。这是通过按下.html审查文件保存的同一.txt文件。如果在最大超时值（由Ch5 Example 1 Max Timeout Seconds环境变量指定）达到之前没有找到确切的文件，我们将继续轮询。如果在最大允许的超时时间内没有检测到文件，将抛出异常：

图 5.7 – 轮询逻辑

1. 查看在找到以当前项 ID 命名的.txt文件之后的六个阶段，工作队列状态被更新。修订后的预测被读回到 BP 中，并且.txt文件被删除：

图 5.8 – 读取修订后的预测并删除.txt 文件

重要提示

更新状态对于此单个工作队列轮询设计是否正确运行不是至关重要的。它保留在这里是为了在异常或停止后重试项时跳过主页面上的步骤。然而，更新状态对于异步审查设计至关重要。在那里，状态被用来反复推迟项，直到它被审查。

1. 在本页的最后一步，找到已删除的 .html 文件。即使它仍在审查员的浏览器中加载，也可以安全地删除 .html 文件，因为现代浏览器的工作方式是这样的：

图 5.9 – 删除 .html 文件

运行流程

此流程将 10 个随机生成的项目加载到名为第五章 示例 1 队列的工作队列中。由于随机生成，此流程可能需要多次运行，才能选择一个图像进行人工审查。平均而言，每个会话运行应有四个项目需要人工审查。机器学习算法不是真实的 – 它是一个占位符，基于随机数。

我们将运行查询流程，并让两分钟过去。这应该会导致第一个项目被标记为异常，因为审查没有在超时期间完成。然后，我们将手动审查所有后续项目，在它们的两分钟限制内完成。这应该会导致所有其他项目被标记为已完成：

1. 前往控制室，找到Ch5组，并启动名为示例 1 – 查询已审查预测的流程。不要等待会话完成。

2. 在 Windows 文件资源管理器中打开已配置为Ch5 示例 1 审查文件夹路径环境变量的文件夹。

3. 等待出现 .html 文件。一旦出现文件，审查员在项目被标记为异常前有 120 秒的时间：

图 5.10 – .html 文件出现在审查文件夹路径中

1. 等待 120 秒，让项目过期，并打开名为第五章 示例 1 队列的工作队列。注意，控制室中显示的项目键与项目 ID（.html 文件的文件名）不同：

图 5.11 – 当超过最大等待时间后，项目将被标记为异常

1. 返回 Windows 文件资源管理器，等待另一个 .html 文件出现。尽快在你的网络浏览器中打开文件。通过选择药物剂量并点击提交已审查****预测按钮来审查预测：

图 5.12 – 进行人工审查并提交

1. 如果出现另存为对话框，请确保文件夹与Ch5 示例 1 已完成审查文件夹路径环境变量的值匹配。保存文件时不要重命名。如果你的浏览器设置为自动下载文件，则可能不会出现另存为对话框。

2. 重复步骤 5和步骤 6，审查出现的任何 .html 文件，直到会话执行完毕。

3. 一旦会话运行完成，打开第五章 示例 1 队列工作队列，你会看到除了一个之外的所有项目都被标记为完成：

图 5.13 – 除了一个之外的所有项目都已完成

在这个例子中，我们看到了如何通过一个单个进程和单个工作队列，结合轮询循环，来满足需要实时 HITL 审查的 IA 用例。我们还设计了一种通过将图像写入.html文件来审查图像的方法。

接下来，让我们将讨论从单个进程设计转移到多进程设计。

重要提示

虽然你可以设计一个单个BP 流程与多个工作队列，但对于 IA 来说，这样做并没有明显的理由。作为一个一般的设计规则，避免为单个 BP 流程拥有多个工作队列。当有多个工作队列可以作为正在处理的项目来源时，很难追踪流程流程，这会降低可维护性。一个例外是，如果额外的队列不是工作项目的来源，例如在父/子工作队列设计中，只有项目状态、标签或数据被更新。

多进程、单工作队列设计

在 IA 的背景下，你可能希望有多个 BP 流程在仅单个工作队列上工作的三个主要原因。第一个是为了保持不同逻辑部分的分离。我们将在本节的后面看到这个例子，其中一个 BP 流程主要用于业务逻辑，其他流程用于存放解决方案设计中的 ML 部分的特定逻辑。将这些逻辑分开使得对业务逻辑的将来修改更容易管理。

下一个原因与第一个原因密切相关。我们可以将解决方案分解为不同的进程来提高可重用性。正如你可以想象的那样，实现随机抽样、阈值设置、通知审查员预测已准备好审查等逻辑，在多个 IA 进程中可能是可互换的，并且可以将其作为它们自己的进程来实现。

第三个原因是为了使整体流程的不同部分能够不同比例地扩展。想象一下，我们正在将一个新的 IA 流程投入生产，并且随机抽样百分比设置为 100%，以强制在超期期间对每个 ML 预测进行人工审查。如果有一个专门用于检查已审查预测的 BP 流程，我们可以在更多的数字工作者上运行它，以防止在此期间出现瓶颈。一旦我们对 ML 模型的准确性和性能感到满意，随机抽样百分比和需要审查检查流程的会话数量可以降低。

在下一节中，我们将讨论一个多进程、单队列IA 设计，其中手动审查的逻辑被分割到它自己的进程中。本节还包含一个示例。

独立的手动审查逻辑

我们之前看到的审阅检查逻辑可以被放入一个单独的进程，从而将其与业务逻辑解耦。以下图表展示了这在高层次上的设置方式。

图 5.14 – 双进程、单队列设计

图表中的进程 1执行所有业务逻辑步骤，包括进行机器学习预测。进程 2使用与进程 1相同的工作队列，仅负责与 HITL 审查相关的逻辑——将数据传输给审稿人并检查完成的审稿。其主要目的是更新工作队列项目状态，以便进程 1在项目被审阅后可以继续对项目进行自动化处理。

功能性

此设计的主要功能是允许进程 1将所有时间都用于执行业务逻辑，而不是 IA 解决方案逻辑（编写共享数据和检查已审阅的预测）。它允许两个活动独立扩展。例如，你可以为进程 1分配多个会话来运行，而只为进程 2分配一个会话，或者相反，具体取决于你的实际需求。

可维护性

通过从单个进程转换为两个进程，每个进程总体上变得更加易于维护。但解决方案的整体复杂性增加了，因为开发者需要理解两个进程如何影响项目的执行流程。随着 IA 团队经验的积累和文档实践的提高，这种复杂性显著降低。

可操作性

单进程、单队列示例通过遍历完成文件夹的内容来检查审阅是否完成。这个完成文件夹可以是 API 调用、数据库或其他系统。在“完成位置”的文件或记录中必须包含对项目 ID的引用。BP 必须能够根据项目 ID 锁定项目以更新其状态，以便它可以继续所需的自动化处理。

从操作角度来看，将项目 ID 直接暴露给审稿人是不稳定的。有人可能会意外地（或故意地）修改项目 ID。这可能导致工作队列项目永久卡住，无法再进行审阅，或者更新了与预期不同的项目的状态。

通过遍历数据传输位置的选择方案是遍历待审阅项目的工作队列。不幸的是，获取下一个项目无法根据状态进行筛选。然而，我们可以根据标签筛选工作队列，我们将在接下来的示例中实现这一点。我们还需要将文件路径或第三方系统 ID 存储为工作队列数据，这样就不需要将项目 ID 暴露给审稿人。

此外，由于我们计划遍历每个待审查的项目，我们可以确保审查数据被正确持久化，并在必要时重新创建它。在我们的先前设计中这是不可能的，因为我们只遍历完成文件夹的内容，而不是需要审查的完整集合。

讨论

你可能想知道我们是否可以在我们的单进程、单工作队列示例中添加标签，以防止将项目 ID 暴露给审查者。虽然在技术上可行，但在实践中，这会占用太多时间，无法根据业务逻辑实际处理项目。回想一下，我们先前示例中的审查检查逻辑位于主页面工作块之外。如果待审查的项目数量很多，或者检查待审查项目是否已审查需要超过几秒钟的时间，我们可能会花费大量时间仅进行此检查。

优点

在单进程、单队列设计中，审查检查是在流程模板的工作块外进行的。在工作块外发生的异常可能会导致终止。采用双进程设计，可以将审查逻辑放入其自己的工作块。发生的异常不再导致立即终止。这使得这种设计非常适合检查完成的审查具有复杂逻辑的场景，例如登录到网络界面。

虽然有些人可能认为这种解决方案比只有一个进程更难维护，但我认为现在维护包含业务逻辑的主要进程更容易，因为大部分 IA 解决方案逻辑已经被移出。业务逻辑在 IA 解决方案的生命周期中更容易发生变化。转向双进程设计也实现了重用和目标扩展。

缺点

与单进程设计相比，这种双进程、单工作队列设计的主要缺点是，获取工作解决方案所需的最小会话数是两个。调度也变得更加复杂。

遍历每个标记为人工审查的项目，无论其是否已审查，都会不必要地增加该项目的总工作时间。这种双进程、单队列设计的负面后果是，案例持续时间统计将高于单进程设计。

另一个缺点是由于将持久化预测数据的逻辑移动到新进程中，以便与审查者共享。由于我们将该任务卸载到不同的进程，我们实际上在 ML 预测后不再立即保存审查数据。我们可能需要频繁地运行进程 2 的会话，以确保及时创建审查数据。

接下来，让我们通过一个示例来查看这种单工作队列、双进程设计的实现。从高层次来看，我们将进行以下五个步骤：

1. 验证发布内容。

2. 确认 HITL 审查逻辑已被移出流程 1。

3. 理解已移入流程 2 的功能。

4. 运行流程 1，并在控制室中查看结果。

5. 运行流程 2，并在控制室中查看结果。

示例 2 – 独立手动审查逻辑

假设我们将从第四章的示例 3中部署客户流失示例到生产环境中，这是第一次。在我们的超期关注期间，我们希望审查每一个机器学习预测。根据案例数量、超期关注期间以及零售购物的整体季节性，我们希望修改我们最初的单一流程设计，并将审查逻辑拆分出来，以便它可以独立扩展并在多个会话中启动。我们仍然会保留一个单一工作队列。

这个发布已经开发完成。让我们检查审查逻辑是如何拆分到一个单独的流程中，并执行它以了解它如何可以独立扩展和维护。

验证发布内容

这个发布的内容与第四章的示例 3相似，除了有一个额外的流程：

1. 验证已导入两个流程、一个工作队列和五个环境变量（环境变量的描述可以在第四章的示例 3中找到）！

图 5.15 – 示例 2 的发布内容

1. 验证Ch5 示例 2 随机抽样目标环境变量是否设置为100.0，这意味着所有机器学习预测都将按照超期关注期间的要求进行审查。

验证主要流程不再包含与审查相关的逻辑

让我们确保包含主要业务逻辑的流程不再包含与创建 Excel 文件和更新项目状态相关的逻辑：

1. 在流程工作室的Ch5组中打开名为示例 2A – 随机抽样的流程。

2. 在主页面上，可以看到在获取下一项阶段之前没有页面来检查已审查的预测；这个逻辑已经被从该流程中移除：

图 5.16 – 没有页面来检查已审查的预测

1. 打开任意的主页面。可以看到已添加了一个标签过滤器，以不选择任何带有手动审查 所需标签的项目。

2. 看到在主页面上的工作队列名称被设置为第五章 示例 2 队列：

图 5.17 – 注意队列名称

1. 打开名为更新状态和标签以进行手动审查的页面。可以看到不再有任何将 Excel 文件写入磁盘的逻辑。还可以看到我们正在将需要 HITL 审查的项目标签设置为手动 审查所需。

我们已经完成验证主流程不包含与 HITL 审核相关的逻辑。接下来，让我们看看这个设计的第二个进程，它包含将审核数据写入磁盘和检查完成审核的 IA 逻辑。

检查审核预测的进程

第二个进程是使用标准的 BP 进程模板开发的。我们将看到所有关于 HITL 审核的逻辑都已移动到这个新进程中：

1. 在流程工作室的Ch5组下打开示例 2B – 人工审核逻辑流程。

2. 注意到主页面上的队列名称也设置为第五章示例 2 队列，与示例 2A – 随机采样进程中的工作队列相匹配。两个进程都从同一个队列工作。

3. 打开任何主页面。注意有一个标签过滤器，用于选择带有需要人工审核标签的项目。

4. 查看主页面上的工作块。有两个步骤。首先，审核数据写入共享文件夹。接下来，我们检查项目是否已移动到完成文件夹，这表示它已被审核。将这些步骤放入工作块中，使我们能够从异常中优雅地恢复，并从控制室重新尝试项目：

图 5.18 – 与审核逻辑相关的两个步骤在工作块中

1. 打开02 检查已审核的预测页面。

2. 定位到更新项目块。注意当项目被审核时，我们正在更新状态并移除标签。此页面上的剩余逻辑与共享文件夹文件管理相关：

图 5.19 – 更新项目的状态和标签

到目前为止，我们已经看到进程 1 不再包含 HITL 审核逻辑，并且两个进程共享相同的工作队列。进程 2 移除了主页面以跳过项目重试时的步骤。

运行主流程

让我们运行主进程并检查工作队列。此进程随机生成 13 个项目以填充工作队列并执行机器学习预测。我们应该看到所有项目都将停止处理，等待人工审核：

1. 定位到Ch5文件夹，并在控制室中运行示例 2A – 随机采样。等待会话完成。

2. 查看第五章示例 2 队列的内容。注意所有 13 个项目都有需要人工审核的状态和标签，因为我们的随机采样率设置为 100%：

图 5.20 – 所有项目都需要人工审核状态

1. 打开 Windows 文件资源管理器，导航到在Ch5 示例 2 审核文件夹路径环境变量中定义的文件夹。检查此文件夹中是否有 Excel 文件。这是因为将审核文件写入磁盘的逻辑已移动到进程 2，而进程 2 尚未运行。

运行 HITL 审查检查逻辑进程

第二个进程将审查数据写入共享文件夹并检查完成的审查。这应该与之前的进程同时运行。然而，为了方便使用 BP 试用版的读者，我们将按顺序运行进程。在这里，我们将在再次运行第二个进程之前审查 13 个预测中的 8 个：

1. 定位到Ch5组，并在控制室运行示例 2B – 手动审查逻辑进程。等待会话完成。

2. 打开 Windows 文件资源管理器，导航到在Ch5 Example 2 待审查文件夹路径环境变量中定义的文件夹。确认该文件夹中有三个 Excel 文件。其中两个 Excel 文件应有五个需要审查的项目（根据批量大小），一个文件应有三个，总共 13 个。注意项目 ID 不再作为文件中的列。

3. 将包含五个预测和一个包含三个预测的文件剪切并粘贴到在Ch5 Example 2 完成审查文件夹路径环境变量中定义的文件夹中。这模拟了审查员在完成两个 Excel 文件的审查后所做的工作，总共八个预测。

4. 再次在控制室运行示例 2B – 手动审查逻辑。等待会话完成。

5. 查看第5 章的示例 2 队列工作队列，以确认 8 个项目的状态被设置为手动审查完成并且已被取消标记：

图 5.21 – 八个项目已更新其状态并移除其标记

1. 打开 Windows 文件资源管理器，导航到在Ch5 Example 2 完成审查文件夹路径环境变量中定义的文件夹。验证该文件夹中不再有任何 Excel 文件。

到目前为止，有 8 个项目已被取消标记，这意味着它们可以被进程 1 的获取下一个****项目动作选中。

再次运行主进程

我们将重新运行主进程并假装它从未停止过。虽然将创建 13 个新的工作队列项目，但我们更感兴趣的是看到之前运行中的 8 个项目被标记为已完成：

1. 再次在控制室运行示例 2A – 随机抽样。等待会话完成。

2. 查看第5 章的示例 2 队列内容。注意 26 个项目中有 8 个被标记为已完成。

在这个例子中，我们看到了如何将审查检查逻辑分离成它自己的进程，独立于主要业务逻辑。这有几个好处，包括促进可重用性，允许业务逻辑与审查检查逻辑独立扩展。通过消除向审查员暴露项目 ID 的需求，并将审查检查逻辑定位在异常处理块内，整体的数据传输设计鲁棒性也得到了提高。

现在，让我们从多进程、单工作队列的设计转向，探讨为什么我们可能想在 IA 中使用多进程和多工作队列。

多进程、多工作队列设计

添加新的进程和工作队列是向现有的 BP 解决方案添加机器学习的好方法，因为大部分原始设计和流程图可以保持不变。虽然添加更多的工作队列会导致整体设计更加复杂，但它们可以在审计等方面为我们提供一些细微的改进，因此值得考虑。

让我们来看看一个两进程、两队列的 IA 解决方案设计的优缺点，其中需要人工审核的工作队列项被保存在一个单独的工作队列中。

完全独立的人工审核

双进程、单工作队列设计的缺点之一是，由于对每个项目的重复检查，案例持续时间统计最终会更高。如果我们将所有需要审核的项目推入一个新的工作队列，我们就可以将处理业务逻辑所花费的时间与审核检查所花费的时间分开。

这种两队列设计在以下图中展示。第一个进程执行业务逻辑，包括进行机器学习预测。如果一个项目需要人工审核，则只有与审核相关的数据会被推入工作队列 2。进程 2 将审核数据保存在审核界面中，并检查审核是否完成。如果审核完成，它将在工作队列 1 中更新项目状态，以便自动化处理可以继续：

图 5.22 – 双进程、双工作队列设计

功能性

这种设计的功能与多进程、单工作队列设计相同。我们可以将进程 1 的所有时间都用于执行业务逻辑，并且我们可以对两个进程进行独立扩展。添加新的工作队列不会影响功能。

可维护性

与双进程、单队列设计相比，这种设计实际上提高了可维护性。工作队列的添加导致了业务逻辑和 HITL 审核逻辑之间更加清晰的分离。

可操作性

新增工作队列最直接地影响了我们操作 IA 解决方案的方式。虽然能够隔离执行业务逻辑和人工审核逻辑所花费的时间是有用的，但报告和控制室操作可能会变得更加复杂。如果你想要查看一个项目完成所需的时间，包括审核逻辑时间，你需要在报告中将两个队列的案例持续时间相加。这实际上应该是对自动报告的一次性更改。控制器还需要在两个工作队列之间导航，同时记住项目键，以全面了解项目的状况，这会给操作带来不便。

优点

这种设计的主要好处，这在未来将变得越来越重要，是第二个工作队列使得简化 HITL 审计成为可能。由于我们只推送执行人工审核所需的最小数据量，因此可以轻松导出流程 2 的会话日志或工作队列数据，而不会暴露不必要的数据。如果我们需要频繁回答以下问题，我们应该强烈考虑实施这种流程设计：

• 机器学习预测的原始输入是什么？

• 谁进行了审核？

• 修订的标签是什么，为什么？

虽然现在可能看起来并不相关，但这些正是监管机构和法律法院会询问的问题，即机器学习预测是否对用户或客户造成了伤害或损害。

重要提示

如果使用 Windows 文件系统作为数据共享方法，你必须明确启用基于文件夹或文件的审计。这将生成安全事件，允许你找出哪个用户修改了文件（审核了预测）。

仅包含经过人工审核内容的隔离工作队列或会话日志数据可以轻松地反馈给开发算法的数据科学家。如果我们没有这个干净的校正数据源，我们就需要通过程序过滤会话日志并删除任何无关数据来生成它。这种设计的主要好处是简化了 HITL 审计，并使数据反馈给机器学习模型开发者成为可能。

最后，这种设计非常适合将现有的 RPA 流程转换为 IA 流程，因为现有的 RPA 设计可以基本保持不变。

缺点

大多数的负面因素是之前讨论过的操作不便。现在必须跨多个工作队列跟踪项目，报告变得更加复杂。

既然我们已经讨论了两个流程，两个工作队列的设计，让我们再进一步，将机器学习预测逻辑也分离出来。

将机器学习预测和人工审核分离到它们自己的流程和工作队列中

如果我们需要将简化审计扩展到涵盖所有机器学习预测，我们可以将机器学习算法调用步骤和数据移动到它们自己的流程和工作队列中。这将导致三个流程，三个工作队列的设计，如下面的图所示：

图 5.23 – 三流程，三工作队列设计

我们的第一流程和工作队列包含标准业务逻辑。所有需要做出的机器学习预测都被添加到工作队列 2，由流程 2 处理。流程 2 执行机器学习算法，生成预测，并决定是否需要人工审核。如果不需要人工审核，项目的状态将在工作队列 1 中更新，以便自动化处理继续。如果需要人工审核，项目将被推入工作队列 3。流程 3 创建 HITL 审核所需的数据，并在审核完成后在工作队列 1 中更新项目状态。

功能性、可维护性和可操作性

这些与两流程、两工作队列设计大致相同。

优点

与两流程、两工作队列设计相比，好处大致相同，但我们获得了对所有机器学习预测的额外审计选项。

缺点

这种设计与两流程、两工作队列设计存在相同的问题。根据业务需求，如果需要将多个工作队列的执行时间相加，报告可能会更复杂。控制器将更难跟踪三个不同工作队列中案件的情况。

接下来，让我们通过一个示例来查看这种三流程、三工作队列设计的实现。

示例 3 – 完全分离

在这个例子（基于一个真实的 IA 案例）中，我们正在自动化一个国家公用事业公司的客户索赔流程。每月处理 5,000 个索赔。当前的未自动化流程需要人工判断，并且有 25 种可能的客户索赔解决方案。

这个国家公用事业公司开发了一个机器学习推荐系统，显示前三个解决方案建议及其置信度分数。当前两个建议的置信度分数相差在 5%以内时，将触发人工审查。这是一种更复杂的阈值形式，其中预测标签之间存在依赖关系。

案例通过包含三个建议、它们的置信度水平、相关案例数据和客户数据的 Web 界面进行审查。由于该解决方案是为国家公用事业公司设计的，IA 团队希望走在法规的前面，并实施一个促进所有机器学习预测和人工审查审计的解决方案设计。

本例的目的是说明实现三流程、三工作队列设计所需逻辑。从高层次来看，我们将进行以下 11 个步骤：

1. 验证发布内容并配置环境变量。

2. 检查流程 1 的（业务逻辑）“主页面”。

3. 看看数据是如何推入机器学习队列（队列 2）的。

4. 检查流程 2 的（机器学习预测）“主页面”。

5. 检查流程 3 的（HITL 审查）“主页面”。

6. 运行流程 1 并查看控制室的结果。

7. 运行流程 2 并查看控制室的结果。

8. 运行流程 3 并查看控制室的结果。

9. 审查一个预测。

10. 再次运行流程 3 并查看控制室的结果。

11. 再次运行流程 1，并在控制室查看结果。

验证发布内容并配置环境变量

让我们熟悉.bprelease并配置一个环境变量：

1. 确认已导入三个流程、三个工作队列和三个环境变量：

图 5.24 – 示例 3 的发布内容

1. 打开名为Ch5 示例 3 完成审查文件夹路径的环境变量。更改值以匹配您网络浏览器的默认下载文件夹。不要在文件夹名称末尾添加尾随斜杠。

检查流程 1 的主页面

接下来，让我们看看第一个流程，它包含主要业务逻辑。这接近于添加任何 IA 组件的 RPA 流程的外观。我们将突出显示使此解决方案设计功能化的区域：

1. 在流程工作室的 Ch5 组中打开示例 3A – IA 业务逻辑。

2. 打开任何“主页面”。注意已添加了一个标签过滤器，以避免选择带有等待机器学习预测或手动审查****必需标签的项目：

图 5.25 – 获取下一个项目在两个标签上的过滤器

1. 查看工作块。有一个名为“03 推送至队列 2”的页面，负责将此流程连接到执行所有机器学习预测的流程 2。所有执行路径都导向此页面，这意味着所有项目最终都将被推送到队列 2 进行机器学习预测：

图 5.26 – 03 推送至队列 2 页面

1. 注意在“03 推送至队列 2”之后有一个“解锁项目”页面。

在这里，我们看到了在“获取下一个项目”中使用了标签过滤器，以便不选择需要手动审查或机器学习预测的项目。

接下来，让我们看看在“03 推送至队列 2”页面会发生什么。

将项目推入机器学习工作队列

“03 推送至队列 2”页面在工作队列 2 中添加了一个新项目，标记了当前项目，并将对工作队列 2 中新创建项目的引用添加到当前项目的数据中：

1. 打开“03 推送至队列 2”页面。

2. 查看与开始连接的前三个动作。第一个动作将现有项目数据复制到一个新集合中，省略了与机器学习预测无关的任何数据。第二个动作将工作队列 1 的当前项目 ID 添加到这个新集合中。第三个动作将这个新集合添加到工作队列 2：

图 5.27 – 03 推送至队列 2 页面的前三个动作

1. 打开名为工作队列::标记项目的下一个动作。注意我们给当前项目添加了等待机器学习预测标签，这阻止了它在此流程中使用获取下一个项目被选中。此标签将在流程 2 中被移除。

流程 1 相对简单。仅对标准流程模板进行了少量修改，即在“获取下一个项目”中添加了标签过滤器，添加了一个新页面将项目推入工作队列 2，并解锁当前项目。

接下来，让我们看看机器学习预测流程本身。

检查流程 2 的主页面

让我们快速查看流程 2 的 Main 页面，以了解在高级别上正在发生的逻辑。此流程负责运行机器学习预测并检查是否需要通过阈值检查进行 HITL 审查：

1. 在流程工作室的 Ch5 组中打开 示例 3B – 机器学习预测。

2. 查看主页面上的 工作 块中的前两个页面。01 机器学习预测 触发机器学习预测并将预测结果持久化到当前项目数据中。02 检查手动审查 包含检查两个最高置信度分数推荐解决方案之间的 阈值 的逻辑。这两个页面与我们在前面的示例中看到的逻辑类似：

图 5.28 – 流程 2 工作块中的前两个页面

1. 查看名为 03a 更新队列 1 项目 的页面。当不需要 HITL 审查时运行。在此页面中，我们尝试锁定工作队列 1 中等效的项目，更新其状态，并移除标签。这允许流程 1 继续处理此项目。

2. 查看名为 03b 推送到队列 3 的页面。当需要 HITL 审查时运行。此页面包含创建队列 3 项目所需的逻辑。它与流程 1 中将项目推送到工作队列 2 所做的操作大致相同。

检查流程 3 的主页面

最后，让我们从高级别看一下我们的第三个流程，该流程负责为审阅者保存 .html 文件，以及检查完成的审查：

1. 在流程工作室的 Ch5 组中打开 示例 3C – 手动审查逻辑。

2. 注意到主页面上的 工作 块只有两个页面。没有选择阶段和状态检查以跳过步骤，因为我们希望能够在文件缺失时重新创建 .html 文件：

图 5.29 – 流程 3 工作块中的两个页面

1. 查看名为 01 编写共享审查数据 的页面。该页面将输入数据写入机器学习算法，并将三个预测结果使用查找/替换功能写入一个 .html 文件。一旦文件保存到由 Ch5 示例 3 审查文件夹路径 环境变量指定的共享位置，该文件路径就会被保存到当前项目的数据中。这使我们能够检查文件是否存在，并在必要时重新创建它。

2. 查看名为 02 检查已审查预测 的页面。该页面检查是否在由 Ch5 示例 3 已完成审查文件夹路径 环境变量指定的位置存在 .txt 文件。如果是，我们尝试锁定工作队列 1 中等效的项目，更新其状态，并移除标签。这允许流程 1 在使用 获取下一个项目 后继续处理此项目。

3. 查看紧随“项目审查完成？ 决策阶段”的两个页面。根据项目是否手动审查，我们要么推迟项目，要么将其标记为已完成。

在检查这个解决方案的三个进程之后，我们应该注意到，与本章早期示例相比，这里实际上没有什么真正的新内容。然而，我们已经将解决方案结构化，使得三个不同的关注点——业务逻辑、ML 预测逻辑和 HITL 审查逻辑——保持相对独立。

工作队列之间的通信是通过将其他队列的项目 ID 持久化到我们的项目数据中实现的。这允许我们锁定并更新包含主要业务流程的进程 1 的项目标签和状态。

现在，让我们运行示例进程。

运行主进程

我们需要在控制室运行三个进程来完成我们的示例。我们将运行的下一个主要进程将随机生成 10 个项目以填充工作队列。填充后，每个项目都应该设置状态和标签，以便我们可以在继续之前等待 ML 预测：

1. 在控制室中的Ch5组运行示例 3A – IA 业务逻辑。等待会话完成。

2. 在队列管理下查看第五章 示例 3 队列 1的内容。您会看到所有 10 个项目都有等待 ML 预测标签：

图 5.30 – 队列 1 中的所有项目正在等待 ML 预测

1. 在队列管理下查看第五章 示例 3 队列 2的内容。这个队列中应该有 10 个项目，与队列 1 中的项目键相同。

项目现在正在等待进程 2 运行。

运行 ML 进程

我们需要运行的第二个进程生成 ML 预测并确定哪些项目需要 HITL 审查。工作队列 1、2 和 3 都由这个进程修改：

1. 在控制室中的Ch5组运行示例 3B – ML 预测。等待会话完成。

2. 在队列管理下查看第五章 示例 3 队列 2的内容。您会看到所有 10 个项目已完成他们的 ML 预测：

图 5.31 – 队列 2 中的所有项目已完成 ML 预测

1. 在队列管理下查看第五章 示例 3 队列 1的内容。您会看到一些项目需要 HITL 审查。请注意，这确实是随机的。如果您没有看到任何需要审查的项目，请再次运行进程 1 和进程 2。计算需要审查的项目数量。在以下图中，它是两个：

图 5.32 – 队列 1 中的一些项目应该需要人工审查

1. 在队列管理下查看第五章 示例 3 队列 3的内容。这个队列中的项目数量应该与步骤 3中计数的一样（两个）。您还可以根据项目键比较这两个队列：

图 5.33 – 需要手动审查的项目在队列 1 中也应在队列 3 中

运行 HITL 审查流程

现在，让我们运行最后一个流程。此流程生成审查数据并检查审查是否完成。如果是，它将更新工作队列 1 中的项目，以便它可以继续自动化处理：

1. 在控制室中的Ch5组中运行示例 3C – 手动审查逻辑。等待会话完成。此流程将遍历所有需要审查的项目，创建它们的审查文件，并检查审查是否完成。

2. 在文件夹中打开由.html文件定义的文件夹，应该与第五章 示例 3 队列 1中的项目数量相同（本例中为两个）。

手动审查一个文件

让我们通过打开一个审查文件并提交网页表单来审查一个预测。此网页表单将尝试将.txt 文件保存到由Ch5 Example 3 完成审查文件夹路径环境变量指定的位置：

1. 选择一个.html文件并在您的网页浏览器中打开它。

2. 滚动到网页底部，从下拉列表中选择一个随机的决议，然后按下提交已审查的预测按钮：

图 5.34 – 手动审查项目

1. 如果出现另存为对话框，请保存文件。确保您保存文件的文件夹与Ch5 Example 3 完成审查文件夹路径环境变量的值匹配。不要重命名文件。如果您的浏览器设置为自动下载文件，则可能不会出现另存为对话框。

再次运行 HITL 审查流程

现在我们已经审查了一个预测，我们可以再次运行第三个流程（这将发现其中一个项目有一个匹配的.txt 文件，并通过移除标签来更新工作队列 1 中的该项目，以便它可以被流程 1 的获取下一个项目所获取）：

1. 在控制室中的Ch5组中运行示例 3C – 手动审查逻辑。等待会话完成。

2. 在队列管理下查看第五章 示例 3 队列 3的内容。其中一个项目应被标记为完成：

图 5.35 – 队列 3 中的一个项目已被标记为已完成

1. 在队列管理下查看第五章 示例 3 队列 1的内容。具有相同项目键的项目应有一个手动审查完成的状态和没有标签：

图 5.36 – 队列 1 中的相同项目应有一个更新的状态和没有标签

再次运行主流程

在此示例中的最后一步是再次运行主流程（请注意，将有 10 个新项目添加到队列 1 和队列 2；我们预计除了标记为需要手动****审查的项目外，所有来自上次会话运行的项目都将完成）：。

1. 在控制室中的Ch5组中运行示例 3A – IA 业务逻辑。等待会话完成。

2. 在队列管理下查看第五章 示例 3 队列 1的内容。您会看到在原始会话中添加的所有项目都被标记为完成，除了那些标记为需要手动****审查的项目。

我们已经完成了示例 3。在这个示例中，我们经历了一个三流程、三工作队列的设计，将机器学习逻辑和 HITL 审查逻辑分别放入它们自己的流程和工作队列中。进程间通信由标签过滤器、状态和引用其他队列中等效的项目 ID 来处理。

此类设计的主要优点是简化了可审计性以及不同 IA 关注点的独立扩展。我们不会走通过导出会话日志的过场，但可以清楚地看到，在客户（或监管机构）对他们的索赔选择的解决方案提出投诉的情况下，我们可以选择性地仅导出机器学习或 HITL 审查日志。

设计比较

我们已经介绍了五种不同的 IA 设计，这些设计在流程和工作队列的数量方面有所不同。让我们回顾这些设计，以了解为什么我们可能想要选择一种设计而不是另一种设计。请记住，没有哪种设计比其他设计更好或更差。这关乎它是否适合您的用例、开发人员的技能水平以及 IA 初始化的整体成熟度。

设计 1 – 异步审查（一个流程，一个工作队列）

此自包含设计允许人类审查无限期延迟。流程通过在项目上执行工作并检查已审查预测的周期交替。完成的审查检查是通过查询数据共享位置来完成的，而不是通过循环遍历每个待审查的项目。

由于所有内容都在单个流程和工作队列中，因此它非常适合可用的并发会话数量有限或工作量较低的场景。控制室的管理开销也较低。对于新开发团队来说，维护/更新单个流程可能更简单。

如果检查已审查预测需要很长时间才能执行或容易抛出异常，则此设计不太合适。这是因为检查逻辑位于主工作块之外。

设计 2 – 同步（轮询）审查（一个流程，一个工作队列）

当需要停止并等待 HITL 审查完成时，应使用此设计。如果未在规定时间内进行人工审查，项目将被标记为异常。由于每个项目都会暂停并等待人工审查，因此此设计的整体案件吞吐量最低。否则，它具有与异步设计相似的优势/劣势。

设计 3 – 独立的 HITL 审查逻辑（两个流程，一个工作队列）

此设计将 HITL 审查逻辑拆分为一个单独的流程，同时保持相同的工作队列。此设计的主要优点是，业务逻辑和审查检查可以在会话运行方面独立扩展。在我看来，可维护性也得到了提高。

此设计遍历所有需要人工审查的工作队列项目，而不是在数据共享接口处循环。这允许在缺少审查记录时重新创建它们。这也增加了单个案件的总工作时间，使统计数据看起来更差。

由于存在两个 BP 流程，我们需要至少两个会话来运行此解决方案。如果会话运行审查逻辑流程不频繁，即使审查员有空闲时间工作，数据共享记录也不会及时创建。完成人工审查的项目也依赖于审查检查流程的频繁运行，以便项目可以更新其状态并继续自动化处理。

最后，与单流程解决方案相比，调度更为复杂，尽管这不应该对经验丰富的控制器造成问题。

设计 4 – 完全独立的 HITL 审查（两个流程，两个工作队列）

在设计 3 的基础上，我们可以通过将需要人工审查的项目推入单独的工作队列来进一步分离人工审查部分。这使我们能够隔离案件统计信息，将执行审查逻辑（将数据保存以供审查员共享并检查完成的审查）的时间与执行业务逻辑的时间分开。在隔离这些统计信息时做出的权衡是，我们可能希望有一个端到端的时间视图。这需要将两个工作队列的案件时间相加。从操作角度来看，添加另一个工作队列会使控制器在控制室中跟踪案件变得更加困难。

最值得注意的是，添加新的工作队列增加了审查内容的可审计性，并允许这些数据更容易地反馈给数据科学团队，以便改进机器学习算法。通过添加机器学习，此设计也是扩展现有 RPA 流程的好方法。除了这些要点外，此设计具有与设计 3 相似的优势和劣势。

设计 5 – 完全分离（三个流程，三个工作队列）

我们最终的设计建立在设计 4 的基础上。它将所有 ML 逻辑（做出预测和检查是否需要 HITL 审查）放入一个新的流程，并将数据放入单独的工作队列。因此，我们获得了一种简单的方式来审计所有 ML 预测。除此之外，我们还有与设计 3 和 4 相似的优势和劣势。

摘要

在本章中，我们探讨了五种 IA 设计，这些设计在 BP 流程和工作队列的数量方面有所不同。确定流程和工作队列的数量对于 IA 和通用 RPA 设计都极为重要，因为它几乎影响剩余解决方案的各个方面。这包括潜在的扩展性、案例报告统计、可维护性、日志记录、可审计性、调度以及其他控制室操作。

两种 IA 设计包含单个流程和单个工作队列。一种设计用于同步审查，另一种设计用于异步审查。在我们的第三种设计中，我们将处理 HITL 审查的逻辑分离成独立的流程，从而形成两个流程、一个工作队列的设计。这允许提高重用性，并分别对业务逻辑和 HITL 审查逻辑进行扩展。对于第四种设计，我们添加了一个新的工作队列来存储所有需要人工审查的项目。这提供了一个更简单的审计轨迹，其中人类纠正了预测。这也使我们能够更容易地将这些纠正后的预测反馈给机器学习团队。最后，我们的第五种设计进一步将所有 ML 调用逻辑分离成独立的工作队列和流程，增强了可扩展性并简化了所有 ML 预测的审计。

在下一章中，我们将讨论一些较小的设计元素，这些元素补充了本章学习的基础上选择的大规模流程/工作队列结构。这些元素，例如环境变量、会话变量和凭证，可以改善整体 IA 解决方案的管理和操作。

第六章：可重用 IA 组件

在本章中，我们将讨论四个可重用 IA 组件。这些可重用逻辑片段很短，因此很容易添加到现有的 IA 流程中。它们通过结合核心 BP 功能（如环境变量、会话变量和凭证）构建，因此易于实现。它们的目的在于提供对每个 IA 解决方案都很有用的功能，而无需进行重大修改。

更具体地说，我们将查看四个组件的实现：

• IA 会话控制

• ML 预测关闭开关

• ML 模型版本控制

• 新的 ML 模型评估

技术要求

从 GitHub 上的ch6文件夹下载并导入两个.bprelease文件：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/tree/main/ch6。

IA 会话控制

会话变量在控制器需要更改活动会话期间执行行为时使用。在 IA 的上下文中，想要更改执行行为最常见的原因是执行以下操作：

• 强制项进行 HITL 审查

• 暂时禁用 HITL 审查

• 强制重新创建用于审查的共享数据

强制 HITL 审查

可能需要强制运行会话中的所有项进行 HITL 审查，完全禁用 HITL，并恢复默认行为。强制会话中的所有项进行审查对于调试和模型验证可能很有用。在审阅人员短缺或需要满足服务级别协议（SLA）的需求高于审查需求时，暂时禁用 HITL 可能是有用的。

在我们之前章节中看到的示例设计中，用于指定阈值或随机抽样率的用于存储的数据存储在环境变量中。更改环境变量不会影响已经运行的会话。然而，它们将影响所有未来的会话，这可能不是所希望的。

实现一种强制在当前运行的会话中发生 HITL 审查的方法很简单。创建一个数据项，将曝光设置为会话。将数据类型设置为标志，将初始值设置为False。如果值为False，我们继续使用随机抽样或阈值逻辑。如果值为True，我们将该项标记为需要 HITL 审查。检查此标志的最佳位置是在我们标记或更新项的状态以指示需要手动审查之前：

图 6.1 – 强制 HITL 审查的会话变量

禁用 HITL 审查

同样，我们可以创建一个新的会话变量来禁用 HITL。创建一个数据项，将数据类型设置为标志，暴露设置为会话，初始值设置为False。当值为False时，尊重原始审查逻辑。当值为True时，跳过 HITL 审查，并使用原始预测值继续自动化处理。这个标志应该在更新项目标签或状态以指示 HITL 审查完成之前进行检查：

图 6.2 – 一个用于禁用 HITL 审查的会话变量

如果强制 HITL 审查和禁用 HITL 审查会话变量的值都设置为True会发生什么？禁用 HITL 审查“覆盖”强制 HITL 审查，因为它是在后面检查的。以下表格总结了两个标志的不同组合会发生什么：

强制 HITL 审查	禁用 HITL 审查	行为
否	否	使用流程的原始逻辑（这是默认行为）
否	是	会话中的所有项目将继续自动化处理 而不 进行 HITL 审查
是	否	会话中的所有项目 都将 需要审查
是	是	会话中的所有项目将继续自动化处理 而不 进行 HITL 审查

表 6.1 – 强制 HITL 审查和禁用 HITL 审查会话变量行为

强制审查数据重建

IA 解决方案的一个可能脆弱的部分在于 BP 和审查员之间的数据共享接口。存在许多可能的情况，记录可能会丢失，导致无法审查的预测。除非控制器手动从标记会话变量编辑其状态，否则此项目将陷入停滞，类似于强制 HITL 审查和禁用 HITL 审查。

我们已经讨论了三个仅属于 IA 的会话变量以及它们如何设置。接下来，让我们通过一个例子来看看三个会话变量，包括对流程逻辑的修改，是如何实现的。

示例 1 – 三个 IA 会话变量

在这个例子中，我们将查看三个流程的修改版本，三个工作队列设计来自第五章，并确切地看到三个会话变量在流程图中的添加位置。然后我们将测试会话变量以确保它们按预期工作。我们的目标是了解我们如何在流程中检查会话变量。这个例子有七个高级步骤：

1. 验证发布内容。

2. 检查强制 HITL 审查会话变量的逻辑。

3. 从控制室测试 强制 HITL 审查。

4. 检查强制创建审查数据会话变量的逻辑。

5. 从控制室测试 强制创建审查数据。

6. 检查禁用 HITL 审查会话变量的逻辑。

7. 从控制室测试 禁用 HITL 审查。

验证发布内容

首先，让我们熟悉一下本示例的发布文件内容。验证是否已导入三个流程、三个工作队列和三个环境变量：

图 6.3 – 示例 1 的发布内容

第一个流程，命名为示例 1A – 三个 IA 会话变量，仅执行标准业务逻辑，不受本节中描述的三个会话变量的影响。流程 2，示例 1B – 强制 HITL 审查，包含一个会话变量。让我们接下来看看它。

检查强制 HITL 审查会话变量逻辑

强制 HITL 审查会话变量控制我们是否希望所有 ML 预测都经过人工审查。这属于流程 2，即 ML 预测制作和阈值或随机抽样逻辑检查的地方。让我们在流程 2 中找到检查我们会话变量的决策阶段逻辑：

1. 在流程工作室的Ch6组中打开示例 1B – 三个 IA 会话变量流程。

2. 请查看是否在主页面中添加了一个全局会话变量：

图 6.4 – 会话变量已保存在流程 2 的主页上

1. 打开02 检查手动 审查页面。

2. 打开是否需要手动审查？决策阶段。查看我们是否已将检查会话变量作为表达式中的OR条件添加：

图 6.5 – 会话变量已添加到决策阶段

测试强制 HITL 审查会话变量

既然我们已经知道了如何检查会话变量，让我们在控制室中测试它。此流程向第六章 示例 1 队列 1添加了 10 个项目：

1. 在控制室中运行示例 1A – 三个 IA 会话变量。等待会话完成。

2. 打开控制 | 会话管理。点击显示会话变量以确保会话变量面板已打开：

图 6.6 – 确保会话变量面板已打开

保持面板打开将允许我们在步骤 4中快速更改强制 HITL 审查会话变量的值。

1. 在控制室中运行示例 1B – 强制 HITL 审查。不要等待会话完成。

2. 在会话变量面板中将强制 HITL 审查会话变量设置为True。从现在起，所有做出的 ML 预测都将标记为需要 HITL 审查：

图 6.7 – 将强制 HITL 审查会话变量设置为 True

1. 一旦会话完成，查看第六章 示例 1 队列 1的内容。根据你更改会话变量的速度，你应该看到所有或几乎所有队列项都需要人工审查：

图 6.8 – 工作队列 1 中的几乎所有项目都应该需要人工审查

我们已确认强制 HITL 审查会话变量正在工作。现在，让我们看看强制重新创建评论数据的会话变量。

检查强制创建评论数据会话变量逻辑

回想一下，第三个流程包含将评论数据写入磁盘的逻辑，并检查评论是否已完成。在这里，我们将检查流程 3，看看文件重建会话变量逻辑是如何实现的：

1. 在流程工作室的Ch6组中打开示例 1C - 禁用 HITL 审查和强制创建评论数据流程。

2. 看到两个全局会话变量在主页上。强制创建评论数据会话变量是我们这里感兴趣的：

图 6.9 – 两个会话变量保存在流程 3 的主页上

1. 打开01 编写共享评论 数据页面。

2. 找到名为会话变量逻辑的块。与上一章中的原始示例相比，这个块是新添加到这个页面上的。

3. 打开强制创建评论数据？决策阶段。我们将检查强制创建评论数据是否为真。如果是，我们将尝试删除现有文件并从我们的项目数据中移除对其的引用。然后我们将继续创建一个新评论文件，就像它从未存在过一样。

图 6.10 – 允许强制创建评论文件的逻辑

测试强制创建评论数据会话变量

现在，让我们测试会话变量是否工作。我们将总共运行流程 3 三次。第一次运行创建所有评论文件一次。第二次运行确认默认情况下不会重新创建评论文件。对于第三次运行，我们将更改会话变量，并看到之前的评论文件正在被删除，同时以新的文件替换它们。

1. 在控制室中运行示例 1C - 禁用 HITL 审查和强制创建评论数据。此流程在项目之间也有一个睡眠阶段，以便更容易编辑会话变量。等待会话完成。

2. 在 Windows 资源管理器中访问由Ch6 Example 1 To Review Folder Path环境变量定义的文件夹。验证文件夹中文件的数量是否与等待人工审查的项目数量相等。注意这些文件创建的时间戳。

3. 等待第六章 示例 1 队列 3中项目的延迟时间通过。

4. 在控制室中第二次运行Example 1C - Disable HITL Review and Force Create Review Data。等待会话完成。

5. 返回由Ch6 Example 1 To Review Folder Path环境变量定义的文件夹。验证文件的日期时间戳没有更改。这表明审查文件尚未被重新创建。

6. 等待第六章 示例 1 队列 3中项目的延迟时间通过。

7. 在控制室中第三次运行Example 1C - Disable HITL Review and Force Create Review Data。不要等待会话完成。

8. 在会话变量面板中将Force Create Review Data会话变量设置为True。从这一点开始，每个项目都将重新创建其审查数据。等待会话完成：

图 6.11 – 将 Force Create Review Data 会话变量设置为 True

1. 返回由Ch6 Example 1 To Review Folder Path环境变量定义的文件夹。验证文件的修改日期时间戳已更改，表明它们已被重新创建。

到目前为止，我们已经测试了我们的两个会话变量。让我们继续并查看第三个，它用于禁用 HITL 审查检查。

检查 Disable HITL Review 会话变量逻辑

我们最后的会话变量也在第三个流程中。让我们看看它是如何实现的：

1. 打开此流程的Main Page。

2. 打开02 Check for Reviewed Predictions页面。

3. 确认已添加名为Disable HITL Review的决策阶段，该阶段跳过后审查项目后应运行的阶段：

图 6.12 – 已添加决策阶段以禁用 HITL Review

测试 Disable HITL Review 会话变量

在本例的最后部分，我们将再次运行第三个流程，将Disable HITL Review会话变量设置为True，并验证第六章 示例 1 队列 1中的项目是否已移除其状态和标签：

1. 在控制室中再次运行Example 1C – Disable HITL Review and Force Create Review Data。不要等待会话完成。

2. 在会话变量面板中将Disable HITL Review会话变量设置为True。从这一点开始，每个项目将不再需要 HITL 审查。等待会话完成。

3. 查看第六章 示例 1 队列 1工作队列的内容。之前需要手动审查的项目现在应显示为手动审查完成，并移除了其标签。队列 1 中的项目准备继续其自动化处理：

图 6.13 – 队列 1 中的项目已跳过 HITL 审查

我们已经完成了包含三个会话变量的可重用设计片段的实现示例。这些会话变量使我们能够在会话仍在运行时控制 IA 特定的行为。现在，让我们从查看特定于会话的设计控制转向一个可以在多个会话中工作的设计组件。

机器学习预测终止开关

想象一下，在机器学习算法已经在生产环境中运行后，发现了一个重大的缺陷。我们希望停止所有正在进行的会话，使其不再使用该模型进行预测。一个选项是从源头上禁用机器学习模型——例如，通过关闭云服务或内部 Web 服务器。然而，IA 团队成员在短时间内完成这一操作的可能性相当低。

IA 控制器团队可用的最明显选项是使用请求停止，但根据标准的 BP 流程模板，只有在项目执行完成后才会进行停止的检查。如果并发运行的会话数量足够低，添加会话变量来停止机器学习预测也是一个选项。但如果我们有数十个，甚至数百个会话在进行中呢？

可以用来防止机器学习预测在所有会话中运行的组件设计是一个终止开关。终止开关的目的是允许 IA 控制器以可控的方式停止所有当前正在运行的会话，以停止机器学习预测。实现终止开关很简单；然而，它使用了一个 BP 功能——凭证，以一种非预期的方式。

示例 2 – 终止开关

由于实现终止开关很简单，让我们从头开始构建一个，看看它是如何工作的。终止开关使用凭证及其标记为无效属性。从高层次来看，我们将进行七个步骤：

1. 创建凭证并授予其权限。

2. 创建一个使用凭证的流程。

3. 在流程中添加异常处理。

4. 确定终止开关的逻辑。

5. 使用非活动的终止开关测试流程。

6. 激活终止开关。

7. 使用活动的终止开关测试流程。

创建凭证并授予权限

实现终止开关的第一步是创建一个新的凭证：

1. 从 BP 的系统|安全|凭证区域创建一个新的凭证。

2. 将凭证命名为终止开关：

图 6.14 – 将凭证命名为“终止开关”

1. 点击访问****权限标签。

2. 点击安全角色子标签，并勾选所有角色复选框。请注意，这不是最佳实践，但我们这样做是为了简化示例。

3. 点击流程（旧版）子标签，并勾选所有****流程复选框。

4. 点击资源（旧版）子标签，并勾选所有****资源复选框。

5. 保存凭证。

创建流程和杀死开关

接下来，让我们创建一个使用此凭证的 BP 流程：

1. 在Ch6组中创建一个名为示例 2 – 测试杀死开关的流程。

2. 在流程工作室中打开示例 2 – 测试杀死开关流程。

3. 在流程图中添加一个操作阶段。

4. 打开操作阶段，然后设置"杀死开关"为凭证名称：

图 6.15 – 将凭证::Get 操作添加到流程图中

1. 点击输出选项卡。创建一个名为状态的数据项以存储状态输出：

图 6.16 – 存储凭证::Get 操作的输出状态

1. 保存操作。

2. 链接****开始到操作。

添加异常处理

杀死开关的下一部分是添加一些简单的异常处理。此 IA 组件需要处理如果凭证意外删除的异常：

1. 在杀死开关周围添加一个块。

2. 在块内添加一个恢复阶段。

3. 链接恢复阶段到一个恢复阶段。恢复阶段应该位于阻塞之外。

4. 添加一个异常阶段。填写以下详细信息：

图 6.17 – 创建异常

1. 链接恢复阶段到异常阶段。到目前为止的流程图应该看起来如下：

图 6.18 – 到目前为止的杀死开关流程图

杀死开关结构几乎完成。接下来，我们需要添加逻辑来检查凭证的状态。

完成杀死开关

杀死开关利用凭证的标记为无效属性。让我们添加一个决策阶段来检查它：

1. 在杀死开关块内添加一个决策阶段到流程图中。

2. 将决策阶段的名称设置为状态 = 无效？并将表达式设置为以下：

   [Status] = "Invalid"
   

图 6.19 – 决策阶段设置

1. 将名为SE – 杀死开关触发的异常阶段复制并粘贴到流程图中，使其出现两次。确保这个新的异常位于杀死开关块内。

2. 链接****凭证::Get操作到状态 = 无效？决策阶段。

3. 链接决策阶段的是路径到新粘贴的异常和否路径到结束。

4. 保存流程。

5. 确认流程图看起来类似于以下：

图 6.20 – 最终的杀死开关测试流程

我们现在已经完成了终止开关。它会检查凭据是否被 标记为无效。如果是，则抛出异常。如果不是，我们可以继续到后续的阶段。当在真实的 IA 流程中使用此终止开关时，决策阶段应直接链接到调用机器学习预测的阶段，而不是链接到 结束。

使用未激活的终止开关从流程工作室运行流程

让我们以当前状态运行流程，使用休眠的终止开关。这是默认行为，或者当我们想要我们的 IA 流程进行机器学习预测时会发生的情况：

1. 从流程工作室运行 示例 2 – 测试终止开关。

2. 看到它只是从 开始 到 结束。

我们已经看到了终止开关未激活的无事案例。接下来，我们将激活机器学习终止开关。

通过将凭据标记为无效来激活终止开关

要激活终止开关，我们标记凭据为无效。当终止开关激活时，执行将被阻止继续通过 终止开关 块。在正常情况下，我们会在会话仍在运行时激活终止开关。然而，我们在这里触发它是为了方便使用 BP 的试用版和学习版的读者。

1. 导航到 系统 | 安全 | 凭据，并打开名为 终止开关 的凭据。

2. 选择 标记为无效 复选框并保存凭据：

图 6.21 – 检查标记为无效的凭据框

当凭据被标记为无效时，我们的终止开关是 激活 的，并且所有当前和未来的 Test Kill Switch 流程的会话运行在执行达到 状态 = 无效？ 决策阶段时都会抛出异常。

使用激活的终止开关从流程工作室运行流程

在终止开关激活的情况下，让我们再次运行我们的流程。这应该会抛出异常，阻止我们到达流程中终止开关块之后的区域：

1. 从流程工作室运行 示例 2 – 测试终止开关。

2. 看到抛出了异常。

当流程尝试获取已作废的凭据时，会抛出异常。当前项目的工作停止，并且使用此特定凭据的所有会话中的后续项目工作也会停止。这会持续到凭据再次被标记为有效。此终止开关最好与项目状态和允许在调用终止开关逻辑之前跳过执行的决策阶段一起使用。

重要提示

想要将凭据标记为无效的用户可能在 BP 中需要额外的权限。在生产环境中使用终止开关可能需要审查逻辑访问模型，该模型定义了哪些用户应该拥有哪些用户角色，以及哪些用户角色应该在 BP 中拥有哪些权限。

删除凭证（不推荐）也可以用来触发关闭开关，但您必须记得使用完全相同的名称重新创建凭证。创建和删除加密方案和环境变量也可以用来实现关闭开关，但使用凭证是一种更简洁的实现方式。勾选标记为无效的复选框操作起来更简单，也更易于撤销。

通常，您会为生产中的每个机器学习模型设置一个关闭开关。如果多个进程使用相同的机器学习模型，则可以使用相同的关闭开关凭证。

我们已经讨论了关闭开关。让我们继续讨论本章的第三个 IA 组件，该组件讨论了为了审计目的需要对机器学习模型进行版本化的需求。

机器学习模型版本化

机器学习程序，就像所有软件一样，应该定期更新。更新可能出于许多原因——可能有新数据、机器学习框架的变化、模型调优的改进、安全修复等。无论更新发生的原因是什么，当它们发生时，IA 团队都应该被告知，因为它们可能会影响预测的准确性。

理想情况下，面向生产的机器学习模型将由供应商进行版本化。模型的更新应导致新的文档和新的 URL 端点。拥有新的端点允许 IA 团队有意识地选择何时使用更新的模型，并在必要时回滚到旧模型。然而，在现实中，机器学习供应商可能会简单地重用相同的端点并使用更新的模型，而不会主动通知客户变化。

如果 IA 团队没有主动被告知机器学习模型的变化，它应该手动跟踪更新发生的时间，以进行调试和审计。否则，当我们查看会话日志时，我们不会知道实际使用了哪个版本的模型！我们的目标是仅通过查看会话日志就能知道哪个版本的机器学习模型被使用。但由于触发机器学习预测有多种方式，这并不立即明显如何实现。

重要注意事项

版本化的目的不是为了确保确定性。确定性模型是指相同的输入集总是导致相同的预测。许多模型引入了随机性；例如，生成式 AI 即使在多次提供相同提示的情况下也会给出不同的输出。对于版本化，我们不是在寻找确定性，但我们希望有信心模型是使用相同的数据、底层算法、库、超参数等创建的。

调用 Web API 的两种不同方式

Web API 是目前部署 ML 模型最常见的方式。在 BP 中，我们通过对象或Web API 服务（可能从 DX 下载）连接到 Web API。API 的 URL 将作为数据项嵌入，在对象的情况下，或者直接保存在 Web API 服务的配置中。这导致我们需要考虑四种不同的情况，当我们思考如何在 BP 中为 ML 模型进行版本控制时。对象的情况也适用于代码阶段和 CLI 脚本。

BP 调用方法	新模型是否有 独立的端点？	要做什么
对象	是	在对象阶段启用日志记录以显示正在使用的 URL
对象	否	手动跟踪版本
Web API 服务	是	手动跟踪版本
Web API 服务	否	手动跟踪版本

表 6.2 – 调试和审计 ML 模型的四种版本控制方式

在接下来的章节中，我们将逐一介绍表 6.2中概述的四个 Web API 调用场景。

当提供新端点时使用对象调用 Web API

假设 ML 供应商已更新其模型，并已为我们提供了新的 URL 端点。如果我们使用对象调用此 URL，我们可以通过记录 URL 将会话运行与正在使用的模型关联起来。在对象中，URL 将作为数据项、环境变量存储，或者直接作为动作的输入输入。无论 URL 如何输入到对象中，我们所需做的就是启用适当的阶段的日志记录。请注意，对象的阶段日志记录默认是禁用的，因此我们必须明确打开日志记录：

图 6.22 – 在对象中启用阶段日志记录以记录 URL 端点

当供应商重用现有端点时使用对象调用 Web API

如果供应商在更新模型时没有提供新的端点，我们需要创建自己的版本控制方案，并在 API 调用之前在会话日志中明确记录。我建议使用日期时间，它存储了我们确定模型已更新的日期作为版本控制方案。让我们通过一个示例一起实现这个 IA 组件。

示例 3 – 手动版本控制 ML 端点

环境变量是我们存储 API 版本的最佳位置，因为我们希望在流程和对象图之外更新其值。然而，环境变量的更改会在审计日志中显示，而不是在会话日志中。因此，仅通过查看会话日志，我们无法知道特定会话运行使用了哪个 ML 模型版本。您需要将会话日志的日期与审计日志交叉引用，以找出何时修改了该环境变量以及更改了什么值。需要查看两种不同类型的日志并不是理想的情况。

图 6.23 – 环境变量更改出现在审计日志中

一个更好的解决方案是在我们的 API 调用之前，在会话日志中始终记录环境变量的值。这使得找出用于进行预测的 API 版本变得容易。为了实现这一点，我们在 API 调用之前添加了一个带有日志记录功能的“虚拟”计算阶段。

在本例中，我们将演示如何实现导致 ML 版本出现在会话日志中的 ML 版本控制。我们将通过五个高级步骤来完成：

1. 创建一个环境变量。

2. 创建一个测试流程。

3. 在控制室中运行流程并查看会话日志。

4. 使用新的 API 模型版本更新环境变量。

5. 再次在控制室中运行流程并查看会话日志。

创建一个环境变量。

首先，我们需要创建一个环境变量，并用一个 DateTime 值填充它——这将是我们当前正在使用的 API 的“版本”：

1. 导航到系统 | 流程 | 环境变量。

2. 添加一个名为 DateTime 的新环境变量，并将值设置为当前的 DateTime。

3. 点击应用。

创建一个测试流程。

接下来，让我们创建一个测试流程，该流程调用一个虚拟 API 对象。虚拟对象取代了真实的 ML API 调用：

1. 在 Ch6 组中创建一个名为示例 3 – ML 版本控制的流程。

2. 在流程工作室中打开示例 3 – ML 版本控制。

3. 将 Ch6 Example 3 ML API Version 环境变量作为数据项添加到图中。

4. 在 Temp 数据项下添加一个计算阶段，并将阶段日志记录设置为启用：

图 6.24 – 创建一个用于记录环境变量值的计算阶段

我们所做的是通过将值保存到一个名为 Temp 的废弃数据项中，将环境变量的值记录到会话日志中。

1. 添加一个 "www.testapi.com"。将阶段日志记录设置为启用。我们将使用这个设置剪贴板动作作为实际调用 API 的替代品。

2. 链接 开始到计算阶段，计算阶段到动作，动作到结束。完成的图应如下所示：

图 6.25 – 一个简单的测试流程

1. 发布并保存流程。

运行测试流程并查看会话日志。

让我们在控制室中运行一次流程，看看会话日志显示了什么：

1. 在控制室中运行示例 3 – ML 版本控制并等待会话完成。

2. 打开该会话运行的会话日志。记录日志 API 版本计算阶段的值和我们的“假 API 调用”的 URL，设置剪贴板：

图 6.26 – 查看会话日志并注意机器学习 API 版本和 URL

现在，假设机器学习供应商在保持 URL 端点不变的情况下更新了机器学习模型。在 设置剪贴板 中记录“URL”的值不会让我们根据会话日志知道模型已更改。我们需要将我们的环境变量更新到新的模型版本值。

更新环境变量

由于我们不需要更新 URL，让我们更新环境变量到一个新的 DateTime 值。这将与我们的计算阶段一起记录下底层机器学习模型已更新的事实，尽管 URL 保持不变：

1. 导航到 系统 | 流程 | 环境变量。

2. 将 Ch6 Example 3 ML API Version 更新为当前的 DateTime。

3. 点击 应用。

运行测试流程并再次查看会话日志

让我们再次运行流程并验证更改环境变量是否反映在会话日志中：

1. 在控制室中运行 示例 3 – 机器学习版本控制。

2. 打开最新会话运行的会话日志。查看更新的环境值是否已反映在我们的日志中：

图 6.27 – 更新的环境变量反映在会话日志中

在这个第三个例子中，我们讨论了一个包含环境变量和计算阶段的组件。这个组件的目的是为了手动对机器学习模型进行版本控制，以便进行调试和审计。

完全没有必要使用计算阶段，因为环境变量的更改会反映在审计日志中。这可以与会话日志进行交叉引用，以确定在会话运行期间使用了哪个版本的机器学习模型。然而，将机器学习模型版本直接保存到会话日志中会更简单，从而避免获取审计日志时可能遇到的问题，例如用户访问限制。

调用 Web API 服务

如果使用 Web API 而不是对象，基本端点将直接保存在配置中的某个地方。在下面的图中，它保存在每个单独的操作中：

图 6.28 – URL 保存到 Web API 服务配置中

假设 API 版本从前面图中的 v1 变更为 v2。审计日志 将显示 Web API 服务已被修改，但新的和之前的 URL 无法看到。这使我们无法确切知道在会话运行期间使用了哪个 URL（以及因此模型）：

图 6.29 – 之前和新的 URL 在审计日志中找不到

因此，如果我们使用 Web API 服务来制作我们的 ML 预测，是否提供了新的端点并不重要——历史更改的 URL 在任何 BP 日志中都无法找到。 如果我们想了解正在使用哪个端点进行 Web API 服务，我们必须使用在 示例 3 中制定的相同方案，包括一个计算阶段和一个环境变量。

我们已经讨论了如何在会话日志中记录 ML 模型版本。接下来，让我们看看最终的可重用 IA 组件，该组件用于按顺序评估新的 ML 模型，与当前在生产中运行的模型一起。

新的 ML 模型评估

预测模型可能会因多种原因而改变，包括训练数据的更新、超参数调整或切换到全新的算法。当一个 ML 模型发生变化时，它需要与一个 验证 数据集进行评估——但这可能还不够。该组件的目的是允许我们对一个提议的模型与 生产 数据进行评估。目标是收集有关提议的模型如何与生产数据交互的数据，以便数据科学或 IA 团队可以确定它是否可接受。

本节所述的 IA 组件是通过一个流程模板实现的。当在 IA 流程中使用时，此模板允许我们使用实时数据对第二个 ML 模型进行预测。该组件设计背后的原则包括以下内容：

• 足够简单，可以集成到现有的 IA 流程中。

• 将日志限制在单个阶段，以方便提取会话日志信息供数据科学家使用。

• 在模板中恢复任何发生的异常，以免影响主生产流程。

• 使用简短且简单的逻辑来避免过多增加项目的总工作时间。

让我们通过一个例子来看看如何实现这一点。

示例 4 – 新的 ML 模型评估流程模板

在这个例子中，我们将通过一个已经开发的流程模板，并解释它是如何工作的。我们还将讨论将模板纳入现有 IA 流程所需的步骤。我们的例子包含三个高级步骤：

1. 验证发布内容。

2. 理解模板逻辑。

3. 理解如何将其集成到现有的 IA 流程中。

验证发布内容

发布内容应在 技术要求 部分中导入。验证是否已导入 一个 流程、一个 工作队列和 两个 环境变量：

图 6.30 – 发布文件内容

Ch6 Example 4 Enable Model Evaluation 环境变量确定此模板是否激活。Ch6 Example 4 Evaluation Model ID 环境变量是我们想要测试的 ML 模型的自定义 ID。这是为了帮助我们跟踪在生产中正在测试哪个模型。接下来，让我们打开流程并了解模板内容。

理解模板逻辑

流程模板逻辑很简单，只有两个页面。有一个占位符页面，你需要在其中提供使机器学习预测的逻辑。完成以下步骤：

1. 在流程工作室的Ch6组中打开示例 4 – 新模型评估流程模板。

2. 双击主页面。你会看到我们需要传递两个集合。输入数据集合存储了我们想要评估的机器学习模型所需的预测输入数据。原始预测结果集合（可选）可以在我们想要将实际生产预测的结果与正在评估的模型的预测结果一起记录时传递。这使得比较两个结果变得更容易：

图 6.31 – 启动阶段的输入参数

1. 查看连接到Ch6 Example 4 Enable Model Evaluation环境变量的启用模型评估？决策阶段，以确定是否使用此模板。

2. 查看输入到新队列（由队列名称指定）的输入数据，并立即使用队列名称锁定该项以进行处理，应与调用进程的工作队列不同：

图 6.32 – 将项添加到新队列

在新队列中创建项的原因是为了使从控制室中找到单个项的评估预测变得容易。

1. 查看环境变量Ch6 Example 4 Evaluation Model ID。这为你提供了一个版本或识别正在评估的模型的方法。这将记录在会话日志中供参考。

2. 查看Recover1阶段。添加了异常处理以确保异常不会向上冒泡到调用进程。

3. 打开调用预测页面。这个页面主要是为了让你插入使用评估机器学习模型进行预测所需的实际阶段。预测输出必须添加到输出数据集合中，以便写入会话日志。在添加你的逻辑时，确保只为想要记录开始和结束时间的阶段开启阶段日志：

图 6.33 – 调用预测页面

1. 查看多计算阶段记录新模型评估结果。这记录了与数据科学家相关的所有相关信息，以便在单个会话日志条目中轻松检索：Ch6 Example 4 Evaluation Model ID、输入数据、原始预测结果和输出数据。

与现有流程的集成

既然我们已经看到了模板的逻辑，我们将讨论将其实施到现有 IA 流程中所需的步骤：

1. 在流程工作室中打开模板，并使用另存为创建一个新的流程。

2. 在主页面下创建一个新的工作队列以匹配它。工作队列的键名字段应根据 ML 调用的输入数据设置，或者可以留空。

3. 创建两个新的环境变量来替换Ch6 Example 4 评估模型 ID和Ch6 Example 4 启用模型评估。设置它们的值，并将主页面上的两个环境变量替换为新创建的变量。这也导致需要更改主页面上的启用模型评估？决策阶段，以及调用``预测页面上的记录新模型评估结果计算阶段。

4. 打开调用预测页面。插入逻辑以使用输入数据集合中的数据对评估 ML 模型进行预测。预测输出应格式化为输出``数据集合。

5. 在特定操作或 Web API 上启用阶段日志记录以进行 ML 预测。否则，将已添加的阶段日志设置为仅记录错误。

6. 保存模板。

7. 在现有的 IA 流程中，在获得实时预测结果后添加一个流程阶段。配置此阶段使用刚刚保存的流程模板。在评估模型进行预测所需的输入数据上，以及可选的，如果您想将其与评估模型一起记录，则原始预测结果。

使用此组件，我们可以在对现有 IA 流程进行很少的更改的情况下，对评估 ML 模型进行实时预测。对原始流程的唯一修改是调用子流程。

由于所有会话日志记录都在单个阶段中发生，因此访问这些评估预测的结果变得简单。可以按多计算阶段的名称导出和过滤会话日志。这为数据科学家提供了他们进一步评估模型所需的所有信息，包括模型 ID、输入数据、生产预测结果和评估预测结果。

可重用 IA 组件审查

我们已经介绍了四个不同的可重用组件，这些组件可以在许多不同的 IA 流程中使用。以下表格显示了每个组件的目的以及创建它们所使用的 BP 功能摘要：

姓名	使用的 BP 主要功能	目的
IA 会话控制	会话变量和决策阶段	基于会话控制是否：项目必须强制进行 HITL 审查。审查检查被禁用。用于审查的共享数据应重新创建。
ML 预测终止开关	凭证（标记为无效）、决策阶段和异常处理	允许防止使用特定模型的所有当前和未来的会话进行 ML 预测
ML 模型版本控制	计算阶段（启用日志记录）和环境变量	创建指定使用哪个 ML 模型版本进行预测的会话日志，即使 API 端点保持不变
新机器学习模型评估	工作队列、环境变量、异常处理和多计算阶段（用于日志记录）	以一种使预测结果提取简单的方式进行，在主机器学习模型旁边运行一个评估机器学习模型

表 6.3 – 四个可重用 IA 组件的总结

摘要

在本章中，我们开发了四个可重用的 IA 组件，它们提供了与机器学习操作特别相关的附加功能。这些组件可以轻松集成到现有的 IA 流程中。

我们的第一个组件是一组三个会话变量。这些会话变量允许控制室操作员根据实时需求对 HITL 预测验证行使更多的控制权。

接下来，我们讨论了一个可以轻松使用的“关闭开关”，它可以用来在整个现有和未来的会话中禁用和重新启用机器学习预测。如果需要紧急停止某个模型在 IA 中使用的所有机器学习预测，这可以派上用场。

第三个组件，机器学习模型版本控制，解决了 BP 中不完善的审计日志（截至版本 7.1.2）引起的问题。在 Web API 服务中更新 URL 不会显示在审计日志中更改的具体 URL。这意味着即使我们查看会话日志和审计日志，我们也不知道确切使用了哪个 API URL 或版本来进行预测。这个第三个组件通过手动版本控制机器学习模型来解决这个问题。这使我们能够通过仅查看会话日志来了解模型使用了哪个版本。

最后，我们的第四个组件是一个可以用来扩展现有 IA 流程的流程模板。这个组件允许我们在生产机器学习预测的同时运行额外的机器学习预测，以便对实时数据进行评估。

创建可重用模板的概念对于 RPA 和 IA 开发都极其重要。它允许标准化、简化维护和加快开发时间。在下一章中，我们将从第一章开始，结合所有已涵盖的内容，形成一个标准化的、可重用的 IA 流程和对象模板。这些模板可以用来启动 IA 解决方案设计，并作为在您的组织中创建 IA 模板的基础。

第七章：IA 模板和实用工具 - IA 对象

成熟的 BP 开发团队很少从空白的流程设计画布开始他们的开发工作。相反，他们建立内部最佳实践，并将它们纳入一个标准模板库中，这些模板涵盖了他们遇到的大多数自动化场景。

在我与大四咨询团队、其他大型技术咨询公司、直接与客户合作，以及作为 SS&C 自动化 COE 成员的工作经验中，大多数现存的模板都是 BP 的标准流程模板的变体。这个标准模板在登录 BP 门户后即可获得，portal.blueprism.com/products/developer-jumpstart。在这个网页上，您可以找到 BP 的官方模板以及如何使用它们的文档。

尽管围绕 IA 有很多“讨论”，但我还没有看到任何合作伙伴、客户甚至 BP 本身使用 IA 特定的模板。为了帮助填补这一差距，我开发了一些可以用于 IA 的模板，包括前几章中讨论的许多设计工作。本章的目标是介绍这些模板，并解释如何使用它们来启动您的 IA 开发。

在本章中，我们将讨论一个对象和三个流程模板：

• IA 实用工具对象

• 一个单流程、单工作队列的同步审查模板

• 一个单流程、单工作队列的异步审查模板

• 一个三流程、三工作队列的异步审查模板

技术要求

从github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/tree/main/ch7下载并导入.bprelease文件。该发布包含五个流程和一个对象。验证它是否与以下图相符：

图 7.1 – 导入的发布内容

让我们先讨论对象。

对象 – 实用工具 – IA

此对象包含执行 IA 中常用任务的辅助函数。大多数操作使用C#代码阶段。此对象依赖于 BP 捆绑的标准MS Excel VBO和实用工具 - 环境对象。

接下来将讨论对象的操作及其与 IA 相关的目的。

范围内的随机整数

这将在一个范围内生成一个随机整数。提交一个下限（默认1）和一个上限（默认100）的范围值。返回的随机数包含范围值。此操作主要用于随机抽样。

范围内的随机小数

这将在一个范围内生成一个随机的小数。提交一个下限（默认0）和一个上限（默认1）的范围值。返回的随机数包含范围值。此操作主要用于随机抽样。

运行流程读取 Stdout Stderr 带超时

此操作需要导入Utility - Environment。

如果你还记得第二章，没有 BP 提供的操作可以启动流程，指定超时，并检索Stdout和Stderr作为数据项。我们不得不使用Utility - Environment::Run Process Until Ended并指定重定向文件来捕获 Stdout 和 Stderr。

此操作是Run Process Until Ended的包装器。此操作的输入与Run Process Until Ended相同。它执行文件重定向和临时文件管理逻辑，以便可以将 Stdout 和 Stderr 作为数据项返回。应使用此操作从 CLI 或 PowerShell 触发 ML 预测，而不是 BP 提供的内置选项。

文件转 Base64

此操作将文件（使用文件路径作为输入）转换为 Base64 格式。与.html文件中提供的版本相比，它具有额外的错误处理功能，可以转换需要上传到 API 的图像和文件。此操作适用于任何通用文件，而不仅仅是图像。

阈值 Excel 收集

此操作将包含标签和阈值值的 Excel 文件转换为集合。Excel 文件必须有两个列，标签在 A 列，阈值值（数值）在 B 列。Excel 文件的第一行应该是标签和阈值值的标题，但实际标题值没有限制。

此操作的输出是一个包含两个字段的集合。第一个字段是标签，第二个字段是阈值值。此操作需要导入MS Excel VBO。

此外，使用此操作会将标签和阈值存储在一个内部字典中，该字典由操作通过标签获取阈值使用，这将在下文中描述。

通过标签获取阈值

本操作的目的是为了提供快速查找阈值值的功能，因为可能会有数百个预测标签。在使用此操作之前，需要先使用一次阈值 Excel 收集操作。

要使用此操作，传递一个标签以获取其对应的阈值值。在集合中查找特定行最常见的方法是使用循环或Utility - Collection Manipulation::Filter Collection，当行数很多时，这并不高效。此操作通过查找标签并从内部字典中检索值来快速查找。如果找不到标签，将抛出异常。

对象概述

Utility - 智能自动化对象中有六个操作。代码阶段使用的语言是 C#。请记住，此对象只是一个起点。它可以，并且应该扩展到您 IA 解决方案所需的一些常用功能。现在，让我们看看使用此对象的三个流程模板。

处理模板

创建了三个流程模板，以涵盖绝大多数不同的 IA 设计。所有这些模板都是基于 BP 的标准流程模板，因此对于大多数开发者来说应该很熟悉。我已有意保持标准流程模板的逻辑尽可能不变，以便开发者可以将他们的开发精力集中在实现针对其特定用例的业务逻辑上。

重要提示

如果您不熟悉 BP 的标准流程模板，可以在门户的开发者快速入门页面上找到操作手册：portal.blueprism.com/system/files/2017-09/Process%20Template%201%20-%20Basic%20-%20Instructions.pdf。在开始使用本章中描述的 IA 模板之前，了解如何使用标准模板非常重要。

两个模板是单进程和单工作队列设计。这些设计更适合刚开始使用 BP 或拥有有限可用许可证的团队。这两个模板的区别在于 HITL 审查是否需要在近实时（同步）完成，或者不需要（异步）。第三个模板具有三进程、三工作队列设计。尽管调度和许可证使用变得更加复杂，但它提高了可扩展性，简化了审计，并促进了已审查预测反馈给 ML 团队。

每个模板都在其对应的子节中进行讨论，并包含对其使用的说明。当通过流程工作室查看模板时，请注意以绿色字体显示的阶段。这些是需要您修改的区域——例如，添加针对您特定用例的逻辑。

单进程、单工作队列、同步审查流程模板

此模板为需要近实时HITL 审查的情况提供了一个简单、单会话的解决方案。让我们看看这个同步审查模板的重要细节，以便您能够在实践中成功实施它。

使用 IA 模板 1 - 同步审查

在本节中，我们将逐页浏览模板，并检查需要理解的内容和需要更改的内容，以便您的 IA 用例可以实施。不会讨论与标准流程模板相同的页面和细节。请记住，您需要使用另存为将模板保存到新的流程中才能使用它。不要直接编辑并保存模板。

在整个流程图中，您会看到绿色的方块。这些绿色方块是为了文档和指导目的而添加到模板中的。请在使用过程中删除这些绿色方块，因为它们可能会影响异常处理。

下面的每个子标题都指的是流程工作室中的一个页面。请打开相应的页面并阅读它，以了解你需要进行哪些更改才能使用此模板。我们将总共涵盖 10 个页面：

1. 主页面：在这里，我们需要了解主要工作步骤，并从工作块中添加/删除页面以满足你的用例。

2. IA 数据：此页面包含在 IA 解决方案逻辑中使用的的重要数据项。

3. 启动：这里有一些占位符区域，用于创建审阅的共享数据文件夹，并在需要时从 Excel 加载阈值值。

4. 02 机器学习预测：在此页面上，我们需要创建终止开关凭据，并修改逻辑以使用该凭据。我们还需要创建一个环境变量来记录机器学习模型版本，以便将其记录下来。最后，我们需要进行机器学习预测，并将预测和置信度分数存储在指定的数据项中。

5. 03 随机抽样：创建一个环境变量来存储随机抽样百分比，如果我们想使用随机抽样，则需要修改逻辑以使用该环境变量。

6. 03 阈值：如果你想使用阈值并且使用 Excel 存储阈值级别，请保持此页面不变。否则，在此处添加你的阈值逻辑。

7. 04 编写共享审阅数据：这里有一些占位符，你可以添加创建审阅数据所需的逻辑。

8. 05 等待已审阅的预测：添加逻辑以检查预测是否已被审阅。创建一个环境变量来存储轮询循环将等待的最大秒数。最后，添加逻辑将已审阅的预测保存到指定的数据项中。

9. 06 检查审阅者异常：此页面无需更改。它包含逻辑，如果审阅者认为项目不应由自动化处理，则会抛出业务异常。

10. 07 使用机器学习预测的工作步骤：此页面展示了如何获取已审阅的预测，以便在流程中进一步使用。如有需要，在此处添加额外的阶段。

打开– 同步审阅组。让我们更深入地查看页面，从主页面开始。

主页面

主页面包含高级流程流程 – 已添加到工作块中的六个阶段，以及一个选择阶段，用于控制如果项目被重试，则跳过 IA 相关阶段。以下列表包含你应该对模板进行的更改或对重要内容的解释：

1. 定位到工作块。如果你想使用阈值方案来确定预测是否需要人工审阅，请将工作块中的03 随机抽样页面替换为03 阈值页面。不需要的页面应该被删除。

2. 双击位于 工作 块左侧的 检查状态 选择阶段。您会看到有三个包含状态的数据项的检查。这些在 IA 解决方案逻辑中用于在阶段已完成时跳过阶段。

3. 查看与 IA 相关的操作步骤页面：02 机器学习预测、04 编写共享审查数据、05 等待审查预测 和 06 检查审查员异常。这些阶段应保持原样，因为它们对 IA 解决方案逻辑很重要。

4. 在 01 工作步骤 和 02 机器学习预测 之间添加更多页面，以添加业务逻辑。

5. 在 07 使用机器学习预测的工作步骤 页面之后添加更多页面，以添加业务逻辑。

6. 更新 队列名称 数据项的值。

图 7.2 – 同步审查模板主页面上的工作块

IA 数据

此页面包含对 IA 逻辑重要的数据项。这里没有需要更改的内容，尽管出于样式原因可以更改初始值。以下列表解释了数据项及其在 IA 模板逻辑中的使用方式：

1. 查看名为 IA 会话控制 的块。在 第六章 中描述的三个会话变量都存在。这些会话变量使控制器在管理实时 IA 操作时具有更大的灵活性。

2. 查看名为 手动审查所需标志 的数据项。此数据项存储是否需要对当前项进行 HITL 审查。

3. 找到名为 全局[项目数据]字段名称 的块。此块包含五个数据项。存储在这些数据项中的值是将在当前 预测 中添加的 字段名称。这意味着 项目数据.预测 将在会话运行期间创建。由于不使用“点表示法”来访问这些集合字段，因此可以安全地更改初始值。

4. 查看名为 全局 ML 状态 的块。它包含三个数据项，用于存储状态文本。这些状态用于在 主页面 上跳过步骤，并简化控制室的管理。

5. 查看 BE。此数据项为审阅者提供了一种强制抛出 BE 的方式，并且模板将在选中用于工作后标记该项为业务异常。

图 7.3 – 同步审查模板的 IA 页面

启动

已在绿色块的底部添加了两个占位符。可以在那里添加 IA 逻辑。以下列表包含您应更改模板或解释的重要内容的更改：

1. 在页面底部附近找到名为 已创建共享数据文件夹 的绿色块。应在此处添加阶段以添加与创建共享文件夹进行 HITL 审查相关的逻辑。

2. 如果未用于异常处理，则删除 已创建共享数据文件夹 块。

3. 在名为加载阈值数据的绿色块中找到。这是用于加载阈值数据的。如果它是一个 Excel 文件，可以使用实用工具 - 智能自动化::阈值 Excel 到集合操作。

4. 如果未用于异常处理，则删除加载阈值数据块。

图 7.4 – 同步审查模板启动页面底部

02 机器学习预测

此页面是实际机器学习预测步骤发生的地方，例如调用 API 网络服务或 CLI 程序。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 注意到在启动之后有一个名为终止开关的块。要使用此终止开关，从 BP 的系统 | 安全 | 凭据区域创建凭据。确保凭据的权限设置正确。

2. 从系统 | 进程 | 环境变量中创建一个新的环境变量，其名称为步骤 1中的凭据名称，其值为凭据名称。

3. 将终止开关凭据名称数据项的暴露更改为环境，并选择在步骤 2中创建的环境变量。这将导致数据项重命名。

4. 将获取终止开关凭据操作更改为使用步骤 3中的数据项名称。

图 7.5 – 同步审查模板的 02 机器学习预测页面上的“终止开关”块

1. 在名为预测的橙色块中找到名为Log [模型版本]的阶段。其目的是记录用于进行预测的机器学习模型的版本。创建一个环境变量，其值为Text或DateTime模型版本。

2. 将模型版本数据项的暴露更改为环境，并选择在步骤 5中创建的环境变量。这将导致数据项重命名。

3. 将Log [模型版本]阶段更改为使用步骤 6中的环境变量数据项。确保阶段日志记录设置为启用。

4. 在名为预测的橙色块中找到占位符注意。将其替换为获取预测所需的实际逻辑。

图 7.6 – 同步审查模板的 02 机器学习预测页面上的预测块

1. 编辑名为设置[预测]和[置信度分数]的绿色块中的Multi Calc阶段。将其更改为将实际预测保存到预测数据项中，置信度分数保存到置信度分数数据项中。

2. 如果未用于异常处理，则删除存储预测结果块。

图 7.7 – 同步审查模板的 02 ML 预测页面上的存储预测结果块

1. 找到名为 可选新 ML 模型评估 的绿色块，该块连接到 结束。您可以将一个调用次级 ML 模型进行评估目的的过程链接到这里。有关如何集成的说明，请参阅 第六章，示例 4。如果不需要，请删除注释和绿色块。

图 7.8 – 同步审查模板的 02 ML 预测页面上的可选新 ML 模型评估块

03 随机抽样

此页面包含确定预测是否需要 HITL 审查的随机抽样逻辑。这可以在 主页面 上替换为 03 阈值，或完全用自定义逻辑替换。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 从 系统 | 进程 | 环境变量 创建一个新的环境变量，其值为抽样率。建议使用介于 1 和 100 之间的十进制值。

2. 将 随机抽样率 数据项 曝光 更改为 环境，并选择在 步骤 1 中创建的环境变量。这将导致数据项被重命名。

3. 将 Require Manual Review? 决策阶段表达式更改为使用在 步骤 2 中重命名的数据项。

图 7.9 – 同步审查模板的 03 随机抽样页面

03 阈值

此页面包含确定预测是否需要人工审查的阈值逻辑。如果您想使用 阈值，请从 主页面 删除 03 随机抽样 页面，并用此页面替换。将阈值加载到集合中所需的逻辑应该在 启动页面 上执行。只有当您不想使用来自 实用工具 - 智能自动化 对象的阈值动作时，才需要更改此页面。

图 7.10 – 同步审查模板的 03 阈值页面

04 编写共享审查数据

此页面应更改以包含创建审查人员所需共享数据的步骤，无论是上传数据到网站、FTP 还是共享文件夹。需要填充两个绿色块以包含您的自定义逻辑。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 找到名为数据创建逻辑的绿色块，并插入插入所需持久化共享数据的逻辑。无论使用什么方法，都需要某种方式将其连接回工作队列中的项 ID。例如，项 ID可以是文件名、数据库记录或上传到 API 的字段的一部分。或者，您可以在项数据中存储共享位置的唯一标识符，以便以后进行检查。请注意，将原始预测和置信度分数作为评审数据的一部分可能会对评审员产生偏见。

2. 如果没有用于异常处理的用途，请删除数据创建逻辑块。

图 7.11 – 同步评审模板中 04 写入共享评审数据页面的“数据创建逻辑”块

1. 找到名为检查共享数据真实存在性的绿色块，并插入检查共享数据是否已成功持久化的逻辑。例如，你可以检查文件是否存在于正确的位置。这应该会导致设置True或False。

2. 如果没有用于异常处理的用途，请删除检查共享数据真实存在性块。

图 7.12 – 同步评审模板中 04 写入共享评审数据页面的“检查共享数据真实存在性”块

1. 找到工作队列::设置数据前的注释，靠近结束。用添加到项数据中唯一标识您创建的数据的逻辑替换此注释。这可以是数据库键、URL 或文件路径。这应该用于简化步骤 3中所需的逻辑，以验证共享数据是否存在于源处。

图 7.13 – 同步评审模板结束前的注释

05 等待已评审的预测

对于同步评审，我们在继续到下一个队列项之前，想要轮询并等待评审到来。此页面包含检查已完成评审的逻辑，以及将已完成评审读回 BP 的逻辑。请注意，这里引入了一个新的异常类型，评审员超时。这个新的异常防止了作为基础 BP 流程模板异常处理逻辑一部分的会话终止。我们需要使用不是系统异常的东西，因为根据标记项为异常页面中的逻辑，三个连续的系统异常将终止会话。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 将轮询循环块内的注释替换为检查评审是否完成的逻辑。这很可能涉及检查当前项目的项目 ID。

2. 使用表示此项目评审是否完成的表达式更改评审完成？决策阶段。

3. 从Number)允许的 HITL 评审中创建一个新的环境变量。

4. 将最大超时秒数数据项的暴露改为环境，并选择在步骤 3中创建的环境变量。这将重命名最大超时秒数数据项。

5. 将继续检查？决策阶段更改为使用步骤 4中重命名的数据项。

6. 注意，如果环境变量超时等待期超过，则会抛出新的异常类型评审员超时。

图 7.14 – 同步评审模板中 05 等待评审预测页面上的轮询循环块

1. 在名为在[项目数据]中存储已评审预测的绿色块中的注释中添加将已评审预测读回 BP 所需的逻辑。这可能是读取文本文件、数据库记录、网页中的文本等。

2. 将设置[已评审预测]和[评审理由]多计算阶段更改为将已评审预测值和纠正评审背后的理由保存到相应的数据项已评审预测和评审理由中。

3. 如果未用于异常处理，则删除在[项目数据]中存储已评审预测块。

图 7.15 – 同步评审模板中 05 等待评审预测页面上的[项目数据]块中的已评审预测

06 检查评审员异常

此页面检查评审员是否希望将此项目标记为业务异常。它检查已评审标签是否等于BE，这在IA 数据页面中定义。如果检测到BE（或标签已更改为何种状态），则会抛出业务异常。此页面不需要任何更改。

图 7.16 – 同步评审模板中 06 检查评审员异常页面

07 使用 ML 预测的工作步骤

此页面演示了如何获取最新的预测，以便在会话期间稍后使用。首先，检查是否存在已评审的预测。如果存在，则使用该预测值。如果不存在，则使用原始预测。这些阶段明确设置了日志记录，以便我们可以追踪此项目是使用已评审还是非已评审的预测进行处理的。

图 7.17 – 使用同步审阅模板的 ML 预测页面在 06 工作步骤上获取最终预测

我们已经完成了对第一个模板的查看，这个模板是用于同步或接近实时审阅的。作为一个高级总结，开发者需要提供以下逻辑：

• 做出生成预测和置信度分数的调用

• 为审阅者创建共享数据以查看

• 检查共享数据是否实际存在

• 检查人工审阅是否已完成

• 将人工审阅的预测读回到 BP

这一切都是针对您场景的特定逻辑。所有通用的 IA 解决方案逻辑都由模板处理。接下来，让我们看看单流程、单工作队列异步流程模板。在该模板中会有很多与这个模板相似之处。

单流程、单工作队列、异步审阅流程模板

此模板为那些我们不希望停止并等待 HITL 审阅的情况提供了一个单一会话解决方案。让我们看看这个异步审阅模板的细节，以便您可以在实践中成功实施它。

使用 IA 模板 2 – 异步审阅

在本节中，我们将逐页检查需要理解并更改的内容，以便您的 IA 用例得以实施。来自标准流程模板继承的页面和细节将不会讨论。这个模板和前一个模板之间有很多重叠，所以你会看到很多重复的内容。我决定保留这些重复内容，以便作为如何使用模板的完整参考。

以下每个子标题都指的是流程工作室中的一个页面。请打开相应的页面并阅读它，以了解您需要做出哪些更改才能使用此模板。我们将总共查看 11 个页面：

1. 主页：在这里，我们需要理解主要的工作步骤，并从工作块中添加/删除页面以满足您的用例。

2. IA 数据：这个页面包含在 IA 解决方案逻辑中使用的 重要数据项。

3. 启动：这里有一些占位符区域用于创建审阅的共享数据文件夹，并在需要时从 Excel 加载阈值值。

4. 02 ML 预测：在这个页面上，我们需要创建终止开关凭证并修改逻辑以使用该凭证。我们还需要创建一个用于 ML 模型版本的环境变量，以便进行记录。最后，我们需要进行 ML 预测并将预测和置信度分数存储在指定的数据项中。

5. 03 随机抽样：如果我们想使用随机抽样来确定预测是否需要审阅，我们应该创建一个环境变量来存储随机抽样百分比，并修改逻辑以使用该环境变量。

6. 03 阈值：如果我们想使用阈值，并且我们使用 Excel 存储阈值，我们可以保持此页面不变。否则，您需要在此处添加您的逻辑。

7. 04 编写共享审核数据：这里为您提供了添加创建审核数据所需逻辑的占位符。

8. 05 检查审核员异常：此页面无需更改。它包含逻辑，如果审核员认为项目不应由自动化处理，则抛出业务异常。

9. 06 使用 ML 预测的工作步骤：此页面演示了如何获取已审核预测，以便在流程中进一步使用。根据需要在此处添加额外的阶段。

10. 将项目推迟至手动审核：此页面防止需要审核的项目过早地被获取下一个项目功能选中。项目推迟是为了防止会话运行进入无限循环。

11. 检查已审核预测：添加逻辑以遍历所有待审核的项目，以查看它们是否已被审核。您还需要添加逻辑以将已审核预测保存到指定的 Data Items 中。

在Ch7 | IA 模板 2 – 异步审核组中打开异步审核流程以开始。在整个流程图中，您会看到绿色块。这些绿色块是为了文档和指导目的而添加到模板中的。请在进行过程中删除绿色块，因为它们可能会影响异常处理。

主页

主页包含高级流程图。在工作块中添加了四个阶段，以及一个选择阶段，用于控制如果项目重试，则跳过与 IA 相关的阶段。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 注意，在每次获取下一个项目之前都有对检查已审核预测页面的调用。这些检查发生在工作块之外。

图 7.18 – 在异步审核模板的主页上检查在获取下一个项目之前的已审核预测

1. 如果您想使用阈值方案来确定预测是否需要人工审核，请定位到工作块，并将03 随机抽样页面替换为03 阈值页面。

2. 双击检查状态选择阶段，位于工作块左侧。您会看到有三个包含状态的 Data Items，这些状态在 IA 解决方案逻辑中用于跳过阶段。

3. 看一下将项目推迟至手动审核页面的位置。如果需要对项目进行人工审核，则该项目将被推迟。在获取 下一个项目之前，会检查所有项目是否已完成审核。

4. 如果需要，在01 工作步骤和02 ML 预测之间添加更多页面。

5. 如果需要，在06 使用 ML 预测的工作步骤页面之后添加更多页面。

6. 更新队列名称数据项的值。

图 7.19 – 异步审查模板主页面上的工作块

IA 数据

此页面包含对 IA 逻辑重要的数据项。这里没有需要更改的内容，尽管出于样式原因可以更改初始值。以下列表解释了数据项及其在 IA 模板逻辑中的使用方式：

1. 查看名为IA 会话控制的块。在第六章中描述的三个会话变量存在。这些会话变量使控制器在管理实时 IA 操作时具有更大的灵活性。

2. 查看名为Flag的数据项。此数据项存储是否需要对当前项目进行 HITL 审查。

3. 找到名为全局[项目数据]字段名称的块。此块包含五个数据项。这些数据项中存储的值是字段名称，将被添加到当前项目数据中。例如，预测项目数据字段名称的初始值为预测。这意味着项目数据.预测将在会话运行期间创建。更改初始值是安全的，因为“点表示法”不用于访问集合字段。

4. 查看名为全局机器学习状态的块。它包含三个数据项，存储状态文本。这些状态用于在主页面上跳过页面，并在控制室中简化管理。

5. 查看名为抛出异常审查文本的数据项。其初始值设置为BE。此数据项为审查员提供了一种强制性地为正在审查的预测抛出Business Exception 的方式。审查员需要将“已审查预测”标签设置为BE，一旦模板被选中进行工作，该条目将被标记为业务异常。

启动

在启动页面底部的绿色块中有两个占位符。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 在页面底部附近找到名为创建共享数据文件夹的绿色块。此块旨在存放与创建共享文件夹进行 HITL 审查相关的逻辑。

2. 如果没有用于异常处理的用途，请删除创建共享数据文件夹块。

3. 找到名为加载阈值数据的绿色块。此块用于加载阈值数据。如果是 Excel 文件，可以使用实用工具 - 智能自动化::阈值 Excel 到集合操作。

4. 如果没有用于异常处理的用途，请删除加载阈值数据块。

02 机器学习预测

此页面是实际机器学习预测步骤（如调用 API Web 服务或 CLI 程序）应发生的地方。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 注意到在开始之后有一个关闭开关块。要使用此关闭开关，请从 BP 的系统 | 安全 | 凭据区域创建凭据。在凭据上设置适当的权限。

2. 从系统 | 进程 | 环境变量创建一个新的环境变量，其值为步骤 1中的凭据名称。

3. 将关闭开关凭据名称数据项的曝光度更改为环境，并选择在步骤 2中创建的环境变量。这将导致数据项重命名。

4. 将获取关闭开关凭据操作更改为使用步骤 3中的数据项名称。

5. 在名为预测的橙色块中找到名为记录[模型版本]的阶段。其目的是记录用于进行预测的机器学习模型的版本。从文本或日期时间模型版本创建一个环境变量，将其值作为其值。

6. 将模型版本数据项的曝光度更改为环境，并选择在步骤 5中创建的环境变量。这将导致数据项重命名。

7. 将记录[模型版本]阶段更改为使用步骤 6中的环境变量数据项。确保阶段日志记录设置为启用。

8. 在名为预测的橙色块中找到占位符注释。将其替换为获取预测所需的实际逻辑。

9. 编辑名为设置[预测]和[置信度分数]的多重计算阶段，位于名为存储预测结果的绿色块中。将其更改为实际预测保存到预测数据项，置信度分数保存到置信度分数数据项。

10. 如果未用于异常处理，则删除存储预测结果块。

11. 找到名为可选新机器学习模型评估的绿色块，该块连接到结束。您可以在此处链接一个进程，用于评估目的调用二级机器学习模型。有关如何集成的说明，请参阅第六章，示例 4。如果不需要，删除注释并将其绿色块化。

03 随机采样

本页包含确定预测是否需要 HITL 审查的随机采样逻辑。这可以在主页面的03 阈值部分替换，或完全用自定义逻辑替换。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 从系统 | 进程 | 环境变量创建一个新的环境变量，其值为采样率。建议使用介于 1 和 100 之间的十进制值。

2. 将随机采样率数据项的曝光度更改为环境，并选择在步骤 1中创建的环境变量。此数据项将被重命名。

3. 将是否需要手动审查？决策阶段表达式更改为使用在步骤 2中重命名的数据项。

03 阈值

此页面包含确定预测是否需要人工审阅的阈值逻辑。如果你想使用阈值，请从Main Page中删除03 Random Sampling页面，并用这个页面替换它。将阈值加载到集合中所需的逻辑应该在Start Up页面执行。只有当你不想使用Utility - Intelligent Automation对象中可用的阈值动作时，才需要对此页面进行更改。

04 编写共享审阅数据

此页面应修改为包含创建审阅者所需共享数据的步骤，无论是上传数据到网站、FTP、共享文件夹等。有两个绿色块需要填充你的自定义逻辑。以下列表包含你应该对模板进行的更改或对重要内容的解释：

1. 找到名为Data Creation Logic的绿色块，并插入持久化审阅者所需共享数据的逻辑。无论使用什么方法，都需要某种方式将其连接回工作队列中的Item ID。例如，Item ID可以是文件名、数据库记录或上传到 API 的字段的一部分。或者，你可以在Item Data中存储共享位置的唯一标识符，以便以后进行检查。请注意，将原始预测和置信度分数作为审阅数据的一部分可能会对审阅者产生偏见。

2. 如果没有用于异常处理的用途，请删除Data Creation Logic块。

3. 找到名为Check for Real Presence of Shared Data的绿色块，并插入检查共享数据是否已成功持久化的逻辑。例如，你可以检查文件是否存在于正确的位置。这应该会导致设置True或False。

4. 如果没有用于异常处理的用途，请删除Check for Real Presence of Shared Data块。

5. 在Work Queues::Set Data之前找到Note，靠近End。将这个Note替换为逻辑，以便在Item Data中添加唯一标识你创建的数据的字段。这可以是一个数据库键、一个 URL 或一个文件路径。这应该用于简化步骤 3中所需的逻辑，以验证共享数据是否存在于源处。

05 检查审阅者异常

此页面检查审阅者是否希望将此项目标记为业务异常。它检查审阅的标签是否等于IA Data页面。如果检测到BE（或标签已被更改为何种名称），则会抛出业务异常。此页面不需要任何更改。

06 使用 ML 预测的工作步骤

本页展示了如何获取最新的预测结果，以便在会话期间进一步使用。首先，检查是否存在已审查的预测。如果存在，则使用该预测值。如果不存在，则使用原始预测值。这些阶段明确设置了日志记录，以便我们可以追踪此项目是使用已审查的预测还是非审查的预测进行处理的。

暂缓项目以进行人工审查

确定项目需要 HITL 审查后，需要暂缓该项目，以便审阅者有足够的时间采取行动。将暂缓时间数据项更改为适当的暂缓时间。想象一下队列中只有一个项目。暂缓时间需要设置得足够高，以免在单个会话运行中连续两次被选中；否则，会导致无限循环。

图 7.20 – 异步审查模板的暂缓项目以进行人工审查页面

检查已审查预测

本页是同步和异步模板之间的主要区别。在这个异步模板中，此页在调用获取下一个项目之前，在工作块外部被调用。这允许其他项目在等待预测被审查的同时继续工作。下一个主要区别是我们必须对所有待审查的项目进行检查，而不是对当前项目进行检查。当前项目不存在，因为我们已经处于工作块外部。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 用逻辑替换链接到开始的备注，以检索需要检查的所有记录。这可能是由数据库查询检索所有待审查的项目，或者获取预期存储完成审查内容的网络文件夹的内容。要检查的项目列表应保存在所有待完成审查的项目集合中。

图 7.21 – 异步审查模板的检查已审查预测页面开始部分

1. 在循环内找到名为设置[要检查的项目 ID]的计算阶段。更改表达式，以便将我们正在检查的项目 ID 保存到要检查的项目 ID数据项中。

图 7.22 – 更改设置[要检查的项目 ID]计算阶段

1. 用逻辑替换名为检查完成审查的块内的备注，以检查项目是否已完成审查。请注意，在此块中发生的任何异常都被屏蔽，以防止进程终止。

2. 在蓝色的检查已完成审阅块之后找到名为Review Complete?的决策阶段。将表达式替换为指示此项目的审阅是否完成的表达式。

图 7.23 – 确定此项目的审阅是否完成

1. 将绿色块在[数据]中存储已审阅预测中的注意替换为将审阅预测读回到 BP 所需的逻辑。这可能包括读取文本文件、数据库记录、网页中的文本等。

2. 将设置[已审阅预测]和[审阅理由]多计算阶段更改为将审阅预测值和修正审阅背后的推理保存到各自的数据项中，即已审阅预测和审阅理由。

3. 如果未用于异常处理，则删除在[数据]中存储已审阅预测块。

图 7.24 – 异步审阅模板中检查审阅预测页面上的[数据]块中存储的已审阅预测

我们已经完成了对第二个模板的查看。两个单流程、单工作队列模板之间的差异在以下表格中突出显示。

同步模板 页面名称	异步模板 页面名称	差异
主页面	主页面	同步模板等待当前项目的预测审阅（如果需要）在工作块内。异步模板在每个获取下一个项目之前检查所有项目的已审阅预测，在工作块外。使用推迟。
IA 数据	IA 数据	无。
启动	启动	无。
02 ML 预测	02 ML 预测	无。
03 随机抽样	03 随机抽样	无。
03 阈值化	03 阈值化	无。
04 编写共享 审阅数据	04 编写共享 审阅数据	无。
05 等待 已审阅预测	检查 已审阅预测	异步模板必须循环通过多个项目。这发生在主工作块之外。同步版本仅在工作块内检查当前项目。
06 检查 审阅者异常	05 检查 审阅者异常	无。尽管编号不同，页面逻辑是相同的。
07 使用 ML 预测 工作步骤	06 使用 ML 预测 工作步骤	无。尽管编号不同，页面逻辑是相同的。
N/A	将项目 推迟至手动审阅	只有异步模板有这个功能。当需要审阅时，使用推迟以防止获取下一个项目操作过于迅速，从而进入无限循环。

表 7.1 – 单进程、单工作队列模板之间的差异

接下来，让我们看看我们的最终模板，它被分为三个 BP 流程。

三进程、三工作队列、异步审查流程模板

我们的第三个模板是最复杂的，因为它被分为三个流程。第一个流程包含我们期望从传统 RPA 中得到的标准业务逻辑。在需要做出机器学习预测之前，数据被推入第二个工作队列，并且流程 1 中的项目执行被暂停。

第二个流程生成机器学习预测并确定是否需要 HITL 审查。如果需要审查，数据将被推入第三个工作队列。如果不需审查，队列 1 中的等效项目将被允许在流程 1 中继续自动化处理。

第三个流程创建共享审查数据并检查已完成审查。一旦项目成功审查，队列 1 中其等效项目将被允许在流程 1 中继续自动化处理。

整个模板是异步的，因为它被分为三个部分。这是我默认选择的新 IA 解决方案模板，除非有对会话数量的具体限制，或者有同步审查的需求。现在，让我们逐个查看每个“子模板”。

使用 IA 模板 3 – 01 – 业务逻辑

此流程与原始 BP 流程模板非常相似。让我们逐页查看差异。以下每个子标题都指的是流程工作室中的一个页面。请打开相应的页面并阅读，以了解您需要做出哪些更改才能使用此模板。我们将在第一个子模板中查看六个页面：

1. 主页面：添加和删除工作块中的页面以满足您的用例。获取下一个项目已添加标签过滤器，以防止等待机器学习预测和机器学习审查的项目被处理。

2. IA 数据：此页面包含在 IA 解决方案逻辑中使用的 重要数据项。

3. 02 推送至队列 2：此页面包含将项目添加到工作队列 2 以进行机器学习预测的逻辑。它还会标记当前项目，以防止其被获取下一个项目操作选中。

4. 03 检查审查员异常：此页面无需更改。它包含逻辑，如果审查员认为项目不应该由自动化处理，则抛出业务异常。

5. 04 使用机器学习预测的工作步骤：此页面展示了如何获取已审查的预测，以便在流程中进一步使用。如有需要，请在此处添加额外的阶段。

6. 解锁项目：此页面解锁当前项目，以便在移除其标签后，获取下一个项目可以将其取走以进行进一步处理。

打开主页面。

主页面

与标准流程模板相比，主页的一个主要变化是获取下一项阶段设置了标签过滤器。在工作块内部，在我们的工作步骤之后有一个页面将当前项推送到工作队列 2进行 ML 预测。我们还有一个页面检查审阅者是否想要为此项抛出业务异常。可以使用选择阶段跳过步骤，该阶段检查与 IA 相关的项状态。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 双击每个获取下一项操作。可以看到有标签过滤器可以过滤掉等待 ML 预测或手动审查的项。

2. 注意到在工作块内部有一个名为02 推送到队列 2的页面，该页面链接到解锁项页面。在当前项被推送到队列 2 进行 ML 预测后，它会被标记并放回队列。这个标记防止它在 ML 预测完成前被获取下一项操作选中。

3. 定位到03 检查审阅者异常页面。此页面用于检查审阅者是否想要抛出业务异常。

4. 双击工作块左侧的检查状态选择阶段。可以看到我们可以根据项的状态跳过执行页面。

5. 修改包含队列名称队列名称和队列名称 2的数据项的值。

6. 如果需要，在01 工作步骤和02 ML 预测之间添加更多页面。

7. 如果需要，在04 使用 ML 预测的工作步骤之后添加更多页面。

IA 数据

此页面包含对 IA 逻辑重要的数据项。这里没有需要更改的内容，尽管出于样式原因可以更改初始值。如果更改，数据项必须在其他两个模板中也有相应的更改。这是为了在整个三个模板中保持项数据字段名称、状态和标签的一致性。以下列表解释了数据项及其在 IA 模板逻辑中的使用方式：

1. 找到名为全局[项数据]字段名称的块。此块包含四个数据项。存储在这些数据项中的值是将在当前项数据中添加的字段名称。例如，预测项数据字段名称的初始值为预测。这意味着项数据.预测将在会话运行期间创建。队列 1 项 ID 项数据字段名称的初始值为队列 1 项 ID。这意味着队列 2的项数据将有一个名为项数据.队列 1 项 ID的字段。由于“点符号”不用于访问集合字段，因此可以安全地更改初始值。

2. 查看全局 ML 状态块。它包含两个数据项，用于存储状态文本。这些状态用于在主页上跳过步骤和在控制室中简化管理。

3. 查看名为 Global ML Tags 的块。它包含两个数据项，用于存储标签文本。这些标签可以防止使用 Get Next Item 获取项目。

4. 查看名为 Throw Exception Review Text 的数据项。其初始值设置为 BE。此数据项为审阅者提供了一种强制抛出业务异常的方法，以便对正在审阅的预测进行审查。审阅者需要将“审阅预测”标签设置为 BE，一旦被选中进行工作，模板将标记该项目为业务异常。

02 推送到 Queue 2

此页面将创建预测所需的数据输入到集合中，并将该集合作为项目数据提交到 Queue 2。它还标记当前项目，以确保在机器学习预测完成之前不会被 Get Next Item 拾取。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 将绿色块中的 Note 阶段替换为填充 Queue 2 Item Data 集合的逻辑。此集合应包含进行机器学习预测所需的输入数据。

2. 在绿色块中查看我们如何在 Queue 2 Item Data 集合中添加 Queue 1 的当前 Item ID。这为 Process 2 和 Queue 2 提供了对 Queue 1 中等效项目的引用。

3. 如果没有用于异常处理的用途，请删除名为 Build Queue 2 Item Data 的绿色块。

4. 查看我们如何使用 Add Tag “Waiting ML Prediction” 动作将当前项目标记为 Waiting ML Prediction。

5. 查看我们如何将 Queue 2 的项目 ID 保存到 Queue 1 的 Item Data 中。这为 Process 1 和 Queue 1 提供了对 Queue 2 中等效项目的引用。

03 检查审阅者异常

此页面检查审阅者是否希望将此项目标记为 Business Exception。它检查审阅的标签是否等于 IA Data 页面。如果检测到 BE（或标签已更改为何种状态），则会抛出 Business Exception。此页面不需要任何更改。

04 使用 ML 预测的工作步骤

此页面演示了如何获取最新的预测，以便在会话期间进一步使用。首先，检查是否存在已审阅的预测。如果存在，则使用该预测值。如果不存在，则使用原始预测。这些阶段明确设置了日志记录，以便我们可以追踪此项目是使用审阅还是非审阅预测进行处理的。

解锁项目

此页面解锁当前项目，以便将其放回队列中。此页面不需要任何更改。当前项目在其标签被删除之前不会再次被拾取。

现在，让我们看看 Process 2 的模板。

使用 IA 模板 3 – 02 – ML Prediction

此流程执行生成机器学习预测的步骤，并通过随机抽样或阈值确定是否需要人工审查。如果需要，它将被推入 队列 3。如果不需，则 队列 1 中的对应项目将被取消标记，以便继续处理。

以下每个小节标题都指的是流程工作室中的一个页面。请打开相应的页面并阅读它，以了解您需要进行的更改以使用此模板。我们将总共查看八个页面：

1. 主页面：在此处了解此流程的高级步骤；如果需要，可以在此处更换审查标准。

2. IA 数据：此页面包含在 IA 解决方案逻辑中使用的 重要数据项。

3. 启动：如果使用阈值处理，此处有一个占位符来从 Excel 加载阈值值。

4. 01 机器学习预测：在此页面，我们需要创建终止开关凭据并修改逻辑以使用该凭据。我们还需要创建一个环境变量来记录机器学习模型版本。最后，我们需要进行机器学习预测并将预测和置信度分数存储在指定的数据项中。

5. 02 随机抽样：如果我们想使用随机抽样来确定是否需要对预测进行审查，我们应该创建一个环境变量来存储随机抽样百分比，并修改逻辑以使用该环境变量。

6. 02 阈值处理：如果我们想使用阈值处理，并且使用 Excel 存储阈值，我们可以保持此页面不变。否则，您需要在此处添加您的逻辑。

7. 03a 更新队列 1 项目：此页面包含更新等效 队列 1 项目的状态、标签和项目数据的固定逻辑。

8. 03b 将数据推入队列 3 并更新队列 1 项目：当需要 HITL 审查时，此页面将数据推入 队列 3，并更新等效 队列 1 项目的状态、标签和项目数据。

打开 Ch7 | IA 模板 3 – 3 流程 3 队列 文件夹以开始，并导航到主页面。

主页面

主页面上的此 工作 块包含四个页面和一个决策阶段。在获取下一个项目中不使用标签过滤器，也不使用项目解锁或延期。以下列表包含您应更改模板或解释的重要内容的更改：

1. 查看工作块中的01 机器学习预测页面。此页面包含进行机器学习预测的逻辑。

2. 查看02 随机抽样页面。如果您想使用阈值方案来确定是否需要对预测进行人工审查，请将其替换为02 阈值处理。

3. 双击左侧 工作 块中的 跳过步骤？ 选择阶段。您会看到一个状态，预测完成，我们可以用它来跳过 工作 块中的阶段。

4. 更改包含队列名称队列名称、队列名称 2和队列名称 3的三个数据项的值。

5. 请注意，除非标记为异常，否则所有项目都会被标记为已完成。

IA 数据

此页面是一个包含对 IA 逻辑重要的数据项的中心位置。这里不需要更改，尽管可以更改初始值以改变样式。如果更改，必须也在其他两个模板IA 数据页面的等效数据项中进行更改。这是为了在整个三个模板中保持一致的项目数据字段名称、状态和标签。以下列表解释了数据项及其在 IA 模板逻辑中的使用方式：

1. 请注意，存在一个会话变量，强制 HITL 审查，可以强制所有经过预测的项目也进行人工审查。

2. 全局所有队列的[项目数据]字段名称块包含四个数据项。这些数据项中存储的值是将在当前项目数据中添加的字段名称。例如，预测项目数据字段名称的初始值为预测。这意味着项目数据.预测将在会话运行期间创建。队列 2 项目 ID 项目数据字段名称的初始值为队列 2 项目 ID。此文本将作为字段添加到推送到队列 3的数据中。

3. 请注意，全局机器学习状态块包含三个数据项，用于存储状态文本。这些状态用于在主页面上跳过步骤以及在控制室中简化管理。

4. 请注意，全局机器学习标签块包含两个数据项，用于存储标签文本。这些标签控制是否可以使用获取下一个项目在队列 1中检索项目。

启动

此页面有一个占位符，您可以在其中添加逻辑将阈值数据加载到 BP 中：

1. 找到名为加载阈值数据的绿色块。这是用于加载阈值数据的。如果它是一个 Excel 文件，可以使用实用工具 - 智能自动化::阈值 Excel 到集合操作。

2. 如果未用于异常处理，请删除加载阈值数据块。

01 机器学习预测

此页面是实际机器学习预测步骤（如调用 API Web 服务或 CLI 程序）应发生的地方。以下列表包含您应更改模板或解释的重要内容的更改：

1. 请注意，在启动之后有一个终止开关块。要使用此终止开关，请从 BP 的系统 | 安全 | 凭据区域创建凭据。在凭据上设置适当的权限。

2. 从系统 | 进程 | 环境变量创建一个新的环境变量，其值为步骤 1中的凭据名称。

3. 将终止开关凭据名称数据项的暴露设置为环境，并选择在步骤 2中创建的环境变量。这会导致数据项被重命名。

4. 将获取关闭开关凭证操作更改为使用步骤 3中的数据项名称。

5. 在名为预测的橙色块中找到名为Log [模型版本]的阶段。其目的是记录正在使用哪个版本的机器学习模型进行预测。从文本或日期时间模型版本创建一个环境变量作为其值。

6. 将模型版本数据项的曝光更改为环境，并选择在步骤 5中创建的环境变量。这将导致数据项被重命名。

7. 将Log [模型版本]阶段更改为使用步骤 6中的环境变量数据项。确保阶段日志记录设置为启用。

8. 在名为预测的橙色块中找到占位符注释。用实际需要的逻辑替换它以获得预测。

9. 编辑名为存储预测结果的绿色块中的多计算阶段设置[预测]和[置信度分数]。将其更改为实际预测保存在预测数据项中，置信度分数保存在置信度分数数据项中。

10. 如果没有用于异常处理的用途，请删除存储预测结果块。

11. 在名为可选新机器学习模型评估的绿色块中找到连接到结束的绿色块。您可以将一个进程链接到这里，以便用于评估目的的二级机器学习模型。有关如何集成的说明，请参阅第六章，示例 4。如果不需要，请删除注释和绿色块。

02 随机采样

本页包含确定预测是否需要 HITL 审查的随机采样逻辑。这可以在主页面上替换为02 阈值处理，或者完全用自定义逻辑替换。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 从系统 | 进程 | 环境变量创建一个新的环境变量，其值为采样率。建议使用介于 1 和 100 之间的十进制值。

2. 将随机采样率数据项曝光更改为环境，并选择在步骤 1中创建的环境变量。此数据项将被重命名。

3. 将是否需要手动审查？决策阶段表达式更改为使用步骤 2中重命名的数据项。

02 阈值处理

本页包含确定预测是否需要人工审查的阈值逻辑。如果您想使用阈值，请从主页面中删除02 随机采样页面，并用这个页面替换它。将阈值加载到集合中的逻辑应该在启动页面上执行。如果不想使用实用工具 - 智能自动化对象中可用的阈值操作，则不需要对页面进行更改。

03a 更新队列 1 项

仅当不需要人工审查预测时，此页才会执行。首先，锁定 Queue 1 的项目，并将预测和置信度分数添加到其项目数据中。然后，更新其状态为 无需手动审查。移除 等待机器学习预测 标签，允许 Process 1 通过 获取下一个项目 再次拾取它。此页无需任何更改。

如果此页未运行，则将运行 03b 推送到队列 3。

03b 推送到队列 3 并更新队列 1 项目

此页包含将创建可审查预测所需的输入数据添加到集合中的逻辑。然后，将集合推送到 Queue 3。它还更新 Queue 1 中等效项目的数据，包括预测结果，并更新项目的状态以指示它需要 HITL 审查。以下列表包含您应更改模板或解释的重要内容的更改：

1. 将绿色块名为 Build Queue 3 Item Data 中的 Note 阶段替换为填充 Queue 3 Item Data 集合的逻辑。此集合应包含创建可审查预测所需的输入数据。

2. 查看名为 Build Queue 3 Item Data 的绿色块中的阶段。注意我们将当前 (Queue 2 的) Item ID 添加到添加到 Queue 3 的 Queue 3 Item Data 集合中。这是为了可追溯性。通过 Queue 3 Item Data，`Queue 1* 的 Item ID 已经有一个副本。

3. 如果未用于异常处理，则删除名为 Build Queue 3 Item Data 的绿色块。

4. 找到 将 Queue 3 Item ID 添加到 [Queue 1 Item Data] 操作。此操作，直到 Work Queue::Set Data 操作，用于更新 Queue 1 中的等效项目，包括置信度分数和预测。

5. 找到 将 Queue 1 的状态更新为“手动审查所需” 操作。此操作和接下来的两个操作将 Queue 1 的项目状态更改为 手动审查所需，移除 等待机器学习预测 标签，并添加 手动审查 所需 标签。

接下来，让我们看看最终的模板，该模板用于创建审查数据并检查完成的审查。

使用 IA 模板 3 – 03 – HITL 审查

此第三个也是最后一个流程模板包含创建共享审查数据记录和检查已审查预测的逻辑。如果审查未完成，则将项目推迟。如果审查完成，则更新 Queue 1 的项目，以便它可以继续处理。以下每个子标题都指的是流程工作室中的一个页面。请打开相应的页面并阅读它，以了解您需要进行的更改。我们将总共查看六个页面：

1. 主页面: 理解高级流程步骤并更新包含队列名称的数据项的值。

2. IA 数据: 本页包含在 IA 解决方案逻辑中使用的 重要数据项。

3. 启动：此页面有一个占位符区域，如果需要，可以创建用于审查的共享数据文件夹。

4. 01 编写共享审查数据：这里提供了占位符，您可以添加创建审查数据所需的逻辑。

5. 02 检查已审查的预测：添加逻辑以检查项目是否已审查。您还需要添加逻辑以将已审查的预测保存到指定的数据项中。

6. 推迟：选择合适的推迟时间，如果项目尚未审查，则推迟项目。

在Ch7 | IA 模板 3 – 3 过程 3 队列组中打开03 – HITL 审查过程以开始。导航到主页。

主页

队列名称和队列名称 3数据项值。

IA 数据

此页面是一个中心位置，包含对 IA 逻辑重要的数据项。这里不需要更改，尽管初始值可以更改以适应风格原因。如果更改，其他两个模板的IA 数据页面中的数据项也必须更改其等效项。这是为了在整个三个模板中保持一致的项目数据字段名称、状态和标签。以下列表解释了数据项及其在 IA 模板逻辑中的使用方式：

1. 定位到页面底部的IA 会话控制块。这里有两个会话变量。禁用 HITL 审查用于禁用 HITL 审查要求，而强制创建审查数据强制项目重新创建其审查数据。

2. 全局所有队列的[项目数据]字段名称块包含四个数据项。这些数据项中存储的值是字段名称，将被添加到当前的项目数据中。例如，已审查预测项目数据字段名称的初始值为Item Data.Reviewed Prediction将在会话运行期间创建。

3. 请注意，全局机器学习状态块包含一个存储状态文本的数据项。此状态用于跳过过程 1和队列 1的主页上的步骤，并简化控制室的管理。

4. 请注意，全局机器学习标签块包含一个存储标签文本的数据项。此标签控制是否可以使用获取下一个项目在过程 1、队列 1中检索项目。

启动

此页面在绿色块中有一个占位符，可以添加创建用于审查的共享文件夹的逻辑：

1. 定位到页面底部的绿色块已创建的共享数据文件夹。如果需要，这里应包含有关创建 HITL 审查所需共享文件夹的逻辑。

2. 如果未用于异常处理，则删除已创建的共享数据文件夹块。

01 编写共享审查数据

此页面包含创建审查所需共享数据的步骤，无论是上传数据到网站、FTP、共享文件夹等。有两个绿色块需要填充您的自定义逻辑。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 找到名为 数据创建逻辑 的绿色块，并插入持久化审查者所需共享数据的逻辑。无论使用哪种方法，都需要某种方式将其连接回工作队列中的Item ID。例如，Item ID可以是文件名、数据库记录或上传到 API 的字段的一部分。或者，您可以在Item Data中存储共享位置的唯一标识符，以便以后进行检查。请注意，将原始预测和置信度分数作为审查数据的一部分可能会对审查者产生偏见。如果您想向审查者提供原始预测标签和置信度分数，请向IA 数据页面上的 全局[所有队列的项数据字段名称] 块添加两个新的数据项以引用这些字段。

2. 如果未用于异常处理，则删除 数据创建逻辑 块。

3. 找到名为 检查共享数据真实存在性 的绿色块，并插入检查共享数据是否已成功持久化的逻辑。例如，您可以检查文件是否位于正确的位置。这将导致将Shared Data Found?数据项设置为True或False。

4. 如果未用于异常处理，则删除 检查共享数据真实存在性 块。

5. 找到Item Data之前的注释。这可能是一个数据库键、URL 或文件路径。这应用于简化步骤 3中所需的逻辑，以验证共享数据是否存在于源处。

02 检查已审查预测

此页面检查当前项是否已审查。如果审查已完成，它将读取修订后的预测及其理由，并更新等效的 队列 1 项，以便继续处理。以下列表包含您应该对模板进行的更改或对重要内容的解释：

1. 将[禁用 HITL 审查]决策阶段之后的绿色 注意 阶段替换为检查此项是否已审查所需的步骤。这可能会涉及检查当前项的Item ID。

2. 将 审查完成? 决策阶段更改为表示此项审查是否完成的表达式。

3. 找到名为 将已审查预测存储在[项数据] 的绿色块，并添加将审查的预测读回到 BP 所需的逻辑。这可能包括读取文本文件、数据库记录、网页中的文本等。

4. 将 设置[已审查预测]和[审查理由] 多计算阶段更改，以便将审查的预测值和修正审查背后的推理保存在各自的数据项中，即已审查预测和审查理由。

5. 如果未用于异常处理，则删除 将已审查预测存储在[项数据] 块。

6. 找到将[已审查预测]添加到[队列 1 项目数据]操作。如果项目已成功审查，则执行此操作和接下来的两个操作。它们将审查预测和理由更新到队列 1 中等效的项目。

7. 找到将队列 1 的状态更新为“手动审查完成”操作。这个操作和下一个操作用于将队列 1 的项目状态更新为手动审查完成并移除手动审查所需标签。这允许队列 1 的项目继续其自动化流程。

延迟

如果项目尚未审查，则将其延迟，以便审阅者有足够的时间采取行动。将 延迟时间 数据项更改为适当的延迟时间。想象一下队列中只有一个项目。延迟时间需要设置得足够高，以免在单个会话运行中连续两次被选中；否则，会导致无限循环。

我们已经完成了对构成最终模板的三个流程的审查。为了巩固我们所看到的，并进一步了解三个子模板之间是如何相互作用的，我提供了 IA 数据 页面的摘要。这将使您能够看到每个子模板中使用的哪些状态、标签和 项目数据 字段。

三进程模板的 IA 数据摘要

Y/N 表值表示数据项是否出现在模板的 IA 数据 页面上。

项目数据字段名称

数据项名称	初始值	01 – 业务逻辑	02 – 机器学习预测	03 – HITL 审查
预测项目数据字段名称	预测	Y	Y	N*
置信度项目数据字段名称	置信度	N	Y	N*
已审查预测项目数据字段名称	已审查预测	Y	N	Y
审查理由	审查理由	N	N	Y
审查数据创建项目数据字段	审查数据创建	N	N	Y
队列 1 项目 ID 项目数据字段名称	队列 1 项目 ID	Y	Y	Y
队列 2 项目 ID 项目数据字段名称	队列 2 项目 ID	Y	Y	N
队列 3 项目 ID 项目数据字段名称	队列 3 项目 ID	N	Y	N

表 7.2 – 项目数据字段名称

*** 如果你想让审阅者知道原始预测和置信度** 分数，可以将这两个数据项添加到子模板 3 中。

状态

数据项名称	初始值	01 – 业务逻辑	02 – 机器学习预测	03 – HITL 审查
预测完成状态	预测完成	N	Y	N
手动审查所需状态	手动审查所需	N	Y	N
手动审查不必要状态	手动审查不必要	Y	Y	N
手动审查完成状态	手动审查完成	Y	N	Y

表 7.3 – 状态

标签

数据项名称	初始值	01 – 业务逻辑	02 – 机器学习预测	03 – HITL 审查
等待机器学习预测标签	等待机器学习预测	Y	Y	N
手动审查所需标签	手动审查所需	Y	Y	Y

表 7.4 – 标签

会话变量

数据 项名称	初始值	01 – 业务逻辑	02 – ML 预测	03 – HITL 审查
强制 HITL 审查	False	N	Y	N
禁用 HITL 审查	False	N	N	Y
强制创建审查数据	False	N	N	Y

表 7.5 – 会话变量

摘要

在本章中，我们将迄今为止的所有开发和设计概念汇总并打包成可重用的模板。这些模板为创建一个管理 ML 复杂性和风险的 IA 解决方案提供了坚实的基础。首先，我们查看了一个包含 IA 特定动作的对象，这些动作在 BP 的默认 VBOs 中缺失。然后我们查看了两份单一流程、单一工作队列的模板。一个模板用于同步审查，而另一个模板用于异步审查。最后，我们查看了一个三部分流程模板，它将业务逻辑与 ML 预测和 HITL 审查分开。

这本书的 IA 解决方案设计部分到此结束。在下一章中，我们将探讨 IA 如何影响过程工作室之外的 BP 运营——例如，在控制室和系统设置中。我们还将推测 IA 如何影响 BP 的机器人运营模型（ROM）。ROM 是一个至关重要的主题，它是成功采用 IA 的基础。

第三部分：控制室和管理

本书这部分内容从对象和流程图转向了 BP 和 IA 更广泛的运营关注点。第八章讨论了 BP 的逻辑访问模型，由于 IA 可能需要的新用户角色，以及这些角色在 BP 软件中应拥有的权限。它还讨论了多团队环境以及如何限制这些新角色所能看到的范围。

第九章介绍了流行的 ML 部署方法。这些方法决定了我们如何更新和回滚 ML 模型以在 BP 中使用。它还介绍了一些 SQL 查询，可以用于从 BP 的会话日志表中提取 ML 审计数据。

BP 的机器人运营模型（ROM）是一种行业领先的方法，帮助业务实现自动化目标。尽管它不是一个技术产品，但毫无疑问，它是 BP 区别于其他 RPA 供应商的一个重要组成部分。第十章探讨了 ROM，并讨论了哪些领域将最受 IA 的影响。

本部分包含以下章节：

• 第八章，LAM、用户角色和多团队环境

• 第九章，ML 部署和数据库操作

• 第十章，IA 对机器人运营模型的影响

第八章：LAM、用户角色和 MTE

逻辑访问模型（LAM）定义了哪些 BP用户角色应该存在，每个用户角色应该拥有哪些 BP权限，以及用户角色到权限映射如何根据其环境（例如，开发、UAT 和生产）而有所不同。LAM 允许 RPA 团队规划哪些用户角色需要用于日常运营，通常以电子表格的形式呈现。LAM 文档应进行版本控制，并作为 BP 环境可以对照的真相来源。它是安全性的重要部分，因为角色和权限之间的映射应根据最小权限原则进行。

随着我们从 RPA 过渡到 IA，我们会发现需要更多团队同事访问 BP 环境。这需要修改您现有的 LAM 文档，并添加新的用户角色。随着我们进入本章，我们将讨论哪些 IA 用户角色可能需要添加，它们应该拥有哪些权限，然后实际创建它们。我们还将探讨何时可以使用多团队环境（MTEs）来限制用户角色可以看到的数据范围。本章的最后一部分将探讨一个基于 LAM Excel 模板的修订版 LAM 文档，包含 IA 新增内容，可在 BP 门户上找到：portal.blueprism.com/documents/blue-prism-logical-access-model-lam-v70。

本章我们将涵盖以下主要内容：

• IA 用户角色和权限

• MTEs

• 更新的 LAM 模板

技术要求

在 GitHub 的ch8文件夹中下载并导入.bprelease文件：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/tree/main/ch8。

重要提示

如果您按照时间顺序阅读这本书，到现在您已经导入 13 个已发布的流程。BP 试用版的许可证对已发布流程的数量有限制，为 15 个。本章的发布文件包含六个已发布的流程。如果您正在使用试用版，我建议您取消发布来自Ch4、Ch5和Ch6组的所有流程，以便导入本章的发布文件和未来的章节。

IA 用户角色和权限

BP 自带一系列预定义的用户角色。然而，这些默认用户角色及其角色到权限映射是在 IA 开发之前制定的。IA 的出现导致需要考虑许多新的用户角色。以下是一些包括的内容：

• ML 审计员：ML 审计员负责审计 ML 预测结果和 HITL 审查，因此他们需要查看和导出会话日志。

• ML 部署者：ML 部署者更新正在使用的 ML 算法。这发生在由应用程序和业务逻辑更新引起的流程和对象更改之外。

• ML 审核员：ML 审核员角色将修改与审核预测相关的会话变量。

重要提示

本章中展示的用户角色和权限列表基于 BP 7.x 版本中可用的内容。如果你使用的是旧版本 BP，你可能会拥有更少的权限。除非你使用的是低于 6.3 版本的 BP（MTE 介绍时），否则这不会影响本章的内容。

ML Auditor

ML Auditor 角色用于查看和导出与 ML 相关的会话日志。与不经常发生的通用安全审计不同，ML 审计可能需要频繁进行。ML 审核员可能需要在每次 ML 算法部署后进行 hypercare，或者定期导出人工审核预测的结果。定期的 ML 审计是抵消模型衰减和数据漂移影响所必需的。让我们以一个例子创建这个 ML Auditor 角色。

重要提示

这些示例假设你正在使用 BP 原生身份验证，并且你以具有 系统管理员 角色的用户登录。如果你使用的是 Active Directory 身份验证或身份验证服务器，你可能会需要 IT 或 Hub 管理员的帮助来为你创建用户。

示例 1 – 创建 ML Auditor 用户角色

在本例中，我们将执行四个高级步骤：

1. 创建 ML Auditor 用户角色。

2. 选择允许你查看和导出会话日志所需的最小权限集。

3. 创建具有 ML Auditor 角色的新用户。

4. 测试用户。

创建 ML Auditor 用户角色

我们的第一步是创建用户角色本身：

1. 访问 系统 | 安全 | 用户角色。

2. 点击 ML Auditor 作为角色名称。

将权限映射到 ML Auditor 用户角色

接下来，我们需要选择 五个 权限添加到我们新创建的用户角色中：

1. 点击一次新创建的 ML Auditor 角色以确保它被突出显示。在右侧面板的 权限 部分中，勾选以下五个权限：对象工作室 | 查看业务对象定义，流程工作室 | 查看流程定义，资源 | 查看资源，系统管理员 | 审计 – 业务对象日志，和 系统管理员 | 审计 – 流程日志。

2. 点击右下角的 应用 按钮以保存更改。

创建具有 ML Auditor 用户角色的新用户

在测试新用户角色之前，创建一个用户并分配 ML Auditor 角色：

1. 访问 系统 | 安全 | 用户。

2. 在 用户 面板上的任何位置右键单击，然后选择 创建用户 或 新建。无论 创建用户 或 新建 出现在哪里，它们都会引导到相同的用户创建向导。

3. 输入用户名 mlaudit。选择一个密码，并重复输入两次。

4. 点击 下一步，直到到达选择用户角色的屏幕。

5. 选择 ML Auditor 用户角色，并点击 完成。

测试新用户

要测试用户，我们需要登出，使用新用户登录，并验证用户只能导出和查看会话日志：

1. 从 BP 中登出。

2. 使用mlaudit用户和您选择的密码登录。

3. 验证您是否可以看到 BP 的工作室部分。打开任何流程或对象，并确认在流程和对象工作室内部您只有读取访问权限。

4. 访问 BP 的控制部分。验证只有会话管理可见，且无法看到任何队列或计划。

5. 访问 BP 的系统部分。验证只有审计 | 进程日志和审计 | 对象日志可见。

6. 点击审计 | 进程日志并将今天过滤器设置为全部。右键单击任何会话，并确认会话日志可查看。

7. 在会话日志仍然打开的情况下，点击文件 | 导出整个日志…。验证您是否能够将日志保存为文件。

我们已经完成了创建和测试ML Auditor用户角色的过程。尽管此用户无法在控制室中查看单个工作队列，但他们能够从审计 | 进程日志部分查看所有会话日志，无论它们属于哪个流程。我们将在本章后面的MTE部分探讨如何限制此用户角色可以查看的流程集。

ML Deployer

此角色负责更新 BP 解决方案以使用更新的 ML 模型或端点。它不是用来首次部署 IA 解决方案的——这需要更广泛的范围的工作，可以通过不同的角色来完成。如果预计 ML 算法将定期作为维护或改进活动的一部分进行更新，则ML Deployer是相关的。这更有可能在内部开发算法时发生。ML 算法的更新通常独立于业务逻辑，作为 ML 模型自身生命周期的部分。将 IA 解决方案更新为使用新的 ML 模型最好是在不需要更改任何流程或对象图的情况下完成。

在这些场景下，有一个专门用于更新仅触及 ML 算法的 BP 区域的角色是有意义的——即环境变量、技能和Web API 服务。如果需要部署新算法是由于重大缺陷，ML Deployer 可能需要激活一个停止所有 ML 预测的凭证（开关）。默认情况下，BP 没有仅限于编辑这些 BP 区域的角色。在下面的示例中，我们将创建 ML Deployer 角色。

示例 2 – 创建 ML Deployer 用户角色

在本例中，我们将执行四个高级步骤：

1. 创建ML Deployer用户角色。

2. 给予它所需的最小权限集。

3. 使用ML Deployer用户角色创建用户。

4. 测试功能。

首先，让我们创建用户角色。

创建 ML Deployer 用户角色

我们的第一步是创建用户角色本身。

1. 访问系统 | 安全 | 用户角色。

2. 将角色名称设置为 ML Deployer。

将权限映射到 ML 部署器用户角色

接下来，我们需要选择 七个 权限以添加到我们新创建的用户角色中：

1. 在新创建的 ML 部署器 角色上单击一次，以确保它被突出显示。在右侧面板的 权限 部分中，勾选以下七个权限：技能 | 导入技能、技能 | 管理技能、技能 | 查看技能、系统管理员 | 进程 – 配置环境变量、系统管理员 | 业务对象 – Web API 服务、系统管理员 | 业务对象 – Web 连接设置 和 系统管理员 | 安全 – 管理凭据。

2. 在右下角单击 应用 按钮以保存更改。

创建具有 ML 部署器用户角色的新用户

在测试 ML 部署器 用户角色之前，创建一个新用户并将其分配给该角色：

1. 访问 系统 | 安全 | 用户。

2. 在用户面板上的任何位置右键单击，然后选择 创建用户 或 新建。无论 创建用户 或 新建 显示取决于您在哪里右键单击，但它们都会引导到相同的用户创建向导。

3. 输入用户名 mldeploy。选择一个密码，并两次输入。

4. 单击 下一步 直到您到达选择用户角色的屏幕。

5. 选择 ML 部署器 用户角色，然后单击 完成。

测试新用户

为了测试用户，我们需要注销，以新用户身份登录，并验证我们只能更改 环境变量、Web API 服务、技能 和 凭据：

1. 从 BP 中注销。

2. 使用 mldeploy 用户和您选择的密码登录。

3. 访问 BP 的 系统 部分。

4. 确认只有 进程 | 环境变量、对象 | Web API 服务、对象 | Web API 服务 | 连接设置、技能 | 管理 和 安全 | 凭据 可以被选中。其他所有选项都应该变灰，表示该角色只能编辑这五个区域。

图 8.1 – ML 部署器可以访问的区域

我们已经完成了 ML 部署器 用户角色的创建。请记住，这个角色是为 ML 人员或数据科学家准备的，以便在他们对生产或测试（例如，使用 示例 4 中介绍的 新模型评估流程模板）部署新的 ML 算法时更新 BP IA 解决方案。初始部署应由不同的角色执行，因为 ML 部署器 用户不需要太多的 BP 培训或权限来部署他们的新算法。

这意味着几乎与 ML 相关的所有内容都应该作为环境变量参数化，包括 URL、模型版本和 ML 脚本的路径。如果它们作为环境变量存储，我们就不需要向用户角色添加对象工作室权限，并且对 BP 的使用进行培训可以保持在最低限度。然而，如果使用了 VB.NET 或 C# ML 库，如 ML.NET，我们可能还想授予用户角色对象工作室和发布管理器权限，并提供足够的培训，以便他们可以自己编辑对象。

ML 审核员

我们的第三个用户角色是为那些审核预测的人准备的，尤其是如果他们是内部业务用户。他们需要修改会话变量以重新创建缺失的审核数据的权限，更改有关共享数据保存路径的环境变量，以及更新工作队列项的状态。这个角色与三个工作队列设计搭配使用时效果最佳，因为它允许我们通过 MTE 限制哪些流程可以访问。接下来，让我们创建ML 审核员角色。

示例 3 – 创建 ML 审核员用户角色

在本例中，我们将通过四个高级步骤进行操作：

1. 创建ML 审核员用户角色。

2. 给予它必要的最小权限。

3. 创建具有ML 审核员角色的用户。

4. 测试功能。

首先，让我们创建用户角色。

创建 ML 审核员用户角色

我们的第一步是创建用户角色本身：

1. 访问系统 | 安全 | 用户角色。

2. 将角色名称设置为ML 审核员。

将权限映射到 ML 审核员用户角色

接下来，我们需要选择四个权限添加到我们新创建的用户角色中：

1. 点击一次新创建的ML 审核员角色以确保它被突出显示。在右侧面板的权限部分，勾选以下四个权限：控制室 | 队列管理完全访问，流程工作室 | 查看流程定义，资源 | 控制资源，和系统管理器 | 流程 – 配置 环境变量。

2. 点击右下角的应用按钮以保存更改。

创建具有 ML 审核员用户角色的新用户

在测试我们新的用户角色之前，我们需要创建一个用户并将其分配给该角色：

1. 访问系统 | 安全 | 用户。

2. 在用户面板上的任何位置右键单击，然后选择创建用户或新建。创建用户或新建显示取决于你右键单击的位置，但它们都指向同一个用户创建向导。

3. 输入用户名mlreview。选择一个密码，并重复输入两次。

4. 点击下一步，直到到达选择用户角色的屏幕。

5. 选择ML 审核员用户角色，并按完成。

测试新用户

为了测试用户，我们需要注销，以新用户身份登录，并验证我们是否可以在系统设置下看到环境变量，查看工作队列，以及在控制室中查看会话：

1. 从 BP 注销。

2. 使用mlreview用户和您选择的密码登录。

3. 访问 BP 的控制部分。

4. 确认会话管理和队列管理可用。

图 8.2 – 会话管理和队列管理对 ML Reviewer 用户角色可用

1. 访问 BP 的系统部分。

2. 确认只能选择流程 | 环境变量。其他所有选项都应变为灰色。

如果您愿意，可以进一步验证 ML Reviewer 角色可以编辑单个队列项的状态，也可以编辑执行会话的会话变量。

我们已创建三个用户角色，可用于 BP 的 IA 目的。请记住，LAM 通常对不同环境有不同的权限。这里显示的示例是根据最小权限原则和生产环境设计的。如果需要，可以在较低环境中授予这三个用户角色额外的权限。

用户角色比较

下表总结了三个用户角色及其在生产环境中执行职责所需的最小权限集。标记为Y的表格单元格表示用户角色应该拥有该权限。空的表格单元格表示用户角色不需要该权限。表中未列出任何三个角色都不使用的权限。

权限	ML 审计员	ML 部署者	ML 审查员
控制室：
完全访问队列管理			Y
对象工作室：
查看业务对象定义	Y
流程工作室：
查看流程定义	Y		Y
资源：
控制资源			Y
查看资源	Y
技能：
导入技能		Y
管理技能		Y
查看技能		Y
系统管理员：
审计 – 业务对象日志	Y
审计 – 流程日志	Y
业务对象 – 网络 API 服务		Y
业务对象 – 网络连接设置		Y
流程 – 配置环境变量		Y	Y
安全 – 管理凭证		Y

表 8.1 – IA 用户角色及其权限表

ML Auditor角色需要权限来导出会话日志，而ML Reviewer需要权限来编辑会话变量以运行会话。在前面的示例中，我们创建的角色可以查看多个流程的会话和会话日志，这是一个安全问题。在下一节关于 MTE 的部分，我们将看到如何进一步限制ML Auditors和ML Reviewers可以查看哪些流程。然而，我们无法使用 MTE 来限制ML Reviewers可以编辑哪些工作队列的项目状态。编辑 Web API 服务、技能、环境变量和凭证的ML Deployers也不从 MTE 中受益。

MTEs

查看流程定义权限允许我们在 BP 的控制室部分看到流程。如果我们想查看会话日志或编辑会话变量，这是必需的。授予此权限允许用户角色查看控制室中发布的所有不受限制的流程。对于ML Auditor用户能够从所有流程中提取会话日志可能没问题，但我们不希望ML Reviewers能够为不属于他们负责的流程设置会话变量。MTE 允许我们设置限制，限制我们新创建的角色可以查看哪些流程和日志。

ML Auditor 和 ML Reviewer 用户角色的 MTE

如果我们想按流程限制可以查看的内容，我们需要创建多个 ML Auditor 和 ML Reviewer 用户角色。我们还需要将我们的流程放入特定的组结构中，以便我们可以设置正确的访问权限。让我们通过一个示例来演示如何实现这一点。

示例 4 – ML Auditor 和 ML Reviewer MTE

假设我们有两个在生产中运行的 IA 解决方案，A 和 B，每个都由三个流程，三个工作队列 IA 模板从第七章创建。有两个 ML 团队（A 和 B）希望能够仅导出使用他们 ML 算法的 IA 解决方案的会话日志。我们还有两个 ML 审查团队（X 和 Y），他们可能需要编辑他们负责的解决方案的会话变量。

我们试图实现的内容列在以下表中：

IA 解决方案	BP 流程	哪个 ML 团队可以导出 会话日志？	哪个审查团队能够编辑 会话变量？
A	01 – Business Logic A	无限制	N/A
A	02 – ML Prediction A	A	N/A
A	03 – HITL Review A	A	X
B	01 – Business Logic B	无限制	N/A
B	02 – ML Prediction B	B	N/A
B	03 – HITL Review B	B	Y

表 8.2 – 示例 4 所需的 MTE 限制

让我们实施一个 MTE 结构，以实现前表中所示的内容。在这个示例中，我们将通过八个高级步骤进行：

1. 检查示例的发布文件内容。

2. 将ML Auditor角色克隆两次，一次为每个团队。

3. 为两个克隆的ML Auditor角色创建用户。

4. 将ML Reviewer角色克隆两次，一次为每个团队。

5. 为两个克隆的ML 审查员角色创建用户。

6. 更改组的访问权限。

7. 运行每个流程一次。

8. 验证 MTE 是否按预期工作。

首先，让我们熟悉一下基于团队组结构的发布。

验证发布内容

已准备了一个结构化的发布，以便配置访问权限。访问权限将按流程限制对会话日志和会话变量的访问。验证发布是否包含六个 BP 流程在组结构中，如下所示图像所示。

图 8.3 – MTE 的组结构

属于 IA 解决方案 A 的三个流程具有A后缀。同样，属于 IA 解决方案 B 的三个流程具有B后缀。可由 ML 团队 A 查看的组包含执行 IA 解决方案 A 的 ML 预测的流程。可由 ML 团队 A 和审查团队 X 查看的组包含执行 IA 解决方案 A 的 HITL 审查检查的流程。

可由 ML 团队 B 查看的组包含执行 IA 解决方案 B 的 ML 预测的流程。可由 ML 团队 B 和审查团队 Y 查看的组包含执行 IA 解决方案 B 的 HITL 审查检查的流程。

还有两个流程，01-业务逻辑 A和01 - 业务逻辑 B，它们都不在前面提到的两个组中。这些流程将对所有角色可见。我们的下一步是将ML 审计员用户角色克隆成两个新的角色。

两次克隆 ML 审计员用户角色

为了授予两个组分别的访问权限，可由 ML 团队 A 查看和可由 ML 团队 B 查看，我们需要有两个单独的用户角色。在这里，我们将克隆在示例 1中创建的现有 ML 审计员角色，并将其重命名两次：

1. 访问系统 | 安全 | 用户角色。

2. 右键单击ML 审计员角色，然后选择克隆。

图 8.4 – 克隆现有的 ML 审计员角色

1. 将克隆的角色重命名为ML 审计员 A。

2. 右键单击ML 审计员角色并克隆（即重复步骤 2）。

3. 将克隆的角色重命名为ML 审计员 B。

现在我们应该有三个 ML 审计员角色 – 基础的ML 审计员角色（在这个例子中将不再使用），ML 审计员 A和ML 审计员 B。接下来，让我们为每个新的用户角色创建一个用户。

创建两个 ML 审计员用户。

为了测试我们的用户角色，我们需要创建具有这些角色的新用户。

1. 访问系统 | 安全 | 用户。

2. 在用户面板上的任何位置右键单击，然后选择创建用户或新建。

3. 输入用户名mlauditA。选择一个密码，并输入两次。

4. 点击下一步，直到到达选择用户角色的屏幕。

5. 选择ML 审计员 A用户角色，然后点击完成。

6. 在用户面板上的任何位置右键单击，然后选择创建用户或新建。

7. 输入用户名 mlauditB。选择一个密码，并重复输入两次。

8. 点击 下一步，直到到达选择用户角色的屏幕。

9. 选择 ML Auditor B 用户角色，并点击 完成。

在创建 ML Auditor 用户后，我们将重复相同的步骤，除了 ML Reviewer 角色。

两次克隆 ML Reviewer 用户角色

让我们复制在示例 3 中创建的 ML Reviewer 角色两次：

1. 访问 系统 | 安全 | 用户角色。

2. 右键点击 ML Reviewer 角色，并选择 克隆。

3. 将复制的角色重命名为 ML Reviewer X。

4. 右键点击 ML Reviewer 角色，并 克隆（即重复 步骤 2）。

5. 将复制的角色重命名为 ML Reviewer Y。

现在，我们应该有三个 ML Reviewer 角色 – 基础 ML Reviewer 角色（在此示例中不再使用），ML Reviewer X 和 ML Reviewer Y。接下来，让我们为每个新的用户角色创建一个用户。

创建两个 ML Reviewer 用户

为了测试我们的用户角色，我们需要创建具有这些角色的新用户：

1. 访问 系统 | 安全 | 用户。

2. 在 用户 面板上右键点击任何位置，并选择 创建用户 或 新建。

3. 输入用户名 mlreviewX。选择一个密码，并重复输入两次。

4. 点击 下一步，直到到达选择用户角色的屏幕。

5. 选择 ML Reviewer X 用户角色，并点击 完成。

6. 在 用户 面板上右键点击任何位置，并选择 创建用户 或 新建。

7. 输入用户名 mlreviewY。选择一个密码，并重复输入两次。

8. 点击 下一步，直到到达选择用户角色的屏幕。

9. 选择 ML Reviewer Y 用户角色，并点击 完成。

到目前为止，我们已经创建了四个新角色和四个用户。接下来，让我们修改组的访问权限，以限制每个新角色的可查看内容。

修改组访问权限

在此步骤中，我们将为每个组设置特定的 访问权限。首先，我们将限制 Viewable by ML team A 组，使其只能由 ML Auditor A 用户角色查看。然后我们将限制 Viewable by ML team B 组，使其只能由 ML Auditor B 用户角色查看。

接下来，我们将限制 Viewable by ML team A and Review team X 组，使其只能由 ML Auditor A 和 ML Reviewer X 角色查看。最后，我们将限制 Viewable by ML team B and Review team Y 组，使其只能由 ML Auditor B 和 ML Reviewer Y 角色查看：

1. 访问 BP 的 工作室 部分。

2. 右键点击 Viewable by ML team A 组，并选择 访问权限。

图 8.5 – 右键点击 Viewable by ML team A 组并选择访问权限

1. 点击 受限 单选按钮。

2. 点击 取消选择 所有 按钮。

3. 点击 ML Auditor A 角色。

4. 打开 选择/取消选择 所有 复选框。

图 8.6 – 为 ML 审计员 A 角色勾选/取消勾选全部框

1. 点击确定以保存更改。此时，可由 ML 团队 A 查看组应仅由ML 审计员 A 角色查看。

2. 右键单击可由 ML 团队 B 查看组，并选择访问权限。

3. 点击受限单选按钮。

4. 点击取消选择 全部按钮。

5. 点击ML 审计员 B 角色按钮。

6. 勾选选择/取消选择 全部框。

7. 点击确定以保存更改。此时，可由 ML 团队 B 查看组应仅由ML 审计员 B 角色查看。

8. 右键单击可由 ML 团队 A 和审查团队 X 查看组，并选择访问权限。

9. 点击受限单选按钮。

10. 点击取消选择 全部按钮。

11. 点击ML 审计员 A 角色按钮。

12. 勾选选择/取消选择 全部框。

13. 点击ML 审查员 X 角色按钮。

14. 勾选选择/取消选择 全部框。

15. 点击确定以保存更改。此时，可由 ML 团队 A 和审查团队 X 查看组应仅由ML 审计员 A和ML 审查员 X 角色查看。

16. 右键单击可由 ML 团队 B 和审查团队 Y 查看组，并选择访问权限。

17. 点击受限单选按钮。

18. 点击取消选择 全部按钮。

19. 点击ML 审计员 B 角色按钮。

20. 勾选选择/取消选择 全部框。

21. 点击ML 审查员 Y 角色按钮。

22. 勾选选择/取消选择 全部框。

23. 点击确定以保存更改。此时，可由 ML 团队 B 和审查团队 Y 查看组应仅由ML 审计员 B 和ML 审查员 Y 角色查看。

我们已经完成了四个组的访问权限更改。现在，让我们在控制室中一次性运行所有六个流程以生成会话日志。

一次性运行每个流程

在我们测试用户之前，我们需要在控制室中一次性运行六个流程中的每一个。访问 BP 的控制部分，并从会话管理部分一次性运行每个流程。只要创建了会话日志，会话运行成功或失败并不重要。

图 8.7 – 在控制室中一次性运行每个流程

验证 MTE 是否正在运行

最后，让我们从 BP 注销，并使用我们新创建的用户重新登录。然后，我们将验证 MTE 是否正在限制访问，正如我们所期望的：

1. 从 BP 注销。

2. 使用mlauditA用户名和密码登录。

3. 访问 BP 的系统 | 审计 | 流程日志部分。

4. 确保您看不到02 – ML 预测 B和03 – HITL 审查 B的会话日志。

图 8.8 – ML 审计员 A 角色不应看到 ML 预测 B 和 HITL 审查 B

1. 从 BP 注销。

2. 使用mlauditB用户名和密码登录。

3. 访问 BP 的系统 | 审计 | 流程日志部分。

4. 确保您看不到02 – ML 预测 A和03 – HITL 审查 A的会话日志。

图 8.9 – ML 审计员 B 角色不应看到 ML 预测 A 和 HITL 审查 A

1. 从 BP 注销。

2. 使用mlreviewX用户名和密码登录。

3. 访问控制 | 会话管理。

4. 确认在Ch8 | 示例 4 – ML 审计员和 ML 审查员 MTE | 可由 ML 团队 A 和审查团队 X 组查看以及无限制的父组中的两个流程中，仅可见03 – HITL 审查 A。

图 8.10 – ML 审查员 X 角色仅应看到 HITL 审查 A

1. 从 BP 注销。

2. 使用mlreviewY用户名和密码登录。

3. 访问控制 | 会话管理。

4. 确认在Ch8 | 示例 4 – ML 审计员和 ML 审查员 MTE | 可由 ML 团队 B 和审查团队 Y 组查看以及无限制的父组中的两个流程中，仅可见03 – HITL 审查 B。

图 8.11 – ML 审查员 Y 角色仅应看到 HITL 审查 B

我们已经完成了示例，展示了如何使用MTE和组访问限制与ML 审计员和ML 审查员用户角色。我们看到了如何选择性地选择哪些流程会话和会话日志可供不同用户角色查看/导出。

此示例还突出了三个流程/三个工作队列设计的好处。通过将业务逻辑、ML 调用和 HITL 审查分离到不同的流程中，我们实现了更干净的 MTE 用户访问控制，从而增强了操作 IA 解决方案的整体安全性。

MTE 限制

MTE 仅限制对流程、对象和资源的可见性。计划、工作队列、技能、凭证和环境变量不能通过 MTE 进行限制。这意味着 MTE 对ML 部署员角色无效。ML 审查员和ML 部署员角色都需要与环境变量交互，因此必须指示他们避免更改与其工作无关的环境变量。BP 中没有内置的方法来限制对这些内容的访问，因此我们必须依赖于文档化的操作程序和培训。

如果你想防止意外更改环境变量、凭证等，你需要想出一个外部解决方案，例如将那些数据保存在一个存储在具有单独访问控制位置的工作表中。

更新的 LAM 模板

三个新的 IA 用户角色、它们的权限和 MTE 推荐已添加到 BP 的 LAM 模板中。此修订后的模板可在 GitHub 上找到：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch8/Blue_Prism_Logical_Access_Model_(LAM)_for_v7_IA.xlsx。

建议为开发、UAT 和生产环境设置ML 部署员角色。ML 审查员角色应仅存在于 UAT 和生产环境中，因为在开发期间审查 ML 预测可能没有意义。ML 审计员角色仅需要在生产环境中存在。

摘要

在本章中，我们探讨了三个可以添加到 BP 环境中以处理 IA 相关任务的全新用户角色 – ML 审计员、ML 部署员和ML 审查员。我们讨论了他们在 BP 内部应执行的任务，并提供了完成工作所需的最低权限集。

我们还看到，仅将用户角色映射到权限对于 ML 审计员和 ML 审查员角色是不够的。我们需要使用 MTE 来限制他们可以访问的流程，以减少安全担忧。最后，我们使用这三个新用户角色更新了 LAM 模板。此模板包括有关每个角色应在哪个环境中存在、每个角色应具有哪些权限以及如何配置 MTE 的建议。在下一章中，我们将探讨从 RPA 过渡到 IA 如何影响 BP 的技术操作，例如部署和维护。

第九章：ML 部署和数据库操作

RPA持续维护的最大来源是处理业务逻辑（流程）和应用程序（对象）的变化。随着 IA 的应用，另一个持续变化的来源被加入其中——更新 BP 以使用新的 ML 模型。想象一下，模型每年只更新一次，而我们有五个模型。这意味着我们每年仍需要五次修改我们的 IA 解决方案的配置，以适应 ML 模型的更新。

即使更新的 ML 模型保持了与之前完全相同的 API 端点定义，我们仍然需要了解正在使用哪种 ML 部署策略，因为这会影响我们计划回滚的方式，以防模型的表现不符合预期。

我们在第8 章中讨论了ML 部署者用户角色。这个用户角色负责定期更新生产中的 ML 模型。在本章中，我们将讨论最常用的 ML 部署策略，它们如何影响 BP 中更新模型所需发生的事情，以及回滚计划。

IA 改变我们操作方式的另一种方式在于数据库维护和 ML 数据提取。第八章也讨论了ML 审计员用户角色，该角色可以在登录 BP 软件后导出会话日志数据。如果我们不想在 BP 中为这个角色分配职责，我们可以定期直接从数据库中提取这些数据。

在本章中，我们将讨论与 IA 相关的特定操作主题：

• ML 部署和回滚

• 数据库维护和数据导出

ML 部署和回滚

ML 通常由 IA 组织之外的团队开发和部署。一旦新的模型可用，IA 团队需要更新 BP 和 ML 模型之间的连接点，以便自动化可以利用它。根据所使用的 ML 部署策略，从 BP 安全更新这些连接点的步骤会有所不同。在本节中，我们将描述最常用的 ML 部署策略。我们还将讨论在特定策略下，如何更改 IA 解决方案的配置以利用新的 ML 模型。

ML 部署策略还影响我们如何从新模型回滚到旧模型。ML 模型的问题通常不会导致容易检测到的会话终止失败。即使有缺陷，模型仍然会继续产生预测。如果发现模型有问题，我们需要准备好回滚到旧模型，以便自动化案例可以继续运行。当然，如果我们使用第三方开发的模型，回滚可能不是一个选项。

回想一下，ML 算法可以从 BP 触发的方式，这些方式在第 1、2 和 3 章中讨论过：Web APIs、CLI 脚本和代码阶段。在接下来的部分中，我们将看到每种部署策略的不同之处以及我们的 IA 解决方案应如何配置以保持可审计性。我们还将讨论安全地将 ML 模型回滚到其先前版本所需的步骤。

Web API 部署策略

部署 ML Web API 的常见方法包括替换、滚动、蓝绿、金丝雀和影子部署。我将解释这些方法背后的基本概念以及 IA 团队应如何操作以在生产中使用新模型。对于这些策略中的许多，我们还需要考虑 ML 团队是否通过重用相同的 API 端点来覆盖先前的模型，或者除了先前的端点外还提供新端点。新端点允许我们快速切换回旧模型。

替换部署

这是需要计划停机的最简单 Web API 部署策略。旧 ML 模型完全离线，新模型被放置到位。需要与 ML 团队协调，以确保在切换期间没有会话正在运行。

API 端点被覆盖

如果在部署新模型后重新使用 API 端点，这意味着 URL 完全保持不变。我们需要使用模型版本环境变量（存在于所有流程模板中，见第七章）来跟踪模型实际更新的时间：

图 9.1 – 当模型更新时，应更改模型版本环境变量

更新 BP 解决方案所需的步骤顺序如图所示。在部署新 ML 模型之前，我们必须确保使用该模型的会话已停止运行，因为需要停机时间。新模型上线后，我们更改模型版本并重新启动会话：

图 9.2 – 当现有端点被覆盖时的替换部署

如果需要回滚，ML 团队将需要停机以撤销其部署。以下图像显示了示例回滚程序。您可能不想等待正在进行的会话结束，而是请求一个模型版本：

图 9.3 – 当端点被覆盖时回滚替换部署

由于这种替换部署策略需要停机时间，因此更适合 IA 流程，其中工作队列的容量较低且 ML 模型更改不频繁。

新的 API 端点已创建

如果有新的 API 端点，更新 IA 解决方案以使用新端点几乎与 图 9.2* 中的步骤相同。唯一的区别在于更新 Web API 服务配置以使用新的 API URL，以及 模型版本 环境变量。回想一下，在 Web API 服务中更改 URL 的详细信息实际上并没有被保存到审计日志中，这样你就可以检索 URL 的值。如果我们使用的是对象而不是 Web API 服务，我们需要更改存储端点 URL 的环境变量：

图 9.4 – 创建新端点时的替换部署

在这种情况下回滚很容易，因为之前的 API 仍然可用。我们只需要更改 Web API 服务 URL（或对象环境变量 URL），以及 模型版本 回到之前的状态。如果你想更加安全，你可以退役计划，等待所有会话完成后再进行这些更改：

图 9.5 – 创建新端点时回滚替换部署

替换 策略可能是最简单的部署类型。本章中讨论的其余策略更为复杂，且不需要停机。由于没有停机时间，因此不需要退役/恢复计划或确保使用 ML 模型的会话没有运行。当然，在停机期间进行解决方案部署和更改仍然更安全。接下来将讨论 滚动更新 策略。

滚动更新

当有多个服务器在负载均衡器后面托管 API 时，可以执行滚动部署。可以在 图 9.6* 中看到简单滚动部署的图像。我们开始时所有 API 服务器都连接到负载均衡器，运行 API 的 版本 1（A）。服务器 1 被从负载均衡器中移除（B），并更新为服务 API 的 V2（C）。更新后，服务器 1 重新连接到负载均衡器（D），这意味着两个模型版本（V1 在 服务器 1 上和 V2 在 服务器 2 上）正在同时提供服务。接下来，我们移除 服务器 2 从负载均衡器（E），更新它到 V2（F），并将其重新连接到负载均衡器（G）。我们重复这些步骤，直到所有服务器都更新。

注意，ML API 服务没有停机时间，但也有时间（D）可以针对旧模型和新模型进行预测，这会复杂化审计。有可能在旧模型和新模型都可能被服务的时间段内，我们不知道使用了哪个模型进行预测。

图 9.6 – 滚动更新部署示例

再次强调，我们必须考虑这种类型部署的两种情况。第一种是现有 API 端点被覆盖，第二种是新 API 端点被创建。

API 端点被覆盖

如果 API 端点被重用，当服务器后面的负载均衡器正在更新时，我们可能不知道正在提供哪个版本的 API。我们唯一知道的方式是如果模型版本作为 API 响应的一部分返回，但这并不保证。出于审计原因，在滚动更新开始之前暂停调用 ML 端点，并在我们知道所有服务器都已更新后恢复，是最安全的。然而，我们可能不知道 ML 团队何时开始滚动更新，特别是如果他们是第三方开发者。

在这种情况下，一旦我们收到部署 100%完成的通知，最简单的方法就是更新模型版本环境变量。如果您需要确切知道在部署时间段内使用了哪个 ML 模型，您需要要求模型开发者检查他们的服务器日志：

图 9.7 – 当现有端点被覆盖时的滚动部署

回滚基本上与部署新模型的程序相同。回滚被启动，我们等待收到完成的通知。一旦完成，我们可以更新模型版本环境变量。

图 9.8 – 当端点被覆盖时回滚滚动部署

新 API 端点被创建

如果引入了新的 API 端点，我们需要更新两件事。第一是模型版本环境变量。第二取决于我们是否使用Web API 服务或对象来调用 API。根据我们使用的是哪一个，我们要么更改 Web API 服务配置以使用新的 API URL，要么更改存储 API URL 的对象环境变量/数据项：

图 9.9 – 创建新端点时进行滚动部署

将 API 回滚到先前版本很简单，因为先前的 API 端点仍然存在。我们撤销对模型版本环境变量和 Web API 服务配置 URL（或对象环境变量/数据项）的更改。

图 9.10 – 创建新端点时回滚滚动部署

滚动部署的一个主要缺点是不知道在部署阶段做出的预测使用了哪个 ML 模型。我们将讨论的下一种策略，称为蓝绿部署，没有这种歧义，也没有停机时间。

蓝绿部署

在蓝绿色部署中，负载均衡器后面有重复的基础设施，但在任何给定时间只有一组基础设施正在积极处理请求。一个示例蓝绿色部署可以在 图 9**.11 中看到。假设我们目前在 绿色 服务器集上运行 版本 1 的模型 (A)。当模型需要更新到 版本 2 时，它被部署到一组单独的蓝色服务器上，这些服务器通常不处理请求 (B)。一旦模型版本 2 准备好使用，负载均衡器被更改以仅向蓝色服务器发送请求 (C)。带有先前模型的绿色服务器处于闲置状态：

图 9.11 – 蓝绿色部署示例

与滚动更新类似，蓝绿色部署不应有服务中断。与蓝绿色和滚动更新的主要区别是，始终有一个先前模型的副本处于待命状态，可以通过重新配置负载均衡器切换回。也不会存在多个模型同时提供预测的模糊期。这两个点使得蓝绿色部署比滚动更新更适合 IA 审计。

API 端点被覆盖

如果 URL 端点被重复使用，我们需要等待通知表明部署已完成，并更改 模型版本 环境变量。

图 9.12 – 覆盖现有端点时的蓝绿色部署

回滚需要机器学习/基础设施团队更改其负载均衡器的配置。一旦完成，IA 团队可以将 模型版本 环境变量改回其先前值。当端点被覆盖时回滚蓝绿色部署的速度应该比回滚滚动更新快得多：

图 9.13 – 当端点被覆盖时回滚蓝绿色部署

新 API 端点已创建

当我们有新的 API 端点时，我们需要更新 模型版本 环境变量，然后是对象环境变量/数据项 API URL 或 Web API 服务配置 URL：

图 9.14 – 创建新端点时的蓝绿色部署

由于当前的服务器集合，无论是蓝色还是绿色，都包含机器学习模型的最新和之前版本，因此回滚实际上不需要重新配置负载均衡器。我们只需将环境变量/数据项或 Web API 服务 URL 回滚到之前的状态：

图 9.15 – 在创建新端点时回滚蓝绿部署

对于我们迄今为止讨论的三个部署策略（替换、滚动、蓝绿），新 ML 模型的 API URL 可以重用（保持不变）或更改。如果新模型有不同的 URL，我们需要在新 ML 模型被调用之前主动更改 IA 解决方案的配置。这与我们将要看到的下两种部署方法形成对比，其中新模型的 URL 将始终保持不变。如果保留模型的前版本，那些将获得新的 URL。

金丝雀部署

在金丝雀部署下，新模型和旧模型在 ML 超关注期间并行提供服务（图 9**.16，B）。最初，只有一小部分请求被路由到新模型；例如，95%的请求将流向旧模型，5%的流量流向新模型（C）。随着对新模型性能的信心增加，到达新 ML 模型的请求百分比逐渐增加（D）。这最终达到 100%（E），托管旧模型的服务器被关闭（F）：

图 9.16 – 一个示例金丝雀部署

IA 团队可能无法看到也无法控制哪些请求会被选择运行在新模型上。这意味着除非 API 响应中提供了该信息，否则我们真的无法确定在切换期间哪些会话将在旧模型和新模型上运行。如果我们需要确定用于审计目的的 ML API 版本，我们需要直接访问 ML 服务的日志，并将它们与会话日志的时间戳进行交叉引用，如果模型是第三方开发的，这可能是不可能的。

金丝雀部署意味着在模型更新时，有一个单一的 URL 端点保持不变。因此，一旦我们收到通知，表示所有流量都被导向新模型，我们只需要更新模型版本环境变量一次。类似于滚动更新，我们不会确切知道在部署期间使用了哪个模型进行预测。

图 9.17 – 金丝雀部署

在金丝雀部署中，完全回滚是罕见的，因为其目的是在部署期间捕捉问题。通常发生的情况是，在部署期间，针对新模型的流量成功标准未达到，一切都会立即回滚。这种回滚不需要对 BP 进行任何更改，因为它发生在我们尚未对 IA 解决方案进行任何配置更改之前。

然而，如果在完整部署之后需要回滚，我们只需要将模型版本的值改回之前的状态，因为 API URL 保持不变。

图 9.18 – 回滚金丝雀部署

金丝雀部署（类似于滚动更新）在部署期间实际用于生产的模型方面会产生歧义。因此，最好避免它们（如果可能的话）或在 API 响应中始终返回模型版本。相反，我们可以考虑使用影子部署（下文将讨论），它也并行运行两个模型。影子部署与金丝雀部署不同，因为旧模型和新模型之间存在明确的切换点。

影子部署

使用影子部署时，对旧模型和新模型同时针对实时数据进行调用。然而，在幕后调用的是新模型，并且其 API 响应不会发送回调用者（图 9.19，A）。影子预测结果直接从服务器日志中检索，由机器学习团队进行分析。一旦机器学习团队对新模型满意，它将被完全切换（B），并且旧模型将被移除（C）：

图 9.19 – 一个示例影子部署

影子部署通常是通过将负载均衡器中的流量镜像到托管新机器学习模型的服务器来实现的。请注意，这与在第六章中介绍的“评估新模型的流程模板”部分在概念上相似。影子部署与模板版本之间的区别在于模板版本明确地按顺序调用两次预测。负载均衡器实现只需要一个 API 请求，并且并行调用。

由于在将新模型用于生产时有一个干净的切换点，影子部署比金丝雀部署更适合 IA。

由于影子部署的实时验证性质，端点 URL 保持不变是隐含的。因此，在部署完成后，我们只需要在 BP 中将模型版本更改一次：

图 9.20 – 影子部署

回滚影子部署需要将模型版本的更改撤销：

图 9.21 – 回滚影子部署

这就结束了基于 Web API 的部署讨论。让我们总结一下我们看到的五种策略。

Web API 部署摘要

如果我们可以影响 ML 模型的部署方式，首选的方法是蓝绿和影子。这是因为从上一个 ML 模型到新模型有一个清晰的截止点，这使得在会话期间使用的模型非常明确。在这两种方法之间，蓝绿可能具有更快的回滚速度，因为上一个 ML 模型版本正在待命。您可以将蓝绿部署与流程模板结合使用，以评估新模型，产生类似于影子部署的效果。使用模板将在实际模型之后立即调用建议的 ML 模型，为 ML 团队的分析生成日志。

对于金丝雀和滚动更新的部署期间，关于实际调用的是哪个模型会有模糊性。要找出部署期间实际提供的是哪个 ML 模型，我们需要从托管模型的服务器请求日志，或者让 API 响应指示正在使用哪个 ML 模型版本。

提到的四种部署方法不需要停机时间。如果我们允许停机时间，采用替换部署策略是合理的，因为退役计划并确保没有会话处于活动状态是执行任何 BP 解决方案更改的最安全方式。我们当然也可以决定将停机时间与任何其他部署策略相结合。

如果 ML 模型是第三方开发或托管服务，我们几乎不可能影响部署策略。也不太可能知道部署何时发生。我们基本上需要关注 API 文档，以了解何时发生变化，或者希望 API 调用返回模型版本。

从 API 部署过渡到脚本部署，脚本部署包括批处理文件、PowerShell 脚本和 Python 脚本，这些脚本通过命令行直接在数字工作者上执行。

脚本部署策略

对于基于脚本的 ML 部署，主要有两种策略。第一种是将脚本及其依赖项直接安装在每个数字工作者的 Windows 系统上。第二种是将脚本及其依赖项虚拟化。无论选择哪种策略，都要对脚本进行版本控制，这有助于记录依赖项并简化回滚。

直接部署

对于直接部署，我们需要考虑脚本的位置并安装运行它们所需的依赖项。脚本可以位于可执行的网络位置，或者保存在每个数字工作者本地。

部署的难度在于正确配置 Windows 系统，以确保更新的模型所需的依赖项被正确设置。这很可能需要 IT 通过命令行手动安装包。如果需要在许多数字工作者之间重复，这可能会很耗时。

从纯 BP 视角来看，ML 脚本的更新不应导致许多变化，除了修改脚本可执行文件的路径、其参数和 Model Version 环境变量。不幸的是，这些更改需要 停机时间，因为流程、对象和环境变量的更新存储在 BP 数据库中。对这些更改的修改只能在所有 VM 的部署完成后进行一次。

图 9.22 – 直接部署

在直接部署中为回滚做准备的最简单方法是，在部署新的 ML 模型之前对数字工作者 VM 进行快照。如果我们发现部署后的 ML 模型存在问题，我们可以通过回滚到先前的图像来解决问题。请注意，将数字工作者 VM 回滚到其先前状态仍然需要撤销对 BP 解决方案的更改，例如更改 Model Version 环境变量、脚本可执行文件的路径、其参数等。这些更改保存在 BP 数据库中，而不是单个 VM 中。

图 9.23 – 通过图像备份回滚直接部署

如果无法创建图像备份，您将需要手动回滚。手动回滚容易出错，因为降级依赖项很少可能。这很可能需要从头开始卸载和重新安装软件包。在许多数字工作者上这样做将会非常繁琐。

虚拟化部署

另一种使回滚变得简单的部署选项是在数字工作者内部使用 虚拟化。您可以在本地容器（如 Docker）中部署脚本，VM 图像，Windows Subsystem for Linux 等。虚拟化部署将附带特定版本 ML 模型的所有必要依赖项。

再次强调，对 BP 流程、对象和环境变量的更改将应用于所有会话，因此不可能仅对少数数字工作者（除了克隆整个 BP 发布版本并重命名所有内容之外）部分部署 ML 解决方案。因此，部署虚拟化 ML 解决方案需要停机时间，并需要 IT 的帮助以确保正确启动图像：

图 9.24 – 虚拟化部署

要回滚虚拟化脚本部署，请恢复到图像的先前版本。再次强调，我们仍然需要撤销对 IA 解决方案所做的更改，因为这些更改已保存在 BP 数据库中：

图 9.25 – 回滚虚拟化部署

与直接部署相比，虚拟化部署在数字工作者上对资源的需求（CPU 和 RAM）更大。然而，回滚本地运行的虚拟机可能执行得更快，因为涉及的团队更少。两种方法都有利弊。

我们已经完成了关于如何部署和回滚基于脚本的机器学习模型的讨论。接下来，让我们讨论代码阶段部署。

代码阶段部署策略

代码阶段机器学习部署对 RPA 团队来说很熟悉，因为它们可以作为标准的对象 XML 或.bprelease导入完成。有些人可能还需要将.dll文件复制到对象中指定的位置，到系统路径上的一个文件夹，或者到 BP 安装文件夹。与导入任何其他非机器学习代码阶段相比，唯一的额外步骤是更改模型版本环境变量。如果我们需要复制新的.dll文件，则需要重启运行时资源以被识别，这将需要停机时间：

图 9.26 – 代码阶段部署

回滚代码阶段部署很简单。重新导入对象或发布的先前版本，复制回正确的.dll文件，删除任何新添加的.dll文件，并将模型版本环境变量值恢复到先前版本。保留先前模型所需的.dll文件的副本对于回滚目的很重要。

图 9.27 – 回滚代码阶段部署

这完成了关于 Web API、CLI 脚本和代码阶段部署策略的章节。了解正在使用的特定部署策略对于部署新的机器学习模型非常重要，因为这会影响我们在 IA 解决方案中实施更改的方式，以及我们如何回滚到模型的先前版本。接下来，让我们探讨 IA 如何改变 BP 的数据库管理需求，以及我们如何使用 SQL 提取机器学习日志，而不是通过 BP 软件通过 ML 审计员角色进行。

数据库操作

BP 的数据库主要用于操作，并不打算作为记录的永久数据存储。随着数据库表大小的增长，数据库开始运行得更慢，这降低了数字工作者的执行速度。将 IA 步骤添加到流程中会导致额外的日志记录，这增加了某些表的增长速度。持续的数据库维护一直是确保 BP RPA 平稳运行的关键因素，而进行 IA 后，数据库维护的需求只会加剧。

表增长维护

受 IA 影响最大的表是BPAWorkQueueItem和BPASessionLog_*。BPAWorkQueueItem存储工作队列项的数据。

重要提示

BPASessionLog_* 表示各种会话日志表，包括 BPASessionLog_NonUnicode、BPASessionLog_NonUnicode_pre65、BPASessionLog_Unicode 和 BPASessionLog_Unicode_pre65。

BPAWorkQueueItem

我们很可能会在“工作队列项”数据中存储用于机器学习算法的所有输入数据。如果机器学习算法有多个输入数据列，BPAWorkQueueItem的大小会迅速增长。管理此表增长率的四种主要方法如下。第一种是直接从 BP 用户界面删除工作队列项。这不推荐，因为 UI 在选择和删除工作队列项时有限制。

第二种方法是使用 BP 客户支持提供的数据库脚本。此 SQL 脚本会在超过特定日期的行从工作队列相关表中删除。例如，您可以配置脚本以保留 30 天的“工作队列项”，并通过 SQL Server Agent 每天运行脚本。这确保了您的“工作队列项”表不会超过 30 天的数据。

第三种方法是使用Blue Prism Archiver XBP资产，该资产可在 DX 上找到，网址为digitalexchange.blueprism.com/dx/entry/3439/solution/blue-prism-archiver-xbp。此资产允许您将工作队列项从主 BP 数据库移动到不同的数据库。更多详细信息可以在 DX 页面文档中找到。

最后，还有一个 DX 资产，名为BPAWorkQueueItem以及各种BPASessionLog_*表，将在下文中讨论。

BPASessionLog*

IA 通过增加执行并记录到数据库的流程和对象阶段数量，简单地增加了各种会话日志表的增长率。如前一段所述，管理此表增长的一种方法是从 DX 使用DB Servicer XBP。

BPASessionLog_*表也可以通过客户支持提供的 SQL 脚本来管理。该脚本允许我们指定我们想要保留多少天的会话日志。任何超过指定天数的日志都将从数据库中删除。一旦设置好，SQL 脚本需要定期运行。

保持会话日志表大小在可控范围内的第三种选项是使用产品内存档功能。这可以在.gz格式下找到。我们必须指定我们想要进行存档的运行时资源（在其空闲时间），在运行时资源上我们想要保存存档文件的位置，以及我们想要在 BP 数据库中保留多少天的日志。

图 9.28 – 产品内存档器，可以减缓会话日志的增长速度

最后一种选项是通过 BP 用户界面手动删除会话。对于大多数公司来说，这是不现实的，因为可能定期运行数千个（如果不是更多）会话。

IA 要求我们改进我们的 BP 数据库维护实践。IA 还导致数据导出方面的新要求。例如，ML 审计员想知道哪些输入导致了哪些预测以及这些预测是如何被使用的。数据科学家想知道手动验证结果，以便他们可以更新算法。如果我们的 ML 模型是第三方开发或托管，获取这些日志的唯一方法是通过 BP 数据库，因为我们无法访问底层的 ML 服务器日志。

虽然可以通过 BP 用户界面导出这些数据，但可能更倾向于自动化并直接从数据库导出这些数据。

重要提示

数据导出应在非工作时间进行，最好是在数据库的只读版本上，以最小化对 BP 生产操作的影响。

从数据库中提取机器学习预测数据

根据在第七章中展示的模板，我们的机器学习预测数据可能从两个数据库位置提取。第一个是从工作队列表，如果我们使用将机器学习预测分离到其自己的工作队列的模板，则此方法有效。如果我们不使用具有专用工作队列的模板，我们可以查询会话日志表以找到这些数据。

查询工作队列数据

如果你使用的是具有专用工作队列的 ML 模板，通过 SQL 查询工作队列数据是直接的。以下 SQL 脚本允许你为数据科学家提供算法的输入数据、预测结果和置信度分数。唯一需要更改的是工作队列的名称，你还可以添加日期以限制返回结果的范围：

SELECT data FROM BPAWorkQueueItem wqi, BPAWorkQueue wq
WHERE wq.name = 'ML Queue Name (To Change)'
AND wqi.queueid = wq.id;

所选的data列是一个 XML 字符串。这种 XML 格式可以直接由 Excel 打开或由数据科学家使用他们选择的编程语言进行解析。

查询会话日志数据

在所有的 IA 模板中，我们故意在一些阶段启用了日志记录，以便在会话日志查看器和数据库中更容易提取预测数据。以下图中显示的启用了日志记录的两个阶段在三个 IA 模板中名称相同。这种常见的命名方案是我们 SQL 运行所必需的：

图 9.29 – 记录机器学习预测结果的常见阶段

我们可以通过传递进程的名称来查询会话日志，以特别找到这两个阶段。根据 BP 的配置，你可能还需要将数据库表名从BPASessionLog_NonUnicode更改为BPASessionLog_Unicode。

SELECT * FROM
(SELECT logid, stagename, LAG(result, 1, 0) OVER(ORDER BY logid) as modelversion, attributexml, startdatetime from BPASessionLog_NonUnicode WHERE stagename in ('Log [Model Version]', 'Set [Prediction] and [Confidence Score]') AND processname = 'To Change') as tbl
WHERE stagename = 'Set [Prediction] and [Confidence Score]';

modelversion列填充了来自Log [模型版本]计算阶段的模型版本。attributexml列包含来自Set [预测]和[置信度分数]多计算阶段记录的值。

LAG(result, 1, 0) OVER(ORDER BY logid) SQL 语法允许我们从 Log [模型版本] 和 Set [预测] 和 [置信度分数] 的单行中选择值，即使它们属于不同的会话日志条目。这依赖于两个阶段之间只有 1 个阶段的差异。如果两个阶段之间存在更多的会话日志记录，您需要将 1 的值更改为匹配。

如果您正在使用 示例 4 – 新模型评估流程模板（来自 第六章）在生产中评估第二个机器学习模型，可以使用以下 SQL 语句：

SELECT logid, stagename, result, attributexml, startdatetime from BPASessionLog_NonUnicode
WHERE stagename = 'Log New Model Evaluation Results'
AND processname = 'To Change';

从数据库中导出审查后的预测数据

根据使用的模板，审查后的预测结果可能出现在两个位置。如果使用双工作队列或三工作队列模板，我们可以从 BPAWorkQueueItem 表中找到它们。如果不使用这些模板，我们可以查看 BPASessionLog_* 表。

查询工作队列数据

对于 HITL 审查工作队列，我们只检索我们知道已经发生审查的结果。我们通过检查名为 Confidence 的收集字段的是否存在来完成此操作：

SELECT data FROM BPAWorkQueueItem wqi, BPAWorkQueue wq
WHERE wq.name = 'ML Queue Name (To Change)'
AND data like '%"Confidence"%'
AND wqi.queueid = wq.id;

查询会话日志数据

在所有三个模板中，都有一个名为阶段的常见名称，该阶段故意启用了日志记录，以捕获修正后的预测结果和理由。此阶段在以下图中显示：

图 9.30 – 记录审查结果和理由的常见阶段

在会话日志表中查找此阶段的 SQL 语句如下：

SELECT logid, attributexml, startdatetime from BPASessionLog_NonUnicode
WHERE stagename = 'Set [Reviewed Prediction] and [Review Justification]'
AND processname = 'attributexml column will need to be parsed by the data scientists manually or opened in Excel.
			Summary
			In this chapter, we discussed two topics which are new, ongoing activities that are required by IA: ML deployments and database operations.
			For deployments of model updates, we discussed the different strategies that are available for Web API, CLI script, and Code Stage-based ML models. Regardless of how the ML model is deployed, we need to think clearly about which steps are needed to update the IA solution, and how to roll it back. This includes whether downtime is needed, what needs to be changed (Objects, Processes, Web API Service Configurations, Environment Variables, copying files, etc.), who performs these changes, and in what order they should be performed in.
			IA affects BP database operations in two main ways. IA leads to faster database table growth, especially for the Work Queue and Session Log tables. The database team that supports IA must really perfect their database maintenance as database growth can negatively affect the performance of BP. Next, IA requires more reports and audits to be generated. It may be desirable to do this from the database. Some sample SQL queries have been provided to extract ML-related logs that work with the Process templates of *Chapter 6* and *Chapter 7*.
			The ongoing IA operations discussed in this chapter, together with the LAM, User Roles and MTE of *Chapter 8* are part of a larger topic, called the BP **Robotic Operating Model** (**ROM**). The ROM is a methodology designed to help firms achieve their automation outcomes. In the next chapter, we’ll be discussing what potential changes IA will have on the ROM.

第十章：IA 对机器人操作模型的影响

我所说的机器人操作模型（ROM）是 RPA 的管理方面。它将 BP 20 多年的自动化经验和最佳实践提炼成一个框架，该框架可以应用于所有类型的公司。这个框架的目的是帮助确保公司在自动化方面的持续成功和增长。这包括一些可能不是立即显而易见的问题领域，例如确保获得高管支持、开发职业路径、选择合适的组织结构以及促进文化接受度。

虽然 ROM 不是一个技术产品，但它仍然是 BP 与其竞争对手之间的一个关键差异化因素。任何从事 RPA 工作的人都应该熟悉 ROM，特别是由于其指导是供应商无关的。随着技术和监管环境的变化，我们的管理框架也必须随之变化；ROM 正在不断修订，目前处于 2.0 版本。有关 ROM 的更多信息，请参阅community.blueprism.com/content/rom-hub。

这个 ROM 的新版本被组织成五个基础：战略、劳动力、设计、开发和运营。每个基础进一步细分为六个子主题，总共达到 30 个主题。虽然 IA 在 ROM 中确实被提及，但它并不是主要焦点。作为一个框架，ROM 旨在提供一般性指导，让我们来填补具体细节。试图填补这些细节是我 IA 研究的主要目标之一，你在这里会找到我的许多研究成果。在本章中，我们将讨论 IA 如何影响 ROM 的五个基础，以便你更好地准备在你自己的组织中实施 IA：

• 战略

• 劳动力

• 设计

• 发展

• 运营

战略

战略基础中的三个子主题受到 IA 的影响更为明显。这些是工作未来愿景、业务案例和价值以及治理、风险和控制。工作未来愿景子主题讨论了整体自动化计划的愿景声明、使命声明和目标。它还讨论了制定沟通计划的重要性，以确保 IA 愿景在整个组织中传播。业务案例和价值是确保 IA 与公司战略一致，并支持该论点的可衡量 KPI。最后，治理、风险和控制讨论了治理委员会和风险管理。

工作未来愿景

如果我们希望从 RPA 过渡到 IA，自动化负责人和执行赞助人明确更新愿景以包括这一点非常重要。对于愿景的更具体部分（使命声明和目标），我们可以指定是否应侧重于集成预构建的 ML 服务，如基于 API 的 OCR、公开可用的 LLMs 等，还是开发内部专业知识以构建定制的 ML 模型。

对于已经运营至少 1 到 2 年的 RPA 团队，建立包含 IA 的愿景是最好的。这至少是 ROM 成熟度模型中的第 3 级：community.blueprism.com/content/rom-hub/rom2-maturity-model。

商业案例和价值

由于 ML 是一种趋势技术，许多高管都希望看到它在整个业务中得到应用。尽管有高管的支持，我们仍然需要弄清楚如何衡量 IA 对整体企业战略的贡献。常用的关键绩效指标（KPI），如全职员工（FTE）节省和返还给业务的小时数，依赖于量化数字工作者与人工工作者节省的时间。但对于 IA，节省的时间可能微不足道——例如，如果我们正在替换一个只需几分钟就能完成的专家决策过程。我们可能需要从基于时间和基于美元节省的 KPI 测量转向基于业务价值的评估。这些评估的例子可以在 ROM 2 培训材料中找到。

IA 的总拥有成本（TCO）也会显著变化。我们仍然有传统的 RPA 成本，但还有 ML 的成本。三个主要场景导致 IA 项目上的 ML 成本不同。第一种情况是将 ML 开发外包给第三方。这可能会产生固定和可变开发成本。如果模型由第三方托管，还可能有持续的服务成本。如果模型在本地部署并由内部团队完全管理，仍将存在内部持续成本。第二种是通过 API 服务消费 ML，这会产生每笔交易的成本。这些成本可以根据预期的作业量和 API 定价进行预测。

第三种情况是如果内部开发机器学习（ML）。通过初步研究，我发现第一次将内部 ML 解决方案部署到生产中大约需要 100,000 美元，不包括 RPA 成本。智能自动化（IA）与引入任何新技术类似，第一次项目的成本很高，但随着更多 IA 项目投入生产，边际成本会降低。决定内部构建 ML 应被视为一项多年努力，而不是一次性或试点项目。内部 ML 的成本主要来自薪资和硬件租赁。

除了完全通过 API 调用消耗的 ML 之外，模型将会有持续的成本，因为需要积极监控数据和模型的表现，并且必须重建模型。还可能有与雇佣 ML 预测审查员相关的成本。

治理、风险和控制

考虑 IA 治理的一种方式是将 RPA 的治理关注点添加到 ML 的治理中。单独来看，ML 治理已经是一个巨大的话题，因此治理委员会必须要有非常熟悉 ML 生产化并能够跟上其周围不断变化的监管环境的人。

IA 团队发展适当治理的起点是内部寻找现有的数据隐私、数据保留和安全方面的数据和 AI 政策。我们还需要考虑从公平和伦理的角度来看，使用 ML 模型是否可取。目前，很少有公司已经建立了 AI 伦理政策。发展内部伦理指南的一些潜在起点包括IEEE 全球自主和智能系统伦理倡议和蒙特利尔负责任 AI 宣言。

风险

IA 与 RPA 相比，存在许多与之相关的风险。首先，我们需要遵守与 AI 相关的现有和即将出台的法律。如第四章中所述，各国已经在制定法律来规范商业中 AI 的使用。

另一类风险是基于模型的，其中主要的一个是预测精度低。ML 模型的表现也已知会随时间退化，某些类型的 ML 算法容易受到对抗性攻击。

还存在基于数据的风险，包括数据偏差、数据质量和数据漂移。数据偏差指的是具有“不良属性”的数据，例如当收集的数据在不应代表某些群体时却未能充分代表。数据质量指的是存在“良好属性”，例如拥有足够的样本数量和具有与我们试图做出的预测高度相关的特征。数据漂移指的是随时间自然发生的底层输入数据分布的变化。数据漂移的一个例子可以在消费者购买行为中看到。即使在相似年龄和薪资范围内，今天人们购买的商品类型与 10 年前人们购买的商品类型不同。

通过 ML 治理可以降低的下一类风险与安全和数据访问有关。引入新的服务器来托管模型，以及必须与数据和模型交互的新员工，增加了可以针对 IA 解决方案进行攻击的潜在攻击区域。

通过治理应对风险

治理可以帮助解决上一节中提到的所有风险。对于合规风险，治理可以强制要求所有 IA 解决方案都有一种方法来禁用 ML 预测（我们在第六章中设计的“终止开关”），偏好固有可解释的算法，并为客户提供一个渠道，让他们在处理他们的案件时请求不使用 ML。

ML 治理可以帮助减少基于模型的风险。治理可以要求我们实施正式的审查和测试流程，以确保在模型达到生产之前，至少有一定比例的预测是正确的。我们还可以强制要求在模型投入生产之前使用通用的 ML 可解释性方法，如 LIME 和 SHAP 来评估模型。

由于模型随着时间的推移会失去预测能力，治理应该定义关于持续监控模型性能的要求。这包括收集经过人工审查的预测进行定期审查，并了解分类预测标签的频率随时间的变化。

治理可以通过实施数据标准和数据科学家培训要求来应对数据风险。建立数据质量的一个例子可能是强制规定数据必须至少有 1,000 个样本每个标签，并且每行必须少于 5%的缺失列。治理可以要求数据科学家在允许他们为 IA 项目开发模型之前，完成关于识别数据偏差的培训。

治理还可以围绕定期监控数据的需求制定标准。首先，需要收集基线统计数据，通常来自训练数据。计算的一些常见统计数据包括数据列的平均值、最大值、最小值和标准差。然后，基于生产中使用的输入数据，定期重新计算新的统计数据。治理可能要求每月进行此操作，并对数据列中超过一个标准差的变化进行手动评估或触发模型重建并部署到生产中。

为了安全，我们需要修改现有的治理政策，以定义谁可以更改这些 IA 组件以及相应的程序。这可以利用在第八章中开发的ML Deployer和ML Reviewer角色。

人力资源

对于劳动力基础，我们将更深入地探讨 构建您的组织模型、采用新的思维和工作方式 以及 角色和职业道路。构建您的组织模型讨论了 IA 功能在公司中可以采取的不同结构方式。一些例子包括 IA 作为为所有人服务的中央单位，不同业务单元内的个人 IA 团队，或者 IA 完全外包给供应商。采用新的思维和工作方式 是关于影响组织并克服对 IA 的阻力以获得支持。最后，角色和职业道路 是关于需要哪些技能集和角色来创造成功的 IA 结果并确保 IA 团队内的职业发展。

构建您的组织模型

关于组织模型的一些主要考虑因素包括 ML 专业知识在组织中的位置，如何与之互动，以及是否需要直接将 ML 专业知识带入 IA 团队。如果公司已经有一个集中的数据科学团队，我们必须考虑他们的组织模型，以及他们期望如何向公司其他部门提供 ML 专业知识。

如果公司对 IA 严肃认真，预计自动化团队至少会有几名成员能够执行数据科学工作，而不依赖于外部团队。对于 卓越中心（COE）、特许经营 或 中心和辐射 组织模型，中央团队应拥有能够将 ML 模型投入生产的内部专业知识。对于 部门、部门联盟 和 外包管理服务 模型，ML 专业知识可以存在于那些团队中。

采用新的思维和工作方式

理解 IA 可能受到 个人员工 和 管理层 反对的方式非常重要。由于潜在可自动化的范围扩大，IA 的采用可能比 RPA 更难管理。在我的研究中，我确定了员工和管理层反对 IA 采用的一些重要方式以及一些对抗这种反对的方法。

员工层面的 IA 阻力

如果认为对员工有意义的任务是自动化的，IA 可能会导致 工作意义的丧失。一个现实生活中的例子是用聊天机器人和 RPA 替换社会工作者对老年人的福利筛选电话。受影响的员工的访谈显示，他们在自动化后工作满意度较低。可以使用名为 工作与意义清单（WAMI）的调查问卷来确定员工在 IA 实施后是否经历了工作意义的丧失。

工作的意义可以分为四个组成部分：个人、工作、组织和社会。如果我们认为 IA 会降低某人的工作意义，我们可以通过针对这些不同层面的改进来对抗这种影响。例如，在个人层面，我们可以通过允许在家工作日来为受影响的员工提供更多的灵活性和自主性。在工作层面，我们可以改变受影响人员工作的意义、可见性和范围。在组织层面，我们可以增加企业社会责任活动的数量。更实际的方法是询问受影响的员工，所提出的自动化是否有可能降低他们的工作满意度，并避免自动化那些领域。

员工可能遇到的其他风险是工作准备度降低。在一家金融服务公司，通过 IA 将文件数字化并自动输入到内部系统中，而不是由案件工作人员自己输入。移除手动数字化和输入任务意味着花在查看客户详细信息上的时间减少。受影响的员工感到更加焦虑，并且不太准备好直接与客户互动。对抗工作准备度降低需要简化数据访问或通过汇总仪表板改进数据的展示。

IA 可能会影响员工对整体工作安全感的感觉。衡量工作安全感的两个方面包括：首先，我们可以通过工作安全感指数问卷来衡量员工认为他们的工作有多“稳定”；其次，我们可以通过工作安全感满意度量表来衡量员工的态度，即他们如何看待自己的工作安全感。如果可行，我们可以让人力资源部门在 IA 实施前后进行测量，以确定是否存在需要解决的工作安全感问题。

如果 IA 的目标不是减少员工人数，那么应明确传达“无岗位流失”的信息，并公布将用于评估 IA 项目成功与否的可衡量指标。SS&C 自实施 IA 以来提出的一个信息是，不是裁员，而是减缓招聘。如果目标是裁员，应准备培训计划，教育将被保留的员工如何与数字工作者协作。还应修订员工的工作角色定义。这两项行动可以帮助减少对工作不安全的感知。

防止对员工产生更广泛负面影响的关键在于在整个组织中培养对 AI 情绪的理解。在所有公司中，都会有支持或希望与 AI 技术合作的人，也会有那些不支持的人。IA 的首次推广应针对那些对 AI 持积极态度的个人或部门，因为这可以提高最初获得积极结果的几率，从而有助于说服业务的其他领域认识到 IA 的好处。

管理层对 IA 的抵制

IA 可能会面临管理层抵制，因为它通常被描绘为减少人员数量和成本的方式。如果管理层的人员数量保持不变或减少，他们自然会担心他们的预算、影响力范围以及达到 KPI 的能力。IA 可能导致管理层被动抵制、拖延甚至积极破坏 IA 的努力。由不合作的管理团队收集的 IA 指标通常会低估，以破坏 IA。

为了了解管理层对自动化的抵制，已经进行了研究。高级管理层的反对主要是因为缺乏知识。中层管理层，他们直接监督将被 IA 取代的员工或流程，对反对的原因更为复杂。按重要性排序，这些原因包括缺乏信心、培训不足和对工作重要性的担忧。失去人员数量的恐惧也被直接提及，作为管理层的主要担忧。

研究中提出的解决管理层抵制的方法在实践观点上相当模糊。减少抵制的建议包括教育、使用数据来说服管理层、逐步实施变革和培训。减少人员流失恐惧的一种实际方法（假设这不是 IA 的主要目标）是明确要求经理提交计划，说明 IA 实施后员工将执行的其他增值任务。规划如何利用他们的员工在释放他们的时间后使用，可以帮助缓解恐惧。

经理们也担心 IA 可能会引发员工流失并降低员工的留存率。已有针对 AI 采纳及其对员工影响的具体研究。正如预期的那样，对 AI 持负面态度的员工在 AI 被采纳时更有可能离职。再次强调，我们应该了解员工对 AI 的看法，并针对那些对 AI 持正面看法的员工使用用例。当员工感到公司给予他们支持时，离职意向会减弱。这包括许多事情，如团队建设活动、职业规划、员工发展、教育等。

另一个关键的管理层担忧是财务损失。这主要体现在两个方面。首先是通过诉讼造成的财务损失——例如，如果属于受保护类别的某个人认为他们因为机器学习模型中的偏见而受到了不公平的对待，并决定采取法律行动。第二种类型的财务损失是由于预测错误导致的进一步错误处理。我们可以通过允许管理层审查现有的治理结构来管理这些担忧，以选择用于生产使用的模型，选择 IA 用例，并审查特定的预测。

角色和职业路径

然而，如果策略是内部发展机器学习能力，将出现一些新的角色。第一个是人工智能数据科学家。这个人将负责分析数据、构建模型、测试模型以及评估它们。我建议雇佣具有这些技能的人，或者从组织内部的其他地方借用这个人，而不是首先内部培养数据科学家。主要原因是因为成为一名数据科学家所需的时间投资非常长。

这个数据科学家可以组建一个由IA 开发者组成的团队，这是一个介于数据科学家和自动化开发者之间的混合角色。IA 开发者将从强大的 RPA 基础开始，并随着时间的推移逐渐建立起他们的数据科学技能。IA 开发者还应关注市场上可用的商业机器学习服务。拥有足够经验的 IA 开发者可以通过横向职业发展成为全职数据科学家。

一个重要的问题是，谁管理机器学习基础设施。随着人工智能（IA）项目的增长，我们可能需要一个专门的人工智能技术架构师来定义适当的部署方法，管理部署和回滚，监控数据，以及管理支持人工智能的其他基础设施问题。与通常不是全职职位的“传统”RPA 技术架构师角色不同，由于机器学习模型持续的管理需求，人工智能技术架构师可能会因为人工智能项目的增长而有足够的工作量，最终可能成为全职职位。

期望普通开发者能够构建和部署机器学习模型是不切实际的。普通开发者最终将能够使用 AutoML 服务（例如，在第十三章中讨论的Decision），以及大型语言模型（LLMs），尽管使用 LLMs 存在许多挑战需要克服，例如处理幻觉结果、幻觉置信度分数以及解析非结构化响应。治理委员会和设计权威机构将需要制定关于普通开发者如何使用 AI 的指导方针。

设计

在本节中，我们将更深入地探讨评估和优先级排序的子主题，该主题讨论如何选择开发 IA 流程，以及需求设计，该主题讨论捕捉业务流程的步骤和功能需求。

评估和优先级

在流程发现过程的评估阶段，在使用案例进行分析之前，应该有一个经验丰富的数据科学家的背书，以确定机器学习部分是否可行。分析阶段的一部分应该包括 ML 模型的 POC（原型）开发或测试现成的 API，以确保有足够的准确性（或其他所需指标）来证明继续进行 IA 用例的合理性。再次强调，治理委员会上必须有一位对 ML 有经验的成员，以便批准 IA 开发流程。

一个重要的评估领域是 IA 将如何影响现有的 SLA。虽然我们预计 IA 会增加可以完成的工作的整体吞吐量，但 SLA 也可能包括基于质量的目标，这取决于所使用的模型的准确性。一个基于质量的目标示例是保持客户满意度评分在 3/5 以上。

新基础设施的引入对部署机器学习（ML）也产生影响，因为它是一个新的停机源。许多机器学习模型托管在主要的云平台上，如 GCP、AWS 和 Azure。2021 年 12 月，AWS 在工作日期间出现了多次故障。Azure 在 2023 年 1 月也发生了重大故障。如果您的模型当时托管在这些平台上，那么由于机器学习模型不可用，您可能会违反服务等级协议（SLA）。

需求设计

在 IA（智能自动化）方面，我们需要帮助业务定义之前不存在的要求。例如，触发预测的 HITL（人类-机器交互）审查的标准是什么？如第四章所示，这可以包括随机抽样、不同标签的不同阈值，或基于公式的方 法。具体的阈值值本身还不必选择，因为它们应该基于候选模型的实验来选择。

业务还需要定义如何向审阅者展示预测数据，例如通过 Excel、自定义开发的网站或数据库。一旦做出预测，我们需要知道是否存在一个最大允许的完成预测与人工审查之间的延迟，这对于 SLA 目的而言。

对于数据和模型本身也可能有要求。在某些用例中，一些数据字段，如年龄和性别，受到保护，不能用于模型。如果数据被认为是敏感的，那么它可能不能发送到组织外部，这会排除在线机器学习 API 在我们的解决方案设计中被考虑。

如果模型需要可解释性，这意味着应该优先考虑某些类型的回归和树模型。我们可能已经考虑了期望的算法，如深度学习或 LLM（大型语言模型），这会对解决方案提出硬件要求（GPU）。我们还需要了解预测是否时间敏感，因为这也会告知数据科学家哪些算法是可能的，以及部署解决方案的大致硬件需求。

开发

方法和团队合作子部分受到 IA 的影响，因为 ML 模型有一个并行于传统 RPA 开发的独立开发周期。在交付控制方面，一个足够高质量的模型也常常作为继续开发 IA 解决方案的通过与否的决定因素。在 IA 下，测试和质量保证永远不会真正停止，因为 ML 模型需要持续的监控以确保质量水平得到维持。

方法与团队合作

机器学习模型开发通常独立于 RPA 开发。虽然 BP 有六个阶段的交付方法（定义、设计、构建、测试、UAT 和部署），但这并不完全适用于机器学习模型构建。例如，许多机器学习模型开发方法都有数据分析和完善阶段，这些在 RPA 中是不需要的。

如果机器学习模型是由不同的团队构建的，我们不需要过多考虑正在使用什么特定的机器学习方法。然而，如果机器学习是内部构建的，IA 团队应该寻求标准化他们的机器学习模型开发方法。网上有许多这样的例子——例如，来自 AWS (docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/well-architected-machine-learning-lifecycle.html) 和 GCP (cloud.google.com/blog/products/ai-machine-learning/making-the-machine-the-machine-learning-lifecycle)。

机器学习模型开发的生命周期在流程定义文档最终确定之前开始是很正常的，尤其是在收集和分析训练数据时。在开发的设计阶段，我们需要与数据科学家合作，选择机器学习模型与 BP 之间的接口，无论是 Web API 调用、可执行文件、程序脚本还是代码阶段。我们还需要数据科学家提供不同的预测响应示例，以便在 BP 中进行模拟。这允许 RPA 开发者即使机器学习程序尚未准备好，也能在本地测试他们的工作。还应该讨论功能需求，例如所需的 SLA、响应时间、我们是否可以批量发送预测请求等。所有这些都应该记录在解决方案设计文档中。

对于最初的几个 IA 项目，RPA 团队通常需要从组织内部的其他地方借用专业知识。如果数据科学家没有完全致力于项目，IA 项目的工作可能会被降级，交付时间表可能会推迟。

设计权威机构应有一名具有实际开发模型经验的成员。如果模型是内部开发的，需要考虑模型是否可以设计为跨多个 IA 用例重用，或者模型是否必须保持独立。设计权威机构的工作部分将扩展到跟踪正在使用的机器学习模型及其应用位置。

交付控制

在 RPA 或等效机器学习开发阶段的构建阶段，我们需要记住，预测精度不足可能导致在整体 IA 解决方案的开发方面做出不继续开发的决策。从某种意义上说，机器学习模型开发应略领先于 RPA 开发，以最大限度地减少开发工作浪费的风险。

机器学习模型的用户验收测试可能完全独立于 RPA 进行。机器学习模型 UAT 的完成应作为开始 RPA UAT 前的入门标准之一。

测试和质量保证

在机器学习模型的用户验收测试（UAT）期间，捕捉预测结果和置信度得分非常重要。这些数据有助于我们校准不同标签所需的适当置信度得分，以防使用阈值来确定是否需要人工审查。

IA 与 RPA 之间的主要区别之一是机器学习模型的质量保证（QA）永远不会真正停止。机器学习运营团队应定期监控机器学习预测的结果，以检测潜在的漂移。

运营

智能分析（IA）会影响部署和发布，因为即使业务逻辑（流程）或应用程序（对象）没有发生变化，也预期会进行机器学习部署。由于机器学习的加入带来了许多需要执行的操作，包括监控模型、监控数据、导出 HITL 审查结果等，因此支持模型有众多变更。

部署和发布

如前一章所述，机器学习模型应定期部署到生产环境中，部署时间表应独立于流程和对象更新。用于机器学习模型的部署方法应通知控制室操作员如何更新整体智能分析（IA）解决方案，以保持可审计性，以及如何在部署的新模型出现问题时进行回滚。建议选择一种不需要停机即可回滚的部署方法，并且模型的预测响应应返回用于做出预测的模型版本，以便进行审计。部署新的机器学习模型还应需要正式的变更请求，并需获得批准。

支持模型

IA（智能代理）为支持模型带来了重大补充。我们现在必须担心 ML 模型的正常运行时间（业务连续性），确保 ML 模型的准确性（这可以通过随机抽样进行评估），以及可能的人类审查的 SLA（服务等级协议）。每个 ML 模型都将有自己的 ML 审查员，他们可能也需要培训和访问 BP（业务流程），因为他们可能会手动更改工作队列项的状态或编辑会话变量以重新创建审查数据。

如果 ML 模型由 IA 团队维护，模型及其数据需要持续监控，以防止性能下降和数据漂移。这通常是通过基于 Web 的仪表板完成的，该仪表板读取 ML 服务器日志。如果 ML 通过 Web API 部署，则这种方法有效，但如果模型是通过 CLI（命令行界面）或代码阶段调用，则不适用。在这种情况下，支持模型需要包括从工作队列或会话日志中导出 ML 结果，供数据科学家进行分析，并将其纳入监控系统中。无论 BP 使用何种方法进行 ML 预测，我们仍然需要将关于已审查预测的信息反馈给数据科学家，因为该数据不在 ML API 服务器日志中。

监控数据和模型可能导致 ML 模型的定期更新和部署。其他关注点，如 ML 库的更新、通过 HITL（人机交互学习）审查接收到的新的训练数据，或对新算法的实验，也可能导致模型更新。业务逻辑的变化也可能触发 ML 模型的更改。IA 支持团队需要非常熟悉将新模型部署到生产环境中。

另一个主要关注点（虽然它与引用处理和异常处理相关，但并不是这两者之一）是所谓的时间滞后效应。想象一下，我们是一家使用机器学习（ML）来判定账户开立申请是否欺诈的银行。如果 ML 模型存在缺陷，许多欺诈性账户创建请求将被进一步处理，数据将被发送到许多其他系统。在模型缺陷被检测到之前，可能已经处理了数千个账户开立申请。在做出错误的 ML 预测和发现它之间需要撤销或纠正的工作量，就是时间滞后效应。

除非 ML 模型完美无缺，否则时间滞后问题是不可避免的。支持模型需要考虑如何处理个别案例——例如，如果业务用户标记了一个由错误的 ML 预测导致错误处理的案例。支持模型还需要处理批量案例，这些案例可能是由有缺陷的 ML 模型引起的。甚至可能需要创建一个专门的自动化流程，专门用于撤销 IA 解决方案在预测后执行的操作。

支持模型应尝试解决如何分配预测责任的问题，该预测导致某种形式的损失。在某个时候，需要有人或团队对由错误的机器学习预测引起的错误处理负责。是 IA 团队或数据科学团队的人？是签署了模型测试结果批准的业务用户？是审查员（假设所讨论的预测已被审查过）？这是在指责发生之前所有各方需要达成一致的事项。

机器学习责任是法律研究的一个活跃领域。我发现法律专家认为，使用预测的公司将被追究责任，即使机器学习模型开发完全外包。虽然使用预测的公司可以尝试寻求对第三方提起法律诉讼，但几乎不可能证明算法有缺陷。

对责任归属的直观分配可能是给维护模型或审查预测的个人或团队，但这两者都可能被外包。如果这些功能已经被外包，那么下一个直观的责任分配将转向在 UAT（用户验收测试）后签署模型批准的业务用户。

最后，如果 IA（可解释人工智能）实践较为先进，那么实施一些通用的机器学习可解释性方法是值得考虑的，例如 LIME 和 SHAP。虽然这些可解释性算法通常被认为是在将模型部署到生产之前的一个审计步骤，但它们也可以在帮助 IA 团队调查对业务用户有问题的预测以及找到避免未来出现这些问题的模型调整方法时发挥作用。

摘要

BP ROM 是一个框架和方法论，指导整个自动化程序。对 ROM 有良好的理解可以显著提高实现自动化目标并更快地扩展数字工作力的可能性。虽然 ROM 是一个无价的资源，但它不提供如何将机器学习预测添加到 RPA 流程的具体指导。

在本章中，我介绍了 ROM 2 的五个基础，并讨论了从 RPA 转向 IA 最受影响的子主题。讨论是基于我的 IA 研究发现和我在机器学习方面的经验。IA 主要通过在现有的 RPA 问题之上增加一套独立的机器学习关注点来影响 ROM。

这就结束了关于 BP（业务流程自动化）管理方面的章节。在下一章中，我们将通过考察两个真实案例来巩固本书所学的内容。

第四部分：真实场景和其他 Blue Prism 产品

在第四部分中，我们将通过考察两个基于现实案例的情景，来整合本书的第二部分和第三部分的内容。第十一章描述了一个包含三个不同机器学习模型的 IA 用例。在这里，我们将分析机器学习模型的要求，以选择合适的设计方案，并通过使用第七章中开发的 IA 流程模板来实施解决方案结构。

第十二章描述了一个不同的用例，其中机器学习可审计性是首要关注点。在这里，我们将通过实例说明如何部署机器学习模型的新版本以及如何回滚。我们还将探讨如何通过 BP 数据库提取机器学习审计数据。

在整本书中，我们只讨论了主要的 BP 产品。BP 生态系统中还有许多其他产品，它们也与 IA 直接或间接相关。第十三章描述了这些附加产品、它们的目的以及如何用于 IA。最后，我们通过讨论三个未来的 IA 趋势来结束本书。

本部分包含以下章节：

• 第十一章，处理退款

• 第十二章，电力服务中断

• 第十三章，其他智能蓝宝石产品

• 附录，IA 风险管理

第十一章：处理退款

在本章中，我们将检查一个场景，目的是巩固本书中提出的概念。这包括如何选择使用哪个 IA 模板开始开发、审计、紧急停止开关等。我们将分析用例的 ML 需求，设计解决方案，并实现解决方案的结构。

本章使用的场景是基于在线零售商的真实生活用例。这家零售商希望自动化通过电子邮件收到的退款请求的批准。这个用例包含多个 ML 模型，其中一个是内部开发的，其他则不是。我们之前只讨论过只有一个 ML 模型的流程解决方案设计，但我们将看到我们可以将本书中提出的设计和模板扩展到多个模型。

IA 团队正在构建一个解决方案来处理发送到在线零售商客户服务电子邮件的退款请求。业务希望使用 ML 来确定电子邮件是否请求启动退款。如果是这样，案件将继续处理。

接下来，业务用户希望从电子邮件中提取有用的实体，例如订单号和项目成本。如果这些数据以足够的置信度提取，同时满足其他业务标准，则退款请求将自动处理。

如果自动退款请求成功，业务用户将使用生成式 AI 创建一封电子邮件回复发送给客户。公司已经开发了一个用于生成式 AI 模型的提示。公司有一个战略计划，即使用更多 AI 技术并显得技术创新。那些电子邮件退款请求自动批准的客户将被告知，他们的案件是通过自动化和 AI 完成的。

客户支持团队有一个 SLA，在收到电子邮件后的 48 小时内提供第一个客户响应（不是解决方案）。他们希望 IA 解决方案能够在 48 小时内为部分退款请求提供完整的解决方案。

在本章中，我们的角色是 IA 团队中的解决方案设计师和开发者。我们将涵盖以下主要主题：

• ML 模型背景信息

• 解决方案设计

• 实现

重要提示

本章的示例主要关注设计和实现 IA 解决方案的结构。关于正常业务逻辑的细节没有讨论。完整的解决方案，包括 ML API 调用，也不会实现，因为这些细节很容易实现，并且在前面章节中已经介绍过。

技术要求

IA 流程模板在第第七章中进行了讨论。如果您还没有阅读该章节，请从github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/tree/main/ch7下载并导入.bprelease文件。该章节中的示例将基于其中一个模板。

ML 模型背景信息

此场景使用三个 ML 模型：一个电子邮件分类器（EC），一个实体识别模型（ER），以及生成式 AI（GAI）。在设计解决方案之前，我们需要了解 ML 模型的一些特定特征。IA 团队与业务用户、数据科学团队和 ML 供应商的文档合作，以回答以下问题：

• 谁开发和维护模型？

• ML 模型的消费和部署方法是什么？

• 是否需要对 ML 模型进行审计？

• ML 预测的估计量是多少？

• HITL 审查的标准是什么？

  • 审查的 SLA 是什么？

  • 是否需要对 HITL 审查进行审计？

  • 将使用什么界面来审查预测？

EC 模型

业务只想确定一封电子邮件是否请求退款。他们不需要预测其他电子邮件类别，如产品咨询和投诉。在与内部数据科学团队讨论后，他们决定开发一个二元分类模型，该模型可以预测退款请求和非退款请求。

消费和部署方法

EC 模型将在内网上托管并通过 HTTP API 调用。由于该模型尚未开发，IA 团队要求 ML 运维团队使用蓝绿风格的部署。IA 团队希望给自己留出在需要时进行无停机回滚模型的选择。IA 团队还要求 API 响应中返回一个模型版本，以防他们需要将其存储以供审计目的。数据科学团队同意这些请求。

预测量

在采访客户支持人员后，我们发现他们每天收到约 500 封电子邮件，其中 70 封是退款请求。客户支持团队估计，在 70 封退款请求中，大约有 20 封符合自动批准所需的条件。

HITL 审查、界面和 SLA

从之前对电子邮件进行分类的经验来看，数据科学团队预计二元分类器的准确性非常高。因此，团队决定不要求进行 HITL 审查，而是随机抽取 5%的预测（大约每天 25 个）来验证模型是否随着时间的推移正确执行。客户支持团队的员工将在他们的常规任务之外进行这些审查。IA 团队决定使 EC 预测审查非阻塞，这意味着我们不会等待审查完成就继续自动化处理。

审查的界面是将客户的电子邮件转发到一个新创建的电子邮件分发列表，该列表将由客户支持监控。审阅者只需简单地回复电子邮件，用Y表示这是一份退款请求，或用N表示这不是。

ML 审计

由于模型将由数据科学团队维护，预测输入和输出日志将从 API web 服务器可用。数据科学团队同意将日志保留六个月，这意味着我们有权决定是否希望在 BP 中也保留日志副本以方便使用。

让我们讨论下一个用于从电子邮件中提取数据的模型。

实体识别模型

实体识别（ER）ML 模型需要从电子邮件文本中识别订单号或产品名称和价格，以便继续处理。IA 团队发现，经过测试一些在线商业产品后，有许多现成的服务可以提取所需的数据。

消费和部署方法

IA 团队决定使用托管在他们已有关系的云提供商上的预训练模型。由于我们选择了一个通用的托管 ML 解决方案，我们无法控制模型何时更新。我们需要积极监控供应商网站，以查看是否有新模型可用。此模型的 API 端点是版本化的，这意味着我们可以根据需要在不同版本的 ER 模型之间切换。

预测量

当认为一封电子邮件是退款请求时，仅在使用 EC 模型之后才使用 ER 模型。客户支持给我们提供了一个大致的预期，每天大约有~70 个预测。在考虑使用此 API 的成本后，治理委员会决定这仍然值得追求。

HITL 审查、界面和 SLA

由于 ER 返回多个标签和置信度水平，我们决定使用具有多个条件的阈值方案。在从客户支持获得历史退款请求电子邮件后，我们进行实验以确定 ER 模型预测的 HITL 审查的适当阈值值。

首先，如果我们提取的订单 ID 的置信度低于 97%，则需要手动审查。接下来，我们审查产品名称或价格置信度低于 93%的预测。最后，我们审查所有置信度无论高低，但提取的价格高于$300 的预测。由于审查方法复杂，需要纠正多个标签，团队决定通过自定义构建的 Web 界面向审阅者展示审查数据。

由于我们旨在在 48 小时内解决案件，团队暂定决定审查 SLA 为 24 小时。

ML 审计

由于 ER 模型是第三方 API，IA 团队需要在 BP 中跟踪预测输入、输出和模型版本。虽然我们可以访问云门户的仪表板来查看历史使用记录，但这些记录隐藏在比从 BP 内部查找数据更复杂的不同审批流程之后。

ER 模型的讨论已经完成。接下来，我们将讨论第三个 ML 模型，即生成式 AI。

生成式 AI 模型

客户服务团队希望使用 GAI 为客户自动批准的退款请求创建电子邮件回复。虽然我们可以简单地使用电子邮件模板，但公司希望向客户和投资者保持其以技术为中心和前瞻性的形象。

消费和部署方法

由于 IA 团队无法获得足够的 GPU 处理能力以内部开发 GAI 模型，团队决定使用托管 API 解决方案。通过查看 API 文档，我们发现供应商使用了一种持续模型升级方案。这意味着 API 端点背后的模型正在不断更新，并且更新不会通知客户。API 响应中返回的确切模型版本，但我们无法明确调用模型的旧版本。这使得模型版本并不那么有用，因为我们只能调用最新版本的模型。发送给 GAI API 的提示将为每位客户相同。

预测量

预计每天将发送 20 封电子邮件。在考虑这些成本后，该用例仍然被认为是可行的。

HITL 审查、界面和 SLA

客户支持团队已经测试了第三方 GAI 服务，并对生成的电子邮件响应感到满意。公司还创建了一个静态免责声明，该声明将在 GAI 响应之后附加到每封电子邮件的底部。这是为了在 GAI 文本不清晰的情况下消除歧义。这个免责声明将清楚地告知客户，他们的退款案例已自动处理并获得批准，并且电子邮件文本是 AI 生成的。正因为如此，团队不打算审查任何由 GAI 生成的电子邮件。选择 GAI 的一个因素是它带来了积极的客户结果，这本质上风险较低。

机器学习审计

生成的电子邮件消息必须通过 CRM 系统发送给客户，而不是直接通过邮件服务器。客户收到的电子邮件副本始终可以通过 CRM 找到。由于业务团队不打算更改提示，IA 团队决定保留每个 API 调用的输入副本是不必要的。尽管模型版本在预测响应中返回，但我们实际上无法指定我们想要调用的模型版本。我们可以决定是否要存储模型版本，尽管这并不特别有用。

现在我们已经收集了关于三个机器学习模型的信息，以便制定解决方案设计。

机器学习模型总结

与解决方案的设计和实施相关的机器学习模型特性的总结如下：

模型	部署方法	HITL 审查标准	HITL 审查界面	HITL 审查 SLA	机器学习审计
EC	蓝绿 API	随机抽样，5%	邮件	N/A	在 API 服务器上
ER	未知，但 API 已版本化	基于多个条件的阈值	网站	24 小时	在 IA 解决方案中
GAI	持续的，API 响应包含模型版本	N/A	N/A	N/A	在客户支持系统中

表 11.1：机器学习模型特性的总结

在了解机器学习模型的信息后，我们可以开始我们的解决方案设计。

解决方案设计

我们需要考虑为我们的解决方案选择多少个进程和工作队列是合适的。回想一下第五章，一个机器学习解决方案可以为机器学习模型和 HITL 审查分别有一个独立的进程/工作队列。让我们分别查看每个机器学习模型，以确定是否需要额外的进程和工作队列。

邮件分类模型

EC 机器学习模型的日志可以直接从本地 API 服务器访问，因此从日志记录的角度来看，没有必要将它们保存在单独的工作队列中。也没有必要从主进程独立扩展机器学习预测。因此，IA 团队决定 EC 机器学习模型不需要独立的进程和工作队列。

接下来，IA 团队考虑 HITL 审查要求。每天大约随机抽取 25 封邮件进行审查。由于模型是在内部开发的，因此将修正后的预测发送回数据科学家以改进模型是有意义的。团队决定为 EC 模型的 HITL 审查部分设置一个独立的进程和工作队列。

实体识别模型

由于 ER 模型是外部 API，并执行整体业务流程的关键部分，我们希望记录模型的输入和输出审计轨迹。这导致我们设计了一个方案，其中ER 模型的预测有一个独立的进程和 工作队列。

审查方法也很复杂，需要自定义开发的 Web 界面。我们希望控制用于审查的共享数据创建，并审计对预测的人为修正。出于这些原因，我们决定为 ER 模型的 HITL 审查部分设置一个独立的进程和工作队列。

生成式 AI 模型

由于提示是静态的，因此不需要在日志中跟踪 GAI 模型的输入。API 响应（电子邮件文本）也将保存在客户支持系统中，因此不需要从 BP 进行 ML 预测结果的审计。由于将随 GAI 生成的电子邮件发送一些模板文本，这降低了误解电子邮件的可能性，因此也不需要 HITL。IA 团队决定不在解决方案的 GAI 部分有单独的流程和工作队列。

解决方案设计图

总体而言，机器学习部分的 BP 解决方案设计看起来如下。

图 11.1：解决方案流程和工作队列的示意图

流程 1 是主要流程，其中包含业务逻辑以及调用 EC 和 GAI 模型的阶段。在 EC 预测完成后，随机抽取的项目被添加到工作队列 2（A）。由于审查是非阻塞的，因此可以安排流程 2 在非高峰时段运行，以检查电子邮件收件箱中关于Y和N的回复。

对于预测为退款请求的电子邮件，处理将继续，直到我们需要使用 ER 模型进行预测。处理暂停，并将输入数据添加到工作队列 3（B）。如果 ER 预测不需要人工审查（C），项目将在流程 1 中继续其工作。如果 ER 预测需要审查，它将被添加到工作队列 4（D）。一旦 ER 预测的 HITL 审查完成，项目的状态将在队列 1（E）中更新，以便处理可以继续。

实现

在根据上述三个模型的特点完成 IA 解决方案设计后，开发者开始构建解决方案的整体结构，从 IA 模板开始。

示例 1 – 从 IA 模板创建解决方案结构

我们不想直接进入业务逻辑和对象的开发，而是想创建解决方案设计结构，以确保不同流程和工作队列之间的协调按预期进行。在这个例子中，我们将从九个高级步骤构建解决方案结构：

1. 使用来自第七章中的一个模板的另存为来创建整体流程结构。

2. 创建工作队列。

3. 在每个流程的主页上更改数据项和获取下一个项目，以便引用新创建的工作队列。

4. 修改我们的解决方案的流程 1，以添加直接调用 EC 和 GAI ML 模型预测相关的页面。

5. 在每个流程的IA 数据页面更改数据项，这些数据项存储用于在解决方案的不同工作队列中保持项目数据一致性的标签、状态和项目数据字段。

6. 在流程 01 - 处理退款 中的 IA 数据 页面数据项中查找并替换，以修复一些对已重命名数据项的损坏引用。通过手动方式修复剩余问题。

7. 在流程 02 – 邮件分类器 HITL 审查 中的 IA 数据 页面数据项中查找并替换，以修复对已重命名数据项的损坏引用。删除在审查完成后更新工作队列 1 的不需要的逻辑。

8. 在流程 03 – 实体识别 中查找并替换 IA 数据 页面的数据项，以修复对已重命名数据项的损坏引用。通过手动方式修复剩余问题。

9. 在流程 04 – 实体识别 HITL 审查 中查找并替换 IA 数据 页面的数据项。

让我们从保存模板为新流程开始。

将模板“流程”保存为新的“流程”

如果查看 图 11.1，我们的解决方案基本上是第七章中的模板 3 (第七章*，增加了两次 HITL 审查流程和队列。让我们打开相关的流程模板并将它们保存为新流程：

1. 导航到 BP 的工作室部分。在流程下创建一个名为 Ch11 的新组。

2. 展开导航到 Ch7 | IA 模板 3 - 3 流程 3 队列 组。

3. 打开 01 - 业务逻辑 流程。使用 文件 | 另存为 将其保存为名为 01 - 处理退款 的新流程，位于 Ch11 组中。关闭生成的流程工作室窗口。

4. 打开 02 - ML 预测 流程。使用 文件 | 另存为 将其保存为名为 03 - 实体识别 的新流程（注意从 02 到 03 的重命名），位于 Ch11 组中。关闭生成的流程工作室窗口。

5. 打开 03 - HITL 审查 流程。使用 文件 | 另存为 将其保存为名为 04 - 实体识别 HITL 审查 的新流程（注意从 03 到 04 的重命名），位于 Ch11 组中。保持流程工作室窗口打开。

6. 在 04 - 实体识别 HITL 审查 流程仍然打开的情况下，使用 文件 | 另存为 将其保存为名为 02 - 邮件分类器 HITL 审查 的新流程，位于 Ch11 组中。关闭生成的流程工作室窗口。

7. 验证你的 Ch11 组包含以下四个流程：

图 11.2：Ch11 组中流程的内容

创建工作队列

创建一个功能解决方案结构的下一步是创建四个工作队列：

1. 导航到 BP 的 系统 | 工作流 | 工作队列 区域。

2. 右键单击 队列 区域并创建一个名为 Ch11 的新组。

3. 在 Ch11 组内创建四个工作队列。将队列名称与 图 11.2* 中显示的流程名称相同。暂时将键名称保留为 字段 1。

4. 验证工作队列中的 Ch11 组看起来如下：

图 11.3：Ch11 组中工作队列的内容

我们已经完成了工作队列和过程解决方案结构的创建。接下来，我们需要更改处理过程以匹配 图 11.1* 中的解决方案图。

修改模板的工作队列数据项

在 图 11.1* 的解决方案图中，箭头显示了每个处理过程需要与之交互的工作队列。对于每个处理过程，我们需要创建一个数据项，引用它有 出向箭头 的每个工作队列，以及它自己的工作队列。每个处理过程 主页面 所需的数据项完整列表如下表所示：

过程名称	数据项名称	数据项初始值
01 - 处理退款	队列名称	01 - 处理退款
01 - 处理退款	队列名称 2	02 - 邮件分类器 HITL 审查
01 - 处理退款	队列名称 3	03 - 实体识别
02 - 邮件分类器 HITL 审查	队列名称 2	02 - 邮件分类器 HITL 审查
03 - 实体识别	队列名称	01 - 处理退款
03 - 实体识别	队列名称 3	03 - 实体识别
03 - 实体识别	队列名称 4	04 - 实体识别 HITL 审查
04 - 实体识别 HITL 审查	队列名称	01 - 处理退款
04 - 实体识别 HITL 审查	队列名称 4	04 - 实体识别 HITL 审查

表 11.2：存储工作队列名称所需的数据项

让我们编辑每个处理过程以使用正确的队列：

1. 在过程工作室中打开 01 - 处理退款 处理过程。

2. 导航到 主页面。

3. 修改 过程设置 块中的数据项以匹配 表 11.2 的第 1 - 3 行。确保数据项的 在过程的其他页面中隐藏 复选框未被勾选。

4. 修改 两个 获取下一个项目 阶段，使它们使用与当前处理过程同名队列。对于 01 - 处理退款，将 队列名称 设置为 [****队列名称]。

5. 对其他三个处理过程重复 步骤 1 - 4。对于 步骤 3，使用 Process 2 的第 4 行，Process 3 的第 5 - 7 行，以及 Process 4 的第 8 - 9 行。对于 步骤 4，使用 [队列名称 2] 作为 Process 2，[队列名称 3] 作为 Process 3，以及 [队列名称 4] 作为 Process 4。

6. 验证对于 01 - 处理退款 处理过程，你有以下内容：

图 11.4：处理 1 的三个队列数据项

对于 02 - 邮件分类器 HITL 审查 处理过程，你应该有如下内容：

图 11.5：处理 2 的队列数据项

对于 03 - 实体识别 处理过程，你应该有如下内容：

图 11.6：处理 3 的三个队列数据项

对于04 - 实体识别 HITL 审查过程，你应该有如下内容：

图 11.7：过程 4 的两个队列数据项

确保保存过程，以免丢失更改。接下来，让我们将缺少的机器学习逻辑页面添加到01 - 处理退款过程中，因为我们需要调用一些模板中不存在的额外机器学习预测。

将缺少的机器学习页面添加到 01 - 处理退款

我们首先通过克隆IA 模板 3开始了这个示例。该模板没有让过程 1 直接进行任何机器学习预测。然而，我们的解决方案需要过程 1 直接使用 EC 和 GAI 模型进行预测。我们的解决方案还需要随机采样 EC 模型。最后，我们还需要将数据推入两个队列而不是一个。让我们通过克隆其他模板中的现有页面来将这些更改添加到过程 1 中：

1. 在过程工作室中打开03 - 实体识别过程。

2. 右键单击01 机器学习预测页面标签并选择复制。

图 11.8：在过程 3 中右键单击 01 机器学习预测页面并选择复制

1. 在过程工作室中打开01 - 处理退款过程。

2. 右键单击主页面标签并选择粘贴。

图 11.9：在过程 1 中右键单击主页面并选择粘贴

1. 将新粘贴的页面重命名为02a 电子邮件 分类器预测。

2. 右键单击主页面标签并再次选择粘贴。

3. 将新粘贴的页面重命名为05 生成式 AI 预测。

4. 在过程工作室中切换回03 - 实体识别过程。

5. 右键单击02 随机采样页面标签并选择复制。

6. 在过程工作室中切换回01 - 处理退款过程。

7. 右键单击主页面标签并选择粘贴。

8. 将新粘贴的页面重命名为02b 随机采样。

9. 将02 推送到队列页面重命名为02d 推送到 队列 3。

10. 右键单击02d 推送到队列 3页面标签并选择复制。

11. 右键单击主页面标签并选择粘贴。

12. 将新粘贴的页面重命名为02c 推送到 队列 2。

13. 修改主页面上的工作块，使其看起来如下。块中的添加内容以粗体显示。

图 11.10：将新页面添加到过程 01 - 处理退款的工作块中

现在，过程 1 的主页面为完成解决方案的机器学习部分所需的高级步骤提供了占位符页面。我们的下一个任务将是更改IA 数据页面上的数据项。

修改每个模板的 IA 数据页面

请记住，我们模板中的每个流程都有一个名为IA Data的页面，其中包含用于协调不同工作队列中项目数据列创建的数据项。还有一些包含状态和标签的数据项，用于控制工作队列项目在不同流程中的流动。这些页面上的数据项需要更改以适应解决方案结构。

流程 1，01 - 处理退款，在这个页面上有最多的数据项（17 个），因为它的项目数据需要存储有关所有三个 ML 模型的信息。

数据 项名称	数据 项值	目的
预测项目数据字段名称 - EC	预测 - EC	存储 EC 模型预测结果的项目数据字段名称
置信度项目数据字段名称 - EC	置信度 - EC	存储 EC 模型置信分数的项目数据字段名称
预测项目数据字段名称 - ER	预测 - ER	存储 ER 模型预测结果的项目数据字段名称
审查预测项目数据字段名称 - ER	审查预测 - ER	存储 ER 模型审查值的项数据字段名称
预测项目数据字段名称 - GAI	预测 - GAI	存储 GAI 模型预测结果的项目数据字段名称
置信度项目数据字段名称 - GAI	置信度 - GAI	存储 GAI 预测置信分数的项数据字段名称
队列 1 项目 ID 项数据字段名称	队列 1 项目 ID	用于在其他队列中存储工作队列 1 的项目 ID 的项数据字段名称
队列 2 项目 ID 项数据字段名称	队列 2 项目 ID	用于在此队列中存储工作队列 2（EC）的项目 ID 的项数据字段名称
队列 3 项目 ID 项数据字段名称	队列 3 项目 ID	用于在此队列中存储工作队列 3（ER）的项目 ID 的项数据字段名称
预测完成状态 - EC	预测完成 - EC	该状态用于指示 EC 预测已完成
预测完成状态 - GAI	预测完成 - GAI	该状态用于指示 GAI 预测已完成
手动审查无需状态 - ER	手动审查无需 - ER	该状态用于指示 ER 预测不需要 HITL 审查
手动审查完成状态 - ER	手动审查完成 - ER	该状态用于指示 ER 预测的 HITL 审查已完成
等待机器学习预测标签 - ER	等待机器学习预测 - ER	该标签用于显示项目正在等待 ER 模型预测
手动审查所需标签 - ER	手动审查所需 - ER	该标签用于显示项目正在等待 HITL 审查 ER 预测
抛出异常审查文本 - ER	BE	这是 ER 模型的审查员如何向流程 1 指示应抛出业务异常的方式
强制 HITL 审查 – EC	False	这是一个会话变量，用于控制我们是否希望强制所有 EC 预测进行审查

表 11.3：IA 数据页面上用于流程 1 所需的 17 个数据项

流程 2（IA 数据页面比流程 1 少得多）。

数据 项名称	数据 项值	目的
审查预测项数据字段名称 - EC	审查预测 - EC	存储人工修正的 EC 预测值的项数据字段名称
审查理由项数据字段名称 - EC	审查理由 - EC	存储预测值被修改原因的项数据字段名称
审查数据已创建项数据字段名称 - EC	审查数据已创建 - EC	此项数据字段名称存储审查数据记录是否已创建
手动审查完成状态 - EC	手动审查完成 - EC	用于指示 EC 预测的 HITL 审查已完成的状况
禁用 HITL 审查 - EC	False	这是一个会话变量，可以用来禁用 EC 模型的全部 HITL 审查
强制创建审查数据 - EC	False	这是一个会话变量，可以用来强制重新创建所有审查记录

表 11.4：IA 数据页面上用于流程 2 所需的 6 个数据项

流程 3（03 - 实体识别）需要与流程 1（01 - 处理退款）和流程 4（04 - 实体识别 HITL 审查）进行通信。因此，需要创建 11 个数据项：

数据 项名称	数据 项值	目的
预测项数据字段名称 - ER	预测 - ER	存储 ER 模型预测结果的项数据字段名称
置信度项数据字段名称 - ER	置信度 - ER	存储 ER 模型预测置信度分数的项数据字段名称
队列 1 项 ID 项数据字段名称	队列 1 项 ID	用于在其他队列中存储工作队列 1 的项 ID 的项数据字段名称
队列 3 项 ID 项数据字段名称	队列 3 项 ID	用于在此队列中存储工作队列 3（ER）的项 ID 的项数据字段名称
队列 4 项 ID 项数据字段名称	队列 4 项 ID	用于在此队列中存储工作队列 4（GAI）的项 ID 的项数据字段名称
预测完成状态 - ER	预测完成 - ER	用于指示 ER 预测已完成的状况
手动审查所需标签 - ER	手动审查所需 - ER	用于显示项正在等待 ER 预测的 HITL 审查的标签
不需要手动审查状态 - ER	不需要手动审查 - ER	用于指示 ER 预测不需要 HITL 审查的状况
等待 ML 预测标签 - ER	等待 ML 预测 - ER	用于显示项正在等待 ER 模型预测的标签
手动审查所需标签 - ER	手动审查所需 - ER	用于显示项目正在等待 HITL 审查 ER 预测的标签
强制 HITL 审查 - ER	False	这是一个会话变量，用于控制我们是否希望强制所有 ER 预测进行审查

表 11.5：IA 数据页面流程 3 所需的 11 个数据项

流程 4（04 - 实体识别 HITL 审查）有八个数据项需要创建：

数据 项名称	数据 项值	目的
已审查预测项数据字段名称 - ER	已审查预测 - ER	存储 ER 模型审查值的项数据字段名称
审查理由项目数据字段名称 - ER	审查理由 - ER	存储预测值修改原因的项目数据字段名称
审查数据创建项目数据字段名称 - ER	审查数据创建 - ER	该项目数据字段名称存储审查数据记录是否已创建
队列 1 项目 ID 项目数据字段名称	队列 1 项目 ID	用于在其他队列中存储工作队列 1 的项目 ID 的项目数据字段名称
手动审查完成状态 - ER	手动审查完成 - ER	用于表示 HITL 审查 ER 预测已完成的状态
手动审查所需标签 - ER	手动审查所需 - ER	用于显示项目正在等待 HITL 审查 ER 预测的标签
禁用 HITL 审查 - ER	False	这是一个会话变量，可以用来禁用 ER 模型的全部 HITL 审查
强制创建审查数据 - ER	False	这是一个会话变量，可以用来强制重新创建所有审查记录

表 11.6：IA 数据页面流程 4 所需的 8 个数据项

现在让我们根据上面的表格对IA 数据页面进行更改。

1. 在流程工作室中打开01 - 处理退款流程。

2. 删除IA 数据页面上的所有数据项。

3. 根据表 11.3 在此页面上创建新的数据项。所有数据项都需要是全局的，数据类型为Text。唯一的例外是会话变量，它们也需要是全局的，但数据类型为Flag，曝光设置为会话。

4. 重复步骤 1 到 3，除了其他流程。流程 2 应根据表 11.4创建数据项，流程 3 应使用表 11.5，流程 4 应使用表 11.6。

在重新创建IA 数据页面上的数据项后，我们将有许多指向先前数据项的断开引用。我们将在下一步修复这些问题。

修复 IA 数据页面在流程 1 中的引用和逻辑。

记住，流程 1 应该包含主要业务逻辑，执行 EC 预测，并执行 GAI 预测。虽然我们可以通过流程工作室，点击错误按钮，并找到每个错误来修复损坏的数据项引用，但我们可以通过将流程导出为 XML，并进行查找/替换来加快我们的工作。然后我们将重新导入流程，并手动修复剩余的问题。让我们从流程 1 所需的更改开始：

1. 在流程工作室中打开01 - 处理退款流程。

2. 点击文件 | 导出 | 此流程。将.bpprocess文件保存到您选择的文件夹。关闭流程工作室。

3. 在文本编辑器中打开.bpprocess文件，例如记事本。

4. 在您的文本编辑器中执行以下七个查找/替换。保存.``bpprocess文件：

查找文本	替换文本
[手动审查完成状态]	[手动审查完成状态 - ER]
[无需手动审查状态]	[无需手动审查状态 - ER]
[手动审查所需标签]	[手动审查所需标签 - ER]
[等待 ML 预测标签]	[等待 ML 预测标签 - ER]
[抛出异常审查文本]	[抛出异常审查文本 - ER]
[强制 HITL 审查]	[强制 HITL 审查 - EC]
[已审查预测项数据字段名称]	[已审查预测项数据字段名称 - ER]

表 11.7 – 流程 1 的七个查找/替换

5. 返回主 BP 软件。点击文件 | 导入 | 流程/对象。选择刚刚保存的.bpprocess文件，并覆盖现有流程。

6. 在流程工作室中打开01 - 处理退款流程。

7. 打开02a 电子邮件分类器预测页面。在这个页面上，我们需要重命名三个动作阶段的输入。

8. 打开[将[置信度分数]添加到[项目数据]]动作的属性。更改字段名称输入[置信度项目数据字段名称 - EC]。

9. 打开[将[预测]添加到[项目数据]]动作的属性。更改字段名称输入[预测项目数据字段名称 - EC]。

10. 打开[将状态设置为"预测完成"]动作的属性。更改状态输入[预测完成状态 - EC]。

11. 打开02b 随机抽样页面。在这个页面上，我们将删除四个阶段并添加一个新的页面阶段。

12. 删除需要手动审查？和结束之间的四个阶段。这些阶段是不必要的，因为我们不需要等待 EC 预测被审查才能继续自动化处理。

13. 创建一个新的页面引用到02c Push to Queue 2。将决策阶段的是路径连接到这个页面阶段，并将页面阶段连接到结束。这创建了一个逻辑，随机抽样的预测被推入一个新的队列进行审查。

14. 将否路径直接连接到结束。

15. 打开02c Push to Queue 2页面。在这个页面上，我们将删除一个动作阶段。

16. 删除添加标签“等待 ML 预测”动作。将添加到 Queue 2动作连接到将“Queue 2 Item ID”添加到[Item **Data]****动作。

17. 打开02d Push to Queue 3页面。在这里，我们需要重命名一个集合，并相应地更改此页面上使用此重命名集合的每个其他动作阶段。我们还需要更改正在使用的项目数据字段名称。

18. 将集合从Queue 2 Item Data重命名为Queue 3 Item Data。

19. 打开实用工具 - 集合操作：复制行动作的属性。将输出集合输出更改为Queue 3 Item Data。

20. 打开将“Queue 1 Item ID”添加到[Queue 2 Item Data]动作的属性。将其重命名为将“Queue 1 Item ID”添加到[Queue 3 Item Data]。将集合输入更改为[Queue 3 Item Data]，并将附加集合输出更改为Queue 3 Item Data。

21. 打开添加到 Queue 2动作的属性。将其重命名为添加到 Queue 3。将队列名称输入更改为[Queue Name 3]，并将数据输入更改为[Queue 3 Item Data]。

22. 打开将“Queue 2 Item ID”添加到[Item Data]动作的属性。将其重命名为将“Queue 3 Item ID”添加到[Item Data]。将字段名称输入更改为[Queue 3 Item ID Item Data 字段名称]。

23. 打开04 使用 ML 预测的工作步骤页面。在此页面上，我们需要更改对[Prediction Item Data Field Name - **ER]****的引用。

24. 打开将[Prediction]设置为原始预测动作的属性。将字段名称输入更改为[Prediction Item Data Field Name - ER]。

25. 打开05 生成式 AI 预测页面。在这里，我们需要更改对 GAI 项目数据集合字段和状态的引用。

26. 打开将[Confidence Score]添加到[Item Data]动作的属性。将字段名称输入更改为[Confidence Item Data Field name - GAI]。

27. 打开将[Prediction]添加到[Item Data]动作的属性。将字段名称输入更改为[Prediction Item Data Field name - GAI]。

28. 打开将[Status]设置为“Prediction Complete”动作的属性。将状态输入更改为[Prediction Complete Status - GAI]。

我们已经完成了流程 1 的修改。让我们继续处理流程 2。

修复流程 2 的 IA 数据页面引用并删除不需要的逻辑

流程 2 包含 EC 模型的 HITL 审查检查逻辑。再次，我们将使用查找/替换方法来加快我们的工作：

1. 在流程工作室中打开02 – 电子邮件分类器 HITL 审查流程。

2. 点击文件 | 导出 | 此流程。将.bpprocess文件保存到您选择的位置。关闭流程工作室。

3. 在文本编辑器中打开.bpprocess文件，例如记事本。

4. 在您的文本编辑器中执行以下六个查找/替换操作。保存.bpprocess文件。

查找文本	替换文本
[禁用 HITL 审查]	[禁用 HITL 审查 - EC]
[强制创建审查数据]	[强制创建审查数据 - EC]
[已审查预测项目数据字段名称]	[已审查预测项目数据字段名称 - EC]
[审查理由项目数据字段名称]	[审查理由项目数据字段名称 - EC]
[审查数据创建项目数据字段名称]	[审查数据创建项目数据字段名称 - EC]
[手动审查完成状态]	[手动审查完成状态 - EC]

表 11.8 – 流程 2 的六个查找/替换

5. 返回主 BP 软件。点击 文件 | 导入 | 过程/对象。选择刚刚保存的 .bpprocess 文件并覆盖现有过程。

6. 打开 02 检查已审查预测 页面。在这里，我们需要删除用于更新工作队列 1 项目的工作队列项的逻辑，因为那不再需要了。

7. 将 审查完成？ 决策阶段的 否 路径直接连接到 结束 阶段。

8. 删除以下图中显示的所有阶段，因为它们与更新工作队列 1 的项目相关。根据设计，当审查完成时不需要更新流程 1。

图 11.11：从页面 02 检查已审查预测的删除阶段

9. 将 设置[项目数据] 下的锚点直接连接到操作 更新状态为“手动 审查完成”。

我们现在已经完成了对流程 2 的更改。让我们继续处理流程 3。

修复流程 3 的 IA 数据页面引用和逻辑

流程 3 执行 ER 模型的 ML 步骤。让我们修复此流程的项目数据引用。我们再次以 .bpprocess 格式导出流程，并在文本上执行查找/替换以加快我们的工作：

1. 在流程工作室中打开流程 03 – 实体识别。

2. 点击 文件 | 导出 | 此过程。将 .bpprocess 文件保存到您选择的位置。关闭流程工作室。

3. 在文本编辑器中打开 .bpprocess 文件，例如记事本。

4. 在您的文本编辑器中执行以下八个查找/替换。保存 .bpprocess 文件。

查找文本	替换文本
[强制 HITL 审查]	[强制 HITL 审查 - ER]
[预测项目数据字段名称]	[预测项目数据字段名称 - ER]
[置信度项目数据字段名称]	[置信度项目数据字段名称 - ER]
[预测完成状态]	[预测完成状态 - ER]
[手动审查所需状态]	[手动审查所需状态 - ER]
[手动审查不需要状态]	[手动审查不需要状态 - ER]
[等待机器学习预测标签]	[等待机器学习预测标签 - ER]
[手动审查所需标签]	[手动审查所需标签 - ER]

表 11.9 – 流程 3 的八个查找/替换

5. 返回主 BP 软件。点击 文件 | 导入 | 过程/对象。选择刚刚保存的 .bpprocess 文件并覆盖现有过程。

6. 在流程工作室中打开 03 – 实体识别 流程。

7. 打开02 阈值页面。在这个页面上，我们将用占位符计算阶段替换智能自动化::通过标签获取阈值操作。

8. 将实用工具 – 智能自动化::通过标签获取阈值操作替换为名为实现阈值逻辑的计算阶段。将表达式设置为0.8，并将存储结果在设置为阈值值。这将作为实际阈值逻辑的占位符。

9. 打开03b 推送到队列 3 并更新队列 1 项页面。将此页面重命名为03b 推送到队列 4 并更新队列 1 项。在这里，我们需要重命名一个集合，并相应地更改此页面上所有其他操作阶段以使用此重命名的集合。

10. 将队列 3 项数据集合重命名为队列 4 项数据。

11. 打开实用工具 - 集合操作：复制行操作的属性。将输出集合输出更改为队列 4 项数据。

12. 打开将"队列 2 项 ID"附加到[队列 3 项数据]操作的属性。将其重命名为将"队列 3 项 ID"附加到[队列 4 数据]。将集合输入更改为[队列 4 数据]。将字段名称输入更改为[队列 3 项 ID 项数据字段名称]。将附加集合输出更改为队列 4 项数据。

13. 打开添加到队列 3操作的属性。将其重命名为添加到队列 4。将队列名称输入更改为[队列名称 4]，并将数据输入更改为[队列 4 项数据]。

14. 打开添加队列 3 项 ID 到[队列 1 项数据]操作的属性。将其重命名为添加队列 4 项 ID 到[队列 1 项数据]。将字段名称输入更改为[队列 4 项 ID 项数据 字段名称]。

最后，让我们进行流程 4 所需的引用更改。

修复流程 4 的 IA 数据页面引用

流程 4 执行 ER 模型的 HITL 审查步骤。让我们修复此流程的项数据引用。我们只需要执行查找/替换，不需要对流程逻辑进行其他更改：

1. 在流程工作室中打开04 – 实体识别 HITL 审查流程。

2. 点击文件 | 导出 | 此流程。将.bpprocess文件保存到您选择的位置。关闭流程工作室。

3. 在文本编辑器中打开.bpprocess文件，例如记事本。

4. 在您的文本编辑器中执行以下七个查找/替换操作。保存.bpprocess文件。

查找文本	替换文本
[禁用 HITL 审查]	[禁用 HITL 审查 - ER]
[强制创建审查数据]	[强制创建审查数据 - ER]
[已审查预测项数据字段名称]	[已审查预测项数据字段名称 - ER]
[审查理由项数据字段名称]	[审查理由项数据字段名称 - ER]
[创建的审查数据项数据字段名称]	[创建的审查数据项数据字段名称 - ER]
[人工审查完成状态]	[人工审查完成状态 - ER]
[需要人工审查的标签]	[需要人工审查的标签 - ER]

表 11.10 – 流程 4 的七个查找/替换

5. 返回主 BP 软件。点击 文件 | 导入 | 流程/对象。选择刚刚保存的 .bpprocess 文件并覆盖现有流程。

我们已经完成了图 11**.1中所示解决方案结构的创建。模型解决方案可以在 GitHub 上找到：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch11/Ex_1_Creating_the_Solution_Structure.bprelease。对模板所做的更改在流程图中以橙色字体突出显示。流程 1 还将三个项目加载到工作队列 1 中，以方便测试解决方案流程。如果您愿意，发布四个流程并在流程工作室中运行模型解决方案以确认解决方案流程与设计匹配。

现在我们已经建立了解决方案的结构，让我们添加一些我们已知的流程 1 的 IA 详细信息。

示例 2 – 在流程 1 中实现 IA 详细信息

在验证解决方案结构正常工作后，我们决定进一步进行 IA 实现。由于 EC 模型是内部开发的，我们目前还没有可用的测试 API。

与业务用户和机器学习团队的先前讨论导致在审查标准和审计方面做出了一些决定。这些决定在表 11.1中有所体现。其中一些机器学习需求可以在最终确定模型之前实现。在这个例子中，我们将通过八个高级步骤来实现这些细节：

1. 导入模型解决方案作为起点（可选）。

2. 添加一个模拟 EC 预测。

3. 删除 EC 预测 BP 记录。

4. 创建一个 EC 模型关闭开关。

5. 将 EC 预测的随机采样率更改为 5%。

6. 添加一个模拟 GAI 预测。

7. 删除 GAI 预测 BP 记录。

8. 创建一个 GAI 模型关闭开关。

下载并导入解决方案结构

如果您尚未完成示例 1，这是一个可选步骤。从(github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch11/Ex_1_Creating_the_Solution_Structure.bprelease)下载发布版本并将其导入 BP。验证它包含四个流程、四个工作队列和一个凭证。

图 11.12 – 开始示例 2 的发布内容

添加一个模拟 EC 预测

EC 预测 API 尚未最终确定，但我们仍想根据预测是退款还是非退款来测试流程的不同分支。我们知道大约 70/500 = 14%的每日收到的电子邮件将是实际的退款请求，所以让我们使用随机数生成器创建假预测，将预测设置为退款 14%的时间：

1. 在流程工作室中打开01 – 处理退款流程。

2. 打开02a 电子邮件分类器预测页面，找到名为预测的橙色块。

3. 删除占位符注意。

4. 创建一个名为退款百分比的Number数据项。将初始值设置为14。

5. 创建一个名为随机值的Number数据项。

6. 创建一个名为预测值的Text数据项。将初始值设置为非退款。

7. 添加一个实用工具 – 智能自动化::在范围内随机整数动作。将下限输入设置为1，将上限输入设置为100。将输出值设置为随机值。从日志[模型版本]计算阶段链接到它。

8. 在上一步的操作下添加一个名为退款？的决策阶段。将表达式设置为[随机值] <= [退款百分比]。从动作阶段链接到这个阶段。

9. 添加一个名为设置预测值到退款的计算阶段。将表达式设置为"退款"，将存储结果在设置为预测值。将退款？决策阶段的是路径链接到这个阶段。将这个阶段链接到设置[预测]和[置信度分数]多计算阶段。

10. 将退款？决策阶段的否路径链接到设置[预测]和[置信度分数]多计算阶段。

11. 打开设置[预测]和[置信度分数]多计算阶段。将第一行的表达式更改为[****预测值]。

12. 确认你的图表看起来如下：

图 11.13 – 创建模拟 EC 预测

现在我们有了 EC 模拟预测，让我们删除模型版本日志。

删除 EC 模型日志

记住，EC 模型调用将在 API 服务器端进行日志记录。我们不需要从 BP 进行日志记录。关闭日志记录将减少数据库中存储的数据量。

1. 删除日志[模型版本]计算阶段。将删除此阶段之前和之后的阶段链接起来以填补空白。确保将前一个决策阶段的否路径链接起来。

2. 打开设置[预测]和[置信度分数]多计算阶段。将阶段日志设置为仅错误。

3. 删除temp和模型版本数据项。

当我们仍在02a 电子邮件分类器预测页面时，我们也应该为这个模型创建一个独特的关闭开关。

为 EC 预测创建一个独特的关闭开关

模板中的关闭开关是一个占位符。让我们通过创建凭证和环境变量并编辑关闭开关逻辑来替换一个真实的：

1. 访问 系统 | 安全 | 凭证。

2. 点击 新建 并将名称设置为 Ch11 EC Kill Switch。

3. 点击 访问权限 选项卡。在 安全角色 下选择 所有角色。在 流程（旧版） 下选择 所有流程。在 资源（旧版） 下选择 所有资源。这并不是最佳实践，只是为了方便演示。

4. 访问 系统 | 流程 | 环境变量。

5. 点击 添加变量。将其命名为 Text 并将值设置为 Ch11 EC Kill Switch。

6. 返回到流程工作室的 02a 电子邮件分类器 预测 页面。

7. 将 Kill Switch 凭证名称 数据项曝光设置为 环境。将名称设置为 Ch11 Example 2 EC Kill Switch Name。

8. 打开 获取 Kill Switch 凭证 动作的属性。将 凭证名称 输入更改为 [Ch11 Example 2 EC Kill Switch Name]。

我们已经完成了 EC 模型的 kill switch 创建。接下来，让我们根据要求设置 EC 模型的随机采样率。

将 EC 采样率更改为 5%

要更改随机采样率，我们将创建一个 Number 环境变量并将其设置为 5。然后我们将更改图表以使用此环境变量：

1. 访问 系统 | 流程 | 环境变量。

2. 点击 添加变量。将其命名为 Number 并将值设置为 5.0。

3. 返回到流程工作室的 01 – 处理退款。

4. 打开 02b 随机 采样 页面。

5. 将 随机采样率 数据项的曝光设置为 环境。选择 Ch11 Example 2 EC Random Sampling Target 作为 名称。

6. 将 需要手动审核？ 决策阶段的表达式更改为 [强制 HITL 审核 - EC] OR [随机数] < [Ch11 Example 2 EC Random 采样目标]。

我们已经完成了 EC 模型的一些要求。接下来，让我们转向 GAI 模型，并创建一个模拟的 GAI 预测调用。

添加一个模拟的 GAI 预测

当 GAI 模型可以调用时，这样做会产生成本。我们仍然想要一个模拟的 GAI 调用，并保存实际调用直到以后。为此，我们将简单地硬编码一个电子邮件文本消息作为 GAI 预测的结果：

1. 打开 05 生成式 AI 预测 页面并找到名为 预测 的橙色块。

2. 删除占位符 注意。

3. 创建一个名为 GAI 电子邮件 的 Text 数据项。

4. 创建一个名为 设置 GAI 电子邮件 的计算阶段。将 表达式 设置为 "您的退款请求已自动处理"。将 存储结果在 设置为 GAI 电子邮件。

5. 打开 设置 [预测] 和 [置信度分数] 多计算阶段。将第一行的表达式更改为 [****GAI Email]。

6. 将计算阶段 Log [模型版本] 连接到计算阶段 设置 GAI 电子邮件 和多计算阶段 设置 [预测] 和 [**置信度分数]。

移除 GAI 模型日志

记住，GAI 模型结果不需要记录。输入提示是静态的，输出电子邮件在 CRM 系统中记录。虽然返回了模型版本号，但我们实际上对模型回滚没有控制权，因为它是一个第三方服务。关闭记录将减少数据库中存储的数据量：

1. 删除 日志 [模型版本] 计算阶段。将此删除阶段之前和之后的阶段链接起来以填补空白。确保您链接了之前决策阶段的 无 路径。

2. 打开 设置 [预测] 和 [置信度分数] 多计算阶段。将 阶段日志记录 设置为 仅错误。

3. 删除 temp 和 模型版本 数据项。

为 GAI 预测创建一个独特的断开开关

模板中的断开开关是一个占位符。让我们通过创建凭证和环境变量并编辑断开开关逻辑来放置一个真实的断开开关：

1. 访问 系统 | 安全 | 凭证。

2. 点击 新建 并将名称设置为 Ch11 GAI 断开开关。

3. 点击 访问权限 选项卡。在 安全角色 下选择 所有角色。在 流程（旧版） 下选择 所有流程。在 资源（旧版） 下选择 所有资源。这不是最佳实践，只是为了方便演示。

4. 访问 系统 | 流程 | 环境变量。

5. 点击 添加变量。将其命名为 Text 并将值设置为 Ch11 GAI 断开开关。

6. 返回到流程工作室，到 05 生成式 AI 预测 页面。

7. 将 断开开关凭证名称 数据项曝光设置为 环境。将名称设置为 Ch11 Example 2 GAI 断 开开关名称。

8. 打开 获取断开开关凭证 动作的属性。将 凭证名称 输入更改为 [Ch11 Example 2 GAI 断 开开关名称]。

我们完成了第二个示例。在这里，我们为 EC 和 GAI 模型实施了一些模拟预测。我们还满足了审计和随机抽样的要求。虽然我们可以继续修改其他流程，但程序基本上是相同的。继续进一步开发需要深入了解对象和业务逻辑细节。

摘要

在本章中，我们讨论了一个实际用例的要求，该用例使用了三种不同的机器学习模型。我们单独分析了每个机器学习模型的要求，这让我们了解了它们的审计和扩展需求。这有助于我们确定在 IA 解决方案中使用适当数量的流程和工作队列。

我们通过一个示例来实现解决方案结构。我们从三个流程和三个工作队列模板开始，并使用每个模板的 IA 数据 页面来明确定义在解决方案中将使用哪些项目数据字段名称、状态、标签和会话变量。最后，我们编辑 IA 解决方案逻辑以利用这些新的数据项。

这个例子将帮助你构建关于如何设计复杂的 IA 解决方案的思考，如何考虑机器学习需求，以及如何选择合适的模板来帮助你开始。请记住，如果你遇到这本书中的模板没有涵盖的情况，你应该创建自己的模板。

然后，我们看到了第二个例子，其中我们为两个机器学习模型实现了简单的模拟预测。创建模拟预测很重要，因为它允许你从调用商业 API 中节省成本，并且它防止你在继续前进之前等待机器学习模型构建完成。机器学习模型几乎总是与 IA 并行构建，模拟允许你在模型尚未准备好之前测试整个流程。

在下一章中，我们将探讨另一个现实生活中的 IA 场景，但我们将从开发和设计转向，而是专注于 IA 解决方案的持续管理和部署方面。

第十二章：电力服务中断

在本章中，我们将再次查看一个基于真实用例的场景。本章中的示例将重点关注对持续 IA 解决方案操作重要的事后维护和机器学习模型部署活动。本章的目标是熟悉模型部署、回滚和通过 SQL 导出审计数据。

在这个场景中，我们是一家拥有现有机器学习模型并已投入生产的电力公司。该模型根据天气指标、日期和时间指标、当前电力基础设施的测量值和历史数据，预测电力网格的某些区域是否会发生停电。

IA 团队希望使用这个现有模型并构建一个新的模型用于新的自动化。首先，停电机器学习模型将定期调用以预测人口密集区域是否会发生停电。如果检测到潜在的停电，我们希望预测哪些客户最有可能拨打客户服务热线。客户投诉预测模型将作为本项目的部分开发。

一旦我们预测出哪些客户可能会拨打客户服务电话，我们将提前通过短信通知他们可能发生的停电情况。这个 IA 项目的目标是减少客户服务电话的数量，从而节省资金，减少电话排队等待时间，并提高客户满意度。建立这个新模型和自动化的提案已经得到了治理委员会的批准。

停电预测模型由一个独立的内部机器学习团队维护。决定在 IA 功能内部开发和维护客户投诉预测模型，因为必要的专业知识已经存在。

在本章中，我们将介绍以下主题：

• 机器学习模型背景信息

• 解决方案设计

• 处理模型部署

• 导出数据以供审计

技术要求

安装 SQL Server Management Studio aka.ms/ssmsfullsetup 以便您可以对 BP 数据库执行查询。SQL Server Management Studio 在示例 4和示例 5中使用。

机器学习模型背景信息

让我们分析两个机器学习模型（停电预测和客户投诉）的需求和特征。这些信息将帮助我们了解部署和回滚模型所需的程序。它还将帮助我们确定我们有哪些选项来捕获机器学习审计数据。

停电预测模型

停电预测（OP）模型已经在其他地方得到了应用，并由不同的内部团队管理。我们已经获得了使用他们机器学习端点进行 IA 解决方案的必要批准。

消费和部署方法

模型托管在内网中，并通过 HTTP API 调用。由于这是一个预存在的模型，部署方法已经确定。使用需要停机的替换部署方法。ML 团队将在模型维护时下线时通知我们。对于模型更新，API 端点将被覆盖，这意味着只能调用模型的最新版本。这意味着通过更改端点 URL 来回滚是不可能的。

预测量

在与项目利益相关者讨论后，我们决定将自动化重点放在四个区域。这将在项目的进一步阶段中扩展。我们决定每个区域的预测间隔为 30 分钟，从早上 6:00 到晚上 10:00。在这个时间范围之外向客户发送短信将不会有效。这总计每天对 API 的 112 次调用，这对 ML 团队来说是可接受的量。

HITL 审查、界面和 SLA

由于专家之外的人无法审查预测，因此决定不需要审查。也没有 SLA 需要满足，因为这不是一个已经存在（也不是关键）的过程。目前，如果可能发生故障，客户不会被提前通知。然而，我们已经设定了一个目标，在从 OP 模型收到潜在故障预测后的 30 分钟内通知客户。

ML 审计

虽然可以从 ML 团队请求服务器日志，但收到它们的提前期是未定义的，因为他们没有现有的程序或 SLA。因此，IA 团队决定在 BP 中保留对模型的 API 调用的副本。由于他们为公共服务工作，IA 团队意识到需要维护他们 ML 调用的审计跟踪。

我们已经收集了与 IA 解决方案相关的 OP 模型的相关信息。让我们接下来看看客户投诉模型。

客户投诉模型

客户投诉（CC）模型根据人口统计信息、账单数据、一天中的时间、过去的通话行为等预测客户是否可能拨打客户支持热线。该模型将由 IA 团队开发和维护。团队决定构建一个二元分类模型，使用回归或基于树的技巧来预测客户是会拨打还是不会拨打。这些技巧受到青睐，因为它们具有固有的某种程度可解释性。

消耗和部署方法

IA 团队决定将 CC ML 解决方案作为原生代码阶段部署，它将直接在数字工作者本身上运行。这将是由于所选算法的类型。

预测量

需要的预测数量取决于该地区住宅电表（客户）的数量。最大的地区大约有 10,000 名客户。假设从各个系统中收集模型输入数据并做出预测需要一分钟，那么在 30 分钟内处理 10,000 个预测将需要 334 名数字工作者，这是不可接受的。

为了将预测所需的时间降低到可管理的水平，IA 团队决定采用一个完全独立的 BP 流程来收集必要的数据输入。该流程将每周为目标区域内的每位客户生成预测。使用每周预测（而不是实时预测）被认为是一个合理的折衷方案，因为输入到模型中的客户数据并不经常改变。

每周的客户投诉预测结果将被保存到数据库中。如果预测到某个地区将出现故障，则保存的预测结果可以被发送短信的流程使用。

假设四个地区总共有 20,000 个住宅，每个地区处理需要一分钟。如果我们选择在非高峰时段（晚上 9:00 到早上 5:00）运行客户投诉预测流程，那么每周处理 20,000 个案例将需要 6 名数字工作者。在与业务用户讨论后，我们获得了在非高峰时段空闲的六名数字工作者上运行此 CC 预测的绿灯，从而提高了劳动力的整体利用率。

HITL 审查、界面和 SLA

由于没有人真正知道如何预测某人是否可能拨打热线电话，因此不需要对预测进行人工审查。尽管我们自行设定了每周更新客户预测的标准，但也没有 SLA 来完成任务预测。

ML 审计

需要进行审计。由于 ML 模型是从代码阶段运行的，因此日志必须保存到 BP 中。

我们已经完成了对两个 ML 模型的审查。让我们总结与 IA 解决方案相关的细节。这将告诉我们如何部署、回滚和检索 ML 日志以进行审计。

ML 模型总结

以下表格提供了与解决方案设计和操作相关的 ML 模型特性的总结：

模型	部署方法	HITL 审查标准	HITL 审查界面	HITL 审查 SLA	ML 审计
OP	替换 API	N/A	N/A	N/A	在 IA 解决方案中
CC	代码阶段	N/A	N/A	N/A	在 IA 解决方案中

表 12.1：ML 模型特性的总结

解决方案设计

由于两种 ML 模型都不可能进行审查，因此我们不需要考虑为审查设计单独的流程和工作队列。同样，由于两个 ML 模型是独立的，并且通过将客户投诉预测结果保存到数据库中通信，因此也不需要在两个 ML 模型之间链接工作队列项。

高级解决方案设计有两个主要候选方案。第一个潜在的设计如下所示图。在这个设计中，我们将解决方案的机器学习部分中的流程和工作队列分开。这导致了一个四流程、四个工作队列的设计。它允许独立扩展并对 ML 模型直接从 BP 用户界面进行针对性审计。这种第一个设计的缺点是需要大量的许可证和调度复杂性的增加。

图 12.1：潜在设计 1：将 ML 部分中的流程和工作队列分开

下一个潜在的设计是不将 ML 分成单独的流程和工作队列。以下截图展示了这种第二个设计的例子。使用这种设计，我们可能需要手动查询数据库以提取 ML 审计信息，或者将会话日志作为 CSV 导出并从那里过滤。

图 12.2：潜在设计 2：不要将 ML 部分中的流程和工作队列分开

让我们考虑需要单独扩展ML 预测的需求。对于 OP 模型，预测量很低，所以没有必要从主流程中独立扩展 ML。对于 CC 模型，瓶颈可能在于从各种 CRM、客户支持系统和计费系统中检索所有必要的输入数据。ML 部分只占总执行时间的很小一部分，并且客户与预测之间存在一对一的关系，因此没有必要单独扩展 CC 模型的预测。

接下来，让我们考虑可审计性需求。在这种情况下，没有必要对任何已审查的结果提供反馈，因为审查是不可能的。虽然客户支持团队可以通知 IA 团队是否有人在实际服务中断后打电话，但这是在 BP 之外发生的事情。

可能需要允许 IA 团队外部的人员访问会话日志以进行导出。从 BP 导出数据的替代方案是直接查询数据库。IA 团队预计不需要定期导出会话日志数据以进行 ML 审计，或检查特定会话或项目的 ML 日志，因此从 BP 用户界面执行导出操作的可能性很低。IA 团队决定通过 BP 数据库执行 ML 审计。选择的解决方案设计是图 12.2中更简单的一个。

处理模型部署

想象 IA 解决方案已经实施并已在生产中运行。我们收到来自 ML 团队的消息，表示由不同内部团队维护的 OP 模型将进行更新，并且将出现停机时间。回想一下，只有 OP 模型的一个版本是活跃的，并且不能调用以前的版本。让我们通过一个例子来看看在 OP 模型更新的那天，IA 团队需要做什么。

示例 1 – 故障预测模型部署

在此示例中，我们将通过部署 OP 模型的新版本到 BP 中所需的步骤。回想一下，OP 模型使用替换部署策略。此示例有七个高级步骤：

1. 导入.bprelease 样本（从同步审查模板创建）。

2. 运行流程一次以创建会话日志。

3. 退役计划。

4. 等待会话完成。

5. 更改存储模型版本的环境变量。

6. 恢复计划。

7. 使用新模型运行流程以创建会话日志。

导入发布版本

让我们导入基于图 12.2中设计开发的发布版本。

1. 从 GitHub 下载发布版本：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch12/Ex_1_Outage_Prediction_Model_Deployment.bprelease。

2. 将发布版本导入 BP。

3. 确保已导入两个流程、一个对象、两个工作队列、两个计划、三个环境变量和两个凭证。

图 12.3 – .bprelease 的内容

1. 访问 系统 | 安全 | 凭证。打开Ch12 OP 预测关闭开关凭证，并确保01 – 故障预测通知流程的访问权限已授予，以及正确的角色和资源。

2. 访问 系统 | 安全 | 凭证。打开Ch12 CC 预测关闭开关凭证，并确保02 – 客户投诉预测流程的访问权限已授予，以及正确的角色和资源。

导入后，我们需要运行流程一次以生成一些会话日志数据。

运行流程

从控制室执行流程一次以生成会话日志。虽然会话日志在此示例中不需要，但它们对于示例 4是必需的：

1. 从控制室运行01 – 故障预测通知流程一次。等待会话完成。

2. 打开 控制 | 队列管理 | Ch12 | 01 – 故障预测通知。查看已创建四个项目，每个项目代表四个区域之一。

接下来，让我们开始部署新的 OP ML 模型。第一步是退役运行 OP 模型预测流程的计划，即01 – 故障预测通知。

退役计划

在发布中导入了两个计划。我们只需要退役Ch12 停电预测通知计划，因为那是运行调用 OP 预测模型的进程的计划。

在控制 | 调度器下，右键单击Ch12 停电预测通知计划并选择退役。即使有会话仍在执行，也应该能够退役。

图 12.4：退役 Ch12 停电预测通知计划

在退役计划后，我们需要确保没有活跃的会话正在运行01 - 停电预测****通知进程。

等待会话停止

在这里我们可以做几件事情，这取决于在 ML 模型下线之前我们有多少时间。如果 ML 模型很快就要下线，我们可以触发 OP 模型的关闭开关。这将阻止在调用 ML 算法之前执行。如果主页上的选择阶段设计正确，我们可以重试因触发关闭开关而被标记为异常的工作队列项。重试后，执行应恢复到 ML 预测被调用之前的点。如果我们拥有的时间超过当前项完成预期的时长，我们可以在所有正在进行的会话上请求停止。最后，如果我们有很多时间，我们可以等待所有会话完成：

1. 在控制 | 会话管理下，选择01 – 停电预测通知作为进程过滤器。确保所有其他过滤器都设置为全部。

图 12.5 – 过滤会话管理以查看 01 – 停电预测通知进程

1. 等待直到所有会话都运行完成，请求停止会话，或触发Ch12 OP 预测关闭开关。应该使用哪一个将取决于一个工作队列项的预期执行时间以及模型下线前的剩余时间。

现在，让我们假设已经过去了一些时间，并且我们已经收到通知，ML 部署已完成。下一步是修改Ch12 OP 模型版本环境变量，并取消退役计划。

将环境变量更新为新 ML 模型版本

由于 OP 模型只有一个版本，我们需要手动跟踪其更新时间。在这种情况下，我们需要更新一个DateTime环境变量。一旦模型版本更新，我们可以允许计划恢复。在系统 | 进程 | 环境变量下，编辑Ch12 OP 模型版本环境变量的值，使其使用当前日期和时间。

取消退役计划

现在我们等待 ML 团队通知我们新模型已准备好使用。一旦我们收到通知，我们可以取消退休计划，以便再次开始处理。在Control | Retired Schedules下，右键单击Ch12 Outage Prediction Notification计划，并取消退休它。

使用新模型运行流程

再次从控制室运行01 – 停电预测通知流程。此步骤仅用于为未来的示例生成会话日志。

我们已经完成了将新版本的 OP 模型部署到我们的 IA 解决方案中所需的步骤，这需要停机。现在让我们看看我们如何部署使用代码阶段的 CC 模型的新版本。

示例 2 – 客户投诉模型部署

假设 CC ML 模型对象已更新，并且这次部署不需要任何新的 DLL。请注意，部署前的模型版本（1.5.3）可以在客户投诉 ML 模型对象的初始化页面作为数据项找到。此外，请注意，返回预测结果的操作也返回了模型版本。这意味着我们不需要使用环境变量来存储模型版本。

图 12.6：CC ML 对象操作返回模型版本。

此示例有三个高级步骤：

1. 运行02 – 客户投诉预测流程一次以创建会话日志。

2. 通过导入对象来部署新模型。

3. 再次运行流程以创建会话日志。

我们的第一步是运行现有的流程一次以生成一些会话日志数据。这些数据将在示例 5中使用。

运行流程

从控制室运行流程一次以生成会话日志。从控制室运行02 – 客户投诉预测流程一次。这将创建 20 个项目（客户），他们属于四个区域之一。接下来，我们需要下载对象并验证模型版本已更新。

下载、检查模型版本并导入对象

在这种情况下，更新的模型以.bpobject文件的形式提供。我们需要下载它并验证模型版本与之前的版本（1.5.3）不同：

1. 从 GitHub 下载对象：github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch12/Ex_2_BPA_Object_Customer_Complaints_ML_Model.bpobject。

2. 将下载的对象导入 BP。

3. 在Studio | Objects | Ch12下，在对象工作室中打开客户投诉 ML 模型对象。

4. 在初始化页面，验证开发人员已将模型版本数据项从之前的版本（1.5.3）更新。

图 12.7：验证模型版本数据项已从 1.5.3 更改

我们已确认模型版本已更改。由于这是一个代码阶段部署，没有新的 DLL 文件，我们只需要导入新的对象文件。在对象导入之前进行的会话仍将使用旧的对象定义和先前的模型版本。在对象导入之后开始的新会话将使用更新的对象和模型版本。

如果你想更安全，可以在将其导入 BP 之前检查模型版本是否已更新。如果文件是.bpobject文件，您可以在任何文本编辑器中打开它并搜索模型版本。如果文件是.bprelease文件，您也可以执行类似的搜索。

图 12.8：可以通过在记事本中打开.bpobject 文件来查看模型版本

最后，让我们再次运行流程，以生成带有更新模型版本的会话日志。

使用新的机器学习模型

从控制室再次执行流程。这些会话日志对于示例 5是必需的。从控制室再次运行02 – 客户投诉预测流程。

我们已经完成了部署基于代码阶段的模型所需的步骤，该模型不需要复制任何新的.dll文件。这很简单，只需导入新的对象文件。接下来，让我们看看回滚此机器学习模型部署所需的步骤。

示例 3 – 回滚客户投诉模型部署

假设我们发现新的 CC 模型存在问题。让我们通过回滚到上一个版本进行练习。此示例有三个高级步骤：

1. 激活终止开关（可选）。

2. 查找并导入对象的前一个版本。

3. 运行一次02 – 客户投诉预测流程以创建会话日志。

如果有正在进行的会话，我们可以考虑打开终止开关，以防止对 CC 机器学习模型的任何进一步调用。

激活客户投诉模型终止开关（可选）

如果模型问题至关重要，我们可以选择性地触发终止开关，这样就不会再使用 CC 模型进行进一步预测。我们可以通过使凭证无效来激活终止开关。

1. 访问系统 | 安全 | 凭证。双击Ch12 CC 预测终止****开关凭证。

2. 打勾选择标记为无效复选框并按确定。

由于会话现在无法再使用 CC 模型，我们可以开始回滚程序。首先，让我们获取上一个对象的副本。

获取并导入上一个对象。

获取对象旧版本的方法有很多。您可以从以前的版本中检索它，并且只重新导入对象。您也可能在共享位置或版本控制系统中有一个副本。如果您没有以前对象的可用副本，我们可以通过 BP 中的比较功能将其导出。

重要提示

BP 客户支持通常会向客户提供数据库维护脚本。其中一些脚本会在对象和流程的历史版本超过一定天数时从BPAAuditEvents表中删除。这可能会阻止您使用比较功能。请与您的数据库团队联系，以确定是否正在使用此维护脚本。

1. 在工作室 | 对象 | Ch12下，单击一次客户投诉 ML 模型对象。对象的版本历史将显示在右侧。

2. 按住Ctrl按钮并选择对象的两个最新版本。

图 12.9：选择对象的两个最新版本

1. 右键单击并选择比较。这会打开业务对象比较窗口。请注意，两个对象具有不同的模型版本。

图 12.10：打开对象比较窗口

1. 在业务对象 比较窗口中，单击文件 | 导出左侧。

图 12.11：导出对象的上一版本

1. 将导出的对象保存到您选择的位置。

2. 将保存的对象重新导入 BP 并覆盖最新版本。

接下来，让我们运行流程以生成使用旧模型的会话日志。

使用旧 ML 模型

从控制室再次执行流程。这些数据将在示例 5中使用。从控制室再次运行02 – 客户投诉预测流程。

我们已经完成了查看如何部署 OP 和 CC 模型新版本的示例。我们还通过一个示例了解了如何使用代码阶段回滚 CC 模型。接下来，让我们看看 IA 需要的下一个主要持续任务，即导出数据以供 ML 审计。

导出数据以供审计

根据解决方案设计，提取与 ML 相关日志的最简单方法是从会话日志数据库表直接查询。让我们通过一个示例来看看应该使用什么查询以及请求从数据库提取 ML 日志后我们应该期望看到什么。在生产环境中，预计这些步骤将由数据库管理员执行。

重要提示

下面的 SQL 查询假设您正在使用BPASessionLog_NonUnicode表来存储您的日志。如果您使用 Unicode 日志，请在查询中将该表替换为BPASessionLog_Unicode。

示例 4 – 通过 SQL 导出 OP 模型数据

在这个例子中，我们将通过 SQL Server Management Studio 查询每次调用 OP 模型 所使用的输入、输出和模型版本。这个例子依赖于完成 示例 1，在那里我们执行了 01 – Outage Prediction Notification 流程两次，一次在部署前，一次在部署后。

我们期望看到 四个 具有较旧 DateTime 模型版本的会话日志记录和 四个 具有较新 DateTime 模型版本的会话日志记录：

1. 打开 SQL Server Management Studio 并连接到您的 BP 数据库服务器。

2. 在对象资源管理器（以下图像中的 IA）中右键单击您的数据库。选择新建查询。一个空的查询编辑器窗口将出现。

图 12.12：打开一个新的查询窗口

1. 将以下查询复制并粘贴到编辑器窗口中，并执行它：SELECT * FROM (SELECT logid, stagename, LAG(result, 1, 0) OVER(ORDER BY logid) as modelversion, attributexml, startdatetime from BPASessionLog_NonUnicode WHERE stagename in ('Log [Model Version]', 'Set [Prediction] and [Confidence Score]') AND processname = '01 - Outage Prediction Notification') as tbl WHERE stagename = 'Set [Prediction] and [``Confidence Score]';.

2. 确认您的结果看起来与图 12.13中显示的结果相似。modelversion列显示了Ch12 OP 模型版本环境变量的值。注意，前四行的modelversion与最后四行不同。attributexml列显示了您想要存储在Set [Prediction] and [Confidence Score] 多计算阶段的模型的其他任何输入和输出参数的值。

图 12.13：提取审计用 ML 会话日志的查询结果

我们已经完成了导出会话日志，这些日志告诉我们 OP ML 模型的版本、输入和输出。我们使用的查询来自第九章，并且可以由使用第七章中的 IA 模板开发的任何流程使用，只需进行一些修改。我们在这里做的唯一改变是修改了流程的名称。

现在，假设我们还想导出使用对象和代码阶段调用的 CC 模型的 ML 审计日志。我们会看到步骤和查询几乎完全相同。

示例 5 – 通过 SQL 导出客户投诉模型数据

在这个例子中，我们将通过 SQL Server Management Studio 查询每次调用 CC 模型 所使用的输入、输出和模型版本。这个例子使用了从 示例 2 和 示例 3 生成的会话日志，所以请确保先阅读那些示例。

我们期望看到返回 60 行数据，其中每一行代表一个客户。前 20 行是在机器学习模型更新之前的数据，应该显示模型版本1.5.3。接下来的 20 行是在更新机器学习模型之后的数据，应该显示模型版本1.6.0。最后的 20 行是在回滚模型之后的数据，应该显示模型版本1.5.3：

1. 打开 SQL Server Management Studio 并连接到你的 BP 数据库服务器。

2. 在对象资源管理器中右键点击你的数据库。选择新建查询。一个空的查询编辑器窗口将出现。

3. 将以下查询复制粘贴到编辑器窗口中，并执行它：SELECT * FROM (SELECT logid, stagename, LAG(result, 1, 0) OVER(ORDER BY logid) as modelversion, attributexml, startdatetime from BPASessionLog_NonUnicode WHERE stagename in ('Log [Model Version]', 'Set [Prediction] and [Confidence Score]') AND processname = '02 - Customer Complaints Prediction') as tbl WHERE stagename = 'Set [Prediction] and [Confidence Score]';。这个查询与示例 4中的查询唯一的区别是流程的名称已更改。

4. 验证查询返回了 60 行数据，其中前 20 行具有modelversion 1.5.3，接下来的 20 行具有modelversion 1.6.0，最后的 20 行再次具有modelversion 1.5.3。

我们已经完成了 CC 模型的机器学习审计日志的导出。由于它使用 IA 模板，我们只需要在查询中更改流程的名称。

摘要

在本章中，我们通过一个基于场景的例子，介绍了一家电力公用事业公司使用了两种不同的机器学习模型。第一个模型预测电网故障，它的 API 由内部机器学习团队托管和维护。第二个模型预测客户是否会拨打客户支持热线，由 IA 团队开发和维护。这个客户投诉模型通过代码阶段部署。通过分析两个机器学习模型的特点和需求，我们提出了一个解决方案设计，该设计没有将机器学习分割成单独的流程和工作队列。

接下来，我们专注于 IA 所需的两个关键任务。这些任务是部署新的机器学习模型和提取用于审计目的的机器学习特定数据。我们通过部署 OP 和 CC 模型的示例以及回滚 CC 模型进行了说明。最后，我们探讨了如何直接通过 SQL 提取机器学习会话日志数据用于审计目的。

虽然在机械上很简单，但思考所需的步骤，并练习如何部署和回滚机器学习模型，对于成熟的 IA 团队来说是必须的。机器学习在未来将受到越来越多的审查，不仅来自管理层，还包括法律系统。如果发现模型存在问题，我们需要能够快速回滚并找出哪些客户受到了机器学习预测的影响。

在下一章和最后一章中，我们将探讨更广泛的 BP 产品生态系统。我们将讨论四个额外的与 IA 相关的产品，以及它们如何为您的公司 IA 项目做出贡献。最后，我们还将讨论三个重要的 IA 趋势。

第十三章：其他智能蓝宝石产品及未来人工智能趋势

在核心 BP RPA 软件之外，还有其他产品丰富了 BP 的人工智能产品组合。在本章中，我们将讨论这四种产品。我们本章的目标是了解产品的用途以及它们如何融入人工智能。我们还将介绍使用每个产品的概述步骤。最后，我们将探讨如果您想尝试这些产品需要采取的下一步行动以及如何获取更多信息。为了完成本书，我还会讨论我认为的人工智能的未来趋势。

我们将要讨论的四个 BP 产品如下：

• 解码器智能文档****处理（IDP）

• 文档自动化

• 决策

• 互动

解码器 IDP

解码器 IDP 是一种提供 OCR、文档分类、实体提取、表格提取以及用于 HITL 校正和文档训练的 Web 界面的文档处理解决方案。解码器于 2020 年 6 月发布，自那时起一直持续升级，因此已经由许多其他公司进行了实战测试。如果您需要从扫描或计算机生成的（非手写）文档的图像中提取内容，您应该考虑使用解码器。

作为一位使用过解码器并且听取过使用过它的 BP 客户的反馈的人，它对于计算机生成的文档绝对值得考虑。它也适用于具有不同行数的表格的文档。目前不支持大量手写的表格（尽管在接下来将要讨论的下一个产品中是支持的）。

我看到一些 BP 客户和合作伙伴内部构建了功能较不全面的文档处理解决方案，这至少需要几个月的开发工作。解码器为您提供免费的文档处理解决方案，前提是您的公司拥有 BP 的生产或业务关键支持计划。

解码器与人工智能有何关联？

从文档中提取字段以便它们可以被 RPA 处理是人工智能最常见的使用案例之一，以至于每个主要的 RPA 供应商都有一个专门用于该任务的产品。

在幕后，解码器在多个地方使用机器学习。首先，解码器使用 OCR 引擎（Tesseract），它本身具有预训练的 ML 模型，用于识别文本。接下来，解码器可以训练文档分类模型以区分不同类型的文档。例如，您可能有一个电子邮件账户，该账户接收报价和发票作为附件。解码器可以帮助您区分这两种类型的文档，并使它们沿着不同的自动化处理路径开始。

Decipher 还可以训练特定于文档的模型以提取预指定的实体或从文档中提取结构化数据。预指定意味着您必须提前告诉 Decipher 您试图提取的内容，例如发票号码或总价。当您在网页 UI 中纠正实体预测时，您将看到您指定的确切字段。Decipher 还可以处理半结构化数据，这意味着具有固定位置字段的文档以及长度可变的表格项。

最后，还有一个可以提取非结构化数据的 NLP 插件。此插件需要安装 GPU。从查看插件的第三方许可声明来看，它使用 Keras 和 Tensorflow，这表明这里正在使用一些神经网络或深度学习模型。

Decipher 还附带一个可用于验证和纠正提取文档字段预测的HITL 网页界面。提取的字段与您预先指定的实体并排显示，以便轻松比较并做出修改。

使用 Decipher

您如何使用 Decipher 的高级视图如下：

1. 在 Decipher 网页界面中，定义您想要提取的文档类型，例如申请表、发票、财务报表等。

2. 对于之前定义的每种文档类型，指定您想要提取哪些字段和表。这两步操作只需进行一次，除非您需要更改要从文档中提取的字段。更改字段将导致需要重新训练整个 ML 模型以适应此文档类型。

3. 从 BP 发送一批图像或文档到 Decipher。这是通过Decipher VBO 的一系列操作完成的：创建批次、将文件添加到批次（必须在每个单独的文件上完成）和提交批次。

4. Decipher 在后台处理文档，并尝试执行分类或提取。它根据模型置信度分数和默认的阈值值（用户可以更改）确定是否需要人工审查文档。

5. 用户检查是否有需要审查的文档。此检查可以通过 BP 流程、使用有批次待验证操作或访问 Decipher UI 并手动检查来完成。如果需要 HITL 审查，用户访问网页 UI 并纠正 Decipher 提取的内容。所做的更正将反馈到 ML 模型中，随着时间的推移提高准确性。

6. 在 BP 中，需要有一个流程来检查是否存在完成的批次，使用 Decipher VBO 动作 获取下一个完成的批次。完成的批次包含经过人工审查的文档，以及由于超过阈值要求而无需人工审查的文档。如果有完成的批次，我们可以通过使用 获取文档 数据 动作循环遍历完成的批次文档的提取数据以供 BP 处理。

下一步

Decipher 可以直接从 BP Portal 下载：portal.blueprism.com/products/decipher。如果您还没有 Decipher 许可证，您需要向您的销售代表申请。

您还需要为新基础设施的安装准备 Decipher。最低要求列在这里：bpdocs.blueprism.com/decipher-2-2/en-us/getting-started/minimum-requirements.htm。我注意到客户在使用 IDP 时提出的一个反对意见来自基础设施要求以及额外的依赖。Decipher 需要安装 RabbitMQ 消息代理，而一些 IT 团队可能没有准备或不愿意支持这一点。

对于试点或测试，可以在单个虚拟机上安装 Decipher 及其所有依赖项。对于生产部署，您可能还需要另外四个虚拟机，除非您愿意将一些 Decipher 组件一起托管，但这还没有考虑到高可用性和灾难恢复。Decipher 的基础设施成本应该提前考虑。虚拟机的大小也很棘手，因为您需要估计每小时要经过不同 Decipher 组件的页面数。大小指南可以在这里找到：bpdocs.blueprism.com/decipher-2-2/en-us/Guides/Architecture/sizing.htm。

Decipher 使用确实需要一些培训。学习曲线不如常规 BP 那么陡峭，但您仍然应该预计在开始变得高效之前至少需要花费一周或两周的时间来尝试使用系统。有关 Decipher 的更多信息可以在 BP 文档网站上找到：bpdocs.blueprism.com/decipher-2-2/en-us/home.htm。最后，BP Portal 网站提供了与 Decipher 一起使用的模板和使用说明：portal.blueprism.com/products/developer-jumpstart。

文档自动化

文档自动化（DA）是 BP 的第二种文档处理解决方案。在 SS&C（BP 的母公司）收购 BP 之前，DA 就在开发中。收购后，DA 被整合到 BP 的产品线中。从高层次来看，DA 用于提取结构化数据，或格式固定且文档字段位置不变的文档。它擅长处理低质量数字文档，并能处理手写文本。

我尚未在生产环境中使用 DA，但我已经阅读了内部培训材料。DA 的一个关键优势是它是一个完全托管解决方案，符合 HIPAA、SOC 2、GDPR 等标准。与 Decipher 不同，它没有基础设施方面的担忧。它也是一个经过验证的系统，拥有众多客户和数百万页已处理的文档。如果你担心将文件发送到公司外部，你可以在 DA 中指定数据保留期，这样超过一定日期的文件就会被从系统中清除。

DA 与 Decipher IDP 在以下方面有所不同：

• DA 专门提取手写或打印的、在低质量数字格式中的数据。例如，使用标准 OCR 技术提取时准确度较低的扫描和传真文档。截至版本 2.2，Decipher 无法处理手写数据。

• DA 专注于结构化文档，而 Decipher 可以处理结构化、半结构化和非结构化文档（带有 NLP 插件）。DA 不处理具有可变行数的表格文档。

• DA 是一种托管服务，不能在本地安装。Decipher 由客户安装、托管和维护。

• DA 有一个独立的许可模式，与 BP 的许可无关。它不是免费的。只要你在生产或业务关键 BP 支持计划下，Decipher 每月最多可处理 4,000 页，且是免费的。

• DA 可以作为独立产品使用，无需 BP。DA 与 BP 之间的联系是通过 DX 上的连接器资产：digitalexchange.blueprism.com/dx/entry/9648/solution/chorus-document-automation。Decipher 与 BP 紧密集成，不能在没有 BP 的情况下使用，除非你开发一些重大的自定义解决方案。

• DA 不会为每种类型的文档训练单独的 ML 模型。Decipher 在产品中有一个循环，包括培训、（如有必要）纠正提取的数据、重新培训以及获取反馈。虽然 DA 有一个用于审查提取数据的 Web 界面，但它仅用于纠正数据。纠正不会用于改进你独有的模型。

• 从最终用户的角度来看，DA 更容易使用，因为许多机器学习概念不需要考虑。Decipher 需要培训，并且启动时间较长。

文档自动化与 IA 有何关联？

DA 与 Decipher 有类似的使用场景。您会使用它将文档转换为 CSV/JSON 格式，以便它们可以被 BP 进一步处理。区别在于 DA 擅长处理哪些类型的文档，使用通用 ML 模型（而不是适合您文档的特定模型），以及用户界面。DA 用于具有固定格式且可能已用笔迹填写的文档。

在幕后，DA 有一个专有的 AI 算法，该算法使用神经网络。这个模型是在超过 12 亿个数据点的由人类纠正的数据集上训练的。该模型在 DA 的所有企业客户中的平均准确率是 96%。

使用文档自动化

在高层次上，使用 DA 的步骤如下：

1. 在 DA 的 Web 界面中，定义您想从文档中提取的字段，例如，姓名、姓氏和地址。字段有一个“名称”和数据类型，例如，中等文本、单选一、签名等。

2. 定义一个模板。模板代表一个可以跨越多个页面的表单。将模板页面的示例上传到 DA，可以是图片或 PDF 格式。一旦上传模板文件，它将在 Web UI 中显示，并列出您已定义的所有字段。

3. 在模板图像上绘制您选择的字段所在的框。这就是您将哪些字段属于模板的过程。这也告诉 DA 在 x，y 坐标的大致位置应该查找以提取特定字段。

4. 将一批文档上传到 DA，通过 Web UI、API（DX 资产使用的是 API）或通过上传文档到云存储，如 AWS S3 或 Google Drive。

5. 提交批次并指定您想使用的模板。您也可以让 DA 为您选择模板。DA 使用对齐功能，如线条、徽标和模板中存在的字段的边界框，以找到最佳匹配的模板。

6. DA 在后台处理文档。如果需要，它将选择最佳匹配的模板来使用。然后，它将根据定义的字段提取数据。

7. （可选）通过 Web UI 将提取的数据与实际文档并排审查和纠正。

8. 对字段应用转换，例如日期格式化和大写。

9. 通过 Web UI 或 API 以 CSV 或 JSON 格式检索提取的数据。

下一步

这里有一个免费试用，您可以在此处注册：shreddr.captricity.com/accounts/signup。生产使用需要从销售代表处获取报价。由于它取决于许多因素，如您需要处理的页面数量以及您需要的 SLA，因此没有固定的定价。您还可以考虑使用专业服务来加速将用例投入生产。您的销售代表也可以帮助您。有关 DA 的更多信息，可以在文档网站上找到 bpdocs.blueprism.com/document-automation/en-us/home.htm。

决策

决策（不要与决策阶段混淆）是一个允许开发者用机器学习模型调用替换复杂的决策和选择阶段逻辑的产品。如果您有复杂的嵌套 if-else 分支，可以考虑使用决策。

图 13.1 – 将复杂的决策和选择阶段逻辑转换为单个操作

它适合那些没有访问数据科学家，并且已经有一些 RPA 成功经验，但刚刚开始 IA 旅程的团队。决策将允许他们以某种形式尝试 IA，即使他们不熟悉训练新模型、部署它和审计预测的概念。

决策是一个 AutoML 解决方案，它从用户那里隐藏了机器学习生命周期的复杂性。用户只需通过 Web 界面定义模型的潜在输出和输入。然后决策生成输入的随机变体，并询问用户正确的预测应该是什么。经过几轮这样的操作后，就构建了一个机器学习模型。

决策不是一个独立的解决方案。它是一个通过另一个名为 Blue Prism Hub 的基于 Web 的产品安装和管理的 插件。如果您想尝试决策，您需要有一个作为先决条件的运行中的 Hub 安装。

我认为决策不适合用于有大量输入列（> 10）的用例。原因是通过 Hub 的 Web UI 逐个样本进行“训练”，有人手动查看输入并告诉决策预测应该是什么。大量的输入使得这个过程非常繁琐。我还认为决策必须与一个可行的替代方案竞争，即通过流程工作室简单地创建复杂的逻辑图。另一个需要考虑的问题是逻辑是否容易更改。想象一下，您需要向模型添加另一个输入，或者添加另一个预测输出可能性。这可能导致重新进行整个模型的“训练”过程，这可能非常耗时，因为它是通过 Web UI 完成的。修改流程图可能更容易一些。

决策与 IA 有何关系？

决策提供了一个直接的方法将 ML 模型部署到生产环境中。安装决策需要部署一个新的服务器，尽管您可以在 Hub 所在的服务器上共同托管它。模型作为基于 Web 的服务在 Windows 或 Linux 上运行。决策具有模型版本控制功能，这是多个先前章节中的重要主题。还有一个模型历史审计跟踪，它记录了所有预测的输入、输出、置信度分数和模型版本。

模型应具有表格输入。您不能使用图像、音频或提示输入。输出可以是数值的（回归）或分类的（分类）。虽然底层模型不是公开知识，但根据引用 scikit-learn 和 SciPy 的第三方认可，我预计它正在使用基于树的算法。基于树的算法也是为数不多的同时适用于回归和分类问题的算法之一，并且它们可以相对快速地进行训练。

使用决策

从高层次来看，使用决策的步骤如下：

1. 在 Hub 中创建一个新的决策模型。

2. 选择模型应预测的输出类型。这可以是数值或分类（标签文本）。如果是数值，您可以限制预测的数字范围。如果是分类，您可以定义标签列表。

3. 通过为每个变量指定一个标识名称和类型（数值或分类）来定义模型输入变量。

4. 现在输入和输出已经定义，我们可以添加固定规则。固定规则在 ML 模型使用之前运行。这允许您有一个混合决策策略，首先使用固定、硬编码的规则，然后是 ML 模型。

5. 如果模型输出是分类的，您需要为每个定义的预测标签手动创建一个数据样本。决策将循环遍历每个潜在的预测输出，并要求您创建一组导致该预测的输入。

6. 为每个输出创建一个数据样本后，决策开始展示输入数据的随机排列，并要求您选择正确的预测。这被称为决策的训练阶段。随着您进行更多此类操作，模型应该变得更加准确。当您觉得模型满足您的准确度要求时停止。

7. 到目前为止，我们有一个使用多个经过人类验证的数据点训练的模型。接下来，决策使用该模型，生成随机输入数据，并显示其预测和置信度。您有两个选择。首先，如果预测错误，您可以纠正预测。或者，您可以更改输入数据，使其导致决策的预测。这被称为决策的校准阶段。重复此步骤，直到您满意为止。

8. 保存模型并记下模型 ID。

9. 在您的 BP 图中，使用实用 - 决策VBO 和获取预测操作，并传入模型 ID（以及您的输入数据）。将返回预测输出和置信度。

下一步

决策功能对拥有生产或业务关键支持计划的客户可用。如果您的公司拥有这些计划之一，您可以通过您的销售代表请求决策许可证。许可证准备好后，您可以从这里下载 Decision：portal.blueprism.com/product/related-products/decision。

假设您已经拥有 Hub，设置 Decision 并不复杂。在大多数情况下，只需要一个额外的服务器。然而，如果您还没有 Hub，您将需要为一个非常大的部署做好准备，因为 Hub 的基础设施设计和安装非常复杂，而 Hub 是 Decision 的先决条件。

关于 Decision 的更多文档可以在这里找到：bpdocs.blueprism.com/hub-interact/4-7/en-us/home-decision.htm。

Interact

Interact 是 BP Hub 的一部分产品。它是一个基于 Web 的 HITL 界面，它使人们（通常是业务用户）与其 BP 数字工作者之间的协作成为可能。通过 Interact，您可以设计用于向业务用户展示的 Web 表单并请求他们的输入。当业务用户提交 Interact Web 表单时，您可以执行各种操作，例如触发一个流程开始，或继续等待人工批准的流程。

Interact 与 IA 有何关联？

如您所猜测的，Interact 是作为 ML 预测审查界面的好选择。它具有将审查数据推送到 Interact 表单的 BP 操作。表单可以分配给特定的 Interact 用户（称为审阅者），或一组审阅者。审阅者可以用正确的预测填写表格，并将其发送回 BP 进行进一步处理。它与 BP 企业产品紧密集成，因此您不需要使用可能脆弱的数据共享接口，例如共享文件夹中的 Excel 文件。

Interact 适用于数值和基于文本的输入和输出值。如果 ML 输入/输出有图像，则 Interact 无法在 Web UI 中显示图像，因此它将不起作用。Interact 还有自己的审计跟踪，记录了谁进行了审查以及他们的审查预测是什么。

使用 Interact

在高层次上，使用 Interact 作为审查 ML 预测的接口的步骤如下：

1. 创建一个 Interact 表单。表单必须与 BP 流程相关联。

2. 将已审查的预测数据推送到工作队列。这应该是一个新的队列，而不是原始流程中使用的队列。如果需要，为表单设置服务等级协议（SLA）。这将与 HITL 审查 SLA 相对应。

3. 如果您需要将表单拆分为多个页面，请向表单添加页面。

4. 在页面上添加所需的表单字段，如文本、文件上传和表格。所有这些字段都可以有默认值、范围以及限制可以输入的内容。

5. 保存表单。

6. 通过向表单添加 Interact 用户角色来部署表单。这会将 Interact 用户映射到他们可以访问和提交的表单。

7. 修改制作机器学习预测的流程，以使用实用工具 – Interact API VBO。一旦流程确定需要 HITL 审查，数字工作者应检索表单并使用输入数据和预测填写它。然后使用提出提交或向角色提出提交操作请求某人审查预测。工作队列项应存储由操作返回的_requestId数据项的引用。

8. Interact 用户（审阅者）访问 Interact Web UI 并纠正提交。这将在步骤 2 中描述的新工作队列中创建一个新的条目。

9. 修改检查 HITL 评论的流程。使用实用工具 – Interact API::获取提交并输入_requestId。检索已审查的预测数据，并继续执行流程逻辑。

下一步

Interact 适用于拥有生产或业务关键支持计划的客户。如果您的公司拥有这些计划之一，您可以通过您的销售代表申请 Interact 许可证。许可证准备好后，您可以从这里下载 Interact：portal.blueprism.com/product/related-products/blue-prism-interact-premise。

安装 Interact 是一个相当复杂的过程，即使我们排除等式中的 Hub 部分。有关 Interact 的基础设施、硬件和软件要求的更多详细信息，请在此处查看：bpdocs.blueprism.com/hub-interact/4-7/en-us/installation/install-interact.htm。

BP 专业服务提供 Interact 加速器包，以获得 Interact 专家的指导。最困难的部分将是设计表单，以及安装，这两者都包含在此服务中。您可以联系您的销售代表获取更多信息。产品的学习曲线本身并不那么糟糕，但从基础设施角度来看设置 Interact 可能是一个多月的任务。有关 Interact 的更多信息，请在此处查看：bpdocs.blueprism.com/hub-interact/4-7/en-us/home-interact.htm。

未来 IA 趋势

我相信在未来的几年里，三个广泛的 IA 趋势将会显现。第一个是将 AI 直接集成到 RPA 产品套件中的加速整合。接下来是通用、低认知 AI 任务的 LLMs 的广泛应用。第三个趋势是 IA 在伦理和安全方面的审查增加。

改进的 AI 产品集成

正如我们在本章中看到的，BP（以及其他 RPA 供应商）的产品套件中已经有许多与 AI 相关的产品。但随着 IA 的发展，我认为产品提供将发生以下变化：

• 将会有更多推动使用基于云的产品版本的趋势，更新的服务条款允许供应商捕获关于你流程流程的高级信息。大多数 RPA 供应商都希望开始训练自己的类似 LLM 的模型，并提供类似 Copilot 的产品功能。

• 用于 ML 审查和构建 ML 模型的 HITL 界面工具将变得更加紧密集成。在 BP 中，这将涉及 Interact 和 Decision。

• 添加数据和 ML 模型监控工具。

• 这可能还需要几年时间，但预计将推出实施通用 ML 可解释性技术（如 SHAP、LIME 和 ICE 图）的产品，这些技术可以自动与 ML 审计日志关联。这些可解释性技术将用于使用供应商的 ML 产品套件构建的模型，例如 Decision。这是因为许多这些技术需要与模型本身非常紧密的集成。一些需要服务器日志访问和访问原始训练数据。由于对在商业中使用 ML 的审查增加，这两点都将被需要。

使用 LLMs 实现 ML 的民主化

许多人认为，大型语言模型（LLMs）将导致基于聊天机器人的 IA 用例激增。虽然这可能成立，但我相信 LLMs 更大的增值在于它们使机器学习民主化，类似于低代码开发解决方案如何使软件开发的部分民主化。

LLMs 的出现使得公民开发者能够参与到机器学习的使用中，并开发他们自己的 IA 流程。在 LLMs 出现之前，我会把 ML 放在典型公民开发者的技能水平之上，但这种情况不会持续太久。虽然 LLMs 的使用案例仍然属于初中生可以完成的认知技能类别，例如数据提取和文本生成，但我们预计这会随着时间的推移而改善。随着 LLMs 变得更加强大，公民开发者将能够访问越来越强大的 AI。

尽管如此，总会有理由定制构建 ML 模型。当你的 AI 使用存在潜在审查时，使用数据和经过验证的技术堆栈构建定制模型将是有益的。LLMs 无法承受这种程度的审查，因为创建它们所需的数据集太大，难以理解。

人工智能伦理和安全

如第四章所述，各国政府目前正在形成他们对人工智能和人工智能助手（IA）的看法，以及这些如何与人类工人相关。大学和其他政策智库也在提出他们的意见，以帮助塑造人工智能政策。例如，2023 年 11 月，麻省理工学院发布了一系列政府政策简报，以帮助塑造人工智能的治理。这些简报可以在以下链接找到：computing.mit.edu/ai-policy-briefs。虽然这些还没有成为完整的法规，但阅读它们可以让我们对未来可能发生的事情有所了解。以下是一些与本书直接相关的政策建议：

• 人工智能必须受到监管，可能由新成立的联邦机构负责。

• 必须开发人工智能系统的审计制度。一些高风险用例在使用前应进行审计，而低风险用例则可以进行事后审计。

• 人工智能系统应该是可解释的。

• 在责任方面，服务的最终提供者应承担责任，即使模型是建立在另一个基础模型之上。

这本书的撰写考虑到了对未来人工智能治理的广泛视角。人工智能助手（IA）必须在监管体系范围内实施，而这个体系正在我们说话的时候形成。IA 团队成员应自觉努力，跟上当地人工智能监管的最新发展，并调整内部实践以满足当地监管要求。

摘要

在本章中，我们探讨了四种额外的 BP 产品，可以帮助你在人工智能助手（IA）的旅程中。其中两款产品，Decipher IDP和文档自动化，专注于使用机器学习处理文档。文档自动化是一个托管解决方案，专注于从质量较差的手写扫描文档中提取数据，这些数据以固定、结构化的形式存在。Decipher 是一个自托管解决方案，它构建特定于您文档类型的机器学习模型。它可以对文档进行分类，并从结构化、半结构化和非结构化文档中提取数据。

决策是一个自动化机器学习（AutoML）产品，它将机器学习的复杂性隐藏在用户之外。它可以用来用单个机器学习调用替换复杂的决策和选择阶段逻辑。用户可以通过 Decision 在 Hub 上的 Web 界面快速创建模型。首先，指定预测输出应该是什么。然后定义输入。Decision 随后向用户展示不同的输入组合，并要求他们提供正确的预测。经过几次重复后，将构建一个模型。Decision 内置了人工智能最佳实践，如机器学习版本控制和审计跟踪。

Interact是 BP 解决人机协作的解决方案。通过 Interact，您可以通过 Hub 平台向用户（审阅者）展示网页表单。用户可以通过这些表单以多种方式与 BP Digital Workers 互动。例如，他们可以触发一个流程开始，或作为 ML 预测的审阅者。也可以定义审阅的 SLA。

最后，我们讨论了三个我认为将在未来几年发生的未来 IA 趋势。首先，供应商的产品将针对 IA 特定的关注点进行许多改进。其次，随着公民开发者能够在其业务流程中使用 ML，LLMs 将极大地扩展 IA 用例的数量。第三，关于 AI 使用的法规将开始改变我们的 IA 实践，因为它们将变得更加明确。

恭喜您完成这本书！希望其中的知识和例子能帮助您和您的公司在 IA 的道路上取得成功。作为最后的额外奖励，我在接下来的附录中包括了与我这本书相关的研究总结。虽然论文总结不是针对 BP 特定的，但信息对参与 IA 的每个人来说都应该是相关的，从开发者到顾问和自动化负责人。

附录

IA 风险管理

本附录总结了我的 IA 论文研究的一部分。我的研究主要关注于揭示 IA 对企业的风险。这一研究的动机在于，我希望能够提高行业对这一研究不足且评价不高的主题的理解，我认为这对 IA 在全球范围内的采纳和成功至关重要。我还希望，了解 IA 的风险将迫使我们考虑如何应对这些风险，并减少自动化对社会可能产生的负面影响。

我的研究揭示了36个 IA 风险。这些风险被分为两大类：社会组织和运营。社会组织风险源于不同社会结构之间的关系。例如，这可能是企业与法律体系之间，或管理层与员工之间的关系。运营风险是指在 IA 运营过程中出现的问题。与社会组织风险相比，它们的范围更窄，且具有项目或技术性质。

我还研究了有哪些缓解措施可以用来对抗 IA 风险。这些风险缓解技术指导了本书的开发，并在可能的情况下被纳入到可重用 IA 模板中。您只需将模板作为您 IA 解决方案设计的起点，就可以利用许多风险降低措施。

社会组织 IA 风险

确定了四个组织结构。它们是环境、企业、第三方和员工。这些群体之间的冲突导致了 22 个 IA 风险。

图表附录.1 – 四个组织群体及其之间风险的产生

以下表格总结了 22 个风险：

社会-组织人工智能风险（22 个）

环境风险（3 个）

合规性

伦理

监管

企业风险（5 个）

部门抵制

员工流失

财务损失

信息不对称

失去控制

员工风险（8 个）

认知工作超负荷

工作意义丧失

工作安全感的丧失

对管理的信任缺失

对模型预测的不信任

预测问责制

工作准备度降低

工人技能退化

第三方 风险（6）

责任归属

吸引竞争反应

利益冲突

错过服务机会

执行协议违约

声誉损失

表格附录.1 – 22 个社会组织 IA 风险

运营 IA 风险

将 14 项运营风险分为四个类别：项目、流程、ML 模型和数据。

图附录.2 – 四种操作风险类别

以下表格显示了操作风险的总结：

操作智能 风险（14）

项目 风险（3）

预测性能低

低 投资回报率（ROI）

无法衡量的 ROI

流程 风险（4）

控制流程漂移

执行错误检测困难

对业务逻辑理解减少

时间滞后效应

机器学习模型 风险（3）

对抗攻击

性能下降

迁移学习偏差

数据 风险（4）

数据偏差

数据漂移

数据隐私与安全

数据质量

表格附录.2 – 14 个操作性的 IA 风险

IA 风险缓解措施

在我的研究中发现了 15 种风险缓解技术。它们根据它们在 IA 项目中的应用时间被组织成四个类别。在规划和尽职调查、算法选择和人机交互设计下的技术可以在 IA 解决方案部署使用之前的规划和设计阶段使用。在运营类别下的技术是在实施后使用的，只要 IA 解决方案在生产中。

图附录.3 – 15 个风险缓解措施

下表展示了风险缓解措施的总结以及它们在本书中讨论或实施的位置：

风险缓解 措施（15）

规划和尽职 调查（3）

合同中的 AI 责任条款

合同重新谈判

理解员工情绪

算法 选择（2）

可解释人工智能

最小化误报

人机交互设计（3）

人在回路中

随机抽样

阈值

操作（7）

避免自我学习

治理

监控数据

监控模型

处理运行时控制

自我学习

分阶段部署

表格附录 3 – 15 项风险缓解措施及其在本书中的讨论位置

这项研究总结到此结束。IA（智能自动化）应成为整个公司范围内的战略和转型性倡议。这需要谨慎的变革和风险控制。但如果没有了解采用 IA 风险的基础工作，公司可能会犹豫是否真正转型自己。进行这项基础工作以揭示 IA 的风险，以及缓解这些风险的方法，是我对这个不断发展的领域的贡献。通过分享这些信息，我希望你们能够提供更好的 IA 解决方案，并催化整个行业对 IA 的采用。