PAL：用于可靠财务算术的程序辅助语言模型
在深入研究了表格推理（tabular reasoning）文献后，我想了解一种互补的方法：与其让大语言模型（LLM）用自然语言对表格进行推理，如果让它们编写代码并将计算完全交给代码执行会发生什么？PAL（Gao 等人，2022，arXiv:2211.10435）是这一问题的权威回答，它对于任何需要可靠地对财务数据进行算术运算的系统都具有显而易见的意义。
论文解读
“PAL: Program-Aided Language Models”（Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023）从一个直观的观察出发：LLM 擅长分解问题，但不擅长执行算术。思维链（Chain-of-thought）提示解决了第一个问题，但对第二个问题束手无策。该论文提出的解决方案是改变 LLM 生成的“推理步骤”——生成 Python 代码，而不是自然语言算术。然后由 Python 解释器运行该代码并返回答案。
分解与执行的分离非常清晰：LLM 负责理解问题和程序 结构；解释器负责处理所有数值。像“奥利维亚有 23 美元，买了五个每个 3 美元的贝果——还剩多少钱？”这样的问题变成了 money_left = 23 - (5 * 3)，而不是一段模型可能会出错的散文式算术推理序列。
核心观点
- 在 GSM8K（小学数学应用题）上，配合 Codex 的 PAL 达到了 72.0% 的准确率，而使用相同 Codex 模型的思维链准确率为 65.6%——提升了 6.4 个百分点——而使用规模大得多的 PaLM-540B 模型的 CoT 准确率为 56.9%。较小的模型通过将算术委派给 Python 获得了胜利。
- 在 GSM-hard（GSM8K 的一个版本，数字被替换为更大的值）上，PAL 达到了 61.2%，而 CoT 仅为 23.1%——绝对差距达 +38.1 个百分点。大数字会破坏 Token 级别的算术；但它们不会破坏 Python。
- 通过对 40 个样本进行多数投票，PAL 在 GSM8K 上达到了 80.4%，以大约 1/10 的模型规模险胜 Minerva-540B (78.5%)。
- 这些增益延伸到了符号推理。在 BIG-Bench Hard 任务中，如物体计数（Object Counting），PAL 的得分率为 96.7%，而 CoT 为 73.0%；在表格中的企鹅（Penguins in a Table）任务中，PAL 为 93.3%，而 CoT 为 79.2%。
- 消融实验揭示了工作的实际核心：当 LLM 充当其自身的解释器（没有外部 Python）时，GSM8K 的准确率崩塌至 23.2%。解释器并非微小的增强——它承担了所有的算术工作。
- 变量命名很重要。将具有实际意义的变量名替换为随机字符会导致符号任务上的准确率大幅下降。模型会读取自己生成的代码。
哪些成立，哪些不成立
核心主张是显而易见的正确，且实验令人信服地证实了这一点：Python 在算术方面比 LLM 强，GSM-hard 极其残酷地证明了这一点。那里 +38pp 的提升并非基准测试的偶然——它反映了 CoT 在规模化下的范式失败。
我觉得不太有说服力的是将其框架化为通用的推理突破。PAL 适用于那些恰好具有确定性的、可用 Python 表达的答案的任务。财务推理中许多重要的部分并不能以这种方式分解。判断一个交易模式是否“对该账户第四季度而言异常”，或者一笔转账是否需要人工审核标记，是无法还原为一个 Python 表达式的。PAL 为你提供了一个可靠的算术引擎；但它没有给你判断力。
安全性维度在论文中没有得到关注。基准测试是在受控环境中运行的，但任何根据用户输入生成并执行任意 Python 代码的部署都是一个显著的攻击面。沙箱解释器的内核逃逸、对文件系统或机密的访问、恶意构建的生成恶意代码的输入——这些都没有被提及。对于金融应用来说，这不仅仅是一个脚注。
论文也没有深入分析代码生成出错时的失效模式。如果 PAL 生成了语法错误的 Python，它将无计可施。作者报告了执行成功率，但没有描述导致生成失败的原因，也没有说明这些失败是随机的还是系统性的。鉴于解释器承担了所有算术工作，代码质量就是整个可靠性的瓶颈——而这一点被分析得不够。
为什么这对金融 AI 很重要
这是我读过的与 Beancount 最直接相关的论文之一。账本操作与 PAL 擅长的领域几乎完美契合：按类别汇总交易、应用汇率、计算跨多个批次（lots）的计税基础、根据账本余额对账银行流水。这些都是确定性的、重算术的且可用 Python 表达的。基于 CoT 的智能体在这些方面会产生数字幻觉；而 PAL 不会，只要程序结构正确。
Program of Thoughts (arXiv:2211.12588)，一篇独立提出相同想法的同期论文，在三个金融问答数据集（FinQA、ConvFinQA 和 TATQA）上进行了评估，并报告了比思维链平均高出约 12% 的增益。这是程序生成方法有助于金融领域推理（而非仅仅是小学数学）的最直接证据。
然而，在账本语境下，写回安全性问题比在基准测试中更尖锐。一个生成 Python 来读取 Beancount 数据的智能体是低风险的。但一个生成 Python 来写入账本条目的智能体需要一个受严格限制的执行环境——一个只能操作账本对象而不能触及其他任何东西的环境，一个在任何异常情况下都会关闭的环境，并且要求生成的代码在执行前通过白名单审核。PAL 将解释器视为中立的计算引擎。生产环境中的金融智能体不能这样做。
延伸阅读
- Program of Thoughts Prompting (Chen 等人, arXiv:2211.12588) —— 在 FinQA、ConvFinQA 和 TATQA 上进行评估的同期工作，报告了比 CoT 平均 ~12% 的增益；这是 PAL 推迟进行的针对金融领域的评估。
- FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen 等人, EMNLP 2021) —— PoT 金融评估背后的基准测试；了解实际测试的内容，可以衡量将其迁移到真实 Beancount 使用场景的可信度。
- Self-Refine: Iterative Refinement with Self-Feedback (Madaan 等人, arXiv:2303.17651) —— 与 PAL 的第一作者相同，将代码生成的见解扩展到迭代自我修正循环；对于 PAL 风格的智能体能否从其自身的代码生成失败中恢复具有参考意义。
