返回

H6.ai 如何用 Lakebase Postgres 构建 AI 财务自动化

RSS Databricks Blog AI 逐段翻译 发布 2026-11-13 00:56

有效阅读仅保存在当前浏览器,用于「为你」推荐;暂停或清除记录。

DataHot 速览

H6.ai 在客户现有 ERP 之上自动化应付账款流程,读取发票、匹配采购订单、分配科目并按企业政策校验。由于客户数据持续变动,回归测试难以判断结果变化来自代码还是数据。团队采用存储计算分离、支持分支的 Lakebase Postgres,为每个客户建立独立数据库,并通过分支冻结时点快照、隔离差异排查。

为什么值得关注:展示了 AI 财务自动化产品如何用 Lakebase 的分支和隔离能力解决数据漂移下的回归测试与多租户治理问题,对做 AI 数据平台与 Agent 落地的团队有直接参考价值。

本文目录 6 节
  1. 挑战:财务数据从不静止
  2. 解决方案:Lakebase 架构
  3. 发票处理测试如何运行
  4. 保护财务数据
  5. 超越通过或失败的 AI 测试
  6. 每一张不寻常的发票都会成为一项回归测试

译文

AI 逐段翻译

传统的应付账款和发票处理工具往往迫使公司做出取舍:要么借助 AI 自动化快速推进,却面临失去控制的风险;要么维持繁琐的人工审核。H6.ai正是为解决这一问题而创立。

H6.ai 在公司现有 ERP 之上实现应付账款自动化。它读取每张发票,将其与采购订单匹配,把发票行分配到正确的科目,并依据公司自身的政策进行检查。我们的方法将 AI 辅助理解与经过批准的、确定性的、可审计的政策执行相结合。我们的挑战在于找到一个能够在规模化场景下支持频繁回归测试的后端解决方案。

挑战:财务数据从不静止

在这个行业里,没有两个客户是相同的。每个客户都有自己的 ERP、供应商、采购订单、会计科目表和政策。发票的范围从单行服务账单到包含数百行的文档不等。

而且数据一直在变化。上午 10 点,一张发票匹配到一个剩余数量充足的未结采购订单。到了下午,该订单可能已被部分消耗、修改或关闭。再次处理同一张发票,结果就会改变,尽管我们的代码并未改变。

这使得回归测试变得困难。当结果发生变化时,我们需要知道是我们的改动导致了变化,还是客户的数据导致了变化。

解决方案:Lakebase 架构

我们的工程团队需要一个可扩展的解决方案,能够隔离客户数据并让我们调查错误。在了解到 Lakebase 架构 之后,该架构将存储与计算分离、可将空闲计算缩减至零并支持分支,我们选择它作为平台的核心记录系统。

如今,每个 H6.ai 客户都有一个专用的 Lakebase Postgres 数据库。它保存客户的完整财务上下文:从 ERP 同步的采购订单和供应商、会计科目表和维度、历史交易以及他们的 H6 政策。每个客户一个数据库,使每个客户的数据保持隔离。

它还允许我们冻结快照。Lakebase 分支是数据库在某一时间点的写时复制副本。创建分支不会复制任何数据:分支与其父级共享存储,只存储在其上发生的变化。

当我们发现 H6 处理错误的发票时,我们会为该客户的数据库创建分支,并将该分支保留为快照。在快照中,原本未结的采购订单保持未结状态,剩余数量和价格不变,即使 ERP 已将其关闭。供应商、科目、维度、历史记录和政策设置也是如此。我们不再尝试重建问题背后的条件。我们将它们保留下来。

阴影带中的每个方框都是同一客户数据库的一个分支。测试框架对实时数据库分支一次以拍摄快照,并且从不向其写入。测试写入的所有内容都留在其各自的运行分支上,并随该分支一起删除。

发票处理测试如何运行

我们测试框架中的每个测试用例将一张发票与一个快照以及我们预期的结果配对:它应匹配哪个采购订单、其各行应属于哪些科目,以及它是否应被保留待审核。一次运行包含四个步骤:

  1. 将快照更新至最新状态。我们的数据库模式不断演进,因此几个月前拍摄的快照会落后于被测代码。我们对快照分支一次,将当前迁移应用到该分支,并在同一代码版本的每次运行中复用它。我们迁移一次,多次分叉。快照本身永远不会被更改。
  2. 分叉一个运行分支。每次运行都会获得该最新副本的一个独立的短生命周期分支。
  3. 真实地处理发票。我们流水线的候选版本读写运行分支,就像它是客户的数据库一样。它完全按照生产环境中的方式提取、匹配、分类和验证原始发票文件。
  4. 评判结果并删除分支。我们将流水线的实际行为与预期进行比较,然后删除运行分支。快照保持原样,准备迎接下一次运行。

一个测试计划可以混合来自许多客户、ERP 和发票格式的用例,每个用例都针对其各自保留的数据库运行。由于每次运行都从相同的冻结状态开始,同一个测试在今天、下周和下一季度都会给出相同的起点。

保护财务数据

我们不会模拟数据库或流水线。隔离承担了这项工作。测试写入的所有内容(审核项、验证结果、草稿文档)都落在运行分支上,并随该分支一起删除。测试永远不会过账到客户的 ERP,实时数据库也永远不会被写入。

这对财务平台很重要。我们可以使用生产环境所用的相同代码路径,针对生产客户数据的副本进行测试,同时客户的账目保持不变。分支管理使用具有最小权限访问的专用服务主体,分支保护机制拒绝触碰客户的实时分支。

超越通过或失败的 AI 测试

检查发票是否已被处理是不够的。一张发票可能被完美读取,却仍被匹配到错误的采购订单、分配到错误的科目,或在违反客户政策的情况下被处理。

因此,每次运行都从两个方面进行评判:

  • 确定性断言检查我们能够精确陈述的事实,例如文档的最终状态、它匹配的采购订单和总计。
  • 一个由来自不同提供商的模型构建的 AI 评审小组,根据预期结果审查完整结果,并返回通过、失败或不确定,同时附上其推理过程。

它们共同告诉我们结果是否正确,而不仅仅是处理是否完成。这让我们能够尝试新模型、改进提取、降低成本并更改我们的匹配和政策引擎,并在真实客户案例上的回归到达生产环境之前发现它。

每一张不寻常的发票都会成为一项回归测试

我们不会修复一个问题后就继续前进。我们将其数据库状态保留为快照,加入发票和预期结果,它就成为一个永久测试用例。随着我们接入更多客户、ERP和发票格式,测试覆盖率随着我们所服务企业的复杂性而增长。

Lakebase Postgres为我们提供了四项我们依赖的能力:

  • 隔离性:每个客户一个数据库,正如多租户金融平台所需要的那样。
  • 冻结状态:分支会保留问题背后的确切财务画面,无论此后实时数据发生多大变化。
  • 廉价、可丢弃的副本:写时复制分支让每次运行都从干净、相同的状态开始,并在之后被丢弃。
  • 模式安全的回放:旧快照可以在其自己的分支上向前迁移,因此随着我们代码的演进,它仍然可用。

对于H6.ai来说,Lakebase的数据库分支不仅仅是基础设施层面的便利。它正是我们构建客户可以信任的AI驱动财务自动化的方式。

未来,我们期待利用Lakebase表上的Lakehouse//RT查询,这将使我们能够在Lakebase上运行只读分析查询而无需复制数据。这将使我们无需管道即可获得新鲜的分析结果。

如果您想了解更多关于我们在H6.ai正在构建的内容,请访问我们的网站。如果您想了解更多关于Lakebase Postgres数据库分支的信息,请观看这个视频。

这篇内容对你有用吗?

反馈只用于改善内容筛选,不等同于收藏

分享这条资讯
分享海报
保存图片
iOS 也可以长按图片保存