LLM应用的UX设计

大型语言模型应用初创公司在过去一年呈爆炸式增长。底层语言建模技术的巨大进步，加上 Github CoPilot 等产品的早期成功，导致大量创始人使用 LLM 重新思考从代码审查到文案撰写再到分析非结构化产品反馈的工作流程。

关于这个新兴生态系统的文章很多——我会推荐 Elad Gil、Leigh Marie Braswell 和 Vinay Iyengar 的优秀文章作为起点——总的来说，看到这个领域有这么多新生的初创公司是令人兴奋的。然而，我担心这个领域的许多初创公司在早期就专注于错误的事情。具体来说，在会见并调查了该领域的众多公司之后，用户体验和产品设计似乎是阻碍大多数应用型大型语言模型初创公司的主要瓶颈，而不是数据或建模。

这篇文章将解释为什么我认为是这种情况，强调我观察到的许多关键用户体验问题，并就建立在 LLM 之上的创始人如何解释这一点提供建议。

1、LLM创业公司的大过滤器

首先，让我描绘一下我看到许多语言模型初创公司经历的共同旅程。

一个技术精湛的创始团队从一个大用例的愿景开始，这个用例显然可以用当前的语言模型技术重新想象。他们拼凑了一个看起来像下面这样的幻灯片：

这是一个可以用语言模型重新想象的用例
这就是为什么我们拥有最好的技术团队来为这个用例构建一个差异化的、独特的、高度微调的模型，与现成的东西相比，它可以实现极高的准确性
以下是我们将如何在我们的数据集或建模方法、我们的架构、从用户那里获取强化信号等方面进行区分
我们想筹集 5-1000 万美元来聘请一群 ML 研究人员，训练这个模型，开始。

团队早期 90% 的关注点都在数据、建模、系统架构和技术防御上。该团队可能非常清楚许多人认为 LLM 正在变得商品化这一事实，因此，他们试图花费大量时间来阐明为什么他们的技术方法是独一无二的，并且是使用 GPT-3 的爱好者不容易模仿 .

经过筹款和大量时间建设后，这家初创公司最终获得了产品的 MVP，并将其展示在客户面前。演示让前景大放异彩，但随后，事情似乎就烟消云散了。潜在客户在 POC 中试用它，但新奇感用完了，他们停止使用它。参与度低。客户流失。尽管该演示有多么令人难以置信，但该初创公司仍在努力寻找真正适合市场的产品。

2、发生了什么？

以我的经验，通常导致这种结果的根本原因是，在一个他们不习惯的环境中，教一个人如何与概率系统一起工作是非常困难的。任何设计为人在环中（human-in-the-loop）的语言模型初创公司（绝大多数）都需要隐式为其用户回答以下类型的问题：

这些首先是用户体验问题，需要非常仔细的设计思维和用户研究才能解决。如果你放弃这样的工作，只是简单地将一个裸露的 GPT-3 文本提示扔到你的 UI 中，或者只是在每次用户按下给定的热键时对 GPT-3 API 进行原始 API 调用，你实际上是在要求用户计算这些事情自己解决。用户通过反复试验找出此类问题的认知负担是巨大的。因此，如果你不知道如何让你的用户可以在 <5 分钟内获得答案，那么一旦新奇效果消失，他们很可能会放弃你的产品 .

根据我的经验，尽管这些 UX 问题是产品市场适应性的关键瓶颈，并且在大多数情况下是最难解决的问题，但该领域的大多数初创公司长期低估了它们的价值。事实上，如果你与少数几家实际构建了广泛采用的应用 LLM 产品的公司交谈，你会发现几乎普遍他们最终不得不在用户体验和人机界面上花费更多的时间，就像他们在建模上所做的那样。

3、为什么是这样？

我相信有一些潜在的因素导致如此多的团队很少关注这些用户体验问题，尽管它们很关键。

首先，这些问题实际上只有在有人开始尝试在日常工作流程中使用该产品时才会浮出水面。这个市场的特点是潜在客户对演示印象深刻或感兴趣与实际转换为付费和参与用户之间存在巨大差距，正是出于这个原因。我相信这也是为什么许多应用 PLG（Product lead growth）和自助服务的 LLM 初创公司流失率很高的原因——第一次使用时，产品“很酷”，但一段时间后，你会发现它太难有效使用了。

其次，许多团队认为提高模型准确性可以让他们避免从产品和设计的角度深入考虑这些问题。不幸的是，无论你的系统的准确性如何（在一定范围内），这些挑战基本上总是存在的。你的 LLM 准确率是 80% 还是 95% 并不重要，因为在这两种情况下，用户仍然需要通过故障模式进行推理，并了解与系统交互时会发生什么。由于除非将用例的范围缩小到非常具体的范围，否则几乎肯定不会达到 100% 的准确度，因此通常最好达到足够好的基线准确度，然后构建允许用户使用的产品知道如何使用模型。这篇关于使用语言模型帮助编写短篇小说的论文很好地说明了这个概念。

最后，还有一个人才问题——这个领域的大多数人都来自研究、博士或工程背景，他们根本不认为像这样的产品和设计决策是需要解决的一流问题。

4、文案写作——一个说明性的例子

为了进一步解释为什么与 LLM 接口的用户体验如此难以正确，让我们简要探讨一下最流行的新兴 LLM 用例之一——文案。有许多著名的公司使用 GPT-3 或类似模型进行文案写作，例如 Jasper.ai、Copy.ai 和 Anyword。在高层次上，这些产品都以以下方式工作——你告诉它你想写什么（例如广告标题），你提供一些上下文（例如产品描述），它会以很高的速度为你生成理论上能够转化用户的建议。

如果你自己尝试这些产品或与使用它们的人交谈，会发现区分它们的主要因素不是模型准确性。他们都非常擅长优化副本以进行转换，坦率地说，如果不花大量时间手动对服务进行 A/B 测试，用户就不可能有意义地比较输出副本的质量。换句话说——模型精度的差异基本上是用户察觉不到的。然而，从用户的角度来看，真正使产品与众不同的是围绕核心语言合成引擎的产品“外围”。

例如：

用户应如何提供输入上下文（例如产品或公司描述）？提供此上下文、其目的以及它将如何影响输出准确性有多容易？如果用户弄乱了输入上下文，他们是否有可能得到非常糟糕的建议？
应该向用户显示多少文案建议？如何平衡想要多样化的用户与感到不知所措的选择？如何解释为什么有多个输出而不是只有一个以及用户应该如何浏览它们的想法？
如何对建议进行排名或评分，以帮助用户了解他们应该选择哪一个或何时应该选择一个与另一个？你如何解释这个排名或分数对用户意味着什么？你应该“评分”输出吗？
如何让用户在他们的个人偏好与模型认为最佳的之间取得平衡？用户是否有办法为模型必须保留的复制输出强制执行某些规则或标准？你允许用户在某个方向（语气、风格等）上“推动”建议吗？
如何避免显示会降低用户信任度的奇怪或奇怪的建议？是否有系统确保模型永远不会“发疯”？
如何帮助用户确信你的建议实际上是好的？如何让人相信这实际上是一个文案写作专家系统？
这如何适应整个文案工作流程？

很好地解决这些类型的 UX 问题对用户选择他们满意的好副本的能力的影响要大得多，而不是对语言模型进行微调以使其在文案建议方面稍微好一些。

事实上，许多此类公司的客户流失率很高，我怀疑此类初创公司在客户流失/保留/参与度方面的绝大多数差异是由这些与用户体验相关的因素驱动的。处理不当的产品尝试起来很有趣，但随着时间的推移难以信任和推理。能够很好地处理它们的产品是神奇的——使用它们感觉毫不费力，而且很清楚它们如何适应真实的工作流程。

5、新兴的用户体验模式和原则

在这一点上，我希望能说服你，重要的是要考虑用户在你的产品环境中如何与 LLM 交互的用户体验。但是你实际上应该如何去做，正确的设计模式是什么？

虽然这个空间非常早，而且有很多东西需要弄清楚，但我想分享一些我看到的共同主题，希望它能激发你的想象力并让你思考。对于每一个，我都会提到几家新兴的初创公司，它们在该 UX 模式的背景下做着有趣的事情。

5.1 用户驱动与系统驱动的触发器

如果你曾经使用过 Gmail，可能遇到过“智能撰写”功能。当你键入一个句子时，Gmail 偶尔会以灰色闪烁建议的自动完成。用户可以快速接受它，也可以继续输入并忽略它。

此功能使用起来非常愉快，因为它易于理解、非常准确，并且对用户而言需要零认知努力。我认为这些好处中的大部分源于这样一个事实，即这些建议是系统提示的，而不是用户提示的。只有在确信结果质量非常高时才会显示建议，并且建议的“推送”性质意味着用户甚至不需要意识到此功能的存在即可使用它。

尽管 smart compose 在技术上不是使用 LLM 构建的，但我认为这些原则非常清晰地转化为大多数 LLM 初创公司。你越能从用户驱动的模型调用转移到在正确的实例中自动触发模型，就越能确保模型输出被认为是极其值得信赖和高质量的，并且你的工作量就越少正在要求用户做。在你的产品中，如果让用户更灵活地决定何时以及如何触发模型至关重要，我会探索不同的方式来“提示”用户模型何时更有可能有效或准确。

5.2 提示工程和提示抽象

语言模型中的一个新兴研究领域是“提示工程”领域。研究人员已经意识到，对于范围广泛的语言模型任务，改变提示模型的方式会导致模型结果准确性的巨大差异。

一个有趣的例子是，如果你要求语言模型解决数学问题，只需添加“让我们逐步思考”这句话就能获得更高的准确性。

整个研究领域都围绕提示工程这一事实暗示了一个更广泛的观点——弄清楚如何与大型语言模型交互真的非常复杂，而且你用它“说话”的方式的细微差别可能有对它的实用性产生巨大影响。这其中的关键含义是你不想强迫你的产品用户成为敏捷的工程研究人员。

不幸的是，这是当今大多数产品中与基础模型交互的现状。在语言生成中，大多数产品都公开相当“原始”的文本框，而用户只能尝试测试和试验什么会产生良好的输出。我尝试过的一个自动电子邮件跟进工具仍然需要我输入“写一封电子邮件……”作为提示的开始以获得良好的输出。

在可能的范围内，我强烈建议在用户输入的内容和你实际提示模型的内容之间建立一个抽象层。一个简单但很好的例子是纹身图像生成应用程序 TattoosAI。请注意，用户界面已将样式、颜色和艺术家等内容抽象到分类下拉列表和特定字段中。在引擎盖下，该产品清楚地将这些分类值转换为非常具体的提示，从而产生良好的纹身效果。否则，用户很难通过直接提示像 Stable Diffusion 这样的模型来自行正确处理。

我怀疑，在许多情况下，提供单个开放文本字段输入作为用户与模型交互的主要方式并不是一个好主意。这可能会为你的用户提供太多的自由，因此，由于不知道与模型对话的正确方式，他们会面临太多奇怪的故障模式。相反，确定应该查询模型并以用户希望不会搞砸的方式将其产品化的受约束的、已定义的情况。

5.3 验证检查和工作流程

构建基于 LLM 的应用程序时要克服的最大障碍之一是信任。作为用户，我在多大程度上可以默认假设输出是好的，而在多大程度上我需要仔细检查输出？用户越需要验证机器生产的一切，机器实际提供的价值就越少。

在这种情况下，代码自动完成是一个有趣的案例研究。 Github CoPilot 和 Replit AI 模式等产品是大型语言模型最早的突破用例——CoPilot 拥有数十万订阅者，每年为该服务支付超过 100 美元，许多人喜欢该产品。

然而，如果你与足够多的 CoPilot 使用人样本交谈，有时会听到混合的反馈。具体来说，CoPilot 会定期建议不正确且未编译或包含错误的代码片段，这意味着工程师在继续前进之前必须非常仔细地分析代码建议。从本质上讲，CoPilot 在花更少的时间编写样板代码和花更多的时间阅读“其他人的”代码（又名 LLM）之间进行了权衡。

将其与谷歌最近在基于 LLM 的代码自动完成方面的工作进行对比是非常有趣的。具体来说，谷歌已经构建了一个混合代码完成系统，它不仅基于转换器模型，而且还结合了语义引擎，语义引擎本质上是基于规则的自动完成系统，传统上在 IDE 中提供代码建议。这些系统的组合允许两种形式的高级自动完成，显着缓解用户信任问题：

传统的语义引擎建议通过transformer模型进行排序
Transformer 模型提供单行和多行代码自动完成建议，语义引擎用于在向用户显示之前检查输出的正确性
有趣的是，Google 直接测试了基于纯 LLM 的自动完成建议，发现由于信任问题，用户对它们的接受率要低得多：

这导致了 ML 驱动的代码完成的一个常见缺点，即模型可能会建议看起来正确但无法编译的代码。根据内部用户体验研究，随着时间的推移，此问题可能会导致用户信任度下降，同时降低生产力收益……在合并该功能的前六周内，单行完成的接受率提高了 1.9 倍，这大概是由于增加用户信任度。作为比较，对于我们没有添加语义检查的语言，我们只看到接受度增加了 1.3 倍。

Replit 的 AI 模式遵循类似的原则——“我们应用一组启发式过滤器来决定丢弃、截断或以其他方式转换一些建议；很快，我们还将应用强化学习层来了解对用户有帮助的建议类型，过滤掉不太可能被接受的建议，以优先考虑真正有帮助的建议。

概括这一点，我发现许多一流的基于 LLM 的产品通过某种形式的验证检查（通常本质上是启发式的）来补充 LLM，以避免错误的输出。向用户建议一些看起来荒谬或明显错误的东西可能是灾难性的。因此，特别是如果ni 的产品允许用户在任意情况下触发模型，那么构建机制以减轻这种情况的可能性通常变得至关重要。

当然，并非所有用例都有像测试代码是否可以编译这样简单的验证检查。因此，我还建议考虑你可以构建的可供性，让用户知道何时对输出进行直觉检查以及如何对输出进行直觉检查。这可能涉及构建一些测试或评估框架，用户可以使用这些框架来定义特定领域的测试或他们想要持有的不变量，或者它可能涉及要求用户测试/验证输出并在某些情况下编辑它的工作流。

Debuild 是一个很好的简单应用程序示例，它很好地接近了验证功能。 Debuild 允许你使用自然语言创建简单的 Web 应用程序——首先输入诸如“允许我以分层格式跟踪、编辑和输入任务的待办事项列表”之类的内容，它将创建一个react应用。重要的是，应用程序的工作流程本身包含调试、测试和验证步骤。在键入初始自然语言提示后，它不会直接将你带到输出，而是会带你完成许多中间验证步骤。例如——它会根据自然语言提示向你显示它认为你的应用需要支持的“用例”列表，并允许你在继续之前编辑/修改该列表。

这个循序渐进、以验证为导向的工作流程采用了一个用例，否则这个用例可能会太令人沮丧——因为如果你试图一次做所有事情，LLM有太多的空间出错——并且使它非常愉快。作为用户，我隐含地理解我应该何时验证输出以及我应该如何做，因此，我并不介意机器有时是否有点错误。

与此相关，我认为基于 LLM 的产品有很大的空间来探索更丰富的错误消息和回退工作流。与其默认始终显示模型输出，不如探索是否有方法可以预测或猜测输出质量低下或不确定的时间。在这种情况下，看看你是否可以从产品的角度做一些不同的事情。这可能涉及清理用户输入并在用户提示以某种方式过于“怪异”时抛出错误消息。它可能涉及分析 LLM 响应的置信度，如果置信度太低，则不显示响应或显示警告（需要注意的是，分析 LLM 推理的置信度水平的“正确”方法是主动的尚不清楚的研究领域）。它可能涉及分析输出并在某些情况下将用户置于“你需要检查此输出”工作流中。我认为这里有很多设计空间需要探索。

5.4 基于会话的交互和用户反馈

今天围绕 LLM 构建的大多数生成产品都是“无状态的”，因为你提供输入，你得到输出，并且这种交互不会影响模型的未来行为。

然而，根据我的经验，这种结构并不符合人类喜欢进行创造性思维的方式。创作过程通常更加反复，每一步都源于最后一步。例如：

你的同事提出了一些想法
你真的很喜欢其中一些想法的某些元素，但你也觉得有些东西仍然缺失。你分享此反馈。
然后，你的同事通过结合你的反馈并产生衍生想法来重复最初的想法
你们两个反复重复这个过程几十次，直到你最终得出一个你喜欢的想法

从这个意义上说，创意的产生通常是“有状态的”——每一步都会产生最后一步的输出。我怀疑大多数专注于创意生成或合成的应用 LLM 产品可能会受益于将用户交互更像是会话，用户可以在会话中看到一些初始输出，突出显示他们喜欢或不喜欢的内容，然后进一步推动模型朝着这个方向发展他们希望输出去。

许多新兴的基于 LLM 的文案写作工具开始做这方面的基础版本。 Copy.ai 允许你选择喜欢的初始建议并生成“更像这样”，而 Anyword 允许你突出显示输出并“改写”它们，这会改变措辞但保留核心含义。

你可以想象出许多更复杂的版本，系统允许你非常优雅地定义你喜欢某些输出的特征（措辞、语气、风格、结构、长度等），以及你想要改变的类型制作。这些类型的功能为用户提供了更大的控制感，并帮助用户避免因从头开始重新提示模型和“丢失”你非常喜欢的东西而产生的挫败感，但这只是一点点。

准确性和信任度将成为许多此类模型的一个问题，这一事实极大地加剧了这一概念的重要性。如果你为用户构建正确的可供性以处理“坏”输出并通过迭代过程选择“好”输出，可以大大减少坏建议的感知负面影响。隐含地，这种设计告诉用户不要期望模型的输出是完美的，并为他们提供了处理这个问题的工具。对于用户在大多数情况下应如何与 LLM 交互，这是一个更现实的心智模型。

5.5 工作流程特异性

到目前为止，我使用过的一些最令人愉快的 LLM 实现是为了解决极其具体和狭窄的工作流程而构建的，例如将英语转换为正则表达式的 AutoRegex，以及将自然语言转换为 CLI 命令的 Warp 工具。这两种工具都处理了极其狭窄的语言生成子集，结果令人信服。该模型基本上总是完全按照你作为用户的期望去做，感知的准确性非常高，并且作为用户不会对如何提示、触发或使用该模型感到困惑。

当你将其与更通用的产品（例如 Lex 等基于 LLM 的文本编辑器）进行比较时，用户体验的差异是巨大的。虽然 Lex 使用起来非常酷和有趣，但对我来说，它仍然感觉更接近新奇，离我可以日常使用的核心工具更远。理解何时触发模型并猜测它会写什么实在是太具有挑战性了。

这个领域的许多初创公司已经开始意识到这一点。如果你看看基于 LLM 的文案写作产品的演变，许多已经从更通用的文案写作界面转变为针对非常具体的文案写作用例的高度细分的 UI——例如，Copy.ai 有不同的产品部分用于编写“Facebook Primary Text” ”、“Facebook 头条新闻”和“Facebook 链接说明”。在自动化代码审查领域，我看到许多最好的初创公司都是从关注特定代码生态系统（例如 Rust）和特定类别的代码审查用例（例如样式错误）开始的。

最常讨论的特异性的好处是它可以允许使用更专业、更微调的模型，从而提高性能或减少延迟/成本。虽然这确实是事实，但它远非唯一的好处。限制用例还允许你在模型和人类之间的界面上做出更多自以为是的产品和 UX 决策，并抽象出更多的模型提示和模型输出。

例如，许多致力于通过 LLM 分析非结构化用户反馈的公司（例如 Viable 和 Enterpret）已经摆脱了高度提示驱动的用户界面，用户可以在其中提出他们想要的任何问题。相反，他们更多地关注“开箱即用”的细分用例，例如趋势负面反馈或与产品的特定最新版本相关的新反馈。这种方法消除了用户确定向模型询问什么以及提示它的正确方式的需要——用户不需要想出分析趋势负面反馈可能是个好主意的想法，也不需要他们需要找出正确的方法来要求模型提供趋势负面反馈。

在编码中，工作流特异性也有明显的趋势。 Replit 将重写代码、解释代码和生成代码视为从 UI 角度和模型角度来看完全不同的用例。一些产品甚至在代码生成中开始进一步细分，将基于函数签名的全功能代码完成（例如，让 LLM 根据注释编写函数）与内联代码自动完成（例如，猜测我正在编写的代码行的其余部分）就它们在 UI 中的显示方式或触发方式而言。

同样，我怀疑随着时间的推移，大多数基于 LLM 的文字编辑器将不再使用热键命令作为触发 LLM 的通用方式，而是转向定义更清晰的用例，这些用例以不同的方式在视觉上呈现或触发通过不同的机制。段落生成、句子或短语自动完成、重写/重写、信息收集以及让模型帮助你“集思广益”写什么，在如何将它们产品化方面可能截然不同；关于短篇小说写作的 Worldcraft 论文有一些很好的插图和例子。虽然细分这些用例肯定会允许对单个模型进行微调，但我怀疑大部分边际收益来自更易于使用、信任和交互的更易于理解的产品。

5.6 延迟和性能

最后一个值得一提的 UX 原则是延迟和性能。许多最有趣的应用 LLM 用例都存在于“流动状态”任务的上下文中，例如写作、编码或类似的任务，理想情况下你不希望被持续 5 秒的加载微调器打断。如果你正在构建基于 LLM 的应用程序，则值得深入研究你的用例实现良好用户体验所需的延迟阈值。从那里，你可以确定正确的模型和系统架构。

例如，TabNine 是一家代码完成初创公司，其架构与 Github CoPilot 截然不同——他们的产品不是使用单一的语言模型，而是围绕针对不同类型任务微调的特定模型的集合构建的。值得注意的是，利用更小的模型可以让他们在你键入每个字符时进行内联、实时的代码建议，这是 CoPilot 无法实现的。

同样，Replit 也进行了广泛的优化工作，以使其中值响应时间达到 400 毫秒。我怀疑随着时间的推移，几乎所有生成式写作 LLM 用例都会从达到 100 毫秒阈值中受益匪浅。

尽管性能改进本质上显然是技术性的，但我的论点是，它们确实需要从对用户、用户的工作流程以及你想要创建的用户体验的深入理解开始。调整语言模型的成本、速度、大小和准确性权衡的方法有很大的设计空间——选择不同的基线预训练模型、微调、前缀调整等——在许多应用程序中，可能有该搜索空间中应该识别的帕累托最优点。

与此相关，我怀疑在许多情况下，还会有其他创新方法来提高性能，例如缓存的智能使用、计算的并行化、使用模型集合（包括一些小型语言模型或传统模型架构）、聪明的语义/启发式检查和语言模型之间的集成，以及类似的。微妙的用户体验变化通常也会导致感知性能的巨大差异，不应低估。例如，Replit 的代码完成模型逐行“流式传输”多行建议的结果，而不是等到可以显示整个响应。这导致用户对速度的看法截然不同，并极大地改善了用户体验。

最佳应用的 LLM 初创公司将对他们应该在这些权衡中处于什么位置有非常强烈的意见，并且可能会确定聪明的系统架构以实现差异化的用户体验。

6、用户体验作为防御机制

许多创办基于 LLM 的公司的人都在考虑建立专有数据护城河或数据反馈循环，以允许数据或模型驱动的防御随着时间的推移。我通常认为，对于 LLM 中的大多数垂直用例，很难以这种方式获得任何实质性优势——这些模型显然正在变得商品化，并且对于大多数这些用例来说，边际准确性的好处超过了某个点是有限的，并且在许多情况下，有足够的易于访问或开放的数据。

人们普遍认为，产品和用户体验洞察力通常不会提高防御能力，因为它们很容易被复制。如果其中一家文案公司找到了 LLM 辅助文案写作的完美工作流程，那么另一家就不能迅速模仿吗？虽然这在一定程度上是正确的，但它遗漏了一些东西——这个领域的许多 UX 见解需要与独特的、特定领域的技术工作相结合才能实现。本文中已经提到的例子包括谷歌用于其代码完成系统的语义验证引擎和 TabNine 的集成语言建模方法，以允许在开发人员键入时提供内联代码建议。

Superhuman是不同领域的一个很好的说明性例子。 Superhuman 的特别之处在于一切都非常快，使用户能够保持心流状态，但这只能通过极端的工程努力来实现，以确保产品中的每一个动作都在 <100 毫秒内发生。

我敢肯定，许多从确定用例的理想用户体验开始的应用 LLM 团队将需要在可解释性、置信度分析、提示工程、性能、测试和验证方面进行研究级工作，或类似的实际构建用户体验。特定领域的上下文集成、微调客户数据和持续学习是开发独特 IP 的其他一些有趣领域，这将改善用户体验。这种针对特定领域的“用户感知”研究通常是其他人难以复制或模仿的最难的技术进步类型。相关的是，我怀疑这个领域的许多持久的初创公司将构建复杂的混合系统，以优雅的方式结合启发式方法、符号方法、基于转换器的模型和遗留语言模型。

这一类别中的优秀初创公司将从第一原则出发思考他们想要提供的用户体验，并确定真正新颖的方法，以一种其他人无法做到的方式在技术上实现这一目标。这些 UX 见解对特定领域越具体越好，因为它们被大型语言模型的一般研究改进所避免的可能性越小。

7、结束语

从某种意义上说，我在这篇文章中写的很多内容都不是特别新。在过去十年中，对于绝大多数应用 ML 公司来说，教导人类如何与概率机器交互的核心问题都是如此。在每种情况下，你都需要弄清楚如何构建一个“优雅地处理混淆矩阵”的产品，并在与模型交互的用户之间建立信任。事实上，我认为许多 LLM 公司可能会从当今存在的一流的支持 ML 的创意工具（例如 Runway）中学到很多东西。

然而，我不禁觉得这些问题更难解决，而且在应用 LLM 空间中正确处理这些问题更为关键。这与该类别初创公司的雄心密切相关。坦率地说，机器可以从根本上影响复杂的、创造性的、知识工作者的任务，比如编写软件，这样的想法是令人难以置信的。这些任务的范围在某种程度上比以前应用的大多数 AI 工作流程要广泛得多，这极大地增加了创建具有出色 UX 的精心调整产品的重要性，尤其是在模型和人类的界面上。

值得注意的是，其中许多 UX 问题都可以用很少的钱进行测试、降低风险和迭代。你可以构建一个带有硬编码后端的 hacky 原型来测试交互模式——不需要 LLM。我认为该领域的更多初创公司在构建庞大的语言模型堆栈之前应该做这样的事情。仔细考虑用户与产品交互的所有不同方式，并通过各种方式推理来解决我在文章开头提出的问题。在尝试从架构或微调角度进行任何定制之前，采用现成的 LLM 模型并专注于改进与产品交互的用户体验。这些都不是很难做的事情，但很少有团队能做到。

这个领域迫切需要更多具有强大设计和产品直觉的创始团队，他们将 UX 视为一流的问题。使用 LLM 的基本交互模式尚未弄清楚，处于这方面前沿的初创公司有很大的机会。

原文链接：The biggest bottleneck for large language model startups is UX

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