Skip to content

搞英语 → 看世界

翻译英文优质信息和名人推特

Menu
  • 首页
  • 作者列表
  • 独立博客
  • 专业媒体
  • 名人推特
  • 邮件列表
  • 关于本站
Menu

LLM 函数调用无法扩展;代码编排更简单、更有效。

Posted on 2025-05-22

TL;DR:将工具调用的完整输出提供给 LLM 成本高昂且速度缓慢。输出模式将使我们能够获取结构化数据,以便我们可以让 LLM 使用生成的代码来协调处理。在代码中调用工具既简单又高效。


处理 MCP 工具调用的一个常见做法是将工具的输出作为消息发送回 LLM,并请求 LLM 执行下一步操作。这样做的目的是希望模型能够理解如何解释数据,并确定下一步应该采取的正确操作。

当数据量较小时,这种方法可以很好地发挥作用,但我们发现,当我们使用真实数据尝试 MCP 服务器时,它很快就会崩溃。

现实世界中的 MCP

我们公司使用 Linear 和 Intercom。我们连接到了它们上周发布的最新官方 MCP 服务器,以了解它们如何响应工具调用。

事实证明,两个服务器都返回了很大的 JSON 数据块,这些数据块与它们的 API 类似,只是文本内容没有任何预定义的模式。这意味着解析它们的唯一合理方法是让 LLM 解释数据。

Linear MCP 将问题列表返回为一个大的 JSON blob

这些 JSON 数据块非常庞大!当我们使用 Linear 的 MCP 列出项目中的问题时,该工具默认只返回 50 个问题,约 7 万个字符,对应约 2.5 万个 token。

ID 字段变成大量标记

JSON 包含许多id字段,这些字段占用了许多标记,并且在语义上没有意义。

当将 Claude 与 MCP 一起使用时,似乎整个 JSON blob 都会被逐字发送回模型。

这种方法很快就会遇到问题。例如,如果我们想让人工智能按截止日期对所有问题进行排序并显示出来,它就需要将所有问题逐字逐句地重现为输出标记!这会很慢,成本高昂,而且可能会丢失数据。

我们的问题数据通常包含大量令人分心的信息:重现问题的步骤、错误信息,甚至可能是用户使用的提示,或者后续跟进用户的说明。模型可能无法准确地输出其中一些数据,甚至更糟的是,偏离原始指令。

数据与编排

这里的核心问题是我们在同一个聊天线程中混淆了编排和数据处理。

“多代理”方法试图通过启动另一个聊天线程(“代理”)来解决这个问题,使其专注于数据处理部分。如果经过仔细调整,它的性能会更好,但当我们的数据结构已经很好时,它仍然会显得笨拙。

如果 MCP 服务器已经返回 JSON 格式的数据,那么解析数据并对其进行操作似乎更为自然。回到我们的排序示例,与其要求 LLM 直接重现输出,不如对数据运行sort操作并返回新的数组。这样不会产生任何错觉,而且这种方法适用于任何大小的输入。

代码执行作为数据处理

这听起来很熟悉,因为我们已经有了AI的代码解释器。当我们开始将代码执行作为处理MCP工具( Code Act 、 Smol Agents )数据的基本方式时,这将为AI模型的可扩展工作方式打开大门。

变量作为内存。LLM无需外部内存系统,而是可以使用变量(系统内存)来存储任何数据。存储内存相当于为变量赋值,查看变量相当于打印变量值,并且模型可以选择在调用其他函数时将变量作为参数传递。更棒的是,如果使用的语言类型良好,模型还可以利用该模式。

工具链。代码可以协调多个函数调用:并行执行,或将一个或多个调用的输出作为另一个调用的输入。函数调用之间的依赖关系通过代码所表示的计算图隐式表示。重要的是,LLM 无需重新整理数据,并且我们保证其完整性。

可扩展处理。通过代码自然可以转换大量数据。模型可以选择使用循环,或依赖 NumPy 或 pandas 等库进行大规模数据转换。

代码还可以调用后台的其他 LLM:您可以让 LLM 编写调用 LLM 进行非结构化数据处理(LLM-inception)的代码。

MCP 准备好了吗?

MCP 规范已经定义了输入模式,并且刚刚引入了输出模式。

一旦输出模式得到广泛传播,我们期望它们能够在大型数据集上解锁用例:构建自定义仪表板、创建已完成票证的每周报告,或让自主代理监控并推动停滞的问题向前发展。

什么使得代码执行变得困难?

现在的挑战转移到了 MCP 客户端。目前大多数执行环境都运行在严格控制的沙盒中;由于我们处理的是用户/AI 生成的代码,因此安全性至关重要。

允许执行环境也访问 MCP、工具和用户数据需要仔细设计 API 密钥的存储位置以及工具的公开方式。

在我们的设计中,我们创建了以特定 API 访问权限为密钥的沙盒环境,并为模型提供了有关如何调用这些 API 的文档,以便它们能够发送/检索信息而无需看到秘密。

大多数执行环境都是有状态的(例如,它们可能依赖于为每个用户会话运行 Jupyter 内核)。如果用户希望稍后能够返回 AI 任务会话,那么这种状态管理起来会很困难,而且成本高昂。对于长期运行(持续多日)的任务会话来说,无状态但持久的执行环境至关重要。

这些限制正在催生一种我们认为全新的运行时类别——“AI 运行时”,它使用 LLM 来编排和执行任务。我们目前仍处于制定这种代码执行方法所有细节的早期阶段,我们期待任何正在解决类似问题的人士提供反馈。如果您对我们的方法感兴趣,可以前往Lutra进行尝试。

原文: https://jngiam.bearblog.dev/mcp-large-data/

本站文章系自动翻译,站长会周期检查,如果有不当内容,请点此留言,非常感谢。
  • Abhinav
  • Abigail Pain
  • Adam Fortuna
  • Alberto Gallego
  • Alex Wlchan
  • Answer.AI
  • Arne Bahlo
  • Ben Carlson
  • Ben Kuhn
  • Bert Hubert
  • Bits about Money
  • Brian Krebs
  • ByteByteGo
  • Chip Huyen
  • Chips and Cheese
  • Christopher Butler
  • Colin Percival
  • Cool Infographics
  • Dan Sinker
  • David Walsh
  • Dmitry Dolzhenko
  • Dustin Curtis
  • Elad Gil
  • Ellie Huxtable
  • Ethan Marcotte
  • Exponential View
  • FAIL Blog
  • Founder Weekly
  • Geoffrey Huntley
  • Geoffrey Litt
  • Greg Mankiw
  • Henrique Dias
  • Hypercritical
  • IEEE Spectrum
  • Investment Talk
  • Jaz
  • Jeff Geerling
  • Jonas Hietala
  • Josh Comeau
  • Lenny Rachitsky
  • Liz Danzico
  • Lou Plummer
  • Luke Wroblewski
  • Matt Baer
  • Matt Stoller
  • Matthias Endler
  • Mert Bulan
  • Mostly metrics
  • News Letter
  • NextDraft
  • Non_Interactive
  • Not Boring
  • One Useful Thing
  • Phil Eaton
  • Product Market Fit
  • Readwise
  • ReedyBear
  • Robert Heaton
  • Ruben Schade
  • Sage Economics
  • Sam Altman
  • Sam Rose
  • selfh.st
  • Shtetl-Optimized
  • Simon schreibt
  • Slashdot
  • Small Good Things
  • Taylor Troesh
  • Telegram Blog
  • The Macro Compass
  • The Pomp Letter
  • thesephist
  • Thinking Deep & Wide
  • Tim Kellogg
  • Understanding AI
  • 英文媒体
  • 英文推特
  • 英文独立博客
©2025 搞英语 → 看世界 | Design: Newspaperly WordPress Theme