财务自动化公司 H6.ai：用数据库分支冻结真实发票状态，多模型裁判回归测试 AI 管线
H6.ai 工程团队 Benji Borg 和 Mauro Pirrone 描述了他们在 AI 驱动的应付账款自动化平台上如何利用 Lakebase Postgres 的 copy-on-write 分支解决回归测试难题：财务数据持续变动导致同一发票在不同时刻处理结果不同，传统方法无法区分是代码改动还是数据变化引起的差异。他们的做法是为每个客户保留冻结的数据库快照，在快照分支上完成 schema 迁移后分叉出一次性运行分支，让候选管线在真实数据上完整执行，最后由确定性断言和跨提供商 AI 裁判面板共同判定结果。
做 AI 驱动的应付账款自动化，最棘手的测试问题不是代码逻辑本身，而是数据在动。H6.ai 的两位工程师 Benji Borg 和 Mauro Pirrone 在 Databricks 官方博客中描述了这一困境：一张发票在上午十点能匹配到一张还有剩余数量的采购订单，到下午那张订单可能已被部分消耗、修改或关闭。同一张发票、同一套代码，结果却变了。当回归测试显示差异时，团队无法判断是代码改动引起的还是客户数据自然变化引起的。
他们的解法不是合成数据或静态夹具，而是保留真实状态。H6.ai 为每个客户运行一个独立的 Lakebase Postgres 数据库，存放从 ERP 同步的采购订单、供应商、科目表、历史交易和客户自定义政策。当发现某张发票处理有误时，团队对该客户数据库创建一个 copy-on-write 分支作为快照。分支不复制任何数据，只与父数据库共享存储，仅记录分支上新产生的变化。快照中那张采购订单保持打开状态，剩余数量和价格不变，即使 ERP 里早已关闭。
测试运行分四步。第一步，把快照迁移到当前 schema：团队对快照分支应用最新数据库迁移，然后复用这个已迁移的分支作为所有运行的起点——迁移一次，分叉多次，快照本身永远不改。第二步，每次运行从已迁移分支再分叉一个短生命周期的运行分支。第三步，候选版本的管线像操作客户真实数据库一样读写这个运行分支，完整执行提取、匹配、分类和校验。第四步，判定结果后删除运行分支，快照保持原样等待下一次运行。
判定环节是这篇描述中最值得注意的部分。H6.ai 不只检查发票是否处理完成，而是用两套机制评估结果是否正确。确定性断言检查可以精确陈述的事实：文档最终状态、匹配到哪张采购订单、总金额。跨不同模型提供商的 AI 裁判面板审查完整输出与预期结果的语义一致性，返回通过、不通过或无法确定，并附带推理过程。两套机制合在一起回答的是结果对不对，而不只是流程跑完了没有。
这套模式的可迁移性在于：任何 AI 管线如果依赖持续变化的真实数据做提取、匹配或分类决策，都面临同样的回归测试困境。冻结状态加一次性分支的思路把问题从重建条件变为保留条件。H6.ai 还把每张异常发票变成永久测试用例——修复问题后保留其数据库快照、发票文件和预期结果，随着客户和发票格式增多，测试覆盖面自然扩展。
需要保留的边界：这是 Databricks 作为 Lakebase 产品厂商发布的客户工程博客，H6.ai 团队描述的是自身实践。架构细节绑定 Lakebase 的具体产品能力，多模型裁判面板的判定一致性和准确率未给出量化数据，整体效果为自述而非独立基准。
但方法论层面的贡献是清楚的：当 AI 系统的正确性取决于它对真实上下文的处理而非孤立代码逻辑时，测试环境需要保留上下文本身。数据库分支的 copy-on-write 特性让这件事的成本从复制整个生产数据库降到一次元数据操作，使得每次运行都从同一冻结状态出发成为工程上可行的日常实践。