会話型検索

このページでは、小売業向け Vertex AI Search の会話型検索のガイド付き検索機能について説明します。

会話型検索を使用すると、小売業者はよりインタラクティブな検索エクスペリエンスをユーザーに提供できます。会話型検索機能は、ガイド付き検索パッケージの一部として機能し、ユーザーのクエリを絞り込み、関連性の高い商品をすばやく表示することで、ユーザーにメリットをもたらします。

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

• 会話型検索の仕組み
• メイン（クエリ）API によるサービング エクスペリエンス
• 管理 API とコンソールによる管理者向け機能

会話型検索の仕組み

会話型の小売業向け Vertex AI Search を有効にすると、小売業者のサイトで商品を検索する買い物客を会話によりガイドできます。小売業向け Vertex AI Search で最初のテキスト クエリを実行すると、オンライン経由の買い物客に、関連するフォローアップの質問と多肢選択式のオプションが表示されます。フォローアップの質問には、ユーザーが自由形式のテキストで回答することも、会話型の多肢選択式のオプションをクリックして回答することもできます。

注: ブラウジングには多肢選択式のオプションのみが用意されていますが、検索には会話型検索の全機能が用意されています。

買い物客のサイトで会話型検索が有効になっている場合、次の 3 つのシナリオのいずれかが発生するまで、フォローアップの質問によって会話が続行されます。

• 事前に設定されている最小商品数に達した（たとえば、商品が 2 つしか表示されない場合は、会話は役に立ちません）。
• ユーザーが商品をクリックしてカートに追加した（目標）。
• 小売向け検索とブラウジングで AI 生成の質問が不足している。

仕組み

会話型検索は、複数のターンにわたる継続的な会話でユーザーを引き付けることを前提としています。そのため、会話型検索を機能させるには、少なくとも 2 つ目のレスポンスが必要です。ユーザーには、フォローアップの質問と返事の候補が回答としてレスポンス内に表示されます。ユーザーは、返事を入力するか、候補の回答（多肢選択式のオプション）をクリックして、このフォローアップの質問に回答できます。

• 多肢選択式 多肢選択式のオプションは、フィルタリングによりクエリを絞り込むファセット（イベントタイプのフィルタ）のように機能します。ユーザーが多肢選択式のレスポンスをクリックすると、バックグラウンドでクエリにフィルタが適用されます。会話型の多肢選択を使用してフィルタを適用することは、動的ファセットまたはタイルを使用して同じフィルタを適用することと同じです。

• 自由形式のテキスト ユーザーが自由形式のテキストで回答した場合は、より絞り込んだ新しいクエリが生成されます。会話型検索がフィルタとユーザー イベントの収集を強化する仕組みについて詳しくは、ユーザー ジャーニーをご覧ください。

会話型検索のメリット

小売業向け Vertex AI Search を会話型検索で拡張すると、小売業者とユーザーの両方にメリットがあります。

数回のクリックでクエリを絞り込むことができる

会話型検索を使用すると、10,000 件の商品を 100 件未満に効率的に絞り込むことができます。これにより、ユーザーが購入を決定する可能性が高まり、検索あたりの収益率が高まります。

動的ファセットの代わりに使える

動的ファセットは、クエリあたりの収益率が低い幅広いクエリに関連付けられます。数十万件もの検索結果が表示されると、ユーザーは圧倒され、検索を中断するリスクが生じます。特に、商品数が非常に多い検索クエリでは、クエリあたりの収益率が異常に低くなります。会話型検索ではクエリを絞り込むことができ、動的ファセットと組み合わせて使用できます。会話型検索には、動的ファセットにはないいくつかの利点があります。より人間味があり、よりインタラクティブで、ページ上のスペースをより少なく使用できます。

小売業者の設定に合わせて質問の生成をカスタマイズできる

会話型検索では、アップロードされたカタログに基づいて、小売業者が好みに応じて AI 生成の質問を事前に編集、上書き、選択解除できるため、生成 AI の質問と人間参加型のやり取りができます。検索に表示する質問を調整するには、小売り向け検索コンソールまたは API で質問を個別または一括で編集または無効にします。

コンソール: 管理者の場合

コンソールを使用すると、小売業者は小売業向け Vertex AI Search のエクスペリエンスで生成された質問を管理できます。詳しくは、生成された質問を会話型検索で使用する方法をご覧ください。

質問生成サービスを利用する手順

1. データ要件を満たしていることを確認します。

2. 手動によるオーバーライドを構成します。

3. 機能をオンにします。

4. プレビューとテストを行います。

データ要件

コンソールの [会話型検索とブラウジング] の [カバレッジのチェック] タブ、または [データ品質] > [会話] で、検索データが会話型検索向けに準備されているかどうかを確認できます。

会話型検索を有効にするには、特定のデータ要件を満たす必要があります。

具体的には、次のとおりです。

1. 1,000 件のクエリ / 日: この最初のしきい値に達すると、入力と出力を評価する会話プランが生成されます。
   • 入力: イベント内のフィルタ数
   • 出力: 会話のカバレッジ
2. 25% の会話カバレッジ: 小売業向け Vertex AI Search モデルによって計算されます。会話カバレッジとは、1 つの質問を含むクエリの割合を意味します。頻度を重視したクエリの 25%（量ベース）に、一致する最初の質問が少なくとも 1 つ含まれている必要があります。

会話カバレッジが 25% に満たないものの、最初の前提条件である 1,000 件のクエリを 1 日あたり処理している場合は、ブロックとアドバイザリのチェックがそれぞれ出力と入力に適用されます。この場合、小売業向け Vertex AI Search は、会話カバレッジのしきい値である 25% に達するために、ユーザー イベントに適用されるフィルタをどの程度増やす必要があるかを計算します。アップロードするフィルタが多いほど、カバレッジは高くなります。

会話の準備状況を確認するには:

1. 小売向け検索コンソールの [データ品質] ページの [会話] タブに移動します。検索クエリの 25% 以上にフォローアップの質問が 1 つ以上含まれているかどうかの重要なチェックと、会話カバレッジの目標を達成するために有効なフィルタを持つユーザー イベントのどのくらいの割合が必要かに関する推奨チェックが表示されます。

2. 有効なフィルタと十分なユーザー イベントがあり、重要なチェックに合格した場合は、次のステップに進みます。

3. 生成された質問の配信方法を管理するには、小売向け検索コンソールの [会話型検索とブラウジング] ページに移動します。

生成された質問のコントロール

生成 AI は、カタログ内のインデックス登録可能な属性ごとに質問を作成します。このとき、システム属性とカスタム属性の名前と値の両方を使用します。これらの質問は LLM によって生成され、検索エクスペリエンスの向上を目的としています。たとえば、家具の種類には「屋内」と「屋外」の値を指定できます。AI は、ユーザーが探している家具の種類に関する質問を生成します。

各ファセットには、生成された質問が 1 つあります。質問は、過去の検索イベント データに基づくユーザー イベントとファセットのエンゲージメントに基づいて、表示される頻度が予想される順に並べ替えられます。AI はまず上位の質問を検討し、次に属性ごとに関連するものを見つけます。質問のリストは 1 回生成されます。新しい属性が追加されると、2 時間以内にリストに反映されます。

1. 小売向け検索コンソールの [会話型検索とブラウジング] ページに移動します。
   
   [会話型検索とブラウジング] ページに移動する

2. [AI 生成の質問の管理] タブでは、使用頻度（クエリの重み付け頻度、つまり一般的なクエリで返される頻度）で並べ替えられたすべての質問を確認できます。ランキングでは、GenerativeQuestionConfig の frequency フィールドが使用されます。このフィールドは、AI 生成の質問を使用頻度で並べ替えるために使用されます。

3. フィルタ オプションを使用して質問をフィルタできます。

4. 各属性の質問の公開設定を有効にするには、チェックボックスをオンにします。

5. 各行の末尾にある アイコンをクリックすると、質問の編集パネルが開きます。

一括編集を行う手順は次のとおりです。

1. 会話に含める質問または除外する質問の横にあるチェックボックスをオンまたはオフにします。

2. リストの上部にある [会話で許可] ボタンまたは [会話で禁止] ボタンをクリックします。個々の質問を編集するには、 アイコンをクリックし、開いたペインで [会話で許可] の横にあるチェックボックスをオフまたはオンにします。

生成された質問を会話型検索で使用する方法

質問生成サービス API には、LLM の出力で生じる可能性のある不整合を軽減するためのコントロールが用意されています。これらはコンソールから管理できます。また、小売業者は、会話型検索を有効または無効に切り替えたり、会話型検索をトリガーするために必要な商品の最小数を設定したりすることで、会話型検索を構成することもできます。

質問を定義して、質問自体、考えられる回答、会話で質問を許可するかどうかを指定できます。個々の質問は LLM によって生成されるか、買い物客によってオーバーライドされます。コンソールでは、AI 生成の質問を確認できます。買い物客は、質問をオーバーライドしたり、会話のステータスを切り替えたりできます。質問を一括編集することもできます。

個々の質問を編集する

コントロールを使用して個々の質問をキュレートすることもできます。会話型検索を有効にする前に、この設定を行うことをおすすめします。

各質問には 2 つのオプションがあります。最後の列の アイコンをクリックして、ユーザーに表示される質問パネルにアクセスします。

1. すべてのクエリで質問を無効にする: 質問はデフォルトで有効になります。[会話で許可] の横にあるチェックボックスをオフにします（または再度オンにします）。このオプションを選択すると、その質問は完全にスキップされます。質問がクエリされた属性に関連していない場合や、不適切と誤解される可能性がある場合（「ドレスのサイズを教えていただけますか？」という質問は、買い物客の体重を尋ねているように受け取られる可能性があります）、買い物客は質問を完全に無効にできます。
2. 質問を書き換える: このペインには、AI 生成の質問、その質問が関連付けられている属性、その属性の値が表示されます。鉛筆アイコンをクリックして書き換えます。

会話型検索をオンにする

コンソールで生成 AI による質問を編集したら、会話型検索をオンにできます。

会話型検索を有効にするには、小売向け検索コンソールの [会話型検索とブラウジング] ページに移動します。

1. 小売向け検索コンソールの [会話型検索とブラウジング] ページに移動します。
   
   [会話型検索とブラウジング] ページに移動する

2. 小売向け検索の [設定] タブに、システム全体の設定が表示されます。ここには、会話が開始される前にクエリに一致させるために必要な商品の最小数も設定できます。この最小数は 2 です。最小値は大きく設定できますが、2 より小さくすることはできません。ユーザーが会話を開始するために検索で返すカタログ内の商品の数を検討してください。たとえば、会話を開始するのに十分な検索結果を表示するには、1 ページに 1 行が適しています。

3. 切り替えボタンをオンにします。このページには、ブロックとアドバイザリのチェックのステータスも表示されます。1 つ以上のフォローアップの質問を含む十分な数の検索クエリが存在する場合、サイトでは会話型検索が有効になります。

評価とテストを行う

[評価] では、テスト検索を実行し、表示されたファセットに対して質問をテストすることで、サービング エクスペリエンスをプレビューできます。ここでは、会話型検索でのサービング エクスペリエンスのプレビューを確認できます。

確認を行うには、小売向け検索コンソールの [評価ページ] の [検索] タブまたは [参照] タブでこのモジュールを見つけます。

1. Search for Retail コンソールの [評価] ページに移動します。
   
   [評価] ページに移動

2. [検索評価] フィールドに、アップロードしたカタログに基づいて適切なテストクエリを入力します。[検索プレビュー] をクリックします。検索結果が表示されます。会話型検索が有効になっている場合は、右側のパネルに生成された質問が表示されます。

3. 右側のパネルに、テストの質問のリストが表示されます。

質問生成の API: 管理者向けの機能

このセクションでは、質問生成 API を使用して、会話型検索 API を UI に統合し、質問の生成を管理して、サイトにこの機能を提供する方法について説明します。

API 統合

• 次の方法で、小売向け検索から GenerativeQuestion API を管理します。
  • [会話型検索とブラウジング] コンソール
  • データ品質
  • 評価

オブジェクト:

• GenerativeQuestionsFeatureConfig
• GenerativeQuestionConfig
• GenerativeQuestions Service
  • UpdateGenerativeQuestionsFeatureConfiguration
  • UpdateGenerativeQuestionConfig
  • ListGenerativeQuestionConfigs
  • GetGenerativeQuestionFeatureConfig
  • BatchUpdateGenerativeQuestionConfigs

この機能の統合において重要なのは、「質問」リソースの定義です。これには、質問自体と、会話で質問が許可されているかどうかが含まれます。質問はデフォルトで LLM によって生成されますが、管理者がオーバーライドできます。

機能を有効にする

オブジェクト:

• GenerativeQuestionsFeatureConfig

このオブジェクトは、会話型検索の全体的なサービング エクスペリエンスを管理するために、質問生成機能を有効にする制御構成ファイルです。GenerativeQuestionsFeatureConfig は、GET メソッドを使用して、プロジェクトに関連付けられたカタログから属性情報と、属性がインデックスに登録可能かどうかを取得します。

feature_enabled スイッチは、サービングにおいて質問を使用するかどうかを決定します。コンソールの最上位の切り替えボタンを管理します。

注: 初期のデータ要件が満たされるまで、この機能を有効にすることはできません。データ要件が満たされていない場合、API は検証エラーをトリガーします。データ要件の検証は、小売向け検索で確認できます。内部的には、この機能構成 API を呼び出しています。

詳しくは、コンソールで会話型検索をオンにするをご覧ください。

API で機能を有効にする

// Configuration for overall generative question feature state.
message GenerativeQuestionsFeatureConfig {
...

  // Resource name of the affected catalog.
  // Format: projects/{project}/locations/{location}/catalogs/{catalog}
  string catalog = 1 [(google.api.field_behavior) = REQUIRED];

  // Determines whether questions will be used at serving time.
  // Note: This feature cannot be enabled until initial data requirements are
  // satisfied.
  bool feature_enabled = 2 [(google.api.field_behavior) = OPTIONAL];

  // Minimum number of products in the response to trigger follow-up questions.
  // Value must be 0 or positive.
  int32 minimum_products = 3 [(google.api.field_behavior) = OPTIONAL];
}

会話に関連するフィールド
カタログ	文字列。影響を受けるカタログのリソース名（プロジェクト レベル）。形式: projects/{project}/locations/{location}/catalogs/{catalog}
feature_enabled	ブール値。質問のオンとオフを切り替えます。このフィールドは省略できます。データ要件が満たされるまで有効にすることはできません。試行すると、エラーがスローされます。
minimum_products	整数（32 ビット）。フォローアップの質問をトリガーするレスポンス内の商品の最小数です。0 以上の値を指定してください。

質問の生成を管理する

オブジェクト:

• GenerativeQuestionConfig

ブール値フィールド allowed_in_conversation を使用して会話で有効にできます。生成された 1 つの質問の構成を制御します。

フィールド（ハイライト表示された会話の動作を制御）
カタログ	string。使用可能な属性セット（および拡張して質問）を識別するために使用されます。これらの値はすべてカタログで定義されています。必須フィールド。
facet	string。質問が関連付けられているファセットです。必須フィールド。
generated_question	string。LLM が生成するデフォルトの質問です。出力専用。
final_question	string。表示される質問です。最大長は 300 バイトです。このフィールドは省略できます。
example_values	Repeated string。質問への回答に使用できる値です。出力専用です。
frequency	float。質問が表示された頻度の割合です。出力専用。
allowed_in_conversation	boolean。サービングにおいてに質問を表示するかどうかを決定します。このフィールドは省略できます。

この機能によって有効になるサービング エクスペリエンス

質問生成サービス（service GenerativeQuestionService{...}）は、LLM 生成の質問の管理に使用されます。親オブジェクトはカタログで、特定のカタログの質問を返す情報を取得します。このサービスは、質問生成機能の全体的な状態の管理、個別または一括での変更、質問のオンとオフの切り替えに使用されます。Service API と連携するにはデータ要件を満たす必要があり、質問を管理するには、まず質問を初期化する必要があります。

このサービスは、2 つのハンドラセットを使用して、特徴レベルの構成および質問レベルの構成とやり取りを行います。

• GenerativeQuestionsFeatureConfig ハンドラ（特徴レベル）:

  1. Update: 商品の最小数を変更し、フィールドを有効にできます
  2. Get: オブジェクトを返します

• GenerativeQuestionConfig ハンドラ（質問レベル）:

  1. List: 指定されたカタログのすべての質問を返します
  2. Update: 個々の質問を管理します
  3. 一括更新: グループ化された質問を管理します

サービスは、最初のクエリに基づいて意味的に適切な質問を返します。

フォローアップの質問は LLM モデルによって生成され、オーバーライドできます。質問は、検索イベント履歴を呼び出して、ユーザーが使用する可能性に基づいて表示されます。検索イベント履歴がない場合は、買い物客の検索ログがフォールバックされます。

前のクエリに基づいて、さまざまな質問が生成されます。重みは固定されていません。LLM 生成の質問を駆動する AI はクエリから学習し、クエリごとに重み付けを変更します。たとえば、「シャツ」ではカテゴリに非常に高い重み付けが設定されますが、「XL の赤いシャツ」ではカテゴリ、サイズ、色に重み付けが設定されます。

会話型検索構成の API: サービング エクスペリエンス

会話型検索構成の API は、Vertex AI API の検索 API と統合されています。

API 統合

この特徴の構成 API ConversationalSearchSpec は、既存の小売業向け Vertex AI Search API の上に構築されています。新しい機能である会話型検索をサポートするために、既存の小売業向け Vertex AI Search のメイン（クエリ）API に次の変更が加えられました。

• ConversationalSearchSpec: このオプション フィールドは SearchRequest に追加されましたが、会話型検索機能を使用する場合、必須です。このフィールドは、SearchRequest フィールド、クエリ、フィルタを再利用します。また、最初のクエリの後にユーザーにフォローアップの質問を送信するためのフィールドと、クライアントとサーバー間の会話の状態を維持するための conversation_id も含まれています。

• ConversationalSearchResult: proto ファイルには、SearchResponse の会話型 CRS フローに対して返す必要がある追加情報が含まれています。これには、conversation_id、refined_query、additional_filters、follow_up_question、suggested_answers が含まれます（ユーザー ジャーニーのセクションをご覧ください）。

ユーザー ジャーニー

会話フローは次のとおりです。ユーザーが最初のクエリで検索を開始し、followup_conversation_requested フラグが「true」に設定されます。ユーザーが回答を選択するか、自由形式のテキスト入力を入力すると、user_answer フィールドを使用して API に送り返されます。API は、ユーザーの入力に基づいて検索結果を絞り込み、新しいフォローアップの質問を表示します。これにより、ユーザーが買い物客のウェブサイトで目的のアイテムを見つけるまで、複数のターンで会話が続きます。

ウェブサイトで会話型検索が有効になっている場合、ユーザー ジャーニーとその後の小売業向け Vertex AI Search とのやり取りは次のようになります。

• ステップ 1. 最初のクエリがユーザーから送信される
• ステップ 1a. フォローアップの会話リクエストが検索に送信される
• ステップ 1b. 絞り込まれたクエリと候補の回答を含む最初の検索レスポンスが行われる
• シナリオ 2: ユーザーが多肢選択式を選択する
• ステップ 2a. 選択された回答フィルタが検索に送信される
• ステップ 2b. フィルタが適用されて検索が再度実行される
• シナリオ 3: ユーザーが自由形式のテキストを選択する
• ステップ 3a. 検索にテキスト回答が送信される
• ステップ 3b. 変更されたクエリで検索が再実行される

ステップ 1. 最初のクエリがユーザーから送信される

conversational_search_spec: SearchRequest メッセージ内にこのフィールドを導入することで、システムは会話型検索と通常検索を区別できるようになります。この判断は、ユーザーが追加の会話型レスポンスを受け取るかどうかに影響します。これにより、元の検索機能は維持されながら、会話型インタラクションに拡張されます。conversational_search_spec フィールドはメッセージ形式で、ユーザーの回答、会話 ID、ユーザーがフォローアップの会話を希望するかどうかなど、会話フローに必要な詳細情報が格納されます。この情報は、コンテキストとユーザー操作を理解するうえでシステムに役立ちます。

ブール値 followup_conversation_requested が TRUE に設定されている場合、API は最初の結果セットとフォローアップ クエリを返します。ユーザーは会話型の検索エクスペリエンスを利用できます。このフィールドが「FALSE」に設定されている場合、フォローアップの質問は表示されません。

ステップ 1a. 小売業者 → 検索: 会話が有効になっている最初のクエリ

JSON リクエスト

{
  "query": "dress",
  "conversational_search_spec":  {
    "followup_conversation_requested": true
  }
}

ステップ 1b. 検索 → 小売業者: 会話 ID、絞り込まれたクエリ、フォローアップの質問、候補の回答

JSON レスポンス

{
  "conversational_search_result": {
    "conversation_id": "c154d073-87f5-4edb-accd-587eabe014ff",
    "refined_query": "dress",
    "followup_question": "What is the color?",
    "suggested_answers": [
      {
        "product_attribute_value": {
          "name": "colors",
          "value": "yellow"
        }
      },
      {
        "product_attribute_value": {
          "name": "colors",
          "value": "blue"
        }
      },
      {
        "product_attribute_value": {
          "name": "colors",
          "value": "red"
        }
      }
    ]
  }
}

• conversational_search_result: ConversationalSearchResult は、会話フローで返された追加情報が含まれるプロトコルです。SearchResponse の conversational_search_result フィールドには、クライアントサイドでの UI レンダリングに不可欠な補足データが提供されます。conversational_search_result フィールドでは、SuggestedAnswer や AdditionalFilter などのネストされたメッセージを使用して、返されたデータを明確でわかりやすい方法で構造化します。この階層構造により、クライアントとサーバー間で交換される情報が明確に定義され、解釈可能になります。
• 回答は、カタログ内のファセット値が、すべてのクエリのフィルタとしてユーザー イベントで最も頻繁に使用された順に並べられます。並べ替えには、ConversationalSearch proto によって生成されたフォローアップの質問の engagement_rate フィールドが使用されます。このフィールドには、サーバーに送信された小売業者の検索イベントからフィルタが示す過去のエンゲージメント率がキャプチャされます。

最初の会話型検索の戻り値の処理

• conversation_id: 進行中の検索セッションの一意の識別子。後続のリクエストで保存して使用する必要があります。最初のクエリでは空で、サーバーは conversation_id で応答します。このフィールドは、1 人の買い物客が複数のタブやデバイスを開いている場合があるため、「進行中の会話」を追跡するために使用されます。
• refined_query: 現在のクエリを追跡し、ユーザーが検索を行うと更新されます。買い物客が自由形式のテキスト入力を選択した場合は、この設定が変更されます。買い物客が多肢選択式のオプションを選択した場合、このフィールドはリクエストのクエリと同じになります。
• followup_question: ユーザーに表示する質問を買い物客に伝えます。このメッセージには、question、suggested_answers が含まれます。
• suggested_answers: 回答ごとに名前と値の Key-Value ペアを含む商品属性値が含まれます。多肢選択式のオプションのリストが表示されます。このフィールドは、最初の N 個の多肢選択式の結果のみを表示するように設定できます。これらの質問は、質問が検索に関連する可能性を表す engagement_rate フィールドで並べ替えられます。

シナリオ 2: ユーザーが多肢選択式のオプションを選択する

ユーザーが多肢選択式の回答 yellow を選択した場合:

• conversation_id はセッション ストレージから復元されます。
• followup_conversation_requested は true に設定されています。
• user_answer 文字列: 1 つの product_attribute_value Key-Value ペアを含む「selected_answer」か、ユーザーの選択を示す値の自由形式入力を含む text_answer のいずれかを使用します。このフィールドは conversational_search_spec フィールド内にあり、ユーザー入力の種類（テキストまたは選択した回答）を指定する「SelectedAnswer」などのネストされたメッセージが含まれています。
• 結果は、SearchResults オブジェクトとそのフィールドの呼び出しに戻されます。
• selected_answer フィールドは、会話型検索をガイドするために商品属性を渡します。

ステップ 2a. 小売業者 → 検索: 選択した回答のフィルタ

JSON リクエスト

{
  "query": "dress",
  "conversational_search_spec": {
    "followup_conversation_requested": true,
    "conversation_id": "c154d073-87f5-4edb-accd-587eabe014ff",
    "user_answer": {
      "selected_answer": {
        "product_attribute_value": {
          "name": "colors",
          "value": "yellow"
        }
      }
    }
  }
}

ステップ 2b. 検索 → 小売業者: フィルタが適用されている

JSON レスポンス

{
  "conversational_search_result": {
    "conversation_id": "c154d073-87f5-4edb-accd-587eabe014ff",
    "refined_query": "dress",
    "additional_filter": {
      "product_attribute_value": {
        "name": "colors",
        "value": "yellow"
      }
    },
    "followup_question": "What is the occasion?",
    "suggested_answers": [
      {
        "product_attribute_value": {
          "name": "attribute.occasion",
          "value": "wedding"
        }
      },
      {
        "product_attribute_value": {
          "name": "attribute.occasion",
          "value": "party"
        }
      }
    ]
  }
}

多肢選択式のレスポンスの処理

検索レスポンスは、additional_filter も使用されていることを除いては、最初のクエリに対するレスポンスと同じです。この例では、color = yellow のフィルタ ボックスを「オン」にするために使用します。filter: "colors:ANY(\"yellow\")" のように、フォローアップの検索リクエストまたはイベント アップロードの filter フィールドに追加する必要があります。

シナリオ 3: ユーザーが自由形式のテキスト入力を選択する

ユーザーが lavender と入力した場合:

• conversation_id がセッション ストレージから復元される
• followup_conversation_requested が true に設定される
• user_answer がユーザーが入力したもの（text_answer: 接頭辞付き）に設定される

ステップ 3a. 小売業者 → 検索: テキスト回答

JSON リクエスト

{
  "query": "dress",
  "conversational_search_spec": {
    "followup_conversation_requested": true,
    "conversation_id": "c154d073-87f5-4edb-accd-587eabe014ff",
    "user_answer": {
      "text_answer": "lavender"
    }
  }
}

自由形式のリクエストにフィルタ フィールドがないことに注意してください。

ステップ 3b. 検索 → 小売業者: 変更したクエリを実行

JSON レスポンス

{
  "conversational_search_result": {
    "conversation_id": "c154d073-87f5-4edb-accd-587eabe014ff",
    "refined_query": "lavender dress",
    "followup_question": "What is the occasion?",
    "suggested_answers": [
      {
        "product_attribute_value": {
          "name": "attribute.occasion",
          "value": "wedding"
        }
      },
      {
        "product_attribute_value": {
          "name": "attribute.occasion",
          "value": "party"
        }
      }
    ]
  }
}

自由形式のレスポンスの処理

• 最初のレスポンスと同様ですが、refined_query が適切に更新されている点に注意してください。
• 検索ユーザー インターフェース（「検索ボックス」）を更新して、絞り込んだクエリを表示します。
• フォローアップの検索リクエストまたはイベントのアップロードで、イベント内の絞り込んだクエリを送信します。
• ユーザーが候補の回答と一致する自由形式の回答を入力した場合（候補の回答が colors="yellow" の場合に text_answer="yellow" を入力した場合など）、このケースは多肢選択式のレスポンスとして扱われます（上述）。