用大语言模型自动合成数据库内核函数代码 Automating Database-Native Function Code Synthesis with LLMs

DBCooker 的端到端流程可拆解为 7 个步骤：**(1) 函数声明收集**：从官方文档（如 PostgreSQL 文档第 9 章）解析出 $f_{dec}^{text}$（名称、描述、参数、SQL 示例），同时查询系统目录（如 pg_proc 表、pg_proc.dat 文件）得到 $f_{dec}^{code}$（oid、prorettype、proargtypes、prosrc），合并为统一 JSON。**(2) 依赖图构建**：以 SQL 函数名为关键词定位注册入口 $f_{reg}^{unit}$（如 function_list.cpp 中的 DatePartFun），用静态分析工具递归扩展参考图 $G_f = (V_f, E_f)$，当新发现的 unit 数小于阈值时停止。**(3) Distinct Unit 识别**：按声明对 unit 分组（如 Time Functions、Math Functions），在每组内随机两两配对，沿 $G_f$ 路径做代码块级精确匹配剪枝，输出 $f_{pruned}^{unit} = f_{unit}^{(a)} \cap f_{unit}^{(b)}$；多轮迭代至剪枝比例不再下降，保留 top-$k$ 出现频率最高的剪枝模板。**(4) Reference Unit 抽取**：沿 $G_f$ 收集所有引用，按类型特化剪枝（保留 ScalarFunctionSet 的声明列表，剔除 GetFunctionByArguments 等完整方法体），得到精简的 reference 集合 $\{f_{ref}^{unit}\}$，合成中可按需 adaptive expansion。**(5) Pseudo-Plan 生成**：把 (3)(4) 输出的元数据喂给 LLM，并行生成 $n$ 个候选 plan，每个 plan 列出每个 unit 的「自然语言步骤描述 + 潜在引用元素 + 文件位置」；用打分函数 $R_k$ 过滤掉低分 plan（阈值 0.5），保留最佳。**(6) Fill-in-the-Blank 合成**：按 plan 把代码骨架中占位符处用剪枝模板填充（component-aware），由 LLM 生成 distinctive 部分的代码；多候选投票合并；如果连续失败，按 $P(n)=\alpha^n$ 衰减概率，最终退化为从零生成。**(7) 三层验证 + 自适应迭代**：先 ANTLR 语法检查，再 `make install` 合规编译，最后 LLM 基于专家指令 + 已有测试集 + 拆解代码块生成 SQL 测试，语义级不通过则回到 (5) 重生成 plan。每条合成轨迹 $(f_{dec}, C, s)$ 存入记忆库 M，下次合成同类函数时按「最小/中位/最大」工具数挑 3 条作参考。整个过程由 LLM 控制器决定下一步调哪个工具，直到 $o_p^{stop}$ 终止。

技术新颖性体现在三个层面的工程化整合：(1) **静态结构化先验**：把数据库的「声明-单元-引用」三层结构用图 + 剪枝算法显式编码进 LLM 上下文，区别于通用 LLM 的「黑盒先验」和 CodeRAG 的「整段检索」。具体地，pairwise pruning 把 $G_f$ 路径上的代码块用集合交集 $f_{pruned}^{unit} = f_{unit}^{(a)} \cap f_{unit}^{(b)}$ 形式化为数学操作，是 SQL/PL 优化领域常见的「公共子表达式提取」思想在 LLM 时代的新应用。(2) **Plan-then-Fill 的两阶段生成**：先用结构化 plan 锁定「该写在哪、引用什么」，再用 fill-in-the-blank 降低 LLM 单次生成压力，相当于把「长上下文生成」拆成「短指令生成 + 局部填空」，缓解幻觉。(3) **轨迹记忆 + 工具编排**：借鉴了 SWE-Agent、AutoGen 等智能体框架的 tool-use 思想，但额外用「同类函数轨迹的统计分布（min/median/max）」做 quality control，让记忆库既紧凑又有覆盖度，且通过 LLM 控制器 + 历史轨迹的混合决策（hybrid optimization）实现「LLM 自主性 + 经验复用」的平衡。相较 UDF 优化（Froid 把 UDF 改写为关系代数、Tuplex 编译 Python UDF）和临时代码生成（HyPer 用 LLVM JIT、Weld 用中间表示），DBCooker 解决的是「持久化的、跨版本演化的、版本敏感的内核 C/C++ 代码」生成问题，是 LLM for Database Engineering 这一新方向的代表性工作。

独立分析论文存在的弱点与改进方向：(1) **轨迹记忆库的统计偏差风险**——论文用 min/median/max 三档代表同类函数轨迹，但若某类别内函数质量分布极不均衡（如 Date 类大部分 EASY，但偶尔出现 HARD），记忆库中三条样本可能都偏向简单，导致 HARD 函数合成时 LLM 被误导去「少调工具」反而漏掉关键验证。**改进方向**：在记忆库中按「难度分桶 + 工具调用数」双重索引，检索时根据当前函数的 k-means 难度标签挑选同档轨迹。(2) **三阶段验证的级联失败传播**——若 ANTLR 语法检查或 `make install` 在某些数据库版本上不稳定，会让后续 LLM 收到「假阴性」反馈，从而错误地触发 plan 重生成。**改进方向**：为每层验证加可信度评分，只在「连续 2 次相同错误」时才回退到 plan 重生成；或引入回归测试集验证验证器本身。(3) **对新增 reference 的处理偏保守**——Section 4.3 的 Adaptive Expansion 只在合成时按需扩展 reference，但剪枝阶段（Section 4.2）会丢失远距离引用（>2 hop），导致对跨文件依赖深的函数支持不足。**改进方向**：把 reference 检索从「2-hop 剪枝」升级为「lazy 加载 + 重要性采样」，按 LLM 关注度动态扩展；可结合 GNN 学习 reference 重要性。(4) **缺乏性能维度评估**——论文只验证正确性，没有评估合成函数的运行时开销。对于数据库内核函数，错误地用了 `int64` 而非 `double`、或多余的拷贝/类型转换，都可能让用户能跑但跑得慢。**改进方向**：在 semantic validation 中加性能 oracle（如「与 ground-truth 实现输出 ≤ 1.2 倍时间」）。(5) **对 prompt 注入与安全验证不足**——数据库函数接受 SQL 字符串作为参数时，存在注入风险；论文未讨论 LLM 生成代码的 SQL injection 安全性。**改进方向**：在 semantic level 增加 fuzz testing 与 adversarial SQL 样例。

作者在 Section 9 明确给出三个未来方向：(1) **大规模代码库碎片化 vs. 长上下文推理**——即便未来 LLM 支持百万 token，直接塞 PostgreSQL 百万行也带来高成本与噪声；DBCooker 的 Function Characterization 通过显式 unit identification 让 LLM 只需关注相关小集合。(2) **确定性正确性要求 vs. 概率性生成**——未来 LLM 仍不能保证内核级 correctness，必须依赖伪计划 + 三阶段验证这类外部约束把概率性输出「翻译」为可验证实现。(3) **动态代码库适配 vs. 静态训练偏差**——未来 LLM 训练数据会混合多版本数据库，存在已废弃约定；DBCooker 通过版本敏感的 retrieval + adaptive orchestration 避免重训。基于成果可延伸的方向还包括：(a) 把同一框架推广到数据库的其他扩展点（索引、聚合算子、Window Function），构建「DBCooker for Database Internals」通用平台；(b) 与 DDL/查询优化器结合，让合成函数自动接受代价模型评估并迭代优化；(c) 多模态输入支持（PDF 文档 + 自然语言规约 + 既有测试），降低用户描述新函数的人工成本；(d) 与数据库迁移工具（如 CrackSQL）联动，在 Oracle→PostgreSQL 迁移中自动补充 Oracle 专有函数的 PG 实现。

**开源情况**：代码已开源在 https://github.com/weAIDB/DBCooker，论文在 Table 4 的脚注承诺「完整测试函数列表 + 新函数实现代码」均在 artifact 中。**数据集与基线**：评估覆盖 75+145+128=348 个函数，其中 17 个 SQLite 新函数已在 Table 4 列出声明式宏；基线包括 GPT-5、Claude Opus 4.1、Claude Sonnet 4.5、Qwen3 Coder Plus 4 个 LLM 及其 CodeRAG 变体，加上 Claude Code、Qwen Code、TRAE 3 个智能体，均为公开可访问。**算力需求**：实验在 2× Intel Xeon E5-2678 v3 (2.50 GHz) + 256 GB RAM + 4× NVIDIA RTX 4090 Ti 的工作站上完成，每个函数合成 timeout 300 秒。**复现难度**：中等偏低——核心算法不依赖专有模型（默认智能体基线用 Qwen3 Coder Plus，温度 0.1），但 (a) PostgreSQL/DuckDB 完整编译耗时较长（PG 需 `make install`），(b) LLM API 调用成本可观（每个函数平均 7–11 次尝试 + 多 plan 并行 + 验证循环），(c) 静态分析工具需针对不同数据库源码版本调整配置。**建议**：先复现 SQLite 75 个函数验证主流程，再扩展到 PG/DuckDB；优先关注 Function Characterization 模块的正确性（这是性能瓶颈）。