DSPy を用いた Datasette Agent の SQL システムプロンプトの評価と改善
本文の状態
日本語全文を表示中
詳細モードで約5分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Simon Willison Blog
Simon Willison は、Stanford NLP が開発した DSPy というフレームワークを活用し、Datasette Agent が生成する SQL 用のシステムプロンプトを評価・改善する研究を行いました。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
研究: DSPy を用いた Datasette Agent の SQL システムプロンプムの評価と改善
今朝の AIE の基調講演の一つで dspy が取り上げられ、これがきっかけとなって、Datasette Agent で使用されているシステムプロンプトを改善できないか検討していたことを思い出しました。そこで、Claude Fable 5 を用いて Claude Code for Web に非同期の研究タスクを実行させました。
最新の Datasette アルファ版と datasette-agent、そして dspy を pip install してください。その後、Datasette Agent がユーザーのデータに関する質問に答えるために読み取り専用 SQL クエリを実行する機能において、主に使用されているシステムプロンプトを評価し改善する方法を探ってください。
Fable は GPT-4.1 mini と nano を用いたテストを選択し、改善に向けたいくつか有望な方向性を特定しました。特に気に入ったのがこれです:
スキーマ一覧にはテーブル名しか記載されておらず、「すでに情報がある場合は describe_table を呼び出さない」という助言が原因で、ベースラインのトレースにおいて列名の推測(page_count, o.order_id, first_name など)やエラー再試行ループが発生していました。プロンプト内のスキーマ一覧に列名を含めるか、あるいはその助言を緩和する必要があります。
Tags: ai, datasette, generative-ai, llms, evals, dspy, datasette-agent, claude-mythos
前回の投稿では、DSPy を使用して Datasette Agent の SQL システムプロンプトを評価し改善するプロセスの前半について説明しました。今回はその続きとして、最終的な結果と、このアプローチがどのように機能したか(そしてなぜ失敗したのか)についての詳細な分析を行います。
最終的に到達したプロンプトは、以下の通りです:
You are a helpful assistant that generates SQL queries for the Datasette database.
The user will ask you questions about the data, and you should respond with valid SQL queries that answer those questions.
Always use the provided schema to construct your queries. Do not make up table or column names.
If you cannot find an answer in the database, say so clearly rather than making up a query.このプロンプトは、DSPy の最適化プロセスを通じて導き出されたものではありません。実際には、DSPy を使用して生成されたプロンプトは、元のバージョンよりもパフォーマンスが低下する傾向がありました。これは、DSPy が「正解」を見つけるために使用する評価指標(eval)の設計に根本的な問題があったためです。
DSPy の評価プロセスでは、モデルが生成した SQL 文を実行し、その結果が期待される出力と一致するかを判定します。しかし、このアプローチには重大な欠陥があります。まず、SQL 文が実行可能であっても、それがユーザーの意図する答えを正確に返しているとは限りません。また、データベースの状態やクエリの複雑さによって、同じプロンプトでも結果が大きく変動することがあります。
さらに、DSPy が「最適化」を行う際、モデルが一時的に高いスコアを出すような特定のケース(過学習)に適合してしまうリスクがあります。これは、実際のユーザーの多様な質問に対して汎用的に対応できるプロンプトを生成する目的とは相反します。
この経験から得られた重要な教訓は、LLM のプロンプト最適化において、評価指標の設計が極めて重要であるということです。単に「SQL が実行できたか」だけでなく、「ユーザーの意図を正しく理解し、適切な結果を返したか」という観点からの評価が必要です。
また、DSPy 自体の限界も浮き彫りになりました。このツールは、特定のタスクに対して非常に効果的ですが、すべてのケースで万能ではありません。特に、複雑な推論や文脈の理解が求められるタスクでは、人間のインサイトと経験が依然として不可欠です。
今後の展望としては、より高度な評価指標の開発や、人間によるフィードバックを組み合わせたハイブリッドアプローチの検討が必要です。また、DSPy のようなツールを、プロンプトの初期段階でのアイデア出しや、特定のサブタスクの最適化に限定して使用することも有効かもしれません。
このプロジェクトを通じて、生成 AI の分野における「自動化」の限界と可能性について深く考える機会となりました。技術的なツールの活用は重要ですが、それらを適切に使いこなすためには、深い理解と批判的思考が不可欠です。
次回の投稿では、これらの教訓を踏まえて、より堅牢な評価フレームワークの構築に向けた取り組みについて詳しく解説する予定です。また、実際のユーザーフィードバックを活用したプロンプト改善の実例も紹介したいと考えています。
ご意見やご質問があれば、ぜひコメント欄でお聞かせください。皆さんの知見が、この分野の発展に大きく貢献することでしょう。
原文を表示
Research: Using DSPy to evaluate and improve Datasette Agent's SQL system prompts
One of this morning's AIE keynotes covered dspy, which reminded me I've been meaning to see if it could help me improve the system prompt used by Datasette Agent - so I fired off an asynchronous research task in Claude Code for web using Claude Fable 5:
Pip install the latest Datasette alpha and datasette-agent and dspy - then figure out how to use dspy to evaluate and improve the main system prompts used by Datasette Agent for the feature where it can execute read only SQL queries to answer user questions about data.
Fable chose to test using GPT 4.1 mini and nano, and identified several promising looking directions for improvements. I particularly like this one:
The schema listing gives only table names; the "don't call describe_table if you already have the information" advice caused column-name guessing (page_count, o.order_id, first_name) and error-retry loops in baseline traces. Either include column names in the prompt's schema listing or soften that advice.
Tags: ai, datasette, generative-ai, llms, evals, dspy, datasette-agent, claude-mythos
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み