LLM—通过LLM执行复杂学术信息查询API调用，避免人为设置的困难性，细节理解与原文阅读：A Solution-based LLM API-using Methodology

A Solution-based LLM API-using Methodology for Academic Information Seeking

基于解决方案的 LLM API 学术信息查询方法

其实就是给定一个思维链的方式微调开源模型或者利用上下文学习用于闭源模型，具体来说就是：
给定用户查询Q:
1.使用LLM拆分负责的Q，生成多个简单的子查询
2.根据不同的子查询，使用LLM来回答要调用的api代码，并执行调用，返回子结果
3.根据子结果，使用LLM对结果进行合并，使其最终符合人类预期

paper: https://arxiv.org/pdf/2405.15165

github: https://github.com/RUCKBReasoning/SoAY?tab=readme-ov-file

application: http://soay.aminer.cn

1.背景动机

现有大模型用作学术检索的问题：

大语言模型有可能进一步减少学术信息搜索所需的工作量。让 LLMs 利用现有的学术检索/挖掘 API往往是一个可行的解决方案。然而，存在两个主要挑战：

1. 耦合： 学术查询所需的学术信息分布在不同的存储位置，这导致多个学术 API 负责不同的功能，但又相互连接。这就要求 LLM 充分了解这些 API 之间的调用顺序。现有的使用 API 的方法，会分别检索和执行 API 以获取结果，因此无法处理这种 API 耦合。
2. 效率：现有方法采用基于深度优先搜索的决策树进行逐步推理，这种方法有可能捕捉到 API 序列中的规律性。然而，与传统学术搜索引擎相比，过多的步骤会导致用户无法接受的查询时间。

本文提出的一种自动生成API调用顺序，其实可以理解为代理：

提出了 SoAY，一种基于解决方案的 API 使用方法，将 LLM 应用于学术信息搜索。

1. 首先让LLM根据复杂的用户输入生成可行的API调用计划，即解决方案
2. 然后让LLM根据生成的解决方案生成可执行的API调用代码。

在生成后续代码时，预生成的解决方案可以帮助 LLM 明确学术 API 之间复杂的耦合关系。在单一推理过程中通过代码生成调用 API，无需重复推理，可以达到接近传统学术搜索系统的效率水平。

2.Model

2.1.任务描述

对于soay的任务描述：

SoAY 任务是根据用户查询 $Q$，寻找适当的学术信息 $I$。要实现这一目标，需要有效地顺序使用学术应用程序接口。

利用LLM将复杂的用户查询分解为简单独立的查询，即单个API就能解决的子问题：

问题 1： 基于 $Q$，SoAY 需要了解用户需要哪些学术信息，然后识别其中的关联并进行单独查询。
Q → Q S , Q S = { Q i } i = 1 N . (1) Q\to Q_{S},\quad Q_{S}=\{Q_{i}\}_{i=1}^{N}. \tag{1} Q→QS​,QS​={Qi​}i=1N​.(1)
传统的学术搜索系统无法完成这项任务，因此需要将 $Q$ 分解为逐步查询 $Q_S$ 输入搜索框。而 SoAY 则需要使用 LLM 来分解意图，并获取相关的 API 调用序列。

对子问题调用API的结果，使用LLM进行结果合并，从而输出用户需求信息：

问题 2： SoAY 根据 $Q_S$ 从数据源中检索相关信息，并对结果进行聚合和处理，以向用户提供他们所寻求的精确信息 $I$ 。

传统的信息检索系统缺乏这种设计，而是将所有检索到的信息以列表的形式显示给用户，让他们选择自己想要的信息。SoAY 需要做的是生成正确的代码来调用学术应用程序接口，并在与传统系统相当的时间内处理所获得的信息。

2.2.SoAY的API调用架构

引入了 SoAY，以调整用于学术信息搜索的通用 LLM，强调使用现有的学术 API。为实现这一目标，以（学术查询、可执行 API 序列）对形式存在的大量训练数据是必不可少的，这有助于对现有 LLM 进行微调，或通过上下文学习对其进行指导。该数据生成管道包括四个关键步骤：

1. 解决方案库的构建 利用所提供的学术应用程序接口，构建了一个表示应用程序接口之间依赖关系的图，并遍历该图以识别有效和简单的路径，称为解决方案。
2. 组合表述 为了获得库中每个解决方案的更精确语义，将解决方案的初始 API 的所有可能输入和最终 API 的所有输出组合起来，形成一系列组合。
3. 查询生成 利用 ChatGPT 将每个组合转化为缺乏特定学术实体数据的模板问题。然后，这些模板被多样化为各种表达式，并通过专门的学术数据源的数据填充到潜在的学术查询中。
4. **代码生成。**最后，再次使用 ChatGPT 给出组合，编写一段相应的代码，预计该代码将与具有相同组合的模板查询相对应。

值得注意的是，在数据准备部分，将 ChatGPT 标注为 gpt-3.5-turbo-0613。

2.3.解决方案库构建

给定一个学术应用程序接口库 $L\_A$，第一步是建立一个应用程序接口图，其中每个节点代表一个应用程序接口 $f$，从节点 $f_n$ 到节点 $f_m$ 的有向边表示从 $f_n$ 到 $f_m$ 的耦合关系，交叉属性为 $a_{n,m}$。

定义 1：应用程序接口耦合定义了学术应用程序接口调用中输入和输出的频繁依赖关系
$$\begin{gathered} f_n\stackrel{a_{n,m}}{\to }{f}_m, \\ if{a}_{n,m}=i_m\cap o_n\text{and}a\ne \varnothing ,\text{\hspace{1em}(2)} \end{gathered}$$

其中，$i_n$ 表示 $f_m$ 的输入参数，$o_n$ 表示 $f_n$ 返回的属性。

API 耦合 $f_n\stackrel{a}{\to }{f}_m$ 意味着可以使用 $f_n$ 输出属性 ${}_{n,m}$，然后使用 $a_{n,m}$ 作为输入参数调用 $f_m$。这是因为 $a_{n,m}$ 是 $f_n$ 返回属性 $o_n$ 和 $f_m$ 输入参数 $i_m$ 的交集。

定义 2： 一个解决方案$S$被定义为从应用程序接口图中遍历的应用程序接口的执行序列：
$$\begin{array}{c}S=f_1\stackrel{a_{1,2}}{\to }{f}_2\cdots \stackrel{a_{k-1,k}}{\to }{f}_k\cdots \stackrel{a_{J-1,J}}{\to }{f}_J,\\ \forall k,f_k\in L_A.\end{array}\text{\hspace{1em}(3)}$$

2.4.结果代码生成

在一个解决方案 $S$ 中，第一个 API 被称为头部 API $f_1$，而最后一个 API 被称为尾部 API $f_J$。由于 ** 头部 API 输入***$i_1$ 和 ** 尾部 API 输出***${}_J$ 的多样性，即使在解决方案建立后，确定在什么条件（输入）下寻找哪些信息（输出）仍然是不确定的。一种直观的方法是将头部 API 输入、解决方案和尾部 API 输出结合起来，将意图空间细化为具体要求。

Query Generation:

模板查询生成 对于给定的组合$C$，我们定义一个模板问题$Q_T$来表示实体信息缺失的$C$的意图。在所提供的示例中，相应的模板问题 $Q_T$ 可以表述为 “XXX 的第一作者毕业于哪所学校？”，其中 "XXXX "指的是代表出版物标题的占位符

语义扩展和实体填充 一个模板问题$Q_T$所代表的特定意图可以通过多个自然语言查询来表达。例如，"XXX 毕业于哪所学校？"和 "XXX 的母校是什么？"表达的是同一个意图。为了丰富意图的语义多样性，我们通过制作提示来进行语义增强，利用 Chat-GPT，为每个组合生成三个新的、语义丰富的模板问题。

语义增强后，我们将模板中的特殊符号（用大写字母 "X "表示）替换为学术数据源中特定学术实体的信息。问题模板中的占位符必须用特定学术实体的属性来替换

Code Generation:

最后一步，再次使用 ChatGPT 生成一段代码，与输入信息缺失的给定组合 $C$ 相对应。该代码的目的是获取与模板查询 $Q_T$ 共享相同组合 $C$ 的答案。仍然是来自特定学术实体的信息，$i_1$ 是生成代码的输入。该代码被期望执行后能得到与 $o_J$ 相同的结果，这可以看作是该代码的黄金信息。如果结果与黄金信息相符，则该代码有效。任何不产生匹配结果的无效代码都将被排除在最终数据集之外。

2.5.LLM训练方式

• 闭源模型：SoayGPT 是针对 GPT等模型提出的解决方案，这些模型的参数无法修改，但具有很强的指令跟随能力。我们从构造的数据中选取了一组不同的三元组（triplet），作为构建提示的示例，这些三元组代表了解决方案的不同用途。给定查询后，SoayGPT 通过上下文学习依次生成解决方案和代码，然后执行生成的代码以获得结果。

• 开源模型：SoayLLaMA 则是针对 LLaMA模型的微调策略，通过使用来自构造数据集中的三元组查询作为输入，并将解决方案和代码整合为输出，SoayLLaMA 经过训练，可根据给定的查询，在zero-shot设置下一步生成解决方案和代码。

3.原文阅读

Abstract

在学术应用程序接口（API）使用中应用大型语言模型（LLM）有望减少研究人员的学术信息搜索工作量。然而，目前的 LLM API 使用方法难以应对学术查询中常见的复杂 API 耦合。为了解决这个问题，我们介绍了 SoAY，一种基于解决方案的学术信息搜索 LLM API 使用方法。它使用带有解决方案的代码作为推理方法，其中解决方案是预先构建的 API 调用序列。解决方案的加入降低了模型理解 API 之间复杂关系的难度。代码提高了推理的效率。

为了评估 SoAY，我们引入了 SoAYBench，这是一个评估基准，与 SoAYEval 配套，建立在 AMiner API 的克隆环境之上。实验结果表明，与最先进的基于 LLM API 的基准相比，SoAY 的性能提高了 34.58-75.99%。所有数据集、代码、调整模型和部署的在线服务均可在 https://github.com/RUCKBReasoning/SoAY 上公开访问。

1 Introduction

作为日常学术活动的一部分，研究人员经常查找学术信息，如论文的元数据、学者的发表记录以及学者之间的联系。学术信息检索系统–包括 DBLP（dblp 团队，2005 年）、CiteSeer（Giles 等人，1998 年）和 Google Scholar（Noruzi，2005 年）–以及微软学术搜索（Sinha 等人，2015 年）和 AMiner（Tang 等人，2008 年）等更复杂的学术挖掘平台的出现，大大降低了探索学术数据的复杂性，因为学术数据包含作者、会议和论文等大量实体。

指出现有大模型用作学术检索的问题：

大语言模型（Zhao 等人，2023 年）（LLMs）具有理解自然语言表达意图的推理能力，因此有可能进一步减少学术信息搜索所需的工作量。让 LLMs 利用现有的学术检索/挖掘 API（Qin 等人，2023 年）往往是一个可行的解决方案。然而，由于存在两个主要挑战，这种适应并非易事：

1. 耦合： 学术查询所需的学术信息分布在不同的存储位置，但内部又相互连接，这导致多个学术 API 负责不同的功能，但又相互连接，即耦合。这就要求 LLM 充分了解这些 API 之间的调用顺序。现有的使用 API 的方法，如图 1(a) 所示的 Chameleon（Lu 等人，2023 年），会分别检索和执行 API 以获取结果，因此无法处理这种 API 耦合。
2. 效率：图 1(b)所示的 Tool-LLM Qin 等人（2023 年）等现有方法采用基于深度优先搜索的决策树（DFSDT）进行逐步推理，这种方法有可能捕捉到 API 序列中的规律性。然而，与为研究人员提供快速响应的传统学术搜索引擎相比，过多的步骤会导致用户无法接受的查询时间。

我们提出了 SoAY，一种基于解决方案的 API 使用方法，将 LLM 应用于学术信息搜索。我们的关键创新在于新的 API 调用方法：解决方案和代码。如图1（c）所示，SoAY首先让LLM根据复杂的用户输入生成可行的API调用计划，即解决方案，然后让LLM根据生成的解决方案生成可执行的API调用代码。在生成后续代码时，预生成的解决方案可以帮助 LLM 明确学术 API 之间复杂的耦合关系。在单一推理过程中通过代码生成调用 API，无需重复推理，可以达到接近传统学术搜索系统的效率水平。具体来说，LLM 能够以这种方式可靠地利用复杂的学术 API 来完成学术搜索任务，得益于自动生成的训练数据集，该数据集由（查询、解决方案、代码）三元组组成。这些数据是在 AMiner API 上创建的，从而产生了 3960 个自动三元组。我们保留了其中的 4/5 个三元组，为微调现有 LLM 或展示 LLM 上下文学习提供了宝贵的资源。这种调整有助于弥合一般 LLM 与学术 API 使用的复杂性之间的差距。

为了评估 SoAY，我们使用了 1/5 的生成数据，包括 792 个（查询、解决方案、代码）三元组。这些数据经过人工验证后得到增强，以确保测试集的质量。然后，我们介绍 SoAYEval，这是一种同时考虑解决方案正确性和代码执行准确性的评估方法。通过使用 SoAYEval 进行自动评估和人工评估，我们的实验证明，与使用最先进 LLM API 的基线相比，SoAY 在使用 AMiner API 时，在上下文学习和调整模式中都非常有效和高效。此外，我们还验证了 SoAY 在其他学术检索系统中的通用性。

本文的贡献包括：（1）SoAY，一种新颖的法学硕士适应方法，通过自动生成数据解决学术信息搜索中的耦合和效率等挑战，教会法学硕士使用学术 API。(2) SoAYBench 是一个已发布的基准数据集，并附有 SoAYEval 评估方法，用于评估法学硕士使用学术 API 的熟练程度。(3) 在 AMiner 系统中展示 SoAY 的有效性和效率，以及在在线服务中的实际部署。

2 Task Formulation

SoAY 的任务是根据复杂的用户查询 $Q$，高效地寻找适当的学术信息 $I$。要实现这一目标，往往需要以有效和高效的顺序使用学术应用程序接口。

问题 1： 基于 $Q$，SoAY 需要了解用户需要哪些学术信息，然后识别其中的关联并进行单独查询。
Q → Q S , Q S = { Q i } i = 1 N . (1) Q\to Q_{S},\quad Q_{S}=\{Q_{i}\}_{i=1}^{N}. \tag{1} Q→QS​,QS​={Qi​}i=1N​.(1)
传统的学术搜索系统无法完成这项任务，因此需要用户将其需求 $Q$ 分解为逐步查询 $Q_S$ 输入搜索框。而 SoAY 则需要使用 LLM 来分解意图，并获取相关的 API 调用序列。

问题 2： 学术信息聚合在了解用户真正需要什么信息后，SoAY 的任务是根据 $Q_S$ 从数据源中检索相关信息，并对结果进行聚合和处理，以向用户提供他们所寻求的精确信息 $I$ 。

传统的信息检索系统缺乏这种设计，而是将所有检索到的信息以列表的形式显示给用户，让他们选择自己想要的信息。SoAY 需要做的是生成正确的代码来调用学术应用程序接口，并在与传统系统相当的时间内处理所获得的信息。

3 SoAY: Solution-based API-using

我们引入了 SoAY，以调整用于学术信息搜索的通用 LLM，强调使用现有的学术 API。为实现这一目标，以（学术查询、可执行 API 序列）对形式存在的大量训练数据是必不可少的，这有助于对现有 LLM 进行微调，或通过上下文学习对其进行指导。如图 3 左侧所示，该数据生成管道包括四个关键步骤：

1. 解决方案库的构建 利用所提供的学术应用程序接口，我们构建了一个表示应用程序接口之间依赖关系的图，并遍历该图以识别有效和简单的路径，称为解决方案。这些解决方案共同组成一个库，称为解决方案库。
2. 组合表述 为了获得库中每个解决方案的更精确语义，我们将解决方案的初始 API 的所有可能输入和最终 API 的所有输出组合起来，形成一系列组合。
3. 查询生成 我们利用 ChatGPT 将每个组合转化为缺乏特定学术实体数据的模板问题。然后，这些模板被多样化为各种表达式，并通过专门的学术数据源（此处为 AMiner 数据库）的数据填充到潜在的学术查询中。
4. **代码生成。**最后，我们再次使用 ChatGPT 给出组合，编写一段相应的代码，预计该代码将与具有相同组合的模板查询相对应。最后，我们再次使用 ChatGPT 生成给定组合的对应代码。预计该代码将与具有相同组合的模板查询相匹配。

值得注意的是，在数据准备部分，我们将 ChatGPT 标注为 gpt-3.5-turbo-0613。我们将在附录中详细介绍数据准备提示和 SoAYBench 的设置过程。

4 Solution Library Construction

给定一个学术应用程序接口库 $L_A$，第一步是建立一个应用程序接口图（API Graph），其中每个节点代表一个应用程序接口 $f$，从节点 $f_n$ 到节点 $f_m$ 的有向边表示从 $f_n$ 到 $f_m$ 的耦合关系，交叉属性为 $a_{n,m}$。

定义 1：应用程序接口耦合定义了学术应用程序接口调用中输入和输出的频繁依赖关系，这是由学术实体相关性的复杂性造成的
$$\begin{gathered} f_n\stackrel{a_{n,m}}{\to }{f}_m, \\ if{a}_{n,m}=i_m\cap o_n\text{and}a\ne \varnothing ,\text{\hspace{1em}(2)} \end{gathered}$$

其中，$i_n$ 表示 $f_m$ 的输入参数，$o_n$ 表示 $f_n$ 返回的属性。

API 耦合 $f_n\stackrel{a}{\to }{f}_m$ 意味着我们可以使用 $f_n$ 输出属性 ${}_{n,m}$，然后使用 $a_{n,m}$ 作为输入参数调用 $f_m$。这是因为 $a_{n,m}$ 是 $f_n$ 返回属性 $o_n$ 和 $f_m$ 输入参数 $i_m$ 的交集。图 2(a)展示了学术应用程序接口耦合的一个例子，即 “searchPerson $\stackrel{\text{person\_id}}{\to }$ getPersonPubs”。由 AMiner API 构建的 $G$ 如图 2(b)所示。通过遍历该图，同时限制最大跳数为 $H$，我们可以得出一个 API 执行序列，称为解决方案：

定义 2： 一个解决方案$S$被定义为从应用程序接口图中遍历的应用程序接口的执行序列：
$$\begin{array}{c}S=f_1\stackrel{a_{1,2}}{\to }{f}_2\cdots \stackrel{a_{k-1,k}}{\to }{f}_k\cdots \stackrel{a_{J-1,J}}{\to }{f}_J,\\ \forall k,f_k\in L_A.\end{array}\text{\hspace{1em}(3)}$$
解决方案库 $L_S$ 表示一组有效的简单解决方案，通过以下方式确保其有效性。

有效解决方案：在所有从应用程序接口图中遍历的解决方案中，有效性是通过从模糊应用程序接口开始来确定的，因为只有模糊应用程序接口才能接受以自然语言作为输入的用户话语。

简单解决方案。对于单个查询，可能有多个解决方案。首选方案是最简单的方案，包含的应用程序接口最少。例如，当查询一位学者的代表作的出版日期时，最佳解决方案是 “searchPerson $\to$ getPersonPubs”，尽管通过 "searchPerson $\to$ getPersonPubs $\to$ getPublication $\to$ searchPublication "也可以获得相同的信息。

我们精心制作了提示，以指导 Chat-GPT 实现上述两个特征。所有用于生成问题的提示详见附录 F.2.3。因此，我们创建了 16 个解决方案，为 AMiner API 建立了解决方案库 $L_S$。图 2© 展示了这些解决方案的子集，包括其输入参数、返回属性和相应的问题模板。

5 Reasoning Code Generation

为了让 LLM 聚合有效的学术信息并为用户提供精确的答案，Soay 让 LLM 生成包含学术信息检索 API 调用的代码。为此，需要生成大量查询、对应代码数据来训练 LLM。

5.1.Combination Formulation

第 2 节描述了一个查询和多个解决方案之间一对多的关系。显然，一个解决方案和多个查询意图之间也存在类似的一对多关系。在一个解决方案 $S$ 中，第一个 API 被称为头部 API $f_1$，而最后一个 API 被称为尾部 API $f_J$。例如，在图 2©中，考虑 3 跳解决方案 “searchPublication $\to$ getPublication $\to$ getPersonBasicInfo”。由于 ** 头部 API 输入***$i_1$ 和 ** 尾部 API 输出***${}_J$ 的多样性，即使在解决方案建立后，确定在什么条件（输入）下寻找哪些信息（输出）仍然是不确定的。一种直观的方法是将头部 API 输入、解决方案和尾部 API 输出结合起来，将意图空间细化为具体要求。基于解决方案的组合被定义为头部 API 输入、解决方案和尾部 API 输出的特定绑定： C=（i_{1},S,o_{J}）$。鉴于 $i_1$ 是 “标题”，$o_J$ 是 “教育经历”，$S$ "searchPublication $\to$ getPublication $\to$ getPersonBasicInfo "可能会导致一种看似合理的解释：查询所提供出版物第一作者的毕业学校。重要的是要认识到，$i_1$ 对应的学术数据源信息既是 q-t 需要填充的信息，也是生成的代码需要输入的信息，$o_J$ 既是 q-t 的预期答案，也是代码的黄金结果。

5.2.Query Generation

模板查询生成 对于给定的组合$C$，我们定义一个模板问题$Q_T$来表示实体信息缺失的$C$的意图。在所提供的示例中，相应的模板问题 $Q_T$ 可以表述为 “XXX 的第一作者毕业于哪所学校？”，其中 "XXXX "指的是代表出版物标题的占位符，如表 1 所示。

语义扩展和实体填充 一个模板问题$Q_T$所代表的特定意图可以通过多个自然语言查询来表达。例如，"XXX 毕业于哪所学校？"和 "XXX 的母校是什么？"表达的是同一个意图。为了丰富意图的语义多样性，我们通过制作提示来进行语义增强，利用 Chat-GPT，为每个组合生成三个新的、语义丰富的模板问题。

语义增强后，我们将模板中的特殊符号（用大写字母 "X "表示）替换为学术数据源中特定学术实体的信息。问题模板中的占位符必须用特定学术实体的属性来替换，如_person_id_、name、interest、organization、bio、_educational_experience_等，如图 2 所示。再以母校查询为例，该学者的姓名将被用来填充 $Q_T$，成为一个真正的问题 “学者姓名的母校是什么”，而该学者的教育经历则是这个查询的黄金答案。

5.3.Code Generation

最后一步，我们再次使用 ChatGPT 生成一段代码，与输入信息缺失的给定组合 $C$ 相对应。该代码的目的是获取与模板查询 $Q_T$ 共享相同组合 $C$ 的答案。仍然是来自特定学术实体的信息，$i_1$ 是生成代码的输入。该代码被期望执行后能得到与 $o_J$ 相同的结果，这可以看作是该代码的黄金信息。如果结果与黄金信息相符，则该代码有效。任何不产生匹配结果的无效代码都将被排除在最终数据集之外。

6 LLMs Alignment

为了最终利用 LLM 完成学术信息搜索任务，SoAy 需要调整 LLM，使其能够通过生成解决方案和代码正确、高效地调用学术 API。这可以通过构建训练数据并根据训练数据调整 LLM 来实现，无论是通过调整方法还是免调整方法。

6.1.SoAyBench-{(Query, Solution, Code)}

在经历了上述四个阶段后，我们自动收集了大量高质量（查询、解决方案、代码）数据。我们将这些数据整理成一个名为 SoAyBench 的综合基准。目前，SoAyBench 包含 3960 个三元组，其中五分之一经过专家检查和调整后形成测试集。该测试集用于评估 LLM 使用 AMiner API 搜索学术信息的能力。其余部分数据则用于支持法律硕士的对齐工作。表 2 显示了 SoAyBench 的问题统计数据。

6.2.Model Alignment

我们为超大型闭源 LLM 和可调开源 LLM 提供了对齐策略。(1) SoayGPT 是我们针对 GPT [1] 等模型提出的解决方案，这些模型的参数无法修改，但具有很强的指令跟随能力。我们从 SoayBench 数据中选取了一组不同的三元组（triplet），作为构建提示的示例，这些三元组代表了解决方案的不同用途。给定查询后，SoayGPT 通过上下文学习依次生成解决方案和代码，然后执行生成的代码以获得结果。为此，我们利用不同版本的 GPT 模型作为骨干。(2) SoayLLaMA 则是我们针对 LLaMA [20] 模型的对齐策略，LLaMA 是一个开源模型，我们可以在可接受的训练成本范围内对其进行微调。通过使用来自 SoayBench 的三元组查询作为输入，并将解决方案和代码整合为输出，SoayLLaMA 经过训练，可根据给定的查询，在零镜头设置下一步生成解决方案和代码。

7 Experiments

在本节中，我们将通过实验来验证 Soay 的有效性、效率和实用性。我们将重点关注以下研究问题：（RQ1）法学硕士在学术信息搜索的哪个部分最费劲？(RQ2) 在学术信息搜索的有效性方面，Soay 是否优于现有方法？(RQ3) 在效率方面，Soay 能否在用户可以接受的执行时间内完成任务？(RQ4) 什么样的基础模型更适合构建 Soay？

我们在 SoayBench 上进行了实验，将 SoAY 与其他基线方法进行比较，重点关注这些研究问题。此外，我们还介绍了一种名为 SoAYEval 的详细评估方法，该方法也可用于其他工具使用场景的评估。我们还专门针对现实世界中的学术信息搜索用例进行了在线评估。附录中有一个独立章节，展示了更多实施细节和有趣的发现。

7.1.Experimental Settings

由于 API 的相互依赖性和复杂的执行逻辑，许多现有的工具利用作品都无法有效发挥作用。我们选择了 GPT-DFSDT，采用与 SoAYGPT 和 ToolLAMA-7b [14] 相同的三个版本的 GPT 作为骨干，作为在 SoAYBench 上进行 API 使用实验的基准，因为前者代表了通用领域工具使用基准 ToolBench [14] 上的最先进模型，而后者是一个开源模型，已在大量工具使用数据样本上进行了微调，取得了与 GPT-DFSDT 不相上下的结果。对于每个 LLM，我们都采用 0 的温度设置，以确保可重复性。

值得注意的是，基线、ToolLAMa 和 GPT-DFSDT 的答案都是自然语言格式，而 SoAYBench 中的答案则是 SoAPI 返回的答案。为了确保比较的公平性，我们设计了一组提示，利用 ChatGPT 从自然语言格式的回复中提取精确的答案。

SoAYEval. 给定一个问题，产生一个 API 解决方案和一个被调用的答案，我们列出了五种评估指标。这些指标综合考虑了解决方案、程序和答案的准确性： （EM）： 检索到的解决方案和答案E完全M符合地面实况。（DS）： 答案正确，但检索到的D与地面实况不同的S解。(WS)： 由于 W 错误的 S 解决方案，答案是错误的。（WP）： 解决方案是正确的，但答案是错误的，原因是为解决方案生成了一个W错误的P程序，该程序可以执行，但得到的答案是错误的。(EE)： 执行E错误，可能是由于生成了不可执行的程序或在请求应用程序接口时出现了网络错误。根据上述指标，我们将准确度指标定义如下：
$$\text{ACC}=\text{EM}+\text{DS}\text{\hspace{1em}(4)}$$
表示受测方法产生的正确答案的比例。最后，我们为被测方法的一跳、二跳和三跳 ACC 分配不同的权重 $w_1$、$w_2$ 和 $w_3$，从而计算出总分数：
$$\text{Score}=\frac{w_1\cdot {\text{ACC}}_1+w_2\ast \cdot {\text{ACC}}_2+w_3\cdot {\text{ACC}}_3}{w_1+w_2+w_3}.\text{\hspace{1em}(5)}$$
我们将这种评估方法命名为 SoAYEval。SoAYEval 对大型模型使用一组 API 的整个过程进行细致分析，以回答相应的问题。这是一种通用的评估方法，其他使用 API 的场景也可以采用。值得注意的是，我们在实验中分配了 $w_1=1,w_2=2,w_3=3$，以突出被测方法的多跳问题解答能力。

7.2.Overall Performance (RQ1, 2)

表 3 列出了 SoAYGPT、SoAYLLaMA 和其他两种代表性基线方法在 SoAYBench 上的实验结果。SoAYLLaMA 的总分最高，Code-13B 模型得分率为 91.24%，其次是另一种 SoAY 方法 SoAYGPT，以 GPT-4 为骨干的得分率为 86.57%。这些结果证明了 SoAY 的有效性。在准备好的解决方案库的帮助下，SoAY 向 LLM 描述了复杂的相互依赖关系和多样化的执行逻辑。这大大减轻了 LLM 在确定耦合 API 的最佳执行路径时的压力。

尽管接受了专门的工具使用培训，ToolLAMA 的得分并不高。这主要是因为 ToolLAMA 的培训目标是掌握通用 API 的使用，而通用 API 所涉及的依赖关系远没有复杂的学术 API 那么复杂。此外，SoAYBench 中的许多问题都需要包含分支或循环逻辑的解决方案。面对需要执行这些复杂执行逻辑的问题，GPT-DFSDT 基于决策树的推理会遇到大量重复的子节点，这使得解决方案异常具有挑战性。

7.3.Error Analysis (RQ1)

SoAYEval 对模型性能的详细分析揭示了每种模型在不同题型中的显著特点和潜在改进领域。SoAYLLaMA 和 SoAYGPT 模型，尤其是它们的最新版本，在管理复杂题型方面表现出卓越的能力，错误率极低。ToolLLaMA 和 GPT-DFSDT 的早期版本则更容易出现执行和解题路径错误，这表明在算法或训练方面存在潜在的改进空间。总体而言，模型版本的进步（特别是从 GPT-DFSDT 3.5 到 4 和 SoAYGPT 3.5 到 4）显示了在减少特定错误类型和提高整体准确性方面的明显改善，凸显了持续模型开发和完善的益处。

7.5.Backbones Comparison (RQ4)

无论是通过 SoAYGPT 还是 SoAYLLaMA，选择哪种骨干模型来构建学术搜索系统都是值得考虑的。根据 SoAYBench 的结果，如果我们关注结果的有效性，那么选择 SoAYGPT 肯定属于最新版本（本文起草时为 GPT-4）。至于 SoAYLLaMA 的选择（附录 B 中介绍了其实现方法），我们可以发现一个趋势，即随着参数数量的增加，得分也在增加。同时，由于 Soay 通过代码生成实现了问题部分定义的规划和格式化过程，因此在代码生成方面表现出色的 CodeLlama 优于 ChatLlama。值得一提的是，在考虑实际应用时，SoAYBench 的结果所显示的有效性不应成为唯一的判断标准。

9.Conclusion

在这项工作中，我们提出了一种使用 API 的方法 SoAY，将 LLMs 应用于学术信息搜索。SoAY 的核心技术是高质量的自动构建数据集 SoAYBench，它提供了 3960 个学术三元组数据。我们将 LLMs 与预先构建的指南相匹配以生成代码，从而应对耦合和执行逻辑方面的各种挑战。我们提出了一种评估策略 SoAYEval，用于评估 AMiner API 的使用能力。实验显示了 SoAY 的有效性、效率和可用性。未来，我们将继续扩大 SoAYBench，并将 SoAY 应用于更多场景和领域。

10 Limitations and Future Directions

本文针对基于学术查询 API 的任务，提出了一种将自动数据生成与 LLM 对齐相结合的方法，并展示了其有效性。已发布的 SoAYBench 和提议的 SoAYEval 可以支持在后续研究中对相关方法进行评估。不过，还有一些值得探索的问题我们尚未进行：

• SoAYBench 是一个通过自动化构建的大规模数据集，由 3960 个三元组数据实例组成。虽然我们在解决方案库构建、查询生成和代码生成过程中加入了质量检查，并由人类专家检查和完善测试集，但我们必须承认，我们无法保证 SoAYBench 中提供的测试与人们对 API 系统的期望完全一致。之前的一些作品秦等人（2023 年）通过比较他们自己的基准测试方法的结果和人工评估的结果来验证其基准的质量。这是我们计划在未来进一步探索和验证的一个方面，这可能会带来更多与人类一致的自动构建数据集。
• 我们提出的 API 使用方法解决了引导大型模型使用复杂学术搜索 API 的任务。不过，我们尚未验证我们的方法在更简单的场景中是否具有优势。我们将继续扩展 SoAYBench，并在各种场景下进行实用性和有效性验证。
• 在实际应用中，我们遇到了更新已部署系统的不便之处：如果要在现有 API 的基础上加入新的 API，尤其是在添加大量 API 时，上下文引导的 SoAYGPT 需要在有限的输入空间内调整提示结构。这就提出了一个挑战，需要在示例的广度和粒度之间做出权衡。虽然我们提出的基于训练的 SoAYLLaMA 理论上允许通过添加足够的训练数据来无限扩展应用程序接口，但这是我们尚未探索的方面。未来，我们计划探索利用 SoAYLLaMA 进行持续学习的方法，以便在不影响模型掌握现有 API 的情况下，快速纳入新的 API 数据。

总之，本文介绍的数据生成质量、可扩展性和应用场景为进一步探索提供了众多可能性。今后，我们将继续完成当前的工作，并在上述方向上进一步探索。