人工智能驱动的商业智能-全-

人工智能驱动的商业智能（全）

原文：zh.annas-archive.org/md5/1c2bd2ead739ce717d4b4823c075d9da

译者：飞龙

协议：CC BY-NC-SA 4.0

序言

流行文化对我们看待人工智能的方式产生了巨大影响。如果有什么东西可以像《黑客帝国》和《终结者》等科幻电影教给我们的，那就是人工智能会追求我们，并且 AI 具有人类的触感。阿诺德·施瓦辛格的《终结者》向我们展示了一个 AI 转变为人类的样子。从《黑客帝国》中，我们了解到我们可能甚至都不会意识到我们的生活被一个高级人工智能控制着。

尽管我认为这两个观点都有问题，但我确实相信它们在商业智能（BI）的背景下传达了一些真理。人工智能正在向我们靠拢，它可能会有人的触感。但在深入讨论之前，让我们首先澄清一些关键术语。什么是 BI？BI 很难定义，因为这取决于你问谁，在什么时候以及在什么背景下。

然而，在本书的背景下，商业智能的定义相当简单明了。我从系统的角度定义 BI：商业智能是一个系统或软件，使业务用户和分析师能够从组织内多个来源查看数据，从而更好地做出决策。 因此，当我提到 BI 时，这个术语与微软 Power BI、Tableau 和 Looker 等 BI 系统以及支撑这些系统的基础设施密切相关。

让我们快速浏览一下人工智能（AI），这是我们在本书的过程中将会更广泛地探讨的一个术语。首先，今天 AI 推动着各种业务流程。全球超过 50%的公司正在进行 AI 之旅，至少有一些小型用例或早期的概念验证（PoC）项目。最受欢迎的 AI 用例包括以下内容：

• 搜索引擎

• 流失预测

• 需求预测

• 文档处理

• 预测性维护

• 客户细分和个性化

• 制造业中的质量控制和过程监控

如果你看看 AI 用例的广泛性，认为 AI 倡议的影响会跳过 BI 领域是愚蠢的。它是不可避免的，只是时间问题，传统 BI 任务的一部分，如规划和预测，将被 AI 超越。如果你试图在数据中找到模式胜过 AI，祝你好运！你可能会失败。

其次，当我们谈论人工智能时，我们常常想到技术将会取代我们的工作。但是，这种担忧真的有多现实呢？请问你自己，你认为自动化的端到端 AI 系统或机器人何时能够足够好，以至于完全取代你每天 100%的工作？再过五年？十年？永远都不会？另一方面，你认为你身边的同事何时能够利用人工智能在重要任务上超越你？明年？下个月？或者说这个人已经在公司里了？重要的是要意识到，人工智能本身并没有取代我们的工作。相反，懂得如何利用人工智能的人正在进入组织并改变现状。这就是数据科学家出现的背景。

就在 2008 年“数据科学”一词被创造出来后不久，一批渴望成为数据科学家的人开始涌现，他们接受各种各样的培训，从在线课程和训练营到专业的大学学位。他们被世界领先公司聘用，希望利用数据产生有意义的业务影响。数据科学家甚至被《哈佛商业评论》称为“世纪最性感的工作”。¹

突然间，“传统”的数据专业人士，如业务分析师和 BI 专业人士，发现自己被边缘化，而新的数据科学家们被引入来处理激动人心的 AI 用例。这导致了两方之间的脱节。

当我成为企业组织中的第一位数据科学家时，我面临着来自高层管理层的高期望，也面临着更“传统”的数据部门的怀疑眼光。我必须承认，一开始确实很艰难。当我首次查看公司的数据仓库时，我想，从我所谓的“小数据”生成静态报告会有多难呢？另一方面，我的 BI 同事对我的工作也持怀疑态度：如何在没有大批专家的支持下，从原始数据源中可靠地生成单一指标？又如何在没有固定的项目范围和明确定义的可交付成果的情况下工作呢？

双方付出了相当大的努力才能理解彼此的目标、挑战和技能。但最终，一切顺利进行了下去。比如，BI 团队帮助我更好地理解如何在考虑 IT 系统和业务流程的持久变化的情况下，如何始终一致地计算指标。另一方面，我提出了一些技术建议，可以帮助我们提供更好的预测，获取更快的洞察力，并通过自动化来提供更好的 BI 体验。

现在是打破组织中“数据部落”之间隔阂的时候了，并将它们聚集起来，产生最深远的影响。我写了这本书，帮助 BI 方面的人了解他们如何从数据科学家的成果（例如模型和算法）中受益，以及如何利用机器学习（ML）来改善他们的 BI 体验。此外，我将解释识别良好 AI 用例的相关方法论，并说明如何以敏捷的方式实施它们，这样你就可以直接开始并将你的 BI 推向新的高度。

为了实现这一目标，我不会过多关注培训或部署 ML 模型等细节，这些事情可以交给数据科学家来处理。相反，你将会发现如何有效地使用这些模型，为你的目的建立第一个原型或快速的概念验证。多亏了 AI 即服务（AIaaS）和自动化机器学习（AutoML）等技术，我们能够涵盖大量 AI 服务，而不必过多担心底层细节。

本书不会把你变成一名数据科学家，但它会让你更接近理解他们的角色以及他们如何在你的工作中帮助你。你将充分利用你已有的知识，学会如何有效地将 AI 服务实施到你自己的工作流程和仪表板中。在本书结束时，你应该能够更有效地与你的数据科学同事合作，甚至自己完成一些真正的数据科学任务。

谁应该阅读本书

如果你已经是一名经验丰富的数据专业人士或一个数据精通的商业人士，在一个组织中，本书将为你提供最大的价值。我假设你对你的业务数据（或者至少是你工作的部分）相当了解，并且你意识到它可能存在的问题和注意事项。作为 BI 专业人士、业务分析师、数据分析师或数据密集型软件开发人员，你对你组织数据在特定用例中的价值有很好的理解。

你仍然想弄清楚的是 AI 如何为你的业务增加价值，改进流程或提供更好的见解。你希望通过自己建立端到端的 AI 用例，或者至少从头到尾理解它来获得实际操作经验。你还不是 AI 专家，但你想在这个领域学习更多。

要充分利用本书，不要害怕自己动手编程。虽然我们在大多数情况下将使用无代码工具，但在某些领域，运行小型 Python 或 R 脚本来确保顺利运作会更加简单。例如，我们将从 HTTP REST API 中获取数据，以便将 AI 预测集成到我们的仪表板中。或者我们将在 Python 的 pandas 或 R 的 Tidyverse 中进行一些基本的数据处理。如果你愿意学习这些实践中的一些内容，本书将为你提供一切所需，使你能够独自创建第一个 AI 用例原型版本，无需任何指导，感谢现成的代码模板。

虽然我不假设你在技术上有多少基础，但我希望你对基本的数据分析工作流程有所了解。例如，你应该知道如何跨多个维度分析数据，创建折线图和柱状图，并从概念上理解 CSV 文件的工作原理。像描述性统计或线性回归这样的术语不应该让你感到太吃惊。

本书中所有的 BI 示例都使用 Microsoft Power BI 展示。如果你已经了解 Power BI，这是一个很大的优势。如果不了解，本书将介绍主要概念，但可能值得阅读下一节列出的附加资源之一。

Microsoft Power BI 和 Azure

虽然本书中所有概念和方法都被写成通用的，但是练习都是基于单一技术堆栈进行解释的。对于本书的目的，我使用了 Microsoft 软件，特别是 Power BI Desktop 作为 BI 前端和 Microsoft Azure 作为云和 AI 服务。如果您更喜欢其他工具，您应该能够轻松切换上下文，因为大多数界面和工作流在其他 BI 工具（如 Tableau 和 Qlik）或来自 Amazon Web Services 或 Google Cloud Platform 的云 AI 服务中都非常相似。

要遵循本书中的示例，您需要访问以下软件：

Microsoft Power BI Desktop

免费版本足以跟随示例。您可以从其网站下载 Microsoft Power BI。如果您以前没有使用过 Power BI，可以查看“Power BI 简介”指南。

Microsoft Azure 云服务

对于本书，我们将使用 Microsoft Azure 云平台的 AI 服务。您应该可以完全在免费订阅层内工作。如果您还没有 Azure 账户，可以注册一个免费 Azure 账户。然而，根据您运行练习的频率和数据集的大小，可能会触及免费层的边界。当您对任何相关费用有疑问时，请查看 Microsoft Azure 的定价计算器。

学习目标

到本书结束时，您应该理解以下内容：

• AI 如何在 BI 环境中产生业务影响

• 商业智能中 AI 的最重要用例

• 如何通过快速原型设计开始使用 AI

• 在 AI 背景下可用的原型工具有哪些

• 如何在 BI 背景下构建 AI 驱动的解决方案

• 如何构建端到端原型以验证 AI 投资回报

• 如何从原型转向生产环境

您将能够完成以下内容：

• 使用 AutoML 进行自动分类和改进预测

• 实施推荐服务以支持决策制定

• 使用自然语言处理服务从大规模文本数据中提取见解

• 使用计算机视觉服务从文档和图像中提取信息

• 为 AI 驱动的仪表板原型构建交互式用户前端

• 实施一个端到端的案例研究，构建一个由 AI 驱动的客户分析仪表板

本书导读

现在您了解了本书的背景及我希望您能够实现的目标，请让我们来看看它的结构。

本书分为两部分。第一部分（从 第一章 到 第四章）为你提供理论基础。第二部分（从 第五章 到 第十一章）提供实际示例，展示如何通过 AI 构建更好的仪表板和预测，以及如何借助 AI 解锁非结构化数据。

第一章，“利用 AI 创造业务价值”，探讨了 AI 对商业智能（BI）景观的影响，以及如何在 BI 上下文中典型地使用 AI。你还将了解一个框架，帮助你根据业务影响优先考虑 AI/ML 使用案例。

第二章，“从 BI 到决策智能：评估 AI 项目的可行性”，着重于 AI 项目的技术可行性。你将了解典型的 AI 解决方案模式，并直观地了解 AI 服务是如何构建的。最终，你将能够评估一个 AI 项目的可行性，以便为 BI 使用案例创建优先级使用案例路线图。

第三章，“机器学习基础”，涵盖了一些基础的机器学习概念，使你不仅能应用 AI 技术，还能理解它们的作用及其在更大图景中的角色。我们还将涵盖一些机器学习的基本陷阱。

第四章，“原型”，向你介绍了敏捷项目管理和数据科学中最强大的工具之一：原型。你将学习原型的定义、其重要性以及如何为 AI 系统构建具有影响力的原型。

第五章，“AI 助力的描述性分析”，开启了本书的第二部分，即实战部分。你将学习如何实施 AI 能力，帮助你更快地进行描述性分析，并提供更直观、更无缝的方式与大数据集交互。

第六章，“AI 助力的诊断性分析”，进一步不仅描述数据，还通过支持诊断性分析来理解数据，自动揭示有趣的模式，让你有更多时间专注于数据的解释。

在 第七章，“AI 助力的预测性分析”，你将学习如何超越历史洞察，通过各种分类、预测和异常检测示例实施 AI 助力的预测性分析。

第八章，“AI 助力的指导性分析”，进一步不仅预测结果，还通过推荐系统提供下一步最佳操作建议。

在第九章，“利用 AI 处理非结构化数据”中，您最终将学会如何离开表格数据的领域，探索 AI 如何帮助您自动处理文本，文档和图像文件等非结构化数据。

第十章，“汇聚一切：构建 AI 驱动的客户分析仪表板”，将所有这些汇聚在一起。你将构建一个 AI 驱动的客户分析仪表板，基于你在前几章学到的各个构建块。

庆祝你的第一个 AI 驱动的 BI PoC 成功之后，第十一章，“迈向下一步：从原型到生产”讨论了从原型到生产所需的下一步工作，并总结了你所学到的内容。

本书有一个配套网站，其中包含所有实用练习中使用的演示文件和代码片段。务必将此网站加入书签以顺利跟进。每章都直接指向此网站上的资源。

准备好了吗？拿起钥匙，坐上前排座位。我会在你身边提供指导，带你穿越 AI 驱动的商业智能的风景线。

本书使用的约定

本书中使用以下排版约定：

斜体

指示新术语，网址，电子邮件地址，文件名和文件扩展名。

常量宽度

用于程序清单，以及段落内引用程序元素，如变量或函数名称，数据库，数据类型，环境变量，语句和关键字。

常量宽度加粗

显示用户应按字面输入的命令或其他文本。

常量宽度斜体

显示应用程序应替换为用户提供的值或根据上下文确定的值的文本。

提示

此元素表示提示或建议。

注意

此元素表示一般说明。

警告

此元素表示警告或注意。

使用代码示例

补充资料（代码示例，练习等）可在https://www.aipoweredbi.com下载。

如果您有技术问题或在使用代码示例时遇到问题，请发送电子邮件至bookquestions@oreilly.com。

这本书旨在帮助您完成工作。一般来说，如果此书提供示例代码，则可以在您的程序和文档中使用它。除非您复制了代码的大部分内容，否则不需要联系我们请求许可。例如，编写一个使用本书中几个代码片段的程序不需要许可。销售或分发 O’Reilly 书籍的示例代码需要许可。引用本书回答问题并引用示例代码不需要许可。将本书大量示例代码整合到产品文档中需要许可。

我们感谢您的支持，但通常不需要署名。署名通常包括标题、作者、出版商和 ISBN。例如，“AI-Powered Business Intelligence by Tobias Zwingmann（O’Reilly）。版权 2022 Tobias Zwingmann，978-1-098-11147-2。”

如果您认为您使用的代码示例超出了合理使用范围或上述许可，请随时与我们联系：permissions@oreilly.com。

O’Reilly 在线学习

注意

超过 40 年来，O’Reilly Media提供技术和商业培训、知识和见解，帮助公司取得成功。

我们独特的专家和创新者网络通过书籍、文章和我们的在线学习平台分享他们的知识和专长。O’Reilly 的在线学习平台为您提供按需访问的实时培训课程、深度学习路径、交互式编码环境以及来自 O’Reilly 和其他 200 多家出版商的大量文本和视频。有关更多信息，请访问https://oreilly.com。

致谢

写书是男人能接近生育的最接近方式。

Norman Mailer

这句话让我感同身受。不仅因为这本书的写作过程几乎耗时九个月。而主要是因为它让我记起了首先要感谢一切的人：我的家人。

写作意味着牺牲。你为了屏幕上一堆高度不确定结果的文字，牺牲了大量的时间、精力和其他生活中的事物。因此，不能认为家人支持这种荒谬的努力是理所当然的。我很幸运，一直能够依靠我美妙的妻子Çiğdem 的支持。她的爱、信任和乐观态度使所有这些成为可能，她每天都给我灵感。“谢谢”这两个词无法表达我的感受。你是最棒的。我爱你。

没有我们母亲，我们都不会有什么。因此，我要感谢我的母亲 Anett，特别是我的岳母 Gülten，她们始终支持我们，从不让我们失望。如果不是因为她们，我们就不可能在抚养地球上最美丽的三个孩子的同时追求我们的梦想。

我还要感谢整个 O’Reilly 团队让这本书变为可能。我特别要感谢 Michelle Smith 对我的支持和对我的信任。我很高兴她把这个独特的机会委托给我来参与这样一个美妙的项目！我还要特别感谢我的开发编辑 Rita Fernando，感谢她的宝贵反馈、意见和全面支持。没有她的帮助和我们的定期会议，我会多次陷入困境！感谢你成为一位出色的写作教练，并在整本书的每一章中指导我。最后但同样重要的是，Chris Faucher，感谢你致力于将一堆狂野的手稿变成这样一本美丽的书，并为它注入生命！我无法感激你的帮助。

写书有很多途径。我的开始于 George Mount。如果我们从未相遇，如果他没有提到这个主题，如果他没有鼓励我写作——这本书将永远不会问世。这是一个美好的例子，说明大事从小步骤开始。我很感激能够和你一起迈出那第一步，George！

审查技术书籍几乎和撰写它一样困难。因此，我要感谢 George Mount、Donald Farmer 和 Michael Norris 对内容进行了批判性审查，并提供了他们详细关注的宝贵反馈。

这本书涵盖了如此多的主题和概念，以至于一个人不可能知道它们全部。许多人与我共同工作或给予我反馈，使这本书成为今天的样子。其中包括 Ram Kumar、Alexander Niltop、Franco Arda、Piotr Menclewicz、Felix Urban、Marek Drob 等许多人。非常感谢你们！

最后，我想感谢所有为开源生态系统做出贡献的人，比如 Python、R 等项目及其衍生物。没有你们的基础工作，单单将这么多概念融合到一本实用书中将是不可能的。

¹ Thomas H. Davenport 和 DJ Patil，《数据科学家：21 世纪最性感的职业》，《哈佛商业评论》（Harvard Business Review），2012 年 10 月，https://hbr.org/2012/10/data-scientist-the-sexiest-job-of-the-21st-century

第一章：利用 AI 创造商业价值

在本章中，我们将探讨为什么 AI 在商业智能（BI）中的采用比以往任何时候都更加重要，以及 AI 如何可以被 BI 团队利用。为此，我们将确定 AI 可以支持 BI 任务和流程的典型领域，并探讨底层的机器学习（ML）能力。在本章的最后，我们将介绍一个实用的框架，让您能够将 AI/ML 能力映射到 BI 问题领域。

AI 如何改变 BI 景观

在过去的 30 年中，BI 已经逐渐成为公司数据驱动文化的推动力量，至少直到关注点转向数据科学、机器学习和人工智能。这是怎么发生的？对于您的 BI 组织意味着什么？

回顾 70 年代决策支持系统第一时代的开始，我们看到由 IT 专家使用的技术系统从小规模（按今天的标准）数据集中获得洞察力。这些系统逐渐演变，最终在 1980 年代末被称为BI。数据分析是新兴的，因此即使是最基本的洞察力也显得令人瞠目。突然间，决策不再基于直觉，而是基于实际数据，这使得在复杂的商业场景中能够做出更安全和更大胆的决策。

二代 BI 始于 2000 年代中期，以自助式分析为主导。大量新工具和技术使非技术人员能够更轻松地切分数据、创建可视化效果，并从日益庞大的数据源中提取洞察力。这些主要由大型软件供应商如 Oracle、SAP 和 Microsoft 提供，同时也促进了像 Tableau Software 这样的小众 BI 公司的增长。电子表格软件也越来越多地整合到整体数据分析生态系统中，例如，通过允许业务用户通过 Microsoft Excel 中的数据透视表访问 Microsoft SQL Server 系统上的在线分析处理（OLAP）立方体。

如今大多数大公司仍然停留在 BI 的第二阶段。为什么会这样？首先，近年来许多技术努力都集中在技术上管理底层数据的指数级增长，这些数据是 BI 系统设计用来处理和从中获取洞察力的。其次，数据量的增加，主要是由互联网和数字服务的增长驱动（见图 1-1），导致了越来越多缺乏数据素养的人，这些人熟练掌握处理高维数据集和相应工具（在这种情况下，不是 Excel）的能力。

图 1-1. 近年数据增长。来源：Statista

相较于消费市场，AI 应用在专业 BI 空间中仍然服务不足。这可能是因为 AI 和 BI 人才分布在组织中的不同团队中，如果它们曾经碰面，它们很难有效地进行沟通。这主要是因为这两个团队通常使用不同的语言，并且有不同的优先级：BI 专家通常不会过多地讨论训练和测试数据，而数据科学家很少聊 SQL Server Integration Services (SSIS)包和 ETL（抽取、转换、加载）流程。

然而，基于以下持续的趋势，AI 在 BI 中的采用需求将不可避免地增加：

从数据中获取快速答案的需求

为了保持竞争力并实现增长，组织需要数据驱动的见解。数据分析师面对着探索这个或那个指标，或者检查这个或那个数据集的询问而感到不堪重负。与此同时，业务用户需要从数据中快速、轻松地获取答案的需求也在增加。如果他们可以向谷歌或亚马逊 Alexa 询问某家公司当前的股价，为什么他们不能向他们的专业 BI 系统询问昨天的销售数据呢？

见解的民主化

业务用户已经习惯于通过自助 BI 解决方案从数据中获取见解。然而，今天的数据往往过于庞大和复杂，以至于不能纯粹依靠业务部门的自助分析来处理。数据量、种类和速度的增加使得非技术用户难以使用本地计算机上的熟悉工具来分析数据，甚至有时几乎不可能。为了在整个组织中继续推广见解的民主化，需要易于使用的 BI 系统，并自动向最终用户展示见解。

ML 服务的可访问性

尽管 AI 在组织内的使用持续增加，但对于更好的预测或更好的预测的期望也在增加。这在 BI 领域尤为明显；低代码或无代码平台使得将机器学习技术提供给非数据科学家比以往任何时候都更容易，并迫使 BI 团队成员将预测性见解整合到其报告中。数据科学领域的同样进展也预计会在 BI 领域中更早或更晚发生。

为了更好地了解 BI 团队如何利用 AI，让我们简要回顾由Gartner发布的分析见解模型（Figure 1-2）。

每个 BI 或报告基础设施的核心功能是通过对历史数据进行描述性和诊断性分析来提供回顾和洞察力。这两种方法对所有进一步的分析过程至关重要。

首先，组织需要了解过去发生了什么，以及从数据角度驱动这些事件的原因。这通常被称为基本报告，具有一些洞察功能。技术难度和复杂性相对较低，但信息的内在价值也相对较低。不要误会：可靠和结构化的报告仍然是业务数据分析最重要的支柱，因为它为更高级别的概念奠定了基础，并引发进一步分析的问题或问题。事实上，洞察模型的每个阶段都包含所有先前的阶段。在弄清楚您的历史数据之前，您无法进行预测性分析。

图 1-2. 洞察类型和分析方法。来源：Gartner

考虑以下例子。某电信公司有订阅每月服务的客户。每月会有一定数量的客户选择不续订服务合约，退出业务关系——这种现象称为客户流失。

商业智能系统最基本的要求是了解过去有多少客户流失，以及这种流失如何随时间发展。描述性分析将为我们提供必要的信息，以了解流失率随时间的变化情况，以及我们是否确实存在问题。表 1-1 给出了这种情况可能看起来如何的一个示例。

表 1-1. 时间序列的流失率（描述性分析）

	Q1	Q2
月份	2022 年 1 月	2022 年 2 月
流失率	24%	26%

这些信息的内在价值相当有限。在这个层面上，分析实际上无法真正解释发生的现象或者如何处理它。但至少它能指示我们是否存在问题：从表中我们可以看出，Q2 的流失率似乎显著高于 Q1，因此可能值得进一步研究。

这就是诊断分析发挥作用的地方。我们现在可以深入挖掘，将交易销售数据与更多关于客户的信息丰富起来，例如客户年龄组，如表 1-2 所示。

表 1-2. 时间序列和客户细分的流失率

客户年龄	Q1 流失率	Q2 流失率
18–29	29%	41%
30–49	28%	30%
50–64	24%	25%
65 岁及以上	20%	19%

这种分析将告诉我们，65 岁及以上的客户的流失率似乎保持稳定。另一方面，年轻客户更有可能流失，并且这一趋势在 Q2 有所增加。经典的商业智能系统可以让我们跨多个变量分析这些数据，以了解到底发生了什么。

在许多情况下，企业可以通过这些分析单独找到导致手动操作或决策的有价值模式。这就是为什么这个阶段仍然如此关键，并且将始终非常重要的原因。

预测分析将分析推向更深层次，并回答一个问题：鉴于我们从过去所知的所有模式都在重复，未来会发生什么？因此，预测分析为数据增加了另一层价值和复杂性，正如您可以在表 1-3 中看到的那样。

表 1-3. 估计客户流失概率（预测分析）

客户 ID	年龄	计划	价格	活跃月数	流失概率
12345	24	A	$9.95	13	87%
12346	23	B	$19.95	1	95%
12347	45	B	$19.95	54	30%

随着我们离开历史数据的领域，复杂性增加了。我们不再以真假的二元术语提供见解，而是引入某些事件发生概率（流失概率）。同时，我们增加了价值，因为我们将我们从过去所知的一切纳入假设，以预测这将如何影响未来行为。

例如，基于未来流失概率和历史销售数据，我们可以计算公司未来几个季度的预测销售风险，并将其纳入我们的财务计划。或者，我们可以选择那些具有高流失概率的客户，采取有针对性的措施来减少流失风险。

但是我们应该采取哪些行动呢？欢迎来到指导性分析！表 1-4 展示了在实践中可能的情况。在这种情况下，我们增加了另一个维度，下一个最佳优惠，它包括了根据客户个人资料和历史购买行为推荐的特定折扣或产品升级。

表 1-4. 建议行动（指导性分析）

客户 ID	年龄	计划	价格	经过月数	流失概率	下一个最佳优惠
12345	24	A	$9.95	13	87%	年度合同优惠
12346	23	B	$19.95	1	95%	升级
12347	45	B	$19.95	54	30%	无

当我们研究拥有成千上万客户的组织时，很明显，要从宏观角度优化这些任务，我们需要依赖微观层面的自动化。仅仅通过手动处理所有这些微小的决策并监控我们对每个客户行动的效果是不可能的。这些微小决策的投资回报率（ROI）太低，无法证明手动努力的必要性。

AI 和 BI 完美结合的地方在于此。考虑到 AI 可以指示每位客户的流失可能性，并建议下一步最佳行动。现在，我们可以将这些信息与经典的 BI 指标（如客户的历史收入或客户的忠诚度）结合起来，从而对这些对业务影响最大且成功机会最高的行动做出明智的决策。

因此，AI 和 BI 之间的关系可以用以下公式简要概括：

• 人工智能 + 商业智能 = 决策智能

最有效的 AI 驱动的 BI 应用是将自动化和人工决策相结合。我们将在第二部分实际探讨这一点。现在，让我们具体看看 AI 如何系统地帮助我们改进我们的 BI。

BI 的常见 AI 使用案例

AI 通常可以通过以下三种方式为 BI 增加价值：

• 自动化洞见并使分析过程更加用户友好

• 更好地计算预测和预测

• 使 BI 系统能够从非结构化数据源中提取洞见

图 1-3 提供了这些应用领域如何映射到各种分析方法的高级概述。

图 1-3. AI 能力如何支持分析方法

让我们更详细地探讨这些领域。

自动化和易用性

使 BI 工具本身更加智能和易用将使其对非技术用户更加可用，减少分析师的工作量。这种易用性通常通过底层自动化来实现。

智能算法使得在几秒钟内筛选大量数据并为业务用户或分析师提供有趣的模式或洞见成为可能。如图 1-4 所示，这些例行程序特别适合描述性和诊断分析阶段。

AI 可以帮助发现许多变量之间的有趣相关性或异常观察结果，这是人类可能会忽略的。在许多情况下，AI 还能比人类更好地查看多个指标的组合，而人类通常一次只能专注于一个指标。但自动化和易用性也触及到预测分析阶段，例如通过使用户更轻松地训练和部署自定义 ML 模型。

图 1-4. AI 驱动的 BI：自动化与易用性（应用层）

这里有一件重要的事情需要注意：在这个阶段，AI 的能力通常是集成到应用层中的，也就是您的 BI 软件。因此，您通常不能通过几行 Python 代码将这些能力添加到 BI 平台（与我们在第 7、8 和 9 章讨论的 AI 驱动预测和解锁非结构化数据形成对比）。如果您正在使用像 Microsoft Power BI 或 Tableau 这样的现代 BI 平台，您会在这些工具中找到这些 AI 功能。有时，它们可能是隐藏的，或者发生得如此无缝，以至于您甚至没有注意到 AI 在这里发挥作用。

本节其余部分描述了 AI 在幕后工作，使分析师的生活更加轻松。

利用自然语言处理与数据交互

通过使用 AI 驱动的自然语言处理（NLP）技术，机器能够更好地解释和处理用户的文本输入。例如，假设您想了解上个月的销售结果或去年与今年美国的销售情况。您可能会输入以下查询：

How were my sales in Texas in the last 5 years?

或者

Sales $ in Texas last year vs Sales $ in Texas this year

不需要复杂的代码或查询语言。这种类似于 Q&A 的输入方式使得 BI 对非技术用户更加可访问，对于无法预测每个业务用户可能提出的问题的分析师来说，这也更加方便。大多数用户对这种方法应该很熟悉，因为它类似于使用 Google 等搜索引擎。

无论您的 BI 工具是否内置了 Q&A 工具，这些实现并非都同样有效。事实上，为了确保这些功能在生产环境中可靠运行，需要解决巨大的复杂性问题。分析师必须追踪业务用户提出的问题类型，并验证生成的输出是否正确。必须定义同义词和领域特定术语，以确保系统能正确解释用户提示。与所有 IT 系统一样，这些内容需要持续维护。希望系统能够改进，从而减少背景中所需的手动工作量。

总结分析结果

即使图表看起来似乎不言自明，将关键见解总结在一两行自然语言中也是一个好习惯，可以减少误解的风险。但是，真的有人喜欢在报告或演示文稿中为图表下面似乎显而易见的描述写作吗？大多数人并不喜欢，而这正是 AI 可以帮助的地方。

AI 驱动的自然语言处理不仅可以帮助您解释自然语言输入，还可以根据数据为您生成摘要文本。这些自动生成的文本将包括有关数据的描述性特征以及显著的变化或连续性。以下是 Power BI 自动生成图表说明的示例：

Sales $ for Texas increased for the last 5 years on record and it experienced the longest period of growth in Sales between 2010 and 2014.

正如你所见，这些小型由 AI 生成的文本片段可以让你作为分析师的生活更轻松，并且在向其他利益相关者传达洞见时节省大量时间。此外，它们可以帮助满足屏幕阅读器的辅助要求。

使用自动化在数据中找出模式

你已经看到了 NLP 的能力如何帮助你高效地从数据中获取描述性洞见。下一个逻辑步骤是找出过去发生某些观察的原因，比如为什么德克萨斯州的销售额会增加这么多？

使用诊断性分析，通常需要搜索数据集以探索基础数据分布中的有意义变化。在这个例子中，您可能想要找出某种产品或某个事件是否推动了整体变化。这个过程很快会变得单调乏味和繁琐。AI 可以帮助您减少洞见时间（TTI）。

算法非常擅长识别数据中的潜在模式并将其显现出来。例如，使用 AI 强化工具如分解树或关键影响者分析，您可以快速找出数据中哪些特征导致了整体观察到的效果——即时。在第五章和第六章中，我们将看到使用 Power BI 中 AI 强化功能的三个具体示例，以使您作为数据分析师或业务用户的生活更轻松。

更好的预测和预测

虽然描述性和诊断性分析一直是每个商业智能系统的核心，但迫切的欲望始终是不仅要理解过去，还要预见未来。正如您在图 1-5 中所见，AI 增强功能可以支持最终用户应用强大的预测性和规定性分析方法，基于历史数据实现更好的预测和预测。

这将增加复杂性，因为我们离开了过去的二进制数据领域，引入了关于未来的概率猜测，自然包含许多不确定性。同时，展望价值增加：如果我们即将预测未来，我们可以在现在做出更好的决策。

图 1-5. AI 强化的商业智能：更好的预测和预测（分析层）

现在，也许你之前听说过统计方法，比如回归或自回归积分移动平均（ARIMA），可能是在高中或基础大学课程中听过，现在你可能想知道 AI 有何大不同。请注意以下两个方面：

AI 可以在更多数据和较少人为监督的情况下生成更好的预测。

AI 在其核心利用诸如线性回归之类的老式技术。但同时，AI 可以通过使用随机方法快速找到最优解，而无需大量人工监督，将这些技术应用于复杂数据集。专门用于时间序列预测的算法被设计用于识别大量时间序列数据中的模式。AI 尝试通过特征选择和最小化损失函数来优化预测。这可以导致在短时间范围内获得更好或更准确的预测，或者试图在较长时间内更准确地预测。更复杂的非线性模型可以导致更精细和最终更好的预测结果。

AI 可以在规模上计算预测，以优化决策制定。

预测下一个季度客户总数是不错的。但更好的是根据最近的数据计算数据库中每个客户的流失可能性。有了这些信息，我们不仅可以知道哪些客户可能在下个月流失，还可以优化我们的决策制定。例如，我们可以确定在下个月将流失的所有客户中，应该以市场营销活动为目标的客户。将 ML 与 BI 结合为组织创造了潜在的巨大价值主张。随着自动机器学习（AutoML）和 AI 作为服务（AIaaS）等新技术的推进，我们将在第三章进一步探讨这些 AI 潜力，组织可以减少由于没有足够的数据科学家或 ML 从业者而造成的瓶颈。

AI 增强预测能力或更好的预测能力可以在现有 BI 软件（应用层）中作为一个不可或缺的部分找到。这些能力也可以独立应用，直接在数据库层面（分析层）上进行。这使得它们始终可用，无论您使用哪种 BI 工具。我们在第七章和第八章中探讨如何应用这些技术。

利用非结构化数据

BI 系统通常使用来自企业数据仓库等关系数据库的表格数据。然而，随着所有渠道数字化的增加，我们看到非结构化数据（如文本、图像或音频文件）的使用显著增加。从历史上看，这些形式难以大规模分析供 BI 用户使用。AI 正在改变这一情况。

AI 利用诸如计算机视觉或 NLP 等技术可以增加可用和机器可读数据的广度和深度，以访问新的、先前未开发的数据源。非结构化数据，例如原始文本文件、PDF 文档、图像和音频文件可以转换为与给定架构匹配的结构化格式，例如表格或 CSV 文件，然后可以通过 BI 系统进行消耗和分析。由于这是在数据摄取层发生的事情，这一过程最终将影响 BI 平台的所有阶段（见图 1-6）。

通过将这些文件纳入我们的分析中，我们可以获得更多信息，这些信息可能导致更好的预测或更好地理解关键驱动因素。第八章将为您演示这在实践中的工作方式。

图 1-6. AI 驱动的 BI：解锁摄取层的非结构化数据

对 AI 和机器学习的直觉理解

我们已经讨论了 AI 如何与 BI 一起使用。但要实际构建 AI 驱动的产品或服务，我们需要深入挖掘并理解 AI 的本质以及它能够（和不能够）实现的内容。

那么 AI 到底是什么？如果你问 10 个人，你可能会得到 11 个答案。在本书的过程中，了解这个术语实际含义是非常重要的。

让我们首先承认，术语人工智能并不新鲜。事实上，这个术语可以追溯到 20 世纪 50 年代的军事研究实验室。自那时以来，研究人员尝试了许多方法来实现使计算机或机器复制人类智能的目标。如图 1-7 所示，自其创建以来，AI 已经形成了两个广泛的领域：通用 AI 和狭义 AI。

图 1-7. 人工智能的发展

通用 AI，或强人工智能，是指旨在解决系统以前从未见过或暴露过的任何给定问题的技术，类似于人类大脑的工作方式。通用 AI 仍然是一个热门的研究课题，但它仍然相当遥远；研究人员仍然不确定是否会达到这一目标。

另一方面，狭义 AI指的是一种相对特定的解决方案，能够解决其设计和训练的单一、明确定义的问题。狭义 AI 在最近的研究和实际或业务相关领域中推动了我们所见的所有 AI 突破。

在狭义人工智能的核心，有一种方法在商业影响和发展进展方面突出：机器学习。事实上，在本书中谈论 AI 时，我们看到了通过机器学习实现的解决方案。这就是为什么我在本书中会将AI和ML互换使用，并将 AI 视为一个相当广义的术语，具有相当直接的意义：AI 是一个工具，用于构建（看似）智能的实体，能够通过机器学习解决特定任务。

现在 AI 和 ML 之间的关系希望已经有了一些更清晰的认识，让我们讨论一下 ML 的实际内容。ML 是一种编程范式，旨在为特定目的找出数据中的模式。机器学习通常有两个阶段：学习（训练）和推断（也称为测试或预测）。

机器学习的核心思想是在历史数据中找到模式，以解决特定任务，例如将观察结果分类、评分概率或找到物品之间的相似性。机器学习的典型用例是分析历史客户交易数据，计算客户流失的个体概率。通过推断，我们的目标是根据从历史数据中学到的一切，为新数据点计算预测。

为了增强您对机器学习的理解，让我们拆解我们定义的核心组件：

一种编程范式

传统软件是通过编写规则来构建特定程序的。如果您开发了一个客户支持系统，您需要定义客户提交支持票后应该发生的所有逻辑（例如通过电子邮件通知支持代理）。您记录所有规则，将它们放入程序中，并发布软件。

然而，机器学习颠覆了这种编程范式。与其将规则硬编码到系统中，不如提供足够的输入示例和期望的输出（标签），让机器学习算法为您提出规则集。虽然这种设置不适合构建客户支持系统，但对于某些规则未知或难以描述的场景非常有效。例如，如果您想根据诸如工单文本、客户类型和工单创建日期等多种特征对客户支持工单进行优先级排序，机器学习算法可以仅通过查看过去的工单如何进行优先级排序来为您提出优先级模型。与手工制作复杂的 if-then-else 逻辑不同，机器学习算法将在一定的计算时间和计算资源下找出解决方案。

数据中的模式发现

为了在数据中找到有用的模式，三个重要的概念共同发挥作用：算法、训练和模型。一个 ML 模型 是一组规则或数学函数，将在给定特定数据输入时计算输出值。可以将其视为一堆加权的 if-then-else 语句。ML 算法 描述了机器必须遵循的计算过程，以获得这个模型。而术语 训练 意味着在现有数据集上多次迭代，以找到特定数据集的最佳模型，从而产生低预测误差并对新的未见数据输入具有良好的泛化能力，以便该模型可以用于特定目的。

一个特定的目的

ML 任务通常根据它们试图解决的问题进行分类。主要领域包括监督学习和无监督学习。虽然这不是一本关于 ML 基础知识的书籍，但我们在第三章中稍微详细地涵盖了它们。

如果我们考虑所有的组成部分，在实际情况中，机器学习从业者的任务是尽可能收集与感兴趣情况相关的数据，选择并优化算法来创建情况模型，然后训练模型以确保其足够准确以便有用。

有关 AI 和 ML 最大的误解之一是，企业领导经常认为 AI 和 ML 难以实施。虽然设计和维护特定的高性能 ML 系统是一项复杂的任务，但我们也必须承认 AI 已经变得商品化和商业化，即使非 ML 专家也可以使用现有的代码库或无代码或低代码解决方案构建性能良好的 ML 解决方案。在第四章中，您将了解更多关于这些技术的信息，以便您可以自己实施 ML 解决方案，而无需数据科学家或 ML 工程师的帮助。

AI 这个术语对于那些真正不了解其含义的人来说可能显得可怕和令人畏惧。事实上，我们离《终结者》和通用人工智能还有很长的路要走。如果你希望在你的组织内部获得更广泛的接受和采用 AI 解决方案，你需要用友好和非技术性语言来解释 AI 是什么。将 AI 视为自动化或能够基于过去的学习实施更好决策的方式应该让你足够放心，以便发现潜在的良好用例并与同事分享这种精神。

将 AI 用例想法映射到业务影响

现在您已经更多地了解了 AI 以及它如何应用于 BI，您可能已经对将 AI 应用于自己的用例有一些想法。为了找出哪些潜力最大且值得深入研究，我们将看一下一个您可以用来进行精确定位的故事映射框架。这个框架受到敏捷项目管理技术的启发，应该能帮助您结构化思维过程。

这个 AI 故事映射框架的核心思想是对比过程的当前实施与 AI 支持的实施。这种技术将为您提供一个高层次的全面概述，说明不同之处，您需要改变哪些事物，并且最重要的是，帮助您结构化思维过程。

创建故事板很简单。拿一张空白纸，将其分成一个包含四列和两行的表格。四个上方的方框将映射您的当前过程，而下方的方框将描述未来预期的实施。从左到右命名列：设置、行动、结果、结果。图 1-8 展示了您的纸张应该如何看起来。

图 1-8. 故事板模板

要创建您的故事板，您需要从左到右填充列。您从第一行开始，概述给定过程的当前实施方式如何沿以下维度运作：

设置

描述了过程如何开始，并列出您的假设、资源或起始标准。

行动

包含所有由设置中列出的资源执行的任务和操作项。

结果

描述了过程的实际工件。确切地说，正在生成、创建或修改什么？

结果

包含结果对业务的影响，以及结果的后续步骤。例如，在仪表板中显示报告是一个结果，但仅仅这样做并没有任何影响。影响是根据仪表板显示的信息，以及由谁执行这些信息而产生的。

在下一步中，您将对预期未来实施做同样的操作。最终，您将对比新旧方法，更清楚地了解事物将如何变化以及这些变化可能产生的影响。为了更好地说明这项练习的工作原理，图 1-9 展示了我们客户流失用例的故事板示例。

图 1-9. 故事板示例

让我们一起走过我们的故事板示例。我们将从左上角开始，为现有过程的当前设置铺平道路。

目前，客户流失是由销售人员检测到的，他们在定期会议中与现有客户交谈时获得反馈，或者由客户支持员工接收到来自客户的反馈，称某些事情并不如他们希望的那样运行，或者他们遇到其他问题。在下一步中，客户支持或销售人员尝试直接与客户解决问题，例如提供入职帮助。

这个过程的主要结果是客户支持（希望能够）解决客户的现有痛点和问题。痛点可能会报告给管理层或投诉管理系统。因此，一旦问题解决，客户很有可能会继续使用当前的服务。

让我们将这一点与启用 AI 的实施对比，从左下角开始，然后向右进行。在我们的设置中，我们将收集关于客户使用各种产品和服务方式的历史数据，并标记流失和未流失的客户。我们还将邀请销售和客户服务的工作人员与分析师分享他们的领域专业知识。

我们的下一步行动将是分析历史数据，以确定数据集中是否可以识别客户流失的关键驱动因素。如果可以，我们将开发一个预测模型，为我们数据库中的每个客户计算个体流失风险，并提供为什么可能发生流失的见解。

结果，这些流失风险评分和流失原因将被呈现给业务部门。这些信息可以与其他指标（如客户收入）混合，并在客户关系管理（CRM）或商业智能（BI）系统中呈现报告。

有了这些信息，客户支持现在可以主动联系有高流失风险的客户，并尝试在客户实际上发出支持票据或完全不发出支持票据的情况下解决问题或消除障碍。因此，随着时间的推移，整体流失率应该会降低，因为组织可以更好地规模化地解决客户流失的原因。

通过现有和新流程的 story map，你应该更有信心描述可能的 AI 解决方案的外观，它可能带来的好处，以及是否值得采用新方法，即通过替换或与现有流程融合来实现。作为练习，使用 storyboard 模板并映射两到三个 AI 使用案例的想法。哪些想法对你来说似乎最有前景？

总结来说，storyboard 的目的是为每个使用案例提供一个简单的一页，直观地对比现有解决方案与新解决方案之间的差异和好处。使用 storyboard 将有助于你构建思维过程，并在优先考虑 AI 使用案例时提供坚实的起点。

摘要

在本章中，您了解到人工智能如何改变商业智能（BI）领域，这是由业务用户需要从数据中更快地获取答案、对洞察力民主化需求增长，以及整体机器学习工具可大规模使用性的增加所推动的。我们探讨了 AI 如何通过自动化和更好的可用性、改进的预测能力以及对新数据来源的访问来支持 BI，从而赋予人们做出更好决策的能力。到目前为止，您应该对 AI 和机器学习的工作方式及其今天的能力有了基本的理解。您还学会了使用一个框架来帮助结构化您的思维过程，并构思机器学习用例的想法。

在下一章中，我们将深入探讨 AI 系统的设计及在您的商业智能服务中实施这些技术之前需要考虑的因素。

第二章：从 BI 到决策智能：评估 AI 项目的可行性

在前一章中，您了解了 ML 能力如何推动业务影响。但是，要创建优先考虑用例的路线图，并对哪些用例作为优先考虑进行知情决策，我们需要考虑另一维度的标准：可行性。

本章将深入探讨 ML 基础知识，以帮助您评估特定 AI 用例的复杂性和整体可行性。我们将基于数据、基础设施/架构和伦理三个主要主题探讨可行性。因此，您将能够创建首个基于 AI 的 BI 用例路线图的版本。

优先考虑数据

AI 项目需要与经典 BI 项目不同的思维方式。大多数 BI 项目通常以相对直接的方式完成，往往遵循传统的瀑布模型：定义要展示的指标，设计数据模型，集成数据，并确保它正常运行（通常已经足够困难了）。如有必要，进行迭代。完成工作。

AI 项目的主要区别在于，即使在理想情况下，结果也是高度不确定的。我们简单地不知道 AI 模型是否能在我们的数据上运行，并且是否足够好以提供价值，直到我们用真实数据进行测试。

因此，AI 项目通常需要在类似敏捷的项目框架中进行多个较短的迭代周期，如数据挖掘的跨行业标准过程（CRISP-DM）所示，如图 2-1。例如，CRISP-DM 建议在业务理解和数据理解阶段之间进行迭代，直到找到值得解决并有可能解决的业务问题，考虑到您拥有的数据。类似地，可能首次看起来数据看起来不错，但是在评估阶段才意识到无法开发出足够好的模型。这时您需要回到业务理解阶段，尝试重新阐述问题陈述。

图 2-1。CRISP-DM 模型。来源：维基媒体共享资源

在处理 AI 项目并实现投资回报率的常见方法是先开发最小可行解决方案或原型，仅在验证原型后才启动大规模项目。我们在第四章中更详细地讨论了这个主题。

尽管如此，在构建原型之前，您可以进行某些事情。考虑您想要解决的问题以及将用于解决问题的数据。在这个阶段，您无需担心像数据库或数据格式之类的技术复杂性。相反，我建议您从高层次查看数据，并用简单的语言描述您试图实现的目标。

在我们先前的客户流失示例中，您的目标描述可能如下所示：

• 我们想主要使用 CRM 和企业资源规划（ERP）系统中的历史数据来预测下个月的客户流失。

你关于这个用例的基本数据问题可能如下：

• 您的用例需要什么数据？

• 这些数据是否可用？如果可用，具体有哪些（表格、媒体文件、文本）？

• 您是否可以访问这些数据？

• 谁可以访问它？

• 公司拥有它吗，还是你需要购买它？

• 你是否有法律权限使用这些数据？

所有这些问题仍然与像“这不在数据仓库中”或“我们不能分期 PNG 文件”等问题无关。如果您无法回答这些关于数据的基本问题，建议不要继续进行数据评估。而是更好地专注于回答这些问题：您如何获取数据？您需要与谁交谈？等等。

但是假设你可以回答这些基本问题，并且数据在理论上似乎是可用的。在这种情况下，在创建原型之前，值得更详细地探索一些数据特征。

并不存在系统性地完成这一工作的黄金标准。然而，一个流行的框架是 4V 框架，我喜欢它的简单性。我们将在下一节更详细地探讨这个框架。

使用 4V 框架评估数据准备情况

4V 框架帮助你更好地理解数据的特征，而不需要过于技术化地考虑体积、多样性、速度和准确性这四个维度。在特定阶段，这种方法应该能帮助你考虑哪些用例更实际或不太实际。再次强调，在你回答更基本的问题之后，例如你是否真的拥有这些数据，以及你是否被允许使用它之后，你应该进行这种分析。

Volume表示在任何给定时间内可用的数据量。您可以以至少两种方式解释这一点：首先，作为观察值（示例、行数），其次，作为数据中包含的信息深度（属性、列数）。

不同类型的 ML 需要不同数量的数据，因此合理估计“足够”数据是困难的。然而，为了给您至少提供一个粗略的概念，表 2-1 列出了各种 ML 技术的数据要求。

在大多数情况下，随着数据量的增加，模型表现会更好。因此，几乎总是希望增加更多数据量。然而，单独的数据量并不能自动增加价值。

表 2-1. ML 技术的数据要求

ML 能力	按经验法则所需的数据量
回归	约 100 个示例
分类	适度特征维度（10 个变量）每个类别约 1,000 个示例
图像分类/检测	每个类别约 100 个明显不同类别的示例（例如猫与狗）更相似类别的示例为 1,000 至 10,000 个（例如狗的品种）
文本/NLP	例如情感分析或实体检测的每类任务中约 500 个示例

现在，让我们讨论一下多样性。您组织中的大部分数据甚至都不是以表格形式存储的。例如，原始文本、图像或日志文件属于通常称为非结构化数据的类别。这些数据没有适合您目的的可靠模式。这对于下游分析过程是有问题的。BI 系统通常需要以关系模式存储的数据。即使大多数 ML 算法也期望您的数据是结构化（表格）形式。因此，非结构化数据可能需要进行广泛的预处理——或者使用 AI 服务将其转换为结构化数据（您将在后面章节中看到）。

然而，多样性在表格数据的背景下也可以被解释，并且指的是您的数据如何很好地代表现实世界，包括边缘情况，以及它是否总体上具有代表性。例如，您的数据集中是否观察到所有类别标签的观测？根据您对这个术语的理解方式，多样性可能是一个目标，也可能是一个需要避免的因素。无论如何，您需要选择一个与您的组织相匹配的一致方法，并选择一个评估框架，以便以同样的方式评估不同的用例。

速度是数据产生和通过您系统流动的速率。您是否处理的是每天可能更新一次的批处理数据？还是处理持续更新的流式数据？数据的速度影响两件事：技术需求和数据漂移。流式数据往往对您的基础设施提出更高的要求。高速数据需要更密切地监控数据变化。如果由于速度而导致的数据快速变化，可能会难以在任何时间点上保持一致的真实视图。

真实性指的是数据作为现实世界的表现的准确性。数据是否存在不一致性、不完整性或模糊性？真实性是关于您的数据是否足够适合其预期用途。在 ML 的情况下，这首先意味着数据是否包含真实情况——您是否有数据标签？如果您的数据不包含标签，那么随着时间的推移，获取它们的唯一方式就是购买一个标注服务或等待业务过程生成带有标签的数据作为输出。

结合 4V 以评估数据的准备情况

通过综合考虑所有的 4V，您可以开始看到您的数据在特定用例中的相对优势和劣势。表 2-2 总结了您应该针对每个类别询问自己的一些关键问题及您可能用来评估它们的刻度。

表 2-2. 评估数据在 4V 模型中的关键问题

维度	问题	可能的分数从...到...
数量	你有多少可用数据？将会产生多少数据？	少量（1）
多样性	数据是否包含足够的多样性来捕获甚至是罕见事件？数据是否包含太多的多样性，从而带有过多噪音并需要大量数据清理？	不期望的多样性（1）代表性差的数据（1）
速度	相关数据源产生或更新的频率如何？数据源是否更新频繁，以便及时重新训练模型，以减少数据漂移的风险？	低速度（1）数据漂移风险高（1）

| 真实性 | 数据的准确性如何？数据的完整性如何？

数据的一致性如何？

您有标签吗？| 数据质量差（1）无标签（1）

不适合使用（1）| 高数据质量（5）所有示例均正确标记（5）

适合使用（5）|

有了这些分数，例如，您可以创建网状图。图 2-2 展示了客户流失示例的可能网状图。

图 2-2. 客户流失使用案例的示例网状图

该图表可以解释如下：

数量得分，5 分中的 5 分

我们有一个庞大的客户群体，涉及购买行为的多个属性，我们认为数据量足够用于训练 ML 模型。

多样性得分，5 分中的 3 分

尽管我们所有的数据都是表格化的，对于 ML 模型来说应该很容易消化，但我们预计长期高价值客户的例子很少。另一方面，我们可能有大量新客户，他们的信息可能不在 CRM 系统中，也没有其他地方捕获到，例如购买偏好。

速度得分，5 分中的 4 分

我们 CRM 和 ERP 系统中的数据应该是最新的，并且至少每天更新。我们假设这足够频繁，以避免数据漂移。

真实性得分，5 分中的 4 分

我们可以从数据本身获取真实标签（Churned），因此不需要标注服务。此外，我们预期 CRM 系统中的数据大部分是正确的，因为有数据治理流程在运行。

从数据角度来看，这张网图表明这个阶段存在一个可行的使用案例，并允许我们将这种方法与其他使用案例进行比较。

选择制造或购买 AI 服务

构建 AI 解决方案是一个耗时的过程，需要大量持续维护。图 2-3 展示了一个示例流程，展示了构建端到端 AI 解决方案所需的所有步骤。

当您考虑到这一点及其涉及的复杂性时，有时最好的 AI 解决方案是根本不开发 AI 解决方案。好消息是您不一定需要自己完成所有这些步骤。一种选择可能是仅开发自己的一些组件，另一种选择则完全依赖现成的 AI 服务。最终，像任何其他业务决策一样，AI 解决方案是一个买或者自制的选择。

图 2-3. AI 系统的高级架构

为了给您一个关于 AI 相关的买或者自制模式的概述，让我们看看您作为企业可以选择的各种阶段（见图 2-4），并简要回顾它们的优缺点。

图 2-4. AI 系统的买或者自制模式

AI 作为服务

使用AI 作为服务（AIaaS），您租用一个完全管理的 AI 服务，通常按使用量付费（例如 API 调用）。例如，您可以将一张图片发送到 API，并收到一个 JSON 文档，其中包含识别出的图像中的标签。

优点是您无需开发或维护任何东西。您只需支付您使用的内容，并且通常可以使用免费套餐来尝试 AI 服务，在花钱之前查看服务与您的数据的匹配情况。此外，AIaaS 的服务不需要您提供训练数据。供应商已经针对特定用例（例如面部识别或情感检测）对 AI 服务进行了训练，您可以直接进入推理模式。

由于有各种各样的 AI 服务可用于不同的常见用例，所以相对容易切换服务，因此您可以尝试多种服务而无需风险。此外，AI 服务不需要机器学习专业知识或技能。如果提供图形用户界面（GUI），业务用户可以在不需要密集培训的情况下使用该服务。

AIaaS 服务的最大缺点通常是它们通常是封闭盒子：您不知道服务内部发生了什么。您只获取输入和输出，没有更多信息。此外，您无法自行修改 AI。因此，如果您想专门处理自己的数据或使用不同于服务提供的标签，通常您无能为力。因此，像 Microsoft Azure Cognitive Services，Google Cloud Vision AI 和 Amazon Rekognition 等现成的 AI 服务通常非常适合一般用例（例如检测用户评论中的情感），但对于更具体的用例很快就会变得不适用。例如，通常不能使用 AI 服务从文本数据中提取特定的产品名称。

最后但同样重要的是，您需要信任提供服务的公司。每次 API 查询都删除数据可能不符合该公司的最佳利益，因此您通常缺乏对数据的灵活性和控制。

以下是 AIaaS 的优缺点总结：

优势

• 速度：快速实施

• 成本：按使用付费模型

• 即时可扩展性：能够快速扩展到（几乎）任何规模

• 服务始终在不断改进

• 不需要或只需要很少的机器学习知识

缺点

• 总是需要在线连接

• 通常需要云设置/项目

• 对模型没有控制（封闭系统）

• 在特定数据上表现不佳

• 规模化后成本高昂

• 隐私问题

平台即服务

平台即服务（PaaS）对于大多数企业来说是最佳选择。通过 PaaS，您可以访问托管的机器学习平台，在这里您可以训练自己的模型或通过市场访问预训练的模型。通常情况下，您按许可证、使用次数或两者的组合付费。

如果你想从头开始构建模型，大多数机器学习平台都会支持你，提供像 AutoML 这样的工具。AutoML 使用机器学习本身来为给定数据集找到最合适的模型，因此即使是经验较少的从业者也可以通过点击鼠标快速创建一个良好的初始机器学习模型。我们稍后在本书中会详细探讨这种方法。当然，对于像 AutoML 这样的概念，你需要提供自己的训练数据。

如果您没有或只有很少的训练数据，大多数机器学习平台提供市场，在这里您可以购买各种用途的现成 AI 模型。这些被称为预训练模型。在某些情况下，您可以对这些模型进行微调以适应您的数据，这比从头开始训练模型需要的训练数据少得多。例如，不需要成千上万张图片来构建一个从头开始的计算机视觉模型，只需每类大约一打图片就能产生良好的结果，具体取决于用例。

许多 PaaS 产品还支持更高级的功能，如定制标记服务或支持部署和监控您的模型。在大多数情况下，机器学习平台运行在云端（例如 Azure Machine Learning Studio、Amazon SageMaker 和 Google Vertex AI），但许多供应商也支持本地环境，例如 DataRobot 或 H2O。

以下是 PaaS 的主要优缺点：

优点

• 使用便捷：在大多数情况下，您无需担心基础设施问题，因为 PaaS 供应商已经提供。

• 速度：不需要进行基础设施设置和维护，节省了大量时间，非机器学习专家的入职速度更快。

缺点

• 规模化后成本高昂：如果需要训练多个模型或应用场景，费用可能会很快上涨。

• 供应商锁定：您被锁定在一个平台上训练和部署模型。如果需要更换平台怎么办？

对于大多数希望尝试机器学习的公司来说，我认为这是一个完美的开始方式。PaaS 为您提供了一个维护良好且易于使用的基础设施，同时仍然灵活以适应您的独特需求。您可以快速进行实验，而无需处理过多的额外工作。

基础设施即服务

通过基础设施即服务（IaaS），你可以按使用付费的方式从云服务提供商租用存储、计算和网络服务。你可以部署任何 ML 框架。对于愿意大量投资于 ML 和软件人才，但不希望处理基础设施硬件负担的公司来说，IaaS 方法是有意义的。通常建议在你的组织在开发和维护 ML 模型方面达到一定成熟水平时采用这种方法。

IaaS 提供的示例包括大型云供应商如亚马逊网络服务（AWS）、微软 Azure 和谷歌云平台（GCP），你可以仅通过几行代码或简单的 Shell 脚本就能提供庞大的基础设施资源。从消费者视频流服务到商业车队管理系统等现代数字服务都依赖于这些能力。

这里是 IaaS 的优缺点概述：

优点

• 高灵活性：易于扩展和缩减。这使得你可以根据业务需求快速调整资源。

• 避免锁定：如果你只是使用基础设施，当需要降低成本或提高服务质量时，可以相对轻松地更换服务提供商。

• 焦点在数据科学：在 IaaS 场景中，你对数据和软件拥有完全控制权。因此，你可以专注于 ML 算法的开发，而不被基础设施相关问题分散注意力，同时拥有完全的可定制性。

缺点

• 需要云专家：管理云基础设施需要专业知识。如果你没有这样的人才，这将是一个关键的瓶颈。

• 需要 ML 专家：因为你不依赖预构建的 ML 平台，所以需要自行进行软件集成，这是耗时且需要专业知识的。

IaaS 非常适合那些希望专注于数据科学和软件开发，同时具备快速扩展和缩减能力的公司。

端到端的所有权

通过端到端的所有权，你需要对一切负责——基础设施硬件、网络、软件框架和数据库。有趣的事实是：许多公司不知不觉地从这里开始，因为他们已经在本地运行基础设施，并让他们的数据科学家在他们的计算机上使用 Jupyter Notebook。如果你试图在没有适当的平台管理的情况下大规模实施，这种方法很快就会遇到瓶颈。

端到端的所有权通常是最复杂的场景，如果你要为超过少数用例做这件事，它也是资源消耗最大的。为了证明这种额外开销的必要性，你的公司至少需要一个非常强大的 AI 用例，这将决定公司的成败（例如特斯拉的自动驾驶）。如果你想创建初步的概念验证（PoC），但不允许将数据移至云端，或者你的公司政策不允许采用 ML 平台，端到端的所有权是必需的。

以下是端到端拥有权的利弊：

优点

• 完全控制

• 完全灵活性

缺点

• 需要前期投资

• 复杂的设置和启动

• 资源密集

• 需要专家

注意

在选择您的 AI 基础设施方法时，请记住，并非每家公司都需要从头到尾拥有整个流程。您需要的级别取决于您的用例、预算以及最重要的是可用的人才。

ML 解决方案不是一次性过程，而是需要持续的开发和维护。请仔细考虑您希望专注于哪些部分以及您将如何从中受益。

在我们的客户流失分析示例中，我们可能会选择托管的 ML 平台，因为我们需要为此用例构建自己的模型（没有 AI 可以作为服务进行客户流失分析而不经过培训），并且我们的源系统数据可能可以轻松上传到 ML 平台。

AI 系统的基本架构

现在我们已经涵盖了关于数据和基础设施设置的 AI 用例的可行性方面，让我们简要介绍现代 AI 系统的一般架构。我保证我们不会在这里过于技术化。但如果您了解如何构建 AI 用例，您将更好地评估特定 AI 用例的技术可行性。

在顶层，我们通常可以识别三个构建 AI 解决方案的层次：数据层、分析层和用户层，如图 2-5 所示。

图 2-5. AI 解决方案的高级层次

这种高级框架足以让我们理解以下内容：

• 我们要为用户解决的问题以及结果应该如何看起来（用户层）

• 我们将用于此的 ML 功能（分析层）

• 我们需要的数据以及进行处理的数据（数据层）

当然，底层技术架构要复杂得多，但这种高度抽象将让您走得更远。在本书的后面部分，您将找到我们涵盖的用例的这些高级架构，因此您可以快速了解解决方案的工作原理。让我简要解释每个层次及其含义，然后是两个示例架构。

用户层

第一层是用户层，通常是开始的一个良好步骤。这是我们确定要解决的问题以及我们的解决方案应该是什么的地方。我们是否要托管用户可以访问的 Web 服务？或者我们的最终结果是在 BI 中显示特定预测的仪表板？明确我们的最终结果将为我们的 AI 用例提供所需的范围，即使在开发过程中期望的结果可能会发生变化。以下是一些在用户层中可以使用的流行元素：

• API

• Web 应用程序

• 仪表板或其他 BI 集成

• 文件（例如 Excel，CSV）

• 旧版连接器（例如 SAP，自定义企业软件）

数据层

紧随本章介绍，让我们首先查看我们要在用户层中使用的数据，然后再深入到分析的技术细节中。数据层 包含描述我们要使用的数据源或源系统的组件。一些示例组件如下：

• 数据库

• 媒体文件

• 数据仓库

• API

• 文件（例如，CSV）

• 用户输入

• 遗留连接器（例如，SAP，定制企业软件）

此外，我们可以使用数据层高层次地描述在应用 ML 服务之前我们打算如何处理数据。步骤包括但不限于以下内容：

• 标记数据

• 合并数据

• 聚合数据

• 重塑数据

• 模拟数据

如何使用完全取决于您的用例。对于某些用例，关于数据源及其处理的推理将是主要部分，而对于其他用例，则可能更加关注用户或分析层。

分析层

现在我们已经界定了问题和我们的数据，是时候进入我们架构的中间部分了，这里是我们的 ML 能力发挥魔力的地方：分析层。请注意，这里并不一定需要整合 ML 能力。相反，您也可以考虑完全填充中间层，而不使用 ML，以获得一个初步基准。您可以应用任何业务规则或启发法吗？是否存在其他现有模型？如果有，集成它们并将它们组合为您的基础架构。

创建完毕后，您可以开始用 ML 支持的功能替换基线组件。这样，您将清楚地知道您的 ML 支持方法可能增加价值的地方。

请注意，您的架构不一定是单向的，这意味着数据可以在各层之间来回流动。如果我们简要看两个示例，您将看到这意味着什么。第一个架构示例，显示在图 2-6 中，说明了客户流失用例的可能设置。

图 2-6. 客户流失用例的示例架构

让我们逆序浏览这个架构，从用户层开始。从左上角的框中，Power BI：报告流失表，我们可以看到最终结果应该是在 Microsoft Power BI 中显示预测的流失表的报告。为此，我们将提供一个数据模型（不同表及其关系），用户可以在 Power BI 中看到（因此仍在用户层）。Power BI 从 Azure Blob Storage 访问数据。

进入分析层之后，来自 Azure Blob 存储的数据来自一个批量推断作业，该作业使用二元分类器为通过 CRM、ERP 和 Web 跟踪系统的预处理管道处理过的数据创建流失真/假标签。为了获得模型，我们使用了相同的数据源进行训练；合并、标记和清理它们；并使用这些数据来训练执行预测的二元分类器。

即使没有编写一行代码，甚至没有接触到任何数据源，我们也可以使用这个架构与业务利益相关者讨论，并提出这样的问题：

• 这是解决方案预期的方式吗？

• 我们认为这将有多复杂？

• 我们能够发布的最小可行产品或原型是什么？

• 这符合我们做的故事映射吗？

让我们再看看另一个架构。 图 2-7 展示了一个聊天机器人用例的示例，数据在各层之间来回流动。在左上角，您可以看到最终用户交互应该是网站上的聊天应用程序，通常通过类似“今天我能帮你什么？”的提示开始对话。用户用一个问题回应，我们将其存储在数据库中并附加一些元数据（时间戳、用户信息，如果允许的话）。

与存储数据并行，我们将用户文本输入到实时 NLP 模型中进行实体识别，从用户输入中提取实体。这些实体可以是一般性主题，如计费或技术问题，也可以是产品名称等更详细的实体。对于这个简单的聊天机器人，实体被用来触发业务规则。这可能是一个针对客户提到的实体相关的预写答案的响应，或者询问澄清问题。

用户用另一个输入回应，并且该过程持续到用户离开聊天为止。当用户离开聊天时，他们会被邀请参加调查并被要求提供反馈。这些反馈存储在我们的数据库中，并与我们收集的先前聊天历史结合。我们清理这些数据并分配标签；即，我们在历史对话中标记实体。然后我们可以使用这些标签重新训练 NLP 实体识别模型，改进现有解决方案。

图 2-7. 聊天机器人用例架构示例

正如您从这个用例中所看到的，架构可以是双向的，数据可以在层之间来回流动。这种高级框架在规划 AI 项目和与技术和非技术利益相关者讨论用例想法方面帮助了我很多。我希望这个框架在您考虑下一个 AI 用例时也能对您有所帮助。

道德考量

我们将讨论的最后一个主题是评估我们 AI 使用案例的可行性的伦理问题。 AI 伦理 是一个快速发展的领域。即使您在直觉上不会考虑它（“我不想伤害任何人！”我听到你说），考虑伦理问题仍然至关重要，至少在原则上是如此。在本节中，我为您提供了一个简洁的框架，帮助您确定哪些 AI 使用案例可能是关键的或不太关键的领域。

让我们立即搞清楚：当我们谈论 AI 伦理时，我们谈论的是高度专业化的工具，并非自我意识实体，它们考虑其行为后果（因此豁免其自身的责任）。因此，我们需要评估 AI 技术正在适应的使用案例或应用程序，而不是评估 AI 服务本身。因此，最终要对它们负责的是那些负责任的人，并且他们必须承担责任。

在几乎每一个人工智能使用案例中，都必须在解决方案实施之前和之后解决潜在的伦理考量。在某些情况下，这些问题非常严重，以至于使用案例无法继续进行。在其他情况下，您需要对使用案例进行改变，以确保道德安全。在还有其他使用案例的情况下，大规模歧视人群的风险非常低。关键是，作为企业领导者或试图考虑开发人工智能解决方案的人，您有责任在尝试第一个原型之前进行这样的思考过程。

关键 在这种情况下具有两个方面：

伦理关键性

从对其他人没有影响的应用到涉及一个或多个人的生死的应用程序范围

隐私重要性

从非个人机器数据到与个人有关的数据，再到基于隐私类别的高度敏感个人数据的范围

图 2-8 展示了这一框架。这里提供了一些应用程序的示例并进行了分类。

此图表的左下角中的应用程序似乎是最无害的，因为没有个人参考数据就足够了，其结果对其他人几乎没有或没有任何影响。许多物联网（IoT）应用程序属于此类别，例如，想象一下工厂中的质量控制，其中基于 AI 的系统确定工件是否符合质量标准。当处理对人类风险很小的物品时（考虑计算机键盘），制造商可以在不涉及广泛的伦理考虑的情况下执行 AI 的质量要求。

然而，当产品对人们的生活产生重大影响时，即使没有使用个人数据，该应用场景在道德上也是关键的。例如，医药品测试。在医学实验的某个阶段，数据经过高度匿名化处理，无法将数据点与特定个体关联起来。现在想象一下，您正在评估开发一种新的 AI 服务，该服务可以预测某一患者群体中药物是否会成功，而不是进行手动统计分析。尽管这种服务所需的数据不包括个人数据，但整个应用场景在道德上是关键的，因为最终结果（使用 AI 生成）可能决定了人们生死存亡的差异。

图 2-8. 评估 AI 应用场景的道德和隐私相关重要性框架（来源：“AI 伦理学”，作者 Tobias Zwingmann 和 Tobias Gärtner [Springer]）

让我们看看图表右上角的另一个极端。这些是最高风险区域，需要最仔细的道德考虑。它们包括直接定制或建立在个人数据基础上、直接影响人们生活（大规模）的应用场景。情报服务属于这一类别，信用评级也是如此。如果您的算法在生产中出现问题，并为数百万客户提供服务，您可能会阻止许多人获取财务资源或住房和购物等其他服务，这些基于评级数据。或者，在另一个极端，您正在让许多人获得他们不应该拥有的资源，并且在长期内会导致个人和公司的损失。

如果我们的客户流失用例是一个 B2B 流失预测器，我们可以将其放置在图表的中间左侧部分。在这种情况下，我们将计算帐户（公司）的流失概率，而不是个体客户（人）。这使数据与个体相关，但不像商业对消费者（B2C）的流失示例那样直接。无论如何，我们的流失预测器对个人的影响相对较小。在最坏的情况下，一些个人可能会收到表现不佳（或没有）的个性化报价，以激励他们留下。

在开发 AI 应用场景时，您应该注意两个方面——实现应用场景所需的个人数据量，以及您的解决方案将对人们产生的影响。这两类都应帮助您确定哪些应用场景需要更深入的道德参与，哪些看起来不那么关键。

无论你采取这种方法还是其他方法，我强烈建议你为评估机器学习使用案例开发和实施一个一致的伦理框架。这个框架不必非常复杂，并导致双位数精度的结果。它可以是广泛的，并高度定制以适应你的需求。最重要的是，它必须是一致的和全面的。你的客户和你的业务将为此而感激。

创建一个优先使用案例路线图

在本节结束时，你应该能够基于数据、基础设施/架构和伦理三个主题来评估你的使用案例的可行性。这将为你提供我们在第一章中通过故事映射练习确定的影响评分的第二维度。现在我们可以为每个使用案例创建一个简单的图表，显示其影响力和可行性，如图 2-9 所示。

图 2-9. 具有使用案例示例的可行性与影响力矩阵

正如你可能已经注意到的，我在本章中没有使用正式的评分指标来计算每个使用案例的实际数值。你可以这样做，更复杂的方法确实会这样做，但我的建议是从简单开始，将所有想法或使用案例相对比。哪种使用案例可能会产生最大的影响？哪种使用案例相对容易实施，哪种更具挑战性？

遵循这个系统将为你提供四种类型的使用案例，可以映射到你的图表中，如图 2-10 所示。

图 2-10. 使用案例片段

这些使用案例领域包括：

冠军

具有高影响力和高可行性的使用案例。这些应该是你的首要任务，并推动你的机器学习路线图。

快速成功

具有与冠军类似高可行性，但业务影响较低的使用案例。由于这些使用案例通常较少复杂，因此更容易实施。然而，它们可以是一个很好的展示，并展示机器学习和人工智能应用的价值。可以将其视为可以使用现成的 AI 服务的领域，例如。

研究案例

这些领域具有很大的影响力，但通常在短期内难以实现。要么是因为你没有数据，或者尚不被允许使用（但有望解除限制），或者存在某些技术上的限制。然而，由于这些使用案例对你的业务潜在影响如此之大，不要忽视它们；要始终将它们放在你的视野中。

日后重新评估

这些用例可能会消耗大量资源，但对业务价值贡献不大。它们应该被搁置一旁，并在稍后重新评估。低影响和低可行性的用例在技术变革时可以迅速成为成功案例。例如，不久前，为客户支持票据创建自动化优先级排名是复杂的。然而，随着人工智能服务的新发展，这一过程可能会突然变得可行，这对您的业务可能是一个有趣的快速胜利。

我们如何评估我们的流失用例？很难说，因为我们目前还没有太多信息。停下来思考一下：你会把它放在哪个类别里？

根据我们目前所知，我会认为技术可行性相对较高，这使得流失用例成为快速胜利或冠军的良好候选者。根据第一章的故事板以及我对其他流失用例的经验，如果做得正确，我估计影响将会很大。因此，我更倾向于冠军。您同意吗？

总之，以下是一些关于将您的图表翻译成优先级用例路线图的指导和最佳实践。

结合冠军和快速胜利

设定宏伟的目标是好的，但偶尔实现它们会更好。再次强调，AI 项目往往是开放式的，你永远不知道事情是否会如预期那样进行。因此，始终在管道中保留一些具有相对较短开发时间和成功实施可能性较高的用例是明智的，即使影响不是那么大。

确定共同的数据来源

如果必须在用例之间进行选择，请选择使用相同数据源的用例，而不是一次混合太多数据领域。例如，我宁愿基于 CRM 数据运行三个用例，而不是查看来自生产设施的 CRM 和传感器数据。每次引入新的数据源，您很可能会发现新的问题领域，这是您之前没有预料到的。一旦彻底了解了一个数据源，应尽可能地利用它。

制定引人入胜的愿景

您是否认为您的公司有一个杀手级用例，但在技术上仍然难以实现？您是否认为您的公司在人工智能领域具有竞争优势，但尚未能够利用它？把它放在您的路线图上，但要明确指出，可能还有很长的路要走。打造一个引人入胜的故事并追求一个宏大的目标将为您提供一个强大的叙事，以对齐其他（不那么复杂，影响不那么大）的用例，直到最终实现目标。俗话说，罗马不是一天建成的。但是，你现在可以从马克西姆斯大马戏团开始。

摘要

在本章中，你学会了如何通过考虑数据、基础设施/架构和伦理来评估人工智能用例的可行性。你应该知道如何使用 4V 框架进行初步数据评估，并了解在选择像 AIaaS 或 PaaS 这样的机器学习基础设施时的选项。我们还看了一个你可以用来描述人工智能用例的高层架构。

我们已经涵盖了很多内容，但你已经为自己独立开发成功的基于人工智能的原型奠定了完美的基础。在我们深入讨论人工智能在各种商业智能场景中的实际应用之前，下一章将重新审视一些基础的机器学习概念，这些概念对你从本书中构建自己的人工智能应用至关重要。

第三章：机器学习基础

本章包含了您需要了解的关于机器学习的一切——至少对于本书来说是如此。它也是您进一步学习的一个很好的起点。接下来的部分将为您提供足够的知识，以便跟随本书中的用例，并帮助您构建自己的第一个原型。我们将涵盖监督机器学习、流行的 ML 算法和关键术语，并且您将学会如何评估 ML 模型。

如果您已经熟悉这些主题，可以将本章视为复习。让我们开始学习监督机器学习！

监督机器学习过程

让我们考虑一个简单的例子：想象一下，您想要出售自己的房子，并且正在考虑如何确定上市价格。为了得到一个真实的价格，您很可能会查看其他类似房屋以及它们的售价。为了得出一个良好的估计，您可能还会比较您的房子与其他房屋在一些关键特征方面的情况，例如总体大小、卧室数量、位置和年龄。不知不觉中，您已经像一个监督机器学习系统一样行事了。

监督学习 是基于已知真实值的历史数据训练 ML 模型的过程。例如，如果您想要像我们的示例那样估计（或预测）房地产价格，监督学习算法会查看历史房价（标签）以及描述房屋的其他信息（特征）。监督机器学习与 无监督机器学习 相对，后者未知真实值，计算机必须将数据点分组成相似类别。聚类 是无监督机器学习的一个常见例子。

大多数企业机器学习问题属于监督学习范畴。我将通过展示关键步骤来为您介绍监督机器学习的基本过程，这样您以后可以在我们从第七章开始构建第一个 ML 模型时应用这些步骤。

步骤 1：收集历史数据

为了让 ML 算法学习，它必须有历史数据。因此，您需要收集数据并以计算机能够高效处理的形式提供它。

大多数算法期望您的数据是整洁的。整洁数据 具有三个特征：

• 每个观察结果都在其自己的行中。

• 每个变量都在其自己的列中。

• 每个测量值都是一个单元。

图 3-1 展示了整洁数据的示例。将数据整理成整洁形式可能是整个机器学习工作流程中最繁琐的过程，这取决于数据的来源。

图 3-1. 整洁数据。来源：数据科学的 R 由哈德利·威克姆和加勒特·格罗勒蒙德（O'Reilly）

步骤 2：确定特征和标签

您的算法试图做的一切就是构建一个模型，该模型将根据输入的x来预测某些输出y。让我们简要解释这个概念。

标签（也称为目标、输出或因变量）是基于其他变量进行预测的变量。这些其他变量在机器学习术语中称为特征（或属性、输入或自变量）。例如，如果您想要预测房价，房价将是您的标签，而卧室数、大小和位置等变量将是您的特征。在监督学习设置中，您有包含一定数量观测值的历史数据，这些数据包含了特征和标签，也称为训练样本。

如果您的标签是数值型，这个过程称为回归问题。如果您的标签是分类的，这个过程称为分类问题。

不同的算法用于分类和回归问题。在“流行的机器学习算法”中，我将介绍三种流行的算法，这些算法足以满足我们的原型开发目的。

第三步：将数据分割为训练集和测试集

当您的数据整理成整洁的形式并且已经定义了特征和标签后，通常需要将数据集分割为训练集和测试集。训练集是历史数据集的一部分，用于训练机器学习模型（通常占数据的 70%至 80%）。测试集（或保留集）是您数据的一部分，将用于最终评估您的机器学习模型。

在大多数 AutoML 场景中，您不需要手动处理这个分割，因为 AutoML 工具会自动处理。然而，有时 AutoML 服务无法猜测出最佳的数据分割方式，因此您需要手动调整（例如，在时间序列数据的情况下）。这就是为什么理解数据分割的重要性，为什么需要它们，以及为什么只能在测试集上评估您的模型的原因。

您将数据分割，因为您希望模型不仅在它已知的数据上表现良好，而且在来自相同分布的新的未见数据上也能表现良好。这就是为什么保留一些数据用于最终评估非常重要的原因。您模型在测试集上的表现将成为对新的未见数据的性能指标。

第四步：使用算法找到最佳模型

在这一步中，您尝试找到最能代表您的数据并具有最高预测能力的模型。您可以通过尝试多种具有多个参数的机器学习算法来实现这一点。再次，让我们快速浏览这个概念。

模型是您的机器学习训练过程的最终产物。它是一个任意复杂的函数，用于计算任何给定输入值的输出值。

让我们考虑一个简单的例子。您的模型可能如下所示：

y = 200x + 1000

这是一个简单线性回归模型的方程式。给定任何x的输入值（例如，房屋大小），该公式将通过将尺寸乘以 200 并加上 1000 来计算最终价格y。当然，ML 模型通常比这复杂得多，但思想是一样的。

那么，计算机如何在给定一些历史输入和输出数据的情况下提出这样的公式呢？需要两个组成部分。首先，我们需要为计算机提供算法（在本例中为线性回归算法）。计算机将知道输出必须类似于回归方程：

y = b1x + b0

计算机将使用历史训练数据来找出此问题的最佳参数b1和b0。这个参数估计过程在 ML 中称为学习或训练。我们可以通过各种方式实现和加速大数据集的这个学习过程，但它们超出了本书的范围，对我们的目的来说是不必要的。

您唯一需要知道的是，您需要定义一个 ML 算法来在训练数据上训练模型。这是像数据科学家或 ML 专家这样的专家可以胜任的地方。在我们的案例中，我们将主要依赖 AutoML 解决方案来为我们找到最佳模型。

步骤 5：评估最终模型

当我们的训练过程完成时，一个模型将在测试集上展现出最佳性能。不同的评估标准用于不同的机器学习问题，我们将在“机器学习模型评估”中进一步探讨。

重要的是要理解这些指标的工作原理，因为您将需要指定这些指标给 AutoML 服务以找到最佳模型。再次强调，不用担心；您的 AutoML 服务会建议一个很好的首选评估指标。

步骤 6：部署

一旦您决定了一个模型，通常希望将其部署到某个地方，以便用户或应用程序可以使用它。这个 ML 过程的技术术语是推断、预测或评分。在这个阶段，您的模型不再学习，而是在接收新的输入值时仅计算输出。

这种工作方式取决于您的设置。通常，模型被托管为一个接受输入数据并返回预测的 HTTP API（在线预测）。或者，该模型可以用于一次评分大量数据，这称为批处理预测。

步骤 7：执行维护

虽然 ML 模型的开发过程在部署后已经结束，但这个过程实际上永远不会结束。随着数据模式的变化，模型需要重新训练，我们需要观察 ML 模型的初始性能是否可以随时间保持高水平。

在原型阶段我们不必处理这些问题，但重要的是注意到机器学习模型在部署后需要大量的维护，这是您在可行性分析中需要考虑的。我们将在第十一章进一步探讨这个话题。

现在您已经从高层次理解了监督机器学习的一般过程，让我们来看看用于训练分类和回归问题模型的最流行的机器学习算法。

流行的机器学习算法

在本节中，我将向您介绍三种流行的机器学习算法家族：线性回归、决策树和集成方法。如果您了解这三类算法，您将能够解决大约 90%的商业监督学习问题。

表 3-1 概述了这些算法类别，然后我们将更详细地研究它们。

表 3-1. 流行的机器学习算法

算法类别	用于	性能	可解释性
线性回归	回归问题	从低到高	高
决策树	回归和分类问题	平均	高
集成方法（bagging 和 boosting）	高	低
高	低

线性回归

线性回归 是理解机器学习中最基本算法之一，因为它支持许多概念。逻辑回归、回归树、时间序列分析，甚至神经网络都在其核心使用线性回归。

线性回归的工作原理很简单，但很难掌握。给定一些数值输入数据，回归算法将拟合一个线性函数，计算（预测）相应的数值输出数据。

回归的两个主要假设很重要：

• 特征之间应该相互独立（特征之间的相关性应该很低）。

• 特征与结果变量之间的关系应该是线性的（例如，当一个变量增加时，输出变量也应该以固定模式增加或减少）。

图 3-2 展示了一个简单线性回归的示例：x 轴上的输入变量预测了 y 轴上的变量。图中的点是观察到的实际数据点（标签），它们对应历史数据集中每个 x 值。回归的预测将是直线上每个 x 值的 y 值。当然，这只是一个用于说明目的的基本示例。线性回归不仅仅适用于单一输入变量，还可以模拟比直线更复杂的形状（例如，多项式回归）。

图 3-2. 简单线性回归

正如你在 表 3-1 的第一行中所见，线性回归的模型性能可以从非常低到非常高不等。这是因为线性回归算法的性能严重依赖于数据以及数据如何符合线性回归的假设。如果输入变量确实是独立的，并且与输出变量具有线性关系，那么回归可以击败任何神经网络。

话虽如此，如果您的数据包含非线性模式，回归并不是一个好选择。例如，如果满足某个特定值，然后突然与目标变量的关系发生变化。这类 if-then-else 规则可以通过其他算法更好地建模，比如决策树。

决策树

与回归模型相比，基于树的模型可以处理分类和数值数据（回归树），正如你在 表 3-1 中所见。决策树 在各个级别、变量之后分割数据，直到数据片段变得足够小，你可以进行预测。想象决策树是一个层次化的 if-then 规则序列。

决策树通常是一种非常通用的算法，可以作为几乎任何表格数据集的首选基线模型。决策树易于分享和解释，即使对非技术相关的利益相关者也是如此。然而，单个决策树在某些情况下未必能够在所有情况下取得最佳结果，因为这种算法是“贪婪”的。这意味着它会首先在数据显示最大差异的地方进行分裂。这一过程并不在所有情况下都是理想的。

图 3-3 展示了一个预测 泰坦尼克号 上乘客生存情况的决策树示例，这是一个流行的研究数据集。你从上到下阅读树，每个节点代表一个决策步骤。

图 3-3. 决策树

因为决策树是贪婪的，它会首先在 gender 上进行第一次分裂。如果你从泰坦尼克号数据集中随机选取一名女性乘客，那么这个人幸存的可能性为 73%。作为第一个猜测，这并不差。对于男性，树看起来复杂一些。预测将是 died 或 survived，考虑到诸如人的 age 和兄弟姐妹或配偶的数量 (sibsp) 等多个因素。

我们在这里不会深入详细讨论。重要的是你理解决策树的工作原理，因为我们将在下一个概念中继续深入探讨：集成学习。

集成学习方法

线性回归和决策树都相当直观，它们的工作方式相对容易解释。集成方法 则处于谱系的另一端。正如你在 表 3-1 中所见，集成方法通常提供较高的预测能力。然而，解释它们做出决策的方式并不那么简单。

线性回归和决策树通常被认为是弱学习器，这意味着它们在数据关系变得更复杂时表现不佳。例如，回归无法处理非线性数据，而决策树在数据集中的每个变量只能进行一次分裂。

要应对这些问题，集成方法允许你将多个弱学习器组合成一个在复杂数据集上表现强大的强学习器。集成学习的两种典型方法是装袋（bagging）和提升（boosting），它们通过组合弱学习器的方式进行区分。

装袋（来自自助法聚合）试图通过分别训练多个弱学习器并使用平均过程将它们组合起来。图 3-4 展示了装袋的工作原理图。在中间层，您可以看到四个模型，它们都在同一训练数据集上进行训练。例如，这可能是四棵决策树，具有不同的树深度或最小节点大小参数。对于每个数据点，这四个模型都将进行个别预测（顶层）。最终预测将是这四个结果的聚合（例如，在分类示例中的多数投票，或在回归问题中的平均值）。

图 3-4. 装袋

一种流行的装袋集成方法称为随机森林。这种方法将决策树分成多个子树，以减少它们之间的相关性。

提升 相反，是顺序地将模型添加到集成中，每个模型都纠正其前任的错误。这是一种流行且强大的技术。两种流行的提升方法是 AdaBoost（自适应提升）和梯度提升。

图 3-5 展示了装袋的概念概述。训练过程从左下角开始，第一个模型（例如决策树）训练并给出了一个具有相对高误差的第一次预测（左上角）。接下来，训练另一个决策树，它试图纠正前一个模型的错误（底行左边的第二个模型）。这个过程重复进行多次，直到误差变得越来越小，找到一个表现良好的模型。图 3-5 有三次迭代，最终在右下角得到最终模型。

图 3-5. 提升

正如您从这个例子中看到的，集成方法比线性回归或决策树更难解释。然而，在大多数情况下，它们提供了更好的性能。

您应采取的方法取决于您的目标。如果对于您的项目来说，解释性不如准确性重要，那么选择像自适应增强这样的强学习器通常是更好的选择。另一方面，如果您的机器学习模型需要用户或其他利益相关者深入理解和解释，那么选择稍微不太准确的模型，如决策树或线性回归，可能是更好的选择。如果犹豫不决，如果简单模型提供类似性能，则选择简单模型。

深度学习

到目前为止，我们已经涵盖的算法在通常在电子表格或数据仓库中找到的结构化表格数据上表现良好。对于其他数据类型，如图像或文本，您需要不同的算法。这个领域通常被称为深度学习。

在这里我们不会详细讨论这个问题。我们将稍后使用来自 Azure 认知服务的 AI 服务，这些服务基于深度学习技术，但我们不打算自己构建它们。对于我们的目的来说，了解这些深度学习概念的一般概念及其工作原理就足够了。

深度学习指的是各种专门处理高维数据集（即具有许多特征的数据）的机器学习方法和技术。并没有明确的正式定义说明“浅层”机器学习在哪里结束，“深度”学习开始，但大多数情况下关键在于数据类型。

考虑以下示例：即使您构建了一个超高维销售预测器，您可能也不会从您的表格 CRM 数据中创建超过几十个，甚至数百个特征。现在想象一下，您正在分析用于对象检测的图像。即使对于分辨率为 300×300 像素的相当小的图像，您也会得到 90000 个维度（每个像素一个维度）。对于彩色红、绿和蓝（RGB）图片，这个数量会增加三倍。

您可以看到，即使在可能有 1000 列（维度）的高维表格数据和每张图片都有 90000 个维度的小图像表示之间仍存在显著差异。这就是为什么深度学习通常用于像图像、视频和非结构化文本文件这样的非表格数据的原因。

深度学习分为两大类：计算机视觉（处理图片或视频数据）和自然语言处理（处理文本数据）。

自然语言处理

您可能已经听说过能够解释人类语言、比以往更准确地进行翻译甚至完全自动生成新文本的 AI 服务。已经在数十亿人类文本示例上进行了训练的大型语言模型，结合一种称为transformers的突破性技术，将 NLP 领域从一个小的研究领域推向了 AI 开发中最热门的领域之一。

我们不会在本书中自行训练 NLP 模型，但你将接触使用最先进的语言模型来规模化分析语言数据。这不仅仅适用于书面文本。NLP 技术还非常适合分析口语。这个领域通常被称为语音转文本。

计算机视觉

计算机视觉是一种技术，使得机器能够“看到”和解释图像和视频文件。一种名为卷积神经网络（CNNs）的技术近年来在这个领域取得了令人难以置信的突破。应用范围从在图像中识别如汽车、自行车、街道标志、动物和人类等商品实体，到人脸识别和从图像中提取文本结构。

这是一个变化多端、充满活力的领域。在第九章中，我们将使用计算机视觉 AI 服务来检测和计数图像文件中的汽车。

强化学习

我想要重点介绍的最后一个深度学习类别是强化学习。我们将在第八章中看到强化学习服务的实际应用。强化学习的工作方式与监督学习或无监督学习有所不同，并已成为一个独立的领域。

强化学习模型学习方式的原因在于它们学习的方式。强化学习方法不依赖于历史数据，而是需要持续涌入新数据流，以便模型可以根据系统当前状态和允许模型操作的策略学习最佳策略。

强化学习已经取得了重大突破，能够击败像围棋和星际争霸这样的世界级人类选手。但正如你后面将发现的那样，它也是个性化用户体验和随时间学习用户需求以及如何与用户交互的绝佳方式。

机器学习模型评估

通过你迄今为止从本书中获得的知识，你应该足够自信能够从原型阶段到真实世界应用 ML 模型。然而，还缺少一个组成部分。那就是如何评估你的模型实际运行效果的方法。

能够测量 ML 模型性能的能力在原型设计阶段和后期投产阶段至关重要。我们选择的评估指标不应该有所不同，只是指标值不同。那么我们如何评估 ML 模型的性能呢？

欢迎来到评估指标的世界！评估指标有两个计算目的：

• 为了比较模型之间的优劣，以找到最佳的预测模型

• 持续测量模型在新的未见数据上的真实性能

模型评估的基本思想始终如一：我们将模型预测的值与地面真相中模型应该预测的值（例如数据集中的标签）进行比较。这听起来直观简单，但实际上涵盖了相当多的复杂性。事实上，仅仅是评估指标本身就可以写成一本书。

在我们的情况下，我们将保持简洁，重点关注您在处理机器学习算法时可能会遇到的最重要概念。我们针对分类和回归问题使用不同的评估指标。

评估回归模型

记住，回归模型预测连续数值变量，如收入、数量和大小。评估回归模型最流行的指标是均方根误差（RMSE）。它是回归预测值（ŷ）平均平方误差的平方根。RMSE 可以定义如下：

$\mathit{\text{RMSE}}=\sqrt{\frac{{\displaystyle {\mathrm{\Sigma }}_{i=1}^n{(y_i-{\hat{y}}_i)}^2}}{{\displaystyle n}}}$

RMSE 衡量了模型的整体准确度，并可以用来比较各个回归模型之间的表现。数值越小，模型的表现似乎越好。RMSE 的结果与原始预测值的规模一致。例如，如果你的模型预测房价的美元数值，并且看到 RMSE 为 256.6，那么这意味着“模型的预测平均偏差为 256.6 美元”。

在回归评估的背景下，你还会看到另一个流行的度量指标，决定系数，也称为R-squared统计量。R-squared 的取值范围是从 0 到 1，用来衡量模型中数据变化的比例。当你想评估模型与数据的拟合程度时，这个指标非常有用。R-squared 的公式如下：

$R^2=1-\frac{{\displaystyle {\mathrm{\Sigma }}_{i=1}^n{(y_i-{\hat{y}}_i)}^2}}{{\displaystyle {\mathrm{\Sigma }}_{i=1}^n{(y_i-\overline{y})}^2}}$

这可以解释为模型解释的方差与目标变量总方差之比的一减。通常情况下，R-squared 值越高，模型越好。R-squared 值为 1 意味着模型能够解释数据中的所有方差。

虽然汇总统计数据是比较不同模型的好方法，但仅仅依靠这些指标来判断我们的回归是否按预期工作仍然很困难。因此，在回归建模中的一个良好方法是查看回归误差的分布，即我们模型的残差。残差的分布为我们提供了关于回归模型表现的良好视觉反馈。

残差图将预测值与残差作为简单的散点图绘制。理想情况下，残差图应该看起来像 图 3-6，以支持以下假设：

线性性

残差图中的点应该随机分布，而不应该显示出太多的曲线。

异方差性

预测值在各个预测值上的点的分布应该基本相同。

图 3-6. 残差分析

残差图将展示你的数据中回归模型表现良好和表现不佳的部分。根据你的使用情况，你可以决定这是否是一个问题，或者在考虑所有其他因素时是否仍然可接受。仅仅查看汇总统计数据不能带给你这些见解。在评估回归模型时，始终注意残差是一个好主意。

评估分类模型

如果预测值不是数值而是分类的话，我们如何评估预测模型的性能呢？我们不能简单地应用从回归模型中学到的度量标准。为了理解原因，让我们看一下 表 3-2 中的数据。

该表显示了分类问题的真实标签（目标列）以及分类模型的相应输出（预测和“概率输出”列）。

表 3-2. 分类输出示例

目标	预测	概率输出
1	1	0.954
1	0	0.456
0	0	0.012
0	1	0.567
0	0	0.234
…	…	…

如果你看看前四行，你会看到可能会发生的四件事：

• 真实标签为 1，我们的预测是 1（正确预测）。

• 真实标签为 0，我们的预测是 0（正确预测）。

• 真实标签为 1，我们的预测不是 1（预测错误）。

• 真实标签为 0，我们的预测不是 0（预测错误）。

如果我们有超过两个类别，这四种结果也会发生。我们可以简单地观察数据集中每个类别的这四种结果。

评估分类模型性能的最流行方式是在 混淆表 或 混淆矩阵 中展示这四种结果，如 表 3-3 所示。

表 3-3. 混淆矩阵

		预测类别
		负面
实际类别	负面	2,388 真负例 (TN)
正面	415 假负例 (FN)	2,954 真正例 (TP)

这个混淆表告诉我们，在我们的例子分类问题中，有 2,388 个观察结果实际标签为 0，我们的模型正确预测了它们。这些观察结果被称为 真负例，因为模型正确地预测了负类标签。同样，有 2,954 个观察结果被我们的模型标识为 真正例，因为实际和预测的结果都有正类标签（在本例中是数字 1）。

但是我们的模型也犯了两种错误。首先，它错误地将负类预测为正类（558 个案例），也称为 I 型错误。其次，模型错误地预测了实际上是正的 415 个案例为负。这些错误称为 II 型错误。统计学家在给这些事物命名时没有那么有创意。

现在，我们可以从这个混淆表中计算各种指标。你会经常看到和听到的最流行指标是准确率。准确率 描述了我们的模型多频繁地正确，基于所有预测。我们可以通过将正确预测的数量除以所有预测的数量来轻松计算模型的准确率：

$\text{ACC}={\displaystyle \frac{{\displaystyle \text{TP}+\text{TN}}}{\text{TP}+\text{TN}+\text{FP}+\text{FN}}}$

对于表 3-3 中的混淆矩阵，准确度为 (2,388 + 2,954) / (2,954 + 2,388 + 558 + 415) = 0.8459，这意味着我们模型的预测在所有情况下都正确率达到了 84.59%。

虽然准确度是一个广泛使用和受欢迎的度量标准，但它有一个重要的限制：准确度仅适用于平衡分类问题。想象一个这样的例子：我们想预测信用卡欺诈，这在所有信用卡交易中只发生在 0.1% 的情况下。如果我们的模型一直预测没有欺诈，它将得到令人惊讶的 99.9% 的准确度分数，因为在大多数情况下它都是正确的。

虽然这个模型具有优秀的准确度度量标准，但显然这个模型完全没有用。这就是为什么混淆矩阵允许我们计算更多更平衡地正确识别正负类别标签的度量标准。

我们可以看一下的第一个度量标准是精确度。它衡量了真正例的比例（预测的真标签实际上是真的）。精确度，也称为正预测值（PPV），定义如下：

$\text{PPV}=\frac{{\displaystyle \text{TP}}}{{\displaystyle \text{TP}+\text{FP}}}$

在我们的例子中，精确度为 2,954 / (2,954 + 558) = 0.8411。这个数值可以解释为当模型将数据点标记为正类别（1）时，它在所有情况下都是正确的 84%。如果一个假阳性的成本非常高而一个假阴性的成本较低（例如，我们要决定是否向在线用户展示昂贵的广告），我们将选择这个度量标准。

另一个关注正类别但具有稍有不同焦点的度量标准是召回率，有时也称为敏感性或真正率（TPR）。它给出了所有正类别中被正确分类为正类别的百分比。召回率定义如下：

$\text{TPR}=\frac{{\displaystyle \text{TP}}}{{\displaystyle \text{TP}+\text{FN}}}$

在我们的示例中，这将是 2,954 / (2,954 + 415) = 0.8768。这个数值表示模型能够识别数据集中 87.68% 的所有正类别。我们会选择这个度量标准来优化我们的模型，以便在数据集中找到正类别（例如，用于欺诈检测）。在成本极高的情况下错过这些正类别（假阴性）时，使用召回率作为评估度量是合理的。

如果您不想倾向于精确度或召回率，并且准确性似乎不能很好地捕捉您的问题，您可以考虑另一种常用的度量标准，称为F 分数。尽管其技术名称，但此度量标准相对直观，因为它结合了精确度和召回率。最流行的 F 分数是 F1 分数，它只是精确度和召回率的调和平均数。

因此，如果已知精确度和召回率，我们可以轻松计算 F1 分数：

${\text{F}}_1=2\times {\displaystyle \frac{\text{PPV}\times \text{TPR}}{\text{PPV}+\text{TPR}}}={\displaystyle \frac{2\text{TP}}{2\text{TP}+\text{FP}+\text{FN}}}$

在我们的情况下，因此 F1 分数将是 2 × (0.8411 × 0.8768) / (0.8411 + 0.8768) = 0.8586。

一个更高的 F1 分数表明模型表现更好，但它究竟告诉了我们什么呢？嗯，F1 分数并不能像前面的指标那样用一句话轻松解释，但通常是评估模型质量的一个好去处。由于 F1 分数使用精确度和召回率的调和平均数而非算术平均数，如果其中一个非常低，它将倾向于较低分数。

想象一个极端的例子，精确度为 0，召回率为 1。算术平均数将返回 0.5 的分数，大致翻译为“如果一个很好，但另一个很差，那么平均值还行。”而调和平均数在这种情况下将为 0。F1 分数不会将高低数值平均化，而是在召回率或精确度极低时发出警告。这更接近你对联合表现指标的期望。

评估多分类模型

我们用于二分类问题的指标也适用于多分类问题（其中有超过两个类别要预测）。例如，请考虑以下目标和预测值：

targets = [1, 3, 2, 0, 2, 2]
predicted = [1, 2, 2, 0, 2, 0]

二分类和多分类问题之间唯一的区别在于，您将计算每个类别（0、1、2、3）的评估指标，并将其与所有其他类别进行比较。您可以使用不同的方法进行此操作，通常称为微观和宏观值。

微观分数通常通过将所有真正例、假负例和假正例总数一起计算，然后仅通过彼此除以彼此来计算指标。宏观分数则首先计算每个标签的精确度、召回率等，然后计算所有标签的平均值。这些方法产生类似但仍然不同的结果。

例如，我们为四个分类标签的虚拟系列的微观 F1 分数为 0.667，宏观 F1 分数为 0.583。如果愿意，可以尝试手动计算这些数字，以促进对这些指标的理解。

微观或宏观度量都没有好坏之分。这只是基于不同方法计算同一摘要统计的不同方式。在你处理更复杂的多类问题后，这些细微差别会变得更加关键。

还有更多的性能指标可供参考，但这超出了本书的范围。例如，到目前为止，我们甚至还没有看过考虑模型概率输出的性能指标，比如 ROC 曲线下的面积（AUC）。

在评估指标方面并不存在银弹。重要的是，你至少要高层次地理解这些指标试图捕捉什么，并确定哪个指标对你的用例实用。你还需要知道何时停止训练更复杂和（表面上）准确的 ML 模型是足够好的。我们将在下一节深入探讨这一点。

机器学习的常见陷阱

机器学习是解决许多现代问题的强大工具，但像任何其他工具一样，容易被误用并导致糟糕的结果。本节概述了一些初学者应避免的错误。

陷阱 1：在不需要时使用机器学习

如果你手里有一把锤子，看什么都像钉子。你最糟糕的做法是利用你新学到的机器学习知识，寻找看起来适合的商业问题。相反，应该从相反的角度来看待：一旦确定了一个相关的商业问题，再考虑机器学习是否能帮助解决它。

即便如此，从一个简单的基线开始是很重要的。这个基线对于获取一个 ML 算法需要超越的性能基准至关重要。如果你以前从未进行过客户流失分析，你不应该从一个基于 ML 的方法开始，而是使用简单的启发式方法或硬编码规则。这些方法复杂度低，业务利益相关者容易理解。一旦发现它们的表现显著优于你的基线解决方案，再转向 ML 模型。

陷阱 2：过于贪心

不要贪图在训练集上最大化性能指标。这可能导致你的模型在未曾见过的新数据上表现不佳。这听起来可能违反直觉，但在训练时应更加保守，特别是在较小的数据集上，这可以更好地推广模型到未见数据的泛化能力。这个概念也被称为奥卡姆剃刀：当你犹豫不决时，简单的解决方案比复杂的解决方案更好。

陷阱 3：构建过于复杂的模型

建立过于复杂的模型往往与前述观点相辅相成：为了达到高准确度，经验不足的人往往倾向于创建过于复杂的模型，例如神经网络。在许多情况下，比起高度复杂且高准确度的模型，更偏向于一个准确度较低但复杂度较低的模型。

复杂模型存在两个缺点：

• 在生产环境中，复杂模型可能难以维护和调试。如果出现问题或者你的模型预测出现偏差（这种情况肯定会偶尔发生），相较于简单模型，高度复杂的模型更难纠正。

• 复杂模型可能导致过拟合：你的模型在训练数据上表现良好，但在新数据上表现不佳。预测分析就是要找到一个甜点（见图 3-7），在这个甜点上，训练（历史数据）和测试（新数据）中的预测误差大致相等。为了避免过拟合，你应该始终监控模型在新数据上的表现以及模型的复杂度。

图 3-7. 训练误差与测试误差

陷阱 4：没有在数据足够时停止

在你的组织中很少会有完全标记完美的机器学习数据。正如你已经了解到的，通常情况下，我们拥有的示例（观察结果）越多，效果就越好。然而，经验表明，机器学习算法会在某一点达到平台期，在这一点之后，额外的训练示例不再显著提高准确性。这种效应在图 3-8 中有所体现。

当你达到这一点时，再多花费在数据标记上的资金就变得不划算了。因此，设定一个明确的目标非常重要。你的模型需要多准确才能使用？阈值可以从“比基准值更好的任何情况”到“需要 99.99%的准确度”，例如在医疗案例中。了解你的目标和想要实现的内容可以帮助你避免高昂的成本。

图 3-8. 模型准确度与标记成本

陷阱 5：陷入维度灾难

虽然“数据越多越好”的原则适用于观察（行），但对于特征（列）来说可能会适得其反。想象一下以下的例子。

你想基于大小、卧室数量和位置（邮政编码）来预测美国房价。大小和卧室可以建模为两个独立的特征（列），这样可以将数据集的维度增加一个数量级，如图 3-9 所示。

然而，一旦你开始使用邮政编码，大多数机器学习算法要求你将此类分类变量编码为一个单列特征，其宽度与唯一值的数量完全相同。这会将数据的维度增加不仅仅是一阶，而是 41692 阶（可能的美国邮政编码数量），因为它将是单列，每个示例包含值0或1。

大多数机器学习算法将难以在数据中找到实际模式，因为数据太稀疏。没有绝对的规则能帮助你避免维度灾难，但这里有一些建议：

• 在向数据集添加新特征时要小心，不要犹豫地删除冗余或无关的特征。有时这一步骤可能很困难，因为你可能需要扎实的领域专业知识。

• 尝试通过将这些依赖关系编码为单一属性来减少属性之间的关系数量。例如，不要有两个属性，价格和大小，你可以计算一个新的属性，每平方英尺价格。数据集中变量之间的依赖关系越少，机器学习算法就越容易理解它们。

图 3-9. 跨多个维度的数据点

Pitfall 6: 忽略异常值

异常值是远高于数据集平均值的数据点。例如，想象一个包含人们工资和净值的数据集。如果绘制数据，它可能看起来像图 3-10 顶部的图表。

图 3-10. 带异常值（顶部）和不带异常值（底部）的样本数据

您可以看到工资和净值之间似乎存在很强的相关性。但有一些数据点与所有其他数据点相距甚远。这些数据点代表的是工资高，但净值更高的人群。在这种情况下，回归线（虚线）偏向这些异常值，导致其他所有数据点拟合效果不佳。一旦我们移除这些高净值个体组（在图 3-10 左括号下）后，回归线似乎更好地适应了其余数据点。

对许多算法来说，异常值的影响可能非常巨大，尤其是那些处理回归任务的算法。这意味着你应该密切注意检测数据集中的异常值。

Pitfall 7: 对云基础设施理所当然

在本书中，我大胆地假设您可以访问云计算进行模型训练和推理。但让我们面对现实：在许多公司中，情况可能并非如此（尚）。尽管云计算的采用速度正在迅速增长，但大多数公司仍然主要使用本地解决方案。造成这种情况的原因很多，但一个重要原因是害怕失去数据控制权。

我强烈建议您至少尝试使用云计算（AIaaS 或 ML 平台）进行原型设计，即使是使用非关键数据，正如下一章所述。虽然这可能还不是您组织中的惯常做法，但它将使您快速启动，并与前沿的 ML 工作流程和工具保持联系。这还将使您能够与团队讨论云计算如何成为一个有利于整体 AI/ML 战略的投资。

摘要

在本章中，您学习了监督式机器学习的基本概念，并了解了哪些算法对机器学习非常重要。我们还涉及了深度学习、计算机视觉和自然语言处理。

当然，您在机器学习方面还有很多东西要学习，但这些页面将为您提供构建自己的 ML 驱动原型所需的一切。我希望您现在对此有了一些信心。如果没有，不要担心！

等到我们接近实际应用案例时，本章的概念可能会对您更易于理解，因为它们将与某些实践联系在一起。如果您想深入了解机器学习，我推荐阅读以下任何一本书：

• 机器学习设计模式 由 Valliappa Lakshmanan 等人（O’Reilly）

• Python 机器学习入门 由 Andreas C. Müller 和 Sarah Guido（O’Reilly）

• 构建机器学习驱动的应用 由 Emmanuel Ameisen（O’Reilly）

我还建议您收藏本章，并在需要时随时回来温习机器学习基础知识。

第四章：原型

到现在为止，您应该已经具备了足够的理论背景知识，可以开始进行一些 AI 用例的实际操作了。在本章中，您将学习如何借鉴产品管理的原型技术，快速创建并实施 ML 用例，并验证您对可行性和影响的假设。

记住，我们的目标是迅速找出我们的 AI 驱动想法是否创造价值，以及我们是否能够在不浪费太多时间或其他资源的情况下构建解决方案的第一个版本。本章不仅将向您介绍有关原型的理论概念，还将介绍我们将在本书示例中使用的具体工具。

什么是原型，为什么它如此重要？

让我们面对现实吧：大多数 ML 项目都会失败。这并不是因为大多数项目资金不足或缺乏人才（尽管这些也是常见问题）。

ML 项目失败的主要原因是围绕它们存在的极大不确定性：需求、解决方案范围、用户接受度、基础设施、法律考虑因素以及最重要的结果质量，这些都非常难以在新倡议开始之前预测。特别是在结果方面，您永远无法真正知道您的数据是否具有足够的信号，直到您经历了数据收集、准备、清洗并构建实际模型的过程。

许多公司在开始他们的第一个 AI/ML 项目时充满了热情。然后他们发现这些项目变成了无底洞。数月的工作和数千美元的花费仅仅是为了得到一个简单的结果：它不起作用。

原型是一种在扩展之前减少风险并评估您的 ML 用例影响力和可行性的方法。通过原型，您的 ML 项目将更快速、更便宜，并且将获得更高的投资回报率。

对于本书而言，原型是一个未完成的产品，其简单目的是验证。像 PoC 或最小可行产品（MVP）这样的概念有着相同的目的，但这些概念背后有着不同的背景，并且涉及的不仅仅是验证。验证的概念非常重要，因为如果没有需要验证的内容，你就不需要构建原型。

在 AI 或 ML 项目的背景下，您希望在两个维度上验证您的用例：影响力和可行性。这就是为什么在继续构建某些东西之前，您需要对这些类别有一个大致的了解。

这里有一些在机器学习和人工智能背景下可以验证的示例：

• 您的解决方案是否为用户提供了价值？

• 你的解决方案是否如预期般使用？

• 您的解决方案是否被用户接受？

• 您的数据是否包含足够的信号以构建有用的模型？

• AI 服务是否能够很好地与您的数据配合，提供足够的价值？

要成为有效的验证工具，机器学习原型必须是端到端的。创建准确的模型是好的。创建有用的模型更好。获取这些信息的唯一途径是让你的机器学习解决方案面向真实用户。你可以建立世界上最好的客户流失预测模型，但如果市场营销和销售人员没有准备好将预测付诸行动，你的项目将是失败的。这就是为什么你需要快速的用户反馈。

当你原型化你的机器学习驱动解决方案时，不要在数据上妥协。不要使用在生产中不可用的数据。不要进行无法扩展的手动清理。你可以修复模型；你可以修复用户界面。但你不能修复数据。把它当作在生产场景中对待的方式。

一个原型通常应该有以下明确定义的范围：

明确的目标

例如，“我们能否建立一个比我们基线 B 在预测y时更好的模型，给定一些数据x？”

严格的时间框架

例如，“我们将在最多两周内建立我们能建立的最好模型。”

接受标准

例如，“如果发生了反馈 F，我们的原型通过了用户验收测试。”

当涉及技术时，原型应该让你决定在何种技术栈内最好地实现目标。原型为你提供宝贵的洞察潜在问题领域（例如数据质量问题），同时从一开始就吸引业务利益相关者并管理他们的期望。

商业智能原型化

几十年来，商业智能系统的典型开发过程是经典的瀑布方法：项目被计划为一个线性过程，从需求收集开始，然后转移到设计，接着是数据工程，测试和部署业务所需的报告或指标。

即使没有人工智能或机器学习，瀑布方法也正在达到其极限。这是因为几个因素共同作用。随着业务要求变得越来越模糊，因为业务本身变得更加复杂。此外，技术也变得更加复杂。10 年前，你可能只需要整合少数几个数据源，而今天，即使是小公司也不得不管理数十个系统。

当你为大规模商业智能计划准备好项目计划时，通常它已经被现实超越了。随着人工智能/机器学习及其相关不确定性，事情不会变得更容易。

要成功推出作为商业智能系统一部分的人工智能驱动解决方案，你必须本质上将你的商业智能系统视为一个数据产品。这意味着承认你不知道你的想法最终是否会按计划进行，最终的解决方案会是什么样子，以及你的用户是否按预期与其互动。产品管理技术，如原型设计，将帮助你减少这些风险，并允许更灵活的开发。但在商业智能领域如何准确应用原型设计呢？

BI 生产系统中的报告通常默认为可靠和可用，其包含的信息是准确的。因此，您的生产系统并不适合在用户之间测试某些东西。我们还有什么其他选择？

通常公司使用测试系统来尝试新功能，然后再将其投入生产。但是，测试系统的问题在于其通常涉及与生产系统相同的技术工作量和挑战。通常会为测试目的复制整个生产环境：测试数据仓库、测试前端 BI 和 ETL 过程的测试区域，因为您希望确保在测试系统上有效的内容也能在生产中运行。

根据我们的定义，原型设计发生在测试之前，如 图 4-1 所示。对于原型设计，您需要从数据摄入、分析服务到用户界面的深度垂直集成，同时保持总体技术复杂性低。

图 4-1. 软件开发过程中的原型设计

在大多数情况下，特别是在单块 BI 系统中，您的生产和测试堆栈不适合在几天或几周内进行原型设计。为了我们的目的，我们需要更简单和轻量级的东西。

无论您使用哪种技术堆栈，都应确保以下内容：

• 技术堆栈支持 AI 使用案例架构的三个层面（数据、分析和用户界面），以确保数据可用且适合使用，您的模型在您的数据上表现良好，并且用户接受并看到您的解决方案的价值。

• 您的堆栈应该是开放的，并且提供高连接性，以便将来能够集成到测试系统甚至生产系统中。这一方面至关重要，因为如果测试成功，您希望能够顺利从原型阶段过渡到测试阶段。如果您在本地机器上进行原型设计，则将工作流程从计算机转移到远程服务器并期望它能顺利运行将变得非常复杂。像 Docker 这样的工具将帮助您简化过渡，减少与您最初的验证假设无关的技术摩擦。

因此，针对基于 AI 的 BI 使用案例的完美原型平台提供高连接性、许多可用的集成服务和低初投资成本。云平台已被证明相当好地满足了这些要求。

此外，你应该使用一个平台，可以轻松访问第二章中涵盖的各种 AI/ML 服务。如果有数据可用，ML 模型的原型设计最多只需两到四周，有时仅需几天。用于回归/分类任务的 AutoML、用于商品服务（如字符识别）的 AIaaS 以及用于定制深度学习应用程序的预训练模型，而不是从头开始训练它们。

在你的下一个 ML 项目中，为了避免不必要的时间和金钱浪费，建议先建立一个原型。

本书的 AI 原型工具包

在本书中，我们将使用 Microsoft Azure 作为原型设计的平台。你可以使用许多其他工具，包括 AWS 或 GCP。这些平台在功能上是可比较的，我们在 Azure 上的操作，基本上也可以在任何其他平台上完成。

我选择 Azure 有以下两个原因：

• 许多企业正在使用 Microsoft 堆栈，并且 Azure 将是他们最熟悉的云平台。

• Azure 与 Power BI 集成得非常顺畅，Power BI 是许多企业中流行的 BI 工具。

也许你会想，像 Azure 这样一个成熟的云平台如何轻便到足以用于原型设计。主要原因在于，我们并未使用整个 Azure 平台，而仅使用作为“服务”提供的部分，因此我们不必担心底层的技术细节。我们将使用的主要服务包括 Azure Machine Learning Studio、Azure Blob Storage、Azure 计算资源以及一组 Azure 认知服务，这是微软的 AI 即服务提供。

好处在于，虽然我们仍处于原型阶段，但基础架构也能应对生产环境。我们需要更改解决方案的流程、维护、集成和管理，但技术基础将保持一致。我们将在第十一章中详细讨论这一点。

我会尽量不过多依赖仅适用于 Azure 和 Power BI 的功能，但保持足够开放，以便你可以将自己的 AI 模型连接到自己的 BI。此外，大多数 Azure 与 Power BI 的集成需要专业许可证，我不希望给你带来这种麻烦。让我们从 Microsoft Azure 的设置开始。

使用 Microsoft Azure

本节简要介绍了 Microsoft Azure，并帮助你激活从第七章开始的使用案例所需的所有工具。虽然你可能暂时不需要所有这些服务，但建议提前设置它们，这样你可以专注于实际使用案例，而不是处理技术上的开销。

注册 Microsoft Azure

要在第七章及以后创建和使用 AI 服务，你需要一个 Microsoft Azure 帐户。如果你是平台的新用户，Azure 为我们在本书中涵盖的所有服务提供首次 12 个月的免费访问（截至撰写本文时）。你还将获得用量计费的服务的免费 200 美元信用额。

要探索免费访问并注册，请访问 https://azure.microsoft.com/free 并开始注册流程。

注意

如果你已经有 Azure 帐户，你可以直接跳转到 “创建 Azure 计算资源”。请注意，如果你不是在免费试用期内，可能会收费。如果你不确定，请在继续之前联系你的 Azure 管理员。

要注册，你将被提示创建一个 Microsoft 帐户。我建议你为测试目的创建一个新帐户（并利用免费信用额外奖励！）。如果你有企业帐户，你可以尝试继续使用，但你的公司可能会有限制。因此，最好从头开始，稍作试探，一旦你把一切弄清楚，再继续使用你公司的帐户。

在接下来的页面上，点击“创建一个！”（图 4-2）。

图 4-2. 创建一个新的 Microsoft 帐户

接下来，输入你的电子邮件地址，然后点击下一步。创建一个密码并继续。确认你不是机器人后，你应该看到 图 4-3 中显示的屏幕。

图 4-3. Azure 注册提示

你必须通过有效的电话号码确认你的帐户。输入你的信息，点击“给我发短信”或“给我打电话”。输入验证码，然后点击“验证代码”。成功验证后，查看条款并点击下一步。

你就快成功了！最后一个提示需要你提供信用卡信息。为什么？所有主要云平台都是如此。一旦你的免费信用额用完或免费期限到期，你将会被收费使用这些服务。但是对于初学者来说，微软的好处是你不会自动收费。免费期结束时，你将需要选择按使用量计费。

成功注册后，你应该看到 图 4-4 中显示的 Azure 门户屏幕。

图 4-4. Azure 门户仪表板

欢迎来到 Microsoft Azure！你可以随时访问这个主页，访问 portal.azure.com。让我们快速浏览 Azure 门户首页：

导航栏（1）

你可以在左侧打开门户菜单，或者在右上角导航至你的帐户设置。

Azure 服务（2）

这些是为您推荐的服务。对于您来说，它们可能看起来不同，特别是如果您是新注册用户。

创建资源（3）

这将是您最常使用的按钮之一。您可以使用它在 Azure 上创建新的服务资源。

导航（4）

此部分包含工具和其他各种项目，可带您进入各种设置。目前您不需要它们。

当您看到此屏幕时，您的 Microsoft Azure 设置已完成。如果您在设置 Azure 帐户时遇到问题，我建议您查阅以下资源：

• Azure 视频

• Azure Lessons 网站

创建 Azure 机器学习工作室工作区

Azure 机器学习工作室将成为我们在 Microsoft Azure 中构建和部署自定义 ML 模型以及管理数据集的工作台。您首先需要创建一个 Azure 机器学习工作区。工作区是您 Azure 帐户中的基本资源，其中包含所有实验、训练和部署的 ML 模型。

工作区资源与您的 Azure 订阅相关联。虽然您可以通过编程方式创建和管理这些服务，但我们将使用 Azure 门户来浏览整个过程。请记住，您在这里使用鼠标和键盘完成的每一步都可以通过自动化脚本来完成。

登录到您用于 Azure 订阅的 Microsoft 帐户，并访问 portal.azure.com。点击“创建资源”按钮（图 4-5）。

图 4-5. 在 Azure 中创建新资源

现在使用搜索栏查找 **machine** **learning** 并选择它（图 4-6）。

图 4-6. 搜索 ML 资源

在机器学习部分，点击创建（图 4-7）。

图 4-7. 创建新的 ML 资源

您需要为新工作区提供一些信息，如 图 4-8 所示：

工作区名称

为工作区选择一个与您创建的其他工作区不同的唯一名称。项目名称通常是工作区名称的良好选择。本示例使用 auto-ml。名称必须在所选资源组内是唯一的。

订阅

选择要使用的 Azure 订阅。

资源组

资源组将您 Azure 订阅中的资源捆绑在一起，例如可能与您的部门相关联。我强烈建议您在此阶段创建一个新的资源组，并将您将为本书设置的任何服务分配给此资源组。这将使以后的清理工作变得更加容易。单击“创建新内容”，并为新的资源组命名。此示例使用 ai-powered-bi。无论何时在任何地方看到此引用，请用您自己资源组的名称替换它。

位置

选择最接近用户和数据资源的物理位置。在将数据传输至欧盟（EU）等受保护地理区域之外时，请格外小心。大多数服务通常首先在美国地区提供。

输入完所有信息后，请单击“审阅 + 创建”。通过初步验证后，再次单击创建。

图 4-8. 配置 ML 资源

在 Azure 云中创建您的工作区可能需要几分钟时间。完成过程后，您将看到成功消息，如图 4-9 所示。

图 4-9. ML 资源创建成功

要查看新的工作区，请单击“转到资源”。这将带您到 ML 资源页面（参见图 4-10）。

图 4-10. ML 资源概览

您现在已选择先前创建的工作区。在此验证您的订阅和资源组。如果您希望通过编程方式训练和部署 ML 模型，现在还可以转到您喜欢的代码编辑器，并从那里继续。

但由于我们希望继续无代码旅程，请单击“启动工作室”以在不编写任何代码的情况下训练和部署 ML 模型。这将带您到机器学习工作室的欢迎界面（参见图 4-11）。您还可以直接访问 ml.azure.com。

图 4-11. Azure 机器学习工作室主页

机器学习工作室是一个网络界面，包含多种 ML 工具，适用于各种数据科学场景，适合各种技能水平的数据科学从业者。该工作室支持所有现代网络浏览器（不包括 Internet Explorer）。

欢迎界面分为三个主要区域：

• 左侧是菜单栏，可访问 ML Studio 中的所有服务。

• 顶部是推荐服务，您可以通过单击“创建新内容”直接创建更多服务。

• 底部将显示 ML Studio 内最近启动的服务或资源概览（由于您刚刚设置了帐户，此处应为空）。

创建 Azure 计算资源

您已经创建了 Azure 订阅和 Machine Learning Studio 的工作区。到目前为止，您还没有启动任何实际执行任务的服务或资源，可以将这些视为“开销”。

现在即将改变。在接下来的步骤中，您将创建一个计算资源。您可以将计算资源想象成一个虚拟机（或一组虚拟机），在这里运行您的作业的实际工作负载。在现代云平台（如 Microsoft Azure）上，可以通过几次点击（或从命令行提示）来创建和删除计算资源，并在几秒钟内进行配置或关闭。您可以选择各种机器设置——从小型便宜的计算机到支持图形处理单元（GPU）的高性能机器。

警告

创建计算资源后，资源在线后，将按照计算资源列表中提到的价格（例如，每小时$0.6）进行计费。如果您仍在使用免费的 Azure 信用额度，则费用将从中扣除。否则，将会直接从您的信用卡中扣款。为了避免不必要的费用，请确保停止或删除任何您不再需要的计算资源。

您将创建一个计算资源，您可以在本书中的所有示例中使用它。在实际操作中，您可能希望为不同的项目设置不同的计算资源，以便更透明地了解哪个项目产生了哪些成本。然而，在我们的原型示例中，一个资源就足够了，您可以轻松跟踪资源是否正在运行，以免耗尽您的免费试用预算。

您可以直接在 Azure ML Studio 中创建计算资源。在左侧导航栏中点击“计算”选项。

然后点击“创建新的计算”，屏幕将显示类似于图 4-12 的界面。要选择机器类型，请选择“从所有选项中选择”单选按钮。

图 4-12. 创建新的计算实例

您可以在这里看到所有可用的机器类型（图 4-13）。分配的性能越高，通常机器学习培训速度越快。美国东部地区最便宜的资源是一台标准型 DS1_v2 机器，配有一个核心、3.5 GB RAM 和 7 GB 存储空间，大约每小时约 $0.06。

在“按 VM 名称搜索”选项中键入 **Standard_DS1** 并选择价格最低的机器，如图 4-13 所示。在这里，您可以选择任何类型的机器；只需确保价格合理，因为目前我们不需要高性能。

图 4-13. 选择一个标准型 DS11 机器

点击“创建”按钮。这将带您回到计算资源的概述页面。请等待资源创建完成，通常需要两到五分钟。一旦资源配置完成，计算资源将自动启动（见图 4-14）。

图 4-14. 计算资源正在运行

由于您在第七章之前不需要此资源，请选择该资源并点击“停止”以防止其占用资源。最终，您的计算资源摘要页面应类似于图 4-15。您的计算资源应显示在列表中，但其状态应为已停止。

图 4-15. 计算资源已停止

创建 Azure Blob 存储

我们原型设置的最后一个构建块是存储和上传文件的地方，例如 CSV 表格或图像。这些二进制文件的典型存放位置是 Azure Blob 存储；blob代表二进制大对象，基本上是几乎所有文件的文件存储，具有几乎无限的扩展能力。我们主要用于从我们的 AI 模型写入输出或为第七章中的用例分期图像文件。

要在 Azure 中创建 blob 存储，请访问portal.azure.com并搜索**storage accounts**。点击“创建”并在与您的 ML Studio 资源位于同一地区的位置创建新的存储帐户。为此帐户指定一个唯一名称，然后选择标准性能和本地冗余存储，如图 4-16 所示。由于这仅是测试数据，您无需为更高的数据可用性标准支付更多。再次强调，您只会在这里暂时保存数据，并且这些费用将完全被您的免费试用预算覆盖。

图 4-16. 正在创建存储帐户

部署完成后，点击“转到资源”。您将看到图 4-17 所示的界面。

图 4-17. Azure 存储帐户概述

点击左侧的“访问密钥”以打开如图 4-18 所示的屏幕。在以编程方式访问存储中的对象时，您将需要这些访问密钥。

图 4-18. Azure 存储帐户访问密钥

现在您已经有一个存储帐户和用于操作数据的密钥，您需要创建一个容器，这类似于一个帮助组织文件的文件夹。点击左侧菜单中的“容器”选项，然后点击屏幕顶部的“+ 容器”，如图 4-19 所示。

图 4-19. 创建 Azure Blob Storage 容器

创建名为**tables**的容器。将访问级别设置为“容器”，这样通过外部工具如 Power BI 稍后访问文件会更加方便。创建另一个名为**simulation**的容器，设置相同的配置。

如果涉及敏感或生产数据，当然应选择“私有”，以确保在访问数据之前需要授权。新容器将显示在列表中，并准备好用于托管一些文件。

使用 Microsoft Power BI

对于用户层，我们将依赖 Microsoft Power BI 作为工具来显示报告、仪表板以及 AI 模型的结果。Power BI 有两个版本：Power BI Desktop 和 Power BI Service。

Power BI Desktop 目前仅适用于 Windows。这款离线应用安装在您的计算机上，并拥有您可以期待的所有 Power BI 功能。如果您有 Microsoft Office 订阅，Power BI 很可能是其一部分。您可以从Microsoft Power BI 下载页面下载 Power BI。

Power BI Service 是 Power BI 的在线版本，可在包括 Mac 在内的所有平台上运行。它目前并不具备桌面版本的所有功能，但定期添加新功能。不能保证本书涵盖的所有内容都能在 Power BI Service 上运行，但如果无法或不想在计算机上安装 Power BI，则可以尝试使用它。您可以从其入门页面开始使用 Power BI Service。

如果您以前从未使用过 Power BI，观看微软的 45 分钟入门课程可能会很有帮助，该课程会高层次地介绍工具的工作原理。

警告

不幸的是，Power BI 并不总是能提供完全可复制的结果。在本书的使用案例中，您可能会注意到您的一些视觉效果和自动建议与本书中的截图不完全一致。不要对此感到过度困惑，总体上的情况应该是相同的，即使在这里和那里出现一些小变化。

如果您不喜欢使用 Power BI，或者想使用自己的 BI 工具，您应该能够在其他任何支持 Python 或 R 脚本执行的 BI 工具中重新创建本案例研究（除了第五章和第六章）。

要在 Power BI 中运行 Python 或 R 脚本，您需要在计算机上安装其中一种语言，并让 Power BI 指向相应的内核。请检查以下资源，确保 Power BI 与 R 或 Power BI 与 Python 正确设置：

• 在 Power BI Desktop 中运行 R 脚本。

• 在 Power BI Desktop 中运行 Python 脚本。

除了干净的 Python 或 R 引擎外，您稍后需要一些用例操作的包。对于 R 来说，这些包如下：

• httr（用于进行 HTTP 请求）

• rjson（用于处理 API 响应）

• dplyr（用于数据准备）

对于 Python 脚本，其等效项如下：

• requests

• json

• pandas

确保这些包已安装到您使用的 Power BI 中的 R 或 Python 引擎中。如果您不知道如何在 R 或 Python 中安装包，请查看以下 YouTube 视频：

• “在 R 中安装包”

• “Python 工作坊—安装包”

摘要

希望本章为您在数据产品开发原型的背景下对原型有了坚实的理解，并且为何强烈建议在任何 AI/ML 项目中首先使用原型进行了解释。到目前为止，您应该已经准备好个人的原型工具包，以便在下一章节中处理实际的用例。让我们开始吧！

第五章：AI 动力描述性分析

在本章中，我们将探讨两个用例，展示 AI 如何帮助我们更快地执行描述性分析，并提供一种更直观和无缝互动大数据集的方式，即使是非技术人员也能轻松掌握。我们还将看到现代 BI 工具（例如 Power BI）的自然语言能力如何为我们减少一些单调的任务。

使用案例：用自然语言查询数据

业务用户典型的分析思维过程通常从一个简单的问题开始，比如以下之一：

• 上个月我的销售额是多少？

• 今年我们比去年卖得更多了吗？

• 最畅销的产品是什么？

这些问题大多是描述性的。用户首先需要了解现状，然后才能深入分析甚至预测未来事件。

解决这个问题的经典方法是，分析师为特定的业务单位或部门的最常见问题创建一组静态报告。然而，通过静态报告或可视化来预测所有最常见的问题对于业务分析师或 BI 设计师来说是极其困难的。根据你关注的问题和询问的人员，感兴趣的确切领域可能有根本不同。在组织中，这通常会导致与不同利益相关者长时间而详尽地讨论在仪表板中显示哪些图表。

这就是自助 BI 系统通常介入的地方，允许个人创建自己的内容。与事先生成所有重要的仪表板和可视化不同，业务用户可以自行切割和切块数据，并创建他们需要的可视化效果。

然而，自助 BI 系统也存在问题。首先，通过可定制的逐级深入或额外维度不可能激活所有可能的思维路径。一个问题经常导致另一个问题，而在数据模型中预测所有可能的思维路径会导致复杂的数据结构和不直观的报告生成器——只是为了展示一些过去的描述性分析。其次，并非所有业务用户都了解如何正确地切割和切块数据，这导致不正确的仪表板和错误的洞察力。将各种度量和维度汇总到自定义仪表板中，对于未接受过培训的非技术用户来说仍然意味着很多摩擦。

总结一下，BI 系统中的静态和自助式方法都无法回答个人提出的所有可能问题，而个人通常也不能总是自行筛选数据，因为这不是他们的主要任务之一。商业用户想要的是提出问题并得到答案。在这一点上，他们通常会寻求数据分析师的帮助来解决问题。当然，这种方法的可扩展性不强，因为组织通常拥有比数据分析师更多的业务用户。即使您能负担得起拥有大量分析专业知识，您也不希望让分析师忙于重复、易于解决的任务。现在让我们为我们的示例用例场景奠定情景基础。

问题陈述

我们正在查看 Power BI 中的销售数据。销售管理人员在认识到积极的收入趋势后，已与 BI 团队接洽，并希望深入了解当前情况。作为 BI 分析师，我们被委托为销售人员提供支持，并帮助他们深入了解其特定关注领域的收入发展情况。在自助式 BI 的同样理念下，我们希望提供“自助式帮助”，并使销售人员能够无缝地与数据集互动，而无需任何技术障碍。

解决方案概述

与其让业务用户与数据分析师合作获取简单描述性统计的答案，更高效的方法是让用户通过自然语言提问来查询数据，并自动或几乎不需要人工干预地得到答案。大多数人甚至没有意识到，他们多年来（或者使用像 Google 这样的互联网搜索引擎多长时间以来），一直在接受这种方法的训练。

例如，如果业务用户想要比较某个国家的销售数字与去年的数据，他们可能想发出这样的查询：

• **显示我去年和今年在美国的销售情况**

实际上，由于 AI 驱动的自然语言功能，用户可以做到这一点。背后的原理是，AI 驱动的自然语言模型解释用户输入，尝试将其映射到数据集中的可用数据，并为其提供适当的可视化效果。这一体验应该快速、互动且无摩擦。图 5-1 展示了我们解决方案的概念架构。

图 5-1. 自然语言使用案例架构

如您在 Figure 5-1 中所见，我们正在使用 Power BI 作为我们的 BI 工具，并将利用其内置的 AI 能力来解决我们的问题。因此，分析层为空，因为我们没有使用任何外部分析服务。一切都内置于 Power BI 中并在用户层中发生。其他 BI 工具，如 Tableau，提供类似的功能，但细节可能有所不同。无论如何，选择一个适合此任务的良好 BI 前端至关重要，因为如果它没有提供原生支持（或提供此类附加组件），则无法向 BI 软件添加 NLP 能力。

在 Power BI 中，NLP 功能被称为 Q&A visual。Q&A visual 允许您用自然语言探索数据，以您自己的话语进行探索。Q&A 是交互式的，甚至可能很有趣。它似乎是我们问题陈述的一个很好的候选者。

用户可以像将任何其他可视化对象拖放到报告中一样，将 Q&A visual 拖放到报告中，以便用户可以对数据执行自定义查询。Q&A visual 还可以作为一个按钮添加到功能区，与报告独立，并集成到仪表板中。它可以与以下数据源一起使用：导入的数据、连接到 Azure Analysis Services 的实时连接，以及通过网关连接到 SQL Server Analysis Services 的 Power BI 数据集。

Power BI 演示

要按照本示例操作，您首先需要从书籍网站下载名为 Sales & Marketing sample PBIX.pbix 的文件。该数据集包含来自一个虚构制造公司的各种销售和营销数据。

数据集已经预先填充了一些报告，用于跟踪公司的市场份额、产品量、销售数据和情感分数。在我们的案例研究中，我们假设数据集中的所有制造商都属于同一控股集团，以便我们可以分析总收入作为一个关注指标。因此，我们对原始情景中突出显示的个别制造商的市场份额不太感兴趣。你可以从Power BI 网站了解更多有关数据集的信息。

让我们从打开 Power BI Desktop 开始。在 Power BI 的左上部分，选择 文件 → 打开报告 → 浏览报告。然后，从您下载文件的文件夹中选择 Sales & Marketing sample PBIX.pbix 文件。您应该能看到该报告文件的介绍界面（见 Figure 5-2）。

图 5-2. Power BI 示例报告

现在，我们不会关心预先编写的报告和仪表板。我们的目标是提供销售数据的高级概述，以及使我们的用户能够与我们的数据进行交互查询。

如果这是您第一次使用 Power BI，我建议您花四分钟阅读 Microsoft 文章 “Tour the Report Editor in Power BI”。它会使您熟悉报告画布、过滤器、可视化和字段窗格等最基本的术语和概念。

首先，您需要通过点击屏幕底部的加号图标添加一个新的空白页面到报告中。在空白的报告页面上，打开右侧的可视化面板。从可视化面板中选择 Q&A 可视化图标（图 5-3），双击将其添加到画布上。

图 5-3. Q&A 可视化图标

拖动边框，使可视化填满整个报告的宽度。增加高度，以便大致覆盖报告画布的一半。您的报告屏幕现在应该看起来类似于 图 5-4。

图 5-4. Q&A 可视化默认屏幕

现在，让我们更详细地探索这个可视化。Q&A 可视化包括四个核心组件：

文本框（1）

这是用户输入其问题或查询的地方，也是他们将看到自动完成和自动建议功能的地方。

推荐问题列表（2）

这个预先填写的列表包含用户可以一键运行的示例问题。

转换图标（3）

这将把 Q&A 工具的输出转换成标准的 Power BI 可视化。

Q&A 齿轮图标（4）

这将打开一个设置菜单，允许设计人员配置底层的自然语言引擎。

让我们尝试这个可视化，选择第一个建议的问题。点击第一个示例表达式：“top geo states by sum of score.”（如果 Power BI 给出了不同的建议，请按照它的指示操作。）

Power BI 将会展示似乎最适合此分析的可视化。在这种情况下，它展示了一个地图可视化，显示了排名前的州（图 5-5）。

图 5-5. Q&A 地图输出

我们可以通过在查询中加入这部分来将其更改为几乎任何其他类型的可视化。尝试更改文本框中的文本如下：top geo states by sum of score as bar chart。这个查询将呈现一个水平条形图，而不是地图（图 5-6）。

图 5-6. Q&A 条形图输出

现在，让我们回到文本框，探索用户如何在这里输入问题。Q&A 工具可以回答各种查询，包括但不限于 表 5-1 中列出的内容。

由于我们对收入趋势感兴趣，我们想要创建一个简单的折线图，显示随时间变化的总收入，最好按年份分解。为了实现这个目标，让我们向 Power BI 提出一个简单的查询：Show me revenue over time。

表 5-1. Power BI Q&A 可视化示例命令

类型	示例
提出自然问题	哪些销售额最高？
相对日期过滤	过去一年的销售
按变量筛选	美国的销售
按条件筛选	产品类别 A 或类别 B 的销售
显示特定可视化	按产品的销售饼状图
显示聚合	按产品的销售中位数
排序	按国家代码排序的销售前 10 个国家
比较	按日期的总销售与总成本
时间	按时间的销售

我们在 图 5-7 中看到的结果并不完全符合预期。输出只是显示了 1999 年的一些日期。这里发生了什么？

图 5-7. 显示随时间变化的收入

通过查看文本框，我们可以了解更多信息，Power BI 帮助我们识别查询中的问题短语。下面“revenue”下方的红线表明 Power BI 无法解释这个变量。实际上，这里的下划线遵循一种明显的颜色代码：

• 系统以实线蓝色下划线表示成功将单词与数据模型中的字段或值匹配。

• 橙色下划线表示表达式的匹配信心较低。如果表达式不明确，例如多个字段包含“sales”表达式，则会发生这种情况。

• 红色下划线表示问答工具完全无法将单词与数据模型中的任何内容匹配。

如果单击下划线的单词，您将看到 Power BI 如何解决冲突的建议。对于“revenue”表达式，Power BI 无法将其分配给一个度量单位。让我们更加明确地调整查询如下，“Show me sum of revenue over time”。

正如您所见，如果依赖默认值，查询必须具体明确。我们稍后会修复这个问题，但现在让我们接受建议并看看会发生什么（图 5-8）。

图 5-8. 显示随时间变化的收入总和

这看起来更符合我们的预期。Power BI 展示了一个折线图，按天列出了随时间变化的总收入。虽然这不错，但我们很难看到大趋势。因此，让我们更加具体地询问，“Show me sum of revenue over time by year”。

添加by year表明我们希望 Power BI 进行年度汇总。因此，Power BI 展示了一个清晰的折线图，我们可以立即看到 2006 年收入飙升，然后随后呈负增长趋势（图 5-9）。自 2010 年以来，趋势似乎再次呈正向。

图 5-9. 显示按年度收入总和随时间变化

假设我们想保留这个可视化图表，为我们的报告消费者提供一个高层概述销售情况。默认情况下，查询结果不会保存或持久化在报告中。因此，如果报告被共享并由另一个用户打开，他们会看到空的 Q&A 可视化图表和最初的建议，就像我们之前所做的一样。

如果您想共享 Q&A 可视化的输出，您必须首先将其转换为静态可视化。要这样做，请点击转换可视化图标，在之前的 图 5-4 中显示。Power BI 将把 Q&A 可视化转换为简单的折线图。

到目前为止，我们已经创建了一个静态的高层可视化图表。现在，我们可以开始添加一个自助服务区域，使业务用户能够使用自定义问题查询数据。

将收入可视化水平调整，以在其下方腾出更多空间。选择 插入 → 文本框，在可视化顶部插入一个标题，标题为 自助服务收入分析。将此报告工作表从“第 1 页”重命名为 按年度总收入。

让我们再添加一个可视化图表。从可视化面板中双击 Q&A 可视化，使其出现在按年度总收入线图下方。您的报告现在应该类似于 图 5-10。

图 5-10. Q&A 报告布局

要使 Q&A 可视化更有帮助和更直观地用于业务用户，我们还想调整 Q&A 工具内部使用的默认建议以及措辞。单击文本框右侧的 Q&A 齿轮图标以编辑 Q&A 可视化设置。您将看到各种选项。在接下来的几段中，我将为您介绍一些选项，这些选项足以定制 Q&A 可视化，以便业务用户（而不仅仅是数据分析师）可以使用它。

我们从 字段同义词 开始，如 图 5-11 所示。在 Q&A 工具中，每个 字段（例如，度量、维度或表）都可以具有一个或多个同义词。例如，假设您的数据模型有一个度量单位“销售”，但您希望用户将此指标称为“收入”。在这种情况下，“收入”就成为“销售”的字段同义词。

Power BI 将向您显示数据维度列表，并允许您为用户所使用的各种业务术语为不同字段添加同义词。在此示例中，打开 SalesFact 列表，如 图 5-11 所示。

图 5-11. Q&A 工具中的字段同义词

您将在此列表中看到所有措施，以及同义词的自动建议和一个切换按钮，您可以选择是否将此字段包含在问答小部件中。向下滚动到“总收入”部分。点击“添加”按钮，在此处加入“总收入”作为同义词，如图 5-12 所示。还将“总的收入”，“收入”，“总收入”，“总销售额”和“总销售”添加到同义词中。我们也可以浏览其他字段，但现在让我们结束这个练习。

图 5-12. 问答字段同义词

点击左侧菜单中的“管理术语”，您将看到添加到问答视觉中的所有术语和定义的列表（图 5-13）。这样，您可以轻松跟踪您所做的任何更改，并删除不合适的术语。

图 5-13. 管理术语

现在，请转到左侧菜单中的“建议问题”。此部分允许您编辑系统默认向用户建议的问题，您可以在图 5-14 中看到。

让我们从按地区进行收入细分开始。输入 显示按地区的收入。这将在预览窗口中生成一个图表（图 5-14）。

图 5-14. 建议问题

好的，让我们通过点击“添加”按钮将其添加到我们的建议中。

业务用户通常很擅长通过示例学习。为了让用户更直观地了解如何使用问答工具，让我们对之前的问题添加一个变体。业务用户稍后应该可以舒适地用“产品”等替换“地区”等内容。

添加以下建议：显示按年度按地区的收入。这将生成三个折线图，引出了比较数据点的概念。因此，让我们添加一个更复杂的建议问题示例，展示业务用户如何比较产品销售表现。让我们添加这个略微复杂的建议问题：按年度比较 Maximus UM-01 和 Maximus UM-02 的收入。

这产生了一个非常有见地的图表，显示我们 Maximus UM-01 自 2005 年达到峰值以来的收入下降，而新产品 Maximus UM-02 自 2007 年初发布以来似乎在逐渐起飞。到 2012 年，新产品贡献的收入超过了其前身，正如您可以在图 5-15 中看到的那样。

图 5-15. 问答收入比较

为了组织建议问题列表，您可以将问题拖动到您想要的顺序中。让我们将最简单的查询移动到第一个位置，最复杂的查询移动到最后一个位置。保存建议。关闭问答设置窗口。

再次查看我们的报告，我们可以看到我们刚刚创建的三个建议现在显示在 Q&A 可视化中。业务用户可以通过简单点击建议开始其数据探索，然后根据需要修改查询，例如将“地区”替换为“地理州”。您可以在图 5-16 中看到最终示例。

图 5-16. 带 Q&A 可视化的最终报告

这种基本设置已足以将此报告的早期原型交付给一些β版业务用户。您有机会收集宝贵的反馈意见，看看是否被接受，并发现需要改进的方面。

要访问用户查询数据，请单击文本框右侧的 Q&A 齿轮图标以访问工具设置。在这里，您将找到“查看问题”菜单选项。这将列出过去 28 天提交的所有查询，以便您可以准确查看人们如何使用您的报告以及可能仍然缺少的同义词、建议或字段。这是开始迭代产品并扩展到更多用户的绝佳地点。如果您想分享此报告，您需要 Power BI Pro 或 Premium 许可证。

如果您想详细了解 Q&A 工具及其管理工作的更多信息，您可能会发现来自 Microsoft 文档的以下资源有用：

• “优化 Power BI 中 Q&A 的最佳实践”

• “Q&A 工具入门：训练 Power BI Q&A”

• “编辑 Power BI Desktop 中的 Q&A 语言模式并添加短语”

使用案例：用自然语言总结数据

业务分析师经常必须编制数据故事，以向业务利益相关者传达见解。尽管他们大部分时间通常花在创建引人注目的视觉上，但与结论进行注释的过程可能会很繁琐和乏味。因此，分析师经常跳过向他们的视觉添加口头评论的步骤，因为图表本身就能说话，不是吗？实际上，许多图表可能会被误解，尤其是在涉及更复杂的可视化时。让我们想象以下情景。

问题说明

基于我们在“使用案例：使用自然语言查询数据”中创建的视觉效果，我们现在希望添加标题，以帮助非技术利益相关者解释数据。我们想提供标题以清晰地表达见解，但我们不想花费太多时间手动编写它们。

解决方案概述

自然语言处理技术使我们能够利用机器不仅分析和解释人类语言，还能根据定义的输入生成文本。在这个示例中，我们可以使用 AI 技术为给定的图表及其基础数据创建标题或注释。

注释应包括关键要点，指出趋势，并允许根据特定受众编辑语言和格式。它们还是使我们的报告对视觉障碍者更易访问的绝佳方式！图 5-17 展示了高级用例架构。

图 5-17. 智能叙述用例架构

再次强调，此示例仅使用内置的 Power BI 功能。Power BI 中名为 智能叙述 的功能适用于设计师和开发人员，无论是在 Power BI Desktop 还是 Power BI Service 中。该功能适用于所有许可类型，不需要 Pro 或 Premium 许可证。我们将探讨如何使用这些自动生成的标题为我们在 “用例：使用自然语言查询数据” 中创建的可视化对象生成数据故事。

Power BI 演练

打开 Sales & Marketing sample PBIX.pbix 文件，从 “用例：使用自然语言查询数据” 中创建一个新的报告页面，并将其命名为 Story。

我们希望创建以下四个可视化对象：

• 按年份收入

• 按州收入

• 按部门收入

• 按年份和部门收入

您可以使用 Q&A 工具快速实现这一点：从可视化面板双击 Q&A 可视化对象，输入前面列表中的查询，然后将其转换为标准可视化对象。对每个收入分解重复此过程。您能看到使用 Power BI 的 AI NLP 功能与传统手动选择可视化对象、映射数据和手动筛选相比创建这些可视化对象有多快吗？

将页面上的可视化对象排列在右侧留有空间的方式。您的页面应类似于 图 5-18。

图 5-18. 销售仪表盘

打开可视化面板。你应该看到“智能叙述”图标（图 5-19）。

注意

如果在可视化面板中看不到“智能叙述”图标，则可能是您正在使用的 Power BI 版本较旧，需要打开智能叙述选项。选择 文件 → 选项和设置 → 选项 → 预览功能，并确保打开智能叙述可视化。

图 5-19. 智能叙述可视化

双击“智能叙述”图标应在页面右侧添加一个文本框。或者，您可以将可视化对象拖放到页面上您喜欢的位置。此文本框将包含 Power BI 为页面上的所有可视化建议的描述。在我们的情况下，描述将看起来像 图 5-20 中的输出。如果点击文本框，您将看到 Power BI 在此处计算的突出显示值。

图 5-20. 智能叙述输出

这里有几个有趣的事情需要注意。在第一行中，您可以看到 Power BI 认识到收入呈下降趋势，并计算了收入时间序列起始和结束的百分比（见图 5-21）。它还建议，产品细分“Moderation”在 2014 年占总收入的 52.59%。当您发现某个陈述不够相关甚至是多余时，您可以简单地从摘要中删除此行。

您还可以详细探索计算出的值，并对其应用格式。例如，单击计算出的收入数字。在上下文菜单中，您可以选择将该值显示为无小数点后的货币形式。

图 5-21. 智能叙述格式化

格式化自动生成的文本输出将使读者更易理解，整体外观也会更加优雅。然而，当我们查看摘要时，我们意识到有关区域销售细分的信息并未提供。也许这些信息对 Power BI 来说并不重要？要手动添加这些详细信息，请右键单击显示按州销售数据的地图图表，并从上下文菜单中选择总结。Power BI 将添加另一个文本框，显示您仅选择的图表的描述。同样，您可以根据需要删除或修改这些描述。

关于自动生成标题的一个重要说明是它们完全动态，并响应底层图表的变化。为了演示这一点，让我们向我们的仪表板添加一个页面过滤器，仅显示 2010 年之后的数据，如图 5-22 所示。打开字段窗格，然后将“年份”字段拖放到“本页面上的过滤器”选项窗格中。一旦应用过滤器，请注意文本框内容的变化。Power BI 认识到收入趋势现在向上，并相应地更新相关的百分比。

图 5-22. 智能叙述响应全局过滤和数据变化

仍然缺少的是对仪表板上最重要的图表之一——按细分划分的收入详细说明。您可以清楚地看到，“Moderation”细分是唯一具有相关正向趋势的细分——这应该是智能叙述工具易于识别的内容，对吗？右键单击图表并点击总结。但结果如何？Power BI 只是在智能叙述框中响应一行文本，这非常难以解释。

我们在这里触及了智能叙述功能的边界。在撰写本文时，尚无法总结具有许多类别或潜在趋势的非常复杂的图表。此外，目前不支持重命名动态值或编辑自动生成的动态值，并且无法为包含即时计算（如复杂度量或百分比）的可视化生成摘要。

由于智能叙述功能最初仅于 2021 年发布，我们将看到哪些限制会消失令人兴奋。您可以在微软资源文档中找到有关智能叙述工具的更多详细信息。

现在，让我们手动为仪表板添加最终结论。在最后一个文本框中添加一行新内容，输入 Conclusion: Sales from product segment Moderation were the main reason for the positive revenue trend between 2011 and 2014。您的最终销售仪表板现在应该看起来类似于 图 5-23。

尽管智能叙述工具具有比本书更多的自定义和配置选项（例如，通过使用 Q&A 风格的语言查询定义自定义值），我们将保持现状。如果您想了解更多关于智能叙述工具的信息，请查看微软的 YouTube 视频教程 “如何使用 Power BI 的智能叙述”。

图 5-23. 带有注释的最终销售仪表板

现在，您可以轻松地将此页面导出为 PDF（文件 → 导出 → 导出为 PDF）或将其发布到 Power BI 服务器。虽然详细讨论 Power BI 中各种共享和发布功能超出了本书的范围，但我建议阅读微软文档 “在 Power BI 中进行协作和共享的方式” 以便深入了解此主题的开始。

现在，只需保存报告（文件 → 保存），因为我们将在下一章回到此示例。您可以通过从本书网站下载 Sales & Marketing Sample_AI-Powered.pbix 来获取包含本章所有练习的完成文件。

总结

在本章中，您学习了如何利用 Power BI 中的基于人工智能的自然语言能力，通过 Q&A 工具更快地创建可视化，并为用户提供更好的 BI 体验。您还学习了如何使用 Power BI 中的智能叙述工具自动化可视化的注释过程，并在运行时添加描述。

在下一章中，我们将进一步探索我们的数据，并找出影响收入趋势的因素。我们将使用 AI 驱动的工具来减少我们获得洞察力的时间，并自动检查有趣模式的数据。

第六章：基于 AI 的诊断分析

找出发生了什么只有一半有趣，找出为什么发生了同样重要。虽然原始数据无法告诉我们事件发生的因果原因，但我们可以分析数据的模式并得出明智的结论。至少，这些模式将指引我们朝着正确的方向前进。在本章中，您将了解人工智能如何帮助您自动地揭示数据中的有趣模式，以便您和您的同事能够集中精力解释和分析这些数据的影响。

应用案例：自动化洞察

我们将继续前一章的案例研究：在一个虚构的制造公司中，我们支持销售管理团队进行决策过程中的支持。在第五章中，我们发现销售似乎在经历了急剧下降后正在缓慢复苏。现在我们将深入分析，并专注于理解为什么某些趋势会发展。

问题陈述

作为团队的业务分析师，我们希望帮助销售管理团队找出两个观察到的收入趋势的解释：为什么销售数字在 2006 年至 2010 年间急剧下降，以及什么因素解释了 2010 年至 2014 年间的缓慢恢复？顺便说一句，如果这是一个真实的情景，我们可能不会在八年期间进行分析，因为很多事情可能已经发生了变化。如果有帮助的话，可以想象我们是一个销售周期非常长的制造公司。

这个过程通常需要手动处理数据，这需要时间，并受分析师可用性的限制。由于我们没有能力与每个业务用户进行一对一的会话，我们正在寻找以更自动化和交互方式向他们提供洞察的方法。

解决方案概述

我们的目标是通过尽可能少的人为干预，自动扫描所有可用信息，在我们的数据集中自动找出模式。为此，我们正在利用基于 AI 的技术以快速和交互方式提供这些洞察。这将允许业务用户在较少或甚至无需专业数据分析师帮助的情况下获得洞察。图 6-1 为您提供了用例架构的概述。

图 6-1. 自动化洞察用例架构

正如前一章的例子一样，这个架构非常直接，因为我们在 Power BI 内完成所有操作。为了提供这种体验，我们特别使用了两个 Power BI 工具：关键影响者和分解树工具。

关键影响因素可视化有助于理解影响感兴趣指标的因素，通过展示对所选指标贡献最大的顶级贡献者。它会检查您提供的信息，并通过将其标记为关键影响因素，将最重要的方面置于顶部。

Power BI 的分解树视觉允许您以多个维度可视化数据。它会自动聚合数据，并允许您按任何顺序深入到任何维度。AI 会根据您特定的兴趣领域建议下一个最相关的维度。因此，这是一种进行即席调查和根本原因分析的有用工具。

我们将这些技术应用于销售和营销示例 Power BI 报告，以找出驱动收入趋势和从数据中观察到的模式。在企业场景中，这两个工具可以以 Power BI 报告页面的形式提供给业务用户，以便他们可以自行与数据交互。

Power BI 漫游

如果您继续跟随上一章的用例，可以继续在您的Sales & Marketing sample PBIX.pbix文件中工作。如果没有，请随时从书籍网站下载Sales & Marketing Sample_AI-Powered.pbix。简要回顾一下，这个数据集包含来自制造公司的各种销售和营销数据，并预先填充了市场份额、产品销量、销售数字和情感评分的报告。

在第五章中，我们发现在前一年经历了一次艰难的反弹后，过去四年的总收入慢慢恢复。图 6-2 是我们之前创建的销售仪表板的快照。

图 6-2. 两个阶段的收入趋势

我们特别关注在收入下降阶段（2006 年至 2010 年，阶段 A）和收入缓慢恢复阶段（2010 年至 2014 年，阶段 B）期间发生了什么，“发生了什么？”这个简单而深刻的问题。

我们将从审视阶段 A 开始。为了重新创建收入可视化效果，请创建一个新的 Power BI 报告页面，拖放 Q&A 视觉，并输入**Revenue by year between 2006 and 2010**。

单击“转换”图标，将 Q&A 视觉转换为标准 Power BI 视觉。图表应该看起来类似于图 6-3。

图 6-3. 2006 年至 2010 年每年收入

选择此图表并打开右侧的可视化窗格。单击“关键影响力”图标，将折线图转换为关键影响力视觉(图 6-4)。

图 6-4. “关键影响力”视觉图标

一旦您选择了新的视觉类型，图表将自动更新为与图 6-5 类似的内容。让我们更详细地探索这种视觉输出。

图 6-5. 关键影响者标准输出

现在，这个输出可能根本不是您期望的，看起来确实有点奇怪。出了什么问题？打开可视化面板，检查关键影响者视觉的属性。这应该看起来像图 6-6。

图 6-6. 从折线图转换后的关键影响者属性

在可视化属性中，您会找到两个关键字段：“分析”和“按年份”。顾名思义，分析是指您希望探索的度量标准，“按年份”则是指可能影响该度量标准的各种维度。默认情况下，鉴于我们先前的折线图，Power BI 建议用“收入总和”字段解释“按年份”维度，这完全没有任何意义。

让我们通过将“收入总和”字段从“按年份”字段拖到分析字段中来修复这个问题。因此，从右侧的数据字段库中拉取其他维度到“按年份”字段中。从商业角度来看，合理的候选字段可能包括段、城市、州、地区、评分平均值、类别和制造商。我们将排除产品维度，因为缺失的数据点太多。例如，一些产品被其他产品替换，一些产品刚刚推出，而一些产品已经过时。如果我们想要分析产品级别的主要影响因素，我们应该查看单个年份而不是四年期间。

关键影响者工具的更新属性现在应该看起来像图 6-7。

图 6-7. 关键影响者属性（已编辑）

在关键影响者视觉中，将顶部的下拉菜单从“增加”切换到“减少”，因为我们有兴趣找出导致收入下降的原因。更新后的视觉现在应该类似于图 6-8。

这种视觉直观地比以前的版本更有意义。请注意，这将是您可以为业务用户共享或发布的报告页面，以便他们可以自行与数据交互。让我们深入了解这个视觉，看看它在更详细的层面上是如何工作的。

图 6-8. 关键影响者工具已编辑

在可视化的左侧，我们可以看到 Power BI 识别出来的在给定指标（在本例中为收入）上作为关键影响因素的变量。我们可以看到，Power BI 确定了维度类别和段的属性 Youth 作为导致收入指标下降的主要关键驱动因素。在右侧，我们展示了所选影响因素的底层数据分布，显示了在所选维度（在本例中为类别维度）中所有类别的收入指标的平均值。您可以按照以下方式阅读右侧的图表：类别 Youth 的平均收入仅为$5,181.98，而除 Youth 以外的所有其他类别的平均收入为$17,349.89。这意味着，当类别是 Youth 时，平均收入比该类别的所有其他值低$12,920。

需要强调的是，在这种情况下，我们不是基于变量的绝对值进行评判，而是基于它们的平均值和观察次数。根据您选择分析的度量标准（无论是分类还是连续），关键影响因素工具将会进行调整。它不会指示平均值，而是会指出如果满足某个值，结果可能是x倍更有可能发生。

关键影响因素工具并不总是将类别的最低值视为影响因素。举例来说，在我们的分析中，以“制造商是 Victoria”为影响因素。如果您点击此影响因素，您将会看到图 6-9 中的图表。您可以看到 Victoria 并不是平均收入最低的制造商，而实际上是 Salvus。那么为什么 Salvus 没有被识别为关键影响因素呢？

Figure 6-9. Phase A 的关键影响因素可视化（负收入趋势）

如果我们看一看 Salvus 和 Victoria 在图 6-10 中的头对头比较，这些原因将变得清晰，这只是为了促进我们对关键影响因素工具如何运作的理解。

Figure 6-10. 比较制造商 Salvus 和 Victoria 的销售情况

有三个因素使 Salvus 不符合关键影响因素的条件。首先，该制造商仅在 2009 年引入，因此总数据点较少，与其他制造商相比。其次，Salvus 的绝对收入贡献非常小，可能缺乏总体影响力。最后但同样重要的是，该制造商的实际收入趋势并非负向，而是正向。尽管 Victoria 的收入从 2006 年的 620 万美元下降到 2010 年的 430 万美元，Salvus 在 2009 年至 2010 年间实际上提高了其收入。

有了这些背景信息，合理地认为 Salvus 不是整体收入下降的关键影响者。关键影响者工具使我们能够更轻松地发现这些有趣的模式，而无需手动搜索所有数据。

让我们探索关键影响因素工具的另一个有用特性：细分领域。细分领域 可以被认为是数据中结合不同值的组，显示对感兴趣的指标有高影响力。切换到 “Top segments” 并选择顶部下拉菜单中的 “When is Sum of Revenue more likely to be Low”，您应该会看到结果显示为 图 6-11 的屏幕。

图 6-11. 分析导致负收入趋势的细分领域

您可以看到 Power BI 为我们识别出的四个细分领域。最大的细分领域，由气泡大小表示，拥有 24,506 个观察点（销售产品），平均每笔销售仅为 $5.43K。低表现的细分领域具有最高（但低于总体）平均收入为 $11.11K，包含 9,282 个观察点。

要了解更多关于这里发生了什么的信息，点击 5.43K 气泡。您将看到这个细分领域的详细视图，在这种情况下看起来像 图 6-12。

从这张图表中，我们可以看出这个细分领域占据了几乎所有产品销售的 16%，因此对我们来说具有非常高的相关性。这个细分领域包含了所有类别不是 Urban、制造商不是 VanArsdel、地区不是 West、而且段不是 Productivity 的销售。这个细分领域贡献了最大的数据点组，并且平均收入最低，这使得在解释 Phase A（2006–2010 年）收入下降趋势时，它成为需要重点关注的一个重要细分领域。

要详细了解这意味着什么，让我们比较分析这个 Segment 1 的收入趋势，与从 2006 年到 2010 年的总体收入趋势进行对比（参见 图 6-13）。

图 6-12. Segment 1 详细信息

图 6-13. 总体收入趋势和 Segment 1 收入的趋势

虽然整体收入数据集从 $643.28 million 下降了 46.6% 至 $343.13 million，仅 Segment 1 就贡献了损失 $12.3 million，从 2006 年的 $31.10 million 下降至 2010 年的 $18.8 million。这些更专注的细分领域对商业用户来说应该更容易处理，并且能够识别潜在的问题区域，而不是像青年类别这样的更大趋势。

我们可以以类似的方式探索其他部分，但让我们暂时结束对过去收入下降的分析，并转向了解在 2010 年至 2014 年期间恢复期间发生了什么，即 B 阶段。如果您对更多关于关键影响者工具工作方式的特性和描述感兴趣，可以查看微软的“创建关键影响者可视化”。

对于阶段 B 的分析，我们将切换到 Power BI 中的分解树功能。分解树是进行根本原因分析的重要工具。您可以将其用作智能下钻，因为 Power BI 根据您想要探索的特定指标自动建议下一个下钻级别。

为了达到这个目的，在您的 Power BI 文件中的空报告页开始。重新创建收入按年份图表，这次的时间段是从 2010 年到 2014 年。如果您使用了 Q&A 工具，请将此图表转换为静态视觉。现在，收入图应该看起来类似于图 6-14。

图 6-14. 2010 年至 2014 年总收入

选择折线图并将可视化类型更改为“分解树”，如图 6-15 所示。

图 6-15. “分解树”图标

与使用关键影响者工具类似，我们必须告诉 Power BI 我们要分析哪个变量，以及我们认为哪些维度是解释因素。修改视觉属性，使其看起来像图 6-16 中的样子。

图 6-16. 分解树属性

分解树视觉化的初始输出将是一个空白画布上我们感兴趣的度量的简单摘要。您可以在图 6-17 中看到这个输出。

图 6-17. 分解树开始

现在的任务是将此聚合指标分解为较小的块，最好是以捕获树顶部最重要的指标为目标进行拆分。当您单击聚合收入右侧的小+图标时，将弹出一个菜单，供您选择要进行的下一个拆分。

您可以手动选择拆分（例如，基于业务逻辑或您自己的偏好），也可以使用称为AI 拆分的功能。我们稍后将回到这个概念，考虑哪些情况可能合理地手动下钻级别。AI 拆分由小灯泡标示，并将根据您是否希望影响顶级指标更高或更小而自动选择下一个最佳下钻级别，如您在图 6-18 中所见。

Figure 6-18. 在分解树中使用 AI 拆分

由于我们有兴趣解释 B 阶段的收入增长，让我们选择一个高值的 AI 拆分。Power BI 会根据类别的条件为你创建第一个拆分，如 Figure 6-19 所示。

Figure 6-19. 分解树中的第一级拆分

如果你将鼠标悬停在与类别拆分相邻的灯泡上，你将看到 Power BI 工具提示，解释树的当前节点。在本例中，第一个拆分告诉你，当类别为 Urban 时，2010 年至 2014 年的收入最高（见 Figure 6-20）。

Figure 6-20. AI 拆分解释

现在您可以深入挖掘，例如查找在 Urban 类别内收入增长的标准是什么。同样，我们可以手动选择下一个深入级别，也可以让 Power BI 为我们找出来，这取决于我们是对高值还是低值感兴趣（见 Figure 6-21）。

Figure 6-21. 第二级 AI 拆分

如果您再次选择“高值”，您将看到下一个拆分将在制造商字段上进行，如 Figure 6-22 所示。

此时，让我们停下来，快速回顾一下为什么我们会按照这个顺序看到这些拆分。为什么数据不先按制造商拆分，然后再按类别拆分呢？至少我们已经看到，制造商 VanArsdel 声称大部分收入。

Figure 6-22. 分解树中的第二级拆分

这是因为 Power BI 中的底层算法是贪婪的。它会选择在拆分带来最大优势的点处的下一个深入类别。为了演示这一现象，让我们对比一下按类别和按制造商划分的收入，如 Figure 6-23 所示。

Figure 6-23. 按制造商和类别划分的收入

您可以清楚地看到，Urban 和 VanArsdel 在其类别中显著突出作为主要的收入驱动因素。然而，更仔细观察，您会注意到 Urban 占大约 85%的收入份额，而 VanArsdel 仅占 53%。这是因为我们有比类别更多的制造商，它们从这一领域的领先关键驱动因素中夺走了大量小份额。这就是为什么 Power BI 首先按类别拆分数据，然后才按制造商拆分的原因。

尽管这种贪婪的方法大多数情况下效果相当不错，但在某些情况下需要小心。在某个分割后检查数据时，你只能分析实际存在于该分割中的数据。例如，首先按类别分割，然后探索城市类别，你将只看到该树枝中实际在城市类别生产产品的制造商。如果数据集中的制造商没有为城市类别生产任何商品，那么该制造商将不会出现在该树枝的后续分割中。

另一方面，这意味着 Power BI 很可能永远不会（或仅在树的最后阶段）建议基于所有观察值均匀分布的字段进行分割。例如，我们可以在数据集的州维度中观察到这一点；最大的收入贡献者（加利福尼亚州）仅占总收入的约 10%，而最小的贡献者占约 4.8%。各州在收入方面几乎是均匀分布的，因此它们不适合 Power BI 根据它们创建分割。如果州对您的业务（或不同的业务用户）起到作用，您可以在第一级手动选择这些分割，或者根据您感兴趣的州添加页面过滤器。

回到我们的分解树示例，我们希望为高值再添加两个 AI 分割。如果您添加了这些分割，您应该会看到一个看起来像图 6-24 的树。

图 6-24。最终的分解树

当您查看这棵树时，您可以立即看到在 2010 年至 2014 年期间，来自东部地区、制造商 VanArsdel 的 Moderation 段的 Urban 类别销售对收入增长的主要贡献者。如果您创建一个具有这些过滤条件的折线图，并将其与整体总收入进行比较，您可以清楚地看到这种情况在图 6-25 中的表现。

仅从这个段落的销售就为我们的总收入增长贡献了超过 2000 万美元，并且相对增长率（+46%）比绝对收入趋势（+15%）增长更强。

通过分解树，业务用户可以轻松与数据交互，并找到他们需要的粒度级别上的相关贡献者。在使用 Power BI 的 AI 功能自动筛选数据后，如果需要，要让数据分析师参与验证他们的结论或在分析过程中提出的问题，这将变得更加容易。

图 6-25。比较总收入和分解树的分支

可以与业务用户共享带有分解树的 Power BI 报告，以便他们可以自行浏览数据。要向组织中的其他用户共享报告，您需要 Power BI 服务器或 Power BI Pro 许可证。

要了解更多关于分解工具的信息，请查看“在 Power BI 中创建和查看分解树可视化”的 Microsoft 文档。

总结

在本章中，我们探讨了 Power BI 中两个强大的 AI 支持功能，帮助商业用户和分析师们通过自动化数据分析过程中的某些部分，减少他们获得见解所需的时间。关键影响因素工具可以用来揭示给定感兴趣指标的主要驱动因素，并识别相关的分段。结合 AI 分割的分解树非常有助于在任何数据维度上进行有针对性的深入钻取，同时保持整体业务指标不变。这使得它成为一种优秀的工具，用于临时数据探索和自助式根本原因分析。

在下一章中，我们将离开过去和现在数据的领域，探讨 AI 如何帮助我们预测未来事件或更好地预测未来结果。我们将从自动化分类任务开始，这有助于我们根据过去的经验对未来的商业事件进行分类。

第七章：AI 驱动的预测性分析

做好起飞的准备！我们正在进入 AI 驱动的预测性分析领域。我们将通过扮演美国航空公司的 BI 分析师的角色来实现这一点。在本章中，我们将从真实数据集中探讨三个使用案例。首先，我们将尝试将航班分类为准时或不准时。其次，我们希望通过预测实际飞行时间与计划飞行持续时间的对比来检测我们航班时间表中的瓶颈。最后，我们将使用自动异常检测分析机场跟得上飞行时间表的能力。

我们的目标是构建一个 AI 驱动的 BI 解决方案的原型，证明它能够根据使用案例解决特定问题。我们希望评估 AI 模型在我们的数据中的表现，展示出来，并通过展示业务价值（快速构建，快速展示，快速学习）来获得组织内对新方法的支持，正如第四章中所述。为此，我们将首先摆脱设置数据管道、处理 ETL 作业以及将 AI 服务集成到企业数据仓库等事务。但请放心，所有这些事情都是可能的，正如你将在第十一章中学到的那样。

在原型和生产阶段最有可能相同的是我们将构建的 AI 模型。在我们的原型中，我们将使用来自 Microsoft Azure 的企业级 AI 服务，这些服务将应对生产工作负载。稍后唯一会改变的是我们将这些服务集成到我们的整体系统架构的方式。一旦我们能够证明业务价值并为我们的解决方案建立一个坚实的业务案例，我们就能够承担将原型移入生产并在那里“正确”构建的工作。

先决条件

要跟随本章中的使用案例，建议您从书籍网站下载以下文件：

数据集

• AA_Flights_2021.xlsx

• AA_Flights_2021_01.csv

用例：自动化分类任务

• Arrival_Delay.pbix

• AA_Hourly_Batches_2021-02-07_0800-0859.csv

• azure-ml-inference-arrdel15.R或

  azure-ml-inference-arrdel15.py

用例：改进 KPI 预测

• Elapsed_Time.pbix

• azure-ml-inference-elapsedtime.R或

  azure-ml-inference-elapsedtime.py

用例：自动化异常检测

• Airports_Anomaly.pbix

• azure-anomaly-detection-airports.R或

  azure-anomaly-detection-airports.py

另外，您将需要一个 Microsoft Azure 账户来训练和托管 AI 模型，如第四章中所示，一些基本的 Python 或 R 知识来从模型获取预测，并且需要一个能够执行 Python 或 R 脚本并将模型预测集成到您的仪表板中的 BI 工具。

尽管我们使用 Microsoft Azure 来训练模型，但类似的功能也大致可在其他云平台提供商（如 GCP 或 AWS）上使用。一旦您对 Azure 的工作方式有所了解，就可以相对轻松快速地在其他平台上运行和运行。

为了构建我们的仪表板，我们将使用 Power BI 以保持与先前使用案例的一致性（以及 Azure 与 Power BI 的良好兼容性）。然而，本书并不局限于 Power BI 用户。因此，我将向您展示如何通过使用像 Python 或 R 这样的流行编程语言，从您的模型中获取推断。您可以将 Python 或 R 代码集成到 Power BI 或任何其他 BI 工具中。或者，您可以直接在数据库上运行预测（批量预测），并在 Tableau 或 Looker 等任何 BI 工具中显示结果。第十章提供了更多详细信息。

关于数据集

注意：我们将处理一个真实世界的数据集。此数据集未经过调整或调优用于 ML 练习。因此，请不要期望有令人瞠目结舌的洞察力或漂亮的图表。但是，您将了解到真实场景是什么样子的，从 ML 中可以获得哪些收益，以及如何使用这项技术来击败自己的基线并自动化预测。这个过程可能会有些混乱，但它比您在任何学术练习中找到的更接近现实生活。

此使用案例的公共数据集已通过美国运输统计局的 TranStats 服务获得。此数据源保持了有关美国航班详细信息的更新信息。在整个章节中，我们将使用 2021 年 1 月和 2021 年 2 月的航班数据，我已将其作为 Excel 文件通过书籍的网站提供给您以便查阅。该文件包括以下处理步骤以使其匹配我们的案例研究：

• 该数据集已经仅针对美国航空公司的航班进行了筛选。

• 已从数据集中删除了取消的航班。

• 已删除没有任何到达延误信息的航班（< 1%）。

如果您想获取更多数据或探索不同的航空公司，请随时从 TranStats 网站下载原始文件。如果您这样做，请确保在下载数据之前选择 Prezipped File 选项，如图 7-1 所示。

图 7-1. 航空公司准点表现数据集下载

使用案例：自动化分类任务

对于我们的第一个使用案例，我们正在处理一个分类问题，预测给定航班是否会延误到达。即使您不是航空业的专家，您也应该熟悉整体挑战。

问题陈述

作为美国航空公司商业智能团队的一员，您被要求构建一个关键业务指标的报告仪表板。该指标是目前在空中并预计延误超过 15 分钟的美国航空公司航班的百分比。这一指标对于质量控制和保持客户满意度以及保持总体航班时间表的重要性不言而喻。

在我们的示例中，假设我们每小时收到一次数据，其中包含过去 60 分钟内起飞的所有航班。这些每小时批次包含航班详情（起点、目的地、航班号等）以及起飞时的航班延误信息。因此，例如，当我们在上午 9:00 到 9:59 之间查看数据批次时，此数据集中将包含在上午 8:00 到 8:59 之间起飞的航班信息。为了简化这个例子，我们暂时忽略时区，假设所有时间戳都以协调世界时（UTC）提供。

延误航班比例这一指标目前通过一个商业智能仪表板报告，如图 7-2 所示。

图 7-2. 关于延误航班比例的报告仪表板

仪表板显示当前批次计划在给定日的 8:00 a.m. 到 8:59 a.m. 起飞时间段内的航班总数为 107 架。大多数这些航班在下一个数据批次到来之前仍将在空中。

为了估算是否会发生到达延误，我们目前使用起飞延误信息作为一个近似。到目前为止，商业智能团队一直使用变量 DepDel15，该变量指示航班是否在起飞时延误至少 15 分钟，来近似航班是否在到达时也会晚于 15 分钟。

此估算是一个很好的初步尝试，但还远非完美。让我们打开 Excel 工作簿 AA_Flights_2021.xlsx 并选择第一个表 AA_Flights_01，如图 7-3 所示，以了解此估算的历史表现。

图 7-3. 2021 年 1 月的美国航空公司航班数据

表 AA_Flights_01 包含了 2021 年 1 月的所有美国航空公司航班数据，几乎有 38,000 行数据。每一行都是 2021 年 1 月期间发生的一次美国航空公司航班。

由于这是一个历史数据集，我们可以看到实际发生的到达延误情况。例如，我们来看第一行。从约翰·肯尼迪国际机场（JFK）到洛杉矶国际机场（LAX）的 AA1 航班起飞于 2021 年 1 月 1 日。该航班没有 15 分钟或更长时间的延误，因此 DepDelay15 列设置为 0。由于飞机甚至提前降落而没有任何延误，ArrDelay15 列也设置为 0。第一个出发延误超过 15 分钟的航班发生在第 21 行：再次是从 JFK 到 LAX 的 AA1 航班，但这次是在 2021 年 1 月 20 日。DepDelay15 属性为 1，因为出发延误为 75 分钟，正如您可以在图 7-4 中看到的那样。

图 7-4. 出发延误 75 分钟的航班

所以在这种情况下，DepDelay15 属性是一个很好的指标，用于判断航班是否实际上也延误到达。现在，如果我们只依赖于 DepDelay15 信息，我们的预测会有多好呢？转到 Excel 文件的第三个工作表 Confusion_Table，看看混淆矩阵（图 7-5）。

图 7-5. 评估基线分类器

在我们深入细节之前，看看最后两行，即 ArrDel15 True = 10.4%和 False = 89.6%。这一摘要告诉我们，我们正在处理一个不平衡分类问题，正如之前在第三章中所解释的那样。只有 10%的航班实际上标记为 ArrDelay15 属性，因此到达延误超过 15 分钟。

为什么这种不平衡对我们很重要呢？因为它影响我们的评估指标。想象一下，如果我们预测所有航班都将准时到达，延误不超过 15 分钟，这将给我们带来惊人的 90%的准确性分数。这种预测有用吗？不。这就是为什么我们必须提出更智能的评估指标。

看看图 7-5 中的混淆矩阵。这显示了我们基线预测（DepDelay15 标签）的表现。如果过去我们使用出发延误启发式，我们会误分类 2,166 个观察结果：1,178 个航班实际上延误了，尽管我们预测它们将准时到达。而 988 个航班实际上准时到达，尽管我们预测会延误。

正如你在第三章学到的，精确率是衡量分类器准确性的指标；较高的精确率表示假阳性较少。如果我们能改善这个指标，那么预测为延误的 988 航班实际上准时的情况将会减少。精确率的计算方法是将真正例（TP：2,749）除以真正例加假阳性（FP：988）的总和。

召回率衡量分类器的完整性；较高的召回率表示假阴性较少（FN：1,178 航班延误，尽管预测为准时）。召回率的计算方法是将真正例除以真正例加假阴性的总和。

为了将这两个信息压缩成一个更易于跟踪的单一指标，我们将使用F1 分数，它是精确率和召回率的调和平均值，计算方法如下：

• F1 = 2 × （精确率 × 召回率）/（精确率 + 召回率）= 2TP / （2TP + FP + FN）

正如你在图 7-6 中所看到的，我们基线分类器的 F1 分数为 0.72。

图 7-6. 基线分类器的 F1 分数

我们的目标是开发出一个新的分类器，能够超过这个 0.72 的 F1 分数基线，这样我们可以更准确地预测航班延误。

解决方案概述

为了改善对航班延误预测的准确性，我们将使用一个基于历史数据训练的 AI 分类器。图 7-7 展示了这个用例架构的概念概述。正如你所见，这个用例比之前章节的用例略为复杂。这主要是因为我们现在超越了 Power BI 的能力，并在分析层中添加了更多功能。

图 7-7. 自动分类用例架构

这个架构中我们有两个数据源。图的左下角是提供的历史航班数据，保存为 CSV 文件。而右下角是我们的 BI 系统（在这种情况下是 Power BI）每小时消费的数据批次。

在这个示例中，我们使用一个 AI 服务，它将从历史航班数据中学习模式，并使用这些信息对新的数据点（每小时航班批次）进行分类，判断这些航班是否可能会延误。

我们可以使用多种方法来解决这些分类问题。由于我们目前不希望引入稀有且昂贵的 AI/ML 专家，所以我们将使用 AutoML 来为我们训练一个 ML 模型。我将演示 Microsoft Azure 机器学习工作室作为 AutoML 平台的工作流程示例，但实际上它可以是任何平台；它们的工作原理都差不多。我们将首先在 Azure ML Studio 上构建和评估模型，然后将其部署为在线 HTTP 端点——所有这些都不需要编写一行代码！

实际的预测将直接从用户层面在 Power BI 中进行。在这里，我们将向在线 API 发送一个预测请求，以便获取新数据，并使用 Power Query 将其集成到我们的数据模型中。对于此部分，我们将依赖于一个处理 API 请求的小型 R 或 Python 脚本。一旦我们在 BI 中获得了预测结果，我们将在 Power BI 报告中呈现结果。

使用 Microsoft Azure 进行模型训练演示

访问Azure ML Studio，您已在第四章中进行了设置。由于我们想要通过 AutoML 训练一个 AI 模型，请在自动化 ML 窗格中选择立即开始，并选择“新的自动化 ML 作业”来填充空白行。

AutoML 作业是一个过程，从提供数据集到获得验证的 ML 模型结果。我们将逐步完成这个过程。

首先，您需要一些数据。在 Azure 上，数据以数据集的形式组织，这些数据集与您的工作区关联。数据集将确保您的数据格式正确，并可以被 ML 作业消费。如图 7-8 所示，选择“创建”。

图 7-8. 从本地文件创建数据集

您可以从各种来源导入数据。在这种情况下，我们将上传一个本地文件，所以请继续选择“从本地文件”，如图 7-8 所示。在图 7-9 中显示的“基本信息”表单中，为您的数据集取一个能说明问题的名称，并添加一个描述（如果需要）。在这个例子中，我将数据集命名为**aa_flights_ontime**。版本将默认为 1，并且数据集类型将是表格，因为 AutoML 当前仅支持表格数据。

图 7-9. 添加基本信息

点击“下一步”进入下一部分。您需要提供如图 7-10 所示的信息。您将选择数据存储的位置以及应从何处上传数据。选择在工作区创建期间自动设置的默认数据存储（在此示例中，我的称为workspaceblobstore）。这是您将物理上传数据文件以使其可供当前工作区使用的地方。

我们无法在此处上传 Excel 文件。Azure ML Studio 支持 CSV、TSV、Parquet 和 JSON 文件作为表格数据集。这就是为什么我们需要先将 Excel 文件转换为 CSV。为了您的方便，我已经完成了这一步，并创建了名为AA_Flights_2021_01.csv的文件，其中包含了 2021 年 1 月的所有航班数据，并且是 Excel 工作簿AA_Flights_2021.xlsx的第一个工作表。在屏幕底部点击“下一步”上传文件。

图 7-10. 选择要上传的文件

文件成功上传后，您应该看到“设置和预览”表单，其中包含一些基于上传文件预填的信息。请仔细检查设置是否与图 7-11 中显示的设置相同，并确保底部的数据预览正确显示前几行。如果一切正常，请点击“下一步”。

图 7-11. 设置和预览

接下来的表单（图 7-12）将定义数据集的模式。该模式对两个原因至关重要。首先，模式将允许您定义哪些列应由 AutoML 算法考虑。其次，模式将允许您定义各列的数据类型。

这一步骤非常重要，因为您想要使用的列以及它们的数据类型对于 Azure ML Studio 来说非常难以自动猜测。例如，列 DayOfWeek 看起来是数字，但实际上是分类数据：工作日 7 + 1 不是工作日 8，而是工作日 1. 因此，DayOfWeek 列应被解释为包含字符串值而不是数值。

图 7-12. 定义模式

数据类型还定义了数据的 AutoML 任务可能性。例如，如果我们将 ArrDel15 变量的数据类型留在 Decimal 上，我们将无法在后续选择分类任务。同样地，如果我们要预测数值，我们必须确保在模式中正确设置它以启用回归任务。AutoML 无法可靠地猜测数据类型，这是我们必须手动定义的内容，提前提供这些信息需要您的专业知识。

在我们的示例中，我们不需要数据集中提供的所有数据。某些值根本不提供有意义的见解，并且只会增加项目的复杂性（例如，Year 具有完全相同的值）。我们不希望在我们的预测中包含一些其他值，因为它在 ML 的上下文中包含目标泄漏，这意味着一个特征本身包含了实际目标。例如，ArrivalDelay 确实可以完美地告诉我们 ArrDel15 是否为真。

这里是我们用例所需的所有列的列表。确保仅包括这些变量，并正确设置它们的数据类型，如图 7-12 所示：

• DayofWeek：String

• Origin：String

• Dest：String

• DepDelay：Dec/Comma

• DepDelayMinutes：Dec/Comma

• DepDel15：String

• DepartureDelayGroups：String

• DepTimeBlk：String

• TaxiOut：Dec/Comma

• ArrDel15：String

• ArrTimeBlk：String

• Distance：Dec/Comma

• DistanceGroup：String

点击“下一步”。在“确认详细信息”页面上，仔细检查您提供的信息，然后点击“创建”完成数据集的创建。您可以从显示的列表中选择您的数据集（如果需要，点击刷新）。

通过点击“下一步”进行处理。您将看到“配置作业”屏幕，如图 7-13 所示，该屏幕允许您指定您的 AutoML 作业应该如何工作。

Figure 7-13. 创建一个新的 AutoML 作业

什么是 AutoML 作业？

现在我们已经定义了我们的数据集，我们必须定义哪些计算资源应该用于 AutoML 训练。在 Azure 中，一个特定数据集上的 AutoML 训练称为 AutoML 作业。作业组织在实验中。一个 实验 包含信息，如您的计算环境的大小，并指定您想要预测的列。

由于我们还没有设置实验，请选择“创建新”单选按钮。输入一个自定义实验名称。在这种情况下，我选择了**aa-automl-arrdel15**。将 ArrDel15（String）指定为目标列。最后，我们必须指定用于此训练作业的计算资源。选择“计算实例”作为计算类型，然后选择我们最初在第四章中创建的计算资源。如果计算实例已停止，您需要首先启动它。为此，请从 Azure 机器学习工作室主菜单中选择计算，从列表中选择您的实例，然后单击“启动”。提示：在新标签页中打开计算实例菜单，以免中断 AutoML 作业的设置过程。

注意

在使用 Azure 机器学习时，并没有额外费用，但是你会为底层的 Azure 服务（如 Azure 计算能力或 Azure Blob 存储）付费。虽然更大的计算能力可以提高 AutoML 的速度（从而降低 AutoML 作业的成本），但通常选择更便宜的计算资源并接受稍长的 AutoML 训练时间更加成本效益。在这种使用情况下，即使你多次进行 AutoML 训练，也应该完全由你的免费试用预算覆盖。要了解有关管理 Azure 机器学习的预算、成本和配额的更多信息，我建议参考微软资源“管理 Azure 机器学习的组织规模预算、成本和配额”。

现在是指定 AutoML 任务应该执行什么操作的时候了（参见图 7-14）。

图 7-14. 选择机器学习任务

我们可以在这里选择三种任务类型：

分类

预测分类变量

回归

预测连续数值变量

时间序列预测

针对时间序列数据的回归

在选择“下一步”之前，请单击“查看附加配置设置”。您将看到“附加配置”窗格（参见图 7-15）。

图 7-15. 机器学习任务的附加配置

我们想要在这里自定义一些选项。首先，我们要更改“主要指标”。默认情况下，这设置为准确度。正如您之前所见，准确度并不适合不平衡分类问题的衡量。我们无法在这里选择“F1 分数”。而是选择“加权精度分数”。这也将考虑召回率，因此会产生更好的 F1 分数。此外，请确保选中“解释最佳模型”。

注意

在 AutoML 过程中选择正确的评估指标是至关重要的一步，可以显著影响结果。与此同时，对于 AutoML 服务来说，很难猜测您需要哪种指标，因为这取决于手头的问题。例如，在临床测试中，您更看重假阳性还是假阴性结果？请随时返回第三章，更加熟悉各种指标，根据需要在多个 AutoML 作业中进行实验。访问 “评估自动化机器学习实验结果” 在 Azure ML Studio 中根据不同的指标比较您的 AutoML 作业。

我们想要自定义的另一个设置是“退出标准”。这将告诉我们的 AutoML 算法模型何时“足够好”。如果满足某一标准，则训练作业将停止。通常，您可以采用两种方法。您可以通过时间限制或者通过指标的最小接受标准来结束训练。在这个例子中，选择 1 小时作为最大时间限制。实际上，如果算法无法在训练中获得更大的增益，训练可能会提前结束。

确认附加设置并保存。单击“下一步”和“完成”以启动您的 AutoML 作业。这将初始化您的 AutoML 作业，并将您带到“运行详细信息”屏幕（参见图 7-16）。

图 7-16. AutoML 作业详细信息

随着实验的进行，此状态会更新。几分钟后，状态应从“未开始”变为“运行”。

第一个模型开始训练可能需要大约 10 分钟左右。Azure 首先进行一些内部设置和检查。其中一个准备工作是名为“数据守则”的服务。点击“数据守则”选项卡以获取更多信息。几分钟后，屏幕应该看起来像图 7-17。如果此区域仍然为空，请稍后再检查并刷新页面。

图 7-17. 数据守则

在 Azure AutoML 中，数据守则 是一系列自动检查，用于增加高质量训练结果的可能性。这些检查包括自动将数据拆分为训练集和验证集，或检查训练列中是否存在缺失值。Azure AutoML 还会检查与当前训练任务相关的一些假设，例如识别标签中的不平衡类，并标记它们作为潜在问题区域。如果你点击“查看附加详细信息”按钮，你将看到类标签的基础分布。

要了解如何解决这个问题，请阅读 Azure 文档 “识别具有不平衡数据的模型”。除了一些内置功能帮助解决不平衡类的问题，例如添加权重列，建议的一个主要点是选择一个针对类不平衡具有鲁棒性的评估指标。我们之前选择精度而不是准确度作为我们的主要评估指标，这是个好主意。

尽管整个训练过程仍在进行中，但请前往“模型”选项卡。在这里，你将看到所有模型的列表以及自动机器学习算法到目前为止提出的初步评估指标。15 到 20 分钟后，你应该已经看到一个带有相应评估指标的初步模型。请记住，模型从这里只会变得更好。如果自动机器学习算法找到了更好的模型，它将出现在列表的顶部。你可以在这里探索每个模型并进一步查看各自的详细信息。但是自动机器学习的理念是，在训练过程中我们不必过于担心发生了什么。让算法自行处理，喝杯咖啡，大约 30 分钟后再回来查看。

训练完成了吗？如果完成了，你应该看到一个类似于图 7-18 的屏幕，状态显示为已完成。

图 7-18. 已完成的 AutoML 作业

评估 AutoML 输出

现在是时候查看算法找到的最佳模型，并稍微详细地探索一下。点击“模型”选项卡进入模型页面。你应该看到一个类似于图 7-19 的列表。从这个概览中，我们可以看到前五名模型非常接近，最佳模型的精度分数在 0.96340 到 0.96690 之间。

在这种情况下，最佳模型是一个投票集成模型，最终精度得分为 0.96690。实际结果取决于计算资源和所花费的训练时间。如果选择了不同的运行配置，结果可能会有所不同。

图 7-19. AutoML 模型

注意

您的 AutoML 作业的实际结果可能会略有不同于本书中的结果。虽然 AutoML 过程是确定性的，但由于数据准备过程中的随机过程（例如，用于训练和测试的自动化数据抽样），您可能会看到不同的结果。然而，总体趋势应该是相似的。

由于我们之前在高级配置中勾选了“解释最佳模型”，最佳模型自动显示了“查看解释”链接。稍后我们会回到这一点。但首先，点击算法名称“VotingEnsemble”以查看模型的详细页面（图 7-20）。

图 7-20. 最佳模型详情

最重要的是，我们要了解这个模型在我们的数据上的表现如何。要了解更多信息，请单击“指标”选项卡。在此部分，启用以下评估指标，并暂时保持所有其他指标禁用状态：

• average_precision_score_macro

• average_precision_score_micro

• average_precision_score_weighted

• confusion_matrix

• f1_score_macro

• f1_score_micro

• f1_score_weighted

您的屏幕应该看起来与图 7-21 中的屏幕类似。

图 7-21. 模型指标

在我们深入研究微观、宏观和平均指标意味着什么之前，让我们先看一下模型评估为我们提供的混淆矩阵。这个混淆表格包含的信息与我们问题陈述中的 Excel 表格（图 7-5）完全相同，只是布局有些不同。

这个表格对比了真实数据标签与模型预测标签。例如，对于 3,374 个观测值，实际标签为0（到达延误超过 15 分钟），而模型预测值也为0。相比之下，有 98 个观测被预测准时到达（预测标签=0），但实际上延误超过 15 分钟（实际标签=1）。请注意，此表格未包含数据集中的所有观测，而仅包括验证集中的样本数据点。

为了使此屏幕与我们问题集中的 Excel 电子表格更可比较，将左上角的下拉菜单从原始切换到归一化，以显示相应的百分比（图 7-22）。这样可以更轻松地将结果与我们来自图 7-5 的 Excel 表格进行比较。

图 7-22. 在 Azure 中的归一化混淆矩阵与 Excel 混淆矩阵的对比

让我们来比较该模型与我们的基线模型，后者仅基于飞机起飞后是否延误超过 15 分钟来进行预测。如您所见，我们的模型在预测将延误的航班（1）实际上按时抵达的情况下，相较于基线模型取得了显著的进展。AI 模型仅在这些观测中误分类了 0.71%，而我们的基线在该类别中的误差为 2.9%。同样地，对于预测将按时抵达的航班（0），实际上抵达延误超过 15 分钟的情况，我们将基线模型的误差从 30.0% 降低到了 24.94%。

让我们看看这对于我们的接受标准，精确率、召回率和 F1-score 意味着什么。基线模型的指标如下：

• 精确率：0.74

• 召回率：0.70

• F1-score: 0.72

我们可以手动计算我们的 AI 模型相同的指标：

• 精确率 = TP / (TP + FP) = 295 / (295 + 24) = 0.92

• 召回率 = TP / (TP + FN) = 295 / (295 + 98) = 0.75

• F1-score: 2TP / (2TP + FP + FN) = 2 × 295 / (2 × 295 + 24 + 98) = 0.83

如您所见，由于 AutoML 方法的采用，我们成功地将基线预测提高了 11 个百分点。

让我们回到模型指标选项卡中的精确率和 F1-score 指标。为什么我们在这里看到的值要高得多？那是因为我们为我们的分类算法提供了微观、宏观和加权得分：

微观

计算全局指标，通过计算总的真正例、假负例和假正例来实现。

宏观

对每个标签计算指标并找到它们的非加权平均值。这不考虑标签的不平衡性。

加权

计算每个标签的指标并根据它们的支持度（每个标签的真实实例数）进行加权平均。

对于不平衡的分类问题，使用宏观平均值更具信息量，其中少数类与多数类具有相同的权重。

对于二分类问题，宏观 F1-score 简单地是正类和负类的 F1-score 的平均值：

• 宏观 F1-score = (正类的 F1-score + 负类的 F1-score) / 2 = (0.83 × 0.98) / 2 = 0.905

如您所见，这正是 Azure 中宏观 F1-score 评估指标在 图 7-23 中展示的内容。

图 7-23. F1-score 宏观比较

在比较这些聚合评估指标时要小心。从粒度层面来看（例如，混淆矩阵），可以更好地理解整体情况。

注意

有时候，最好的模型并不适合您的目的。 特别是当评估指标接近时，您可能希望检查前三个模型，并探索详细信息，例如我们之前做过的混淆矩阵。 根据您的偏好，如果更适合解决手头的问题，使用第二或第三优秀的模型可能是有意义的。 也许您会发现一个模型在牺牲一些精度的情况下提供了更好的召回率？

现在我们已经确认我们的模型比非 AI 基线效果更好，让我们明白为什么会这样。 前往我们最佳模型的解释选项卡。 从 Figure 7-24 表格中选择“原始数据”，然后通过点击双箭头来收缩列表窗格。

Figure 7-24. 模型解释

接下来，点击“聚合特征重要性”选项卡。 这应该会显示与 Figure 7-25 类似的屏幕。

此视觉简要显示了影响特定预测结果的最重要的变量（特征）。 正如我们从图表中看到的那样，DepDelay（出发延误）属性显然是远远最重要的影响因素。

但有趣的是，还有三个变量对预测有显著影响。 第一个是 TaxiOut 属性，其重要性几乎与 DepDelay 相当。 这并不奇怪，因为出租车等待时间与出发延误密切相关。 但令人惊讶的是，我们还看到目的地（Dest）和起飞地（Origin）在预测到达延误时起了作用。 根据飞机起飞和计划到达的机场位置，及时到达的概率会增加或减少。 这些特征并不像出发延误和出租车等待时间那样重要，但确实在提高预测精度方面发挥了作用。

Figure 7-25. 聚合特征重要性

在我们的数据集中，有四百多个唯一的出发和到达机场组合，这是 AutoML 可以发挥其优势的领域，因为对于这些组合，手工制定规则会很麻烦，仅仅为了通过一定的百分比提高我们的预测质量。 现在我们已经大致了解为什么 AutoML 模型比我们的基线效果更好，让我们继续前进，为新的、未见过的数据集部署我们的模型。

使用 Microsoft Azure 进行模型部署的实例

现在我们已经训练、验证并理解了我们的 ML 模型，是时候部署它了，这样我们就可以用它来预测新数据。 在 Azure ML Studio 中，选择您想要提供的模型，然后点击“部署 → 部署到 Web 服务”。 “部署模型”面板将在右侧弹出（参见 Figure 7-26）。

Figure 7-26. 模型部署

为您的模型部署命名。我建议使用模型目的（预测变量）和您正在使用的算法的组合。在我们的情况下，一个好的模型名称可能是**arrdel-votingensemble**。接下来，选择计算类型。在这里，您可以选择 Azure Kubernetes 服务和 Azure 容器实例。这两种资源通常用于实时推断。Kubernetes 服务通常用于需要快速响应时间和自动缩放的大规模生产部署，这与我们的原型要求完全相反。我们满意 Azure 容器服务，用于小型基于 CPU 的工作负载，需要少于 48 GB 的 RAM。确保目前已禁用身份验证，然后点击“部署”。

点击部署后，您应该会看到一个通知，告诉您部署正在进行中（图 7-27）。

图 7-27. 模型部署中

几分钟后，您应该会看到另一个通知，告诉您部署已完成。从左侧的主菜单中，点击“端点”，然后选择您部署的模型。您应该会看到类似于图 7-28 的屏幕。您的模型部署状态应为正常，并且您应该看到一个 REST 端点 URL。这是整个页面中最重要的参数之一。我们稍后将使用 REST 端点进行预测（推理）。

图 7-28. 部署的模型端点

恭喜，您的第一个机器学习模型现在已经准备好使用了！但在将此模型集成到我们的 BI 报告之前，让我们通过使用 Azure ML Studio 中的内置测试功能快速测试它。

在部署模型的选项菜单中，选择“测试”。在这里，您可以快速获取一些样本数据点的在线预测结果。您可以使用提供的表单手动输入这些值，或者您可以切换小的 CSV 图标以粘贴表格数据，如图 7-29 所示。

图 7-29. 使用实时端点测试模型

在您选择的纯文本编辑器中打开AA_Hourly_Batches_2021-02-07_0800-0859.csv文件（请勿在 Excel 中打开！）。此文件包含一个小时航班数据的一个批次，我们希望用它来预测预期到达延迟。在文本编辑器中，选择所有内容，然后复制并粘贴到测试页面的文本区域中。点击“测试”按钮，您应该立即在右侧看到结果（图 7-30）。

图 7-30. 测试模型预测

现在我们的模型已经启动运行，我们将使用 R 或 Python 开始在我们的 BI 仪表板内获取推断。要从我们的 BI 报告中调用在线预测，我们需要运行一个小脚本，该脚本从（在我们的情况下）Power BI 获取数据，将其发送到 HTTP API，检索结果，并将其反馈到报告中。

警告

我们现在离开 Azure ML Studio，并且只会在下一个用例中回到它。为了避免费用，我建议您通过选择 Azure Machine Learning Studio → 计算 → 停止来停止用于 Auto ML 训练的计算资源。

使用 Python 或 R 获取模型预测

根据您喜欢的编程语言，您可以继续使用 Python 或 R 来完成本节。我用 R 演示了示例，但同样的步骤也适用于 Python。

访问 Azure ML Studio。选择“端点”并选择您要用于请求推断的模型。在接下来的屏幕上，选择“消耗”，然后从选项卡菜单中选择 R（或 Python）。您将在这里看到两个重要的事项，如图 7-31 所示：您需要使用的公共 REST 端点 URL 以及提交请求的预写脚本。

图 7-31. 用于模型推断的 R 脚本

如果您只想处理单个观察请求，则预写脚本已经足够好了。如果要处理包含多个数据点的整个表格，则需要以一种使多条记录发送到 API 的方式重写脚本，而不仅仅是一条记录。

在书籍的网站上，您可以找到两个文件，azure-ml-inference-arrdel15.R和azure-ml-inference-arrdel15.py。这两个脚本共享相同的结构、部分、变量名称和代码逻辑。我将为您演示 R 中的代码示例，但同样适用于 Python 版本。

让我们逐步查看脚本azure-ml-inference-arrdel15.R。脚本的第零部分进行了一些设置和日常维护。首先，脚本加载了所有必需的包。在 R 的情况下，这些包括以下内容：

• httr（用于发出 HTTP 请求）

• rjson（用于处理 API 响应）

• dplyr（用于数据准备）

确保您已安装了用于 Power BI 使用的 R 引擎，如第四章中描述的那样。

接下来，您需要自定义两个变量。对于变量API_URL，请使用 Azure 门户中“消耗”选项卡中的 REST 端点 URL 替换虚拟 URL。

变量API_KEY为空，因为我们在不进行身份验证的情况下部署了我们的模型。如果启用身份验证，您需要在此处包括您的身份验证密钥：

# SECTION 0: Setup and Variables ----
# Make sure these packages are installed
library("httr")
library("rjson")
library("dplyr")

API_KEY = ""
API_URL = "http://*xxxxxxxxxxxxxxxxxxx*.eastus2.azurecontainer.io/score"

警告

虽然我们在这里将我们的 Azure 凭证以明文形式存储在代码中，但请注意，这通常不是良好的编程实践。我们之所以这样做是为了简化事务。如果您想了解有关处理身份验证机制的最佳实践，请查阅微软资源 “关于 Azure 密钥保管库”。

代码的第一部分包含了实际 API 请求的函数，类似于 Azure 中的示例脚本。主要区别在于，您可以将整套记录传递给此函数，而不仅仅是单个观察结果，这极大地加快了整个处理过程。

从代码中可以看出，列名称具有静态引用。因此，如果您已对数据集进行了更改或选择了不同的列进行预测，您也需要在脚本中更新它们：

# SECTION 1: API Request Function ----
inference_request <- function(DayOfWeek, 
                              Origin, 
                              Dest, 
                              DepDelay, 
                              DepDelayMinutes, 
                              DepDel15, 
                              DepartureDelayGroups,
                              DepTimeBlk, 
                              TaxiOut, 
                              ArrTimeBlk, 
                              Distance, 
                              DistanceGroup) {

  # Bind columns to dataframe
  request_df <- data.frame(DayOfWeek, 
                           Origin, 
                           Dest, 
                           DepDelay, 
                           DepDelayMinutes, 
                           DepDel15, 
                           DepartureDelayGroups, 
                           DepTimeBlk, 
                           TaxiOut, 
                           ArrTimeBlk, 
                           Distance, 
                           DistanceGroup)

  req = list(
    Inputs = list(
      "data"=apply(request_df,1,as.list)
    ),
    GlobalParameters = list(
      'method' = "predict"
    )
  )
… (Truncated for brevity)

第二部分包含了这种情况下的数据处理部分。此脚本稍后将嵌入到 Power Query 工作流中，Power Query 将前一步骤的数据作为名为 dataset 的表传递给脚本。正如您从脚本中看到的那样，我们将此源数据分配给一个新变量 df，以保持组织结构，并将处理后的数据与原始数据分开：

# SECTION 2: Data preprocessing ----
# Fetch data from Power Query workflow
df <- dataset

第三部分从给定数据集中提取了我们预测所需的相关列，并实际调用了 API，这是我们托管的模型：

# SECTION 3: Get Predictions ----
result <- inference_request(df$DayOfWeek, 
                            df$Origin, 
                            df$Dest, 
                            df$DepDelay, 
                            …)
							(Truncated for brevity)

第四部分从 API 中获取结果，并将其格式化为可以添加到我们的原始数据集作为名为 ArrDel15_Prediction 的新列的形式：

# SECTION 4: Data postprocessing ----
result <- unlist(content(result))
df$ArrDel15_Prediction <- result

最后，第五部分以 Power BI 可以继续处理的形式提供输出：

# SECTION 5: Format output for Power BI ----
output <- df

注意

我们的数据集仅包含略多于 100 个观察结果。如果您需要的预测量比这多得多（10,000+ 行），请考虑限制每个 API 调用的数据点数量，或选择批量预测而不是在线预测。您将在 第十章 中了解更多关于批量预测的信息。

使用 Power BI 演示模型推理

现在您知道如何以编程方式从模型中获取预测结果，终于可以在 Power BI 中将您的知识付诸实践了。请注意，尽管我们在这里使用的是 Power BI，但您可以使用任何能够处理 R 或 Python 代码的 BI 工具。

我们的目标是增强对我们在问题说明中看到的仪表板的到达延迟预测（如 图 7-2 所示）。回顾一下：仪表板每小时读取一批航班数据，并显示到达时延迟航班的预期比例。现在，我们将获取这些数据，发送到我们托管的模型中，获取预测结果，并显示聚合分数以供进一步使用和改进决策。

要在 Power BI 中进行操作，请打开 Arrival_Delay.pbix 文件。您应该看到 图 7-32 中显示的仪表板。

图 7-32. Power BI 按时到达报告

要添加我们的 AI 预测，我们必须应用一些数据转换。点击工具栏中的“转换数据”图标以启动 Power Query，如图 7-33 所示。

图 7-33. 数据转换图标

这将打开 Power Query 编辑器。该工具允许您操作数据，应用计算，执行转换，并执行 Python 和 R 脚本！

从工具栏中选择“转换”选项卡，然后根据您的偏好选择“运行 R 脚本”或“运行 Python 脚本”（参见图 7-34）。在本教程中，我将继续使用 R 的示例。

图 7-34. Power Query 编辑器

在代码编辑器中，粘贴来自脚本文件（azure-ml-inference-arrdel15.R）的代码，如图 7-35 所示。请确保已将代码段 0 中的终端 URL 替换为您模型的 URL。

图 7-35. 在 Power Query 中运行 R/Python 脚本

点击“确定”，Power BI 将评估脚本。如果您收到有关数据隐私的警告，请选择“忽略此文件的隐私级别检查”。脚本的执行时间会根据发送到 API 终端的行数而有所不同。请记住，我们仍处于原型阶段。在生产环境中，您将在数据库级别应用这些 AI 预测，并且只需从 Power BI 或报告系统中使用它们。详细信息请参阅第十一章。

脚本执行完成后，在 Power Query 中您应该会看到一个提示，其中包含两个表格。选择“输出”表。如果您向右滚动，您将注意到编辑器中的两件事。首先，在右侧的“应用步骤”窗格下添加了另一个步骤。其次，您将看到一个新的列，“ArrDel15_Prediction”，如果您滚动到右侧的话（参见图 7-36）。请务必检查此列的数据类型是否被识别为数字。如果没有，请右键单击列，然后选择“更改类型”→“整数”。

图 7-36. Power Query 中的预测列

在 Power Query 编辑器中，选择“主页”，然后选择“关闭并应用”。您的数据模型正在更新，并添加了新的附加信息。您可以在更新的模型中看到新的列。每当您希望更新数据或预测时，您需要刷新数据模型，如图 7-37 所示。这将重新加载来自文件或外部源的数据，并重新运行 Power Query 编辑器中的步骤。

图 7-37. 刷新数据

在 Power BI 中构建 AI 强化的仪表板

现在我们已经准备好用新信息填充我们的仪表板了。返回报告，选择 Card 视觉，使用延误航班比例的 Proportion of Delayed Flights。从字段窗格中拖放新的维度 ArrDel15_Prediction 到卡片视觉的值字段，替换旧的度量 DepDel15。右键单击更新后的字段，选择平均值。设置窗格现在应该看起来像 Figure 7-38，度量应该更新为 0.1495。

Figure 7-38. 带有 AI 预测的更新仪表板

继续使用新的 ArrDel15_Predicted 维度替换仪表板中其余视觉的 DepDel15 字段。这包括 Card 视觉上预期到达延迟的过滤值以及航班表上的过滤器。

或者，您可以打开文件Arrival_Delay_AI-Powered.pbix，并从那里跟随。您的最终仪表板应该像 Figure 7-39 那样。

Figure 7-39. 带有在线航班延误预测的最终 AI 驱动仪表板

仅从延误航班的计数来看，我们可能直觉地认为我们的基线和 AI 模型的预测并没有太大差异。但不要陷入这个陷阱！仅仅因为 AI 预测总体上会有更多的延误航班，实际上预计会延误的航班是完全不同的。看一下航班表格。在 AI 驱动的仪表板上，我们可以看到标记的航班，并没有 15 分钟的出发延误。例如从 IAH 到 DFW 的 AA2378 航班，从 OKC 到 DFW 的 AA2776 航班，以及从 AUS 到 DFW 的 AA2828 航班，甚至提前起飞。

正如我们从 Figure 7-40 所示的真实数据集中所知，我们可以确认 AA2378 航班和 AA2828 航班确实延误了超过 15 分钟。尽管 AA2776 航班没有到达延误 15 标志，但飞机降落晚了 12 分钟，尽管起飞时间领先 10 分钟。从技术上讲，这里 AI 的预测是错误的，但这绝对是一个不错的猜测。

Figure 7-40. AA2378 和 AA2776 航班在 7/2/21 的实际延误情况

希望您喜欢制作这个仪表板，并了解 AI 如何帮助您对数据集进行更好的预测。跟踪一个基线，并查看 AI 可能如何超越它。

使用案例：改进 KPI 预测

对于这个用例，我们将继续之前的情景。我们是美国航空的商业智能团队。这一次，我们不想改善我们的实时报告，而是提前进行规划。

为此，我们需要处理经过时间指标，该指标衡量了给定航班实际起飞时间与实际到达时间之间的差异。经过时间计划得很早，称为计算机预订系统（CRS）经过时间。与之前的用例不同，这不是一个分类变量，而是一个连续的数值变量。

欢迎来到回归问题的世界！让我们通过以下问题陈述进一步了解问题。

问题陈述

我们希望识别下个月航班时间表中的瓶颈，并标记那些可能延误的航班，即实际经过时间高于计划经过时间。BI 团队已建立一个仪表板，分析历史数据并展示一个关键绩效指标（KPI），比较了 CRS（计划）经过时间与实际经过时间。您可以在图 7-41 中看到这个仪表板，或者在 Power BI 中使用文件Elapsed_Time.pbix自行打开。

图 7-41. 航班分析仪表板

从仪表板中，我们发现，平均而言，航班需要比计划的时间少 9.30 分钟。这在直觉上是有道理的，因为我们知道航班时间表被优化以最小化延误。同时，我们可以从左侧的散点图中看到，一些航班超过了计划的经过时间。散点图显示了 CRS 经过时间与实际经过时间。每个点代表一个航班。在图的上部暗区域的点需要比原定计划的时间更多。关键问题是，我们能否创建一个模型，在生成航班时间表时标记这些航班？

基于历史数据，分析师们建立了一个简单的回归模型，也显示为仪表板上的趋势线。该模型以计划的 CRS 经过时间为基础，根据历史数据计算实际经过时间的预测。分析师告诉我们，回归模型的标准误差（RMSE）为 14.30，如图 7-42 所示。如果您对这些指标的解释感到困惑，请简要回顾第三章。尽管在文件上模型看起来不错，但它实际上对于预测实际经过时间几乎没什么用处。

图 7-42. 基准回归模型

在文件Elapsed_Time.pbix的“未来时间表”报告中打开（图 7-43）CRS 预计时间与预测经过时间。从这份报告中我们可以看到，应用模型到 2021 年 2 月的航班时间表将标记 114 个航班号，其实际经过时间可能比计划经过时间多五分钟或更多。然而，通过右侧的条形图我们可以看到，计划经过时间与实际预测经过时间之间的最大差异仅微小，比计划多了 6.50 分钟。这是回归模型能够预测到的最大差异。看一下左侧的散点图，它显示了按航班号排序的平均预期延误。你可以看到所有这些航班都接近准时的阈值，这使我们难以确定可能会遇到长时间延误的航班。

图 7-43. CRS 预计经过时间与预测经过时间基准

建立的回归模型并不能灵活地捕捉由于除计划 CRS 时间以外的变量引起的经过时间的变化。但究竟是哪些影响变量呢？BI 团队进一步进行了分析，并确定了导致预定经过时间与实际经过时间差异增加的关键驱动因素。你可以在图 7-44 中找到这次分析的截图，或者在 Power BI 文件Elapsed_Time.pbix的“关键影响因素”报告页面中查看。

图 7-44. 预测飞行延误的关键影响因素分析

从分析中，我们发现多种因素导致预定时间与实际时间之间的差异。其中包括出发机场、飞行距离、计划飞行持续时间和到达时间段。因此，如果你从奥斯汀乘坐短途航班，预计在上午 9:00 至 9:59 之间降落，你可能不希望安排在抵达后不久的会议。

但作为航空公司，我们如何将这些洞见转化为可操作的信息呢？如何在不反复运行关键影响因素分析的情况下自动标识航班时间表中的关键瓶颈？我们通过解决方案概述来找出答案。

解决方案概述

为了识别航班时间表中的瓶颈，我们将在创建时间表时利用所有可用信息，并使用历史数据训练 ML 模型来预测实际经过时间。这些信息包括起始机场、目的地机场、到达和离开时间段等属性。所有这些属性在航班发生之前都是已知的，因此我们不会遇到训练-服务偏差，并且可以提前很好地响应模型输出。

图 7-45 展示了此用例的高层架构。这与我们之前在 “用例：自动化分类任务” 中所做的类似。我们将在历史数据上训练 ML 模型，并使用 Azure ML Studio 部署它，以便我们可以从 Power BI 内部获取在线端点的预测。唯一的主要区别是，这次我们不是训练分类模型，而是回归模型。同样，我们使用 Power BI 发出请求，但我们也可以使用其他 BI 工具。

图 7-45. 用例架构用于改进 KPI 预测

使用 Microsoft Azure 演练模型训练

前往 Azure ML Studio，通过导航至 ml.azure.com。从主屏幕选择创建新 → 自动化 ML 作业，如图 7-46 所示。

图 7-46. 创建新的自动化 ML 作业

选择创建数据集 → 从本地文件。您将看到有关数据集基本信息的表单（见图 7-47）。为您的数据集取一个可以与 AutoML 训练作业相关联的名称。在本示例中，我选择了 **aa-flights-elapsedtime**。继续点击下一步。

图 7-47. 从本地文件创建数据集

点击上传按钮并选择 AA_Flights_2021_01.csv 文件。一旦上传完成，屏幕底部应出现下一步按钮。

注意

尽管我们在技术上使用的是与之前用例相同的数据源，但重新将文件作为 Microsoft Azure 中的单独数据集重新上传仍然是一个好主意，以保持组织有序。我们现在使用的训练数据集与第一个用例的训练数据集具有不同的模式。例如，这次我们预测实际经过时间属性。你还可以通过添加新版本在 Azure 中更新数据集的模式，但如果你想重新训练之前的 ArrDel15 分类器，这将会很复杂。一个好的经验法则是：为每个 AutoML 任务保留单独的数据集，这意味着目标列应保持固定。使用模式更新功能和版本控制来添加或删除特征或调整输入数据的数据类型，但不要触及目标列。

继续到“设置和预览”表单。确保文件格式设置为分隔符，分隔符设置为分号，并且编码设置为 UTF-8。你应该看到数据的正确格式预览，如图 7-48 所示。

图 7-48. 数据集设置和预览

点击下一步进入模式设置。仅包括以下带有其相应数据类型的属性：

• DayOfWeek: String

• Origin: String

• Dest: String

• DepTimeBlk: String

• ArrTimeBlk: String

• CRSElapsedTime: Decimal (Comma)

• ActualElapsedTime: Decimal (Comma)

• Distance: Decimal (Comma)

• DistanceGroup: String

点击下一步，确认细节，你应该看到新数据集出现在可用数据集列表中（图 7-49）。

图 7-49. 可用数据集列表

选择新数据集并点击下一步。在接下来的屏幕上，我建议创建一个新的实验，以便将分类和回归任务的模型和结果分开保存。选择一个能够很好区分前一个实验的实验名称，例如**aa-automl-time**。选择 ActualElapsedTime (Decimal)作为目标列。对于计算资源，你可以使用之前用过的“automl”资源。继续进行下一步。

在接下来的屏幕上，AutoML 将猜测你试图解决一个回归问题，因为你指定了一个连续的数值目标变量。在我们的案例中，这是完全正确的！在完成设置过程之前，通过点击“查看附加配置设置”，打开图 7-50 中显示的高级设置。

图 7-50. AutoML 的附加配置

在附加配置中，确保“主要指标”设置为“归一化的均方根误差”。这样，我们可以与我们已有的回归模型基线相当好地比较 AutoML 模型。还要再次确认选项“解释最佳模型”已被选中。在“退出标准”下，将训练作业设置为最多 1 小时。实际上，我们可能甚至不需要那么多时间，算法大约在 30 分钟后应该会收敛。确认设置后点击保存，并通过点击完成提交 AutoML 作业。

这个运行可能需要一些时间，所以休息一下，几分钟后再回来。你可以通过选择实验 → aa-automl-time（或者你给它起的任何名字）来检查运行的状态，并检查当前运行的状态。一旦状态变为已完成，运行的详细信息应该类似于图 7-51。

图 7-51. 已完成的任务详细信息用于过去时间预测

正如你所看到的，在这种情况下，整体运行大约需要 38 分钟，并且生成了一个使用 VotingEnsemble 作为算法的模型——再次是这样！事实上，AutoML 经常会产生 VotingEnsemble 或 Stacked Ensemble 作为最终模型。这两种技术都将众多模型的结果结合起来，这些模型要么为最终结果“投票”，要么“叠加”在一起以得出最终决策（如果你想了解更多，请回顾第三章）。AutoML 算法最终生成集成模型是很常见的。

在我们的情况下，该模型实现了 0.2403 的归一化 RMSE。我们如何将其与我们简单回归模型的 RMSE 基线 14.30 进行比较？

点击 VotingEnsemble 链接，选择指标。取消除 r2-score、残差和 root_mean_squared_error 之外的所有框，如图 7-52 所示。

图 7-52. 回归评估指标

从指标来看，我们的 AutoML 回归模型的 RMSE 为 12.57。这比简单回归模型要好（因此更好），但实际上并不太多，考虑到我们投入这个问题的计算能力。但正如你从本章的前一个用例中学到的那样，我们应该对聚合质量指标持怀疑态度，并且更详细地查看结果。

回顾一下图 7-52 中的残差直方图。残差是回归模型的误差，即实际值与预测值之间的差异。对于我们的简单回归模型，预测值几乎总是低于实际值。在我们这里的 AutoML 场景中，我们可以看到残差集中在 0 值附近，有些预测值略高于实际度量值，而其他预测值则略低于实际度量值。这种变化的类型是一个好迹象，因为我们需要这种变化来识别那些有可能超出计划经过时间的航班。因此，对我们的 AutoML 模型抱有一些信心，并确认至少在理论上它比我们的回归基线更好后，前往“解释”选项卡查找影响我们预测的因素。

在“解释”选项卡中，选择原始特征的第一个列表项。然后从子菜单中选择“聚合特征重要性”选项卡。选择前 5 个特征，您应该看到一个类似于图 7-53 的屏幕。

图 7-53. 回归模型的聚合特征重要性

在这种情况下，排名前五的特征是 CRSElapsedTime（毫不奇怪，远远超过其他）以及 Distance、Dest、Origin 和 ArrTimeBlk。从逻辑角度来看，这种选择是有意义的。较大的机场比较繁忙，因此延误的可能性更高。此外，ArrTimeBlk 从关键影响因素工具中确认了我们之前观察到的内容。在特定的到达时间，特别是在早晨，机场通常比较繁忙，延误的可能性更高。

在您的情况下，实际结果可能会有所不同，因为在 AutoML 过程中涉及一些随机元素（例如，数据分为训练、测试和验证集的方式）。不幸的是，我们无法在 Azure 中固定这些随机过程的种子，因此无法 100%复现结果。然而，当您自行进行分析时，总体大局应该是相同的。

让我们花一分钟时间更好地理解我们的模型，看看发生了什么。点击“个体特征重要性”选项卡，如图 7-54 所示。在散点图中，点击 y 轴的标题，选择“预测 Y”。对于 x 轴，选择“真实 Y”。这将为所有数据点（航班）及其相应的真实和预测值提供一个概述，针对“Elapsed Time”属性。

这种可视化的绝妙之处在于，我们可以单独选择单个数据点并检查导致个别预测结果的具体特征重要性。从此图中选择三个数据点：

• 一个预测值高于实际值的点

• 一个预测值几乎与实际值匹配的点

• 一个预测值远低于实际值的点

图 7-54 展示了我所选内容的情况。

图 7-54. 个体特征重要性

为了提供更多背景信息，您也可以打开右侧的菜单窗格，以查看有关数据点更多的细节。例如，第 662 行数据点是从檀香山机场到达达拉斯-沃斯堡的航班，周六晚上起飞，早晨降落，正如您在图 7-55 中所看到的。这个点的预测时间是 454.2 分钟，实际时间是 446 分钟，预测非常准确。

图 7-55. 数据点特征重要性

同样地，我选择了一个预测值远高于实际值的点（例如第 2395 行，预测 426 分钟，实际 395 分钟），以及一个预测值偏低的点（例如第 1523 行，预测 84 分钟，实际 140 分钟）。

现在，选择了三个点后，向下滚动以查看类似于图 7-56 的图形。

图 7-56. 所选数据点的本地特征重要性

这张图展示了导致所选数据点个体预测结果的原因。例如，我们可以看到第 1523 行（中间的柱状图）预测值过低时，特征 CRSElapsedTime 实际上被模型所削弱。由于某种原因，模型决定在这种特殊情况下不应过多考虑原计划时间。事实证明，在这种情况下，这是一个错误的决定。相比之下，对于第 662 行（右侧的柱状图），预测值几乎与实际结果相同，预定起飞时间具有很高的影响因素。在这里，模型并未认为其他任何因素对可能导致延误有重要影响。

分析单个预测并理解哪些因素对它们有影响，将帮助您更加自信地应用和解释您的机器学习模型，而不仅仅把它当作一个“黑盒子”接受。这个过程也是调试的一个好工具。在这个例子中，我们可以看到模型基本按照预期工作。

让我们部署这个模型到生产环境，这样我们就可以从中得到一些推断结果。

使用 Microsoft Azure 进行模型部署步骤

部署步骤与前一个用例相同，所以我在这里会简要说明一下。选择要部署的模型，然后从菜单栏中点击“部署 → 部署到 Web 服务”，如图 7-57 所示。

图 7-57. 从 Azure ML Studio 部署模型

在弹出的窗格中，给您的模型取一个名字，比如 **elapsedtime-votingensemble**。选择 Azure 容器实例作为计算类型。点击部署。

当您的模型在端点下列出并且状态为健康时（图 7-58），部署完成。选择模型以查看 REST 端点 URL，在接下来的步骤中您将需要这个 URL。

图 7-58. 部署模型详细信息

随时通过选择导航菜单中的测试来在线测试您的模型。您可以使用消耗选项卡编程地探索如何对您的模型发出请求。让我们继续从我们的在线端点获取一些预测。

使用 Python 或 R 获取模型预测

要将数据发送到我们托管的模型端点并获取预测结果，我们将使用与前一个用例（“自动化分类任务”）相同的方法。这意味着您可以在 书籍网站 上找到名为 azure-ml-inference-elapsedtime.R 和 azure-ml-inference-elapsedtime.py 的两个脚本文件。

您可以继续使用您偏好的编程语言。我将通过 R 代码示例引导您，但所有部分、变量名和整体代码逻辑在 Python 文件中都是相同的。该脚本包含六个服务不同目的的部分。

Section 0 再次包含设置部分，您可以查看所需的软件包并更新您的 API 参数。确保用您之前部署的自定义端点 API_URL 替换：

# SECTION 0: Setup and Variables ----

# Make sure these packages are installed
library("httr")
library("rjson")
library("dplyr")

API_KEY = ""
API_URL = "http://*xxxxxxxxxxxxxxxxxxxxxx*.eastus2.azurecontainer.io/score"

Section 1 再次包含 API 请求函数。与前面的示例相比，主要区别在于我们现在向函数传递了不同的列，因为此端点期望不同的数据。此外，GlobalParameters 必须设置为 Azure 端点示例指定的 0.0。否则，函数的工作方式完全相同：

# SECTION 1: API Request Function ----

inference_request <- function(DayOfWeek, 
                              Origin,
                              Dest,
                              DepTimeBlk,
                              ArrTimeBlk,
                              CRSElapsedTime,
                              Distance,
                              DistanceGroup) {

  # Bind columns to dataframe
  request_df <- data.frame(DayOfWeek,
                           Origin, 
                           Dest, 
                           DepTimeBlk, 
                           ArrTimeBlk, 
                           CRSElapsedTime, 
                           Distance, 
                           DistanceGroup)
… (Truncated for brevity)

Section 2 包含预处理步骤的新细节。在以前的用例中，我们只查看了一个小时批处理数据（大约 100 行），而在这种情况下，我们处理了整个月的数据——2021 年 2 月共超过 32,000 行！尽管这可能会因为查询大小而有效，但我们在此处推动了在线推断的极限；此请求的处理时间将接近一分钟。

此外，此数据包含推理 API 的大量冗余信息。请记住，我们在工作日进行了训练。时间表中的某些航班每天都发生，这意味着每周的每一天在数据集中重复了四次或更多次。因此，代码包括一个 distinct 语句，根据我们用于 AI 预测的列删除冗余行：

# SECTION 2: Data preprocessing ----
# Fetch data from Power Query workflow
df <- dataset

# Create subset of dataframe that holds distinct flight information for prediction
df_inference <- df %>% select(DayOfWeek, 
                              Origin, 
                              Dest, 
                              DepTimeBlk, 
                              ArrTimeBlk, 
                              CRSElapsedTime, 
                              Distance, 
                              DistanceGroup) %>% 
  distinct()

distinct 操作将我们的数据框架从 32,048 行缩减到仅包含 13,826 行，这些行包含推断所需的唯一信息。这将我们的数据工作量减少了超过 50%！

第三部分最终通过使用缩减的数据集来实际调用 API：

# SECTION 3: Get Predictions ----
result <- inference_request(df_inference$DayOfWeek, 
                            df_inference$Origin, 
                            df_inference$Dest, 
                            df_inference$DepTimeBlk, 
                            df_inference$ArrTimeBlk, 
                            df_inference$CRSElapsedTime, 
                            df_inference$Distance, 
                            df_inference$DistanceGroup)

然而，最终，我们希望报告所有航班，而不仅仅是发送到我们的模型的不同组合。我们在第四部分中解决了这个问题：

# SECTION 4: Data postprocessing ----
result <- unlist(content(result))
df_inference$ELAPSED_TIME_PREDICTED <- result

# Bring results back to original dataframe
df <- df %>% 
  left_join(df_inference, by = c("DayOfWeek", 
                                 "Origin", 
                                 "Dest", 
                                 "DepTimeBlk", 
                                 "ArrTimeBlk", 
                                 "CRSElapsedTime", 
                                 "Distance", 
                                 "DistanceGroup"))

在第四部分中，我们将预测结果与原始数据框架进行连接，以便为原始数据集中的每一行获取一个预测结果。因此，数据框架 df 包含所有 32,048 个原始观察结果及其相应的预测结果，但我们只发送其中的 13,826 行给我们的模型。这不是很美吗？

第五部分清理环境并提供输出，以供在 Power BI（或任何其他 BI 工具）中进行进一步的下游处理：

 # SECTION 5: Format output for Power BI ----
rm(df_inference)
output <- df

现在是时候让我们的脚本开始工作，并在我们的 BI 工具中看到我们的模型在操作中的表现！

使用 Power BI 演示模型推断步骤

在 Power BI Desktop 中打开 Elapsed_Time.pbix。选择左侧导航窗格中的模型图标以打开建模视图。您将在这里看到两个数据源（图 7-59）。

图 7-59. Power BI 中的数据模型

数据源 AA_Flights_2021_1 包含了 2021 年 1 月的所有历史航班。这是我们用来训练模型的数据。我们不需要修改这些数据。第二个数据源 AA_Flight_Schedule_2021_2 包含了我们感兴趣的航班时间表数据。对于这个数据模型，我们希望对 Elapsed Time 属性运行预测。

我们将通过应用之前编写的 R 或 Python 脚本，在模型中创建一个新列来实现这一点。打开 Power Query 编辑器，并确保您在左侧选择了 AA_Flight_Schedule_2021_2 表，如 图 7-60 所示。在菜单窗格中，选择“转换”选项卡，然后选择“运行 Python 脚本”或“运行 R 脚本”，具体取决于您的偏好。

图 7-60. Power Query 编辑器

复制并粘贴来自 R 或 Python 脚本文件的内容，并将其粘贴到 Power BI 中的代码窗口中。双检查脚本中提供的 URL 是否为您健康的 REST 终端之一。还要确保您在 Power BI 使用的代码环境中安装了所有所需的包（httr、rjson 和 dplyr 适用于 R，或 requests、json 和 pandas 适用于 Python），如 第四章 所述。

点击“确定”，Power BI 将运行您的脚本。如果 Power BI 给出警告消息，请选择“忽略此文件的隐私级别检查”。根据您的计算机性能，推理过程可能需要一些时间。请记住，我们在这里为超过 32,000 行数据进行计算。虽然我们减少了发送到 API 的数据量，但仍然超过 13,000 行。如果您想查看计算机在做什么，请打开 Windows 任务管理器，点击“性能”选项卡，看看您的计算机在工作。

过程完成后，您应该看到一个提示，显示脚本生成的两个结果表“df”和“output”。选择“output”表，您将看到右侧的“已应用步骤”下新增了一个步骤，并且您的数据集现在包含一个名为 ELAPSED_TIME_PREDICTED 的额外列，如 图 7-61 所示。

图 7-61. Power BI 中的 ELAPSED_TIME_PREDICTED 列

在关闭 Power Query 编辑器之前，让我们快速创建一个新列，计算 AI 预测与 CRS 计划时间之间的差异，以便稍后过滤可能延误的航班。

要在 Power Query 中插入新列，请选择“添加列” → “自定义列”，并输入如 图 7-62 所示的自定义列公式。点击“确定”确认。

图 7-62. 在 Power Query 中添加新的自定义列

要确认这个新列被正确格式化为数值型值，请右键单击列 PREDICTED_DIFF_AI 并选择“更改类型” → “十进制数”。现在选择“文件” → “关闭并应用”以退出 Power Query 编辑器并应用您的转换。Power BI 将相应地更新数据模型，这可能需要几分钟的时间。在这种情况下的等待时间不应该让我们感到困扰，因为这个过程每月的航班时间表只需执行一次。

在 Power BI 中构建 AI 驱动的仪表板

数据模型成功更新后，转到 Power BI 的报告页面。我们想要把新的预测应用起来。选择“未来时间表”报告，您可以查看基线回归预测。现在是时候调整它们了。

选择左侧的散点图。替换 y 轴的值。将 ELAPSED_REGRESSION 替换为新的度量 ELAPSED_TIME_PREDICTED。相应地更新页面上的另外两个可视化图表。此外，通过删除 PREDICTED_DIFF 并添加“PREDICTED_DIFF_AI 大于 5”来替换右上角 KPI 可视化图表上的过滤器，以考虑您的 AI 预测。图 7-63 显示了更新后的仪表板。

图 7-63. 带有 AI 预测的更新仪表板

到目前为止，我们取得了什么成就？

首先，通过应用我们的 AI 模型，我们已将预测需要比计划时间长至少五分钟的航班数量从 114 减少到 34 个观察结果。

其次，如果我们看左侧的散点图，我们可以看到更多的变化；点不像简单回归模型中形成单一直线。

另外，如果我们看右侧的条形图，我们可以看到我们已经确定了两次预测的航班，比计划的时间长了 15 分钟。如果我们将其与之前的回归模型进行比较，那里最大的差异只有大约 6.5 分钟，这是一个显著更大的数值。

让我们看看是否可以稍微调整这份报告，使其更具互动性和可操作性。右键单击“未来时间表”选项卡，然后单击“复制页面”以创建当前报告的副本。将副本从“未来时间表的副本”重命名为**互动时间表**。

在“互动时间表”报告中，选择右侧的条形图，并将 DistanceGroup 字段添加到图例中，如 图 7-64 所示。

图 7-64. 条形图中突出显示的距离组

从这些额外信息中，我们可以看到预测与计划飞行时间之间差异最大的航班是长途航班（距离组 11）。然而，图表上大多数航班是短途航班。

此外，让我们去掉散点图。它提供了模型运行情况的良好概述，但不太互动。选择散点图，并用树状图视觉替换它。按照以下设置调整树状图（见 图 7-65）：

• 将 Origin 和 Dest 字段添加到 Group 中。

• 将字段 PREDICTED_DIFF_AI 放入 Values 中。

• 通过平均值聚合 PREDICTED_DIFF_AI。

• 将这个可视化过滤到“PREDICTED_DIFF_AI 大于 0”。

• 从详细信息中删除任何字段。

图 7-65. 树状图视觉和设置

结果，您应该看到一个更新的可视化，如 图 7-66 所示。在顶部启用钻取功能。

图 7-66. 带有钻取功能的树状图

树状图显示了起始机场的情况，其字段大小为该机场航班预测与计划飞行时间之间差异的平均值。每次与这棵树互动时，右侧的条形图都会改变，我们可以进行钻取。例如，单击起始机场檀香山。您会看到树状图和条形图如 图 7-67 所示更新。

图 7-67. 钻取至檀香山 (航班 AA693 已选择)

通过这次深入分析，我们可以看到有四个航班号，其中两个预测延误超过五分钟。

这为我们提供了一个很好的互动资源，用来定位我们飞行计划中的瓶颈。我们可以清楚地看到，计划从檀香山出发的航班时间安排紧张，并且檀香山到亚利桑那州凤凰城的连接有最高的超时可能性，至少根据我们目前的最佳知识。

同样地，我们可以反向搜索并从条形图中选择一根条形来显示与可能延误的航班号相关的机场，如图 7-68 所示。

图 7-68。按航班号（选择航班 AA301）深入挖掘

虽然模型并不完美，但我们已经改进了我们的基线，也许我们可以考虑更多的标准，使模型更加准确。至少现在我们有一个很好的案例展示，展示如何通过改进我们的时间表提前获益于更好的 AI 模型。

你可以从书籍网站下载最终的 Power BI 文件（Elapsed_Time_AI-Powered.pbix）。

用例：自动化异常检测

在前面的用例中，您学习了如何利用 AI 来预测分类和数值变量，并如何利用这一技能创造业务价值。在接下来的用例中，我们对于一个值是分类还是数值并不是那么感兴趣，但我们想知道某个值是否异常。为了确定一个值是否异常，算法将考虑这些点作为时间上的一系列事件，也称为时间序列。让我们进入我们用例的问题陈述。

问题陈述

我们是美国航空公司运营团队的分析师，我们的工作是保持服务水平。这包括观察美国航空公司起飞的机场的情况，特别是那些最常用的机场。2021 年 1 月，起飞超过 1000 次的最重要机场包括达拉斯沃思堡国际机场（DFW）、夏洛特道格拉斯国际机场（CLT）、凤凰城天港国际机场（PHX）、迈阿密国际机场（MIA）、芝加哥奥黑尔国际机场（ORD）、费城国际机场（PHL）和洛杉矶国际机场（LAX）。除其他指标外，我们还必须密切监控这些机场发生的滑行离开时间。

滑行离开时间被定义为飞机离开登机门到实际起飞之间的时间。高滑行离开时间是繁忙或过度拥挤的机场的代表，并可能导致意外的航班延误（正如您在前面的用例中看到的）。

虽然出租车滑出时间的自然波动是正常的，并由航班时间表考虑，但是长时间的出租车滑出峰值会导致延误的频繁发生。稳定的出租车滑出时间是保证机场顺利出发流程的重要前提条件。此外，长时间的出租车滑出时间增加了拥堵和过多的温室气体排放。

监控出租车滑出状态并标记给机场操作者不希望的峰值是消除延误和提高资源利用率的有效方法。目前处理此过程的方式是通过 BI 仪表板，显示先前提到的高流量机场每日平均出租车滑出时间的概述。该仪表板显示在图 7-69 中。

我们作为分析师查看此仪表板的主要目标是识别对机场来说异常的高峰，以便将这些问题提升给运营团队进行进一步调查。主要问题是，什么是异常点？

折线图显示了一月份七个机场的平均每日出租车滑出时间。这些机场的一月平均出租车滑出时间用虚线水平线显示。从仪表板可以看出，这些平均值因机场而异。LAX 的平均出租车滑出时间为 15.3 分钟，DFW 几乎为 20 分钟。因此，通常很难判断出租车滑出时间是否异常，而是必须根据各机场情况进行考虑。

图 7-69。出租车滑出基线仪表板

然而，标记所有高于平均值的出租车滑出时间并不实际，因为时间波动太大。相反，团队决定为每个机场设定 90 百分位数阈值，该阈值在图表中由实线水平线表示。该阈值涵盖了特定机场所有出租车滑出时间平均数的 90%。超过此阈值的所有每日出租车滑出平均值将被标记为异常。例如，DFW 在 1 月 4 日和 1 月 10 日的平均出租车滑出时间已被标记。

然而，这种方法确实存在一些限制：

• 90 百分位数标记是静态的，不考虑数据中正在发生的任何趋势。

• 它对极端值非常敏感，这意味着一天的高平均出租车滑出值可以将标准提高到不必要的高度。

• 手动查看这些图表并逐案标记问题事件是单调乏味且耗时的。

团队正在寻求一种更全面的方法来识别这些机场出租车滑出时间的高峰值。

解决方案概述

我们的目标是使异常数据点的预测更加动态，更能响应时间轴的整体发展。图 7-70 展示了此用例的整体架构高层次概述。

图 7-70. 异常检测用例架构

这一次，我们不打算训练自己的 AI 模型。相反，我们将在本书中首次使用现成的 AI 服务。这意味着我们将使用一个在我们想要达到的任务上预先训练过的 AI 模型。这就是为什么我们在这里不需要任何训练过程，而可以直接跳到推理过程。

我们在这里采取的方法是通过 AI 驱动的异常检测，分析一段时间内一系列事件（值）的情况（时间戳）。异常检测将计算预期值的动态上限和下限，并标记所有超出这些边界的值为正（超过上限边界）或负（低于下限边界）的异常。

在这个例子中，我们使用 Azure 认知服务的异常检测器。为此，我们将通过 Azure 门户启用端点，学习如何准备我们的数据，使用 Python 或 R 从这个端点获取预测，并最终在 Power BI 中应用这些预测，以构建增强版的出租车出站异常检测报告。

请注意，异常检测服务可以用于批处理和实时预测。在本例中，实时预测 意味着我们直接将我们观察到的任何点发送到 API，并将根据我们先前发送的点来获取此点是否为异常的预测。然而，对于我们的用例，我们采取的是批处理方法，这意味着我们一次性上传所有可用数据到 API。

毫不拖延，让我们转向 Azure 门户。

注意

异常检测可以被认为是预测性和诊断性分析的工具，这取决于它如何以及用于何种目的。如果重点更多地放在分析历史数据上，异常检测可以被视为诊断性分析的工具。然而，一旦我们实时分析新数据点时，它就具有更多预测分析工具的特征。

在 Microsoft Azure 上启用 AI 服务演示

我们的第一个任务是通过创建资源来在 Azure 中启用认知服务的异常检测器 API。要做到这一点，您可以访问创建异常检测器页面或手动导航至：访问portal.azure.com，搜索**认知服务**，在决策部分您将找到“异常检测器”卡片，您可以单击“创建”（图 7-71）。

图 7-71. 认知服务概述

创建异常检测器表单需要您填写更多细节。选择您的 Azure 订阅，并选择您之前为先前用例创建的同一资源组。此外，您需要指定服务应运行的地理区域。选择您偏好的区域，并为您的服务取一个描述性名称。请注意，此名称在全球范围内必须唯一；将其视为最终端点的子域。

最后，您需要选择定价层。不同的定价层会影响 AI 服务的性能和定价模型。对于我们的目的，免费层应该足够了；它允许每秒 10 次调用和每月 20,000 次交易。参见 图 7-72 以查看填写表单的示例。选择“Review + create”继续。在随后的页面上检查您的设置，并通过单击“Create”确认。

图 7-72. 在 Azure 中创建异常检测器

服务部署可能需要几分钟时间。完成后，在 Azure 中应该会看到通知和成功消息（图 7-73）。

图 7-73. 认知服务部署完成

点击“转到资源”导航到新创建的资源。或者，您可以从 Azure 门户主页导航到“认知服务”，从左侧菜单选择“异常检测器”，并从列表中点击端点的名称，如 图 7-74 所示。

图 7-74. 认知服务列表视图

选择异常检测器资源后，您将收到快速入门指南。如果您希望将端点集成到更多应用程序中，这是一个很好的返回点。我们将需要的最重要页面是左侧菜单中的“Keys and Endpoint”（图 7-75）。

图 7-75. 认知服务的访问密钥

在此页面上，您将找到三个重要组件。前两个是您的秘密凭据，您需要这些凭据来访问 AI 服务。将它们视为授权您对服务发出请求的密码。就像处理密码一样，您不应将这些密钥明文保存在任何地方，也不应公开分享它们。如果您不小心或故意（如在书中打印它们），请点击“重新生成 Key 1”或“重新生成 Key 2”按钮生成新的密钥对。这将使先前的密钥失效，并为您创建新的密钥。

你可能会问，为什么我们需要两个密钥？把它想象成你家里的客人钥匙。你有一把可以分享和分发给同事进行快速原型设计的备用钥匙，所以当密钥经常重生成时也无妨。第一把钥匙应该安全地集成到你的运行应用中，你不需要频繁更换这把钥匙（很可能，永远不用更换）。

最后，页面上的第三个组件是 API 端点。然而，请注意：这不是你可以用来进行推理请求的完整端点，就像我们在之前的示例中所做的那样。相反，你需要将实际服务的路径、服务版本和服务设置添加到其中。要了解如何构建最终的 REST 端点，你可以参考 API 文档 或之前访问的快速入门。

例如 例如，异常批量推理的最终 REST 端点如下所示（将 *ai-powered-bi-anomaly* 替换为你自己的服务名称）：

https://*ai-powered-bi-anomaly*.cognitiveservices.azure.com/anomalydetector/v1.0/timeseries/entire/detect

就是这样。现在我们已经准备好从新设置的 AI 服务开始进行预测请求了。让我们来看看如何在 Python 或 R 中进行，具体取决于你的偏好。

使用 Python 或 R 获取模型预测

在书籍的官方网站上，你会找到文件 azure-anomaly-detection-flights.r 和 azure-anomaly-detection-flights.py。你可以使用其中任何一个来根据你喜欢的编程语言进行跟进。我将在 R 中演示示例，但所有代码段、变量名和中间步骤也会出现在相应的 Python 版本中。

代码的结构类似于你之前在 AutoML 示例中看到的。脚本总共有六个部分，每个部分处理不同的内容。让我们逐个了解它们。

第零部分同样是脚本加载所有必需的包，如 R 中的 httr、rjson 和 dplyr。此外，你需要从 Azure 门户中指定你的自定义 API_Key 和 API_URL，如前所述。确保用你自己的参数替换 *xxxxxxxx* 值。同时，仔细检查 REGION 是否已设置为相应的值，如访问密钥下所示：

# SECTION 0: Setup and Variables ----
library("httr")
library("rjson")
library("dplyr")

API_KEY = "*xxxxxxxxxxxxxx*"
API_URL = "https://`*xxxxxxxxxxxxxxxxxx*`.cognitiveservices.azure.com/
anomalydetector/v1.0/timeseries/entire/detect"
REGION = 'eastus2'
… (Truncated for brevity)

在第零部分中，我们还定义了机场选择的 MIN_FLIGHTS 阈值。记住，我们不希望对所有机场进行异常检测，只对最繁忙的机场进行检测，定义为每周起飞航班数量不少于 1000 个的机场。

第一部分包含 inference_request 函数。它类似于我们之前使用的请求函数，但包含一些变化。最大的变化是请求主体已按照 Azure 异常检测器 API 的要求进行了不同结构的排列。API 预期一个包含有关时间序列粒度（在我们的情况下是每日）和实际时间序列及其相应时间戳和值的 JSON 对象。该函数接受两个向量（R）或列表（Python）作为输入（时间戳和值）。在函数内部，这两个列表将被格式化为可以被 API 使用的格式。

# SECTION 1: API Request Function ----

# Expects a list of columns and gets predictions for each row 
inference_request <- function(timestamp, value, granularity) {

  # Build request dataframe based on timestamp and value
  request_df <- data.frame("timestamp" = timestamp, "value" = value)
  … (Truncated for brevity)

第二部分正在处理实际将数据发送到 API 之前所需的数据预处理步骤。首先，我们重新分配变量 dataset，这是从 Power Query 工作流中流入的数据的默认占位符。分配不同的变量名称将清楚地显示哪个变量是指向原始源数据（dataset），哪个是指向预处理数据（df）：

# SECTION 2: Data preprocessing ----

# Fetch dataset variable from Power BI and convert Timestamp to string
df <- dataset

其次，我们将我们的阈值应用于筛选至少服务于 1,000 次美国航空公司航班的机场：

# Get airports where threshold is met
airports <- df %>% 
  group_by(Origin) %>% 
  count() %>%  
  filter(n >= MIN_FLIGHTS) %>% 
  arrange(desc(n))
  … (Truncated for brevity)

第三部分处理将函数 inference_request 应用于各个机场每日平均出租车离港时间的代码。我们通过在 for 循环中运行预处理脚本来处理此操作，该循环迭代通过阈值条件选择的机场列表。所有结果将收集在名为 df_inference_all 的数据框中：

# SECTION 3: Get Predictions ----
# Loop through all airports in list and calculate average taxi-out time
for (airport in airports$Origin) {

  # Create aggregated dataframe for average TaxiOut per Airport 
  df_inference <- df %>% 
    select(FlightDate, Origin, TaxiOut) %>% 
    filter(Origin == airport) %>% 
    group_by(FlightDate, Origin) %>% 
    summarize(AvgTaxiOut = mean(TaxiOut)) %>% 
    mutate(Timestamp = paste0(FlightDate, "T00:00:00Z"),
           AvgTaxiOut = round(AvgTaxiOut,2)) 

  # Submit request to get anomaly predictions
  result <- inference_request(df_inference$Timestamp, df_inference$AvgTaxiOut, "daily")
  result <- (content(result))

  # Convert result object to dataframe
  results_df <- data.frame(lapply(result, function(x) Reduce(c, x)))

  # Add inference results to inference_df (collects results for all airports)
  df_inference <- bind_cols(df_inference, results_df) %>% 
    select(-Timestamp)

  df_inference_all <- bind_rows(df_inference_all, df_inference)

}

最后，在第四部分中，我们将信息与原始数据框架重新联接，以便我们可以在 BI 工具中利用新列，就像之前一样。这个过程由以下代码处理：

# SECTION 4: Data postprocessing ----
# Add inference information to original dataframe
df <- df %>% 
  left_join(df_inference_all, by = c("FlightDate", "Origin")) %>% 
  mutate(upperMargins = expectedValues + upperMargins,
         lowerMargins = expectedValues - lowerMargins)

最后但并非最不重要的，第五部分返回输出，因此 Power Query 可以使用我们转换后的数据集进行进一步处理：

# SECTION 5: Format output for Power BI ----
rm(df_inference, df_inference_all, airports, results_df)
output <- as.data.frame(df)

如果代码一开始看起来过于复杂或令人不知所措，请不要担心。如果需要的话，您可以随时回过头一步一步地重新审视它。否则，可以在替换自定义变量的同时，随意复制和粘贴所有内容到第零部分。

使用 Power BI 详细说明模型推理

我们的目标是利用异常检测器创建更好的报告和更具操作性的见解。我们希望使整体报告更加准确和交互式，并摆脱手动工作的束缚。

首先，让我们将 AI 插入到我们的数据模型中。在 Power BI Desktop 中打开 Anomaly_Detection.pbix，并导航到数据模型。打开 Power Query Editor，如图 7-76 所示。

图 7-76. Power Query Editor

在我们可以插入 R 或 Python 脚本之前，我们需要包括一个小的预处理步骤。我们的脚本期望以特定格式（YYYY-MM-DD）接收飞行日期。然而，Power BI 将 FlightDate 列从字符串转换为专有的日期时间格式，这在 Python 或 R 中处理起来很困难。但我们不想删除此类型转换，因为它将提供更好的报告体验。因此，我们将手动生成 YYYY-MM-DD 字符串，并使用简单的 Power Query 公式将该字符串存储在单独的列中。从功能区菜单中，选择 添加列 → 自定义列。输入新列名 **FlightDateTxt**（注意正确的拼写和大小写！），并包含 图 7-77 中显示的自定义公式。

图 7-77. Power Query 新自定义列

结果将在预览中看到一个名为 FlightDateTxt 的新列。最后，通过右键单击列名并选择 FlightDate → 更改类型 → 文本，将原始列转换为文本。现在，我们已经准备好集成我们的 R 或 Python 脚本了。

从功能区菜单中，选择 转换，然后根据您的偏好选择“运行 R 脚本”或“运行 Python 脚本”。我将继续使用 R 作为示例，但这些步骤同样适用于 Python。

当脚本编辑器打开时，粘贴 azure-anomaly-detection-flights.r 或 azure-anomaly-detection-flights.py 中的代码，并替换来自 Azure 门户“密钥和终结点”页面的个人 API 密钥和 URL 的 *xxxxxxxxx* 值（见 图 7-78）。

图 7-78. Power BI 代码编辑器（R 示例）

单击 确定 并等待脚本执行。在提示时选择“为此文件忽略隐私级别检查”。脚本的执行时间取决于您计算机的性能。如果脚本已完成，请选择作为结果出现的“输出”表。

您最终应该在预览表中看到新列 expectedValues、isAnomaly、isPositiveAnomaly 和 upperMargins。如果前几行显示空值，这是可以接受的，因为我们仅对一些机场进行推断而非整个数据集。如果向下滚动，您应该会看到从第 32 行开始出现的结果。

在关闭 Power Query 之前，将列 FlightDate 转换回原始格式（右键单击，选择 FlightDate → 更改类型 → 日期）。您的最终预览和 Power Query 步骤应该如 图 7-79 所示。

图 7-79. Power Query 中的异常列

选择 文件 → 关闭并应用 以退出 Power Query Editor。返回到数据模型菜单，您应该看到模型中新列的列表。

繁重的工作已经完成。现在，我们可以继续到仪表板，使我们的预测对报告用户可见。

在 Power BI 中构建 AI 动力仪表板

在报告部分，通过点击第一个报告页旁边的加号图标来添加另一个报告页。我们不想更新现有的可视化内容，而是想出一个更适合我们拥有信息的方法。

我们的目标是构建一条折线图，不仅显示实际的平均出租车推出时间，还预测时间序列的上限边界。此外，我们希望突出显示超过上限边界的数据点，并将它们标记为异常。最后，我们希望为用户提供一种交互方式，方便地切换机场。

在我们添加任何可视化内容之前，打开筛选器面板并为此报告页面添加页面过滤器，如 图 7-80 所示。记住，我们只想分析所选机场组，因此过滤出这些机场对于所有图表来说很方便。将数据字段 **Origin** 添加到“此页面上的筛选器”区域，并选择以下机场：CLT、DFW、LAX、MIA、ORD、PHL 和 PHX。

图 7-80. 页面过滤选项

让我们继续添加折线图可视化。从可视化面板中双击折线图图标。将折线图拖动到报告页面的大约一半位置。按照如下字段添加到轴和数值区域，如 图 7-81 所示：FlightDate（轴）、TaxiOut、upperMargins（数值）。

图 7-81. 折线图的字段设置

在 FlightDate 下方，通过点击小 x 图标删除年、季度和月的层次结构，以便只剩下天（图 7-82）。另外，右键点击 TaxiOut 和 upperMargins，并选择平均作为聚合函数，而不是求和。字段标签现在应该显示为“平均出租车推出时间”和“平均上限边界”。

图 7-82. 带聚合方法的字段设置

你应该看到两条线（图 7-83）。

图 7-83. 平均出租车推出时间和上限边界的折线图

该图表显示了我们在页面过滤器上指定的机场的平均出租车推出时间和平均上限边界。但是，我们想要逐个分析机场。因此，再次打开筛选器面板，并为此可视化设置一个筛选器，“Origin” 是 “DFW”，如 图 7-84 所示。稍后我们将添加交互性，使用户可以选择他们想要分析的机场。

图 7-84. 折线视觉上的机场过滤器

现在您已经设置了两个过滤器：页面上的七个机场的一个过滤器，以及视觉上的 DFW 机场的一个过滤器。此外，我们已经在图表上有了两条线：一条线显示每日平均出租车出站时间，另一条线显示预测的上限边界。缺少的是异常值的突出显示。我们快要完成了！

将字段 isPositiveAnomaly 添加到值中作为第三行。右键单击并选择“新建快速测量”。在弹出的窗口中，按照图 7-85 中显示的设置进行设置：选择“计算”选项为“过滤值”，将“基础值”设置为 TaxiOut 的平均值，并将过滤器设置为 isPositiveAnomaly 等于 True。通过单击“确定”来确认设置。如果这里仍然显示 isPositiveAnomaly 的计数，请从值区域中删除它。现在应该看到三个值：TaxiOut 的平均值，upperMargins 的平均值以及 True 的 TaxiOut 的平均值。右键单击 True 的 TaxiOut 的平均值并选择“为此视觉重命名”。将此字段重命名为**异常**。同样地，将“upperMargins 的平均值”更改为**上限边界**以供此视觉使用。

图 7-85. 添加快速测量

有了这三个值，我们已经得到了图表所需的所有信息。剩下的只是“仅仅”格式化。所以前往格式设置（图 7-86）。

图 7-86. 格式化窗格

选择“X 轴”并将类型从连续更改为分类，如图 7-87 所示。

图 7-87. 更改格式类型

前往“数据颜色”并将上限边界和异常的颜色都更改为红色。

接下来，选择形状并将描边宽度设置为 6. 从图 7-88 所示的下拉菜单中选择“上限边界”。

图 7-88. 格式化形状

我们希望给这个上限带上一个不同的样式，以明确这是一个边界，而不是实际的数据值。所以将线条样式设置为点状，然后切换到“步进”模式。接下来，在形状的下拉菜单中选择“异常”，并将描边宽度设置为 0. 然后滚动到标记并打开它们。从下拉菜单中选择“异常”。将标记形状从圆形切换为正方形，并将标记大小增加到 10，如图 7-89 所示。关闭其他两个系列的标记。

图 7-89. 标记形状格式

你的折线图应该看起来像图 7-90，我们几乎准备好了！现在唯一缺少的是用户能够选择他们想要检查的机场。我们将使用 Power BI 中的交叉筛选功能，使这个过程对用户更加方便。

图 7-90. 具有异常突出显示的最终线形图

从可视化面板向报告页面添加堆叠条形图，双击即可。确保未选择线形图；否则，它将替换此可视化效果。条形图应自动填充紧挨线形图旁的空白区域。添加"Origin"到轴上，"TaxiOut"到数值上。右键点击"TaxiOut"，选择平均值作为聚合度量。在格式中，选择“Y 轴”，将内部填充增加到 50%。

Power BI 中的交叉过滤功能会导致用户从条形图中选择一条后，同一页上的其他可视化效果会相应过滤。为了允许我们线形图的动态过滤，选择线形图，打开过滤器面板，移除我们为设计图表设置的可视化过滤器“Origin is DFW”。保留页面过滤器不变。

现在，每当我们在右侧选择一个条形图时，左侧将显示具有突出显示异常值的每日平均出租车出场时间；参见图 7-91。

图 7-91. 报告互动性

为了完成我们的报告，让我们在顶部添加一个标题和当前月份，通过从第一个报告页面复制这些元素来实现。图 7-92 展示了我们最终的仪表板效果。您可以在书的网站的Anomaly-Detection_AI-Powered.pbix文件中找到最终状态。

图 7-92. 最终 AI 驱动的仪表板

由于我们现在在数据集中具有 isAnomaly 属性，我们可以轻松运行进一步的分析或此指标的自动报告。要详细了解异常检测的工作原理、如何实时运行推断结果以及围绕此 API 的一般最佳实践，我建议阅读 Microsoft 的“使用异常检测器单变量 API 的最佳实践”。

通过我们的 AI 驱动方法，我们帮助运营团队更快速地识别异常，而无需遵循固定的规则集。由于 AI 预测，数据模型中现在还可用数据标签 isAnomaly，这允许进一步分析或自动报告此指标，从而通过减少大量手动工作量来支持数据团队。

清理资源

考虑停止或删除本章中使用的以下资源，以避免持续收费：

• 停止计算实例。

• 删除回归和分类模型端点。

• 删除 Azure 认知服务异常检测器资源。

我们仍将在其他章节中使用这些资源的一部分。如果您不打算在接下来的章节中进行使用案例，可以一次性删除所有资源。在 Azure 门户中选择“资源组”，选择您创建的资源组，然后选择“删除资源组”。确认资源组名称，然后单击“删除”。

概要

恭喜！你刚刚做的事情不亚于应用先进的 AI 工具处理实际数据，并构建可操作的 BI 仪表板进行预测分析。你不仅学会了如何利用数据集中的历史信息预测未来的分类或数值变量，还涉及到了提供自动估算的 AI 服务（在本例中，用于异常检测）。

无论您是 Power BI 还是 Tableau 用户，或者您更喜欢 AWS、Azure 还是 GCP，本章中学到并应用的基本构建块将帮助您快速上手任何这些平台。尝试将所学内容应用于您自己的数据集，以获得更多的实际经验。在下一章中，我们将涉及处方分析的领域，为微观层面的决策提供智能推荐。

第八章：基于 AI 的预测分析

现在，您已经学会如何利用 AI 分析过去的数据并对未来进行预测，现在是讨论推荐行动的时候了！在本章中，您将学习如何通过让算法建议在一系列可能行动中选择最佳选项来支持数据驱动的决策。让我们开始吧！

使用案例：下一步最佳行动建议

对于这个使用案例，我们建立在预测模型建议的基础上，并选择特定客户的最佳选项。

问题陈述

我们正在一家大型电信提供商的 BI 团队工作。该公司销售各种产品，如月度或年度的有线电视和手机订阅，并且每年有数百万活跃客户。公司面临越来越多的客户流失问题。

团队的数据科学家们成功地构建了一个客户流失模型，预测了单个客户在当前季度末流失的可能性。流失预测已计算为流失分数：100 表示最高的流失概率，0 表示最低的流失概率。虽然流失预测器在识别那些可能取消订阅的客户方面非常准确和有用，但业务仍然在寻找正确的措施来对抗流失。BI 团队已经整合了一个流失预防仪表板，如 图 8-1 所示。

图 8-1. 基准流失预防仪表板

仪表板在左上角显示了散点图，比较了流失分数与月收入。在右上象限中，是那些月费用高且流失可能性也高的客户，这使得他们成为特别相关的流失预防措施的目标群体。

目前，所有标记为流失的客户都获得相同的留存优惠。平均而言，这一优惠被 31% 的客户接受，这些接受的优惠反映在散点图中的相应点上。这 31% 的接受优惠转化为了 $94,670 的维护收入。销售人员表示他们可以提供其他优惠，但不确定应向客户展示哪种优惠。由于客户群体和优惠类型的多样性，简单的 A/B 测试被证明效果不佳。

分析部门的负责人建议采用数据驱动方法，找出应向各种客户群体展示哪种留存优惠。我们的目标是制定一种至少能超过现有基准线的方法，并支持实时尝试新的优惠类型。

解决方案概述

图 8-2 展示了我们用于解决这一问题的使用案例架构。

正如您所见，繁重的工作将在数据层完成。这是因为在分析层我们依赖于现成的 AI 服务来预测最佳的推荐。

图 8-2. Next Best Offer 使用案例架构

AI 服务采用一种称为 强化学习 的方法。通过为不同的客户群体尝试不同的推荐，强化模型最终将找出向哪些客户群体展示哪些推荐。该模型将基于奖励系统进行学习。如果客户接受推荐，模型将获得奖励；如果不接受，则模型将受到惩罚。我们将使用 Microsoft 的 AI 服务 Azure Personalizer 运行和维护该模型。

然而，为了使此服务正常运行，我们需要提供用户互动数据。由于在这个示例中我们不希望向客户发送推荐，因此我们将基于包含用户偏好的规则表来模拟用户行为。在现实世界的设置中，我们自然不知道这些用户偏好，必须通过实验来找出它们，但是为了我们的模拟，我们将保留真实数据存储在一个普通的 JSON 文件中。当然，模型将无法访问此文件，需要单独找出这些模式。

在 Azure 笔记本中运行的一个小脚本将利用个性化服务模拟向用户提供推荐，并根据用户的（隐藏）偏好生成奖励。我们的模拟结果将使用 CSV 文件记录，并存储在 Azure Blob Storage 中，以便稍后通过 Power BI 进行进一步分析。

最后，我们将使用 Power BI 监控我们模型的性能，并了解哪些推荐适合哪些用户群体。通过这种方法，我们应该能够看到我们的个性化推荐与基线推荐相比有多大的改进。

设置 AI 服务

访问 portal.azure.com 进入 Azure 仪表板。在顶部的搜索栏中输入 **Personalizer**，选择服务中的 Personalizers。点击“创建”，将您带到创建个性化推荐表单的页面（见 Figure 8-3）。选择您在 第四章 中创建的资源组，并为您的推荐服务取一个名字，例如 **offer-engine**。选择 Free F0 定价层。点击“审核 + 创建”。通过最终验证后，确认创建。部署可能需要几分钟完成。

图 8-3. 创建个性化推荐表单

一旦您的 Personalizer 服务部署完成，请点击“Go to resource”导航至服务页面。让我们前往那里看看发生了什么。在服务首页，您会看到一个快速开始，看起来像 Figure 8-4。

图 8-4. Personalizer 服务快速开始

这个界面一开始可能有点令人不知所措，但我们在这里不需要做太多事情。首先，在左侧菜单中点击“Configuration”以查看您的模型设置。这是您可以调整模型学习行为的地方。选择这里的时间取决于您处理的数据。通常可以从标准设置开始，并查看模型如何迅速捕捉任何模式。但对于我们的用例，因为我们将模拟用户交互，我们希望保持等待和模型更新周期短。将“奖励等待时间”设置为 10 分钟，将“模型更新频率”设置为 1 分钟，如 Figure 8-5 所示。此外，我们可以将探索百分比降低到 15%，因为我们知道在我们的实验过程中用户偏好不会改变。

图 8-5. Personalizer 学习配置

不要忘记通过点击顶部的小磁盘图标保存您的更改，并通过刷新页面验证设置是否已应用。

接下来，查看“Learning behavior”选项卡。这是一个实际设置中的实用功能。在这里，您可以调整服务是立即交付预测结果还是运行在 学徒模式，这意味着提供基线预测并收集数据，直到此基线可以超越。您可以通过查看微软文档 “配置 Personalizer 学习行为” 获取有关 Personalizer 服务学习行为的更多信息。对于我们的设置，我们将保持一切不变，并选择“返回最佳操作，实时学习”。

要访问模型并向其发送请求，我们需要独特的模型 URL 和相应的访问密钥。您可以通过在左侧导航窗格中点击“Keys and Endpoint”菜单来找到它们，以访问如下所示的屏幕：Figure 8-6。

图 8-6. 访问 Personalizer 服务的快捷键和 URL

此屏幕显示了两个重要信息。首先，它为您提供了两个访问密钥，您需要使用它们进行 API 验证，以便允许您进行排名和奖励请求。其次，您会找到访问模型所需的 URL。将此页面保持打开，因为在与模型交互时，我们将需要这些信息。

强化学习如何与 Personalizer 服务配合工作

现在我们已经设置了我们的模型并获得了使用它的凭据，现在是时候回顾学习过程实际上是如何发生的，以及模型的工作原理了。Figure 8-7 在概念上展示了这一点。

模型的典型请求同时包含排名和奖励调用。这两者共同被称为学习循环：排名函数向用户建议某些内容，并决定模型是否利用（根据过去的数据显示最佳行动）或探索（选择不同的行动以查看是否可以改善总体推荐结果）。

Figure 8-7. 个性化服务与应用程序的概念流程交互

当服务向用户建议行动后，模型期望得到一个奖励。这可以是一个简单的标志，比如0表示“不成功”，或1表示“成功”（在我们的案例中，表示是否接受了一项提议），或者可以是一个连续的值，可以代表从新闻文章的滚动深度到股票交易赢利的任何内容。强化学习是一个非常通用的概念，可以应用于系统遵循一组定义好的规则的任何场景。

在 Azure Personalizer 的情况下，服务的工作方式如下，如您在 Figure 8-7 中所见：

1. 关于用户的信息（上下文特征）和可供选择的行动的信息通过 Rank API 发送到 Personalizer 服务。

2. 服务将通过神奇之处并将一个排名响应返回。排名响应通过它们最有可能获得奖励的概率排列的行动列表（如果在利用模式下运行）。

3. 根据用户采取的行动，应用程序计算结果分数并通过奖励 API 发送回服务。模型将接收此反馈，并根据预先定义的学习策略进行更新。

有了这些关于强化学习的新知识，让我们继续获得一些实际操作经验，看看学习循环在实践中是如何工作的，以及我们如何在我们的 BI 中利用这一点。

设置 Azure 笔记本

要模拟用户与我们的优惠互动，我们需要在 Power BI 之外运行一些代码。要运行代码，我们将使用 Azure 笔记本。这项服务提供了一种快速执行 Python 或 R 代码的方式，无需在您的计算机上安装任何软件。

要设置 Azure 笔记本，请转到ml.azure.com，选择您喜欢的工作区，并导航到笔记本，如 Figure 8-8 所示。

Figure 8-8. Azure 笔记本

选择上传 → 上传文件，如 Figure 8-9 所示。选择以下文件：

• user-simulations.ipynb

• customer-information.csv

• preferences.json

• offers.json

您可以在书籍网站上找到所有文件。选择“我信任此文件的内容”选项并点击上传。

图 8-9. 创建新的 Azure 笔记本

点击 user-simulations.ipynb 文件。您应该会在屏幕右侧看到笔记本，左侧则显示所有文件，如图 8-10 所示。

图 8-10. Azure 笔记本界面

在我们运行代码之前，我们需要为代码实际执行的计算资源进行配置。如果您尚未创建计算资源，请参阅“创建 Azure 计算资源”。如果资源已停止，请为本练习启动资源。否则，请从下拉菜单中选择计算资源，然后点击“启动计算”，如图 8-10 中所示。

一旦计算资源启动并首次连接到此笔记本，您应该会看到一条通知，提示您对 Azure 计算资源进行身份验证。点击身份验证按钮，结果会显示一个绿色徽章（图 8-11）。这一身份验证过程大大简化了从 Azure 笔记本中访问 Azure 资源的流程。

图 8-11. Azure 笔记本中的身份验证

现在，您可以从右上角选择您想要使用的编程语言。为了跟随代码示例，请选择“Python 3.6 - Azure ML”（或更新版本），如图 8-12 所示。

图 8-12. 在 Azure 笔记本中切换编程语言

注意

我们将在此代码中使用一些 Azure 包进行身份验证和 Blob 存储，目前这些功能在 R 中还不受支持。虽然仍然可以在 R 中执行此工作流程，但会非常繁重。因此，在这种情况下，我只提供 Python 版本。所有 R 用户，请跟随这里的内容。

模拟用户交互

最后让我们模拟一些用户与优惠的交互。为此，我们会做出两个假设。首先，我们定义了一组有限的优惠可能性，具有相当简单的复杂性。其次，我们假设我们知道哪个用户分段接受哪个优惠。有了这些信息，我们可以让我们的模型开始随机向各种客户段推荐优惠，并通过探索捕捉到底层模式。

我们还保持用户细分复杂性相对较低，因为我们不想超过免费层的 50,000 个 API 调用。请记住，我们每个等级和奖励函数都需要一次调用，而典型的强化模型需要几千次迭代才能开始学习有意义的模式。因此，我们将在开始时保持复杂性低，这样我们就可以在较少的学习循环中获得良好的学习结果（并且您可以保持在免费学分范围内）。但是，我们将坚持一个原则：模型不知道哪个客户段偏好哪种优惠类型，它必须自己找出答案。

不要被此示例限制。如果您希望追求更高的目标，可以自由添加关于客户细分或行动特征或新优惠的更多上下文特征。

对于我们的模拟，我们需要四个组件：

• 关于可用优惠类型和优惠属性的信息

• 关于客户的信息（上下文特征）

• 有关客户真实偏好（基本真相）以计算离线奖励

• 一个可以存储互动数据的地方，以便稍后通过 Power BI 进行分析

第一个组件包含在offers.json文件中，该文件列出了可用的优惠及其相应的特征。为了公平起见，我们假设所有这些优惠的价值相同，因此没有比其他优惠更划算的优惠。这纯粹是偏好的问题。

第二部分是关于客户的信息（上下文特征）。这些信息包含在customer-information.csv文件中。正如前面提到的，我们通过仅考虑“老年人”和“合同”这两个变量来保持复杂性低，但当然，Personalizer 服务可以处理更多的特征。事实上，我们提供的优惠环境特征越多，效果就越好——只要我们有足够的时间和学分来学习。

第三个部分在preferences.json中。它包括关于哪个客户段偏好哪种优惠类型的信息。表 8-1 以表格形式显示这些信息。这些是我们模型未知的模式，我们希望模型能够自动学习。

表 8-1. 带有客户偏好的规则表

老年人	合同	首选优惠
是	按月	现金折扣（优惠 1）
是	一年	免费一个月（优惠 2）
是	两年	免费一个月（优惠 2）
否	按月	业绩奖励（优惠 3）
否	一年	业绩奖励（优惠 2）
否	两年	现金折扣（优惠 1）

最后，我们需要一个地方来存储仿真结果。为了保持示例简单（并通过 Power BI 保持可访问性），我们将结果保存为普通的 CSV 文件。为了提供更多实际的体验，我们将输出写入 Azure Blob Storage（在第四章中创建），然后从那里加载到 Power BI 中。

使用 Python 运行仿真

在 Azure Notebooks 中，仔细看看你面前的代码。我的目标是让你理解这段代码在做什么，即使你对 Python 不熟悉，所以让我们来逐步走过它。

代码由五个部分组成。第一个称为用户输入，您需要自定义一些选项：

OFFERS_FILE_PATH

offers.json 文件所在的文件路径。

PREFERENCES_FILE_PATH

preferences.json 文件所在的文件路径。

USER_TABLE_FILE_PATH

user-information.csv 文件所在的文件路径。

PERSONALIZATION_BASE_URL

在 Azure 门户中的 Keys 和 Endpoint 屏幕上显示的终结点。

KEY

Azure 门户页面上的访问密钥之一（具体哪个密钥无关紧要）。如果决定重新生成密钥，请确保替换此密钥。

AZURE_CONNECTION_STRING

用于授权 blob 存储的 Azure 连接字符串，如果为空将被忽略。

AZURE_CONTAINER_NAME

Azure blob 容器的名称，如果为空将被忽略。

如果按照前面展示的方式将文件上传到 Azure Notebooks，可以将文件路径保留原样。

在本节中用你的自定义变量替换 *xxxxxxxxx* 值，包括 Personalizer URL、Personalizer 密钥和 Azure 连接字符串。还要确保你创建了一个名为 simulation 的存储容器，如第四章中所述。

这个脚本只需要你自定义这些内容。剩下的就是在我们一次性运行整个脚本之前进行阅读和理解。

第二个代码部分叫做 Dependencies，加载了此脚本所需的所有包。所有这些包应该已经预装在我们刚选择的“Python 3.6 - Azure ML”内核中。

第三部分称为 Functions，包含四个主要函数：

add_event_id

此函数为每个 rank 调用生成一个唯一的 ID。该 ID 用于标识 rank 和奖励调用信息。此值可以来自业务流程，如 Web 视图 ID 或事务 ID。

add_action_features

此函数将所有优惠列表添加到要发送给 rank 请求的 JSON 对象中。

get_reward_from_preferences

此函数在调用 Rank API 后被调用，用于比较用户对某个优惠的偏好（基于其资历和合同类型）与 Personalizer 根据这些过滤器为用户提供的建议是否正确。如果推荐正确，则返回 1 的奖励；否则为 0。

loop_through_user_table

此函数包含脚本的主要工作。它将迭代提供的用户表的每一行，从 API 请求个性化优惠，与实际用户偏好进行比较，并计算一个奖励分数，然后将其发送回 Personalizer 服务。所有结果将在名为 results 的列表中收集，并在函数完成时返回。

第四部分称为 Execution，将调用这些函数并运行实际的工作流程。

第五部分 Export，将通过保存到名为 results.csv 的平面文件持久保存结果。如果提供了 Azure 存储凭据，则结果文件也将上传到 Azure Blob 存储。

再次验证您是否已经在第一个代码部分自定义了所有输入。现在，通过选择“重新启动内核并运行所有单元格”来运行代码，如 图 8-13 所示。

图 8-13. 运行整个 Azure 笔记本

对整个客户表的迭代大约需要 10 分钟。当进程完成时，您应该会在左侧的文件树上看到新文件 results.csv 被创建。这基本上是我们实验的产物（也会是实际场景的日志文件）。如果在输入中指定了 Azure 连接字符串和有效的容器名称，该文件将自动上传到您的 Azure 容器。如果上传失败，请确保您不要重新运行整个脚本，而只需运行处理文件上传的脚本最后一个代码单元。

在 Azure 门户中评估模型性能

为了快速了解模型的工作情况，我们可以在 Azure 门户中检查模型的性能。导航至您的 Personalizer 资源，并从左侧菜单中选择 Evaluations。向下滚动，您应该可以看到平均奖励分数，如 图 8-14 所示。

在本示例中，您可以将这个数字解释为模型为客户选择正确优惠的百分比。此时，奖励分数应该还相对较低。

图 8-14. Personalizer 评估

请记住，我们从一个天真的模型开始，通过几千次实验才找出潜在的模式。个性化服务通常需要成千上万个示例才能在实际场景中表现良好。如果您运行前述的模拟代码两到三次，您应该会看到此数字随之增加。如果不是这种情况，这清楚地表明模型学习行为出现了问题。您可以查看 Microsoft FAQ 来解决模型学习中的错误。

我们可以通过离线评估来提高性能，而无需重新运行整个数据集。这种技术允许您使用现有数据，并通过各种学习策略重新训练模型，找出哪种策略最适合您的数据。让我们试试这个方法，看看是否能比我们迄今为止训练的模型效果更好。从顶部菜单中选择“离线评估”，如图 8-15 所示。

图 8-15. 创建离线评估

双检查日期范围是否与您运行模拟实验的日期匹配，并将所有其他设置保持不变。单击“确定”以启动离线评估，如图 8-16 所示。

图 8-16. 离线评估表单

评估过程大约需要几分钟时间。完成后，从列表中选择评估以查看更多详细信息。点击链接“与其他潜在学习设置比较您应用程序的分数”以查看评估指标，如图 8-17 所示。

图 8-17. 离线评估结果

正如您可以看到的，从离线评估中，我们了解到如果应用 Hyper1 学习设置，我们可以将我们的模型从 0.5363 的平均奖励（作为评估结果）提高到 0.5775。考虑到我们留出 15%用于探索，这更接近理想情况下的 0.85。通过单击旁边的“应用”按钮选择新的学习设置。这将重新训练您的模型，并使用新的学习设置部署它。

您现在可以回到代码中，再次运行模拟以查看模型的改进。但首先，我们希望将我们的 AI 建议整合到我们的 BI 仪表板中。让我们在此使用案例的最后一步中探索这一点。

Power BI 中的模型推断演示

正如您可能记得的那样，我们的使用案例场景已经提供了一个 BI 仪表板，显示了当前客户流失预测以及标准报价的整体接受率，表明我们客户保留策略的成功。现在我们想做的是将这些信息与我们的个性化服务的绩效见解结合起来，看看我们的举措是否导致更多客户接受报价。

首先，从书的网站打开 Power BI 工作簿Offer_Recommendation.pbix，然后转到数据模型。您应该在这里看到用于客户流失预测的现有表结构。让我们通过导入模拟过程中创建的结果 CSV 文件，将我们的模型结果添加进去。如果您之前决定将 CSV 文件保存到本地，请选择获取数据 → 导入文本/CSV，并找到本地计算机上的 CSV 文件。

如果决定将文件保存在 Azure Blob 存储中，请选择“获取数据”→“Azure”→“Azure Blob 存储”。提供之前提供的存储帐户名称。在下一步中，粘贴从 Azure 门户获取的访问密钥。确认这些选项后，您应该看到显示所有容器和文件的列表，如 图 8-18 所示。

图 8-18. 从 Power BI 访问 Azure Blob 存储

选择带有您的模拟数据的容器。但不要加载文件！而是点击“转换数据”按钮。这将允许您使用 Power Query 提取 CSV 文件的实际内容。否则，您将只看到 CSV 的元数据，如文件名、创建日期和大小。

在 Power Query 编辑器中，单击二进制数据链接，如 图 8-19 所示。

图 8-19. 使用 Power Query 编辑器访问 blob 文件

这将带您进入 CSV 文件的内容；将二进制数据转换为表格数据显示为“应用步骤”面板中的处理步骤（见右侧）（图 8-20）。

图 8-20. 从 blob 存储导入表格数据

通过从顶部菜单选择“关闭并应用”确认转换。新 CSV 文件的内容将添加到您的数据模型中。Power BI 将基于字段 CustomerID 自动为 Churntable 和模拟数据模型生成关系，如 图 8-21 所示。

图 8-21. Power BI 中的数据关系

在 Power BI 中构建 AI 动力仪表板

转到 BI 报告页面，我们需要做一些修改，以包含我们的新基于 AI 的建议。对报告进行以下更改：

1. 更新散点图视觉：

   • 图例字段：从模拟数据模型中用“奖励”替换“接受报价？”。

   • 更改格式和数据颜色下的颜色方案：将空白设置为灰色，0 设置为红色，1 设置为蓝色。

2. 更新仪表盘表：

   • 将“平均接受报价”替换为“模拟”表中的“奖励”。将“奖励”应用于“平均”计算。

3. 更新防御收入指标视觉：

   • 将奖励 = 1 添加到视觉筛选器中。

   • 从视觉筛选器中删除“接受报价”。

4. 更新树状图表：

   • 在组字段中，将“显示的报价”替换为“预测”。在格式设置窗格中调整数据颜色，以便空白匹配灰色，所有报价匹配蓝色的色调。

最终的仪表板现在应该看起来类似于 图 8-22。

图 8-22. AI 动力推荐仪表板

让我们简要比较这个仪表板与本章开头的原始仪表板（见图 8-1）。你会注意到两个主要变化。

首先，与我们现有的基准相比，准确率从 0.31 上升到 0.54，提高了 23 个百分点。这意味着通过使用基于 AI 的方法，我们可以说服更多客户接受我们的留存优惠。因此，捍卫的月收入也相应增加到了 154.38K，几乎增加了 6 万美元。

其次，我们可以看到优惠的比例增加了。以前最受欢迎的优惠 1（现金优惠）现在几乎不再发生。大多数客户接受了优惠 3——更高的性能。

我们可以进一步改善这些 KPI 吗？记住，我们之前通过离线评估调整了我们的模型。但我们尚未应用新模型。

返回模拟代码，再次运行而不做任何更改。再过 10 分钟，代码将会处理一次数据集，因此个性化服务可以使用更新的学习设置。你的 Azure Blob Storage 中的results.csv文件应该已自动更新。因此，我们在 Power BI 中所需做的一切就是进入数据模型并点击“刷新数据”，如图 8-23 所示。

图 8-23. 刷新数据

几秒钟后，Power BI 已获取更新的数据。如果我们返回报告，我们可以看到更新的推荐实施情况（见图 8-24）。

图 8-24. 数据更新后的 AI 驱动仪表板

通过更新的学习设置再次迭代数据集，我们的推荐又提高了 5 个百分点，现在达到了 59%的准确率。捍卫的收入又增加了$17,680。

对于实际场景，想象一下，你不是反复迭代相同的数据集，而是每个季度、月份或者每天都处理新的客户数据，这取决于你的业务。这样，你可以监控你的推荐模型的表现，并决定它是否足够好以投入生产。至少仪表板将为你提供一个坚实的指导，评估基于 AI 的推荐服务的业务价值，与你现有的基准进行对比。

您可以从书籍网站下载最终的 Power BI 文件Offer_Recommendation_AI-Powered.pbix。

清理资源

考虑停止或删除我们在本章中使用的以下资源，以避免任何持续的费用：

• 停止计算实例。

• 删除 Azure Personalizer 服务资源。

• 删除 Azure Blob Storage 中的 CSV 文件。

我们仍将在其他章节中使用这些资源。如果您不打算在接下来的章节中执行这些用例，可以一次性删除所有资源。在您的 Azure 门户中选择“资源组”，选择您创建的资源组，然后选择“删除资源组”。确认资源组名称，然后点击删除。

总结

我希望您能从这个用例中看到，我们如何利用 AI 将预测转化为行动，以及如何找出哪些行动适合特定的情境。虽然 Azure Personalizer 只是众多服务中的一个，但基于强化学习的推荐引擎背后的思想和原则是相似的，如果需要，您也会发现学习其他服务非常容易。此外，通过 Azure Blob Storage，您学会了实时监控模型更新并将其无缝集成到您的 BI 中，过程也不会太过复杂。

在下一章中，我们将处理非结构化数据，看看如何利用 AI 分析图像、文档和音频文件的内容，并将其融入我们常规的 BI 工作流程中，与来自业务的现有信息进行整合。

第九章：利用 AI 处理非结构化数据

在之前的章节中，我们在处理结构化数据时大量使用了 AI，或者大多数人称之为表格。然而，企业中的许多数据实际上并未存储在干净的表格中，而是以各种格式存在，如 PDF、图像、原始文本、网站和电子邮件。当考虑到这些格式时，组织内可用的大多数数据是非结构化的。借助 AI，我们可以解锁这些宝藏，并从以前未被分析师触及或需要大量手动工作才能从中获得见解的数据中获取洞察。在本章中，我们将探讨 AI 如何帮助我们分析文本、文档和图像文件。

使用案例：从文本数据中获取洞察

书面语言是人类收集的最大和最多样化的数据来源之一。企业也不例外。数据的最大创造者是人，无论是在组织内还是外部。顾客成为内容生产者，通过网络和各种渠道分享他们对产品或服务的意见。

在这个使用案例中，我们将部署一个 AI 服务来帮助我们理解这些数据。在具体的问题中，我们将分析用户评论的规模，并通过 BI 仪表板传达关键见解。让我们开始吧！

问题陈述

小房间、不友好的员工和可怕的早餐——或者并非如此？一家大型酒店的管理团队因各种客户反馈的多样性而感到紧张。管理层是否真的需要解决问题，还是只是不得不接受零星的投诉，作为经营住宿业务的一部分？运营负责人已聘请您作为外部分析师，以了解客户对酒店的看法以及这一趋势随时间的发展情况。

作为数据来源，公司提供了通过酒店网站和预订平台收集的客户反馈文本文件样本。由于新季即将开始，管理层希望尽快看到结果，速度明显优先于准确性。管理人员希望了解是否存在根本性问题，并有能力在必要时深入了解。

解决方案概述

查看图 9-1 中的高层次使用案例架构。

图 9-1 从文本数据中获取洞察的使用案例架构

从对这种架构的第一眼看，您应该立即认识到分析层似乎非常简单。原因是，为了自动分析许多文本文件，我们将使用 NLP AI 服务。正如您之前所见，这种 AI 服务不需要任何训练；相反，我们可以将数据发送到服务，并立即获得响应。

在这种情况下，我们的目标是提取关于存储为文本文件的客户评论中的意见是消极还是积极的信息，这也被称为情感分析。此外，我们希望提取关键词，以便我们可以关联到带有积极或消极情绪的词组。展示应以 BI 仪表板的形式呈现，在我们的情况下是 Power BI（用户层）。

此用例中最具挑战性的部分在于数据层。我们需要将数据整理成正确的格式，将其发送到 AI 服务，并以结构化表格的方式检索结果，以便我们的 BI 系统可以处理它们。我们将通过在 Azure Notebooks 上使用 Azure ML Studio 中的脚本构建一个小型数据处理流水线来实现这一目标，该流水线加载文件，调用 AI 服务，转换结果，并导出可以被我们的 BI 系统（Power BI）消费的扁平 CSV 文件。

设置 AI 服务

首先，我们需要在我们的 Azure 订阅中激活认知服务文本分析。这一步骤非常简单，类似于我们在其他章节中做过的操作。要激活认知服务文本分析，请转到您的 Azure 门户，并在搜索栏中搜索**cognitive services**，如 图 9-2 所示。

图 9-2. 搜索 Azure 认知服务

从建议列表中选择认知服务，然后转到相应的资源页面。在此页面，您可以为各种数据和用例启用认知服务。向下滚动直到看到语言部分，如 图 9-3 所示。

图 9-3. 语言认知服务

从这里，您可以通过点击“+ 创建”按钮部署新的语言服务资源。在接下来的表单中，您应该已经非常熟悉了，选择您的 Azure 订阅和资源组，并为您的语言服务命名。此外，请确保选择免费层（F0），该层允许每 30 天进行 5,000 次交易。一次交易是一个文本记录，对应于作为输入提供给语言服务 API 的文档中的 1,000 个字符单位数量——对于我们这里的用例来说，这已经足够了。您可以在 图 9-4 中看到填写好的表单示例。

点击“审核 + 创建”，然后在自动审核流程通过后点击创建。部署将需要几分钟时间，但之后您应该会看到一条通知，提示新资源已准备就绪。

图 9-4. 创建文本分析服务表单

部署完成后，导航到新资源，可以通过单击通知或者（如果您离开了页面）只需在 Azure 搜索栏中搜索您在表单中提供的资源名称来实现。 在这两种情况下，您应该会看到资源的概述页面（图 9-5）。

图 9-5. 文本分析概述页面

我们可以在这里做很多事情，但现在我们只想专注于两件事。 首先，我们如何对 API 进行身份验证？ 其次，我们在哪里找到 API 的工作原理（我们需要编写或更好地复制和粘贴的代码）？

要回答第一个问题，您可以在左侧菜单窗格中单击“键和端点”选项。 在这里，您会找到两个密钥，就像在 第八章 中的 Azure Personalizer 示例中一样。 您只需要其中一个来调用 API。 在新标签页中保持此窗口打开，因为我们很快将需要这些资源密钥。

要了解 API 的工作原理，您可以在概述页面的“开发”下探索资源。 这将带您到一个网站，解释了各种情景，您可以在文本分析 API 和您将使用的代码中使用这些情景。 现在可能会有点多，但不要被吓到。 您不需要所有这些信息。 现在，认识到我们稍后在数据准备步骤中编写的大部分代码可以从此文档页面获取，并根据自己的需求进行调整，就足够了。

浏览文本分类的文档时，我们可以发现有关我们新 AI 服务的一些更有用的信息。 转到 概念 → 数据限制，您应该会找到一张表（图 9-6）。

图 9-6. 文本分析请求限制

如果我们查看此表，并定位到情绪分析行，我们可以看到 API 接受每次请求的 10 个文档。 我们可以一次性向 API 发送最多 10 个文本文件，与逐个发送文本文件到 API 相比，这将大大加快我们的推理过程。 我们将在数据处理期间回到这一点。

现在，AI 服务的一切都已经准备就绪。 让我们继续构建我们的迷你数据管道，并对客户反馈数据进行一些推理。

设置数据管道

要从原始文本文件到设计精美的 BI 仪表板，我们必须解决一些中间步骤。 在生产环境中，这将被称为我们的提取，转换，加载（ETL）过程。 对于我们的原型，我们不会将其称为完全成熟的 ETL 过程，但本质上我们正在做同样的事情。 让我们称之为我们的迷你 ETL 作业。

我们将编写一个简短的脚本来处理 ETL 过程的基本部分：

1. 从文件中读取纯文本文件。

2. 将文件内容发送到 AI 服务 API。

3. 收集结果，转换它们，并将它们存储在结构化的数据对象中。

4. 将文件导出为扁平表格，以便我们的 BI 软件可以轻松消费。

对于第一步，我们需要获取文本文件并将它们存储在脚本可以访问的地方。我们将使用 Azure Blob Storage 进行存储。前往书籍网站，下载reviews.zip文件。在 Azure 门户中，导航到存储，选择您之前设置的存储帐户，并创建一个名为**texts**的新容器，如图 9-7 所示。该容器将保存原始输入文本文件。“表”容器应该已经存在于第四章中，并将接收我们的迷你 ETL 过程的表格化输出。

图 9-7. 在 Azure Blob Storage 中创建新容器

创建“texts”容器后，将所有单独的文本文件上传到这里。不要上传 ZIP 文件，而是其内容。您的容器现在应如图 9-8 所示。

图 9-8. 带有审查数据的 Azure 存储容器

现在我们的输入数据已准备好供脚本消费。暂时可以将其他“表”容器保持为空。我们将通过下面将要查看的脚本来填充它。

从书籍网站下载ETL_For_Text_Analytics.ipynb文件。该笔记本包含您执行迷你 ETL 过程所需的所有代码。如果您已经在计算机上安装了本地 IDE，如 Jupyter 笔记本，可以直接使用它。如果没有，我建议使用 Azure 笔记本作为托管 IDE，因为它是 Azure 订阅的一部分。

我将指导您使用 Azure 笔记本的示例，但是当您使用本地 IDE 时，步骤相同。

注意

我们将使用一些 Azure 包进行此代码所需的身份验证和 Blob 存储，这些包目前不支持 R 语言。虽然在 R 中仍然可以执行此工作流程，但会非常耗费资源。因此，在这种情况下，我仅提供 Python 版本。所有使用 R 的用户，请跟随这里。

让我们首先创建一个新的 Azure 笔记本：

1. 前往Microsoft Azure 机器学习工作室，并选择您在整本书中一直使用的工作区。

2. 从左侧菜单中选择笔记本。

3. 单击加号图标，并选择“上传文件”，如图 9-9 所示。

4. 在您的计算机上找到ETL_For_Text_Analytics.ipynb，选中“我信任该文件的内容”选项，然后点击上传。

图 9-9. 将文件上传到笔记本环境中

您应该看到笔记本，如图 9-10 所示。

图 9-10. ETL 笔记

笔记本将显示在右侧。虽然此文件包含大量代码，但不要被吓到。事实上，您唯一需要修改的是第零部分“Packages and Setup”中第 2、3 和 6 行的访问凭据和 AI 服务端点的自定义参数，就像您在第八章中所做的那样。

作为在让您一次运行整个笔记本和逐行讨论代码之间的中间解决方案，我将通过解释代码部分来为您提供此代码正在执行的高级概述。我建议您跟着执行代码单元格。

此代码分为四个主要部分，大致对应我之前在 ETL 过程中提到的四个步骤：

1. 从 Azure 下载文本文件：我们将从 Azure 下载原始文本文件到运行笔记本的本地计算机。

2. 调用 AI 服务（情感分析）：我们将发送文本文件到 AI 服务并保存结果。

3. 将 AI 结果转换为 CSV：我们将 AI 结果从 JSON 输出转换为平面 CSV 文件，以便我们的 BI 系统能够轻松消化。

4. 将 CSV 上传到 Azure Blob Storage：我们将文件上传回连接到我们的 BI 系统的 Azure Blob Storage 中。

在开始之前，请确保笔记本连接到正在运行的计算资源。如果尚未创建计算资源，请参考“创建 Azure 计算资源”。

如果在计算资源启动后再次要求进行身份验证，请单击显示身份验证按钮。然后，您应该看到成功提示（图 9-11）。

图 9-11. 身份验证提示

现在，请前往代码的第零部分。这是我们确保所有需要的包都已安装和加载，更重要的是，提供您的个人 Azure 凭据的地方。这是整个笔记本中您需要更改内容的唯一位置。用来自 Text Analytics Cognitive Service 和 Storage 账户的 Azure 门户自定义值替换密钥、端点和 Azure 连接的虚拟字符串。

更新了个人凭证后，通过将光标放在第一个代码单元格内并按 Shift+Enter 来运行第一个代码单元格。此代码的输出应该相对简单。所有包应该已经安装在 Azure 计算资源上，您应该只看到Requirement already satisfied的通知，如图 9-12 所示。

注意

虽然我们在代码中以明文存储我们的 Azure 凭据，但请注意，这通常不是良好的编码实践。我们之所以这样做是为了保持示例简单，并且因为笔记本仍然托管在受保护的 Azure 环境中。如果您想了解如何处理身份验证机制的最佳实践，请查阅微软资源 “关于 Azure Key Vault”。

图 9-12. 包安装的笔记本输出

让我们继续我们的小型 ETL 过程的第一部分：文件下载。第 1 步的第一个代码单元调用了我们在前面设置部分中定义的一个类对象。这段代码基本上是通过使用您的连接字符串来建立与 Azure 存储帐户的连接，并从您提供的 AZURE_INPUT_CONTAINER 中下载所有文件。运行此代码单元，大约一分钟后应该会完成，并打印如 图 9-13 所示的输出。

图 9-13. Blob 下载的笔记本输出

注意

如果您想知道为什么这个下载如此耗时，请放心，有方法可以加快下载过程——例如同时运行多个下载任务。事实上，您甚至可以直接传递 AI 服务的文件 URL，而完全不下载它们。对于我们的原型，慢速下载的方法仍然可以接受。但是如果您进入生产阶段，您可能会考虑更快的替代方案。

接下来，让我们继续我们代码的第二部分，调用 AI 服务。在这一部分，我们将文本发送到 AI 服务进行分析。如前所述，我们一次发送 10 个文本文件（文档）的批次到 API，以便更快地获得结果。运行代码单元。一旦完成，您应该会看到第一个结果，其中包含情感分析的前 10 个结果，如 图 9-14 所示。

图 9-14. 情感分析的原始笔记本输出

正如您从这个预览输出中所注意到的，结果的结构是嵌套的。AI 服务不仅为每个文本提供情感分数，还为每个分析的文本在词级别上提供了详细的意见分析。这对于数据的解释将会很有用，但不利的一面是，我们需要费些工夫来解开整个对象并将其转换回一些简洁的平面表格。这就是本代码第三部分的内容。让我们继续前进吧！

数据准备代码的第三部分是最详尽的部分。虽然主要的 AI 工作负荷已经完成，但还需要进行一些后处理工作，提取每个文本的情感分数和每个条目中发现的相应意见。

现在，如果你问自己，“我到底该如何编写这段代码？”我有好消息告诉你。大部分这段代码都是从 AI 服务的文档页面借用来的。你还记得 Azure 控制台里的快速入门参考吗？这就是这段代码大部分来自的地方。一旦你理解了一般行为，你所需做的调整就相当简单了。

在这个示例中，我进行了三处调整。首先，我只提取每个文本项的高级情感分数，并将它们保存为扁平表以更好地与 CSV 兼容。这个表或数据框还包含原始文件名、原始文本以及从文本文件名中提取的日期时间列。这将产生一个漂亮的扁平 CSV 输出，我们稍后可以在我们的 BI 中显示。其次，我为文本文档中找到的所有正面和负面词汇或意见分别创建了一个扁平 CSV 文件，同样存储有对原始文件名和提取的日期时间列的引用，以便这些术语可以被链接回其原始上下文，并且也可能按时间进行过滤。如果你感觉幸运，逐行查看代码看看发生了什么。如果没有，也没关系。我们不打算成为软件工程师。无论如何，点击此单元格的运行按钮以查看显示在图 9-15 中的输出。

图 9-15. 情感分析的格式化笔记本输出

为了方便起见，输出以易读的格式打印了每个文本文档的情感和意见。例如，你可以从图 9-15 看到，尽管有语法错误，“地下室很吵”被 AI 识别为负面情感，而 AI 服务能够识别“房间”和“吵闹”作为这一负面意见的主要驱动因素。这不是挺好吗？

最后，这段代码还创建了我们想要的 CSV 文件。如果你查看左侧的文件资源管理器并点击刷新，你应该会看到三个新的 CSV 文件，就像图 9-16 所示。

图 9-16. 笔记本环境中的 CSV 输出

要使这些 CSV 文件对我们的 BI 可访问，让我们转到第四部分的代码部分，这部分代码专门用于将这些文件上传到 Azure Blob Storage。与第三部分相比，这将会轻而易举。

执行最后一个代码单元格。眨眼间，你应该会看到显示在图 9-17 中的输出，确认文件已成功上传。

图 9-17. 已完成上传的笔记本输出

恭喜！您已完成最困难的部分，并成功完成了迷你 ETL 挑战。现在，与每个 ETL 过程一样，此流程是可重复的。每当更新 blob 输入容器中的文本文件，并且文件保持相同结构时，您只需重新运行整个工作流程（一次），输出容器中的 CSV 文件将被替换并覆盖为新结果。

现在让我们暂时离开 ETL 的领域，转向更有趣的部分：在我们的 BI 中可视化和综合我们的结果。

警告

不要忘记在此练习后停止计算资源，以避免任何持续费用！

使用 Power BI 进行模型推断演练

要显示我们的结果，我们将再次回到 Power BI。在 Power BI 中创建一个新报告，选择 Azure Blob 存储作为数据源。连接到您的存储账户，然后选择 Tables 文件夹旁边的复选框。点击“Transform”。在 Power Query Editor 中，您会找到文件夹中所有 CSV 表格的列表。我们需要逐个处理这三个表格。

选择第一个文件并点击 Binary 链接以查看数据预览，如图 9-18 所示。确保 Datetime 列已正确转换为日期时间格式。点击“关闭并应用”，然后对其他两个 CSV 文件重复这些步骤。

图 9-18. Power Query 中的情感数据

现在你的数据模型应该列出三个单独的表。然而，我们知道这些表彼此相关，并且我们希望 Power BI 也知道这一点。右键单击任何表格，选择“编辑关系”。在弹出的编辑器中，基于“文件名”列在“positive_targets”和“sentiment”表之间创建关系。基数应该是多对一，如图 9-19 所示。点击“确定”，然后为“negative_targets”表重复此设置。

图 9-19. Power BI 中的数据关系

此后，您的数据模型中的表格应该已连接，如图 9-20 所示。

图 9-20. Power BI 中的数据模型

现在我们的数据模型已经完成，是时候继续处理可视化了。

在 Power BI 中构建 AI 驱动的仪表板

让我们快速回顾一下情况：管理层想知道是否有什么事情需要他们关注。为了对客户评论进行高层次的概述，我们需要四个要素：

• 随时间发展顾客情感以检查趋势

• 顾客投诉的项目列表（负面目标）

• 顾客喜欢的项目列表（正面目标）

• 回到原始数据以获取更多上下文信息

我们可以通过多种方式传达这些信息。我决定编制一份报告，包含一个显示总体趋势的折线图，两个突显正面和负面目标的树状图，以及一个简单的表格，列出所有客户反馈的纯文本。你可以在图 9-21 中看到最终结果。

图 9-21. AI 动力情感分析的最终仪表板

试着在 Power BI 中自行重新创建这个仪表板，或者想出你自己的解决方案。或者，你可以从书籍网站下载完整的 User_Reviews_AI-Powered.pbix 文件，并将其连接到你自己的 Azure Blob Storage。

那么这个仪表板告诉我们什么？首先，我们可以看到正面和负面情感似乎有一个相对稳定的趋势，每天都有起伏。如果我们将可视化数据聚合到月度水平，情况就会变得更加清晰（参见图 9-22）。从月度的角度来看，负面情感似乎大幅增加。如果我们探究原因，我们会发现大多数投诉是关于房间、早餐和 WiFi 的。尽管房间可能在短期内难以修复，但早餐和 WiFi 提供了可以由管理层迅速解决的明确行动项目。

图 9-22. 每月情感分析

另外，由于我们已经在表格之间创建了关系，Power BI 允许我们筛选特定的数据点。例如，如果我们从折线图中选择一个日期，仪表板的其余部分将相应更新，并仅显示在这一天收集的相关数据，反之亦然。关于房间，客户投诉了什么？只需点击负面目标树状图中的房间，通过探索底部的原始文本来了解客户的说法。这为探索数据集并更多地了解实际客户反馈提供了一个很好的途径。

虽然这个仪表板只触及了文本分析的冰山一角，但希望你已经看到了在大规模文本数据分析中其强大的能力。多亏了 AI 服务，这可以用几行代码完成，并集成到任何 BI 系统中。

使用案例：使用 AI 解析文档

你有见过一个不使用表格的企业吗？对于企业来说，表格就像程序员的 API 一样重要。表格有一个很大的优势。它们通常很好地在人类之间交换信息。给定一个特定的表格和一些描述，你应该很快能够弄清楚如何阅读表格或如何填写它。

当表格需要由计算机处理时，常常会出现问题。通常表格仍然以纸质文件或其电子副本形式存在，即 PDF 文件。如果您希望大规模处理它们，往往除了手动查阅并从这些 PDF 中提取数据进行进一步分析之外别无选择。收据也可以看作是一种表格；它们提供了一种易于人类阅读但难以机器解释的重复数据结构。在这个使用案例中，我们将学习如何利用人工智能帮助我们大规模阅读文件并从中提取值，以便在商业智能系统中显示。

问题陈述

在我们的下一个场景中，假设我们正在为一家提供咨询服务的中型公司工作。该公司位于德国，销售代表经常出差到潜在客户那里，以准备或完成交易。这些出差大多通过连接德国大城市的高速列车进行，称为 ICE（InterCity Express）。

我们的出差管理部门负责控制总体开支。商务旅行的流程如下：销售代表可以通过火车运营商（德国铁路）的自助门户预订火车票。这些票券使用公司信用卡支付。出差管理团队在每月末监督信用卡账单结算，以便了解出差开支的概况。然而，信用卡对账单除了支出金额和日期外并未提供任何进一步的细节。为了优化出差开支并更好地了解哪些商务旅行造成了最高成本，出差管理团队希望更深入地了解出差情况，包括按流行旅行路线（火车出发地和目的地）进行的细分。

这些信息可以在销售代表每次成功预订后自动通过电子邮件接收的预订收据中找到。图 9-23 展示了这种收据的示例。

特别是，团队对从这份表格中提取以下信息感兴趣：预订日期、出发地、目的地以及票价。出差管理团队希望找到一种自动提取这些信息并理想情况下使用现有的商业智能系统进行报告的方法。他们已经提供了一位销售代表的 162 张收据样本，用于初版原型的开发。

图 9-23. ICE 列车在线车票

解决方案概述

在这种情况下，我们将使用光学字符识别（OCR）从文档中提取信息。现在，这项技术并不新鲜，并且已经存在了一段时间。但是，AI 将帮助我们解决这个问题的至少两个层面。第一层是改进实际的 OCR——即识别单个文本字符并将其转换为可机器读取的形式（纯文本字符串）。第二部分是理解这些字符，找出哪些属于单词或句子，甚至识别更复杂的结构，如表格。

查看图 9-24 以审查此使用案例的整体架构。

图 9-24. 解析文档的用例架构

要解决这个问题，我们将采用与“使用案例：从文本数据获取洞察”类似的方法：

1. 部署 Microsoft Azure 中的即用即用 AI 服务——在本例中，是计算机视觉的认知服务（分析层）。

2. 将数据加载到分段区域——再次使用 Azure Blob Storage（数据层）。

3. 准备一个小的 ETL 脚本，从分段区域加载数据，应用 AI 服务，并将其转换为平面 CSV（数据层）。

4. 将 CSV 文件上传到一个可以轻松访问和可视化的位置，并与我们的 BI 工具（用户层）一起使用。

开始吧！

设置 AI 服务

前往你的Azure 门户，在搜索栏中输入**认知服务**。从建议列表中选择“认知服务”，然后进入相应的资源页面。向下滚动至 Vision，你应该看到显示在图 9-25 中的可用服务。

图 9-25. 计算机视觉的认知服务

从“计算机视觉”框中选择“+ 创建”，你应该会看到设置计算机视觉资源的现在广为人知的表单。再次选择一个资源组，给你的资源命名，并选择免费的 F0 定价层。不要忘记选择底部的复选框，同意使用“负责任的 AI 条款”。

花一分钟时间了解这些术语。它们基本上意味着你不会通过使用 AI 来违反个人权利。请记住，你发送到 API 的每个图像或文档都将由微软拥有和运营的服务处理。因此，特别是当你处理个人数据时，你必须确保已获得同意和权限。对于我们的用例，我们处理的是虚构或公共领域的数据，因此没有风险。然而，在商业环境中，在开始向远程 AI 服务发送关于你的客户或员工的文档之前，请三思。

在完成表单后，点击“审核 + 创建”，并在自动验证通过后点击“创建”。几分钟后，您的服务应该已部署完成，您可以通过点击通知链接或在 Azure 门户中的搜索栏中搜索资源名称来访问它。如果打开资源页面，您应该会看到一个与图 9-26 类似的屏幕。

图 9-26. 计算机视觉服务概述

快速入门看起来与以前的 AI 服务有些不同，但基本上包含相同的信息：您将找到访问密钥的链接以及一些快速入门的代码示例。目前，您可以导航到“Keys and Endpoint”，在那里您将找到资源的 HTTP 终端和秘密访问密钥。保持此页面打开，因为我们稍后将需要这些密钥。

AI 设置已完成，现在我们继续加载和处理 PDF 文件。

注意

等一下，你可能会说。为什么我们没有使用专用的 Azure 服务“表单识别器”？表单识别器是一项专门针对表单识别和价值提取的计算机视觉服务。该服务更专注，但在开始工作之前需要一定程度的定制训练和设置；它并非即开即用的服务。另一方面，计算机视觉 API 是一个多用途的服务，类似即插即用。它更容易实现，但在任务过于专业化时会受到限制。它在除了表单提取之外的场景中也会很有用。我的建议是首先从通用计算机视觉开始，如有需要再转向更定制或特定的服务。如果你想了解更多关于表单识别器的信息，请参阅“Azure 表单识别器文档”。

设置数据管道

让我们首先将我们的 PDF 文件上传到 Azure Blob 存储容器中，以便我们可以轻松访问它们。通过搜索栏或查看仪表板中的最近项目，打开新的 Azure 门户窗口并导航到 Azure Blob 存储。导航到“容器”并创建一个名为**pdfs**的新容器，如图 9-27 所示。

图 9-27. 在 Azure Blob 存储中创建新的存储容器

现在，在书籍网站下载pdfs.zip文件，并在本地计算机上解压缩它。从本地的pdfs文件夹下载所有内容到 Azure Blob 存储中的容器。最终，所有 PDF 文件应存储在 Azure Blob 存储的“pdfs”容器中，不包含任何子文件夹或任何 ZIP 文件，如图 9-28 所示。

图 9-28. Azure Blob 存储中的 PDF 文件

现在文件已准备好进行分析，我们可以继续进行 ETL 过程。与之前的示例一样，我将逐步为您讲解代码，并在 Azure Notebooks 中运行脚本。当然，如果您更喜欢，也可以使用您的本地 IDE。

首先，从书籍网站下载ETL_For_Document_Analysis.ipynb文件到您的本地计算机。打开Azure ML Studio，选择您的首选工作区，然后点击“开始”。导航到笔记本，并选择“上传文件”，如图 9-9 所示。选择ETL_For_Document_Analysis.ipynb文件并将其上传到 Azure Notebooks。上传后，笔记本将显示在屏幕右侧。不要忘记像在之前的用例中一样将您的笔记本连接到计算资源。当一切准备就绪时，您的屏幕应类似于图 9-29。

图 9-29. 文档分析的 ETL 笔记本

现在我将为您详细讲解代码，并逐节解释发生的情况。请按照这里覆盖的顺序执行代码单元格。

首先是第零部分，包和设置，这里再次是您需要输入自定义的 Azure 连接字符串以及计算机视觉服务的自定义密钥和端点的地方。您的窗口还打开着吗？很好，那么您只需在此处复制并粘贴这两个值即可。在接下来的部分中，代码确保导入了所有所需的包，并定义了一些自定义函数。一旦我们将要使用它们，我将更详细地解释这些函数。现在，通过将光标放在内部并按 Shift+Enter 来运行第一个代码单元格。

第一部分涵盖了从 Azure Blob 存储中下载文件。这个非常简单，与我们在之前的用例中所做的完全相同。也运行这个代码单元格。作为结果，在文件浏览器中您应该看到一个pdfs文件夹。如果没有，请点击文件浏览器中的小刷新图标。

第二部分再次很简短。在这里，我们只是调用 AI 服务并从分析中获取原始结果。这里有两个重要的事情需要注意。

您可能会注意到代码中的time.sleep(6)命令。我包含了这一行以确保我们不会超过每分钟 20 次请求的免费限制。那么为什么我们等待 6 秒而不仅仅是 3 秒（3 秒 × 20 次请求 = 60 秒）？这是因为在计算机视觉的情况下，我们正在运行一个异步操作。

在前一个情感分析示例中，请记住，我们只是将文本发送到 API，并立即收到带有 AI 结果的响应。而在计算机视觉中，操作更复杂，结果可能需要一段时间（如几秒钟）。因此，对于每个文档，我们需要进行两次 API 调用：一次 POST 请求将文档发送到 AI 服务，一次 GET 请求获取结果。如果您仔细查看第零部分下的 document_analysis 函数，您将注意到这两个 API 调用。事实上，我们在进行 GET 请求之前每次等待两秒，以增加结果在每次调用时都能及时返回的机会。

如果您升级到付费计划，可以安全地从第 2 步循环中删除 time.sleep(6) 行。但我建议在第一个 POST 和 GET 请求之间保持短暂的暂停；否则，您将遇到许多空的（但仍计费）API 调用。考虑到免费计划的限制，对 162 个 PDF 文档的整体分析大约需要 30 分钟。运行代码单元。现在是喝杯咖啡的时间，然后我们开始做一些“脏活”！

迄今为止，调用 AI 服务相当简单。不过，从响应中提取信息可能会很混乱。要理解原因，让我们看看 AI 结果的样子。为此，我们不能只是打印结果对象。结果对象是一个嵌套结构，我们需要解开它。幸运的是，GitHub 的带有 Python 代码示例的文档向我们展示了如何做到这一点。

# Inspect the first result
read_result = results[0]
# Print the detected text, line by line
if read_result.status == OperationStatusCodes.succeeded:
   for text_result in read_result.analyze_result.read_results:
       for line in text_result.lines:
           print(line.text)
           print(line.bounding_box)

以上代码将产生以下输出（为简洁起见进行了截断）。

DB
[0.6349, 0.5273, 1.0222, 0.5165, 1.0222, 0.764, 0.6349, 0.764]
Online-Ticket
[3.0799, 0.5784, 4.6416, 0.5784, 4.6416, 0.7642, 3.0799, 0.7642]
ICE Fahrkarte
[0.5206, 1.1069, 1.4109, 1.1069, 1.4109, 1.2117, 0.5206, 1.2117]
...
Betrag
[0.5614, 3.5237, 0.873, 3.5237, 0.873, 3.6278, 0.5614, 3.6278]
**92,00€**
[1.109, 3.5237, 1.455, 3.5237, 1.455, 3.6197, 1.109, 3.6197]
...
Datum
[0.5621, 3.6571, 0.8733, 3.6571, 0.8733, 3.7384, 0.5621, 3.7384]
**02.02.2018**
...
Halt
[0.5207, 4.6438, 0.7449, 4.6438, 0.7449, 4.7352, 0.5207, 4.7352]
Datum
[2.4111, 4.6438, 2.7826, 4.6438, 2.7826, 4.7352, 2.4111, 4.7352]
Zeit
[2.9165, 4.6429, 3.1326, 4.6429, 3.1326, 4.7352, 2.9165, 4.7352]
Gleis
[3.4701, 4.6429, 3.7657, 4.6429, 3.7657, 4.7358, 3.4701, 4.7358]
Produkte
[4.104, 4.6438, 4.6302, 4.6438, 4.6302, 4.7352, 4.104, 4.7352]
Reservierung
[4.852, 4.6429, 5.6354, 4.6429, 5.6354, 4.7605, 4.852, 4.7605]
**Hamburg Hbf**
[0.5214, 4.8136, 1.2506, 4.8136, 1.2506, 4.932, 0.5214, 4.932]
02.02.
[2.4063, 4.8167, 2.7382, 4.8167, 2.7382, 4.9068, 2.4063, 4.9068]
ab 16:36 5
[2.9179, 4.8148, 3.5288, 4.8148, 3.5288, 4.9068, 2.9179, 4.9068]
ICE 1527
[4.1059, 4.8209, 4.6115, 4.8209, 4.6115, 4.9153, 4.1059, 4.9153]
1 Sitzplatz, Wg. 38, Pl. 12, 1 Fenster,
[4.8551, 4.8209, 6.8913, 4.8209, 6.8913, 4.9404, 4.8551, 4.9404]
**Leipzig Hbf**
[0.5213, 4.9636, 1.1351, 4.9636, 1.1351, 5.082, 0.5213, 5.082]
...
Seite 1 / 1
[7.1081, 11.2414, 7.5931, 11.2414, 7.5931, 11.3253, 7.1081, 11.3253]

要理解这一点，让我们将输出与原始文档进行比较，如图 9-30 所示。

图 9-30. 在线火车票（完整 PDF）

在代码输出和图 9-30 中，我已突出显示了我们感兴趣的文档元素（日期、价格、起始地点、目的地）。

如果我们将 AI 的输出与原始文档进行比较，我们会发现 AI 逐行解析文档。它从左上角的“DB”和“Online-Ticket”开始，到右下角的“Seite 1/1”结束。

每行文本都是结果对象的一个元素，后面的数字是这些行的边界框，指示行在文档中的位置。六个数字对应于 x 和 y 坐标，如图 9-31 所示，坐标系统从文档的左上角开始，坐标为 (x = 0, y = 0)。每个坐标列表映射为 [x1, y1, x2, y2, x3, y3, x4, y4]。

图 9-31. 计算机视觉服务使用的边界框

要从文档中提取我们想要的信息，我们需要依赖于这样一个假设，即文档按西方阅读顺序解析（从左到右，从上到下）；如果需要，可以为 AI 服务进行调整。

让我们从运行标记为第三部分的 Part 1 代码单元格开始获取日期信息。在这个代码单元格中，大部分工作由自定义函数 get_text_by_keyword(result, "Datum") 完成。该函数在第零部分中定义，接受一个给定的关键字参数，此处为 Datum（德语中的 日期），并返回 AI 响应中紧随其后的项目。由于 AI 从左到右解析文本，结果将是我们正在寻找的实际日期。我们进行了一些后处理，以将其转换为更常规的日期格式，就这样。提取具有显著表单标签的表单值是非常简单的。

现在我们转向第二部分，提取起始点和目的地信息。这部分有点棘手，因为信息不在同一行上列出，而是在文档中的不同行上，类似于表格结构。为了使事情更加复杂，如果连接的列车在起点和最终目的地之间运行，则该列表可能会更长。我们如何解决这个问题呢？我们将使用关键词搜索和边界框过滤的组合方法。在运行单元格之前，让我们先看一下。

首先，我们调用函数 get_text_between_keywords(result, "Halt", "Wichtige Nutzungshinweise:")，这将给我们提供表格的所有文本元素，这是表格的第一列标题（Halt，德语中的 停止）和表格之后的第一个文本对象（Wichtige Nutzungshinweise，意为 使用条款）。该函数将提取表格中的所有文本元素，如图 9-32 所示。

图 9-32. 包含在 PDF 中的表格数据

然而，我们并不需要所有的文本元素，而只需要第一列的项目。我们该如何获取它们呢？可能有许多方法可以解决这个问题，但我发现最简单的方法是使用相应的边界框来定位这些信息。我们的想法是，从我们刚刚收集的文本片段中，仅提取由虚线框标识的部分，见图 9-33。

图 9-33. PDF 表格中相关列

那么我们如何获取这个虚线框的坐标呢？我们取第一列标题Halt的左下角，并定义它为我们虚线框的左上角。要获取框的宽度，我们取文本Datum的左下角的x坐标，因为我们知道这将始终是第二列。这将成为我们虚线框的x2 值。最后，要获取虚线框的高度，我们在提取的文本区域中搜索最高的y3 坐标。这些坐标就是我们绘制矩形所需的一切。

现在我们已经定义了我们的“筛选”框，我们可以保留文本发现，其中边界框位于我们筛选器的范围内。这就是函数get_text_by_position(result, filter_box)为我们处理的内容。这个函数将返回一个干净的列表，其中包含所有的列车停靠站点。现在，我们只需取此列表的第一项和最后一项，voilá——我们得到了起始点和目的地值。理解了这里正在发生的事情后，运行第二部分的代码单元。

第三部分再次简单一些。在这种情况下，我们根据文档中关键字Betrag（指示价格）来提取价格信息，类似于我们提取日期的方式。唯一的区别是，这次我们不仅提取关键字后面的下一个项，还提取关键字后面的下两个项，正如您在函数get_text_by_keyword(result, "Betrag", 2)中看到的那样。为什么会这样呢？简短的答案是，这使我们的脚本更加健壮。我们可以安全地根据€符号识别价格信息，并且我们知道它应该很快出现在标签Betrag后面，但不一定是第一个项目；它可能是第二个。继续运行这个单元格。

现在数据转换只剩下一步，那就是将我们的结果汇总并将 CSV 表写入。到目前为止，您应该有四个列表对象——dates、prices、origins和destinations——它们的长度都相同。在这最后一步中，我们将它们绑定到一个数据框架并将其导出为 CSV 文件。运行此最后一个单元格，然后您应该在左侧的文件资源管理器中快速刷新后看到新文件public-transportation-costs.csv。结果表显示在图 9-34 中。

图 9-34. 提取 PDF 数据的结构化输出

最后，让我们将结果上传到 Azure Blob 存储上名为“tables”的容器中。第四部分中的最后一个代码单元将为您处理此操作。运行此单元格，并为自己鼓掌；大部分工作已经完成。现在我们可以继续并在我们的 BI 中可视化结果。

警告

不要忘记在完成脚本后停止 Azure 计算资源，以避免任何持续的费用！

使用 Power BI 模型推断演示

让我们进入有趣的部分。打开你喜欢的 BI 工具，并加载我们刚刚创建的 CSV 文件，以获取更多见解。我将再次用 Power BI 的示例来带你完成这个过程。

在 Power BI 中，创建一个新报表，并选择“获取数据”中的 Azure Blob 存储。提供你的 Azure Blob 存储账户名称，如 图 9-35 所示。

图 9-35. 从 Azure Blob 存储导入数据

你应该看到你的 Blob 存储文件列表。导航到 tables 文件夹并点击“刷新”，如 图 9-36 所示，如果你仍然看不到新文件 public-transportation-costs.csv。

选择 tables 文件夹的复选框，然后点击“转换数据”以打开 Power Query。点击 CSV 文件 public-transportation-costs.csv 名称旁边的二进制链接。

图 9-36. 在 Power Query 中刷新数据预览

在这里你需要确保两件事情。首先，日期列应正确识别为日期数据类型。其次，确保价格转换为数值。如果 Power BI 没有自动识别正确的数据类型，请右键单击日期列并选择日期，如 图 9-37 所示。

图 9-37. 在 Power Query 中更改数据类型

如果价格没有显示为数值，请右键单击列并选择“更改类型” → 使用区域设置，如 图 9-38 所示。

图 9-38. 在 Power Query 中使用区域设置解析小数

将数据类型更改为小数，并设置区域设置为英语（美国），如 图 9-39 所示。

图 9-39. 使用区域设置更改数据类型

最后，你的表格应类似于 图 9-40。通过单击“关闭并应用”关闭 Power Query。

图 9-40. 在 Power Query 中转换后的数据集

在 Power BI 中构建 AI 助力仪表板

转到报表并创建一些新的可视化内容。我决定用折线图展示每年的总旅行费用，用指标显示总商务旅行次数，用水平条形图展示热门目的地，最后在树状图中显示所有路线（起点和目的地的组合），其中大小等于花费的金额。图 9-41 展示了这些可视化内容。

图 9-41. AI 助力费用追踪仪表板

使用这些可视化工具，旅行管理团队可以清楚地看到总体成本趋势和绝对出行次数。团队还可以确定哪些路线对整体旅行费用贡献最大。在这个例子中，我们可以看到从汉堡到莱比锡来回的连接占据了旅行费用的最大比例。我们还可以看到大多数出行都始于汉堡，而波恩和法兰克福则是从这个起点出发的第二和第三最受欢迎的目的地。

欢迎您自行重新创建这个仪表板，或者看看是否能找到更好的方式来展示数据。如果您想看到我创建的最终仪表板，可以从书籍的网站下载 Document_Analysis_AI-Powered.pbix。

用例：图像中物体计数

在前面的用例中，我们仅仅触及了计算机视觉的广泛能力。在接下来的场景中，我将向您展示如何进一步利用现有基础设施——即在图像中检测物体。为此，让我们更详细地看一下手头的问题。

问题陈述

我们为一个试图改进整体交通管理和交通流量以最小化道路拥堵的交通和道路管理机构工作。一个重要因素是控制高速公路上的限速。为了设定限速，管理机构需要理想情况下对道路上的交通流量进行恒定测量。虽然新建道路配备了相应的测量传感器和技术，但旧道路通常只安装了用于手动交通检查的闭路电视（CCTV）摄像头。

运维团队与我们联系，希望通过现有的摄像头基础设施进行交通计数，并为测试目的提供了样本 CCTV 录像。图 9-42 展示了一个 CCTV 录像的示例。

图 9-42. CCTV 摄像头录像。来源：Kaggle

这个用例的 CCTV 图像是通过 Kaggle 提供的数据集提供的（高速公路 CCTV 录像图像）。

解决方案概述

为解决手头的问题，我们基于前一个用例中的现有计算机视觉 AI 服务展开工作。由于我们使用了相同的服务，因此整体的用例架构与之前的计算机视觉用例几乎相同，正如您可以在图 9-43 中看到的那样。

图 9-43. 图像中物体计数的用例架构

现在我们不是进行读取操作，而是调用一个名为“检测对象”的服务。在这种情况下，我们希望动态分析数据。因此，我们不会将数据集加载到 Azure Blob 存储中，而是直接从 Web URL 消耗 CCTV 录像，并将此 Web URL 馈送到 AI 服务中。我们仍然有一个小的 ETL 作业，消耗 HTTP URL，调用 AI 服务，并将输出写入 Azure Blob 存储作为平面 CSV 文件，以便我们可以用 BI 工具消耗它。让我们开始吧！

设置 AI 服务

我们正在使用与之前部署的 AI 服务相同的 AI 服务在“用例：使用 AI 解析文档”。如果您还没有完成，请转到前一节，在“设置 AI 服务”下完成列出的步骤，然后返回此处。如果您已经完成了，只需跟着做，不需要再做其他事情。

事实证明，计算机视觉有许多使用案例都在同一个服务下运行。通过刚刚部署的计算机视觉服务，您不仅可以提取文本和检测对象，还可以识别品牌名称、热门地标、标记图像等等。要获取完整指南，请查看 “计算机视觉文档” ，这是 Azure 认知服务的一部分。

设置数据管道

从书的网站下载 ETL_For_Image_Analysis.ipynb。与之前一样，将文件打开在本地 IDE 中或上传到 Azure 笔记本中。除了这个文件，您还需要 image-urls.txt，它需要位于笔记本文件相同的目录中。

如果您打开 ETL_For_Image_Analysis.ipynb，您会发现它看起来与我们之前使用的文件相似，正如您在图 9-44 中所看到的。我将快速为您介绍主要步骤。

图 9-44. 图像分析的 ETL 笔记本

在第零部分中，更新您的 Azure 凭证。这些与您在先前用例中使用的相同。输入完后，运行第一个代码单元。

在第一部分中，执行代码单元以导入包含图像 URL 的 TXT 文件。确保您从书的存储库下载了该文件，并将其放置在与 .ipynb 文件相同的位置。

第二部分调用计算机视觉 AI 服务。与之前的用例相比，对象检测是同步操作，因此我们每张图片只需一次 API 调用，并且可以将等待时间减少到每张图片后的三秒钟，以保持在免费套餐的每分钟 20 张图片的限制内。如果您使用的是付费套餐，可以安全地从脚本中删除time.sleep(3)这行。

执行这个代码单元格。在等待结果的同时，现在是注意一些对象检测 AI 服务的限制或前提条件的好时机。这些限制或多或少也适用于其他供应商，不仅限于 Microsoft Azure。正如我们可以在Azure 文档中看到的那样，以下限制适用：

需要注意的是对象检测的限制，以避免或减少假阴性（遗漏的对象）和有限的细节。

如果物体很小（小于图像的 5%），通常不会检测到物体。

如果物体排列紧密（例如一堆盘子），通常不会检测到物体。

对象不会根据品牌或产品名称进行区分（例如商店货架上的不同类型的汽水）。但是，您可以通过使用品牌检测功能从图像中获取品牌信息。

最重要的是我们要考虑第一个要点。我们基本上必须确保感兴趣的对象与整体图像大小相比足够大。如果您仔细注意文本文件中的图像 URL，您会注意到我们并没有将原始镜头传递给 AI 服务，而是在使用内容传递网络（CDN）时即时裁剪这些图像。通过这种方式，我们可以专注于实际对我们有意义的图像部分，并确保潜在的汽车对象覆盖了图像面积的 5%以上。因此，如果您在对象检测 AI 服务中看到效果不佳，请尝试裁剪图像或将其分割为部分。

到目前为止，AI 服务应该已经完成了它的工作，您可以运行下面的代码单元格来打印一个示例结果（图 9-45）。

图 9-45. 一个图像的计算机视觉服务示例输出

正如你所看到的，AI 服务不仅提供检测到的对象名称，还提供更多的上下文，例如对象在图像中的位置和额外的语义信息。接下来让我们进入第三部分，数据转换，我们想要解析这些结果以获取图像中车辆的计数。

这里的方法相当简单。我们调用一个名为count_objects(result, "Car", 0.7)的函数，该函数根据两个标准过滤结果的输出：对象属性名称和检测的置信度。我选择了 0.7，这相当于“AI 服务有 70%的把握检测到的对象是一辆车。” 可以自由地尝试不同的值，找出适合你使用情况的最佳值。运行此代码单元格，您将看到一个包含计数的列表。

唯一剩下的任务是将其放入一个漂亮的表格格式中，还包括原始图像文件 URL 以引用数据源和一个使数据排序更容易的索引。执行第三部分的第二个代码单元格，您应该看到类似于图 9-46 的输出。

图 9-46. 图像分析服务输出的表格数据

最后，在第四部分的最后一个代码单元格中运行，将 CSV 文件上传到我们的 Azure Blob Storage。这就是我们原型 ETL 作业所需做的一切。接下来让我们开始在 BI 中可视化结果！

警告

完成脚本后，请别忘了停止 Azure 计算资源，以避免继续产生费用！

Model Inference with Power BI Walk-Through

由于我们将 AI 结果存储在扁平化的 CSV 文件中，任何 BI 工具都可以利用这些数据。我将再次展示如何在 Power BI 中使用它——并且会有一个小惊喜！

首先，创建一个新的 Power BI 文件。选择“获取数据”→“Azure Blob Storage”，提供您的存储账户名称，并选择名为“tables”的容器。点击“转换”并点击显示新表名为traffic_counts.csv的行上的二进制链接（参见图 9-47）。如果看不到此文件，请在 Power Query 中刷新预览。

图 9-47. 在 Power Query 中列出的 Azure Blob Storage 文件

在 Power Query Editor 中，我们没什么可做的。只需右键点击索引列名并选择重命名，如图 9-48 所示。将列重命名为**Index**。

图 9-48. 在 Power Query 中重命名列

双重检查表格中是否包含所有三列：索引（数字）、计数（数字）和文件 URL（字符串）。点击“关闭并应用”以确认查询。

在我们开始构建报告之前，让我们包含 Power BI 为我们提供的一个小而强大的功能。点击左侧（数据模型和报告图标之间）的小表格图标，如图 9-49 所示。在这个窗口中，选择 URL 列，并从顶部菜单窗格中选择“列工具”。找到稍微隐藏在顶部菜单中的“数据类别”字段，并将数据类型从文本更改为图像 URL，如图 9-49 所示。

图 9-49. 在 Power BI 中设置数据类别为图像 URL

在 Power BI 中构建 AI 驱动的仪表板

现在，让我们进入报告页面。在此示例中，我仅选择了两个组件：一个用于随时间计数（在我们的案例中是指数）的折线图，以及一个显示计数、指数和图像 URL 的表格。因为我们已将 URL 字段格式化为图像 URL 数据类型，Power BI 将从此 URL 获取图像并显示在我们的仪表板中。这不是很神奇吗？查看图 9-50 看看最终仪表板的效果。

图 9-50. AI 强化的交通监控仪表板

当然，此表格具有您从 Power BI 可视化中期望的完全互动性。因此，当您选择例如在指数 80 上具有最高流量计数的一个点时，表格将显示此数据点的相关图像，就像图 9-51 中展示的那样。这样，我们还可以通过观察图像中的四辆车确保 AI 检测是正确的。

图 9-51. 在报告中选择单个数据点

欢迎您按照自己的需求重新创建或修改此仪表板。您可以在书籍网站下载 Traffic-Monitoring_AI-Powered.pbix 文件的最终版本。

清理资源

在本章中，考虑停止或删除我们在此章节中使用的以下资源，以避免任何持续的费用：

• 停止 Azure ML Studio 中的计算资源。

• 删除您部署的 Azure 认知服务。

• 删除 Azure Blob 存储中的所有文件。

我们仍然需要 Azure 资源组用于最终章节的使用案例。如果您不打算继续使用，请一次性删除所有资源。在您的 Azure 门户中选择“资源组”，选择您创建的资源组，然后选择“删除资源组”。确认资源组名称，然后单击“删除”。

总结

本章只是触及了 AI 服务能够处理非常规 CSV 或 Excel 格式数据源的表面。希望您尝试了这些 AI 服务后感到愉快，并希望您能从中获取更多灵感，以便在您自己的用例中使用这些工具。

本章总结了可以增强您的 BI 的 AI 服务构建模块。在下一章中，我们将探讨如何结合您学到的内容，构建一个具有多个 AI 服务的完全功能的 BI 仪表板。

第十章：将所有内容结合起来：构建 AI 驱动的客户分析仪表板

你在这本书中走了很长的路（希望如此！）并学到了很多关于如何在分析堆栈的各个层次部署 AI 服务的新知识。在本章中，我将向你展示如何将这些分析和 AI 服务层次结合起来，为 BI 用户提供更好的体验，并通过融合这两种方法来利用 AI 和 BI 的潜力。事实上，你应该看到不同的 AI 服务并不是二选一的决定，它们可以互补。例如，我们可以将非结构化数据（原始文本）转换为结构化数据（情感评分表），以便我们可以用它来进行监督学习（使用情感评分来预测客户流失）。

在本章结束时，你将能够混合和匹配多个 AI 服务，开发更强大的用例。为了将编程工作保持在最低限度，我们将使用 Azure 机器学习设计器作为一个无代码工具来创建高级 ML 工作流，这允许比你在前几章学到的 AutoML 服务更多的定制化。

问题陈述

在这种情景下，我们是一个电信服务提供商的数据分析团队的一部分。消费者部门的销售和营销负责人发起了一个项目，进一步研究客户流失的主题。根据企业的定义，客户在取消合同的那一刻即算是流失，无论合同的剩余期限如何（企业提供月租和 24 个月合同）。

企业目前面临以下挑战：

• 流失率被测量，但营销和销售部门尚不能理解它们。流失指标似乎断断续续地上升和下降，员工们在尝试从这些指标中获得任何有意义的见解时遇到了困难。

• 作为抵制流失的有效措施，企业已确定提供反流失策略是一种可行的策略。这些优惠被提供给正在取消合同的客户，以赢回他们或者防止他们完全取消。这些优惠被证明是有效的，但成本高昂。因此，企业希望知道哪些客户最有利于被针对此类反流失优惠，并且最好在发生流失之前预测流失，以确保优惠类型与客户细分的匹配度良好。

• 企业定期对客户进行调查，其中包括大量的开放式文本反馈。通过查看调查数据的样本，调查团队建议文本答案可能为流失建模提供重要信号。

• 企业希望通过浏览数据来达到一定的交互性，以了解在各种客户细分中关于客户流失的情况。

数据分析团队预计能够确定向业务利益相关者呈现请求信息的可行方式——当然，尽快并且在重度预算约束下。

解决方案概述

查看图 10-1 中的用例架构。正如您立即看到的那样，这将是我们在本书中构建的最复杂的用例。但别担心，我们基本上是在重用您在前几章学到的概念和技术。

要了解这个架构中发生了什么，让我们从用户层的顶部开始，并找出我们的输出应该实际是什么样子的。我们希望在 Power BI 中有一个交互式仪表板，让我们能够多方面分析客户流失；我们想做以下几件事：

• 了解流失发生的位置，并为用户提供与历史数据交互的无缝体验（描述性分析）。我们将使用 Power BI Q&A 视觉来实现这一目的。

• 理解最近客户流失中哪些波动应标记为“过高”。我们将使用异常检测进行诊断分析。

• 预测未来客户流失，以了解哪些部分的收入面临风险（预测分析）。

• 分析客户评价反馈，以了解我们的流失报告中客户抱怨的内容（非结构化数据）。

图 10-1. AI 驱动的客户分析用例架构

在我们查看分析层发生了什么之前，让我们跳到底部，检查我们为这个用例准备的数据层。我们的 BI 系统主要由三个数据源提供数据：

• 源文件Churn_Metrics_2021.csv包含有关客户流失的汇总历史信息。

• 源文件Churn_Predictions_June_2022.csv包含最新的客户数据及其相应的流失预测。

• 源文件Customer_Dimensions_June_2022.csv包含关于我们客户的人口统计信息，我们可以用于进一步的探索或钻取。

这些数据通常存储在数据仓库中，但在我们的情况下，我们从 Azure Blob Storage 中获取它们作为 CSV 文件，以保持简单。虽然Churn_Metrics_2021.csv和Customer_Dimensions_June_2022.csv这些文件已经给出，但我们需要通过分析来创建Churn_Predictions_June_2022.csv。

现在，让我们转向分析层。为了我们的目的，我们将在 Azure ML Designer 中使用一个 ML 模型，该模型将在历史数据（结构化和非结构化数据）上进行训练。我们已提供的历史客户事实表涵盖了过去五个月，并已包括由我们内部分析师计算的流失标签。除了流失标签，事实表还包含一个标志，指示客户是否在过去接受了反流失。训练数据还将包括来自Survey_Responses_Jan-May_2022.csv中提供的用户调查原始文本的情感信息。

为了理解开放式文本答案的意义，我们将对客户反馈进行情感分析，并查看这些情感标签是否能帮助我们提高预测模型的性能。我们将不再手动处理此工作流程，而是使用作为 Azure 订阅一部分的 Azure ML Designer。ML Designer 是一个无代码 AI 平台，允许我们尽可能少地在 Azure 云中构建和部署托管的 ML 工作流。

准备数据集

从书籍网站下载以下文件：

customers_factTable_Jan-May_2022.csv

关于 2022 年 1 月至 5 月间客户指标和流失标签的信息

survey_responses_Jan-May_2022.csv

来自 2022 年 1 月至 5 月期间的样本客户调查的客户反馈

customers_factTable_June_2022.csv

2022 年 6 月的当前客户事实数据

survey_responses_June_2022.csv

新的 2022 年 6 月调查数据

打开Microsoft Azure Machine Learning Studio，选择您喜欢的工作区，您应该看到您的仪表板（图 10-2）。

图 10-2. Azure Machine Learning Studio 仪表板

首先，我们将逐个将所有四个 CSV 文件作为数据集（数据资产）上传到 Azure ML Studio，以便稍后通过 ML Designer 访问它们。单击加号图标，选择“数据资产”或从左侧菜单中选择“数据”。

对于每个 CSV 文件，选择创建 → 从本地文件创建。按文件名提供数据集的名称，例如，对于文件customers_factTable_Jan-May_2022.csv，名称应为**customers_factTable_Jan-May_2022**。跟随表单，上传 CSV 文件，并检查数据预览是否一切正常。所有文件的分隔符应为逗号，编码为 UTF-8。在模式方面，您必须进行一些调整。

请确保客户事实表的模式如下（注意：6 月份的文件中不包含 Churn 和 OfferAccepted 列，因为这代表最新月份，而流失信息尚不可用，这是我们稍后要预测的）：

• customerID: String

• tenure: Integer

• 合同：String

• 月度费用：Decimal（小数点）

• Churn: 字符串

• 不包括：OfferAccepted

• 不包括：Month

对于两个调查文件，请确保列与以下架构匹配：

• id: 字符串

• text: 字符串

到最后，您应该在 ML Studio 中看到以下四个数据集：

• customers_factTable_Jan-May_2022

• survey_responses_Jan-May_2022

• customers_factTable_June_2022

• survey_responses_June_2022

分配计算资源

现在我们已经准备好数据，需要确保资源可用以进行实际计算。要添加计算资源，请在 ML Studio 左侧的菜单中选择 Compute，如 Figure 10-3 所示。

图 10-3. 在 Azure ML Studio 中添加计算资源

在这里，您应该仍然看到您在前几章中使用的计算资源。如果您看到资源，但尚未启动，请选择资源并点击“启动”。如果您还没有任何资源或之前删除了它，请点击“新建”，并创建一个带有默认设置和足够本案例研究的最便宜机器类型（STANDARD_DS1_V2）的新计算资源。一旦您至少有一个计算实例正在运行，您可以继续使用 ML Designer。

构建 ML 工作流程

从左侧菜单中选择 Designer（Figure 10-4）。ML Designer 将是我们拖放界面，用于构建 ML 管道。我们可以训练自己的模型，也可以进行基本的数据预处理和运行自定义脚本。

图 10-4. Azure ML Studio 中的 ML Designer

点击“新管道”创建您的第一个管道。现在您应该可以看到 ML Designer 的空白画布（图 10-5）(Figure 10-5)。ML Designer 有三个主要组件：左侧的库，您可以在其中切换数据资产和组件；右侧的画布用于构建管道；顶部的工具栏用于保存、编辑和提交整个管道。

图 10-5. Azure ML Designer 界面

在我们开始之前，将正在运行的计算实例分配给我们的会话。如果设置窗口没有自动弹出，请单击工具栏中管道名称旁边的齿轮图标访问它。说到管道名称，将管道标题更改为**Customer-Churn-Predictor**。

现在我们可以开始填充空白画布了。构建自定义工作流的想法是使用左侧预构建的模块，并将它们组合在画布上。每个模块都可以有输入和输出端口，并提供不同的设置。

从资产库中选择数据集 customers_factTable_Jan-May_2022，并将其拖放到画布上，如 Figure 10-6 所示。

图 10-6. 在画布上添加数据集

管道将从顶部到底部执行。因此，一切将从加载此数据集开始。如果愿意，可以通过右键点击模块并选择“预览数据”来预览数据。在开始时，特别是在熟悉界面时，通过在画布上预览单个模块的输出是一种直观的调试方式。

接下来，让我们对数据进行一些操作。我们的目标是构建一个简单的机器学习管道，根据输入特征预测流失列，类似于第 7 章中的 AutoML 用例。

通过点击相应的图标，从数据资产切换到库中的组件。搜索**select columns in dataset**。此模块的目的是去除我们预测不需要的列，例如 Customer ID。将模块拖动到数据集模块下方的画布上。如果它们自动弹出，请暂时关闭设置。将数据集模块的输出端口连接到选择数据集模块，如图 10-7 所示。

图 10-7. 添加选择数据集模块

在两个模块之间绘制连接允许元数据在我们的流水线中向下流动。这意味着我们的选择数据集模块现在将知道可用的列名。双击画布上的模块再次打开设置。点击“编辑列”并选择按名称选择列，如图 10-8 所示。

图 10-8. 过滤列

选择除了 CustomerID 列之外的所有列。点击保存进行确认。关闭模块设置窗格以为画布腾出更多空间。

接下来，我们要将数据分成训练集和测试集。在模块搜索栏中搜索**Split Data**，并将模块拖动到画布上。在模块设置中，定义以下拆分参数：

• 拆分模式：拆分行

• 第一个输出的行分数：0.75

• 随机拆分：True

• 随机种子：1234（用于可重现性）

• 分层拆分：True

• 分层键列：流失

使用这些设置，我们进行了分层的训练-测试拆分，其中数据的 75%用于训练，25%用于测试。分层意味着流失标签的类别分布在训练集和测试集中相同。

关闭设置，并连接选择数据集模块的输出端口到分割数据模块的输入端口。正如你在图 10-9 中所看到的，现在分割数据模块有两个输出，一个用于训练（左）和一个用于测试数据集（右）。

图 10-9. 添加一个分割数据组件

现在我们可以添加Train Model组件。在模块窗格中搜索该组件并将其拖放到画布上。您会发现该模块有两个输入：左侧期望训练算法，右侧期望训练数据集。将Split Data模块的左输出节点连接到Train Model模块的右输入端口。我们还需要告诉Train Model组件我们实际想要预测的列。因此，双击该组件以打开设置，并将 Churn 提供为标签列。

现在该由我们提供实际的训练算法了。与 AutoML 相比，我们必须自己选择训练算法。现在，这不是一本机器学习基础知识的书，但在大多数监督学习场景中，选择像决策森林或提升树等集成方法作为第一个基线，您将会获得相当不错的结果。这些模型尝试将几个弱学习器（例如决策树）结合成一个强学习算法，试图在训练数据集上最小化预测误差。这些模型适用于分类和回归问题，因此它们是非常全面的算法，尽管它们相对复杂。ML Designer 的好处在于您可以轻松尝试不同的、甚至更简单的算法，如线性或逻辑回归，并查看它们在数据集上的表现。

对于我们的练习，从模块窗格中搜索**Two-Class Boosted Decision Tree**并将其拖放到画布上。现在，我们可以将所有设置保留为默认值。将决策树模块连接到Train Model组件，您的流水线应该看起来像 Figure 10-10。

图 10-10. 添加决策树和 Train Model 组件

我们快要完成了！只剩下一件事，那就是添加一个组件，根据训练好的模型对实际预测进行评分并计算评估指标。

搜索Score Model组件并将其拖放到画布上。将Train Model组件的输出端口连接到Score Model组件的左输入端口。

然后将Split Data组件的右输出端口连接到Score Model组件的右输入端口。这将允许我们使用在训练数据集上训练的模型来计算测试数据集的预测值。最后，找到Evaluate Model模块，将其拖放到画布上，并将Score Model的输出端口连接到Evaluate Model组件的左输入端口。您的最终流水线现在应该看起来类似于 Figure 10-11。

图 10-11. ML Designer 中的第一个端到端工作流

恭喜！您刚刚从头开始构建了您的第一个 ML 流水线。单击提交按钮运行流水线。所有运行将被收集到实验中，这是我们从 AutoML 场景中习惯的。我建议为这个流水线创建一个新实验，以保持您的工作组织良好。创建一个新实验并提供一个有意义的名称，如**customer-churn-prediction-training**。点击提交并在 Azure ML Studio 在幕后做它的魔法时稍事休息。

要跟踪训练过程，请在屏幕左侧的“已提交作业”下单击“作业详情”。在这里，ML Designer 将指示当前正在运行的步骤以及已完成的步骤。请注意，您刚刚离开了 Designer 并切换到了作业部分，正如您从菜单中看到的那样。虽然 Designer 允许您创建流水线，但作业将允许您监视实际的流水线执行并触发最终部署。整个作业应该需要大约 10 到 15 分钟。

之所以这么长时间是因为 Azure 为每个模块单独启动了进程，这会产生一些开销。好处是，这种界面也适用于非常大的数据集，因为每个模块都独立于其他模块运行。这就是为什么在我们的案例中，与在您的本地笔记本上运行相比，运行 ML Designer 对一些相当小的数据集实际上会花费更长的时间。但数据集越大，您将看到的性能优势就越多。

当过程完成时，您应该在最后一个评估模块上看到完成徽章。在这种情况下，双击模块以查看评估结果。这应该会给您显示在图 10-12 中展示的输出。

图 10-12. 第一个工作流的评估指标

单击放大图标以腾出更多空间，整个界面应该看起来很熟悉，就像您在前几章中看到的那样。通过我们的初步运行，我们已经达到了 86.6%的准确率和 80.9%的 F1 分数。对于第一次尝试来说，这还不错，但让我们看看是否可以通过将训练数据集与更多数据混合来进一步提高这个度量指标。

到目前为止，我们所做的只是另一个无监督的 ML 工作流，我们本可以很容易地使用第七章中的 AutoML 服务来完成。事实上，如果只是这样的话，我会建议使用 AutoML 服务而不是 Azure ML Studio。然而，我们还没有完成，因为我们仍然希望插入来自非结构化数据（情感评分）的见解，并将它们合并到我们的最终模型中。这个工作流程仅依靠 AutoML 服务是不可能的，因此我们选择 ML Studio 来完成这项任务。

将情感数据添加到工作流程中

关闭评估指标并返回到设计界面。这次，我们想要增加对客户反馈的分析，看看这是否有助于改进我们的客户流失预测。我们的方法是在已有的管道旁边建立第二个管道，并将结果馈送到评估模型模块的正确输入端口。这将直接比较两种建模方法。

让我们一步步来解决这个问题。首先，从左侧模块窗格将customers_factTable_Jan-May_2022数据集模块拖放到画布上。此外，找到survey_responses_Jan-May_2022数据集模块，并将其拖放到另外两个数据集模块旁边。你的画布现在应该看起来像图 10-13。

图 10-13. 将更多数据源添加到 ML Designer

为了更熟悉调查数据，请右键单击该模块并选择“预览数据”。数据集仅包含两列，即客户 ID 和文本响应，这两个值来自原始客户调查结果。

到目前为止，我们的机器学习模型无法很好地处理原始文本输入作为预测特征。为了使它们更易访问，我们将从调查数据集中读取开放式文本答案，发送到 Azure 认知服务，并获取每个文本的情感值。分类“负面”或“正面”将成为我们分类模型的额外特征。为此，我们将使用在第 9 章中部署的 Azure 认知服务情感分析。

让我们将这个 AI 服务组件带到画布上吧！信不信由你，Azure 认知服务在 ML Designer 中没有预构建的模块可以直接拖放到画布上（至少在撰写本文时是这样）。但我们可以采取的方法是简单地添加一个可以运行 Python 或 R 代码的模块。这正是我们要采取的方法：我们将从调查中获取的响应，通过 Python 或 R 发送到远程 AI 服务 API，并将结果馈送回 ML Designer 管道中。

要开始，请搜索**执行 Python 脚本**或**执行 R 脚本**，取决于您的偏好。将其拖动到画布上。连接survey_responses数据集的输出端口到脚本模块的第一个输入端口。

脚本模块的工作方式是，它期望最多两个数据帧（表格），然后可以在名为azureml_main的函数中进行修改。结果将再次作为一个或两个数据帧返回。

底层的 Python 或 R 运行时附带了有限数量的包。要了解更多信息，请查阅微软文档 “在 Azure 机器学习设计师中运行 Python 代码” 或 “执行 R 脚本组件”。现在我们只需将预构建的演示代码替换为我们想要执行的任务的自定义代码。我将使用 Python 来示例说明，但是相同的步骤也适用于 R 脚本。

在文本编辑器中打开来自书籍网站的 ml-designer.py（ml-designer.R）。用您的自定义参数替换密钥和端点，如第九章所示。现在选择所有脚本并复制它。将 Execute Python Script 模块中的所有示例代码替换为剪贴板内容。脚本模块现在应仅包含来自 ml-designer.py 文件的代码，而不包括其他内容（见图 10-14）。

图 10-14. Azure ML 设计师中的 Python 脚本模块

该代码基本上会将 dataframe 作为输入读取并将其整理成 API 服务可以处理的格式。它将返回附有情感预测的原始 dataframe。现在，单击提交以运行新的图形。转到作业并验证一切是否如预期运行。

请注意，我们之前在图的左侧运行的所有步骤不会重新执行，因为我们在这里没有做任何更改。相反，此运行将仅读取新数据集并将其馈送到脚本模块中。几分钟后，您应该会看到脚本成功执行。如果出现错误，请单击脚本模块并查看日志文件。那里的错误消息将帮助您调试，例如，如果您的资源密钥无效或您的免费配额已超过。

当运行完成后，右键点击已提交的训练作业中的脚本模块，选择预览数据 → 结果数据集。如图所示图 10-15，您应该可以看到现在每个客户反馈条目已经获得了情感标签。

图 10-15. Azure ML 设计师中的情感分析结果

我们的目标是将此信息添加到用于训练客户流失模型的主数据集中。我们需要将此表连接到主表中，而不会丢失主表中的任何记录；请记住，这次调查并不是针对所有客户进行的，而是针对样本进行的。这种数据连接称为左外连接；左表是我们的主数据集，右表是我们希望连接其他信息的数据集。返回到设计师并在资产库中搜索 **Join Data**，找到相应的组件。

将连接数据模块拖动到画布上。将前一个脚本模块的第一个输出端口连接到连接数据模块的右输入端口。然后将 customers_factTable_Jan-May_2022 的输出端口（我们尚未使用的那个）连接到连接数据模块的左输入端口。在画布上双击连接数据模块以打开其设置。我们必须定义将两个数据集合并的关键列。您可以通过点击左右数据集的“编辑列”来编辑关键列。对于左侧数据集，选择列 customerID，对于右侧数据集，选择列 “id”。将连接类型设置为左外连接，并将 “在连接表中保留右侧键列” 设置为 False。您的设置最终应与图 10-16 中的设置相似。

图 10-16. 从不同来源连接数据

点击提交以运行流水线，验证连接是否按预期工作。您合并后的数据集应该有七列和 3,814 行，您可以右键单击连接数据模块并选择“预览数据”→“运行完成后的结果数据集”来验证。

我们现在基本上必须像之前一样重新创建其余的流水线。我不会详细介绍这些步骤，因为这些都是重复的。简单来说，添加以下模块并应用以下设置：

选择数据集中的列

按规则选择列：包括所有列，除了 “customerID”，包括列名 “sentiment”，并排除列名 “text”。

分割数据

在列 Churn 上进行与之前相同的 0.75 分层样本。

训练模型

标签列是 Churn。

二类增强决策树

保持默认设置。

评分模型

将 Score Model 组件的最后一个输出端口连接到我们之前创建的 Evaluate Model 组件的右输入端口。

最终的流水线显示在图 10-17 中。

图 10-17. 第二个端到端工作流

点击提交以运行整个图形。如果您认为现在是喝咖啡的时候，那您是对的！整个过程可能需要几分钟。当流程完成后，请回来查看结果。

当运行完成后，让我们检查评估模块，看看是否可以改进模型性能。转到作业并选择您完成的训练作业。右键单击评估模块，选择“预览数据”→“评估结果”。图 10-18 显示了输出。

图 10-18. 第二工作流的评估指标

从评估指标中，我们可以看到准确率提高了另一个百分点，达到了 87.7%，而 F1 分数增加到了 82.6%。虽然不是突破性的，但考虑到情感标签仅为数据的一小部分提供了这一点，这仍然是一个可靠的性能提升。这意味着情感信息本身对于我们的用例具有非常高的预测能力。因此，最好保留这些信息在我们的数据集中，并在可能的情况下使用它。

如果我们想进一步提高准确率，我们可以尝试在更多数据（行）上进行训练，使用不同的算法，或尝试更多特征（列）以获得更好的结果。对于什么准确率值是足够的，没有通用的规则，因为这取决于您的用例。但一般来说，拥有现有基线（如第 7 章）可以给您一个良好的基准，因为您的 ML 模型应该能够显著超越该基线。否则，所有额外的努力都不值得。

现在，我们的模型训练完成了。恭喜！您刚刚将一个即开即用的 AI 服务与先进的 ML 算法结合起来，自己打造了一个强大的定制 AI 模型！现在是时候让这个模型投入工作，并准备好进行推断了。

在我们继续之前，让我们通过选择左侧的所有部分并删除它们来整理我们的图形。在设计师中，打开你的工作流，并从顶部菜单栏点击克隆以创建图形的副本。

要选择多个模块，请从工具栏中选择选择工具，并选择图左侧所有组件，如图 10-19 所示。右键单击选择内容，然后选择删除。

图 10-19. 选择画布上的多个组件

最后，通过选择连接 Score Model 模块与 Evaluate Model 模块第一个输入端口之间的现有连接，删除它，并重新连接到第一个输入端口，重新提交训练流水线最后一次；这将很快，因为它仅重新计算最后一个模块的结果。

部署推断工作流

现在我们可以将这个图形部署为一个推断流水线。我们只需要进入作业，打开最新的实验，并从顶部菜单中选择“创建推断流水线”，然后选择“批处理推断流水线” (图 10-20)。

图 10-20. 创建批处理推断流水线

在这种情况下，在线推断管道和批处理推断管道的主要区别在于批处理管道将 Blob 数据集作为输入，而在线管道则通过在线 API 提交数据。

无论如何，训练管道都将被转换为推断管道，我将其重命名为“客户流失预测器批量推断”，如图 10-21 所示。

图 10-21. 批量推断管道（原始）

训练和推断管道的主要区别在于推断管道不包含任何训练组件。请注意，“提升决策树”模型和“训练模型”模块已被一个名为“MD-客户流失预测器-Train_Model_Trained_model”的新模块替换，如图 10-21 所示。此模块将自动引用我们训练过的模型，以便我们可以用于推断。数据准备管道的其余部分，包括我们的 Python 脚本，将保持不变。

要对新数据运行推断，请分别用customers_factTable_June_2022和survey_responses_June_2022替换输入数据集。这两个数据集代表了客户的新数据；我们还不知道他们是否会流失。要替换数据集，只需从画布中删除现有数据集，并从资产库中拉取新数据集。您的画布应该看起来像图 10-22。

图 10-22. 批量推断管道（新数据）

在我们可以进行推断之前，我们仍然需要进行一些小调整。在画布上找到数据集中的“选择列”模块。它仍然包含我们用于训练的“流失”列。但是在推断阶段我们不会有这一列（这就是我们要预测的列！）。因此，请编辑设置并从模块中删除“流失”列。同时保留“customerID”列，因为稍后我们需要用它来将流失预测与客户记录匹配。双重检查，“sentiment”列是否仍然包含在内。

如果您跳到管道的末尾，您仍然会看到“评估模型”模块作为最后一个组件。但是在这个阶段我们不需要这个组件，因为我们没有任何地面真相可供比较。相反，我们希望将得分数据导出到某个位置。为此，请从画布中删除“评估模型”组件，并从资产库中拖动“导出数据”组件到画布上。

在“导出数据”模块设置中，选择 Azure Blob Storage 作为数据存储类型。对于数据存储，点击“新数据存储”并给它取一个名称，比如**churn_⁠m⁠o⁠d⁠e⁠l⁠_​s⁠c⁠o⁠r⁠i⁠n⁠g**。对于存储账户，选择您在之前章节中使用的存储账户，并在“Blob container”下选择“tables”。您的设置应该看起来与图 10-23 类似。

图 10-23. 创建新的数据存储

向下滚动并将您的 Azure 存储帐户资源中的帐户密钥粘贴到此设置窗口中的相应字段。单击“创建”，您应该会发现自己回到导出数据设置中。仔细检查您新创建的数据存储是否已选择，并在路径字段中将输出文件命名为**churn_predictions_June_2022.csv**。最后，将文件格式设置为 CSV。 Figure 10-24 显示了导出设置的示例。

图 10-24. 添加导出数据模块和设置

最后，将评分模型模块连接到导出数据模块。最终管道显示在 Figure 10-25 中。

现在，单击“提交”以运行您的推理管道。为了保持组织良好，创建一个新的实验，比如**customer-churn-inference**，将您的推理运行与培训运行分开。推理运行将花费几分钟时间。再次强调，我们在这里使用的是相对较小的数据样本，但这个过程本身在处理非常大的数据集时表现良好，而且时间成本并不成比例增加。

图 10-25. 最终推理管道

一旦推理运行完成，您应该会在存储容器中的“tables”文件夹中看到名为 churn_predictions_June_2022.csv 的新文件（Figure 10-26）。

图 10-26. Azure Blob Storage 中的表输出

现在是时候转向我们的 BI 了！

在 Power BI 中构建 AI 动力仪表板

现在我们已经构建了预测模型，并将非结构化文本转化为易于分析的分类数据，让我们通过构建一个 AI 动力客户仪表板将所有内容整合起来。

请记住，我们的目标是为营销和销售构建一个仪表板，提供客户流失发展的高级概述，如果事情“仍然正常”，以及采取有效对策的情况。该仪表板还应提供进一步的功能，以深入了解定制洞察。与之前的章节不同，我不会详细说明如何构建仪表板的逐步说明，而是专注于此处运作的主要概念和不同组件。

您可以从 book’s website 下载 Customer_Analytics_AI-Powered.pbix 或自行重新创建。我使用了之前概述的步骤。

注意

想要了解如何构建仪表板的逐步视频教程，请访问 https://www.aipoweredbi.com/chapter-10。

为了构建我们的客户仪表板，我们需要 Figure 10-27 中的数据模型，该模型基于以下四个表：

churn_predictions_June_2022

这个表格包括我们从 ML Designer 获得的得分流失数据集。

customer_dimensions_June_2022

此表还包含有关客户的进一步 BI 数据，例如服务时间、服务和人口统计信息。它与表 churn_predictions_June_2022 具有一对一的关系，基于客户 ID 字段。

Churn_Metrics_2021

一个表格，包括以往几个月每月的聚合流失率和接受优惠率。这些数据可能来自 SQL 数据仓库；在我们这里，它作为一个 CSV 文件存储在 Azure Blob 存储中提供。

Aggregated_metrics_2022

此表由 Power BI 生成，通过获取数据集 churn_metrics_2021 并添加 2022 年 6 月的预测流失率生成。它将获取这个时间序列，并发送至 Azure 异常检测以推断出该指标的期望下限和上限，并设置检测到的异常标志。

图 10-27. Power BI 中的数据模型

利用这些数据，我们可以生成一个看起来像图 10-28 的仪表板。

图 10-28. 最终仪表板的组件

让我们分解各个组件。

异常检测

在仪表板的左上角，有两个线图显示了每月的流失率和接受优惠率。您可以在图 10-29 中看到仪表板的这一部分。虽然线图本身只代表基本的描述性分析（“发生了什么？”），但我们在这里通过混合另外两种信息来丰富图表。

首先，我们展示了一个浅灰色线来表示根据迄今为止所见数据的相应指标的预期值。其次，我们突出显示显示异常正向高峰点的数据点（无论是流失率过高还是接受优惠率过高）。这些异常由方形数据标记表示。通过这些额外信息，我们可以看到整体的流失趋势似乎是负向的（这是好的！），同时我们并没有真正观察到任何明显的异常值，尽管线看起来相当曲折。对于优惠，我们可以明显观察到上个月高峰被检测为异常，但之前也有一些数据点。因此，整体趋势似乎相当稳定，除了一些异常值。所有这些信息都来自我们直接从 Power BI 调用的异常检测 AI 服务的数据。

图 10-29. 每月流失率和接受优惠率指标

预测分析

仪表板的预测分析部分结合了历史信息和 AI 预测。图 10-30 展示了这一可视化效果。其中包括了当前月份预测的客户流失率，以及这对收入风险的影响。当前月份预测的客户流失率是我们基于 ML Designer 中使用的模型的个别 AI 预测计算出的摘要指标。我们可以将这一指标与目标进行比较，本例中定义为 0.33 的流失率——这个标准可能在当前月份得到满足。

为了使业务用户更易于理解这些信息，我们将此指标与称为“风险收入”的圆环图表结合在一起，总结了本月从标有 churn flag = 1 的客户处获得的所有收入。请注意，这一指标相当简单化，因为它没有考虑客户的生命周期价值。如果我们希望，可以添加这些信息，但出于演示的目的，我决定坚持基础内容。核心思想在于，我们可以将 AI 预测与历史或交易型 BI 数据相结合，使预测对业务更加相关。我们将在下一个组件中看到另一个更详细的示例。

图 10-30. 流失预测 KPI 指标

AI 驱动的描述性分析

在仪表板的 AI 驱动的描述性分析部分，AI 的工作是最无缝的，但可能也是对用户最直观的。这项分析的 AI 驱动部分包括两个图表，显示在图 10-31 中。上部分是一个问答工具，下部分是一个表格可视化。

首先让我们探索问答工具。此工具将流失评分与 BI 数据结合，允许查询诸如“在 xyz 细分中的平均预测流失率是多少？”这样的问题。此可视化可用于针对我们的数据模型运行自然语言查询。由于预测流失结果与数据仓库中的维度 BI 数据之间的关系，用户可以无缝地将 AI 驱动的预测与客户的附加属性相结合。如示例所示，用户可以查询“每种互联网服务的平均流失率”，并看到光纤的流失率比其他互联网服务类别要高得多。我们唯一需要做的设置是在问答工具中定义同义词，以便将“平均流失率”与源数据表中称为“评分标签”的数据字段匹配起来。

图 10-31. 描述性分析组件

描述性分析组件的下部是一个表格，利用历史 BI 数据和 AI 预测的组合。用户可以通过将流失预测与当前收入结合来计算风险收入。为此，该表格使用了一个名为“收入风险”的新字段，这个字段在 Power BI 中作为快速度量生成，通过将客户的月度收入乘以其个体流失概率来计算。如果我们现在在各种客户类别上累加这些值，我们可以轻松地发现将会损失大量资金的客户细分，使总体流失数字对销售和营销更具操作性。如果我们看一下图 10-31，我们可以清楚地看到，使用光纤互联网服务的月租合同客户且没有多条线路的客户群体，为捍卫收入提供了最大的杠杆效应，每月的收入风险为$8,754。如果营销部门考虑个性化的反流失优惠，这将是一个有趣的类别进一步探索。

非结构化数据

最后，在仪表板的非结构化数据区域，结合维度数据，可以提供更多有关情感分数的见解。非结构化数据的情感分析最终成为我们流失预测模型的一部分，但它也可以独立提供更深入的见解。

Treemap 视觉化，显示在图 10-32，将情感标签与我们想要的任何客户维度进行对比——在本例中为合同类型。从这个视觉化中，我们可以看到，尽管大多数客户对他们的调查评论的情感感到满意，但提供负面反馈的大多数客户都是月度计划用户。考虑到这一类客户的高流失可能性，应首先优先处理这一类别中出现的根本问题。

图 10-32. 情感分析

如果我们把所有内容汇总，并查看仪表板本身（图 10-33），我们可以为市场营销和销售人员提供一个以客户为中心的仪表板，它在幕后使用 AI，并非为了炫耀，而是有一个目标：使数据对业务利益相关者更具操作性和更有意义。

你可以尝试自己操作，通过在计算机上打开配套的 Power BI 文件并与其中的组件互动。您会添加、更改或完全删除哪些信息？

图 10-33. 最终仪表板

清理资源

当您完成了本书中的使用案例后，我建议删除所有使用的资源，以避免在 Microsoft Azure 上产生持续的成本。要一次性删除所有资源，请访问 Azure 门户 并选择“资源组”。选择您为本书创建的资源组，然后选择“删除资源组”。确认资源组名称，然后单击删除。

概要

希望本章能够向您展示，在您的商业智能中使用 AI 服务并不是非此即彼的选择。事实上，最大的好处来自于结合多个 AI 服务。但是，不要让技术把您拖入兔子洞，使得商业智能功能因工作中的 AI 组件而过载。请记住，每个添加的 AI 服务都会增加一层技术债务：最终必须有人来管理模型、问答工具、数据集成等。

然而，将各种 AI 服务整合在一起，是验证业务是否从进一步洞察中获益，或明确业务正在寻找的内容的一种很好的方式。通过您灵活的分析堆栈，从访问非结构化数据、到描述性分析，再到规范性分析，都能在同一平台内实现，您将能够找到增加技术复杂性与提供实际业务价值之间的最佳平衡点。

恭喜您成功构建了第一个原型，其中包含不少于四个 AI 服务！接下来呢？如前所述，这只是一个原型，离能够将此仪表板部署到生产环境还有很长的路要走。在下一章中，您将了解更多关于从原型到生产的过程及如何处理随之而来的复杂性。

第十一章：迈出下一步：从原型到生产

如果您已经走到这一步，并且跟随了示例和案例研究，那么您应该已经掌握了主要 AI/ML 技术及其在各种 BI 场景中的应用的扎实知识。祝贺您！这确实是一个伟大的成就，并使您处于一个极好的位置，可以成功启动自己的 AI 用例。

在本章中，我们最终将讨论一些关键点，即将原型解决方案（这就是我们迄今所做的）推向生产。相反，我们还将讨论为什么将原型推向生产实际上可能不是一个好主意。为了解决这一明显的矛盾，我们需要看两个概念，这两个概念最初是从产品管理中借来的：产品发现和交付。

通过本章的最后，如果您的目标是在整个组织中推出您的 AI 解决方案，您应该对接下来应该采取的步骤有直觉。

发现与交付

到目前为止，我们讨论过的实际用例都是原型。你已经完成了产品经理所说的发现过程。发现过程是关于验证产品（或用例）的价值、可用性、可行性或可行性的过程。

值得注意的是，大多数原型不太可能在发现阶段存活下来。这就是游戏的本质：你希望快速学习并快速失败。这没问题。到目前为止，您不应该投入太多资源，并且理想情况下，您的待办事项中还有其他想法可以追求。

但是，如果您的原型通过了验证阶段会发生什么？如果它脱颖而出呢？

假设您的早期 BI 测试用户喜欢新功能或模型预测。每个人都对您的新解决方案感到兴奋，有些人甚至可能在公司内传播有关它的消息。如何将您的原型扩展到生产规模？

简单的答案是：您根本不应该扩展它。在我们的原型示例中，我们自己完成了所有工作：我们为计算作业创建了虚拟机，我们管理了存储的访问密钥，甚至为我们的容器设置了安全策略。您可能已经猜到：这不是您在生产场景中应该做的事情。Azure 云平台（以及所有其他平台）在一些培训后看起来非常直观和易于使用。但实际上，它们是超级复杂的景观，需要专业知识来安全有效地管理和控制。否则，您面临数据泄露或资源账单激增的风险，或两者兼而有之。

如果一个原型被证明成功，并通过了影响和可行性测试，那么是时候放手并进入不同阶段了：交付。在企业组织中，交付远不止于创建代码和仪表板的“干净”版本。当您进行交付时，您应该优先考虑以下几个方面：

• 可伸缩性

• 可靠性

• 性能

• 可维护性

此外，原型通常由于在开发阶段未经适当测试而存在多个安全漏洞。因此，你不应立即将原型投入生产，而是应该重新思考这些维度。让我们简要梳理一下这些概念。

可伸缩性 指的是使你的解决方案对更多用户可用的技术和非技术挑战。从技术上讲，它关乎多少用户可以同时访问解决方案的上限，这受限于你的基础设施。在非技术层面上，你希望弄清楚流程如何阻碍应用程序的部署。例如，如果每个用户都需要手动设置仪表板，则你的解决方案的最大规模将受到可以分配给它的人数的限制。如果自动部署仪表板或使用专用 BI 服务器，则可以以更大的规模运行解决方案。

可靠性 意味着你的解决方案能够如预期般正常工作。当发生故障时，能否轻松修复并且几乎没有停机时间？迟早你将需要回应用户的查询，并通常提供在线帮助。这些问题可以多快解决？

性能 是指你的应用程序响应用户请求的速度。随着用户数量的增加，这成为一个重要因素。第一印象至关重要，加载缓慢的应用程序或交互迟钝会阻碍增长。毕竟，你希望用户能尽可能快地完成任务，而不会遇到延迟。

可维护性 是指在解决方案上线后进行更改的容易程度。能否无需程序员即可添加或更改功能？你的代码是否有适当的文档，以确保新用户在使用时不会出现意外错误？

你的生产应用程序应从一开始就具备可伸缩性、可靠性、性能和可维护性。实际优先级取决于你的业务需求。如果你希望为许多用户提供解决方案，可伸缩性就非常重要。另一方面，如果企业应用程序仅设计为一定数量的用户，可以降低可伸缩性目标，并在交付项目中记录这一约束。

无论哪种方式，在大多数情况下，你的原型堆栈都不符合这些交付原则，因为你为了速度和开发者的方便而牺牲了它们。这就是为什么你不应该尝试扩展一个原型，而应该逐步正确地重建它。

AI 产品交付的成功标准

那么，如何从发现阶段成功过渡到交付阶段？在 BI 的 AI 产品背景下开发成功的企业产品，你需要考虑五个维度：人、流程、数据、技术和 MLOps，如图 Figure 11-1 所示。

图 11-1. 在 BI 环境中 AI 产品交付的成功标准

让我们更详细地讨论五个维度。

人员

人决定了您的 AI 产品的成功或失败。在发现阶段，您的团队可能不会超过“两块比萨饼”规则，即项目团队的所有成员都可以通过两块大比萨饼饱腹。通常最多不超过 10 人。

一旦您开始以企业场景为目标，情况将会改变。企业 AI 项目本质上是企业软件项目。与两块比萨饼不同，您可能需要订购一个大型自助餐，因为可能会涉及各种人员参与新软件开发项目。这些可能包括但不限于：

• IT 安全

• IT 应用管理

• IT 基础设施管理

• 数据治理办公室

• 各部门的业务领导者

• 文档人员

• 工作委员会

• 律师

注意

在扩展您的 AI 工作时，根据需要请咨询您的 IT 部门或外部专家。您将需要大量的支持，特别是在开始阶段，以避免严重的错误。请记住，在这个阶段，您的原型已经证明了实际结果，您应该有信心与他人讨论它。

您需要包含的各种职能部门非常依赖于公司的组织方式和规模。这些人通常与您需要遵循的流程框架紧密相关。虽然我无法为您列出完整的人员名单，但通常组织利益相关者为一个矩阵是有用的，该矩阵将人们映射到两个广泛维度上：对项目的权力和对工作的兴趣，如图 11-2 所示。

图 11-2. 利益相关者矩阵

目标是确定每个类别中的利益相关者，以确定与他们沟通的正确策略。这四个利益相关者类别需要四种沟通策略：密切管理、保持满意、保持知情和监控：

密切管理。

这个类别包括对您的项目具有很大权力和高度兴趣的人。这些是您最重要的利益相关者。您需要经常与他们交流，早期识别关注点，并积极参与以确保他们对项目保持一致，并管理他们的期望。

例子：赞助商、高级管理层、董事、项目/产品经理

保持满意。

这些人拥有很大的权力，但对您的项目兴趣不大。他们通常不引人注目，但却很重要，因为他们有权力决定项目是否应继续，这取决于当前的结果或进展。

例子：项目管理、财务规划

保持知情。

在您的项目中具有很大兴趣但权力有限的人需要定期保持信息沟通。这些通常是最终将使用正在构建的内容的人。即使他们的正式权力较小，您也应经常与他们沟通。他们参与程度如此之深，很可能会影响其他（更有权势的）利益相关者。

终端用户、客户

监控

对您的项目兴趣不大但权力也不大的人。这些人可能对您来说不是优先考虑的对象，您也不希望过多打扰他们。然而，他们仍然需要不时监测和通知，即使他们不太可能引起重大问题。

例如：来自其他部门的员工

一旦您开始将人员分类到这些类别中，您应该对项目的复杂性有所感觉，并确定随着您的计划发展，与他们沟通的正确策略。

流程

由于 AI 项目本质上是软件项目，因此您需要注意公司中管理软件工件开发过程的框架和流程。根据您的组织，可能会有各种规则，并列出所有这些规则超出了本书的范围。但是，如果您通常不熟悉软件项目处理方式，我将为您提供一些关键术语，以查看它们是否适用于您的组织：

ISO/IEC

ISO/IEC 25000 系列标准也被称为系统和软件质量要求及评估（SQuaRE）。这些标准旨在为评估软件产品的质量提供框架。如果您的组织使用 ISO 认证标准，您的项目可能会受到这些规则的约束，需要相应地设置。

Scrum

Scrum 是一种由公司用于敏捷软件开发的软件开发框架。虽然目标是实现轻量级迭代开发过程，但它带来了相对严格的开销和固定角色（例如产品负责人和 Scrum 主管）。请检查您的组织中是否存在 Scrum，因为这将定义项目结构。

业务流程管理（BPM）

业务流程管理通常用于大型组织中管理关键业务流程及其各自的所有者。BPM 也用于软件开发，您可能需要相应地记录您的项目。

项目管理办公室（PMO）

项目管理办公室是一个内部部门，负责制定和维护公司特定的项目标准。根据您的项目规模和公司运作方式的大小，您至少必须遵守 PMO 规则，并有时甚至定期向该办公室报告。

一旦您的原型有机会进入交付阶段，我强烈建议您联系 IT/DevOps 部门（如果在原型设计期间尚未这样做）以确保您的项目设置符合软件开发项目所需的所有正式要求。

数据

现在，您应该对 AI 项目中的数据非常熟悉了。在原型设计阶段，您应该已经能够识别出最大的数据陷阱，如果您成功交付，那么您肯定找到了克服它们的方法。剩下的问题只有以下几个：您所采取的方法在生产环境中是否有效？它们是否安全可靠？它们是否可扩展？还有其他需要考虑的事项吗？

作为 BI 的从业者，您应该对您组织内可以操作的杠杆以及需求或限制有坚实的了解。以下是您应特别关注的一些领域：

数据管道

还记得我们如何在第七章中手动上传 CSV 文件到 Azure ML Studio，并将结果存储在 Azure Blob Storage 中吗？很可能，在生产场景中，这种方法不会奏效，因为有太多东西可能会出错。理想情况下，您应该从数据仓库中提取数据，并按一致的架构存储导出数据，使得生产应用程序可以直接访问它们——这甚至可以是 Azure Blob Storage。

数据清洗和管理

一旦您自动化了数据管道并创建了实际的 ETL 脚本，您需要确保它们既易于维护又可以自动化（您将无法进行手动数据清洗）。根据项目的规模大小，仅这个数据清洗部分就可能成为整个项目的重大障碍。

数据访问

我希望本书中的用例向您展示了在开发过程的各个阶段轻松访问和共享数据的重要性。如果您将所有数据存储在集中式云数据仓库中，访问它将“只是”访问权限的问题，而不是技术障碍。我知道许多公司仍在努力打破其数据孤岛，改善业务单元间的共享。理想情况下，您的原型用例已经清楚地展示了使数据易于访问并通过几个简单的脚本连接应用程序到这些数据源的好处。将数据仓库托管在云中可能存在其缺点，但在快速灵活的开发方面，这绝对是一个巨大的优势。

数据保护

当您进入生产阶段并服务更多用户时，请考虑您的数据是否受到与原型数据不同的其他约束。例如，在原型设计中，您可能使用了来自美国的客户数据，并在 Microsoft Azure 中使用了该数据。在生产环境中，您的用户也可能位于欧盟，如果数据包含个人信息，则需要特殊许可来处理这些数据。将数据存储在欧盟以外对这些用户组也可能很快成为问题。如果您已经建立了数据治理框架，请尽早（最好在原型设计阶段）让您的数据治理团队参与，以便及早识别主要障碍。

技术

在 99%的情况下，您用于原型设计的技术堆栈将不会是您在生产中使用的技术堆栈。如果确实如此，恭喜您——您已经理解了数字转型的真正含义。通常不会常见使用相同的基础设施来进行快速原型设计、测试新功能以及扩展生产工作负载。

原因是生产系统被优化为可扩展、可靠、可维护、高性能和安全。正如您所了解的，当进行原型设计时，通常会为了更快速和更灵活的开发而牺牲这些目标。

如果您想要交付一个新的软件应用程序，甚至是现有（BI）系统中的一个单独功能，您应该根据测试环境的要求来指导自己。测试阶段通常会与生产环境相似，并且是交付可用于测试的内容的第一个里程碑。

此时你需要问自己的最重要的问题是，我需要重新创建原型的哪些部分才能将其交付到测试环境，并且哪些部分可以重复使用？

对于这些问题的答案可能处于两个极端之间。首先，您不需要重建任何内容，因为原型堆栈与测试堆栈相同。在这种情况下，您只需要专注于实际改进并确保您构建的内容符合生产环境在可扩展性、可靠性、可维护性、性能和安全性方面的标准。在另一个极端，您基本上需要重建所有内容。

在大多数情况下，您会发现自己处于这两个极端之间，并且需要确定哪些组件可以重复使用。剩下的部分将需要重新构建，并且将决定您的开发团队和预算的规模。您的产品变得越复杂，开发和维护的成本就会越高。

基于我们在本书中探讨的用例，以下是一些我们在原型设计中使用过的组件，您可能甚至可以在生产中重复使用：

模型端点 APIs

我们使用 Azure ML Studio 实施的模型通常满足生产工作负载的所有要求。请查看“MLOps”了解生产中的 ML 模型标准。但基础设施本身将是兼容的。

用户界面和报告

如果您在现有的报告环境中使用 Power BI，您可能可以重用我们在练习中创建的报告布局和仪表板。您将它们交付给用户的方式可能会有所不同（例如使用 Power BI 服务器），但外观和感觉将保持不变，因此您不需要重新创建这些内容。

数据管道

我们在本书中使用 Azure ML Studio 的数据集来训练我们的模型。只要保持架构不变，您应该能够通过从文件或 Azure 中的其他资源导入数据，相当快速地整合新数据。只要您能通过相同的模式将数据管理到数据集中，Azure ML Studio 内的数据准备流程仍然保持不变。

文档

理想情况下，您已经利用原型阶段对整体开发过程做了一些笔记。这可以是非技术文档，回答诸如“您解决了什么问题？”、“您采取了什么方法？”、“您涉及了哪些人？”等问题，以及更多技术文档（数据架构、API 文档、Power BI 数据模型）。您可能可以重用这些组件，或至少将它们作为将原型项目移入交付阶段的起点。

尽量重用尽可能多的内容，并适当重建其余内容。

MLOps

在生产系统中管理和操作 ML 模型的过程通常被称为MLOps。这是将严肃对待数据科学的公司与仅仅雇佣数据科学家“构建预测模型”的公司区分开来的关键。我们在疫情期间已经看到了 MLOps 的重要性：突然间，ML 模型在生产中消耗的数据看起来与训练过程中看到的数据大不相同。这导致了许多行业中的 ML 模型崩溃或表现明显下降。除非您的公司至少有一个基本的 MLOps 流程，否则您可能不会注意到模型性能不佳，直到为时已晚（例如，您的库存已经耗尽，但您的 ML 模型仍然预测您的供应链正常）。

最少需要 MLOps 的充足 API 文档和部署后模型的维护人员。在最佳情况下，MLOps 覆盖了整个 ML 解决方案的生命周期：从数据获取到版本控制、实验、性能监控和端点管理，再到模型废弃。

因此，ML 模型可以被视为一个独立的端到端软件项目，并应相应地进行管理。这就是为什么在 MLOps 中会找到一些与整体解决方案中应用的相同概念的原因。

以下领域是 MLOps 最重要的成功因素之一：

人员

说实话，如果你没有人定期监控模型并负责其维护，那么最好不要实施任何 ML 模型。实施后可能会发生很多事情。最常见的现象是数据漂移：模型在生产中看到的数据与训练时看到的数据越来越不同，导致随着时间推移预测变得不太准确和可靠。虽然工具可以帮助自动化这一过程，但最终还是需要人类决定是否需要重新训练新模型以及用于训练的数据。除了模型性能，调试也是一个重要组成部分。如果模型产生错误或其他问题出现，谁应该负责修复这些问题？

自动化

MLOps 的主要目标之一是尽可能自动化整个过程。如果您不能轻松地重现分析或模型训练，您的团队可能无法快速迭代新模型以提供价值。因此，自动化流水线被认为是 MLOps 中最重要的方面之一，特别是如果您在生产中运行超过一两个模型。

可靠性和可重用性

如果您的组织正在扩展 ML 模型的使用，重要的是确立一个可靠的标准流程来创建这些模型，并且每次操作都能轻松验证其正确运行。如果未能做到这一点，创建新模型或对现有模型进行后续更改的成本可能会超过 ML 模型的价值。您还需要确保团队内部发生变化时能够进行平稳过渡，并且新同事能够快速接手。

安全性

重要的是，您的 MLOps 团队理解正在处理的数据及其适用的治理规则。在某些情况下，这些数据包括可能不得离开某些地理区域、可能不对所有个人开放或可能受隐私法规限制使用的敏感用户信息。MLOps 还确保通过适当的身份和访问管理（IAM）规则和技术安排管理所有数据和基础设施资源。

可扩展性

跟上不断增长的 ML 资源占用是 MLOps 的另一个主要关注点。避免这种情况的最佳方法之一是能够根据需要扩展基础设施，无论是在训练期间还是推断期间。一方面，您希望避免通过未提供足够或正确的基础设施来限制 ML 训练进度。另一方面，您不希望为每隔几个月运行一次的 ML 作业保留大型计算机集群。

专用 ML 平台如 Azure ML Studio 将帮助您解决 MLOps 处理的一些问题。但是，最终，您的组织需要一个处理过程和人员框架来管理这些方面。在将自定义 ML 服务移入生产环境之前，请务必考虑这些问题。尽管在这种情况下，这些领域中的一些也适用于 AI 服务，但通常情况下，您通常有一个供应商将负责大部分事务或根据您的需求提供支持。

通过交付完整增量来开始

我知道，AI 产品交付的成功标准听起来很多。我不想美化任何事情；交付阶段确实很多！这就是为什么您不应该通过一次大的跃迁从发现阶段跳到交付阶段（或从原型设计跳到生产阶段）。相反，请花时间制定完整增量的交付计划，请求资源，并制定交付的路线图。

您的增量路线图可能如下所示：

1. 组建团队和赞助者。

2. 让利益相关者加入。

3. 获得项目计划批准。

4. 构建数据管道。

5. 构建模型。

6. 集成模型。

7. 构建用户报告。

8. 彻底测试所有内容。

9. 部署到生产系统。

10. 再次根据用户反馈进行迭代。

在转移到下一个阶段之前一定要完成每个增量。交付单一完整的增量将使您保持灵活性，同时还能够在路上庆祝小的胜利。

结论

您做到了！希望本书让您对 AI 世界和如何在 BI 中使用它有所了解。在本章中，我们探讨了几个使用案例，让您对 ML 应用程序的许多可能性有所了解。借助本书的帮助，您现在应该已经在开发自己的 AI 驱动的 BI 应用程序的道路上有了良好的进展。

那么，您学到了什么？以下是我们讨论过的一些概念：

• 如何找到具有业务影响的使用案例

• 如何评估 AI 项目的可行性

• 关于 ML 的基本知识

• 如何在产品发现中使用原型设计以及在 AI 原型设计环境中使用哪些工具

• AI 如何改进 BI 结果的实际应用案例

• 如何进入下一阶段，将您的项目从原型转入生产

我希望本书中的使用案例引起了您对 AI 如何在数据收集、描述性、诊断性、预测性或指导性分析方面改善业务结果的兴趣。如果是这样，请不要止步于此。下一步是利用 AI 技术构建您自己的 BI 应用程序。

世界正在以迅猛的速度变化，但是通过这本书中的信息，你将能够独自航行这个领域。如果你有反馈、问题或关于 AI 驱动的商业智能原型的想法，你可以随时通过LinkedIn或书籍网站与我联系！祝愿你在未来的 AI 之旅中一切顺利，并希望你能启动许多成功的项目。