GCP-上的人工智能实用指南-全-

GCP 上的人工智能实用指南（全）

原文：Hands-On Artificial Intelligence on Google Cloud Platform

协议：CC BY-NC-SA 4.0

零、前言

在计算过程中，我们正处于一个有趣的关头。 大多数企业工作负载（数据库，计算和分析）都移到了云上。 云计算使任何人都可以便捷地使用高端计算能力。 结果，我们看到各种规模的个人和组织使用计算资源的方式发生了根本性的变化。 云计算基础架构的提供商还启用了软件即服务（SaaS）范例。 这样，与存储，计算，机器学习和可视化相关的各种服务就可用，而无需执行任何服务器管理或管理。 根据我们的经验，我们看到的根本转变是朝着无服务器架构迈进。

目前，Google Cloud Platform（GCP）是 Google 基于多年的创新和研究而提供的完整平台，为建立迄今为止最强大的搜索引擎做出了贡献。 现在，相同的技术栈已经可以通过 Google 在商业上使用，因此，每个人都可以使用海量的计算能力。 借助 GCP 上可用的工具，可以轻松构建复杂的数据管理管道以及机器学习/ AI 工作流程。 这种普及为开发社区提供了巨大的力量，可以构建尖端的，创新的，智能的应用，这些应用可以补充人类的智能并多次提高人类的能力。

本书旨在简化使用 GCP 构建智能 AI 系统的入门。 我们采用了动手方法来解释 GCP 上可用于促进 AI 开发的各种概念和组件。 我们希望这本书将成为开始探索令人兴奋且不断扩展的计算世界以在 GCP 上构建支持 AI 的应用的良好起点。

这本书是给谁的

本书适用于计划使用 GCP 构建 AI 应用的软件开发人员，技术主管和架构师。 除此之外，学生和任何对 AI 应用有很好的主意并希望了解可用工具和技术来快速构建原型并最终用于生产级应用的人都将从本书中受益。 本书对业务分析师和从业务角度了解数据格局的任何人也很有用。 无需大量的动手经验，就可以按照本书来基于领域知识构建支持 AI 的应用。 我们试图逐步提供这些说明，以使读者发现它们易于遵循和实现。

本书涵盖的内容

根据所涵盖内容的逻辑分组，我们将本书分为四个部分。 第 1 节提供了 GCP 的基本介绍，并向读者介绍了 GCP 上可用的各种工具。

“第 1 章”， “GCP 上的 AI 概述”设置了云上无服务器计算的上下文，并向读者介绍了 GCP。

“第 2 章”，“使用 GCP 组件进行计算和处理”向读者介绍 GCP 上用于端到端数据管理的各种工具和应用，这对于在其上构建 AI 应用至关重要 GCP。

“第 3 章”，“带有 XGBoost 的机器学习应用”显示了如何在 GCP 上使用最流行的机器学习算法之一 XGBoost。 这个想法是让读者理解机器学习算法可以在 GCP 上使用，而不必担心基础架构和计算资源。

“第 4 章”，“使用 Cloud AutoML” 将帮助我们迈出迈向机器学习普及的第一步。 AutoML 旨在提供机器学习即服务，并使对机器学习模型和核心实现细节了解有限的任何人都可以轻松地使用机器学习模型构建应用。 我们将使用 AutoML 向您介绍自然语言和视觉界面。

“第 5 章”，“构建大数据云机器学习引擎”将探讨云中机器学习的一些基础知识。 关于云上的机器学习模型，存在范式转变。 我们需要了解云计算的各种概念，以及如何利用存储和计算来构建和部署模型。 这是了解我们是否要优化在云上训练和运行机器学习模型的成本的必要章节。 我们将研究 Keras 等各种框架，并了解如何在 GCP 上使用它们。

“第 6 章”，“使用 DialogFlow 的智能对话应用”讨论了机器智能的对话界面，这是整体 AI 功能的重要组成部分。 在本章中，我们将了解如何使用 DialogFlow 来构建对话应用。 DialogFlow 提供了简单的 Web 和 API，用于快速构建对话应用。 一旦针对大量对话路径训练了模型，便可以提供类似人的口头交流。

“第 7 章”，“了解云 TPU” 讨论了张量处理单元（TPU），它们是 GCP 机器学习模型背后的基本构建块。 在本章中，我们将向读者介绍 TPU，并讨论它们的组织结构和在 GCP 上加速机器学习工作流程的重要性。 如果我们要优化性能并提高速度，则必须利用 TPU 的强度。

“第 8 章”，“使用 Cloud ML Engine” 实现 TensorFlow 模型，将进一步探讨 ML Engine，并说明如何在 ML Engine 上构建 TensorFlow 模型。 我们将采用逐步的方法来在 GCP 上训练和部署机器学习模型。 我们将研究在 GCP 上构建机器学习管道的推荐最佳实践。

“第 9 章”，“构建预测应用”解释了在 GCP 上构建预测应用的过程。 我们从讨论预测过程的基础开始，并逐步采用动手方法来使用 GCP 构建预测应用。 我们将在平台上训练和部署模型，并利用 API 层与已部署的模型进行交互。

“第 10 章”，“构建 AI 应用”将利用 GCP 的各种组件来构建端到端 AI 应用。 我们将通过一个示例用例进行说明：使用 GCP 上的工具自动化发票处理工作流。

充分利用这本书

为了在 GCP 上快速构建 AI 应用，建议顺序阅读本章。 每章都建立在前几章介绍的概念之上。 我们强烈建议读者将本书视为概念的动手指南，并通过与个人或组织帐户进行 GCP 练习来遵循这些步骤。

下载示例代码文件

您可以从 www.packt.com 的帐户中下载本书的示例代码文件。 如果您在其他地方购买了此书，则可以访问 www.packtpub.com/support 并注册以将文件直接通过电子邮件发送给您。

您可以按照以下步骤下载代码文件：

  1. 登录或注册 www.packt.com 。
  2. 选择“支持选项卡”。
  3. 单击“代码下载”。
  4. 在搜索框中输入书籍的名称，然后按照屏幕上的说明进行操作。

下载文件后，请确保使用以下最新版本解压缩或解压缩文件夹：

  • Windows 的 WinRAR/7-Zip
  • Mac 版 Zipeg/iZip/UnRarX
  • 适用于 Linux 的 7-Zip/PeaZip

本书的代码包也托管在 GitHub 上。 如果代码有更新，它将在现有的 GitHub 存储库中进行更新。

我们还从这里提供了丰富的书籍和视频目录中的其他代码包。 去看一下！

下载彩色图像

我们还提供了 PDF 文件，其中包含本书中使用的屏幕截图/图表的彩色图像。 您可以在此处下载。

使用约定

本书中使用了许多文本约定。

CodeInText：指示文本，数据库表名称，文件夹名称，文件名，文件扩展名，路径名，虚拟 URL，用户输入和 Twitter 句柄中的代码字。 这是一个示例：“Lead_Stage是我们将根据测试数据进行预测的标签。”

代码块设置如下：

if version_name:
        body['predictionInput']['versionName'] = version_id
    else:
        body['predictionInput']['modelName'] = model_id

任何命令行输入或输出的编写方式如下：

curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" -H "Content-Type:application/json" https://automl.googleapis.com/v1beta1/model-name/modelEvaluations

粗体：表示新术语，重要单词或您在屏幕上看到的单词。 例如，菜单或对话框中的单词会出现在这样的文本中。 例如：“在高级选项中，如果数据集具有标题，则将跳过行标记为 1。”

警告或重要提示如下所示。

提示和技巧如下所示。

一、AI 和 GCP 概述

在计算技术发展的紧要关头，我们不断从越来越多的设备和平台生成数据。 现在很清楚，如果使用不当，数据是可以提供竞争优势或劣势的关键因素。 在过去的几年中，我们已经看到，使用云上可用的基础架构可以存储和处理大量数据。

在本章中，我们将介绍云优先策略，企业正在采用该策略对数据执行高级分析。 我们将看到 Cloud First 策略的一些优势以及反模式。 在本章的后续部分中，我们将对 Google Cloud Platform（GCP）进行高层概述。

我们将在本章介绍以下主题：

  • 了解用于高级数据分析的 Cloud First 策略
  • Google 数据中心
  • GCP 概述
  • 人工智能构建块
  • GCP 上可用的 AI 工具

了解用于高级数据分析的云优先策略

对于已开始将数据视为保持相关性的最关键资产的组织而言，2018 年发生了重大变化。 从大数据处理基础架构的“本地”部署到云的过渡已经有了明显的转变。 随着分布式数据管理系统的成熟，企业开始依赖于分布式计算平台来满足其分析和运营需求。 但是，随着增加新的数据源，数据量和后续分析的可能性也在不断增长。 这样，很明显，需要快速进行实验并根据需要缩放（放大和缩小）环境。

一些高级分析工作负载利用机器学习算法，这些算法需要图形处理器（GPU）的集群，以便在合理的时间内提供结果。 也可以按需采购 GPU，然后在云环境中将其无缝释放回资源池。 为了达到最大的业务影响，某些实验需要迅速投入生产。 在敏捷性和快速部署方面，基于云的环境是理想的。 业界已经开始在云上进行部署。 企业不仅看到基础架构即服务（IaaS）的好处，而且还看到高级分析即服务（AAaaS）在云平台上。

自 2018 年初以来，已迅速转向 Cloud First 策略。刚开始实现其数据策略的组织正在将云作为其第一个游乐场，而不是投资于内部部署。 但是，“云优先”并不意味着“数据最后”策略。 在完全由数据驱动的策略中，数据仍然扮演着核心角色。 让我们看一下与本地部署相比，云中数据管理的一些优势。

云优先策略的优势

采用云优先策略具有以下优点：

  • 最低的前期成本：由于服务全天候可用，因此存储和计算基础架构几乎不受限制，并且扩展成本最低。 无需购买任何硬件或从头开始设置应用和软件。 此外，在云平台上虚拟化了基础架构以及软件。 这样可以使企业的前期成本和投资降至最低。 该模型特别适合于开发原型和测试概念证明。 在某些情况下，可以快速验证概念的业务可行性，而不必承担资本支出和其他间接费用。 借助云，可以以最小的成本压力快速测试和部署创新的想法和概念，以立即获得业务收益。
  • 弹性容量：即付即用是建立云服务的核心原则。 尽管仔细的容量规划对于任何成功的数据策略都很重要，但是借助云，我们可以在容量规划方面拥有一定的灵活性。 如果需要更多容量（例如，在线零售商可以预期在黑色星期五期间会有很高的销量），则公司可以在短时间内扩展容量，然后缩减到常规容量。 这种类型的灵活性在数据管理系统的内部部署中不可行。
  • 全局连接：只要可以使用互联网连接以及适当的认证/授权，就可以在全球范围内虚拟访问作为云上可用的基础结构，平台和应用的服务。 通过云提供商跨区域和物理位置的隐式冗余，确保了连接性。 内部部署和拓扑不是客户端考虑或关注的领域。 云端点是一致且无缝的，而与客户端的位置无关。
  • 无缝升级：云提供商可以无缝升级在云上配置的操作系统和应用软件。 这样可以确保所有部署之间的一致性和可靠性，并且非常适合互联网规模的企业应用。 与传统的本地部署相比，传统的本地部署需要在管理服务停机和业务中断的同时，将应用版本和补丁小心地应用于所有节点。 在云环境中，责任完全转移给云提供商，企业可以专注于核心业务应用。
  • 无服务器 DevOps：借助此，应用开发团队可以完全专注于核心业务逻辑。 他们可以根据数据量和计算需求，根据应用范围简单地规定存储和计算需求。 这些团队无需担心任何部署，他们将以最少的配置和扩展时间开始使用服务。 无服务器架构将 Cloud Functions 作为服务公开给云提供商托管应用的地方，并负责管理硬件和相关软件组件。 这种模式提供了进入业务应用，算法和模型开发的快速入门，而不必担心底层基础结构，因此，可以快速构建核心功能以开始实现业务收益。
  • 快速发布时间（TTM）：有了前面列出的所有优点，采用 Cloud First 策略将各种概念和原型的 TTM 降至最低。

Google 通过从头开始构建服务，从而为企业提供云服务时采取了创新的方法。 这些服务最初是由 Google 自己内部用于搜索和其他互联网规模的服务而构建的。 该平台迅速成熟，形成了一套完整的套件，可用于开发整个简单范围的应用，从简单的 Web 应用开始，再到微服务和高级分析，这些功能利用了大量的结构化和非结构化数据以及 GPU 和 张量处理单元（TPU），用于训练计算密集型模型。 在本书的“第 7 章”，“了解云 TPU” 中，我们将深入研究 TPU 并详细了解 TPU。 在本书中，我们将详细了解 GCP 的各个组成部分，并将专门研究如何利用 GCP 将人工智能（AI）工作负载以及各种应用的无缝集成部署为服务。

尽管 Cloud First 策略在实现实实在在的利益方面具有公认的优势和优势，但由于接下来要说明的原因，云的采用也受到了批评。

云优先策略的反模式

尽管云计算是一个新的范例，但仍需要解决某些基本假设和一致的连接性和安全性要求。 以下是“云优先”策略的一些反模式：

  • 停机时间：云服务完全取决于可靠的互联网连接的可用性。 当关键业务应用部署在云上时，互联网停机的风险和影响会增加。 但是，停机风险在本地部署中同样普遍，并且需要仔细考虑架构模式以最大程度地减少这些风险。 借助云，应在设计服务时考虑到高可用性，冗余和灾难恢复。 云供应商为云基础架构提供了多个可用性区域。 应用应利用这些冗余区域来部署关键服务。 在下一部分中，我们将了解 Google 如何通过地理位置分散的数据中心来减轻停机风险。
  • 安全性和私密性：许多管理敏感数据资产的企业在采用云时都担心数据的安全性和私密性。 云是共享空间，因此，风险显而易见。 但是，以下策略可以轻松应对反模式：
    • 在所有部署级别上实现安全治理实践和流程。
    • 实现精心定义的访问控制级别，并为所有用户和进程提供最低级别的访问。 如有疑问，请提供比访问服务和基础结构的更广泛的网络访问更多的受限访问。
    • 对所有用户帐户实现多因素认证。
    • 在所有端点上部署异常检测程序并持续监视云基础架构（自动以及基于样本的手动监视）。

云服务提供商已在保护这些反模式方面进行了大量投资，并且云部署此时与本地部署一样可靠和安全。

在下一节中，我们将根据地理区域和服务可用性来查看 Google 数据中心的当前状态。

Google 数据中心

作为互联网规模的数据托管人，Google 建立了完善的数据中心网络。 现在，相同的基础结构可用于 GCP。 在撰写本文时，GCP 拥有 18 个全球区域，分为 55 个区域，分布在 35 个国家/地区。 以下屏幕快照显示了全球 GCP 区域：

这些地区分为“美洲”（北美和南美），“欧洲”和“亚太地区”。 选择正确的区域和区域对于确保服务和数据的延迟，可用性以及持久性处于可接受的水平至关重要。 确保区域内位置之间的网络数据包的往返延迟为亚毫秒级的 95%。 部署在区域内单个区域上的服务将不会容错。 在这种情况下，区域故障将导致服务中断。 为了开发容错应用，需要跨区域部署。 对于关键任务应用，应实现多区域部署策略。 根据应用和服务的关键级别，将资源分类如下：

  • 区域资源：这些资源在区域内操作。 在这种情况下，如果该区域不可用，则该服务将变得不可访问。 计算引擎是区域资源，因为如果基础数据可用，则可以恢复计算。 如果包含计算引擎实例的区域出现故障，则一旦该区域可用，就需要重新启动计算。
  • 区域资源：这些资源部署在一个区域内，并且在各个区域之间具有冗余性。 这些资源提供的服务不会因为区域故障而中断。 结果，利用区域资源确保了更高的可用性。
  • 多区域资源：一些关键任务服务在区域间冗余部署。 由于地区之间的地理隔离，服务需要与延迟和一致性之间的权衡取舍一致。 这些折衷是基于服务和可接受的服务级别协议（SLA）选择的。 部署在多区域资源上的服务中的数据不属于特定区域，并保持流动性。 可以跨区域传输数据以满足服务级别。

考虑到现有的可用容量和对云计算资源的需求预测，Google 已经在跨地区扩展其业务范围。 通过使用机器学习算法，可以确保最佳利用容量。 从 AI 从业者的角度来看，GCP 提供了可靠的平台，因此我们可以利用无服务器架构范例专注于构建出色的应用。

在下一节中，我们将研究 GCP 的各个组件并熟悉该接口。 这是本书中对平台的基本介绍。

GCP 概述

尽管任何云平台都可以作为虚拟服务通过网络使用，但其核心是系统和物理资源。 如上一节所述，GCP 创建了一个数据中心全球网络，该网络可提供跨区域和区域的服务冗余性，从而提供可靠性。 选择更靠近客户端位置的区域的优势之一是较低的延迟，这在我们处理大量数据传输时起着重要作用。 这些用例需要事件时间和处理时间之间的最小延迟。 GCP 上的所有资源（例如存储和计算）都被视为服务。 该范例称为一切即服务（XaaS）。 这包括 IaaS，平台即服务（PaaS）等。 GCP 上的资源和服务根据抽象性和适用性级别分为全球，区域和区域。 组织在 GCP 上管理的任何资源都必须是项目的一部分。 项目是组织提供的所有资源的顶级抽象。 项目具有各种属性，元数据，资源和访问控制。 项目边界内的资源根据区域和区域限制相互连接，并与内部网络进行通信。 但是，跨项目的资源可能会通过外部网络进行通信。 在 GCP 中，项目由项目名称，项目 ID 和项目编号唯一标识。

GCP 提供了 Web 界面控制台，命令行界面（CLI）和 Cloud Shell，以与各种服务进行交互。 这是 GCP 控制台的屏幕截图：

云服务开发套件（SDK）提供了一个称为gcloud的 CLI 工具，可用于执行所有配置并与平台进行交互。 它也可以用于开发工作流程的管理。 Cloud Shell 提供了与 GCP 进行交互的类似界面，Cloud Shell 是一个基于浏览器的临时 Shell 环境，可以从云控制台内部进行访问。

人工智能构建块

为了构建智能机器或系统，需要一些基本的构建块。 “数据”是 AI 开发和大规模采用的核心。 在本节中，我们将回顾围绕数据的所有构造块。 这是显示 AI 的所有构建块的图：

数据

可以与人类能力相匹配的智能机器的一般概念是在大约一个世纪前提出的，为创建这些智能机器投入了大量的思考和研究。 这些努力为现代 AI 奠定了基础。 但是，研究受到可用数据存储和处理能力的限制，因为构成 AI 基础的机器学习模型需要大量的数据来进行训练，并且需要大量的处理能力来进行算法计算。 由于我们可以存储和处理的数据量很大，现在恢复了 AI 研究领域。 数据是 AI 构建块的核心和焦点。 数据容量分为三个区域：存储，处理和数据驱动的操作。

存储

从本世纪初开始，我们已经看到数字化和存储数字资产的能力急剧上升。 由于采用了云计算，通用存储容量的可访问性也得到了显着提高。 在云计算范例中，存储作为服务可用，不需要采购和管理与存储相关的基础架构。 结果，用于 AI 研究的数据资产的可用性呈指数增长。 下图说明了一段时间内存储容量的增长。 商店的需求正在成倍增长，并且超出了我们目前的限制。 这正在迅速发生。 为了坚持数据量增长的速度，我们描述了一个超出范围的规模：

处理

由于分布式计算框架，我们还看到了整体处理能力的提高。 处理单元分布在各种机器上，以进行并行处理和计算。 框架负责跟踪跨节点的计算，并整合从可行见解中得出的结果。 由于云计算范例（其中计算可作为服务使用），处理能力也大大提高。 在这种情况下，无需为大型数据处理而采购和管理专门的基础架构。 通过增加的处理能力，我们现在能够通过利用大量数据来尝试机器学习算法。 反过来，这又推动了 AI 领域的快速发展。

动作

由于可获得大量数据，并且能够处理这些数据以获取有意义的见解的处理能力，我们能够根据概率模型预测未来的事件和行动。 这些操作基于数据而不是主观判断。 智能机器的基本组成部分之一是根据环境情况采取行动的能力。 该行为应为智能体带来最大的回报。 AI 系统需要促进基于数据的行动而不是主观的人类判断，以便充分增强人类的能力。

自然语言处理

任何 AI 系统的关键组件之一是智能机器和智能体程序的自然语言处理（NLP）接口。 与具有 AI 功能的系统的交互必须以人与人之间交互的自然方式进行。 由于我们交流的程度和模糊性，语言处理非常复杂。 人类语音的合成和分析可以通过使用大量训练数据训练深度神经网络（DNNs）来实现。 尽管 DNN 中有大量数据，但是由于语言中的语义变化，很难达到相同的准确率。 但是，NLP 是 AI 的基本构建块。 在本书的后面，我们将研究 GCP 上可用于 NLP 的各种选项和工具。

语音识别

为了使与智能机的接口尽可能接近人机交互，我们需要语音识别功能。 指令需要作为语音命令给出，并且我们需要复杂的语音识别引擎才能将口语单词转换为机器可读格式。 同样，由于各个人说特定单词的方式有所不同，因此语音识别系统很难获得 100% 的准确率。 该接口需要针对特定​​个人进行校准和训练，并且通用模型需要不断增强，以提高语音识别引擎的整体效率。

机器视觉

为了使 AI 系统充分增强人类的能力，它需要开发一种方法，通过建立以类似于人眼的方式处理视觉信息的能力来收集对环境上下文的理解。 摄像机捕获了视觉效果，并且需要使用大量视频数据来训练模型，以便对环境进行准确的了解。 机器视觉是 AI 的关键元素。 在接下来的章节中，我们将探索机器视觉 API，以及 GCP 中的示例代码。

信息处理与推理

人类善于处理各种感官收集的信息，并善于运用推理以有意义的方式对这些感官做出反应。 智能机器需要类似的功能才能模仿和增强人类的能力。 在 AI 系统的情况下，推理可以基于大量的训练数据以及强化学习引擎。 基于信息的环境上下文的逻辑推理是 AI 系统的关键组成部分。

规划与探索

人脑可以轻松执行的最先进的功能之一是提前计划事件和行动。 此技能要求探索过去的数据以及当前的上下文数据和实时信息。 这些行动是根据牢记的短期和长期目标制定的。 智能体需要具有探索上下文环境数据并根据过去可用数据进行计划的能力。 在地理地图上浏览是规划和探索 AI 功能的一个很好的例子。 制图应用可以基于实时数据探索来建议特定时刻的最佳路线，并且可以基于沿途遇到的新信息来调整路线图。

处理和控制

一些智能体还需要能够处理和控制物理对象。 这包括工业机器人，这些机器人在装配线上处理各种机器零件，将它们放置在正确的位置，然后根据预定义的例程进行应用。 这种类型的系统需要具有一定程度的模糊性以及可以根据环境运行的自学习循环。 不可能为所有可能的情况编程处理和控制功能。 需要以这样的方式构建模型：智能体可以根据环境状态的变化采取行动，同时仍能最大化环境中智能体的总体报酬。

导航和移动

智能体需要能够在物理环境中导航和移动。 自动驾驶汽车或自动驾驶汽车是 AI 系统功能的示例。 为了建立这种能力，需要对智能体进行全面的实际生活中可能遇到的路况训练。 DNN 还需要在尽可能多的场景中进行训练。 真实（非训练）环境中的模型执行需要非常高效，以使智能体能够在关键任务环境中生存，而该任务关键环境要求智能体的事件时间和行动时间之间的等待时间极低。

语音生成

为了使智能体以自然形式交互，它需要能够生成人类语音。 启用语音的系统现在已成为主流，并且比语音到文本的界面更容易构建。 Google 提供了易于使用的语音生成 API。 我们将在本章的下一部分中查看这些 API 和服务，并在本书后面的章节中探索详细的示例。

图像生成

图像生成功能是 AI 系统的另一个组成部分。 图像经过处理和重新格式化，以便从像素数据中获取更多含义和信息。 图像生成功能可用于医学图像处理以及高端法医研究。

在下一节中，我们将介绍 GCP 中可用于促进 AI 各个构建模块的工具。

GCP 上可用的 AI 工具

Google 简化了在 GCP 上使用现成的 AI 构建块构建 AI 系统的过程。 GCP 上提供了三类组件和工具：视觉，语言和会话。

Sight

Sight 是指智能机器的可视界面。 GCP 提供以下用于视觉信息和情报的 API：

  • Cloud Vision API：这是在 GCP 上经过预先训练的模型之上的表述性状态转移（REST）API 抽象。 API 可以将图像分为通用类别和特定对象。 它还可以读取图像中的文本。 随 Cloud Vision API 开箱即用地提供了图像元数据管理以及对特定应用不需要的内容的审核。 从图像中收集见解非常简单，无缝。 此 API 的一些常见用例是图像搜索，文档分类和产品搜索（零售）。 下图显示了 Cloud Vision API 的各种应用和用例：

  • Cloud Video Intelligence API：这是一种 REST API，可以从视频供稿中提取信息，并可以从视频数据中搜索和提取元数据。 该 API 易于使用，并且包含超过 20,000 个预定义标签的列表。 该 API 还提供了视频标签和内容之间的互操作性，当视频资产存储在 Google Cloud Storage 中时，可以跨视频资产进行基于文本的搜索。 下图显示了 Cloud Video Intelligence API 的各种应用和用例：

  • AutoML Vision：此服务可以定制训练模型以对视觉图像进行分类。 可以使用易于使用的界面对模型进行训练和评估。 也可以使用唯一的名称空间注册它们，以便通过 AutoML API 使用它们。 如果用户有大量要标记的图像，则可以使用人工标记服务来补充 AutoML Vision API。 可以通过 AutoML Vision 用户界面直接启动人工标签。

语言

GCP 通过翻译和自然语言 API 提供用于语言信息和情报的 API，如下所示：

  • Cloud Translation API：此 API 根据预先训练的模型以及可以使用 AutoML 翻译框架进行训练的自定义模型，在两种语言之间提供双向翻译。 当源文本的语言未知时，API 还可促进语言检测。 与其他 AI 服务类似，翻译服务也可用作 REST API，用于在应用内进行编程访问和集成。 在撰写本文时，支持 100 种语言。 无需显式解析即可翻译 HTML 内容的独特功能使提供网页翻译以及创建多语言站点和应用变得容易。
  • Cloud Natural Language API：此 API 提供了对基于预训练模型以及可以使用 AutoML Natural Language 框架进行训练的自定义模型的非结构化文本和音频数据的见解。 API 可以根据各种形式的非结构化文本来收集有关人员，地点，事件，情感等的信息。 在内部，该服务利用丰富的本体图和不断发展的模型来提高准确率。 此 API 可能会使用的一些常见用例是客户情感分析和产品分类（零售市场研究）。 易于使用的 REST API 有助于语法分析，实体识别，情感分析和内容分类，并支持多种语言。

GCP 提供了 API，可通过 Dialogflow 和 Google Cloud TTS/STT API 与智能机实现语音和对话界面。

对话

对话界面是支持 AI 的应用的重要方面。 GCP 提供了 Dialogflow 引擎，用于通过简单的界面和 API 创建企业级的对话应用，如下所示：

  • Dialogflow Enterprise Edition：此服务使用预先训练好的随时可用的底层深度学习模型，为应用的会话界面创建提供便利。 会话服务可用于具有网站，移动应用甚至物联网（IoT）设备的用户的自然界面。 在编写本书时，该服务支持 20 种语言的对话界面。 Dialogflow 与 Natural Language API 无缝集成，以便在进行实时对话时执行情感分析。 这有助于为客户提供特定于客户的针对性服务。 该界面可能的一些用例包括企业生产率的提高，面向最终客户的自助业务交易以及与 IoT 设备的自然语言通信。
  • Cloud TTS API：此 API 有助于从输入文本合成人类语音。 该服务具有多种语言和变体，可以为应用创建自然语言界面。 负责文本到语音转换的机器学习模型已经过预先训练，并且不断发展以提高准确率和保真度，使其尽可能接近自然的人声。 可以通过 TTS API 实现的一些常见用例包括呼叫中心自动化，与 IoT 设备的交互以及将文本转换为音频以供阅读器使用。
  • Cloud STT API：此 API 基于强大的模型，这些模型经过预先训练，可以将音频输入转换为多种语言的文本。 该 API 支持实时流式传输或预先录制的音频输入。 它还具有自动检测语言的能力，并支持将短格式和长格式音频片段实时转换为文本。 在编写本书时，语音到文本接口有四类预训练的模型。 这些模型适用于特定的用例和对话界面：
    • command_and_search：可用于短命令和语音搜索。
    • phone_call：用于来自电话对话的音频。
    • video：适用于作为视频信号一部分或以更高采样率录制的音频。
    • default：这是通用模型。

本节中列出的所有服务和 API 均可与智能机实现自然的接口，并且是 AI 的构建块。 在本书中，我们将通过代码示例详细探讨这些 AI 工具。

总结

在本章中，我们已经了解了 Cloud First 策略，以及这对于开发利用 AI 的现代应用是当务之急的选择。 另外，我们已经简要地看到了各种系统的基于云的实现的反模式。 我们还介绍了 GCP，它是基于 Google 在管理大量数据方面的经验而构建的。 随着时间的推移，该平台正在得到丰富和扩展。 我们研究了通用 AI 系统的各种构建块，并研究了 GCP 上可用的工具，这些工具可以以无服务器方式无缝地促进 AI 应用的开发。

在下一章中，我们将研究 GCP 上可用于计算和处理 GCP 上的数据资产的各种组件。

二、使用 GCP 组件的计算和处理

在云中构建和运行人工智能（AI）应用之前，了解可用的不同选项非常重要。 这将帮助我们为应用选择正确的选项，以确保我们以经济高效的方式获得最佳性能。

在本章中，我们将深入探讨可用于在 Google Cloud Platform（GCP）上构建和运行 AI 应用的选项。 我们将研究 GCP 上可用的计算，处理和存储选项，以及业务流程和可视化。 一旦我们对这些选项有了充分的了解，我们将在本章的结尾部分介绍一个动手例子。

在本章中，我们将研究以下主题：

  • 了解计算选项
  • 进入存储选项
  • 了解处理选项
  • 创建构建机器学习（ML）管道的示例

了解计算选项

GCP 提供了各种计算选项来部署您的应用，并使用实际的 Google 基础架构来运行您的应用。 可用的选项如下：

  • 基础架构即服务（IaaS）
  • 容器
  • 平台即服务（PaaS）

所有计算选项均与其他 GCP 服务和产品进行通信，例如存储，网络，Stackdriver，安全性和大数据产品套件。 根据给定应用的需求，从 Compute Engine，Kubernetes Engine，App Engine 和 Cloud Functions 中选择适当的计算选项。

Google 计算选项可帮助您在 Google 基础架构上运行多种大小的虚拟机并对其进行自定义。 它使您能够运行容器化的应用，并且如果您不必照顾与基础架构相关的项目，则可以直接在引擎上部署代码。 因此，根据您的需求，Google 提供了多种选择来利用计算能力，加快开发工作并缩短产品上市时间。

接下来，我们将详细讨论以下计算选项：

  • 计算引擎
  • 应用引擎
  • Cloud Functions
  • Kubernetes 引擎

Compute Engine

Compute Engine 是 Google Cloud 提供的 IaaS； 它是在 Google 基础架构中运行的虚拟机。

Google Cloud 提供的所有区域和区域都可以使用 Compute Engine。 它具有永久性磁盘和本地固态驱动器（SSD）的存储选项。SSD 内部内置芯片上集成电路，不包含任何旋转头或磁盘驱动器以读取数据。 与硬盘驱动器相比，SSD 更耐用，读取时间更快。 永久磁盘是一种网络存储，最多可以扩展到 64 TB，而本地 SSD 是加密驱动器，它实际上已连接到服务器，并且可以扩展到 3 TB。

在旋转实例时，用户可以选择预定义的计算选项之一，也可以使用自定义的配置。 可以使用 Linux 或 Windows 操作系统启动 Compute Engine。 这些实例可以使用 CPU，GPU 和 TPU 启动，并且由于基础结构是由 Google 提供的，因此用户可以进行操作系统级的自定义。

用户可以在 Compute Engine 中创建托管和非托管实例组：

  • 受管实例组将始终包含相同的虚拟机，并支持自动扩展，高可用性，滚动更新等。
  • 非托管实例组可以包含具有不同配置的计算机。 用户可以在创建托管实例组时使用实例模板，但不能与非托管实例组一起使用。
  • 建议选择一个受管且统一的实例组，直到在同一池中非常需要不同配置的计算机为止。

让我们快速讨论一个有助于降低价格的选项。 如果可能，请使用可抢占的计算机。 可抢占式虚拟机是短期且低成本的选件，可在已知工作负载并预期在 24 小时内完成工作负载时使用。 这些虚拟机具有显着的成本优势，与常规实例相比，可节省高达 80% 的成本。 可抢占式机器将节省多达 80% 的成本，但有一个陷阱：Google 始终可以在 30 秒内从您那里收回该实例。 Google 每秒收费，并为用户提供可持续的折扣。

Compute Engine 和 AI 应用

在为 AI（ML）应用训练模型时，始终需要功能强大的机器，以通过提供充足的训练数据并减少训练模型的时间来提高模型的效率。 Google Compute Engine 具有多个选项，可以启动功能强大的计算实例和组，从而可以在其上训练和运行模型。 对于训练和运行模型，应使用 CPU 和 GPU 的功能。 对于 TensorFlow 应用，应使用带有 TPU 的机器。

App Engine

App Engine 是 Google Cloud 提供的 PaaS； 它是一个完全托管的无服务器应用平台。

在 Google Cloud 覆盖的大多数区域中都可以使用 App Engine。 您可以将 App Engine 视为可用于部署的基础架构； 开发人员只需专注于构建应用并将其部署到 App Engine 上，其他所有事情都将得到解决。 App Engine 具有出色的功能，例如自动缩放，流量拆分，应用安全，监视和调试-所有这些功能对于部署，保护和扩展任何应用都是必不可少的。 使用 Cloud SDK 和 IntelliJ IDEA 之类的工具，开发人员可以直接连接到 App Engine 并执行诸如调试源代码和运行 API 后端之类的操作。 App Engine 的限制之一是无法自定义其操作系统。

App Engine 有两种不同的环境：

  • 标准
  • 灵活

App Engine 标准环境应用在沙盒环境中运行，并支持运行 Python，Java，Node.js，Go 和 PHP 应用。 另一方面，App Engine 灵活环境应用在 Google Compute Engine 虚拟机上的 Docker 容器中运行，除了标准环境支持的语言外，还支持运行 Ruby 和 .NET 应用。 有关在标准环境和灵活环境之间进行选择的更多详细信息，请参阅这里。

App Engine 对于部署任何 Web 或移动应用非常有用。 根据资源的使用情况，基础架构会自动扩展，Google 只会针对已使用的应用收费。

App Engine 和 AI 应用

在 App Engine 上运行任何移动或 Web 应用时，在许多用例中，这些应用都需要 AI。 在 App Engine 中部署应用时可以实现这些目标。 该服务可以与云终结点一起部署，而 Python 应用可以在 App Engine 中部署，从而加载训练有素的机器学习模型。 通过 App Engine 访问模型后，该服务可以将请求发送到 Python 应用并以一致的方式获取响应。

Cloud Functions

Cloud Functions 是 Google Cloud 提供的事件驱动的无服务器 PaaS，非常适合微服务架构。

Google Cloud 覆盖的大多数区域都提供 Cloud Functions。 它们主要用于小型或单一用途的功能，例如调用其他服务或将事件写入发布/订阅主题等。 Cloud Functions 中有一些很棒的功能，可提供敏捷性和零停机维护。 Cloud Functions 可以自动销售，并且高度可用。 您可以使用 Cloud Functions 连接到大多数 Google Cloud 服务。

可以使用 JavaScript 或 Python 开发 Cloud Functions。 用户仅在运行时才需要为 Cloud Functions 付费。 这使其非常具有成本效益。

Cloud Functions 和 AI 应用

在运行任何应用时，如果用户希望基于特定事件调用 Cloud ML 或 Cloud Vision 的 API，则可以使用 Cloud Functions。

Kubernetes Engine

Kubernetes Engine 是 Google Cloud 提供的一项托管服务； 它用于部署和运行容器化的应用。 以下是 Kubernetes Engine 的功能：

  • 它可在 Google Cloud 提供的所有区域和区域中使用。
  • 在 Kubernetes 集群下，Google 实际上正在运行 Compute Engine，因此我们在 Compute Engine 上拥有的大多数优势将与 Kubernetes Engine 一起使用，并提供其提供的其他服务。
  • 在 Kubernetes 集群中，可以使用具有自定义 OS 映像的虚拟机，并且集群将自动缩放自定义映像。
  • Kubernetes 集群具有高度的安全性，并获得了 HIPAA 和 PCI DSS 3.1 的支持。
  • 它带有仪表板服务，允许用户对其进行管理。
  • 它会自动升级和自动修复。
  • 它支持常见的 Docker 映像和私有容器注册表，用户可以通过该注册表访问私有 Docker 映像。
  • Kubernetes 集群可以与 Stackdriver 集成在一起，以实现对集群的监视和日志记录。

如果您的应用可以管理其中一台虚拟机发生故障的情况，那么将可抢占实例与 Kubernetes 群集配合使用非常有意义，因为这样可以节省大量成本。

Kubernetes Engine 和 AI 应用

在为 Al（ML）应用训练模型时，始终需要功能强大的机器，以通过提供充足的训练数据并减少训练模型的时间来提高模型的效率。 可以使用 GPU 构建 Kubernetes 集群，以训练模型并运行 ML 工作负载。 这可以使许多机器学习应用受益，这些应用需要具有强大 GPU 机器的托管容器化集群。

进入存储选项

GCP 提供了各种存储选项来存储您的应用数据。 不同的应用具有不同的存储需求，并且取决于应用，性能得以提高。 从 GCP 存储选项来看，很明显，它可以支持各种存储需求，例如 NoSQL，文档 DB，对象存储，关系数据库管理系统（RDBMS）等。 。 您可以使用 Google 的托管服务来满足存储需求，也可以使用 Google 基础架构并安装所需的服务。

为您的应用选择正确的存储选项很重要。 根据 Google 中可用的存储选项，以下图表将帮助您确定正确的存储选项：

接下来，我们将详细讨论以下存储选项：

  • Cloud Storage
  • Cloud Bigtable
  • Cloud Datastore
  • Cloud Firestore
  • Cloud SQL
  • Cloud Spanner
  • Cloud Memorystore
  • Cloud Filestore

Cloud Storage

云存储是 GCP 提供的对象存储。 以下是云存储的功能：

  • 它可以存储任何数量的数据和各种格式的数据，包括结构化数据，非结构化数据，视频文件，图像，二进制数据等。
  • 用户可以根据以下要求将数据存储在 Cloud Storage 中的四个不同的存储桶中，即多区域存储，区域存储，近线存储和冷线存储。
    • 如果数据在世界范围内经常访问，则转到“多区域”存储桶。
    • 如果经常在同一地理区域访问数据，则进入“区域”存储桶。 对于每月访问一次的数据，请使用 Nearline，对于每年访问一次的数据，请使用 Coldline 存储桶。
    • 选择桶很重要，因为与之相关的成本。
  • 默认情况下，存储在 Cloud Storage 中的数据是高度可用的并已加密。 如果您要自定义默认加密，则可以轻松实现。
  • Cloud Storage 提供了 API 和工具，用于进出数据传输。
  • 用户可以使用gsutil工具从本地传输数据，也可以使用云服务从其他云传输数据。
  • 所有数据传输都是安全的，并且在飞行中已加密。
  • 具有对象生命周期管理等功能，可将数据移至便宜的，不常使用的存储中，并且用户可以使用访问控制列表（ACL）来确保数据访问的安全性。
  • 这是一项集中式服务，并且与所有计算和处理选项集成在一起。
  • BigQuery 和 Dataproc 等服务可以访问 Cloud Storage 中存储的数据，以创建表并将其用于处理中。

凭借其所有功能，云存储是 GCP 上最常用的存储选项，也是最便宜的存储选项之一。 根据存储类别和访问模式，其价格从每月每 GB 0.007 美元到每月每 GB 0.036 美元不等。

Cloud Storage 和 AI 应用

云存储可以在各种 AI 和 ML 用例中提供帮助。 大多数大数据迁移或现代数据平台都使用 Cloud Bigtable 构建其 NoSQL 数据库。 例如，Spark ML 应用将访问 Cloud Bigtable 中的数据并将结果存储在其中。 云存储已经用于基因组学，视频转码，数据分析和计算等用例。

Cloud Bigtable

Cloud Bigtable 是 GCP 提供的完全托管的 NoSQL 数据库系统。 它可以以极低的延迟和高吞吐量扩展到 PB 级的数据。 Cloud Bigtable 的功能如下：

  • Cloud Bigtable 最适合读写操作非常繁重的用例； 话虽如此，Bigtable 可以用于流和批量操作。
  • Bigtable 中的每个表都包含一个单列族，并且每个列族都具有多个列限定符。 在任何给定的时间点，可以将列限定符添加到列族。
  • 数据作为键值对存储在表中。 在 Bigtable 中设计表格时，最重要的事情是行键列。 仅基于此列，数据将在表中均匀分布，并且用户在读取数据时将获得优化的性能。
  • 如果行键列的数据倾斜，则将发生热点。 例如，如果行键是表中的一个城市，并且数据仅针对一个城市倾斜，那么数据将不会均匀分布，并且读取也不会得到优化。
  • 另一方面，如果应用正在均匀地接收多个城市的数据，则数据将被公平分配，并且读取操作将得到优化。
  • 可以在 Bigtable 中的行级别执行更新操作。
  • Google Cloud Bigtable 与 Stackdriver，Cloud Dataflow，Dataproc 和 Hadoop 等服务集成在一起。
  • 它还支持行业标准的 HBase API。 默认情况下，存储在 Bigtable 中的所有数据都是加密的，并且可以使用访问控制为用户提供适当的访问权限。
  • 对于 Bigtable 的每个节点，用户每小时需支付 0.65 美元，SSD 存储每小时每 GB 收费 0.17 美元，HDD 存储每小时每 GB 0.026 美元。

Cloud Bigtable 和 AI 应用

Cloud Bigtable 可以充当各种 AI 和 ML 用例的存储。 大多数大数据迁移或现代数据平台都使用 Cloud Bigtable 构建其 NoSQL 数据库。 例如，流式 ML 应用可以很好地将 Bigtable 用作后端。

Cloud Datastore

Cloud Datastore 是 GCP 提供的完全托管的，可扩展的 NoSQL 数据库。 数据存储区建立在 Bigtable 之上； 这就是为什么它具有高度可扩展性的原因。 Cloud Datastore 的功能如下：

  • Cloud Datastore 提供了一些重要的 RDBMS 功能，例如 ACID 支持，类似于 SQL 的查询等等。
  • 为了轻松使用数据存储，您应该了解基本术语及其与 RDBMS 的相似性。 这是 RDBMS 和数据存储区术语的比较表：

| | Datastore | RDBMS |
| --- | --- |
| 对象类别 | 类 | 表 |
| 单一对象 | 实体 | 行 |
| 唯一标识 | 键 | 主键 |
| 属性信息 | 属性 | 字段 |

如果数据存储与 RDBMS 非常相似，为什么还要使用数据存储？ 原因很简单，因为它的可伸缩性是 RDBMS 无法实现的。

  • Google Cloud Datastore 与 Stackdriver，App Engine 和 Compute Engine 等服务集成在一起。
  • 它具有很高的可用性，并带有管理仪表板。 默认情况下，存储在数据存储区中的所有数据都是加密的，并且可以使用访问控制为用户提供适当的访问权限。
  • 对于 1 GB 的存储空间，向用户收取 0.18 美元，写入 100,000 个实体 0.18 美元，读取 100,000 个实体 0.06 美元以及删除相同金额的 0.02 美元。

Cloud Datastore 和 AI 应用

Cloud Datastore 可以充当大型 Web 应用的 AI 和 ML 用例的存储。 GCP 上托管的任何电子商务网站都可以使用数据存储来保存数据，并且使用此数据，可以训练 ML 模型并可以向用户提供所需的建议，进而可以提高客户满意度。

Cloud Firestore

Cloud Firestore 是可扩展的 NoSQL 文档数据库。 它是适用于 Firebase 的 Web，服务器和移动开发的数据库。

Firestore 中存储的数据几乎全局实时同步，并且可以从多个设备进行访问。 Firestore 将数据存储在文档和集合中。 让我们快速看一下如何存储数据的示例：

  • 员工是集合，其中应包含所有文件。
  • Anand 和 Vikram 是代表员工的文档，并且在文档内部，有一些字段映射到值。

这是集合的结构：

Employee -- Collection
                    Anand -- Document
                                  Name: Anand Deshpande
                                  Department: IT
                                 Designation: Vice President
                 Vikram -- Document
                               Name: Vikram Chaudhari
                              Department: IT
                              Designation: Director

随后是 GCP 中的 Firestore 用户界面的屏幕截图：

文档通过它们在数据库中的位置唯一标识。 默认情况下，Firestore 中存储的所有数据都是加密的，并且可以使用访问控制为用户提供适当的访问权限。 对于 1 GB 的存储空间，向用户收取 0.18 美元，写入 100,000 个文档 0.18 美元，读取 100,000 个文档 0.06 美元和删除相同数量的文档 0.02 美元。

Cloud Firestore 和 AI 应用

Cloud Firestore 可以充当 AI 和 ML 用例中存储在移动和 Web 设备上的应用的存储。 在 GCP 上托管的具有网站和移动应用的任何应用都可以将数据保存在 Firestore 中，并且可以使用此数据训练 ML 模型，并可以在其移动设备和网站应用上向用户提供所需的建议。

Cloud SQL

Cloud SQL 是 MySQL 和 PostgreSQL 的完全托管实例。 Cloud SQL 的功能如下：

  • 它具有可扩展性，是高达 10 TB 数据的正确选择。

  • 它的实例可以在任何时间和适合应用的区域中立即创建。

  • 可以创建的实例的范围从 1 个虚拟 CPU（VCPU）到 64 个 VCPU，以及 600 MB RAM 到 400 GB RAM。

  • 关于持久性存储，用户可以选择 SSD 或 HDD 存储。 速度更快的 SSD 比 HDD 的成本更高。

  • 可以启用自动持久性存储，以确保数据库不会耗尽空间。 高可用性是可选的，并且取决于用户是否启用它。

  • 可以从大多数 GCP 计算和处理服务访问 Cloud SQL 实例。

  • 最快的访问方式之一是使用 Google Cloud Shell。 实例的所有更新和补丁都是自动的，用户无需担心。

  • Cloud SQL 是高度安全的，并且默认情况下，其中存储的所有数据都是加密的。

  • 从 GCP 外部访问 Cloud SQL 的应用必须经过健壮的安全层才能对其进行访问。

  • Cloud SQL 很便宜，并且为实例提供了很多持续的用户折扣价格。

  • 根据实例类型的不同，每小时的价格范围为 0.0150 – 8.0480 美元。 永久存储的价格为：SSD 为 0.17 美元，HDD 为 0.09 美元，备份为 0.08 美元。

Cloud SQL 和 AI 应用

Cloud SQL 可以为大型和复杂的结构化数据提供所有 AI 和 ML 用例。 另一个名为 Cloud Spanner 的服务可以提供类似的用例，Cloud SQL 可以提供类似的用例，但是规模非常大。

Cloud Spanner

Cloud Spanner 是完全托管的，可横向扩展的关系数据库管理服务。 它可以在所有可用区域中扩展到数百万个节点。 Cloud Spanner 的功能如下：

  • 可以立即创建它的实例，并且可以在单个或多个区域中创建适合该应用的实例。

  • 可以从一个节点到数百万个节点创建 Cloud Spanner 实例。

  • 即使 Cloud Spanner 是分布式数据库，它仍支持 ACID 事务，其可用性为 99.999%。 Cloud Spanner 具有 RDBMS 等功能和可扩展性（如分布式数据库）。

  • 可以使用大多数 GCP 计算和处理服务以及外部 GCP（具有正确的权限集）访问 Cloud Spanner 实例。

  • 最快的方法之一是使用 Google Cloud Shell 快速访问它。 实例的所有更新和补丁都是自动的，用户不必担心。

  • Cloud Spanner 是高度安全的，默认情况下，所有存储的数据都是加密的。

  • 它与身份和访问管理集成在一起，并提供诸如审核和日志记录之类的功能。

  • 它提供两种定价，一种用于区域设置，另一种用于多区域设置。

  • 区域实例的每个节点价格为 0.90 美元，而多区域节点的价格为每小时每个节点 3 美元。

  • 对于区域实例，持久性存储的价格为每月每 GB 0.30 美元，对于多区域实例，永久性存储的价格为每月每 GB 0.50 美元。

Cloud Spanner 和 AI 应用

Cloud Spanner 可以提供适用于 MySQL 和 PostgreSQL 的所有 AI 和 ML 用例。 Cloud SQL 适用于服务需要高达 10 TB 结构化数据的 AI 和 ML 用例； 例如，机器学习用例需要数据准备，这涉及复杂的 SQL 连接并可以提高流程效率。

Cloud Memorystore

Cloud Memorystore 是基于 Redis 构建的完全托管的内存中数据存储服务。 以下是 Cloud Memorystore 的功能：

  • Redis 是一个通用的数据库，可以用于很多用例。 通常，人们将 Redis 用作缓存服务，但是它具有各种不同的数据结构，可以为物联网（IoT），ML，流式传输等其他用例提供服务。

  • 借助 Cloud Memorystore，Google 本质上提供了可伸缩且高度可用的 Redis 实例。

  • Google 针对 Cloud Memorystore 的服务级别协议（SLA）对于标准层为 99.9%，并且受到 Google 的网络策略和基于角色的访问控制的完全保护。

  • Cloud Memorystore 分为两层：基本层和标准层：

    • 基本实例非常适合用作缓存服务，并且不会附加任何 SLA。
    • 标准实例提供了高可用性，并在另一个区域中部署了副本，因此它可以从区域故障中恢复。

  • 根据 Redis M1-M5 的存储容量和网络容量，可分为五个容量层，分别从 1 GB 到 300 GB 和 3 Gbps 到 12 Gbps 不等。

  • 由于 Cloud Memorystore 遵循所有 Redis 协议，因此很容易在其上提升和转移现有 Redis 项目。

  • Cloud Memory 与身份和访问管理以及 Stackdriver 集成在一起，后者提供 24/7 系统监视等功能来保护您的数据，检查 Memorystore 的性能等。 其数据始终驻留在 VPC 中。

  • 由于 Cloud Memorystore 具有五种不同的容量，因此其价格也会相应变化。 价格范围从每小时每 GB 0.016 美元到每小时每 GB 0.049 美元。

Cloud Memorystore 和 AI 应用

Cloud Memorystore 可以使用 Redis ML 模块满足各种 AL 和 ML 用例。 Redis ML 具有各种 ML 模块作为内置数据类型。 Cloud Memorystore 可以为线性和逻辑回归，决策树矩阵计算等提供机器学习模块服务。

Cloud Filestore

Cloud Filestore 是 GCP 提供的完全托管的高性能网络文件存储。 以下是 Cloud Filestore 的功能：

  • 云端存储可与需要网络文件存储的 Google Compute Engine 和 Kubernetes Engine 应用一起使用。
  • Cloud Filestore 快速可靠，非常适合要求低延迟和高吞吐量的应用。
  • Filestore 是一致的，并在一段时间内提供可靠的性能。 它遵循 NFSv3 协议，具有 99.99% 的高可用性，并且最大共享容量为 63.9 TB。
  • Cloud Filestore 具有 Google 级别的安全性，具有高度的安全性，分为两个等级：标准和高级。
  • 这两层的价格因地区而异。 标准层的价格从每月每 GB 0.20 美元到 0.24 美元不等，高级层的价格从每月每 GB 0.30 美元到 0.36 美元不等。

Cloud Filestore 和 AI 应用

Cloud Filestore 可以服务所有 AI 和 ML 用例，这些用例要求本质上不是很复杂的数据集具有高吞吐量。

在下一节中，我们将讨论处理选项。

了解处理选项

除了 IaaS 选项（可用于通过计算选项构建自己的 AI 和 ML 管道）之外，Google 还提供了一些托管服务，可用于处理数据以及构建 AI 和 ML 管道。 以下是完全托管的处理选项：

  • BigQuery
  • Cloud Dataproc
  • Cloud Datastream

所有托管处理选项都与其他 Google Cloud Services 集成在一起，例如网络，身份和访问管理，Stackdriver 等。 这些使跟踪活动和加强应用的安全性变得容易。 BigQuery 可用于卸载现有数据仓库并创建一个新仓库，并且使用 BigQuery ML 选项，您可以构建 ML 管道。 Dataproc 可用于在 GCP 上迁移现有的 Hadoop 项目并在其上运行 AI 和 ML 管道。 Cloud Dataflow 可用于在 GCP 上构建全新的管道。

BigQuery

BigQuery 是 GCP 的云数据仓库，具有机器学习风格（BigQuery ML）。 它是一个非常强大的工具，可以处理 PB 的数据，并且为您提供了随时可用的模型，您可以在 SQL 编程中使用这些模型来构建机器学习管道。

BigQuery 快速，可扩展且无服务器。 您只需单击几下即可构建 BigQuery 数据集，然后开始将数据加载到其中。 BigQuery 使用 Colossus 以列格式将数据存储在本机表中，并且数据被压缩。 这使得数据检索非常快。 除存储外，BigQuery 使用以下工具和网络组件来使其快速，可靠和高效：

  • Jupyter 网络，用于对数据进行混洗
  • Dremel 引擎用于处理
  • Borg 用于集群管理

换句话说，它利用 Google 出色的基础架构和最佳服务，使其快速，高度可用且可扩展。

BigQuery 带有其他功能，例如数据和查询共享，保存所需的查询； 它符合 ANSI 2011，并与本机以及外部工具（包括 Informatica，Talend 等）集成。 BigQuery 中保存的所有数据均已加密。 它是联盟的，可以查询来自其他服务（如 Cloud Storage 和 Bigtable）的数据。 BigQuery 还通过 BigQuery Streaming 支持实时分析。

BigQuery 拥有一个友好的用户界面，用户可以从中执行所有操作，还具有一个命令行工具bqclient，可用于连接到 BigQuery。 BigQuery 有两种定价模式：“按需付费”，即每 TB 查询处理向用户收取 5 美元的费用；以及“固定费用定价”，即每月约 40,000 美元，为此用户可获得 2,000 个专用插槽用于处理。 存储费用为每月每 GB 0.02 美元； 对于短期存储和长期存储，每月每 GB 0.01 USD。

BigQuery 和 AI 应用

BigQuery ML 是 BigQuery 机器学习的一种形式，它具有一些内置算法，可以直接在 SQL 查询中用于训练模型和预测输出。 BigQuery ML 当前支持分类模型的线性回归，二进制逻辑回归和多类逻辑回归。

Cloud Dataproc

Cloud Dataproc 是一个完全托管的 Hadoop 和 Spark 集群，可以在几秒钟内旋转。 Cloud Dataproc 是一个自动扩展集群，可用于非常有效地运行 Hadoop，Spark 以及 AI 和 ML 应用。 在高峰时段，可以根据使用情况将节点添加到群集，并且在需求较低时可以进行缩减。

Dataproc 与其他服务集成，例如云存储，BigQuery，Stackdriver，身份和访问管理以及网络。 这使得群集的使用非常容易且安全。

在 Dataproc 集群下，Google 实际上运行计算实例。 用户可以从广泛的计算机配置中进行选择来构建集群，或者如果现有计算机配置不能满足需求，则用户也可以使用自定义计算机配置来构建集群。 这里要注意的一件非常重要的事情是 Dataproc 集群使用抢占式实例。 这可以为集群的定价创造奇迹。 抢占型实例的价格要低得多，大约是具有相同配置的实际实例的 20%，而 Google 可以在 30 秒内通知收回实例。

对于 Dataproc 集群，可将抢占实例用作数据节点，因为通常将 Dataproc 集群用于计算目的，并且所有数据都将保存在 Cloud Storage 中。 因此，在这种情况下，即使抢占式实例发生故障，该作业也将转移到另一个节点，并且不会产生任何影响。 Cloud Dataproc 集群的定价随实例而异，但是具有非常有竞争力的定价。

Cloud Dataproc 和 AI 应用

Cloud Dataproc 可以使用 Apache Spark，Hadoop 和其他工具来满足各种 AI 和 ML 用例。 将 Dataproc 视为完全托管的云 Hadoop 和 Spark 集群。 可以在 Hadoop 和 Spark 上构建的所有 AI 和 ML 用例都可以在 Cloud Dataproc 集群上构建。

Cloud Dataflow

Cloud Dataflow 是用于运行批量和流应用的完全托管服务，并且具有用于运行 AI 和 ML 作业的丰富集成。 它是 Google 提供的无服务器服务，基于 Apache Beam 构建，因此，批量代码和流代码都可以相互使用。 可以以非常简化的方式用 Java 和 Python 构建 Cloud Dataflow 应用。

Cloud Dataflow 与其他 GCP 服务集成在一起，例如 Cloud Pub/Sub，Cloud Machine Learning，Stackdriver，BigQuery 和 Bigtable，这使得构建 Cloud Dataflow 作业非常容易。 在 Cloud Dataflow 之下，App Engine 正在运行，因此用户拥有无限的能力来扩展其工作。 Cloud Dataflow 会根据工作需求自动扩展。

除了已处理数据的定价外，批量和流作业的 Cloud Dataflow 定价基本相同。 它根据 VCPU，RAM，持久性存储和处理的数据量进行收费。

Cloud Dataflow 和 AI 应用

Cloud Dataflow 可以与 Cloud Machine Learning 集成，服务于各种 AL 和 ML 用例。 欺诈检测是一个经典的用例，可以使用 Cloud Dataflow 和 Cloud Machine Learning 实现流作业。

到目前为止，我们已经了解了 GCP 的基本知识，这将有助于我们有效地使用平台，做出正确的选择并建立有效的渠道。 现在，您已了解 GCP 上所有可用的计算，存储和处理选项。 现在，让我们开始构建 ML 管道。

建立 ML 管道

让我们来看一个详细的示例，在该示例中，我们将建立一条端到端的管道，从将数据加载到 Cloud Storage，在其上创建 BigQuery 数据集，使用 BigQuery ML 训练模型并对其进行测试。 在此用例中，我们将使用逻辑回归模型来查找潜在客户转化概率。 您可以使用选择的任何合适的数据集并遵循此示例。

潜在客户数据包含有关潜在客户的各种属性。 BigQuery ML 具有内置功能，我们可以直接在任何数据集中训练模型。 我们可以预测输出变量和转换概率。 BigQuery 提供了一个 SQL 接口来训练和评估机器学习模型。 该模型可以部署在平台上进行消费。

我们有两个数据集：潜在客户训练数据和测试数据，其中训练数据为实际总体数据的 80%，测试数据为 20%。 使用训练数据训练模型后，我们将在测试数据上评估模型，并在以下类别中找到每个潜在客户的潜在客户转换概率：

  • Junk lead
  • 合格（Qualified）
  • 有兴趣（Interested）
  • 封闭（Closed）
  • 没兴趣（Not interested）
  • 不合格（Not eligible）
  • 无法到达（Unreachable）

了解流程设计

下图代表了将数据加载到 Cloud Storage 和 BigQuery 中以及对模型进行训练并使用潜在客户数据进行测试的端到端过程。 您可以选择一个数据集：

从上图中，我们可以看到以下内容：

  1. 我们已将潜在客户的训练和测试数据集加载到 Cloud Storage 存储桶中。
  2. 将数据加载到 Cloud Storage 后，我们将使用leads_training和leads_test这两个表将潜在客户数据集创建到 BigQuery 中。
  3. 创建数据集后，我们将使用leads_training表来训练我们的模型，并使用leads_test表来测试模型。

我们将在以下各节中详细讨论每个步骤。

将数据加载到 Cloud Storage

让我们讨论将数据加载到 Cloud Storage 中的分步过程：

  1. 您应该具有训练和测试数据。
  2. 在 Cloud Storage 中创建训练和测试存储桶。
  3. 在 GCP 控制台中，单击左上角的导航菜单，然后在存储部分中，单击“存储（云存储）”。
  4. 单击顶部的创建存储桶。 您将看到以下屏幕：

  1. 为存储桶指定一个全局唯一的名称。

  2. 为您的用例选择一个区域存储桶。

  3. 选择您要在其中创建存储桶的位置。

  4. 单击“创建”。

  5. 通过单击存储桶，将训练和测试数据上传到各自的存储桶，然后使用上载文件选项或将文件拖放到存储桶中。

将数据加载到 BigQuery

现在，我们将讨论 BigQuery 数据集并将数据加载到 BigQuery 中：

  1. 首先，按照以下步骤在 BigQuery 中创建 Leads 数据集：
    1. 在 GCP 控制台中，点击左上方的导航菜单，然后在大数据部分中点击BigQuery。
    2. 单击左侧面板中的项目名称。
    3. 单击“创建数据集链接”。
    4. 将数据集名称指定为 Leads 并创建它。 选择您喜欢的位置，然后创建数据集。
  2. 接下来，按照以下步骤从 Cloud Storage 存储桶中的可用数据创建Leads_Training和Leads_Test表：
    1. 单击左侧面板中项目中的 Leads 数据集。
    2. 单击“创建表”。
    3. 代替空表，选择从以下位置创建表：Google Cloud Storage。
    4. 给出文件的位置。
    5. 选择文件格式为 CSV。
    6. 根据要创建的表，将表名命名为Leads_Test_Data或Leads_Training_Data。
    7. 单击“自动检测架构”。
    8. 在高级选项中，如果数据集具有标题，则将“标题行”设置为跳过为1。
    9. 单击“创建表”。

以下屏幕快照中还显示了创建表的上述步骤：

以下屏幕快照描述了如何跳过标题行：

现在，我们已经在 BigQuery 中创建了 Leads 数据集，并从 Cloud Storage 存储桶中的可用数据中创建了Leads_Training和Leads_Test表，接下来我们将训练模型。

训练模型

以下 BigQuery 代码段将用于通过Leads_Training表中的逻辑回归来训练销售线索模型：

请使用这个页面上的leads_model.sql文件从以下链接加载查询。

CREATE MODEL
 `Leads.lead_model_optimum`
 OPTIONS
 (model_type = 'logistic_reg') AS
 SELECT
 Lead_Stage AS label,
 lead_origin,
 lead_source,
 ...,
 ...,
 ...,
 ..., 
 receive_more_updates_about_our_courses,
 update_me_on_supply_chain_content,
 Get_updates_on_PGDMHBSCM,
 city_new,
 ...,
 ...,
 Asymmetrique_Activity_Score,
 Asymmetrique_Profile_Score,
 Last_Notable_Activity
 FROM
 Leads.Leads_Training_Data;

从前面的代码中，我们可以看到以下内容：

  • 我们正在 Leads 数据集中创建一个名称为lead_model_optimum 的模型。

  • 如您在OPTIONS中看到的那样，已经创建了逻辑回归模型，其中model_type是logistic_reg。

  • Lead_Stage是我们将根据测试数据进行预测的标签。

  • Lead_Stage是我们可以从中识别销售线索状态的列。

  • 模型将使用lead_origin至Last_Notable_Activity列来预测测试数据上的Lead_Status。

  • 该模型是使用Leads_Training_Table中的数据创建的。

  • 创建模型后，它将以名称lead_model_optimum保存在 Leads 数据集中。

通过单击“模型”，您将能够看到“模型详细信息”，“模型状态”和“模型模式”。 它具有完整的细节，例如所使用的算法，迭代次数，学习率，完成时间等。 因此，只需将前面的代码复制并粘贴到BigQuery窗口中，便可以创建第一个模型。

接下来，我们将看到如何评估所创建的模型。

评估模型

在BigQuery中，可以使用ml.evaluate()函数评估任何模型。 它将给出该模型的结果。 在下面的代码块中是BigQuery代码和模型评估结果。 让我们看下面的代码：

SELECT *  FROM
 ml.evaluate (model `Leads.lead_model_optimum`,
         (
         SELECT  Lead_Stage AS label, *
             FROM
         `Leads.Leads_Training_Data` )
        )

在前面的代码中，我们对lead_model_optimum进行了评估以查找其详细信息。

执行前面的查询后，让我们看一下以下结果：

上面的屏幕快照显示了完整的模型评估详细信息。 如我们所见，SQL 界面训练模型的准确率很高，并且训练数据覆盖率。 得分值还表明该模型是最佳拟合的，而不是评估数据的过拟合或过拟合。 关键是，业务分析师还可以使用 BigQuery 提供的简单 SQL 接口执行模型训练和部署。

测试模型

在 BigQuery 中，ml.predict()函数用于使用模型预测结果。 执行以下 BigQuery 代码以测试您的模型：

SELECT
 prospect_id,
 predicted_label
 FROM
 ml.predict(model `Leads.lead_model_optimum`,
 (
 SELECT
 *
 FROM
 Leads_Test_Data))

在前面的代码中，模型基于prospect_id预测test_data的Lead_Stage。

您可以看到生成的屏幕截图。 请比较模型的预测和基于prospect_id的测试数据的Lead_Stage列，以查看模型的准确率：

至此，本例结束。 请在使用 Spark 的 Dataproc 集群上尝试相同的示例。

总结

在本章中，我们学习了在 GCP 上构建 AI 应用时对我们有帮助的所有组件。 我们研究了不同的计算，存储和处理选项，以及这些选项可以为我们提供哪些帮助。 请记住，选择正确的存储，计算和处理对于构建具有成本效益的应用非常重要。 除了学习组件之外，我们还使用 BigQuery 和 Cloud Storage 进行了潜在客户预测的动手示例，并且您可以在 Dataproc 集群上使用 Spark 尝试相同的示例。

在下一章中，我们将深入探讨利用 GCP 的功能来使用自动缩放功能处理大量数据。

三、XGBoost 的机器学习应用

在许多领域，基于机器学习的数据驱动方法变得非常重要。 一个很好的例子是基于机器学习的智能电子邮件垃圾邮件分类器，它通过学习大量垃圾邮件数据和用户反馈来保护我们的电子邮件。 另一个这样的示例可以是针对性广告系统，其基于某些上下文向用户展示广告，或者是防止恶意攻击者攻击的银行欺诈检测系统。 为了使机器学习应用在上述领域取得成功，必须牢记一些重要因素。

一种是建立并使用有效的统计模型来表示涵盖最重要场景的所有复杂数据依赖关系，另一种是可伸缩地构建那些模型以确保它们在越来越大的数据集上工作。 机器学习的可伸缩性使您能够通过并行和分布式计算进行快速学习，并且还提供了有效的内存利用率。

在本章中，我们将讨论 XGBoost 库，这是一种集成学习算法。 XGBoost 是一种基于决策树集成的机器学习算法，该算法使用梯度提升系统。 在预测涉及非结构化数据（例如图像和文本）的问题时，人工神经网络往往会胜过任何其他算法或系统。 尽管如此，当涉及中小型结构化/表格数据时，基于决策树的算法目前被认为是同类最佳。 这是因为在某些情况下，仅一种机器学习模型的结果可能不够。 共同学习为组合多种机器学习算法的预测能力提供了系统的解决方案。 结果是一个单一模型，提供了多个模型的附加输出。 集成模型（也称为基础学习器）可以使用相同的学习算法，也可以使用不同的算法。 在本章中，您将学习如何使用 Python 实现 XGBoost 算法。 您还将学习有关梯度提升的概念以及它们如何支持 XGBoost 算法的知识。

本章将涵盖以下主题：

  • XGBoost 库概述
  • 训练和存储 XGBoost 机器学习模型
  • 用已训练的 XGBoost 模型
  • 使用 XGBoost 库构建推荐系统

XGBoost 库概述

XGBoost 是一个库，可帮助以可扩展且以性能为中心的方式在非常大的数据集上运行集成学习机器学习算法。 因此，它着重于计算速度和模型表现。 换句话说，对于 XGBoost 而言，高端硬件情况下性能或可伸缩性提高的结果更多。 XGBoost 在梯度提升框架内实现了用于机器学习的算法。 我们将很快进入 XGBoost 库。 但是在此之前，我们还应该了解集成学习和梯度提升。

集成学习

集成学习算法结合了多个基本模型以产生最佳的预测模型。 与尝试从训练数据中学习假设的普通机器学习方法相反，集成方法尝试构建和组合许多假设。 使用集成方法时，重点放在泛化上，由于算法的特定性质或由于选择的训练集而导致的偏差方差折衷，有时基础学习器会忽略它。

通常，基础学习算法会根据训练数据生成基础学习器，这些数据可以是决策树，神经网络或其他机器学习算法。 大多数乐团使用单个基本学习算法来生成同类基础学习器，但是也存在几种使用多种不同类型的学习算法来生成异构学习器的方法。 在后一种情况下，没有用于基础学习的单一算法。 装袋和提升是广泛使用的集成方法。 这些是一种简单的组装技术，使用一些模型平均技术来共同构建许多独立的预测变量/模型/学习器（例如平均加权，多数或平均法线）。

另一个更大的问题是如何确保基础学习器不相互关联。 确保这些基本共同学习器的预测彼此独立是很重要的。 否则，它将排除整体建模的优化预测模型。 对于不同的基础共同学习器，我们的意思是最终的基础模型应该有所不同。 如果模型使用的数据集完全不同并且完全代表不同的上下文，则这些模型可以不同。 如果模型考虑不同的假设或使用完全不同的算法类别，则模型可以有所不同。

集成学习如何决定最佳预测模型？

当集成学习模型产生的误差尽可能低时，确定最佳模型，而损失函数的较低值确定最小值。 损失函数用于衡量预测模型可以预测预期结果的程度。 查找最小函数点的最常见方法是梯度下降。 总而言之，我们必须首先了解导致模型误差的原因，才能真正了解集成模式背后的原因。 我们将向您简要介绍这些误差，并为每位集成学生提供对这些问题的见解。 任何模型的误差都可以在数学上分为三种类型。

可减少的误差 – 偏差

偏差是预测值和实际值之间的距离。 换句话说，偏差是平均模型预测值与我们尝试预测的正确值之间的差。 高度偏倚的模型很少考虑训练数据，而过于简化了模型。 高偏差会导致算法错过相关的输入输出变量关系。 如果模型具有很高的偏差度，则意味着该模型过于简单，无法捕获支撑数据的复杂性。 为了量化偏差，它是预测值和实际值之间的平均差。

可减少的误差 – 方差

当模型在经过训练的数据集上良好但在新数据集（例如测试数据集或验证数据集）上表现不佳时，就会发生方差。 方差告诉我们如何分散实际值。 高方差会导致过拟合，这意味着算法模型中训练数据中存在随机噪声。 如果模型显示出很高的方差，则它会变得非常灵活，并适应训练集的数据点。 如果高方差模型遇到另一个未学习的数据点，则无法正确预测。 方差量化了预测和相同观测值之间的差异。

不可减少的误差

不可减少的误差是无论您使用哪种机器学习算法都无法将其最小化的误差。 它们通常是由可能影响输出变量的未知变量引起的。 改善不可减少误差的预测的唯一方法是识别和预测那些外部影响。

总误差

总误差定义如下：

通常，随着模型变得越来越复杂，由于模型的失真较小，您会看到误差的减少。 但是，这只会发生到某个特定点。 随着模型的不断复杂化，您最终会过拟合模型，因此方差将开始增加。 正确优化的模型应该平衡方差和偏差，如下图所示：

梯度提升

梯度提升是整体学习器的一种。 这意味着将基于一组不同的模型创建最终模型。 这些不同模型的拟合程度过高，因此它们的预测能力较弱，但是由于将它们组合在一起，因此在总体结果方面要好得多。 在梯度提升机中，决策树是最常用的弱模型类型。 因此，简而言之，梯度提升是一种基于回归和分类的机器学习方法，可将预测模型生成为弱预测模型的集合，该模型通常基于决策树。 现在让我们看看如何在数学上进行定义。

任何监督学习算法都旨在定义和最小化损失函数。 均方误差（MSE）或损失函数定义如下：

我们希望损失函数最小。 实际上，梯度提升的目的是找到使损失函数最小化的数据的最近似函数。 这可以用数学方式表示为：

因此，在梯度提升中，除了找到最佳参数P之外，我们还希望找到最佳函数F。 与简单的逻辑回归不同，此更改使问题复杂得多。 之前，我们要优化的参数数量是固定的（例如，在开始训练之前已定义了逻辑回归模型）； 现在，如果函数F发生更改，它可以随着我的优化过程而更改。

显然，搜索每个单个特征和参数以获得最佳特征会花费太长时间，因此梯度提升可以通过使用许多简单函数并将它们组合来找到最佳函数F。 以下是梯度增强中涉及的步骤：

  1. 首先，使用简单的模型和错误分析数据对数据建模。 这些误差指向难以通过简单模型拟合的数据点。
  2. 然后，对于后续模型，我们特别关注难以拟合的数据以对其进行校正。
  3. 归根结底，我们将所有预测变量组合在一起，赋予每个预测变量一定的权重。

这个页面上的代码表示如何在 Python 中完成梯度提升。

此代码用于在 Python 中实现梯度提升。 但目的还在于显示如何在多次迭代后减少误差。 散点图显示了机器学习算法的输入（X）的输出（Y）的分布方式。 以下输出还显示了残留散点图，该残留散点图在第 20 次迭代后变得随机性降低，表明梯度提升已找到最佳输出：

前面的散点图是输入和输出机器学习算法的表示。 下面显示了应用梯度提升之前的实际输出：

我们可以在前面的屏幕截图中看到以下内容：

  • 从第 18 次迭代开始，残差实际上是在第 20 次迭代附近随机分布的。
  • 一旦残差随机分布均匀，我们就知道梯度提升已经给出了优化的输出。
  • 换句话说，梯度提升从残差中识别出最大数量的图案，并给出了最大的优化输出。

极限梯度提升（XGBoost）

XGBoost 是由 Tianqi Chen 开发的，其全名是 eXtreme Gradient Boosting。 XGBoost 是梯度助推器机器的一种可扩展且准确的实现方式，仅针对模型表现和计算速度而开发，作为助力树算法的计算机功率极限。 陈天琪说，后者使它更具优势，与其他库有所不同。 以下是 XGboost 使其独特的一些重要功能：

  • 并行化：在 XGBoost 中并行构建顺序树。 用于构建基础学习器的循环可以互换。 因此，列出树的叶节点的外循环可以与计算特征的内循环互换。 如果这是原始方式，则必须在外部循环开始之前完成内部循环，而内部循环不会占用更多的计算量。 在 XGBoost 中，为了缩短运行时间，通过初始化全局扫描并使用所有实例的并行线程进行排序来交换循环的顺序。 此开关通过抵消任何并行开销来提高算法效率。
  • 停止标准：在梯度提升框架中，用于树分割的停止标准基于分割时的负损失函数。 但是，对于 XGBoost，它将按指定的max_depth参数开始向后修剪树。 这是一种深度优先的方法，可以提高算法的整体性能和效率。
  • 最大硬件资源使用率：XGBoost 旨在最大程度地利用硬件资源。 它通过每棵树中的内部缓冲区利用系统缓存来存储梯度统计信息。 其他改进包括计算核外和优化可用磁盘空间，同时处理不适合内存的大数据帧。

训练和存储 XGBoost 机器学习模型

在本节中，我们将研究如何使用 Google AI Hub 训练和存储机器学习模型。 AI Hub 是一站式存储，用于检测，共享和部署机器学习模型。 它是可重用的模型目录，可以快速安装在 AI 平台执行环境中。 该目录包含基于以下通用框架的模型设计的汇编：TensorFlow，PyTorch，Keras，scikit-learn 和 XGBoost。 每种模型都可以包装由 GPU 或 TPU，Jupyter 笔记本和 Google 自己的 AI API 支持的深度学习 VM，格式可以在 Kubeflow 中实现。 每个模型都有标签，这些标签可根据一系列特征来方便信息的搜索和发现。 借助.../text_classification_rapids_framework.py处的代码，我们将 XGBoost 与 RAPIDS 框架一起用于文本分类。

从算法上讲，此代码执行以下步骤：

  1. 导入了必要的包。 在较高级别上，此代码使用OS，google.cloud，cudf(RAPID)，sklearn，pandas和xgboost。 它还会导入pynvml，这是一个 Python 库，用于低级 CUDA 库，用于 GPU 管理和监视。
  2. 接下来，代码将安装miniconda库和 RAPIDS 平台，然后设置 NVIDIA GPU 所需的一些环境变量。
  3. 代码的下一部分将设置访问 Google API 所需的一些常量，例如project id和bucket id。
  4. 然后，该代码从 GCS 存储桶中下载训练数据（text_classification_emp.csv）。 然后将其存储在本地作业目录中以供进一步使用。
  5. 代码的下一部分使用\n分割 CSV，并创建两个数组，一个数组用于标签（目标变量），另一个数组用于文本（预测变量）。
  6. 然后，它创建一个 Pandas DataFrame，然后将其转换为与基础 GPU 兼容的 CUDF DataFrame。 这样做是为了确保所有其他操作都利用基础 GPU。
  7. 然后，按照 80%-20% 的规则将数据分为训练和测试数据集。
  8. 然后，标签编码器用于将标签编码为向量值。
  9. 之后，在字符级别上计算 TF-IDF。
  10. 最后，使用 XGBoost 库训练模型。

要提交前面的代码来训练模型，您必须运行以下命令。 此命令是标准google-ai-platform CLI，该 CLI 提交训练说明以在 Google Cloud AI 平台上训练任何模型：

gcloud ai-platform jobs submit training $JOB_NAME \
--job-dir=$JOB_DIR \
--package-path=$TRAINING_PACKAGE_PATH \
--module-name=$MAIN_TRAINER_MODULE \
--region=$REGION \
--runtime-version=$RUNTIME_VERSION \
--python-version=$PYTHON_VERSION \
--config=config.yaml

可以按照以下方法将那边的环境变量设置为job.properties，并且在运行gcloud ai-platform作业之前必须先获取job.properties的源。 可以在以下代码中看到一个示例：

PROJECT_ID=test-project-id
BUCKET_ID=ml-assets
JOB_NAME=gpu_text_classification_$(date +"%Y%m%d_%H%M%S")
JOB_DIR=gs://${BUCKET_ID}/xgboost_job_dir
TRAINING_PACKAGE_PATH="text_classification"
MAIN_TRAINER_MODULE=text_classification.train
REGION=us-central1
RUNTIME_VERSION=1.13
PYTHON_VERSION=3.5

特定于 GPU 的config.yml文件的内容如下：

trainingInput:
  scaleTier: CUSTOM
  # Configure a master worker with 4 K80 GPUs
  masterType: complex_model_m_gpu
  # Configure 9 workers, each with 4 K80 GPUs
  workerCount: 9
  workerType: complex_model_m_gpu
  # Configure 3 parameter servers with no GPUs
  parameterServerCount: 3
  parameterServerType: large_model

包的结构如下块所示：

text_classification
|
|__ __init__.py
|__ config.yml
|__ run.sh
|__ job.properties
|__ train.py

提交代码后，您可以使用以下屏幕快照中显示的命令检查作业状态：

如以下屏幕截图所示，这是驱动 Cloud ML GPU 日志的外观：

在本部分中，我们了解了如何使用 Google Cloud AI 平台进行 XGBoost 模型训练。 部署代码和使用 GCP 强大的并行计算的步骤很重要。 尝试在您的工作环境中执行此处演示的每个步骤。

使用已训练的 XGBoost 模型

将模型存储在 Google Cloud Storage 中之后，需要以正确的格式放置数据以进行预测。 它必须是向量格式且非稀疏。 这意味着您必须具有不包含零值的向量。 如果该值为 0，则必须将其表示为 0.0。 让我们看下面的例子：

执行以下步骤以使用 XGBoost 训练的模型：

  1. 从网络浏览器转到console.google.com。
  2. 在 GCP 控制台中打开“AI 平台模型”页面：

  1. 接下来，您将必须使用以下屏幕快照中显示的输入来创建模型资源：

  1. 之后，创建以下屏幕截图所示的模型版本：

  1. 有效创建模型版本后，AI 平台将从准备用于预测应用的新服务器开始。

现在，您可以运行以下 Python 程序来调用云机器学习 API：

import googleapiclient.discovery

def predict_json(project, model, instances, version=None):
    """Send json data to a deployed model for prediction.
    Args:
        project (str): project where the AI Platform Model is deployed.
        model (str): model name.
        instances ([[float]]): List of input instances, where each input
           instance is a list of floats.
        version: str, version of the model to target.
    Returns:
        Mapping[str: any]: dictionary of prediction results defined by the
            model.
    """
    # Create the AI Platform service object.
    # To authenticate set the environment variable
    # GOOGLE_APPLICATION_CREDENTIALS=<path_to_service_account_file>
    service = googleapiclient.discovery.build('ml', 'v1')
    name = 'projects/{}/models/{}'.format(project, model)

    if version is not None:
        name += '/versions/{}'.format(version)

    response = service.projects().predict(
        name=name,
        body={'instances': instances}
    ).execute()

    if 'error' in response:
        raise RuntimeError(response['error'])

    return response['predictions']

前面的代码是客户端机器学习 Python 代码，并利用了通过 Google Cloud AI 平台部署的模型。 它以 JSON 作为输入并提供预测的输出。 在下一节中，我们将看到如何使用 XGBoost 库构建推荐系统。

您可以在这个页面上找到 Python 客户端库的详细信息。

使用 XGBoost 库构建推荐系统

现代互联网零售客户要求个性化产品。 这提高了他们的满​​意度，因此也增加了电子零售商的收入。 这就是为什么推荐系统已经使用了很多年的原因。 当前的推荐系统所提供的结果主要包括普通产品。 但是，分销商想要的方案也建议不常见的商品，因为在这个漫长的尾巴中，它们仍占零售商销售的很大份额。 亚马逊的推荐系统享有盛誉。 它提出了其他产品，通常与消费者目前正在观看的商品相关。 如果他们不完全了解他们要寻找的内容，建议的系统还可以帮助客户找到产品或访问 Netflix 和 YouTube 时的视频。 它们通常基于称为协同过滤的技术。 通过使用这种方法收集许多用户的偏好来生成用户选择的预测。 假设，如果用户具有等效首选项的子集，则其他不可见产品的等效首选项更有可能出现。

与具有相应历史记录的用户相比，集体过滤仅依赖于用户历史记录。 换句话说，零售商对所提建议的影响有限，强烈建议将其用于普通产品。 对于许多在线公司而言，这是不必要的，因为他们的大部分收入仍然来自知名度较低的产品的长尾巴。 因此，对于公司而言，找到一种能够鼓励少见的普通产品和著名产品的算法至关重要。 为了开发一种平衡的项目推荐系统，将零售商最畅销产品清单中最著名的产品与较不常见的产品结合在一起，建议使用基于树的梯度提升算法 XGBoost。 使用开源 XGBoost 软件库，梯度提升树学习可以成为平衡产品建议的正确方法。

由于推荐系统的长期使用，已经建立了几种推荐算法。 文献表明，最有前途的算法类别包括基于模型的算法。 针对用户-项目关系，交互信息以及用户和项目特征调整了几种机器学习方法。 决策树学习在先前的研究中非常成功。 在该技术中，决策树用于使用标注来预测对象的目标值。 梯度提升方法允许顺序添加模型以纠正先前模型的误差，直到可以进行进一步的改进为止。 结合起来，将创建目标值的最终预测。 更具体地说，建议某个用户购买物品的可能性。

为了进一步说明这一点，让我们以用户项目矩阵为例：

在此用户项目矩阵中，行代表用户，每一列都是项目，每个单元格都是用户评分。 共有j + 1个用户和n + 1个项目。 在此， A[jn]是iₙ的用户uⱼ分数。A[jn]可以在 1 到 5 之间。有时，如果矩阵是用户uᵢ是否查看对象iₙ，A[jn]也可以是二进制的。 在这种情况下， A[jn]为 0 或 1。在我们的情况下，我们将A[jn]视为 1 到 5 分 。 该矩阵是非常稀疏的矩阵，这意味着其中的许多单元都是空的。

由于项目很多，因此单个用户不可能对所有项目进行评分。 在实际情况下，单个用户甚至不会给最低的项目评分。 这就是为什么此矩阵中约有 99% 的单元空着。 空单元格可以表示为非数字（NaN）。 例如，假设n为 1000 万，m为 20,000。 因此n * m为20 ^ 10M，这是一个非常大的数字。 如果用户平均给 5 项评分，则评分总数为5 * 10M = 5 * 10⁶。 这被称为矩阵的稀疏度。 矩阵稀疏度的公式如下：

矩阵的稀疏度 = 空单元数 / 单元总数。

因此，矩阵的稀疏度为(10^10 - 5 * 10^6) / 10^10 = 0.9995。 这意味着 99.95% 的单元格为空。 这是极其稀疏的。

由于稀疏度为 99.95%，因此标准推荐系统可能会考虑有利可图但未由特定用户评级的线下项目。 因此，XGBoost 算法将派上用场。

创建和测试 XGBoost 推荐系统模型

让我们使用 XGBoost 创建一个推荐系统。 这个页面上的代码表示如何使用 XGBoost 构建推荐系统模型。 它基于用户电影评级数据集。 我们将利用 RAPIDS 包进行此实现。 我们将使用conda安装运行时库，安装包，并使用图形库表示结果。

下表包含users.csv的示例数据：

0 50 5 881250949
0 172 5 881250949
0 133 1 881250949
196 242 3 881250949
186 302 3 891717742
22 377 1 878887116
244 51 2 880606923
166 346 1 886397596
298 474 4 884182806
115 265 2 881171488

下表包含movie_lens.csv的示例数据。 这是一个说明性示例。 实际的训练数据可以高达数 GB，一旦我们使用了正确的基础基础架构集，XGBoost 算法就可以有效地训练它：

项目 ID 标题
1 Toy Story（1995）
2 GoldenEye（1995）
3 Four Rooms（1995）
4 Get Shorty（1995）
5 Copycat（1995）
6 Shanghai Triad (Yao a yao yao dao waipo qiao)（1995）
7 Twelve Monkeys（1995）
8 Babe（1995）
9 Dead Man Walking（1995）
10 Richard III（1995）

这些样本文件可用于使用 XGBoost 算法训练和评估模型。 使用非常大的数据集进行训练时，可以显着提高性能。

总结

树增强是一种非常有效的，广泛使用的机器学习技术。 在本章中，我们定义了一种称为 XGBoost 的可伸缩端到端树提升方案，数据研究人员广泛使用该方案来获取有关许多机器学习问题的最新成果。 我们提出了一种用于稀疏数据的新颖算法和一种用于近似树学习的加权分位数草图。 XGBoost 使用比当前系统少得多的资源来扩展数十亿个示例。 在本章中，我们介绍了不同的代码示例，到目前为止，您知道如何使用 Google Cloud AI Platform 提交模型并将这些模型用于预测。

在下一章中，我们将演示使用流组件对运动中的数据执行分析。

四、使用 Cloud AutoML

在上一章中，我们了解了机器学习中最流行，最方便的算法之一。 在本章中，我们将了解 Google 云平台（GCP）如何使通过 AutoML 服务轻松使用各种机器学习模型成为可能。 AutoML 使开发人员和分析人员在数据工程和机器学习编程方面经验有限的情况下，可以轻松构建机器学习模型。 我们将对 AutoML 采取一种实际的方法，并学习如何利用它来构建和部署一些实际用例的模型，例如文档和图像分类，语音到文本转换以及情感分析。

本章将涵盖以下主题：

  • Cloud AutoML 概述
  • 使用 AutoML 自然语言的文档分类
  • 使用 AutoML Vision API 的图像分类
  • 使用语音到文本 API 执行语音到文本转换。
  • 使用 AutoML 自然语言 API 的情感分析

Cloud AutoML 概述

有监督的机器学习模型遵循一致的生命周期。 监督学习取决于历史数据。 基于历史数据，对模型进行训练。 模型训练只是建立一个假设函数，该函数能够根据输入或自变量预测输出或因变量。 例如，在零售商店的销售预测模型的情况下，历史销售数据用于训练。 数据可以横向分布在影响销售的众多因素中。 训练数据被随机分为训练数据集和评估数据集。 通常，训练数据和评估数据之间分别有 80-20 的比例。

基于所选算法对模型进行训练，然后将其用于基于评估数据集评估准确率。 调整训练参数可提高模型的准确率和表现。 一旦模型在各种评估样本中都能很好地运行，就可以在实际环境中进行部署和使用了。 在此阶段，模型遇到了全新的数据集，而在训练过程中可能看不到。 在这里，将假设函数的泛化用于预测。 下图描述了通用的监督学习过程：

传统上，在非云环境中，此过程需要由数据科学家完全管理。 GCP Cloud AutoML 是一个完全托管的环境，负责所有操作流程，基础架构和模型管理。 GCP Cloud AutoML 为与自然语言处理（NLP）和计算机视觉（CV）相关的模型提供了接口。 在本章中，我们将通过利用 NLP 和 CV 接口的示例用例深入探讨 GCP Cloud AutoML。 Cloud AutoML 的优点如下：

  • 易于使用：机器学习经验有限的开发人员可以轻松地使用 AutoML 平台来训练自定义机器学习模型。 可以根据特定的业务用例快速定制模型。 底层的复杂性由 GCP 管理，最终用户在训练模型和运行各种实验时无需担心计算能力或存储需求。
  • 高性能：通过使用 GCP AutoML 引擎进行训练，评估和部署模型，用户可以访问 Google 的最新计算基础架构和分布式计算平台，从而始终如一地提供可靠的结果 。 根据资源需求与数据量和模型复杂性成比例，对集群进行动态自动缩放。
  • 速度和敏捷性：上图所示的监督学习过程通过 AutoML 提供的简单直观的用户界面进行全面管理。 GUI 使您可以轻松快速地训练，评估，调整和部署模型。 由于可以进行各种实验的速度和敏捷性，可以快速尝试和测试不同的模型。 可以调整参数并可以快速验证结果。 这使得模型开发和部署过程极为灵活。

AutoML 的工作原理

通过在机器学习模型的训练，评估和部署上创建高层抽象，AutoML 简化了有监督的学习过程。 下图显示了 AutoML 的工作原理：

将 AutoML 与传统的有监督的学习管道进行比较，显而易见：

  • AutoML 简化了训练，评估和部署 ML 模型的过程。
  • 此外，AutoML 支持通过 RESTful API 与模型进行交互。
  • 与 REST API 集成后，可以轻松利用来自各种应用和端点的机器学习模型。
  • AutoML 用户界面通常用于实验和快速测试假设。

但是，REST API 用于训练，评估和利用机器学习模型。 这是 AutoML 支持的通用和代表性 API 端点的快速概述。

AutoML API 概述

RESTful API 被基于 GCP 的 AI 应用用来调用 AutoML 服务。 用户界面通常用于概念验证，但是企业应用需要一组丰富的 API 库才能与诸如 AutoML 之类的组件进行交互。 在本节中，我们将介绍一组代表性的 API 和这些 RESTful API 中的重要字段。

让我们看一下与v1beta1.projects.locations.models中的模型进行交互的 API 端点。

REST 源 – 指向模型位置

在下表中，我们列出了通过模型位置 API 进行的一些基本方法调用。 调用应用需要将适当的参数传递给 API 端点，以创建和删除模型并将其用于预测：

方法 端点 说明 响应
create POST /v1beta1/{parent}/models 创建一个模型 完成后在响应字段中返回模型
delete DELETE /v1beta1/{name} 删除模型 完成后，在响应字段中返回google.protobuf.Empty，在元数据字段中返回deleteDetails
get GET /v1beta1/{name} 获取模型 如果成功，则响应主体包含模型的实例
predict POST /v1beta1/{name}/predict 预测 执行预测

让我们看一下可用于调用 API 的实际有效负载。 这是机器学习模型的 JSON 表示形式。 以下代码段描述了关键字段和相应的数据类型：

{
  "name": string,
  "displayName": string,
  "datasetId": string,
  "createTime": string,
  "updateTime": string,
  "deploymentState": enum(DeploymentState),

  // Union field model_metadata can be only one of the following:
  "imageClassificationModelMetadata": {
    object(ImageClassificationModelMetadata)
  },
  "textClassificationModelMetadata": {
    object(TextClassificationModelMetadata)
  },
  "translationModelMetadata": {
    object(TranslationModelMetadata)
  }
  // End of list of possible types for union field model_metadata.
}

应用运行时需要提供通用存根，以利用响应内容并利用调用应用中的响应。

让我们看一下前面代码中的字段描述：

  • name：这是一个仅输出的字段，代表模型的资源名称。 该字段的输出格式为projects/{project_id}/locations/{locationId}/models/{modelId}。
  • displayName：此字段是 GCP Web 界面中显示的模型的名称。 名称可以由用户选择。 管理此字段名称的规则如下：
    • 长度最多为 32 个字符。
    • 它可以包含 ASCII 拉丁字母A-Z和a-z：
      • 下划线（_）
      • ASCII 数字0-9
    • 第一个字符必须是字母。
  • datasetId：此字段指向用于创建模型的数据集的资源 ID。 数据集必须属于相同的祖先项目和位置。
  • createTime/updateTime：这是创建/更新模型时的日期时间戳。 GCP 使用具有纳秒精度的 RFC3339 UTC 格式，例如2019-03-05T15:01:23.045123456Z。
  • deploymentState：这是模型的当前状态。 GCP 平台上模型的可能状态如下：
    • DEPLOYMENT_STATE_UNSPECIFIED：不应使用。
    • DEPLOYED：已部署模型。
    • UNDEPLOYED：未部署模型。

imageClassificationModelMetadata，textClassificationModelMetadata和translationModelMetadata分别用于图像，文本和翻译模型。 我们将在本章的后续部分中对此进行解释。

这是用于模型评估的 REST 源 API：v1beta1.projects.locations.models.modelEvaluations。

REST 源 – 用于评估模型

这是获取和列出模型评估的方法调用：

方法 端点 说明
get GET /v1beta1/{name} 获得模型评估
list GET /v1beta1/{parent}/modelEvaluations 列出模型评估

可以使用简单的 API 列出模型评估参数，并且可以将其用于调用应用中的迭代模型改进。

以下 API 使应用能够在运行时分析模型操作。 在某些情况下，由于数据量和模型复杂性，模型训练和评估需要更长的时间。 这些操作调用帮助应用向最终用户报告模型训练和评估的状态。

REST 源 – 操作 API

下表列出了v1beta1.projects.locations.operations API：

方法 端点 说明
cancel POST /v1beta1/{name} 在长时间运行的操作上启动异步取消
delete DELETE /v1beta1/{name} 删除长时间运行的操作
get GET /v1beta1/{name} 获取长时间运行的操作的最新状态
list GET /v1beta1/{name}/operations 列出与请求中的指定过滤器匹配的操作
wait POST /v1beta1/{name}/wait 等待指定的长时间运行的操作，直到完成或最多达到指定的超时，并返回最新状态

请注意，对于操作 API 的请求是异步的，并且对于调用应用是非阻塞的。 这些对于调用应用以报告模型训练和评估的进度很有用。

使用 AutoML 自然语言的文档分类

文档分类是一个非常重要的用例，主要用于分析文档或大量文档（例如法律文档）的内容。 有时，手动分类需要付出很多努力，而且可能不可行。 GCP 提供了易于使用的自然语言界面，可以对其进行自定义训练，以基于 AutoML 进行文档分类。 让我们了解一个包含 20 个新闻组的公共可用数据集的分类过程。 该数据集可从这里下载。 这是大约 20,000 个新闻组文档的集合，平均分布在 20 个不同的新闻组中。 这些新闻组对应于不同的主题。 目标是根据训练数据训练模型，评估模型，最后将其用于文档分类。

用于文档分类的传统的机器学习方法

文档分类过程遵循一组标准步骤。 在训练分类模型之前，需要对文档内容进行分类，以确保分类的准确率。 下图显示了以传统方式使用机器学习进行文档分类的整个过程：

与该图所示的方法不同，AutoML 简化了文档分类的流程。

使用 AutoML 的文档分类

在本节中，我们将研究 GCP 中的 AutoML 接口，以使用 AutoML 进行文档分类。

导航到 AutoML 自然语言界面

使用您的 GCP 凭据登录这里。 在导航菜单上，转到人工智能部分，然后单击自然语言子菜单：

AutoML 自然语言使上传数据集和训练模型变得容易。 在我们的示例中，数据集是新闻组文档的集合。

创建数据集

要创建新数据集，请单击标题栏中的“新建数据集”按钮：

为数据集提供唯一的名称（在这种情况下为newsgroups）。 GCP 提供以下用于上传数据集的选项：

  • 从计算机上载 CSV 文件：CSV 文件应包含 Google Cloud Storage 路径列表和相应的标签，并用逗号分隔。
  • 从计算机上载文本项：该界面允许选择多个文本文件或包含多个文件的 ZIP 存档。
  • 在云存储上选择 CSV：可以从 Cloud Storage 中选择包含路径和标签的带标签的 CSV 文件。

创建数据集后，可以从 Google Cloud Storage URI 和本地驱动器导入其他项目。

标记训练数据

可以通过在上传到数据集的 CSV 文件中包含标签并使用 AutoML Natural Language UI 来为文本文档添加标签来标记训练数据：

创建标记的训练数据集时，请考虑以下提示：

  • 创建具有可变长度文档以及各种写作风格和作者的数据集。 较高的变化水平可提高模型准确率。
  • 这些文档需要对人类读者分类。 AutoML 界面取决于预先标记的训练数据，因此模型的准确率取决于手动标记过程的准确率。
  • GCP 建议每个标签有 1,000 个训练文件。 每个标签的最小文档数为 10。每个标签的训练样本数量越多，内容的变化也越大，模型的准确率就越高。
  • 对于无法归入预定义标签之一的文档，请使用None_of_the_above或等效标签。 这将提高模型的准确率，而不是贴错标签或保留空白标签。

训练模型

创建数据集并对其进行完全标记后，即可对模型进行训练。 单击 TRAIN NEW MODEL 按钮，通过提供模型名称来启动异步训练过程。 模型名称最多可以包含 32 个字符，并且可以包含字母，数字和下划线。 模型训练所需的时间取决于训练数据的数量和变化。 训练模型可能需要几分钟到几个小时。 一旦模型训练完成，就会向已注册的电子邮件 ID 发送电子邮件通知。

如下面的屏幕快照所示，模型经过训练后，将显示模型属性（例如，模型创建时的日期时间和训练数据的定量性质）以及质量参数（例如精度和召回）：

评估模型

与传统的机器学习管道不同，在传统的机器学习管道中，我们需要在评估数据集上评估模型，而 GCP 在内部使用测试集中的项目评估模型。 在此阶段检查模型的质量和准确率。 AutoML 提供了两个级别的聚合质量指标，这些指标指示模型在所有特征和标签以及每个类别标签上的总体训练水平。 GCP 报告了以下指标：

  • AuPRC（精度和召回曲线下的面积）：这表示平均精度。 典型值在 0.5 到 1.0 之间。 值越高表示模型越准确。
  • 精度和召回曲线：AutoML 提供了一种交互式方式来设置标签的阈值。 较低的阈值会增加召回率，但会降低精度：

  • 混淆矩阵：这可以可视化模型的准确率，以预测输出类别。 它代表评估阶段训练数据中输出标签的百分比：

这些易于使用的 AutoML 度量标准可用于评估模型的可靠性，从而预测实际数据集上的输出类别。 如果混乱程度很高，而准确率和召回率得分很低，则该模型可能需要其他训练数据。

除了用于模型评估的 Web 界面之外，GCP 还提供了一个可编程的 API 接口，用于使用命令行，Python，Java 和 Node.js 进行评估。

命令行

使用以下命令通过将model-name替换为实际模型名称来获取 JSON 格式的模型评估参数：

curl -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" -H "Content-Type:application/json" https://automl.googleapis.com/v1beta1/model-name/modelEvaluations

此命令以 JSON 格式返回评估参数，如下所示：

{
  "modelEvaluation": [
    {
      "name": "projects/434039606874/locations/us-central1/models/7537307368641647584/modelEvaluations/9009741181387603448",
      "annotationSpecId": "17040929661974749",
      "classificationMetrics": {
        "auPrc": 0.99772006,
        "baseAuPrc": 0.21706384,
        "evaluatedExamplesCount": 377,
        "confidenceMetricsEntry": [
          {
            "recall": 1,
            "precision": -1.3877788e-17,
            "f1Score": -2.7755576e-17,
            "recallAt1": 0.9761273,
            "precisionAt1": 0.9761273,
            "f1ScoreAt1": 0.9761273
          },
          {
            "confidenceThreshold": 0.05,
            "recall": 0.997,
            "precision": 0.867,
            "f1Score": 0.92746675,
            "recallAt1": 0.9761273,
            "precisionAt1": 0.9761273,
            "f1ScoreAt1": 0.9761273

有两个主要的封装对象用于表示模型评估参数：标头级别的分类指标和置信度指标。 在此 JSON 响应中还报告了准确率和召回率得分。

Python

这是用于获取模型评估参数的 Python 代码片段：

project_id = 'PROJECT_ID'
compute_region = 'COMPUTE_REGION'
model_id = 'MODEL_ID'
filter_ = 'Filter expression'

from google.cloud import automl_v1beta1 as automl

client = automl.AutoMlClient()

# Get the fully qualified path of the model based on project, region and model
model_full_id = client.model_path(project_id, compute_region, model_id)

# Apply the filter for listing all the model evaluations. 
response = client.list_model_evaluations(model_full_id, filter_)

print("Loop for listing all the model evaluations received based on the filter condition")
for element in response:
    print(element)

此代码段获取模型评估参数，并在响应上进行迭代，并打印各个参数，例如精度和召回率。

Java

这是用于获取模型评估参数的等效 Java 代码：

public static void autoMLModelEvaluation(
    String projectId, String computeRegion, String modelId, String filter) throws IOException {
  // Instantiates a client
  AutoMlClient client = AutoMlClient.create();

  // Get the full path of the model.
  ModelName modelFullId = ModelName.of(projectId, computeRegion, modelId);

  // List all the model evaluations in the model by applying filter
  ListModelEvaluationsRequest modelEvaluationsrequest = ListModelEvaluationsRequest.newBuilder()
          .setParent(modelFullId.toString())
          .setFilter(filter)
          .build();

  // Iterate through the results.
  String modelEvaluationId = "";
  for (ModelEvaluation element : client.listModelEvaluations(modelEvaluationsrequest).iterateAll()) {
    if (element.getAnnotationSpecId() != null) {
      modelEvaluationId = element.getName().split("/")[element.getName().split("/").length - 1];
    }
  }

  // Resource name for the model evaluation.
  ModelEvaluationName modelEvaluationFullId =
      ModelEvaluationName.of(projectId, computeRegion, modelId, modelEvaluationId);

  // Get a model evaluation.
  ModelEvaluation modelEvaluation = client.getModelEvaluation(modelEvaluationFullId);

  ClassificationEvaluationMetrics classMetrics = modelEvaluation.getClassificationEvaluationMetrics();
  List<ConfidenceMetricsEntry> confidenceMetricsEntries = classMetrics.getConfidenceMetricsEntryList();

// Iterate over the list and get individual evaluation parameters.

此代码段获取模型评估参数，并在响应上进行迭代，并打印各个参数，例如精度和召回率。 也可以将其打包为独立的 API 调用，并开发为微服务。

Node.js

这是评估代码的 Node.js 实现。 代码简洁明了，并异步调用评估 API：

const automl = require(`@google-cloud/automl`);
const util = require(`util`);

const client = new automl.v1beta1.AutoMlClient();

const projectId = `PROJECT_ID`;
const computeRegion = `REGION_NAME`;
const modelId = `MODEL_ID`;
const modelEvaluationId = `MODEL_EVAL_ID`;

  // Get the full path of the model evaluation.
  const modelEvaluationFullId = client.modelEvaluationPath(
    projectId,
    computeRegion,
    modelId,
    modelEvaluationId
  );

  // Get complete detail of the model evaluation.
  const [response] = await client.getModelEvaluation({
    name: modelEvaluationFullId,
  });
  console.log(util.inspect(response, false, null));

可以使用此代码段开发无阻塞的异步微服务，该代码段可以使用评估参数响应调用的应用。

将模型用于预测

建立并评估模型后，GCP 将提供一个简单的界面，用于使用模型进行预测。 在这种情况下，该模型已准备好根据输入数据中的关键字对各种类别的文档进行分类。

Web 界面

GCP 提供了用于快速测试模型的 Web 界面和 REST API，可在生产环境中用于文档分类：

在这种情况下，模型已基于在文本区域中输入的文本，以 100% 的置信度预测文档与计算机图形学相关。

用于模型预测的 REST API

我们可以使用一个简单的 REST API 来使用已部署的模型进行预测：

export GOOGLE_APPLICATION_CREDENTIALS=key-file-path 

curl -X POST   
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" 
-H "Content-Type: application/json" 
https://automl.googleapis.com/v1beta1/projects/ai-gcp-ch4/locations/us-central1/models/TCN2853684430635363573:predict 
-d '{
         "payload" : {
           "textSnippet": {
                "content": "YOUR TEXT HERE",
                 "mime_type": "text/plain"
            },
         }
    }'

可以在生产环境中使用 Python 调用该 API。

用于模型预测的 Python 代码

将以下代码保存在名为document_classifier.py的文件中。 此代码使用已部署的模型进行预测：

import sys 

from google.cloud import automl_v1beta1 
from google.cloud.automl_v1beta1.proto 
import service_pb2 

def get_prediction(content, project_id, model_id):
   prediction_client = automl_v1beta1.PredictionServiceClient()
   name = 'projects/{}/locations/us-central1/models/{}'.format(project_id, model_id)
   payload = {'text_snippet': {'content': content, 'mime_type': 'text/plain' }}
   params = {}
   request = prediction_client.predict(name, payload, params)
   return request # waits till request is returned
 if __name__ == '__main__':
   content = sys.argv[1]
   project_id = sys.argv[2]
   model_id = sys.argv[3]
   print get_prediction(content, project_id, model_id)

用python document_classifier.py "Document Text" <<project_id>> <<model_id>>调用文档分类器 API。 通过传递项目 ID 和已部署的模型 ID，可以使用此命令执行 Python 代码。

使用 AutoML Vision API 的图像分类

GCP 提供了 Vision API，可用于以可视输入（图像和视频）的形式为非结构化数据构建智能应用，并可通过 Web 控制台和 API 进行访问。

AutoML Vision 的图像分类步骤

GCP 上的图像分类过程遵循与 AutoML 文档分类中的文档分类过程相似的步骤。 以下是图像分类中涉及的步骤：

假设您已经知道如何设置 Google 帐户并创建了 GCP 项目。 让我们从收集训练图像步骤中逐步进行图像分类的步骤。

收集训练图像

AutoML Vision API 使用监督学习模型，因此需要训练图像的集合。 这些是用于训练目的的预先标记图像。 图像中可以包含一个或多个对象，并且需要以样本为基础定义和验证各个输出标签以确保准确率。 我们需要建立一个数据集来训练图像分类模型。

创建数据集

第一步，我们需要为图像创建一个占位符，以用于训练和评估模型。 创建数据集时，我们需要将分类类型称为多类或多标签。 在多分类器的情况下，将单个标签分配给每个分类的文档，而多标签分类器可以将多个标签分配给一个文档。

Web 界面提供了创建数据集的直观方法：

  1. 单击标题栏中的新数据集按钮。 以下屏幕快照显示了用于创建数据集的用户界面：

  1. 在项目中为新数据集提供唯一的名称。 有两种方法可以在数据集创建 UI 中上传图像：
    • 从您的计算机上载图像：AutoML 支持 JPG 和 PNG 格式。 包含一组 JPG 或 PNG 图像的 ZIP 归档文件也可以批量上传。
    • 在 Cloud Storage 上选择一个 CSV 文件：一个逗号分隔的文件，其中包含 Google Cloud Storage 上图像的路径列表及其标签（如果在创建数据集时可用）。

也可以将图像导入推迟到以后，并且可以将其中没有任何图像的数据集创建为占位符。 可以通过选中启用多标签分类复选框来指定分类类型。 默认分类类型是多分类。

标记和上传训练图像

我们将利用 Cloud Storage 上载图像并创建一个 CSV 文件来标记图像文件的内容。 我们将创建一个 Google Cloud Storage 存储桶，并存储将用于训练自定义模型的文档。 使用 Google Cloud Shell 中的以下命令创建 Cloud Storage 存储桶：

gsutil mb -p ai-gcp-ch4 -c regional -l us-central gs://ai-gcp-ch4-vcm/

值区名称必须采用PROJECT_ID-vcm格式。

此命令将在项目内创建名称为ai-gcp-ch4-vcm的存储桶。

我们将通过以下命令在新创建的存储桶中使用包含花卉图像的公共可用数据集：

gsutil -m cp -R gs://cloud-ml-data/img/flower_photos/  gs://ai-gcp-ch4-vcm/img/

将图像批量装入存储桶后，标记图像的最简单方法是使用 CSV。 CSV 文件的通用格式为Image_Path, Label(s)。 如果有多个标签（一个图像中有多个对象），则各个标签需要用逗号（,）分隔，如以下示例所示：

gs://ai-gcp-ch4-vcm/img/flower_photos/roses/15674450867_0ced942941_n.jpg,roses
gs://ai-gcp-ch4-vcm/img/flower_photos/daisy/1031799732_e7f4008c03.jpg,daisy

在此示例中，第一个图像包含玫瑰，第二个图像包含雏菊花。 让我们将图像和标签导入数据集中：

CSV 文件中列出的图像以及存储在存储桶中的图像将被加载到数据集中并在此步骤中进行标记。 至此，我们的数据集已准备好训练分类模型。 这是 AutoML Vision 界面中带标签的数据集的快照：

我们的数据集包含分布在五个标签中的 3,665 个标签图像。 Web 界面允许修改标签并根据需要删除图像。 也可以通过使用 REST API 和命令行界面来填充带有标签图像的数据集，并且可以通过实用地调用它。

这是可用于调用 API 的 HTTP POST URL。 （在此 URL 字符串中替换Project_ID，Region和datasetId）：

POST https://automl.googleapis.com/v1beta1/projects/ai-gcp-ch4/locations/us-central1/datasets/ICN7902227254662260284:importData

请求正文包含以下 JSON 格式的有效负载：

{
     "inputConfig": {
     "gcsSource": {
     "inputUris": "gs://ai-gcp-ch4-vcm/img/flower_photos/all_data_updated.csv",
     }
    }
}

将请求正文保存在import_images_request.json文件中，然后在 Cloud Shell 上发送curl请求：

curl -X POST \
-H "Authorization: Bearer "$(gcloud auth application-default print-access-token) \
-H "Content-Type: application/json; charset=utf-8" \
-d @import_images_request.json \
https://automl.googleapis.com/v1beta1/projects/ai-gcp-ch4/locations/us-central1/datasets/ICN7902227254662260284:importData

也可以通过导入automl_v1beta1包从 Python 调用该 API。 这是用于将图像导入数据集中的 Python 代码段：

project_id = 'ai-gcp-ch4'
compute_region = 'us-central1'
dataset_id = 'ICN7902227254662260284'
paths = 'gs://ai-gcp-ch4-vcm/img/flower_photos/all_data_updated.csv'

from google.cloud import automl_v1beta1 as automl

client = automl.AutoMlClient()
dataset_full_id = client.dataset_path(project_id, compute_region, dataset_id)
input_config = {'gcs_source': {'input_uris': paths}}
response = client.import_data(dataset_full_id, input_config)
print('Processing import...')
print('Data imported. {}'.format(response.result()))

将图像加载到数据集中后，下一步就是训练分类模型。

训练模型

GCP AutoML 抽象了实际模型训练的复杂性，并从数据集中的图像创建了三个唯一的集合。 80% 的图像被随机标记为训练集，而 10% 的图像分别用于评估和测试集。 一个简单的界面启动分类模型训练过程：

根据训练图像的数量，标签的数量以及分配的计算资源，模型训练最多可能需要 15 分钟或几个小时。 该过程是异步的，一旦模型训练完成，便会触发电子邮件。 模型训练也可以通过命令行和实用地调用 API 来完成。

这是训练模型的POST请求（为Project_ID，Region，datasetId和displayName使用适当的参数； displayName是模型的名称，可由用户选择） ）：

curl \
-X POST \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
https://automl.googleapis.com/v1beta1/projects/ai-gcp-ch4/locations/us-central1/models \
-d '{
       "datasetId": "ICN7902227254662260284",
       "displayName": "aigcpch4-image-clasification-model",
       "image_object_detection_model_metadata": {
            "model_type": "cloud-low-latency-1"
       },
    }'

model_type有两个选项。 cloud-low-latency-1以模型准确率为代价来最小化训练时间，而cloud-high-accuracy-1通过进行更多次训练迭代来最小化训练误差并创建更准确的模型，因此需要更多的时间和计算资源来进行训练。 需要根据特定用例以及时间和成本预算进行选择。 可以利用 AutoML Vision API 进行实用的模型训练。 这是训练模型的 Python 代码：

project_id = 'ai-gcp-ch4'
compute_region = 'us-central1'
dataset_id = 'ICN7902227254662260284' 
model_name = 'aigcpch4-image-clasification-model'

from google.cloud import automl_v1beta1 as automl

client = automl.AutoMlClient()
project_location = client.location_path(project_id, compute_region)

my_model = {
    'display_name': model_name,
    'dataset_id': dataset_id,
    'image_object_detection_model_metadata': {
        "model_type": "cloud-low-latency-1"
    }
}
response = client.create_model(project_location, my_model)
print('Training image object detection model...')

模型训练完成后，该模型将在 AutoML Vision Web 界面的“模型”部分列出：

下一步是评估模型的准确率。 可在 Web 界面的EVALUATE选项卡下获得评估统计信息。

评估模型

使用训练集对模型进行训练后，评估集将用于模型评估。 评估结果位于“评估”选项卡中，并显示“平均精度”，“精度”和“调用率”。 这是用于评估模型的 Web 界面的屏幕截图：

如屏幕截图所示，我们在用户界面上获得了模型评估指标。 我们得到以下重要的模型训练参数：

  • 平均精度：这可衡量所有得分阈值上的模型表现。
  • 精度：这是对阳性指示正确比例的度量。 在数学上，精度定义为Pred = TP / (TP + FP)。 真实肯定代表模型正确预测肯定类别的结果。 假阳性表示模型错误地预测阳性类别的结果。
  • 召回：这是对正确识别的实际阳性比例的度量。 在数学上，召回率定义为Recall = TP / (TP + FN)。 假阴性表示模型错误地预测阴性类别的结果。

可以同时使用精度和召回措施对模型进行全面评估，因此平均精度对于理解模型的有效性非常重要。 AutoML 提供了所有标签上模型参数的合并视图以及特定标签的参数值：

可以使用 REST API 评估模型，可以通过命令行以及实用地调用 REST API。

命令行界面

这是用于从 GCP AutoML 上部署的模型中获取模型评估的命令：

curl -X GET \
-H "Authorization: Bearer "$(gcloud auth application-default print-access-token) \
https://automl.googleapis.com/v1beta1/projects/ai-gcp-ch4/locations/us-central1/models/ICN7883804797052012134/modelEvaluations

我们需要提供项目名称，区域和模型 ID，以便使用命令行界面获得评估。

Python 代码

这是一段 Python 代码，可用于获取已部署模型的模型评估。 我们需要传递project_id，region 和model_id作为参数：

project_id = 'ai-gcp-ch4'
compute_region = 'us-central1'
model_id = 'ICN7883804797052012134'
filter_ = ''
from google.cloud import automl_v1beta1 as automl
client = automl.AutoMlClient()
model_full_id = client.model_path(project_id, compute_region, model_id)
response = client.list_model_evaluations(model_full_id, filter_)
print('List of model evaluations:')
for element in response:
 print(element)

一旦建立了模型并评估了阈值准确率，就可以使用一组新图像来测试模型了。

测试模型

GCP AutoML 提供了一个简单的界面来测试模型。 可以从 Web UI 上载新图像，并根据部署的模型进行测试。 这是 Web UI 的屏幕截图，展示了所需的步骤：

还可以通过 REST API 使用命令行以及以编程方式测试和使用该模型。

创建一个image_classification_request.json文件，如下所示：

{ "payload": { "image": { "imageBytes": "IMAGE_BYTES" } } }

将以下请求发送到 Web 服务：

curl -X POST -H "Content-Type: application/json" \
  -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
  https://automl.googleapis.com/v1beta1/projects/ai-gcp-ch4/locations/us-central1/models/ICN7883804797052012134:predict -d @image_classification_request.json

Python 代码

以下是可在应用内用于基于一组新图像调用模型的 Python 代码：

import sys
from google.cloud import automl_v1beta1
from google.cloud.automl_v1beta1.proto import service_pb2
def get_prediction(content, project_id, model_id):
  prediction_client = automl_v1beta1.PredictionServiceClient()
  name = 'projects/{}/locations/us-central1/models/{}'.format(project_id, model_id)
  payload = {'image': {'image_bytes': content }}
  params = {}
  request = prediction_client.predict(name, payload, params)
  return request # waits till request is returned
if __name__ == '__main__':
  file_path = sys.argv[1]
  project_id = sys.argv[2]
  model_id = sys.argv[3]
  with open(file_path, 'rb') as ff:
    content = ff.read()
  print get_prediction(content, project_id, model_id)

如本节中所述，AutoML 使无缝训练该图像分类模型变得无缝且容易，并且该模型已部署在云上，并且可以由经过认证的用户和服务帐户使用简单的 API 接口进行访问。

使用语音文本 API 执行语音文本转换

GCP 提供了一个非常有效且易于使用的 API，用于语音到文本的转换。 尽管界面简单直观，但下方仍存在深度神经网络，可不断训练并丰富语音到文本模型。 应用开发人员无需了解底层细节以及特定的神经网络配置和调整。 在撰写本文时，API 可以识别一百多种语言和方言。 该平台以批量和实时模式提供语音到文本转换服务。 随着平台被越来越多的用户用于转换，模型的准确率会在一段时间内提高。 该平台还提供用于自动检测口语的 API。 在允许语音命令的特定用例中，此功能非常方便。 该 API 允许选择适合特定用例的预构建模型。 例如，命令和搜索模型最适合语音命令，电话模型最适合记录电话对话。 下图描述了语音文本 API 的所有受支持的功能：

在本节中，我们将遍历 API 并了解如何利用语音转文本 API 来构建应用。

与语音到文本 API 交互的方法有以下三种：

  • 同步识别：这是一个阻塞 API 调用，适用于少于 1 分钟的音频内容。 音频数据将发送到 REST 或 gRPC 端点。 仅当转录整个音频内容时，API 才会响应。
  • 异步识别：这是一个非阻塞 API 调用，适用于持续时间较长的音频内容（最长 480 分钟）。 此 API 调用在云上启动了长期运行的操作，并且调用服务需要定期轮询以获取转录结果。 呼叫服务需要在后续呼叫期间管理文本数据，以优化表现。
  • 流识别：用于实时转录，并通过 gRPC 作为双向流进行支持。 文本转换过程是实时的，并且响应文本可以作为连续流使用。 呼叫服务需要收集时间序列数据并将其用作流。

同步请求

请求主体由配置参数和音频文件的路径组成。 同步请求示例如下：

{
    "config": {
        "encoding": "LINEAR16",
        "sampleRateHertz": 16000,
        "languageCode": "en-US",
    },
    "audio": {
        "uri": "gs://bucket-name/path_to_audio_file"
    }
}

JSON 请求正文中的config字段是RecognitionConfig对象的体现，其 JSON 表示如下：

{
  "encoding": enum (AudioEncoding),
  "sampleRateHertz": number,
  "audioChannelCount": number,
  "enableSeparateRecognitionPerChannel": boolean,
  "languageCode": string,
  "maxAlternatives": number,
  "profanityFilter": boolean,
  "speechContexts": [
    {
      object (SpeechContext)
    }
  ],
  "enableWordTimeOffsets": boolean,
  "enableAutomaticPunctuation": boolean,
  "metadata": {
    object (RecognitionMetadata)
  },
  "model": string,
  "useEnhanced": boolean
}

下表中定义了 JSON 模板中的字段：

字段名称 类型 说明
encoding enum 该字段定义了需要转录的音频文件的编码。 API 支持以下值：
ENCODING_UNSPECIFIED
LINEAR16 – 16 位未压缩格式
FLAC（免费无损音频编解码器）：这种编码比 LINEAR16 更可靠，并且需要一半的带宽
MULAW/AMR（自适应多速率窄带编解码器）/AMR_WB（宽带）/OGG_OPUS/SPEEX_WITH_HEADER_BYTE
sampleRateHertz number 该字段定义音频数据的采样率。 数据点的范围为 8,000 至 48,000 Hz。 对于 WAV 和 FLAC 音频格式，此字段是可选的。
audioChannelCount number 该字段指示输入音频数据中的多个通道。
enableSeparateRecognitionPerChannel boolean 如果audioChannelCount大于 1，则需要将该参数显式设置为True。
languageCode string 这是指示对话语言的必填字段。 例如，en-US用于表示美国英语。
maxAlternatives number 这是一个可选参数，指示响应中返回的替代识别消息的最大数量。 根据训练的模型和语音上下文，服务器返回的值可能少于设置的替代值。 参数值范围为 0 到 30。 值 0 或 1 将最多返回一个识别，如果该字段不是请求的一部分，则最多返回一个识别。
profanityFilter boolean 这是一个可选属性，如果设置为True，则会过滤出亵渎或淫秽的语言表达式。
speechContexts[] 对象（SpeechContext） 这是一个可选的但重要的属性，可为识别模型提供提示以实现更准确的转录。 通过在此对象中发送语音上下文，可以消除由于语音上相似的单词而引起的潜在错误，从而可以基于语音上下文进行更准确的识别。
enableWordTimeOffsets boolean 这是个可选的选项。 如果设置为true，则转录语音中的每个单词都将在音频信号中标记其开始和结束时间。 默认情况下，此参数的值为false。
enableAutomaticPunctuation boolean 此可选字段仅影响所选的语言，当前可作为实验字段使用。 启用后，转录将包括标点文本。 默认情况下，该参数设置为false。
metadata object 这是一个可选字段，提供有关音频信号的元数据。 该字段是RecognitionMetadata类型，包含以下子字段：interactionType/industryNaicsCodeOfAudio/microphoneDistance/originalMediaType/recordingDeviceType/recordingDeviceName/originalMimeType/obfuscatedId/audioTopic元数据为模型提供了其他提示，这些提示用于更准确和上下文相关的转录。
model string 这是一个可选字段，用于选择适当的机器学习模型以执行语音到文本的识别。 选择合适的识别模型可以大大提高转录的准确率。 如果未设置模型，则根据RecognitionConfig中的参数选择运行时模型。 以下是 GCP 上当前可用模型的列表：
command_and_search：最适合语音命令或语音搜索的模型
phone_call：最适合电话对话转录的模型
video：最适合从原始视频数据中提取音频信号的模型
default：未指定或无法使用特定对话模型时的模型
useEnhanced boolean 这是一个可选参数，为使用增强型模型而设置为true。 增强型模型比常规模型更准确，成本也更高。

通过在请求的audio字段中发送content参数，可以将音频内容嵌入到请求主体中。 嵌入式内容可以成为 gRPC 或 REST 请求的一部分。 对于 gRPC 请求，音频必须与协议缓冲区版本 3 语言规范兼容，并作为二进制数据嵌入。 在 REST 请求中发送嵌入式音频时，需要对音频进行 JSON 序列化和 Base64 编码。 这是在请求正文中发送 Base64 编码的音频内容的示例：

  {
      "config": {
        "encoding":"WAV",
        "sampleRateHertz":18000,
        "languageCode":"en-US"
      },
      "audio": {
        "content": "XtxhQwJJJCIQABQLLTUJABtAA+gA8AB+W8FZndQvQAyjv..."
      }
    }

这是 Base64 编码的音频数据的 Python 代码：

import base64

def encode_audio(audio):
  audio_content = audio.read()
  return base64.b64encode(audio_content)

或者，可以通过使用 URI 指向内容来在请求中发送对音频内容的引用。 指向的音频应为原始二进制格式，而不是 Base64 编码格式。 URI 指向 Google Cloud Storage 上音频文件的请求示例如下：

 {
      "config": {
        "encoding":"WAV",
        "sampleRateHertz":18000,
        "languageCode":"en-US"
      },
      "audio": {
        "uri": "gs://bucket-name/path_to_audio_file"
      }
    }

URI 指向的音频文件应该可以通过互联网公开访问和/或可以通过 GCP 上的服务帐户访问。

同步请求提供的时间响应与音频内容的长度成正比。 以以下格式接收响应：

{
  "name": "8214202757943088943",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeMetadata",
    "progressPercent": 100,
    "startTime": "2019-09-22T08:16:32.013650Z",
    "lastUpdateTime": "2019-09-22T08:16:55.278630Z"
  },
  "done": true,
  "response": {
    "@type": "type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeResponse",
    "results": [
      {
        "alternatives": [
          {
            "transcript": "One Two Three Four",
            "confidence": 0.97186122,
            "words": [
              {
                "startTime": "1.300s",
                "endTime": "1.400s",
                "word": "One"
              },
              {
                "startTime": "1.400s",
                "endTime": "1.600s",
                "word": "two"
              },
              {
                "startTime": "1.600s",
                "endTime": "1.600s",
                "word": "three"
              },
              {
                "startTime": "1.600s",
                "endTime": "1.900s",
                "word": "four"
              },
              ...
            ]
          }
        ]
      },
      {
        "alternatives": [
          {
            "transcript": "one too thee four",
            "confidence": 0.9041967,
          }
        ]
      }
    ]
  }
}

响应包含两个不同的部分：

  • 标头信息：这是有关语音到文本转录过程的标头级信息。 标头包含以下字段：
    • name：这是语音转文字 API 分配的唯一名称。
    • metadata：包括以下内容：
      • @type：此字段表示 GCP 定义的响应类型。 该字段指向对象定义 URI。
      • progressPercent：此字段表示转录完成的百分比。
      • startTime：这是语音到文本翻译的开始时间。
      • LastUpdateTime：这是 API 上次更新状态的时间。
  • 响应：包含以下字段：
    • @type：此字段表示由 GCP 定义的响应主体的类型。 该字段指向对象定义 URI（type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeResponse）。
    • results：这是一个收集对象，它是基于音频输入的连续部分的语音到文本转换单元的顺序列表。
    • alternatives：每个单独的顺序结果均包含一个或多个具有不同置信度的替代转录。 备选方案按置信度降序排列。 通常，第一种选择是最好的，可以由应用使用。 响应中的替代数目由maxAlternatives请求参数控制。
    • transcript：每个备选方案均显示音频部分的笔录。
    • confidence：这是一个数字字段，指示模型与副本的可信度。
    • words：在每个替代成绩单中，都有多个单词。 （可选）这些单词显示在时间轴上（基于enableWordTimeOffsets请求参数的值）：
      • startTime：表示输出单词的音频信号内的开始时间
      • endTime：表示输出单词的音频信号内的结束时间
      • word：实际转录

对于同步转录，该请求将发送到以下端点：

POST https://speech.googleapis.com/v1/speech:recognize

这是一条简单的 HTTP POST消息，以 JSON 格式返回语音识别响应。

异步请求

异步或非阻塞请求在请求主体和标头方面相似。 但是，当请求旨在异步时，API 方法调用是不同的。 调用LongRunningRecognize方法。 响应不会立即返回。 LongRunningRecognize的请求将在调用 API 时立即返回脉冲检查消息，而不是包含转录的响应。 响应格式如下：

{
  "name": "operation_name",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeMetadata"
    "progressPercent": 37,
    "startTime": "2019-09-03T13:24:39.579144Z",
    "lastUpdateTime": "2019-09-03T13:24:39.826903Z"
  }
}

该过程将继续转录请求中发送的音频信号。 转录完成后，将以progressPercent作为100发送响应。 此时，响应的格式与同步响应的格式相同。

流式请求

根据应用的要求，可能需要具有双向流传输功能以实时连续记录音频信号。 语音转文字 API 提供了一种在双向流中进行实时转录的方法。 发送者应用可以将连续的音频信号流发送到 API，并从服务中接收离散的以及完整的转录形式。 即时结果以转录格式表示当前音频，最终响应获得整个转录（类似于同步和异步响应）。

就 API 而言，流请求将作为端点发送到StreamingRecognize方法。 由于该 API 是连续的流式 API，因此会将多个请求发送到具有不同音频窗口的 API。 但是，第一条消息必须包含流请求的配置。 该配置由StreamingRecognitionConfig对象定义，该对象向 API 提供提示以处理特定的流音频信号。 StreamingRecognitionConfig对象定义如下：

  • config：这是我们在本章前面讨论的RecognitionConfig对象。
  • single_utterance：这是一个可选的boolean标志。 当将其设置为false时，尽管语音中有很长时间的停顿，流识别 API 仍会继续转录输入信号。 该流将保持打开状态，直到被调用进程显式关闭为止，或者直到经过了某个时间阈值为止。 在这种情况下，API 可能返回多个StreamingRecognitionResult对象。 如果将此标志设置为true，则模型会检测到音频信号中的暂停，并且 API 返回END_OF_SIGNAL_UTTERANCE事件并完成识别过程。 在这种情况下，API 将仅返回一次出现的StreamingRecognitionResult。
  • interim_results：这是一个可选标志。 如果设置为true，则中间结果由 API 返回；如果设置为false，则 API 仅在转录完成后才返回结果。

API 以StreamingRecognizeResponse消息对象的形式返回响应。 这是流式语音转文本服务 API 返回的唯一对象。 响应对象包含以下重要字段：

  • speechEventType：这表示基础模型检测到的音频对话中的暂停。 API 识别两种事件类型。 SPEECH_EVENT_UNSPECIFIED表示未指定任何事件，END_OF_SINGLE_UTTERANCE表示模型已检测到音频信号中的暂停，并且 API 预计流中不会再有其他音频数据。 仅当single_utterance请求参数设置为true时，才发送此事件。
  • results：这是主要包装对象，其中包含转录结果作为集合：
    • alternatives：类似于同步和异步转录请求，此集合提供了具有不同置信度的各种转录选择。
    • isFinal：当模型录制整个音频信号时，此标志设置为true。
    • stability：在流语音识别的上下文中，语音的重叠部分会在移动的时间窗口上被转录。 这意味着音频信号内的特定位置可以在后续帧内被转录一次以上。 语音到文本模型会生成一个稳定性分数，该分数指示转录发生变化的可能性。 分数为 0 表示不稳定的转录将最终改变，分数为 1 表示原始转录将没有任何变化。

使用 AutoML 自然语言 API 的情感分析

情感分析是构建智能平台的关键实用功能之一，该智能平台可根据最终用户对服务或主题的感知来推荐业务操作。 考虑到数据的上下文和性质的变化，该过程非常复杂。 通常，在大多数情况下，数据是非结构化或半结构化的，这使得难以实现较高的准确率。 作为一般过程，情感分析可以分为以下步骤：

  • 目标设置：需要在用例的上下文中明确定义情感分析的目标。 例如，当要分析购买者的情感时，我们需要将其围绕产品及其功能集中。
  • 文本处理：基于上下文目标和内容来源，下一步是执行文本处理，这涉及消除噪音和不需要的单词，并组织语和情感内容。
  • 解析内容：在此阶段，将根据逻辑和有意义的内涵对内容进行解析和分组。 根据极性和语义对内容进行细分。
  • 文本细化：在此阶段需要识别停用词和同义词。
  • 分析和评分：在此阶段，将根据训练数据和文本的语义对经过解析和精炼的内容进行评分。 评分用于训练模型以对新内容进行实际情感分析。

AutoML 自然语言情感分析创建了一个抽象层，使应用开发过程摆脱了情感分析的核心复杂性。 一旦以适当的评分精心准备了训练数据，该平台就会通过简单的 Web 界面和 API 来进行模型的训练，评估和部署。 在本节中，我们将了解使用 AutoML 在 GCP 上执行情感分析的过程。

该过程中最重要且最耗时的步骤是使用 GCP AutoML 创建用于自然语言情感分析的训练数据。 类似于任何其他有监督的学习模型训练过程，我们需要提供示例数据，该数据以整数比例标记文本内容。 通常，情感分数从 0 开始，可以根据需要进行细化。 整数标签越高，情感越积极。 可以基于预期的粒度定义最大情感分数。 作为一般准则，情感分数必须从 0 开始，并且在训练数据中不得有任何差距，以进行准确的模型训练。 建议在训练数据中使用偶数个样本，每个单独的分数。 这将避免模型欠拟合。

AutoML 接受 CSV 格式的训练数据，每行三个字段。 第一个字段将行表示为训练，验证或测试样本。 该字段在数据集中是可选的。 如果数据文件中未提供，AutoML 会自动创建一个拆分，并将大约 80% 的样本分配给训练，每个样本分别分配 10% 进行验证和测试。

第二个字段是模型需要分析的实际内容的占位符。 第三个字段表示代表情感的实际分数，该分数以 0（最负数）开头，最大值为 10（最正数）：

  1. 让我们用标有 Twitter 数据的示例数据集进行 AutoML 情感分析实验。 从导航菜单>人工智能>自然语言启动 AutoML 情感分析：

  1. 启动应用后，单击顶部菜单栏上的新数据集按钮

  2. 提供数据集名称，然后选择情感分析选项，如以下屏幕快照所示：

存在用于上传文本内容的四个选项：

  • 从您的计算机上载 CSV 文件：CSV 文件可以是带有实际数据的文本文件，也可以是 GCS 路径列表。
  • 从您的计算机上载文本项。
  • 在 Cloud Storage 上选择一个 CSV 文件。
  • 稍后导入文本项：可以通过创建文本项集并将其直接标记在工作空间中来创建数据集。

加载数据集后，AutoML 将在控制台上提供有关标记数据的统计信息：

  1. 在此阶段，模型已准备好进行训练。 单击TRAIN选项卡，然后单击开始训练按钮。 AutoML 将根据用户定义的分割或默认分割百分比来分割训练数据。 训练完模型后，将基于评估样本对其进行评估，并在EVALUATE选项卡上提供详细的模型表现分析。 该模型自动部署在平台上，可用于通过 Web 界面或 API 对新数据集执行情感分析。 这是使用部署的模型执行情感分析的 Python 代码片段：
    project_id = 'ai-gcp-ch4'
    compute_region = 'us-central1'
    model_id = '[MODEL_ID]'
    file_path = '/local/path/to/file'

    from google.cloud import automl_v1beta1 as automl

    automl_client = automl.AutoMlClient()

    prediction_client = automl.PredictionServiceClient()

    model_full_id = automl_client.model_path(
        project_id, compute_region, model_id
    )

    with open(file_path, "rb") as content_file:
        snippet = content_file.read()

    payload = {"text_snippet": {"content": snippet, "mime_type": "text/plain"}}

    params = {}
    response = prediction_client.predict(model_full_id, payload, params)
    print("Prediction results:")
    for result in response.payload:
        print("Predicted sentiment label: {}".format(result.text_sentiment.sentiment))
    for key, data in response.metadata.items():
        if key == 'sentiment_score':
            print("Normalized sentiment score: {}".format(data))

该代码可用于通过应用边界调用 API，并且需要认证密钥才能访问服务。

总结

在本章中，我们了解了 GCP 如何通过 Web 界面和 API 轻松构建，部署和使用机器学习模型。 我们已经根据一些最常见的用例展示了该平台的易用性和可伸缩性。 可以以安全的方式公开 API 层，并且可以基于新的和标记的数据集不断升级模型。

在下一章中，我们将了解如何构建基于云的机器学习引擎，并逐步介绍在生产环境中将机器学习即服务应用于服务的分步过程。

五、构建大数据云机器学习引擎

机器学习（ML）通过实现人工智能（AI）彻底改变了技术领域。 在客户支持，欺诈检测和商业智能领域，ML 一直成为企业的最爱。 ML 的重要性也影响着云计算领域。 因此，包括谷歌在内的每个云提供商都在革新其平台上的 AI 服务方面发挥着重要作用。 从新服务的开发到大型重组（在战略上将 AI 定位于其组织结构及其发展中）的重大重组中，他们在过去几年进行了大量投资。

与其他基于云的本机服务相比，云上的 ML 和 AI 平台具有各种交付模型，例如语音重组，视频分析，其他形式的认知计算，ML 自动化，ML 模型管理，ML 模型服务和 GPU- 基于计算。

在本章中，我们将研究 ML 的各种元素，包括 Google Cloud ML 以及如何使用 Google Cloud 的机器学习引擎。 Cloud Machine Learning Engine 也称为 Cloud AI Platform。 因此，让我们从了解云中的 ML 开始。

本章将涵盖以下主题：

  • 了解机器学习
  • 了解如何使用云机器学习引擎
  • Keras 框架概述
  • 使用 Keras 框架训练模型
  • 使用 Google AI 平台训练模型
  • 使用 Cloud Machine Learning Engine 的异步批量预测
  • 使用 Cloud Machine Learning Engine 进行实时预测

了解机器学习

几年来，人们一直在谈论 ML，好像它有望带来可影响人类生存各个方面的巨大优势。 还已努力将 ML 开发到不需要人类参与的程度。 在 AI 阶段可以看到 ML 的光明前景，该阶段利用 ML 模型并使他们从观察中学习。 需要大量处理能力和存储空间才能正确评估所有适当信息，以在 AI 系统中获得准确的 ML 结果。 希望将 ML 技术用于预测分析的公司必须在软件和硬件方面节省大量资金。 由于云已经改变了一切，因此情况不再如此。 在当今的大数据时代，云消除了对完全拥有物理硬件和软件的需求。 许多公司可以轻松地对数据进行智能分析，因为这些复杂的系统可以在云中租用。 只要他们可以访问 ML 的云，任何人都可以最大程度地使用该技术。

要构建 ML 解决方案，您不需要云提供商。 有现成的开源学习框架，例如 TensorFlow，MXNet 和 CNTK，这些框架允许企业在其硬件上进行操作并帮助他们构建 ML 模型。 但是，内部开发的高级 ML 模型会遇到准确率问题。 这是因为对实际大数据模型的训练通常涉及具有巨大计算和存储容量的大型集群。 在将 ML 技能引入业务应用中的许多方面，进入的障碍很大。 构造，训练和实现 ML 模型以及计算和硬件规范所需的专业知识，将导致更大的人工，生产和基础架构支出。 这些问题可以通过云计算解决，因为主要的公共云平台旨在使企业能够利用 ML 技能来解决业务问题，而不会带来任何技术负担。 总而言之，以下是在云上使用 ML 的一些优点：

  • 由于对必需硬件的短期要求，云的按使用付费模型对于 AI 或 ML 的繁重工作负载非常有用。

  • 云使公司可以轻松地在计算实例或存储空间方面试验 ML 的容量，并随着性能和需求目标的增加而扩展。

  • 可以在云中找到专用设备（GPU / TPU）的便捷可用性，可以帮助加快 AI 的增长。

  • 云提供了智能服务，无需用户具备 AI 或数据科学的先进能力。

  • 要开发 AI 框架，您必须从硬件，软件以及所有其他类型的必需框架开始使用云供应商。

  • 还允许您自己在云中部署某些成本控制策略。 例如，仅使用硬件并使用开源软件开发自定义解决方案，就可以为组织节省资金。

在下一节中，我们将专门研究 Google Cloud Platform 的 AI 平台产品以及如何使用它。 我们还将简要介绍 Google Cloud 提供的某些 ML 服务。

了解如何使用云机器学习引擎

Cloud Machine Learning Engine 是一项由 Google Cloud 管理的服务，可让开发人员和信息研究人员为 ML 构建，操作和产生更好的模型。 Cloud ML Engine（或 AI 平台）提供可以单独使用或一起使用的训练和预测服务。 训练和预测服务现在称为 ML Engine 中的 AI 平台训练和 AI 平台预测。 下图表示 Google Cloud AI 平台：

三个步骤使用 Cloud AI Platform。 如上图所示，您可以使用 Google AI Platform Notebooks，Google Cloud Machine Learning 模型训练以及 Google Cloud AI Platform Prediction 服务来构建项目。 在本章中，我们将介绍如何利用 Google AI Platform Notebooks。 我们在“第 8 章”，“使用 Cloud ML Engine 实现 TensorFlow 模型”和“第 9 章”，“构建预测应用”中介绍了 Google Cloud Machine Learning 模型的训练和预测服务。

Google Cloud AI Platform 笔记本

AI 平台笔记本是一项托管服务，可提供嵌入式 JupyterLab 环境，设计人员和信息研究人员只需单击一下最新信息研究和 ML 框架，即可构建 JupyterLab 案例。 BigQuery，Cloud Dataproc 和 Cloud Dataflow 集成在笔记本中。 这使得处理和预处理信息易于实现。 最终，这会导致建模，训练和实现方面的信息获取更为简单。 一键部署新的 JupyterLab 案例，即可立即分析您的信息。 每个示例都预先配置了最常见的数据科学和 ML 库的优化变体。 JupyterLab 接口利用笔记本电脑，并预先安装了优化的库变体，例如 TensorFlow，PyTorch，sci-kit-learn，pandas， SciPy 和 Matplotlib。 通过添加 CPU， RAM 和 GPU，您可以从小处着手，然后进行扩展。 如果您的信息对于一台计算机而言太大，则可以无缝迁移到 BigQuery，Cloud Dataproc，Cloud Dataflow 和 AI Platform 预测训练等服务。

Google AI Platform 深度学习映像

Google AI 平台笔记本为您节省了创建专门用于运行深度学习算法的计算实例的麻烦。 Google Cloud AI Platform 提供了深度学习虚拟机，这些虚拟机提供经过验证，优化和测试的操作系统映像，从而省去了为深度学习算法构建和配置计算实例的麻烦。 AI 深度学习 VM 映像平台是一系列 VM 映像，这些映像已通过基于 Debian9 的 Compute Engine 针对数据科学和 ML 进行了优化。 所有映像都预装了主要的 ML 框架和仪器，并且可以在 GPU 盒的盒子外面使用，以加快信息处理的速度。 Google Cloud AI Platform 的深度学习 VM 映像是预打包的虚拟机图片的集合，这些图片提供了深刻的，随时可运行的 ML 平台结构。

深度学习 VM 图片通过预配置依赖项，重要仪器的预安装和性能优化来帮助您为深度学习模型营造氛围。 关于 Google 平台深度学习映像，您需要注意三个重要概念。 让我们来看看。

第一个概念称为映像系列。 映像族是为特定目的或特定架构预先配置的一系列映像。 Google 云端提供了各种深度学习 VM 映像族。 每个映像系列都特定于某个 ML 框架。 Google 云提供的一些映像系列示例如下：

  • TensorFlow 系列，带有或不带有 GPU。
  • PyTorch 系列，带有或不带有 GPU。
  • Chainer 实验系列，带有或不带有 GPU。
  • 一个基本或通用映像系列，您可以在其中添加或不添加 GPU 来添加首选框架。

第二个概念称为映像。 映像是虚拟机的单个蓝图。 深度学习 VM 图片是由公共计算引擎预先配置的虚拟机图片。 映像类型有两种，如下所示：

  • 自定义映像：只有您的项目可以查看自定义映像。 这些映像是根据您正在处理的项目的需要专门定制的。 可以创建启动驱动器中的自定义图片以及其他图片。 然后，您可以使用此个性化图片生成示例。
  • 公共映像：Google，开放源代码社区和第三方供应商提供并维护公共映像。 默认情况下，所有项目都可以访问和使用这些映像来创建实例。

您可以免费使用大多数公共映像，但也可以在项目中添加一些高级映像。 您无需为 Compute Engine 的自定义图片付费，但在维护项目中的自定义图片时会产生存储费。

第三个概念称为实例。 实例是承载 Google 基础架构的虚拟机。 预先配置的深度学习 VM 映像之一基于深度学习 VM 实例。 使用 Google Cloud Platform 控制台或命令行工具，可以生成带有映像的实例。

深度学习映像始终是使用 Google AI 平台笔记本的第一步。 如果不选择这些深度学习映像，您将无法启动这些笔记本。 在下一节中，我们将研究如何启动和运行这些笔记本。

创建 Google Platform AI 笔记本

让我们首先创建一个 Google Platform AI Notebook，如下所示：

  1. 创建一个新实例。 以下屏幕截图显示了如何从 Google 云控制台的用户界面执行此操作：

  1. 接下来，您必须选择将在 AI Notebook 的计算实例中使用的可用自定义图像或公共图像：

  1. 选择虚拟机映像后，将显示以下屏幕，其中包含一些重要的实例信息。 您应该仔细检查它。 如果您需要更改任何内容，可以单击CUSTOMIZE选项，如下所示：

  1. 自定义屏幕提供了用于更改 RAM，区域，区域等的选项，如以下屏幕截图所示：

  1. 您还可以在 GPU 和启动磁盘周围进行其他自定义，如以下屏幕截图所示：

  1. 创建笔记本后，它将显示在 Google Cloud AI Platform UI 的可用笔记本列表中，如以下屏幕截图所示：

  1. 运行以下命令以访问您创建的 VM 实例上的 JupyterLab 用户界面。 以下命令设置端口转发：
export INSTANCE_NAME="<my-instance>"
gcloud compute ssh $INSTANCE_NAME -- -L 8080:localhost:8080
  1. 以下屏幕截图显示了 UI 的外观。 您必须在网络浏览器中输入http://localhost:8080/lab?才能获得此信息：

您还可以使用以下 shell 脚本自动执行此操作：

#!/bin/bash
IMAGE=--image-family=tf-latest-cpu
INSTANCE_NAME=dlvm
GCP_LOGIN_NAME=<proxy@gmail.com> # CHANGE THIS
gcloud config set compute/zone us-central1-a # CHANGE THIS
echo "Launching $INSTANCE_NAME"
gcloud compute instances create ${INSTANCE_NAME} \
      --machine-type=n1-standard-2 \
      --scopes=https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/userinfo.email \
      ${IMAGE} \
      --image-project=deeplearning-platform-release \
      --boot-disk-device-name=${INSTANCE_NAME} \
      --metadata="proxy-user-mail=${GCP_LOGIN_NAME}"
echo "Looking for Jupyter URL on $INSTANCE_NAME"
while true; do
   proxy=$(gcloud compute instances describe ${INSTANCE_NAME} 2> /dev/null | grep dot-datalab-vm)
   if [ -z "$proxy" ]
   then
      echo -n "."
      sleep 1
   else
      echo "done!"
      echo "$proxy"
      break
   fi
done

这是此自动化脚本的伪代码：

  • 定义虚拟机映像类型
  • 提供 Google Cloud Platform 凭证
  • 设置将在笔记本后面进行计算的计算区域
  • 定义实例大小
  • 遍历计算实例，并在实例上查找 Jupyter 笔记本 URL

在下一部分中，我们将探索 AI 笔记本，并学习如何将其用于特定任务。

使用 Google Platform AI 笔记本

您可以使用 AI Notebooks JupyterLab 平台设置本地笔记本，也可以从 Git 存储库克隆。 在用户界面中，单击顶部菜单上的 Git 图标以克隆存储库，如以下屏幕截图所示：

如我们所见，Google Cloud Platform 允许我们选择各种版本的 Python，以及一种创建特定类型的支持文件的方式：

Jupyter 笔记本允许命令行界面从 Git 存储库中提取代码。 您可以使用左窗格中的文件浏览器查看此代码。 这是一个方便的功能，使多个开发人员可以轻松无缝地进行协作。

自动执行 AI 笔记本

一旦开发了代码并能够基于运行时配置参数使其工作，就可以使用称为 Papermill 的库来执行和评估这些笔记本。 让我们来看看 Papermill 可以为我们做些什么：

  • 该库允许您生成各种笔记本并同时运行它们。
  • Papermill 还可以帮助您收集和汇总笔记本集合中的指标。
  • 它还允许您从各个地方读取或写入信息。 这意味着您可以将输出笔记本存储在另一个存储系统上，该存储系统具有更高的耐用性并更易于访问可靠的管道。
  • 在撰写本文时，Papermill 最近添加了 Google Cloud Bucket 帮助。 我们将在本章中演示如何使用此新功能。

下图显示了 Papermill 如何与 Google Cloud AI Notebooks 一起使用：

Papermill 可让您改变笔记本材料工作方式的范式。 由于 Papermill 不会更改笔记本电脑室通常缺少的原始笔记本电脑，因此我们收到的功能特征已添加到我们的工作定义中。 我们的输入（它是一个 JSON 笔记本文档）和我们的输入参数被视为不变的执行文档，这些文档会生成不变的输出文档。

该输出文档提供了已执行的代码，输出和日志，以及可随时轻松进行重做的可重复模板。 Papermill 从多个位置读取或写入的能力是它的另一个特点。 为了提供可靠的管道，我们可以将输出笔记本存储在耐用性高且易于访问的地方。 前往 Google Cloud 存储桶以存储您的输出笔记本。 这使输出笔记本隔离了文档，从而为我们的用户提供了尽可能多的支持。 这使我们可以轻松分析诸如连接到服务或 Google Cloud 的存储前缀之类的操作。

用户可以使用这些连接并调试问题，验证结果并生成新模板，而不会影响初始工作流程。 此外，由于 Papermill 管理其运行时过程，因此您不需要笔记本或其他基础结构即可针对笔记本内核执行。 这消除了我们在托管的笔记本服务的简化上下文中执行的某些复杂性。 请查看下图，以更深入地了解 Papermill 库：

以下代码是创建深度学习 VM 的常规方法。 但是，请记住，必须选择包含要运行笔记本的关键依赖项的 VM。 如果您的笔记本需要 PyTorch，反之亦然，请不要尝试使用 TensorFlow 图片：

  # Compute Engine Instance parameters
export IMAGE_FAMILY="tf-latest-cu100" 
export ZONE="us-central1-b"
export INSTANCE_NAME="notebook-executor"
export INSTANCE_TYPE="n1-standard-8"
# Notebook parameters
export INPUT_NOTEBOOK_PATH="gs://my-bucket/input.ipynb"
export OUTPUT_NOTEBOOK_PATH="gs://my-bucket/output.ipynb"
export PARAMETERS_FILE="params.yaml" # Optional
export PARAMETERS="-p batch_size 128 -p epochs 40" # Optional
export STARTUP_SCRIPT="Papermill ${INPUT_NOTEBOOK_PATH} ${OUTPUT_NOTEBOOK_PATH} -y ${PARAMETERS_FILE} ${PARAMETERS}"

gcloud compute instances create $INSTANCE_NAME \
        --zone=$ZONE \
        --image-family=$IMAGE_FAMILY \
        --image-project=deeplearning-platform-release \
        --maintenance-policy=TERMINATE \
        --accelerator='type=nvidia-tesla-t4,count=2' \
        --machine-type=$INSTANCE_TYPE \
        --boot-disk-size=100GB \
        --scopes=https://www.googleapis.com/auth/cloud-platform \
        --metadata="install-nvidia-driver=True,startup-script=${STARTUP_SCRIPT}"

gcloud --quiet compute instances delete $INSTANCE_NAME --zone $ZONE

前面的代码中使用的参数如下：

  • INPUT_NOTEBOOK_PATH：位于 Cloud Storage 存储桶中的输入笔记本； 例如gs://my-bucket/input.ipynb。
  • OUTPUT_NOTEBOOK_PATH：位于 Cloud Storage 存储桶中的输出笔记本； 例如gs://my-bucket/input.ipynb。
  • PARAMETERS_FILE：用户可以提供一个 YAML 文件，应在其中读取笔记本参数值； 例如gs://my-bucket/params.yaml。
  • PARAMETERS：用户可以通过-p键值传递参数以执行笔记本； 例如-p batch_size 128 -p epochs 40。

以下是我们选择*cu-100图像系列的 GPU 实例示例。 根据特定要求和版本的可用性，可以使用其他配置。 另外，我们需要提供输入和输出笔记本的路径。 将所有这些参数传递给gcloud命令以创建计算实例：

    IMAGE_FAMILY="tf-latest-cu100" # Or use any required DLVM image.
    ZONE="us-central1-b"
    INSTANCE_NAME="notebook-executor"
    INSTANCE_TYPE="n1-standard-8"
    INPUT_NOTEBOOK_PATH=$1
    OUTPUT_NOTEBOOK_PATH=$2
    GPU_TYPE=$3
    GPU_COUNT=$4
    STARTUP_SCRIPT="Papermill ${INPUT_NOTEBOOK_PATH} ${OUTPUT_NOTEBOOK_PATH}"
    # Create DLVM
    gcloud compute instances create $INSTANCE_NAME \
        --zone=$ZONE \
        --image-family=$IMAGE_FAMILY \
        --image-project=deeplearning-platform-release \
        --maintenance-policy=TERMINATE \
        --accelerator="type=nvidia-tesla-${GPU_TYPE},count=${GPU_COUNT}" \
        --machine-type=$INSTANCE_TYPE \
        --boot-disk-size=100GB \
        --scopes=https://www.googleapis.com/auth/cloud-platform \ --metadata="install-nvidia-driver=True,startup-script=${STARTUP_SCRIPT}"
    gcloud --quiet compute instances delete $INSTANCE_NAME --zone $ZONE

以下是一个 CPU 实例示例。 这类似于使用 GPU 购买虚拟机。 我们需要选择适当的映像系列，即*-cpu，并提供类似的参数以使用gcloud命令启动实例：


    IMAGE_FAMILY="tf-latest-cpu" # Or use any required DLVM image.
    ZONE="us-central1-b"
    INSTANCE_NAME="notebook-executor"
    INSTANCE_TYPE="n1-standard-8"
    INPUT_NOTEBOOK_PATH=$1
    OUTPUT_NOTEBOOK_PATH=$2
    STARTUP_SCRIPT="Papermill ${INPUT_NOTEBOOK_PATH} ${OUTPUT_NOTEBOOK_PATH}"
    # Create DLVM
    gcloud compute instances create $INSTANCE_NAME \
        --zone=$ZONE \
        --image-family=$IMAGE_FAMILY \
        --image-project=deeplearning-platform-release \
        --machine-type=$INSTANCE_TYPE \
        --boot-disk-size=100GB \
        --scopes=https://www.googleapis.com/auth/cloud-platform \
        --metadata="startup-script=${STARTUP_SCRIPT}"
    gcloud --quiet compute instances delete $INSTANCE_NAME --zone $ZONE

启动脚本执行以下操作：

  1. 使用 TensorFlow 深度学习 VM 和两个 NVIDIA Tesla T4 GPU 创建一个 Compute Engine 实例。
  2. 安装 NVIDIA GPU 驱动。
  3. 使用 Papermill 工具执行笔记本。
  4. 将笔记本的结果（所有单元格都已预先计算）上载到 Cloud Storage 存储桶，在本例中为gs://my-bucket/。
  5. 每个单元执行后，Papermill 发出一个保存。 这可能会产生 429 个“太多请求”错误，这些错误由库本身处理。
  6. 终止 Compute Engine 实例。

如果要查看启动脚本的完整代码，请查看以下链接。

希望您现在对 Papermill 库有了很好的了解。 您需要完成以下步骤，以完成在生产环境中使用 AI 笔记本的过程。 我们在这里谨慎地介绍了这些步骤，但是也最好在合并列表中显示它们：

  1. 使用 Google AI 笔记本开发代码
  2. 安排和自动化深度学习 VM 映像配置
  3. 安排和自动化 Jupyter 笔记本

Keras 框架概述

Keras 是 Python 的深度学习框架，可以帮助我们识别和训练几乎任何类型的深度学习模型。 对于科学家而言，Keras 的创建是为了进行快速实验。 这是一个在 TensorFlow 或 Theano 上运行的开源 Python 库。 让我们看一下 Keras 及其功能：

  • 它是模块化，快速且易于使用的。
  • 它是由 Google 工程师 FrançoisChollet 设计的。
  • Keras 不处理低级计算。 相反，他们使用另一个名为后端的库来执行工作。 因此，Keras 是具有低级 API 的高级 API 包装器，可以在 TensorFlow，CNTK 或 Theano 之上运行。
  • Keras 的高级 API 处理我们如何创建模型，定义级别或设置各种输入输出模型。 它允许相同的代码在 CPU 或 GPU 上无缝运行。
  • Keras 具有一些主要的重要特征。 它具有易于使用的 API 来快速构建深度学习模型的原型。
  • 它支持卷积（PC 视觉）网络，循环（序列）网络及其任意组合。
  • 它包含各种任意的网络架构。 支持多输入或多输出，层共享，模型共享等。 这包括多个模型。
  • Keras 本质上非常适合构建深度学习模型，从生成的对手网络到图灵机。
  • Keras 是一个模型库，为深入的教育系统的发展提供了高级构建块。
  • 它不处理低级活动，例如张量的操纵和微分。 取而代之的是，它依赖于经过优化的专用张量库，该张量库可用作 Keras 的主干电机。

Keras 不用选择单个张量库，而是以模块化的方式管理此问题，并将 Keras 与该库联系在一起。 多个后端电机可以无缝插入 Keras。 TensorFlow 后端，Theano 后端和 Microsoft 认知工具包（CNTK）后端目前是当前的三种后端实现。 Keras 将来将能够与更多的深度学习引擎一起使用。

Keras 的构建是为了与 Python 配合使用，因此它易于使用，模块化且易于扩展。 该 API 是为人而不是机器而设计的，并且遵循减少认知负载的最​​佳实践。 所有这些独立的模块都可以组合起来，以生成新的模型，神经层，成本函数，优化器，初始化方案，激活函数和正则化系统。 有了新的类和函数，可以轻松添加新模型。 描述的是 Python 代码中的模型，而不是用于模型设置的不同文件。

使用 Keras 的主要原因来自其指南，主要是它易于使用。 Keras 提供的优势包括广泛接受，支持广泛的制造部署，至少包含五种支持电机（TensorFlow，CNTK，Theano，MXNet 和 PlaidML），以及对各种 GPU 和分布式训练的强大支持。 易于教学和易于模型开发。 此外，Google，Microsoft，Amazon，Apple，Nvidia，Uber 等都支持 Keras。

Keras 本身并不像张量积和卷积那样在较低级别上运行。 相反，它取决于后端电动机。 虽然 Keras 支持多个后端马达，但它使用 TensorFlow 作为主要（默认）后端，并使用 Google 作为主要风扇。 如前所述，Keras API 在 TensorFlow 中打包为tf.keras，现在是 TensorFlow 2.0 中的主要 TensorFlow API。 这是一个如何使用 Keras 框架使用 MNIST 数据集进行图像分类的基本示例：

import keras
keras.__version__

from keras.datasets import mnist

(train_images, train_labels), (test_images, test_labels) = mnist.load_data()

train_images.shape

len(train_labels)

train_labels

test_images.shape

len(test_labels)

test_labels

from keras import models
from keras import layers

network = models.Sequential()
network.add(layers.Dense(512, activation='relu', input_shape=(28 * 28,)))
network.add(layers.Dense(10, activation='softmax'))

network.compile(optimizer='rmsprop',
                loss='categorical_crossentropy',
                metrics=['accuracy'])

train_images = train_images.reshape((60000, 28 * 28))
train_images = train_images.astype('float32') / 255

test_images = test_images.reshape((10000, 28 * 28))
test_images = test_images.astype('float32') / 255

from keras.utils import to_categorical

train_labels = to_categorical(train_labels)
test_labels = to_categorical(test_labels)

network.fit(train_images, train_labels, epochs=5, batch_size=128)

test_loss, test_acc = network.evaluate(test_images, test_labels)

print('test_acc:', test_acc)

在前面的代码中，我们通过将图像重塑为像素矩阵来加载图像数据集并使用 Keras 库训练图像。 通过神经网络以五次迭代（周期）对神经网络进行 128 批量的训练。 训练和测试标签在输入到神经网络之前会被转换为分类变量。 network.fit方法为训练数据集训练神经网络，而network.evaluate方法用于评估模型的精度参数。 最后，打印精度参数以进行分析。 如果发现模型的准确率高于阈值，则将其用于对新数据集运行预测。

这是前面代码的输出：

如我们所见，通过神经网络进行了五次迭代，每次迭代，我们在评估数据集上的准确率更高。

使用 Keras 框架训练模型

在本节中，我们将介绍另一个使用 Keras 框架训练神经网络的代码示例。 要运行此代码，我们需要访问以下库：

  • os：这提供了各种依赖于操作系统的函数。
  • glob：该模块非常适合使用 UNIX shell 参数。
  • numpy：该库用于基本的数学函数。

以下链接提供了使用 Keras 训练神经网络的必要代码。

前面链接中引用的代码从磁盘加载训练数据，并将其分为训练和评估集。 该模型的结构从 Keras 顺序模型开始，并在我们向其提供训练数据之前将各种层添加到网络。 最后，model.fit方法用于通过五个迭代（周期）以 256 个批量训练数据。

以下屏幕快照显示了不同代码段的输出结果：

如我们所见，该模型基于用于训练的训练数据图像将图像分类为bicycle。

现在，让我们看一下神经网络的结构，以及通过神经网络进行的每次迭代输出如何变化。 输出形状定义了神经网络结构，我们可以根据评估结果通过将参数值传递到 Keras 库来对其进行配置：

现在，让我们看一下使用带有 TensorFlow 背景的 Keras 库训练模型的输出。 我们已经配置了训练，以使其经过 5 次迭代（历时）进行处理。 如我们所见，模型的准确率随着每次迭代而增加。 一旦我们对模型进行了足够的训练，使其准确率超过设置的阈值，就可以使用该模型对新记录进行分类：

现在，我们可以使用此模型来预测新数据点。 该预测将根据提供的训练数据输出类：

至此，我们已经使用 Keras 完成了模型训练，评估和预测步骤。 我们还可以可视化模型在各个周期的表现以及使用matplot库如何通过模型优化损失函数：

前面的屏幕快照显示了如何使用 Keras 在模型的训练迭代中将训练和验证损失最小化。

使用 Google AI 平台训练模型

在上一节中，您学习了如何使用 Keras 框架训练模型。 在本节中，我们将在 Google Cloud AI Platform 上训练相同的模型。 核心代码库将保持不变，但是训练模型的方式将有所不同。 让我们开始吧：

  1. 您要做的第一件事是设置代码的目录结构。 确保根据 Google Cloud AI 平台的要求命名文件。 看起来像这样：

  1. 需要将其他代码添加到前面的代码中，以确保将模型保存到 Google Cloud 存储桶中。 该代码如下：
PROJECT_ID="<project_id>" #change this
BUCKET_ID="ml_assets"
JOB_NAME = 'my_first_keras_job'
JOB_DIR = 'gs://' + BUCKET_ID + '/keras-job-dir'
REGION="<REGION>" #change this
! gsutil ls -al gs://$BUCKET_ID
print(JOB_DIR)
export_path = tf.contrib.saved_model.save_keras_model(model, JOB_DIR + '/keras_export')
print("Model exported to: ", export_path)
#Verify model is created
! gsutil ls -al $JOB_DIR/keras_export

以下屏幕截图显示了上述代码的输出：

  1. 让我们来看看 Google Cloud 控制台窗口中的存储桶：

  1. 最后，您必须以以下gcloud AI 平台命令的形式提交训练工作：
#!/bin/sh
PROJECT_ID="<project-id>" #change this
BUCKET_ID="ml_assets"
JOB_NAME='my_keras_job'
JOB_DIR='gs://$BUCKET_ID/keras-job-dir'
REGION="us-central1" #change this
gcloud config set project $PROJECT_ID
gcloud ai-platform jobs submit training $JOB_NAME \
  --package-path trainer/ \
  --module-name trainer.task \
  --region $REGION \
  --python-version 3.5 \
  --runtime-version 1.13 \
  --job-dir $JOB_DIR \
  --stream-logs

上一条命令的输出如下：

  1. 此外，我们可以使用 Google Cloud 控制台可视化正在运行的作业，如下所示：

Google Cloud Platform 会存储过程日志，以便于监视和故障排除。 我们可以通过控制台窗口中的 Stackdrive Logging 访问这些日志，如下所示：

现在我们的训练工作已经成功，我们可以将保存的 ML 模型用于在线和离线预测。 接下来我们将看这个。

使用 Cloud Machine Learning Engine 的异步批量预测

为了使用上一节中训练和导出的模型来提供在线预测，我们必须在 AI 平台中创建模型资源，并在其中创建版本资源。 版本资源是合格模型有效地用于提供预测的资源。 使用此框架，您可以多次调整，重新训练和管理 AI 平台中的所有版本。

模型或版本是已存储在 AI 平台的模型服务中的高级学习解决方案的示例。 您可以使用已训练的标准模型（作为保存的模型）进行发布。 您也可以在创建版本时提供自定义代码（测试版）来处理预测。 让我们来看看：

  1. 以下命令在 Google Cloud AI Platform 中创建模型版本：
MODEL_NAME = "keras_model"

! gcloud ai-platform models create $MODEL_NAME \
  --regions $REGION

上一条命令的输出如下：

  1. 使用以下命令创建下一个模型版本：
MODEL_VERSION = "v1"

# Get a list of directories in the `keras_export` parent directory
KERAS_EXPORT_DIRS = ! gsutil ls $JOB_DIR/keras_export/

# Pick the directory with the latest timestamp, in case you've trained
# multiple times
SAVED_MODEL_PATH = KERAS_EXPORT_DIRS[-1]

# Create model version based on that SavedModel directory
! gcloud ai-platform versions create $MODEL_VERSION \
  --model $MODEL_NAME \
  --runtime-version 1.13 \
  --python-version 3.5 \
  --framework tensorflow \
  --origin $SAVED_MODEL_PATH

以下是 Google Cloud UI 的输出：

以下屏幕截图显示了 Keras 模型的版本详细信息：

  1. 现在，您已经创建了预测模型版本，您需要创建用于批量预测的 Python 脚本。 首先以以下代码中所示的格式创建预测输入 JSON：
{
  "dataFormat": enum (DataFormat),
  "outputDataFormat": enum (DataFormat),
  "inputPaths": [
    string
  ],
  "maxWorkerCount": string,
  "region": string,
  "runtimeVersion": string,
  "batchSize": string,
  "signatureName": string,

  // Union field model_version can be only one of the following:
  "modelName": string,
  "versionName": string,
  "uri": string
  // End of list of possible types for union field model_version.
  "outputPath": string
}

让我们回顾一下前面代码中使用的每个参数：

  • 数据格式：用于输入文件进行预测的格式类型。 对于特定任务，所有输入文件必须具有相同的信息格式。 它可以是 JSON，TF_Record或TF_Record_GZIP格式。

  • 输出数据格式：用于预测输出文件的格式类型。

  • 输入路径：需要存储在 Google Cloud 存储中的输入数据文件的 URI。

  • 输出路径：云中要通过提供预测服务保存输出的位置。 您的项目需要被允许写到这个地方。

  • 模型名称和版本名称：您希望从中接收投影的模型名称和版本。 如果未指定版本，则使用模型的默认版本。 如果愿意，可以使用未部署的 SavedModel Cloud 存储路径，称为 Model URI。

  • 模型 URI：您要从中接收投影的模型名称和版本。 如果未指定版本，则使用模型的默认版本。 如果愿意，可以使用未部署的 SavedModel Cloud 存储路径，称为 Model URI。

  • 区域：Google Compute Engine 将在其中运行您的工作的区域。 为了执行预测任务并保存输入和输出信息以获取非常广泛的信息，所有内容都需要在同一区域中设置。

  • 最大工作器数（可选）：处理集群中用于此任务的最大预测节点数。 您可以通过这种方式为自动批量预测的缩放功能设置上限。 如果不设置值，则默认为 10。

  • 运行时版本（可选）：使用的 AI 平台的版本。 包含此选项以允许您指定要与 AI Platform 模型一起使用的运行时版本。 对于已部署的模型版本，应始终忽略此值，以告知服务使用在部署模型版本时指定的相同版本。

  • 签名名称（可选）：如果您保存的模型具有各种签名，则可以选择由 TensorFlow SavedModel 标识的备用输入/输出映射，以指定自定义 TensorFlow 签名名称。

  1. 以下 Python 代码代表了如何构建 JSON 主体：
import time
import re

def make_batch_job_body(project_name, input_paths, output_path,
 model_name, region, data_format='JSON',
 version_name=None, max_worker_count=None,
 runtime_version=None):

 project_id = 'projects/{}'.format(project_name)
 model_id = '{}/models/{}'.format(project_id, model_name)
 if version_name:
 version_id = '{}/versions/{}'.format(model_id, version_name)
  1. 以model_name_batch_predict_YYYYMMDD_HHMMSS格式制作jobName：
timestamp = time.strftime('%Y%m%d_%H%M%S', time.gmtime())

    # Make sure the project name is formatted correctly to work as the basis
    # of a valid job name.
    clean_project_name = re.sub(r'\W+', '_', project_name)

    job_id = '{}_{}_{}'.format(clean_project_name, model_name,
                           timestamp)
  1. 开始使用所需信息构建请求字典：
body = {'jobId': job_id,
            'predictionInput': {
                'dataFormat': data_format,
                'inputPaths': input_paths,
                'outputPath': output_path,
                'region': region}}
  1. 使用版本（如果存在）或模型（默认版本）（如果不存在）：
if version_name:
 body['predictionInput']['versionName'] = version_id
 else:
 body['predictionInput']['modelName'] = model_id
  1. 如果指定，则仅包括最大数量的工作程序或运行时版本。 否则，让服务使用其默认值：
 if max_worker_count:
        body['predictionInput']['maxWorkerCount'] = max_worker_count

    if runtime_version:
        body['predictionInput']['runtimeVersion'] = runtime_version

    return body
  1. 同样，用于调用 Prediction API 的 Python 代码如下：
    import googleapiclient.discovery as discovery

    project_id = 'projects/{}'.format(project_name)

    ml = discovery.build('ml', 'v1')
    request = ml.projects().jobs().create(parent=project_id,
                                          body=batch_predict_body)

    try:
        response = request.execute()

        print('Job requested.')

        # The state returned will almost always be QUEUED.
        print('state : {}'.format(response['state']))

    except errors.HttpError as err:
        # Something went wrong, print out some information.
        print('There was an error getting the prediction results.' +
              'Check the details:')
        print(err._get_reason())

前面的代码通过request.execute()方法调用发送预测请求，该请求以异步方式执行批量预测作业。

在下一节中，我们将研究使用 Cloud Machine Learning Engine 的实时预测，该引擎将范例转换为 Google Cloud Platform 上的完全无服务器的 ML。

使用 Cloud Machine Learning Engine 的实时预测

优化了在线预测，以最小化服务预测的延迟。 每个请求我们可以处理一个或多个实例。 在线预测在响应消息中作为输入数据返回，该输入数据直接作为 JSON 字符串传递。 它将尽快返回。 在响应应用输入进行请求或在其他需要及时推断的情况下，通常应使用在线预测。 批量预测有其自身的缺点。 如果使用单个模型和少量输入实例，则可以看到使用在线预测与批量预测完成相同的预测请求所需的时间有相当大的差异。 几乎立即完成由互联网请求返回的预测可能要花费大量时间。 这是两种预测技术所使用的各种设施的副作用。 在创建应用时，AI 平台会分配并初始化批量预测资源。 通常，已准备好在线预测，以便可以在需要时进行处理。 您可以通过这里了解有关在线预测的更多信息。

前面的链接告诉我们，使用 Google Cloud Platform 上的简单且一致的 API 可以轻松地与 ML 引擎进行交互。 该 API 可用于实时预测，因为它具有很高的吞吐量和使用底层弹性计算能力的效率，而所有这些功能均由 Google Cloud Platform 启用。

总结

在本章中，我们通过一个实际的示例用例演示了 Keras 与 Google Cloud Platform 的结合使用。 我们了解了如何使用云机器学习引擎。 Keras 是一个用 Python 编写的开源神经网络库。 它可以在 Microsoft Cognitive Toolkit，TensorFlow 或 Theano 上运行。 我们看到 Keras 支持卷积网络，循环网络以及两者的组合。 展望未来，我们使用 Cloud Machine Learning Engine 执行了异步批量预测和实时预测。

在下一章中，我们将学习 DialogFlow，它用于构建界面（例如对话式 IVR 和聊天机器人），以实现企业和用户之间的交互。

六、使用 DialogFlow 的智能对话应用

人工智能（AI）不断改变着我们搜索和处理事物的方式，而聊天机器人是人们渴望摆脱自己不想做的事情的真实例证。 通过他们自己。 人工智能驱动的聊天机器人可以在不涉及人类的情况下完成出色的工作。 聊天机器人是一个智能聊天程序。 它应该能够令人信服地模拟一个人。 与 AI 技术结合使用时，它称为智能聊天机器人。

聊天机器人的最常见实例是某些公司使用的客户支持系统。 它已经发展为可以进行 70-80% 的对话，而公司中没有实际的人与客户进行对话。 银行和金融市场已经在大量使用聊天机器人来处理客户请求并迅速协助他们进行银行交易。 出于完全相同的原因，云提供商正在提供聊天机器人平台，以缩短产品上市时间。 在本章中，我们将学习如何使用名为 DialogFlow 的 Google Cloud Platform（GCP）服务构建会话应用。 DialogFlow 提供了一种轻松的方法来为企业构建会话应用，并可以大大节省运营成本。 在本章中，我们将学习 DialogFlow 的核心概念，并通过一个示例说明如何构建对话应用。

以下是本章将涉及的主题：

  • DialogFlow 简介
  • 构建一个 DialogFlow 智能体
  • 使用 DialogFlow 执行音频情感分析

DialogFlow 简介

在开始 DialogFlow 之前，我们需要从高层次了解如何使用不同的技术来增强智能聊天机器人系统的功能。 大多数聊天机器人是电子邮件或对话的一种界面，其中机器人会响应您的文本，而不是人。 这些聊天机器人在包含应用的上下文中运行。 但是，捕获集中在您与之通信的用户界面层周围。 人类与机器人的对话是由机器学习（ML）算法驱动的，该算法将您的消息分解为具有自然语言理解（NLU）能力的自然语言方法并以与任何人都可以期望的方式相当的方式回答查询。

了解 DialogFlow 的构建块

让我们通过查看 DialogFlow 的高级架构来了解对话应用的各种构建块。

下图从高层表示了任何聊天机器人应用的不同组件：

图 6.1：聊天机器人应用的组件

系统的独立构建块需要在一段时间内进行微调和即兴创作，并且需要不断的反馈和训练循环。 在某些情况下，基于对一组已知输入的一组预定义响应来构建会话应用。 显然，这些系统无法提供类似于人的体验，并且缺乏自然的对话风格。 DialogFlow 抽象了许多此类过程，并允许应用开发人员通过简单易用的界面专注于对话框的上下文和语义。

该引擎还利用了不断增强的 ML 模型来支持其他意图，实体和上下文。 在本节中，我们将学习 DialogFlow 的各种构造块和接口，如以下列表所示：

  • DialogFlow 智能体：简而言之，此组件类似于需要训练才能处理用户呼叫的人工智能体。 例如，一家银行的呼叫中心员工需要了解他们在接听客户电话时将会遇到的一些基本工作流程，术语和常见情况。 但是，训练不能满足所有可能的问题和会话分支。 智能体需要了解上下文中的意图，并在信息不足以满足客户查询的情况下以最佳选择或首要问题做出回应。 与人工智能体类似，DialogFlow 智能体是一个复制人工智能体并以一定程度的模糊性理解自然语言的模块。 作为 DialogFlow 应用开发人员，我们需要设计和开发 DialogFlow 智能体，以处理预期应用上下文中的对话。

  • DialogFlow 意图：一旦智能体将文本转换成段，便会标记和标记某些关键字以了解智能体上下文中的意图。 与人类对话一样，DialogFlow 智能体和另一端的人类用户轮流进行对话，以使其成为有意义的对话。 从该人那里收集到的信息又称为最终用户表示。 DialogFlow 智能体需要经过训练，以将最终用户表达与预配置的意图匹配-此过程称为意图分类。 例如，如果我们正在设计一个 DialogFlow 智能体来处理餐厅的预订，则该智能体需要响应与菜单，时间安排和预订有关的用户问题和查询。 这称为对话的上下文，并且智能体需要在餐厅预订的上下文中对用户的意图进行分类。 基于意图分类，智能体要么通过从用户那里寻求其他信息来进行响应，要么查询应用的后端以找到问题的答案。 该意图包含以下组件：

    • 训练短语：这些是智能体在应用上下文内的对话中寻找的预定义关键字集。 DialogFlow 使用基于主要短语集的本体映射，应用开发人员使用这些短语来扩展智能体的词汇表。 这意味着应用开发人员无需针对所有可能的意图关键字和短语训练智能体。 DialogFlow 引擎在内部增强了智能体上下文中可能的一组意图表达。
    • 动作：应用开发人员可以为意图定义动作。 这些动作需要在系统中预定义和配置。 这些动作可能是对基础数据集进行修改的特定活动，也可能是智能体在下一个会话输出中提出的主要问题。 例如，在酒店预订系统的情况下，如果最终用户的意图被理解为针对特定人数的特定时间的预订，则智能体可以继续进行并触发预订餐桌的动作。 如果智能体需要其他信息以了解预订时间，则可以提出补充问题。
    • 参数：在应用的上下文中验证了意图，并且 DialogFlow 提取最终用户表达式作为参数。 每个参数都是实体的预定义类型。 DialogFlow 提供的系统实体与会话数据类型匹配。 系统实体匹配日期，参数值，范围，电子邮件 ID 等。 此时的参数定义了如何从最终用户中提取数据。 参数是可用于构建逻辑表达式的结构化数据构造。
    • 响应：应用开发人员可以根据上下文，意图和派生给最终用户的动作定义响应。 根据上下文，座席可以结束对话，采取预期的操作或提出问题以收集其他信息。

  • DialogFlow 实体：当智能体从最终用户对话中提取意图时，它将映射到一个实体。 实体将语义含义与关键字相关联。 DialogFlow 提供了一组系统实体，它们是跨各种上下文（例如，数量和单位，日期和时间等）的通用对话实体。 DialogFlow 还提供了用于定义开发人员实体的接口。 这些是特定于上下文的自定义实体，应用开发人员可以创建这些实体，以使智能体理解应用上下文中的对话。 例如，可以用映射到餐厅所服务的特定菜单项的开发者实体来训练餐厅预订智能体。

  • DialogFlow 上下文：类似于人机交互，DialogFlow 对话发生在上下文中。 该应用适合特定的业务场景，因此需要在应用的上下文中理解关键字。 重要的是，要使意图与应用的上下文正确匹配，以使对话有意义。 通过使用上下文，可以在特定方向上构建对话。 有两种类型的上下文需要解决：

    • 输入上下文：当最终用户表达式在上下文中是紧密匹配时，这允许 DialogFlow 匹配意图。
    • 输出上下文：如果用户表达式在当前上下文中不紧密匹配，则 DialogFlow 可以激活新的上下文。 例如，如果最终用户说“菜单上是什么？”，将触发输出上下文，并询问特定问题以进一步阐明，例如“素食还是非素食菜单？”。根据用户的选择，将激活特定的上下文，并且 DialogFlow 会详细说明这些选项。 在对话中的任何给定点，可以激活多个输出上下文。 这样可以对输出进行更好的控制，从而使对话朝着预期的方向发展。 可以基于用户响应来确定此时的上下文。 在这种情况下，如果用户选择素食，则可以将素食菜单中的项目提供给用户。 输出上下文具有生命周期，并且在匹配意图后 5 个请求或 20 分钟后过期。

  • 跟进意图：我们可以使用跟进意图来设置各种意图的上下文。 父意愿与跟进意愿之间存在亲子关系。 在对话的上下文中可以创建嵌套的后续意层次结构。 DialogFlow 提供了一组预定义的后续意图，这些意图表示对话期间使用的大多数表达式。 该平台还提供了一种定义自定义跟进意图的方式，以实现更精细的控制和对话流程。 这是 DialogFlow 提供的所有后续意图的标题列表：

    • 后备：当基于用户的输入不清楚意图和上下文时，这是一个表达式。
    • 是/否：捕获对后续问题的肯定/否定反应。
    • 之后：这链接到用户打算在不久的将来某个时间发生的定时事件。
    • 取消：这通常适用于特定动作或事件的取消。 通常，会话在这一点上趋向于关闭意图或遵循替代路径。
    • 更多：当用户需要更多信息或 DialogFlow 智能体需要来自调用者的其他信息以实现意图时，使用此选项。
    • 下一个/上一个：在处理一组可能的选项时使用。 例如，如果对话是关于菜单项的，则调用者和 DialogFlow 智能体可以使用此后续意图导航到下一个或上一个可能的选项。
    • 重复：用于重复对话。
    • 选择编号：这是选择编号选项时使用的跟进意图。

  • DialogFlow 事件：使用 DialogFlow 事件，智能体可以响应外部事件触发对话流。 外部事件在上下文中称为非对话输入。 例如，电子邮件，社交媒体消息或对特定号码的电话的接收可以配置为外部事件。 DialogFlow 智能体可以配置为监听此类事件，并根据特定事件采取对话路径。 DialogFlow 上有一些可用的预定义平台事件。 这些是在集成平台上发生的事件。 这是 DialogFlow 支持的平台事件的代表性列表：

    • TELEPHONY_WELCOME：当收到使用 DialogFlow 注册的电话号码的呼叫时，将生成此事件。
    • ALEXA_WELCOME：当用户开始与特定技能进行交互时，将生成此事件。
    • MEDIA_STATUS：根据特定媒体文件的状态（例如，音频文件的播放完成时）生成此事件。 可以在此类媒体状态事件上触发 DialogFlow 操作。
    • SIGN_IN：当用户登录到集成服务（Twitter，Google 等）时，将生成此事件。 在这种情况下，可以触发对话流程。

  • DialogFlow 实现：有时候，对话需要来自外部源的数据才能提供用户所需的信息。 在这种情况下，DialogFlow 提供了一个实现接口，以将请求派生到外部源（例如数据库和 API），并请求特定的数据点。 从外部服务接收到数据后，DialogFlow 会将数据集成到会话的意图和上下文中，并将响应提供给调用方。 可以针对每个意图启用实现设置。 如果未定义实现，则 DialogFlow 使用在意图内定义的静态响应。 通过 Webhook 服务启用与实现智能体的交互。 Webhook 使集成两个异构应用变得容易。 DialogFlow 将上下文和意图数据序列化到 Webhook 服务。 Webhook 服务依次调用外部 API 端点或访问数据库以获取所请求的信息。 这是定义 DialogFlow 请求生命周期的工作流程，该请求需要通过履行服务使用外部源数据：

图 6.2：通过履行服务的 DialogFlow 请求的生命周期

在介绍了 DialogFlow 核心概念之后，在下一部分中，我们将研究在平台上构建 DialogFlow 智能体的过程。

构建一个 DialogFlow 智能体

作为通用 GCP 原则，GCP 项目中存在任何服务。 一个 GCP 项目可以包含一个 DialogFlow 智能体。 如果我们要有多个 DialogFlow 智能体，则需要在不同的项目下进行管理。 一个项目组织了 DialogFlow 智能体所需的所有资源。 前提条件是，我们需要启用 API，监视工具和计费信息。 我们需要提供对项目用户帐户的访问权限，并在粒度级别上设置访问控制，以便用户可以访问最少的服务资源。 我们将通过 DialogFlow 控制台导航至这里来进行工作。

让我们为书店构建一个 DialogFlow 智能体。 导航到控制台后，单击侧面菜单或控制台登录页面上的“创建智能体”按钮。 根据应用的上下文以及默认语言和时区选择智能体名称。 DialogFlow 控制台提供了一个选项，可以使用现有的 GCP 项目以及在从控制台创建智能体的工作流程中创建新项目。 以下屏幕快照显示了 DialogFlow 控制台中的智能体创建屏幕：

图 6.3：DialogFlow 控制台中的智能体创建屏幕

我们将通过 DialogFlow 控制台创建一个新的 Google 项目。 单击右上角的“创建”按钮。 创建智能体后，我们将进入“意图”屏幕。 DialogFlow 为每个智能体提供两个默认意图。 这些是任何应用通常都需要的预配置意图：

  • 欢迎意图：这是开始对话的默认意图。 作为最佳实践，座席需要向用户打招呼并使其与问候语的总体用户风格相匹配。 还建议欢迎意图以智能体提供的领域特定的功能进行答复。 例如，对于书店智能体，该智能体需要向用户打招呼，并简短地谈论书店。

  • 后备意图：这是默认意图，当智能体无法将用户表达式与任何已配置的意图匹配时调用。

所有意图都配置有上下文，事件，训练短语，动作和参数，响应和实现。 让我们看一下默认的欢迎意图。 可以根据应用上下文对欢迎意图进行配置和修改以吸引用户：

图 6.4：默认欢迎意图

默认的欢迎意图配置了一组训练短语和响应。 让我们修改默认的欢迎意图以适合我们的书店智能体。 我们可以添加新的响应，也可以删除 DialogFlow 提供的默认响应。

以下屏幕截图说明了欢迎意图的配置：

图 6.5：配置默认的欢迎意图

DialogFlow 控制台提供了一种快速测试已配置响应的简便方法。 在右窗格中，DialogFlow 提供了一种提供音频和文本输入的方法，并根据配置的意图模拟 DialogFlow 智能体的响应。 这是一个截图，说明了来自欢迎意图的响应：

图 6.6：意图测试

我们可以使用以下工具配置智能体：

  • 用于输入测试短语的文本字段：控制台使用户可以键入测试字符串，还可以与系统的麦克风集成以进行语音对话测试。
  • 用户表达式：DialogFlow 测试窗格会重现输入或说出的文字，以进行验证和测试。
  • 响应：基于意图配置，来自 DialogFlow 智能体的响应显示在此区域中。
  • 诊断信息：这是 DialogFlow 提供的一种方便工具，用于对意图请求/响应进行故障排除。

单击“诊断信息”按钮，以 JSON 格式查看 DialogFlow 智能体的响应。 这是来自智能体的 JSON 格式的示例响应：

{
        "responseId": "af1b533d-b107-42c1-b2af-1fcc30ed6b01-b4ef8d5f",
        "queryResult": {
             "queryText": "Hello",
             "action": "input.welcome",
             "parameters": {},
             "allRequiredParamsPresent": true,
             "fulfillmentText": "Hi, Thank you for calling My Book Store. We are open from 9 am to 6 pm",
             "fulfillmentMessages": [
                 {
                   "text": {
                   "text": [
                        "Hi, Thank you for calling My Book Store. We are open from 9 am to 6 pm"
                     ]
                   }
                }
              ],
       "intent": {
           "name": "projects/mybookstore-efjbhb/agent/intents/6fa880d8-1ed2-4999-86dc-a58211a164c4",
           "displayName": "Default Welcome Intent"
       },
          "intentDetectionConfidence": 1,
          "languageCode": "en"
     }
}

我们可以为欢迎意图添加响应变体。 DialogFlow 根据上下文和用户表达式随机选择响应。 为了对提供的特定响应进行精细控制，我们需要通过编写自定义代码来利用实现 API。 当我们提供诸如“我该如何帮助您？”的开放式回复时，智能体期望来自用户的响应以在特定方向上推动对话。

我们可以通过创建自定义意图来处理对话中的这些派生。 在创建自定义意图之前，让我们看一下 DialogFlow 提供的默认回退意图。 当用户的表达式无法与任何已配置的意图匹配时，激活后备意图。 当基于用户表达的意图匹配失败时，DialogFlow 会提供默认的后备意图和一组预配置的响应。 这是 DialogFlow 中默认回退意图的快照：

图 6.7：默认回退意图

让我们创建几个自定义意图来帮助 MyBookStore DialogFlow 智能体继续与自定义欢迎意图之外的呼叫者进行对话。 我们希望智能体执行以下两项任务：

  • 提及当月的新来者清单。
  • 保留该书的副本供用户取用。

在这种情况下，我们需要创建两个意图。 让我们创建我们的第一个意图，该意图将当前月书店中的最新消息告知用户。 例如，当用户说“我想知道最近的到货”时，智能体应回答“这是本月到货的新书清单”。 书-1，作者，出版物”。 以下屏幕截图显示了创建新的自定义意图的过程：

图 6.8：自定义意图的创建

从前面的屏幕截图可以看出，我们执行以下步骤：

  1. 在 DialogFlow 控制台中单击“创建意图”按钮。
  2. 提供自定义意图的名称。 在这种情况下，我们将其命名为“新到货”。
  3. 单击“保存”按钮。
  4. 作为基本配置，请配置智能体可以在当前意图内响应的各种训练短语。

以下屏幕截图显示了在新到达意图中配置训练短语和座席响应的过程：

图 6.9：自定义意图的训练短语和座席响应的配置

在特定的自定义意图内添加可能的用户短语的多个变体。 当我们使用自然语言进行交流时，可以通过多种方式表达特定的事物。 我们配置的训练短语越多，DialogFlow 越能训练模型以准确处理各种交流方式。 在内部，DialogFlow 利用 ML 算法，该算法在更多训练数据中会变得更好。

建议使用至少 10 个训练短语组合来配置意图：

  1. DialogFlow 提供了用于实现反馈循环的训练工具，并提高了智能体的准确率。 部署 DialogFlow 智能体并且用户开始与该智能体通信后，将有用户登录到 DialogFlow 的短语和话语。 我们需要启用设置以将交互记录到 DialogFlow。 这些设置可以在智能体设置页面的“常规”选项卡上找到。 以下屏幕快照显示了 DialogFlow 智能体的常规设置：

图 6.10：使用 DialogFlow 记录交互的常规配置

我们需要启用日志设置，以将交互记录到 DialogFlow。 这样，我们将能够收集和存储用户查询。 用户查询将可用于手动训练。 这将有助于创建一个训练循环，以确保随着越来越多的用户与智能体进行交互，智能体在一段时间内的表现会更好。

  1. 为“新到达”意图添加各种响应。 在此意图的上下文中，输入表达式的所有变体都希望智能体做出响应，以提及书店中的新到货清单。 与我们使用默认的欢迎意图所做的类似，我们可以配置多个响应，这些响应向呼叫者提供有关新到达的信息。 DialogFlow 会为每个用户表达式随机选择一个已配置的响应的特定实例，以匹配意图中已配置的训练短语。

  2. 可以使用一组训练短语来测试智能体配置。

  3. DialogFlow 显示了已被解释并与意图匹配的用户表达式。

  4. 智能体基于意图配置做出响应。

一旦用户知道书店有新来的东西，智能体就可以引导对话以查看用户是否感兴趣。 如果是，则可以将意图响应配置为引导用户保留特定书籍的副本以供提取。 为了简化此操作，我们需要从用户的表达式中捕获参数。 到目前为止，这是使用 MyBookStore 智能体进行的转换的流程：

来电者：你好我的书店智能体：您好，感谢您致电我的书店。 我们的营业时间为上午 9 点至下午 6 点。来电者：这个月有什么新来的？我的书店的智能体：这个月我们有三个新来的人。 您想来接下一本书吗？来电者：是的。 我想明天来接。我的书店智能体：可以。 你明天想什么时间来？来电者：上午 10 点。我的书店智能体：知道了。 您的约会预定于 2019 年 12 月 30 日在上午 10 点进行。 再见。

在这种情况下，用户打算去商店并提到一天。 DialogFlow 智能体需要配置为从用户表达式中提取含义。 对于人类来说，从对话中提取有意义的信息是一件容易的事。 但是，机器（DialogFlow）智能体需要针对特定​​的对话流进行训练。 要安排商店访问的约会，让我们创建一个名为Store_Visit的新意图：

  1. 创建一个名为Store_Visit的新意图。
  2. 在训练短语部分中，添加以下短语：
    • 3 pm today。
    • Today。
    • Yes. I want to come and pickup tomorrow。

输入这些训练短语后，请注意，“操作和参数”部分中将出现两个参数。 这些参数映射到@sys.date和@sys.time系统参数。 以下屏幕截图显示了训练短语以及已配置的操作和参数：

图 6.11：带有动作和参数的定制意图

通过此设置，当“我的书店”智能体包含日期和时间信息时，他们可以根据特定的训练短语为呼叫者预订约会； 但是，在实际对话中，我们不能期望用户在初始对话期间提供所有必需的信息。 为了解决这个问题，我们需要使用一种称为插槽填充的功能。 我们需要将已识别的参数设置为REQUIRED。 请参阅“图 6.11”。 我们需要通过选中第一列中的框来设置所需的日期和时间参数。

一旦完成，座席将在对话期间要求特定的数据和时间信息，并提示用户输入需要安排约会的日期和时间。 必需参数的顺序指示 DialogFlow 智能体将搜索有关必需字段的信息的顺序。 在这种情况下，智能体将提示用户设置约会日期，然后再在特定时间进行预订。 获取约会日期后，智能体会提示用户设置约会时间。 在PROMPTS列中，我们可以配置各种表达式，以提示需要特定的参数。 以下屏幕截图显示了$time参数的提示配置：

图 6.11：插槽填充和提示配置

这是使对话更加有意义和自然的两个不同步骤：

  • 使用提示填充插槽来收集所需参数的值
  • 配置各种提示来收集约会时间

随着我们添加更多的训练短语和响应，并在我们的应用上下文中以自然的对话风格填充空位和提示，对话听起来越来越自然。 让我们使用 DialogFlow 提供的测试接口来测试 MyBookStore 智能体：

图 6.12：测试 MyBookStore 智能体

MyBookStore 智能体执行以下步骤：

  • 智能体通过各种意图和空位填充无缝地导航对话。 在这一点上，我们仅提供了答复，说已预约。
  • 该约会尚未在后端系统中实际预订，并且尚未进行日历条目。 为了使用户能够进行日历条目，我们需要使用履行过程来创建日历条目。

DialogFlow 支持的用例

DialogFlow 引擎可以有效地用于需要人工智能体回答客户查询或执行一组预配置操作的任何行业的商务应用。 借助语音交互和强大的 NLP 引擎，对话听起来自然，并且如果进行了广泛配置，则呼叫者很难区分人工智能体和 DialogFlow 智能体。

DialogFlow 智能体提供对在开发和配置过程中经过内部训练的 ML 模型的无服务器访问。 GCP 支持的所有非函数式方面和功能固有地可用于 DialogFlow 智能体。 一些重要的优势是可伸缩性和可用性。 如果服务遇到大量流量和 API 请求，则会自动扩展群集以满足对计算资源的需求增长。 由于使用了底层的 GCP 基础架构，该平台还确保了 99.9% 的可用性。

这有助于无缝地为服务提供 24/7 客户支持。 例如，在航空公司智能体的情况下，客户可以使用 DialogFlow 提供的对话界面查询航班时刻表，预订航班或执行 Web 登机手续。 该智能体可以 24/7 全天候提供这些服务，从而提高了服务水平并显着降低了运营成本。 智能体可以与客户的 CRM 系统集成，以便处理某些未经训练的请求。 随着服务的使用，对日志进行分析，并建立反馈循环，会话智能体的质量会在一段时间内提高。

使用 DialogFlow 执行音频情感分析

DialogFlow 提供了一项功能，可以对每个用户表达式执行情感分析。 当产品或服务的用户致电寻求帮助时，此功能在呼叫中心的环境中很有用。 DialogFlow 利用了 Cloud Natural Language 的情感分析引擎。 可以从 DialogFlow 设置菜单中启用情感分析，方法是导航到“高级”设置，然后单击“为当前查询启用情感分析”。

DialogFlow 企业版中提供了此功能。 DialogFlow 还提供与 Cloud Natural Language 引擎的集成，以执行情感分析。 每个用户对话都是有状态的交互，并由 DialogFlow 中的session_id唯一标识。 建议您在 API 调用中使用相同的会话 ID 进行连续对话。 这是一个代码片段，用于使用 DialogFlow API 根据对话中的用户表达式执行情感分析：

def get_sentiment(PROJECT_ID, SESSION_ID, text,language_code): 

    import dialogflow_v2 as dialogflow  
    session_client = dialogflow.SessionsClient()

    session_path = session_client.session_path(project_id, session_id)

    text_input = dialogflow.types.TextInput(text=text, language_code=language_code)

    query_input = dialogflow.types.QueryInput(text=text_input)

    sentiment_config = dialogflow.types.SentimentAnalysisRequestConfig(analyze_query_text_sentiment=True)

    query_params = dialogflow.types.QueryParameters(sentiment_analysis_request_config=sentiment_config)

    response = session_client.detect_intent(session=session_path, query_input=query_input, query_params=query_params)

用户表达的情感分数封装在响应对象中。 当需要智能履行智能体程序时，可以将该 API 方便使用，该智能体程序可以与外部系统和服务集成以通过智能对话智能体程序提供增值服务。 该服务可以与外部数据源集成，以使对话对呼叫者更加有意义和有用。

这种集成使构建可以访问大量外部信息和服务的智能体成为可能。 该平台还提供了一个封闭的反馈环路，用于在智能体用于自然对话时改善一段时间内的对话。 该平台还提供与 Natural Language 引擎的无缝集成，以对 DialogFlow 智能体遇到的每个用户表达式执行情感分析。 利用 DialogFlow 可以轻松满足各种可能性和用例。 使用 DialogFlow，功能团队可以使用机器智能和类似人的对话。

总结

在本章中，我们学习了 DialogFlow，它是一个用于构建对话应用的服务。 对话式应用需要强大的 NLP 引擎，训练模型以分析用户表达的基础结构，规则引擎以及用于提供自然语言响应的智能体。 独立地构建这些功能块需要对组件进行编码。 可伸缩性和可用性也面临挑战。

我们已经看到了 GCP 上的 DialogFlow 引擎如何处理所有构造块，并允许开发人员专注于业务场景并提供简单的用户界面以及 API 层以利用服务。 无需编码即可构建具有静态内容的简单对话智能体，因此开发团队无需具备高端编程技能。 可以由业务分析师和了解服务功能方面的人员来构建简单的对话智能体。 与外部服务（电子邮件，电话，社交媒体等）的集成也可以由实现智能体完成。

在下一章中，我们将深入研究云 TPU，它们是构建高性能 ML 操作的基本构建块。

七、了解云 TPU

任何平台都只能发挥其优势。 利用 Google Cloud Platform（GCP）之类的平台，最重要的方面是将其投入运营，来处理业务的日常工作量。 在本章中，我们将看到在 GCP 上运行人工智能（AI）的一些最佳实践和实用技巧。 我们将了解张量处理单元（TPU）以及 TPU 如何在内部运行以促进大规模并行计算需求，以便构建利用机器学习（ML）模型的各种服务。

本章将涵盖以下主题：

  • 云 TPU 及其组织简介
  • 软硬件架构图
  • 将 TPU 用于模型开发的最佳实践
  • 使用TPUEstimator训练模型
  • 设置 TensorBoard 以分析 TPU 性能
  • 表现指南
  • 了解抢占式 TPU

云 TPU 及其组织的简介

TPU 是在 GCP 上构建各种服务和 ML 模型的基本构建块。 为了充分利用该平台，我们需要了解 TPU 的核心概念。 这些核心概念将帮助我们优化性能，并使我们能够最大程度地利用为该帐户分配的计算资源。

Google 已经开发了 TPU，以加速 ML 工作流程。 借助 Cloud TPU，用户可以使用 TensorFlow 在 Google 的 Cloud TPU 硬件上运行其 ML 工作流。 用户可以使用 TPU（特别是线性代数算法）获得最大的性能提升。 TensorFlow 计算集群可以利用中央处理器（CPU），图形处理器（GPU）和 TPU 来构建。 在本章的后面，我们将详细讨论可以使用 TPU 并可以带来巨大好处的领域。

现在，让我们快速检查一下 Cloud TPU 可用的区域。 这将帮助您确定最近的模型部署区域：

  • 在美国地区的可用性：在撰写本章时，TPU 在美国和欧洲地区普遍可用。 以下屏幕快照所示的表格中列出了美国地区的一般可用性：

TFRC 是 TensorFlow 研究云的缩写。

  • 在欧洲地区的可用性：在以下屏幕快照中显示的表格中列出了欧洲区域的一般可用性：

  • 在亚洲地区的可用性：此外，GCP 在亚洲地区也正在扩展，在撰写本章时，其可用性有限，如以下屏幕快照所示。 预计随着 GCP 在整个地理区域中采用率的提高，亚洲地区的可用性也会有所提高：

应用可以通过虚拟私有云（VPC）网络从实例，容器和 AI 服务访问 TPU 节点。 下表概述了访问 GCP 上的 TPU 节点的方法：

  • Compute Engine 上的 Cloud TPU 非常适合需要它来管理自己的 Cloud TPU 服务的用户； 通常，建议使用 Google Cloud 的用户，因为它具有 CTPU 工具，可以为用户完成基本的后台工作，例如设置虚拟机，云存储服务和 TPU。

  • 当您需要在应用中进行自动扩展，灵活地更改硬件（CPU，GPU 和 TPU 之间），虚拟机的自动管理以及无类别域间路由（CIDR）时，可以使用 Kubernetes Engine 上的 Cloud TPU 块范围，更重要的是，是一个容错应用。

  • 经验丰富的 ML 程序员应使用 AI 服务上的 Cloud TPU，他们可以利用 GCP 提供的托管 AI 服务。 AI 服务为用户管理 AI 工作流中的许多活动，例如在用户数据上训练 ML 模型，部署模型，预测监控和模型管理。

现在，我们对 TPU 有了基本的了解，让我们看一下 TPU 的使用领域和优势。

以下屏幕快照描述了硬件使用的区域，即 CPU，GPU 和 TPU：

从前面的屏幕快照可以明显看出，我们需要在用例和当前问题的背景下进行思考，然后才能在 CPU，GPU 和 TPU 之间做出选择。 具有由矩阵计算控制的大量训练和评估数据的超大型模型最适合在 TPU 上进行训练。

使用 TPU 的优势

在 ML 算法中，通常使用线性代数计算。 TPU 使这种计算的性能最大化； 可以在很短的时间内在 TPU 上训练在 GPU 上花费大量时间的模型。 此外，对于卷积神经网络（CNN）模型，Cloud TPU 大大缩短了达到准确率的时间。 如果您拥有适用于 Cloud TPU 的应用，则可以在很短的时间内以非常低的成本获得最大的输出。

以下屏幕快照显示了用于训练 ResNet 50 模型的 GPU 和 TPU 的快速比较。 ResNet 50 是一个 CNN 模型，已经对 ImageNet 数据库中的一百万幅图像进行了训练。 已经观察到，如果用户使用八个 v100 GPU 和一个完整的 Cloud TPU v2 pod，则训练时间和成本都会大大降低。 虽然训练速度提高了 27 倍，但成本也降低了 38%。

以下屏幕截图比较了在 GPU 和 TPU 上进行训练的成本：

图 7.1 训练费用比较

从前面的屏幕快照可以明显看出，TPU 可以为复杂的模型训练工作节省大量成本。 在一段时间内进行多次部署后，节省的成本变得更加重要，尤其是在生产部署场景中，该场景中需要经常训练模型。

软硬件架构图

为了进一步加速数学计算，创建了专用硬件作为专用集成电路（ASIC）。 这样，尤其是在n-多维数学中，计算能力得到了倍增。 在本节中，我们将详细介绍 TPU 及其相关组件的软件和硬件架构。

可用的 TPU 版本

每个 TPU 版本都包含一些主要组件，这些组件构成了 TPU 的功能。 在讨论 TPU 版本时，我们将看一下 TPU 内核的架构和 TPU 内核的高带宽存储器（HBM）。 我们将了解每个 TPU 设备上的内核如何互连以及如何将网络接口用于设备间通信。

下表显示了 TPU v2 的特征：

  • 每个 TPU 内核 TPU v2 的 HBM 为 8 GB。
  • 每个内核具有一个128 * 128的矩阵单元（MXU）。
  • 一个 TPU 盒最多可具有 512 个内核和 4 TB 的总内存。

下图显示了 TPU v2 的组织：

图 7.2 TPU V2 特性

下表显示了 TPU v3 的特征：

  • 每个 TPU 内核 TPU v3 的 HBM 为 16 GB。
  • 每个内核具有两个128 * 128的 MXU。
  • 一个 TPU 盒最多可具有 2,048 个内核和 32 TB 的总内存。

下图显示了 TPU v3 的组织：

图 7.3 TPU 的组织

每个 TPU 内核均由标量单元，向量单元和 MXU 组成。 TPU 芯片以 MXU 计算能力为后盾。 在一个周期内，MXU 可以执行 16,000 个乘积（MAC）操作。 MXU 输入和输出是 32 位浮点值，但是它以bfloat16精度执行乘法以提高精度。 每个内核可以独立执行用户操作，并且通过高带宽互连可以与其他芯片进行通信。 对于大型 ML 工作负载，可以将多个 TPU 设备与高速网络接口互连，以获得大量的 TPU 内核和内存。

与 TPU v2 相比，TPU v3 的性能优势

正如我们在本书前面所看到的，与 TPU v2 相比，TPU v3 具有更多的 TeraFlops（TFLOPS）和内存。 因此，肯定有一些地方 TPU v3 可以获得比 TPU v2 更好的结果。 要确定要使用的 TPU 版本，可以在可用版本上运行模型，并使用 TensorBoard 检查性能。

以下是 TPU v3 可以改善的一些方面：

  • 受计算限制的模型在 TPU v3 上具有显着的优势。
  • 数据不适合 TPU v2 内存但适合 TPU v3 内存的情况会有所帮助。
  • 批量大小不适合 TPU v2 的新模型可以再次获得性能优势。
  • 在某些区域中，模型是输入绑定的，或者模型是内存绑定的； 在那里，您可能看不到这种性能提升。 因此，在确定 TPU 版本之前，请在预期用例的背景下进行性能基准测试和成本值分析。

可用的 TPU 配置

让我们讨论 Google 提供的不同类型的 TPU 配置。

Google 提供了两种不同类型的配置，用户可以在两个 TPU 版本中利用它们。 它们如下：

  • 单设备 TPU：这些是执行所有操作的单独设备。 这些设备未通过网络与其他 TPU 设备互连。 实际上，一个以上的单个 TPU 设备无法通过网络连接到另一设备。
  • TPU 盒：TPU 盒不过是群集，其中有多个 TPU 设备通过高速网络与另一台设备互连。

下图描述了单个 TPU 设备，因为它不连接到另一个 TPU 设备，因此不需要高速网络带宽。 TPU 节点仅连接到一个 TPU 设备。 TPU 中的芯片已经互连，不需要主机 CPU 或主机网络资源：

图 7.4 单设备 TPU

上图中的设备正在使用 Cloud TPU v3，但是在设置节点时，您可以指定任何 TPU 版本。 我们将在“软件架构”部分中讨论流程。 以下屏幕快照描绘了一个 TPU 盒，其中多个 TPU 设备通过高速网络连接进行连接：

图 7.5 TPU 盒

在上图中，请注意以下几点：

  • 主机正在不同的 TPU 设备上分配 ML 工作流。
  • TPU 中的芯片已经互连，不需要主机 CPU 或主机网络资源。
  • 由于 TPU 设备通过高速带宽网络连接，因此它们也不需要主机 CPU 或主机网络资源。

上图中的设备正在使用 Cloud TPU v2，但是在设置节点时，可以指定任何 TPU 版本。 在创建 TPU 节点时，我们还可以指定是占用全部 TPU 还是部分 TPU 吊舱。 可以使用 Cloud TPU API 自动化 TPU 节点的 TPU 管理，这极大地有助于扩展集群和管理工作负载。

软件架构

在本节中，我们将看到运行应用时在软件方面发生的情况。

TPU 软件架构的流程：TensorFlow 生成计算图，并通过 gRPC 远程过程调用（gRPC）。 根据您选择的 TPU 的类型和可用于工作负载的设备数量，TPU 节点会及时编译计算图，并将二进制文件发送到一个或多个可用的 TPU 设备。

下图描述了 TPU 软件架构的软件组件块。 它由 ML 模型，TPUEstimator， TensorFlow 客户端， TensorFlow 服务器 和 XLA 即时（JIT）编译组成：

图 7.6 TPU 的软件组件块

让我们详细讨论每个组件，如下所示：

  • TPUEstimator：TPUEstimator简化了 Cloud TPU 的模型构建，以提取最大的 TPU 性能。 TPUEstimator是基于估计器的高级 API。 TPUEstimator将 ML 程序转换为 TensorFlow 操作。 对于使用 Cloud TPU 的 ML 模型，绝对应该使用TPUEstimator。
  • TensorFlow 客户端：TensorFlow 客户端将 TensorFlow 操作转换为计算图，然后通过 gRPC 发送到 TensorFlow 服务器。
  • TensorFlow 服务器：TensorFlow 服务器在 Cloud TPU 服务器上运行。 当 TensorFlow 服务器从 TensorFlow 客户端接收到计算图时，它将从所需的存储中加载输入。 它将图划分为多个块，应在 TPU 和 CPU 上运行。 它生成加速线性代数（XLA）操作，以便在 Cloud TPU 上运行子图，并调用 XLA 编译器。
  • XLA 编译器：XLA 是即时（JIT）编译器。 TensorFlow 服务器产生 XLA 编译器视为输入的操作。 XLA 生成在 Cloud TPU 上运行的二进制代码，包括从片上存储器到硬件执行单元的数据编排以及芯片间通信。 Cloud TPU 使用 Cloud TPU 服务器和 Cloud TPU 之间的外围组件互连快速（PCIe）连接来加载二进制代码，然后启动执行。

使用 TPU 的模型开发的最佳实践

在本节中，我们将讨论如何在 Cloud TPU 上开发模型以最大化模型表现并优化利用硬件。

让我们快速看一下 TPU 芯片配置。 单个 TPU 芯片包含两个内核，每个内核具有多个 MXU。 正如我们所讨论的，MXU 非常适合执行密集矩阵乘法和卷积的程序。 因此，对于此类程序，我们绝对应该考虑使用 TPU 并利用其硬件。 未执行矩阵乘法并且执行诸如add之类的操作的程序将不会有效地使用 MXU。 在以下小节中，我们将介绍一些准则，这些准则将帮助您决定是否应使用 TPU，并告知您如何开发模型以从中获得最佳性能。

在 TPU 上进行模型开发的指导原则

为了充分利用硬件程序，您应该利用所有可用的内核，因为这会增加模型训练的时间（每个 TPU 设备包含四个芯片和八个内核）。 这可以使用TPUEstimator来实现。 它提供了一个图运算符，可帮助构建和运行副本。 每个副本都是在每个核心上运行的训练图，并且实质上是批量大小的八分之一。

布局和形状是获得性能提升的非常重要的方面。 当 XLA 编译器转换代码时，它包括将矩阵平铺为多个小块。 这样可以提高 MXU 的使用效率。 由于 MXU 为128 * 128，因此它希望平铺应为 8 的倍数。有些适用于平铺的矩阵，而有些则需要重塑。 这些是内存绑定操作。 形状恒定的模型适合 TPU，而形状变化的模型不适合 Cloud TPU，因为重新编译形状会减慢处理速度。

对于高性能的 Cloud TPU 程序，应将密集的计算轻松地分为128 * 128的倍数。XLA 编译器使用填充选项。XLA 编译器未完全利用 MXU 时，将张量填充零。 您可以通过op_profile看到 XLA 编译器应用的填充。 通常，填充有助于提高性能，但也有两个缺点。 应用填充意味着未充分利用 MXU，并且由于它增加了张量所需的片上存储空间，因此有时可能会导致内存不足错误。 因此，选择正确的尺寸对于最小化/避免填充非常重要。

张量尺寸应该非常谨慎地选择，因为它在从 MXU 中提取最大性能方面起着重要作用。 XLA 编译器使用批量大小或尺寸来获得 MXU 的最佳性能。 因此，任何一个都应该是 128 的倍数。如果都不是 128 的倍数，则编译器应该填充 1 到 128。可以从 MXU 中获得最大的性能，因为它的批量大小和 TPU 是 8 的倍数。

使用TPUEstimator训练模型

在本节中，我们将讨论训练模型时TPUEstimator的用法和优点。

TPUEstimator吸收了许多底层的，特定于硬件的细节，并简化了在 Cloud TPU 上运行的模型。 TPUEstimator在内部执行许多优化以增强模型的性能。 使用TPUEstimator编写的模型可以跨不同的硬件运行，例如 CPU，GPU，TPU 吊舱和单个 TPU 设备，大多数情况下无需更改代码。

标准 TensorFlow 估计器 API

TensorFlow Estimator 提供了一个用于训练，评估，运行和导出服务模型的 API，如下表所示。 对于估计器，您应该编写与 TensorFlow 图的模型和输入部分相对应的model_fn和input_fn函数。 让我们看一下以下屏幕截图：

图 7.7 TensorFlow API

除了上述功能之外，TensorFlow Estimator 还包括其他一些常见功能，例如工作训练，检查点功能等。

TPUEstimator编程模型

GCP 为TPUEstimator编程提供了一致的模型。 以下是有关模型的详细信息：

  • TPUEstimator使用model_fn，它包装计算并将其分配到所有 Cloud TPU 内核。 为了获得最佳性能，应根据批量大小调整学习率。

  • 跨 TPU 进行计算的复制和分发由model_fn完成。 您必须确保计算仅包含 Cloud TPU 支持的操作。

  • 通过input_fn函数对在远程主机 CPU 上运行的输入管道进行建模。

  • 输入操作应使用tf.data进行编程。

  • 每次调用都会将全局批量的输入处理到一个设备上。 碎片批量大小是从['batch_size']参数中获取的。 确保返回数据集而不是张量以获得最佳性能。

  • 应用代码始终在客户端上运行，而工作程序执行 TPU 计算。

  • 为了获得良好的性能输入管道，操作始终放在远程工作器上，只有tf.data支持它。

  • 为了摊销 TPU 的启动成本，模型训练步骤包含在tf.while_loop中，到目前为止，tf.while_loop仅可以包装tf.data。 因此，正是出于这两个原因，必须使用tf.data。

TPUEstimator概念

基本上，TensorFlow 程序可以使用图内复制和图间复制。 为了运行 TensorFlow 程序，TPUEstimator使用图内复制。 稍后，我们将介绍图内复制和图间复制之间的区别。

TensorFlow 会话主服务器不在TPUEstimator中本地运行。 我们的程序创建了一个图，该图被复制到 Cloud TPU 中的所有可用核心，并且 TensorFlow 会话主服务器设置为第一个工作服务器。 输入管道位于远程主机上，因此训练示例可以快速提供给 Cloud TPU。 Cloud TPU 工作器之间发生同步操作； 也就是说，每个工作器都在同一时间执行相同的步骤。

从 TensorFlow 估计器转换为TPUEstimator

当您转换为任何其他工具时，请确保从一个小例子开始，然后再处理一个复杂的例子。 这有助于熟悉任何工具的基本概念。

要将tf.estimator.Estimator类转换为使用tf.contrib.tpu.TPUEstimator，您将需要执行以下步骤：

  1. 将tf.estimator.RunConfig更改为tf.contrib.tpu.RunConfig。

  2. 设置TPUConfig以指定iterations_per_loop。 训练循环的指定迭代次数由 Cloud TPU 执行，然后返回主机。 在运行所有 Cloud TPU 迭代之前，不会保存检查点或摘要。

  3. 在model_fn中，使用tf.contrib.tpu.CrossShardOptimizer包装优化器，如以下代码所示。 您必须将tf.estimator.Estimator更改为tf.contrib.tpu.TPUEstimator才能转换为TPUEstimator：

optimizer = tf.contrib.tpu.CrossShardOptimizer(
 tf.train.GradientDescentOptimizer(learning_rate=learning_rate))

默认值RunConfig在每 100 个步骤后为 TensorBoard 保存摘要，并每 10 分钟写入一个检查点。

设置 TensorBoard 来分析 TPU 性能

分析任何应用的性能都是至关重要的，TensorBoard 可帮助可视化和分析 Cloud TPU 的性能。 使用 TensorBoard，您不仅可以监视您的应用，还可以通过应用 TensorBoard 提供的建议来提高其性能。

设置 Cloud TPU 之后，您应该安装最新版本的 Cloud TPU 分析器以创建capture-tpu-profile脚本。 以下是运行 TensorBoard 的步骤：

  1. 打开一个新的 Cloud Shell 以启动 TensorBoard。
  2. 运行以下命令来设置所需的环境变量，并为您的云存储桶和模型目录创建环境变量。 模型目录变量（MODEL_DIR）包含 GCP 目录的名称，该目录在模型训练期间存储检查点，摘要和 TensorBoard 输出。 以下代码显示了带有可用于设置 TensorBoard 的参数的命令：
$ ctpu up ctpu up --name=[Your TPU Name] --zone=[Your TPU Zone]

$ export STORAGE_BUCKET=gs://YOUR STORAGE BUCKET NAME
$ export MODEL_DIR=${STORAGE_BUCKET}/MODEL DIRECTORY

TensorBoard 跟踪可以通过两种方式查看：

  • 静态跟踪查看器
  • 流式跟踪查看器

如果每个 TPU 需要超过一百万个事件，则必须使用流式跟踪查看器。

让我们检查一下如何启用静态跟踪查看器。

  1. 在用于设置环境变量（在上一步中设置）的同一 Cloud Shell 中运行以下命令：
$tensorboard --logdir=${MODEL_DIR} &
  1. 在同一 Cloud Shell 的顶部，单击Web Preview并打开端口8080以查看 TensorBoard 输出。 要从命令行捕获输出，请运行以下命令：
$ capture_tpu_profile --tpu=[YOUR TPU NAME] --logdir=${MODEL_DIR}

TensorBoard 提供以下功能：

  • TensorBoard 提供了各种选项来可视化和分析性能。
  • 您可以可视化图并利用 Profiler 来提高应用的性能。
  • XLA 结构图和 TPU 兼容性图对于分析非常有用。
  • 还有一些分析器选项，例如概述页面，输入管道分析器，XLA Op 配置文件，跟踪查看器（仅适用于 Chrome 浏览器），内存查看器，吊舱查看器和流式跟踪查看器（仅适用于 Chrome 浏览器）。 这些对于分析性能和调整应用非常有用。

性能指南

在开发模型时，非常重要的是要对其进行调整以使其获得良好的性能。 在本节中，我们将介绍一些技巧，这些技巧将帮助您提高模型在 Cloud TPU 上的性能。 这样，Cloud TPU 可以提供良好的性能，但是我们可以通过为应用设置正确的配置来增强它。

在以下小节中，我们将讨论提高性能的重点领域。

XLA 编译器性能

XLA 编译器是标准 TensorFlow 代码库的一部分。 它是 ML 编译器，可以为 CPU，GPU，TPU 和其他一些平台生成二进制文件。 将 Cloud TPU 的 TensorFlow 模型转换为 XLA 图，然后 XLA 编译器将其转换为 TPU 可执行文件。 在这里，我们将注意到的一件事是 TPU 硬件不同于 CPU 和 GPU 硬件。

CPU 具有少量高性能线程，而 GPU 具有大量高性能线程。 Cloud TPU 具有128 * 128个 MXU，它们可以作为单个非常高性能的线程执行，并且每个周期可以执行 16,000 次操作，或者以管道方式连接的128 * 128个微小线程。

平铺的后果

Cloud TPU 中的数组是平铺的。 这要求将其中一个维度的填充填充为 8 的倍数，将另一个维度填充为 128 的倍数。XLA 执行数据布局转换，以将数据安排在内存中以进行有效使用。 这些转变是由试探法驱动的。 这对于大多数模型而言效果很好，但有时可能会出错。 为了获得最佳性能，应尝试不同的配置。

以下是一些可以最大程度提高性能的非常重要的事情：

  • 填充成本应降至最低。
  • 批和特征尺寸的值应非常有效地选择。

融合

如果要组合执行多个操作，则 XLA 编译器将使用融合技术来优化程序。 融合操作是可以组合执行的多个操作的组合。

例如，考虑以下一系列操作：

tf_add = tf.add(x, y)
result = tf.multiply(tf_add, z)

在步骤中，此代码将像这样执行：

  1. 首先，循环将顺序访问元素并执行加法运算，结果将保存在tf_add中，并将其存储在临时存储器中，如以下代码块所示：
for (i = 0; i < cnt; i++) {
 tf_add[i] = x[i] + y[i];
}
  1. 现在，将再次访问加法结果并将其相乘，如下所示：
for (i = 0; i < cnt; i++) {
 result = tf_add[i] * z[i];
}

使用融合，数组访问会同时发生，如以下代码块所示：

#In Fusion both addition and multiplication operations are performed together.
for (i = 0; i < cnt; i++) {
 result = (x[i] + y[i]) * z[i];
}

在此示例中，内存往返次数减少了，并且 XLA 不需要为tf_add分配任何空间。

融合为 Cloud TPU 带来了许多好处，例如：减少了内存传输，优化了硬件利用率，等等。

当两个形状相同的张量组合在一起时，广播将隐式发生，但是请注意，强制实现广播可能会导致性能下降。

了解抢占式 TPU

可抢占的 TPU 是低成本 TPU，但其性能与按需 TPU 相同。 但是这里要注意的是，当 Google 需要资源用于其他目的时，总可以终止它。 让我们检查一下如何从控制台创建可抢占的 TPU。

从控制台创建抢占式 TPU 的步骤

GCP 为创建可抢占的 TPU 提供了简单的界面。 涉及的步骤如下：

  1. 在 GCP 控制台上的 Compute Engine 下，选择TPU。 如果未启用 API，请单击ENABLE启用它，如以下屏幕截图所示：

图 7.8 启用 Cloud TPU API

  1. 单击创建 TPU 节点，如以下屏幕截图所示：

图 7.9 创建 TPU 节点

  1. 填写所需的详细信息，选择可抢占性选项，然后单击网络，描述，标签链接，如以下屏幕截图所示：

图 7.10 创建云 TPU

  1. 填写其他详细信息，然后单击屏幕底部的创建，如以下屏幕截图所示，您的 TPU 准备就绪：

图 7.11 创建 Cloud TPU 的其他详细信息

抢占式 TPU 的定价

与按需 TPU 相比，可抢占 TPU 的价格约为价格的 30% 左右。 这里要注意的一点是，抢占式 TPU 的配额高于普通 TPU 的配额，而抢占式 TPU 具有单独的配额。 以下屏幕快照显示了 us-central1 区域中 v2-8 和 v3-8 的定价比较示例：

图 7.12 价格比较 v2-8 和 v3-5

抢占式 TPU 的检测

如果已经创建了 TPU，并且我们必须检查它是否可抢占，则有相应的规定。 以下命令用于检测 TPU 是否可抢占：

  • ctpu命令：运行以下命令检查已创建的 TPU 的详细信息。 在“TPU 可抢占”上打印的值指示 TPU 是否被抢占，READY值表示未抢占 TPU，而PREEMPTED值表示 TPU 已被抢占：
$ ctpu status
  • gcloud命令：如果尚未指定区域，它将使用当前配置中的 compute 属性的值。 运行以下命令以检索项目中可用于 Cloud TPU 的计算区域列表：
$gcloud compute tpus list

在决定使用 TPU 选项之前，请检查您的用例是否可以继续使用可抢占的 TPU，因为这样可以节省大量成本。

总结

在本章中，我们获得了创建 TPU 并在其上编写模型的所有必需知识。 我们已经了解了 Cloud TPU 及其组织以及 Cloud TPU 软件和硬件架构的基础。 我们已经在 Google Cloud 上创建了 TPU 和可抢占的 TPU。 我们已经编写了模型并使用TPUEstimator对其进行了训练。 我们已经使用 TensorBoard 描述了 Cloud TPU。 除了学习所有这些，我们还通过了足够的技巧来编写优化的模型。

在下一章中，我们将基于在实际项目上的经验，介绍在 GCP 上实现 TensorFlow 模型的最佳和行之有效的实践。

八、使用 Cloud ML Engine 实现 TensorFlow 模型

Google Cloud Platform（GCP）上的 Cloud ML Engine 是一种无服务器方式，可用于构建机器学习管道。 该引擎利用基础平台组件，消除了对基础架构的配置和维护的需求。 数据科学家可以专注于数据，模型和预测。 这是在生产环境中启动并运行模型的理想且快速的方法。 该平台固有地提供了存储和计算弹性，并且几乎无限制地扩展了模型的训练和使用已部署的模型进行实时预测的能力。

在本章中，我们将深入研究 Cloud ML Engine，并了解各种构建模块，并使用 TensorFlow 模型对机器学习管道进行实验。

本章将涵盖以下主要主题：

  • 了解 Cloud ML Engine 的组件
  • 训练和利用 TensorFlow 模型涉及的步骤
  • 在 Cloud ML Engine 中打包和部署您的训练应用
  • 为您的训练工作选择正确的计算选项
  • 监控您的 TensorFlow 训练模型作业

了解 Cloud ML Engine 的组件

首先，让我们了解 Cloud ML Engine 满足哪些机器学习工作流程单元。 Cloud ML Engine 可用于以下目的：

  • 训练机器学习模型
  • 部署训练有素的模型
  • 将部署的模型用于预测
  • 通过各种参数和 KPI 监视模型使用情况
  • 模型管理以及版本控制

Cloud ML Engine 具有各种组件，它们执行独特的操作并在机器学习管道中发挥作用。 这些组件是服务组件，它们利用基础平台组件并利用所需的存储和计算量，具体取决于模型的复杂性和数据量。 这是 Cloud ML Engine 的组件。

训练服务

训练服务模型提供了一些预定义的算法，这些算法可轻松用于训练而无需编写任何代码。 该算法可与训练数据一起使用，前提是该数据限于平台上可用算法内的预期方案。

使用内置算法

在撰写本章时，Cloud ML Engine 支持以下算法：

  • 线性学习器：此学习器算法使用 TensorFlow 估计器，LinearClassifier和LinearRegressor，可用于分类和回归问题。 该算法支持图形处理器（GPU）加速，以及默认的中央处理器（CPU）加速器。

  • 宽和深：这是一种旨在具有最佳级别的算法，用于存储训练数据并同时概括输入。 该算法对于分类，回归和排名问题很有用。 该算法支持 GPU 加速以及默认的 CPU 加速器。

  • XGBoost：我们已经在“第 3 章”，“使用 XGBoost 的机器学习应用”中详细了解了此算法，Cloud ML Engine 提供了对该算法的内置包装器，并以并行的方式简化了两个阶段，即预处理和训练。 在预处理阶段，Cloud ML Engine 将分类数据和数字数据转换为统一的数据集，该数据集完全以数字格式表示。 该算法可轻松用于诸如点击率预测之类的用例。 GPU 加速器不支持该算法，并且只能与 CPU 一起使用。

一旦确定了合适的算法，就需要对输入（训练，评估和生产）数据进行格式化，以匹配内置算法的预期模式。 数据需要以不带标题的逗号分隔值（CSV）格式提交，并且第一列应代表目标变量。 我们需要在 GCP 上为内置算法指定存储分区，以存储训练输出。 Cloud ML Engine 为训练工作提供了有限的自定义，例如使用特定的机器类型进行训练。

原始的一组机器类型只能用于内置算法。 我们还可以定义需要运行作业的区域。 默认情况下，平台会自动选择合适的区域来运行训练作业。 还可以通过使用所需的学习率和批量大小来完成特定于作业的自定义。 我们可以设置超参数调整的目标阈值，以实现最大的准确率并最小化损失函数的值。 内置算法可在 GCP 共享空间上的容器内使用，可以与特定的统一资源标识符（URI）配合使用，如下表所示：

算法 容器 URI
线性学习器 gcr.io/cloud-ml-algos/linear_learner_cpu:latest``gcr.io/cloud-ml-algos/linear_learner_gpu:latest
宽深 gcr.io/cloud-ml-algos/wide_deep_learner_cpu:latest``gcr.io/cloud-ml-algos/wide_deep_learner_gpu:latest
XGBoost gcr.io/cloud-ml-algos/boosted_trees:latest

让我们使用内置的线性学习器算法解决一个简单的回归问题。 例如，学生的学业能力测验（SAT）分数与平均绩点（GPA）分数之间存在已知的相关关系 。 我们将有一个包含两列的示例 CSV 文件。

第一列包含 GPA 分数（输出变量），第二列包含 SAT 分数。 首先让我们将 CSV 文件上传到存储桶。 以下是使用 Cloud ML Engine 训练模型的简单步骤，该模型根据 SAT 分数预测 GPA 分数：

  1. 从导航菜单中输入 GCP 控制台和 AI 平台，然后转到Jobs侧菜单。 您将以表格格式查看所有作业（正在运行和已完成）。 单击标题菜单中的“新训练工作”按钮。
  2. 创建训练工作有两种选择：使用内置算法训练或自定义代码训练。 在这种情况下，请选择“内置算法训练”选项。
  3. 选择线性学习器算法。
  4. 单击“下一步”按钮。

在以下屏幕快照中直观地表示了所有前面的步骤。 我们来看一下：

图 8.1-Cloud ML Engine 的模型训练所涉及的步骤（1）

  1. 提供 Google Storage 上 CSV 文件的标准路径。 该 CSV 文件包含没有标题行的训练数据，并且目标属性出现在第一列中。
  2. 提供用于验证的训练数据百分比的数值。 默认情况下，此值为 20，并且可以根据用例上下文将此数字更改为任何合理的值。
  3. 提供用于测试的训练数据百分比的数字值（可选）。 推荐值为 20，可以根据用例要求和机器学习问题的特征进行设置。
  4. 提供到要存储模型文件的输出目录的标准路径。 这必须是 Google Cloud Storage 上的有效位置。
  5. 单击NEXT按钮，为算法提供运行时参数。

在以下屏幕快照中直观地表示了所有前面的步骤。 我们来看一下：

图 8.2-Cloud Engine ML 模型训练所涉及的步骤（2）

  1. 选择需要训练的模型类型。 当预期输出是连续变量时，将使用回归模型；而当预期输出是离散类时，将使用分类模型。
  2. 仔细选择最大步数，以确保完整的训练数据在生成的输出模型中得到充分体现。 同时，为此参数设置很高的值会增加训练模型的计算成本。
  3. 学习率是使用梯度下降算法使用模型时使用的数值。 原则上，此属性指示学习算法的两次迭代之间的步长。

这是需要设置的基本参数。 在以下屏幕快照中直观地表示了所有前面的步骤。 我们来看一下：

图 8.3-将参数传递给模型训练

除了这些基本参数外，还可以对模型进行超调，以进一步优化和提高准确率。 选中“最大步数”旁边的HyperTune复选框时，需要设置最小和最大步数； 并且选中“学习率”旁边的HyperTune复选框时，需要设置最小和最大学习率。

除了基本参数之外，还有一些高级设置可用作可配置参数，用于进一步调整模型训练，如以下屏幕快照所示：

图 8.4-高级模型训练配置

可用于调整的其他参数如下：

  • 评估步骤：这是一个可选字段，指示需要对其进行评估的批量数量。 如果未指定参数，则对整个数据集运行评估。

  • 批量大小：这是在一个评估步骤中处理的数据行数。

  • 优化器类型：我们可以选择三种可能的优化器，这些优化器根据梯度下降算法的实现细节而有所不同：

    • AdamOptimizer
    • FTRLOptimizer（默认）
    • 随机梯度下降（SGD）优化器

  • L1 正则化强度：这是一个数值，表示正则化的一种类型，该类型与权重的绝对值之和成比例地对权重进行惩罚。

  • L2 正则化强度：这是一个数值，表示正则化的一种类型，该类型与权重的平方和成比例地对权重进行惩罚。

  • L2 收缩调整强度：此参数适用于FtrlOptimizer，表示幅度损失。 大于等于 0。

设置算法参数后，最后一步是在下一个工作流程步骤中提供作业 ID，区域和资源大小，如下所示：

  1. 作业 ID：这是一个字母数字字段，在项目中必须是唯一的，并且一旦设置就无法更改。 建议在作业 ID 创建中使用项目特定的上下文，因为这样可以更轻松地在生产环境中进行监视和故障排除。

  2. 区域：这是用于训练模型的服务器所在的地理区域。 建议使用相同的区域来存储训练数据和模型训练。

  3. 扩展层：这定义了需要分配给 AI 平台用于训练工作的资源。 各个层具有预先配置的资源级别，并且可以进行自定义，如下所示：

*   `BASIC`：此层设置单个工作程序实例。 顾名思义，这是基本配置级别，不能考虑用于生产负载。
*   `STANDARD_1`：此层配置许多工作程序和一组有限的参数服务器。
*   `PREMIUM_1`：此层预配置了大量工作程序和参数服务器。
*   `BASIC_GPU`：此层为 GPU 提供单个工作程序实例。 再一次，这将加快训练速度，仅对实验有益。
*   `BASIC_TPU`：此层使用 Cloud TPU 设置单个工作程序实例。
*   `CUSTOM`：使用此配置时，可以完全配置用于训练的群集的规模。 需要为自定义配置设置以下参数：
    *   **主节点类型**：需要用于主节点的虚拟机的类型。 这是必填字段。
    *   **工作器数**：这定义了用于训练的工作器数。 如果工作器数设置为 1 或更多，则还需要设置工作器类型。
    *   **参数服务器数**：这定义了用于训练的参数服务器的计数。 如果参数服务器的数量为 1 个或更多，则需要设置参数服务器类型。

在以下屏幕快照中直观地表示了所有前面的步骤。 我们来看一下：

图 8.5-模型训练的作业设置

  1. 作业设置完成后，模型开始训练，并且可以在控制台中跟踪作业。 以下屏幕截图显示了控制台中正在进行，成功和失败的作业：

图 8.6-模型训练作业控制台

  1. 一旦模型训练完成，就可以从控制台进行部署。 该模型可通过表述性状态转移（REST）API 与新数据集一起调用。 需要提供唯一的模型名称以及需要在其中部署模型的区域，以及关于模型的可选描述，如以下屏幕快照所示：

图 8.7-模型部署

在这一点上，模型被训练和部署以供使用。 在接下来的部分中，我们将研究利用模型和构建预测服务。

使用自定义训练应用

内置算法是一些最常用的算法。 但是，您将需要针对大多数实际用例训练定制模型。 AI 平台提供了用于训练自定义模型的标准一致框架。 以下屏幕快照描述了通用过程：

图 8.8-在 AI 平台上训练自定义模型的步骤

AI 平台与典型的机器学习开发生命周期同步工作并对其进行补充。 模型训练代码从本地文件夹或共享位置访问训练数据。 我们需要从 Cloud Storage 位置访问训练数据。 提取数据后，需要分批量每个单独的数据实例。 可以根据用例上下文和数据量来决定这些批量。 评估数据用于测试模型的准确率。 经过训练的模型将作为二进制文件导出，并存储在本地驱动器或 Cloud Storage 位置中。

另外，可以以分布式方式训练模型。 AI 平台使其成为一个无缝的过程，并要求将有关多台机器的详细信息作为训练群集的参数进行传递。 训练服务根据机器类型和所选容量执行资源分配。 在单个节点上运行的每个训练作业都称为复制副本。 每个副本都扮演一个角色，并对一组特定的训练数据进行操作。 工作负载分配的详细信息由平台管理，不需要特定的用户配置或参与。 有三种类型的实体有助于分布式模型训练，如下所示：

  • 主节点：AI 平台将一个副本指定为主节点。 分布式训练计划在其他可用节点上进行，并且主节点会跟踪进度。 训练作业的总体状态与主节点的状态相同。
  • 工作器：集群中可用的节点扮演工作器的角色。 单个工作器执行其任务，并将状态报告回主节点。
  • 参数服务器：副本节点之一被指定为参数服务器，并执行节点之间模型的共享状态的协调任务。

分布式训练的基本且简单的策略涉及将数据分块为各个段，从而在节点上使用每个单独的数据段来训练模型。 在这种情况下，参数服务器会跟踪各个梯度值，并执行合并到最终模型状态的任务。

使用可用框架之一构建应用后，需要将其打包以便在平台上进行部署。 可以使用gcloud 命令行界面（CLI）完成打包。 建议使用gcloud工具打包应用。 可以使用标准打包和构建工具手动构建该包，如以下代码块所示：

gcloud ai-platform jobs submit training $JOB_NAME --staging-bucket $PACKAGE_STAGING_PATH --job-dir $JOB_DIR --package-path $TRAINER_PACKAGE_PATH --module-name $MAIN_TRAINER_MODULE --region $REGION

这是我们需要传递给脚本的参数的简要说明：

  • --staging-bucket：这是一个存储训练和依赖项的云存储位置。 GCP 项目需要有权访问此存储桶，建议该存储桶位于打算运行训练作业的同一区域中。
  • --job-dir：这是一个云存储位置，用于存储训练作业的输出文件。 该位置必须与训练作业要在同一区域进行。
  • --package-path：这是父目录的本地路径，其中存在应用工件。 AI 平台将该路径中的内容打包到tar.gz文件中，并将其上传到云存储中。 通过解压缩档案的内容来执行训练作业。
  • --module-name：这是应用的名称。
  • --region：这是执行训练工作的地理区域。

预测服务

上一节中训练的机器学习模型可以基于新的数据集托管在云上进行消费和预测。 预测服务主要负责管理预测所需的存储和计算资源。 作为一般过程，需要导出训练工件。 对于在 AI 平台上训练的模型以及在外部训练的模型，导出过程相同。 可以导出的最大模型大小为 250 MB。 如果需要导出更大的定制模型，则需要提交配额增加表。 AI 平台限制了计算基础架构的使用，因此该平台可以在合理的水平上使用，足以满足大多数通用用例的需要。

但是，计算密集型和大型模型可能需要增加配额。 机器学习模型预测是一个迭代过程，需要对模型的多个版本进行训练。 AI 平台将模型引用为特定机器学习管道的各种版本的容器。 模型可以包含管道的各种版本，并且特定版本可以由 API 调用。 一旦提供了模型版本，就应格式化需要发送到预测服务的数据，并将其提供给 API 调用进行预测。

可以通过两种方式请求预测，如下所示：

  • 在线预测：服务使用用于 API 调用的数据调用模型版本，并在响应中返回预测。 在后台，模型版本会在运行时部署在请求中指定的区域上。 平台可以缓存模型版本，该模型版本更常用于快速响应时间。
  • 批量预测：批量预测是一个异步服务调用，当用例需求是这样的需求：需要大量进行预测时，可以使用该异步服务，并且可以在服务提供预测时独立进行处理。 当请求批量预测时，预测服务会在 AI 平台上分配资源以运行作业。 这可能涉及一个或多个预测节点。 在每个分配的节点上还原模型图。 一旦分配了节点，输入数据就由主服务器分发以进行分布式预测。 每个单独的节点在请求预测服务时将预测数据存储在提到的云存储位置中。

在在线预测和批量预测的前提，可能的用例以及因此的存储和计算需求方面，存在根本的区别。 在线预测的目标是最小化预测服务的等待时间（响应时间），并将预测返回到响应的消息正文中。 另一方面，批量预测的目标是处理具有大型数据集和复杂模型的大量实例。 预测输出存储在 Cloud Storage 存储桶中，而不是在消息响应正文中发送。

在线预测通常可以用在处理实时数据的用例中，并且需要及时进行预测以使系统采取行动。 当预测需要对大量历史数据进行操作时，可以使用批量预测。 如果我们尝试使用批量预测模式运行较小的预测负载（数据量较小且算法简单），则与在线预测模型相比，它需要更长的时间。 这是由于以下事实：发送请求时完成了计算和存储资源的提供，并且优先级低于在线预测作业。 为特定用例选择正确的预测模式非常重要。

在创建用于在线预测的模型时，用户需要决定使用哪个区域来运行预测，并且必须决定是否启用在线预测日志记录。 启用日志记录对于故障排除或测试很有用。 但是，启用日志记录时会产生额外的费用。 在提出在线模型预测请求之前，需要先考虑这些成本。

应用开发人员还需要确定要使用的运行时版本，以及 Python 的版本和用于在线预测的机器类型。 可以根据数据量和模型的复杂性来确定机器类型。

可以为预测服务启用三个级别的日志记录，如下所示：

  • 访问日志记录：此日志记录有助于分析对预测服务的请求数，并跟踪请求开始和呈现时间的时间戳。 可以基于等待时间值以及预测服务的使用模式进行分析。
  • 流日志记录：标准错误和标准输出被写入 Stackdriver Logging。 仅出于调试目的，需要仔细启用此设置，否则可能会遇到高昂的成本。 仅在创建模型资源时才能启用此日志记录。
  • 请求-响应日志记录：此级别将在线预测请求和响应记录到 BigQuery 表中。

可以使用gcloud命令行以及 REST API 启用这些日志记录级别。 为了使用gcloud启用访问日志记录，需要传递--enable logging参数，如下所示：

gcloud ai-platform models create model_name --regions us-central1 --enable-logging

如以下代码块所示，需要传递--enable-console-logging参数以启用流日志记录：

gcloud ai-platform models create model_name --regions us-central1 --enable-console-logging

无法使用gcloud启用请求响应日志记录。 需要使用 REST API 启用它。 可以在创建模型和版本时设置日志记录级别。 projects.models.create 方法用于创建模型，并通过以下 HTTP URI 进行调用：

POST https://ml.googleapis.com/v1/{parent=projects/*}/models

父项是代表项目名称的必需的字符串 URL 参数。 为了成功验证请求，我们需要对项目具有ml.models.create Google 身份和访问管理（IAM）权限。 请求主体是模型对象的表示。 这是模型对象的示意图：

{
  "name": string,
  "description": string,
  "defaultVersion": {
    object (Version)
  },
  "regions": [
    string
  ],
  "onlinePredictionLogging": boolean,
  "onlinePredictionConsoleLogging": boolean,
  "labels": {
    string: string,
    ...
  },
  "etag": string
}

让我们看一下下表中的模型参数列表及其描述：

参数名称 类型 必填 说明
name 字符串 是 这是模型的名称。 模型名称在项目中必须唯一。
description 字符串 否 这是创建模型时的描述。
defaultVersion 目的 是 当未在请求内发送版本信息时，将使用该模型版本。 随着模型的发展，默认版本会不断变化并变得越来越有用。 可以使用projects.methods更改为模型版本。
regions[] 字符串数组 否 这是模型在其上部署的所有区域的列表。 这是为 AI 平台的将来版本提供的。 在撰写本章时，平台仅支持一个区域。 默认值为us-central1。
onlinePredictionLogging 布尔型 否 如果设置为true，则在线预测日志将发送到 StackDriver Logging。 这些日志类似于服务器访问日志，其中记录了所有请求的请求时间戳和响应时间。 默认情况下，此参数的值为false，需要将其显式设置为true。
onlinePredictionConsoleLogging 布尔型 否 如果设置为true，则在线预测日志将以更详细的方式发送到 StackDriver Logging，并包含标准输出以及标准错误日志消息的完整记录。 该日志对于调试很有帮助，但需要谨慎使用以节省成本。
labels 键值对映射 否 标签有助于组织 AI 平台上的各种资源。 这些标签是可以具有任意值的键值字符串。 带标签的资源易于监视和分组。 我们最多可以提供 64 个标签。 键和值最多可以包含 63 个字符。 键必须以字母开头，并且可以包含字母数字字符，下划线和破折号。
etag 字符串 是 该标志用于防止两个独立模型更新之间的竞争状况。 需要在各种请求和响应之间以链接的方式使用etag参数，以确保对模型进行顺序更新。 建议有效使用etag，以避免模型版本不一致。

除了创建模型之外，相同的请求主体对象还可用于以下函数：

  • delete：删除模型
  • get：获取有关模型的所有信息，包括版本
  • getIamPolicy：获取资源的访问控制策略
  • list：提供项目中存在的所有模型的列表
  • patch：更新模型资源
  • setIamPolicy：设置 AI 平台内特定资源的访问控制
  • testIamPermissions：列出调用用户帐户对特定资源拥有的所有权限

为了执行在线预测，需要以值列表形式或 JSON 对象的形式对输入数据进行结构化和格式化。 以下是可以在 AI 平台上传递给张量模型的输入张量的示例：

{"values":["one","two","three"], "key":123}

需要将该对象格式化为以下格式，才能发送到 REST API 端点：

{"instances": [
                       {"values": ["one","two","three"], "key": 1},
                       {"values": ["five","six","seven"], "key": 2}
]}

def predict(project, model, instances, version=None):

    GOOGLE_APPLICATION_CREDENTIALS=<path_to_service_account_file>
    service = googleapiclient.discovery.build('ml', 'v1')
    name = 'projects/{}/models/{}'.format(project, model)

    if version is not None:
        name += '/versions/{}'.format(version)

    response = service.projects().predict(
        name=name,
        body={'instances': instances}
    ).execute()

    if 'error' in response:
        raise RuntimeError(response['error'])

    return response['predictions']

如我们所见，可以通过使用对项目的引用来对 JSON 格式的输入结构化数据进行建模来获得在线预测。 我们使用googleapiclient创建机器学习服务的实例，并在服务实例上调用predict方法。

笔记本

The AI Platform provides an intuitive way of working with it in terms of notebooks. These are pre-packaged online interfaces that can be used for effective collaboration among team members and can be quickly configured to have the latest versions of Python libraries in the backend. The notebooks enable the developers to create and manage virtual machines on the GCP that can utilize TensorFlow and PyTorch frameworks, along with R and Python deep learning packages.

可以配置工作流和管道，以真正无服务器的方式利用 CPU 和 GPU。 笔记本电脑可以使用的图像经过测试和优化，以实现最佳表现和易用性。 GCP 的认证层用于访问笔记本，并且可以与任何其他 GCP 资源相同的方式配置 IAM 策略。 与 GCP 上托管的 GitHub 存储库无缝集成。

AI Platform 笔记本支持以下运行时和包：

图 8.9-AI 平台支持的运行时和包

为了在 AI 平台上使用笔记本，需要选择一个项目，并且需要启用 Compute Engine API 才能导航到笔记本页面。 让我们创建笔记本的新实例：

  1. 从导航菜单转到 AI 平台内的Notebooks笔记本菜单。
  2. 单击顶部菜单栏上的NEW INSTANCE链接。
  3. 从可用选项中选择用于创建实例，或单击“自定义实例”以对新实例的各种参数和容量进行精细控制。
  4. 选择具有或不具有 GPU 的实例。 如果实例是使用 GPU 创建的，请选择选项以自动安装 GPU 驱动。 创建实例后，可以在以后修改 GPU 计数。 以下屏幕快照描述了创建笔记本新实例的步骤：

图 8.10-创建新笔记本实例的步骤（1）

让我们使用不带 GPU 的 TensorFlow 2.0 创建一个新的笔记本实例。

  1. AI 平台分配默认实例名称。 可以根据用例上下文修改此名称。 建议使用日期时间戳作为实例名称，以提高可维护性。
  2. 环境：AI 平台使用带有英特尔®MKL-DNN 和 CUDA 10.0 的 TensorFlow 2.0 创建图像，并且默认情况下包括 Python 2/3，scikit-learn，pandas 和 NLTK。
  3. 机器配置：AI 平台使用默认区域（us-west1-b），具有 15 GB RAM 的 4 个 vCPU 和 100 GB 的启动磁盘创建机器。
  4. 联网：子网是默认设置（10.138.0.0/20）。
  5. 估计成本：AI 平台根据持续使用折扣提供估计成本。
  6. 单击“创建”按钮分配笔记本实例。

以下屏幕截图显示了使用 TensorFlow 2.0 而不使用 GPU 创建新笔记本实例的步骤：

图 8.11-创建新笔记本实例的步骤（2）

  1. 使用设定的配置创建笔记本后，您可以通过单击OPEN JUPYTERLAB超链接来打开 JupyterLab 界面，如以下屏幕截图所示：

图 8.12-打开 Jupyter 笔记本

数据标签服务

AI 平台提供了数据标注服务，该服务可以在人类标记者的帮助下轻松，高效地标注训练数据。 模型训练需要大量数据，有时无法获得人工为训练和评估数据加上标签的努力。 可以利用数据标签服务进行连续评估，这有助于基于一组新的输入数据来改进模型，以提高准确率。

使用数据标签服务的一般过程始于创建一个数据集，其中包含样本，这些样本将作为人类标签的指南。 与样本数据集一起，需要提供一个标注规范集，其中包含用例上下文中训练数据的所有可能的分类类别。 我们还可以向贴标机提供一组额外的说明，以进行实际的贴标。 一旦满足先决条件，就可以根据样本，标注规范集和说明生成服务请求，人工贴标人员可以导出训练数据以用于模型的训练和评估。

以下屏幕快照显示了使用数据标签服务的一般过程：

图 8.13-使用数据标记服务涉及的步骤

深度学习容器

这些容器提供了一个抽象的应用层，该层可以在各种环境中运行并且可以与基础操作系统无缝地协同工作。 这有助于开发人员专注于应用开发，因为所有依赖项均由容器管理，而与部署应用的环境无关。

AI 平台提供了一个现成的深度学习容器，其中包含关键的数据科学框架，库和工具。 AI 平台上的深度学习容器包含 TensorFlow，PyTorch，scikit-learn 和 R 框架，以及 Python 和 R 运行时。 容器中还包括最常用的 Python 包。

训练和利用 TensorFlow 模型涉及的步骤

在本部分中，我们将逐步介绍在 AI 平台上训练 TensorFlow 模型所涉及的所有步骤。 本地机器学习管道以及 AI 平台上的核心组件是相似的，因此，应用开发人员很容易利用熟悉的过程在 AI 平台上构建和部署模型。 以下屏幕截图中的流程图表示在 AI 平台上训练和使用 TensorFlow 模型的一般步骤：

图 8.14-在 AI 平台上训练和使用 TensorFlow 模型的通用步骤

先决条件

为了在 AI 平台上训练，部署和利用 TensorFlow 模型，我们需要考虑以下组件的成本：

  • AI 平台：训练/部署/预测
  • 云存储：用于训练/分段应用包/训练工件的输入数据

训练和部署 TensorFlow 模型的主要要求是创建一个项目。 创建项目并启用计费后，我们需要启用 AI 平台和 Compute Engine API。 此时，请安装云软件开发套件（SDK），并使用认证和授权对其进行初始化。

至此，完成了与平台相关的先决条件。 现在，我们需要为应用运行设置环境。

在 GCP 控制台中，单击顶部菜单栏上的“激活 Cloud Shell”按钮。 这将打开 Cloud Shell Web 界面。

这是我们需要从 Cloud Shell 采取的步骤：

  1. 列出 AI 平台上存在的所有模型。
  2. 更新 AI 平台上的所有组件。
  3. 安装或升级 TensorFlow。

您可以在控制台的以下屏幕截图中看到突出显示的上述步骤：

图 8.15-通过 GCP 控制台进行 AI 平台设置的要求

至此，环境设置完成。 现在，我们可以在本地开发和验证训练应用。 在云上运行该应用之前，建议在本地运行该应用以进行快速调试，并确保所有程序都能按预期工作。 在本地运行应用时，云资源不会产生任何费用。

创建一个 TensorFlow 应用并在本地运行

训练应用是根据开发人员的偏好和项目的上下文构造的。 但是，有一个推荐的项目结构，可以确保各个项目之间的一致性，并且不需要进行上下文开发人员训练。

项目结构推荐

让我们设置项目结构：

  1. 创建一个主项目目录，其中包含应用的所有代码。
  2. 在主项目目录中创建一个setup.py文件。 setup.py文件确保所有子目录都包含在用于应用分发的存档包中。 以下代码块显示了setup.py的典型实现：
from setuptools import setup, find_packages
import os

NAME = 'preprocessing'
VERSION = 'x.y'
REQUIRED_PACKAGES = [COMMA_SEPARATED LIST OF PACKAGES]

setup(
    name=NAME,
    version=VERSION,
    packages=find_packages(),
    install_requires=REQUIRED_PACKAGES, 
    )

  1. 创建一个名为trainer的子目录。 trainer目录包含应用模块代码，并且通常包含以下文件：

    • task.py：这是主要的应用模块，以及包含负责训练作业的编排的应用逻辑的文件。
    • model.py：这是包含模型逻辑以及模型的各种属性和配置参数的文件。

  2. 创建使应用模块化和逻辑可读的各种子目录。

  3. 建议在每个子目录中创建一个__init__.py文件。 通常，Setuptools将这些用作包装应用的标记。

  4. 当调用gcloud命令进行训练时，package-path参数设置为trainer目录。 运行时在父目录中搜索setup.py文件，并根据trainer目录中task.py和model.py文件中的代码训练模型。

训练数据

在此示例中，我们将使用人口普查收入数据，它是公共可用的数据集之一。 这是数据集的特征：

  • 摘要：基于 14 个属性的数据集，用于预测一个人的收入是低于还是大于 50,000 美元。
  • 类型：多变量。
  • 实例数量：48,842。
  • 领域：社交。
  • 属性类型：类别/整数。

让我们继续进行模型训练。

  1. 在以下命令的帮助下，打开 Cloud Shell 并下载示例代码：
wget https://github.com/GoogleCloudPlatform/cloudml-samples/archive/master.zip
unzip master.zip
cd cloudml-samples-master/census/estimator
  1. 在以下命令的帮助下获取训练数据：
mkdir data
gsutil -m cp gs://cloud-samples-data/ai-platform/census/data/* data/
TRAIN_DATA=$(pwd)/data/adult.data.csv
EVAL_DATA=$(pwd)/data/adult.test.csv

  1. 创建用于存储模型和中间文件的输出目录。

  2. 为了在本地运行模型，我们需要使用以下命令：

gcloud ai-platform local train \
    --module-name trainer.task \
    --package-path trainer/ \
    --job-dir $MODEL_DIR \
    -- \
    --train-files $TRAIN_DATA \
    --eval-files $EVAL_DATA \
    --train-steps 1000 \
    --eval-steps 100

这是模型输出目录的屏幕截图：

图 8.16-模型输出目录

训练和评估模型后，即可使用 TensorBoard 分析各种模型训练参数。 TensorBoard 是 TensorFlow 打包的可视化工具包。 它有助于在模型图中可视化和分析损失和准确率。 以下命令用于将 TensorBoard 作为 Web 应用启动（默认在端口8080上）：

tensorboard --logdir=$MODEL_DIR --port=8080

前面的命令将返回以下输出。 我们来看一下：

图 8.17 使用 TensorBoard 的模型视图

正如我们从前面的屏幕截图中可以看到的那样，TensorBoard 可以通过直观的可视化工具轻松分析模型表现。

在下一部分中，让我们看一下打包和部署训练应用所涉及的步骤。

在 Cloud ML Engine 中打包和部署您的训练应用

重要的是要了解在 ML Engine 中打包和部署应用的正确方法。 在本节中，我们将讨论机器学习应用的打包和部署中的一些推荐方法和最佳实践。 我们可以使用gcloud命令行工具来打包和上传应用。 最简单的方法是使用以下命令进行打包以及上载应用，同时提交训练作业：

gcloud ai-platform jobs submit training

让我们定义打包和部署应用所需的全局环境变量，如下所示：

  • PATH_TRAINER_PACKAGE：训练作业所需的所有源代码文件的标准路径。
  • TRAINER_MODULE：这是.task文件的名称，该文件代表主应用模块，并且该文件包含负责训练作业的编排的应用逻辑。
  • STAGING_BUCKET：这是训练作业运行时用于存储中间结果和临时文件的 Google 存储空间上的路径。

除了这些之外，我们需要设置变量以表示作业名称，作业目录和区域。 作业名称可用于跟踪与作业相关的数据和沿袭点； 作业目录存储训练作业的中间结果和最终结果； 并且需要该区域在适当的位置运行训练工作，以优化计算和存储成本并最小化开销。

这是一个使用gcloud ai-platform命令负责打包和部署应用的命令：

gcloud ai-platform jobs submit training $JOB_NAME \
    --staging-bucket $STAGING_BUCKET \
    --job-dir $JOB_DIR \
    --package-path $PATH_TRAINER_PACKAGE \
    --module-name $TRAINER_MODULE \
    --region $REGION \
    -- \
    --user_first_arg=first_arg_value \
    --user_second_arg=second_arg_value

除了运行命令的必需参数之外，我们还可以将许多用户定义的和应用特定的参数传递给此脚本。 参数值可用于运行时和特定于应用的逻辑的实现。

训练作业还可能需要一些依赖关系才能成功运行训练作业。 有两种类型的依赖关系需要解决：

  • 标准 Python 依赖项：这些是 PyPI 上可用的标准 Python 包。 AI 平台通过pip install命令安装了标准依赖项。 这类似于独立应用的依赖项解析。 定义 AI 平台上的依赖项的标准方法是提及setup.py文件中的依赖项。 setup.py文件需要放置在应用的根目录中。 在以下代码片段中可以看到setup.py文件的模板：
from setuptools import find_packages
from setuptools import setup

REQUIRED_PACKAGES = ['comma separated list of required packages']
setup(
    name='trainer',
    version='0.1',
    install_requires=REQUIRED_PACKAGES,
    packages=find_packages(),
    include_package_data=True,
    description='Setup details and required packages for the training application'
)
  • 用户定义和自定义依赖项：这些是应用在运行时所需的用户定义包。 AI 平台可以使用pip install命令解决这些依赖性。 定制依赖项包需要在运行时可供应用访问，因此，需要提供该包的标准 URI 作为脚本的参数。 建议将包文件存储在可访问的 Cloud Storage 位置。 使用gcloud命令时，依赖项可以放在本地计算机上，也可以放在 Cloud Storage 上。 AI 平台按照它们在命令中出现的顺序对这些依赖项进行分级。 需要将多个依赖项指定为以逗号分隔的列表。

在下一节中，我们将学习如何通过选择正确的计算选项和运行时参数来优化训练工作。

为您的训练工作选择正确的计算选项

重要的是为训练工作选择正确的计算选项，以便最佳利用平台资源。 这导致训练时间和成本最小化。 我们需要为训练作业设置运行时属性。 训练工作是 AI 平台上的标准对象。 训练工作的结构如下（输入参数以粗体字体突出显示，请在此链接中找到完整的配置：

{
  "jobId": string, //Required: user defined identifier for the job
  "createTime": string,          //Output Parameter: indicates when a job was created 
  "labels": {                    //Optional Input Parameter: recommended to be used for organizing 
    string: string,              //and troubleshooting the run-time jobs.   
    ...
  },
 "trainingInput": { //Required: specifies the input parameters for the training job.  
 object (TrainingInput)
 },
  "predictionInput": {           //Required: specifies the input parameters for the prediction job. 
 object (PredictionInput)
 }
}

具体来说，我们需要为运行时作业配置填充TrainingInput或PredictionInput资源。 这些对于特定请求是互斥的，并且在运行时仅需要使用这些输入参数之一。 让我们详细查看TrainingInput参数的以下 JSON 结构（请在此链接中找到完整的配置）：

{
  "scaleTier": enum (ScaleTier),    //Required: specifies machine types, count of replicas, workers,parameter servers
  "packageUris": [                 //Required: These are the Google Cloud Storage locations for
    string                         // the packages containing the training program along with
  ],                               //          additional dependencies
  "pythonModule": string,          //Required: The python module to run after importing all the 
  "args": [                        //packages and resolving the dependencies 
    string
  ],
  "hyperparameters": {             //Optional: The set of hyper-parameters to be tuned. 
    object (HyperparameterSpec)
  },
  "region": string,               //Required: The compute engine region on which the training job will run
}

我们将详细研究ScaleTier和HyperParameterSpec对象。 在此之前，让我们了解在提交预测作业时使用的PredictionInput对象的 JSON 结构，如以下代码块所示：

{
  "dataFormat": enum (DataFormat),        //Required: Format of the input data file (JSON, TEXT, etc.)    
  "outputDataFormat": enum (DataFormat),  //Optional: Format of the output data file (default-JSON)
  "inputPaths": [                         //Required: Cloud storage location of input data files
    string
  ],
  "maxWorkerCount": string,               //Optional: Maximum number of workers (default-10)
  "region": string,                       //Required: Google Compute Engine region
  "runtimeVersion": string,               //Optional: AI Platform run-time version
  "batchSize": string,                    //Optional: Number of records per batch (default-64)
  "signatureName": string,                //Optional: Name of signature defined in the saved model
  "modelName": string,                    
  "versionName": string,
  "uri": string
  "outputPath": string
}

选择正确的参数后，可以极大地优化训练和预测表现。 我们需要了解各种规模的层和超参数，以进一步优化表现和成本。 根据训练数据的数量和算法的复杂性，选择合适的比例尺等级很重要。 想法是仅使用适当数量的资源进行训练和预测。 这有助于最小化训练单元的成本。 根据需要，高级层在 CPU 内核数和 GPU 利用率方面具有额外的容量。 但是，随着等级的提高，成本也会增加。 GCP 上有各种可用的规模级别，如下所示：

  • BASIC：提供单个工作程序实例，适合于学习和实验。 这也可以用于小尺寸的概念证明（POC）。
  • STANDARD_1：提供多个工作程序节点和仅几个参数服务器。
  • PREMIUM_1：为大量工作器提供许多参数服务器。
  • BASIC_GPU：为单个工作程序实例提供 GPU。
  • CUSTOM：此层允许设置主服务器类型，工作程序计数，参数服务器计数和参数服务器类型的自定义值。 选择CUSTOM标度等级时，TrainingInput中的这些参数成为必需参数。

除了比例等级之外，我们还需要仔细选择超参数值，以进一步优化训练效果。

为训练工作选择超参数

通过TrainingInput对象中的HyperparameterSpec对象控制超参数。 以下代码块显示了HyperParameterSpec对象的结构：

{
  "goal": enum (GoalType),            //Required: The type of goal used for tuning [MAXIMIZE/MINIMIZE]
  "params": [                         //Required: The set of parameters to be tuned
    {
      object (ParameterSpec)
    }
  ],
  "maxTrials": number,               //Optional: Number of trials to be attempted (default-1)
  "maxParallelTrials": number,       //Optional: Number of parallel trials. May reduce quality of                                              //          optimization
  "maxFailedTrials": number,         //Optional: Number of failed trials before the hyper parameter tuning                                      //          job is failed
  "hyperparameterMetricTag": string, //Optional: TensorFlow summary tag name for optimizing trials. 
  "resumePreviousJobId": string,     
  "enableTrialEarlyStopping": boolean,
  "algorithm": enum (Algorithm)      //Optional: Search algorithm used by the hyper parameter tuning job
}                                    //          ALGORITHM_UNSPECIFIED / GRID_SEARCH / RANDOM_SEARCH

虽然成本是选择计算资源时的基本考虑因素之一，但我们还需要了解，平台对训练资源的使用存在一些限制，这些限制由各种操作的配额设置。 让我们简要地看一下 AI 平台施加的配额限制。

由于多租户云平台的固有性质，特定用户和项目所使用的资源需要受到配额的限制和控制，以防止错误地过度使用资源。 AI 平台还根据服务请求强加了一些配额限制。 分配给项目的任何用户帐户每分钟只能发起一定数量的单个 API 请求。 该限制适用于特定的 API 或一组 API，如下所示：

  • 作业创建请求：1 分钟内最多可以发出 60 个请求。
  • 预测请求：1 分钟内最多可以提出 6,000 个请求。
  • 以下用于资源管理的子 API 的请求总数：每分钟最多 300 个请求：
    • list/get（projects.jobs，projects.model秒，projects.models.versions，projects.operations）
    • delete/create（projects.models，projects.models。versions）
    • cancel（projects.jobs，projects.operations）
    • setDefault

除服务请求外，每个项目最多有 100 个模型，每个模型最多可以有 200 个版本。

在某些情况下，无法创建具有这些限制的 AI 应用的生产版本。 GCP 允许通过管理控制台请求增加配额。 此外，AI 平台还限制了虚拟机的并发使用次数，如下所示：

  • 并发预测节点数：72
  • 预测节点中运行的并发 vCPU 数量：450

用于训练的 GPU 的限制如下：

GPU 类型 并行 GCP（训练） 并行 GPU（预测）
Tesla K80 30 30
Tesla P4 8 2
Tesla P100 30 30
Tesla V100 8 8
Tesla T4 6 6

我们需要从可用选项中仔细选择，以优化表现和成本。 在下一节中，我们将研究如何在 GCP 上监视 TensorFlow 模型作业。

监控您的 TensorFlow 训练模型作业

模型训练工作所需的时间与训练数据量和训练模型的复杂度成比例。 应用必须能够报告训练工作的状态。 AI 平台提供了三种主要方法来监视训练工作。 GCP 控制台提供了用于列出训练作业的用户界面。 gcloud CLI 和自定义 Python 代码可用于获取训练作业的状态。

以下是用于监视训练作业的gcloud命令：

gcloud ai-platform jobs describe job_name

该命令返回当前正在运行的作业的状态，由job_name参数指示，如下所示：

gcloud ai-platform jobs list --limit=5

此命令返回项目平台上当前正在运行的所有作业的列表。

总结

在本章中，我们已经了解了如何借助 Cloud ML Engine（AI 平台）在 GCP 上利用无服务器机器学习。 我们已经看到了访问 AI 平台的各种方法，以及构建 TensorFlow 应用以及打包和部署模型的方法。 我们还研究了在 AI 平台上组织应用，通过使用正确级别的基础架构来优化表现，同时节省成本的最佳实践。 最后，我们学习了如何使用命令行工具监视应用。

在下一章中，我们将使用 TensorFlow 模型构建预测应用，并在 GCP 上采用实用的方法进行 AI 应用开发。

九、构建预测应用

云中的预测是关于开发预测机器学习模型，部署机器学习模型的最终版本，以及使用该部署模型使用云原生服务或基础架构从新到达的数据中预测目标值。 简而言之，云管理着基础架构和机器学习框架的高层抽象，可以轻松地用于训练或使用您的机器学习模型。

与其他任何云提供商一样，Google Cloud 还提供了使用其本机服务运行基于机器学习的模型预测的功能。 在本章中，我们将研究使用 Google Cloud 服务执行预测所涉及的一些步骤，如下所示：

  • 基于机器的智能预测概述
  • 维护模型及其版本
  • 深入研究已保存的模型
  • 在 Google Cloud Platform（GCP）上部署模型
  • 模型训练实例
  • 使用服务端点执行预测

基于机器的智能预测概述

预测分析是大数据的推动力：组织收集大量的实时客户数据，并且预测分析使用此历史数据结合消费者的直觉来预测未来事件。 预测分析使组织可以使用数据（历史数据和实时数据）从历史角度转换为客户的前瞻性角度。 预测分析使公司能够变得前瞻性和前瞻性，预测基于数据的结果和行动，而不是假设。

规范性分析是建议采取行动以利用预测并提供决策选择的下一步骤，以从预测及其后果中受益。 可以使用部署在云上的服务进行预测。 这些服务可以作为易于使用的 API 公开，并且使分析人员可以轻松使用预测服务，而无需完全了解基础算法的细节。 GCP 组件使您可以更轻松地构建，部署和利用预测服务，而所需的精力和成本却更少。

了解预测过程

下图描述了在 GCP 上使用预测所涉及的高级步骤（这些步骤将在以下段落和章节中详细说明）：

图 9.1：在 GCP 上使用预测的步骤

开始预测过程的第一步是在完成模型训练后将模型导出为工件。 您需要将合格的机器学习模型导出为一个或多个工件，以实现来自 Google Cloud AI 平台的预测。 本章将说明如何在 GCP 上导出合格的 AI 系统预测模型。 根据用于构建模型的机器学习框架的类型，有多种选项可以导出模型。 例如，如果您已使用 TensorFlow 训练机器学习模型，则可以先使用tf.save_model API 保存模型，然后再使用 Google Cloud AI Platform 导出模型。

下一步是部署模型。 Google Cloud AI 平台将托管模型，为您提供云预测。 模型部署是用于托管已保存模型文件的方法。 云预测供应商可以处理您的模型基础架构，并可以接受在线和批量预测的请求。 模型部署是预测过程中最重要的方面，必须对其进行详细了解。 在下一部分中，我们将详细介绍模型部署方面。

部署模型后，就可以将模型用于在线预测或批量预测。 如果您想一次为一组观测值生成预测，然后对一定数量或一定百分比的观测值采取行动，则批量预测很有用。 通常，对于这样的请求，您没有低延迟要求。 这些预测然后存储在数据库中，开发人员或最终用户可以访问。 批量推断有时可以使用大数据技术（例如 Spark）来生成预测。

批量推理技术规范比在线推理更简单。 例如，数据科学家可以简单地在执行批量推断的机器上反序列化经过训练的模型，而无需通过表述性状态转移（REST）API 公开经过训练的模型。 批量推断期间所做的预测也可以在最终利益相关者看到之前进行分析和处理。 下图显示了批量预测的工作原理：

图 9.2：批量预测

在线预测是根据请求实时创建用于机器学习的预测的方法。 这也称为实时或动态推理。 这些预测通常由运行时的单个数据观察生成。 在线推论预测可以在一天中的任何时间产生。 在线推论使我们能够实时使用机器模型。 它开辟了一个可以利用机器学习的全新技术领域。 无需等待数小时或数天的批量预测，我们可以在需要时立即生成预测，并立即提供服务。

在线推论还有助于我们快速分析新数据，而不会产生延迟。 通常，在线推理比批量推理更具挑战性。 由于添加了满足延迟要求所需的工具和系统，因此在线推理往往更加复杂。 与需要 24 小时服务级别协议（SLA）的系统相比，需要在几毫秒内执行预测的程序要困难得多。 下图显示了在线预测的工作方式：

图 9.3：在线预测

如果使用简单模型和少量输入案例，则完成在线预测和针对类似预防请求的批量分析所花费的时间将大大不同。 完成在线应用几乎立即返回的预测可能需要很长时间。 两种预测方法中使用的特定基础结构都有副作用。 提交订单后，AI 平台将分配并初始化批量预测资源。

通常，可以根据要求准备在线预测。 下表总结了在线预测和批量预测之间的区别。

批量预测 在线预测
适用于具有复杂计算要求的海量大数据量。 适用于一次记录，具有低延迟和较简单的模型。
输出是具有多个预测结果的文件格式。 输出一次是一个响应，大多数为 JSON 格式。
异步请求和响应。 同步实时请求和响应。
它可以使用存储在某些外部存储（例如 Google Cloud 存储桶）中的模型，也可以使用通过 Google Cloud AI 平台进行部署的模型。 它只能使用通过 Google Cloud AI 平台部署的模型。
仅当使用通过 Google Cloud AI 平台部署的模型时，才对某些实例类型进行有限使用。 可以使用不同类型的计算实例进行运行预测。

维护模型及其版本

Google Cloud AI 平台可让您将机器学习解决方案组织为模型和版本。 模型是为您的机器学习解决方案提供的名称，该版本唯一地将部署的模型标识为工件。 例如，您可以创建一个名为ProductCategoryIdentification的模型，该模型表示用于对产品进行分类的机器学习解决方案。 在机器学习中，模型是要解决的问题的解决方案。

换句话说，这是预测数据值的方法。 模型是 Google Cloud AI 平台上此 AI /机器学习解决方案的每次迭代的概念容器。 例如，要解决的问题是在给定与先前销售相关的一组数据的情况下，预测房屋的销售价格。 您构建一个称为房屋价格的 AI 应用模型，并尝试通过几种机器学习技术来解决问题。 您可以在每个级别上部署该模型的版本。 该版本可以与其他版本完全不同，但是如果适合您的工作流程，则可以将其布置在同一模型下。

以下屏幕快照表示如何在 Google Cloud AI 平台上创建模型：

图 9.4：创建新模型

如您所见，模型创建用户界面与用户熟悉的 GCP 上的其他服务一致。 我们需要提供区分大小写的模型名称和区域作为强制属性。 建议提供可选描述，以提高模型的可维护性。 当我们针对各种用例构建和部署大量模型时，这一点尤其重要。 以下屏幕快照显示了平台上可通过用户界面或 API 使用的模型的列表：

图 9.5：模型清单

现在，在创建模型之后，您可以创建它的版本。 一个版本表示用来训练模型的机器学习代码和框架。 有时，数据科学家使用不同的框架（例如 XGBoost 或 TensorFlow）来设计针对同一问题的解决方案。 他们创建不同的版本来识别工件。 因此，模型版本或仅一个版本是存储在 AI 平台模型服务中的机器学习解决方案的实例。 您可以通过将经过训练的串行模型（作为保存的模型）传输到服务来制作版本。 您还可以提供自定义代码（在撰写本文时仍处于 beta 阶段），以在制作版本时管理预测。

至少具有一个版本的每个模型都有一个默认版本。 生成第一个版本时，将设置默认值。 如果您请求仅指定模型名称的预测，则 AI 平台将使用该模型的默认版本。

以下屏幕截图显示了如何管理版本：

图 9.6：创建模型版本

命名模型和版本的一些规则如下：

  • 名称应仅包含字母（大小写混合），数字和下划线。
  • 名称应以字母开头。
  • 名称最多可包含 128 个字符。
  • 该名称在项目中应该是唯一的（如果它是模型名称），在模型中应该是唯一的（如果它是版本名称）。

您还可以添加自定义内置代码所需的自定义包，如以下屏幕截图所示：

图 9.7：添加自定义代码和包

最终的输出屏幕将类似于以下屏幕截图中的屏幕：

图 9.8：模型版本

优良作法是，模型名称应简洁明了，因为您需要从多个名称列表中的日志或报告中选择它们。 简短的版本名称最适合维护。

深入研究已保存的模型

您需要将合格的机器学习模型导出（或保存）为一个或多个对象，以便执行 Google Cloud AI Platform 预测。 本部分介绍了导出用于 AI 系统预测部署的合格模型的各种方法。 根据您使用的机器学习平台的类型，Google Cloud AI 平台为您提供多种导出这些模型的方法。 这些方法特定于用于训练模型的框架。 我们将在本节中介绍 TensorFlow 保存的模型的某些方面。 您必须首先以 TensorFlow SavedModel 的格式将训练有素的模型导出到 Google Cloud AI 平台，以支持预测。

保存的 TensorFlow 模型实际上包含具有权重和计算的 TensorFlow 程序。 它不是指向用于构建模型的代码，而是指向使用派生的数学参数进行预测所需的代码。 TensorFlow 被称为 SavedModel，是在 Google Cloud AI 平台中部署经过训练的模型的推荐格式。 建议导出 TensorFlow SavedModel。

导出训练有素的 SavedModel 模型会将训练图保存为 Google Cloud AI Platform 特定的格式，可使用其元数据将其用于预测并还原。 SavedModel 提供了一种与语言无关的格式，用于保存可恢复且密封的机器学习模型。 它有助于更​​高级别的系统和资源生成，使用和处理 TensorFlow 模型。 以下是 SavedModel 的一些重要功能：

  • 可以使用单个变量和资产将单个 SavedModel 添加到多个图。 每个图都连接到一组标签，以便在加载或还原时进行标识。 图以协议缓冲区格式存储。

  • SavedModel 支持 SignatureDef（协议缓冲区消息的技术名称）。 SavedModel 使用此功能为与图存储的签名提供支持。 这些用于机器学习预测工作的图通常包含一堆数据输入和数据输出，称为签名。 签名具有以下结构：

  • inputs：用于训练 TensorFlow 模型的相应数据输入存储了字符串映射列表。

  • outputs：用于训练 TensorFlow 模型的相应数据输出存储了字符串映射列表。

  • method_name：在 TensorFlow 框架中使用的受支持的命名方法。

  • SavedModel 也支持资产。 如果操作依赖于外部初始化文件（例如词汇表），则 SavedModel 将使用资产。 资产被复制到 SavedModel 目录，并在加载特定的元图定义时读取。

  • 在生成 SavedModel 之前，它支持清除设备。

如上一节所述，尽管 SavedModels 支持某些重要功能，但不支持其他功能。 这些如下：

  • 它不支持隐式版本控制。
  • 它本身不支持垃圾收集。 使用这些模型的外部工具可能对此提供支持。
  • 它不支持对 TensorFlow SavedModels 的原子写入。

SavedModel 目录具有以下结构：

assets/
assets.extra/
variables/
    variables.data-?????-of-?????
    variables.index
saved_model.pb

saved_model.pb或saved_model.pbtxt文件是协议缓冲区文件，其中包括所有图定义作为 MetaGraphDef 协议缓冲区消息。 assets子文件夹包含支持的辅助文件，例如文本词汇文件。 assets.extra子文件夹包含可以与模型共存的用户添加的资产，但是不会在运行时加载。 用户或最终开发人员必须自己管理它，因为 TensorFlow 库不管理它。 variables子文件夹包含 TensorFlow 库 TensorFlow 保护程序的输出。

TensorFlow SavedModel 中的 SignatureDef

SignatureDef 确定 TensorFlow 图辅助计算的签名。 SignatureDefs 旨在为定义函数的输入和输出提供通用支持。 TF-Exporter 和 SessionBundle 使用的签名在概念上相似，但是允许用户区分命名签名和默认签名，以便在加载时可以正确检索它们。 对于以前使用 TF-Exporter / SessionBundle 的用户，TF-Exporter 中的签名将由 SavedModel 中的 SignatureDefs 替换。 TensorFlow Serving 提供高级 API 进行演绎。 要允许这些 API，模型应包含一个或多个 SignatureDef，它们描述了用于输入和输出的确切 TensorFlow 节点。 请参阅以下针对每个 API 支持 TensorFlow Serving 的 SignatureDef 示例。

分类 SignatureDefs 支持对 TensorFlow Serving 的分类 API 的标准化调用。 这些指定应该有一个 Tensor 输入，并且有两个可能的 Tensor 输出：类和等级，至少需要存在一个。 以下屏幕快照显示了分类 SignatureDefs 的结构：

图 9.9：分类消息 API 有效负载

预测 SignatureDefs 支持对 TensorFlow Serving 的 Predict API 的调用。 这样的签名使您可以任意支持多个输入和输出张量。 对于以下示例，我的预测签名具有特定的逻辑张量图像，该图像在您的图x:0中映射到实际张量。 预测 SignatureDefs 允许模型到模型的可移植性。 这意味着您可以在不同的 SavedModels 中处理不同的基础 Tensor 名称（例如，您可能具有张量Z:0而不是x:0的替代模型），因此您的客户将继续在网络上测试新旧模型，而不会改变客户方面。 预测 SignatureDefs 允许您向输出中添加其他张量，您可以显式请求这些张量。 假设除了scores下面的输出键之外，您还希望获取堆层用于调试或其他目的。 在这种情况下，只需添加带有池密钥和适当值的附加张量即可。 以下屏幕截图显示了预测 SignatureDefs 的结构：

图 9.10：分类 API 响应

回归 SignatureDefs 支持对 TensorFlow 服务回归 API 的结构化调用，该 API 恰好需要一个张量输入和一个张量输出。 以下屏幕截图显示了回归 SignatureDefs 的结构：

图 9.11：回归 SignatureDef 的结构

TensorFlow SavedModel API

如下图所示，TensorFlow SavedModel 有两个主要的 API。 一个是 Builder API，另一个是 Loader API。 一旦 Loader API 加载了 SavedModel，它将用于预测：

图 9.12：Tensorflow SavedModel API

SavedModelBuilder类提供了多个要保存的元图定义，相关变量和属性。 必须使用变量保存第一个元图，以便构建 SavedModel。 以下元图及其图说明易于保存。 当必须保存属性并将其写入或复制到磁盘时，可以在插入元语法定义时提供属性。 如果将多个元图定义连接到同名资产，则仅保留第一个版本。 每个 SavedModel 元图必须用反映元图功能和特定于案例的用户标签的标签标注。

这样的标签通常包括带有其属性（例如，服务或训练）以及可能的硬件特定方面（例如 GPU）的元图。 SavedModel 中的定义元图的标记集与 Loader API 中的标记集完全匹配，是加载程序加载的图元。 如果没有定义元图与列出的标签匹配，将返回错误。 例如，需要 GPU 服务的加载程序可以通过在tensorflow::LoadSavedModel(...)中指定标签来仅加载带有tags=serve（GPU）标注的元图。 以下屏幕快照中的代码表示如何使用 Builder API：

图 9.13：API Builder 代码

使用 SavedModelBuilder 包，用户可以测试在添加 SavedModel 包元图时是否必须从 NodeDefs 中删除默认评估的属性。 SavedModelBuilder.add元语法和变量以及SavedModelbuilder.add元图都接受控制此行为的带状默认属性boolean标志。 通过将条带默认属性设置为True，模型创建者可以删除 NodeDefs 中任何具有值的默认属性。 这有助于确保具有默认值的新属性不会导致较旧的模型使用者无法加载已使用新训练二进制文件重新生成的模型。

加载程序 API 用 C++ 和 Python 实现。 Python 的 SavedModel 加载程序版本包含 SavedModel 加载和还原功能。 加载功能包括用于恢复图形描述和变量的会话，用于定义默认加载元图的标签以及 SavedModel 的位置。 特定元图定义中提供的变量和资产的子集将还原到加载时提供的会话。 加载程序 API 的代表性 Python 代码如下所示：

图 9.14：API 加载程序代码

C++ 的 SavedModel 加载器版本提供了一个 API，用于从路径加载 SavedModel，允许使用SessionOptions和RunOptions。 与 Python 版本相比，C++ 版本需要加载和定义与图关联的标签。 加载的此版本 SavedModel 称为 SavedModelBundle，其中包括定义元图和加载会话。 Loader API 的代表性 C++ 代码如下所示：

图 9.15：Loader API 代码的 C++ 实现

SavedModel 为构建和加载用于各种应用的 TensorFlow 图提供了灵活性。 SavedModel API 提供了许多 Python 和 C++ 常量，这些常量易于使用，并且在针对最常见的预期应用的工具之间始终保持共享。

在 GCP 上部署模型

要在导出机器学习模型后对其进行部署，则必须部署导出的模型。 部署模型的第一步是将它们存储在 Google Cloud Storage 存储桶中。 通常，专用的云存储分区更易于用于 Google Cloud AI 平台的同一项目。 如果您使用其他项目中的存储桶，则需要确保可以访问 Google Cloud AI Platform 服务帐户中的云存储模型。 没有必需的权限，您尝试构建 Google Cloud AI Platform 模型版本的尝试将失败。

让我们开始研究如何创建 Google Cloud Storage 存储桶。 可以使用现有存储桶，但它必须位于您计划在 Google Cloud AI 平台上工作的同一区域。 以下代码可以帮助您创建新的存储桶：

BUCKET_NAME="google_cloud_ai_platform_your_bucket_name"
PROJECT_ID=$(gcloud config list project --format "value(core.project)")
BUCKET_NAME=${PROJECT_ID}-mlengine
echo $BUCKET_NAME
REGION=us-east2
gsutil mb -l $REGION gs://$BUCKET_NAME

前面的代码指定您的新存储桶名称。 它定义了创建存储桶所需的项目 ID。 然后，您指定要在其中创建存储桶的区域的名称。 最后，使用gsutil 命令行界面（CLI）创建存储桶。

可以在以下链接中找到对gsutil工具的完整引用。

以下屏幕截图提供了有关如何使用控制台 UI 创建存储桶的指南：

图 9.16：GCP 控制台–存储和浏览

从控制台菜单中，我们需要导航到“存储”部分，然后单击“浏览器”部分以找到存储在存储桶中的所有数据文件。 如果用户帐户有权创建多区域存储桶，则使用此控制台 UI 可以在一处看到跨区域存储桶的所有数据文件，如以下屏幕快照所示：

图 9.17：存储桶列表

GCP 控制台提供了一个轻松的界面来创建新的存储桶。 这是我们单击CREATE BUCKET按钮时打开的初始页面的屏幕截图：

图 9.18：创建新存储桶

我们需要为该存储桶提供一个在整个项目中唯一的名称。 此外，我们需要提供区域和默认存储类，并在 GCP 中创建存储桶时定义访问级别（可以访问存储桶的用户组和用户）。 提供详细信息后，GCP 提供了一个简单的界面来查看每月成本估计，以获取并保存正在创建的存储桶中的数据。 这有助于在创建存储桶时根据用例和应用的上下文选择适当的选项。 如果配置不正确，GCP 可以轻松避免可能导致高成本的错误。

将已保存的模型上传到 Google Cloud Storage 存储桶

下一步是将模型上传到 Google Cloud Storage 存储桶。 如果您正在使用 Tensorflow SavedModels，则可以使用以下代码上传模型：

SAVED_MODEL_DIR=$(ls ./your-export-dir-base | tail -1)
gsutil cp -r $SAVED_MODEL_DIR gs://your-bucket

如果您从tf.keras或 TensorFlow 估计器导出 SavedModel，则所选导出目录的子目录将另存为带有时间戳的代码目录/ 123201202301。 本示例说明如何使用当前时间戳更新目录。 如果您以其他方式构建了 SavedModel，则可以将其放置在本地文件系统上的其他位置。

如果您已使用 scikit-learn 或 XGBoost 导出了模型，则可以使用以下代码以.joblib，*.pk1或*.bst格式导出模型：

gsutil cp ./model.joblib gs://your-bucket/model.joblib

gsutil cp ./model.pkl gs://your-bucket/model.pkl

gsutil cp ./model.bst gs://your-bucket/model.bst

如果您具有自定义的预测例程（测试版），则还可以将一些其他示例对象上载到应用目录。 如果您使用的是旧版计算机（MLS1）类型，则配置目录的最小文件大小必须为 500 MB 或更小；如果使用的是 Compute Engine（N1）类型的计算机（beta），则配置目录的最小文件大小必须为 2 GB 或更小。 在构建模式的后续迭代时，请将其存储在云存储桶中的单独目录中。 如果您部署带有自定义代码或自定义预测例程的 Science Learning 管道，则还必须上传包含自定义代码的源交付包。 您可以将以下代码用于相同的代码：

gsutil cp dist/google_cloud_ai_custom_code-1.0.tar.gz gs://ai-ml-bucket/google_cloud_ai_custom_code-1.0.tar.gz

测试机器学习模型

下一步是测试机器学习模型。 机器学习领域提供了一些工具，可以根据数据自动做出决策，以实现某些目标或要求。 手动指定的解决方案会遇到一些问题。 机器学习很重要，因为它为复杂的问题提供了解决方案。 与手动指定的解决方案相比，机器学习可为您提供自动，更快，更精确的问题解决方案。 机器学习应用并非 100% 准确，并且永远不会部分正确。 关于测试人员为何不能忽略对计算机教育和深度学习的思考，有多种解释。 主要原因是这些程序从用于构造算法的数据中学习。 由于机器学习应用几乎每天都在处理人类活动，因此错误可能导致严重的损失。 代替这些事实，机器学习模型测试非常重要。

测试机器学习解决方案涉及多个方面。 这样的方面之一是确保用于训练的数据的质量。 您对训练的测试应确保没有可以歪曲结果的数据集。 训练数据的质量保证（QA）创建检查协议，以验证用于训练的数据是否已被消毒。 还必须执行检查以确定是否意外或故意发生了数据中毒攻击。 与数据统计有关的测试（中位数，平均值，样式等）描述了高级数据和关系。 您应该使用脚本创建测试以检查统计信息和相关性。 这些测试应定期进行。 必须定期跟踪列出的参数，并在每次发布之前进行验证。

您还应该针对机器学习模型训练中使用的特征执行测试。 多次，一个或多个特征是冗余/不相关的，实际上会影响预测错误率。 需要采用质量保证/测试程序来主动确定设计技术，例如降低尺寸和选择特征。

最后但并非最不重要的一点是，您还应该确保模型训练算法的质量。 不断发展的数据集可能会由于数据中毒攻击而导致预览错误级别增加。 随着机器学习模型的重新训练，增加的预测错误率意味着机器学习模型将被重新估值，以检测新算法，而现有算法的准确率更高。 重新训练所有模型，并使用新的数据集定期跟踪模型输出。 如果另一个模型比现有模型更可靠或更成功，则会引发缺陷。

您可以在 Google Cloud AI Platform 预测中使用本地predict命令检查模型的预测方式，然后再使用它。 该命令使用本地依赖性来预测并以与执行在线预测后的 Google Cloud AI 平台相同的格式返回结果。 测试本地预测将使您能够在计算在线预测请求成本之前发现错误。 对于--model-dir语句，您可以定义一个目录，并将您的机器学习模型导出到本地计算机或云存储中。 另外，为--framework参数指定tensorflow，sklearn或xgboost。 您不能将本地预测命令 Google Cloud AI Platform 与自定义预测例程一起使用。 以下屏幕截图显示了用于本地模型测试的代码：

gcloud ai-platform local predict --model-dir local-or-cloud-storage-path-to-model-directory/ \
  --json-instances local-path-to-prediction-input.json \
  --framework name-of-framework

部署模型及其版本

Google Cloud AI 平台使用模型和版本资源来组织您训练有素的模型。 AI 平台是学习机模型的容器。 在 AI 平台中，创建数据库资源以部署模型，构建模型版本，然后将模型版本连接到存储在云存储中的模型文件。 您可以使用gcloud控制台为您的产品版本构建默认工具，并在不附带括号的情况下填写您的首选模型名称，如下所示：

gcloud ai-platform models create "[YOUR-MODEL-NAME]"

您还可以使用 REST API 创建模型资源。 以下是相同的步骤：

  1. 通过将模型对象插入请求主体来格式化规范。 您至少必须给模型起一个名字。 如下填写您的姓名（不带括号）：
{"name": "[YOUR-MODEL-NAME]"}
  1. 将以下文章放入您的 REST API 中，并用正确的值替换[括号中的值]，如下所示：
POST https://ml.googleapis.com/v1/projects/[YOUR-PROJECT-ID]/models/

curl -X POST -H "Content-Type: application/json" \
  -d '{"name": "[YOUR-MODEL-NAME]"}' \
  -H "Authorization: Bearer `gcloud auth print-access-token`" \
  "https://ml.googleapis.com/v1/projects/[YOUR-PROJECT-ID]/models"

前面命令的示例 JSON 输出将类似于以下屏幕快照所示：

图 9.19：REST API 调用的 JSON 输出

创建模型资源后，即可创建模型版本。 我们将在这里看到如何做到这一点。 使用 Google Cloud API，您可以创建版本，如以下屏幕截图所示：

图 9.20：新创建的模型和模型列表页面

如前面的屏幕快照所示，选择模型工具的名称以在“模型”选项卡上构建您的版本。 这将带您浏览产品页面。 在“模型详细信息”页面的顶部，单击“新版本”按钮。 这将带您到版本开发页面，如以下屏幕截图所示：

图 9.21：新模型版本开发屏幕

创建模型版本时要注意的一件事是您可以选择手动和自动缩放的缩放选项。 如果选择“自动缩放”，则会显示可选的最小字段节点数。 您可以输入最少的节点数，以在服务减少时继续运行。 默认区域为0。 如果选择“手动缩放”，则需要始终输入要运行的节点数。 请参考以下屏幕截图：

图 9.22：手动缩放配置

需要仔细选择“手动缩放”选项。 无论群集上的负载如何，GCP 都会提供已配置的节点数（在手动扩展的情况下，这是必填字段）。 此操作适用于关键任务用例，这些用例需要频繁地在波动的级别上访问模型，并且不提供 Google Cloud AI Platform 在合理的时间内配置所需的节点。 在这种情况下，建议根据平均流量水平提供最少数量的节点。 即使没有发送任何模型访问请求，预配节点也将产生成本，如以下屏幕截图所示：

图 9.23：自动缩放比例配置

实现此目的的另一种方法是使用gcloud CLI。 如果使用gcloud，则首先设置环境变量以保存云存储目录路径，模型名称，版本名称和框架选择。 创建gcloud工具版本时，可以在框架名称中使用大写字母（例如，_SCIKIT-LEARN）添加下划线，也可以使用小写字母（例如，_scikit-learn）添加连字符。 所有方法导致相同的行为。 以下代码块显示了如何在脚本中设置相关的环境变量：

MODEL_DIR="gs://your_bucket_name/"
VERSION_NAME="[YOUR-VERSION-NAME]"
MODEL_NAME="[YOUR-MODEL-NAME]"
FRAMEWORK="[YOUR-FRAMEWORK_NAME]"

在具有定制代码的 scikit-learn 管道的定制代码 tarball 的路径上设置一个附加变量，如下所示：

MODEL_DIR="gs://your_bucket_name/"
VERSION_NAME="[YOUR-VERSION-NAME]"
MODEL_NAME="[YOUR-MODEL-NAME]"
FRAMEWORK="scikit-learn"
CUSTOM_CODE_PATH="gs://your_bucket_name/ai_platform_custom_code-0.1.tar.gz"

要执行自定义预测例程，请忽略FRAMEWORK变量，然后定义自定义代码 tarball 的路径以及预测变量类的名称。 检查以下代码：

MODEL_DIR="gs://your_bucket_name/"
VERSION_NAME="[YOUR-VERSION-NAME]"
MODEL_NAME="[YOUR-MODEL-NAME]"
CUSTOM_CODE_PATH="gs://your_bucket_name/ai_platform_custom_code-0.1.tar.gz"
PREDICTOR_CLASS="[MODULE_NAME].[CLASS_NAME]"

一旦设置了相关的环境变量，就可以使用 CLI 通过以下代码创建版本：

gcloud ai-platform versions create $VERSION_NAME \
  --model $MODEL_NAME \
  --origin $MODEL_DIR \
  --runtime-version=1.15 \
  --framework $FRAMEWORK \
  --python-version=3.7

将gcloud beta 组件用于 scikit-learn 管道（beta），并确保您设置了--package-uris-flag，如下所示：

gcloud components install beta

gcloud beta ai-platform versions create $VERSION_NAME \
  --model $MODEL_NAME \
  --origin $MODEL_DIR \
  --runtime-version=1.15 \
  --framework $FRAMEWORK \
  --python-version=3.7
  --package-uris=$CUSTOM_CODE_PATH

将gcloud beta 部分用于自定义预测例程，删除--frame标志，并设置--package-uris和--prediction-class标志，如下所示：

gcloud components install beta

gcloud beta ai-platform versions create $VERSION_NAME \
  --model $MODEL_NAME \
  --origin $MODEL_DIR \
  --runtime-version=1.15 \
  --python-version=3.7
  --package-uris=$CUSTOM_CODE_PATH
  --prediction-class=$PREDICTOR_CLASS

您可以检查模型版本，如下所示：

gcloud ai-platform versions describe $VERSION_NAME \
  --model $MODEL_NAME

/*****Output*****/
createTime: '2018-02-28T16:30:45Z'
deploymentUri: gs://your_bucket_name
framework: [YOUR-FRAMEWORK-NAME]
machineType: mls1-c1-m2
name: projects/[YOUR-PROJECT-ID]/models/[YOUR-MODEL-NAME]/versions/[YOUR-VERSION-NAME]
pythonVersion: '3.7'
runtimeVersion: '1.15'
state: READY

例如，具有 Cloud ML 服务智能体身份和访问管理（IAM）功能的模型版本具有 Google 托管服务帐户的权限。 对于大多数情况，此默认服务帐户就足够了。 但是，如果您正在使用自定义预测例程，并且需要在模型版本中具有一组不同的权限，则可以添加另一个服务帐户以供使用。 例如，如果您的模型版本需要从特定的 Google Cloud 项目访问云存储存储桶，则可以定义具有该存储桶读取权限的服务帐户。 以下代码块显示了用于创建服务帐户的示例 Python 代码：

import os

from google.oauth2 import service_account
import googleapiclient.discovery

def create_service_account(project_id, name, display_name):
    """Creates a service account."""

    credentials = service_account.Credentials.from_service_account_file(
        filename=os.environ['GOOGLE_APPLICATION_CREDENTIALS'],
        scopes=['https://www.googleapis.com/auth/cloud-platform'])

    service = googleapiclient.discovery.build(
        'iam', 'v1', credentials=credentials)

    my_service_account = service.projects().serviceAccounts().create(
        name='projects/' + project_id,
        body={
            'accountId': name,
            'serviceAccount': {
                'displayName': display_name
            }
        }).execute()

    print('Created service account: ' + my_service_account['email'])
    return my_service_account

部署模型版本的用户应为先前创建的服务帐户使用服务帐户令牌创建者角色。 在serviceAccount区域中指定模型版本的服务帐户名称。 使用gcloud方法时，可以使用--service-account标志，如以下代码示例所示：

gcloud components install beta

gcloud beta ai-platform versions create your-version-name \
  --service-account your-service-account-name@your-project-id.iam.gserviceaccount.com

模型训练实例

在本节中，我们将研究如何使用 Google Cloud 平台训练模型以进行预测。 重点是如何使用 Google Cloud 平台训练模型以及其中涉及的步骤。 整个训练代码均来自 Google Cloud 示例示例。 请参阅以下链接以获取训练代码。 您还可以从 Google Cloud 公共存储（gs://cloud-samples-data/ai-platform/census/data/*）下载数据：

  1. 您可以创建数据目录，然后使用gsutil copy 命令将数据从 Google Cloud 存储桶复制到本地目录。 这是必需的，因为您必须首先在本地训练和测试模型。 以下代码将执行相同的操作：
mkdir data
gsutil -m cp gs://cloud-samples-data/ai-platform/census/data/* data/

data文件夹具有以下屏幕截图所示的结构：

图 9.24：测试和训练数据文件

因此，假设您已经拥有训练代码和训练数据，并且已经设置了 Google Cloud SDK 的所有相关 Python 环境，我们现在可以研究使用 Google Cloud AI 平台训练模型的步骤。 您首先要从本地训练工作开始。

  1. 以下代码设置了MODEL_DIR环境变量，然后使用 Google Cloud AI Platform 命令在本地训练模型，如下所示：
MODEL_DIR=output
rm -rf $MODEL_DIR/*
gcloud ai-platform local train \
    --module-name trainer.task \
    --package-path trainer/ \
    --job-dir $MODEL_DIR \
    -- \
    --train-files $TRAIN_DATA \
    --eval-files $EVAL_DATA \
    --train-steps 1000 \
    --eval-steps 100

前面代码的输出看起来像下面的屏幕快照所示：

图 9.25：模型训练输出

输出目录将包含以下内容：

图 9.26：输出目录内容

要显示局部模型训练测试的结果，可以使用 TensorBoard 可视化工具。 使用 TensorBoard，您可以查看 TensorFlow 映射，编辑有关模型运行方式的定量数据以及显示其他数据，例如遍历图表的图片。 作为 TensorFlow 安装的一部分，可以使用 TensorBoard。

  1. 运行以下命令以启动tensorboard：
tensorboard --logdir=$MODEL_DIR --port=8080

前面的命令的输出看起来像下面的屏幕快照：

图 9.27：TensorBoard 命令输出

以下屏幕快照提供了 TensorBoard 外观的概览：

图 9.28：TensorBoard 显示模型训练图

单击屏幕左侧菜单中的“下载 PNG”选项，以获取前面图形的更清晰图像。

如您在此屏幕截图中所见，模型训练经历了各个阶段，TensorFlow 通过有效的日志记录来创建沿袭。 通过图形用户界面（GUI）可以轻松跟踪此沿袭。 在训练阶段处理输入值并产生中间结果时，可以跟踪它们。 可以通过将适当的值传递给运行时，基于训练图来调整模型：

图 9.29：TensorBoard 中的模型状态

  1. 现在，在进行本地测试之后，您需要在分布式本地模式下测试模型训练，以确保可以在分布式模式下训练模型，如果使用 Google Cloud AI Platform 训练模型，情况就是如此。 以下代码可用于相同的代码：
MODEL_DIR=output-dist
rm -rf $MODEL_DIR/*
gcloud ai-platform local train \
    --module-name trainer.task \
    --package-path trainer/ \
    --job-dir $MODEL_DIR \
    --distributed \
    -- \
    --train-files $TRAIN_DATA \
    --eval-files $EVAL_DATA \
    --train-steps 1000 \
    --eval-steps 100

输出如下图所示：

图 9.30：本地训练模型输出

输出模型目录具有以下内容。 检查点和日志文件夹启用 TensorBoard 上的图形视图，如以下屏幕快照所示：

图 9.31：模型训练输出目录

  1. 前面的步骤是关于运行模型训练作业以进行本地测试的。 此后，对于实际的生产级部署，您需要在云上运行模型训练。 为此，您必须先创建存储桶（或者也可以使用现有的存储桶）。 以下代码将为您创建存储桶：
BUCKET_NAME_PREFIX="ai_ml_book"
PROJECT_ID=$(gcloud config list project --format "value(core.project)")
BUCKET_NAME=${PROJECT_ID}-${BUCKET_NAME_PREFIX}
echo $BUCKET_NAME
REGION=us-central1
gsutil mb -l $REGION gs://$BUCKET_NAME

前面的代码的输出如下所示：

图 9.32：桶创建输出

  1. 创建存储桶后，您可以使用以下代码将工件上传到存储桶。 此代码还设置了一些变量以更正值，以便可以运行下一组命令：
gsutil cp -r data gs://$BUCKET_NAME/data
TRAIN_DATA=gs://$BUCKET_NAME/data/adult.data.csv
EVAL_DATA=gs://$BUCKET_NAME/data/adult.test.csv
gsutil cp ../test.json gs://$BUCKET_NAME/data/test.json
TEST_JSON=gs://$BUCKET_NAME/data/test.json

输出如下所示：

图 9.33：存储桶上传输出

  1. 现在，您可以通过批准的单人和分布式模式练习，在云中工作。 您将首先申请一份实例的训练工作。 使用默认的 BASIC 规模计算层来执行单个实例的训练工作。 最初的作业请求可能需要几分钟才能开始，但是之后作业将运行得更快。 在改进和验证准备工作时，它可以帮助您轻松进行迭代。 以下是相同的代码：
JOB_NAME=ai_book_model_single_1
OUTPUT_PATH=gs://$BUCKET_NAME/$JOB_NAME
gcloud ai-platform jobs submit training $JOB_NAME \
    --job-dir $OUTPUT_PATH \
    --runtime-version 1.14 \
    --module-name trainer.task \
    --package-path trainer/ \
    --region $REGION \
    -- \
    --train-files $TRAIN_DATA \
    --eval-files $EVAL_DATA \
    --train-steps 1000 \
    --eval-steps 100 \
    --verbosity DEBUG

前面命令的输出如下所示：

图 9.34：模型训练输出

  1. 运行gcloud ai-platform jobs describe ai_book_model_single_1命令后，将看到以下输出：

图 9.35：模型训练输出（2）

您也可以从 Google Cloud 控制台用户界面查看作业状态和日志。 以下屏幕截图表示相同：

图 9.36：Google Cloud 控制台上的模型训练状态

  1. 在进行模型训练时，我们会在模型列表用户界面中看到一个进度栏。 可以实时访问日志，以了解模型训练进度以及了解中间结果。 此级别的日志记录在模型调整中很有用，可以在以下屏幕截图中看到：

图 9.37：模型训练日志

存储在 Google Cloud 存储桶中的输出仅看起来像我们本地训练的输出模型，如以下屏幕截图所示：

图 9.38：Google Cloud 存储桶上的输出

  1. 通过启动 TensorBoard，可以检查您的训练工作的行为，并指向锻炼期间（锻炼期间和之后）生成的摘要日志。 由于摘要是由训练程序写入云存储位置的，因此 TensorBoard 可以从中读取内容，而无需手动复制事件文件。 以下屏幕快照是相同的：

图 9.39：TensorBoard 上的模型训练图

单击屏幕左侧菜单中的“下载 PNG”选项，以获取前面图形的更清晰图像。

  1. 您应该以分布式模式配置训练工作，以便在执行训练工作时利用 Google 的灵活平台。 要将模型作为分布式流程在 AI 平台上运行，则无需更改代码。 将--scale-tier设置为高于基本级别的任何层以执行分布式作业。 以下是相同的示例代码：
JOB_NAME=census_dist_1
OUTPUT_PATH=gs://$BUCKET_NAME/$JOB_NAME
gcloud ai-platform jobs submit training $JOB_NAME \
    --job-dir $OUTPUT_PATH \
    --runtime-version 1.14 \
    --module-name trainer.task \
    --package-path trainer/ \
    --region $REGION \
    --scale-tier STANDARD_1 \
    -- \
    --train-files $TRAIN_DATA \
    --eval-files $EVAL_DATA \
    --train-steps 1000 \
    --verbosity DEBUG

以下屏幕快照显示了上述代码的输出：

图 9.40：带有刻度的训练作业输出

  1. 您可以使用gcloud ai-platform jobs stream-logs $JOB_NAME命令流式传输日志。 以下屏幕快照表示流日志的输出：

图 9.41：流作业

  1. 模型训练的最后一步是部署模型。 以下代码将使用一个版本来部署模型：
MODEL_NAME=census
    gcloud ai-platform models create $MODEL_NAME --regions=$REGION
    OUTPUT_PATH=gs://$BUCKET_NAME/census_dist_1
    gsutil ls -r $OUTPUT_PATH/export
    MODEL_BINARIES=gs://$BUCKET_NAME/census_dist_1/export/census/1578466652
    gcloud ai-platform versions create v1 \
    --model $MODEL_NAME \
    --origin $MODEL_BINARIES \
    --runtime-version 1.14

以下是上述命令的输出：

图 9.42：模型部署输出

您还可以在 Google Cloud 控制台用户界面上查看已部署的模型版本，如以下屏幕截图所示：

图 9.43：从 Google Cloud 控制台部署的模型视图

在下一部分中，我们将研究如何使用已部署的人口普查模型进行在线和批量预测。

使用服务端点执行预测

通常，您已经在机器学习模型及其版本上训练并部署了 Google Cloud API 平台之后，才执行此步骤。 下图显示了在线预测如何在 Google Cloud AI 平台中工作：

图 9.44：在线预测工作流程

您可以使用部署在 Google Cloud Storage 存储桶上的模型作为服务端点公开，并且这些服务端点可以由使用 REST API 或gcloud工具本身的某些应用使用。 gcloud工具用于快速测试在线预测。 在实际的生产案例中，您可以使用用 Python 编写的脚本或 cURL 工具来使用 Rest API，从而在已部署的模型版本上公开预测功能。

以下代码显示了如何使用gcloud工具进行在线预测。 JSON 代码示例如下所示：

{"values": [1, 2, 3, 4], "key": 1}
{"values": [5, 6, 7, 8], "key": 2}

代码如下所示：

MODEL_NAME="census"
INPUT_DATA_FILE="instances.json"
VERSION_NAME="v1"
gcloud ai-platform predict --model $MODEL_NAME \
                   --version $VERSION_NAME \
                   --json-instances $INPUT_DATA_FILE

使用此代码，我们能够使用已部署的模型并根据训练数据预测结果。

总结

在本章中，我们介绍了 AI 的基本方面，使我们能够根据历史数据预测结果。 我们了解了预测分析的一般流程，并以 GCP 为例对流程进行了深入研究。 借助命令行和 Google Cloud 控制台上的用户界面工具，可以简化 GCP 上的模型构建（训练，评估）和部署过程。 我们还研究了如何对模型进行版本控制以及如何使用适当的模型进行预测。 预测服务也以 API 调用的形式公开，可以以与语言无关的方式进行调用。

在本书的最后一章中，我们将利用到目前为止研究的所有组件来构建 AI 应用。

十、构建一个 AI 应用

在本书的最后九章中，我们在 Google Cloud Platform（GCP）的背景下研究了人工智能的基本构成元素。

在本章中，我们将概述在本书中学习的各种工具和技术，并将其应用于构建示例 AI 应用。 我们还将介绍 GCP 即将推出的功能，这些功能将通过使 AI 和 ML 普及来进一步增强其构建智能应用的能力。

本章将涵盖以下主题：

  • 开发 AI 应用的分步方法
  • 用例概述– 自动发票处理（AIP）
  • 即将推出的功能

开发 AI 应用的分步方法

平台可通过补充人类智能来促进解决问题的现实应用和用例。 随着人工智能成为主流并被日常应用和软件平台所采用，开发人员社区以及大型组织必须利用 GCP 等平台以最少的时间和人力资源投资来构建功能强大的应用。 GCP 的 AI 还使我们在创建生产应用之前可以轻松进行各种实验和检验假设。 数据管理和 ML 作为 GCP 上的服务提供。 这样就无需管理基础架构和软件。 开发团队可以专注于解决实际问题，而无需担心平台和基础架构管理。 为此，开发人员社区可以使用 GCP 提供的复杂工具包，而无需前期投资。 我们将看到应用周转时间和易于开发方面的重大变化。

这促进了尖端的创新，并解决了一些现实世界中无法解决的问题。

通常，AI 应用的开发遵循循序渐进的方法。 总体上讲，AI 应用的开发和操作分为六个阶段，如下图所示。 在本节中，我们将研究这些通用阶段并学习基本的机器学习理论，在随后的部分中，我们将通过示例进行学习：

图 10.1：AI 应用开发阶段

问题分类

根据投入的特征和预期成果，人工​​智能可以解决的问题可以大致分为以下几类。

分类

分类问题通常涉及将结果分类为预定义的类别。 结果称为因变量。 结果取决于一组输入变量或特征。 输入变量或特征称为自变量。 分类问题训练模型以数学方式将自变量的组合映射到因变量。 输出是集合中的值之一。 例如，当通过分类算法时，水果图像被分类为苹果或橙子。 通常，算法规定图像属于特定类别的概率。 概率最大的类别是基于训练数据的分类。

回归

与分类问题不同，回归问题期望连续的结果而不是离散的类。 例如，预测特定人口区域的降雨的模型可以基于各种输入参数来预测以毫米为单位的降雨。

聚类

聚类问题通常通过无监督的学习方法来解决。 根据相似度指标，将可变空间分为多个聚类。 这是根据数据点与组输入质心的距离进行数学建模的。 例如，可以通过聚类算法将生物细胞聚类为感染或正常类别。

优化

优化问题用于提高特定计算活动的表现。 例如，如果我们需要压缩文件，则可以尝试各种算法，然后根据数据类型选择最佳算法。 优化问题的另一个示例是根据实时交通和其他路况为车辆找到最佳路线。 该算法可帮助优化路线，以实现从 A 点到 B 点的最短行驶时间。

异常检测

异常检测是一种类型的问题，其中需要检测数据中的极端条件。 网络安全是异常检测的一个非常突出的用例。 生成了大量的网络日志，如果没有智能采样和智能算法，就不可能检测到异常值。

排名

排名问题涉及我们需要根据特定用例按堆叠排名对结果空间进行排序。 控制排名的规则充当输入变量，而顺序排名则作为输出。 这些问题可以通过有监督的学习方法和无监督的学习方法来解决。 这些排名算法的典型用法是通过推荐系统。 在零售的情况下，产品会根据各种用户偏好按相关性进行排名，并呈现给用户。

数据准备

数据准备问题是期望算法从历史模式生成数据的地方。 一个示例用例是基于神经网络和大量面部图像创建人脸，这些面部图像被馈送到算法中（使用生成对抗网络）以生成新图像。 该算法可以创建用于测试和实验目的的真实数据。

数据采集

AI 应用获得的用于训练基础模型的数据越多，表现就会越好。 数据的质量和数量对于 AI 应用真正补充人类智能至关重要。 这意味着从各种来源获取数据是该过程中的重要一步。 通常以批量或接近实时的方式获取数据。

通常，历史数据在批量模式下用于训练和调整模型，而实时数据在流模式下用于进一步处理。 在某些用例中，期望 AI 应用的事件时间与操作时间之间的时间间隔最小。 在这种情况下，我们需要考虑使用高端计算基础架构，以确保数据采集和处理中的亚毫秒级延迟。

数据处理

随着更多设备连接到互联网，我们正在生成更多数据。 这称为大数据，并导致数据量增长。 必须使用尽可能多的数据来构建 AI 应用，因为各种形式的数据都包含可以用来构建智能应用的智能。 通过处理非结构化数据的功能，大数据现在包括例如图像，视频，音频文件，文本和无线数据。 大数据处理还涉及计算机视觉，自然语言处理（NLP），社交网络，语音识别，车联网（IoV）数据分析，实时物联网（IoT）数据分析以及无线大数据处理。

近来，已集中实现了以人工智能（AI）为动力的大规模异构数据处理技术，这些技术专注于模式识别，机器学习和深度学习。 然而，人工智能驱动的大数据处理的发展仍然充满挑战。 在计算机视觉和图像处理中，越来越多的数据库和数据流已经被分发和处理。 大规模分析图像/视频数据的最大挑战之一是建立节能高效的实时方法，以从每秒产生的大量数据中提取有用的信息。 得益于大数据和新的 AI 技术的帮助，语音处理也取得了很多进展。

问题建模

我们需要了解特定的问题，并使用适当的模型来解决该特定的问题。 根据问题的具体类别，在决定在生产中使用特定模型之前，我们需要尝试各种算法。 在特定类别的算法中，可能会部署不正确的模型，而该模型不会在新数据集上产生准确的结果。

在最终选择所部署的模型之前，我们需要了解一段时间内的数据模式。 对于增强人员功能的关键任务 AI 应用而言，这尤其重要。

验证与执行

在将训练后的模型用于 AI 应用之前，需要对其进行彻底的验证。 在 AI 应用中，该想法是对人类情报的补充，因此，在部署模型之前，确保已对异构数据样本（评估数据集）进行了验证，这一点变得尤为重要。 该模型不仅需要在预定义的评估样本上而且还需要在模型从未看到的新数据集上通过较高的阈值。 我们可以使用两种主要的验证类别来评估模型：保持和交叉验证。

两种方法都使用测试集来评估模型输出（即算法看不到的数据）。 不建议使用我们用来开发模型的数据进行测试。 这是因为我们的模型会记住整个训练集，因此会在训练集中的任何点预测正确的标签。 这称为过拟合。 由于其速度，简单性和多函数式，所以保留方法很有用。 尽管如此，由于训练和测试数据集的变化会导致准确率估计值的显着差异，因此该方法通常具有很高的不确定性。

留存

留存方法的基本思想是通过将模型暴露于新数据集（与用于训练的数据集相比）来避免过拟合。 最初，它导致模型精度低于最小阈值； 然而，该方法提供了无偏的学习表现和准确的估计。 该方法将数据集随机分为三个子集：

  • 训练集：这是用于预测模型构建的数据集子集。
  • 验证集：这是一个数据集子集，用于评估在训练阶段构建的模型的表现。 它提供了一个测试平台，可以微调模型的参数并选择表现最佳的模型。 并非每种建模算法都需要一组验证。
  • 测试集：这是数据集的子集，用于预测产品的潜在未来输出。

交叉验证

这是一种我们可以访问有限的数据集进行训练和评估的技术。 通过这种技术，我们将数据分解为不同的块。 这些独立的块以随机顺序用于评估过程中的多次迭代训练和评估。 这样可以确保在各种样本上训练模型，并且还可以通过训练数据的不同子集执行等效评估。

这样可以确保模型结构有足够的变化，以避免过拟合和过拟合。 但是，即使使用交叉验证方法，也建议您拥有尽可能多的数据用于训练和评估。 这些方法的准确率计算是通过训练和评估使用的各种迭代的平均值。

模型评估参数（指标）

需要模型评估指标来度量模型效率。 选择评估指标取决于 ML 的特定任务（例如分类，回归，排名，聚类或主题建模等）。 某些指标（例如精确召回）对于多个任务很有用。 基于监督和经验（历史数据）的机器学习模型（例如分类和回归）构成了机器学习的大部分应用。

分类指标

让我们看一些常用的分类指标：

  • 分类准确率：对于分类问题，准确率是标准的度量标准。 通常将其作为预测总数与正确预测数目之比来衡量。 例如，如果我们有一个基于图像对动物进行分类的用例，则可以通过比较训练和评估时间数据并与分类尝试的总数之比来衡量正确分类的数量。 我们需要通过将样本数据划分为各种评估测试来运行多个测试，以避免数据过大和不足。 我们还可以通过比较各种模型来部署交叉验证，以优化表现，而不是对同一模型使用不同的随机样本运行多个测试。 使用这些方法，我们可以迭代的方式提高分类的准确率。

  • 混淆矩阵：有关错误分类的信息对于提高模型的整体可靠性也很重要。 混淆矩阵是了解整体模型效率的有用技术。

  • 对数损失：当输入是介于 0 和 1 之间的概率值时，这是理解模型表现的重要指标。对于 ML 模型，最好具有最小的对数损失。 通常为此指标设置的阈值小于 0.1。

  • 曲线下面积（AUC）：AUC 提供了所有可能的额定水平的综合表现指标。

模型部署

AI 和 ML 模型的部署是全面运行模型的重要步骤。 GCP 使部署模型的多个版本变得容易且无缝。 以下是在生产中部署模型所需遵循的一般步骤：

  1. 使模型文件在 Cloud Storage 存储桶中可用。

  2. 建议您在使用的同一 AI 系统项目中使用专用的 Cloud Storage 池。 如果您需要在其他项目中使用存储桶，则必须确保您的 AI 平台帐户能够访问您的 Cloud Storage 模型。 没有所需的权限，您尝试构建模型的 AI 平台版本将失败。 以下是设置 Google Cloud 存储桶所涉及的步骤：

  3. 为存储桶设置唯一的名称。 确保它具有唯一的名称，以使其与项目的云存储中的所有其他存储桶区分开。 通常，您可以通过在项目 ID 的末尾附加-mlengine来生成存储区名称。 为确保在整个项目中进行一致的部署，建议使用最佳实践。 例如，如果项目名称为 AIGCP，则用于存储模型文件的存储桶名称将为AIGCP-mlengine。

  4. 设置存储桶的区域并设置环境变量值。 建议您使用打算在其上运行 AI 平台作业的区域。

  5. 使用以下针对 TensorFlow SavedModel 的命令将模型上传到新创建的存储桶：

SAVED_MODEL_DIR=$(ls ./your-export-dir-base | tail -1)
gsutil cp -r $SAVED_MODEL_DIR gs://your-bucket
  1. 在将模型用于 AI 平台预测之前，请测试model—Gcloud ai-platform local predict命令以检查模型如何处理预测。 该命令使用本地环境中的依赖项进行预测并在联机进行预测时以与gcloud ai-platform predict相同的方式产生输出。 为了节省成本，建议您在发送联机预测请求之前在本地检查预测以发现错误。 这是测试模型的示例命令：
gcloud ai-platform local predict --model-dir model_storage_path/ \
 --JSON-instances path-for-prediction-input.JSON \
 --framework tensorflow

在本节中，我们已经看到了构建 AI 应用的各个阶段。 这是用于开发 AI 应用的高级构建块的简化视图：

图 10.1：AI 应用的高级构建块

正如我们在图中所看到的，AI 应用管道中主要包含三个区域：数据获取，数据处理（特征工程），然后是模型执行和调整。 在本章的后续部分中，我们将考虑一个用例，并了解在 GCP 上使用 AI 工具包构建可运行的应用有多么容易。

用例概述 – 自动发票处理（AIP）

发票处理是遵循典型工作流程的重复性通用过程。 目前，大多数组织都需要大量的人工干预来管理发票处理的各个方面。 我们在本书中看到的各种 GCP 工具可以使组织的整个发票处理系统自动化。 在本节中，我们将通过逐步进行自动开票的过程来探索用例。

例如，让我们考虑一家为客户提供 IT 咨询服务的软件开发公司。 通常，对于项目的时间和材料成本，在月底（或预定义的发票期）将发票发送给客户。 发票包含有关卖方提供给客户的服务的所有详细信息，以及各个服务的详细信息以及付款处理所需的详细信息（例如，银行帐户详细信息）。 在我们的示例中，让我们考虑发票文件为 PDF 格式，并通过电子邮件接收。 这是我们示例的发票示例：

图 10.2：示例用例的发票示例

通常，发票包含以下部分：

  1. 客户名称，地址和电话号码。
  2. 发票抬头信息，例如发票编号，日期，SOW 编号，项目 ID 等。
  3. 发票金额明细和总计。
  4. 发票金额（以字为单位）。
  5. 用于汇款的银行帐户详细信息。

应付帐款团队收到发票后，他们将根据时间表系统验证各个应付款条目，并根据供应商的付款条件安排发票以进行付款。 以下流程图描述了此工作流程：

图 10.3：具有代表性 GCP 组件的发票处理流程

我们将使用 GCP 组件来自动化此过程。 在下一节中，我们将介绍 GCP 上 AIP 系统的设计。

在 GCP 上使用 AI 平台工具设计 AIP

我们将使用本书前面已经学习过的一些 GCP 组件来设计 AIP 应用。 下图突出显示了四个部分，这些部分分别有助于构建应用。 我们将使用原始发票 PDF 文件作为信息源。

数据将存储在 Cloud SQL 中，并在 Cloud Functions 的帮助下传递给 AI 工具包以进行进一步处理。 然后，我们将利用 GCP 上的 AI 工具包在应用中构建智能。 首先，我们需要一个 ML，自然语言界面，视觉 API 和语音 API 来启用对话界面。 最后，我们将利用出站服务，特别是 Dialogflow。 这是使用 GCP 组件的 AIP 应用的高层组件交互：

图 10.4：AIP 应用的组件设计

通过集成各种 GCP 组件，我们可以实现功能齐全的 AIP 应用。 以下列表显示了应用中涉及的各种 GCP 组件的功能摘要。

以下组件可用作 GCP 中的数据存储区； 在我们的应用中，我们将利用 Cloud SQL：

  • Cloud SQL：这是一个完全托管的数据库，可以充当 GCP 上的关系数据库。 在撰写本文时，Cloud SQL 可以与 MySQL，PostgreSQL 和 SQL Server 一起使用。
  • Cloud Bigtable：这是 GCP 上的 NoSQL 数据库服务。 Bigtable 为数据集提供了低延迟，可大规模扩展的界面。 该存储是 ML 应用的理想选择，并且易于与各种开源大数据框架集成。
  • Cloud Spanner：这是一种水平可伸缩的关系数据库服务，在各个实例和节点之间高度一致。 它结合了关系型数据库和非关系型数据库的最佳功能，其完全托管的特性使其成为用最少的时间投资来进行大型数据库部署的有吸引力的选择。
  • Cloud Memorystore：这是一种完全托管的内存中数据存储服务，可用于构建应用缓存，并为数据访问提供极低的延迟。 该内存存储利用 Redis 协议，从而使它在各个部署之间保持一致。 缓存的移植很容易。
  • Cloud Firestore：这是一个方便的 NoSQL 数据存储，用于使客户端和服务器端之间的数据保持同步。 它通常用于移动，Web 和服务器开发，并为构建响应式应用和跨设备应用提供支持。
  • Cloud Datastore：这是另一个完全托管的 NoSQL 数据库，用于处理分片和复制，以确保跨部署区域的高可用性。 它支持 ACID 事务以及类似 SQL 的查询和索引。 数据存储区提供了 REST API，通过允许通过多级安全连接进行数据访问，可以轻松集成外部应用。 可以很容易地更改基础数据结构，并提供一种易于使用的查询语言。

以下组件可用于计算和处理； 在我们的应用中，我们将利用 Cloud Functions：

  • Cloud SDK：这是用于使用 GCP 开发的一组工具和库。 这是所有 GCP 服务的命令行界面，例如虚拟机编排，计算引擎，网络和磁盘存储。 它通常用于自动执行各种应用管理任务。 对于 AIP 应用，我们可以使用 Cloud SDK 来管理开发，测试和部署管道，并自动管理整个应用。
  • Cloud Functions：这是一个无服务器，事件驱动的计算平台。 根据工作负载和基于预定义的事件，可以轻松地进行伸缩。 对于 AIP 应用，一旦发票到达源位置，我们就可以使用 Cloud Functions 触发自动过程，以读取发票并进行处理。 它为跨各种语言和应用接口协议的互操作性提供了无缝支持。 它基于最小特权的核心安全原理工作，并根据为用户分配的角色，促进对事件和功能的安全访问。

以下是 AI 工具包中可利用的组件： 在我们的应用中，我们将利用云机器学习，自然语言 API，视觉 API，翻译 API，语音 API 和云视频智能 API：

  • Cloud ML：这是一个全面的平台，可利用 Google Cloud 的功能，使训练和部署可用于任何类型和大小的数据的 ML 模型变得容易。 在平台上训练的模型可以立即使用，并且可以通过安全的 API 进行访问，从而可以以最少的资金和时间投入轻松开发应用的快速原型。

  • 自然语言 API：自然语言 API 可用于执行 Web 规模的文本分析。 该 API 与 AutoML 集成在一起，并允许用户基于非结构化数据来训练，测试和部署其模型。 有预训练的模型，具有各种领域功能的各种应用可以轻松利用这些模型。 该平台使协作和共享不断被平台升级的模型变得容易，从而提供了一种一致且可靠的方式来创建用于处理自然语言形式输入的应用。 这样可以通过语音 API 与人进行数据交互。

  • 视觉 API：这在基于视觉输入（例如图像）的分析中非常方便。 如果机器具有补充人类视觉的能力（例如从 PDF 或 Word 文档抄录文本），我们可以将大量 API 用于此用例。 这样，可以以有效和具有成本效益的方式对大量文档进行分类。 无需大量设置即可使用该服务，因此，一旦为项目和用户帐户启用了该服务，就可以轻松无缝地开始使用它。 强大的 API 层使您可以轻松以安全的方式与第三方应用集成。

  • 翻译 API：这是一种便捷的服务，无需设置转换规则即可使用。 该 API 允许根据预先训练并不断发展的模型在各种语言之间进行翻译。 这些功能易于使用，为语言互操作性以及以各种语言构建的各种应用之间的集成打开了可能性。

  • 语音 API：这是智能机器的重要方面，它使人与应用之间具有类似人的界面。 首先，API 启用了文本到语音到文本的转换。 这些功能可用于创建对话应用。 DialogFlow 在内部利用语音 API 来促进对话。

  • Cloud Video Intelligence API：此 API 使我们能够利用视频输入中的信息。 GCP 上有可用的预训练模型，这些模型可用于分类和识别视频帧内的特定对象。 它是自动驾驶汽车的组成部分之一，API 高效且可扩展，足以在关键任务应用中使用。

在下一部分中，概述了 GCP 上可用于构建端到端 AI 应用的各种组件，下面让我们看一下如何在 GCP 上构建自动发票处理应用。

使用 Vision API 执行光学字符识别

收到 PDF 格式的发票后的第一步是解释其内容。 我们将通过以下步骤使用视觉 API 来执行光学字符识别（OCR）：

  1. 在 GCP 上创建一个新项目。 建议您使用一个新项目来尝试 OCR。 转录文档后，可以根据需要删除该项目，而不会影响任何其他应用。
  2. 从 GCP 控制台启用 Cloud Vision API，Cloud Pub/Sub，Cloud Functions 和 Cloud Storage。
  3. 从 Cloud Shell（从 GCP 控制台），确保使用以下命令更新所有组件：
gcloud components update
  1. 如下在 Cloud Storage 上创建两个存储桶：

图 10.5：用于创建存储桶的gsutil命令

  1. 创建aigcp存储桶以存储发票 PDF 文件，并使用aigcp-text存储桶存储转录的文本文件（JSON 格式）。
  2. 将发票 PDF 文件复制到aigcp存储桶（从 Cloud Shell 或从 GCP 控制台复制）。 这是 GCP 控制台中存储区内容的快速快照：

图 10.6：Google Cloud Storage 存储桶中的发票文件

  1. 运行以下命令以使用 Vision API 读取发票 PDF 文件并将其转录为文本：

图 10.7：使用 Vision API 进行 OCR 和文本检测的命令

  1. OCR 也可以通过任何一个编程接口执行。 GCP 提供了用于 C#，Go，Java，Node.js，PHP，Python 和 Ruby 的 API。 让我们看一下 OCR 的 Python 实现的一小段。 完整的实现在 GitHub 上：
def async_detect_document(source_path_gcs, destination_path_gcs):

    client = vision.ImageAnnotatorClient()

    feature = vision.types.Feature(
        type=vision.enums.Feature.Type.DOCUMENT_TEXT_DETECTION)

    gcs_source = vision.types.GcsSource(uri=source_path_gcs)
    input_config = vision.types.InputConfig(
        gcs_source=gcs_source, mime_type=mime_type)

    async_request = vision.types.AsyncAnnotateFileRequest(
        features=[feature], input_config=input_config,
        output_config=output_config)

    operation = client.async_batch_annotate_files(
        requests=[async_request])
  1. JSON 格式的转录文本文件现在存储在aigcp-text存储桶中，如以下屏幕截图所示：

图 10.8：在 Google Cloud Storage 中输出 JSON 文件

  1. 为了从输出 JSON 文件中提取有意义的信息，我们需要了解输出 JSON 文件（output-1-to-1.JSON）的格式：

图 10.9：输出文件中的 JSON 标头

这是输出文件中的头信息。 Vision API 自动检测 PDF 文档中使用的语言。 实际字符数据封装在[H​​TG0] > paragraphs > words > symbols的层次结构中，如下图所示：

图 10.10：输出 JSON 结构

Vision API 还将 PDF 文件中找到的所有符号收集到一个文本字段中。 这有助于我们快速从发票中收集有意义的内容。 以下是包含文本字段的输出 JSON 的代码段：

图 10.11：发票文件中的文字

有关发票中的原始内容和 Vision API 提取的文本，请参见图 10.2。 发票内的所有字段在文本字段内的输出 JSON 文件中可用。

至此，我们已经利用 Vision API 从发票中提取了有意义的信息，以便对其进行自动处理。 在接下来的部分中，我们将使用各种 GCP 工具存储相关数据，进行验证并安排发票付款。

使用 Cloud SQL 存储发票

在本节中，我们将介绍一个完整的过程，该过程是从 OCR 输出生成的 JSON 文件中选取文本并将其通过 Cloud Functions 推送到 Cloud SQL 中的。 首先，我们将介绍在 GCP 上准备好 Cloud SQL 和 Cloud Functions 的步骤，然后我们将解释用于选择文本并将其转换为所需的结构化格式以将其插入表中的代码。

创建一个 Cloud SQL 实例

首先，让我们通过执行以下步骤来创建 Cloud SQL 实例：

  1. 从左侧面板中，从“存储”部分中选择SQL：

  1. 单击“创建实例”：

  1. 点击“选择 MySQL”：

  1. 为实例命名，设置适当的密码，选择您的区域，保留默认数据库版本，然后单击“创建”。 记住您为 root 用户设置的密码，因为稍后将有用：

设置数据库和表

现在，借助以下步骤来设置数据库和表：

  1. 单击创建的实例：

  1. 单击“使用 Cloud Shell 进行连接”，然后通过输入创建实例时设置的 root 用户的密码来连接到 MySQL：

  1. 运行以下命令来创建数据库：
create database aip_db;
  1. 运行以下命令以创建发票表。 SQL 文件aip.sql也可从这里获得，以创建与数据库相关的工件：
create table invoice 
(Company_Name VARCHAR(50),
Client_Name VARCHAR(50),
Client_Address VARCHAR(50),
SOW_Number VARCHAR(50),
Project_ID VARCHAR(50),
Invoice_Number VARCHAR(50),
Invoice_Date DATE,
Billing_Period DATE,
Developer VARCHAR(255),
Rate VARCHAR(50),
Hours INT,
Subtotal VARCHAR(50),
Balance_Due VARCHAR(50),
Bank_Account_Number INT,
Bank_Name VARCHAR(50));

启用 Cloud SQL API

现在让我们启用 Cloud SQL API：

  1. 从控制台搜索 Cloud SQL Admin API：

  1. 单击“启用”：

启用 Cloud Functions API

现在启用 Cloud Functions API：

  1. 从控制台搜索 Cloud Functions API：

  1. 要启用 API，请单击“启用”：

  1. 要建立从 Cloud Functions 到 Cloud SQL 的连接，需要以下 Cloud SQL 详细信息：
  • 实例名称
  • 数据库名称
  • 用户名：root
  • 创建实例时设置的root用户的密码

创建 Cloud Function

现在让我们创建一个 Cloud Function：

  1. 从“计算”部分下的左侧面板中选择“云函数”：

  1. 单击“创建功能”：

  1. 输入所需的功能名称。 分配的内存可以为 256 MB。 选择“触发器”作为“云存储”，然后选择“事件类型”作为“完成/创建”。 存储桶名称应为存储 PDF 到文本输出的存储桶的名称。 源代码应为内联编辑器：

  1. 复制aip_cloud_function.py中的代码，并根据存储区名称和创建的 Pub/Sub 主题替换所需的详细信息。 要连接到 Cloud SQL 数据库，将需要再进行一次替换。 将“步骤 6”中提到的代码行替换为下载代码中的 Cloud SQL 详细信息。
  2. 从这里下载 Cloud Functions 代码。
  3. 提供 MySQL 连接详细信息，如以下代码所示。 您将从上一步下载的 Cloud Function 代码中获得相同的代码行。 请使用适当的详细信息替换数据库用户，密码，名称和 Cloud SQL 实例：

# MYSQL+pymysql://<db_user>:<db_pass>@/<db_name>?unix_socket=/cloudsql/<cloud_sql_instance_name>

  1. 替换该行后，复制并粘贴代码，如以下屏幕截图所示：

  1. 对于依赖项设置，请从以下链接复制requirement.txt中的内容，并将其粘贴到中的需求文件中 https://github.com/vss-vikram/Hands-On-Artificial-Intelligence-on-Google -云平台

  1. 单击“创建功能”。
  2. 创建功能后，单击功能，然后转到“常规”选项卡。 检查用于运行该功能的服务帐户：

提供 Cloud SQL 管理员角色

接下来，让我们向运行 Cloud Function 的服务帐户提供 Cloud SQL Admin 角色：

  1. 转到“IAM”部分：

  1. 选择将用于运行 Cloud Functions 的服务帐户：

  1. 将 Cloud Admin 角色分配给该帐户：

现在，让我们遍历 Cloud Function 的完整代码，以将 PDF 转换为文本后处理发票。 以下是部分代码段。 完整代码可在这个页面处找到：

def validate_aip(event, context):
    """Triggered by a change to a Cloud Storage bucket.
    Args:
         event (dict): Event payload.
         context (google.cloud.functions.Context): Metadata for the event.
    """
    #Code block to read file from GCS and load data in JSON format.
    client = storage.Client()
    bucket = client.get_bucket(bucket)
    blob = bucket.get_blob(file_path)
    contents = blob.download_as_string()
    contents = contents.decode("utf-8")
    data = JSON.loads(contents)

    #Reading required text field from data.
    output = data['responses'][0]['fullTextAnnotation']['text']
    output = output[:-1]

    #Code setup to convert output data from JSON file to the required format                                for loading into invoice table.

    df_invoice = pd.DataFrame.from_dict(output_dict)

    df_invoice[['Developer', 'Rate', 'Hours', 'Subtotal']] =                               df_invoice['Developer Rate Hours Subtotal'].str.split(expand=True)

    df_invoice = df_invoice.drop(columns=['Developer Rate Hours Subtotal'])

    #Establishing connection with Cloud SQL.
    db_con = sqlalchemy.create_engine('MYSQL+pymysql://<db_user>:                                     <db_pass>@/<db_name>?                                                                  unix_socket=/cloudsql/<cloud_sql_instance_name>'
    )

在代码的这一部分中，我们导入了所需的依赖关系，然后，当从 GCS 加载数据时，我们使用了 GCS 特定的库从 GCS 中存储的文件中加载数据。 加载文件后，将从 JSON 文件中提取包含我们在本章前面讨论的所有信息的特定文本。 使用正则表达式将文本字段分隔为单独的列，并使用正则表达式输出填充 Cloud SQL 中的发票表。

使用 Cloud Functions 验证发票

在本节中，我们将遍历用于验证发票处理的代码。 您将需要在时间表表中加载数据以与发票表进行交叉验证（发票表是使用 PDF 文件填充的）。

以下是在数据库中创建时间表表并将数据加载到表中的步骤：

  1. 正如我们在“使用 Cloud SQL 秘籍存储发票”的步骤 2 中所讨论的那样，使用 Cloud Shell 实例连接到 MySQL，并运行以下查询以创建表时间表表：
create table timesheet 
(Company_Name VARCHAR(50),
SOW_Number VARCHAR(50),
Project_ID VARCHAR(50),
Invoice_Number VARCHAR(50),
Invoice_Date DATE,
Billing_Period DATE,
Developer VARCHAR(255),
Rate VARCHAR(50),
Hours INT,
Bank_Account_Number INT,
Bank_Name VARCHAR(50));
  1. 运行以下查询以将数据插入时间表表。 如前所述，您可以使用aip.sql来获取以下查询：
insert into timesheet (Company_Name, SOW_Number, Project_ID, Invoice_Number, Invoice_Date, Billing_Period, Developer, Rate, Hours, Bank_Account_Number, Bank_name)
values ('Vsquare Systems', '001', '002', '030', '2020-01-31', '2020-01-31', 'Developer1', '$185', 160, 000000001, 'Payment Bank');

insert into timesheet (Company_Name, SOW_Number, Project_ID, Invoice_Number, Invoice_Date, Billing_Period, Developer, Rate, Hours, Bank_Account_Number, Bank_name)
values ('Vsquare Systems', '001', '002', '030', '2020-01-31', '2020-01-31', 'Developer2', '$150', 152, 000000001, 'Payment Bank');

insert into timesheet (Company_Name, SOW_Number, Project_ID, Invoice_Number, Invoice_Date, Billing_Period, Developer, Rate, Hours, Bank_Account_Number, Bank_name)
values ('Vsquare Systems', '001', '002', '030', '2020-01-31', '2020-01-31', 'Developer3', '$140', 168, 000000001, 'Payment Bank')

现在我们已经准备好数据，让我们深入验证过程。

  1. 让我们来看一下数据验证所需的代码。 在以下代码中，我们从先前创建的时间表表中提取数据，并基于Company Name，SOW_Number，Project_ID，Invoice_Number和Developer创建数据框：
#Reading data from timesheet table.
 df_timesheet = pd.read_sql(f'SELECT * FROM timesheet', con=db_con)
 joined_df = pd.merge(df_invoice, df_timesheet, on=['Company_Name','SOW_Number','Project_ID','Invoice_Number','Invoice_Date','Developer'])

在以下代码中，我们根据费率和小时数匹配发票和时间表数据框。 如果所有记录都匹配，那么我们可以继续； 如果存在差异，则不会处理发票：

#Matching data of both tables.
 matched = []

 for index, row in joined_df.iterrows():

 if row['Rate_x'] == row['Rate_y'] and row['Hours_x'] == row['Hours_y'] and                                               row['Bank_Account_Number_x'] ==                                                                   row['Bank_Account_Number_y']:

     matched.append(True)

 else:

     matched.append(False)

为发票安排付款队列（发布/订阅）

在本节中，我们将学习如何将消息推送到 Pub/Sub 主题，以便发票处理系统处理发票。 我们将介绍创建发布/订阅主题的过程，以及如何发布和订阅该主题的消息。

让我们创建一个主题并对其进行测试：

  1. 要启用 Cloud Pub/Sub API，请执行以下步骤：

    1. 从主页搜索发布/订阅 API。
    2. 启用 API。

  2. 要创建发布/订阅主题和订阅，请执行以下步骤：

    1. 从左侧面板中选择发布/订阅。
    2. 单击“创建主题”。
    3. 在左侧面板中，转到“订阅”，然后为创建的主题创建订阅。

  3. 从以下屏幕快照中显示的选项中，将消息推送到主题中：

  1. 以下代码演示了，一旦数据匹配，我们就将一条消息推送到 Pub/Sub 主题，该信息将由付款处理系统使用以处理发票：
 #Pushing successful message into Pub/Sub.
 if False not in matched:
     data = f"Invoice Matched"
     publisher = pubsub_v1.PublisherClient()
     topic_path = publisher.topic_path('project_id', 'topic_name')
     bdata = data.encode("utf-8")
     future = publisher.publish(topic_path, data=bdata)

通知供应商和 AP 团队有关付款完成的信息

在撰写本文时，GCP 使用 SendGrid 发送电子邮件。 SendGrid 是一个受信任的电子邮件传递系统，该系统在全球范围内用于发送跨国和市场营销电子邮件。 这是一个非常强大的基于云的解决方案，它消除了维护电子邮件基础结构的所有复杂性。 在本节中，我们将学习如何使用 SendGrid 发送电子邮件。 它免费提供 12,000 封电子邮件。

以下是启用 SendGrid API 的步骤：

  1. 从主页搜索云消息传递。
  2. 启用 S​​endGrid API。

现在，让我们看看如何从 SendGrid 配置和发送电子邮件。

以下是示例 Python 代码，可用于从 SendGrid 发送电子邮件。 该代码非常简单，不言自明。 您只需要确保使用正确的 API 密钥即可：

# using SendGrid's Python Library - https://github.com/sendgrid/sendgrid-python
import sendgrid
​
sg = sendgrid.SendGridClient("YOUR_SENDGRID_API_KEY")
message = sendgrid.Mail()
​
message.add_to("test@sendgrid.com")
message.set_from("you@youremail.com")
message.set_subject("Sending with SendGrid is Fun")
message.set_html("and easy to do anywhere, even with Python")
sg.send(message)

前面的代码用于在电子邮件正文中配置 SendGrid 客户端，收件人，发件人，主题和消息。

现在，您已经了解了如何以自动化方式处理发票。 接下来，我们将快速了解如何为 AIP 创建对话界面。

为 AIP 创建对话界面

使用存储在 Cloud SQL 中的数据构建应用后，我们可以通过启用 Dialogflow API 来启用会话界面。 我们可以创建应用上下文并训练智能体以处理与发票相关的各种用户查询。 我们需要连接到数据存储的外部集成服务，以根据应用上下文回答各种用户查询。 我们已经在第 6 章，“使用 Dialogflow 的智能会话应用”中，看到了使用 Dialogflow 启用对话接口的详细步骤。 通过启用 Dialogflow 智能体，自动发票处理的用例可以完全补充人的智能并避免人工干预和错误，并且可以更快，更高效地处理大量发票。

在本章中，我们已经看到了各种 GCP 工具和应用在构建用于自动发票处理的智能应用中的实际应用。 如我们所见，通过使用 GCP 工具，可以轻松无缝地开发补充人类智能的功能。 该平台本身正在不断发展，并朝着高端功能的完全普及发展，这些高端功能利用了完全托管的服务来进行存储，计算，机器学习和高级分析。 在本章（和本书）的最后部分，我们将探讨 GCP 即将推出的一些功能。 我们期望，凭借不断的创新和 Google 在处理全球数据方面的经验，即将推出的工具，框架和应用将使在 GCP 上构建智能应用变得更加轻松，快捷和更具成本效益。

即将推出的功能

当务之急是，随着新功能的增加，GCP 将会进一步发展。 以下是我们认为将来会添加到 GCP 中的新增功能的代表列表：

  • GCP 将具有更好的跨平台产品集成和可用性。 例如，IBM Power Systems 现在可以在 GCP 上使用。 这样，通过将整个平台迁移到 GCP，即可利用企业已经在大型生产系统中进行的投资。 这将为企业节省实现成本和基础设施成本。

  • 即用型 AI 和 ML 模型将启用 GCP。 随着市场的成熟，GCP 将托管越来越多的 AI 和 ML 模型。 这些模型可通过具有固有互操作性的预定义 API 来使用。 GCP 将不断对模型进行训练和调整，并随着时间的推移产生越来越好的结果。 市场将随着使用量的增加而成熟。 签署和定价将简化，以使所有经验级别（包括入门级）的开发人员都能够快速构建其企业应用。

  • GCP 将提供一个拖放式用户界面，以构建从问题分类到模型部署的整个 AI 管道。 届时，人工智能的力量将完全掌握在业务团队手中，而对 IT 和开发团队的依赖将减少。 平台的简化和普及将带来进一步的创新，我们将体验不仅使用而且每个人都构建的智能应用。

  • GCP 将启用针对特定行业和企业的 AI 工具包，以提高各种规模企业的盈利能力和创新能力。 例如，谷歌已经在帮助零售商加速其数字和多渠道收入增长。 除此之外，Google 还帮助零售商变得完全由数据驱动，并提出建议（基于数据）以提高运营效率。 这可以通过利用 GCP，Chrome Enterprise 和 Android 上的 AI 工具以及整个连接的工具箱来实现。

  • GCP 上的 AI 工具包还将促进需要大量数据和计算能力以及用于构建 AI 管道的过程和接口的研究项目。 例如，谷歌正在帮助 FDA MyStudies 利用现实世界的数据进行生物学研究。 Google Cloud 正在与 FDA 合作开发 MyStudies 应用，并提供了更好，适应性更强的保护和可配置的隐私权策略。 目的是为研究组织提供自动识别和保护个人身份信息的能力。 Google Cloud 将继续投资于各种研究和研究计划，以对该平台进行总体改进，扩大支持的评估数量，并允许与下游分析和可视化工具集成。

  • AutoML Tables 使您的整个数据科学家团队能够以极高的速度和规模在结构化数据上自动构建和部署 ML 模型。 它具有出色的特征工程模型训练函数。 训练开始时，AutoML 表将自动执行某些特征工程任务，例如对输入进行标准化。 数值函数被限制在范围内，以实现更好的模型可靠性，日期时间输入参数的规范化，基本文本处理清除和停止单词删除，并为因变量创建单热编码和嵌入。 AutoML 表在线性，前馈深度神经网络，梯度提升决策树，AdaNet 和各种模型架构的集合上执行并行测试，以确定适合您的数据集的最佳模型架构。 用户将能够使用 StackDriver 日志记录查看 AutoML 表结构，并能够导出测试数据。

  • AI Hub 是即将加入 GCP 的另一个非常有用的功能。 AI Hub 是用于构建最复杂的 ML 管道的一站式设施。 可以使用预配置的笔记本使用一些预训练的模型来构建 AI 应用，以及轻松地训练新模型。 AI Hub 还确保以一致的方式访问相关事件数据集。 还可以在模型开发上进行协作，并利用基于通用框架（例如 TensorFlow）构建的模型。 这极大地促进了在 GCP 上训练和部署模型。

  • 通过 AI 平台笔记本，可以通过受保护的，公开可用的笔记本实例 URL 轻松管理 JupyterLab 实例。 它将使您能够创建和管理与 JupyterLab 预先打包的虚拟机实例。 AI Platform Notebooks 实例将支持 PyTorch 和 TensorFlow 框架。 这些笔记本将受到 GCP 认证和授权的保护。 AI Platform Notebooks 将随附许多预装的常用软件。

  • AI 平台深度学习容器是 GCP 提供一种访问预训练模型的独特方法，可以在 GCP 上高度优化和一致的环境的帮助下快速对其进行原型化和使用。 这有助于快速构建工作流，并以最小的进入障碍和成本促进实验。 这是使 AI 开发功能完全普及的巨大飞跃。

  • AI 平台数据标记服务是在网络规模标记数据点时利用人类智能的绝佳方法。 组织可以向 Google 请求此服务以手动标记数据集。 当考虑新的用例且初始数据集不可用时，这有助于收集训练和评估数据。 Google 一直致力于在互联网上众包数据集标签的过程。 当我们要处理需要标记的高度安全的数据时，标记服务也很方便。 带有标签服务的接口是一种获取数据标签的安全有效的方法。

总结

在本章中，我们学习了创建 AI 应用的分步方法。 我们讨论了自动发票处理应用的设计和开发。 我们使用 OCR 和 Vision API 将发票 PDF 转换为文本，然后使用发票数据来验证时间表数据。 成功验证后，我们处理了发票。 我们学习了如何使用多种 Google 服务在 GCP 上开发端到端应用。 最后，我们简要讨论了 GCP 即将发布的功能。

第 1 节：Google Cloud Platform 的基础

在本节中，我们将介绍 Google Cloud Platform（GCP）上的无服务器计算基础。 我们还将概述 GCP 上可用的 AI 组件，并向您介绍 GCP 上的各种计算和处理选项。

本节包括以下章节：

  • “第 1 章”，“AI 和 GCP 概述”
  • “第 2 章”，“使用 GCP 组件的计算和处理”

第 2 节：使用 Google Cloud Platform 的人工智能

在本节中，我们将能够使用各种算法执行动手实验。 在第 3 章中，我们将介绍 XGBoost（一种功能强大的算法），以及如何利用它在 Google Cloud Platform（GCP）上构建机器学习应用。 在第 4 章中，我们将介绍 Cloud AutoML，它在 GCP 上提供机器学习即服务。 在第 5 章中，我们将使用 Cloud MLEngine 构建机器学习管道。 在第 6 章中，我们将提供有关使用 Dialogflow 构建会话应用的分步指南。

本节包括以下章节：

  • “第 3 章”，“使用 XGBoost 的机器学习应用”
  • “第 4 章”，“使用 Cloud AutoML”
  • “第 5 章”，“构建大数据云机器学习引擎”
  • “第 6 章”，“使用 Dialogflow 的智能会话应用”

第 3 节：Google Cloud Platform 上的 TensorFlow

张量处理单元（TPU）是 Google Cloud Platform（GCP）上高性能 AI 应用的基本构建块。 在本节中，我们将重点介绍 GCP 上的 TensorFlow。 本节包含三章。 我们将深入介绍 Cloud TPU，以及如何利用它们来构建重要的 AI 应用。 我们还将通过利用 Cloud TPU 构建预测应用，使用 Cloud ML Engine 实现 TensorFlow 模型。

本节包括以下章节：

  • “第 7 章”，“了解云 TPU”
  • “第 8 章”，“使用 Cloud ML Engine 实现 TensorFlow 模型”
  • “第 9 章”，“构建预测应用”

第 4 节：构建应用和即将发布的功能

本节总结了从前几章获得的所有知识。 它由一章组成。 我们将使用 Google Cloud Platform（GCP）上的各种组件来构建端到端的 AI 应用。 本章提供了使用 GCP 快速构建生产就绪应用的一般过程。

本节包括以下章节：

  • “第 10 章”，“构建 AI 应用”
posted @ 2026-03-25 10:26  布客飞龙II  阅读(0)  评论(0)    收藏  举报