提升ai代理工具选择准确性的策略：如何应对工具复杂性挑战

Rifx.Online
Large Language Models , Best Practices , Industry Insights
27 Feb, 2025

共同作者: Sebastian Carbajales

在我们之前的讨论中，我们探讨了AI代理能够处理的工具数量（“数量”）如何影响令牌消耗。现在，我们将注意力转向 选择准确性 — AI代理为给定任务选择正确工具并生成正确调用规范的能力。随着工具数量和复杂性的增加，选择准确性可能会下降，从而导致低效、错误和糟糕的用户体验。

在本文中，我们将研究工具的“质量”：

工具描述 如何影响准确性。
接口复杂性 在工具选择中的作用。
减轻选择挑战的架构策略。
编写有效的工具描述和参数的 最佳实践。

在本次讨论中，我们关注 单轮工具选择 — AI必须在单次交互中选择正确的工具，而不依赖于先前的对话历史。

这是一篇相当长的文章，如果您只想阅读我们的结论和建议，请跳到“关于工具复杂性的任何指导？”部分。

本文是以AI为先的企业自动化与GenAI和AI代理系列的一部分。

影响工具选择准确性的因素

1. 工具数量对准确性的影响

AI代理可访问的工具越多，选择正确工具的难度就越大。两个关键的研究基准突显了这一挑战：

Nexus功能调用排行榜

Nexus功能调用排行榜 (NFCL) 评估了AI模型中的函数选择。比较不同类别的结果可以揭示工具数量如何影响选择准确性。

VirusTotal类别 → 包含 12个简单API（即12个工具） 用于分析可疑文件和URL。由于每个请求只需要 一次函数调用，因此选择相对简单。
OTX类别 → 包含 9个API 与开放威胁交换互动。这也是一个简单的基准，模型通常能够达到 高准确性分数。

结论： 尽管VirusTotal和OTX都有简单的API，但模型在OTX上的表现优于VirusTotal。VirusTotal中工具数量的增加可能导致性能下降。

最近的ReAct代理基准测试（2025年2月）

Langchain团队最近发布的另一个实验评估了ReAct代理的性能，测试了随着更多工具和指令的添加，AI代理的性能如何变化。

实验发现 随着领域（工具类别）数量的增加，准确性下降。
需要 多个函数调用 的任务准确性下降更为明显。

实验设置：

测试了5个模型： claude-3.5-sonnet, gpt-4o, o1, o3-mini, llama-3.3–70B
对两个领域进行了30个任务的三次运行：日历调度（4个工具）和客户支持（9个工具）
通过向原始领域添加无关领域运行相同任务：最终测试涉及14个领域和117个工具

结论： 从1个领域到14个领域，准确性急剧下降

日历调度任务： gpt-4o的准确性从单一领域和4个工具的43%下降到7个领域和51个工具的仅2%。llama-3–3–70b在所有情况下均失败。
客户支持任务： gpt-4o的准确性从单一领域和9个工具的58%下降到7个领域和51个工具的仅26%。llama-3–3–70b从1个领域下降到7个领域时，从21%降至0%。

这些发现进一步证明，拥有 过多的工具 — 尤其是 与无关工具结合 且 缺乏预选择策略 — 会显著降低性能。

Composio函数调用基准

上述性能评估中的一个共同点是，通过更好的提示和工具描述可以提高准确性。例如，Composio函数调用基准测试了50个函数调用问题，每个问题必须从8个函数模式中选择。该基准评估了几种模式优化技术，并测量了结果准确性，准确性范围从大约 33%（没有优化） 到大约 74%（应用多种优化），这是一个显著的提升。所有优化技术的详细描述可以在基准的网页上找到。

在类似的实验中，Gentoro 创建了更贴合特定提示的等效函数，然后进行了相同的基准测试。结果显示所有测试用例的准确性达到了100%，证明了设计与用户需求对齐的工具的价值，而不仅仅是镜像API接口。通过定义一个更接近用户与系统交互方式的接口，该实验能够实现更优的性能和准确性。然而，这种方法需要额外的实施努力，因为它涉及对API的业务用例有更深入的理解，并调整API签名以优化不同的用例。

结论： 工具设计与其描述和优化同样重要，关系到选择准确性的成功。有效平衡以用户为中心的设计与计算效率的能力将对开发能够在广泛用例中持续提供高性能结果的工具至关重要。

2. 接口复杂性对选择的影响

选择正确的函数只是第一步。下一个挑战是生成正确的输入以调用函数。这里有三个关键因素影响准确性：

工具参数的数量（更多参数会增加混淆）。
工具接口中使用的数据结构的复杂性。
工具规格的描述性。

NVD库与VirusTotal和OTX的比较

对NVD库类别在NFCL中的分析发现，模型在NVD库中的表现不如在VirusTotal或OTX中的表现。

NVD库类别仅包含两个API，因此选择应该是直接的。
然而，每个API都有30个参数，这使得AI更难正确映射输入。
结论：这表明即使小型工具集也可能导致选择错误，如果参数设计过于复杂。

3. 如何编写有效的工具描述和参数

伯克利函数调用排行榜 (BFCL) 提供了关于参数的数量和复杂性如何影响AI模型性能的宝贵见解。在其第二个版本中，平均参数数量为四个参数，最复杂的函数有28个参数。参数数量的变化直接影响模型准确选择和执行函数的能力。

此外，BFCL V2 强调了在现实世界应用中，需要模型从多个选项中选择合适函数的场景更加普遍。这突显了设计具有可管理参数数量的函数以提高选择准确性和整体性能的重要性。
结论：一个明确定义的工具描述可以显著提高选择准确性。让我们来看一些例子。

示例 1：模糊/不清晰的数据定义

如果一个工具需要多个输入，使用基于 JSON架构 的 结构化数据定义 可以使AI更容易选择和正确使用。

❌ 坏例子：

{ 
  “name”: “stock_info”, 
  “description”: “Get stock market data.”, 
  “parameters”: { 
    “ticker”: “Stock symbol”, 
    “date”: “Date” 
  } 
}

🔴 为什么这是不好的？

函数名称过于一般。
描述没有明确提供哪些股票数据。
没有为日期或股票代码输入指定格式说明。

✅ 好例子：

{ 
  “name”: “get_stock_data”, 
  “description”: “Retrieves real-time or historical stock market data, including price, volume, and trends.”, 
  “parameters”: { 
    “ticker”: { 
      “type”: “string”, 
      “description”: “Stock symbol of the company (e.g., ‘IBM’ for IBM.).” 
    }, 
    “date”: { 
      “type”: “string”, 
      “format”: “YYYY-MM-DD”, 
      “description”: “Date for historical stock data retrieval (leave blank for real-time data).” 
    } 
  } 
}

🟢 为什么这更好？

精确的函数名称（“get_stock_data”明确了检索）遵循“{operation}{entity}{data}”的约定。— 虽然没有固定的规则来命名函数，但我们可以遵循“{operation}{entity}{data}”的简单格式，例如“get_stock_quote”，“update_product_price”，“query_flight_schedule”，“update_account_address”。
扩展的描述（指定实时或历史数据）。
结构化的参数（确保AI正确解释输入）。

示例 2：差的与有效的工具描述

❌ 差的工具描述：

{ 
  "name": "weather_info", 
  "description": "获取某个位置的天气详情。", 
  "parameters": { 
    "location": "用户的位置", 
    "unit": "温度单位" 
  } 
}

🔴 为什么这不好？

模糊的函数名称（“weather_info”没有具体说明检索什么信息）。
不清晰的描述（什么类型的天气详情？当前天气还是预报？）。
差的参数描述（“unit”是指摄氏度/华氏度吗？）。

✅ 好的工具描述：

{ 
  "name": "get_weather_data", 
  "description": "检索给定位置的当前温度、湿度和天气预报。", 
  "parameters": { 
    "location": { 
      "type": "string", 
      "description": "请求天气数据的城市名称或地理坐标。" 
    }, 
    "unit": { 
      "type": "string", 
      "enum": ["Celsius", "Fahrenheit"], 
      "description": "温度显示的首选单位。" 
    } 
  } 
}

🟢 为什么这更好？

清晰且描述性的函数名称（“get_weather_data”明确说明它检索天气数据）。
详细的描述（澄清提供了什么信息）。
定义良好的参数（包括类型、有效值和详细描述）。

示例 3：简单与复杂参数设计（采购用例）

让我们举一个例子，AI代理正在选择一个工具来在采购系统中查找产品。

❌ 过于复杂的参数结构（AI更难处理）

{ 
  “name”: “search_product_catalog”, 
  “description”: “根据各种过滤条件在采购目录中查找产品。” , 
  “parameters”: { 
    “category”: { 
      “type”: “object”, 
      “properties”: { 
        “department”: { 
          “type”: “string” 
        }, 
        “subcategory”: { 
          “type”: “string” 
        } 
      }, 
      “description”: “产品的部门和子类别。” 
    }, 
    “specifications”: { 
      “type”: “object”, 
      “properties”: { 
        “brand”: { 
          “type”: “string” 
        }, 
        “material”: { 
          “type”: “string” 
        }, 
        “size”: { 
          “type”: “string” 
        } 
      }, 
      “description”: “产品规格。” 
    }, 
    “price_range”: { 
      “type”: “object”, 
      “properties”: { 
        “min_price”: { 
          “type”: “number” 
        }, 
        “max_price”: { 
          “type”: “number” 
        } 
      }, 
      “description”: “最低和最高价格范围。” 
    }, 
    “availability”: { 
      “type”: “string”, 
      “enum”: [“in_stock”, “out_of_stock”, “backorder”], 
      “description”: “可用性状态。” 
    } 
  } 
}

🔴 为什么这不好？

嵌套字段过多（例如，类别 → 子类别，规格 → [品牌、材料、尺寸]）。
迫使AI推理深层对象结构，增加错误风险。
由于深层嵌套，令牌使用量更高。

✅ 简化的、AI友好的结构（更有利于选择准确性）

{ 
  “name”: “search_product_catalog_by_brand”, 
  “description”: “根据简单过滤条件在采购目录中查找产品。” , 
  “parameters”: { 
    “query”: { 
      “type”: “string”, 
      “description”: “搜索产品的关键字（例如，‘办公椅 人体工学’）。” 
    }, 
    “category”: { 
      “type”: “string”, 
      “description”: “主要产品类别（例如，‘办公用品’，‘家具’）。” 
    }, 
    “brand”: { 
      “type”: “string”, 
      “description”: “首选品牌名称（可选）。” 
    }, 
    “price_min”: { 
      “type”: “number”, 
      “description”: “最低价格过滤器。” 
    }, 
    “price_max”: { 
      “type”: “number”, 
      “description”: “最高价格过滤器。” 
    }, 
    “availability”: { 
      “type”: “string”, 
      “enum”: [“in_stock”, “out_of_stock”, “backorder”], 
      “description”: “按产品可用性过滤。” 
    } 
  } 
}

🟢 为什么这更好？

将嵌套字段扁平化为简单参数（没有复杂的对象结构）。
使用灵活的“query”参数，而不是强制结构化输入。
缩小选择范围（例如“按品牌”），而不是支持所有可能的选择标准。
通过减少深层嵌套来最小化决策复杂性。

关于工具复杂性的任何指导方针？

在给定工具中，参数的数量或嵌套结构的深度没有严格限制，但以下是一些一般指导方针：

1–5 个参数且无嵌套（1级） → 模型管理起来容易。
6–10 个参数，最多 2 级嵌套 → 输入错误的可能性增加，尤其是在没有结构化指导的情况下（即未使用 JSON 架构）。
10 个以上参数或超过 2 级嵌套 → 错误参数映射的风险高，特别是在没有结构化指导的情况下。

提高工具选择准确性的策略

✅ 1. 通过更好的提示和工具描述来提高准确性

减少参数数量

仅包含必要的输入。 删除冗余或可选字段。
如果一个参数很少需要，将其作为可选默认值处理，而不是每次都要求。
将复杂操作中包含许多参数的内容拆分为多个参数较少的工具，并在描述中明确或重命名新工具集。

扁平化嵌套结构

尽量使用基于字符串的表示，而不是深度嵌套的对象。
将多个相关参数合并为一个单一字段（例如，使用类别而不是部门和子类别）。

使用枚举减少自由格式输入

如果一个参数有有限的有效值，使用枚举列表而不是让AI生成自由文本。
示例：

{ 
  "availability": { 
    "type": "string", 
    "enum": ["in_stock", "out_of_stock", "backorder"], 
    "description": "Filter by product availability." 
  } 
}

为什么？ AI不需要推断可接受的值。

预格式化复杂数据以减少认知负荷

使用基于JSON架构的预结构化格式，而不是要求AI组合复杂输入。
示例：允许一个单一格式化字符串（“品牌：Logitech，颜色：黑色，大小：中等”），而不是要求一个结构化的JSON对象用于产品规格。

✅ 2. 分层工具选择：子代理和监督代理

与其让单个AI代理处理所有工具，不如为特定领域使用子代理，并由监督代理路由请求。

🔹 示例：

用户请求财务数据。
监督代理路由到财务代理。
财务代理选择正确的API（例如，股票价格与预算分析）。

✅ 3. 动态工具激活

Instead of sending all tools in every request, 根据用户查询预过滤工具。

🔹 示例：

If the user asks about weather, only weather-related tools should be sent.
If the query is about finance, omit weather tools to improve selection accuracy.