换一种方式做AI产品

如果你想构建独特、有价值且快速的 AI 产品，请不要做其他人正在做的事情。我会告诉你该怎么做。

1、不该做什么

目前正在构建的绝大多数 AI 产品只是其他模型的包装器，例如那些本质上涉及通过 API 调用 ChatGPT 的产品。

虽然这非常简单——你发送自然语言并得到自然语言——它可以做一些非常酷的事情，但人们遇到了这种方法的一些主要问题。

但是，我会向你展示一个解决方案。

1.1 问题 1 - 缺乏差异化

第一个主要问题是这不是差异化技术。

如果你注意到一个人使用 PDF 应用程序创建聊天，然后另外十几个人也这样做，然后 OpenAI 直接将其构建到 ChatGPT 中，那是因为那里没有人真正构建了差异化的东西。

他们使用一种简单的技术，使用预先训练的模型，任何人都可以在很短的时间内复制。

当构建的产品的独特的价值主张是某种先进的人工智能技术时，很容易被复制是非常危险的。

现在，当然，这里有一个完整的范围。

如果你在滑杆的右侧，你所做的只是一个按钮，将某些内容发送到 ChatGPT 并得到一个向最终用户展示的响应——ChatGPT 基本上完成了所有工作——你在这里面临的风险最高。

另一方面，如果你真的建立了一些实质性的技术和 LLM，而 OpenAI 只协助了一个小而关键的部分，那么你可能会处于更好的位置，但你仍然会遇到另外两个主要问题。

1.2 问题 2 - LLM 非常昂贵

你遇到的第一个主要问题是成本。大型语言模型的最大优点是其广泛的通用性，但它们通过异常庞大和复杂来实现这一点，这使得它们的运行成本极高。

例如，根据《华尔街日报》报道，最近 GitHub Copilot 在每个用户上都处于亏损状态，收费 10 美元，但平均成本为 20 美元，有些用户每月向 GitHub 支付的费用高达 80 美元。

最糟糕的是，你可能不需要这么大的模型。你的用例可能不需要在整个互联网上训练的模型，因为 99.9% 的训练涵盖与你的用例无关的主题。

因此，虽然这种方法的简便性可能很诱人，但你可能会遇到这个常见问题，即你的用户愿意支付的费用低于在大型语言模型上运行你的服务的成本。

1.3 问题 3 - LLM 速度慢得令人难以忍受

即使是成本经济性可能对你来说还不错的少数情况，你仍会遇到另一个主要问题：LLM 速度慢得令人难以忍受。

现在，这对所有应用程序来说都不是大问题。对于 ChatGPT 等用例，一次阅读一个单词是常态，这可能没问题。

但是，在不适合逐字输出文本的应用程序中，在继续工作流程的下一步之前需要完整的响应，这可能会带来重大问题。

例如，当我们开始研究 Builder 的 Visual Copilot 时，我们希望单击一下按钮即可将任何设计转换为高质量代码，我们探索的方法之一是使用 LLM 进行转换。

我们遇到的关键问题之一是显着的时间延迟。当将整个设计规范传递到 LLM 并逐个令牌接收新的表示时，生成响应需要几分钟，这使其不切实际。

并且由于 LLM 返回的表示不是人类能够感知的，因此加载状态只是一个旋转器——并不理想。

1.4 问题 4 - LLM 无法进行太多定制

如果出于某种原因，性能仍然不是你的问题，并且你的用户不关心拥有速度慢且价格昂贵且容易被竞争对手复制的产品，那么你仍然可能会遇到另一个主要问题——LLM 无法进行太多定制。

是的，它们都支持微调，微调可以逐步帮助模型更接近你的需求。但在我们的案例中，我们尝试使用微调来提供 Figma 设计并将代码发送到另一端。

但无论我们给模型提供了多少示例，它都没有改善。我们得到的是速度慢、价格昂贵且质量低劣的东西。就在那时，我们意识到我们必须采取不同的方法。

2、解决方案：创建自己的工具链

我们必须做什么？我们必须创建自己的工具链。

在这种情况下，我们结合了经过微调的 LLM、我们编写的自定义编译器和自定义训练的模型。

这并不像看起来那么难。如今，你不必是数据科学家或机器学习博士就可以训练自己的模型。

任何有一定经验的开发人员都可以做到。这样，你就可以构建速度更快、更可靠、更便宜、差异化更强的东西。你也不必担心一夜之间出现山寨产品或开源克隆。

这不仅仅是一种理论。大多数（如果不是全部）高级 AI 产品都是这样构建的。

2.1 关于 AI 产品的常见误解

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

以自动驾驶汽车为例。很多人的印象是，有一个巨大的模型可以接收所有这些不同的输入，如摄像头、传感器、GPS 等，并通过 AI 对其进行处理，然后输出另一侧的动作，例如右转。

但这与事实相去甚远。自动驾驶汽车并不是一个巨大的 AI 大脑。

并非是整个由专用模型组成的工具链，所有模型都与普通代码相连——例如用于查找和识别物体的计算机视觉模型、预测决策、预测他人行为的模型或用于理解语音命令的自然语言处理——所有这些专用模型都与大量普通代码和逻辑相结合，最终产生结果——一辆可以自动驾驶的汽车。

现在，请记住，自动驾驶汽车是一个非常复杂的例子，它包含的模型比我在这里提到的要多得多。

对于构建自己的产品，你不需要如此复杂的东西，尤其是在刚开始时。

请记住，自动驾驶汽车不是一夜之间诞生的。我的 2018 年普锐斯能够自动停车，在离物体太近时自动停车，以及使用很少或根本不使用人工智能进行许多其他操作。

随着时间的推移，汽车中增加了越来越多的层来执行越来越高级的事情，例如纠正车道偏离，或最终做出从一个地方开车到另一个地方的完整决定。

但与所有软件一样，这些东西都是层层构建的，一层接一层。

2.2 从哪里开始构建真正的 AI

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

最重要的是不要一开始就使用 AI。

使用正常的编程实践探索问题空间，以确定哪些领域首先需要专门的模型。

请记住，制作“超级模型”通常不是正确的方法。我们不想将大量 Figma 数据发送到模型中，然后在另一端获得完成的代码。

这将是一个仅用一个模型解决的极其复杂的问题。当您考虑到我们支持的所有不同框架以及样式选项和自定义时，使用所有这些额外数据重新训练此模型是不可行的。

它可能会变得如此复杂、缓慢和昂贵，以至于我们的产品可能永远不会发货。

相反，我们考虑了这个问题并说，好吧，如果没有 AI，我们如何解决这个问题？如果没有 AI 最擅长的那种专业决策，在变得不可能之前，我们能走多远？

因此，我们将问题分解，然后说，好吧，我们需要将每个节点转换为我们可以用代码表示的东西。

我们需要详细了解如何使用图像、背景和前景等元素。最重要的是，我们需要深入了解如何使任何输入具有响应性。

之后，我们开始考虑更复杂的示例，并意识到有很多情况下需要将许多层转换为一张图片。

2.3 首先手工编写逻辑

我们开始编写手工编写的逻辑，以说明如果一组项目位于垂直堆栈中，则可能应该是弹性列，而并排的项目可能应该是弹性行。

在开始达到极限之前，我们尽可能地创建所有这些不同类型的复杂算法来自动将设计转换为响应式代码。

根据我的经验，无论你认为极限在哪里，它可能都远得多。但是，在某个时候，你会发现有些事情几乎不可能用标准代码完成。

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

2.4 添加专门的 AI 来填补空白

幸运的是，训练自己的对象检测模型以使用 AI 解决这一需求并不难。例如，像 Google 的 Vertex AI 这样的产品有一系列常见的模型类型，你可以有效地训练自己 - 其中之一就是对象检测。

我可以使用 GUI 选择它，然后准备数据并将其作为文件上传。

对于像这样的成熟模型类型，归根结底就是创建数据。

现在，事情变得有趣的是找到生成所需数据的创造性方法。

一个很棒的、大量的免费数据生成资源就是互联网。

我们探索的一种方法是使用 puppeteer 自动在 Web 浏览器中打开网站、截取网站屏幕截图并遍历 HTML 以查找 img 标签。

然后，我们将图像的位置用作输出数据，将网页屏幕截图用作输入数据。现在，我们得到了我们所需要的东西——源图像和所有子图像的坐标，用于训练这个 AI 模型。

2.5 将代码 + AI 结合起来，形成完整的方案

使用这些技术，我们用专门的 AI 模型填充未知数并将它们结合起来，这就是我们能够产生这样的最终结果的方式：我只需选择我的设计，单击“生成代码”，等待大约一秒钟，然后启动 Builder.io。

然后在 Builder 中，我们得到一个完全响应的网站，其中包含你可以完全自定义的高质量代码。它支持各种框架和选项，而且速度非常快，因为我们的所有模型都是为此目的专门构建的。

我们以极低的成本提供这项服务，提供慷慨的免费套餐，这对我们的客户非常有价值，帮助他们节省大量时间。

3、控制自己的模型的好处

最好的部分是，这只是一个开始。

• 好处 1：你可以掌控自己的命运

这种方法最好的部分之一是我们完全拥有模型，因此我们可以不断改进它们。我们不仅仅是包装别人的模型。

如果你完全依赖别人的模型，比如 OpenAI，那么就不能保证它会在任何保证的时间内变得更智能、更快或更便宜。而且，你通过及时的工程和微调来控制它的能力受到严重限制。

但由于我们拥有自己的模型，我们每天都在进行重大改进。

当新设计导入效果不佳时（这在测试版中仍然会发生），我们依靠用户反馈快速改进，每天都会发布改进。

• 好处 2：你可以控制隐私

通过这种方法，我们永远不必担心缺乏控制。例如，当我们开始与一些大型且注重隐私的公司交谈，将其作为潜在的早期 beta 客户时，最常见的反馈之一是他们无法使用 OpenAI 或任何使用 OpenAI 的产品。

他们的隐私要求优先确保他们的数据永远不会进入他们不允许的系统。

在我们的案例中，因为我们控制着整个技术，所以我们可以将我们的模型保持在极高的隐私标准下。谢天谢地，因为如果我们依赖其他公司（就像许多其他公司一样），我们就会失去一些重要的业务。

对于 LLM 步骤，我们可以关闭它（因为有它纯粹是件好事），或者公司可以插入他们自己的 LLM。这些 LLM 可能是完全内部构建的模型、llama2 的分支、他们自己的 OpenAI 企业实例或其他完全不同的东西。

4、结束语

因此，如果你想构建 AI 产品，我强烈建议你采取与 Builder 类似的方法。

听起来很奇怪，但请尽可能长时间避免在你的项目中使用 AI。然后，当你开始发现标准编码无法很好解决的特定问题（但成熟的 AI 模型可以）时，开始使用各种现成的工具生成自己的数据并训练自己的模型。

仅在需要时将模型连接到代码。

我想强调这一点：尽可能少地使用 AI。归根结底，“普通”代码是你拥有的最快、最可靠、最确定、最容易调试、最容易修复、最容易管理和最容易测试的代码。

但奇迹将来自于你使用 AI 模型的细小但关键的领域。

迫不及待地想看到你建造的精彩事物。

原文链接：Don’t Build AI Products The Way Everyone Else Is Doing It

BimAnt翻译整理，转载请标明出处