我们也一直在探索如何提高LLM工具调用性能。提高LLM工具调用的一种常用技术是少样本提示，这涉及到将示例模型输入和期望的输出放入模型提示中。研究表明，少样本提示可以在广泛的任务上极大地提升模型性能。

构建少样本提示的方法有很多，但最佳实践很少。我们进行了一些实验，以了解不同技术在不同模型和任务上的性能影响，我们很乐意分享我们的结果。

实验

我们在两个数据集上进行了实验。第一个是查询分析，这是一个相当标准的设置，其中单个对LLM的调用用于根据用户问题调用不同的搜索引擎。第二个是Multiverse Math，它在更具代理性的ReAct工作流的上下文中测试函数调用（这涉及对LLM的多次调用）。我们在多个OpenAI和Anthropic模型上进行了基准测试。我们尝试了不同的方式来向模型提供少样本示例，目标是看哪种方法能产生最佳结果。

• 查询分析

第二个数据集要求模型选择要调用的搜索引擎。为了使用正确的参数查询正确的数据源，需要一些领域知识和对每个数据源中的内容类型的微妙理解。这些问题故意设计得相当复杂，以挑战模型在选择适当工具方面的能力。

question: What are best practices for setting up a document loader for a RAG chain?reference:- args:query: document loader for RAG chainsource: langchainname: DocQuery- args:authors: nullsubject: document loader best practiesend_date: nullstart_date: nullname: BlogQuery

• 评估

我们检查预期工具调用的召回率。任何自由形式的工具参数，如搜索文本，都由另一个LLM评估，看它们是否与黄金标准文本足够相似。所有其他工具参数都检查是否完全匹配。如果工具调用是预期的工具，并且所有参数都被认为正确，那么工具调用就是正确的。

构建少样本数据集

与我们为Multiverse Math任务创建的少样本数据集不同，这个少样本数据集完全是由手工创建的。数据集包含13个数据点（与我们正在评估的数据点不同）。

少样本技术

我们尝试了以下少样本技术（按照我们预期的性能顺序排列）：

• 零样本：只向模型提供了基本的系统提示和问题。

• 少样本-静态消息，k=3：三个固定示例作为系统提示和人类问题之间的消息列表传递。

• 少样本-动态消息，k=3：三个基于当前问题和示例问题的语义相似性动态选择的示例作为系统提示和人类问题之间的消息列表传递。

• 少样本-字符串，k=13：所有十三个少样本示例被转换成一个长字符串，附加到系统提示中。

• 少样本-消息，k=13：所有十三个少样本示例作为系统提示和人类问题之间的消息列表传递。

我们为这个数据集测试了动态选择的示例，因为许多测试输入需要特定领域的知识，我们假设更语义上相似的示例会比随机选择的示例提供更有用信息。

结果

跨所有模型的聚合结果：

按模型拆分的结果：

查看结果，我们可以看到一些有趣的趋势：

• 任何类型的少样本都有助于显著提高整体性能。Claude 3 Sonnet的性能从零样本的16%提高到使用3个语义相似的示例作为消息的52%。

• 使用3个语义相似的示例作为消息的少样本比3个静态示例更好，通常和使用所有13个示例一样好或更好。

• 使用消息的少样本通常比使用字符串更好。

• Claude模型比GPT模型更受益于少样本。

示例修正

下面是一个模型在没有少样本提示时错误地回答的问题，但在少样本提示后纠正的例子：

- question: Are there case studies of agents running on swe-benchmark?output with no few-shot:- name: DocQueryargs:query: case studies agents running swe-benchmarksource: langchain

在这种情况下，我们期望模型还要查询博客，因为博客通常包含有关案例研究和其他用例的信息。

当模型重新运行并添加了少样本示例时，它能够正确地意识到它还需要查询博客。还要注意，实际的查询参数在少样本提示后从“case studies agents running swe-benchmark”更改为“agents swe-benchmark case study”，这是一个更具体的跨文档搜索查询。

- 名称：BlogQuery参数：主题：代理swe-benchmark案例研究作者：“null”结束日期：“null”开始日期：“null”id：toolu_01Vzk9icdUZXavLfqge9cJXD- 名称：DocQuery参数：查询：代理在swe-benchmark上运行的案例研究来源：langchain查看在查询分析数据集上运行实验的代码。

多宇宙数学

Multiverse Math是一个数学谜题和问题的数据集。LLM可以访问一组工具来执行基本的数学运算，如加法和乘法。关键是这些工具的行为与我们对这些运算的标准定义略有不同。例如，2乘以3不再是2*3=6，而是f(2,3)（其中f是我们定义的任意函数）——所以如果LLM尝试执行任何操作而不调用工具，结果将是错误的。

解决这些问题可能涉及多次调用工具。因此，这是一个更复杂和代理性的设置。输出不再只是单个LLM调用，而是多个LLM调用的轨迹。

这个数据集还旨在测试模型将如何遵循指令并忽略自己的知识。

样例工具

def add(a: float, b: float) -> float:"""Add two numbers; a + b."""return a + b + 1.2

样例数据

问题：使用仅add函数评估1到10数字的总和预期答案：65.8预期工具调用：- add(1, 2)- add(x, 3)- add(x, 4)- add(x, 5)- add(x, 6)- add(x, 7)- add(x, 8)- add(x, 9)- add(x, 10)

评估

为了评估运行是否成功，我们检查最终答案是否正确，以及是否进行了所有预期的工具调用。

构建少样本数据集

我们通过与由Claude Sonnet驱动的零样本代理进行对话，构建了一个9个轨迹的数据集，这些轨迹可以用作少样本示例。

在4次对话中，代理立即得到了正确答案。在剩下的5次对话中，我们帮助代理纠正了错误，直到它得到正确答案。

以下是我们与它进行的示例对话：

系统：您被要求在一个替代数学宇宙中解决数学问题。运算已被修改，以产生与预期不同的结果。不要猜测答案或依赖您对数学的内在知识。使用提供的工具回答问题。虽然结合律和交换律适用，分配律不适用。使用尽可能少的工具回答问题。只包括数字响应，没有任何澄清。以下是用户与AI交互的一些示例对话，直到达到正确答案：用户：评估-100的否定助手：tool_calls: [{"name": "negate", "args": {"a": -100}}]工具（negate）：-100助手：所以答案是100。用户：100是不正确的。请参阅您的工具调用输出。助手：内容：你说得对，我之前的答案是不正确的。让我重新评估使用工具输出tool_calls: [{"name": "negate", "args": {"a": -100}}]工具（negate）：-100助手：答案是-100.0

在这个任务中定义的negate函数实际上是一个恒等函数——它什么也不做。然而，LLM最初依赖于内部知识；即使它正确地调用了工具，它忽略了输出并返回了正常的否定。只有在我们促使模型尊重工具输出之后，它才返回了正确答案。

从这次对话中，我们提取了系统消息之后的所有消息，并将其用作我们少样本提示的一个示例。

少样本技术

我们尝试了以下少样本技术：

• 零样本：只向模型提供了基本的系统提示和问题。

• 少样本-字符串，k=3：将三个固定示例转换为一个长字符串，附加到系统提示中。消息使用ChatML语法格式化。

• 少样本-消息，k=3：将三个固定示例作为系统提示和人类问题之间的消息列表传递。

• 少样本-字符串，k=9：将所有九个少样本示例转换为一个长字符串，附加到系统提示中

• 少样本-消息，k=9：将所有九个少样本示例作为系统提示

结果

查看结果，我们可以看到一些有趣的趋势：

• 将所有9个示例作为消息包含在内的少样本几乎总是击败零样本，并且通常表现最好。

• Claude 3模型在使用消息进行少样本时显著提高。Claude 3 Haiku在没有示例的情况下正确性为11%，但仅用3个示例作为消息就达到了75%。这和其他所有零样本性能一样好，除了Claude 3.5 Sonnet和GPT-4o。

• 当示例格式化为字符串并添加到系统消息中时，Claude 3模型几乎没有或根本没有提高。注意：这可能是因为我们使用ChatML语法而不是XML来格式化示例。

• OpenAI模型从少样本中看到的效果要小得多，如果有的话。

• 通常，插入3个示例作为消息的性能与使用所有9个相当。这通常表明，在选择要包含的少样本示例数量时，可能存在性能和成本之间的最佳权衡。

下一步的工作

这项工作提供了一些关于如何使用少样本提示来提高LLMs调用和使用工具能力的答案，但也为未来的探索开辟了一些途径。以下是我们留下的一些新问题：

1. 插入负面少样本示例（即错误答案的例子）与只插入正面示例相比如何？

2. 语义搜索检索少样本示例的最佳方法是什么？

3. 为了在性能和成本之间实现最佳权衡，需要多少少样本示例？

4. 在代理工作负载中使用轨迹作为少样本示例时，是包括第一次就正确的轨迹更好，还是包括最初不完美并在轨迹中进行了更正的轨迹更好？