Oracle Deep NL2SQL: ナレッジ主導型のフィードバック改善されたSQL (2026/10/26)
Oracle Deep NL2SQL: ナレッジ主導型のフィードバック改善されたSQL (2026/10/26)
投稿者：Tirthankar Lahiri | Senior Vice President, Mission-Critical Data and AI Engines
自然言語からSQLへの変換は、ユーザーがデータと対話するだけで済む強力なAI機能です。開発者はアプリケーションを構築でき、ビジネスユーザーは洞察を得たり、予測を生成したり、より良い意思決定を行うことができます。今日の基盤となるモデルは、適切なコンテキストがあれば、自然言語をSQLに変換する能力に非常に優れています。
そして、そこに落とし穴があるのです。実際のエンタープライズスキーマは、人間が理解できるように設計されていることはほとんどなく、ましてやLLM（論理モデル）が理解できるように設計されていることは稀です。それらは大規模で複雑であり、難解な名前や内部規則で満ちており、データが実際に何を意味するのかを捉えるのに十分なコンテキストが含まれていないことがよくあります。最高のモデルでさえ推測に頼らざるを得ず、スキーマに関する知識を持つアプリケーションの専門家だけが、信頼できる正しいSQLを作成できるのです。
そのため、今日のスキーマ依存型のNL2SQLソリューションは、現実世界で一貫して高い精度を実現するのに苦労しています。そして、その回答が重要なビジネス上の意思決定を左右する場合、「時々正しい」というだけでは、ビジネスを賭けるには十分ではありません。スキーマコンテキストの不足に加えて、既存のNL2SQLソリューションには他にもいくつかの問題があります。
- 言語の曖昧さの不適切な取り扱い–人間の言語は混沌としている！
- エンドユーザーの専門用語や業界用語、アプリケーションメトリクス、ビジネスルールに関する詳細な知識が不足している。ほとんどのモデルはそれらについて何も知らない。
- 結果を改善するために人間のフィードバックが活用されていない– NL2SQLシステムはユーザーから学ぶ必要がある。つまり、ユーザーが何を意図していたのか、何が間違っていたのか、より良い回答とはどのようなものなのかを学ぶ必要がある。
「カリフォルニアで最も売れているL2商品は何ですか？」といった、eコマースアプリケーションにとって一見単純な質問であっても、標準的なNL2SQLシステムで実行すると、これらの制限事項がそれぞれ露呈する可能性があります。
- 曖昧さ：「トップ」（何件か？）や「販売」（販売台数、予約数、利益、収益？）の定義には多くの方法があり、考慮すべき期間も多岐にわたる（年初来、直近四半期、昨年？）。
- 専門用語：「L2 提供可能」はアプリケーション固有の用語であり、一般的な用語ではありません。
- 指標：利益や収益などの指標は、アプリケーションのドキュメントでのみ定義され、スキーマ内で適切に定義されていない場合があります。
- ルール:例えば、商品が販売されたと認識するために、企業は商品が返品されていないこと、および返金期間が経過していることを要求する場合がありますが、この情報はスキーマに含まれていない場合もあります。
- フィードバック：この質問に対する一度きりの不適切な回答では、システムが間違いから学び、将来同じ過ちを繰り返さないための機会が全く与えられません。
OracleのDeep NL2SQLをご紹介します
他の従来型のNL2SQLソリューションとは異なり、OracleのDeep NL2SQLエージェントは、統合された知識工学ワークベンチとフィードバック駆動型のワークフローを備え、これらの制約に対処することで、実際のエンタープライズアプリケーション向けの信頼性の高いNL2SQLソリューションを提供します。
このソリューションの主な特長は以下のとおりです。
- 知識エンジニアリングワークベンチを使用して構築されたビジネス知識グラフは、正確なSQL生成に必要な追加コンテキストでスキーマを拡張します。
- フィードバック主導型のワークフロー は、言語の曖昧さを明確化し、エージェントが時間とともに精度を向上させるための反復的な知識の洗練を可能にします。
- 検証済みの自然言語からSQLへの変換を特徴とする組み込みの回帰テストにより、知識が変更されてもシステムの精度が低下しないことが保証されます。
このブログでは、OracleのDeep NL2SQLエージェントに関する詳細情報を提供し、知識ベースと代表的な「ゴールド」SQLステートメントのセットを設定するための必要な事前作業を行った後、データとのやり取りにおいてほぼ100%の精度を達成する方法について説明します。
Deep NL2SQLはどのように機能するのか？
Deep NL2SQLは、信頼できる回答には構文的に正しいSQL以上のものが必要であるというシンプルな前提から始まります。クエリを生成する前に、ユーザーが質問で実際に何を意味しているのかを理解し、曖昧な用語を明確にし、適切なビジネス定義とデータ関係を特定し、以前に検証された知識を活用します。そのため、Deep NL2SQLの最初のステップは、ビジネス知識グラフ を構築することです。
ビジネスナレッジグラフ
ビジネスナレッジグラフは、想定される質問や質問のカテゴリに答えるために必要な情報に対応する「トピック」に企業知識を整理します。たとえば、一般的なデータウェアハウスのワークロードの場合、ビジネスナレッジグラフのトピックには、製品販売、顧客注文、製品レビュー、在庫に関する情報が含まれる可能性があります。「前四半期の総売上高はいくらですか」という質問は製品販売トピックにマッピングされ、「 2025年（2026年？）で最も評価の低い製品トップ5は何ですか」という質問は製品レビュートピックにルーティングされます。
ビジネス知識グラフのトピックは階層構造を持つ場合があり、ルート知識トピックには多くのドメインレベルの子トピックにまたがる共有企業知識が含まれ、各子トピックはさらにドリルダウントピックを表す子トピックを持つことができます。子トピックは親トピックから知識を継承します。
各知識トピックには、その範囲内の質問を解釈し、回答するために必要な情報が含まれています。内容には以下が含まれる場合があります。
- 関連するデータベーススキーマ、テーブル、ビュー、カラム、およびリレーションシップ
- テーブル、列、値、および想定される使用方法を説明する注釈/コメント
- ビジネス用語集の用語と指標の定義
- 対応するSQL文の有無にかかわらず、自然言語による質問例
- 組織固有の知識またはアプリケーション固有の知識を含む文書
例えば、製品販売に関する知識トピックには、以下のような内容が含まれる場合があります。
- 製品および注文テーブル
- 「戦略」などの概念や「利益」などの指標に関するビジネス上の定義
- 売上計算時に返品された商品を除外するための手順
- このトピックに適用できる質問の例としては、「最も収益性の高い製品は何ですか」などがあります。
ビジネス知識グラフは、SQL生成モデルに提示される無関係な情報の量を大幅に削減できます。エージェントに企業全体のスキーマを公開する代わりに、システムはベクトル、テキスト、グラフなどの高度なデータベースネイティブ検索技術を使用して、質問に答えるために特に必要なデータと知識が含まれている可能性が最も高いトピックを特定します。それ以上でもそれ以下でもありません。
ビジネスナレッジグラフの評価
ビジネスナレッジグラフは一度作成されると、時間の経過とともに静的な状態を維持することは期待できません。データベーステーブルが変更されたり、ビジネス定義が変更されたり、エージェントがより高度な質問に答えるようになるにつれて新しいトピックが追加されたりする可能性があるからです。そのため、変更が加えられるたびにビジネスナレッジグラフの正確性を継続的に評価できるワークフローを確立することが重要です。
NL2SQLには、まさにこの目的のために組み込まれた回帰テストワークフローがあります。それでは、その手順を見ていきましょう。
- まず、自然言語による一連の質問と、それに関連付けられた検証済みのSQLを、Deep NL2SQLの回帰テストスイートの一部として登録できます。これを「ゴールドセット」と呼びます。これらの質問は、回帰テストの実行中に必ず提示されます。
- ビジネスナレッジグラフに変更が加えられると、それらの変更は、すべてのユーザーが閲覧できる公式の公開済みビジネスナレッジグラフに含めても安全であると判断されるまで、未公開の状態で保持されます。
- 評価ワークフローをトリガーすることで、未公開のビジネス知識グラフを使用して、ゴールドセットでDeep NL2SQLを実行し 、回答を生成することができます。
- 回答が想定されるセットと一致する場合、変更は安全であるとみなされ、未公開のグラフを公開状態に切り替えることで、すべてのユーザーが反映された変更を確認できるようになります。
ワークベンチは、ビジネス知識グラフへのわずかな変更であっても、期待される動作に影響を与えないことを検証するためのベストプラクティスを組み込んでいます。Deep NL2SQLのユーザーはシステムに対して100%の信頼を期待しているため、システムが応答において一貫性と決定性を促進することが不可欠です。
フィードバック駆動型NL2SQLとヒューマン・イン・ザ・ループ
ビジネス知識グラフが作成され、テストされ、完全に検証されると、Deep NL2SQLは質問への回答に使用できるようになります。しかし、この段階でも、信頼性をさらに高めることができます。Deep NL2SQLの中核となるのは、エージェントとユーザーとの会話のあらゆる段階でヒューマン・イン・ザ・ループを通じてユーザーからフィードバックを収集し、回答の正確性と信頼性を確保する機能です。詳しく見ていきましょう。
質問が投げかけられると、エージェントはまず知識を収集し、曖昧さを解消することで質問を完全に理解しようと試みます。そのためには、まず質問をビジネス知識グラフ内の1つ以上のトピックにマッピングします。次に、エージェントはそれらのトピックに含まれる知識が質問の意図を完全に明確にしているかどうかを評価します。エージェントが満足できない場合は、ためらうことなくビジネスユーザーに明確化のための質問をします。
ビジネス知識グラフの知識とヒューマン・イン・ザ・ループを組み合わせて質問が理解されたら、SQL の生成を開始します。Deep NL2SQL エージェントは、質問の分解、クエリ計画、探索的データ分析、SQL の生成と実行、リフレクションと検証を実行する高度な推論ベースのエージェントです。Deep NL2SQL は、すべてのステップでヒューマン・イン・ザ・ループを組み込み、質問への回答時に発生する懸念事項を解決します。たとえば、エージェントが「注文済み」を定義するステータスを決定しようとしている場合、ビジネス知識グラフに質問に答えるのに十分なコンテキストがない場合は、ユーザーに説明を求めます。
Deep NL2SQLは、生成した最終SQLを自己レビューし、ビジネス知識グラフから取り込んだ前提と知識を振り返り、最終的な回答をユーザーに返します。生成されるSQLには、回答を生成するために用いられたすべての思考と推論が付随しており、ユーザーは回答を完全に理解するための十分な情報を得ることができます。この段階でも、信頼性が考慮されています。ユーザーは結果に賛成または反対の投票を行うことができ、これはシステムがバックエンドで処理するための追加フィードバックとして機能します。
フィードバックを取り入れてシステムを改善する
エージェントとの会話中に蓄積されたすべてのフィードバックは記録され、エージェント設計者が後で内省するためにログに記録されます。理想的には、フィードバックはビジネス知識グラフに追加され、エージェントが今後確認のための質問をする必要がなくなります。得られた知識は学習された知識です。知識をビジネス知識グラフに追加することで、他のユーザーもその恩恵を受けることができます。また、Deep NL2SQLの評価ワークベンチを使用すれば、変更をユーザーに公開する前に安全に追加できます。
まとめ
従来のNL2SQLソリューションとは異なり、Deep NL2SQLは信頼性を核として設計されています。ビジネス知識グラフを通じて企業知識をクエリ可能なセマンティック領域に整理し、信頼性の高い正確性を実現するためにヒューマン・イン・ザ・ループ・フィードバックを組み込み、知識グラフとその評価ワークフローの作成、検証、保守を行うためのワークベンチを提供します。フィードバックは、管理された再利用可能な知識として安全に組み込むことができ、システムは一貫性、透明性、そして回答に対する信頼性を維持しながら改善していくことができます。Deep NL2SQLを使えば、データに対して自信を持って対話し、信頼できる回答を得ることができます。
コメント
コメントを投稿