每一个 AI 财务技术栈都需要的四层架构

大多数“AI 用于财务”的演示，只做到了两层深度。它们连接一个数据源，再让一个模型去检索并讨论找到的内容。演示看起来很干净。然后有人问起上个季度按地区划分的毛利率，模型给出一个自信的数字，财务总监在四分钟内就把它拆穿了，因为它根本对不上总账中的任何一项。

缺失的部分正处在中间。一个可信赖的 AI 财务技术栈应该有四个截然不同的层，而不是两个:连接、对账、确定性计算和检索。人人都会跳过的正是这两层，而恰恰是这两层决定了一个数字是否经得起辩护。跳过它们，正是大多数此类演示最终在需要有人签字的那个房间里失败的结构性原因。

第一层:连接

这是每个人最先构建的一层，因为它是拥有一个令人满意的 API 的一层。你接入 QuickBooks、Xero、NetSuite、Sage、SAP 或 Oracle 实例、数据仓库，或者接收上传的对账单和导出文件。数据开始流动，模型能够看到它。

连接是必要的，而且在边界情况下确实很难做好。权限、速率限制、模式漂移，以及“营收”在一个系统中是一个字段，在另一个系统中却对应三个不同字段这样的现实。但把连接做好，只解决了一个问题:访问权限。它无法告诉你这些数字彼此是否一致，也无法阻止模型去做它本不该做的算术。

陷阱在于，连接感觉起来就像是全部的工作。你可以把一条经过认证的管道交给语言模型，让它连到总账，并观察它用平实的语言回答问题。演示效果非常出色。而这恰恰是一种会产生对不上账的数字的确切设置，因为接下来的两层什么都没做。

第二层:对账

这正是大多数技术栈存在漏洞的地方。原始财务数据不是财务模型。它是一堆来自从未被设计成彼此一致的系统的事实。子账簿与总账之间总是差几千块钱。公司间往来分录在两边以不同的时间入账。一个实体用不同的货币、不同的结账日历、不同的会计科目表报告数据。同一个数字的三份导出结果互相矛盾，而这三份从各自的来源看，技术上都是正确的。

对账，就是把这一堆事实变成一个与总账相符的统一模型的工作。真正意义上的单一事实来源:彼此对账一致、并能追溯回其来源系统的数字。这是不起眼的、确定性的、按规则驱动的工作。它同时也是决定其上所构建的一切是否可信赖的那一层，因为每一次计算、每一个被检索出的数字，都继承了其下方模型的完整性。

跳过对账，你就是在要求 AI 对矛盾之处进行推理。它会照做。它会挑出相互冲突的数字中的一个，或悄悄地把它们混合在一起，然后以和给出正确答案时一样流畅自信的态度呈现结果。模型没有任何机制去知道输入之间存在分歧。这不是一个可以靠提示词修复的问题，而是一个你没有构建的层。

第三层:确定性计算

这是最常被争论的一层，所以让我直接说明其中的机制。语言模型不进行计算，它预测最可能出现的下一个词元，而一个看起来合理的数字并不等于一个正确的数字。近期的机制性研究相当直接地指出:模型能够生成算术结果，却无法验证它，而且这些错误是可复现的，而非随机噪声。甚至已有研究专门定位出那些导致模型自信地给出错误财务答案的内部电路。对任何在这个领域构建产品的人来说，结论是明确的:模型可以决定要计算什么,但绝不能是执行计算的那个东西。

因此，计算必须发生在别处，在一个确定性引擎中。利润率、比率、增长率、合并报表、分摊、按正确日期以正确汇率进行的货币换算、环比同比运算，这些都应作为代码在经对账的模型上运行，而不是作为由一个 Transformer 生成的文字。相同的输入，始终得到相同的答案。这一特性之所以重要，与优雅与否无关:财务总监能够重新运行它，审计师也能够重新运行它。不确定性的输出，也就是同一个问题在周二给出的数字略有不同，从表面上看就无法满足基本的审计与合规要求。

对任何 AI 财务工具的一个有效测试:用略微不同的措辞，把同一个数字问题问三遍。如果数字发生漂移，说明算术运算是在模型内部进行的，而你面对的其实是一个被包装成功能的第三层问题。

这是 Rexfin 团队最常思考的架构部分，因为这正是市场一直试图跳过的部分。把一个模型连接到你的 ERP 并让它回答问题，感觉“已经完工”了。但数学结果依然是错的，因为模型仍然在充当计算器。

第四层:检索

检索是最受关注的一层，它也的确应该得到重视，只是不该被赋予演示中给它的那种角色。做得好的检索，能让一个人用平实的语言提出问题，从经对账的模型中提取出正确的数字，运行一个假设情景，并得到一个每个数字都能追溯到来源的答案。模型在这里的角色是真实且有价值的:理解意图、取回正确的数字、组织结果、做出解释。

检索所不能做的，是替代它下方的那些层。检索增强生成之所以赢得声誉，是因为它把答案锚定在真实文档之中，而对于“这个条款说了什么”这类问题，这已经足够了。财务是必须对得上账的算术。把模型指向准确的总账行，是必要的，但仍然无法阻止它从一个正确的数字中算出错误的利润率。检索能锚定数字来自哪里,却不能让计算本身正确。这正是为什么“连接加检索”这种两层式演示，会撞上一个天花板，并且始终停留在那里。

当检索建立在一个经对账的模型和一个确定性引擎之上时，情况就不同了。它返回的数字已经对得上账。计算结果已经可以被重新运行验证。模型是在用值得信赖的部件去组合一个答案，而不是凭空制造一个答案。这份洞察能够追溯到来源，是因为在模型看到它之前，这个来源本身就是真实的。

为什么中间两层总被跳过，以及代价是什么

这两个缺失的层之所以缺失，原因很平淡:它们是艰苦、不起眼的工程工作，而且演示不出来。连接有一个 API。检索有一个聊天框。对账和确定性计算是安静的基础设施，只有在缺失时才会显现出来，而到那时，你已经在向 CFO 解释为什么 AI 给出的数字和结账结果对不上了。

我承认一个明显的局限。这一切都不能让 AI 对你的业务无所不知。经对账的模型，其质量取决于喂给它的源系统，垃圾进垃圾出的道理依然成立，而关于调整项的判断，仍然属于你团队的职责。四层分离带来的收益范围更窄，但也更重要:当 AI 给你一个数字时，那是一个你能够为之辩护的数字。它对得上总账，计算结果可以被相同地重新运行，来源路径能够追溯回原始出处。

这就是财务领域的全部标准。不是“在演示中令人印象深刻”,而是“在需要有人签字的房间里经得起检验”。

如果你想看看当中间两层真正被构建出来时，一个技术栈是什么样子，支柱文章面向 AI 的可靠财务建模层呈现了完整的图景，而面向财务的 MCP 还不够深入探讨了为什么把 LLM 连接到你的 ERP,数学计算依然会出错。如果你更愿意看它对着真实数字运行，而不是阅读相关内容,预约演示,带上一个你上一个工具算错过的问题。