NSDT工具推荐： Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器 - REVIT导出3D模型插件 - 3D模型语义搜索引擎 - AI模型在线查看 - Three.js虚拟轴心开发包 - 3D模型在线减面 - STL模型在线切割 - 3D道路快速建模

多年前，Opendoor 的老板给我的第一条建议很简洁：“回测。AI 产品团队的成功或失败取决于回测的质量。”当时，这条建议是经过实践检验的；搜索、推荐、生命科学、金融和其他高风险产品的团队都从惨痛经历中吸取了教训。这是我近十年来最珍视的建议。

但我开始相信，对于构建生成式 AI 产品来说，这并不是不言而喻的。一年前，我从传统的 ML 产品（产生简单的输出：数字、类别、有序列表）转向了生成式 AI 产品。在此过程中，我发现传统 ML 的许多原则不再适用于我和我的团队。

通过我在 Tome 的工作（我是产品主管）以及与生成式 AI 初创公司领导者的对话，我认识到了 3 种行为，这些行为区分了提供最强大、最有用的生成式 AI 功能的团队。这些团队：

  • 从用户问题出发后向工作，同事从技术机会出发前向工作
  • 从一开始就设计低摩擦反馈循环
  • 重新考虑传统机器学习的研究和开发工具

这些行为需要“忘记”许多仍然是传统机器学习最佳实践的东西。有些乍一看似乎违反直觉。尽管如此，它们广泛适用于生成式人工智能应用，从横向到纵向软件，从初创公司到现有企业。让我们深入研究吧！

1、从用户问题和技术机会双向思考

“从用户问题开始向后工作”是许多产品和设计圈的信条，亚马逊使这一信条声名远扬。研究用户，确定他们的痛点，编写 UX 要求以缓解最重要的痛点，确定最佳实施技术，然后重复上述步骤。换句话说，弄清楚“这是我们要打的最重要的钉子，然后使用哪把锤子。”

当使能技术发展非常迅速时，这种方法就不那么有意义了。ChatGPT 不是从用户痛点向后工作的。它之所以成功，是因为它通过简单、开放的用户界面提供了一种强大的新使能技术。换句话说：“我们发明了一把新锤子，让我们看看用户会用它打哪些钉子。”

最好的生成式 AI 应用程序团队同时向前和向后工作。他们进行用户研究，了解痛点的广度和深度。但他们不会简单地按顺序浏览排名列表。团队中的每个人，包括项目经理和设计师，都深深沉浸在最近的 AI 进展中。他们将这些不断发展的技术机会与用户痛点联系起来，而这种联系通常比一对一映射更复杂。

例如，一个团队会发现用户痛点 #2、#3 和 #6 都可以通过模型突破 X 来缓解。那么，下一个项目可能更适合通过整合模型突破 X 来“向前发展”，而不是从痛点 #1“向后发展”。

深入研究最近的 AI 进展意味着了解它们如何应用于你的实际应用，而不仅仅是阅读研究论文。这需要原型设计。除非你在应用环境中尝试了新技术，否则对用户收益的估计只是猜测。原型设计的重要性日益提升，这要求将传统的规范 → 原型 → 构建流程转变为原型 → 规范 → 构建。更多的原型被丢弃，但这是始终如一地规范功能的唯一方法，这些功能将有用的新技术与广泛、深入的用户需求相匹配。

2、从一开始就设计低摩擦反馈循环

经典的 ML 产品产生相对简单的输出类型：数字、类别、有序列表。用户倾向于接受或拒绝这些输出：你单击 Google 搜索结果页面中的链接，或将电子邮件标记为垃圾邮件。每次用户交互都会提供直接反馈到模型再训练中的数据，因此实际使用和模型改进之间的联系很强（而且是机械的）。

不幸的是，大多数生成式 AI 产品往往不会在每次用户交互中产生新的、真实的训练数据。这一挑战与生成模型如此强大的原因有关：它们能够生成结合文本、图像、视频、音频、代码等的复杂工件。对于复杂的工件，用户很少会“接受或放弃”。相反，大多数用户会使用更多/不同的 AI 或手动优化模型输出。例如，用户可以将 ChatGPT 输出复制到 Word 中，对其进行编辑，然后将其发送给同事。这种行为会阻止应用程序 (ChatGPT)“看到”工件的最终理想形式。

一个含义是允许用户在你的应用程序中迭代输出。但这并不能消除问题：当用户不迭代输出时，这是否意味着“哇”或“悲哀”？你可以为每个 AI 响应添加一个情绪指标（例如竖起大拇指/竖起大拇指），但交互级反馈响应率往往非常低。并且提交的响应往往偏向极端。用户大多将情绪收集工作视为额外的摩擦，因为它们大多不会帮助用户立即获得更好的输出。

更好的策略是在用户的工作流程中确定一个表示“此输出现在足够好”的步骤。将该步骤构建到你的应用程序中，并确保记录此时的输出。对于 Tome 来说，我们帮助用户使用 AI 制作演示文稿，关键步骤是与另一个人分享演示文稿。为了将其引入我们的应用程序，我们在共享功能方面投入了大量资金。然后，我们评估哪些 AI 输出是“可共享的”，哪些需要大量手动编辑才能共享。

用户帮助反馈

自由文本已成为用户与生成式 AI 应用程序交互的主要方式。但自由文本是潘多拉魔盒：给用户自由文本输入 AI，他们会要求产品做各种它不能做的事情。自由文本是一种众所周知的难以传达产品约束的输入机制；相比之下，老式的 Web 表单非常清楚地说明了哪些信息可以和必须提交，以及以何种格式提交。

但用户在进行创造性或复杂的工作时不需要表单。他们想要自由文本——以及如何针对手头的任务制作出色提示的指导。帮助用户的策略包括示例提示或模板、有关最佳提示长度和格式的指导（它们是否应该包括少量示例？）。人性化的错误信息也是关键（例如：“此提示使用的是 X 语言，但我们仅支持 Y 和 Z 语言。”）

自由文本输入的一个好处是，不受支持的请求可以成为下一步构建的绝佳灵感来源。诀窍是能够识别和聚类用户在自由文本中尝试执行的操作。下一节将详细介绍这一点……

3、重新考虑传统 ML 的研究和开发工具

要构建的东西、要保留的东西、要丢弃的东西

3.1 构建：自然语言分析

许多生成式 AI 应用程序允许用户从同一个入口点（开放式自由文本界面）追求非常不同的工作流程。用户不会从下拉菜单中选择“我正在集思广益”或“我想解决一个数学问题”——他们想要的工作流程隐含在他们的文本输入中。因此，了解用户想要的工作流程需要对自由文本输入进行细分。一些细分方法可能会经久不衰——在 Tome，我们始终对想要的语言和受众类型感兴趣。还有临时细分，以回答产品路线图上的具体问题——例如，有多少提示要求图像、视频、表格或图表等视觉元素，因此我们应该投资哪个视觉元素？

自然语言分析应该补充而不是取代传统的研究方法。NLP 与结构化数据（例如传统 SQL）搭配使用时尤其强大。许多关键数据不是自由文本：用户何时注册，用户的属性是什么（组织、工作、地理位置等）。在 Tome，我们倾向于按工作职能、地理位置和免费/付费用户状态查看语言集群——所有这些都需要传统的 SQL。

如果没有定性洞察，就永远不要依赖量化洞察。我发现，观察用户实时浏览我们的产品有时可以产生 10 倍于用户访谈（用户事后讨论他们的产品印象）的洞察。我发现，一次好的用户访谈可以解锁 10 倍于量化分析的洞察。

3.2 保留：低代码原型设计工具

两种工具类型支持高速、高质量的生成式 AI 应用程序开发：原型设计工具和输出质量评估工具。

有很多不同的方法来改进 ML 应用程序，但有一种既快速又易于访问的策略是快速工程。它很快，因为它不需要重新训练模型；它之所以易于理解，是因为它涉及自然语言，而不是代码。允许非工程师操纵提示工程方法（在开发或本地环境中）可以显著提高速度和质量。这通常可以通过笔记本来实现。笔记本可能包含大量代码，但非工程师可以在不接触代码的情况下迭代自然语言提示，从而取得重大进展。

评估原型输出质量通常非常困难，尤其是在构建全新功能时。我发现，与投资自动化质量测量相比，在“beta 测试程序”中对同事或用户进行 10-100 次结构化评估（分数 + 注释）要快得多，也更有用。“投票方法”的支持技术可以很轻松：一个笔记本可以生成适度规模的输入/输出示例，并将其导入 Google Sheet。这允许并行进行手动评估，并且通常很容易在不到一天的时间内对少数人评估约 100 个示例。评估员的注释提供了对失败或卓越模式的洞察，这是一个额外的好处；注释往往比数字分数更有助于确定下一步要修复或构建的内容。

3.3 丢弃：自动化、回测的质量衡量标准

经典 ML 工程的原则是投资于强大的回测。团队经常（每周或每天）重新训练经典模型，良好的回测可确保只有优秀的新候选模型才能投入生产。这对于输出数字或类别的模型来说是有意义的，因为这些模型可以轻松地根据真实数据集进行评分。

但是，对于复杂（可能是多模式）输出，准确度的评分会更难。你可能有一段自认为很棒的文本，因此倾向于将其称为“真实数据”，但如果模型输出与其相差 1 个单词，这有意义吗？相差 1 句话？如果事实都一样，但结构不同怎么办？如果是文本和图像一起怎么办？

但并非一切都失去了。人类往往很容易评估生成式人工智能输出是否符合他们的质量标准。这并不意味着很容易将坏的输出转化为好的，只是用户往往能够在几秒钟内判断文本、图像、音频等是“好还是坏”。此外，由于计算成本和/或获取足够的用户信号以保证重新训练所需的时间较长，大多数应用层的生成式人工智能系统不会按日、周甚至月进行重新训练。因此，我们不需要每天运行质量评估流程（除非你是 Google、Meta 或 OpenAI）。

鉴于人类可以轻松评估生成式 AI 输出，并且重新训练的频率很低，因此基于内部手动测试（例如上一节中描述的轮询方法）而不是自动回测来评估新的模型候选者通常更有意义。

4、结束语

开发出色的生成式 AI 应用程序需要的不仅仅是创新工程；它需要产品和设计以与传统 ML 或非 ML 产品原则截然不同的方式工作。有些模式需要被遗忘（“投资于你的回测！”），有些模式需要重新制定（“来回工作”），有些则是全新的（“从一开始就构建反馈循环。”）

这可能需要大量的流程和人员重新布线，但好处是巨大的——如果你不这样做，革命就会与你擦肩而过。

原文链接：Unlearning to Build Great AI Apps

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