GLM 5.2 增值税基准测试：AI 在英国中小企业记账中的准确性
GLM 5.2 增值税基准测试：AI 在英国中小企业记账中的准确性
GLM 5.2 实现了接近人工水平的增值税申报准备准确度
GLM 5.2 是一款开源权重的 AI 模型，能够以远低于人工簿记员的成本为英国小企业准备几乎完美的季度增值税（VAT）申报。在一次涉及 59 笔交易的基准测试中，该模型在 68 分钟内处理完数据，原始 token 成本为 $2.73，最终的净增值税位置仅比人工准备的真实值偏差 7 便士（约合 10 美分）。
基准测试方法论
数据与环境
研究人员使用 Vineyard Finance 2026 年第一季度的账簿作为测试集。基准测试向模型提供了每笔交易的三类主要输入：
- 银行流水行：包含日期、金额、货币和描述的 JSON 数据。
- 收据 PDF：包含文本的 PDF（不需要视觉能力）。
- 用户备注：可选的上下文信息（在 59 笔中有 2 笔使用），用于提供银行流水或收据中无法推导的真实业务信息。
GLM 5.2 部署在 Google Cloud Platform（GCP）实例上，使用 Fireworks AI 的无服务器层。为确保模型无法访问真实答案，它被隔离在测试环境之外，但仍拥有互联网访问权限以及通过预先认证的命令行界面（CLI）工具访问云端会计软件的权限。
评分标准
每笔交易依据会计软件最终状态的六项确定性标准进行评估：
- 交易类型：（例如采购、销售收入、转账）。
- 科目：科目表中的具体账户。
- 增值税处理：（例如 20% 增值税、0% 增值税、逆向收费）。
- 增值税金额：误差在 0.02 英镑以内。
- 逆向收费增值税：误差在 0.02 英镑以内。
- 收据附件：验证是否附上了正确的凭证。
性能分析
成功之处
GLM 5.2 在多项复杂记账任务中表现出高度可靠性：
- 准确分类：模型几乎为每笔交易分配到了科目表中的正确账户。
- 消歧义：成功处理了棘手的输入，如同一供应商在同一天的相同金额、公司银行之间的转账以及跨多条银行流水的交易拆分。
- 文档匹配：模型从未将错误的发票附加到交易上。
错误与局限性
在 354 项评分检查中，模型在 18 笔交易中共出现 20 处错误。这些错误可归为三类：
1. 法律分类错误（严重） 模型将“创始股份”（10,000 英镑）错误归类为“资本账户”，而非“未缴股份”。虽然此错误未影响增值税申报，但在公司审计和年终报表中具有重大法律影响，因为股本是永久性的、保护债权人的资本。
2. 税务类别混淆 在 14 笔交易中，模型将“零税率”增值税与“免税”增值税混淆。虽然两者都不涉及增值税付款，但在税法中属于不同类别。模型的表现呈随机性：一月和二月出现错误，三月则成功。
3. 拆分交易的推理错误 在涉及多币种余额（Wise）的三起案例中，模型偶尔会出现“双重计税”，即对拆分交易的主腿和残余腿都计入增值税，尽管财务影响可以忽略不计。
技术资源消耗
| 月份 | 交易数 | 回合数 | 工具调用数 | 实际耗时 | Prompt Tokens | Output Tokens | 估算费用 |
|---|---|---|---|---|---|---|---|
| 一月 | 8 | 28 | 38 | 10.3 min | 871,917 | 34,371 | $0.45 |
| 二月 | 29 | 37 | 44 | 31.4 min | 1,873,745 | 65,929 | $0.94 |
| 三月 | 22 | 47 | 55 | 26.3 min | 2,985,966 | 93,183 | $1.34 |
| 总计 | 59 | 112 | 137 | 68 min | 5.73M | 193,483 | $2.73 |
注：Prompt tokens 有 92‑95% 已缓存，显著降低了成本。
社区洞察与反驳
技术用户的讨论凸显了基准成功与实际部署之间的若干关键差距：
数据获取的“最后一公里” 批评者指出，基准测试向模型提供了收据和用户备注，而人工簿记员必须主动在邮箱中寻找发票或向供应商索取。
“几乎所有值得做的非录入类办公室工作，都涉及大量未记录（甚至不可记录）的问题，需要判断力和经验。”
责任与问责 一个反复出现的担忧是税务错误的法律责任。与人类会计师不同，LLM 不能被追究法律责任，也不会因税务欺诈或疏忽而入狱。
“你买的不是服务本身，而是免于担心服务的后顾之忧。”
“几乎正确”悖论 一些用户认为，在税务合规中，“基本正确”是不够的，因为任何错误都可能导致罚款或审计，无论误差多小。
“我不能向 IRS 提交‘几乎’正确的报表。那不会有好结果。”