Over a year ago I shared my thoughts on why most startups that focused on deep learning tools for enterprises would fail. That post got a lot of attention (with help from Peter Norvig posting a video about it), and more than one founder of said startups told me that their investors made them write a response. I apologize for any inconvenience caused, but more scrutiny in this space definitely helps.

一年多以前，我分享了我的想法，为什么大多数专注于企业深度学习工具的创业公司都会失败 。 该帖子引起了很多关注(在Peter Norvig的帮助下发布了有关该视频的视频 )，并且上述创业公司的一位以上创始人告诉我，他们的投资者让他们写了一个回应。 对于给您带来的任何不便，我深表歉意，但是对此领域进行更多的检查肯定会有所帮助。

Unfortunately, the landscape hasn’t changed much since then. The way I lovingly describe most AI developer stacks these days is that they are “like DIY craft kits, with the instructions and 70% of the parts missing”. Innovation takes time.

不幸的是，自那时以来，景观并没有太大变化。 我最近描述大多数AI开发人员堆栈的方式是，它们“像DIYCraft.io套件，缺少说明和70％的零件” 。 创新需要时间。

In an effort to explain how we got here, and help guide where we need to go, I summarize three major challenges that are common in the early stages of the technology innovation lifecycle. Most importantly, we haven’t converged on a dominant design for ML Platforms, which leads to a proliferation of differently scoped and shaped systems with ill-defined interfaces. As a result, it has proven prohibitively hard to create appropriate form factors for AI developer tools targeted at enterprise users. Finally, and this is where IKEA comes in, the predominant way of how these tools are consumed by enterprises today tragically suffers from the IKEA effect.

为了解释我们如何到达这里，并帮助指导我们需要去的地方，我总结了技术创新生命周期早期常见的三个主要挑战。 最重要的是，我们还没有集中在ML平台的主导设计上 ，这导致了具有定义不清的接口的范围不同且形状不同的系统的泛滥。 结果，事实证明，很难为针对企业用户的AI开发人员工具创建合适的外形尺寸 。 最终，这就是宜家进来的地方，当今企业如何使用这些工具的主要方式遭受了宜家的影响 。

“A

“一个

AI开发人员工具缺乏主导设计 (AI Developer Tools are lacking a Dominant Design)

The emergence of new technologies is usually accompanied with subsequent phases of expansion and contraction in the number of possible solution designs. It is no longer contentious that AI will transform many industries, often becoming a strategic advantage and even creating new “AI first” business models and companies. As a result, all major Cloud vendors (and countless startups) are piling on resources to bring AI developer tools to a broader audience, most importantly big enterprises. All of these vendors broadly attempt to solve the same user needs, but with distinctly different approaches and outcomes, leading to a proliferation in different designs.

新技术的出现通常伴随着可能的解决方案设计的扩展和收缩的后续阶段。 人工智能将改变许多行业，通常成为战略优势，甚至创建新的“人工智能优先”业务模型和公司，这已不再引起争议。 结果，所有主要的云供应商(以及无数的初创公司)都在利用资源，将AI开发人员工具带给更广泛的受众，最重要的是大型企业。 所有这些供应商都在尝试解决相同的用户需求，但是方法和结果截然不同，从而导致不同设计的泛滥。

ML API中的主导设计 (Dominant Design in ML APIs)

This phenomenon exists at every level of the stack and usually progresses from the bottom up. As a PM on the Google Brain team in 2016, I remember trying to rationalize over 20 different high-level Python APIs that had emerged for TensorFlow within Google. Eventually, we converged on the Estimator and Layers APIs (which merged with Keras in TensorFlow 2.0).

此现象存在于堆栈的每个级别，并且通常是自下而上进行的。 作为2016年Google Brain团队的PM，我记得曾试图合理化Google内部针对TensorFlow出现的20多种不同的高级Python API。 最终，我们融合了Estimator和Layers API(在TensorFlow 2.0中与Keras合并)。

Once one of the design’s user adoption surpasses its competitors by a significant enough margin, it becomes the standard (or “dominant design”) and other players in this space conform to it, e.g. see equivalent APIs in PyTorch. The need for convergence on a dominant design is especially evident with platform products where it is prohibitively expensive to maintain countless competing designs, as is the case with ML frameworks where Data Scientists, ML Engineers, ISVs, Educators, etc. can’t cope with 100’s of overlapping and incompatible APIs.

一旦某个设计的用户采用率大大超过其竞争对手，它就会成为标准(或“主导设计”)，并且该领域的其他参与者也都遵循它，例如，在PyTorch中看到等效的API。 对于平台产品而言，对主流设计的融合需求尤为明显，因为维护无数竞争性设计的代价非常高，就像数据科学家，机器学习工程师，独立软件开发商，教育工作者等无法应对的机器学习框架一样。 100个重叠和不兼容的API。

机器学习平台中的主导设计 (Dominant Design in ML Platforms)

When we talk about “AI developer tools for enterprises” we are really talking about an emerging class of technology called “ML Platforms”. The fact that we are missing a dominant design for ML Platforms also means that there is no generally accepted definition, so I’ll just give you a very basic one: An ML Platform is a horizontal technology (i.e. not specific to a vertical use case) that provides all of the capabilities to cover the full lifecycle of ML applications. A graph from my previous blog post helps illustrate some of the different components of such a platform.

当我们谈论“面向企业的AI开发人员工具”时，我们实际上是在谈论一类新兴的技术，即“ ML平台”。 我们缺少ML平台的主导设计这一事实也意味着没有公认的定义，因此，我只给您一个非常基本的定义：ML平台是一种水平技术(即，不特定于垂直用例) )，它提供了涵盖ML应用程序整个生命周期的所有功能。 我以前的博客文章中的图表有助于说明该平台的一些不同组件。

At this point in time, there isn’t even broad agreement in the industry on the scope of ML Platforms, i.e. where they begin and end. E.g., some ML Platform products are entirely lacking capabilities from the Pre-Training (Data Prep) category.

目前，业界在ML平台的范围(即它们的起点和终点)上甚至还没有达成广泛的共识。 例如，某些ML平台产品完全缺乏训练前(数据准备)类别的功能。

There are several reasons why we haven’t reached a dominant design for ML Platforms. To name just the most important ones:

我们尚未达到ML平台的主导设计的原因有很多。 仅列举最重要的几个：

• Underlying technologies haven’t matured. Many of the technologies leveraged within an ML Platform are themselves early in their lifecycle. It is hard to build an ML Platform that provides continuously updated ML models when the ML framework used for said models makes backwards incompatible changes to its checkpointing format. Imagine trying to build the UI for a web app without the backend APIs having been defined. You will inadvertently have to go back and change things as the APIs evolve, and in the ML space APIs evolve rapidly.

  基础技术尚未成熟 。 ML平台中利用的许多技术本身都处于生命周期的早期。 当用于所述模型的ML框架对其检查点格式进行向后不兼容的更改时，很难构建一个提供持续更新的ML模型的ML平台。 想象一下，尝试在未定义后端API的情况下为Web应用程序构建UI。 随着API的发展，您将不经意地回过头去改变事物，并且在ML空间中，APISwift发展。

• ML Platform creators don’t know what they don’t know. I have spent countless hours talking to engineering teams who had grand plans for building the canonical ML Platform. In most cases they had a mental model of only about 20% of what was required to build an ML Platform and, as a result, vastly underestimated the difficulty of what they were embarking on. A quick anecdote of how I used to make this point at Google might help: If a random Google engineer wants to build a driverless car and asks their Director for headcount, the typical response is “That’s crazy hard and we are already investing massive resources into this; go work at Waymo”. However, if a random Google engineer wants to build an ML Platform and asks their Director for headcount, the typical response is “Sounds great, here have two engineers”. Of course, we eventually got to the point where the effort of building an ML Platform was generally recognized as being more like that of building a driverless car (with some level of exaggeration to make my own job sound more important), and most of Alphabet started using TFX.

  ML平台的创建者不知道他们不知道的东西。 我花了无数的时间与有宏大计划来构建规范化ML平台的工程团队交谈。 在大多数情况下，他们的思维模型仅占构建ML平台所需模型的20％，因此，大大低估了他们着手进行的难度。 快速讲一下我以前在Google上提出这一观点的方式可能会有所帮助：如果一位随机的Google工程师想要制造无人驾驶汽车并要求其董事人数，通常的回答是“这太疯狂了，我们已经在投入大量资源这个; 去Waymo工作” 。 但是，如果一位随机的Google工程师想要构建一个ML平台并要求其总监提供人员，则典型的回答是“听起来不错，这里有两名工程师” 。 当然，我们最终达到了一个共识，即建立ML平台的努力通常被认为更像是建造无人驾驶汽车(有些夸张的表达使我自己的工作听起来更重要)，而大部分Alphabet开始使用TFX 。

• ML Platform consumers don’t know what they don’t know. Especially in the enterprise space, there are many companies who buy so-called “ML Platforms” without knowing the features they should be expecting or the questions they should be asking. It is almost impossible for enterprises to evaluate these offerings because they all sound the same but provide vastly different sets of features. The way that a customer once put this to me is that “there is an equivalence problem in the ML Platform space”, meaning that every product they get pitched sounds equivalent and they don’t know the differences until it’s too late. Below is a graph I used in a talk at MLSys (previously SysML) earlier this year to make this point.

  ML平台用户不知道他们不知道的东西。 特别是在企业领域，有许多公司在购买所谓的“ ML平台”时却不知道他们应该期望的功能或他们应该问的问题。 企业几乎不可能评估这些产品，因为它们听起来都一样，但提供的功能却大不相同。 客户曾经这样说过： “ ML平台领域存在一个等效问题” ，这意味着他们获得的每个产品听起来都是等效的，直到为时已晚，他们才知道差异。 下面是我今年早些时候在MLSys (以前是SysML)的一次演讲中使用的图表来说明这一点。

AI开发人员工具存在尺寸问题 (AI Developer Tools have a Form Factor Problem)

The previous section should already spell trouble for the attentive reader. If we haven’t converged on a dominant design, how can we agree on the appropriate form factors? First, let me explain what I mean by form factor in this context. Usually, this term is used to refer either to electronic components (e.g. motherboards) or, closer to how I use it, to different incarnations of how technology is packaged for users. E.g., the iPhone defined the predominant form factor for smartphones. I misappropriate this term to summarize everything you would consider when you talk about the “product surface”, “user experience”, or “developer experience”. What do developers actually interact with when we say they are using an ML Platform?

上一节应该已经为专心的读者带来麻烦。 如果我们尚未收敛于主导设计，我们如何就合适的外形达成一致？ 首先，让我解释一下在这种情况下我所说的外形尺寸 。 通常，该术语用于指电子组件(例如母板)，或者更接近于我的用法，指的是为用户封装技术的不同形式。 例如，iPhone定义了智能手机的主要外形尺寸。 我不恰当地使用该术语来概括您在谈论“产品表面”，“用户体验”或“开发人员体验”时会考虑的所有内容。 当我们说开发人员正在使用ML平台时，开发人员实际上会与之交互？

Right now, the form factor for most AI developer tools is like the Wild West of different API surfaces and services. Let me illustrate this with an example. To cover a minimal set of technologies you would need to train and deploy an ML model, you could:

目前，大多数AI开发人员工具的外形就像是具有不同API表面和服务的Wild West。 让我用一个例子来说明。 为了涵盖您需要训练和部署ML模型的最少技术，您可以：

1. Use a data engineering product like Spark for wrangling data.使用Spark之类的数据工程产品处理数据。
2. Use a library like TensorFlow for training your ML model.使用TensorFlow之类的库来训练您的ML模型。
3. Use Docker for packaging up those models.使用Docker打包这些模型。
4. Use Kubernetes to orchestrate those Docker containers.使用Kubernetes编排这些Docker容器。

You could make the argument that there should be a separation of concerns; that Data Engineers should write the data pipelines, Data Scientists should train the models, and Software Engineers should write the deployment systems; and that an ML Platform couldn’t possibly provide all of these capabilities. But what I have seen time and again in enterprises is that this artificial separation of concerns (which is the result of technology boundaries drawn well before ML Platforms emerged) leads to significant slowdown, costly mistakes, and overall higher failure rates of ML projects.

您可以提出以下论点：应将关注点分开； 数据工程师应编写数据管道，数据科学家应训练模型，软件工程师应编写部署系统； 而且ML平台不可能提供所有这些功能。 但是我在企业中一次又一次地看到，这种人为的关注点分离(这是在ML平台出现之前就已经划定了技术界限的结果)会导致ML项目显着减慢，代价高昂的错误以及总体上更高的失败率。

We can’t assume that tools and processes created decades ago for Software Engineering are magically transferable to ML. E.g., you shouldn’t just check your ML model artifacts (which can be rather large in size and contain sensitive data) into version control systems intended for code. That’s why, at Databricks, we built the MLflow Model Registry to manage the versioning and deployment lifecycle of ML models. If you want to empower your Data Scientists or Software Engineers to manage the full ML lifecycle, these tools need to be accessible to a wide range of users, not just DevOps experts. At companies like Google it is not unusual for a single person to own the full lifecycle from data pipeline to model deployment. Others have come to the same realization and are creating a broad “ML Engineer” role for this very reason.

我们不能认为数十年前为软件工程创建的工具和流程可以神奇地转移到ML。 例如，您不应该仅将ML模型工件(可能很大，并且包含敏感数据)检查到用于代码的版本控制系统中。 因此，在Databricks，我们建立了MLflow模型注册表来管理ML模型的版本控制和部署生命周期。 如果您想让您的数据科学家或软件工程师管理整个ML生命周期，则这些工具需要广泛的用户访问，而不仅仅是DevOps专家。 在像Google这样的公司中，一个人拥有从数据管道到模型部署的整个生命周期并不罕见。 出于这个原因，其他人也已经实现了同样的认识，并且正在创建广泛的“ ML工程师”角色。

“We can’t assume that tools and processes created decades ago for Software Engineering are magically transferable to ML.”

“我们不能认为数十年前为软件工程创建的工具和流程可以神奇地转移到ML。”

尝试采用更一致的外形尺寸 (Attempts at more consistent Form Factors)

Some vendors, realizing that the target audience for solutions that require you to master Spark, TensorFlow, Docker, and Kubernetes, is limited, have attempted to create different form factors that abstract away this complexity. However, most of them fail in painful ways. Let me provide two illustrative examples:

一些供应商意识到需要您掌握Spark，TensorFlow，Docker和Kubernetes的解决方案的目标受众是有限的，因此他们试图创建不同的外形来消除这种复杂性。 但是，它们中的大多数以痛苦的方式失败了。 让我提供两个说明性示例：

• SQL ML: There are products, which shall remain unnamed in this post, that claim they “make machine learning as easy as writing SQL queries”. However, in order to do so, they let you register a snippet of Python code as a procedure, or they simply mirror the same Python APIs in SQL (e.g. to define layers of a neural network in your SQL query). Needless to say, just allowing someone to register Python code and call it from SQL isn’t really achieving anything new. In fact, it just makes everything harder (like debugging your Python code). And if you are using hardware accelerators (e.g. GPUs), you can see what I mean by violating the basic principles of levels of abstraction: Now your SQL query will throw errors that are specific to the hardware you run it on. Or, even worse, it will just silently fail and you have to go hunt for log files.

  SQL ML ：有些产品在这篇文章中将保持匿名，声称它们“使机器学习与编写SQL查询一样容易” 。 但是，为了这样做，它们允许您将Python代码片段注册为过程，或者它们只是在SQL中镜像相同的Python API(例如，在SQL查询中定义神经网络的层)。 不用说，仅允许某人注册Python代码并从SQL调用它并不能真正实现任何新功能。 实际上，这只会使一切变得更困难(例如调试Python代码)。 而且，如果您使用的是硬件加速器(例如GPU)，则可以通过违反抽象级别的基本原理来理解我的意思：现在，SQL查询将引发特定于您在其上运行的硬件的错误。 或者，甚至更糟的是，它只会静默地失败，而您必须去寻找日志文件。

• WYSIWYG/UI ML: Another class of products tries to provide no-code solutions for so-called citizen data scientists. Nice UI-based workflows are meant to guide users through the typical Data Science & ML model building steps. I have observed two common failure modes for this type of product: (1) At one or more steps in the workflow, commonly the modeling step, they require users to specify low-level parameters like L1 regularization. Requiring knowledge of what L1 regularization is, or how to pick a good value for it, misses the whole point of building an UI-based ML product. (2) In most cases, these tools only solve for the highest level of abstraction and don’t provide an “escape hatch” for when users reach its limits. As a result, many enterprises find UI-based ML tools falling short of solving real life use cases. These two reasons result in a typical product/market mismatch and most tools in this category don’t gain much traction beyond toy demos and POCs.

  所见即所得/ UI ML ：另一类产品试图为所谓的公民数据科学家提供无代码解决方案。 不错的基于UI的工作流旨在指导用户完成典型的数据科学和ML模型构建步骤。 我已经观察到这种产品的两种常见故障模式：(1)在工作流程中的一个或多个步骤(通常是建模步骤)，它们要求用户指定低级参数，例如L1正则化。 要求了解什么是L1正则化或如何为其选择合适的值，就错过了构建基于UI的ML产品的全部要点。 (2)在大多数情况下，这些工具只能解决最高级别的抽象，而无法在用户达到极限时提供“逃生阴影”。 结果，许多企业发现基于UI的ML工具无法解决现实生活中的用例。 这两个原因导致典型的产品/市场不匹配，并且该类别中的大多数工具在玩具演示和POC方面并没有获得太多关注。

The underlying issues here are, of course, ill-defined boundaries (because of the missing dominant design) and the creation of new form factors without respecting levels of abstractions. Much of this has to do with the speed of which ML tools are evolving, usually driven by research findings and open source contributions at the detriment of strict engineering principles (which would slow progress down). This balance between flexibility and stability is a function of the stage in the lifecycle of a technology, and it means that there will likely be significant changes in these tools as they mature. To give just one example for which I take partial blame: There used to be a TPUEstimator in TensorFlow. The Estimator API is fairly high level, and the TPUEstimator didn’t even try to hide the fact that it was making assumptions about the hardware it ran on (TPUs); a clear violation of levels of abstractions. In newer versions of the API the hardware assignment happens at a lower API level (as a distribution strategy).

当然，这里的潜在问题是边界不明确(由于缺少主导设计)以及在不考虑抽象级别的情况下创建了新的外形尺寸。 这很大程度上与ML工具的发展速度有关，通常是由研究结果和开源贡献驱动的，而这不利于严格的工程原理(这会减慢进度)。 灵活性和稳定性之间的平衡是技术生命周期中各个阶段的功能，这意味着随着这些工具的成熟，它们可能会发生重大变化。 仅举一个我应该部分负责的示例：TensorFlow中曾经有一个TPUEstimator 。 Estimator API的级别相当高，TPUEstimator甚至没有试图掩盖它是对其运行的硬件(TPU)进行假设的事实。 明显违反抽象级别。 在较新版本的API中，硬件分配发生在较低的API级别(作为分发策略 )。

选择AI堆栈时要当心IKEA效果 (Beware the IKEA effect when you pick an AI stack)

Finally, with neither a dominant design nor an appropriate form factor, it is not surprising that many enterprises are struggling with adopting ML Platforms, let alone transforming their companies into an “AI first” business model. Those who try often suffer from the IKEA effect.

最后，既没有主导设计也没有合适的外形尺寸，许多企业都在努力采用ML平台，这不足为奇，更不用说将其公司转变为“ AI优先”的业务模型了。 那些尝试的人经常遭受宜家的影响。

AI developer tools are slowly starting to find widespread use. Engineers love building things and they love acquiring new skills. As a result, many engineers take way-too-low-level ML courses online. I usually tell anyone who wants to listen that no Data Scientist or ML Engineer these days needs to know how things like backprop actually work. Yet, many people take online courses that teach just that. (To be fair, I too learned how to write most of the popular ML algorithms from scratch. But, then again, I am a PM for AI developer tools). All of these engineers, emboldened by their newly acquired knowledge about the nitty gritty details of ML, then go out and try to apply them to their enterprise businesses problems. This is where the IKEA effect comes in.

AI开发人员工具正在慢慢开始广泛使用。 工程师喜欢建造东西，也喜欢学习新技能。 结果，许多工程师在线上了太低级的ML课程。 我通常会告诉任何想听的人，这些天没有数据科学家或ML工程师需要知道backprop之类的东西是如何工作的。 但是，很多人都选择在线课程来教授这一点。 (公平地说，我也从头开始学习如何编写大多数流行的ML算法。但是，我又是AI开发人员工具的PM)。 所有这些工程师都对新近了解到的ML的具体细节感到鼓舞，然后出去尝试将其应用于企业业务问题。 这就是宜家效果的体现。

The IKEA effect refers to the phenomenon that people attribute more value to products they helped create. It turns out that this effect applies broadly to all kinds of products (furniture, cake mixes, toys, etc.). What I am conjecturing is that the same effect is predominant in companies with a strong engineering culture. An engineering team that built their own ML Platform from the ground up, flawed as it may be, will attribute more value to it than if they just bought something out-of-the-box from a vendor. They give it a fancy name, write blog posts about it, and everyone gets promoted.

宜家效应是指人们将更多的价值归功于他们帮助创造的产品的现象。 事实证明，这种效果广泛适用于所有产品(家具，蛋糕粉，玩具等)。 我猜想的是，在具有强大工程文化的公司中，同样的效果也很明显。 一个工程团队从头开始构建自己的ML平台(可能存在缺陷)，比从供应商那里开箱即用地购买东西时，将赋予它更多的价值。 他们给它起一个奇特的名字，写关于它的博客文章，每个人都被提升。

Of course, the same applies to any kind of new technology. However, no one these days would say “let’s build our own database from scratch”. The particular challenge with ML Platforms is that, because we lack a dominant design and common form factor, and people don’t know what they don’t know, it is far too easy to think that you can build something meaningful with just a few engineers. As the story goes, a software engineer goes and asks their Director for headcount to build an ML Platform…

当然，同样适用于任何一种新技术。 但是，如今没有人会说“让我们从头开始构建我们自己的数据库” 。 机器学习平台的特殊挑战在于，由于我们缺乏主导设计和通用的外形，而且人们不知道他们不知道的东西，因此很难想到仅用几个就可以构建出有意义的东西。工程师。 随着故事的发展，一位软件工程师开始请其总监来建立ML平台……

“An engineering team that built their own ML Platform from the ground up, flawed as it may be, will attribute more value to it than if they just bought something out-of-the-box from a vendor.”

“一个工程团队从头开始构建自己的ML平台(可能存在缺陷)，将比从供应商那里直接购买某些东西提供更多的价值。”

十年后，AI开发人员工具将是什么样？ (What will AI Developer Tools look like in 10 Years?)

Finally you may ask yourself, what will AI developer tools look like 10 years from now? If you’ve been around long enough you’ll probably say something like “OK, I got it Clemens, these are all common problems of any new technology. You could have written the same blog post about distributed data processing engines 20 years ago”. And I’d say “Thank you, that’s exactly my point”. If you think that, 10 years from now, millions of people will use low-level Python APIs to specify their exact model architecture (“I wonder if a skiplayer or a convolution would help here?”) and fiddle around with hundreds of parameters, I’d bet that you are wrong. In fact, in an ideal world, the entire process of building “data driven applications” (which is really the broader category that ML models fall under) is just a common part of any software engineer’s job without having to earn a PhD in AI or master Kubernetes.

最后，您可能会问自己，从现在开始十年后，AI开发人员工具将是什么样？ 如果您已经呆了很长时间，您可能会说“好吧，我知道了Clemens，这些都是任何新技术的常见问题。 您本可以在20年前写过一篇有关分布式数据处理引擎的博客文章 。” 我会说“ 谢谢，这正是我的意思 ”。 如果您认为从现在起10年后，数百万人将使用低级Python API来指定其确切的模型体系结构( “我想知道跳过层或卷积是否会在这里起到帮助作用？” )，然后摆弄数百个参数，我打赌你错了。 实际上，在理想的世界中，构建“数据驱动的应用程序”(这实际上是ML模型所涉及的更广泛的类别)的整个过程只是任何软件工程师工作中的常见部分，而无需获得AI博士学位或掌握Kubernetes。

At the risk of stating the obvious, here are my expectations of what will happen in the next couple of years to address the aforementioned challenges:

冒着明显的风险，我对未来几年应对上述挑战的期望如下：

• We will converge on a dominant design for ML Platforms. What do we think is “inside the box” when we talk about ML Platforms? Today, many vendors focus only on the ML training part, forgetting that most time in ML is spent with data wrangling. Most likely, one product will gain traction and lead the way in defining the category. Many other vendors will exit the market and others will conform to the dominant design.

  我们将集中在ML平台的主导设计上。 当我们谈论ML平台时，我们认为“框内”是什么？ 如今，许多供应商只专注于ML培训部分，而忘记了ML中的大部分时间都花在了数据整理上。 最有可能的是，一种产品将获得吸引力并引领类别的定义。 许多其他厂商将退出市场，而其他厂商将遵循主导设计。

• There will be a few meaningful form factors for different target audiences. We don’t need to have a single form factor. In fact, I’d argue that it is desirable to have different layers of abstraction. Each layer needs to be well defined and abstractions shouldn’t leak between layers. I would argue that we haven’t seen a good example of the highest level of abstraction (e.g., SQL or UI-based ML).

  对于不同的目标受众，将有一些有意义的形式因素。 我们不需要单一的外形。 实际上，我认为拥有不同的抽象层是可取的。 每一层都需要定义良好，抽象层之间不应泄漏。 我认为，我们还没有看到一个最高抽象级别的好例子(例如，SQL或基于UI的ML)。

• Enterprise customers will realize that building their own ML Platforms is not their comparative advantage. Of course, every company can hire an engineering team and try to build their own ML Platform. However, with a dominant design in place, it will be more obvious how futile of an effort this is, and that it is not (and should not be) the core competency of most companies. For most enterprises, value comes from applying ML Platforms to their business problems, not from building their own ML Platforms and maintaining them.

  企业客户将意识到，构建自己的ML平台并不是他们的比较优势。 当然，每个公司都可以聘请工程团队并尝试构建自己的ML平台。 但是，在采用了占主导地位的设计的情况下，这将变得更加明显，这是一项努力的徒劳，并且它不是(也不应该是)大多数公司的核心竞争力。 对于大多数企业而言，价值来自将ML平台应用于其业务问题，而不是来自构建自己的ML平台和维护它们。

As you may be able to guess, I have opinions on what a dominant design and good form factors for ML Platforms look like. If you are interested in solving these challenges, and defining the future of ML Platforms, I happen to be hiring an ML Platform Product Manager.

您可能会猜到，我对ML平台的主要设计和良好的外形有自己的看法。 如果您有兴趣解决这些挑战并定义ML平台的未来，那么我恰好聘请了ML平台产品经理。

Clemens Mewald leads the product team for Data Science and Machine Learning at Databricks. Previously he spent four years on the Google Brain team building AI infrastructure for Alphabet, including TensorFlow and TensorFlow Extended (TFX).

Clemens Mewald领导Databricks的数据科学和机器学习产品团队。 之前，他在Google Brain团队工作了四年，为Alphabet构建AI基础架构，包括TensorFlow和TensorFlow Extended(TFX)。