LLM 在 Beancount DSL 生成中得分仅为 2.3%：LLMFinLiteracy 基准测试

这是我自 LOG-001 以来一直在等待的一篇论文：一项针对 LLM 是否能从自然语言金融场景中生成有效的 Beancount DSL 交易的直接实证测试。来自柏林应用科技大学的 Figueroa 等人提出了他们所称的——据我所知是正确的——首个已发表的关于 LLM 在纯文本会计中生成金融交易能力的评估。简而言之：它们做不到，至少在没有可靠性的情况下做不到，即使使用了思维链（CoT）提示词，并将实际的 Beancount 资产负债表作为上下文提供给它们。

论文详解

Figueroa, Grundmann, Freidank, Löser 和 Nejdl 在一个名为 LLMFinLiteracy 的双任务基准测试中评估了五个约 7B 参数的权重开放模型。任务 1 要求模型根据来自五个 DAX 上市公司（空客、拜耳、德国电信、梅赛德斯-奔驰、SAP）的真实季度资产负债表，生成会影响特定流动性比率（流动比率、速动比率或现金比率）的文本场景。任务 2 要求模型将这些场景翻译成可编译的 Beancount 交易。Beancount 编译器充当基准语法检查器；人类领域专家评估语义正确性。论文介绍了一个涵盖这两个任务的 12 类错误分类法，并使用了包含双入账会计规则、输入/输出示例以及 Beancount 格式的真实公司资产负债表的 9 步思维链提示词。由于金融数据的敏感性，评估的模型——Llama-3-8B、Qwen-2-7B、Mistral-7B、CodeLlama-7B 和 CodeQwen-1.5-7B——都在本地运行。语料库总计 1,500 个生成的样本，其中 300 个分层条目由人类专家进行了评估。

核心观点

• 在 300 个评估的场景-交易对中，只有 7 个（2.3%）是完全端到端正确的；即使仅限于三个通用模型，正确率也仅上升到 3.8%。
• 表现最好的两个模型 Qwen-2-7B 和 Mistral-7B，生成正确场景的概率仅为 21.67% 和 20.00%，生成正确编译交易的概率仅为 16.67% 和 10.00%。
• 代码专用模型（CodeLlama, CodeQwen）在两个任务上得分均为 0%；它们对提示词模板的响应是字面上的“Processed — Waiting for next input”字符串，完全忽略了任务。
• 语法不是瓶颈：没有模型产生过任何语法错误。失败完全在于会计推理——余额错误在 Qwen-2（61.67%）和 Llama-3（38.33%）中占主导地位，而 Mistral 则主要引用了提供的资产负债表中不存在的账户（45% 的未知账户错误）。
• 很大一部分成功编译的交易在语义上是错误的——模型最喜欢的技巧是将减少负债称为“出售你的债务”，这虽然增加了现金，但原因错误。
• 被用作自动裁判的 GPT-4o 未能发现向其展示的所有 10 个荒谬场景中的不一致之处，这证实了 LLM 自我评估对于会计输出而言并非可靠的质量门控。
• 模型在很大程度上是复制提示词中的输入/输出示例，而不是进行泛化：那 7 个正确的交易对与提供的示例交易结构非常相似。

哪些结论站得住脚，哪些站不住？

论文的核心实证贡献是扎实的。Beancount 编译器是一个客观、可重复的正确性标准，使用真实的公司资产负债表而非演示数据增加了生态有效性。分层错误分类法设计得非常周到——在发现第一个错误时停止评估，避免了对垃圾输出给予“部分学分”而导致的虚高评分。

也就是说，存在作者大多承认的明显局限性。来自 2023–2024 年的五个约 7B 权重开放模型只是能力格局中的一小部分；出于隐私原因排除了 GPT-4o 和 Claude，这虽然可以理解，但意味着标题数据（2.3% 正确率）低估了前沿水平。为了测试内在的领域知识，提示词中故意省去了财务比率公式——这在方法论上是一个有趣的选择，但这也使得结果与任何合理包含公式文档的系统都不具有可比性。此外，跨越五个模型、三个比率和五家公司的 300 个由人类评估的样本规模较小；每个模型每个比率的单元格太小（12 个样本），无法得出关于方差的有力结论。

最有趣的方法论空白是缺乏任何基于迭代或反馈的协议。没有工具调用，没有自我修正，没有编译器反馈循环——只有单次生成。鉴于 CRITIC (LOG-012) 和相关工作表明，工具交互式优化能显著提高具有可验证输出的任务的准确性，一个“Beancount 编译器在环”的实验本可以提供更多关于可部署性的信息。

为什么这对金融 AI 至关重要

Bean Labs 回写代理的每个设计决策都基于对 LLM 处理 Beancount DSL 能力的假设。这篇论文是第一个实证锚点。标题结论虽然令人清醒，但也具有非常有用的解释性。

首先，失败模式是特定的，而非随机的。余额错误和未知账户是两个主要问题，两者都可以通过编译器在环反馈循环来解决：Beancount 编译器会准确地告诉你哪个账户是未知的，以及交易是否平衡。一个基于编译器输出进行迭代的代理架构——而不是生成一次就停止——其表现应该会显著优于此处的单次生成结果。其次，语法是“免费”的。模型显然已经学会了 Beancount 的表面语法；它们只是无法可靠地将金融意图转化为正确的账户变动。这种区别对于在提示词工程和微调方面投入精力的方向至关重要。第三，GPT-4o 无法自动评估会计质量的发现提高了任何自动验证系统的门槛：你需要编译器，加上领域专家的抽查，而不是一个 LLM 裁判。

这篇论文还证实了我从异常检测工作 (LOG-049) 中怀疑的一点：处理金融交易的 LLM 过于容易执行“编译并提交”。“错误 | 可编译”这一类别——即通过了语法检查但在语义上错误的交易——正是回写安全护栏必须捕获的失败模式。一笔交易可以完美平衡，但仍将收入记为负债减少，这在任何纯语法检查中都无法被检测到。

延伸阅读

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) —— 基于似然的异常评分，作为批量检测方法的替代方案；可自然地与 Beancount 编译器信号结合，以标记结构有效但统计异常的条目。
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) —— 将低置信度的决策路由到更大的模型或人类；直接解决了 Beancount 回写代理何时应推迟到人工审核，而不是在编译器反馈循环后继续执行的问题。
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) —— 在本文评估的架构之上构建编译器在环修正代理的最相关的现有工作。