一个被忽视的真相

在Function Calling的实践中，我们做了一个对比实验：用同一个模型（GPT-4o），但分别用"草率写就"和"精心设计"的函数Schema，测试准确率。

结果令人震惊：草率Schema的准确率只有72%，而精心设计的Schema达到了94%。差距如此之大，以至于我们重新审视了函数Schema设计的重要性。

Schema设计的黄金法则

法则一：函数名是模型的"路标"。

函数名是模型选择函数的第一依据。一个好的函数名应该：使用动词+名词格式（如search_products、get_weather、create_order）；避免缩写（用get_user_profile而不是get_usr_prof）；避免过于通用的名称（用search_flights而不是search）。

法则二：函数描述是微型的用户手册。

函数描述不只是给开发者看的，更是给模型看的。一个好的描述应该包含三部分：这个函数做什么（一句话概括）、什么情况下应该调用（使用场景）、调用后返回什么（返回值格式）。

法则三：参数描述要具体，不要抽象。

不要写"用户ID"，要写"用户的唯一标识符，可以在用户个人资料页面的URL中找到，格式为’usr_‘开头后跟10位数字"。

不要写"日期"，要写"查询日期，格式为YYYY-MM-DD，例如2026-07-13。如果不提供，默认为今天"。

法则四：使用枚举值约束参数。

如果一个参数只有几个固定选项，用enum来约束，而不是让模型自由发挥。比如：

"status": {
  "type": "string",
  "enum": ["pending", "processing", "shipped", "delivered", "cancelled"],
  "description": "订单状态"
}

法则五：提供示例值。

在参数描述中提供示例值，可以帮助模型更好地理解参数的格式和含义。特别是对于日期、ID、复杂对象等参数。

常见Schema设计错误

错误一：函数描述过于笼统。 “查询信息的函数”——什么信息？什么时候用？返回什么？模型完全不知道。

错误二：参数描述缺失。 只有一个参数名，没有任何描述。模型只能靠猜。

错误三：多个函数的功能重叠。 search_products和find_products和query_products都做同样的事。模型不知道该选哪个。

错误四：必需参数和可选参数没有区分。 所有参数都标记为required，或者所有参数都标记为optional。模型无法判断哪些信息是必须的。

错误五：Schema与实际API不一致。 Schema说参数是string，但实际API需要integer。或者Schema没有包含某个参数，但实际API需要。

Schema设计的测试方法

写好Schema后，需要用测试来验证。我们推荐以下测试方法：

单元测试：对每个函数，构造10个典型的用户请求，检查模型是否正确选择函数和提取参数。

边界测试：构造模糊的、不完整的、矛盾的请求，检查模型的处理是否正确。

回归测试：每次修改Schema后，重新跑一遍测试集，确保没有引入新的问题。

A/B测试：如果你不确定两种Schema设计哪种更好，用A/B测试来验证——让一部分用户使用Schema A，另一部分使用Schema B，对比实际效果。

进阶技巧

渐进式函数发现：如果函数太多（超过20个），可以考虑渐进式发现——先展示函数类别，用户选择类别后再展示具体函数。

函数优先级提示：在system prompt中给出函数调用的优先级指引，帮助模型在相似函数之间做出选择。

动态Schema：根据用户的历史行为和当前上下文，动态调整Schema——只展示当前场景下最相关的函数。

结论

在Function Calling中，Schema设计是最被低估的环节。一个好的Schema可以把一个平庸的模型变成优秀的工具使用者，而一个差的Schema可以毁掉最好的模型。在你花时间比较模型之前，先花时间优化你的Schema。