实现大语言模型按正确顺序执行API调用

通过业务流程依赖图与约束解码技术，能够有效减少API幻觉和乱序执行现象。

在大型语言模型（LLMs）取得惊人成功之前，基于对话的AI系统研究主要沿着两个方向展开：一是能够进行开放对话的聊天机器人，二是专注于提取API参数并代表用户执行任务的目标导向对话模型。LLMs在第一个挑战上取得了巨大进展，但在第二个方面进展相对有限。

这部分是因为LLMs难以遵循预定的操作序列，无论是操作工作流还是API依赖关系。例如，旅行代理应用可能希望在客户预订航班后才推荐租车服务；同样，搜索航班选项的API调用只能在将城市名称转换为机场代码的API调用之后发生。

在北美计算语言学协会年会（NAACL）上，我们提出了一种新方法来约束LLMs的输出，使其遵循预定的操作序列。幸运的是，该方法不需要对LLMs参数进行任何微调，并且可以开箱即用地与任何具有logit访问权限的LLM配合使用。

我们使用图来表示API和工作流依赖关系，并构建提示词引导LLM通过生成计划来响应用户请求——包括API调用序列以及每个调用的自然语言原理说明。给定提示词后，我们考虑LLM预测的k个最可能的后续标记。对于每个标记，我们向前看，继续生成固定长度的输出。我们根据语义内容和遵循图中依赖约束的程度对k个标记延续序列进行评分，最终只选择得分最高的序列。

由于现有面向任务的对话数据集往往不包含大量操作序列依赖关系，为测试我们的方法，我们创建了自己的数据集。该数据集包含13个不同的工作流和64个API调用，每个工作流有20个相关查询——例如不同措辞的跨城市航班预订请求。每个工作流都有一个由有序API调用组成的黄金标准计划。

在实验中，我们将我们的方法与使用相同提示和相同LLM但采用不同解码方法（即选择输出标记序列的方法）进行比较。给定查询后，模型应该生成能够成功解决该查询的计划。我们根据与黄金解决方案的偏差（如计划中乱序操作的数量）以及其他因素（如API幻觉和API冗余）评估解决方案。

我们的方法经常将幻觉API调用和乱序生成的次数减少一个数量级甚至两个。根据模型和解码方法的超参数，它将解决生成计划与黄金计划所需编辑次数减少了8%到64%。我们还证明，我们的方法使较小的LLM（约70亿参数）能够达到具有300-400亿参数的LLM的相同性能。这是一个令人鼓舞的结果，因为随着LLM商业应用的增加，运营效率和成本正成为越来越重要的考虑因素。

FLAP方法

我们的方法称为FLAP（流程遵循规划），每次向智能体发出查询前都会提供一组指令，这些指令确立了可用的API调用和相关的工作流序列。提示词还包括用自然语言解释每个API调用的思考示例。

我们试验了包含和不包含思考的指令集，发现包含思考始终提高了生成质量。对于每个输入标记，LLM会生成一个可能后续标记的列表，并根据概率进行评分。所有LLM都使用某种解码策略将这些列表转换为字符串：例如，贪婪解码器直接获取最高概率的后续标记；核采样只选择一组核心的高概率后继标记并从其中采样；而束搜索解码并行跟踪多个高概率标记序列，并选择整体概率最高的序列。

FLAP提出了一种替代解码策略，使用鼓励选择符合API和工作流依赖图的标记的评分系统。首先，对于每个输出思考，我们使用语义相似性评分模型来识别指令工作流规范中最相似的步骤。然后，基于工作流依赖图，我们确定当前思考是否被允许——即图中其祖先节点对应的步骤是否已经执行（满足先决条件）。如果已执行，该思考获得高分；否则获得低分。

我们以相同的方式对API调用进行评分——即基于它们的执行顺序是否符合依赖图。我们还使用相似性评分模型来测量生成思考与用户查询之间的相似性，以及思考与生成API调用之间的相似性。最后，我们根据计划是否遵循每个步骤的<思考, API调用>语法对计划进行评分，思考和API调用分别以"[thought]“和”[API]“标签为前缀。基于所有这些度量，我们的模型从LLM输出的k个标记序列中选择一个。

在我们的实验中，我们考虑了指令集的两种变体：一种将整个域的所有工作流约束都包含在提示中，另一种只包含相关的工作流。基线和FLAP实现使用相同的LLM，仅解码策略不同：基线使用贪婪、束搜索和核采样解码器。

在所有测试的LLM上，FLAP全面优于基线。此外，我们在不同指标上没有观察到基线中有明显的亚军。因此，即使在FLAP在特定指标上相对于特定基线改进相对较小的情况下，它经常在其他指标之一上展现出更大的改进。

当前的FLAP实现为输入用户查询生成初始计划。但在现实世界中，客户经常在对话过程中修改或扩展他们的意图。在正在进行的工作中，我们计划研究能够基于与客户的持续对话动态调整初始计划的模型。