Automating Database-Native Function Code Synthesis with LLMs

使用大型語言模型自動化資料庫原生函式程式碼合成

原始論文：Automating Database-Native Function Code Synthesis with LLMs 作者：Wei Zhou (上海交通大學)、Xuanhe Zhou* (上海交通大學，通訊作者)、Qikang He (上海交通大學)、Guoliang Li (清華大學)、Bingsheng He (新加坡國立大學)、Quanqing Xu (螞蟻集團)、Fan Wu (上海交通大學) arXiv ID：2604.06231v1 日期：2026-04 期刊：Proc. ACM Manag. Data, Vol. 4, No. 3 (SIGMOD), Article 141, June 2026 程式碼：github.com/weAIDB/DBCooker 標籤：LLM Code Synthesis Database SQL UDF Tool Use SIGMOD

摘要 (Abstract)

資料庫系統 (Database Systems) 在其核心 (kernel) 中內建了越來越多的函式 (亦即「資料庫原生函式 (database native functions)」)，以支援新應用場景與業務遷移。這種增長帶來了對自動化資料庫原生函式合成 (synthesis) 的迫切需求。雖然近期基於大型語言模型 (LLM-based) 的程式碼生成 (code generation) 進展 (例如 Claude Code) 展示了潛力，但既有方法對於資料庫專屬開發而言過於通用。它們經常產生幻覺 (hallucinate) 或遺漏關鍵脈絡，因為資料庫函式合成本質上是複雜且容易出錯的：合成單一資料庫函式可能涉及註冊多個函式單元 (function units，例如針對不同輸入型別)、將程式碼放置於正確的原始檔案中、連接內部參照 (internal references)，並正確實作邏輯。

為此，我們提出了 DBCooker，這是一個基於 LLM 的系統，可自動合成資料庫原生函式。系統包含三個關鍵組件。首先，函式特徵化 (function characterization) 模組聚合多源宣告，透過階層化分析辨識需要專門編碼的函式單元，並透過靜態分析 (static analysis) 追蹤跨單元相依性。其次，我們設計操作以解決主要的合成挑戰：(1) 一個基於偽碼 (pseudo-code) 的編碼計畫生成器，透過辨識可重用的參照函式等關鍵元素來建構結構化的實作骨架；(2) 一個由機率先驗 (probabilistic prior) 與組件感知 (component-aware) 引導的混合填空 (fill-in-the-blank) 模型，將核心邏輯與可重用的常式整合在一起；(3) 三層漸進式驗證 (progressive validation)，包括語法檢查 (syntax checking)、規範符合性 (standards compliance) 以及由 LLM 引導的語義驗證 (semantic verification)。最後，自適應編排 (adaptive orchestration) 策略將這些操作與既有資料庫工具統一起來，並基於相似函式的編排歷史動態地排序它們。結果顯示，我們的系統在 SQLite、PostgreSQL 與 DuckDB 上勝過了最先進的方法 (state-of-the-art methods)，平均準確率高出 34.55%，並可合成最新版 SQLite (v3.50) 中尚未存在的四類新函式。

關鍵字：資料庫函式 (Database Function)、函式程式碼合成 (Function Code Synthesis)、大型語言模型 (Large Language Models)

一、引言 (Introduction)

資料庫在其核心中提供了大量的原生 SQL 函式 (Native SQL Functions)。例如，PostgreSQL v18 包含 27 個日期函式 (例如 date_trunc())，DuckDB v1.4.0 提供 57 個數值函式 (例如 sqrt())。現代資料庫系統中原生 SQL 函式的數量持續快速增長。如圖 1(b) 所示，PostgreSQL 函式從 v11 的 237 個成長到 v18 的 630 個，幾近三倍；DuckDB 從 v0.3.3 的 60 個成長至 v1.4.0 的 666 個；SQLite 從 v3.8.0 的 52 個成長至 v3.50.0 的 143 個。這種擴張源自於對新場景的支援 (例如商業智慧分析 (BI analysis)、幾何處理 (geometric processing)) 以及業務遷移 (business migration)。具體而言，在舊系統遷移情境中 (例如 Oracle 遷至 PostgreSQL)，實作專有函式是主要瓶頸：程式碼重構佔了遷移預算的 30%–60%，每 1,000 行程式碼需耗費 40–80 小時。

合成資料庫原生函式是擴展系統能力的關鍵任務，主流系統 (如 PostgreSQL) 提供的官方開發指引也佐證了此點。然而，這是一個高度耦合、易錯的過程，需要大量人類專業知識，並深入了解內部相依性以及主要資料庫更新間的差異，這對開發者構成難以承受的負擔。其複雜性相當可觀：PostgreSQL 從 v11 到 v18 的原生函式程式碼 (在兩跳相依範圍內) 跨越 119,161 行；DuckDB 的 GitHub 儲存庫上回報了 3,791 個與函式相關的議題。

如圖 1(a) 所示，要在 PostgreSQL 中實作 SQL 函式 date_trunc()，開發者必須：(1) 根據 prorettype 屬性中指定的引數型別等因素，註冊適當的函式單元 (例如 timestamptz_trunc 與 interval_trunc)；(2) 找到正確的原始檔案來實作這些函式單元 (例如 timestamp.c 之於 timestamptz_trunc)；(3) 參照正確的單元 (例如 PG_GETARG_TEXT_PP) 以完成這些函式單元中的程式碼區塊。若未能利用這些參照 (例如誤用某些內部資料型別)，可能會導致違反規範 (造成合成失敗) 或重新實作的浪費。如圖 1(c) 所示，若使用參照單元僅實作 date_trunc() 註冊的四個單元，相比於從零開始實作 (這需要 6,235 行程式碼，跨越兩跳呼叫的 225 個函式)，可減少約 94.95% 的程式碼行數。

既有方法的限制 (Limitations of Existing Methods)

儘管在基於 LLM 的通用程式碼生成上已有近期進展，據我們所知，目前並無公開的工具或框架提供完整的資料庫原生函式自動化流程。既有的程式碼合成方法 (包括基於提示的方法 (prompt-based)、基於代理人的系統 (agent-based)、與訓練導向的模型 (training-based)) 在資料庫原生函式合成上展現出顯著的限制：

1. 缺乏資料庫特性意識：這些通用方法無法捕捉資料庫原生函式的特定特徵 (例如必要的函式單元與儲存庫內細粒度的參照)，導致實作不正確或不完整。例如，Qwen Code 可能會忽略 date_trunc() 中處理 interval 輸入所需的函式單元。
2. 過度依賴粗粒度檔案搜尋：缺少領域特定 (domain-specific) 的啟發式規則來引導程式碼放置，並忽略基本驗證步驟。例如，Claude Code 大部分時間都在掃描不相關的檔案以尋找該在哪裡實作 date_trunc()，而非驗證其在不同輸入值下的正確性。
3. 靜態合成策略：現有方法以檔案探索為起點並從零開始實作函式，未考慮函式複雜度的差異或利用函式間的相似性。例如，它們將簡單的數學函式 sqrt() 與複雜的聚合函式 json_agg() 同等對待，並無法重用同一日期函式類別中相關的實作 (如 date_part())。

挑戰 (Challenges)

合成資料庫原生函式面臨三大挑戰：

• C1：高層 SQL 函式可能對應到多個底層函式單元，這些單元具有不同名稱與職責，因而難以判斷需要合成哪些單元。例如，date_trunc() 在 PostgreSQL 中需要分別為 timezone 與 interval 輸入引數註冊 timestamptz_trunc 與 interval_trunc。
• C2：實作資料庫原生函式需要參照大量既有函式單元，否則無法正確合成實作流程。原因是：(1) 參照複雜，難以從零生成 (例如 date_trunc() 在兩跳內的參照程式碼從 315 行擴增至 6,235 行)；(2) 某些參照對於功能性是必要的 (例如使用 PG_RETURN_NUMERIC 巨集進行輸出格式化)。
• C3：跨多樣化函式的合成泛化困難。如 sqrt() 等簡單函式可透過直接包裝標準函式庫實作，而複雜的聚合函式 (如 json_agg()) 則需要自訂邏輯，因此需要自適應的合成策略。

我們的方法 (Our Methodology)

為解決這些挑戰，我們提出了 DBCooker，一個基於 LLM 的自動化資料庫函式合成系統：

• 針對 C1：引入函式特徵化模組，包含 (1) 多源函式宣告蒐集 (例如文件與系統目錄)、(2) 階層式函式單元辨識以隔離出需要實作的區別性單元、(3) 使用靜態相依性圖與類別特定剪枝的脈絡感知 (context-aware) 跨單元參照分析。
• 針對 C2：設計合成操作，包含 (1) 基於格式的偽碼計畫生成 (產生並評分結構化程式碼骨架以引導生成)、(2) 由機率先驗與組件感知強化的混合填空編碼模型 (精確整合區別性與可重用的參照單元)、(3) 三層漸進式驗證模組 (涵蓋語法、規範符合性與 LLM 引導的檢查)。
• 針對 C3：提出自適應合成操作編排模組，將操作抽象為工具，並結合 LLM 驅動決策與相似工作流程軌跡，動態最佳化工具呼叫工作流程。

貢獻 (Contributions)

• 我們提出首個基於 LLM 的資料庫函式程式碼自動合成系統，能分析函式組成、生成必要的內部參照與函式單元間的連結，並自適應地合成多種資料庫函式。
• 我們提出函式特徵化模組，透過宣告擷取、區別性單元辨識與跨單元參照分析來捕捉關鍵實作資訊。
• 我們提出基於格式偽碼計畫生成、混合填空模型引導編碼，與漸進式程式碼驗證的區別性函式單元程式碼合成策略。
• 我們採用自適應的多樣化函式程式碼合成機制，結合 LLM 驅動決策與基於軌跡的工作流程重用，動態編排合成操作。
• 我們在三個主流資料庫上對不同合成方法進行廣泛實驗，DBCooker 較最先進方法 (例如 Claude Code) 的平均準確率高出 34.55%，並可加入最新版 SQLite (v3.50) 中尚未存在的全新函式。

二、預備知識 (Preliminary)

2.1 資料庫原生函式

資料庫原生函式提供了廣泛功能 (例如字串操作、數值計算)，可分解為三部分：(1) 函式宣告 (function declaration)、(2) 待實作的新函式單元 (new function units)、(3) 用作參照的既有函式單元 (reference function units)。

函式宣告 (Function Declaration)：給定資料庫引擎 $D$，函式宣告 $f_{dec}$ 形式化地描述函式的存在與用法，包括名稱、描述、引數型別與回傳型別。宣告通常儲存於系統目錄 (system catalog) 以支援一致的註冊與呼叫。例如，date_trunc() 的宣告描述其功能為「截斷時間戳記」，並在 pg_proc.dat 中指定兩個輸入引數 (text, timestamp)。

函式單元 (Function Unit)：函式單元 $f_{unit}$ 是一個自包含的可執行組件，由定義在特定資料庫檔案中的一個或多個程式碼區塊 $\{c_{block}\}$ 組成。每個程式碼區塊封裝函式行為的特定面向，從主要計算邏輯到輔助任務 (如處理輸入引數或格式化輸出結果)。對於函式程式碼合成，給定一個 SQL 函式，我們區分新合成的函式單元 $f^{new}_{unit}$ (需要實作) 與參照函式單元 $f^{ref}_{unit}$ (已實作，例如函式庫函式或巨集)。

資料庫原生函式 (Database Native Function)：與在 SQL 層級定義的 UDF (User-Defined Function) 不同，資料庫原生函式 $f$ 完全由一個或多個函式單元實作並直接整合到資料庫 $D$ 中。形式化表示為：

$$f = \langle f_{dec}, \{ \langle f^{new}_{unit}, \{f^{ref}_{unit}\} \rangle \} \rangle$$

範例 2.1：PostgreSQL 中的 date_trunc() 包含：(1) $f_{dec}$ 指定簽章為兩個輸入引數 (text, timestamp) 與一個輸出引數 timestamp；(2) $f_{unit}$ 包含四個新合成的函式單元 (timestamp_trunc、interval_trunc、timestamptz_trunc 與 timestamptz_trunc_zone)，定義於 src/backend/utils/adt/timestamp.c 中以處理不同輸入；以及多個參照函式單元 (例如 PG_GETARG_TEXT_PP 用於取得輸入引數，PG_RETURN_TIMESTAMPTZ 用於格式化輸出結果)。

2.2 資料庫原生函式程式碼合成

我們接著定義資料庫原生函式程式碼合成的問題。給定精確的函式規格 $S$ (例如函式名稱、描述、輸入引數、輸出型別與 SQL 範例)，目標是自動生成並實作資料庫核心中的可執行函式程式碼，使合成的程式碼正確實現預期的功能。

定義 2.2 (資料庫原生函式合成)：給定目標資料庫 $D$ 的 SQL 層級函式規格 $S$，資料庫原生函式合成的目標是生成必要函式單元 $\{f^{new}_{unit}\}$ 的程式碼，使其滿足 $S$ 並可成功整合到 $D$ 中，包含所有必要的參照 $\{f^{ref}_{unit}\}$，亦即無任何規範錯誤且通過資料庫 $D$ 中所有測試案例 $T$ 並產生預期結果。

2.3 先導研究 (Pilot Study)

我們對資料庫原生函式程式碼進行了特徵化分析，並調查既有方法的限制。

O1：資料庫包含大量參照，但原生函式只依賴一小部分。我們分析了整個資料庫儲存庫中的參照總數，並與原生函式直接使用的參照進行比較。如圖 2(a) 所示，雖然資料庫儲存庫包含大量檔案與函式參照，但原生函式只依賴其中有限的一部分。具體而言，三個資料庫儲存庫的每檔案平均參照數分別為 2619.56、1594.65 與 872.32，但單一函式單元的對應平均值僅為 13.73、47.58 與 33.11。這種高度的參照密度凸顯了在合成過程中精確辨識正確參照函式的方法是必要的。

O2：當前的代理人框架採用通用設計，對資料庫特定操作的關注有限，導致探索與合成效率低下。如圖 2(b) 所示，Claude Code 大部分時間花在檔案層級的搜尋上 (63.70% 用於 Search Repo 與 Read File)，而非實作函式邏輯的程式碼生成任務 (僅 4.95% 用於 Update File)。這種失衡顯示當前框架過度聚焦於儲存庫遍歷，忽略了程式碼建構與驗證。

O3：既有合成方法呈現多種錯誤，宣告錯誤是合成資料庫函式時最常見的。如圖 2(c) 所示，無論是先進 LLM (Claude Sonnet 4.5) 還是基於代理人的框架 (Claude Code)，都會產生大量宣告相關錯誤。這些錯誤包括同一檔案內的重複宣告 (例如在 div 中重新定義 int4div)、與引數不匹配的不正確函式參照 (例如 regexp_matches 中對 pg_regcomp 的引數過少)。平均而言，宣告錯誤佔了兩種方法所有錯誤的 81.76%。

三、DBCooker 系統概覽 (Overview)

如圖 3 所示，DBCooker 與通用程式碼合成框架不同，其設計明確考慮了資料庫程式碼庫的特性，能穩健地處理其獨特的結構組織 (例如 SQL 層級目錄定義與底層實作單元之間的嚴格映射)。

函式特徵化 (Function Characterization)

此模組設計圍繞於資料庫函式如何實作，形成捕捉內部組織以引導合成的結構模板與約束。將資料庫程式碼庫作為輸入，我們引入自動化策略以擷取關鍵元數據 (metadata) 作為輸出：

1. 函式宣告蒐集：以官方文件與系統目錄 (例如 PostgreSQL 的 pg_proc) 作為輸入，透過解析官方文件以擷取結構化函式資料，並透過查詢系統目錄以直接從資料庫引擎蒐集權威宣告。
2. 區別性函式單元辨識：採用基於圖的分析策略 (graph-based analysis)。以函式名稱為輸入，透過關鍵字匹配定位潛在的註冊點，然後在透過靜態分析工具建構的相依性圖中遍歷程式碼路徑，蒐集相關單元，並透過配對比較區分共享輔助單元 (可作為模板重用) 與區別性單元。
3. 跨單元參照分析：以初始相依性圖為輸入，先蒐集相依性，然後使用類別特定的規則進行精煉，僅保留必要內容 (例如保留宣告，省略完整方法主體)，這些可在合成時還原。

函式合成操作 (Function Synthesis Operations)

此模組基於擷取的函式特徵進行建構，包含確保資料庫正確性的專門合成操作。它涉及三個操作：規劃 (planning)、編碼 (coding) 與測試 (testing)。

1. 基於偽碼的編碼計畫生成：以函式元數據與資料庫階層為輸入，透過從相似函式進行元資訊匹配以辨識相關參照單元。然後指示 LLM 生成多個候選計畫 (即結構化程式碼骨架)，並使用評分為基礎的剪枝機制根據資料庫程式碼簡潔性與規範遵循度排序這些候選。
2. 漸進式程式碼合成：將函式合成建模為填空問題，每個空格對應一個必要的程式碼單元。採用兩步策略：(a) 模板實例化機制根據宣告型別檢索部分匹配的模板；(b) 在失敗情況下，機率適應模組控制合成，允許填空或從零生成以輸出合成的程式碼。
3. 三階段程式碼驗證：(a) 語法驗證使用語法解析器 (例如 ANTLR) 確保在目標資料庫下可解析；(b) 規範性檢查使用資料庫原生編譯工具驗證函式遵循內部慣例；(c) 語義驗證以自動生成的測試案例擴增資料庫的測試套件。

自適應函式合成 (Adaptive Function Synthesis)

為了解決對於不同複雜度函式採用僵硬的「編碼 → 測試」工作流程的限制，我們首先透過將共用工具 (例如 bash) 與基於 LLM 的工具抽象成一組可呼叫工具來統一多樣化的合成步驟。然後，我們開發混合編排策略，結合 LLM 控制器 (透過脈絡感知推理自適應地決定下一個工具) 與全域軌跡記憶 (累積歷史工作流程以引導與加速相似函式的合成)。

四、函式特徵化模組 (Function Characterization)

不同於依賴低效檔案搜尋的通用代理人，此模組執行確定性的基於圖的分析，將 SQL 函式分解為基本結構模板而非原始片段。它解決資料庫核心固有的三個挑戰：(1) 為函式建構簡潔且資訊豐富的概覽是非平凡的，因為其定義散佈於異質的文字與程式碼層級宣告中；(2) 辨識基本函式單元需要理解資料庫的內部架構慣例 (例如型別特定組件與模組化執行管線)；(3) 這些函式單元常呈現結構重用與跨單元相依性 (例如資料庫特定的巨集) 以促進相似函式間的一致實作。

4.1 函式宣告蒐集

我們設計雙源策略以系統化擷取文字與程式碼樣式的函式宣告 $f_{dec}$。

基於文件的函式蒐集：自動解析並分析官方資料庫文件以蒐集文字函式宣告。我們透過檢查階層式文件結構辨識描述原生函式的章節，並使用自動化指令碼解析並標準化擷取的內容為包含函式相關資訊的統一 JSON 格式。例如，從 PostgreSQL 的「Chapter 9. Functions and Operators」中，我們擷取 date_trunc 函式，描述為「將時間戳記截斷至指定精度」，並包含範例 date_trunc('hour', timestamp '2001-02-16 20:38:40') → 2001-02-16 20:00:00。

基於目錄的宣告擷取：從內部系統目錄與註冊檔案 (例如 PostgreSQL 中的 pg_proc 表與 pg_proc.dat 檔案) 擷取確定性的程式碼層級宣告。我們查詢並整合目錄條目，系統化地檢索關鍵屬性 (如輸入引數與回傳型別)，並標準化為相同的 JSON 格式。

4.2 區別性函式單元辨識

為遵循新資料庫函式合成的隱含慣例，我們設計兩個模組來辨識需要跨多個檔案實作的基本函式單元 $f_{unit}$。

基於圖的單元擷取 (Graph-based Unit Extraction)：對於具有 SQL 層級宣告 $f_{dec}$ 的原生資料庫函式 $f$，我們先執行基於關鍵字的檢索以定位對應的函式條目與其註冊單元 $f^{reg}_{unit}$。從 $f^{reg}_{unit}$ 開始，我們應用自動化靜態分析來建構參照圖 $G_f = (V_f, E_f)$，其中 $V_f$ 表示函式單元 $f_{unit}$ 的集合，$E_f$ 編碼透過函式呼叫或類別繼承關係建立的參照。圖的擴展遞迴進行，直到未發現額外函式單元，或當前被參照的單元數量大於預定義門檻時終止。

如圖 4(a) 所示，我們從 SQL 關鍵字 date_part 開始初始化 DuckDB 中的相依性圖以定位 function_list.cpp 中的註冊條目。然後透過參照遍歷擴展圖，辨識關鍵功能單元 (如 date_functions.hpp 中的 DatePartFun)，而 function_set.hpp 被排除，因為涉及的組件 ScalarFunctionSet 是廣泛用於各種純量函式的參照單元。

配對單元剪枝 (Pairwise Unit Pruning)：我們引入一種配對單元剪枝策略以從擷取的函式單元集合 $\{f_{unit}\}$ 中提取剪枝後的固定模式：

1. 依函式宣告分組：擷取的函式單元 $f_{unit}$ 首先依照其 SQL 層級宣告 $f_{dec}$ 進行分組，考慮輸入輸出引數型別與功能類別。例如，timestamptz_part 與 extract_timestamptz 因屬於相同的 datetime 類別且接受 timestamp 引數而被歸為一組。
2. 配對內容比較：每組內的單元被隨機配對選擇，並沿其在參照圖中的呼叫路徑進行比較。對於一對單元 $f^{(a)}_{unit}, f^{(b)}_{unit}$，先抽象化變數名稱等識別符以標準化程式碼。然後基於精確關鍵字匹配擷取剪枝後的程式碼區塊 $f^{pruned}_{unit} = f^{(a)}_{unit} \cap f^{(b)}_{unit}$。非剪枝區塊被替換為佔位符 (placeholders)。
3. 多輪精煉：在每組內進行多輪配對比較，每輪 $t$ 在剪枝組件比例相對於前一輪減少時停止：$|f^{pruned(t)}_{unit}| / |f^{(t)}_{unit}| < |f^{pruned(t-1)}_{unit}| / |f^{(t-1)}_{unit}|$。

4.3 跨單元參照分析

為系統化捕捉複雜資料庫儲存庫中函式單元間的相依性，我們提出跨單元參照分析以擷取每個原生函式 $f$ 的參照單元 $f^{ref}_{unit}$：

1. 靜態相依性擷取：給定參照圖 $G_f = (V_f, E_f)$，我們迭代執行自動化靜態分析以辨識每個函式單元 $f_{unit} \in V_f$ 沿著圖路徑的參照單元 $\{f^{ref}_{unit}\}$，包括 D_ASSERT 斷言參照與 BinaryExecutor 等執行器參照。
2. 型別特定剪枝：為解決直接包含所有參照單元 (如完整類別定義) 帶來的冗餘或過度細節，我們應用預定義的型別特定剪枝規則。例如，ScalarFunctionSet 類別保留其宣告列表，但省略 GetFunctionByArguments 等詳細方法實作。
3. 自適應擴展：所得的參照集合提供了 $f^{ref}_{unit}$ 的初始表示，可在函式合成期間漸進擴展。

五、函式程式碼合成操作 (Code Synthesis Operations)

5.1 偽碼導向的編碼計畫生成

如圖 1 所示，人類開發者投入大量精力將 SQL 層級函式映射到其內部單元，並透過儲存庫探索決定其實作邏輯與位置。DBCooker 不依賴 LLM 不可見的推理，而是將程式碼合成延後到一個資訊豐富的計畫。我們基於註冊的函式單元 (用於 SQL 層級功能) 與內部資料庫階層資訊生成骨架。每個計畫明確包含：(1) 分解的函式單元；(2) 資料庫內參照的單元。

5.1.1 候選計畫生成

為辨識資訊豐富計畫的相關函式單元，我們採用基於元數據的匹配策略。我們先從相同函式類別的所有既有函式中蒐集潛在的參照函式單元。然後過濾這些參照單元以移除重複，並依單元型別分組。

考量不同輸入型別所需的多樣化處理邏輯與資料庫原生函式中既有單元的頻繁重用，我們定義並指示 LLM 生成包含以下內容的候選編碼計畫：(1) 每個輸入型別的分解函式單元，以及每個單元內的結構化處理邏輯；(2) 資料庫中支援每個分解函式單元中各程式碼區塊實作的潛在參照單元。如圖 5 所示，編碼計畫列舉所需的函式單元及其檔案路徑。每個單元被分解為一系列具有特定功能的邏輯程式碼區塊。對於每個區塊，LLM 生成的計畫包含自然語言描述 (例如「步驟 1：擷取函式引數」) 與潛在參照單元列表 (例如 PG_GETARG_TEXT_PP())。

5.1.2 基於評分的計畫過濾

為降低生成低品質計畫誤導合成過程的風險，我們引入基於度量評分函式的計畫過濾。給定 $n$ 個實作計畫，計算每個計畫的標準化分數，計畫 $k$ 的分數計算如下：

$$R_k = \alpha \cdot N(v^1_k) + \beta \cdot N(v^2_k) + \gamma \cdot N(v^3_k)$$

其中前兩項表徵忠實度 (faithfulness)，最後一項捕捉簡潔度 (simplicity)。$v^1_k$ 是錯誤參照函式單元的數量；$v^2_k$ 是每個函式單元錯誤指定檔案位置的數量；$v^3_k$ 是列出的函式單元數量。$N(x)$ 表示最小-最大標準化 $N(x) = 1 - \frac{x - \min}{\max - \min}$。$\alpha, \beta, \gamma$ 為權重係數，分別為 0.4, 0.4, 0.2。我們在計算此分數時從計畫中移除錯誤的函式單元與參照函式單元，並過濾掉分數低於預定義門檻 (例如 0.5) 的計畫。

5.2 漸進式程式碼合成

我們將函式合成形式化為填空任務 (fill-in-the-blank task)。不同於需要 LLM 從零合成整個函式的傳統方法，我們採用一個利用模板與評分偽碼計畫的機率性自我修正框架。

填空合成模型：給定函式宣告中指定的元數據 (例如函式類別)，我們先檢索共享相同元數據值的原生函式。從這些檢索到的函式中，我們擷取在 4.2 節中具有佔位符的前 $k$ 個代表性函式單元。例如，在 DuckDB 中，LLM 只需為十個型別特定函式生成區別性函式單元並將其加入 DatePartFun::GetFunctions，而不需要實作所有函式單元。為進一步增強合成可靠性，我們呼叫 LLM 平行生成多個候選函式單元，然後應用自我一致性 (self-consistency) 策略合併這些候選。

合成模型適應：我們將填空模型的採用形式化為機率問題，初始使用填空模型的機率設為 $P_0 = 1$。此機率隨每次失敗的合成嘗試指數衰減：$P(n) = \alpha^n$，其中 $n$ 表示程式碼合成失敗的次數，$\alpha (0 < \alpha < 1)$ 是衰減因子。一旦機率達到零 ($P_0 = 0$)，LLM 切換到完全探索性的合成模式，自主辨識並從零實作所有必要的函式單元。

5.3 三階段程式碼驗證

我們提出漸進式驗證策略，從單檔案正確性到多檔案整合，在三個階層性層級評估生成的函式單元：

1. 語法層 (Syntax Level)：在單一檔案內執行基本語法檢查以確保變數正確宣告與參照，使用語言特定解析器如 ANTLR。
2. 規範層 (Compliance Level)：透過自訂編譯工具與命令 (例如 PostgreSQL 中的 make install) 跨多檔案驗證對資料庫特定慣例的遵循。
3. 語義層 (Semantic Level)：使用 LLM 生成 SQL 來評估執行時行為，最大化覆蓋範圍的三個脈絡來源：(a) 引導 LLM 注意易錯區域 (如輸入型別) 的專業指令；(b) 既有資料庫測試套件以重用範例與格式慣例；(c) 分解的內部程式碼區塊以生成與新實作相關的測試案例。

六、從靜態合成走向自適應工具編排

傳統合成工作流程通常採用具有固定階段 (例如 coding → testing) 的預定義管線。然而，資料庫原生函式表現出多樣化的合成複雜性。為克服預定義工作流程在處理函式特定合成上的有限靈活性，我們從靜態合成工作流程轉向自適應工具編排框架。

6.1 操作即工具抽象 (Operation-as-Tool)

為將合成操作與通用工具 (例如檔案搜尋) 無縫整合到統一工作流程中，我們引入操作即工具抽象，將每個合成操作封裝為可呼叫工具 $O$。每個工具的統一介面包含三個模組：

• (1) 元數據模組：定義工具的名稱、引數與功能描述。
• (2) 核心邏輯模組：透過處理邏輯模組實作所設計的操作，例如編碼計畫生成。
• (3) 路由模組：將輸入轉發到處理邏輯模組，並以可直接餵入 LLM 脈絡的標準化格式回傳輸出。

例如，我們將編碼計畫操作封裝為一個工具：(1) 元數據模組包含名稱「plan_agent」、輸入引數「plan_num」(預期計畫數量)、與描述「生成基於偽碼的計畫以概述並指示合成」；(2) 核心邏輯模組指示 LLM 生成多個基於偽碼的計畫，並依據預定義評分函式過濾這些計畫；(3) 路由模組以 JSON 內容回傳計畫以輸入到 LLM。

6.2 工具導向的逐步函式合成

演算法 1：工具導向的逐步函式合成

輸入：函式宣告 f_dec、合成工具集 O、合成記憶池 M
輸出：合成的函式單元 f_unit

1. /* 1. 取得相似函式的軌跡作為參照 */
2. 檢索 M'_ref = {m ∈ M | category(m) = category(f_dec) ∧ count_op(m) ∈ {min, median, max}}
3. /* 2. 即時編排操作工具 */
4. 初始化函式單元 f_unit ← ∅、軌跡 C ← ∅、工具 op ← op_coding
5. while True do
6.    更新 f_unit ← execute(op) 並更新 C ← C ∪ op
7.    決定下一個工具 op' ← LLM(C, M'_ref)
8.    if op' = op_stop then
9.       生成軌跡摘要 s ← LLM(C)
10.      break
11.   else
12.      op ← op'
13. /* 3. 儲存軌跡並回傳合成單元 */
14. 將 (f_dec, C, s) 儲存到記憶池 M
15. return f_unit

工具導向編排記憶 (Tool-based Orchestration Memory)：記憶池 $M = \{f_{dec}, C, s\}$ 用於捕捉編排，包含：(1) 函式元數據；(2) 工具呼叫軌跡 $C$；(3) LLM 生成的合成摘要 $s$。為確保軌跡池保持精簡與代表性，我們實作分布感知的品質控制機制：軌跡依函式類別組織以實現相似操作編排模式的高效檢索。新軌跡僅在其工具呼叫設定檔 (即呼叫工具的數量與型別) 更新該類別維護的統計資訊 (例如最小、中位數、最大工具使用量) 時才被插入。

七、實驗 (Experiments)

7.1 實驗設定

測試資料庫：(1) SQLite：用 C 實作的輕量級資料庫引擎；(2) PostgreSQL：用 C 編寫的全功能、符合標準的物件關聯式資料庫；(3) DuckDB：用 C++ 編寫的高效能進程內分析資料庫。

測試函式：合成兩種類型的函式：(1) 在官方儲存庫中具有真實實作的函式；(2) 目前在這些儲存庫中缺失的函式。我們在 SQLite、PostgreSQL 與 DuckDB 上分別測試 75、145、128 個函式。

評估方法：(1) 基於 LLM 的方法：GPT-5、Claude Opus 4.1、Claude Sonnet 4.5、Qwen3 Coder Plus；(2) 基於 RAG 的方法：以 CodeRAG 增強的 LLM；(3) 基於代理人的方法：Claude Code、Qwen Code、TRAE (SWE-bench Verified 排行榜第一)。

評估指標：(1) 規範準確率 $Acc_{EXE}$：成功編譯並整合到資料庫的合成函式比例；(2) 結果準確率 $Acc_{RES}$：通過所有測試案例並產生預期結果的合成函式比例。

實作：實驗在配備 2 顆 Intel Xeon E5-2678 v3 CPU、256 GB RAM 與 4 顆 NVIDIA RTX 4090 Ti GPU 的工作站上執行。代理人方法的預設 LLM 為 Qwen3 Coder Plus，溫度設為 0.1，每次合成最大逾時 300 秒。

7.2 整體效能

合成準確率：DBCooker 在不同資料庫上以最高合成準確率超越所有其他方法。具體而言，它達到 $Acc_{EXE}$ 與 $Acc_{RES}$ 分別為 78.90% 與 65.19%，平均勝過其他方法 124.37% 與 149.68%。這項改進源自於 DBCooker 整合的三個資料庫感知模組。

其次，基於 RAG 的方法 (透過參照函式單元豐富 LLM 脈絡) 改善了基於 LLM 方法的合成準確率。具體而言，整合 CodeRAG 平均將 LLM 方法的準確率提升 50.56%。

合成錯誤分布：基於代理人的方法產生較少的宣告相關錯誤，DBCooker 達到最低的宣告相關錯誤。為進一步隔離由檔案搜尋引入的錯誤，我們進行額外實驗，明確給予代理人基線正確的檔案路徑、函式宣告與參照單元的完整脈絡 (+ Hint)。即使具有此完整脈絡，這些代理人 (+ Hint) 仍生成包含未定義參照與型別相關語義錯誤的程式碼，平均準確率比 DBCooker 低 22.56%。

7.3 細粒度分析

依合成難度的效能 (表 1)：我們將函式分為三個合成難度組 (EASY、MEDIUM、HARD)，並評估每組內的合成準確率。DBCooker 在三個難度層級上一致地優於其他方法。具體而言，其達到 $Acc_{EXE}$ 與 $Acc_{RES}$ 分別為 78.44% 與 62.60%，平均比其他方法高 133.06% 與 150.80%。值得注意的是，對於 HARD 函式，DBCooker 達到 68.97% 的準確率，比其他方法平均高 197.10%。

依函式類別的效能 (表 2)：DBCooker 在不同類別間達到更高且更穩定的合成準確率。具體而言，$Acc_{EXE}$ 在四個類別 (Math、Date、String、JSON) 中範圍為 89.19% 至 96.67%，整體準確率平均比其他方法高 151.11%。

7.4 消融研究 (Ablation Study)

表 3：DBCooker 變體的程式碼合成準確率 (%)

觀察 1：所有提出的組件對於準確合成都是必要的，移除它們會導致不同程度的準確率下降。整體而言，DBCooker 在 $Acc_{EXE}$ 與 $Acc_{RES}$ 上獲得平均 42.14% 與 37.50% 的改進。

觀察 2：漸進式程式碼驗證對於可靠合成至關重要。對於 PostgreSQL，移除三階段驗證導致 $Acc_{EXE}$ 從 78.62% 顯著降至 6.9%，反映 PostgreSQL 較 SQLite 具有更多跨檔案相依性與多分支執行路徑。

觀察 3：偽碼計畫生成與漸進式驗證等組件協同工作以處理複雜邏輯。

7.5 新原生函式合成

為評估 DBCooker 在新函式合成上的能力，我們透過從其他資料庫引入新函式來擴展 SQLite 的能力。表 4 列出了新合成的 SQLite 函式 (包括 covar_pop、bool_and、century、monthname、yearweek、gamma、lgamma、nextafter、regexp_split_to_array、translate 等)，DBCooker 在所有 17 個函式上均成功合成，展現了卓越的效能。

DBCooker 的優勢來自三個方面：

1. 準確實作所有必要函式單元並正確宣告。例如，它為 SQLite 的 covar_pop() 聚合函式實作了三個必要函式單元 (covarPopStep、covarPopFinalize、covarPopInverse)。
2. 有效利用資料庫儲存庫內的參照函式單元。例如，在 bool_or 函式中，DBCooker 使用 sqlite3_aggregate_context 進行脈絡管理。
3. 自適應地管理多樣化函式並漸進精煉程式碼。例如，它使用不同的巨集 (例如 WAGGREGATE 與 FUNCTION) 區分聚合函式與其他純量函式。

八、相關工作 (Related Work)

通用程式碼生成 (General Code Generation)

近期程式碼生成進展可歸為三類：(1) 基於提示的方法 (如 Codex、GitHub Copilot) 將程式碼生成視為從自然語言或程式碼提示出發的條件文字生成；(2) 基於代理人的系統 (如 Claude Code、SWE-Dev、Qwen Code) 透過規劃與工具使用增強 LLM 以進行多步推理與程式碼除錯；(3) 訓練導向的模型 (如 Code Llama、StarCoder、WizardCoder) 聚焦於透過在大型程式碼語料上預訓練或從執行軌跡進行強化學習的架構改進。

UDF 最佳化 (UDF Optimization)

既有 UDF 最佳化工作聚焦於將高層 UDF 邏輯轉換為高效內部表示。Froid 將命令式 UDF 轉換為關聯代數表達式，將其嵌入 SQL 以進行成本基礎最佳化與平行執行。Tuplex 加速並將 Python UDF 編譯為原生程式碼。

執行時程式碼生成 (Runtime Code Generation)

既有研究透過暫時性的機器碼加速執行。HyPer 將查詢編譯為基於 LLVM 的機器碼。Weld 採用通用的中間表示用於跨函式庫工作流程。

資料庫遷移 (Database Migration)

近期研究使用 LLM 跨越 SQL 方言間的差距。CrackSQL 透過區域到全域策略自動化方言轉換。PARROT 提出了跨系統 SQL 轉換的基準。

九、結論與未來工作

本論文中，我們提出 DBCooker，這是首個用於自動化資料庫原生函式程式碼合成的 LLM 系統。它提出函式特徵化模組以捕捉函式宣告、區別性單元與跨單元參照，以及三個資料庫感知合成操作 (基於偽碼的計畫生成、漸進式程式碼合成與三階段程式碼驗證) 與自適應工具編排以進行多樣化函式合成。在三個資料庫上的實驗顯示，DBCooker 勝過最先進方法並有效支援新函式合成。

隨著前沿模型 (frontier models) 的進步，DBCooker 可持續強化其函式合成能力：

1. 大型程式碼庫碎片化 vs. 長脈絡推理 (Long-Context Reasoning)：資料庫程式碼庫龐大 (例如 PostgreSQL 超過一百萬行)，函式單元散佈，難以完全納入 LLM 脈絡視窗。即使未來 LLM 能處理整個程式碼庫，盲目包含一切也會引入高推論成本，且有效合成仍需可靠地辨識少量散佈的相關單元。DBCooker 的函式特徵化明確辨識這些單元，防止 LLM 遺漏關鍵資訊。

2. 確定性正確性需求 vs. 機率性生成合成：資料庫系統是任務關鍵的，其函式必須滿足嚴格的確定性正確性保證。即使未來 LLM 變得更可靠，其輸出仍基於機率性生成，無法本質上保證精確的資料庫正確性。DBCooker 的函式程式碼合成操作透過明確強制結構模板與正確性約束 (透過偽碼計畫與三階段漸進式驗證)，仍是必要的。

3. 動態程式碼庫適應 vs. 靜態訓練偏差：資料庫函式跨版本演進 (例如函式簽章、所需巨集或系統目錄定義的變化)。即使有更廣泛與較新的訓練資料，未來 LLM 不可避免地會學習資料庫版本與已棄用慣例的混合。DBCooker 透過動態檢索版本特定的資料庫實作常式並透過自適應工具編排強制執行它們來解決這個問題。

References

[1] Claude Code. (Anthropic). https://www.claude.com/product/claude-code [2] Claude Opus 4.1. (Anthropic). https://www.anthropic.com/news/claude-opus-4-1 [3] Claude Sonnet 4.5. (Anthropic). https://www.anthropic.com/claude/sonnet [4] DuckDB. (Dependency Management in DuckDB Extensions). [5] DuckDB. (extension). https://duckdb.org/docs/stable/extensions/overview [6] DuckDB. (function). https://duckdb.org/docs/stable/sql/functions/overview [7] DuckDB. (Repository). https://github.com/duckdb/duckdb [8] DuckDB. (Versioning of Extensions). [9] GPT-5. (OpenAI). https://platform.openai.com/docs/models/gpt-5 [10] Oracle to PostgreSQL Migration. (Cost). [11] Oracle to PostgreSQL Migration Challenge. (EnterpriseDB). [12] Oracle to PostgreSQL Migration Challenge. (Estuary). [13] PostgreSQL. (extension). https://www.postgresql.org/docs/current/xfunc-c.html [14] PostgreSQL. (function). https://www.postgresql.org/docs/current/functions-comparison.html [15] Qwen Code. (Qwen). https://qwenlm.github.io/qwen-code-docs/ [16] SQLite. (function). https://sqlite.org/lang_corefunc.html [17] Understand. (SciTools). https://scitools.com/ [18] Maryam Abbasi, et al. 2024. Adaptive and scalable database management with machine learning integration. Information 15, 9. [19] Bei Chen, et al. 2023. CodeT: Code Generation with Generated Tests. ICLR. [20] Mark Chen, et al. 2021. Evaluating Large Language Models Trained on Code. arXiv:2107.03374. [21] Jean-Baptiste Döderlein, et al. 2025. Piloting Copilot, Codex, and StarCoder2. J. Syst. Softw. 230. [22] Korry Douglas, Susan Douglas. 2003. PostgreSQL: a comprehensive guide. SAMS publishing. [23] Pengfei Gao, et al. 2025. Trae Agent: An LLM-based Agent for Software Engineering. arXiv:2507.23370. [24] Haralampos Gavriilidis, et al. 2023. In-situ cross-database query processing. ICDE. [25] Sirui Hong, et al. 2024. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. ICLR. [26] Binyuan Hui, et al. 2024. Qwen2.5-coder technical report. arXiv:2409.12186. [27] Juyong Jiang, et al. 2024. A Survey on Large Language Models for Code Generation. arXiv:2406.00515. [28] Carlos E. Jimenez, et al. 2024. SWE-bench: Can Language Models Resolve Real-world Github Issues? ICLR. [29] Roman Kochnev, et al. 2025. Optuna vs Code Llama. arXiv:2504.06006. [30] Sachit Kuhar, et al. 2025. LibEvolutionEval. NAACL. [31] Yujia Li, et al. 2022. Competition-Level Code Generation with AlphaCode. arXiv:2203.07814. [32] Linxi Liang, et al. 2025. RustEvo2. arXiv:2503.16922. [33] Nelson F. Liu, et al. 2024. Lost in the Middle: How Language Models Use Long Contexts. TACL 12. [34] Ziyang Luo, et al. 2024. WizardCoder. ICLR. [35] Antonios Makris, et al. 2019. Performance Evaluation of MongoDB and PostgreSQL for Spatio-temporal Data. EDBT/ICDT Workshops. [36] Thomas Neumann. 2011. Efficiently Compiling Efficient Query Plans for Modern Hardware. PVLDB 4, 9. [37] Shoumik Palkar, et al. 2017. A Common Runtime for High Performance Data Analysis. CIDR. [38] Terence J. Parr, Russell W. Quong. 1995. ANTLR: A predicated-LL(k) parser generator. Software: Practice and Experience. [39] Karthik Ramachandra, et al. 2017. Froid: Optimization of Imperative Programs in a Relational Database. PVLDB 11, 4. [40] Stefano Rando, et al. 2025. LongCodeBench. arXiv:2505.07897. [41] Leonhard F. Spiegelberg, et al. 2021. Tuplex: Data Science in Python at Native Code Speed. SIGMOD. [42] Qwen Team. 2025. Qwen3 Technical Report. arXiv:2505.09388. [43] Haoran Wang, et al. 2025. SWE-Dev. ACL Findings. [44] Xingyao Wang, et al. 2024. OpenDevin. arXiv:2407.16741. [45] Michel Wermelinger. 2023. Using GitHub Copilot to Solve Simple Programming Problems. SIGCSE. [46] John Yang, et al. 2024. SWE-agent: Agent-Computer Interfaces. NeurIPS. [47] Shunyu Yao, et al. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR. [48] Weiqiu You, et al. 2025. Probabilistic Soundness Guarantees in LLM Reasoning Chains. arXiv:2507.12948. [49] Wei Zhou, et al. 2025. Cracking SQL Barriers: An LLM-based Dialect Translation System. PACMMOD 3, 3. [50] Wei Zhou, et al. 2025. CrackSQL. arXiv:2504.00882. [51] Wei Zhou, et al. 2025. PARROT. NeurIPS. [52] Wei Zhou, et al. 2024. Breaking It Down: An In-depth Study of Index Advisors. PVLDB 17, 10. [53] Wei Zhou, et al. 2026. DBAIOps. PVLDB 19, 6. [54] Wei Zhou, et al. 2026. Can LLMs Clean Up Your Mess? arXiv:2601.17058. [55] Xuanhe Zhou, et al. 2025. A Survey of LLM × DATA. arXiv:2505.18458. [56] Xuanhe Zhou, et al. 2025. OpenMLDB. SIGMOD Companion.

術語對照表