🏨 🔷 ♎️ テキストクエリのSQLへの変換 🛌🏽 🥇 🚟

遅かれ早かれNLPの問題に直面したことのあるほとんどの開発者は、記事のタイトルに示されている問題について考えました。この種の十分な数のソリューションが作成され、それぞれに独自の特性、プラスとマイナスがあります。私の同僚と私が10年前に会った最初のもの、そして私が今でも見つけることができなかったリンクは、絶対に読めない論文の形で発行されました。私たちは正直に、一歩一歩、そのページを突破しようとしましたが、数年間、このトピックへの絶望と興味を失いました。しかし遅かれ早かれ、あなたはこの問題に戻ってきます。そして、一般的に業界では、この問題への関心が何度も温まり、冷え込んでおり、近年、再び上昇しています。

テキストクエリをSQLに変換するためのシステム

そのようなシステムができるべきこと：

データベースエンティティに対応するテキスト内のエンティティ（テーブル、列、場合によっては値）を検索します。
リンクテーブル、フォームフィルター。
返されるデータのセットを定義します。つまり、選択リストを作成します。
サンプリング順序と行数を決定します。
比較的明白なものに加えて、基本スキーマの設計者以外の誰にも不透明ないくつかの絶対的に暗黙の依存関係またはフィルターを特定します（上の図のbonus_typeフィールドの条件を参照してください）
エンティティを選択する際のあいまいさを解決します。「イワノフに関するデータを教えてください」-相手方またはその姓の従業員に関する情報を要求する必要がありますか？2月の従業員データ-採用日または販売日でサンプルを制限しますか？等

つまり、最初のステップでは、他のすべてのNLPシステムで作業する場合と同じようにクエリを解析してから、その場でSQLを生成するか、事前に準備されたパラメータ化されたSQLクエリが記述されている関数で最適なインテントを見つける必要があります。一見すると、最初のオプションははるかに印象的です。それについてもっと詳しく話しましょう。

このようなシステムの特徴は、実際には1つのインテントのみがシステムに登録され、モデルと少なくとも何らかの関係があるすべてに対してトリガーされ、すべてのタイプのクエリに対してSQLを生成するスーパー関数があることです。SQLは、アルゴリズム的に、またはニューラルネットワークの参加により、任意のルールに基づいて作成できます。

アルゴリズムとルール

一見したところ、解析された文をSQLに変換するタスクは、純粋にアルゴリズムの問題です。つまり、問題なく解決できます。認識されたエンティティ、参照、相互参照など、1つの強力なモデルを別のモデルに変換するために必要なものはすべて揃っているようです。しかし、残念ながら、ニュアンスとあいまいさは、いつものように、すべてを複雑にし、この場合、100％ユニバーサルアプローチをほとんど機能させません。モデルは不完全であり（上記および記事に沿った例を参照）、エンティティは名前と意味の両方で交差し、エンティティの数の増加に伴う複雑さの増大とベースの複雑さは非線形になります。

ニューラルネットワーク

このようなシステムでのニューラルネットワークの使用は、急速に発展している分野です。この記事の枠組みの中で、私はリンクと簡単な結論にとどまります。

私は記事の短いシリーズを読むことを助言する： 1、 2、 3、 4、 5は、彼らは理論、品質のためのトレーニングとテストが行われているかについての話、ソリューションの簡単な概要のかなり含まれています。さらに、ここで-SparkNLPの詳細。こちら-SalesForceのPhotonソリューションについて。参考文献によると、オープンソースコミュニティのもう1つの代表者であるAllennlp。ここに-システムの品質に関するデータ、つまりテスト率。これは、NLPライブラリ、特に企業での同様のソリューションの使用に関するデータです。

この方向性には素晴らしい未来がありますが、やはり予約が必要です。まだすべてのタイプのモデルに対応しているわけではありません。モデルを操作するときに、完全に厳密な数値を取得する必要がなく、正確で再現性のある予測可能な結果を保証する必要がない場合（たとえば、傾向の特定、指標の比較、依存関係の特定など）、すべて問題ありません。しかし、回答の非決定性と確率的性質は、多くのシステムでのそのようなアプローチの使用に制限を課します。

ニューラルネットワークに基づくシステムでの作業例

多くの場合、この種のサービスを提供する企業は、よくできたビデオで優れた結果を示し、詳細な会話のためにそれらに連絡することを提案します。しかし、ネット上で利用可能なオンラインデモもあります。この場合、ベースダイアグラムは目の前にあるため、Photonを試すのは特に便利です。パブリックドメインで見た2番目のデモは、Allennlpからのものです。一部のクエリの解析は、その洗練度が驚くべきものであり、一部のオプションはやや成功していません。全体的な印象はまちまちです。興味があれば、これらのデモで遊んでみて、自分の意見を形成してください。

一般的に、状況は非常に興味深いものです。ニューラルネットワークに基づいてテキストの非構造化クエリをSQLに自動変換するシステムはますます良くなり、合格するテストセットの品質はますます高くなっていますが、それでもその値はせいぜい70％を超えません（スパイダーデータセット-今日の約69％）日）。この結果は良いと見なすことができますか？そのようなシステムの開発の観点からは、もちろん、結果は印象的ですが、すべてのタイプのタスクを変更せずに実際のシステムでそれらを使用することは不可能です。

ApacheNlpCraftツール

Apache NlpCraftプロジェクトは、このようなシステムの構築と整理にどのように役立ちますか？問題の最初の部分（テキストクエリの解析）について質問がない場合、すべてが通常どおりです。次に、2番目の部分（NLPデータに基づくSQLクエリの形成）では、NlpCraftは100％完全なソリューションを提供しませんが、この問題を個別に解決するのに役立つツールのみを提供します。 ..。

どこから始めますか？開発プロセスを可能な限り自動化したい場合は、データベーススキーマのメタデータとデータ自体が役立ちます。データベースから抽出できる情報をリストします。簡単にするために、テーブルに限定し、トリガーやストアドプロシージャなどの分析は行いません。

— . , .
(null / not null) (where clause).
, foreign keys , 1:1, 1:0, 1:n, n:m. joins.
. , , .. , select list.
. . - — , — enumeration, . .
. , . .
Primary and unique keys — , , , .
(, , Oracle) — .
制約の確認-制約の知識は、これらの列にすべて同じフィルターを作成するのに役立ちます。

したがって、メタデータを取得している場合は、モデルのエンティティについてすでに多くのことを知っています。したがって、たとえば、ある理想的な世界では、以下の表についてほとんどすべてを知っています。

CREATE TABLE users (
    id number primary key,
    first_name varchar(32) not null,
    last_name varchar(64) not null unique,
    birthday date null,
    salary_level_id number not null foreign key on salary_level(id)
);

実際には、すべてがそれほどバラ色ではなく、名前が省略されて判読できなくなり、データタイプが完全に予期しないものになることが多く、非正規化されたフィールドや1：0のような急いで追加されたテーブルがあちこちに散らばっています。その結果、現実的には、長期間生産されてきたデータベースのほとんどは、事前の準備なしにエンティティを認識するのに非常に困難にしか使用できません。これはすべてのシステムに当てはまり、ニューラルネットワークに基づいており、おそらく他のシステムよりもさらに当てはまります。

この状況では、NLPモジュールに、ある程度洗練されたスキーム（正しいフィールド名、必要かつ十分なテーブルと列のセット、セキュリティの問題などを含む、事前に準備されたビューのセット）へのアクセスを許可することをお勧めします。

設計を開始する

主で非常に単純な考えは、すべてのユーザー要求をカバーすることはほとんど不可能であるということです。ユーザーがシステムを欺くという目標を設定し、それを混乱させるような質問をしたい場合、彼は簡単にそれを行います。開発者の仕事は、開発中のシステムの機能とその実装の複雑さのバランスをとることです。したがって、非常に単純なアドバイスもあります。これらすべてのオプションに対してSQLを生成する1つのユニバーサルメソッドを使用して、すべての質問に答える1つのユニバーサルインテントをサポートしようとしないでください。100％の汎用性を放棄してみてください。プロジェクトのカラフルさが少し減りますが、より実現可能になります。

ユーザーに質問し、最も一般的なタイプの質問を30〜40個書き留めます。
, , , ..
. SQL, 20-30 . , . SQL ML text2Sql, .
. — , , , . — SQL . C — , .

このような大量の作業と十分なリソースがあるため、このような問題の解決に必要な時間は日数で測定され、最終的にはユーザーのニーズを80％カバーし、かなり高品質のパフォーマンスを実現します。次に、最初のポイントに戻り、インテントを追加します。

複数のインテントをサポートする価値がある理由を説明する最も簡単な方法は、例を使用することです。ほとんどの場合、ユーザーは、「そのような期間について、そのような期間について私を比較しますが、そのような期間には含まれず、同時に...」など、特定の数の非常に非標準的なレポートに関心を持っています。そのようなクエリに対してSQLをすぐに生成できるシステムはありません。何らかの方法でそれをトレーニングするか、そのようなケースを選択して個別にプログラムする必要があります。限られた範囲の複雑なクエリに応答できることは、ユーザーにとって非常に重要です。そのようなすべての要求を満たすのに十分なリソースがあるという事実ではなく、バランスをもう一度探しますが、そのような要望を完全に無視することは、システムの機能を許容できないレベルに狭めることを意味します。適切な比率を見つけたら、システムの開発には有限の時間がかかり、数日間は単なる楽しいおもちゃではないため、後で役立つというよりも煩わしいものになります。非常に重要な点は、トリッキーなリクエストのインテントをすぐに追加するのではなく、その過程で1つずつ追加できることです。一度に1つのユニバーサルインテントのみを持つMVPがあります。

ツールキットとAPI

Apache NlpCraftは、データベース操作を簡素化するためのツールキットを提供します。

操作手順：

データベースjdbcurlからモデルテンプレートを生成します。上で述べたように、データのより「正しい」表現でビューのセットを準備し、そのセットへのアクセスを提供する方が良い場合があります。テンプレートを生成する最も簡単な方法は、CLIユーティリティを使用することです。ユーティリティを起動し、データベーススキーマ、jdbcドライバ、使用および無視されるテーブルのリスト、およびその他のパラメータをパラメータとして指定します。詳細については、ドキュメントを参照してください。

JSON YAML , , , , .., , .

:

- id: "tbl:orders"
 groups:
 - "table"
 synonyms:
 - "orders"
 metadata:
   sql:name: "orders"
   sql:defaultselect:
   - "order_id"
   - "customer_id"
   - "employee_id"
   sql:defaultsort:
   - "orders.order_id#desc"
   sql:extratables:
   - "customers"
   - "shippers"
   - "employees"
 description: "Auto-generated from 'orders' table."
.....
- id: "col:orders_order_id"
 groups:
 - "column"
 synonyms:
 - "{order_id|order <ID>}"
 - "orders {order_id|order <ID>}"
 - "{order_id|order <ID>} <OF> orders"
 metadata:
   sql:name: "order_id"
   sql:tablename: "orders"
   sql:datatype: 4
   sql:isnullable: false
   sql:ispk: true
 description: "Auto-generated from 'orders.order_id' column."

— , , . , . , , , , , , .. .
豊富なモデルに基づいて、開発者は、インテント関数でのSQLクエリの構築を大幅に容易にするコンパクトなAPIを使用できます。詳細な例を参照してください。

以下は、わかりやすくするためのコードスニペットです。

@NCIntent(
  "intent=commonReport " +
  "term(tbls)~{groups @@ 'table'}[0,7] " +
  "term(cols)~{
    id == 'col:date' || 
    id == 'col:num' || 
    id == 'col:varchar'
  }[0,7] " +
  "term(condNums)~{id == 'condition:num'}[0,7] " +
  "term(condVals)~{id == 'condition:value'}[0,7] " +
  "term(condDates)~{id == 'condition:date'}[0,7] " +
  "term(condFreeDate)~{id == 'nlpcraft:date'}? " +
  "term(sort)~{id == 'nlpcraft:sort'}? " +
  "term(limit)~{id == 'nlpcraft:limit'}?"
)
def onCommonReport(
  ctx: NCIntentMatch,
  @NCIntentTerm("tbls") tbls: Seq[NCToken],
  @NCIntentTerm("cols") cols: Seq[NCToken],
  @NCIntentTerm("condNums") condNums: Seq[NCToken],
  @NCIntentTerm("condVals") condVals: Seq[NCToken],
  @NCIntentTerm("condDates") condDates: Seq[NCToken],
  @NCIntentTerm("condFreeDate") freeDateOpt: Option[NCToken],
  @NCIntentTerm("sort") sortTokOpt: Option[NCToken],
  @NCIntentTerm("limit") limitTokOpt: Option[NCToken]
): NCResult = {
  val ext = NCSqlExtractorBuilder.build(SCHEMA, ctx.getVariant)
  
  val query =
    SqlBuilder(SCHEMA).
      withTables(tbls.map(ext.extractTable): _*).
      withAndConditions(extractValuesConditions(ext, condVals): _*).
      ...
    //      SQL   
    // . 
 }

これは、リクエストで定義された基本要素に反応し、照合プロセス中に厳密な一致が見つからなかった場合にトリガーされるデフォルトのインテント関数のフラグメントです。これは、SQLクエリの構築とSQLビルダーの例の操作に関係するSQL要素抽出APIの使用法を示しています。

繰り返しになりますが、Apache NlpCraftは、解析されたテキストクエリをSQLに変換するための既製のツールを提供していません。このタスクは、少なくとも現在のバージョンでは、プロジェクトの範囲外です。クエリビルダーコードは、APIではなく例で利用できます。重大な制限がありますが、コメント付きのコードは500行のみ、コメントなしのコードは約300行で構成されています。同時に、そのすべての単純さと制限さえもありますが、この最も単純な実装でさえ、非常に多くの最も多様なタイプのユーザークエリに必要なSQLを生成できます。このバージョンでは、この例を使用するために同様のシステムの構築に関心のあるユーザーに提案しますテンプレートとして作成し、ニーズに合わせて開発します。はい、これは一晩の作業ではありませんが、ユニバーサルソリューションを正面から使用する場合よりも比類のない高品質の結果が得られます。

私はデフォルトの意思機能で、あなたはどちらかだけの例を変更することができるということを繰り返す例（レビューによると、その機能は十分でもよい）、またはニューラルネットワークで使用するソリューション。

結論

データベースにアクセスするためのシステムを構築することは簡単な作業ではありませんが、 Apache NlpCraftはすでに日常業務のかなりの部分を引き継いでおり、これが主な理由で、まともな品質のシステムの開発には測定可能な時間とリソースがかかります。Apache NlpCraftコミュニティがテキストクエリのSQLへの変換を自動化する方向性を開発し、この単純なSQLの例を本格的なAPIに拡張するかどうか-プロジェクトの計画と方向性を形成する時間とユーザーの要求が示されます。

テキストクエリのSQLへの変換