コンテキスト セットの概要

コンテキスト セットは、QueryData を強化するドメイン知識です。アプリケーションが本番環境に移行する前にビジネス ロジックがどのように機能するかを定義します。これにより、QueryData はほぼ 100% の精度と低いオンライン レイテンシで自然言語の質問に回答できます。

ドメイン コンテキストにはさまざまな形式がありますが、コンテキスト セットは次の 3 つの特殊なコンテキスト タイプをサポートしています。

  • クエリ テンプレート: 一般的なビジネス上の質問に対して事前に承認された SQL クエリ。
  • クエリ ファセット: テンプレートに動的にアタッチされるモジュラー フィルタ（「新婚家庭」や「オーシャン ビュー」など）。
  • 値検索: ユーザーのフレーズを正確なデータベース値にマッピングし、曖昧さを解消するエンティティ検索。

サポートされているデータベースは次のとおりです。

  • AlloyDB for PostgreSQL
  • Cloud SQL for MySQL
  • Cloud SQL for PostgreSQL
  • Spanner
  • MongoDB 互換の Firestore
  • Bigtable

コンテキスト セットとは

設計時にコンテキスト エンジニアリング エージェントを使用して、コンテキスト セットを作成して最適化します。コンテキスト エンジニアリング エージェントは、QueryData を介して代表的なゴールデン ベンチマークを実行し、結果をスコア付けして、コンテキスト セットを繰り返し改良（山登り）します。次に、過学習を回避するために、最終バージョンを未確認のホールドアウト テストセットと照合し、コンテキスト セットをGoogle Cloudに自動的にアップロードします。

データベースをキュレートされたコンテキスト セットと組み合わせると、本番環境で次の 2 つの主なメリットが得られます。

  • 一般化するほぼ 100% の精度: データベース スキーマはテーブルと列を記述しますが、どの距離が「近い」か、どの評価が学校を「良い」とするかをモデルに伝えることはできません。コンテキスト セットは、組織の検証済みのビジネスルールで QueryData をグラウンディングします。一方、パラメータ化されたパターンを使用すると、コンパクトなコンテキスト セットを、言い回しのバリエーション、フィルタの組み合わせ、エンティティ値全体で一般化できます。
  • 高速なオンライン実行と低レイテンシ: コンテキスト エンジニアリングにより、コストのかかるスキーマ推論をオフラインから設計時に移行します。
    • コンテキスト セットを使用したコンテキスト一致実行: 事前コンパイルされたテンプレート マッチングとインデックス付き値のルックアップによる高速なシングルパス実行。
    • テンプレートなしの予期しないクエリのゼロショット合成: モデルがスキーマ メタデータを探索し、実行時に SQL を合成する必要があるため、2 ～ 3 倍の時間がかかります。
    • 未加工の SQL ツールを使用したオープンなエージェント探索: マルチターンの試行錯誤クエリとエラー修正ループにより、30 秒以上かかることがよくあります。

コンテキスト セット内のコンテキスト タイプ

実行時に、QueryData は 3 つのコンテキスト タイプをすべて 1 つのパスに結合します。たとえば、ユーザーが次のように質問したとします。

「デルマーで、良い学校の近くにあり、オーシャンビューの新婚家庭向けの家を探して」

QueryData は、次の 4 つのステップを連携してリクエストを解決します。

  1. クエリ テンプレートは、「$1 の良い学校の近くにある家」のコア クエリ構造を提供し、距離（2 マイル以内）と学校のランキング（5 以上）のビジネスルールを適用します。
  2. クエリ ファセットは、「スターター ファミリー」（3 ～ 4 ベッドルーム、2 つ以上のバスルーム）と「オーシャンビュー」（ベクトル類似性検索）のモジュラー フィルタを挿入します。
  3. 値検索では、cities.city_name 列で 'Del Mar' を検索し、そのコンセプト タイプを確認します。
  4. インテントの説明は、クエリ結果とともに返される 1 つの認定された説明に統合されます。「デルマーにある、学校から 2 マイル以内の、5 つ星以上の、寝室 3 ～ 4 室の、オーシャンビューの家」

クエリ テンプレート

クエリ テンプレートは、代表的な自然言語の質問とそれに対応する SQL クエリをまとめたものです。また、質問がどのように解釈されたかについて、認定された根拠を提供する説明も含まれています。

たとえば、ユーザーが不動産アプリケーションに「デルマーの良い学校の近くにある家を探して」と質問した場合、データベース スキーマだけでは、「近く」と見なされる距離、「良い」学校と見なされる評価、一致する物件のランク付け方法を定義できません。クエリ テンプレートは、ランキングと近接性の重み付けスコアで並べ替えられた、ランク 5 以上の学校から 2 マイル以内の物件など、正確なビジネス解釈をキャプチャし、任意の都市に一般化します。

クエリ テンプレートの主なコンポーネントは次のとおりです。

  • 自然言語の質問の例: 「Find me homes near good schools in Del Mar（デルマーの良い学校の近くにある家を探して）」など、平易な英語で尋ねられた代表的な質問。
  • SQL クエリの例: ビジネスルールに従って質問に回答する、検証済みの SQL クエリ。
  • 一般化された質問パターン: 特定の値を一般的な説明に置き換えた自動生成パターン（「特定の都市のよい学校の近くにある家を探す」など）。さまざまな言い回しで入力される質問を照合するために使用されます。
  • インテントの説明: クエリによって適用されるビジネスルール（「$1 で、ランクが 5 以上の学校から 2 マイル以内にある住宅を検索する」など）の、認定されたわかりやすい説明。
  • パラメータ化された SQL クエリ: $1 などのパラメータを使用して、インテントの説明に対応する実行可能な SQL クエリ。

クエリ ファセット

クエリ ファセットは、代表的な自然言語の条件と、対応する SQL 述語をまとめたものです。ファセットはフィルタリングと条件を管理します。これにより、クエリ テンプレートは、フィルタの組み合わせごとに個別のテンプレートを必要とせずに、ファセット検索を実行できます。

たとえば、ユーザーは「デルマーの良い学校の近くにある家を探して」という質問に、次のような追加条件を付けることができます。

  • 「...for a starter family」は、properties.bedrooms BETWEEN 3 AND 4 AND properties.bathrooms >= 2.0 などの構造化 SQL フィルタにマッピングされます。
  • 「...オーシャンビュー」は、ai.if などのデータベース AI 演算子や、listing_description、listing_image_embeddings、customer_reviews などの非構造化列にわたるベクトル類似性検索（<=>）を使用します。

クエリ ファセットの主なコンポーネントは次のとおりです。

  • SQL スニペット: 再利用可能な SQL フィルタ条件（properties.bedrooms BETWEEN 3 AND 4 AND properties.bathrooms >= 2.0 など）。
  • 一般化された条件パターン: ファセットが一致する自然言語パターン（「初めての家族に適している」など）。
  • インテントの説明: フィルタ条件の認定された説明。全体的な回答の根拠の一部として返されます。
  • パラメータ化された SQL スニペット: インテントの説明に対応する実行可能な SQL フラグメント。

値の検索クエリ

値検索クエリは、デベロッパーが定義したクエリです。完全一致、ファジー トリグラム類似度、セマンティック ベクトル検索などの一致関数を使用して、データベース内の値とそのコンテキストを検索します。QueryData は、これらの結果に対して値のリンクを使用して、一致する値を含むテーブルと列を特定し、値のコンセプト タイプを理解し、スペルミスを修正し、SQL を実行する前に曖昧さを検出します。

たとえば、ユーザーが不動産アプリケーションに「過去 1 か月間に売却された Westwod の物件」をリクエストした場合、スキーマのみのモデルは WHERE name = 'Westwod' でフィルタし、結果を返さない可能性があります。値検索クエリは、ファジー マッチングを使用して、スペルミスの「Westwod」をデータベース値 'Westwood' に解決します。また、'Westwood' がデータベース内の複数のコンセプト タイプ（City、Municipality、Brokerage など）に存在する場合、値リンクは曖昧さを検出します。これにより、QueryData は推測するのではなく、ユーザーにどのコンセプトを意味しているかを明確にするよう求めることができます。

値検索クエリの主なコンポーネントは次のとおりです。