今年 3 月,在红杉资本的 AI Ascent 大会上,我谈到了代理的三个局限性:规划、UX 和记忆。您可以在此查看该演讲。在这篇文章中,我将更深入地探讨代理的 UX。感谢 LangChain 的创始工程师 Nuno Campos 提供了许多最初的想法和类比。
由于代理的 UX 涉及许多不同的方面,因此本主题将分为三个单独的博文。这是该系列中的第一篇。
人机交互是一个多年来一直得到充分研究的领域。我相信在未来几年,人机交互也将成为一个关键的研究领域。
代理系统不同于过去的传统计算机系统,这是由于延迟、不可靠性和自然语言接口带来的新挑战。因此,我坚信将出现用于与这些代理应用程序交互的新 UI/UX 范式。
虽然代理系统仍处于早期阶段,但我认为存在多种新兴的 UX 范式。在本博文中,我们将讨论迄今为止可能最主要的 UX:聊天。
流式聊天
“流式聊天”UX 迄今为止是最主要的 UX。这很简单,就是一个以聊天格式流式传输其想法和行动的代理系统——ChatGPT 是最受欢迎的示例。这种交互模式看似简单,但实际上由于几个原因而相当不错。
“编程”LLM 的主要方式是使用自然语言。在聊天中,您可以通过自然语言直接与 LLM 交互。这意味着您与 LLM 之间几乎没有障碍。
终端(尤其是在早期计算机中)提供了对底层操作系统的更低级且更直接的访问。但随着时间的推移,计算机已转向更多基于 UI 的交互。流式聊天可能类似——这是我们构建与 LLM 交互的第一种方式,它提供了对底层 LLM 的相当直接的访问。随着时间的推移,可能会出现其他 UX(就像计算机变得更加基于 UI 一样)——但低级访问具有重大优势,尤其是在开始时!
流式聊天很棒的原因之一是 LLM 可能需要一段时间才能工作。流式传输使用户能够准确了解幕后正在发生的事情。您可以流式传输回 LLM 执行的中间操作(包括它们执行的操作以及结果),以及 LLM“思考”时的标记。
流式聊天的另一个好处是 LLM 经常会出错。聊天提供了一个非常棒的界面,可以自然地纠正和引导它!我们已经非常习惯于通过聊天进行后续对话和迭代讨论。
尽管如此,流式聊天也存在缺点。首先,流式聊天是一种相对较新的 UX,因此我们现有的聊天平台(iMessage、Facebook Messenger、Slack 等)没有内置此模式。其次,对于长时间运行的任务来说,它有点尴尬——我只是坐在那里观看代理工作吗?第三,流式聊天通常需要由人类触发,这意味着人类仍然非常参与循环。
非流式聊天
称之为“非流式”聊天感觉很奇怪,因为直到两年前我们都将其称为“聊天”——但现在就是这样。非流式聊天具有与流式聊天许多相同的特性——它将 LLM 非常直接地暴露给用户,并且允许进行非常自然的更正。
非流式聊天的主要区别在于响应以完整的批次返回,这有利有弊。主要的缺点是您无法看到幕后发生的事情,让您处于黑暗之中。
但是……这实际上可以吗?
Linus Lee 最近在“委托”方面有一些很棒的想法,我真的很喜欢。摘录一小段来说明
我故意将界面设计得尽可能不透明。
他认为不透明的界面需要一定的信任,但一旦建立,就可以让您只需将任务委托给代理,而无需进行微观管理。这种异步特性也有助于更长时间运行的任务——这意味着代理为您完成更多工作。
假设建立了信任,这似乎很好。但它也带来了其他问题。例如,如何处理“重复发消息”——用户发送一次消息,代理开始执行某些操作,然后在代理完成其任务之前,用户再次发送另一条(有时不相关)消息。使用流式聊天,您通常不会遇到此问题,因为代理的流式传输阻止用户键入新的输入。
非流式聊天 UX 的好处之一也更适合我们,这意味着它可能更容易集成到现有工作流程中。人们习惯于向人类发送短信——为什么他们不应该轻松地适应向 AI 发送短信呢?
这通常是由于非流式聊天更本地集成到我们现有的工作流程中。我们并不期望朋友立即回复我们的短信——为什么我们应该期望 AI 立即回复?这使得与更复杂的代理系统交互变得更容易——这些系统通常需要一段时间,如果期望立即响应,可能会令人沮丧。非流式聊天通常消除了这种期望,从而更容易完成更复杂的事情。
最初,流式传输可能看起来比标准聊天更新、更炫酷、更具未来感……但随着我们对代理系统的信任度越来越高,这种情况会逆转吗?
除了聊天之外还有其他方式吗?
由于这只是三部分系列中的第一部分,因此我们认为除了聊天之外,还有更多 UX 需要考虑。尽管如此,仍然值得提醒的是,聊天是一种非常好的 UX,并且它被广泛使用是有原因的。
聊天的优点
- 允许用户直接与模型交互
- 允许轻松进行后续提问和/或更正
流式聊天与非流式聊天的优缺点
