夕小瑶科技说 原创
作者 | 谢年年最近,多篇文章《GPT-4的推理能力非常有限,有两篇论文为证》,《DeepMind:无法自我纠正推理,除非提前得知正确答案》指出大模型在推理任务中似乎没有自我改进的能力。即在无任何外部反馈的情况下无法通过自我纠正的形式来改进输出,除非LLM在自我纠正的过程中已经知道了正确答案。
那么反过来,如果告诉模型错在哪儿,它能改正吗?另外,对于有唯一答案的题目来说,正确答案只有一个,错误答案可是千千万,能不能指出具体犯错的某一步对于模型改进来说至关重要。
加利福尼亚大学团队提出了一种名为多方面反馈(Multi-Aspect Feedback)的迭代改进框架。该框架针对不同的错误类型集成了多个反馈模块,每个模块都专注于特定的错误类别,各个击破。实验结果表明,该方法在解决LLM生成的推理链中的多个错误方面表现出了有效性,从而提高了LLM在多个推理任务中的整体性能。
论文标题:
MAF: Multi-Aspect Feedback for Improving Reasoning in Large Language Models
论文链接:
https://arxiv.org/pdf/2310.12426.pdf
Github链接:
https://github.com/deepakn97/MAF/tree/main
MAF框架主要由三个关键部分构成:
本文将常见错误问题分为十个不同的类别,包括算术、编程语法、变量命名、缺失步骤、连贯性、冗余性、重复性、幻觉、常识和事实性等。
而对错误进行反馈的模块可以是各种工具,例如代码解释器、计算器、知识图谱、语言模型,甚至是经过微调的模型。
不同的反馈模块适用于解决特定类型的问题。例如,像代码解释器这样的外部工具非常适合提供关于代码语法错误的反馈,而微调模型则可以提供如冗余或幻觉等更细致的反馈。这种解耦的方法能够更有针对性的方式处理错误,从而提高改进解决方案的整体质量。
表1显示了用于每个任务及其错误类型的反馈模块。
Eager-Refinement(急切改进):出现反馈信息后立马改进模型输出。用于可能在细化过程中引起冲突的反馈类型,如Variable Naming(VN)反馈模块(用于修正生成代码中的变量名)。这是因为当其他模块引用一个根据VN反馈应该更改的变量时,如果改进不正确,程序可能无法执行。
Lazy-Refinement(懒惰改进):多个模块的反馈与对应的错误类别一起组成多方面的反馈,然后整体传递给改进模型以获得修订。通过一次细化多个错误来提高效率,并增加了灵活性。
但是多方面反馈有时上下文长度会超过模型的承受范围。为了解决这个问题,作者采用了选择性摘要的方法,即只选择指出问题的反馈部分token,从而有效地将所有反馈结合起来,并可以在上下文长度较小的模型上使用。
本文分别在数学推理数据集GSMIC、GSM8K,逻辑推理数据集EntailmentBank(EB),问答数据集DROP上进行实验,实验结果如表2所示:
▲其中SR代表Self-Refine[1]方法仅使用单方面的反馈结果显示,MAF在各种推理数据集上均优于基准语言模型和Self-Refine。
但该方法存在过度改进的问题,即如果已经找到了最优解,强迫语言模型进一步改进会降低推理链的性能和质量。如图3所示,随着迭代次数的增加,MAF与Self-Refine准确率都有所下降
因此,作者增加了一个Oracle验证器。它可以判断模型生成的最终答案是否正确。如果正确则停止改进;否则,让模型继续改进。在这种设置下,过度改进的问题得到有效遏制。
前文提到,本文设置了多种不同的反馈模型如表1所示,其中Programming Syntax(编程语法)和Variable Naming(变量命名)使用了急切改进方案。
从图3中可以看到,变量命名和缺失步骤模块对MAFs性能的影响并不是很大,他们真正的作用是使分布偏移更加稳健。
▲模块前的符号表示移除该反馈模块后MAF的精度。结果清楚地表明,两种改进方式组合比只使用一种改进方式效果更好。
仅依赖懒惰改进可能导致多个反馈类别被压缩成一个提示,导致迭代提示超过很多模型的上下文窗口限制。而仅使用急切改进虽然可以获得即时反馈,但需要使用更多的token,成本过高。两种方式结合降低了成本且增加了可扩展性。
本文提出了多方面反馈(MAF)迭代改进框架,它将反馈模块解耦,并利用特定的工具生成反馈,在多个推理数据集中取得了不错的效果。但作者也发现该框架存在过度的改进,因为模型无法确定自己的答案是否正确,引入外部验证器可以改善这种情况。这也为继续研究大模型推理能力提供了一个方向。