検索結果を取得する

このページでは、 Google Cloud コンソールを使用して検索結果をプレビューし、API を使用して検索結果を取得する方法について説明します。

また、ウェブアプリの UI を使用する代わりに、API 呼び出しを行って、それらの呼び出しをサーバーやアプリケーションに統合することもできます。このページでは、サービス アカウントで gRPC クライアント ライブラリを使用して検索クエリを作成する方法のコードサンプルを紹介します。

検索結果を取得する

検索結果は、 Google Cloud コンソールでプレビューするか、API を使用して取得できます。

コンソール

Google Cloud コンソールを使用して、構造化データまたは非構造化データを含むアプリの検索結果をプレビューする手順は次のとおりです。

  1. コンソールで [プレビュー] ページを開きます。
  2. 検索語句を入力します。
    1. 手順 1 で予測入力を有効にした場合、入力すると検索バーの下に予測入力候補のリストが表示されます。
  3. (省略可)複数のデータストアをアプリに接続しているが、特定のデータストアの結果のみが必要な場合は、結果を取得するデータストアを選択します。
  4. Enter キーを押してクエリを送信します。
    1. 検索バーの下に検索結果の一覧が表示されます。
    2. [構成] ページで属性マッピングが定義されていない場合、各検索結果は未加工の属性名と値のリストとして表示されます。
    3. [構成] ページに属性マッピングが保存されている場合、検索結果には [構成] ページのプレビューと同じ画像が表示されます。
  5. [構成] ページでファセットが指定されている場合は、同様に表示されます。
  6. 結果リストの下にある矢印をクリックして、結果の次のページを読み込みます。

REST

API を使用して、構造化データまたは非構造化データを含むアプリの検索結果を取得するには、engines.servingConfigs.search メソッドを使用します。

  1. アプリ ID を確認します。アプリ ID がすでにある場合は、次のステップに進みます。

    1. Google Cloud コンソールで、[Gemini Enterprise] ページに移動します。

      [アプリ] に移動

    2. [アプリ] ページで、アプリの名前を見つけ、[ID] 列からアプリの ID を取得します。

  2. 検索結果をプレビューします。

    curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/collections/default_collection/engines/APP_ID/servingConfigs/default_search:search" \
    -d '{
    "query": "QUERY",
    "userPseudoId": "USER_PSEUDO_ID",
    "pageSize": "PAGE_SIZE",
    "offset": "OFFSET",
    "orderBy": "ORDER_BY",
    "filter": "FILTER",
    "boostSpec": "BOOST_SPEC",
    "facetSpec": "FACET_SPEC",
    "queryExpansionSpec": "QUERY_EXPANSION_SPEC",
    "spellCorrectionSpec": "SPELL_CORRECTION_SPEC",
    "contentSearchSpec": "CONTENT_SEARCH_SPEC",
    "dataStoreSpecs": [{"DATA_STORE_SPEC"}],
    }'
    

    次のように置き換えます。

    • PROJECT_ID: 実際のプロジェクトの ID。
    • APP_ID: クエリするアプリの ID。
    • QUERY: 検索するクエリテキスト。
    • USER_PSEUDO_ID: ユーザーをトラッキングする一意の仮名化 ID として機能する UTF-8 エンコード文字列。最大長は 128 文字です。このフィールドを使用すると、モデルのパフォーマンスとパーソナライズの品質が向上するため、このフィールドを使用することを強くおすすめします。このフィールドには HTTP Cookie を使用できます。これにより、1 つのデバイス上の訪問者を一意に識別できます。重要な考慮事項は次のとおりです。

      • この ID は、訪問者がウェブサイトにログインまたはログアウトしても変更されません。
      • このフィールドを複数のユーザーに対して同じ ID に設定しないでください。そうしないと、複数のユーザーに同じユーザー ID を使用すると、異なるユーザーのイベント履歴が統合され、モデルの品質が低下する可能性があります。
      • このフィールドに個人を特定できる情報(PII)を含めることはできません。
      • 特定の検索リクエストまたはブラウジング リクエストの場合、このフィールドはユーザー イベントの対応する userPseudoId フィールドにマッピングする必要があります。

      詳細については、userPseudoId をご覧ください。

    • PAGE_SIZE: 検索によって返された結果の数。許可される最大ページサイズは、データ型によって異なります。最大値を超えるページサイズは、最大値に強制変換されます。
    • OFFSET: 省略可。結果の開始インデックス。 デフォルト値は 0 です。

      たとえば、オフセットが 2、ページサイズが 10、返される結果が 15 個ある場合、1 ページ目には 2 から 12 個の結果が返されます。

    • ORDER_BY: 省略可。結果が並べ替えられる順序。

    • FILTER: 省略可。フィルタ式を使用して検索結果をフィルタリングするためのテキスト フィールド。デフォルト値は空の文字列です。これは、フィルタが適用されないことを意味します。

      例: color: ANY("red", "blue") AND score: IN(*, 100.0e)

      詳細については、構造化データまたは非構造化データの検索をフィルタするをご覧ください。

    • BOOST_SPEC: 省略可。ドキュメントをブーストまたは埋め込むための仕様。値:

      • BOOST: [-1,1] の範囲の浮動小数点数。値が負の場合、結果は降格されます(結果の下位に表示されます)。値が正の場合、結果は昇格されます(結果の上位に表示されます)。
      • CONDITION: ブーストを適用するドキュメントを選択するためのテキスト フィルタ式。フィルタはブール値に評価される必要があります。

      構造化検索のブーストについては、検索結果をブーストするをご覧ください。

    • FACET_SPEC: 省略可。ファセット検索を実行するファセットの仕様。

    • QUERY_EXPANSION_SPEC: 省略可。クエリ拡張を行う条件を決定するための仕様。デフォルトは DISABLED です。

    • SPELL_CORRECTION_SPEC: 省略可。スペル修正を行う条件を決定するための仕様。デフォルトは AUTO です。

    • CONTENT_SEARCH_SPEC: 省略可。スニペット、抽出回答、抽出セグメント、検索のサマリーを取得します。非構造化データのみ。詳しくは以下をご覧ください。

    • DATA_STORE_SPEC: 検索対象の特定のデータストアのフィルタ。検索アプリが複数のデータストアに接続されている場合に使用できます。詳細については、DataStoreSpec をご覧ください。

    • 検索レスポンスでガイド付きの検索結果を表示する:

      ガイド付きの検索結果は、構造化検索と非構造化検索の検索レスポンスとともに返されます。ガイド付きの検索結果には、検索結果ドキュメントに基づいて抽出された属性の Key-Value ペアのリストが含まれます。これにより、ユーザーは一部の属性キーと値をフィルタとして使用して、検索結果を絞り込むことができます。

      このレスポンス例では、緑色を使用して検索結果を絞り込むため、フィルタ フィールドを _gs.color: ANY("green") として指定した新しい検索リクエストを発行しています。

      {
      "guidedSearchResult": {
        "refinementAttributes": [
          {
            "attributeKey": "_gs.color",
            "attributeValue": "green"
          },
          {
            "attributeKey": "_gs.category",
            "attributeValue": "shoe"
          }
        ]
      }
      }
      

検索結果でドキュメントの関連性スコアを取得する

ドキュメントの関連性スコアは、クエリとドキュメントの類似性に基づいています。スコアは 0、0.1、0.2、...、1.0 の範囲の 11 個のバケットに分類されます。スコアが高いほど、ドキュメントの関連性が高くなります。

次のユースケースのドキュメント関連性スコアについて考えてみましょう。

  • 関連性スコアに基づく検索後のフィルタリングにより、関連性の低い結果を削除する

  • 検索後のランキング、または他のアプリケーションへの入力として使用

  • デバッグ: 関連性スコアを使用すると、一部の検索結果が返される理由を把握できます

検索結果ごとに、関連性スコアを返すことができます。

  "results": [
    {
      "id": "DOCUMENT_ID",
      "document": {
      ...
      },
      "modelScores": {
        "relevance_score": {
          "values": [
            DOCUMENT-RELEVANCE-SCORE
          ]
        }
      }
    },
    ...

以下の手順のコマンド例もご覧ください。

始める前に: 検索アプリが構造化データストアまたは非構造化データストアに関連付けられていることを確認します。

REST

検索結果とともにドキュメントの関連性スコアを返すようにリクエストするには、次のように engines.servingConfigs.search メソッドを使用します。

  1. アプリ ID を確認します。アプリ ID がすでにある場合は、次のステップに進みます。

    1. Google Cloud コンソールで、[Gemini Enterprise] ページに移動します。

      [アプリ] に移動

    2. [アプリ] ページで、アプリの名前を見つけ、[ID] 列からアプリの ID を取得します。

  2. 次の curl コマンドを実行して、検索結果とともに返されるスコアを取得します。

    curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    "https://discoveryengine.googleapis.com/v1/projects/PROJECT_ID/locations/global/collections/default_collection/engines/APP_ID/servingConfigs/default_search:search" \
    -d '{
         "servingConfig": "projects/PROJECT_ID/locations/global/collections/default_collection/engines/APP_ID/servingConfigs/default_search",
         "query": "QUERY",
         "relevanceScoreSpec": {
           "returnRelevanceScore": true
         }
    }'
    
    • PROJECT_ID: 実際のプロジェクトの ID。
    • APP_ID: クエリするアプリの ID。
    • QUERY: 検索するクエリテキスト。

検索のサマリーはモデルによって異なる

クエリの検索のサマリーを生成すると、コンソールの結果と API の結果でサマリーが異なる場合があります。このような場合は、コンソールが API とは異なる LLM モデルを使用している可能性があります。このページの curl とコードの例では、安定版の LLM モデルを使用しています。

  • UI の [プレビュー] ページで使用されている LLM モデルを変更または表示するには、アプリの [構成] ページ > [UI] タブに移動します。

  • メソッド呼び出しの場合、安定版モデルがデフォルトのモデルです。安定版モデル以外の LLM モデルを使用するには、要約モデルを指定する回答モデルを指定するをご覧ください。