正文｜Cameorn R. Wolfe @DeepLearningFocus题图来自论文「1-Gao, Luyu, et al. "PAL: Program-aided Language Models." arXiv:2211.10435 (2022)」论文概论作者CAMERON R. WOLFE，作为专业PhD，解读了16篇相关论文，解码LLM推理黑盒，推理与计算解耦，从PaL到PoT，在更强大的GPT发布解决现有思维链（CoT）准确性问题之前，可以利用编程辅助语言模型（如Codex）辅助LLM生成PoT来释放GPT思维能力解决复杂推理难题。
文章介绍了程序辅助语言模型（PaL）和思维程序提示（PoT），这是一种利用编程辅助大型语言模型（LLM）生成推理链来解决各种任务的技术。文章解释了这些技术的原理、有效性以及优缺点。文章还提供了一些将这些技术应用于不同领域和数据集的示例和结果。
PaL 和 PoT 是使用 LLM 生成推理链以解决各种任务的技术，例如数学、符号和算法推理。
PaL 和 PoT 使用代码增强提示，将自然语言和程序语句相结合来表达问题解决的逻辑。
PaL 和 PoT 将最终答案的计算委托给外部代码解释器，它可以执行生成的程序并避免 LLM 可能犯的错误。
PaL 和 PoT 在多个数据集和领域上取得了最先进的结果，显示了从计算中解耦推理的好处。
PaL 和 PoT 可以通过使用更好的解码策略（例如自洽和从最少到最多的提示）以及在程序中使用有意义的变量名称来改进。
尽管大型语言模型（LLM）被用于各种应用场景，但它们通常难以解决基于推理的任务。随着思维链（CoT）和最小到最多提示（Least-to-Most Prompting）等提示技术的出现，这个问题得到了显著改善。在高层次上，这些技术通过在模型提示中提供解决问题的逻辑依据来改善LLM中的推理行为。然后，模型可以学习输出这些基本原理，并为潜在问题生成分步解决方案。值得注意的是，这是一种仅提示的方法，不需要微调，这表明LLM能够在具有足够上下文的提示下进行推理。尽管思维链提示等技术显示出一定有效性，但人们期望LLM既能产生解决问题的思维链也能给出最终答案。有趣的是，这种方法会导致特别有趣的失败案例，其中LLM可能会产生解决问题的准确逻辑步骤，但最终结果仍然不正确。通常，此类错误是由于简单的错误（例如，算术不佳）引起的。为了解决这个问题，最近的研究探索了一种程序化的方法，鼓励LLM使用自然语言和代码组件生成思维链。然后，LLM 可以通过外部解释器运行此代码以获取所需的输出。为了理解为什么这种方法可行，我们注意到当前LLM纠结的许多问题（例如，算术错误、无法计算复杂表达式等）可以在代码组件程序内部轻松表达和解决。因此，在具有生成代码能力的LLM上使用思维风格的提示链（例如Codex），使我们能够将LLM的优势与任意Python程序的计算能力组合到一起！更具体地说，可以鼓励LLM生成包含自然语言和代码组件的问题解决逻辑依据，生成脚本可由外部解释器运行来计算问题的最终输出。我们将在本文探讨这种方法，这种方法对LLM在解决基于推理的任务方面的准确性和可靠性非常有益。尽管现代LLM展现了令人难以置信的能力，但这些模型都基于一个简单的预训练过程，该过程对大量未标记的文本数据执行下一个Token预测。尽管我们可以调整此过程的细节（例如，正在使用的数据的类型或混合），但大多数LLM的基本预训练方法仍然是固定的。我们只是简单地ii） 教模型准确预测语料库中的下一个单词/标记。就是这样！这种简单却不简约的方法为所有现代语言建模奠定了基础。但。。。从多年的研究中学到的更多技巧和经验教训才使我们能够训练出像 ChatGPT 或 GPT-4这样强大的语言模型。 大多数模型使用相同的“单解码器”（decoder-only）架构，但是创建高性能的语言模型服务不能仅通过预训练就能完成。我们需要：- 通过监督微调（SFT）和来自人类反馈的强化学习（RLHF）进行行为精调。
- [可选]领域专业化（即根据特定类型的数据-如代码或对话微调模型）。如果我们正确执行所有这些步骤，我们可以创建一个强大的基础模型（Foundation Model），该模型能够通过文本提示输入解决各种任务。值得注意的是，语言模型的大部分知识和信息都是通过预训练学习的（请参阅此处「https://openai.com/research/gpt-4」的“训练过程”部分），但是在预训练后采取的这些额外精调步骤使LLM更具可操纵性和趣味性；见下图。
LLM不擅长什么？语言模型在各种不同的应用程序中实现了令人印象深刻的性能，但它们并不完美。这些模型具有已知的限制，例如：难以计算大数的相加
无法评估/求解复杂方程
- 例如，如果我们用斐波那契数列的描述提示LLM，然后要求它计算第100个数字，那么它很有可能会失败！为什么会这样呢？好吧，我们知道LLM在执行算术方面很困难，并且解决斐波那契数列（除非模型使用蛮力记忆）需要在两个数字之间进行许多迭代加法。如果模型在每次迭代中有 95% 的机会正确执行此加法，则第 100 个斐波那契数的正确机会只有不到1% ！
斐波那契数列（Fibonacci Sequence）
斐波那契数列是一系列数字：0, 1, 1, 2, 3, 5, 8, 13, 21, 34, ...
下一个数字是通过将它前面的两个数字相加来找到的：2 是通过将它前面的两个数字相加 （1+1） 找到的，3 是通过将它前面的两个数字相加 （1+2） 找到的，5 则是 （2+3），等等！
示例：上述序列中的下一个数字是 21+34 = 55
*快速免责声明：最近发布的 GPT-4 使得关于 LLM 限制的说法更加困难。例如，GPT-4 完全能够求解第 100 个斐波那契数，甚至可以以最少提示努力评估一些（相对）复杂的方程；见下图。考虑到这一点，任何关于LLM功能的陈述都需要持保留态度。这个领域正在迅速发展，模型每天都变得越来越强大和令人印象深刻。如上所述，创建高性能LLM的一个（可选）部分是 领域专业化。经过预训练后的LLM 非常通用，只能执行一种类型任务——预测下一个Token。如果我们想要一个LMM专门在某个领域或擅长执行特定任务（例如，寻求信息的对话或编写剧本），则需要在大量数据上微调模型，以确保该任务的正确行为。此技术最成功的应用之一（与本概述特别相关）是创建可以编写代码的语言模型。“截图来自arXiv论文截图：Chen, Mark, et al. "Evaluating large language models trained on code." arXiv2107.03374 (2021)”类似于从互联网上下载大量文本数据以正常预训练语言模型一样，我们可以从公共来源（例如GitHub）下载大量代码来训练LLM，这使得编码成为专业LLM的特别完美的应用。这种模型的一个显着例子是Codex（arXiv2107.03374 (2021)），它是使用未标记的文本数据和从互联网下载的代码的组合进行训练的。给定一个 Python 文档字符串，Codex 的任务是生成一个工作 Python 函数，该函数执行文档字符串中概述的任务；见上图。Codex 在人工策划的编码任务（见上文）上表现得非常好，甚至用于为 GitHub Copilot 编码助手提供支持，这表明 LLM 不仅可以应用于自然语言！我们还可以将它们应用于遵循类似结构的许多其他问题。在这种情况下，我们对代码数据集使用进一步的语言模型预训练，以使预训练的LLM适应新领域。值得注意的是，Codex能够生成代码和基于自然语言的输出，使其成为一种特殊的多功能和有用的LLM。此外，创建此特定于域的模型相对简单 — 我们只需要大量代码进行训练。▩思维链 （CoT） 提示
除了前面概述的限制之外，LLM最初因无法解决推理任务而受到批评。然而，该领域的研究导致了诸如CoT提示之类的突破性技术，使LLM能够非常准确地解决基于推理的任务。CoT 提示背后的想法很简单。我们只是使用少数样本学习（few-shot learning）来教LLM如何输出解决问题的逻辑依据，详细解释其答案 - 用于任何推理任务;见下图。这种方法非常实用，因为我们只需要生成提示中包含一些解决问题的逻辑依据示例，而先前的工作则帮助此类逻辑依据的整个数据集以进行微调。与教LLM如何编码不同，我们看到CoT提示这样的模型能够在没有任何微调的情况下解决推理任务！相反，我们只需要采用一种更好的提示方法来“解锁”LLM解决复杂推理任务的能力。“Large pretrained language models have built in reasoning capabilities, but they need specific prompts to unleash their power.” - from [ Li, Yifei, et al. "On the advance of making language models better reasoners." arXiv: 2206.02336 (2022)]“大型预训练语言模型已经内置了推理功能，但它们需要特定的提示来释放它们的力量。”
鉴于我们已经在之前的概述中了解了很多关于 CoT 提示及其许多变体的知识，因此我不会在这里广泛探讨这个想法。然而，CoT提示的一个值得注意的方面是我们应该注意的 - LLM被期望同时尽管CoT提示是有效的，但我们可能会开始怀疑：依靠LLM来准确解决这两个步骤真的是一个好主意吗？我们知道语言模型能够（给定正确的提示方法下）提供准确的解决问题的基本逻辑步骤或对其输出的详细解释。但是，生成正确的逻辑步骤并不意味着LLM将正确解决问题！如果LLM在产生最终答案时犯了一个小的算术错误怎么办？鉴于LLM的基本局限性，CoT提示等技术通常会遇到令人沮丧的失败案例，其中模型产生准确的逻辑步骤，但输出不正确的最终答案。这种错误通常被称为LLM的组合性差距。
“We measure how often models can correctly answer all subproblems but not generate the overall solution, a ratio we call the compositionality gap.” - from [Press, Ofir, et al. "Measuring and Narrowing the Compositionality Gap in Language Models." arXiv:2210.03350 (2022)]“我们衡量模型正确回答所有子问题但不能生成整体解决方案的频率，我们称之为组合性差距。”
“LLMs的组合性差距”，它指的是LLMs在单跳任务上的性能比多跳任务上的性能提升得更快的事实。因此，随着模型的大小和复杂度的增加，组合性差距并没有减小。这意味着LLMs在记忆和回忆事实方面有所进步，但在执行这种组合推理方面没有相应的改善。
在本节中，我们将探讨最近的研究，这些研究试图通过利用经过代码培训的LLM的独特技能（例如Codex）来编写连贯和功能性程序来解决这个问题。我们可以依靠LLM来产生解决问题的理由。但是，我们不是要求LLM产生实际答案，而是提示模型生成与基本原理相关的程序，当使用单独的代码解释器执行时，可以生成最终答案。因此，我们的基本原理变成了代码和语言之间的混合体——基本上是一个带有信息注释的 Python 脚本！▩程序辅助语言模型 （PaL）
在[1]中，作者提出了一种受CoT启发的技术，称为程序辅助语言模型（PaL），它使用LLM将基于推理的问题分解为逐步解决问题的基本逻辑步骤。但是，此基本逻辑步骤包含自然语言和（基于 Python）的程序组件。在生成这样的混合步骤后，我们可以通过 Python 解释器执行提示的基于程序的部分来解决问题。这种方法的目标是消除LLM生成正确推理链但仍产生不正确的最终答案的情况。“This bridges an important gap in chain-of-thought-like methods, where reasoning chains can be correct but produce an incorrect answer.” - from [Gao, Luyu, et al. "PAL: Program-aided Language Models." arXiv preprint arXiv:2211.10435 (2022)]“这弥合了类似思维链的方法中的一个重要差距，推理链可能是正确的，但会产生不正确的答案。”
使用PaL，我们可以使用LLM来生成解决问题的逻辑依据，但是计算最终解决方案的过程（即，这是模型通常纠结的部分！）被委托给代码解释器，消除了算术或逻辑错误的可能性。因此，LLM只需要学习如何生成解决问题的逻辑步骤 - 解决方案是通过编程得出的。我们可以教LLM通过少样本学习（few-shot learning）来生成这样的混合逻辑步骤。然而，为了做到这一点，我们需要一个已经预先训练过的自然语言和代码的LLM（例如，Codex）。了解PaL，在高层次上，PaL 采用的方法与 CoT 提示非常相似。我们使用一种few-shot提示方法，该方法提供了几个将问题分解为相关逻辑依据的示例。CoT 和 PaL 之间的主要区别在于，PaL 中使用的基本原理由交错的自然语言和程序语句组成；见下图。使用 PaL 推理过程中的每一步都通过编程语句进行增强。然后，当合成这些编程语句时，可以通过单独的 Python 解释器执行它们以生成最终答案（即通过单个事后执行完成）。PaL正在教LLM（通过少样本学习few-shot learning）生成一个程序，以逐步解决所需的问题。有趣的是，[1]中的作者鼓励LLM通过利用Python注释语法（即 # 字符）来生成基于自然语言的中间步骤，这使得基于语言的组件能够插入到生成的程序中。换句话说，我们正在教LLM通过带有信息丰富的评论的分步程序解决推理任务！与 CoT 提示不同，PaL 使用的少数样本不包含最终解决方案。相反，示例只是具有交错自然语言语句的程序（仅此而已！），最终解决方案的生成则委托给 Python 解释器，因此 LLM 永远不需要学习如何执行此步骤；见上图。更进一步，[1] 中的作者观察到，为程序中使用的变量提供有意义的名称是有益的。这一发现表明，PaL提出的推理过程是一种真正的混合方法，融合了语言和基于程序的组件。在编程和语言模式中的实体之间形成象征性联系很重要；见下文。这效果好吗？PaL 在各种符号、数学和算法推理任务中进行评估，其中显示它可以缓解 CoT 提示遇到的许多常见问题。将所提出的方法与标准的少样本学习（few-shot learning）（在[1]中称为“直接”提示）和CoT提示进行了比较。在数学推理任务中，带有Codex的PaL很容易胜过具有各种不同模型的先前提示方法。值得注意的是，PaL 甚至优于 Minerva，这是一种通过大量定量推理数据明确微调的 LLM；见下图。从上表中，我们还应该注意到，使用Codex的PaL在GSM8K上实现了最先进的性能，超过了PaLM-540B（即更大的型号！）的性能，CoT的绝对精度为15%。有趣的是，[1]的作者指出， GSM8K 主要关注数字较小的数学单词问题（即50%的数字在0-8之间），并提出了 GSM-Hard - 这个数据集的一个版本，具有更大的数字。在较难的数据集中，与使用 CoT 提示的 PaLM 相比，PaL 的绝对前 1 名精度提高了近 40%，这表明程序辅助提示对于需要大数复杂算术的问题更胜一筹。在符号和算法推理任务上，PaL 再次提供了显着的好处；见上图。事实上，PaL 几乎完全解决了该类别中五个数据集中的四个，实现了 >90% 的准确率。此外，随着问题复杂性的增加，PaL 似乎保持一致的性能；见下图。在这里，我们看到推理任务中以大量或更多对象的形式增加的复杂性很容易以编程方式处理，尽管直接使用 LLM 处理这种复杂性可能会导致问题。▩思维编程 （PoT） 提示（Program of Thoughts Prompting）
如前所述，使用 CoT 提示的推理过程有两个不同的步骤：
LLM擅长执行上述第一步，但他们可能难以计算最终答案。通常，出现此问题是由于算术错误或无法计算复杂表达式而发生的。简而言之，LLM在复杂的数值任务中挣扎。在论文中，作者的目标是利用一种称为思维程序（PoT）提示的代码增强提示方法来改善这个问题，并使LLM能够准确地解决复杂的数值任务。“In PoT, the computation can be delegated to a program interpreter, which is used to execute the generated program, thus decoupling complex computation from reasoning and language understanding.” - from [Chen, Wenhu, et al. "Program of thoughts prompting: Disentangling computation from reasoning for numerical reasoning tasks." arXiv preprint arXiv:2211.12588 (2022)]“在PoT中，计算可以委托给程序解释器，该程序解释器用于执行生成的程序，从而将复杂的计算与推理和语言理解解耦。”
正如我们可能怀疑的那样，PoT提示与PaL非常相似。这两种技术都使用代码增强提示技术来解决复杂的推理任务，并将推理过程的必要部分委托给代码解释器。更具体地说，PoT提示利用基于代码的LLM（例如Codex）的少样本学习（few-shot learning）来生成包含自然语言语句和代码（在Python中）的混合逻辑步骤。然后，输出的代码部分被卸载到解释器进行评估，从而解耦推理和计算。相比之下，CoT提示直接使用LLM执行推理和计算。这是一个问题，因为LLM很难做到：执行基本算术（尤其是较大的数字）
评估复杂的数学表达式（例如，多项式或微分方程）
解决需要迭代的问题
上图证明了这些问题，其中具有CoT提示的LLM无法通过斐波那契数列的迭代计算来评估简单的三次方程或原因。幸运的是，我们可以通过程序轻松解决这些问题！例如，我们可以用 for 循环计算斐波那契数列，并且可以使用 Python 语法轻松表示三次方程。然后，我们可以运行这个程序来生成正确的输出，从而删除对LLM的不必要的依赖。
PoT的详细信息。与 PaL 类似，PoT 提示生成包含语言和代码组件的问题解决逻辑步骤。LLM教如何通过一系列少样本学习示例生成这些基本逻辑步骤，这些示例包含具有相关“思想程序”的问题对（即，具有解释计算的交错自然语言语句的多步骤程序）; 见上图。与PaL不同，PoT编写的代码依赖于一个名为SymPy的符号数学库。该软件包允许用户定义数学“符号”，然后可以将它们组合在一起以形成复杂的表达式。为了评估这些表达式，我们可以简单地将它们传递到 SymPy 的 solve 函数中；见上图。有关更多详细信息，请查看下面的教程。https://docs.sympy.org/latest/tutorials/intro-tutorial/intro.html#what-is-symbolic-computation尽管使用了符号数学，但PoT提示与尝试使用LLM直接生成数学方程不同，后者已被先前的工作证明是相当困难的[Wei, Jason, et al. "Chain of thought prompting elicits reasoning in large language models." arXiv:2201.11903 (2022)]。这是因为 PoT 提示：- 与PaL类似，上面论文中的作者指出，为程序中的变量分配有意义的名称确实会对LLM的性能产生可衡量的影响。结果。PoT提示使用Codex [4]和GPT-3 [7]在几个数学单词问题和财务问答数据集（例如，FinQA [8]和ConvFinQA [9]）上进行评估。采用几种不同的LLM作为基线，使用少镜头学习和CoT提示（包括可以访问外部计算器的CoT提示变体）。如下表所示，PoT 提示在所有情况下都明显优于基线，这强调了推理与计算解耦的价值。有趣的是，[2] 中的作者还发现零样本（zero-shot） PoT 提示（即类似于零样本 CoT 提示 [10]）效果很好。即使没有为LLM策划几个程序注入的基本逻辑依据的例子，我们也可以通过PoT提示在数值任务上使用LLM实现合理的性能。此外，作者对使用 PoT 提示做了一个有趣的实际说明。为了避免生成完全基于语言的逻辑依据（即，包含所有注释的程序），他们必须手动抑制 # 标记的概率。虽然这是一个小细节，但重要的是要记住 - 我们不希望我们生成的程序只是评论！此外，它表明，使这些技术在实践中发挥作用通常是脆弱和困难的。
PaL和PoT在大多数实验中都采用贪婪解码策略，这意味着LLM将通过自回归迭代选择具有最高概率的下一个Token来产生输出序列。但是，我们可以使用多种更好的解码策略！一个值得注意的（也是超级简单）的策略是自洽[14-Wang, Xuezhi, et al. "Self-consistency improves chain of thought reasoning in language models." arXiv:2203.11171 (2022)]。此技术使用相同的LLM和提示为问题生成多个不同的输出。然后，通过对生成的所有输出进行多数投票得出最终答案；见上图。当自洽应用于 PoT 提示时，我们看到了立竿见影的显著好处！如上所示，具有自一致性的PoT在[2]中考虑的几乎所有数据集上都实现了最先进的性能。类似地，PaL [1] 受益于自一致性的使用，甚至用于探索更复杂的解码/提示策略，例如最小到最紧密的提示 [15]（即 CoT 提示的一种变体，一次明确地解决推理任务）。当与这种更复杂的提示样式结合使用时，PaL 变得更加有效；见下图。尽管 PaL 和 PoT 工作得很好，但我们可以通过对它们的提示技术进行一些易于实现的添加来使它们变得更好一点。这些发现激发了进一步的实验。也许我们可以通过利用其他有用的技术来获得额外的性能优势，例如提示融合。尽管LLM本身很有用，但我们在此概述中看到，当可以访问有用的工具时，它们可以更酷。特别是，我们已经了解到，将LLM连接到外部代码解释器对推理任务的性能非常有益。但是，我们需要访问能够编写代码的LLM。下面概述了一些要点。为什么会这样？PaL和PoT的有效性源于这样一个事实，即LLM能够产生准确的解决问题的基本逻辑依据，但往往难以处理简单的任务，如算术和迭代。幸运的是，这些概念可以很容易地在程序中建模，这使得LLM与外部代码解释器的连接成为解决推理问题的直观而强大的技术。简而言之，通过依靠LLM来获得他们擅长的东西，并将剩余的问题解决组件委托给代码解释器，而不是更可靠地产生解决方案，我们获得了很多收益。我们应该如何解决LLM的弱点？正如本文中简要提到的，随着更强大的模型（如 GPT-4）的发布，LLM 的许多已知缺点正在得到解决。但是，我们在此概述中看到，存在解决此类问题的替代方法，这些方法甚至可能更可靠。特别是，依靠外部代码解释器可以解决由于LLM在解决基于推理的任务方面的局限性而遇到的问题。赋予模型执行代码的能力无疑增加了其能力的范围，这激发了我们思考可能对LLM有用的其他工具。将想法表达为一个程序。这项工作确实突出了一个事实，即程序可以被解释为表达思想的结构化语言。与自然语言相比，编程语言受到更多的约束，这使它们能够轻松表达迭代、对复杂方程进行建模等。然而，程序的形式性质也限制了表达能力——用自然语言写一首诗比用 Python 脚本写一首诗要容易得多（假设没有调用 GPT-4 API）！在我看来，考虑自然语言和代码之间的差异非常有趣。我们在这里看到，将它们结合起来可以借鉴两者的优势。Bibliography
[1] Gao, Luyu, et al. "PAL: Program-aided Language Models." arXiv preprint arXiv:2211.10435 (2022).
[2] Chen, Wenhu, et al. "Program of thoughts prompting: Disentangling computation from reasoning for numerical reasoning tasks." arXiv preprint arXiv:2211.12588 (2022).[3] Wei, Jason, et al. "Chain of thought prompting elicits reasoning in large language models." arXiv preprint arXiv:2201.11903 (2022).[4] Chen, Mark, et al. "Evaluating large language models trained on code." arXiv preprint arXiv:2107.03374 (2021).[5] Lewkowycz, Aitor, et al. "Solving quantitative reasoning problems with language models." arXiv preprint arXiv:2206.14858 (2022).[6] Chen, Wenhu. "Large language models are few (1)-shot table reasoners." arXiv preprint arXiv:2210.06710 (2022).[7] Brown, Tom, et al. "Language models are few-shot learners." Advances in neural information processing systems 33 (2020): 1877-1901.[8] Chen, Zhiyu, et al. "Finqa: A dataset of numerical reasoning over financial data." arXiv preprint arXiv:2109.00122 (2021).[9] Chen, Zhiyu, et al. "Convfinqa: Exploring the chain of numerical reasoning in conversational finance question answering." arXiv preprint arXiv:2210.03849 (2022).[10] Kojima, Takeshi, et al. "Large language models are zero-shot reasoners." arXiv preprint arXiv:2205.11916 (2022).[11] Ouyang, Long, et al. "Training language models to follow instructions with human feedback." Advances in Neural Information Processing Systems 35 (2022): 27730-27744.[12] Thoppilan, Romal, et al. "Lamda: Language models for dialog applications." arXiv preprint arXiv:2201.08239 (2022).[13] Li, Yifei, et al. "On the advance of making language models better reasoners." arXiv preprint arXiv:2206.02336 (2022).[14] Wang, Xuezhi, et al. "Self-consistency improves chain of thought reasoning in language models." arXiv preprint arXiv:2203.11171 (2022).[15] Zhou, Denny, et al. "Least-to-most prompting enables complex reasoning in large language models." arXiv preprint arXiv:2205.10625 (2022).[16] Press, Ofir, et al. "Measuring and Narrowing the Compositionality Gap in Language Models." arXiv preprint arXiv:2210.03350 (2022).-CAMERON R. WOLFE：Program-Aided Language Models
https://cameronrwolfe.substack.com/p/program-aided-language-models