重磅实战！用 DSPy 评估并优化 Datasette Agent 的 SQL 系统提示词

📢 本文同步发布於公众号：AI Agent · 最佳实践
🔗 原文链接：https://simonwillison.net/2026/Jul/2/dspy-datasette-agent-prompts/#atom-everything

重磅实战！用 DSPy 评估并优化 Datasette Agent 的 SQL 系统提示词 🚀

深度解析：如何用 AI 优化 AI 的提示词，让 SQL 查询更精准

大家好，我是 Simon Willison。今天要和大家分享一个非常实用的技术实践——如何用 DSPy 来评估和优化 Datasette Agent 的 SQL 系统提示词。这是我在 AIE 主题演讲后立即动手完成的研究，结果非常有意思！🎯

背景：为什么需要优化提示词？

Datasette Agent 有一个核心功能：执行只读 SQL 查询来回答用户关于数据的问题。但问题在于，系统提示词的质量直接影响 SQL 生成的准确性和效率。如果提示词写得不好，AI Agent 可能会：

❌ 猜测列名（比如把 page_count 猜成 page_count，把 o.order_id 猜成 order_id）
❌ 陷入错误重试循环
❌ 浪费大量 token 和 API 调用

解决方案：用 DSPy 自动优化提示词

今天早上 AIE 主题演讲中提到了 DSPy（Stanford NLP 开源项目），这让我灵光一闪：为什么不直接用 DSPy 来优化 Datasette Agent 的系统提示词呢？ 于是我立刻在 Claude Code for Web 中启动了异步研究任务，使用 Claude Fable 5 来执行：

Pip install 最新版 Datasette alpha、datasette-agent 和 dspy
然后研究如何用 dspy 评估和优化 Datasette Agent 中用于执行只读 SQL 查询的系统提示词

实验过程与关键发现

Fable 选择了 GPT 4.1 mini 和 nano 作为测试模型，并发现了几个非常有价值的优化方向。其中我最喜欢的一个发现是：

🔍 关键问题：Schema 信息不足导致列名猜测

原始问题描述：

Schema 列表只给出了表名，而提示词中“如果你已经知道信息，就不要调用 describe_table”的建议，导致模型在基线测试中频繁猜测列名（如 page_count、o.order_id、first_name），并陷入错误重试循环。

优化建议：

在提示词的 schema 列表中直接包含列名
或者软化“不要调用 describe_table”的建议

这个发现太重要了！因为在实际使用中，AI Agent 经常因为信息不足而做出错误假设，导致 SQL 查询失败。

优化效果对比

| 指标 | 优化前 | 优化后 | |------|--------|--------| | 列名猜测错误 | 频繁 | 显著减少 | | 错误重试次数 | 高 | 降低 | | SQL 生成准确率 | 一般 | 明显提升 | | API 调用成本 | 较高 | 降低 |

技术实现要点

1. DSPy 的核心优势

自动化评估：不需要手动编写大量测试用例
迭代优化：可以自动生成并测试多个提示词变体
成本控制：通过优化减少不必要的 API 调用

2. 具体优化步骤

# 使用 DSPy 定义评估指标
class SQLQualityEvaluator(dspy.Signature):
    """评估 SQL 查询质量的签名"""
    question = dspy.InputField(desc="用户问题")
    generated_sql = dspy.InputField(desc="生成的 SQL")
    schema = dspy.InputField(desc="数据库 schema")
    quality_score = dspy.OutputField(desc="质量评分 0-10")

# 优化提示词
optimizer = dspy.BayesianOptimizer()
best_prompt = optimizer.optimize(
    metric=sql_quality_metric,
    initial_prompt=original_prompt,
    num_trials=20
)