エンタープライズ データ ウェアハウスは、過去 20 年間におけるあらゆる業界の企業にとって最大のテクノロジー投資の多くを占めています。生成 AI は、斬新なコンテンツを作成したり、非構造化形式の情報の大規模なコーパスを理解したりする点で多くの期待を示していますが、組織が有益なものにするために多大な投資を行ってきたデータの消費をどのように改善するのでしょうか?これらのデータ ソースは組織内で最も信頼されており、多くの場合、最高レベルのリーダーシップの意思決定を推進します。
70 年代の創設以来、構造照会言語 (SQL) はデータベースと対話するための最も広く普及している言語ですが、データを理解するには依然として集合論、データ型、および外部キー関係を深く理解する必要があります。 。 Generative AI は、自然言語の質問を有効な SQL クエリに変換することで、この知識とスキルのギャップを埋める方法を提供します。
データベースへのこのアクセス パターンから恩恵を受けるシステムや人々には、カスタマー サービス エージェントやコールセンターの従業員など、プロセスにリレーショナル データ ソースを組み込もうとしている非技術者も含まれます。さらに、技術的な使用例には、抽出、変換、読み込みパイプライン、リレーショナル データベースを統合する既存の検索拡張生成 (RAG) アーキテクチャ、および分離して合理的にナビゲートするには大きすぎるデータ プラットフォームを扱う組織が含まれます。
自然言語から正確な SQL クエリを作成する最も難しいコンポーネントは、私たちがその言語を初めて使用したときに苦労したかもしれないコンポーネントと同じです。外部キー関係の特定、質問をより小さなネストされたクエリへの分割、テーブルの適切な結合などの概念は、SQL クエリ生成の最も難しいコンポーネントの 1 つです。研究者によると、SQL 生成テストの 50% 以上がスキーマ リンクと結合だけで失敗します。
クエリのこれらのコア コンポーネントに加えて、各データベース エンジンには、有効なクエリを作成するために習得する必要がある独自の構文があります。さらに、多くの組織では、重複するデータ属性が多数存在します。たとえば、値が 1 つのテーブルに集計され、別のテーブルには集計されません。また、正しく使用するには固有の知識が必要な短縮列名も存在します。
では、私たちはこの問題の解決にどれくらい近づいているでしょうか?コミュニティは、ラベル付きデータセットを使用して最も成功したアプローチをランク付けする 2 つの主要なリーダーボード、Spider と BIRD を中心に結集しました。どちらのリーダーボードも、実行精度 (EX) と呼ばれる、この問題を解決するための特定のアプローチの精度を測定するための最も重要な指標を優先します。このメトリクスは、生成された SQL クエリとラベル付き SQL クエリを単純に比較して、一致するかどうかを判断します。さらに、SPIDER は、クエリの作成方法に関係なく、返された結果セットが実際に質問に答えているかどうかの完全セット一致精度 (EM) を測定します。また、BIRD は、生成された SQL クエリのパフォーマンスを測定する有効効率スコア (VES) を提供します。各ベンチマーク データ セットの詳細については、それぞれのページを参照してください。
Spider および BIRD データセットは、Text-to-SQL 技術のベンチマークを行うため、さらにはモデルの微調整を行うための信頼できる堅牢なデータ セットであることが証明されています。このモジュール全体を通じて、これらのデータセットとそれに対応するリーダーボードを参照して、Text-to-SQL への最も堅牢なアプローチを示します。
BIRD リーダーボードによると、Text-to-SQL 問題の最先端の実行精度は 60% です。これはまだ人間のパフォーマンスには遠く及ばないものの、ベースラインの T5 モデルの 7% EM パフォーマンスから 1 年後には EM が 60% を超えていることに注目してください。これらのモデルと技術の研究が継続されているため、来年にこれがどのように改善されるかを見るのが楽しみです。
これらの手法は、正しい SQL クエリを生成するという 1 つのことに対して最適化されていることに注意することが重要です。これらのリーダーボードは、これらのテクニックのいくつかの重要な側面、最も重要な速度を評価しません。これらの手法の多くは、数秒をはるかに超えるエンドツーエンドのプロンプト チェーン速度を示していますが、多くのゼロショット ビジネス インテリジェンスのユース ケースではこれが許容できません。さらに、それらの多くは、必要な推論を完了するために LLM に対して複数の推論を行うため、クエリあたりのコストが大幅に上昇する可能性があります。
このワークショップは、堅牢なプロンプト エンジニアリングから始めて、Text-to-SQL テクニックを発展させるように設計されています。すべてのコードは Jupyter Notebook の形式であり、SageMaker Studio でホストされます。開始する準備ができたら、[セットアップ] に移動して、このワークショップに必要なリソースの展開を開始します。
ワークショップの内容の概要は以下の通りです。