概要
コインチェック株式会社（以下、コインチェック） データ基盤グループの吉田です。この記事では、Google Cloud の Gemini in BigQuery を利用したSQL作成のプロセスにおいて、データセットにビジネスメタデータを付与することで、どの程度精度が向上するのか検証した結果について紹介します。
背景
あらゆる業界において AI の利活用が進む中、データ分析の効率化はどの企業にとっても重要な課題です。弊社においても、データ基盤の利用促進にあたって生成 AI の利用を推進することは必要不可欠でした。
データ分析基盤としての BigQuery にデータセットを揃え、ユーザーライクなユーザーマニュアルを展開したとしても、ユーザーが SQL を業務目的に応じて作成し分析を行うことは、日頃の業務において SQL を利用しないユーザーにとっては難しい課題です。
また膨大なデータセットの中で、知りたい情報を持つデータセットが特定できなければ、SQL を作成することすらままなりません。
そうした中で我々データ基盤グループでは、BigQuery のデータセットに対して、そのデータが何のデータなのかを説明するビジネスメタデータを付与することにしました。
データセットの意味情報をユーザーに提供し、生成 AI の精度を高め、データ基盤の利用を推進し、社内のデータリテラシーを高めることが目的です。しかしながら、多様なデータソースから構成されたデータ基盤を踏まえると、既存のデータセットにビジネスメタデータを付与するには、相応の工数が必要になります。
そのため、BigQuery のデータセットにビジネスメタデータを付与することで、どの程度生成 AI による SQL 作成の精度が向上するのか効果を明らかにするために、今回の検証に着手しました。
前提
ビジネスメタデータ
ビジネスメタデータとは、データセットに対してビジネス上のコンテキストを付与する情報です。例えば、データがどの部門に関連するか、あるいはどのような業務プロセスに利用されるかといった情報を含むことができます。
これにより、データ利用者がデータの意味をより簡単に理解できるようになり、分析作業がスムーズに進みます。また、Gemini in BigQuery の利用においても Gemini が参照するデータとして価値を持ちます。
検証用のデータセット
この検証で利用したデータは全て検証用のダミーデータです。これらは Gemini による SQL 生成の精度検証を目的として作成したものであり、コインチェックで取り扱っている個人情報や通貨名、データセット自体とはテーブルやカラム、その値まで全て異なるものです。
検証
検証用データセットの生成
精度検証のためのデータセット作成にあたっては、データセットの種類によって精度に差が出ることが想定されました。今回の検証対象である Gemini in BigQuery では、大規模言語モデルである Gemini が利用されており、このモデルのチューニングのために利用されたデータに、特定業界のデータが多く含まれていた場合には、モデル自体に得意不得意があるのではないか、と考えました。
例えば、そのモデルが広告業界のデータセットの扱いには向いていても、金融業界のデータセットの取り扱いには向いていないといったことが想定されます。このことから、ビジネスメタデータの付与による Gemini の SQL 生成の精度検証には、コインチェックと同じく暗号資産交換業のデータセットをサンプルとして生成して用いることにしました。
データセットの行数と列数について、データセットの行数が重要になるのは、SQL のパフォーマンスやスケーラビリティの観点です。クエリが大規模なデータセットに対してどれだけ効率的に実行されるか、または結果が正確に得られるかといった部分で、行数は大きな影響を与えます。しかしながら、今回の検証ではあくまで生成された SQL の “確からしさ” を検証することを目的としています。またBigQuery の課金体系においては、行数の多いデータセットへのクエリ実行はそれだけコストが増大するため、サンプルデータセットの行数は抑えることが必要でした。
こうした点を踏まえ、以下のようなサンプルデータセットを2種類ずつ（ビジネスメタデータあり/なし）を生成しました。
データセット名
- 取引データセット（トランザクション履歴など）
- ユーザーデータセット（顧客情報、プロファイルデータなど）
- マーケットデータセット（資産の市場動向など）
- アセットデータセット（暗号資産の種類に関する詳細など）
- サポートデータセット（カスタマーサポートやKYCデータ）
行列数
- 列数: 20
- 行数: 100
データセットの種類は暗号資産交換業において一般的に分析で使われているであろうものとし、列数は実際にデータ基盤で取り扱っているものと比較して差が大きくなりすぎないように20列としました。
テーブル例）
SQL生成と記録
自然言語スクリプトの作成
次のような、SQL を生成するためのプロンプト（自然文によるリクエスト）を50個作成しました。
- 機関投資家の参加が高いマーケットのデータを出してください。
- 2023年に行われたETHの取引ペアを持つ取引の詳細をすべて表示してください。
- 優先度が高いサポートチケットをエスカレーションレベル別に表示してください。
上記の Gemini の SQL 生成精度を評価するための自然言語によるプロンプトは、別の LLMにて生成しました。正確な文章になりすぎないように（ユーザーが生成するであろうもっともらしい文章となるように）自然言語のスクリプトを生成する LLM に与える情報は、データセットの概要のみとしました。
これでデータセットの構造を完全に理解していないユーザが生成するであろう自然言語のスクリプトを再現することとしました。
SQL 生成
作成したそれぞれのデータセットに対して自然言語によるスクリプトを与え、SQLを生成し出力結果を検証していきます。ビジネスメタデータなし／ありのデータセットに対して、同一のプロンプトで SQL を生成し、結果を記録します。
Gemini For BigQuery の使い方
- https://cloud.google.com/gemini/docs/bigquery/overview
それぞれの生成結果が正しいかどうか、スクリプトが意図する目的に対する SQL 出力が得られているかどうかは、目視で評価を行い定性的に判定しました。
評価一例）
結果
比較結果は以下となりました。
- ビジネスメタデータ"なし"のデータセット群に対するSQLの正答率
スコア: 23/50
- ビジネスメタデータ"あり"のデータセット群に対するSQLの正答率
スコア:43/50
ビジネスメタデータありのデータセットの場合、自然文のプロンプトから生成されるSQLの精度が、40%ほど向上しました。
考察
この検証結果からわかることは、生成AIによるSQL作成において、カテゴリカルデータ（列挙型のデータ配列を持っているカラム）にはメタデータの付与は必須であるということです。
例えば、gender(0:male 1:female 2:other)といった enum（列挙型）のカラムも、カラムの値それ単体の情報のみでは、その値が何を示す情報であるか、生成AIであっても判断することができません。
カテゴリカル変数を INTEGER 型のままデータ基盤で扱う場合、今回のようなメタデータ整備の効果は非常に高いといえるでしょう。
Gemini は、INTEGER 型については前提となる情報がない場合、ほぼ当てずっぽうのSQLとなっていましたが、STRING 型に対するクエリであれば、ビジネスメタデータがないカラムであっても、カラム名などから高い精度でSQLを生成していました。
カラム名と値が直感的に理解できる（STRING）値に対するメタデータの付与は、SQL の精度向上を目的とした施策においては大きな効果は得られないとも考えられます。
まとめ
今回の検証では、データセットにビジネスメタデータを付与することで、GeminiによるSQLクエリ作成精度が40%ほど向上することが確認されました。現実の多様なデータセットに適用して、必ずしも同じ効果が得られるとは言えませんが、BigQueryのデータセット群に対するビジネスメタデータの付与は、生成 AI による SQL 作成の精度向上に非常に有効と考えられます。
このアプローチは、SQL知識を持たないビジネスユーザーにデータ分析を活用してもらう目的において重要なアプローチであると考えています。データ分析の精度とスピードを高めるために、ビジネスメタデータの付与は今後ますます重要な要素となるでしょう。
実際のデータ基盤におけるメタデータのリッチ化については、データ基盤Gのインターンのメンバーが進めてくれているので、そちらについても後日ご紹介できればと考えていますのでご期待いただければと思います。
最後に
ここまでお読みいただきありがとうございました。生成AIは便利なツールですが、より良く利用するためには、必要な情報をより適切な形で与えることが必要不可欠であると改めて感じます。この検証結果が他の企業やデータエンジニアの方々にとって参考になることを願っています。
