Tulip Agent – 基于 LLM 智体使用大型工具库解决任务

24年7月来自欧洲本田研究所的论文“Tulip Agent – Enabling LLM-Based Agents to Solve Tasks Using Large Tool Libraries”。

Tulip Agent，是一种基于 LLM 的自主智体架构，富有大量工具的工具库创建、读取、更新和删除访问权限。与最先进的实现相比，Tulip Agent不会在系统提示中编码所有可用工具的描述（这计入模型的上下文窗口），也不会嵌入整个提示以检索合适的工具。相反，Tulip Agent可以在其可扩展工具库中递归搜索合适的工具，该库以向量存储的形式实现。Tulip Agent架构显著降低了推理成本，允许使用甚至大型工具库，并使智体能够调整和扩展其工具集。

参考实现和基准如 GitHub - HRI-EU/tulip_agent: autonomous agent with access to a tool library 。

如图是Tulip Agent求解一个数学问题的架构实例：

大语言模型 (LLM) 的进步为实现自主智体提供了技术基础。示例包括助手（例如纯软件智体或设备上的智体）以及以机器人形式体现的人工智能。提高此类智体自主性的关键方面，是它们对环境的理解以及在环境中采取行动的能力。这已经成为可能，因为 LLM 能够规划并严格遵守指令，包括其输出格式，从而使它们能够使用工具。尽管 LLM 取得了这些进步并不断增加上下文窗口，但当前的实现仍然存在固有的局限性，存在以下挑战 1-3：

挑战 1（成本）工具描述计入 LLM 的上下文窗口，从而增加推理时间和金钱方面的成本。
挑战 2（注意和工具限制）从大量工具中进行选择对 LLM 来说是一项挑战，因为它带来了一种“大海捞针”的挑战。因为 LLM 很难进行长输入的上下文学习（Li et al. [2024]），很难检索多个事实，也很难推理这些事实（LangChain, 2024）。此外，可以提供给 LLM 的工具数量可能有限，例如 OpenAI 模型就是这种情况。
挑战 3（静态性）工具的使用是静态的，并且仅限于先验定义的工具，这限制了自主智体的适应性及其对开放式场景的适用性。
Tulip Agent架构旨在通过为 LLM 提供对可扩展工具库的访问权限来解决挑战 1 - 3。这使得可以访问任意大小的工具集，这些工具可以高效扩展和调整，同时降低总体成本。

如图概述了Tulip Agent的组件，箭头表示信息流。要设置Tulip Agent，需要通过代码自省自动提取有关可用工具（在例子中是 Python 函数）的信息。从函数的文档字符串中，生成嵌入，这些嵌入与工具信息的 LLM 兼容表示 一起存储在工具库中（0）。当收到用户提示时（1 ），模型将请求分解为子任务，并将相应的描述传递给搜索模块 （2） 。这些描述是嵌入的基础，搜索模块使用嵌入通过语义搜索为每个子任务找到合适的工具（检索）。搜索模块将有关最相关工具的信息传递给模型 （3） ，模型为所有子任务适当地调用工具 （4） 。相应工具执行 （5） 并将结果反馈给模型 （6） ，从而允许模型启动进一步的操作或向用户提供响应 （7） 。

工具是一种可执行函数，它可实现某种目的并返回结果或状态消息。示例包括计算器提供的数学函数，以及对机器人 API 的调用。为了方便向Tulip Agent提供工具，需要导入包含函数的整个文件。

对于使用工具，LLM 需要工具的唯一标识符（可解析该标识符以调用工具）、工具用途的描述以及必要输入参数的名称、类型和描述。这种方法依赖于函数分析器进行自省。它可以提取根据 Sphinx 样式记录的 Python 函数，但这可以扩展到其他类型的工具。从提取的信息中，构建一个工具库。原则上，工具库可以是任何支持搜索合适工具的数据库。由于用户提供自然语言输入，并且 LLM 适用于自然语言，因此通过密集嵌入进行语义搜索（允许将任务与可用工具匹配）尤其有前景。在智体初始化期间，创建函数名称和相应文档字符串的嵌入，即捕获语义的向量表示，并将它们与自省模块生成的函数描述一起存储。生成的向量存储允许通过语义搜索来搜索合适的工具。初始化工具库的过程总结在如下算法 1 中：

初始化时，Tulip Agent可以接受自然语言用户输入，描述要完成的任务。与可用工具的粒度相比，此类任务通常处于高抽象层次。因此，它们无法合理地与单个工具匹配。为了应对这种情况，用 LLM 将任务分解为子任务。粒度和清晰度对于减少任务描述和合适工具描述之间的语义距离至关重要。这是因为任务描述中不必要的细节会增加噪音，并可能导致更模糊的工具建议。在分解过程中，让 LLM 为子任务创建更通用的描述，这些描述可以更好地与工具的通用描述匹配。这导致规划以子任务的通用自然语言描述列表的形式出现。

Tulip Agent在其工具库中搜索每个子任务的合适工具。具体来说，为规划中的每个子任务创建一个嵌入，并与工具描述的嵌入进行匹配，返回最合适的前 k 个工具。

值得注意的是，Tulip Agent架构支持递归分解和搜索工具。如果初始子任务不够细粒度，无法找到合适的工具，这很有用。通过为语义搜索设置相似度阈值，可以确保只返回合适的工具。如果没有找到描述与任务描述足够相似的工具，智体会进一步分解子任务，对下一级工具进行另一次搜索。为了避免无限循环，求助于设置最大递归深度。

如下算法 2 总结了在工具库中搜索工具作为语义搜索的过程。默认情况下，用平方 l2 范数作为嵌入向量之间的距离函数：

根据由子任务和已识别工具组成的规划，LLM 会生成工具调用。这是逐步完成的，允许 LLM 考虑先前的返回值。请注意，工具调用可以采用结构化 JSON 响应的形式，例如针对工具使用进行微调的模型或必须解析的文本。对于每个工具调用，都会从查找中检索相应的工具，参见算法 1 中的 ToolLookup，然后由工具执行器使用提供的参数执行该工具。工具的返回值可以是中间结果（例如来自计算）、状态消息（例如来自机器人动作）或有关失败的反馈。此结果反馈给 LLM，使模型能够通过调用其他工具甚至在工具库中搜索其他相关工具来做出反应。当所有子任务都得到解决或 LLM 无法解决任务时，LLM 可能会向用户提供最终响应。

如下算法 3 总结了 CotTulipAgent 的查询过程；它包括几个步骤，首先将用户强加的任务分解为子任务，为每个子任务搜索合适的工具，使用这些工具，并响应最终结果：

平台原型在 Python 3.10 中实现，工具库基于 ChromaDB 构建。作为语言模型，通过 API 使用 OpenAI 模型，具体来说是 gpt-4-turbo-2024-04-09 和 gpt-3.5-turbo-0125，以及作为嵌入模型的 text-embedding-ada-002、text-embedding-3-small 和 text-embedding-3-large。为了获得尽可能确定的结果，将温度设置为 1e-9 并重复实验五次。请注意，报告成本的四分位均值。这是因为 API 交互限制为 100 可能会导致异常值，从而扭曲比较。