如果你想构建独特、有价值和快速的人工智能产品,就不要做其他人正在做的事情。我会告诉你该怎么做。

不该做什么

目前正在构建的绝大多数 AI 产品只是其他模型的包装器,例如那些本质上涉及通过 API 调用 ChatGPT 的模型。
请输入图片描述
虽然这非常容易——你发送自然语言并输出自然语言——它可以做一些非常酷的事情,但这种方法存在一些人们遇到的重大问题。
但是,我会向你展示一个解决方案。

问题#1:缺乏差异化

第一个主要问题是这不是差异化技术。如果你注意到一个人用 PDF 应用程序创建聊天,然后另外十几个人也这样做,然后 OpenAI 直接将其构建到 ChatGPT 中,那是因为没有人真正构建差异化的东西。他们使用一种简单的技术,带有预先训练的模型,任何人都可以在很短的时间内复制该模型。

在构建其独特价值主张是某种先进的人工智能技术的产品时,如此容易复制是一个非常冒险的位置。现在,当然,这里有一个完整的范围。如果你在光谱的右边,你所做的只是一个按钮,它向 ChatGPT 发送一些东西,并得到你向最终用户展示的响应——ChatGPT 基本上完成了所有工作——你在这里的风险最高。另一方面,如果你真的构建了一些实质性的技术和LLM,而OpenAI只帮助了一小部分,那么你可能处于一个更好的位置,但你仍然会遇到另外两个主要问题。

问题 #2:LLM 非常昂贵

您将遇到的第一个主要问题是成本。大型语言模型最好的部分是它们广泛的多功能性,但它们通过异常庞大和复杂来实现这一点,这使得它们的运行成本非常高。例如,据《华尔街日报》报道,最近 GitHub Copilot 每用户亏损,收费 10 美元,但平均成本为 20 美元,有些用户每月花费 GitHub 高达 80 美元。最糟糕的是,你可能不需要这么大的模型。您的用例可能不需要在整个 Internet 上训练的模型,因为 99.9% 的训练涵盖了与您的用例无关的主题。因此,虽然这种方法的易用性可能很诱人,但您可能会遇到这个常见问题,即用户想要支付的费用低于在大型语言模型上运行服务的成本。

问题 #3:LLM 非常慢

即使你是极少数成本经济学可能对你有利的情况,你仍然会遇到另一个主要问题:LLM 非常缓慢。现在,对于所有应用程序来说,这并不是一个大问题。对于像 ChatGPT 这样的用例,一次阅读一个单词是常态,这可能没问题。但是,在不打算逐字阅读文本的应用程序中,并且在继续工作流的下一步之前需要整个响应,这可能会带来一个重大问题。举个例子,当我们开始开发 Builder 的 Visual Copilot 时,我们希望只需单击一下按钮即可将任何设计转换为高质量的代码,我们探索的方法之一是使用 LLM 进行转换。

我们遇到的关键问题之一是严重的时间延迟。当将整个设计规范传递到 LLM 中并逐个令牌接收新的表示标记时,生成响应将需要几分钟时间,因此不切实际。而且由于 LLM 返回的表示不是人类所感知的,因此加载状态只是一个微调器——并不理想。

问题 #4:LLM 不能定制那么多

如果出于某种原因,性能对你来说仍然不是问题,并且你的用户不关心你的竞争对手很容易复制的缓慢而昂贵的产品,你仍然可能会遇到另一个主要问题——LLM 不能被定制那么多。是的,它们都支持微调,微调可以逐步帮助模型更接近您需要的内容。但在我们的例子中,我们尝试使用微调来提供 Figma 设计并从另一端获取代码。但无论我们给出多少例子,它都没有改善。我们留下了一些缓慢、昂贵和劣质的东西。就在那时,我们意识到我们必须采取不同的方法。

解决方案:创建自己的工具链

我们必须做些什么呢?我们必须创建自己的工具链。
请输入图片描述
在本例中,我们结合了微调的 LLM、我们编写的自定义编译器和自定义训练的模型。这并不像看起来那么难。如今,您不必成为数据科学家或机器学习博士学位即可训练自己的模型。任何有经验的开发人员都可以做到。这样,你就可以构建更快、更可靠、更便宜、更差异化的东西。您也不必担心山寨产品或开源克隆会在一夜之间产生。这不仅仅是一个理论。大多数(如果不是全部)高级人工智能产品都是这样构建的。

关于人工智能产品的常见误解

很多人对人工智能产品的构建方式存在重大误解。我注意到,他们经常认为所有的核心技术都是由一个超级智能模型处理的,该模型经过大量输入训练,以提供正确的输出。

以自动驾驶汽车为例。很多人的印象是,有一个巨大的模型,它接收所有这些不同的输入,如摄像头、传感器、GPS 等,然后通过人工智能对其进行处理,然后出现另一边的动作,比如右转。但这与事实相去甚远。汽车本身并不是一个大的人工智能大脑。所有这些专用模型都与普通代码相连,而不是与普通代码相连的整个专用模型工具链——例如用于查找和识别物体的计算机视觉模型、预测决策、预测他人的行为或用于理解语音命令的自然语言处理——所有这些专用模型都与大量普通代码和逻辑相结合,从而产生最终结果——一辆可以自动驾驶的汽车。现在,请记住,自动驾驶汽车是一个非常复杂的例子,它包含的模型比我在这里提到的要多得多。

要构建自己的产品,您不需要如此复杂的东西,尤其是在开始时。请记住,自动驾驶汽车并不是一夜之间诞生的。我的 2018 年普锐斯能够自行停车,在离物体太近时自动停车,以及许多其他几乎不使用 AI 的东西。随着时间的流逝,越来越多的层被添加到汽车中,以做越来越高级的事情,比如纠正车道偏离,或者最终做出从一个地方开车到另一个地方的整个决定。但像所有软件一样,这些东西是分层构建的,一个在下一个之上。

从哪里开始构建真正的 AI

我强烈建议您探索我们用于 Visual Copilot 的方法,用于您自己的 AI 解决方案。这是一种简单但违反直觉的方法。

最重要的是一开始不要使用人工智能。使用常规编程实践探索问题空间,以确定哪些领域首先需要专门的模型。请记住,制作“超模”通常不是正确的方法。我们不想将大量的 Figma 数据发送到模型中,然后从另一端获取完成的代码。仅用一个模型即可解决这是一个非常复杂的问题。当您考虑到我们支持的所有不同框架以及样式选项和自定义时,使用所有这些附加数据重新训练此模型是不可行的。

它可能会变得如此复杂、缓慢和昂贵,以至于我们的产品甚至可能永远不会发货。相反,我们考虑了这个问题,并说,好吧,如果没有人工智能,我们怎么能解决这个问题?如果没有人工智能最擅长的专业决策类型,我们能走多远才能实现不可能?因此,我们分解了问题并说,好吧,我们需要将每个节点转换为我们可以在代码中表示的内容。我们需要详细了解如何使用图像、背景和前景等元素。最重要的是,我们需要复杂地了解如何使任何输入具有响应性。在那之后,我们开始考虑更复杂的例子,并意识到在很多情况下,需要将许多图层转换为一个图像。

首先手动编写逻辑代码

我们开始编写手动编码的逻辑来说明一组项目是否在垂直堆栈中,该堆栈可能应该是一个 flex 列,而并排的项目可能应该是一个 flex 行。我们尽可能地创建了所有这些不同类型的复杂算法,以便在我们开始达到极限之前自动将设计转换为响应式代码。根据我的经验,无论你认为极限在哪里,它可能都更远。但是,在某个时候,你会发现有些事情几乎不可能用标准代码完成。

例如,自动检测哪些层应该变成一个图像,这是人类感知非常擅长理解的事情,但这不一定是正常的命令式代码。在我们的例子中,我们用 JavaScript 编写了所有这些内容。

添加专门的 AI 来填补空白

幸运的是,训练自己的对象检测模型以使用 AI 解决这一需求并不难。例如,像谷歌的 Vertex AI 这样的产品有一系列常见的模型类型,你可以有效地训练自己——其中之一就是对象检测。我可以使用 GUI 选择它,然后准备数据并将其作为文件上传。对于像这样成熟的模型类型,归根结底就是创建数据。现在,事情变得有趣的地方是找到创造性的方法来生成您需要的数据。一个很棒的、用于生成数据的大量免费资源就是互联网。

我们探索的一种方法是使用 puppeteer 在 Web 浏览器中自动打开网站,截取网站的屏幕截图,并遍历 HTML 以查找 img 标签。然后,我们使用图像的位置作为输出数据,使用网页的屏幕截图作为输入数据。现在,我们完全拥有了我们需要的东西——源图像和所有子图像的坐标,以训练这个 AI 模型。
请输入图片描述

将代码 + AI 模型组合成一个完整的解决方案

使用这些技术,我们用专门的 AI 模型填充未知数并将它们组合在一起,这就是我们能够产生如下最终结果的方式:我只需选择我的设计,单击“生成代码”,只需等待大约一秒钟,然后启动 Builder.io。然后在 Builder 中,我们得到了一个完全响应的网站,其中包含您可以完全自定义的高质量代码。它支持多种框架和选项,而且速度非常快,因为我们所有的模型都是专门为此目的而构建的。我们以极低的成本提供此功能,提供慷慨的免费套餐,这对我们的客户来说非常有价值,帮助他们节省了大量时间。

控制自己的模型的好处

最好的部分是,这仅仅是个开始。

好处#1:你掌握自己的命运

这种方法最好的部分之一是我们完全拥有模型,因此我们可以不断改进它们。我们不只是在包装别人的模型。如果你完全依赖别人的模型,比如 OpenAI,那么在任何有保证的时间线内,你的用例都会变得更智能、更快或更便宜。而你通过快速的工程和微调来控制它的能力是严重有限的。但是,由于我们拥有自己的模型,因此我们每天都在进行重大改进。当新设计导入效果不佳时(这种情况仍处于测试阶段),我们依靠用户反馈来快速改进,每天都在进行改进。

好处#2:您可以控制隐私

通过这种方法,我们永远不必担心缺乏控制。例如,当我们开始与一些大型且注重隐私的公司作为潜在的早期测试版客户交谈时,最常见的反馈之一是他们无法使用 OpenAI 或任何使用 OpenAI 的产品。他们的隐私要求优先考虑确保他们的数据永远不会进入他们不允许的系统。在我们的案例中,由于我们控制了整个技术,因此我们可以将模型保持在极高的隐私标准。谢天谢地,因为如果我们依赖其他公司(就像许多其他公司一样),我们就会失去一些严肃的业务。对于LLM步骤,我们可以将其关闭(因为它纯粹是件好事),或者公司可以插入自己的LLM。这些 LLM 可能是一个完全内部构建的模型,是他们自己的 OpenAI 企业实例的分支 llama2 ,或者完全是其他东西。

结论

因此,如果你想构建 AI 产品,我强烈建议你采用与 Builder 类似的方法。尽管听起来很奇怪,但请尽可能长时间地避免在您的项目中使用 AI。然后,当你开始发现标准编码不能很好地解决的特定问题时——但成熟的人工智能模型可以——开始生成你自己的数据,并使用你可以找到的各种现成的工具训练你自己的模型。仅在需要模型的地方将模型连接到代码。我想强调的是:尽可能少地使用人工智能。归根结底,“普通”代码是你所拥有的最快、最可靠、最具确定性、最容易调试、最容易修复、最易于管理、最易于测试的代码。但魔力将来自你使用人工智能模型的小而关键的领域。

迫不及待地想看看你建造的令人敬畏的东西。

原文:https://www.builder.io/blog/build-ai