LLM 驱动的软件在中期会怎样演变

2023-09-17 19:47:14 +0000

最近，我开始开发一个面向 LLM 的新项目。它目前离功能完备还差得很远，可能也满是 bug，但我希望把它作为一个实验平台，用来探索一个最近经常思考的问题：在中期未来，由 LLM 驱动的软件会是什么样子？

LLM 正在显著改变我们与计算机交互的方式，这一点似乎毋庸置疑。但目前这些由 LLM 居中协调的交互，显然还相当原始。今天使用 LLM——无论是通过聊天机器人、Copilot，还是其他任何 UX——仍然充斥着各种拼凑式方案、不一致、挫败感和局限。自然语言是一种迷人而自由的界面，但越来越明显的是，它并不能完全取代过去几十年数字 UX 领域积累的其他创新。

最近，我读到了一些很有意思的文章，作者包括 Maggie Appleton、Nick Arner 和 Linus Lee 等。他们设想了如何改进现有的 LLM UX，也就是我们可以怎样改善今天已有的体验。而在这篇文章中，我希望从相反的方向来思考这个问题：假如我们要想象一下 2027 年左右面向 LLM 的 UX，它们会具备哪些特征？

我写这篇文章主要是为了自己，因为写作就是思考；但我也希望它能启发互联网上的其他人来填补其中的空白，并告诉我哪些地方错得离谱。其中一些想法已经在 Lightrail 中得到了部分实现——主要面向开发者群体；一些已经列入我的 roadmap；还有一些，我完全不知道该从何着手才能有效实现。尽管如此，我仍然希望，对这些特征作出定义，能够成为迈向一个让它们真正存在的世界的第一步。

1. Chat UX 的整合

最近，我听到一种观点：LLM 预示着彼此独立、面向特定应用的 UX 即将终结。这种思路大致是说，一旦我们能够用自然语言向计算机表达自己的需求，并且自然语言 Agent 能够代替我们执行操作，我们就不再需要今天数量繁多、各自针对特定任务的独立应用。

就我个人而言，我既不相信这种结果会出现，也不希望它出现。正如 Dijkstra 对自然语言编程的否定一样，我不认为自然语言足以承载许多应用所要求的高精度指令。此外，“手动”完成许多数字任务时所包含的那种“低效率”，恰恰是使用计算机能够带来乐趣的核心原因之一——至少对我如此，我猜对其他一部分人也是如此。

即便 LLM 能提供一个完全符合我需求的食谱，我也不愿放弃使用食谱搜索引擎、浏览大量食谱的体验。即便 LLM 能根据我的偏好推荐餐厅，我仍然会想使用基于地图的 UX，探索附近各种各样的选择。试图用 LLM 取代一切 UX，似乎就像是试图用效率取代所有意外发现的乐趣。我认为——或者说希望——这种转变在理论上远比在实践中更具吸引力。

话虽如此，我确实认为，Chat 以及与 Chat 相邻的 UX 会被广泛整合到一个统一的接触点中。目前，每种工具或网站都有一套自己专属的类 Chat UX，比如程序库文档页面上的 Documentation Chat、VSCode 扩展、Google Bard 集成，或者我的银行应用里那个实现得一塌糊涂的聊天机器人。这并没有让其中任何一种体验变得更愉快、更有效或更有趣，只是让它们各自多了一点古怪的独特性。

如果我们正在迈向一个大多数软件和数字体验都能够响应自然语言命令的世界，那么目前横亘在我和命令输入界面之间的所有步骤——例如打开某个针对特定功能的应用或网站——理想情况下，长期来看都应该消失。LLM 很可能会在各种场景的底层被使用，但那些明显由语言模型驱动、对外也呈现为语言模型体验的产品，最终会彼此融合。

除了能够更有效地利用 LLM 的能力之外，我之所以押注这种趋势，还有一部分原因是：彼此分离的 Chat 界面会让本文接下来列出的大多数特征更难实现，比如……

2. 跨使用场景的持久性

目前，持久性在 LLM 中扮演的角色很有意思。从某种意义上说，LLM 和自然语言 UX 尤其容易实现短期持久性——“对话”是交互的基本单元，因此之前请求、操作和陈述的上下文，会自动包含在当前交互之中。LLM 很容易将我当前的意图放进此前意图的上下文里，并据此进行解释。

持久性在 LLM UX 中的理想角色也相当直观：我们很容易想象一种由 LLM 驱动的体验，它能够记住并“理解”我过去与它进行的所有交互，再利用这些信息，更好地协助我完成当前任务。

考虑到计算机过去一直具备的优势，颇具讽刺意味的是：在这幅愿景中，“理解”这一部分目前已经相当可靠，真正欠缺的反而是“记忆”。上下文长度的限制，以及 LLM 权重的静态特性，使得真正实现长期记忆非常困难。RAG 等方案展现出了潜力，但如果要让它作为持久化记忆库大规模运行，似乎仍有大量棘手问题需要解决。

不过，既然这篇文章讨论的幸好只是推测，而不是具体实施方案，那么我只想坚持这样一个判断：到了 2027 年前后，我们将找到实现这种长期持久性的方法，让 LLM UX 能够可靠地纳入我此前任何使用阶段产生的信息。

这种能力也许会通过更复杂的 RAG 实现，也许只是依靠极其漫长的上下文长度——可能借助 RWKV 之类的不同架构——也可能来自我们对 LLM 训练机制理解上的某种激动人心的突破。

我认为，这种能力会成为推动前一项特征——Chat UX 整合——落地的重要催化剂。如果我正在与一种能够记住并利用我此前表达过的偏好、愿望、目标和信息的 UX 交互，那么在不同使用场景之间共享底层记忆，显然是一项能够大幅减少摩擦、又很容易实现的改进。

3. 普遍访问能力（以及多模态）

沿着类似的思路，我认为我们很快就会允许 LLM 访问更广泛的内容，而不仅仅是我们粘贴进聊天框的信息，或者当前在具备 LLM 功能的应用中打开的内容。它们将能够接触到横跨我们整个数字生活的大量内容。

举一个小规模、以开发者为中心的例子：我在 VSCode 中使用 GitHub Copilot。最近，我在实现一个程序库，而它的文档提供了由 LLM 驱动的问答功能。当时，同时打开两种由 LLM 居中协调的体验，却发现它们各自只掌握解决问题所需信息的一半，这种感觉非常荒谬。

如果 LLM UX 最终整合成一个统一、长期存在的助手，我希望这个助手能够从我的浏览历史、笔记本电脑上的文件、云端文件，以及其他任何文本信息源中提取信息。

现代 LLM 最根本、也最不可思议的能力，在于它能将文本转化为可供行动的含义。恰巧的是，我在笔记本电脑上创建或消费的绝大多数内容，都以某种文本形式存在。只有相对较少的一部分采用图片或视频格式，但我认为这不会成为障碍，因为 Multimodal LLM 已经近在眼前。

除了内容本身，我还希望 LLM UX 能够更好地理解我当前以及过去与其他非 LLM UX 的交互。代词长期以来一直是自然语言处理中的难题，而这个问题最新的表现形式，似乎是人们会用代词指代屏幕上的其他东西。

我希望自己永远不再需要把任何内容复制粘贴到聊天框里。用“这个”或“那个”——或者类似的某种表达——来指代窗口、选中的文本，或者鼠标当前悬停的对象，这似乎是实现顺畅交互体验所必需的功能。

我不会在这一点上继续赘述，因为 Linus Lee 已经对此进行了详尽讨论，我确信自己也无法解释得更好。但它看起来的确是 UX 演进中不可或缺、也合乎逻辑的一步。

3b.（但愿能够）商品化并在本地运行的 LLM

更关注隐私的读者，看到前两点时可能已经有些不安。需要说明的是，这些首先是预测。虽然我未必喜欢让 {OpenAI/Microsoft/Google/Whoever} 大量攫取我的数据，只为提供上述功能，但从历史经验来看，用户通常相当愿意牺牲数据隐私，以换取方便且无缝的体验。因此，我预计这一次也会发生同样的事情。

不过，我希望这些发展能够与高效、高性能 LLM，以及运行这些模型推理所需硬件的商品化同步发生。在理想的世界里，我希望底层模型只是一个可以随时替换的实现细节。Llama 2 及类似进展让我对此保持乐观。

我有一个或许有些天真的愿望：如果 LLM 及其记忆库可以在本地运行和维护，它们甚至可能降低各种垂直领域企业大规模收集数据的必要性。只要以我授权的方式与我的 LLM 交互，第三方服务就能获得它们真正需要的精确信息，为我提供个性化体验，而不必依赖那些需要大量宽泛、非特定个人数据的启发式方法和模型。

不过，这些更多只是愿望，而非坚定判断。目前，可在本地运行的开放模型完全无法与 GPT-4 等模型匹敌，我也没有任何充分理由相信，最终在 LLM UX 领域胜出的玩家会在开发产品时将这些顾虑放在心上。🤞

4. 动态生成的 UI 与更高层次的 Prompting

今天的 LLM UX 高度依赖 Chat 和人工编写的 prompt，但我预计这种情况会迅速改变。Prompting 往往更像一门艺术，而非一门科学，其中充满了出人意料的微妙之处，使它远没有最初看起来那么容易上手。

文本是一种普遍直观的界面，但在许多领域，从可发现性和准确性来看，它远不如针对特定领域设计的控件。类似地，LLM 的文本输出往往也不是呈现所请求信息或任务的最佳方式。

我预计在未来几年内，LLM UX 会更加依赖：

• 结构化或半结构化输入；
• 根据响应生成或作为响应组成部分的动态 UI 元素。

我预计我们会看到更多对可执行操作或任务完成方式的建议；更多在幕后完成的 prompt 构建，只需将用户输入插入其中；以及更多 toggle、slider 和 button 等 UX 元素，它们会在用户交互时生成特定的 prompt。

在输出侧，我希望交互能力能成为 LLM 响应的一部分。这样一来，系统不必只是向我发送文本，而是可以直接向我呈现完成任务所需的 UX，让我处理 LLM 系统无法在内部完成的部分。

我还预计，LLM 使用工具以及与其他软件交互的能力会迅速提升，可以参考 Adept、Meta 的 Toolformer，甚至 ChatGPT Plugins。

反过来说——而且这更具推测性——即便其他应用和网站本身并不依赖 LLM，如果统一的 LLM 交互接触点真的成为现实，它们也可能集成能够响应 LLM 的功能。

例如，假设我拥有一个具备长期记忆和广泛上下文的统一 LLM“助手”，那么我可以设想：我访问的网站会通过获得授权的 API 向这个 LLM 发出请求，再利用响应改变向我展示的信息或 UI。我还不确定这种体验具体会是什么样子，但最近我经常重新思考这个想法。

5. 主动交互

最后，如果我们能够构建出集中式的 LLM UX，并让它访问如此丰富的信息，我希望它们能够主动提出建议，而不是始终要求我先发出操作请求。

当然，任何超过一定年龄、读到这句话的人，大概都会想到 Clippy 带来的那些恐怖回忆。没错，主动式 UX 有无数种可能彻底搞砸的方式。

然而，正如 ChatGPT 站在前 LLM 时代聊天机器人留下的垃圾堆上，最终交付了一个真正有用的产品一样，我希望未来对这种主动性的尝试，能够更接近“在正确的时间做正确的事”这一理想。

Maggie Appleton 提出的 LLM Daemons 概念，是一种很有意思的潜在实现：LLM 只在特定内容范围内、围绕明确定义的目标，主动但不打扰地提供建议。GitHub Copilot 也是一种相当不错的主动式 UX 实现，只不过它受到严格限制。

总体而言，我预计随着时间推移，“我去找 LLM”和“LLM 来找我”之间的平衡，会逐渐向后者倾斜。

我确信，这五项特征远不足以完整描绘 LLM UX 的未来方向。但我确实认为，把它们放在一起时，所呈现出的图景已经能够很好地表明事情将朝哪个方向发展：

一个统一的入口，承载大多数明确由 LLM 驱动的交互；它能够访问一个记忆库，其中既包含我过去与它的所有交互，也包含构成我数字生活的所有可消费数据；它能够把当前的 UX 最佳实践作为层级，叠加在 prompt 构建和 LLM 输出之上；还能根据我当前的任务，主动采取有帮助的行动——我愿意押注，我们很快就会开始看到这样的未来。

当然，这仍然只是一个相当高层的描述，还有大量细节需要补充。我希望能在未来的文章和自己的实验中继续完成这项工作。尽管如此，我也希望这个预测足够具体，仍然可以被讨论和质疑。我非常乐意听到反对意见！