Communication is all you need

沟通至关重要

7 分钟阅读
“我们这里的问题是沟通失败” - 《铁窗喋血》(1967)

沟通是人生中最难的部分。它也是构建 LLM 应用程序中最难的部分。

新员工入职总是需要大量的沟通,无论他们多么聪明。这可能包括获得关键程序和最佳实践指南,让经理介入以帮助新员工快速上手,以及获得访问特定软件以正确完成工作的权限。在适应期间,给予和接收持续的反馈确保新员工在其职位上取得成功。

正如新员工入职需要周到的沟通一样,构建代理也需要良好的沟通标准。无论底层 LLM 变得多么智能,它们仍然需要适当的上下文才能可靠地运行,并且需要正确地传达该上下文。

💡
大多数时候,当代理无法可靠地执行时,根本原因不是模型不够智能,而是上下文和指令没有正确地传达给模型。

不要误解我的意思 - 模型确实会出错,并且有改进的空间。但通常情况下,问题归结为基本的沟通问题。

如果我们相信沟通是构建 LLM 应用程序的关键部分,那么从这个公理出发,我们可以推导出一些关于代理的其他“热门观点”,这些观点应该成立。我在下面简要列出了一些。所有这些都可以(也许将会)成为独立的博客文章。

为什么提示工程不会消失

随着模型的改进,提示工程技巧,例如 用小费贿赂 LLM 或担心 JSON 与 XML 格式化将变得几乎过时。但是,对于您来说,有效且清晰地与模型沟通并就如何处理各种场景给出明确的指示仍然至关重要。

💡
模型不是读心术者 - 如果您希望它以某种方式运行或处理特定信息,您必须提供该上下文。

诊断您的代理无法工作的最佳技巧是简单地查看对 LLM 的实际调用以及提示的确切输入——然后确保如果您将这些输入提供给您认识的最聪明的人,他们将能够按照您的预期做出回应。如果他们做不到,那么您需要澄清您的请求,通常是通过调整提示。这个过程,称为提示工程,不太可能在短期内消失。

为什么代码将构成代理“认知架构”的很大一部分

提示是向 LLM 传达它们应如何在代理系统中运行的一种方式,但代码同样重要。代码是传达系统应如何运行的绝佳方式。与自然语言相比,代码可以让您更精确地传达您期望系统采取的步骤。

💡
您的代理的“认知架构”将由代码和提示组成。

代理的某些指令只能用自然语言传达。其他的可以用代码或语言来表达。代码可以更精确、更高效,因此在构建代理的“认知架构”时,我们看到代码在很多方面比提示更有用。

为什么您需要代理框架

对于您作为代理开发人员来说,为了最好地向代理传达它应该做什么,编写一些代码是必要的。这构成了您应用程序的认知架构,并且是您的竞争优势和护城河的一部分。

💡
您将不得不编写的其他一些代码是您需要构建的通用基础设施和工具,但它们不提供任何差异化。这就是代理框架可以提供帮助的地方。

代理框架通过让您专注于代码中重要的部分 - 代理应该做什么 — 同时处理与您应用程序的认知架构无关的常见问题,从而促进这一点,例如

  • 清晰地流式传输代理正在执行的操作
  • 持久性以支持多租户内存
  • 为人机在环交互模式提供动力的基础设施
  • 以容错、水平可扩展的方式运行代理

为什么 LangGraph 是目前最可控的代理框架至关重要

您需要一个代理框架来处理上面列出的一些问题,但仍然可以让您尽可能清晰地(通过提示和代码)传达代理应该做什么。任何阻碍这一点的代理框架都会碍事 - 即使它使入门更容易。坦率地说,这就是我们在 langchain 中看到的 - 它使入门变得容易,但存在内置提示、硬编码的 while 循环,并且不易扩展。

我们确保使用 LangGraph 解决了这个问题。

💡
LangGraph 与所有其他代理框架的不同之处在于它专注于低级别、高度可控和高度可定制。

没有任何内置的东西会限制您可以构建的认知架构。节点和边只不过是 Python 函数 - 您可以将任何您想要的东西放入其中!

代理将在其认知架构中大量使用代码。代理框架可以帮助消除一些常见的基础设施需求。但是它们不能限制您代理的认知架构。这将阻碍您传达您究竟想要发生什么的能力,并且代理将不可靠。

为什么像 LangGraph 这样的代理框架将长期存在

我被问到的一个比较常见的问题是:“随着模型变得更好,这会消除对像 LangGraph 这样的框架的需求吗?”。潜在的假设是模型会变得非常好,以至于它们将消除对 LLM 周围任何代码的需求。

不会。

如果您使用 LangGraph 从模型中引出更好的通用推理,那么当然,也许会。

但这不是大多数人使用它的方式。

💡
大多数人使用 LangGraph 来构建垂直领域特定的、高度定制的代理应用程序。

沟通是其中的关键部分,而代码是沟通的关键部分。沟通不会消失,代码也不会消失——因此 LangGraph 也不会消失。

为什么构建代理是一项多学科的工作

我们很快注意到的一件事是,构建代理的团队不仅仅由工程师组成。

💡
非技术主题 matter 专家通常在构建过程中也起着至关重要的作用。

一个关键领域是提示工程,领域专家通常为提示编写最佳的自然语言指令,因为他们比工程师更了解 LLM 应该如何运行。

然而,领域专家的价值不仅仅在于提示。他们可以审查代理的整个“认知架构”,以确保所有逻辑(无论是用语言还是代码表达)都是正确的。像 LangGraph Studio 这样的工具可以可视化您的代理流程,使这个过程更容易。

领域专家还可以帮助调试代理为什么会出错,因为代理经常因为沟通失败而出错 - 领域专家非常擅长发现这种差距。

为什么我们将 LangSmith 打造成最用户友好的“LLM Ops”工具

由于 AI 工程需要多个团队协作才能弄清楚如何最好地使用 LLM 进行构建,因此像 LangSmith 这样的“LLM Ops”工具也侧重于促进这种类型的协作。大多数分类流程的重点是 - “查看您的数据!”,我们希望在 LangSmith 中非常容易地查看大量主要为文本的响应。

我们从一开始就投入巨资的一件事是用于可视化代理轨迹的漂亮 UI。这种美观是有目的的 - 它使所有技术水平的领域专家更容易理解正在发生的事情。它比 JSON 日志更清晰地传达了正在发生的事情。

💡
LangSmith 中轨迹的可视化使每个人 - 无论技术能力如何 - 都能够理解代理内部正在发生的事情,并为诊断任何问题做出贡献。

LangSmith 还在其他领域促进跨团队协作 - 最值得注意的是,提示游乐场 - 但我喜欢使用跟踪作为示例,因为它非常微妙但非常重要。

为什么人们要求我们将 LangSmith 轨迹暴露给他们的最终用户

出于上述相同的原因,我们有多家公司要求将 LangSmith 轨迹暴露给他们的最终用户。了解代理正在做什么不仅对开发人员很重要 - 对最终用户也很重要!

当然,还有其他(更用户友好的方式)比我们的轨迹更适合做到这一点。但听到这个请求仍然令人感到荣幸。

为什么 UI/UX 是 AI 创新最重要的领域

这篇文章的大部分内容都集中在构建 AI 代理时与它们沟通的重要性上,但这同样适用于最终用户。允许用户以透明、高效和可靠的方式与代理交互对于采用至关重要。

💡
AI 应用程序的力量归结为它在多大程度上促进了人机协作,因此我们认为 UI/UX 是最重要的创新领域之一。

我们已经讨论了我们看到的正在出现的不同代理 UX (此处, 此处, 和 此处),但这个领域仍然处于非常早期的阶段。

沟通至关重要,因此最能促进这种人机交互模式的 UI/UX 将带来更好的产品。

沟通至关重要

沟通可以意味着很多事情。它是人类体验不可或缺的一部分。随着代理尝试完成越来越多类人的任务,我坚信良好的沟通技巧将使您成为更好的代理开发人员 — 无论是通过提示、代码还是 UX 设计。

沟通不仅仅是用自然语言表达,它还可以涉及代码以更精确地沟通。最擅长沟通某事的人是那些最了解它的人,因此构建这些代理将成为跨职能的。

最后,我想用乔治·伯纳德·肖的一句话来结束:“沟通中最大的问题是认为已经发生沟通的错觉。” 如果我们想要一个 LLM 应用程序解决实际问题的未来,我们需要弄清楚如何更好地与它们沟通。

感谢 Nuno Campos、Julia Schottenstein 和 Linda Ye 阅读本文草稿。