为什么财务智能体必须调用工具,而不是自己计算
LLM 预测的是一个数字应该长什么样,而不是真正运行公式。智能体式财务的解决方案,是让每一次计算都通过确定性工具运行在一个已核对的模型之上。
作者 The Rexfin team
让一个大语言模型把两个九位数相加,它经常会给出一个看起来完全正确、实际上却相差几千的答案。数字位数是合理的,数量级是对的,答案却是错的。正是这一个行为,让大多数“财务 AI”演示在总监核对数学结果的那一刻当场崩塌。
底层机制令人不安。LLM 并不运行算术,它预测的是下一个词元。当你要求计算 14,820,116 减去 9,335,402 时,模型并不是在做减法,而是在根据训练中吸收的一切,生成在统计上最可能跟在你的提示之后的那串数字。对于常见的小数字求和,它实际上已经记住了这些模式并能算对。而对于真实总账中充斥的那些又长又不规则的数字,它是在猜一个大致的样子。有时猜对了,但你仅凭输出本身完全无法判断是哪一次,因为一个自信的错误数字读起来和一个自信的正确数字一模一样。
问题就在于这个数字看起来是对的
这比普通的软件缺陷更糟,因为它的失效模式是伪装。电子表格里一个损坏的公式通常会抛出 #REF! 或一个明显不可能的总数。而一个语言模型给出的数字,恰好落在 CFO 会预期的范围之内。本应是 4730 万的营收变成了 4690 万,本应是 62% 的毛利率变成了 64%。没有任何警报响起。这个错误之所以能逃过审核,正是因为它本来就是被生成出来长得像真相的样子。
基准测试证实了这一点。在 FinanceBench 上,一套取自上市公司备案文件的问答证据三元组测试集中,搭配检索系统的 GPT-4-Turbo 只正确回答或尝试了少数问题,在最初的评估中大约五分之四都答错或拒答了。即使把包含答案的确切文档直接交给它,针对财务报表问题的准确率据报道从不到两成到接近九成不等,具体取决于提问措辞和上下文的位置。更新的专用技术栈能把准确率大幅提高,但这个波动范围本身就是一个警示。一个准确率会因为你把问题放在提示词中的位置不同而摆动四十个百分点的系统,不是你能用来支撑一个董事会数字的东西。
这并不意味着模型没用,而是意味着你要求它做了一件它在结构上无法保证做到的事。
推理留在模型里,数学交给专门的层
解决办法不是更好的提示词或更大的模型,而是一次分工。
语言模型在财务工作中软性的那部分确实做得很好:理解“烧钱”指的是净现金流出,判断一个关于“跑道”的问题需要用现金余额除以月度烧钱速度,注意到用户大概率想要的是年初至今的数字而不是季度数字,并围绕结果拼出一段通顺的白话解释。这是推理,也是模型真正发挥价值的地方。
模型绝不应该做的是减法、除法、货币换算、期间汇总或比率计算。这些要交给确定性工具,即真正的代码,每次都用同一种方式运行同一个公式。模型的职责是选对工具、提供正确的参数,并读出结果。这正是工具调用(或函数调用)被设计出来要解决的问题:让语言部分保持灵活,让计算部分保持精确,而且永远不要把两者混为一谈。
说得直白一点:智能体应该负责推理该计算什么,然后调用别的东西去真正计算出来。当一个智能体在自己“脑子里”计算利润率时,你信任的是一个概率分布,而它承载的是你经过审计的账目。当它调用一个工具时,你信任的是算术本身。
为什么工具调用之下仍然需要一个已核对的模型
单靠工具调用还完成不了这项工作,而这正是许多 2026 年架构差一步没做到的地方。给智能体一个 calculate_ratio() 函数是必要的,但不充分,因为这个函数的可信度完全取决于你喂给它的数字。如果智能体从一个系统取来营收数字,从一份过期导出文件取来成本数字,再从一张幻灯片取来员工人数,这个工具会在不一致的输入上计算出一个完美确定的比率。建立在坏数据之上的确定性,只会给你一个可重复的错误答案。
所以这些工具必须运行在一个已核对的模型之上,即一个与账本对得上的单一财务模型,其中每个数字都有已知来源,输入之间彼此已经一致。这正是 Rexfin 视为根基的部分。我们连接你的会计和财务数据平台(QuickBooks、Xero、NetSuite、Sage、SAP、Oracle、数据仓库)或上传的报表,构建出一个与账本对得上的已核对模型,再在其之上暴露确定性的计算工具。智能体负责推理,确定性引擎负责计算,每一个输出都能追溯回源头。
顺序很重要。先连接,再核对,然后才让引擎去做数学计算,跳过中间这一步正是大多数演示产出的数字没有一位总监会签字确认的原因。我们在工作原理中详细讲解了这个流程,同样的原则也是为什么单靠 MCP 对财务领域来说是不够的:被治理的 ERP 访问权限能让模型拿到实时数据,但如果没有一个已核对的层和确定性计算,LLM 依然是在原始字段上做脆弱的概率性算术。
这能为持怀疑态度的 CFO 带来什么
具体来说,三件事。
第一,可重演性。同一个问题问两次,得到同样的数字,因为数学计算是在代码中运行的,而不是在采样器里运行的。你可以像证明一个电子表格公式那样,通过重新运行来证明一个数字。
第二,可追溯性。因为计算是在一个已核对的模型上运行的,每一个输出都能指回产生它的源头行。审计师问“这个数字是哪来的”,得到的是一条完整的血缘链路,而不是一句耸肩。
第三,一个站得住脚的自主性边界。一旦数学计算离开了模型,你就可以放心地让智能体做更多事而不必因此夜不能寐。这是自主层级的前提条件,后者决定一个智能体可以独立运行哪些工作流,也正是这一点让治理型自主比在每一笔交易中都塞进一个人更安全。你无法治理一个连数字都无法复现的智能体。
结论
一个自己做计算的 LLM,是在猜测一个数字大致的样子。一个在已核对的模型上调用工具的 LLM,是让算术去做算术,让语言留给语言。前者在演示中让人惊艳,却在审计中失效;后者显得平平无奇,而平平无奇正是你希望藏在一份董事会材料底下的东西。
如果你正在评估智能体式财务工具,不妨问供应商一个问题:是模型自己计算这个数字,还是它调用了某个确定性的东西来计算?如果他们无法干净利落地回答,那么这个数学结果就是一个猜测。预约演示,我们会用你自己的数字向你展示这个区别。