由于代理系统的用户体验涉及许多不同方面,这个主题将分为三篇独立的博客。这是系列的第一篇。

人机交互一直是多年来备受关注的研究领域。我相信在未来几年,人机代理交互也将成为一个关键的研究领域。

由于延迟、不可靠性和自然语言界面带来的新挑战,代理系统与过去的传统计算机系统有所不同。因此,我坚信将会出现与这些代理应用交互的新型UI/UX范式。

虽然代理系统还处于早期阶段,但我认为已经出现了多种新兴的UX范式。在这篇博客中,我们将讨论迄今为止可能最主要的UX:聊天。

流式聊天

"流式聊天"UX是目前最主流的UX。这很简单,就是一个以聊天格式流式返回其思考和行动的代理系统 — ChatGPT是最流行的例子。这种交互模式看似基础,但实际上有几个很好的优点。

"编程"大语言模型(LLM)的主要方式是使用自然语言。在聊天中,你可以通过自然语言直接与LLM交互。这意味着你和LLM之间几乎没有障碍。从某种意义上说,流式聊天就像早期计算机的"终端"。

终端(尤其是在早期计算机中)提供了对底层操作系统更低级和更直接的访问。但随着时间的推移,计算机已经转向更多基于UI的交互。流式聊天可能也类似 - 它是我们构建的与LLM交互的第一种方式,并提供了对底层LLM相当直接的访问。随着时间的推移,其他UX可能会出现(就像计算机变得更加基于UI一样) – 但低级访问在开始时确实有显著的优势!

流式聊天之所以很棒的原因之一是LLM可能需要一段时间来工作。流式传输使用户能够准确理解底层发生的情况。你可以流式返回LLM采取的中间动作(它们采取了哪些动作,以及结果如何),还可以在LLM"思考"时流式返回tokens。

流式聊天的另一个好处是LLM经常会出错。聊天提供了一个很好的界面来自然地纠正和引导它!我们已经很习惯在聊天中进行后续对话和迭代讨论了。

尽管如此,流式聊天也有其缺点。首先 - 流式聊天是一种相对较新的UX,所以我们现有的聊天平台(iMessage、Facebook Messenger、Slack等)还没有内置这种模式。其次,对于长时间运行的任务来说有点尴尬 — 我是不是要坐在那里看着代理工作?第三,流式聊天通常需要由人类触发,这意味着人类仍然非常需要参与其中。

非流式聊天

称之为"非流式"聊天感觉有点奇怪,因为直到两年前我们还只是称之为"聊天" — 但现在情况就是这样。非流式聊天具有许多与流式聊天相同的特性 - 它将LLM直接暴露给用户,并允许非常自然的纠正。

非流式聊天的最大区别在于响应以完整的批次返回,这有利有弊。主要的缺点是你无法看到底层发生的情况,让你处于黑暗中。

但是...这实际上没问题吗?

Linus Lee最近对"委派"有一些很棒的想法^[2],我非常喜欢。这里摘录一小段来说明:

我有意将界面构建得尽可能不透明。

他认为,不透明的界面需要一定程度的信任,但一旦建立,就允许你只是将任务委派给代理,而无需微观管理。这种异步性质也适合长时间运行的任务 - 这意味着代理可以为你做更多工作。

假设已经建立了信任,这看起来不错。但它也带来了其他问题。例如,你如何处理"双重发信” — 用户发送一条消息,代理开始做某事,然后用户在代理完成任务之前又发送了另一条不同(有时无关)的想法。使用流式聊天,你通常不会遇到这个问题,因为代理的流式输出会阻止用户输入新内容。

非流式聊天UX的一个好处是它对我们来说更加原生,这意味着它可能更容易集成到现有的工作流程中。人们习惯于与人类发短信 - 为什么他们不应该轻松适应与AI发短信呢?

非流式聊天的另一个巨大好处是,AI花更长时间回复通常是可以接受的。

这通常是因为非流式聊天更自然地集成到我们现有的工作流程中。我们不期望朋友立即回复短信 - 为什么我们要期望AI立即回复呢?这使得与更复杂的代理系统交互变得更容易 - 这些系统通常需要一段时间,如果期望立即得到回应,可能会令人沮丧。非流式聊天通常消除了这种期望,使做更复杂的事情变得更容易。

起初可能看起来流式传输更新、更炫、更具未来感...但随着我们对代理系统的信任度提高,这种情况会不会反过来?

除了聊天还有其他方式吗?

由于这只是三部曲系列的第一部分,我们相信除了聊天之外还有更多UX需要考虑。尽管如此,值得提醒的是聊天是一种非常好的UX,这就是它被广泛使用的原因。

聊天的好处:

• 允许用户直接与模型交互
• 允许轻松进行后续问题和/或纠正

流式vs非流式聊天的优缺点

参考资料