【要約】Text-to-SQLの精度を評価したら、モデルより先に自分のプロンプトとコードのバグが3層見つかった [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がText-to-SQLツールを構築した際、定量的な精度が低い問題に直面した。単に「動く」という感触だけでは、システムの信頼性を担保できない。
- ・手動テストの「感触」に頼り、実測値に基づいた評価ができていなかった。
- ・SQLの文字列比較では、書き方の違いにより正解を判定できない課題があった。
- ・精度低下の原因がモデルの性能なのか、他の要因なのか判別不能であった。
// Approach
開発者は、SQLの文字列比較ではなく、実行結果を期待値と比較する手法を採用した。これにより、書き方の揺らぎを排除し、真の精度を測定可能にした。
- ・18問のテストセット（単一検索、JOIN、集計等）を作成。
- ・第1層：プロンプトに「指定列のみを返す」等の指示を追加。
- ・第2層：質問文と期待結果の整合性をとり、評価データの曖昧さを排除。
- ・第3層：SQL結果の辞書化におけるキー重複への対策を実施。
// Result
評価プロセスを通じて、モデルの性能向上に頼らずに精度を44.4%から100%へ引き上げた。これは、精度低下の真因が周辺環境にあることを証明した。
- ・プロンプトの指示不足による誤判定を解消。
- ・評価データセットの不備による誤判定を修正。
- ・Pythonの辞書化における実装バグを特定・修正。
Senior Engineer Insight
> LLMの精度向上において、モデルの調整に走る前に評価パイプラインを疑え。特に「評価データ」と「実装」の整合性は、実戦で致命的なバグを隠蔽する。評価データは実装と共に育てるべき動的なものである。