大型语言模型（LLMs）已经超越了基本的文本生成，发展成为能够通过功能调用的方式与外部系统进行程序化互动的强大工具。这种能力使得LLMs能够通过预定义的功能执行API调用，进一步发挥它们在更高级和实用应用中的潜力。
例如，设想一个旅行者想要修改航班的返程日期。通过函数调用，大语言模型可以访问航空公司的预订 API。当提示“将我的返程航班日期从十一月二十五日改到十二月一日”时，大语言模型可以理解请求，选择适当的修改预订函数，并提供参数，如预订 ID 和新的日期。然后它会调用 API 来调整行程，从而有效地完成任务而无需进一步的用户干预。
这种操作的成功很大程度上取决于函数的定义。清晰且结构良好的函数能够让大型语言模型理解指令并执行正确的任务，直接影响性能表现。这使得函数设计成为达到高准确度和实用性的关键因素。
这篇文章比较了定义函数的两种不同方法——API导向和用户导向。通过基准测试来，它探讨了这两种方法在性能上的差异，并进一步探讨了这些差异产生的原因。
与 API 对齐的方法
在设计一个用于通过API与企业系统交互的GenAI应用程序时，一个自然的选择是定义直接对应所需API操作的LLM函数。然后，LLM的任务是将传入的提示映射到这些API对应的函数上。
这种方法通过一组特定的提示和八个功能来展示基准测试结果（这些功能代表项目管理服务API的各个端点，更多详细信息请参见https://composio.dev/blog/gpt-4-function-calling-example/）。最初，未经任何优化，Composio仅达到33%的准确率。通过逐步改进功能定义，比如调整参数结构或提供更清晰的描述，他们将准确率提升至74%。
这种方法的准确性在一定程度上取决于LLM的质量。一个更强大的LLM，就像一个更有经验的开发者一样，通常能更好地应对复杂场景。例如，当输入参数被展平而非深度嵌套时，LLM表现得更有效。虽然更先进的模型可以无缝处理嵌套参数，但较弱的模型则很难应对这种复杂的情况。
然而，与API对齐相关的功能中的一些挑战超出了LLM的基础能力——即使是一个“天才”级别的等同于开发者的LLM，在某些情况下也可能会失败：
1. 隐含的知识要求: 正确使用端点可能需要了解一些特定的情境或专业知识，这些内容不是单靠查看定义就能明白的。
示例: 例如，一个提示要求 LLM “将项目存档”，但 API 端点需要一些额外的隐藏参数，比如是否通知团队成员或保留特定的元数据。
2. 术语不匹配：提示中使用的词汇可能与 API 使用的词汇不匹配。
示例: 用户请求中提到“购物车”，而API将其定义为ItemList（项目列表）。没有额外指导时，模型无法正确理解这些术语。
这些挑战凸显了API对齐方法内在的局限性。虽然在API定义明确且映射简单的场景下，这种方法可以有效，但要实现一致的准确性则不仅需要改进大语言模型（LLM），还需要解决功能定义中的模糊性和用户输入对齐中的差距问题。
用户对齐的方法
与基于API的方法不同的是，可以根据用户输入的提示来定义函数。这种方法更注重用户如何自然地表达他们的请求。这两种方法的区别可以简单总结如下：
• 与 API 结构对齐的函数： 这些函数与 API 的结构紧密相连，需要 LLM 花更多的功夫将用户提示映射到合适的函数上。
• 与用户指令更贴近的功能: 这些功能旨在减少大语言模型的映射负担。然而，这通常需要更多的实现工作，可能需调用多个API端点或进行额外计算。
两种函数设计的途径
生成函数（一种数学工具）
API 对齐的功能通常是根据 API 规范直接生成的，因此实现起来非常简单。而用户对齐的功能则必须根据提示来推导，这意味着提示必须是实体完整的——也就是说，它们必须明确地提及定义功能所需的所有实体和参数。
例如，如果一个 API 端点需要一个模式(mode)参数，用于生成与用户需求对齐的函数的提示必须明确指定这个参数。如果提示未提及该参数，生成的函数定义也会缺少这个参数，在实现时可能会选择一个默认值。确保提示的完整性对于生成有效的与用户需求对齐的函数至关重要。
用户界面功能面临的挑战
虽然用户对齐的功能化简化了LLM将提示绑定到功能的任务，为LLM提供了便利，但也带来了独特的难题。
1. 功能繁多： 一个主要缺点是可能会创建出许多针对性很强的功能，每个功能对应特定的输入提示变更。在最糟糕的情况下，这将导致每种提示变化都有一个对应的功能，从而导致实现过于复杂且碎片化。
2. 通用化过程: 为了缓解这一问题，必须将过拟合的函数整合成一组较小的通用功能。这一过程必须确保通用化不会影响大型语言模型准确绑定到这些功能的能力。必须谨慎地找到一个平衡点，以保持效率和可靠性，同时保持与用户输入的一致性。
使用 Composio 功能调用基准测试这两种方法
Composio基准包含50个提示，每个提示都有一个预期结果，对应于大型语言模型将输入绑定到八个预定义功能中的一个。该基准旨在衡量各种优化技术下的API对齐功能的性能。为了评估用户对齐的方法，使用同样的提示生成相应的用户对齐功能，然后执行并将其与基准的预期结果进行比较。
一个显著的挑战是在这种比较中，这些用户对齐的功能在结构上与预定义的八个API对齐的功能有所不同。为应对这一问题，开发了一款语义比较工具，详情如下。
评估步骤如下:
每个提示的评估都是按照以下步骤进行的。
1. 生成功能: 根据提示，生成了 Gentoro 的功能描述。
2. 快速执行提示: 将提示和生成的函数一起提交给大型语言模型，并记录了由此产生的函数调用记录。
3. 对比: 使用自定义语义比较器将记录的函数调用记录与基准测试的预期输出进行了语义对比。
这表明，采用用户对齐的方式，所有50个提示都成功运行。
基准运行情况细节
在基准评估过程中，出现了这样的情况：某些预期的函数调用在提示中没有明确给出所需值。在用户对齐的方法中，由于输入提示中没有这些参数，生成的函数调用轨迹中也不会出现这些参数。为解决这种不匹配的问题，评估者设置为忽略这些未出现在原始提示中的参数。修改后的基准测试结果可以在这里查看：https://github.com/gentoro-gh/Composio-Function-Calling-Benchmark
以下用于比较实际结果和预期结果的系统提示信息为：
系统消息：
对比两个函数调用（预期和实际），以确定它们是否匹配。倾向于通过测验，只有在无法通过创造性推理解决这些不匹配时才视为失败。
用户消息：
匹配步骤
1. 解析与标准化：
- 提取参数为键值对。
- 将嵌套结构扁平化（例如，a=(b=(enabled=true)) 转换为 a.b.enabled=true）。
2. 处理别名：
- 使用映射来处理语义上等价的参数（例如，due_dates_enabled ↔ features.due_date.enabled）。
- 将两个列表转换成统一格式。
3. 排除无关或未引用的参数：
- 忽略未明确提及或调用所需参数。
- 除非明确关键，否则实际调用中缺失的参数不予考虑。
4. 比较参数：
- 精确、语义或创造性地匹配键值。
- 解决歧义时倾向于通过。
5. 忽略多余参数：
- 实际调用中的额外参数不会影响通过与否。
6. 汇总发现：
- 总结匹配的、排除的和忽略的参数。
7. 决定通过或失败：
- 通过：只有当所有相关参数一致或存在合理的匹配时。
- 失败：如果一个关键的、明确引用的参数无法以任何方式一致；在这种情况下，不要尝试寻找通过的其他理由。切换到全屏模式，退出全屏模式
实验设置
以下是一些我们用来评估的指标：
• 型号: GPT-4o-2024-08-06
• 温度是: 0,8
• Top-p: 0.8
影响、挑战与应对挑战和结论
该评估展示了将函数定义与用户提供的输入相匹配以简化LLM调用函数过程的可能性。通过减少对僵化API模式的依赖性，用户对齐的方法论简化了函数绑定，并减少了调整提示的复杂性。然而，尽管这种方法显示出前景，但仍需进行更广泛的测试和验证，以进行全面的评估，从而全面评估其在不同的场景和使用案例中的有效性。
在评估中，一个显著的挑战是测试的依次进行，每个工具都是单独创建、测试并被丢弃的。优化这一流程以一次性处理多个提示，可以显著提高效率。此外，当前的基准主要集中于相对简单的场景，如果能扩展至更复杂的多步骤任务或更高计算需求，将能更深入地了解用户对齐的系统或工具的可扩展性和鲁棒性。
另一个挑战在于平衡具体性和通用性之间的关系。使功能与用户指令紧密对齐可以简化LLM的功能绑定，但这也可能生成过多的专用功能。未来的研究应探索如何将过度拟合的专用功能整合为更通用的功能的技术，同时不牺牲LLM准确地将提示映射到这些更广泛定义的能力。
混合策略也为未来的研究提供了有前景的方向。通过动态调整功能定义和提示信息，混合方法可以结合API对齐方法的精准性与用户对齐方法的灵活性，提供了一个既平衡又可扩展的解决方案，适用于实际应用中。
总之，这种方法为提高LLM在函数调用任务中的准确性提供了一个明确的方向，但其需要进一步的完善和测试。解决测试效率、函数泛化和广泛基准测试等挑战将是发挥这种方法潜力的关键。通过结合这些努力和混合策略，该领域可以朝着更灵活和稳健的LLM函数调用机制迈进。