Natural Language Commanding via Program Synthesis解读

概要

提出了基于LLM的语义解释器（Semantic Interpreter】的系统框架，用于将自然语言描述的意图转化为对Microsoft Office这类生产力的应用的可执行的操作。核心思想是将高层次的自然语言意图用LLM转化为一种领域特定语言（ODSL）来执行对Office这类应用的操作。LLM在其中起到了程序生成的作用，但不是直接生成面向Office的API编程的JS代码这类通用程序，而是用于生成有一定抽象能力的ODSL这类程序。其实际过程面向该目的，对LLM的prompt的设计以及构建，比较核心处理ODSL的设计，还包括面向上述场景以及LLM的局限性，使用few-shot以及基于RAG的基于分析的ARM，根据用户的实际输入来分析召回相关的例子，以提高LLM生成ODSL的效果。框架图如下：

要点：

1. 自然语言命令接口（natural language commanding interface）

现在通过LLM来辅助使用一些应用都涉及到自然语言命令接口，需要理解用户自然语言输入中的意图，然后有LLM给出实现用户的意图的具体方式，与其他不同的是，最终要生成的实现方式的描述不是自然语言，而是对特定应用的API这类调用的序列和方式，是结构化的数据，而虽然LLM对人输入的自然语言的意图理解比较有效，但是对满足意图的方案的输出，特别是特定到某个应用的可执行的有效方案，还是存在问题。

2. 将用户的自然语言输入意图编码成DSL的结构化精确、可执行的表示

针对现有存在的问题，提出以DSL作为中间表示，连接用户的自然语言输入和应用的API的操作，需要给LLM注入对特定应用的理解能力和如何使用好应用的领域专家知识。该方法存在如下挑战以及解决办法：

• LLM只是掌握自然语言与一些常见的编程语言的知识，对于特定于应用设计的DSL没有了解
  • 微调，不现实因为数据比较少，使用few-shot上下文学习，在prompt中提供包含DSL的语法、用户自然语言输入的意图以及对应的DSL、应用上下文数据以及系统指示
• prompt的token数目受限
  • 通过query相关性，为每个不同的问题动态生成最相关的例子注入prompt，并且不对syntax进行详细描述，只是通过例子方式说明
• LLM的幻觉问题，特别是对于新的DSL以及特定领域的应用不太了解时
  • 设计ODSL尽量做到LLM-friendly，也就是提高LLM迁移学习的可能性
  • 使用编译工具检查、修正一些ODSL的语法语义等低级的可修复的错误
• 评测效果的主观性问题，因为是对意图的实现方法有很多，且效果很主观
  • 使用ODSL程序的等效性代替最终效果的

3. 相关的研究背景

• 自动程序生成
  • 从程序生成的输入区分，有基于formal specification、input-output、nature language的程序生成
  • 基于LLM的生成，包括基于CodeLLM和通过使用LLM并应用一些技巧生成程序
  • 存在自然语言描述的不一致性、生成程序存在错误、生成的程序与用户意图不一致等各种问题
• 混合神经-符号方法（NeuroSymbolic Method）
  • （还不是很理解）混合神经-符号的方法是结合了传统的符号化逻辑推理的方法和基于神经网络的机器学习方法，根据数据学习出可解释也可验证的表示，如DSL。
  • 本文的方法一定程度上是类似于该方法的，ODSL就是对如何操作Offic这类应用的任务的一个形式化描述
• 如何让LLM使用Tool
  • LLM的推理能力可以通过对tool使用来加强，现有很多让LLM将部分问题转换成生成对tool或者API的调用

4. ODSL设计

• 基于LLM，生成面向DSL的程序比生成面向通用编程语言的程序的问题更简单，因此相关程序生成的问题也可以得到缓解
• ODSL设计的几个原则
  • 表达性和可拓展性
    • 需要考虑到未来应用场景的变迁和扩展，本文是对于PP，根据PP的API和特点场景
    • 抽象并定义了entity和statement两大类
      • entity就是根据PP中的对象来定义，有分层结构
      • statement有四种，select、insert、format、delete，另外就是代理扩展了一些其他能力，如insert_image可以调用DALLE2产生image并插入
  • LLM友好性
    • 统一格式，目的就是让LLM更好更迅速地在少量的例子下准确学习DSL的语法
      • 比如上述四种statement的格式类似统一，命名和参数格式都统一
      • 比如statement的返回值不区分0、1、多，而是都用统一个形式
    • 紧凑性，token数目限制和成本控制原因，在表达相同意思的情况下需要让语句尽量简洁，比如通过参数化方式取代一个个参数设置的方式
    • 最小化冗余，表达同样意思的表达式尽量只有一种，不要有多种
    • 上、下文相关设计，将文档以json形式描述作为DSL的参考索引，用name和index
  • 鲁棒性
    • DSL不涉及危险操作，如关闭文件
    • 语法检查，通过编译错误查找最小化运行时出错，并对运行时错误进行不执行的处理
    • 自动代码纠正

5. 所谓的借鉴了DAG的一个ARM（Analysis-Retrieval 先分析再召回方法）

• 考虑了token限制和问题需要后的prompt组成的设计
  • 系统指示，固定的用于描述llm需要完成的任务
  • ODSL语法，基于query可变，用于让llm了解ODSL的语法，是基于示例而非直接提供语法描述文件
  • Rules，基于query可变，和entity相关联的指示
  • Few-shot ODSL samples，基于query可变，示例的用户输入、文档上下文、相应的ODSL程序
  • Input utterance，用户的query
  • Current document context，基于query可变，是json格式的文档描述
• 分析过程
  1. 通过llm回答query和哪些entity以及doc context相关，以此筛选出entities、 context；
  2. entities直接用于rules、odsl语法的示例的获取，间接用于后续retrieval过程中获取few-shot odsl samples
  3. context直接用于current document context
• 召回过程
  1. 创建sample库，也就是utterance和odsl对，也包括可能的上下文、以及entities标签
  2. 将sample库的utterance进行归一化处理，用抽象的概念词汇统一代表具体的词语
  3. 向量化utterance，主要基于向量相似度来找最相近的sample
  4. 在sample之下还设定sub-sample，以区分不同上下文下同一个utterance的不同例子

6.实验步骤

• 提出这一类系统的结果好坏很难评估，以及相应的处理办法
  • 问题：用户的输入是很难穷尽
  • 解决办法：手动写例子，尽量覆盖所有的ODSL可表示的范围，写了197个
  • 问题：期待的输出很难唯一化
  • 解决办法：将效果的评估转化成程序等价性的评估，也就是为每个测试用例写一些可以接受的期待输出的ODSL例子，然后将真实输出和例子程序比较等价性
• 为了更好地评估程序等价性需要做以下两个处理
  • 程序标准化，将变量名、等式顺序、字符常量等转换成统一格式
  • 子程序分析，对于实际的输出程序如果是可接受程序的一个子集（也就是除了可接受程序的操作，还存在其他操作）
• 将结果输出分等级为7个，exact、normalized、subprogram exact、subprogram normalized、manual check valid、none、error

7.实验结果

通过消融实验，对few-shot的k以及其他的环节做有无/多少的对比实验，结果证明整体最佳效果是96.06%左右的通过率，并且是在所有环节都有的情况；（我觉得为了说明ARM的设计有效性，至少应该对比随机获取few-shot例子的结果）