埃里克：马特，感谢您今天加入我们的播客。

马特：谢谢，埃里克。感谢您的款待。

埃里克：是的，我真的很期待这个。我认为我们将讨论一些与我的业务密切相关的话题——关于如何成功部署物联网的话题，以及一些我个人真正感兴趣的话题，即在上下文中展望生成人工智能的未来工业物联网。所以我真的很期待和你一起深入研究这些，马特。

但也许在我们去那里之前，我很想更好地了解您来自哪里以及您如何成为 Embassy of Things 的创始人兼首席执行官。理解为什么有人决定投身于某个特定问题总是很有趣。在过去的 20 年里，您作为联合创始人或高级管理人员参与了 10、15 家公司的工作，这是什么？因此，我很想谈谈其中的一些亮点，并了解您现在创立 Embassy of Things 的想法。

Matt：我的背景是真正参与分析的工业方面。我是一家风险基金的成员，该基金基本上还创办并孵化了 20 多家工业分析公司。在所有这些小型初创公司中，我们都在尝试与大型制造公司之一、石油和天然气、能源、电力、公用事业等公司合作获得项目。我的工作是担任首席技术官，帮助他们整合技术堆栈，真正做到这一点，并成为一家成功的分析公司，并提供人工智能、酷炫的新人工智能产品等等。

发生的事情是，很多次，有成功的 POC，但后来都失败了。 POC 就像是，“哦，作为 POC，我们实现了我们想做的一切。”但随后，无论接下来发生什么，“哦，领导层决定不实际做”，或者“公司实际上无法将其投入生产”，或者“它不可扩展”。所以我越来越深入地研究这个问题。我发现那里有一个大问题，那就是，在大多数这些项目中，每个参与的人都忽略了一个事实，即他们必须从基本上与互联网隔离的系统中获取工业人工智能的数据，这些系统在发电厂是不容易接近的。

因此，如果您想创建一个实时分析系统来分析和进行异常检测，您可以在本地进行。但是你不能真正在云中完成它，除非你真的将数据泵入云中，这是不可能的，因为你没有互联网连接。但是，在本地，您不具备进行机器学习的计算和存储能力。因为这需要大量存储所有历史数据，以及大量的计算能力。

当那件事发生时，我的想法是，在某个时候，创办一家专注于这个完全被忽视的问题的公司会很棒，这就是管道问题。让我给你这个例子。没有人，当他们买新房子时，会说，“它也有淋浴和水龙头吗？”每个人都只是假设，“哦，它看起来很漂亮。水在那儿。水龙头在那儿。管道在那儿。”所以很多时候发生的事情是，当数字转型项目开始时，分析公司说，“嘿，我们可以做这件很酷的事情，”人工智能公司说，“我们可以预测未来，”在第一个 POC 中，他们说他们可以做吧。他们得到了一些样本数据。因为真正在运营方面的人说，“这里没有人会接触我们的系统。我们将通过 FTP 将一些示例数据传输给您。我们可以给您磁带、拇指棒或拇指驱动器，或者他们拥有数据的地方。人工智能公司、分析公司开始训练他们的模型——比如说，半 TB 的数据——回来说，“是的，我们解决了它。我们可以给你增加 5% 的产量或节省成本等等。”这就是成功的 POC，因为你证明了你的 AI 软件将提供价值。我们有价值证明，对吧？但是，实际上把它放到一个高度可用的可扩展生产解决方案，实时执行，这是一个完全不同的球赛。当时的这些实例确实触发了这个想法。

后来，我在得克萨斯州休斯敦和几个朋友坐在一起，我们在考虑下一步应该去哪家公司。因为我一年前有两次成功退出。那个念头又回来了。我们说，“你知道吗？这仍然是大多数尝试这样做的公司所忽视的最大问题之一。”因此，您在运营方与 IT 方和安全方之间存在组织阻力，等等。让我们专注于此。让我们专注于最无聊的事情，即真正将数据从运营数据源安全地传输到企业级数据湖和数据库，然后使这些数据有意义。意思是，将其上下文化。能够用这些信息丰富它，以便数据科学家和数据工程师最终可以使用它。这样，客户就会喜欢我们。显然，云供应商会喜欢我们，因为我们基本上是将大量数据传输到云中。消费云服务。此外，想要销售 AI 产品的分析公司也会喜欢我们。因为突然之间，他们实际上不仅可以进行 POC 然后失败。但他们实际上可以拥有 POC，然后实际投入生产。这就是促使我创办这家公司的背景故事。

埃里克：是的，这是完全有道理的。我不知道有多少我们遇到过这种情况或我们一直在与之合作的客户，我们试图帮助他们推出一些路线图。然后他们遇到了这个挑战，正如你所说的，这些管道问题的非常简单的问题就是能够以 IT 和操作人员都满意的安全方式访问数据。所以我想稍后进入公司并深入研究 -

马特：我只想说——抱歉打扰了。但我只想说这个。我如何看待它是数字化转型的地狱，数字化转型的门徒，到处都是成功的 POC。可以这么说，它充满了成功的 POC，它们都落入了 POC 地狱。这就是我的看法。请继续。

埃里克：是的，我知道。绝对地。因此，一方面，成功的 POC 激增，但最终在生产中失败。其中很大一部分是在从操作系统获取实时数据的同时实施 POC 的技术挑战。那里还有很多其他挑战。

您最近出版了一本书，《工业物联网开拓者指南》。令我感兴趣的是，您在那本书中提到的许多主题与技术挑战没有直接关系，但它们也与获得 POC 的人员、组织挑战有关。因为这些技术挑战，你可以说其中很大一部分也是风险感知。因此，还有人为因素，或者决策因素，我们可以接受多大的风险？我们对云等感到满意吗？所以总是这样：只有有人这样看待风险，风险才是风险。我很想听听您对这个观点的看法，比方说，人为因素还是组织因素是从 POC 转向规模化的瓶颈？

马特：当然。我的意思是，埃里克，这是最大的问题，所有事情中最大的挑战。这本书实际上与现有的任何工业物联网书籍都非常不同，因为它不关注技术。它侧重于人和组织的挑战。所以它实际上是一本书，分为两部分。第一部分写成小说。这是一本讲故事的书或书中讲述的典型制造业、典型能源公司的故事，基本上说，“嘿，我们想使用人工智能。我们想用它来拯救公司。否则，我们将被抛在后面等等。”因此，书中的团队真正经历了所有不同的组织挑战，还有一些技术挑战。但是这本书不是在谈论什么是 OPC UA，或者你能告诉我 MQTT 协议是如何工作的吗？真的是这样。

其中一些挑战真正始于数字战略。最后，第一件事——我想，埃里克，你很清楚这一点。但公司必须要做的第一件事是必须有一个工业数据战略。还必须有人拥有它。所以你必须有一个领导者。领导者必须能够做出决定。领导者必须拥有资源、资金和权力来实际构建跨越多个部门和多个组织的东西。第二部分是这个人还必须能够创造一个愿景，阐明它，并让利益相关者支持他。然后第三件事是必须有必须定义的用例。

最大的挑战之一是定义第一个用例。因为，最终，第一个用例要么成就整个项目，要么毁掉整个项目。如果您选择了错误的用例，那么几乎没有第二次机会。所以它变得非常非常关键。当然，如果不剧透的话，很多时候发生的事情是，一旦你开始在发现会议中收集用例——我称之为发现死亡——组织中的每个人都会提出一个用例，每个人都想要他们的当然，用例首先出现。然后你会自动说，“那么，哪些是对业务影响最大的用例？哪个具有最高的投资回报率或其他什么？”然后你可以这样对它们进行排名。

也就是说，如果你这样做，也很有可能会发生一个非常大的用例最终成为最重要的用例。实施可能需要很多很多个月的努力和金钱。甚至可能是两年，因为它包罗万象，涉及许多部门。因此，填充的风险是巨大的。因为只有当整个时间里的每个人都真正一起工作并且玩得开心时，它才会成功。所以是的，它具有最大的业务影响，但它也具有最高的失败风险。

因此，如果您以不同的方式对它进行排名，您会说，“好吧，让我们也说一下什么是价值评估时间？”你之前提到过这个，埃里克。但实现价值的时间意味着，您真正能够以多快的速度将价值直接返回并展示给公司的领导层？嘿，我们实施这个项目。比方说，它花费了 50 万美元，但从现在到未来或直到重复发生结束，它每年可为您节省 100 万美元。”一旦你这样做了，一旦你成功地将一个用例投入生产，甚至如果它很小，表明你可以做到，表明它有效，那么你就可以解决一个更大的问题，一个更大的问题，一个更大的问题。

我的一个朋友早些时候在另一个播客中说，这就像吃大象一样。所以你用小勺子吃一头大象，但你不能一次吃掉整头大象。我说，嗯，第一口是很小的一口。一旦成功，你基本上就可以咬大象了。所以最终，你可以做所有的用例，但你必须找到合适的开始。所以这可能是最初最大的挑战之一：开始，做正确的事。然后还有其他挑战，即如何真正挑选团队并解决问题。

埃里克：这是非常有名的。所以我们经常受雇做用例路线图并进行这种类型的优先级排序。我们始终非常关注的几个因素是，特定用例涉及多少利益相关者？感动了多少人？我们必须访问多少种不同的数据源？什么是风险，感知风险？如果失败，那么会发生什么？然后你开始发现通常有一些用例可能不会彻底改变业务，但它们只是触及几个利益相关者。他们只需要来自几个来源的数据。如果它们失败了，它们实际上不会造成任何问题。你会说，好吧，这些，我们可以让它们起飞，对吧？我们可以让这些离开地面。我们可以产生合理的投资回报率。同样，这可能不会令人难以置信，但这将是一个合理的投资回报率。然后组织可以看着它说，“好的。我们做到了。”通过这个过程，你开始建立一些基础设施和一些内部知识等等。然后你可以更有野心。

马特：我很高兴你这么说，埃里克。因为这基本上也是组织开始学习和改变的地方。我的意思是——实际上，你说的，你们做得很完美——如果你从一个用例开始，你可以向组织展示，然后说，“看，我们做到了。它有效。这是影响。这就是价值，”然后组织内部的人在更大的用例之前可能已经抵抗了知道两件事。首先，它会发生。这已经发生在其他组织身上，所以我们无法阻止它。所以阻力位会下降。因为如果每个人都看到一个成功解决方案的第一次部署，并说谁想成为下一个解决方案的一部分，谁想反对它，那么突然之间，与从大象开始相比，组织中的阻力要小得多并尝试一次吃掉它。每个人都说，“不，这不会发生。”所以我非常喜欢你在那里说的话。

埃里克：这里还有另一种观点，我真的很想听听您的想法，即自上而下与自下而上的问题。在某种程度上，这是一个战略问题，我们是否希望通过组织努力来定义我们的方法，然后制定这份多年路线图？还是我们想让最接近问题的人只是想一想？所以有一个组织元素。还有一个建筑元素。

所以如果你做自上而下的事情，那么你就会真正开始思考我们需要什么样的架构来实现这一切，这会造成很多延迟。它将您的注意力放在前期的架构上。如果您有更多自下而上的用例，那么您可以更快地完成工作。而且，您最终可能会一起破解东西。五年后，你会发现，“哦，我的天哪。我们做了什么？我们创造了这个科学怪人，其中包含 100 个不同的用例，它们彼此不交谈。”所以我想这两种方式都需要权衡取舍，但我很好奇你是如何考虑解决这个问题的。

马特：这是我的交易。那是我的日常工作，正是这个专门关于架构的讨论。对我来说，首先是用例。用例驱动架构，而不是相反。如果我看到有人在白板上，他们开始在上面放一些小标志，比方说，云服务——比方说，卡夫卡。 Kafka 可以解决世界或其他任何问题——这已经是失败的秘诀。因为用例是什么？为什么需要卡夫卡？为什么不提供其他一些已发布的订阅者或提供给其他人的服务类型呢？这是因为那个人非常熟悉 Kafka，并且那个人相信 Kafka——我说的是 Apache Kafka——会解决问题。它可能是一个很好的候选人。但对我来说，建筑学的起点要高得多。

当您开始绘制实际上包含特定系统或组件的架构时，您谈论的是逻辑架构。不是真正描述模块的基本架构。您已经在谈论您心目中的特定技术候选者，它解决了您认为正确的某些架构的特定问题。在我看来，要真正构建架构，首先要选择用例。也许是两个或三个用例。然后你真的去创新自上而下的方法来识别，没有真正考虑任何技术，特定的模块。

比方说，您有一个数据摄取和上下文化层。这意味着数据来自不同的数据源。它不仅是时间序列数据或日志文件或其他任何东西。它还具有关于资产的元信息，它们在哪里，它们如何组合在一起，它们如何汇总到一个业务单元中，它们如何反映在层次结构中，在树中。您实际上如何搜索树？您如何选择同一资产的不同类型供以后查询？所以你有它的背景。您想要构建一个层，将这些数据汇集到一个单一的真实来源中。所以这可能是一层。

另一层可能是，我们希望在哪里访问这些数据？谁将访问它？会是想要运行分析的业务用户吗？是否将由操作员实际拥有一些运行分析系统的应用程序来实际操作机器？这取决于。这些人在哪里，就是实际数据所在的地方，必须访问的地方以及应该访问的地方。所以你有数据访问层。您拥有数据摄取、管理、情境化层。因此，您正在构建这些组件的架构。这些组件中的每一个，然后你可以说，有什么候选人，什么技术，什么云服务，什么系统，什么应用程序，有什么第三方。

您可以说 Kafka 是其中之一，适合在这个特定模块中执行此操作。但可能还有其他 15 个仍在做类似的事情。然后它变得更像是，“我们应该使用这个还是那个，因为我们已经有人知道如何做到这一点，”或者，“这个更便宜，”或者，“这个更快，”或者其他什么. 逻辑架构，然后你实际上真正深入到组件级别并说，好吧，为了摄取数据，我们将从云中使用这个特定的服务。假设它是 AWS Kinesis 与 Kafka 或其他什么。然后你得到到那个水平。但是如果你从那个水平开始，我们就有问题了。

所以它有点自上而下，然后越来越低，直到您真正了解物理架构，即 IP 地址、端口号、协议等等。这是最后的结果。就是这样。让我们对此发表评论。你必须做功课，从最顶层一直走到最顶层的架构，最基本的，然后一路向下，才能真正理解实现它需要付出的努力。因为只有到达底部，您才会知道，好吧，我们将需要这么多具有这种内存大小的虚拟机。这将使我们每月花费 X 美元或其他任何费用。我们需要很多人来设置、维护和操作它。那将是我们的运营支出。因此，一旦您真正深入到底部，您将只知道该信息。然后在那个时候，你知道真正到达那里需要付出什么努力。这是我对此的简短回答。

埃里克：明白了。好的。所以从架构的角度来看，这就像自上而下，从应用程序到基础层，通信层越多。那么也许从组织的角度来看——这里没有正确的答案——但你觉得自上而下在你的体验中往往更有效还是自下而上？这只是个案吗？

马特：嗯，好的。非常好。是的，关于如何实际构建或设计架构的组织构成，也是一个很好的问题。那么谁应该参与，应该在组织中？我们聚在一起创建一个联合架构，还是应该更像是几个人真正做出决定等等？

我的个人经验是，如果你试图让所有组织进行协作，它通常最终要么成为一个不可行的解决方案，因为每个人都在推动自己的议程。 SAP 团队希望仍然是单一来源的所有者。这就是 SAP。运营人员认为单一来源是运营数据源。 IT 人员认为他们有东西，应该是所有东西所在的东西。这些组织这样做并没有错，因为他们是经过衡量的，这是他们的工作。那是他们的角色，所以他们正在以这种方式推动它。

但是如果你试着说，“哦，你们聚在一起，自由地想出——忘记你的日常工作，建立新的东西，这实际上甚至可能会消除你的一些责任，甚至是组织权力。放弃它，做点什么否则，”非常难。几乎不可能。会发生什么？第一个是它根本不会发生，因为他们就是做不到。第二个是，你最终会陷入某种边缘状态，每个人都同意并在这里和那里付出一点。所以你最终会得到一些不可扩展的东西。这是行不通的。它涉及大事中的每个人。所以这是一个解决方案。每个人都同意。但这就像你让世界上所有国家都同意一件事。如果他们最终就此事达成一致，那就太淡化了。这对任何人都没有帮助，对吧？

所以我的个人经验是，你必须在一个较小的团队中有来自外部或内部的关键利益相关者。然而，这些人必须能够理解获取 SAP 数据、获取 OT 数据、获取 IT 数据所涉及的挑战，了解什么是 MES 系统、EIM 系统、数据历史记录、SCADA，这些都是什么以及为什么获取数据是个问题。他们必须对架构的底层有详细的了解，但与此同时，也能够完全理解业务影响——用 CEO、高管等的语言来阐明愿景并带来这一切在一起。如果你让一小群人聚在一起，他们可以完全理解端到端需要什么，并形成一个可以得到包括 CEO 在内的高管支持和支持的愿景，那么与你相比，这更有可能取得成功让所有组织都做一个 kumbaya。

埃里克：是的，这是一个很好的类比。联合国可以解决的问题太多了。大多数问题需要由国家来解决，也许是城市，也许是社区。但是如果你真的想理解它，你必须深入到问题的根源。

也许这是介绍您的旗舰产品 Twin Talk 的好时机。然后还有其他几个，Twin Sight 和 Twin Central，我很想了解它们。听起来它们的设计——如果我错了请纠正我——介于两者之间。一方面，我想拥有一个可以在整个组织中使用的平台，但另一方面允许人们插入该平台并从更多以自下而上的用例为中心的角度工作。帮助我了解它在架构堆栈中的位置。我想公司都有很多他们正在构建的遗留东西。那么它如何适应那里呢？那么价值主张是什么？您尝试通过 Twin Talk 实现的前后效果是什么？

马特：哦，当然。我们创建的产品套件非常简单，但又有点复杂。但简单是我们想要的——我们的产品，这些是软件产品。这不是一项服务。它不是软件即服务。从字面上看，它是一种软件产品，可以解决其中一些关键连接以及将数据背景化和可视化的能力。所以我们称它为工业数据结构，因为它就像你可以将你的架构编织在一起。我们的产品可以填补一些通常会出现的空白。我们的产品并不能解决一家公司的全部问题，也不能解决所有问题。它们可以帮助将其他组件组合在一起，并使其成为您想要的样子。它就像一块织物。所以你可以这样做。

我们的第一个产品叫做 Twin Talk。 Twin Talk 只是让数字双胞胎和物理双胞胎相互交谈。因此，Twin Talk。这是描述它的最简单方法。物理双胞胎是所有操作数据源，包括 SCADA 系统、不同类型的 SCADA 系统、不同类型的操作协议、数据历史记录，以及基本上位于一级和二级 Purdue 模型（即 Model S）中的任何东西。这描述了哪个层或哪个级别的系统可以与哪个其他层对话。它基本上是从最低级别开始的，实际上是在物理传感器级别到企业网络。两者之间有不同的安全层。

Twin Talk 基本上允许桥接这些安全层并将数据从非常安全的传感器网络获取到企业级数据库或数据湖。在执行此操作时，它实际上可以将数据置于上下文中，不仅可以显示时间序列传感器数据，还可以显示有关传感器的所有信息。这就是 Twin Talk 的全部意义所在。

埃里克：只是为了澄清一点。然后数字双胞胎将由其他供应商提供。是对的吗？

马特：是的，完美的问题。谢谢，埃里克。因此，数字孪生可以由不同的供应商提供。我们实际上刚刚宣布将 Twin Central 与 TwinMaker 集成。 TwinMaker 是 AWS 的一项云服务，可让您实际创建数字孪生。这是一个云服务，你可以创建层次结构，你可以创建资产。资产可以包括——比方说，你在制造方面。它拥有所有不同的锅炉、传送带，以及制造过程中的任何东西。它还具有以 3D 形式飞过制造侧的能力，等等。基本上，通过这种集成，我们已经集成了这项 AWS 服务。这是数字孪生的唯一真实来源。

埃里克：好的。清除。

马特：这种整合是与我们的第二个产品。来自 AWS 的 TwinMaker 实际上与我们的第二个产品 Twin Central 集成在一起。 Twin Central 基本上是一种解决方案，它允许您从字面上获取元信息和来自不同数据源的层次信息，并在层次结构中创建一个企业范围的资产树模型。 Twin Central 允许您管理您的数字双胞胎，但它不是来源。在这种情况下，数据源实际上是 TwinMaker 服务。但是 Twin Central 允许您管理、决定哪个数据源、信息在哪里，比方说，在您的 SAP 系统中。您的MES系统中的层次结构是另一个层次结构吗？您想要构建一个层次结构，该层次结构具有来自多个系统的多个站点，并实时反映并将其提供给使用 Power BI 的组织。人们只想浏览那棵树。这就是我们的第二个产品 Twin Central 可以做到的。

埃里克：好的。清除。所以你有 Twin Central。您还有 Twin Sight，它是一个无代码应用程序构建器。这适用于希望在 Twin Talk 之上构建应用程序的公司。那是构建完全可部署的应用程序，还是更多的是用于测试概念的工具包？这在规模上的可部署性如何？

Matt：是的，它是一个单独的应用程序，一个单独的软件包，基本上可以让您可视化来自不同系统的数据。我的意思是，它们不同于 Power BI、Grafana 或其他一些可视化工具。 Twin Sight 的真正设计目的是让您从运营数据源获取数据，并向您展示直接来自 OT 数据源的油井流速，然后将其与物流数据相结合来自 EIM 系统。然后基本上能够点击这些图表并从完全孤立的不同数据源中提取数据。因此，您有一个用户界面，可以为您提供概览并显示一张图片。但在下面，您实际上拥有许多不同的数据源，它可以利用这些数据源。它对单位的使用是完全透明的。它基本上创建了执行此操作的应用程序。

埃里克：好的。清除。这就是您的软件组合。您还有这个 Asset Catalogue Studio，它围绕管理物理资产、传感器等。这更像是一个支持中间件的解决方案吗？这如何适应架构？

Matt：Asset Model Studio 是一个辅助功能。这实际上很有趣。它的开发是因为客户需要它，坦率地说。很多客户后面真正投产的时候都会出现这个问题，就是这个。假设您实际上成功地构建了一个数据湖，并且您获得了 20,000 项资产的所有数据。然后在你这样做之后，你会获取所有数据，然后训练你的机器学习模型。每个人都很开心，一切都在生产中。但是，比如说，运营方面购买了一套新资产或出售了一些资产。或者，最坏的情况是，他们实际上认为到目前为止的命名约定是错误的。他们想更改所有资产的所有名称，因为他们只是想对其进行标准化或其他。现在你有以下问题。如果他们这样做，如果他们更改了运营方面的所有名称，那么所有命名以及您在 IT 站点、数据湖中构建的所有内容都将是错误的，因为您拥有旧数据在那里。

那么你如何解决这个问题，你可以在一侧更改资产的命名，但在另一侧仍然有名称？当我们创建它时，它基本上就是所谓的资产目录管理器。您基本上可以做的是允许公司的运营部门选择名称、更改名称等等。但与此同时，您可以定义这些名称如何投射到 IT 系统中，这样即使需要更改名称、命名约定等，也不会破坏或更改您已构建或想要的任何内容为您的预测分析、业务应用程序以及报告和仪表板构建。一切都保持不变。那是资产模型目录。

埃里克：好的。伟大的。所以我认为这是对产品的一个很好的概述。也许您可以向我们介绍一两个客户案例，只是从端到端的角度了解您正在与谁合作。他们遇到的问题是什么？我认为这是帮助我们了解实际情况的好方法。

马特：当然。我们最大的客户之一是 BP，特别是北美的 BPX。我们已经用它们完成了许多公共用例。您实际上可以谷歌 — BPX、EOT 和 AWS。你会发现一个架构等等。关于这里的用例和我们在这里实施的内容，这里的需求是真正将来自 SCADA 系统和历史学家的数据带入工业数据湖。工业数据湖在 BPX 中有许多不同的用例，我无法详细说明具体的用例是什么。但它成长了。当我们最初开始使用 BPX 时，我们从少量用例开始。随着时间的推移，它变成了更多的用例。然后，一旦我们进行了公共案例研究和所有这些工作，就很清楚这对我们来说到底有多大。使用 BPX，我们经历了从拥有第一个 POC（您真正尝试测试一些东西）到实际决定成熟的架构并将其投入使用所需的许多里程碑或所有里程碑为十亿美元的业务生产。

另一个我也想在这里真正快速提及的公司是一家名为 Hilcorp 的公司，因为它既相关又非常不同。他们基本上是美国最大的私营石油和天然气公司。 Hilcorp 非常有趣，因为他们的商业模式基本上是购买报废的资产。基本上，你拿一个油田说，“好吧，没有人想要这个了，因为它是生命的终结。它是油田。”但是 Hilcorp，他们实际上让它开花或产生比以往更多的能量和石油，即使没有其他人能够做到。所以他们在某种程度上就像魔术师。同时，从挑战的角度或重要的是，公司内部的人员能够使用分析并能够真正了解资产的寿命和健康状况。因为他们必须比地球上几乎任何其他人都做得更好才能使这种奇迹发生。

对于我们来说，我们基本上构建了架构，即整个数字孪生数据湖。这也是一个公共用例，您可以使用 Google 或 ChatGPT 搜索它。您会看到我们将不同类型的组件、不同类型的数据源组合在一起以实际实现这一目标。此架构中的一点是使用的数据湖是 Databricks。所以我们实际上有 Apache Spark 驱动的实时分析系统，它基本上处理工业数据并真正扩展。它真的可以处理数以万计的资产并处理机器学习模型，为操作员提供洞察力并帮助他们，这是你以前做不到的，以前甚至不存在。我们真的为他们创造了一个突破性的里程碑。

埃里克：所以你非常关注能量。这是因为市场的独特需求，还是只是作为一家企业需要专注于特定细分市场？

马特：嗯，我刚才提到了两家能源公司。我们也有制造业。但事实是，我们是从能源开始的，所以这是我们最大的部分。目前，今天，实际上，我们在德国的汉诺威工业博览会上宣布了我们的 Twin Talk GPT，它真正专注于制造业。对我们来说，实际上是能源、制造和运输。这是我们关注的三个工业部门。但我们真的是从能源开始的。

埃里克：明白了。我很想谈谈这个 Twin Talk GPT。实际上，这是我一直关注的话题，知识管理的概念。我不知道你怎么看这个。我们从能够为维护工程师等人员提供访问相关信息的界面以帮助解决维护问题等的角度来看待它。但是您如何看待 GPT 并将其集成到工厂环境中？

Matt：首先，让我们从所见所闻和所做的事情来定义通用 AI 之间的区别。首先，让我们看一下这个话题并定义通用 AI 和生成 AI 之间的区别。因为人工智能已经存在了。已经成为热门话题。现在我们有了生成式人工智能，每个人都会说，“哇。这是有史以来最大的突破。”但有什么区别呢？现在有什么不同？对我们来说，这是从数据集中学习以创建学习的机器学习模型的能力。您不仅可以分析数据，还可以实际生成数据。对我们来说，这就是最大的不同。

传统的 AI 神经网络、Hessian 网络、任何其他神经网络、循环神经网络都能够学习并能够理解，比方说，时间序列数据，这实际上是传感器的重要组成部分——语言。语言模型并没有那么重要。然后通用人工智能可以检测异常。但是有了生成式人工智能，它基本上可以产生异常事件。所以我给你举个例子。比方说，你想创建一个新的预测分析应用程序，或者你想做一个主动维护系统。如果你想训练一个机器学习模型能够实际进行预测分析或维护，你将拥有一些包含不良事件的数据，这些数据会出错。您需要的数据实际上具有应该检测到的东西。所以你可以用生成式人工智能做的是，你可以从过去 10 年的 20,000 项资产中获取数据。训练模型。然后，您创建一个资产，它是一个生成式 AI 转换器模型。这是重要的部分。这个训练有素的转换器模型将能够模拟您希望它模拟的任何类型的事件。你可以说，“好吧，如果它坏了怎么办？模拟传感器的数据，当这个东西坏了，或者这个阀门关闭，或者有人掉到传送带上，或者发生地震，整个东西都着火了管他呢。”所以你基本上可以告诉生成 AI 通过命令来创建这些事件。您基本上可以告诉它为这个特定事件生成数据。

另一部分是它让您在一定程度上确信模拟数据实际上是准确的。所以如果你也说，“这就是如果有人掉在传送带上会发生的事情，”它也会说，“嗯，我们不确定或确定这是准确的。这是对真实情况的准确描述。 “就像基于语言的转换器模型 ChatGPT 一样，它可以告诉您问题的答案。这可能是错误的。他们称之为幻觉。如果您对传感器数据执行此操作，也会发生同样的事情。这可能是错误的。

然而，在生成式 AI 模型中——当你实际使用 ChatGPT 时通常不会显示，但也许他们将来会这样做——它实际上知道并感觉到这个答案实际上有多么不确定。所以它可以说，好吧，我正在给你一个答案。有 10% 的把握那是真的。在内部，它知道这一点。它仍然给你答案。它现在不会告诉你这个。但对我们来说，我们基本上在我们的产品中构建了一个基于时间序列的生成式、预训练的转换器系统。现在，这是什么意思？这意味着您实际上可以训练这些模型或使用从工业系统流入的数据训练模型。然后你可以关闭真实数据并说，“好的。继续提供这些数据。”当它提供实时数据时，您还可以控制它并说“现在创建一个停机事件”。然后，您可以测试您的所有预测分析应用程序是否真正捕捉到了它，它们是否触发了正确的警报，是否向正确的人发送了电子邮件或短信。它使您不仅可以创建记录实时故障的实时数据。

生成式 AI 可以创建超出其实际学习范围的事件。这不仅仅是一个播放版本。它实际上可以创建从未从历史数据中实际学习到的新事件。因此，这才是真正的突破，能够实现并加速任何类型的测试、先发制人维护的数字化加速、主动干预。任何这些类型的应用程序或系统都将从中受益。

埃里克：好的。超级有趣。对吗？你是最近才宣布的，对吧？公告是在本周发布还是之后发布？

马特：是的，实际上是今天。所以恰逢其时。是的，就是这周。

埃里克：好的。伟大的。好吧，也许一年后我们必须再做一个播客。我真的很想知道这最终是如何被采用的。我认为这是每个人都将产品推向市场的领域，基本上是在 GPT 推出大约四个月后。所以我认为明年，我们会产生很多创新，很多关于价值在哪里的学习。所以我很想进行后续对话。

马特：当然。

埃里克：太好了。马特，非常感谢您抽出宝贵时间。我想也许我这边的最后一个问题是，如果我们的一位听众想跟进并与您或您的团队进行对话，他们联系的最佳方式是什么？

马特：最好的方法是在 LinkedIn 上联系我。 LinkedIn 上的马特·奥伯多弗 (Matt Oberdorfer)。这很容易。给我发个信息吧。

埃里克：太棒了。谢谢，马特。我真的很感谢你今天的时间。

马特：嗯，谢谢你，埃里克，邀请我。