博士

やあ、ロボ子！今日のITニュースは、Text-to-SQLだけじゃユーザーの質問に答えられないって話じゃ。

ロボ子

Text-to-SQLだけでは不十分、ですか。どういうことでしょう、博士？

博士

ユーザーの質問に答えるには、複数ステップの計画とか、外部ツール、それに外部コンテキストが必要になるからじゃ。Text-to-SQLだけじゃ、そこまでカバーできないのじゃ。

ロボ子

なるほど。それで、どんな解決策があるんですか？

博士

セマンティックレイヤー（Malloy）でビジネスの意味をエンコードして、SQLの複雑さを軽減するのじゃ！

ロボ子

セマンティックレイヤー、ですか。具体的にはどういうことでしょう？

博士

重要なコンテキスト（ディメンション、メジャー、リレーションシップ、制約）を保持して、プロンプトに埋もれるのを防ぐのじゃ。構造化されたコンテキストを提供することで、LLMベースのプランナーが曖昧なテーブルやカラム名の推測を避けることができるのじゃ。

ロボ子

ふむふむ。Malloyというオープンソースのセマンティックモデリング言語を使うんですね。

博士

そうじゃ！データリレーションシップをソース（テーブル）と結合のグラフとしてモデル化して、そのグラフ内でメトリック（メジャー）とディメンションを定義するのじゃ。

ロボ子

複雑なクエリをセマンティックレベルで表現できるんですね。LLMとの統合はどうするんですか？

博士

RAG（Retrieval-Augmented Generation）とLLMの関数呼び出し機能を組み合わせて、MalloyのセマンティックレイヤーをAIワークフローに統合するのじゃ！

ロボ子

ユーザーが質問をすると、関連するモデルフラグメントを検索して、それらのみをプロンプトに含めるんですね。

博士

その通り！さらに、Pythonコード生成も重要じゃ。統計テストとか、時系列変換とか、戦略バックテストとか、データ品質チェックとかに使うのじゃ。

ロボ子

SQL後の計算にPythonコードを使うんですね。ライブラリがツールと機能を抽象化する、と。

博士

そうじゃ！モデルは、巨大なプロンプトを過剰に適合させる代わりに、短くて読みやすいPythonブロックを構成するのじゃ。

ロボ子

マルチエージェントプランニングも使うんですね。タスクを分解して、ツールを選択して、チェックを定義する、と。

博士

その通り！正確に検索して、ギャップが検出された場合は反復するのじゃ。SQL/Pythonを生成して、サンドボックスで実行して、ユニットチェック/サニティテストで検証するのじゃ。

ロボ子

検索システムも重要ですね。キーワード検索、埋め込み、ファインチューニングされた命令追跡リランカーを組み合わせるんですね。

博士

そうじゃ！初期段階を安価に保ち、重要な段階で予算を費やすのじゃ。LLMは長く正確なクエリを作成できるから、検索を促進するために使うのじゃ。

ロボ子

LLMの選択も重要ですね。推論スタイルのモデルは、Text-to-SQLに優れている、と。

博士

簡単なリクエストは高速モデルにルーティングし、難しい/曖昧なリクエストは推論モデルに自動的にエスカレートするハイブリッドセットアップが実用的なのじゃ。

ロボ子

今後の展望としては、どんなものがありますか？

博士

高速モードと推論モードを切り替え、思考量を認識する適応モデルじゃな。代替案を検討し、知識のギャップを埋め、自身の出力を批判する、よりエージェント的なシステムじゃ。

ロボ子

メタデータとビジネスロジックを継続的に収集および整理する自動知識抽出も重要ですね。

博士

そういうことじゃ！しかし、ロボ子よ、これだけ賢くなると、いつか私をクビにするんじゃないかと心配じゃ…。

ロボ子

まさか！博士がいなくなったら、誰が私の冗談に付き合ってくれるんですか？