ガバナンスされたSQL、メダリオンセマンティックレイヤー、そして3つのクエリエンジンが、幻覚によるカラム名なしでエンタープライズデータを実際にクエリ可能にする方法。

ほとんどのText-to-SQLデモは、本物のエンタープライズデータで試すまで素晴らしいように見えます。「先四半期の売上トップ10の資材は何か」と尋ねると、モデルは自信たっぷりにORDERSとPRODUCTSを結合するクエリを返しますが、これらのテーブルはSAPシステムに存在しません。また、SAPコンサルタントとして何年も過ごさないと意味がわからないVBAK.NETWRというフィールドに埋もれた本物のカラムではなく、revenueという名前のカラムを発明します。

これが、私たちがOnibex ASKで解決しようとした問題です。ASKはAgentic Semantic Knowledgeの略で、SAPデータ上で自然言語をガバナンスされたSQLに変換するオープンなプラットフォームです。「ガバナンスされた」という言葉はこの文で大きな役割を果たしており、それが何を意味し、なぜすべてを変えるのかを正確に解明する価値があります。

LLMは発明者ではなくコンパイラであるべき

ほとんどのText-to-SQLシステムはLLMにデータベーススキーマを与え、「解決せよ」と要求します。これは単純なスキーマでは驚くほどうまく機能します。明らかな名前のテーブルが数個あるだけです。しかし、SAP HANAスキーマは単純ではありません。実際のS/4HANAシステムには、数千のテーブル、難解な4文字のフィールド名、そして可読性ではなくパフォーマンスのために設計された結合条件が存在する可能性があります。

私たちのアプローチは異なります。LLMは構造を発明しません。ビジネス用語をキュレートされたセマンティックレイヤーにマッピングするだけです。

セマンティックレイヤー — 私たちがData Productsと呼ぶYAMLファイルのセット — が唯一の信頼できる情報源です。すべてのクエリの各フィールドは、実在するテーブルの実在するカラムに、正確な結合述語とともに追跡可能でなければなりません。LLMはコンパイラです。自然言語の質問を受け取り、レイヤー内の一致するビジネス用語を検索し、これらの解決されたマッピングからのみSQLを生成します。レイヤーに用語が存在しない場合、エージェントは推測するのではなく、明確化を求めます。

ユーザーが「資材別の売上は？」と尋ねると、ASKは「revenue」をsynonymsフィールド経由でVBAK.NETWRにマッピングします。VBAKからVBAPへの結合をData Productが定義しているため知っています。他のテーブルには決して触れません。SQLはLLMが異常に賢いからではなく、厳格なガードレール内で動作するため、再現可能で、監査可能で、決定的です。

SAPに適用されたメダリオンモデル

他のすべてを機能させた構造的な決定の1つは、セマンティックレイヤーに対してBronze/Silver/Goldメダリオンモデルを採用することでした。

Bronzeは生のSAPテーブルです。カラムと主キー、結合ロジックはありません。VBAK（販売注文ヘッダー）、VBAP（販売注文明細）、MARA（品目マスタ）。これらはASKが物理スキーマを理解するために存在します。

Silverはビジネスロジックが存在する場所です。Silverエンティティは複数のBronzeテーブルを一貫したビジネス概念に結合し、その概念の完全な結合トポロジを所有し、フィールドの役割（メジャー、ディメンション、識別子、タイムスタンプ）を定義します。Silverプレーンはエージェントのフォールバックです。Goldエンティティが質問をカバーしない場合、ASKはSilverから解決し、結合を計算します。

Goldは非正規化されたアナリティクスです。エージェントが単一スキャンでクエリできる事前結合、事前集約エンティティです。Goldエンティティが質問に必要な正確なメトリクスとディメンションをカバーする場合、ASKはGoldのみから回答します。結合なし、計画オーバーヘッドなし、最小限のレイテンシ。

質問：「Q1の純額による資材トップ10」│ ▼ Goldエンティティはこの質問をカバーするか？ ├─ はい → Goldテーブルに対する単一クエリ └─ いいえ → Silverエンティティ（VBAK + VBAP結合）を介して解決

このGold優先の解決が、スケール時にクエリレイテンシを妥当な範囲に保つものです。適切にモデル化されたGoldエンティティは、ビジネスユーザーが実際に尋ねる質問の80%をカバーします。Silverはロングテールに対応します。

異なるトレードオフのための3つのエンジン

最も長く格闘した質問の1つは、各クエリでエージェントにどれだけの計画をさせるべきかということでした。より多くの計画はより良いSQLを意味しますが、より多くのLLM呼び出し、より大きなレイテンシ、より高いコストも意味します。最終的に、ユーザーが管理者とこのトレードオフを明示的に行えるようにする3つのエンジンを出荷しました。

Flash
1回のLLM呼び出し · 約15秒 · 低コスト

スキーマをフリーテキストチャンクとして検索し、ワンショットでSQLを書き込みます。セマンティックプランなし、結合検証なし、スコープチェックなし。高速で安価 — 探索的な質問に適しています。再現性が最も低い：同じ質問を2回尋ねても、わずかに異なるSQLが生成される可能性があります。

Precise
3回のLLM呼び出し · 約60秒 · 高信頼性

Semantic Plan IRを抽出、Medallionリランキングを使用したハイブリッドkNN+BM25検索を実行、Dijkstraのアルゴリズムで結合を計画、SQLを生成し、許可されたテーブルセットに対して監査 — 範囲外に逸脱した場合は1回リトライします。完全に決定的なData Product選択。コンプライアンス、監査証跡、またはFlashが失敗した場合に使用します。

Smart
2回のLLM呼び出し · 約40秒 · デフォルト

LLMにコンパクトなカタログを表示し、関連するData Productsを選択させます。選択はモデル駆動です。しかし、選択後の結合計画はPreciseと同じDijkstraグラフを使用します。日常的な本番使用のための速度と精度のバランスを取ります。

この設計の背後にある洞察は、決定的さをどこに置くかが重要だということです。PreciseはData Productsの選択を決定的にします。Smartは結合計画を決定的にします。Flashは両方をモデルに委ねます。監査可能性を必要とするユーザーはPreciseを使用し、スループットを必要とするユーザーはSmartを使用し、速度を必要とするユーザーはFlashを使用します。

質問が曖昧な場合はどうなるか？

実際のエンタープライズデータには語彙の問題があります。「Sales」はSDモジュールのVBAKまたはMMのEKKOを意味する可能性があり、調達の観点から見ると異なります。「Revenue」はユーザーがFinanceかSalesかによって総額または純額を意味する可能性があります。

ASKはOpenSearchのセマンティック辞書インデックスに支えられた3レベルの曖昧性解消システムでこれを処理します。

レベル1: 用語が正確に1つのエンティティにマッピングされる場合、エージェントは自動的に解決します。中断はありません。

レベル2: 用語が異なるSAPモジュールにまたがって複数のエンティティにマッピングされる場合、エージェントは曖昧性解消メッセージを表示します。「SD販売注文を意味しますか、それともMM購買注文を意味しますか？」 — そして待機します。推測しません。

レベル3: 用語にマッピングがまったくない場合、エージェントはユーザーをAgentic Trainerに誘導する明確なメッセージを返します。決して幻覚による解決を行いません。

セマンティック辞書は、ASK Configuration Appを通じて管理者が管理します。これはReact SPAで、正規のフィールドラベル、SAPカラムマッピング、同義語、コンテキストヒント、モジュールごとの曖昧性解消ヒントを登録でき、すべてOpenSearchでハイブリッド検索用にインデックス化されています。

アーティファクト

アーティファクトは完全なビジネスドキュメントです。販売レポート、エグゼクティブブリーフ、データテーブルパック — すべて自然言語から生成されます。ユーザーは4ステップの会話型ウィザードで、名前、対象読者と目的、含めるデータ、形式をカバーして必要なものを記述します。エージェントは複数のSQLクエリを計画・実行し、結果から構造化されたナラティブを書き込み、埋め込みデータテーブル付きのフォーマットされたドキュメントを返します。

出力はExcelファイルとしてダウンロード可能です。ナラティブなReportシート、クエリ結果ごとのDataシート、SQLシートを含むワークブックで、サーバーサイドのExcel依存なしにブラウザ内で完全に組み立てられます。

これを「単にレポートを生成する」ことと異なるのは、ドキュメント内のデータが他のすべてのクエリと同じセマンティックレイヤーによってガバナンスされていることです。エグゼクティブブリーフの資材別売上テーブルは、チャット回答と同じVBAK.NETWRカラムを使用します。同期を保つための別個のレポートレイヤーは存在しません。

私たちが学んだこと

01. スキーマ品質が製品

ASKはデータを記述するData Productsの品質に依存します。追加するすべての同義語、辞書のすべての曖昧性解消ヒント、結合条件のすべてのビジネス言語記述 — これらはすべて回答品質を直接向上させます。エンジニアリングはインフラストラクチャであり、セマンティックレイヤーが製品です。

02. 決定的さは制約ではなく機能

私たちは結合計画を決定的にすることを選択しました。LLMが結合を選択するのではなく、グラフ上のDijkstra — なぜならユーザーが監査人に回答を説明する必要があったからです。「エージェントがこの結合を選択したのは、関係グラフ内のこれら2つのエンティティ間の最短パスだからです」というのは、「モデルが選択したからです」というよりもはるかに正当化しやすい回答です。

03. 3つのエンジンは過剰エンジニアリングではない

FlashとPreciseは真に異なるユースケースに対応します。単一のエンジンが両方を十分にカバーすることはできません。Smartは80%ケースのデフォルトとして登場しました。明示的なモードを持つことは、ユーザーにデバッグツールも提供します。Smartが失敗した場合はPreciseを試す。Preciseが遅すぎる場合はFlashを試す。モードセレクターは設定オプションであると同時に診断機能でもあります。

04. ガバナンスには儀式が必要

dev → prodプロモーションフローは設計時、オーバーヘッドのように感じられました。実際には、ユーザーはこれが最も価値のある機能の1つであると私たちに伝えました。悪いフィールド記述はdevクエリを破壊する可能性がありますが、月曜朝にCEOがクエリする本番データを静かに破壊することは決してありません。

Agentic Semantic Knowledgeを試す

セマンティックレイヤー仕様、プラットフォームコード、完全なマニュアルはGitHubで公開されています。SAPデータ — または複雑なスキーマを持つエンタープライズデータ — を扱っている場合、Bronze/Silver/GoldモデルとガバナンスされたSQLアプローチは、このプラットフォームを使用するかどうかに関わらず、理解する価値があります。GitHubで表示。