构建财务数据的 AI 控制栈:一套参考架构

一位财务主管让 AI 助手回答上季度的自由现金流是多少。它在两秒内给出了答案，语气自信，格式规整，看起来有据可查。这个数字其实错了 4%。没有人发现，因为根本没有任何机制可以发现它。模型检索了一个数字，在“脑中”做了一些运算，然后打印出结果。没有第二双眼睛核对，没有重新计算，没有日志记录。

这正是大多数“财务 AI”部署普遍存在的缺口。模型本身没有问题，缺失的是围绕它的架构。当问题是 CFO 能否把一个 AI 生成的数字呈现给审计委员会时，答案几乎完全取决于语言模型和账本之间架设了什么。

本文是针对这个“中间地带”的参考架构。可以把它想象成五道控制层，每一层拦截一种不同的失败模式，层层叠加，使一个数字在到达人之前必须通过全部五层。

为什么单一模型不能构成控制

先看一组令人不安的基准数据。在财务电子表格类任务上,2026 年最强的模型准确率也只徘徊在 82% 左右，相当于每六个问题就有一个出错。在更难的多步骤财务推理任务上，即便是前沿模型也只能维持在 80% 多到 90% 出头的水平，而且在时序推理和情景分析上表现更差，而这恰恰是财务工作的核心。没有任何一个独立的语言模型能把错误率降到可以无监督用于生产环境的程度。这不是靠提示词工程就能解决的问题，而是这类系统生成文本方式本身的固有属性。

因此设计目标不是找一个更好的模型，而是让模型最薄弱的能力(可靠地做算术)变得无关紧要，同时用检查机制包裹住它最擅长的能力(阅读与解释)。下面的每一层都各司其职。

第一层:边界处的数据质量

垃圾进，垃圾出，仍是错误答案的主要来源，也是最不起眼、最难被重视的一环。在任何数据进入模型之前，输入必须经过对账，而不仅仅是“存在”。这意味着从 QuickBooks、Xero、NetSuite、Sage、SAP 或 Oracle 实例、数据仓库，或上传的 PDF 报表中提取的数字，都要归并进一个与总账相符的统一模型中:科目已映射，期间保持一致，公司间交易已抵消，科目表有据可查。

这一层的控制机制就是对账本身:一个核对检查，一旦汇总模型与源账本对不到分毫就会明确报错。如果第一层没有通过，下游任何环节都不应运行。在脏数据上做出的干净计算，不过是一个自信的错误答案。这个经过对账的基础正是大多数团队会跳过的部分，也是他们的演示一旦接触真实数据就崩溃的原因。我们在为什么电子表格是 AI 财务的错误基础中对此有详细阐述。

第二层:确定性计算

这是承重层。语言模型永远不计算自由现金流，永远不做比率反算，永远不判断某项变化是绝对值还是百分比。它只负责识别用户在问什么、涉及哪些数字，然后调用一个确定性引擎，针对已对账模型运行真正的公式。

相同的输入，永远得到相同的输出。财务主管可以像证明电子表格单元格一样证明这个结果:追溯到操作数，检查公式，重新计算。运算存在于具有固定定义的代码中，而不是存在于对 token 的概率分布中。这是唯一一个能让你从“通常是对的”变为“对且可证明”的改变，也是为什么确定性且可重放的计算已经成为审计人员对 AI 输出的期望标准。

第三层:输出审计

即便输入干净、计算确定，你仍然需要在引擎结果和用户之间设一道检查。输出审计是一组规则，在每个答案展示之前运行:数字是否落在合理区间内，资产负债表是否平衡，现金流出的符号是否合理，本季度收入是否处于过去若干季度的合理区间内?

这些不是 AI 的判断，而是一名敏锐的分析师会不假思索做的常规核实，被编码为确定性断言。一旦某项检查失败，答案就会被拦截并标记，而不是直接放行。监管机构正日益期待这种行为验证方式，即测试系统的输出而不仅仅是检查模型本身，因为对于供应商提供的 LLM,权重本来就不是你能检查的对象。我们在面向供应商 LLM 的输出验证中详述了这一约束。

第四层:访问控制

谁有权提问，谁又有权看到什么?一个抹平权限边界的 AI 界面，不过是带了个聊天框的数据泄露事件。控制层必须执行与底层系统相同的实体、期间和字段级限制，并且必须把每一次查询归属到真实的个人身份，而不是一个共享服务账号，后者会让审计轨迹形同虚设。

这一点在 AI 场景下比在静态报表中更重要，因为界面鼓励开放式提问。某地区团队的员工问一个宽泛问题，不应该因为模型“乐于助人”就拿到集团级别的数字。访问控制必须处在查询路径中，而不是事后补挂上去的。

第五层:不可篡改日志

最后一层记录前四层所做的一切，且以不可被悄悄篡改的形式保存。对每一个答案:谁提问、问了什么、哪个源数据及版本参与了计算、运行了哪个公式、输出审计检查返回了什么结果、最终返回了什么数字。仅追加、带时间戳、长期保留。

正是这一点，把一个数字变成了一个站得住脚的数字。几个月后，当董事会成员对某个数字提出质疑，或审计人员要求提供支持材料时，你可以回放这条记录，从完全相同的输入中复现完全相同的结果。日志也是监管期望正在悄然趋同的地方，取代 SR 11-7 的 2026 年模型风险框架高度强调可追溯性和可复现性，欧盟《AI 法案》的日志留存要求也指向同一方向。

各层如何协同失效得体面

叠层控制的意义在于纵深防御。一个错误的源数据会在第一层被拦下。推理失误根本不会发生，因为第二层已经把推理从运算中剔除。一个偏离常规的结果会在第三层被拦截。不该看到某些数据的用户会在第四层被挡住。而如果仍然出了问题，第五层能让你精确查明是什么问题、发生在何时。

也要诚实面对局限。这套架构并不能让语言模型变准确，它只是让模型的不准确不再致命。它并不能消除对重要数字进行人工复核的必要性，而是让这种复核变得快速且有据可依，而不是一场信任的飞跃。它还会增加延迟和工程成本:确定性引擎、对账、日志记录，这些都是实打实的工作量。但换来的是一个财务主管真正愿意签字确认的输出。

有一条诱人的捷径值得点名:通过 MCP 之类的协议把 LLM 连到你的 ERP 上，然后就认为大功告成。这确实能让模型获得受治理的实时数据访问权，大致相当于第四层，但它仍然让模型在原始总账字段上做脆弱的算术，没有对账，也没有确定性计算。检索从来不是难点，中间那几层才是。

结论

如果你只记住一件事:模型是可信赖的 AI 财务系统中最不重要的组件。价值在于其下方经过对账的基础，以及围绕它的控制机制。搭建好这五层,AI 就能整天检索、解释、建模情景，每个数字都可追溯至源头。跳过它们，你得到的只是一台生成自信错误的高速机器。

Rexfin 正是承担这项工作的那一层:一个经过对账的模型、一个确定性计算引擎，以及不可篡改日志，同时让 LLM 专注于它擅长的推理和检索。如果你想看看一个董事会演示中的答案是如何被一路追溯回产生它的账本条目的，请预约演示。