GLM 5.2 几乎像人类记账员一样准确

# GLM 5.2 在准确度上几乎与人类记账员持平，但成本不到其1% 来源：https://toot-books.pages.dev/blog/glm-5-2-vat-benchmark 我们评估了开放权重的 AI 模型 GLM 5.2 在为一家英国小企业准备季度增值税申报表时的表现。准备增值税申报表是英国中小企业的典型合规任务。在英国，注册增值税的企业必须每季度准备增值税申报表。对于中小企业，增值税申报表通常由外部会计师事务所准备。此服务的典型费用约为每季度 750–2,100 英镑（1,000–2,800 美元）。法定的提交期限是季度结束后 5 周内。逾期提交将面临高额罚款。 在我们的测试中，GLM 5.2 可以为一家英国中小企业准备一份近乎完美的季度增值税申报表，处理 59 笔交易，耗时 68 分钟，原始 token 成本为 2.73 美元。GLM 5.2 必须通过命令行工具将每笔交易输入会计软件。我们根据会计软件的最终状态进行评分，每笔交易检查 6 个标准的正确性。模型生成了基本正确的增值税申报表，净额（第 5 栏）与真实基准仅相差 7 便士（约 10 美分）。 在这篇博文中，我们将解释基准测试是如何进行的，并指出模型所犯的错误。 ## 基准测试是如何进行的 我们使用了 Claude Fable 5 从我们的会计软件中提取基准交易数据及相应的收据：Vineyard Finance 2026 年第一季度的账簿（2026 年 1 月、2 月、3 月）。这些账簿由人工内部准备，遵循典型的会计流程：一人记账，另一人复核。人类完成的工作范围比本基准测试中要求模型完成的工作更广：人类还需要查找相关发票（通过搜索邮箱或向供应商索取），并对无法仅从银行流水和发票/收据推断出的任何情况进行推理。本基准测试中，这些情况以“用户备注”的形式提供给模型。 GLM 5.2 运行在与测试环境其余部分隔离的 Google Cloud Platform 实例上（以防止模型访问真实基准），但它可以访问互联网、基于云的会计软件以及一个预认证的命令行工具。模型运行在一个定制的最小化 harness 上，该 harness 仅暴露了两个工具：bash 工具和会话终止及最终报告工具。我们使用 Fireworks AI serverless 层级作为 GLM 5.2 模型提供商（提供商未披露模型的精确量化级别，但据信为 FP16 或 FP8）。 对模型推理和工具使用情况的审计未发现任何明显的作弊行为。模型对互联网的唯一意外使用是收集关于记录反向征收增值税的信息，并且所寻找的信息是针对所使用的会计软件的。其他出站连接是预期的，并且是基于运营原因以 API 调用的形式向会计 SaaS 提供商发起的。我们注意到，模型的推理受到了意识到自身正在被测试的影响。例如，模型在某一点上评论道： “任务是在测试我是否正确处理增值税……什么是‘预期’答案” ## 模型看到了什么 以下是基准测试中典型交易呈现给模型的方式： **银行流水行：** ```json {"id": "941285000000092067", "date": "2026-03-08", "amount": -18, "currency": "GBP", "account": "Wise GBP", "description": "Card transaction of 18.00 GBP issued by Claude.ai Subscription ANTHROPIC.COM CARD-3534994599", "card_ref": "CARD-3534994599"} ``` **收据 PDF：** 基准测试中的所有收据和发票均为包含文本的 PDF；无需图像处理。因此，GLM 5.2 模型缺乏视觉支持并不是本基准测试的限制因素。 **可选的用户备注。** 59 笔交易中只有两笔有用户备注。用户备注的文本如下：1）“创始人股份”和 2）“个人租车”。这两个用户备注是必要的，以便让模型推理出无法从银行流水和收据数据中推导出的现实世界背景。 ## 我们如何评分 每笔交易根据基准测试运行后会计软件中账簿的最终状态，按以下 6 个标准进行评分： 1. **交易类型**（例如购买、银行手续费、转账、销售收入、资本注入、董事贷款、退款等）——这些是根据会计软件中已处理交易的状态确定性推导出来的。 2. **科目类别**（会计科目表中的“账户”，例如“IT 和互联网费用”）。 3. **增值税处理**（例如反向征收、20% 增值税、0% 增值税、增值税豁免）。 4. **增值税金额**（容忍度 0.02 英镑）。 5. **反向征收增值税**（容忍度 0.02 英镑）。 6. **附有收据**（税务机关要求的证据）。 下表总结了整个季度的基准测试运行情况： | 月份 | 交易数 | 轮次 | 工具调用 | 挂钟时间 | 提示 token | 缓存占比 | 输出 token | 峰值上下文¹ | 预估成本 | |------|--------|------|----------|----------|-------------|----------|-------------|-------------|---------| | 一月 | 8 | 28 | 38 | 10.3 分钟 | 871,917 | 92% | 34,371 | 66,381 (6.3%) | $0.45 | | 二月 | 29 | 37 | 44 | 31.4 分钟 | 1,873,745 | 92% | 65,929 | 111,246 (10.6%) | $0.94 | | 三月 | 22 | 47 | 55 | 26.3 分钟 | 2,985,966 | 95% | 93,183 | 139,128 (13.3%) | $1.34 | | 季度 | 59 | 112 | 137 | 68 分钟 | 5.73M | 93% | 193,483 | 139,128 (13.3%) | $2.73 | 每月运行一次连续的智能体会话；“轮次”是一次 API 调用，整个对话在每次轮次中重新发送——这就是为什么提示 token 达到数百万，而其中 92–95% 由提供商缓存以五分之一的价格提供。输出 token 包括模型的内部推理。 ¹ 峰值上下文是单次最大调用，占模型 1,048,576 token 上下文窗口的比例——最繁忙的月份使用了大约八分之一。 ## 模型犯了什么错误？ 模型准备的增值税申报表基本正确：申报表中最重要的数字——公司应税务机关退还的增值税金额——与人工准备的申报表仅相差 7 便士。 然而，了解模型做错了什么以及为什么在实际中很重要是有益的。模型的大多数错误实际上没有财务影响，但熟练的会计师绝不会犯这些错误。 在 354 项检查（59 笔交易 × 6 个标准）中，模型有 20 项未通过，分布在 18 笔交易中。只有 1 个错误是严重的，我们将先讨论它；其余 19 个错误属于以下两类之一。 严重的错误是模型如何处理创始人股份。在英国，有限公司发行“股本”。股东（包括创始人）将资本支付到公司账户，这应该记入类似“已催缴但未缴股本”的科目，在我们使用的软件中称为“未缴股份”。这是对此付款的正确会计处理。模型的选择是“资本账户”，这具有法律含义，可能会对公司产生影响，并且在审计期间可能受到质疑，或在年底提交公司账目时成为问题。争论的实质是，股本（“未缴股份”）不仅仅是创始人的资金（“资本账户”）。它是永久的、保护债权人的资本，带有法律约束。例如，它不能简单退还给创始人，还必须在年底申报中适当向税务机关披露。进一步加剧这个问题的是涉及的金额：10,000 英镑（约 13,300 美元）。这可不是零钱。虽然对增值税申报没有影响，但这是模型在本基准测试中犯下的最大错误。 在其余 17 笔交易中，有 14 笔的错误类型是混淆了“零税率”增值税类别和“免税”类别。这两个类别都不涉及增值税支付，但由于微妙的税务原因，它们是不同的。实际影响很小，但熟练的会计师通常不会混淆这两者。有趣的是，模型在这里是随机性的——它在一月和二月犯了错误（并且 100% 地犯错误），但在三月没有犯错误，正确处理了每笔增值税豁免交易。 最后 3 笔交易共有一个稍显晦涩的推理错误，并且可以争辩说，在一种情况下（同样是在三月），模型实际上是正确的。在 Vineyard Finance，我们使用 Wise，它有一个稍微奇怪的习惯，即资金分散存放在多种货币的余额中，即使用户有意识地只使用一种货币。当用卡消费时，Wise 按某种明确定义的顺序从各个余额中取钱。在我们的案例中，我们收到来自 Wise 的某种“现金返还”或“费用退款”，不知何故进入了美元余额（我们通常不使用美元余额）。因此，一笔以美元支付的服务费用导致了一笔“拆分交易”，即跨两个余额的两笔交易，具体是 0.51 美元和 43.45 英镑。通常增值税会在“主要”交易（43.45 英镑）中核算。在一次实例中，模型不幸地“双重计算”了——它在“主要部分”（比如 43.45 英镑）上核算了全部增值税，并按比例减少了“剩余部分”（比如 0.51 美元）上的增值税份额。这是不正确的，尽管无关紧要。在三月份的一笔交易中，模型意识到这会导致重复计算，因此计算出了正确的增值税总额，并将其分摊到每一部分。这非常规，但可以认为没有错（评分者比较保守，但仍将三月的交易视为错误）。 ## 模型总是正确的地方 同样重要的是，应该注意模型总是正确的地方： - 除了那个股本错误外，它正确地将每笔交易归类到会计科目表中正确的账户。 - 它从未将错误的发票附加到交易上。 - 它能够区分真正棘手的输入，例如两笔金额相同、供应商相同、日期相同的交易。 - 它正确地区分了棘手的交易，例如公司银行之间的转账、拆分成两行银行流水的单笔交易，以及伪装成卡购买的转账。直到最近，这只有通过昂贵的、前沿的 AI 模型，或者熟练且昂贵的人工记账员才能实现（而便宜的记账员通常不如今天的 GLM 5.2 做得好）。 ## 这意味着什么？我们应该从中学习什么？ 记账正迅速成为一个已解决的问题。当前的重点需要放在构建适当的框架上，将这些能力交到英国初创公司和中小企业手中。我们正在开发这样一个解决方案——您可以在 toot-books.com (https://toot-books.com/) 测试我们产品的公开测试版。如果您对自动化记账感兴趣，请通过 [[email protected]](mailto:[email protected]) 与我们联系。