在信任一款 AI 财务工具之前，如何对它进行压力测试

供应商坐在你对面说，他们的 AI 在财务数据上“准确率达 98%”。不妨问一句：98% 是相对于谁的答案而言，衡量的是什么。在大多数演示中，诚实的回答是，这个数字来自某个公开基准，是在别人的报表上跑出来的，评分方式你也看不到。这几乎无法告诉你，这款工具在你的结账分录、公司间抵消、混乱的会计科目表上会表现如何。

已发表的研究结果同样不令人安心。在 FinanceBench 上，这是一个从美国上市公司文件中提取的、包含超过 10,000 个问答对的基准测试中，一次针对 GPT-4-Turbo 搭配检索系统的早期测试，在 150 个问题的样本中，约有 81% 的回答错误或拒绝作答。这可是一个前沿模型，配备检索能力，处理的还是干净的 SEC 文件。而你的数据只会更复杂。

所以，别再轻信头条式的准确率数字，自己动手建一个测试。黄金数据集是财务团队在签任何合同之前最值得花一个下午做的事，也是日后经受住审计委员会质询的唯一证据。

黄金数据集究竟是什么

黄金数据集是一组关于你财务数据的固定问题，答案是你已经知道的正确答案，并且经过一位能够为其辩护的人核准。不是模型给出的答案，而是财务主管的答案，且与总账挂钩。

每一条记录包含四个部分：用户实际会如何提问的问题、带单位和符号的正确答案、答案可追溯到的来源（哪个科目、哪个期间、哪张报表），以及产生该答案的计算过程。“第三季度自由现金流是多少？”是一个问题。“418 万美元，经营性现金流 602 万美元减去资本支出 184 万美元，依据现金流量表”才是一个黄金答案。数学过程与来源脉络是记录的一部分，不是事后补充。

你不需要成千上万条这样的记录，只需要那些真正重要、以及那些会让工具出错的记录。

应该纳入哪些内容

有意识地从四个类别中取材。

检索类案例。 单纯的查找。“上一财年总收入是多少？”这类问题检验工具能否在正确的期间找到正确的数字。它们看起来很简单，却是过时数据错误藏身的地方，因为模型会满怀信心地报出去年的数字。

计算类案例。 任何需要数学运算的内容：毛利率、同比增长、应收账款周转天数、三行式 EBITDA 桥接。大多数 AI 财务工具正是在这里悄悄失手的。模型可以正确检索到两个数字，却仍会把比率算反、把绝对变化误当成百分比变化，或者把现金流出的符号弄反。答案读起来言之凿凿，实则是错的。这正是我们在《AI 数字对了，数学错了》中讨论的失效模式，也是为什么要把计算测试和检索测试分开的最大原因。

对抗性案例。 专门用来诱导出自信错误答案的问题。问一个你不报告的指标，问一个尚不存在的期间，或者提出一个暗藏错误前提的问题（比如“第二季度毛利率为什么下降？”而实际上它是上升的）。值得信赖的工具会说自己无法回答，或纠正这一前提；不靠谱的工具则会编造答案。你需要知道自己买到的是哪一种。

多来源案例。 迫使工具跨系统核对的问题：一个同时出现在总账和账单系统中的数字，一个横跨两家实体的合并数字。如果工具只从一个来源取数、无视冲突，你在这里就会发现。

目标是几十条到几百条不等，并让计算类和对抗性案例占足够比重，因为正是它们决定了通过率的走向。

设定阈值，并且要让它有痛感

在测试开始之前先书面确定一个数字。对于任何会进入报告或董事会材料的数字，我们以 95% 作为起始门槛，更低的阈值几乎没有意义。在 90% 的水平上，十个答案中就有一个是错的，而你无法预知是哪一个，这意味着人工必须重新核查所有答案，工具存在的意义也就荡然无存。

然后精确定义“正确”的含义：数字完全一致、符号正确、单位正确、期间正确。一个数量级正确但符号错误的工具，在该项目上不是“90% 正确”，而是错的，就应该这样打分。对计算类和多来源类案例的要求应比单纯检索类更严格，因为这些是财务主管无法凭肉眼判断对错的地方。

再借用一条来自董事会材料验证清单的规则：一个无法追溯来源的答案应记为未通过，即便这个数字碰巧是对的。一个无法证明的正确数字，在审计中不是资产，而是等着被质疑的负债。

按计划重新测试漂移

这是大多数团队会跳过的一步。你在二月通过了测试，就以为这款工具在七月依然安全，未必如此。它背后的模型会被更新，你的数据结构会变化，提示词会被调整。准确率可能从 96% 悄悄滑落到 88%，却没有任何公告，因为表面上什么都没坏。

按月运行黄金数据集，或者在任何模型或集成变更之后运行，以先到者为准。持续追踪通过率。下降两个百分点值得调查，下降五个百分点则应该暂停依赖，直到你搞清楚原因。这就是“只信任一次”与“持续治理”的区别。

这项测试真正衡量的是什么

归根结底，黄金数据集对任何 AI 财务工具提出两个问题：它是否找到了正确的数字？它是否做对了数学？大多数在第一项上表现良好的工具都会在第二项上失手，因为计算是由一个预测数字“应该”长什么样、而不是真正计算数字的语言模型来完成的。

这正是隐藏在这一切背后的架构问题。如果数学运算发生在 LLM 内部，你的通过率就永远只是一个概率，而且还会漂移。唯一持久的解决方案，是把计算完全从模型手中拿走。

这正是 Rexfin 的构建方式。我们连接你的会计平台或上传的报表，将其核对整合为一个与总账对得上的模型，然后让 AI 检索数字，并通过确定性引擎（而非语言模型）运行每一项计算。相同的输入，相同的答案，每次都是如此，并且都有一条通向源头的回溯路径。用这样设计的系统跑一遍你的黄金数据集，计算类案例就不再是失败的那一类。

在购买任何东西之前先建好这个数据集，然后预约演示，把你最难的问题直接抛给我们。如果数字对不上你的总账，你应该转身走人。我们宁愿你来测试我们，而不是仅仅信任我们。