AI和机器学习历程经验教训总结

从我的AI /机器学习历程中学到的教训

我最近有幸与几位AI /机器学习专家一起参加了小组讨论。 有很多伟大的问题，但大多数与如何在大型组织中最有效地建立AI /机器学习（AI / ML）有关。

这使我有机会反思自己的经验，以帮助大型企业加速其AI /机器学习之旅，并且更具体地说，评估什么是行得通的，也许同样重要的是，什么行不通的。 我将这些总结为几个简单的"经验教训"，希望它们对您组织的AI / ML之旅有用。

第1课：不要让完美成为够用的敌人

以我的经验，您的模型将永远不会是完美的。 因此，请勿尝试使其完美。 现在，请不要误会我-模型的准确性（或适用于您的情况的任何指标）很重要，但是获得绝对最佳的模型可能仅在Kaggle比赛中起作用。

相反，您的重点应该是使模型足够好以满足业务需求。 事实是，几乎所有企业都认为，要获得一个可以提供价值的"足够好"的模型，要获得完美的模型要花很长时间。 因此，我的建议非常简单：找出对您的组织"足够好"的内容，并专注于将模型投入生产。

第2课：建立模型只是工作量的10％

这是一个基本但基本上未被认可的事实：如今，企业中数据科学的绝大部分时间并没有真正花费在数据科学上。 相反，大部分时间（根据我的经验，有90％以上的时间）都花在了其他事情上，包括：获取数据，工程数据和功能集，解决安全问题，设置基础架构（云或数据中心）或 工作站，用于生产的包装模型，以及创建DEVOPS脚本以将完整的模型迁移到产品中……这还不是完整列表！

不幸的是，在大多数不成熟的组织（也就是说，大多数组织都认识到相对的"新颖性"或AI / ML）中，每个项目实际上都经历了这种额外的非数据科学工作。

这有什么大不了的吗？ 的确如此。 假设您小组的预算为100万美元（一个很好的整数，这使数学很容易），这意味着某人（在很多情况下是您的高价数据科学家）将90％或90万美元用于与其他任务不直接相关的任务 到您雇用他们的目的。 那是很多钱！ 这不仅令人痛苦，而且体验起来更加痛苦！

那么，如何避免这种痛苦呢？ 好吧，这导致了我的下一堂课……

第3课：秘诀：AI / ML平台

正如我之前强调的那样，太多的项目将太多的时间花费在与AI / ML不直接相关的任务上。

解决方案：" AI / ML平台"。

首先，不要混淆" AI / ML平台"的含义。 不仅仅是云供应商提供的环境和工具包。 别误会，我喜欢AWS，Azure和Google提供的工具-没有它们，您真的无法有效地进行AI / ML。 但是，存在一些云供应商工具无法解决的重要考虑因素。 换句话说，云供应商工具是必需的，但还不够。

那么，什么是" AI / ML平台"？ 简而言之，AI / ML平台的目的是加速将AI / ML模型投入生产。 它是在AI / ML环境和工具之上实现的"胶水"，即脚本，安全策略，可操作性问题和自我配置基础结构。

让我们解决关键因素：

·安全性：解决访问敏感数据所需的安全性问题，需要大量的尽职调查。在大多数组织中，其根本原因是几乎每个项目都讨论，辩论和实施了几乎相同的安全问题。另一方面，AI / ML平台根据您组织的安全状况实施安全模型，执行一次，然后将其提供给所有项目。大多数组织，尤其是受到严格监管的组织，都需要远远超出云供应商通常提供的"虚拟公共云"功能的安全控制。至少应具有的一组附加功能包括：基于身份的访问控制（将解决几乎所有黑客问题），配置漂移管理（例如，捕获Capital One发生的错误防火墙规则更改），以及数据流的方式（例如，数据可以存储在平台上，但只能使用"类似于Citrix"的门户来可视化以使用工具-数据永远不会离开平台）

·可操作性：所有大型企业对生产代码都有严格的要求。 如今，AI / ML模型被认为是可部署的代码，并且受到与其他生产代码相同的要求的约束。 不幸的是，在大多数不成熟的组织中，这些要求是在每个项目的基础上实现的。 相比之下，AI / ML平台提供了生产级工具，可通过常用的日志记录，警报，异常处理，统计信息和指标捕获以及与企业操作控制台的集成来增强裸机模型，从而确保AI / ML模型也能解决 基本的企业关注点

·自我配置的基础架构：我发现组织迁移到云时发生了不幸的事情：他们带来了旧的数据中心包（主要是笨拙的流程和手动流程），并在云上实施了同样低效的流程。 错误的答案！ 云供应商花费了数年时间优化工具和流程，以使数据科学家能够自行配置工具和环境，而无需其他监督或流程。 AI / ML平台整合了必要的DEVOPS和安全功能，以允许数据科学家和数据工程师快速获取数据并提供训练环境。

第4课：" AI / ML市场"是现代AI / ML的基本要求

简而言之，AI / ML市场是与AI / ML模型相关的所有工件的目录，可实现模型的可再现性，可追溯性，可解释性和可验证性：

· 为了解决可重复性问题，AI / ML Marketplace提供了对模型源代码的引用（当前版本和先前版本），并且用于训练模型的数据都保存在清单中

· 为了解决可追溯性，AI / ML Marketplace保留了对原始源系统数据和数据工程脚本的引用，这些数据用于转换和丰富其内容，从而在整个交付生命周期中提供对数据的所有更改的可见性。

· 为了解决可验证性，AI / ML市场管理对训练输出，日志和相关工件（包括与模型偏差和"道德"检查相关的输出日志）的引用，从而捕获模型有效性的证据。

· 为了自动化信息捕获过程，AI / ML市场将与AI / OPS（用于AI / ML的DEVOPS）过程集成在一起，以自动捕获上述工件。 有趣的是，主要的云提供商，传统的DEVOPS供应商以及较新的AI / OPS初创公司都可以使用工具和功能，可以将它们组合在一起以捕获许多所需的指标和元数据。

简而言之，AI / ML市场是目录和存储库，可通过充分解决可重复性，可追溯性，可验证性和可解释性来促进现代AI / ML开发，管理和治理。

第5课：立即开始您的Cloud-Native AI / ML程序！

在大多数企业中，我看到计算平台和数据/存储量的扩展远远超出了内部数据中心的功能。 GPU不在议程中。 三倍和四倍的存储池正在建设中。 但事实是，事实证明，即使是大型组织也无法跟上步伐。

大型国际咨询公司埃森哲（Accenture）说，问题很少：首先，"到现在为止，还没有经过验证的扩展蓝图，组织可能陷入一些常见的陷阱。"其次，"人工智能的陌生环境 意味着企业可以被诱使放弃久负盛名的行为，重新发明轮子并从头开始构建。"最后，"有许多行之有效的低成本AI选项可以立即购买并开始使用。 "

那么，当大型云供应商提供其他功能更强大，成本效益更高，可扩展的最新选项时，为什么要与之抗衡呢？ 我的简单建议是：抛开批评家，让您的云原生AI / ML程序启动！

第六课：使AI / ML民主化

大多数组织，尤其是那些将AI / ML迁移到云中的组织，都有千载难逢的机会来组织其组织以取得成功。 我的愿景（我在大型企业中看到过的愿景）是"使AI / ML民主化"。 我的意思是，任何小组（假设他们具有技能）都应该能够随时随地使用他们需要的任何工具和库来构建AI / ML模型。

但是，您如何扩展和管理这种类型的组织结构？ 简单来说，基本要求是在AI / ML平台和AI / ML市场中实现了规模和管理所需的必要防护栏。 考虑到这一点，以下是AI / ML组织中一组实用的组：

· AI / ML平台团队：该团队对建立，运行，支持和发展包括基础架构，云环境，安全性，工具和DEVOPS在内的所有组件具有完全的端到端责任。 该团队不仅要对平台负责，而且还要培训，支持和指导数据科学团队

· 分布式数据科学团队：由于许多跨领域的问题都融入了AI / ML平台中，因此这使数据科学家可以腾出时间从事数据科学工作，还可以使整个组织中的数据科学家快速，无缝地入职。 该指导原则允许任何具有数据科学技能的小组，以其小组的需求和业务需求所决定的速度进行数据科学。 没有集中的组。 没有象牙塔。

总结

我在本文中的目的是提供一些简单的经验教训，这些经验教训将帮助您加速企业的AI / ML之旅，并避免一些我遇到的减速带和坑洼。 希望我已经实现了这个目标。

但是我可以肯定地说的是，事情发展很快。 技术和方法可能会发展，而且很可能我应该考虑从现在开始一年编写一个新版本。 或者，也许，一年后，您将能够写出从您的组织的AI / ML之旅中学到的一些经验教训！