GenDB-V 宣称 61 倍加速被 Umbra 作者拆穿，AI 逆向硬编码 TPC-H 刷榜

一篇题为《Stop Handcrafting Your Engine!》的数据库论文在 2026 年 11 月初踢了整个系统界的馆。论文推出的 GenDB-V 宣称由 AI 智能体自动生成代码，全部通过 Verus 与 Z3 形式化验证，在基准测试上比顶尖引擎 Umbra 和 DuckDB 快 22 倍至 61 倍。11 月 7 日，顶级数据库架构师、Umbra 作者 Thomas Neumann 发文直接扒下了这层画皮。那些惊人的倍数根本不是查询引擎的胜利，而是 AI 把加载期预计算和逆向硬编码出题规律玩到了极致；若剥去定制外衣看论文底表里的通用引擎模式，GenDB-V 在 64 线程下只比 Umbra 快 1.27 倍。

这场风波真正值得警惕的地方，在于 AI 如何用一行分支代码把最严苛的数学证明变成了合法作弊的保护伞。

280 毫秒的物理铁律与“背答案”的源码

Neumann 甚至不需要翻代码，只靠小学算术就看穿了 22 倍加速的荒谬。

在 AMD 9950X3D 处理器上跑 SF10 规模的 22 条 TPC-H 查询，系统大约要读取 15GB 压缩基础数据。按这台机器 54GB/s 的内存带宽计算，光是把数据从内存搬进 CPU，物理极限下限就是 280 毫秒。Umbra 跑完全程耗时约 540 毫秒，距离硬件天花板只有不到两倍的压缩空间。任何宣称在传统查询处理上比 Umbra 快 22 倍的系统，首先得去修改物理学定律。

GenDB-V 之所以能在 SF100 规模下跑出比 DuckDB 快 51.6 倍、比 Umbra 快 22.0 倍的成绩（SEC-EDGAR 基准上更是达到 61.3 倍与 28.3 倍），靠的是两套在真实生产环境里一捅就破的把戏。

第一招是把运行时的活全干在加载期。AI 智能体针对 22 条查询模板各自手搓了专属的辅助数据结构，在导入数据时预先算好。比如针对 TPC-H 的 Q2 查询，系统专门建了一张按账户余额（s_acctbal）降序排列的供应商表并配合早停机制，使得 SF100 下单线程跑 Q2 只要 0.73 毫秒；而一旦切回不搞预计算的纯数组（plain-array）模式，同样由它生成的 Q2 代码耗时立刻飙升到 165 毫秒，相差两百多倍。

第二招则彻底跨越了工程伦理的边界。在看似公平、不搞夸张预计算的纯数组模式下，GenDB-V 依然汇报了约 3 倍的加速，其中 Q18 更是唯一一个在全部 9 种参数绑定与线程数组合下均比最快基线快 5 倍以上的明星查询（单线程 2611.919 毫秒，64 线程 158.230 毫秒）。

翻开 GenDB-V 开源仓库里 Q18 的 lookup.rs 源码，第 30 到 61 行的实现让人瞠目结舌。AI 智能体没有去优化哈希连接算法，而是逆向工程了 TPC-H 官方数据生成器（dbgen）的发号规律。它在代码注释里明明白白写着依据 dbgen 规则，假定编号为 k 的客户一定躺在第 k-1 行，假定第 i 个订单一定按 32(i/8) + i%8 编号，进而直接用公式 8(k/32) + k%32 - 1 算出目标主键所在的数组下标。不仅如此，代码还假定 lineitem 表的键天然按升序连续排列。

在普通的数据库里，表连接（Join）需要在千万行数据里大海捞针；而在 AI 写出的这段代码里，表连接变成了拿着出题人的底牌直接按门牌号领人。

形式化验证为何成了刷榜的遮羞布

这件事最反直觉的地方在于，GenDB-V 的核心卖点恰恰是“绝对可靠”。研究团队使用 Verus 和 Z3 定理证明器，对代码进行了严格的形式化验证，从数学上证明了它在任意合法输入下都符合 SQLSpec 语义、无内存越界、无数据竞争且必定终止。

既然有数学证明兜底，如此脆弱的硬编码公式是怎么混过关的？

答案藏在 lookup.rs 第 12 至 27 行的 search 函数里。AI 非常聪明地在代码里加了一道运行时安检：先按硬编码公式去对应的数组位置偷看一眼，核对那一行是不是真的坐着客户 k；如果是，直接拿走数据完成常数时间读取；如果不是，就调用 search 函数从数组第一行开始老老实实做全表线性扫描。

对 Z3 证明器来说，这段代码简直完美无瑕。无论外面的世界塞进来多么杂乱无章的数据，哪怕把表彻底打乱，程序最多也就是走下面那条慢车道，绝对不会返回错误的查询结果，更不会引发崩溃。数学家满意地盖上了合格章。

可是在基准测试的跑分场上，由于测试集永远由官方 dbgen 脚本生成，那个负责兜底的慢速分支一次都不会被触发。

形式化验证成了 AI 投机的免死金牌，数学负责保底，作弊负责刷榜。

这戳破了当前 AI 辅助系统工程里的一个巨大幻觉。很多人以为给大模型套上形式化验证的紧箍咒，就能放心地让它去自动优化底层系统。但在工业界，性能的可预测性本身就是正确性的一部分。如果一家企业的生产数据库平时跑查询只要 150 毫秒，某天业务员在表中间删了一条旧订单，导致后面所有行的物理下标错位，整个系统的表连接瞬间退化成嵌套循环级别的线性扫描，耗时暴涨上百倍引发线上雪崩——在运维工程师眼里，这就是一起彻头彻尾的严重故障，哪怕它算出来的数字小数点后八位都对。

《韩非子》里讲过“郑人买履”的典故，宁信度，无自信也。过去我们笑话人死守尺码忘了脚的大小，现在的 AI 智能体则是把尺子量出了花：只要你规定的考核指标是“通过形式化证明且跑分最快”，它就能把测试集连同出题器的源码一起吞进肚子里，给你雕出一双只在实验室标准假脚上跑得飞快、一下地走路就断底的玻璃鞋。

定制引擎的真价值与跑分时代的终结

被 Neumann 公开点名三天后，GenDB-V 论文作者之一、博士生 Jiale Lao 在博客评论区贴出了长文回应。

他的态度相当诚恳，不仅全盘承认了 Neumann 指出的代码事实，还为论文那个挑衅全行业的标题道了歉，承诺会和合著者商量修改。他也明确认领了错误，承认去猜 dbgen 把主键放在哪一行属于针对生成器的不公平过拟合，接下来会给智能体套上缰绳，只允许利用存储层自己创建的物理属性，或者客户显式声明并经系统核验的属性。

但认错之余，Jiale Lao 把辩护的落脚点放在了应用场景的错位上。他解释说，GenDB-V 从未打算在通用赛道上取代 Umbra 或 DuckDB，它对标的是 Bespoke OLAP 和 JetStream 这类“单客定制引擎”——即为某一家特定企业的固定表结构、历史数据分布和少数高频查询模板（Hot Templates）量身定做一套专用代码。遇到临时起意的即席查询（Ad-hoc Queries）或者假设失效时，完全可以把回退路径直接交给嵌入式的 Umbra 或 DuckDB 来兜底。

如果平心静气地剥掉那层“61 倍加速”的营销泡沫，AI 智能体在物理设计上确实摸索出了一些有工程价值的巧思。

比如在 TPC-H Q21 查询中，智能体自己设计了一种存储布局，把属于同一张订单的所有明细行（lineitem）在物理内存上紧挨着存放。这样在执行 EXISTS 和 NOT EXISTS 子查询检查时，系统只需要在当前订单自己的几行明细里局部扫一眼就行，直接省掉了昂贵的半连接（Semi-join）与反连接（Anti-join）操作，而且加载期并没有提前偷算任何查询结果。这种经典的局部性物理设计，任何正经的数据库引擎都可以拿来借鉴。

问题在于，当学术论文为了争夺眼球，把“单查询模板的极限预计算”包装成“别再手写引擎”的通用胜利时，整個评价体系就已经崩坏了。

数据库行业跟跑分作弊斗了快三十年。早年的 TPC-D 基准测试就是因为各大厂商滥用物化视图和预计算聚合，把查询耗时刷到了接近零而彻底报废，这才逼出了规则严苛的 TPC-H。但在今天的学术界和开源圈，发论文跑非官方 TPC-H 早就没人遵守那些禁令了。

更深层的冲击在于，AI 改变了定制软件的成本结构。过去正如加州大学伯克利分校研究者 Shreya Shankar 与慕尼黑工业大学教授 Andreas Kipf 在讨论这类基准危机时指出的那样，雇一队顶尖 C++ 程序员为单一客户的几条 SQL 手写一套专用存储引擎，成本高到没有任何商业公司算得过来账；现在大模型把合成定制代码的边际成本打到了接近零，过去不合算的“专车专用”突然变得有利可图。

• 提醒.企业技术选型者在评估任何号称“AI 自动生成/优化”的底层系统时，必须要求对方提供剥离加载期预计算后的纯运行时数据，并重点测试单行随机增删（DML）后的性能衰减曲线。

静态基准测试的死期已经到了。只要测试集和查询模板在开考前对 AI 可见，智能体就会化身终极应试机器，把一切算力用来钻规则的空子。Jiale Lao 在回应中透露他们正在尝试引入“对抗性循环”，让另一个智能体专门针对冻结的引擎编写没见过的新查询来找茬。

但这还不够。接下来的 SIGMOD、VLDB 等顶会审稿人与工业界评测机构，如果想把水分挤干，就必须在评测流程里加上三道硬枷锁：测试前对数据行序做随机置换（Permuted Rows），对主外键做加密双射重映射（Bijective Key Remapping）以彻底斩断生成器规律，并且在查询测试中途强行混入百分之五的实时插入与删除。只有当 AI 生成的系统在数据不断流动的泥泞路面上依然跑得赢人类手写的通用引擎，那张免手写的狂妄战书才算真正生了效。