如果你想打造独特、有价值且快速的人工智能产品，就不要去做其他人正在做的事情。我会告诉你应该做什么。
不该做什么
目前正在构建的绝大多数AI产品只是其他模型的包装器，例如那些本质上涉及通过API调用ChatGPT的产品。
虽然这非常容易——你输入自然语言然后得到自然语言的输出——并且它能够做出一些非常酷的事情，但这种方法存在一些人们正在遇到的大问题。
但是，我会向他们展示一个解决方案。
问题1：缺乏差异化
第一个主要问题是这不是一种有区别的技术。
如果你注意到一个人用PDF应用程序创建了一个聊天，然后另外十几个人也这样做了，然后OpenAI直接将其构建到ChatGPT中，那是因为那里没有人真正构建了有区别的东西。
他们使用了一种简单的技术，使用了一个预先训练好的模型，任何人都可以在很短的时间内复制。
当构建一个其独特价值主张是某种类型的高级人工智能技术的产品时，这将是一个很容易被复制的非常冒险的立场。
当然，这里有一个完整的范围。
如果你处在这个谱系的正确一端，你所做的一切不过是一个按钮，它将某些东西发送给ChatGPT并得到一个回应，然后你向你的终端用户展示这个回应——基本上ChatGPT做了所有的工作——你在这里的风险最高。
另一方面，如果你实际上建立了一些实质性的技术，并且大型语言模型（LLMs）在其中只提供了一小部分但至关重要的帮助，那么你可能会处于一个更好的位置，但你仍然会遇到另外两个主要问题。
问题2：有限寿命机器非常昂贵
首先，你会遇到的一个主要问题是成本。大型语言模型最大的优点是它们广泛的多样性，但它们通过异常庞大和复杂来实现这一点，这使得它们运行起来非常昂贵。
例如，根据《华尔街日报》的报道，最近GitHub Copilot每个用户损失的钱，收费10美元，但平均成本20美元，一些用户给GitHub带来了高达80美元的成本_每月_.
最糟糕的是，您可能并不需要如此庞大的模型。 您的用例可能不需要一个在互联网的全部内容上训练的模型，因为99.9％的训练涵盖与您的用例无关的主题。
所以，尽管这种方法的简便性可能很诱人，但你可能会遇到一个常见的问题，即你的用户愿意支付的费用低于在大型语言模型上运行你的服务的成本。
问题3：LLMs慢得让人痛苦
即使你是罕见的例子，成本经济学可能对你来说是可行的，你仍然会遇到一个更大的问题：LLMs的速度非常慢。
现在，对于所有应用程序来说，这不是一个巨大的问题。对于像ChatGPT这样的用例，一次读取一个词是常态，这可能是可以的。
然而，在那些不希望逐字阅读文本的应用中，以及在继续工作流程的下一步之前期望获得整个响应的地方，这可能带来一个重大问题。
例如，当我们开始致力于构建者的时候视觉副驾驶我们希望实现一键将任何设计转换为高质量的代码，我们探索的方法之一是使用基于语言的模型进行转换。
我们遇到的一个关键问题就是显著的时间延迟。将整个设计规范传给一个LLM并逐个接收新的表示令牌，生成响应需要花费数分钟，这使得它变得不切实际。
而由于LLM返回的表现并非人类所感知的，载入状态仅仅是一个旋转器——这并不理想。
问题 #4：LLMs 不能定制那个非常
如果出于某种原因，性能对您来说仍然不是问题，并且您的用户不在乎拥有一个速度慢且成本高昂的产品，这种产品很容易被竞争对手复制，那么您很可能还会遇到另一个主要问题——LLMs无法进行大量定制。
是的，他们都支持微调，微调可以逐步帮助模型更接近您所需要的。但在我们的情况下，我们尝试使用微调来提供Figma设计，并从另一端获得代码。
但不管我们给模型提供多少例子，它都没有改进。我们得到的是一些缓慢的、昂贵的、质量低劣的东西。就在这时，我们意识到我们必须采取不同的方法。
解决方案：创建您自己的工具链
我们不得不做什么呢？我们不得不创建我们自己的工具链。
在这种情况下，我们结合了一个微调过的LLM，一个自定义编译器我们编写的，以及一个定制训练的模型。
而这并不像它看起来那么难。如今，你不必非得是一个数据科学家或者机器学习博士才能训练你自己的模型。
任何有中等经验的开发人员都能做到这一点。这样，你就可以构建一些速度更快、更可靠、更便宜、更具差异化的东西。你也不必担心山寨产品或开源克隆一夜之间涌现。
这不仅仅是一个理论。大多数，如果不是全部的话，高级人工智能产品都是这样构建的。
关于人工智能产品的一个常见误解
很多人对人工智能产品的构建存在一个重大误解。我注意到他们常常认为所有核心技术都是由一个超级聪明的模型处理的，用大量的输入进行训练，以便给出完全正确的输出。
以自动驾驶汽车为例。许多人有这样的印象：有一个巨大的模型，它接收所有这些不同的输入，如摄像头、传感器、GPS等，然后通过人工智能进行处理，然后输出另一边的动作，比如右转。
但这与事实相去甚远。那辆自动驾驶的汽车并不是一个巨大的人工智能大脑。
而不是一整套专门模型的工具链，所有这些都与普通代码相连——比如用于计算机视觉的模型来找到和识别物体，预测性决策制定，预测其他人的行动，或者用于理解语音命令的自然语言处理——所有这些专门的模型都与大量的普通代码和逻辑相结合，创造出最终结果——一辆可以自动驾驶的汽车。
现在，请记住，自动驾驶汽车是一个非常复杂的例子，它包括了比我在这里提到的还要多的模型。
对于构建你自己的产品，你不需要几乎这么复杂的东西，特别是刚开始的时候。
记住，无人驾驶汽车不是一夜之间出现的。我的2018年普锐斯能够自己停车，当离物体太近时自动停止，以及使用很少或没有人工智能就能完成许多其他事情。
随着时间的推移，汽车上增加了越来越多的层次，以执行越来越先进的功能，例如纠正车道偏离，或者最终做出从一个地方到另一个地方的整个驾驶决定。
但是就像所有软件一样，这些功能都是分层构建的，一层叠一层。
从哪里开始构建真正的人工智能
我强烈建议您探索我们为Visual Copilot所使用的方法，以用于您自己的人工智能解决方案。这是一个简单直接但又违反直觉的方法。
最重要的是一开始不要使用人工智能。
使用正常的编程实践来探索问题空间，以确定首先需要一个专门的模型的领域。
记住，通常来说，制造“超级模特”并不是正确的方法。我们不希望将大量的Figma数据发送到模型中，然后从另一端得到完成的代码。
如果只用一个模型来解决这个问题，那将是一个极其复杂的问题。而且，当你考虑到我们支持的所有不同框架、样式选项和定制选项时，用所有这些额外的数据重新训练这个模型将是不可行的。
它可能会变得如此复杂、缓慢和昂贵，以至于我们的产品可能永远不会上市。
相反，我们考虑了这个问题并说，嗯，我们如何在没有人工智能的情况下解决这个问题？在我们没有人工智能最擅长的那种专门的决策能力之前，我们能走多远？
所以我们分解了这个问题，然后说，好的，我们需要将这些节点转换成我们能在代码中表示的东西。
我们需要详细了解如何使用图像、背景和前景等元素。最重要的是，我们需要复杂地理解如何使任何输入响应。
在那之后，我们开始考虑更复杂的例子，并意识到有很多案例需要将许多层转换成一张图片。
首先手动编码逻辑
我们开始编写手写逻辑，以判断一组项目是否在应该成为flex列的垂直堆栈中，以及并排的项目是否应该成为flex行。
我们尽可能地创建了所有这些不同类型的复杂算法，以自动将设计转换为响应式代码，然后我们开始遇到限制。
根据我的经验，无论你认为限制在哪里，它可能还有很长一段距离。但是，在某个时候，你会发现有一些事情几乎不可能用标准代码来完成。
例如，自动识别哪些层应该变成一张图片，是人类感知非常擅长理解的事情，但这并不一定是常规的命令式代码。 在我们的例子中，我们用JavaScript编写了所有这些。
添加专门的人工智能来填补空白
幸运的是，用人工智能训练自己的目标检测模型来满足这一需求并不难。例如，像谷歌的Vertex AI这样的产品有一系列常见的模型类型，您可以自己高效地训练——其中之一就是目标检测。
我可以用图形用户界面选择它，然后准备数据，然后将其作为文件上传。
对于这种已经非常成熟的模型类型，关键就在于创建数据。
现在，事情变得有趣的地方在于找到创造性的方法来生成你需要的数据。
一个极好且庞大的免费资源来生成数据仅仅是互联网。
我们探索解决这个问题的一个方法是使用puppeteer自动化地在网页浏览器中打开网站，截取网站的屏幕截图，并遍历HTML以找到img标签。
然后我们使用图像的位置作为输出数据，网页截图作为输入数据。现在我们有我们需要的东西——一个源图像和所有子图像的位置坐标，来训练这个人工智能模型。
将代码 + AI模型结合起来，形成一个完整的解决方案
通过使用这些技术，我们可以用专门的人工智能模型填补未知数，并将它们结合起来，这就是我们能够产生这样的最终结果：我可以选择我的设计，点击生成代码，等待大约一秒钟，然后启动进入Builder.io。
然后在构建器中，我们得到一个完全响应式的网站，拥有高质量的代码，您可以完全自定义。它支持各种框架和选项，并且一切都超级快速，因为我们的所有模型都是专门为这个目的特别构建的。
我们以极低的价格提供这个，提供了一个慷慨的免费层，这对我们的客户来说非常有价值，帮助他们节省了很多时间。
控制自己的模型的好处
最好的部分是这仅仅是个开始。
好处1：你可以控制自己的命运
这种方法最好的部分之一是我们完全拥有这些模型，所以我们可以不断改进它们。我们不仅仅是在包装别人的模型。
如果你完全依赖别人的模型，比如OpenAI，那么没有任何保证它会变得更智能、更快或更便宜，以满足你的使用案例。而且你通过提示工程和微调来控制它的可能性非常有限。
但由于我们拥有自己的模型，我们每天都在进行重大改进。
当新设计进来，如果导入效果不佳——这种情况仍在发生，因为我们还在测试阶段——我们依赖用户反馈来快速改进，每天都在发布改进。
好处2：您可以控制隐私
有了这种方法，我们就不必担心缺乏控制。例如，当我们开始与一些大型和注重隐私的公司进行交谈，作为潜在的早期测试客户时，最常见的反馈之一是他们无法使用OpenAI或任何使用OpenAI的产品。
他们的隐私需求优先考虑确保他们的数据不会进入他们不允许的系统。
在我们的例子中，因为我们控制着整个技术，我们可以将我们的模型保持在一个非常高的隐私标准。谢天谢地，因为如果我们依赖其他公司（像许多其他人一样），我们就会失去一些严肃的业务。
对于LLM步骤，我们可以将其关闭（因为它纯粹是锦上添花），或者公司可以插入自己的LLM。这些LLM可能是完全在内部构建的模型，或者是llama2他们自己的企业版OpenAI实例，或者完全不同的东西。
结论
所以，如果你想构建AI产品，我强烈推荐采取类似Builder的方法。
尽管听起来有些奇怪，在你的项目中尽可能长时间地避免使用人工智能。然后，当你开始发现特定问题，标准编码不能很好地解决——但成熟的人工智能模型可以——开始生成你自己的数据，并使用你可以找到的各种现成的工具来训练你自己的模型。
只有在需要的地方将你的模型连接到你的代码上。
而且我想强调这一点：使用人工智能进行_很少_尽可能地。在一天结束的时候，“正常”的代码将是你见过的最快的、最可靠的、最确定的、最容易调试的、容易修复的、容易管理的以及容易测试的代码。
但这种魔力将来自于你使用人工智能模型的一些小而关键的领域。
迫不及待想看看你们建造的了不起的东西。
引入视觉副驾驶：将Figma设计一键转换为高质量代码。
原文链接：Don’t Build AI Products The Way Everyone Else Is Doing It
本文使用 🐝 A C(Collect) -> T(Transform) -> P(Publish) automation workflow for content creator. 全自动采集 - 翻译 - 发布
留下评论