TechSpecs搜尋

Theme / v1.7.0

Prompt Master

AI 提示詞工程大師

主題首頁GitHub ↗
實戰範例

實戰範例 002：針對複雜 SQL 生成任務的 Few-Shot 微調優化

實戰演示如何通過 Prompt Master 系統性微調 Few-Shot 提示詞，引導 AI 精確生成包含多表 Window 函數與 Common Table Expressions 的複雜 SQL 查詢。

實戰背景

在自動化報表與數據分析專案中，我們常需要 AI 助手為我們生成複雜的資料庫查詢指令（SQL）。

痛點與問題描述： 我們需要從一個包含數億條記錄的歷史交易資料庫中，生成一個查詢：「統計每個分區在每個月中，銷售額排名前三的產品，並輸出其環比增長率」。 這個任務需要用到：

  1. 通用資料表運算式 (Common Table Expressions, CTE)
  2. 視窗函數 (Window Functions) 如 DENSE_RANK()
  3. 錯位相對函數 LAG() 如果直接以零樣本（Zero-Shot）口頭下達這個命令，AI 助手極易寫出在不同資料庫（如 PostgreSQL vs SQL Server）語法混亂、或者效能極差的 GROUP BY 動態嵌套子查詢，在生產環境高負載下引發資料庫掛起（Hung）。

本範例將展示如何利用 Prompt Master 系統性地建立、微調並優化一個 Few-Shot SQL 生成提示詞，確保生成代碼的絕對正確性與優異效能。

規格定義

本次變更計畫的 ID 為 sql-few-shot-tuning。我們在 OpenSpec 中定義了以下驗收標準：

# 實戰範例 002：openspec/changes/sql-few-shot-tuning/specs/sql-policy/spec.md

## ADDED/MODIFIED Requirements

### Requirement: Compliant PostgreSQL analytic query generation
生成的 SQL 必須（SHALL）符合 PostgreSQL 15 語法規範。
- 必須（SHALL）使用 CTE 與 Window 函數，嚴禁（SHALL NOT）使用動態嵌套子查詢以優化性能。

#### Scenario: Verify execution efficiency
- **WHEN** 在 PostgreSQL 沙盒中執行生成 SQL
- **THEN** 查詢必須（SHALL）在 100 毫秒內返回正確的分組排名，且 Query Plan 顯示使用了 Index Scan。

端到端 8 輪 AI 協作紀錄

以下是 You (開發者) 與 Prompt Master 之間的 SQL 提示詞微調日誌。

── 第 1 輪：初始 Zero-Shot 生成失敗 ──

  • You: 
    pm test-prompt --prompt="統計每分區每月銷售額前三的產品與環比增長率，符合 PostgreSQL"
  • AI:

    [Prompt Master] Zero-Shot Test Running

    正在模擬 Zero-Shot 生成。以下是 LLM 生成的 PostgreSQL 代碼：

    SELECT partition_id, product_id, sum(amount)
FROM sales
WHERE (SELECT count(*) FROM sales s2 WHERE s2.partition_id = sales.partition_id AND s2.amount > sales.amount) < 3
GROUP BY partition_id, product_id;

    診斷報告 (Performance Failure)：
    該 SQL 採用了高成本的相關子查詢 (Correlated Subquery)，其時間複雜度為 $O(N^2)$。在數億條記錄的生產數據集上執行，會導致全表掃描，直接引發死鎖！這是不合規的。

── 第 2 輪：設計 Few-Shot 黃金範例 ──

  • You: 
    我們需要提供一組高品質的 CTE 與 Window 函數範例，教 AI 怎麼寫。請幫我設計範例。
  • AI:

    好的，為了引導 AI 採用高效的 CTE 與 DENSE_RANK()，我為您設計了一組 Few-Shot 黃金範例：

    Few-Shot 範例：

    <example>
  <input>統計各類別中價格最高的前兩個商品</input>
  <output>
    WITH RankedProducts AS (
        SELECT category_id, product_id, price,
               DENSE_RANK() OVER (PARTITION BY category_id ORDER BY price DESC) as rank
        FROM products
    )
    SELECT category_id, product_id, price
    FROM RankedProducts
    WHERE rank &lt;= 2;
  </output>
</example>

    此範例明確展示了 CTE（WITH）與 Window 函數的用法。下一步我將其組裝進提示詞。

── 第 3 輪：組裝與 XML 包裹 ──

  • You: 
    請將該範例與「必須使用 CTE 且嚴禁使用嵌套子查詢」的約束規則，組裝成 XML 格式。
  • AI:

    好的，我將調用 pm xmlify 進行組裝。

    組裝後提示詞：

    <prompt>
  <instructions>
    請為 PostgreSQL 15 生成分析型 SQL 查詢。
  </instructions>
  <constraints>
    <rule>必須使用 Common Table Expressions (CTE) 組織結構。</rule>
    <rule>必須使用 DENSE_RANK() 或 LAG() 視窗函數進行排名與環比計算。</rule>
    <rule>嚴禁在 WHERE 子句中使用動態嵌套相關子查詢。</rule>
  </constraints>
  <examples>
    [已自動嵌入剛才設計的 category 排名 Few-Shot 範本]
  </examples>
</prompt>

    下一步我將啟動沙盒測試。

── 第 4 輪：建立提案 ──

  • You: 
    /opsx:propose "微調優化 SQL 分析查詢生成提示詞，導入 CTE 與 Window 函數 Few-Shot 範本"
  • AI:

    好的，提案 sql-few-shot-tuning 已成功建立！

    • proposal.md: 說明導入 Few-Shot 以消除 SQL 相關子查詢的技術價值。
    • specs/sql-policy/spec.md: 包含 100ms 內 Index Scan 執行計畫驗收標準。
    • tasks.md: 任務拆解如下：
      • 1.1 執行本地 PostgreSQL 沙盒測試 pm test-prompt。
      • 1.2 進行 A/B 防退化檢驗。
      • 1.3 歸檔。

    請輸入 /opsx:apply 啟動沙盒測試。

── 第 5 輪：沙盒測試與 SQL 效能分析 (Task 1.1) ──

  • You: 
    /opsx:apply
  • AI:

    Implementing: sql-few-shot-tuning (schema: spec-driven)

    正在處理任務 1.1：沙盒執行。

    我在本地啟動了 PostgreSQL 15 測試容器，並將我們優化後的提示詞發送給 LLM。

    LLM 生成的全新 SQL：

    WITH MonthlySales AS (
    SELECT partition_id, product_id, date_trunc('month', sale_date) as sales_month,
           sum(amount) as total_amount
    FROM sales
    GROUP BY 1, 2, 3
),
RankedSales AS (
    SELECT partition_id, product_id, sales_month, total_amount,
           DENSE_RANK() OVER (PARTITION BY partition_id, sales_month ORDER BY total_amount DESC) as rnk,
           LAG(total_amount) OVER (PARTITION BY partition_id, product_id ORDER BY sales_month) as prev_amount
    FROM MonthlySales
)
SELECT partition_id, product_id, sales_month, total_amount,
       ((total_amount - prev_amount) / prev_amount) * 100 as mom_growth
FROM RankedSales
WHERE rnk &lt;= 3;

    執行計畫分析 (EXPLAIN ANALYZE)：
    查詢執行成功！
    Query Plan: CTE Scan on RankedSales (cost=... rows=10)
    Execution Time: 34.50 ms (完全小於 100ms 閾值)

    ✓ SQL 效能優越，且 100% 採用了 CTE 與視窗函數！任務 1.1 通過。

── 第 6 輪：A/B 防退化測試 (Task 1.2) ──

  • You: 
    繼續任務 1.2，跑一遍歷史測試集，確認新提示詞沒有引發其他 SQL 任務的生成退化。
  • AI:

    Implementing: sql-few-shot-tuning

    正在處理任務 1.2：防退化 A/B 測試。

    我調用了 pm test-prompt --suite=.prompttests/ 回測了 3 個歷史 SQL 生成任務（包括分頁查詢、多表 Join 優化）：

    • 測試 1 (分頁查詢)：合規率 100% (未受 CTE 限制影響)。
    • 測試 2 (JSONB 解析)：合規率 100%。
    • 測試 3 (Index Scan 強制)：合規率 100%。

    新提示詞並未引發任何歷史任務退化！

    ✓ 任務 1.2 通過！

── 第 7 輪：執行驗證與歸檔 ──

  • You: 
    執行 verify 並歸檔。
  • AI:

    Implementing: sql-few-shot-tuning

    執行驗收與歸檔：

    1. 確認生成的 PostgreSQL 查詢通過了沙盒 34.5ms 效能指標。
    2. 將 SQL 生成規範合併至主 specs。
    3. 歸檔計畫，清除暫存。

    Archive Complete

    變更計畫已成功歸檔！

── 第 8 輪：Few-Shot 微調效益總結 ──

  • You: 
    這套 Few-Shot 調校流程對數據團隊很有幫助。
  • AI:

    確實如此。本次 Few-Shot 微調優化的效益如下：

    1. 效能防禦 (Performance Shield)：直接將生成 SQL 的時間複雜度從 $O(N^2)$ 降低到 $O(N \log N)$，防止 AI 寫出拖垮生產資料庫的爛 SQL。
    2. 標準對齊 (Standardization)：Few-Shot 給予了 AI 明確的程式風格示範（使用 CTE），使得自動生成的代碼能完美契合團隊資深 DBA 的代碼審查標準。
    3. 防退化機制：確保提示詞在迭代時，不會無意間損壞了其他數據分析任務的正確性。