原文：
annas-archive.org/md5/2f8059e0c6c259396db3b43f33d9255e译者：飞龙
前言
在过去十年中，两种自动化趋势已经改变了公司的运营方式。第一种趋势是使用机器人流程自动化（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 版本。
在任何地方、任何设备上阅读。直接从您最喜欢的技术书籍中搜索、复制和粘贴代码到您的应用程序中。
好处不止于此，您还可以获得独家折扣、时事通讯和每日免费内容的专属访问权限。
按照以下简单步骤获取好处：
- 扫描二维码或访问以下链接
packt.link/free-ebook/978-1-80324-969-8
-
提交您的购买证明
-
就这样！我们将直接将免费 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 的包装器。在本例中，我们将执行四个高级步骤：
-
从 DX 下载资产
-
将资产导入 BP
-
配置 BP 凭证
-
通过进行机器学习预测来测试 DX API 资产
从 DX 下载
在此步骤中，我们将访问 DX (digitalexchange.blueprism.com/dx/search) 以搜索和下载 AWS Comprehend 资产：
-
访问 DX 并在搜索栏中输入
comprehend capability aws（大小写不敏感）。搜索并点击结果中的 Comprehend Capability AWS 云 资产。 -
点击屏幕右侧的绿色下载按钮，并将
.bprelease资产保存到您的计算机上。如果您尚未登录，DX 网站将要求您登录。此.bprelease包含一个网络 API、一个对象和一个凭证。 -
在 Comprehend Capability AWS Cloud 连接器 页面上继续向下滚动并下载 AWS Comprehend 用户指南。
图 1.7 – 下载资产和 AWS Comprehend 用户指南
重要提示
AWS Comprehend 用户指南提供了如何设置您的 AWS 账户以允许从 BP 进行 API 调用的链接和详细信息。请按照用户指南中的步骤正确设置您的 AWS 账户和身份验证详细信息。我们不会在这里介绍设置 AWS 账户的步骤。
将 Comprehend 资产导入到 BP 中
让我们将下载的资产导入到 BP 中并检查导入的内容：
-
打开 BP 并登录。点击 文件 | 导入 | 发布 / 技能。导入 AWS Comprehend 发布。导入时接受所有默认设置。
-
验证
.bprelease是否已成功导入到 BP 中。应该有一个对象、一个网络 API 服务和一个凭证。对象可以在 BP 的 工作室 部分找到。
图 1.8 – 在工作室部分找到对象
- 在 系统 | 对象 | 网络 API 服务 下找到 Comprehend 网络 API。
图 1.9 – 在系统 | 对象 | 网络 API 服务下找到 AWS: Comprehend
- 在 系统 | 安全 | 凭证 下找到凭证。
图 1.10 – 在系统 | 安全 | 凭证下找到 AWS 凭证
配置 AWS 凭证
在此步骤中，我们将导入 AWS 凭证（如果您还没有创建这些凭证，请查看下载的用户指南）到 BP 中。然后，我们将设置凭证的权限，以便我们可以在流程中测试它：
- 将您的 AWS 访问密钥 ID 复制到
AWS凭证中。将您的秘密访问密钥复制到两个 密码 字段中。
图 1.11 – 输入 AWS 访问密钥 ID 和秘密访问密钥
- 在凭证的 访问权限 选项卡上，将 安全角色 设置为 所有角色，流程（旧版） 设置为 所有流程，资源（旧版） 设置为 所有资源。虽然这不是最佳实践，但我们只为测试目的这样做。
测试 AWS Comprehend 对象
最后，让我们测试 DX 资产并做出预测！注意在测试流程中，操作使用的是对象而不是 Web API 服务。直接使用 Web API 服务不会工作，因为它不包含身份验证部分。请按照以下步骤操作：
-
在 Process Studio 的
Ch1组中打开“示例 1 - 测试 AWS Comprehend”流程。此流程还需要导入“Utility – General”VBO。这可以在 BP 安装目录下的VBO子文件夹中找到。 -
在 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。
在本例中，我们将执行四个高级步骤：
-
从 GitHub（或 DX）下载资产
-
将资产导入 BP
-
配置表单识别器对象
-
通过进行预测来测试 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)以下载文档：
-
在 DX 搜索栏中输入
form recognizer client（大小写不敏感）进行搜索。点击表单识别器 客户端资产。 -
在表单识别器客户端连接器 – 1.0.0页面向下滚动并下载用户指南。
图 1.14 – 下载资产和用户指南
重要提示
用户指南提供了如何设置 Azure 账户以允许从 BP 进行 API 调用的详细信息。请按照指南中的步骤正确设置 Azure。指南还列出了两个必须导入到 BP 中的其他 VBO：Utility - JSON 和 Utility – HTTP VBO。这两个都包含在之前的 GitHub 链接中。如果您希望单独下载它们，它们也可以从 DX 获取。
导入到 BP
下载资产后，必须将其导入到 BP 中。这一步骤无论您是从 DX 还是 GitHub 下载资产都是相同的：
-
打开 BP 并登录。点击 文件 | 导入 | 发布 / 技能 并导入资产。
-
验证
表单识别客户端服务对象是否存在。还要验证 HTTP 和 JSON VBO 的正确版本是否存在，这是用户指南所要求的。
图 1.15 – 验证三个对象是否存在
配置表单识别客户端服务对象
DX 资产的作者选择将身份验证 ID 作为对象中的数据项存储。这 不是最佳实践，因为这些应该作为凭据存储。但由于对象就是这样设计的，让我们编辑这些数据项以配置连接到 Web API 所需要的身份验证详细信息。如果您没有订阅密钥，请按照资产文档创建一个。
重要提示
配置对象所需的访问令牌和基础 URL 可以从 Azure 网站的 表单识别 页面获取。图 1.15 中显示的用户指南提供了更多关于如何找到此页面的详细信息。
- 在对象工作室中打开
表单识别客户端服务对象。在访问令牌集合和需要填写的数据项基础 URL上。
图 1.16 – 在初始化页面填写访问令牌和基础 URL
- 打开
访问令牌集合并点击 初始值 选项卡。在 Ocp-Apim-Subscription-Key 字段中填写您的订阅密钥并保存。
图 1.17 – 将订阅密钥填写到访问令牌中
- 打开
基础 URL数据项并将 初始值 设置为 Azure 网站上的端点 URL。不要在 URL 末尾包含尾部斜杠。
图 1.18 – 在没有尾部斜杠的情况下填写基础 URL
现在我们已经配置了 Azure 对象，我们可以对其进行测试。
测试表单识别客户端服务对象
在章节开头“技术要求”部分导入的发布文件中包含了一个测试流程。此流程需要导入 Utility – General 和 Utility – File Management。这两个都可以在安装文件夹的 VBO 子文件夹中找到。
-
在 Process Studio 的
Ch1组中打开示例 2 – 测试 Azure 表单识别器客户端服务流程。 -
在 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 服务的配置并排显示，以供参考。
与前两个示例相比，本例的步骤非常不同。从高层次上讲，我们将执行以下四个步骤：
-
访问 GCP 网站以设置 API 认证所需的密钥
-
将 API 认证密钥保存到凭证中
-
在 BP 中创建 Web API 服务
-
通过进行预测来测试 Web API
设置服务帐户和密钥
本节包含在 GCP 网站上执行的操作步骤。目的是生成可以下载并在 BP Web API 服务内部使用的认证凭证。如果这些步骤过时了，请使用步骤 1中的链接作为参考：
-
访问
cloud.google.com/iam/docs/service-accounts-create#creating_a_service_account并按照说明创建您的服务帐户。确保您的服务帐户有权访问Vision API。 -
在IAM & Admin的服务帐户部分下，点击密钥选项卡，然后点击添加密钥：
图 1.20 – 为您的服务帐户创建密钥
- 选择JSON作为密钥类型并按创建：
图 1.21 – 创建 JSON 密钥
- 在按创建后下载出现的 JSON 文件。
将服务帐户电子邮件和私钥保存为凭证
我们已创建认证凭证并以 JSON 格式下载。现在我们需要将相关信息保存到 BP 凭证中：
-
在任何文本编辑器中打开 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", -
在 BP 中访问系统 | 安全 | 凭证。点击新建以创建新的凭证。
-
设置
GCP Cloud Vision。将类型设置为OAuth 2.0 (JWT Bearer Token)。将发行者设置为服务帐户电子邮件地址，对于私钥，粘贴在步骤 1中复制的部分：
图 1.22 – 使用 GCP 门户信息保存凭证
- 点击凭据的访问权限选项卡。将安全角色设置为所有角色，进程（旧版）设置为所有进程，资源（旧版）设置为所有资源。虽然这不是最佳实践，但我们只是在测试，并没有将任何东西部署到生产环境中。保存凭据。
创建 Web API 服务
在这里，我们将从头开始创建一个 Web API 服务。在这次练习中，将频繁查阅 Google 的 API 文档（cloud.google.com/vision/docs/file-small-batch）。
在从头开始构建一个 Web API 时，一个需要考虑的关键提示是查看供应商是否已经在 DX 上提供了一种不同的服务。如果是这样，请下载它，导入它，并将其用作参考。每个供应商都试图保持其 API 的内部一致性。在一个供应商内部，它们的 API 可能使用相同的认证方法，并且它们的输入和输出具有相似的 JSON 结构。你很可能会将一个工作的 Web API 服务的一部分复制到自己的 API 中！
-
访问系统|对象|Web API 服务。点击添加服务。
-
设置
Google Cloud Vision Batch Annotation Online。这是一个任意名称，它将作为一个可选择的选项出现在动作阶段。将基本 URL设置为vision.googleapis.com/，包括尾随斜杠。在这个步骤结束时，你的 Web API 应该看起来像这样：
图 1.23 – 设置名称和基本 URL
基本 URL 取自 GCP 的文档：
图 1.24 – GCP 文档中的基本 URL
- 点击
Content-Type和application/json; charset=utf-8。公共头信息部分应该看起来像这样：
图 1.25 – 设置公共头信息
这些公共头信息来自 GCP 文档中显示的示例 API 请求：
图 1.26 – GCP 文档中的头信息（其他头信息可以忽略）
- 点击
GCP Cloud Vision，这是在步骤 2中保存服务账户电子邮件和私钥作为凭据部分创建的。取消选中暴露给****进程框。
重要提示
令牌端点数据来自accounts.google.com/.well-known/openid-configuration，作用域端点来自developers.google.com/oauthplayground。
公共认证部分应该看起来像这样：
图 1.27 – 设置公共认证
- 点击
Annotate Batch。这是将在 BP 中作为可选项目出现的操作名称。每个操作相当于一个 Web API 端点。完成此步骤后，您的 操作 部分应如下所示：
图 1.28 – 创建操作
- 点击
mimeType、pages和content。将 初始值 留空，并为所有三个选项勾选 暴露。完成此步骤后，您的 参数 部分应如下所示：
图 1.29 – 设置操作参数
这三个参数是从 GCP 请求 JSON 主体中期望接收的示例中提取的。我们将这些作为 Web API 的输入参数公开，以便它们可以根据流程的需求传递和更改。
图 1.30 – GCP 文档的参数
-
点击
/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.32 – 设置响应
- 我们的单个输出
responses集合相当于 GCP 文档样本响应输出中突出显示的项目：
图 1.33 – GCP 文档的响应
- 保存 Web API 服务。
现在我们已经完成了新 Web API 的设置。让我们用一个流程来测试它。
测试批处理图像 Web API 服务
样本流程应已从 技术要求 部分导入。我们还需要导入一个额外的 VBO 来将我们的 PDF 文件转换为 Base64 格式，这是 GCP 视觉 API 的要求：
-
从 DX 中下载并导入
Utility – File Manipulation资产，链接为digitalexchange.blueprism.com/dx/entry/9648/solution/utility---file-manipulation。这个工具用于将 PDF 文件转换为 Base64 格式。 -
在流程工作室的
Ch1组中打开Example 3 – Test GCP Batch PDF流程。 -
在流程工作室中运行流程。此流程进行一次 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 执行直到脚本完成，这是出于可预测性的原因。最后，我们介绍了超时的概念，以停止命令行进程运行时间过长。
在下一节中，我们将通过示例回答以下问题：
-
我应该使用哪个 VBO 和操作来触发预测？
-
我如何将预测结果返回到 BP？
-
我如何停止运行时间过长的脚本？
使用 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，这样我们就不需要进行任何重定向。流程结束时，我们删除创建的批处理文件。按照以下步骤操作：
-
在流程工作室中打开
Ch2组。 -
在橙色块中打开Utility Environment::Start Process操作。注意我们提供批处理文件的路径作为应用程序输入参数，以及两个通过空格分隔的数据项作为参数值：
图 2.11 – 将脚本路径作为应用程序，并将两个参数通过空格分隔作为参数
-
通过按下Go按钮或F5来运行示例一次。
-
通过验证输出文本文件的内容，
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：
-
在流程工作室中打开示例 2 – 使用运行进程直到结束运行程序 BP 流程。
-
在橙色块中打开Utility - Environment::Run Process Until Ended操作。注意参数和应用程序输入与示例 1相同。不同之处在于操作已从Start Process更改为Run Process Until Ended。此外，请注意超时输入为空。当为空时，默认为 10 秒：
图 2.13 – 此操作配置与示例 1 相同
-
验证流程图中已移除睡眠阶段。
-
通过按下Go按钮或 F5 来运行示例一次。
-
验证脚本是否正确运行，请打开 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 运行命令提示符的内部命令所需的特殊语法，以防您将来需要这样做。请按照以下步骤操作：
-
在Ch2组中创建一个名为示例 3的新进程。在 Process Studio 中打开它。
-
在图中添加一个动作阶段。选择实用工具 - 环境作为业务对象，并将启动进程读取标准错误和标准输出作为动作。
-
设置
"cmd.exe"（包括双引号）和"/c dir"。dir命令列出了 BP 安装文件夹内的所有文件和目录。BP 安装文件夹是我们从 Process Studio 内部启动cmd.exe命令提示符的位置。/c表示在dir命令执行完毕后终止cmd.exe。
重要提示
为了从 WCP 使用dir、echo、copy等内部命令，我们需要将cmd.exe作为进程名称，而我们要在 WCP 中运行的命令作为参数。
-
点击动作的
标准输出和标准错误数据项。 -
在开始和结束阶段之间链接动作。完成的进程应如下所示：
图 2.14 – 示例 3 的完成测试进程
- 从 Process Studio 运行进程。
标准输出数据项将包含内容，而标准错误数据项将保持为空。这是因为dir命令成功执行且无错误：
图 2.15 – 标准输出已填充
-
修改动作的
"/c dir *.xyz"。此更改意味着我们想要列出所有具有.xyz文件扩展名的文件，这些文件不应存在于 BP 安装文件夹中。 -
再次运行测试进程。
标准输出和标准错误数据项都应填充，因为有错误：
图 2.16 – 标准输出和标准错误都已填充
注意，在运行示例 3时，实际的控制台窗口没有弹出，但我们能够捕获打印到控制台屏幕上的数据。假设 ML 预测将输出打印到屏幕上，捕获这些数据的第二种方法是重定向 STDOUT 和 STDERR 流到 BP 可以读取的文件。让我们看看在下一个示例中如何做到这一点。
示例 4 – 将内部命令（dir）重定向到文件
我们已经在示例 2中使用了实用工具 - 环境 VBO 中的运行进程直到结束操作。这个操作不允许我们直接将 STDOUT 和 STDERR 捕获为数据项；然而，示例 2中的批处理脚本本身创建了一个可以读入 BP 的文件。
在本例中，我们将再次使用此对象和操作创建一个新的进程，除了批处理脚本将输出打印到 STDOUT 和 STDERR。我们需要将 STDOUT 和 STDERR 流重定向到文件，以便它们可以被读入 BP。本章节的发布中提供了此示例的完整版本，供您参考。请按照以下步骤操作：
-
在Ch2组中创建一个名为示例 4的新进程。在流程工作室中打开它。
-
创建两个具有
Text数据类型的数据项。这些是我们重定向输出将保存的文件路径。按照以下设置：
| 数据项名称 | 初始值 |
|---|---|
Stdout File | C:\Users\Public\ch2_ex4_stdout.txt |
Stderr File | C:\Users\Public\ch4_ex4_stderr.txt |
表 2.2 – 配置两个数据项以保存我们的文件路径
-
将一个操作阶段添加到图中。选择实用工具 - 环境作为业务对象，并选择
"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.17 – 示例 4 的完成测试流程
-
在流程工作室中运行进程。
-
检查
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 脚本，并查看如果它运行时间过长我们如何超时。
-
在Ch2组中打开示例 5 – PowerShell 脚本超时 BP 流程。我们将一起查看重要细节。
-
打开
powershell.exe。尝试将 PS 脚本路径放入应用程序输入实际上不会执行脚本，而是使用默认应用程序打开文件，这通常是记事本。参数输入应该对你来说很熟悉，因为它包含 PS 脚本参数和重定向文件路径。此外，请注意超时输入为空，这意味着脚本最多可以运行 10 秒。 -
通过按播放以运行来运行示例一次。你会看到当脚本运行时 PS 窗口会弹出，之后会关闭。
-
打开
预测集合，查看它包含八个客户的置信度分数：
图 2.18 – 成功预测的置信度分数
- 将
MakeTimeSpan(0, 0, 0, 3)打开到Timeout输入。现在我们允许脚本运行的最大时间是 3 秒：
图 2.19 – 将 MakeTimeSpan(0, 0, 0, 3)添加到 Timeout 输入
- 重置，然后再次运行示例。当 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：
-
在 Ch2 组中打开 示例 6 – 通用 PowerShell 运行脚本 BP 流程。此示例已经为您构建好了，但我们将一起查看重要细节。
-
打开
parameter_name=parameter_value。多个参数应以逗号分隔。请注意，此动作直接将输出流保存为数据项，因此不需要重定向。 -
在 Process Studio 中运行此示例一次。与在 示例 5 中运行 PS 脚本不同，你不会注意到任何 PS 窗口弹出！
-
验证
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 脚本返回一个数值预测，而不是标签和置信度分数。按照以下步骤操作：
-
在Ch2组中打开示例 7 – 脚本执行 VBO 调用 Python 脚本 BP 过程。这个示例已经为您构建好了，但我们将一起查看重要细节。
-
打开命令行，
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 位置匹配
- 在橙色块中打开Script Execution VBO::Execute Script Action，注意它看起来相对更干净，因为输入被分离，并且不需要重定向：
图 2.22 – 输入参数被很好地分隔
-
在 Process Studio 中运行一次 Process。注意，Action blocks 并且不会弹出任何窗口。
-
验证从 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 语句通常在添加相应的程序集后。
接下来，让我们看看我们的第一个示例，我们将向一个对象添加 外部引用 和 命名空间导入。我们将进行五个高级步骤：
-
检查源代码中的现有
using语句 -
从 NuGet 下载 ML.NET 包
-
从 NuGet 包中提取
.dll文件 -
将
.dll文件复制到 BP 安装文件夹 -
在 代码选项 选项卡中添加引用和命名空间
本例的总体目标是尽可能在添加实际 C# 代码到代码阶段之前，让 BP 与 ML.NET 一起工作。
示例 1 – BP 之前的准备工作
回想本章开头介绍的情景。我们负责将 C# ML 代码移入 BP。有两种方法来确定需要导入哪些 .dll 库。第一种方法是将所有源代码复制到一个代码阶段，并查看出现的错误消息。另一种（可能更聪明）的方法是首先检查项目的源代码。这将使我们熟悉代码库，并给我们一个需要添加哪些 .dll 文件和命名空间的思路。我们在这里将采用后者。
我们的起始源代码来自微软的 GitHub：
检查 C# 源文件中的 using 语句
在 Microsoft GitHub 项目中，只有三个 C# 源文件。让我们逐一检查并注意可能需要导入的任何 .dll 文件：
-
打开第一个源文件
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 是对当前项目的自引用，而不是外部库。
-
打开第二个源文件
github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/DataStructures/SentimentIssue.cs。对于Microsoft.ML.Data只有一个using语句。 -
打开最后一个源文件
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 网站手动下载包：
-
在您的网页浏览器中打开
www.nuget.org/。搜索ML.NET。点击名为Microsoft.ML的结果。 -
点击版本
.nupkg文件。此文件可以用.zip提取程序打开，包括默认的 Windows 程序。
- 使用 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文件复制到安装文件夹。如果这不是您的安装路径，请替换为您自己的路径：
-
将从 NuGet 包中提取的七个
.dll文件复制到 BP 安装文件夹中。 -
如果您已经打开了 BP 应用程序，请重新启动。BP 需要重新启动才能加载新的程序集。
重要提示
您可以将程序集复制到多个位置，以便与 BP 一起使用。这包括 Windows 目录、Windows 系统目录以及系统路径环境变量中的任何文件夹。为了使这个例子更不容易出错，我们将它复制到 BP 安装文件夹中。在生产环境中，一个更易于维护的解决方案是将.dll文件复制到一个自定义文件夹中，并将该文件夹包含在 Windows 环境路径变量中。
现在库已经被复制到一个 BP 可访问的文件夹中，让我们创建一个示例对象并导入它们。
创建一个 BP 对象并添加外部引用和命名空间导入
在这个第一个示例的最后一部分，我们将创建一个 BP 对象，添加所需的.dll文件作为引用，添加命名空间，并将语言设置为 C#：
-
在工作室 | 对象内创建一个名为
Ch3的新组。 -
在
Ch3组内创建一个名为Example 1 – 用户评论的情感分析的新对象。 -
在初始化页面，双击带有对象名称的白色框。这会打开业务对象的属性。
图 3.6 – 双击打开业务对象的属性
-
点击
Microsoft.ML.dll。点击Microsoft.ML.Data.dll。 -
点击
Microsoft.ML。点击Microsoft.ML.Data。 -
在语言下拉菜单中选择C#。
-
确认代码选项选项卡看起来如下：
图 3.7 – 在第一个示例末尾的代码选项卡
- 保存对象。
在这个例子中，我们在将 C#代码移动到代码阶段之前完成了所需的前期准备工作。首先，我们检查了项目的代码，以确定所需的某些程序集导入。这些程序集本身以及我们需要添加到代码阶段的进一步代码可能还有尚未导入的附加依赖项。接下来，我们从 NuGet 下载了 ML.NET 包，并提取了.dll文件。最后，我们将 ML.NET 程序集复制到 BP 安装文件夹中，并在对象的属性中添加了它们作为引用。在下一节中，我们将专注于将源代码移植到 BP 中。
将 ML.NET C#移植到代码阶段
将代码移植到 BP 更像是艺术而非科学。这需要了解 C#的工作原理，并在必要时深入研究 ML.NET API 文档。我们已经讨论了对象的属性中的代码选项部分。对象的属性还有一个全局代码选项卡，它将在下一个示例中使用。
全局代码
全局代码选项卡通过对象的属性访问，类似于代码****选项选项卡：
图 3.8 – 通过对象的属性访问全局代码标签
全局代码部分用于放置需要在多个代码阶段中使用的通用代码。这在概念上类似于需要在不同操作或页面中使用的全局数据项（取消选中“在过程中隐藏其他页面”的复选框），类似于通用数据项。通用代码可以包括变量、类和函数。
您还会注意到一个检查代码按钮。此按钮从全局代码部分的编译器角度以及对象中的任何其他代码阶段验证代码。我们将频繁使用此按钮来帮助我们确定哪些程序集缺失。
在下一个示例中，我们将使用全局代码部分和检查代码按钮来帮助将 C#代码移植到 BP。示例将通过五个高级步骤进行：
-
将两个 C#类移动到对象的全局代码部分
-
将主要源代码复制到代码阶段
-
通过使用检查 代码按钮迭代修复编译错误
-
修改 C#控制台打印命令，以便将输出到文件
-
测试移植的 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，是类定义。让我们将它们移动到对象的全局代码部分：
-
打开第一个示例中创建的对象。如果需要，一个名为
Example 1 - Sentiment Analysis for User Reviews (Completed)的完成版对象应该已经导入到Ch3组中。 -
通过双击初始化页面上的带有对象名称的白色框来打开对象的属性。
-
点击全局 代码标签。
-
将类定义代码从
github.com/dotnet/machine learning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/DataStructures/SentimentIssue.cs复制到public class SentimentIssue { … }。 -
对
github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/SentimentAnalysisConsoleApp/DataStructures/SentimentPrediction.cs中的文件重复此操作。这包括public class SentimentPrediction { … }之间的所有内容。 -
确认全局代码部分包含如图所示的两个类定义：
图 3.9 – 全局代码部分包含两个类定义
-
点击“类型 ‘Attribute’ 在未引用的程序集中定义。您必须添加对程序集 ‘netstandard,
-
点击
netstandard.dll。 -
返回到全局代码选项卡并再次点击检查代码。确保没有编译器错误。
-
点击确定以保存业务对象的属性。
-
保存对象。
到目前为止，我们已经成功将两个类添加到对象的全局代码部分。接下来，让我们将主程序代码导入到一个代码阶段。
将机器学习程序代码移植到代码阶段
让我们将其移动到一个代码阶段：
-
导航到“动作 1”页面并添加一个代码阶段。
-
链接它们在开始和结束之间。
图 3.10 – 向动作 1 添加代码阶段
-
查看
Program.cs的第 12-20 行。注意它包含多个private static readonly string语句。这些语句定义了训练数据文件（第 15 行）和模型输出文件（第 20 行）的路径。在对象图中添加两个Text来表示这些。将一个数据项命名为DataPath，另一个命名为ModelPath。 -
将
DataPath设置为C:/Users/Public/wikiDetoxAnnotated40kRows.tsv，将ModelPath设置为C:/Users/Public/ch3_SentimentModel.zip：
图 3.11 – 设置 DataPath 和 ModelPath 的初始值
- 双击
Code1。添加两个与数据项DataPath和ModelPath对应的输入。
图 3.12 – 将两个数据项作为输入添加到代码阶段
- 点击代码窗口中的
Main(string[] args) { [Copy the text here] }。这些是Program.cs的第 24 行到第 68 行。你的代码窗口中应该有 45 行代码。
图 3.13 – 应该在窗口中的 45 行代码
-
点击
.dll缺失。例如，你可能会遇到你必须添加对程序集'Microsoft.ML.Core'的引用或你必须添加对程序集'Microsoft.ML.DataView'的引用。关闭检查代码窗口并按确定保存代码阶段。 -
通过在 NuGet 网站上搜索
lib\netstandard2.0\Microsoft.ML.DataView.dll文件从 NuGet 包到 BP 安装文件夹位置找到Microsoft.ML.DataView.dll文件。关闭并重新启动 BP。 -
在
Microsoft.ML.Core.dll和Microsoft.ML.DataView.dll上打开对象的属性作为外部引用。按确定关闭对象的属性。
图 3.14 – 将两个新的外部引用添加到对象的属性中
- 返回到
Code1阶段并再次点击检查代码。应该仍然有四个编译器错误，它们没有给出需要导入哪个程序集或命名空间的明确指示。
图 3.15 – 剩余的四个编译器错误
到目前为止，我们还没有一个工作的代码阶段，但我们已经接近了！让我们逐一调查和解决剩余的编译器错误。
修复单个编译器错误
没有编译器错误有明显的解决方案。我们需要依赖 API 文档来找出需要添加哪些命名空间或程序集。让我们按照错误发生的顺序来处理它们：
-
查看第 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，但不能以这种方式添加。相反，我们需要在源代码本身中提供整个命名空间。 -
在第 8 行打开
Code1阶段，并在TrainTestSplit前加上Microsoft.ML.DataOperationsCatalog。现在第 8 行应该是这样的：Microsoft.ML.DataOperationsCatalog.TrainTestData trainTestSplit = mlContext.Data.TrainTestSplit(dataView, testFraction: 0.2); -
点击检查代码。查看第 8 行的编译错误是否已消失。
-
查看第 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
- 在对象的属性中将
Microsoft.ML.Transforms.dll添加为外部引用，并通过按确定按钮关闭对象的属性窗口。
图 3.17 – 添加 Microsoft.ML.Transforms.dll 作为外部引用
-
验证第 13 行的编译错误是否已消失。
-
查看第 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
-
在对象的属性中将
Microsoft.ML.StandardTrainers.dll添加为外部引用。按确定按钮关闭属性窗口。 -
验证第 16 行的编译错误是否已消失。
剩下的第 26 行的最后一个编译错误是关于一个帮助将结果打印到控制台窗口的实用程序 (ConsoleHelper.PrintBinaryClassificationMetrics)。由于我们的目标是让这个程序从 BP 运行，我们将不会看到任何控制台窗口。让我们将 C# 代码更改为将输出写入文件。
将控制台输出更改为文件
ConsoleHelper.cs 文件位于 github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/common/ConsoleHelper.cs。我们可以将那个函数的代码复制到我们的对象的属性中的 全局代码 部分，并将第 26 行更改为从我们的代码阶段调用该函数。然后，我们将更改打印到控制台窗口为写入文件：
- 在 GitHub 上打开
ConsoleHelper.cs文件，并将第 41-57 行的PrintBinary ClassificationMetrics(…)函数复制到你的对象的属性中的 全局代码 部分：
图 3.19 – 将 PrintBinaryClassificationMetrics() 复制到全局代码
-
打开
Code1阶段，在第 26 行删除Console.Helper.前缀。第 26 行应显示PrintBinaryClassificationMetrics(trainer.ToString(), metrics);。 -
点击 检查代码 并确认没有更多的编译错误。
-
打开对象的属性，并将
System.IO添加到 命名空间导入。这是写入文件所需的。
图 3.20 – 将 System.IO 添加到命名空间导入
-
返回到
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); -
删除代码窗口底部的最后两行。它们如下所示：
Console.WriteLine($"================End of Process.Hit any key to exit=================================="); Console.ReadLine();可以安全地删除它们，因为它们的作用是暂停控制台窗口，以便你可以查看打印的文本，这现在不再是必要的。
-
将以下三行粘贴到代码窗口的底部：
Console.SetOut(oldOut); writer.Close(); ostrm.Close(); -
按 确定 保存代码窗口。
现在所有编译错误都已解决，我们可以下载训练数据并测试 ML.NET 代码阶段。
运行 ML.NET 程序
我们接近终点线了！我们需要下载训练数据，将其复制到正确的位置，并运行我们的模型：
-
从
github.com/dotnet/machinelearning-samples/blob/main/samples/csharp/getting-started/BinaryClassification_SentimentAnalysis/SentimentAnalysis/Data/wikiDetoxAnnotated40kRows.tsv下载训练数据。确保文件以.tsv文件格式下载，而不是.txt文件。 -
将
.tsv文件复制到由DataPath数据项指定的位置，C:/Users/Public/wikiDetoxAnnotated40kRows.tsv。 -
点击“操作 1”页面，并在对象工作室中运行它。
-
注意到有一个错误：“内部：无法执行代码阶段，因为代码阶段抛出异常：无法加载文件或程序集
System.Collections.Immutable, Version=1.2.3.0”。 -
通过在 NuGet 网站上搜索
lib\netstandard2.0\Systems.Collections.Immutable.dll文件从 NuGet 包中找到，将其放入 BP 安装文件夹位置。关闭并重新启动 BP。 -
再次从对象工作室运行“操作 1”页面。注意到有一个错误：“Shuffle 输入游标读取失败，异常”。这个错误不是很有用，但我们可以将代码阶段包裹在 try / catch 语句中，以获取完整的堆栈跟踪。完整的堆栈跟踪揭示了另一个缺失的依赖项，
Microsoft.ML.CpuMath。 -
通过在 NuGet 网站上搜索“lib\netstandard2.0\Microsoft.ML.CpuMath.dll”文件从 NuGet 包中找到，将其放入 BP 安装文件夹位置。实际上，此程序集还依赖于一个名为 CpuMathNative.dll 的文件。这个文件通常由机器学习工程师提供，因为它将作为他们代码项目的一部分构建。
-
从 GitHub 下载
CpuMathNative.dll（假设这是由机器学习团队提供的）：github.com/PacktPublishing/Intelligent-Process-Automation-with-Blue-Prism/blob/main/ch3/CpuMathNative.dll，并将其复制到 BP 安装文件夹。关闭并重新启动 BP。 -
再次从对象工作室运行“操作 1”页面。
-
打开
C:\Users\Public\ch3_output.txt并确认其外观类似于以下图示：
图 3.21 – 包含在 ch3_output.txt 中的重定向控制台输出
此文件显示了句子的训练准确性和对“我爱这部电影！”的样本预测结果。
- 确认存储在
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 - 重构
在本章的最后一个例子中，我们将查看第二个例子的重构版本，它改进了功能、可重用性和日志记录：
-
在对象工作室的
Ch3组中打开Example 3 – Sentiment Analysis for User Reviews (Refactored)对象。 -
无需编辑对象图即可访问
.zip文件。
图 3.22 – 训练数据路径和保存的模型路径存储为环境变量
- 注意，训练模型路径现在与预测模型路径分开。通过保持这些分开，你可以在继续使用之前的模型进行预测的同时重新训练模型。这是至关重要的，因为新训练的模型在使用生产之前需要经过审查。
图 3.23 – 训练模型路径和预测模型路径不同
-
注意，如果需要更改而不编辑对象图，训练数据与测试数据的比例将作为环境变量暴露出来。构建模型的一部分是围绕训练参数的大量实验。最好不在对象的代码阶段中硬编码训练/测试分割，以防需要更改。另一种有效的设计是将此作为动作的输入。
-
注意，训练、评分、模型保存和预测制作都已拆分为单独的动作。最重要的是，我们现在可以预测而无需每次都训练模型。这也提高了会话日志的精确度。
图 3.24 – 每个机器学习阶段都有自己的动作以改进日志记录和可重用性
- 在每个代码阶段中添加了
try…catch块，将错误消息和成功标志输出回 BP。
图 3.25 – 添加 try…catch 块以改进错误处理
每一页在结束阶段都将这些内容作为输出返回给调用者，而不是将文本写入文件。
- 访问初始化页面，打开对象的属性，查看全局代码。你会看到为了适应所有这些变化，已经添加了许多新的静态变量：
图 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 预测将给出一个预测值，无论是数字、标签、图像还是生成的文本，以及一个置信度分数。一个明智的干预决策通常会考虑这两个因素，但仍有理由仅基于其中一个因素进行干预。
随机抽样
决定哪些工作案例应该手动审查的最简单方法是通过随机抽样：
-
要使用随机抽样，选择一个您希望用于手动验证的目标百分比，例如，10%。
-
在 ML 预测之后生成一个介于 1 到 100（包括 100）之间的随机数。如果随机数低于所选目标（本例中为 10），则自动化处理将停止，等待对预测的人工审查。
-
在审查过程中，审查员可以纠正预测并允许工作案例继续，或者完全暂停自动化处理。
在一个实际案例中，IA 团队选择了 25%的随机抽样目标。随机抽样 25%案例进行手动审查的主要目的是跟踪预测准确性。尽管随机抽样并没有明确指出是为了降低风险而使用的，但它绝对可以用于这个目的。
随机抽样不使用任何预测或置信度分数。这是随机抽样与阈值之间的主要区别，这是一种不同的 HITL 触发器，将在本章后面讨论。请注意，如果我们将目标百分比设置为 100%，我们实际上使得每个预测都必须由人员进行审查。
让我们通过一个示例来看看如何实现随机抽样。我们将经历的四个高级步骤如下：
-
检查示例的发布文件内容。
-
了解如何在 BP 中生成随机数。
-
理解如何通过随机采样触发 HITL 审查来定义使用随机采样的流程的流程。
-
运行示例，在控制室中查看结果。
示例 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 – 随机采样流程的Ch4组。
-
找到名为
Main Page的块。所有流程的主要步骤都应该属于这里。让我们将注意力集中在包含执行随机采样的逻辑的03 Random Sampling页面上：
图 4.2 – 主页上的工作块中的随机采样
- 打开
03 随机抽样页面。双击Get-Random函数，并传入最小值和最大值1.0和100.0。添加的小数点.0非常重要，因为它允许生成小数。如果省略，Get-Random返回整数值。由于我们的随机抽样目标是小数，33.33，因此需要小数：
图 4.3 – 使用 PowerShell 的 Get-Random 生成随机数
- 双击 需要手动审查？ 决策阶段。在这里，我们将 PowerShell 生成的随机数与环境变量的值进行比较。如果比较是
主页面：
图 4.4 – 确定是否需要手动审查的标准
我们已经完成了对随机抽样逻辑的审查。接下来，让我们看看如何在等待 HITL 审查完成的同时，防止工作队列项目工作。
推迟、选择和状态
主页面 包含三个重要的阶段，这些阶段构成了防止工作队列项目在待审期间继续进行的逻辑。在本例的这一部分，我们将检查这三个阶段——检查状态、手动审查和将项目推迟至手动审查：
图 4.5 - 阻止项目在审查待定期间继续进行的阶段
-
返回到
主页面并双击 手动审查？ 决策阶段。这个阶段检查在03 随机抽样页面上设置的标志。如果需要手动审查，执行将继续到推迟项目至手动审查页面。 -
打开
推迟项目至手动审查页面。这里只发生两件事。首先，当前工作队列项目的 状态 被设置为 手动审查所需。接下来，工作队列项目被推迟 10 分钟。10 分钟的推迟时间是任意的，可以根据您的喜好进行调整：
图 4.6 – 推迟项目至手动审查页面设置项目状态并推迟
- 返回到
主页面并双击 检查状态 选择阶段。在本例的上下文中，选择阶段主要用于不断推迟具有 手动审查所需 状态的项目，直到状态变为 手动审查完成：
图 4.7 - 如果项目未被审查，状态检查将阻止推迟的项目继续进行
还要注意，第三个选项总是将手动审查标志设置为 True，以便将尚未审查的推迟工作队列项目再次推迟：
图 4.8 – 延迟持续到状态变为手动审查完成
如果手动审查标志为False（随机生成的数字大于或等于 33.33），或者如果工作队列项状态被更改为手动审查完成，自动化处理可以继续。
运行流程
现在，让我们运行一次流程。该流程将九个项目加载到名为第五章 示例 1 队列的工作队列中。由于我们的采样率为 33.33%，我们预计每次运行流程时，大约有三项被延迟以供 HITL 审查：
-
从控制室运行名为示例 1 – 随机抽样的流程，在Ch4组中。你将看到每次做出预测时都会弹出 PowerShell 窗口。
-
在队列管理下的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 中的阈值。在以下示例中，我们将执行三个高级步骤：
-
检查示例的 Release 文件内容，并下载一个存储阈值标签和值的 Excel 文件。
-
看看阈值逻辑如何在 BP 中实现。
-
运行示例以在控制室中查看结果。
示例 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 – 发布文件内容
-
从
github.com/PacktPublishing/Intelligent-Automation-with-Blue-Prism/blob/main/ch4/Ch4%20Example%202%20Thresholds.xlsx下载 Excel 文件。 -
将 Excel 文件复制到
C:\Users\Public文件夹，并确保文件名为Ch4 Example2 阈值.xlsx。 -
打开 Excel 文件。此文件存储了不同标签的所有阈值。根据 表 4.3 中选择的阈值，非有毒 标签的阈值设置为 75，有毒 标签的阈值设置为 100。100 表示所有内容都需要人工审核。虽然可以使用环境变量来存储阈值值，但如果存在多个标签，管理起来可能会变得困难：
图 4.11 – 存储在 Excel 文件中的阈值值
接下来，让我们在流程工作室中查看流程并检查与阈值化相关的 BP 阶段。与延迟和状态相关的流程部分将不会在本章的 示例 1 中讨论。
阈值化
在这里，我们将查看 BP 流程中与阈值化逻辑相关的区域。这包括一个将阈值 Excel 文件转换为集合、一个全局数据项和一个检查阈值值的决策阶段：
-
在流程工作室的 Ch4 组中打开 示例 2 – 阈值化 流程。
-
注意到有一个名为
Convert Thresholds to Collection的页面。这个页面将 Excel 文件中保存的阈值映射到集合中。这个Threshold集合存储在Main Page上作为一个全局数据项：
图 4.12 – Excel 阈值被转换为集合
- 打开
03 阈值化页面。有两点需要注意。首先，我们正在通过预测为这个工作队列项目运行所预测的标签来过滤Threshold集合。这允许我们按标签设置阈值。其次，在结束阶段之前有一个 决策 阶段，其中包含确定此项目是否需要人工审核的逻辑：
图 4.13 – 决策阶段的阈值化逻辑
运行流程
示例 2 将 10 个静态用户评论加载到工作队列中。有一个有毒用户评论被正确标记为有毒。还有一个用户评论被预测为非有毒，但置信度低，需要 HITL 审核。
-
在 Control Room 的 Ch4 组下运行名为 示例 2 – 阈值化 的流程。等待会话完成。
-
在 队列管理 下的 第四章 示例 2 队列 中点击 Chapter 4。
-
注意到有两个项目因为需要人工审核而被延迟：
图 4.14 – 确认需要人工审核的项目已被延迟
我们已经看到如何将随机抽样和阈值设计到 BP 流程中。这两种方法都使用相同的基本设计结构，包括使用状态和延迟。在随机抽样和阈值之间进行选择是一个商业决策，而不是技术决策。
到目前为止，我们方便地忽略了审阅者如何将审阅过的预测数据提交回 BP。这是下一节的主题。
我们如何共享预测数据在预测审阅者和 BP 之间？
在前两个示例中，我们没有展示如何将纠正过的预测反馈到 BP 中，以便案件可以继续。为了实现这一点，我们需要一个在 BP 和审阅者之间共享数据的地方。有四种常见的方法可以实现这一点：
-
通过将预测数据复制到共享文件夹位置
-
通过程序化调用或 API 调用上传预测数据
-
通过将预测数据存储在数据库中
-
通过电子邮件或其他消息服务发送数据
上述列表并不全面；例如，可以使用 FTP。然而，使用共享文件夹和 API 调用是共享 BP 和审阅者之间纠正预测所需数据的最常见方式。
我们还需要考虑是否存在服务等级协议（SLA）的担忧，这意味着审阅必须在一定时间内完成，以确保其余的处理可以按时完成。如果是这样，我们可能希望选择具有内在通知功能的审阅方法，例如电子邮件或即时消息。
通过共享文件夹审阅预测
通过共享文件夹在人类和数字工作者之间共享数据是常见的 RPA 实践。然而，当使用共享文件夹来审阅机器学习预测时，设计变得更加复杂，因为需要考虑更多因素。以下是一些例子：
-
什么文件格式（用户界面）最合适？例如，包括纯文本文件、Excel 文件、HTML 文档等等。这取决于需要向审阅者展示多少种类型的数据。如果我们正在验证一段文本是否被正确标记，一个文本文件可能就足够了。如果我们有表格形式的输入数据，例如商店 ID、产品 ID、价格等等，Excel 可能更合适。如果我们需要向审阅者展示图像，我们可以考虑使用基于网络的界面。
-
每个文件中应该包含多少预测？是只有一个，还是我们可以将批量审阅合并在一起？这取决于审阅案例的数量、审阅过程的复杂性、服务等级协议（SLA）以及可供审阅预测的人数。
-
BP 如何知道审阅是否已经完成？
让我们通过扩展示例 1 – 随机抽样流程，包括共享文件夹作为界面，在审阅者和 BP 之间传输预测数据来探讨这些设计考虑因素。
示例 3 – 通过共享文件夹复制数据
在示例 1 – 随机抽样流程中，我们根据客户的特点，如职业类别和忠诚度计划中的积分数量，预测客户是否会流失。由于这是表格数据，我们将选择通过Excel来展示这些数据以供复查。
随机抽样率为 33.33%时，许多预测都需要进行复查。业务也认为审查单个案例并不简单。基于这两个因素，团队决定将预测批量分成每个 Excel 文件五个，以便将复查工作分散到多个复查员之间，同时避免让任何一位复查员一次性进行过多复查而感到压力。
我们这个示例的目标是看看我们如何构建一个涉及使用共享文件夹并将多个预测批量放入 Excel 文件的预测复查方案。从高层次来看，我们将进行以下六个步骤：
-
检查示例的发布文件内容。
-
看看需要复查的预测是如何首先写入临时文件夹中的 Excel 文件，以及一旦达到批量大小，如何将 Excel 文件移动到“准备复查”文件夹。
-
看看复查员如何在 Excel 文件中复查预测，并通过将文件复制到“完成复查”文件夹来通知 BP 复查已完成。
-
理解 BP 逻辑以识别并进一步处理已完成人工复查的项目。
-
看看如果在会话结束前未达到完整的批量大小，如何复制临时文件夹中剩余的复查。
-
运行示例，在控制室中查看结果。
检查.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。
接下来，让我们看看流程图：
-
在流程工作室的 Ch4 组中打开 Example 3 - Random Sampling with Shared Folders。
-
打开
Defer Item for Manual Review页面。 -
查看名为 Do not Reset to Initial Value 的块。在将不同工作队列项目之间的相同 Excel 文件进行批量写入时，需要两个在页面重新运行时不重置其初始值的 Data Items。当前批量计数跟踪已写入当前 Excel 文件中的预测数量。Excel 文件名存储一个包含运行时资源名称和时间的唯一文件名。在 Excel 文件名中包含运行时资源的名称是逻辑设计的重要部分，因为它允许数字工作者知道它在共享文件夹中创建了哪些文件。
图 4.16 – 两个未重置其值的数据项
- 检查名为
Writing the Temporary Excel file的块。块内的逻辑将一个预测写入一个 临时 文件。此临时文件应不可访问给评审人员：
图 4.17 – 将一个预测写入临时文件
Create New Excel File? 决策阶段的 Yes 路径用于创建新的 Excel 文件。No 路径用于将现有 Excel 文件写入以批量合并评审。这些都在 临时 文件夹中完成。
- 查看紧随 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 审阅，我们可以在控制室手动更改其状态并修改其延期时间到一个更早的日期时间。
检查已审阅预测并更新项目状态
让我们了解检查已完成审阅的逻辑：
- 访问流程的“主页面”。注意，在“获取下一个项目”之前有一个名为“检查已审阅预测”的页面：
图 4.20 – 在处理工作队列项目之前检查已完成审阅的情况
-
打开“检查已审阅预测”页面。此页面遍历Ch4 Example 3 完成审阅文件夹中的所有 Excel 文件并读取所有行。然后，它尝试根据项目 ID 来锁定每个项目，以便更新其状态。更新状态后，项目被解锁，允许它再次被工作队列选中。
-
定位以下图中所示的四个阶段：
图 4.21 – 锁定项目，更新状态，然后解锁
如果我们成功更新了项目的状态，将设置一个重写 Excel 文件所需标志，表示流程需要从 Excel 文件中删除一些行（已审阅预测）。从完成后的 Excel 文件中删除一行意味着项目可以在审阅后继续处理步骤。
如果我们无法锁定项目，我们将设置一个不同的标志，Failed to Lock，表示我们遇到了这个 Excel 文件的问题。任何我们无法锁定的项目都将添加到一个新的集合中，用于跟踪目的。那些我们未能更新状态的项目将不会从 Excel 文件中删除，以便在未来的会话运行中再次进行检查。
图 4.22 – 将无法锁定到集合中的项目存储
- 定位以下图中显示的两个阶段。如果
Failed to Lock标志表示我们已经成功更新了此 Excel 文件的所有项目状态，则从文件夹中删除 Excel 文件：
图 4.23 – 如果我们成功更新所有五个预测的状态，则删除文件
- 定位以下图中显示的六个阶段：
图 4.24 – 删除状态成功更新的 Excel 行
如果流程未能更新某些项目的状态，则覆盖 Excel 文件，使其仅包含那些失败的行（这些行已在图 4.22中单独保存）。这从 Excel 文件中删除了状态成功更新的预测。在下一个会话运行时，将执行此检查已审查预测页面，流程将尝试再次更新这些项目的状态。
清理临时文件夹中的文件
Excel 文件可能会卡在关闭``下页面：
-
打开
关闭下页面。注意在结束前有一个移动临时文件页面。 -
打开
移动临时文件页面。此页面遍历临时文件夹中的所有文件，并且只有在它们是由这个特定的运行时资源创建的情况下才会移动它们。此文件夹中由其他运行时资源创建的文件将不会移动。这是通过在 Excel 文件名中检查完整的运行时资源名称来实现的。
图 4.25 – 移动临时文件页面
运行流程
我们现在已经看到了使用 Excel 和共享文件夹实现的 HITL 审查的示例。接下来，我们需要测试该流程。当运行时，将随机生成 30 名客户，算法将预测他们是否会流失。在 33.33%的随机抽样率下，我们预计大约需要手动审查 10 个预测。
重要提示
在测试Example 3时，不要在控制室和流程工作室之间混合运行。这是因为流程工作室会将_DEBUG添加到运行时资源名称的末尾。在移动临时文件和手动审查项延迟页面中，我们使用 Excel 文件名中的运行时资源名称。如果我们一次在流程工作室中运行一次，一次在控制室中运行，运行时资源名称将不会匹配，并且移动临时文件页面不会将一些 Excel 文件移动到审查文件夹。
-
从控制室开始Example 3 – 使用共享文件夹的随机抽样流程的Ch4组。等待会话完成。
-
打开控制室并点击第四章 Example 3 队列。应该有许多项目正在等待手动审查。记下需要审查的项目数量。在以下图中，有七个：
图 4.26 – 计算等待手动审查的项目数量
-
在 Windows 中打开对应于Ch4 Example 3 To Review Folder Path的文件夹。该文件夹中 Excel 文件的数量应该是**(需要审查的项目数量)/5*，向上取整。例如，如果你有七个需要手动审查的项目，我们应该有两个 Excel 文件。
-
打开每个 Excel 文件，确保每个文件中（不包括标题）的累积行数等于需要审查的项目数量。根据步骤 2中的屏幕截图，我们的第一个文件应有五行，我们的第二个文件应有两行。
-
将Ch5 Example 3 To Review Folder Path中的所有 Excel 文件剪切并粘贴到Ch5 Example 3 Completed Review Folder Path。这模拟了完成所有机器学习预测审查的过程。
-
访问 BP 的系统区域。将Ch4 Example 3 Random Sampling Target环境变量从 33.33 更改为 0 并点击应用。这将在下一次会话运行时关闭随机抽样，这意味着 30 个新项目都不需要手动审查。
-
等待所有延迟的工作队列项的延迟时间通过。
-
再次从控制室运行流程。将创建一个新的包含 30 名客户的批次并对其进行预测。等待会话完成。
-
打开控制室并点击第四章 Example 3 队列。所有 60 个工作队列项应标记为完成，没有项目需要手动审查。
-
在 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）流程。
734
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
