为什么 OLAP 多维立方体是财务 AI 的错误基础

多维立方体是经典企业绩效管理背后那匹默默拉车的马。TM1(现称 Planning Analytics)、Jedox、Board,以及各类 Hyperblock 式引擎，都建立在同一个理念上:把业务建模为相互交叉的维度(科目、实体、期间、情景、产品),让用户在点击的一瞬间就能在数十亿个单元格中自如透视。三十年来，这一直是正确的取舍。当一位计划人员在会议中需要按地区、按月查看营收，并从四个不同角度切片时，立方体能瞬间给出答案，而关系型查询只会慢吞吞地爬行。

因此，当团队想把 AI 助手接入自己的 EPM 技术栈时，立方体似乎是理所当然的接入点。它已经是“唯一的数字来源”,已经很快。问题在于，为了获得这种速度，立方体悄悄丢弃了什么。立方体存储的是答案，而不是得出答案的推理过程。而一个基于存储答案进行推理的 AI,继承了在问题被提出之前很久就已经写死的每一个聚合和映射决策，却没有任何办法回溯到能够证实或证伪它的交易本身。

立方体存储的是结论，而不是证据

OLAP 的核心动作是预聚合。原始交易沿着维度层级被汇总(数千条总账过账记录合并成一个“EMEA / Q2 / 净营收”单元格),因为预先计算这些汇总恰恰是让透视变得瞬时的原因。而这种汇总是一条单向道路。一旦过账记录被汇总进一个单元格，该单元格就不再记得自己来自哪些过账记录。它是一个抛弃了证据的结论。

对于立方体本来要完成的工作来说，这不仅可以接受，甚至是理想的。没有人在浏览差异报告时想要拖动一千万条日记账明细。但这也意味着，立方体在结构上恰恰是财务 AI 真正必须回答的那个问题的错误形态:“这个数字是从哪里来的？”立方体能给出的诚实答案是“它下方那些单元格的总和”,而这本身又是一组结论，而不是证据。你可以沿着层级一路下钻，直到触及所存储的最底层，然后就到头了。在那个层级之下，在总账里，才是审计轨迹真正所在之处，而立方体没有指向那里的指针。

映射过程是不可见的,AI 也同样看不见

把数据载入立方体不是一次复制，而是一次翻译。加载流程把源科目映射到立方体科目，应用正负号翻转、货币折算、公司间抵消以及分摊规则，然后把结果写入单元格。每一步转换都是一个建模决策，而其中大部分都存在于加载脚本、TurboIntegrator 流程或规则文件之中，立方体本身并不会把它们作为数据暴露出来。

查询立方体的 AI 看到的是那次翻译的输出结果，却没有附带翻译过程本身。问它营销支出为什么上涨，它会老老实实地报告那个单元格的数字。但它无法告诉你，这个上涨究竟是真实的，还是上季度有人改动了分摊基础所致，因为这个事实从来没有进入过立方体，它存在于喂养立方体的流程里。这与电子表格是错误基础所遇到的失败问题相同，只是走了一条不同的路。表格隐藏了总账数字和手工改写数字之间的差异;立方体隐藏了原始数字和经过转换的数字之间的差异。在这两种情况下，模型读到的都是一个语气自信、却被剥去了来源信息的数字。

“追溯这个数字”最终止步于一个单元格

把这两个问题合在一起，就是 AI 面临的核心缺陷。一个基于检索的助手，其可信度上限就是它所能引用的来源。而当来源是一个立方体时，能拿到的最好的引用不过是一个坐标，一个位于一组维度之内的单元格地址。

CFO 提出的问题	立方体能返回什么	缺少什么
EMEA 第二季度净营收是多少？	立即返回单元格数值	没有缺失，这正是立方体的强项
哪些交易构成了这个数字？	下一层的子单元格	缺少交易明细;下钻止步于所存储的最底层
为什么它相对预测发生了变动？	两个单元格及其差值	缺少驱动因子;差值只是算术结果，不是解释
证明这个数字与总账相符	一个汇总总数	缺少能够证明这一点的映射关系和源头过账记录

最后一行才是关键所在。一个单元格坐标不是审计师会接受的引用。它说的是“这个数字在模型里位于何处”,而不是“这个数字在现实中是从哪里来的”。追溯止步于一个单元格，而一个止步于单元格的 AI 答案是一种主张，而不是一个站得住脚的事实。这就是为什么把语言模型直接接到 EPM 立方体上(许多“AI 原生规划”所许下的承诺)只是改善了交互界面，却没有触及信任问题。检索的依据本身就是一个无法被追溯的来源。

快，不等于扎实可靠

这一切并不意味着立方体是糟糕的技术。它们在聚合性能、稀疏存储，以及让人交互式地探索大型模型方面，确实非常出色。如果你唯一的需求是对已经被信任的数字进行快速切片切块，立方体很难被超越，而Board和Jedox这类工具正是擅长于此。

真正的错误在于，把“查询速度快”当成隐含着“可以安全地供 AI 推理和引用”。这是两种不同的属性。立方体通过预先固定一组聚合和映射来优化检索速度;而 AI 的可信度需要的恰恰相反，即能够按需把任何一个数字分解回源头，包括那些被立方体刻意压缩掉的事实。你无法从一个为了速度而被设计成丢弃血缘信息的结构中，再把血缘信息找回来。事后补上的下钻路径，只能到达有人事先预先配置好的那些特定单元格所对应的总账，这不是通用的血缘追溯,AI 也不能假设它一定存在。

一个可供引用的基础应该是什么样子

解决方案与电子表格那个案例的思路相似:把真相来源下移到查询层之下，进入一个每一个数字都保留着与产生它的交易之间关联的模型。Rexfin 通过直接连接到数字真正所在的地方来构建这个模型，包括会计系统、银行、数据仓库，或上传的报表文件，并把它们对账合并进一个能够与总账核对一致的单一模型。立方体埋藏在加载脚本中的那些转换(映射、抵消、分摊)会成为模型所记录血缘的一部分，而不再是一个不可见的预处理步骤。这与正确的财务合并背后的原则是一致的:模型必须知道自己是如何被搭建出来的，而不仅仅是它得出了什么结论。

聚合依然会发生，你依然希望能够即时按地区、按月查看营收。区别在于，每一个聚合结果都携带一个指向其下方过账记录和规则的指针，并且进行运算的是一个确定性引擎，而不是模型自己的算术推断。因此，当 AI 给出答案时，它是从已对账模型中检索出来的，并能连同追溯链一起返回该数字:相关规则、源头行项目，以及审计师会走的那条路径。立方体给你的是一个坐标。已对账模型给你的是一份引用。

结论

OLAP 立方体凭借在切片切块上的速度赢得了自己的位置，它也应该继续保有这个位置。但它是靠存储结论、丢弃证据换来这种速度的，而 AI 只能引用其来源所保留下来的内容。把模型指向一个立方体,“追溯这个数字”就止步于一个单元格，那是一个位置，不是一个来源。真正能从财务 AI 那里得到站得住脚答案的团队，靠的不是查询一个更快的立方体，而是在底层放置一个已对账模型，让每一个数字都能追溯回总账，并让 AI 既能给出答案,又能展示推导过程。

关于完整图景，请从面向 AI 的可靠财务建模层这个支柱页面开始了解。想亲眼看看它如何将你自己的数字追溯回来源，欢迎预约演示。