Text-to-SQLベンチマークは「現実世界のデータストア」が抱える難題に向き合うべきだ

Text-to-SQLの性能評価において、既存のベンチマークが現実の複雑なデータ環境をどこまで反映できているかは議論の余地があります。実際の現場におけるデータ構造の歪さや制約、そしてノイズの多さに対応できるモデルこそが真に価値があるはずです。実運用に耐えうるシステムを目指すなら、今のベンチマークにはより過酷でリアルな条件設定が求められています。

友人がこれに関連したスタートアップを立ち上げて、技術的な知識がない人でも「自然言語を使ってデータベースをクエリする」ことを可能にしているよ： https://www.blazesql.com/ (https://www.blazesql.com/) どうやって実現したのかはよく分からないけど（TFAを信じるなら）、クエリ生成と結果はかなり堅牢な印象。

興味深いね…。今の職場で、チームと一緒にまさにこの問題を解決しようとしているところ。LLMに自分たちのSQLデータウェアハウスを理解させて、クライアントの分析的な質問に答えてもらうっていう課題。記事にある通り、20年物の腐りかけたスキーマを持つデータベースを抱えてるから、しっかり構造化されて管理された形に作り直す必要があったんだ。その大変な作業が終わった後、ビジネスメトリクスの上にdbtモデルを載せて、モデルのYAMLファイル（と共通のMDファイル）で、セマンティックな情報やメタデータをたっぷり含めるようにした。

それからソフトウェアエンジニアリングチームがdbtモデルを取り込んで（戦術的にdbtモデルを作る必要があった。つまり、実装する時に「どうすればLLMのハルシネーションを減らせるか」を常に考えなきゃいけない）、セマンティックレイヤーからの情報を使ってLLMのコンテキストを構築し、それを使って分析的な質問に答える仕組みにしてる。今のところ、かなり見込みがある感じ。ただ、記事の著者が示唆していたような「精度ゼロ」ってことはないよ。前四半期にdbtとセマンティックレイヤーで30個くらいのメトリクスを作って、リサーチチームとアナリティクスチームにLLMアプリの内部テストをお願いしたんだ。このアプローチの精度がどれくらいか、近いうちにフィードバックでわかるはず。

> LLMはこれまでに見たことのあるデータしか見つけられないということは広く知られている。

これってどういう意味？文字通りに受け取ると明らかに間違いだし、著者は何を伝えようとしているんだろう？

SQLを知らないビジネスユーザーがLLMを使ってSQLを書く際の一番の問題は、そのクエリを検証する人が誰もいないってこと。そのせいでビジネスユーザーはLLMの回答を「正」として扱い、会議やプレゼン、クライアントとのやり取りでそのまま使ってしまう。LLMはフィルタを忘れていたり、収益の定義を間違えていたり、ユーザーの意図を誤解して質問に対する回答を最も字義通りに書いてしまったりする可能性があるからね。

それが問題の核心だよ。プロンプトの曖昧さを解消するためにLLMがユーザーの心を読めるようになるまでは、どんなにセマンティックレイヤーやコンテキストを充実させても解決しないはず。

LLMの最大のメリットは、SQLを知っているアナリストがもっと生産的に仕事をするために使うことにあると思ってる。