“长寿” AI 产品的背后：请手动编码，少用 AI 模型！

译者 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

如果你想打造独一无二、有价值且快速的 AI 产品，就不要像其他人那样做——接下来，我会告诉你应该怎么做。

不应该做什么

目前正在构建的绝大多数 AI 产品，都只是对其他模型的封装，例如一些本质上是通过 API 调用 ChatGPT 的 AI 产品。虽然这种方法非常简单：用户输入自然语言，AI 产品输出自然语言，还可以做一些非常酷的事情，但开发者在使用这种方法时会遇到一些重大问题。 

问题 1：缺乏差异化

第一个主要问题是：这不是差异化技术。举个例子，如果你发现有个人创建了一个 PDF 聊天应用，很快会有十几个人也这样做，接着说不定 OpenAI 会直接将其构建到 ChatGPT 中。

为什么？因为在这过程中，没有人真正构建出了差异化的东西。他们使用的是一种简单的技术，只要预先训练好的模型，任何人都可以在很短的时间内进行复制。

当你想打造一款以某种先进 AI 技术为独特价值的产品时，如此容易被复制是非常危险的。但这具体也分为两种情况：

（1）如果你处于右边这种情况，即让 ChatGPT 基本上完成所有工作，你起到的只是一个按钮的作用：向 ChatGPT 发送一些东西，然后得到一个回复，再向你的最终用户展示。那么，你被复制的风险最高。 

（2）反之，如果你确实构建了一些实质性技术和 LLM，而 OpenAI 只是协助帮你完成了一小部分关键工作，那么你的处境可能会好一些，但仍然会遇到下面几个主要问题。

问题 2：LLM 非常昂贵

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

举个例子，据《华尔街日报》报道，最近 GitHub Copilot 向每位用户收取 10 美元的费用，但平均成本却高达 20 美元，而有些用户每月花费 GitHub 高达 80 美元。最糟糕的是，你可能并不需要这么大的模型：你的 AI 产品，不需要一个在整个互联网上训练过的模型，其 99.9% 的训练内容可能与你的产品定位毫不相关。 

因此，虽然这种方法的便捷性很诱人，但你可能会遇到这样一个常见问题：你的用户所希望支付的费用，会低于你支付给大型语言模型服务所需的费用。 

问题 3：LLM 慢得令人痛苦 

就算你真的是富豪，支撑得起 LLM 的运行成本，但你仍然会遇到一个大问题：LLM 慢得令人痛苦。 

当然，这并不是所有应用都有的大问题。对于像 ChatGPT 这样每次只读一个单词的用例来说，可能没什么问题。然而，在不需要逐字读取文本的应用中，在进入工作流的下一个步骤之前需要完整的响应，这就会带来很大的问题。 

举例来说，当我们开始开发 Builder 的 Visual Copilot 时，希望只需点击一个按钮就能将任何设计转化为高质量代码，我们探索的方法之一就是用 LLM 进行转换。我们遇到了一个关键问题：时间上存在严重延迟。当我们把整个设计规范传递给 LLM 并逐个标记接收新的表示时，生成响应将花费几分钟时间！

此外，由于 LLM 返回响应的过程并非人类所能感知到的，加载状态只是一个旋转器，这也并不理想。 

问题 4：无法对 LLM 进行太多定制 

如果出于某种原因，LLM 性能对你来说不是什么大问题，你的用户也不在乎拥有一个既慢又贵且容易被竞争对手复制的产品，那么你可能还会遇到另一个大问题：LLM 无法进行太多定制。 

是的，LLM 都支持微调，这可以逐步帮助模型更接近你的需求。但从我们团队曾尝试用微调来提供 Figma 设计，并从另一端获得代码。可无论我们给模型提供多少示例，它都没有任何改进。最终展现给我们的，就是缓慢、昂贵和质量低劣的结果。这时，我们意识到必须采取不同的方法。 

学着创建自己的工具链

面对以上问题，我们应该做些什么呢？答：创建自己的工具链。

下面，我们将结合微调的 LLM、编写的自定义编译器和自定义训练的模型展开讲解。这没有看起来那么难，你不必成为数据科学家或机器学习博士即可训练自己的模型，任何有经验的开发人员都可以做到。 

这样，你就可以构建更快、更可靠、更便宜、更差异化的东西，并且也不必担心山寨产品或开源克隆会在一夜之间产生。这不仅仅是一个理论化的想法，大多数高级 AI 产品都是这样构建的。 

关于 AI 产品的常见误解

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

以自动驾驶汽车为例。很多人对它的印象是，里面有一个巨大的 AI 模型，它能接收所有不同的输入，如摄像头、传感器、GPS 等，然后通过 AI 对其进行处理并推算出下一个动作——这与事实相差甚远，汽车本身并不是一个 AI 大脑。 

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

请记住，自动驾驶汽车是一个非常复杂的例子，它包含的模型比我在上面提到的还要多得多。但在构建自己的产品时，尤其是在开始时，我们并不需要如此复杂的东西。要知道，自动驾驶汽车并不是一夜之间诞生的，例如 2018 年我的普锐斯还只能自动停车，许多其他功能几乎都无关 AI。但随着时间推移，越来越多的层被添加到汽车中，可以做越来越高级的事情，比如纠正车道偏离，或实现从一个地方开车到另一个地方的整个过程。 

但和所有软件一样，这些东西是分层构建的，一个基于一个。 

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

围绕这个问题，我觉得可以参考构建 Visual Copilot 的方法，很简单但违反直觉：最重要的是，不要一开始就使用 AI。先用常规编程实践探索问题空间，以确定哪些领域首先需要专门的模型。 

要记住，制作“超级模型”通常不是正确方法。我们不想将大量 Figma 数据发送给模型，然后直接在另一端得到完成的代码，因为这是一个极其复杂的问题，仅用一个模型无法解决。当考虑到我们支持的所有不同框架、样式选项和自定义时，用所有这些额外数据重新训练这个模型是不可行的——它会变得很复杂、缓慢和昂贵，导致我们的产品可能永远都不会上市。 

所以我们开始思考：如果没有 AI，要怎么能解决这个问题？如果没有 AI 最擅长的专业决策，我们还能走多远？把这些问题分解之后，我们决定：需要将每个节点转换为可以在代码中表示的内容。 

我们要详细了解如何使用图像、背景和前景等元素，要了解如何使任何输入具有响应性。在那之后，我们开始考虑更复杂的例子，并意识到在很多情况下，需要将许多图层转换为一个图像。 

首先手动编写逻辑代码

我们开始编写手动编码的逻辑，来说明一组项目是否在垂直堆栈中，该堆栈可能应该是一个 flex 列，而并排的项目可能应该是一个 flex 行。为此，我们尽可能地创建了所有这些不同类型的复杂算法，以便我们在达到极限之前自动将设计转换为响应式代码。

根据我的经验，无论你认为极限在哪里，它可能都远不止于此。而在某个时候，你会发现有些事情用标准代码几乎是不可能完成的。例如，自动检测哪些层应该变成一个图像——这是人类感知非常擅长理解的事情，但不一定是正常命令式代码可以解决的。

让专门的 AI 来填补缺陷

幸运的是，训练你自己的目标检测模型来解决这个问题并不难。例如，像谷歌 Vertex AI 这样的产品就有一系列常见的模型类型，你可以用它来训练自己的目标检测模型：用 GUI 选择它，然后准备数据并将其作为文件上传。 

对于像这样成熟的模型类型，归根结底就是创建数据。所以现在，让事情变得有趣的地方是找到生成所需数据的创造性方法。其中，一个很棒的、用于生成数据的大量免费资源就是互联网。 

我们探索的一种方法是使用 puppeteer 在 Web 浏览器中自动打开网站，截取网站截图，并遍历 HTML 以查找 tags.img。然后，我们用图像的位置作为输出数据，使用网站截图作为输入数据，从而就完全拥有了我们需要的东西：一个源图像和所有子图像的坐标，以训练这个 AI 模型。 

通过代码 + AI模型的结合，我们组合成了一个完整的解决方案，最终实现了产品目标：用户可自己设计出一个网站，支持多种框架和选项，并提供可完全自定义的高质量代码，而且速度非常快——因为我们所有的模型都是专门为此目的而构建的。 

控制自己模型的好处 

最大的好处是，这仅仅是个开始。 

好处 1：掌握自己的命运 

如果你完全依赖别人的模型，例如 OpenAI，那么在有保证的时间线内，你的产品会变得更智能、更快或更便宜。可如果你想通过快速的工程和微调来控制它，能力就非常有限了。

但是，由于我们完全拥有自己的模型，因此我们可以不断改进它们、进行重大改进，而不只是在包装别人的模型。当新设计导入效果不佳时，我们也可以依靠用户反馈来快速改进。 

好处 2：可以控制隐私

通过这种方法，我们永远不必担心缺乏控制。例如，当我们开始与一些大型且注重隐私的公司作为潜在的早期测试版客户交谈时，最常见的反馈之一是他们不会用 OpenAI 或任何使用 OpenAI 的产品——他们的隐私要求优先考虑：确保其数据永远不会进入其他不被允许的系统。

那么由于我们控制了整个技术，因此我们可以将模型保持在极高的隐私标准。如果我们依赖其他公司（就像许多其他公司一样），我们就会失去这些业务。

结论

因此，如果你想构建 AI 产品，我强烈建议你采用与我们类似的方法：尽管听起来很奇怪，但请尽可能长时间地避免在你的项目中使用 AI。

直到当你开始发现标准编码不能很好地解决的特定问题、而成熟的 AI 模型可以做到时，再开始生成你自己的数据，并使用可以找到的各种现成工具来训练你的模型——记住一句话：仅在需要模型的地方，将模型连接到代码。 

总之，我想强调的是：归根结底，”普通“代码才是你所拥有的最快、最可靠、最具确定性、最容易调试、最容易修复、最易于管理、最易于测试的代码，而魔法将来自你使用 AI 模型的那些小而关键的领域。 

最后，期待能看到你所建造的令人惊叹的东西。

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

推荐阅读：