上交大与清华等突破：AI实现数据库自动技能扩展准确率提升突破

这项由上海交通大学主导联合清华大学、新加坡国立大学以及蚂蚁集团共同开展的研究发表于2026年6月的ACM数据管理顶级期刊《Proceedings of the ACM on Management of Data》第4卷第3期SIGMOD 2026论文编号为Article 141DOI为10.1145/3802018。数据库是现代软件世界的粮仓。银行记录你的每一笔转账医院存储你的每一次就诊电商平台追踪你的每一个订单背后都有数据库在默默运转。而数据库里有一种东西叫原生函数——你可以把它理解成数据库内置的小工具箱里面装满了各种预先写好的功能算平方根、截断时间戳、拼接字符串、处理JSON格式数据……程序员只需呼唤一声比如写下date_trunc(hour, timestamp 2001-02-16 20:38:40)数据库就乖乖把时间精确到小时返回2001-02-16 20:00:00。这些小工具的数量这些年一直在飞速增长。以PostgreSQL为例从2018年的237个函数到2026年的630个翻了将近三倍DuckDB从60个涨到666个SQLite也从52个攀升到143个。驱动这场增长的是不断涌现的新业务需求——比如企业要把Oracle数据库迁移到PostgreSQL就得把那些Oracle独有的功能一一在新系统里重新实现这项工作占到整个迁移预算的30%到60%平均每一千行代码需要花费40到80个小时。问题在于给数据库手写这些原生函数极其困难。PostgreSQL的原生函数相关代码光是两跳以内的依赖就超过11万9千行DuckDB的GitHub代码仓库里和函数相关的问题单多达3791条。每写一个新函数开发者需要同时在多个文件里注册、实现、引用内部接口稍有不慎就会酿成编译错误或者逻辑漏洞。这项工作长期依赖资深工程师的经验难以自动化。正是为了解决这个痛点上述研究团队提出了一套名为**DBCooker**的自动化系统——借助大语言模型也就是近年来广为人知的ChatGPT、Claude之类的AI让机器自动完成数据库原生函数的代码合成。实验结果显示DBCooker在SQLite、PostgreSQL和DuckDB三个主流数据库上平均准确率比当前最强的对手包括Anthropic的Claude Code、阿里巴巴的Qwen Code等高出34.55%并且成功为最新版SQLitev3.50添加了四大类此前完全不存在的新函数。---一、为什么让AI写数据库函数这么难要理解DBCooker解决了什么问题先得摸清这件事到底难在哪里。以PostgreSQL里的date_trunc()为例。这个函数的功能听起来简单把一个时间戳截断到指定精度比如截到小时、截到天。但在数据库内部这一个SQL关键字背后对应的是四个不同的底层函数单元处理带时区时间戳的timestamptz_trunc、处理时间间隔的interval_trunc、处理带时区信息的timestamptz_trunc_zone以及一个内部辅助函数timestamptz_trunc_internal。开发者必须把这四个单元分别注册在系统目录文件pg_proc.dat里然后在src/backend/utils/adt/timestamp.c这个源文件里逐一实现它们还要正确引用数十个数据库内部的宏和工具函数比如用PG_GETARG_TEXT_PP()获取输入参数用PG_RETURN_TIMESTAMPTZ()格式化输出结果。假如不借助这些现成的内部工具从零实现date_trunc()需要6235行代码涉及225个函数而借助这些工具只需要315行。节省了94.95%的代码量。这说明正确识别和复用数据库内部的参考函数单元是整件事的核心难点之一。研究团队通过大量观察总结出了三个主要障碍。第一个障碍是一对多的映射。一个SQL层面的函数在数据库内核里往往对应多个分工不同的底层单元而且这种映射关系深埋在代码仓库的隐式约定里没有明确文档全靠经验。第二个障碍是海量引用中的精准寻找。数据库代码仓库极其庞大以SQLite为例每个文件平均有2619个可引用的函数和宏但一个原生函数真正需要用到的平均只有13.73个。在这片汪洋大海里找到那十几颗关键的明珠对AI来说并不容易。第三个障碍是千人千面的复杂度。有些函数比如sqrt()本质上就是套一个标准数学库实现极简有些函数比如json_agg()需要从头构建复杂的聚合逻辑代码量可能是前者的数十倍。用一套固定流程统一对待它们必然顾此失彼。现有的AI代码生成工具包括著名的Claude Code和Qwen Code在面对这三个障碍时都暴露出明显短板。研究团队做过统计Claude Code在合成数据库函数时有63.70%的操作时间花在了搜索仓库和读取文件上真正用于生成代码的时间只占4.95%。换句话说它把大部分精力用来在浩如烟海的代码文件里找方向而不是实实在在地写代码。与此同时这些通用AI工具产生的错误里有81.76%属于声明错误——要么把函数注册在了错误的地方要么引用了根本不存在的内部接口。这就是DBCooker要攻克的战场。---二、DBCooker的烹饪哲学先备料再按方煮最后严格验收研究团队把这套系统命名为DBCooker这个名字颇有意思——数据库DB加烹饪者Cooker。确实整套系统的逻辑像极了一个专业厨师的工作方式先弄清楚这道菜的配方和所需食材函数特征化再按照菜谱一步步下厨函数合成操作最后对成品进行严格的口味检验代码验证而且整个流程会根据菜肴的复杂程度灵活调整自适应工具编排。整个系统由三大模块构成彼此紧密协作。第一大模块叫做函数特征化负责在开始写代码之前把一个SQL函数需要的所有关键信息摸清楚——就像厨师在下锅前必须先备好料。这个模块从两条路径汇集信息一条是解析数据库官方文档提取函数的文字描述和使用示例另一条是查询数据库系统目录比如PostgreSQL的pg_proc.dat获取精确的函数签名、参数类型、返回类型等代码层面的声明。把这两路信息合并成统一的JSON格式就得到了一份完整的函数档案。备好基础资料之后这个模块还要做一件更精细的工作在代码仓库里把这个SQL函数背后所有需要实现的底层单元一一识别出来。系统采用了一种图遍历的方法——把代码仓库里函数之间的调用关系想象成一张地铁线路图从SQL关键字这个起始站出发沿着调用关系一站一站往下走把所有相关的底层函数单元都找出来同时把那些全局通用、并非这个函数专属的单元排除掉。找到所有相关单元之后系统还会对同一类别的函数比如所有处理时间的函数做成对比较把两个同类函数的代码对齐找出它们共同的固定部分和各自不同的变化部分把固定部分提炼为可复用的模板把变化部分标记为需要填写的空格。这套找相同、标差异的逻辑为后续的代码生成奠定了基础。第二大模块叫做函数合成操作负责真正把代码写出来——也就是那位厨师实际下厨炒菜的过程。这个模块包含三个递进的环节。第一个环节是伪代码计划生成。在真正写代码之前系统先让AI生成一份详细的实现方案——不是真正的代码而是一份像施工图纸一样的骨架标明每个底层单元放在哪个文件里每个单元内部分几个代码块每个代码块大概要用哪些内部接口。这就好比厨师在下锅之前先在脑海里过一遍第一步加盐、第二步翻炒、第三步收汁的流程。为了确保这份计划的质量系统会同时生成多份候选计划然后用一个评分公式筛选出最好的那份。评分考虑两个维度一是可信度即计划里列出的引用接口实际存在、文件路径实际正确的比例二是简洁性即计划列出的函数单元数量不要过于冗余。两个维度加权平均得分低于门槛的计划直接淘汰。第二个环节是填空式代码合成。有了计划骨架之后实际写代码的过程被设计成填空题而非作文题。系统从同类函数里提取那些带有空格标记的模板把固定部分直接复用让AI只专注于填写那些真正需要创新的、因函数而异的逻辑。这样一来AI的注意力被精准引导到最关键的地方而不是从头写起、容易在细节上出错。为了进一步提高质量系统会同时生成多个候选实现然后用少数服从多数的投票策略选出出现频率最高的方案作为最终代码。此外这个环节还设计了一个自动降级机制。假如填空模板的质量不够好或者多次生成的代码都以失败告终系统会逐步降低对模板的依赖程度——就像一道复杂的菜谱执行失败几次之后厨师会选择放弃照着菜谱做、转而凭自己的经验自由发挥。降级的速度由一个衰减参数控制失败次数越多越快切换到完全自由生成的模式。第三个环节是三阶段代码验证。代码写完之后要经历三关考核才算真正合格。第一关是语法检查用ANTLR这类专业的语法解析工具确认代码本身没有拼写错误、括号缺漏之类的低级问题。第二关是合规检查直接调用数据库的编译工具比如PostgreSQL的make install验证代码能否顺利编译并集成到数据库里。第三关是语义验证让AI自动生成一批测试用例——覆盖各种输入类型、边界情况和异常情况——然后实际运行这些测试检查函数的输出结果是否符合预期。三关里任何一关不过系统都会把错误信息反馈给AI让它修改代码直到全部通过为止。第三大模块叫做自适应工具编排负责把前两个模块里的所有操作智能地串联起来——这就像那位厨师的工作节奏管理根据今天要做的菜有多复杂灵活决定先做什么、后做什么。系统把每一个可用的操作生成计划、写代码、检查语法、编译验证……都包装成一个标准化的工具然后由一个AI控制器实时决定下一步调用哪个工具。这个控制器不是盲目决策的它会参考一个历史经验库——记录了过去合成类似函数时用过的操作序列包括哪些函数只需要简单几步就搞定了哪些函数需要反复迭代。每次遇到新函数控制器会从历史库里找出同类别的参考案例综合参考最省事的做法、最费劲的做法和中间水平的做法再结合当前的实时状态动态决定接下来的行动。这种设计避免了一刀切——简单函数不会被迫走冗长的流程复杂函数也不会因流程太短而留下隐患。---三、实验室里的成绩单数据说话为了检验DBCooker的实际效果研究团队在SQLite、PostgreSQL和DuckDB三个主流数据库上进行了全面测试分别测试了75、145和128个函数涵盖数学函数、日期函数、字符串函数、JSON函数等多个类别并设置了不同复杂度的函数样本。与之对比的方法涵盖了目前最强的竞争者直接用GPT-5、Claude Opus 4.1、Claude Sonnet 4.5、Qwen3 Coder Plus等大语言模型生成代码在大语言模型基础上增加代码检索增强CodeRAG的版本以及Claude Code、Qwen Code、TRAESWE-bench排行榜第一名等专业代码智能体系统。评估指标分两层一是合规准确率即生成的代码能成功编译并集成到数据库的比例二是结果准确率即生成的代码不仅能编译还能在所有测试用例上输出正确结果的比例。DBCooker在两项指标上都大幅领先。综合三个数据库合规准确率达到78.90%结果准确率达到65.19%分别比其他方法的平均水平高出124.37%和149.68%。换句话说DBCooker在正确率上大约是竞争对手平均水平的两倍以上。按函数难度分层来看DBCooker的优势在难度较高的函数上尤为明显。对于简单函数各方法差距相对较小DBCooker的合规准确率达到78.44%但对于困难函数其他方法的平均合规准确率只有约22%而DBCooker仍然保持在68.97%差距达到197.10%。这说明随着函数复杂度的增加那些通用AI工具的能力急剧退化而DBCooker的专项设计使它在复杂场景下依然保持稳定。按函数类别来看DBCooker在四大类PostgreSQL函数数学、日期、字符串、JSON上的合规准确率从89.19%到96.67%不等整体稳定且均匀比其他方法的平均水平高出151.11%。相比之下竞争对手在不同类别上的表现参差不齐尤其在数学函数这类看起来简单实则充满底层细节的函数上大多数LLM方法合规准确率仅有6.67%到16.67%。研究团队还做了一个有趣的补充实验把正确的文件路径、函数声明和引用接口全部提前告诉那些竞争对手相当于把所有食材都备好放在桌上看看它们在彻底消除文件搜索障碍之后能达到什么水平。结果是即便如此这些竞争对手的准确率仍然比DBCooker低22.56%。这说明数据库原生函数合成的难点不仅仅在于找到正确的文件更在于生成符合数据库内核规范的代码本身——而这正是DBCooker通过三阶段验证和伪代码计划所着力解决的。错误分布的分析同样印证了这一点。通用LLM方法产生的错误以声明错误为主占到所有错误的约82%Claude Code这类智能体工具虽然搜索能力更强能主动验证声明位置但生成的代码仍然频繁出现引用不存在接口的问题DBCooker则通过函数特征化和三阶段验证把各类错误压到了最低水平。---四、消融实验每个零件都不能少为了验证系统各模块的贡献研究团队做了拆零件实验——每次去掉一个模块看看准确率如何变化。去掉函数特征化模块即不再预先提取函数的声明信息和参考函数单元时三个数据库上的合规准确率分别从81.33%、78.62%、83.67%下降到68.0%、31.25%、44.90%。尤其PostgreSQL的降幅最大说明对于结构复杂的数据库预先理解函数组成至关重要。去掉三阶段验证模块时PostgreSQL的合规准确率从78.62%骤降至6.9%。这个极端的下降幅度反映了PostgreSQL的内部依赖关系极其复杂没有逐级验证反馈AI生成的代码几乎无法自行收敛到正确状态。单独去掉伪代码计划生成保留三阶段验证时准确率从78.62%下降至37.04%单独去掉三阶段验证保留计划生成时如上所述降至6.9%两者都去掉时则跌至9.66%。这表明计划和验证是相辅相成的——计划帮助AI构建全面的实现蓝图验证帮助AI纠正执行过程中的错误两者缺一不可。去掉自适应工具编排改为固定流程的多LLM协作时三个数据库上的结果准确率从69.33%、58.62%、67.35%分别下降到49.33%、21.19%、30.61%。这说明对于不同复杂度的函数固定流程难以自适应地分配精力而动态编排能有效提升资源利用效率。---五、让SQLite学会它从未会过的新技能除了在已有函数上的测试研究团队还做了一个更有野心的实验把PostgreSQL和DuckDB里有、但SQLite里没有的函数用DBCooker合成到SQLite里。这项工作的难度更高因为不同数据库的内部架构差异极大代码不能直接移植必须从头适配SQLite的内部规范。研究团队共尝试了17个新函数涵盖聚合函数如covar_pop、bool_and、bool_or、日期函数如century、monthname、yearweek、last_day、数值函数如lcm、even、gamma、lgamma、nextafter和字符串函数如left、regexp_split_to_array、repeat、to_hex、translate。DBCooker成功合成了全部17个新函数而Claude Code合成了其中12个TRAE合成了12个Qwen Code只合成了7个。有几个函数三个竞争对手都无法合成只有DBCooker成功包括century、monthname、even、gamma、lgamma、nextafter和translate。以covar_pop计算协方差的聚合函数为例DBCooker正确识别出它需要三个底层单元covarPopStep逐行累加中间结果、covarPopFinalize计算最终协方差值和covarPopInverse用于窗口函数的逆运算并把这三个单元用SQLite专属的宏WAGGREGATE正确注册在src/func.c文件里使得用户可以直接执行SELECT covar_pop(...)。Qwen Code则虽然正确注册了声明但没有实现covarPopInverse导致编译时报错WAGGREGATE宏中xInverse未声明。以regexp_split_to_array用正则表达式分割字符串为数组为例DBCooker正确使用了SQLite内部的sqlite3_value_text和sqlite3_str_new等引用接口而其他三个方法则尝试引用外部文件sqlite3re.c里的sqlite3re_compile和sqlite3re_match这两个接口在SQLite标准发行版里根本不存在直接触发合规错误。---六、和其他相关工作的区别在哪里这项研究和几个相邻领域的工作之间边界是清晰的值得简单梳理一下。通用代码生成领域涵盖Codex、GitHub Copilot这类提示词驱动的方法Claude Code、SWE-Dev这类智能体驱动的方法以及Code Llama、WizardCoder这类训练驱动的方法。它们都是面向通用代码仓库设计的缺少对数据库内核架构的针对性理解在数据库原生函数这个专项任务上效果有限——这一点已经被实验结果充分验证。用户自定义函数UDF优化领域代表性工作包括微软的Froid把命令式UDF转换为关系代数表达式以提升执行效率和Tuplex把Python UDF编译为原生机器码。这些工作聚焦的是如何让已有的函数跑得更快而不是如何从零合成一个新函数并集成进数据库内核和DBCooker的目标完全不同。运行时代码生成领域代表性工作包括HyPer把查询计划编译为LLVM机器码和Weld为跨库数据分析流程生成优化的并行代码。这些工作生成的代码是临时性的、面向单次查询执行的而DBCooker合成的是持久性的、作为数据库内核一部分的原生函数。数据库迁移领域代表性工作包括CrackSQL用LLM实现不同SQL方言之间的翻译和PARROT跨系统SQL翻译的评测基准。这些工作处理的是SQL语句的表层语法转换而DBCooker处理的是函数在数据库内核层面的重新实现两者粒度和难度都不在同一层次。---七、展望这套系统未来面对哪些挑战研究团队在论文中坦诚地指出了三个值得持续关注的深层挑战。第一个挑战是代码库的碎片化与长上下文推理的矛盾。PostgreSQL的源代码超过一百万行而且声明和实现往往分散在不同文件里比如pg_proc.dat里是声明src/func.c里是实现。即便未来的AI模型能够处理超长上下文把整个代码库一股脑塞进去也会带来高昂的推理成本而且AI很可能在信息量过大的时候迷失方向、遗漏关键细节。DBCooker通过函数特征化提前精准定位相关内容是解决这一矛盾的有效路径。第二个挑战是数据库的确定性正确性要求与AI的概率性生成本质之间的矛盾。数据库函数必须在所有情况下都输出正确结果没有大体上正确这一说。而AI生成内容的本质是概率性的无法从根本上保证精确正确。DBCooker通过外部强制执行的伪代码计划和三阶段渐进验证把概率性输出转化为可验证的正确实现是应对这一矛盾的关键机制。第三个挑战是数据库版本迭代与AI训练数据滞后之间的矛盾。数据库函数的签名、内部宏的用法、系统目录的结构会随版本更新而变化。AI模型训练时接触的是历史数据难以跟上最新版本的变化甚至可能把旧版本的写法带入新版本的代码里造成隐蔽的错误。DBCooker通过动态检索当前版本的实现惯例并用自适应工具编排加以强制执行使系统能够直接适应版本变化而无需重新训练模型。---说到底DBCooker做的事情本质上是在为一项长期靠人工经验维系的高难度工作设计了一套有章法、有记忆、能自我纠错的自动化流程。它并不是简单地把让AI写代码这件事重复一遍而是针对数据库原生函数这个具体场景把函数的结构分析、模板复用、分层验证和历史经验融合为一个有机整体。对于数据库开发者和企业IT团队而言这意味着那些长达数月的数据库迁移项目其中最耗时的函数重实现部分未来或许能够得到切实的自动化支持而不再只是AI能帮我搜索一些参考代码这种程度的辅助。对于更广泛的软件工程领域而言这项工作也提示了一个值得关注的方向面对高度结构化、规范严格、内部依赖复杂的特定代码合成任务专项化的设计比通用方法有着相当明显的优势空间。有兴趣深入了解技术细节的读者可以通过DOI 10.1145/3802018查阅完整论文也可以访问GitHub上的开源代码库 weAIDB/DBCooker复现实验或在自己的数据库项目中尝试应用。---QAQ1DBCooker和Claude Code这类AI编程工具相比核心区别是什么AClaude Code是通用代码智能体遇到数据库原生函数合成任务时会花大量时间在代码仓库里盲目搜索文件真正用于写代码的时间只有不到5%而且不了解数据库内部的注册规范经常把函数声明放错地方或者引用根本不存在的内部接口。DBCooker则是专门针对数据库原生函数设计的它预先分析清楚每个函数对应哪些底层单元、这些单元应该放在哪里、应该引用哪些内部接口然后按照数据库内核的规范逐步生成和验证代码把错误率压到了Claude Code的三分之一以下。Q2DBCooker的三阶段代码验证具体是怎么工作的A三阶段验证是从浅到深的三关考核。第一关是语法检查用专业的语法解析工具ANTLR扫描生成的代码排除括号不配对、变量未声明之类的低级语法错误。第二关是合规检查直接调用数据库自身的编译工具比如PostgreSQL的make install命令看代码能否真正编译并集成进数据库这一关能发现函数注册位置不对、引用接口不存在等深层问题。第三关是语义验证让AI自动生成覆盖各种输入类型和边界情况的SQL测试用例实际运行后检查输出结果是否符合预期这一关专门针对代码能跑但结果不对的情况。三关都通过才算合格任何一关失败都会把错误反馈给AI让它修改。Q3DBCooker能用来给任意数据库添加新函数吗有什么限制A目前DBCooker已经在SQLite、PostgreSQL和DuckDB三个主流数据库上经过了系统验证能够处理数学、日期、字符串、JSON等多个类别的函数包括从其他数据库移植全新函数。主要的限制在于DBCooker的函数特征化模块需要访问目标数据库的代码仓库和系统目录对于闭源数据库或内部结构没有文档化的系统适用性会受限。此外对于极端复杂的函数比如涉及几百个底层依赖的聚合函数当前版本的成功率仍然低于理想水平这也是研究团队正在持续改进的方向。