DSPy を用いた Datasette Agent の SQL システムプロンプトの評価と改善

**研究:** [DSPy を用いた Datasette Agent の SQL システムプロンプムの評価と改善](https://github.com/simonw/research/tree/main/dspy-datasette-agent-prompts#readme) 今朝の AIE の基調講演の一つで [dspy](https://github.com/stanfordnlp/dspy) が取り上げられ、これがきっかけとなって、[Datasette Agent](https://agent.datasette.io) で使用されているシステムプロンプトを改善できないか検討していたことを思い出しました。そこで、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](https://simonwillison.net/tags/ai), [datasette](https://simonwillison.net/tags/datasette), [generative-ai](https://simonwillison.net/tags/generative-ai), [llms](https://simonwillison.net/tags/llms), [evals](https://simonwillison.net/tags/evals), [dspy](https://simonwillison.net/tags/dspy), [datasette-agent](https://simonwillison.net/tags/datasette-agent), [claude-mythos](https://simonwillison.net/tags/claude-mythos) 前回の投稿では、DSPy を使用して Datasette Agent の SQL システムプロンプトを評価し改善するプロセスの前半について説明しました。今回はその続きとして、最終的な結果と、このアプローチがどのように機能したか（そしてなぜ失敗したのか）についての詳細な分析を行います。 最終的に到達したプロンプトは、以下の通りです： ```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 の分野における「自動化」の限界と可能性について深く考える機会となりました。技術的なツールの活用は重要ですが、それらを適切に使いこなすためには、深い理解と批判的思考が不可欠です。 次回の投稿では、これらの教訓を踏まえて、より堅牢な評価フレームワークの構築に向けた取り組みについて詳しく解説する予定です。また、実際のユーザーフィードバックを活用したプロンプト改善の実例も紹介したいと考えています。 ご意見やご質問があれば、ぜひコメント欄でお聞かせください。皆さんの知見が、この分野の発展に大きく貢献することでしょう。

DSPy を用いた Datasette Agent の SQL システムプロンプトの評価と改善

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト