對話過濾開發人員指南

以下是開發人員指南，說明如何在 API 中整合對話式產品篩選功能。

達到最低資料門檻，啟用對話過濾功能

如要達到啟用對話式產品篩選功能所需的 25% 配額，您必須增加含有有效篩選資訊的使用者事件量。上傳的使用者事件篩選器越多，對話涵蓋範圍就越廣。

以下是提高涵蓋範圍的具體步驟和邏輯：

• 上傳使用者事件中的篩選器。您需要增加使用者事件套用篩選器的輸入內容。這樣一來，當使用者在網站上套用顏色或價格等篩選條件時，系統就會在傳送至 AI Commerce Search 的相應搜尋使用者事件篩選條件欄位中，擷取這項動作。

• 建立意見回饋循環。LLM 會根據這些篩選器推斷構面熱門程度。當屬性標示為可動態篩選時，只要在搜尋事件中加入對應的篩選條件，即可啟動模型的學習程序。理想情況下，使用者介面應擷取並轉送搜尋要求和事件中的使用者篩選條件選項，以持續改善模型。

• 監控資料品質建議檢查。如果已達到每日 1,000 次查詢的初始門檻，但涵蓋範圍未達 25%，控制台的「資料品質」頁面 (位於「對話」分頁下方) 會提供具體的建議檢查。這些檢查會計算並顯示使用者事件套用篩選條件必須增加的確切百分比，才能達到涵蓋率目標。

• 確認屬性設定。由於模型會使用您篩選的屬性來產生問題，請確保這些屬性在目錄中已正確設定為可建立索引和動態切面。

管理員體驗

直接在 API 或 Gemini Enterprise for Customer Experience 控制台的 AI Commerce Search 中，管理生成的問題和對話式產品篩選功能，並在 Gemini Enterprise for Customer Experience 控制台的 AI Commerce Search 中，於「資料品質」和「評估」部分進行設定。

Cloud 控制台

零售商可透過控制台，在對話式產品篩選體驗中管理生成的問題。進一步瞭解如何在對話式產品篩選功能中使用生成式問題。

使用生成問題服務的步驟

1. 符合資料規定。

2. 設定手動問題覆寫。

3. 開啟這項功能。

4. 預覽及測試。

資料條件

如要確認搜尋資料是否已準備好進行對話式產品篩選，請在控制台的「對話式產品篩選和瀏覽」或「資料品質」>「對話」下方，前往「涵蓋範圍檢查」分頁。

如要啟用對話式產品篩選功能，必須符合特定資料規定。

包括：

• 每天 1,000 次查詢：達到這個門檻後，系統會產生對話方案，評估您的輸入和輸出內容：
• 輸入內容：事件中的篩選器數量
• 輸出內容：對話涵蓋範圍
• 25% 的對話涵蓋率：由 AI 商業搜尋模型計算，對話涵蓋率是指含有一個問題的查詢所占百分比。加權頻率為 25% (依數量) 的查詢應至少有一個相符的第一個問題。

如果對話涵蓋率尚未達到 25%，但已符合每日 1,000 筆查詢的第一項先決條件，系統就會開始對輸出內容套用封鎖檢查，並對輸入內容套用建議檢查。此時，AI 商家搜尋會開始計算使用者事件套用的篩選條件必須增加多少百分比，才能達到 25% 的對話涵蓋率門檻。上傳的篩選器越多，觸及範圍就越廣。

如要查看對話準備程度，請按照下列步驟操作：

1. 前往 Gemini Enterprise for Customer Experience 控制台的「AI Commerce Search」頁面，然後點按「資料品質」分頁中的「對話」分頁。這項功能會進行重要檢查，判斷至少 25% 的搜尋查詢是否至少有一個後續問題，並提供建議檢查，判斷需要多少百分比的有效篩選器使用者事件，才能達成對話涵蓋率目標。

圖 1：檢查對話式搜尋準備程度。

1. 如果通過重要檢查，且有足夠的使用者事件和有效篩選條件，請繼續下一個步驟。

2. 如要控管生成問題的顯示方式，請前往 AI Commerce Search 控制台的「對話式產品篩選和瀏覽頁面」。

生成問題控制選項

生成式 AI 會為目錄中的每個可建立索引的屬性撰寫問題，並使用系統和自訂屬性的名稱和值。這些問題是由 LLM 生成，旨在提升搜尋體驗。舉例來說，如果家具類型的值是室內或室外，AI 就會合成問題，詢問你要找哪種家具。

每個面向都會生成一個問題。系統會根據歷來使用者事件和過去搜尋事件資料中的構面參與度，依問題預期出現的頻率排序。AI 會先查看頂端的提問，然後依據屬性找出相關內容。系統會產生一次問題清單。如果新增屬性，清單會在兩小時內反映變更。

1. 前往 Gemini Enterprise for Customer Experience 控制台的 AI Commerce Search「購物代理程式」頁面。
   
   前往對話式搜尋和瀏覽頁面。

2. 在「管理 AI 生成的問題」分頁中，查看所有問題，並依查詢加權頻率排序，也就是問題與常見查詢一起顯示的頻率。排名會使用 GenerativeQuestionConfig 設定中的頻率欄位。這個欄位負責根據使用頻率排序 AI 生成的問題。

3. 你可以使用篩選器選項篩選問題。

4. 勾選方塊，為每個屬性啟用問題顯示功能。

5. 按一下每列結尾的 ，即可開啟每個問題的編輯面板。

如要大量編輯，請按照下列步驟操作：

1. 選取或取消選取要納入或排除在對話中的問題旁邊的方塊。

2. 按一下清單頂端的「允許在對話中使用」或「禁止在對話中使用」按鈕。如要編輯個別問題，請按一下 ，然後在開啟的窗格中，清除或重新勾選「允許在對話中使用」旁邊的方塊：

圖 2：編輯每個 AI 生成的問題。

在對話式產品篩選功能中使用生成的問題

生成問題服務 API 提供控制項，可減少 LLM 輸出內容可能出現的不一致情形。您可以在控制台中管理這些項目。零售商也可以在這裡切換啟用狀態，並設定觸發對話式產品篩選的最低產品數量，藉此設定這項功能。

您可以定義問題、指定問題本身、可能的答案，以及是否允許在對話中提出問題。個別問題可由 LLM 生成，或由零售商覆寫。零售商可在控制台中查看 AI 生成的問題、覆寫問題或切換對話狀態。你也可以大量編輯問題。

編輯個別問題

您也可以使用控制項來管理個別問題。建議您先完成這項作業，再開啟對話式產品篩選功能。

每個問題都有兩個選項。按一下最後一欄的 ，即可存取「使用者可見問題」面板：

1. 為所有查詢關閉問題：問題預設為啟用。取消勾選 (或再次勾選)「允許在對話中使用」旁的方塊。這個選項會直接略過問題。如果問題與查詢的屬性無關，或可能被誤解為不當內容 (例如「你要找什麼尺寸的洋裝？」這類問題可能會被視為探詢體重)，零售商可以選擇完全停用問題。
2. 改寫問題：在窗格中，你可以查看 AI 生成的問題、附加的屬性，以及屬性的值。按一下鉛筆圖示即可重新撰寫。

開啟對話過濾功能

在控制台編輯生成式 AI 問題後，即可啟用對話式產品篩選功能。

如要啟用對話式產品篩選功能，請前往 Gemini Enterprise for Customer Experience 控制台的 AI Commerce Search，然後點選「對話式產品篩選和瀏覽頁面」。

1. 前往 Gemini Enterprise for Customer Experience 控制台的 AI Commerce Search「購物代理程式」頁面。
   
   前往對話式搜尋和瀏覽頁面。

2. 請考量目錄中要傳回搜尋結果的產品數量下限，系統才會生成問題。這個數字可以更高，但絕不會低於 2。通常一列就足以觸發對話。

3. 設定號碼，然後將切換鈕設為「開啟」。如果相符的產品數量較少，就會遭到篩除。

圖 3. 將切換鈕切換為「啟用對話式搜尋」。

注意： 如果啟用生成式 AI，且大型語言模型將 AI 生成的問題與任何相關屬性值建立關聯，系統可能會顯示 AI 問題。

本頁面提供封鎖和建議檢查的狀態資訊。如果搜尋查詢中至少有一個後續問題，表示網站已啟用對話式搜尋功能。

評估及測試

評估功能可讓您執行測試搜尋，並根據顯示的層面測試問題，預覽放送體驗。控制台的這部分會顯示提供對話式產品篩選功能的服務預覽畫面。

如要評估及測試，請按照下列步驟操作。在 Gemini Enterprise for Customer Experience 控制台的 AI Commerce Search 評估頁面，點選「搜尋」或「瀏覽」分頁的「評估」部分。

1. 前往 Gemini Enterprise for Customer Experience 控制台的「AI Commerce Search」頁面。
   
   前往「評估」頁面

2. 按一下「搜尋」或「瀏覽」。

3. 在「Search Evaluation」(搜尋評估) 欄位中，根據你上傳至搜尋的目錄輸入合理的測試查詢，例如目錄包含服飾，則輸入「鞋子」。

4. 按一下「搜尋預覽」即可查看搜尋結果。

圖 4. 預覽結果。

啟用對話式產品篩選功能後，系統就會啟用生成式問題。

Generative Question API

本節說明如何使用生成問題 API，將對話式 API 整合至網頁介面、管理生成問題，以及在網站上提供對話式產品篩選功能。

API 整合

物件：

• GenerativeQuestionsFeatureConfig
• GenerativeQuestionConfig
• 生成問題服務
  • UpdateGenerativeQuestionsFeatureConfiguration
  • UpdateGenerativeQuestionConfig
  • ListGenerativeQuestionConfigs
  • GetGenerativeQuestionFeatureConfig
  • BatchUpdateGenerativeQuestionConfigs

整合對話式產品篩選功能的關鍵在於定義 question 資源。包括問題本身，以及是否允許在對話中使用該問題。問題預設由 LLM 生成，但管理員可以覆寫。

啟用對話式產品篩選

物件：

• GenerativeQuestionsFeatureConfig

這個物件是控制項設定檔，可啟用生成問題的對話式產品篩選功能，以管理整體放送體驗。GenerativeQuestionsFeatureConfig 會使用 GET 方法，從與專案相關聯的目錄取得屬性資訊，以及屬性是否可編入索引。

feature_enabled 切換鈕可決定在放送時是否使用問題。可管理控制台中的頂層切換按鈕。

注意： 你必須先滿足資料規定，才能啟用對話式產品篩選功能。如果未符合資料規定，API 會觸發驗證錯誤。資料規定驗證會顯示在 Gemini Enterprise for Customer Experience 控制台的 AI Commerce Search 中，該控制台會在幕後呼叫 Conversational Configuration 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 are used at serving time.
// Note: You cannot enable this 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	Integer32	回應中的產品數量下限，達到這個數量就會觸發後續問題。值必須等於或大於 0。

管理生成的問題

物件：

• GenerativeQuestionConfig

您可以使用布林欄位 allowed_in_conversation，為問題啟用對話功能。這項設定可控制單一生成問題的設定。

欄位 (醒目顯示對話的控制行為)
目錄	字串	用於識別可用的屬性集 (以及延伸問題)。這些值全都在目錄中定義。必填欄位。
facet	字串	與問題相關的構面。必填欄位。
generated_question	字串	大型語言模型生成的預設問題。僅供輸出。
final_question	字串	提出的問題。長度上限為 300 位元組。選填欄位。
example_values	重複字串	可用於回答問題的值。僅供輸出。
頻率	float	問題的詢問頻率比率。僅供輸出。
allowed_in_conversation	布林值	是否在放送時詢問問題。這是選填欄位。

服務體驗

對話式產品篩選功能會與使用者進行多輪對話，因此，對話式產品篩選功能至少需要第二個回覆才能運作。使用者會在回覆中看到後續問題和建議答案，並可輸入答案或點選建議答案 (選擇題選項) 回答後續問題。

選擇題選項在幕後運作時，就像是層面 (事件類型篩選器)，會使用篩選功能縮小查詢範圍。在背景中，使用者點選選擇題答案時，系統會將篩選器套用至查詢。使用對話式多重選擇套用篩選器，與使用動態分頁或圖塊套用相同篩選器的方式相同。

透過對話式產品篩選器啟用的服務

生成問題服務 (service GenerativeQuestionService{...}) 用於管理 LLM 生成的問題。其父項物件是目錄，可從中擷取資訊，並傳回特定目錄的問題。這項服務可用於管理整體生成問題狀態、進行個別或批次變更，以及開啟或關閉問題。如要與 Service API 介接，必須符合資料規定，且問題必須先初始化，才能進行管理。

這項服務會透過兩組處理常式，與功能層級和問題層級的設定檔互動：

• GenerativeQuestionsFeatureConfig 處理常式 (功能層級)：

  1. 更新：可變更最低產品數量，以及啟用欄位。
  2. Get：傳回物件。

• GenerativeQuestion Config 處理常式 (問題層級)：

  1. 清單：傳回指定目錄的所有問題。
  2. 更新：管理個別問題。
  3. 批次更新：執行分組問題管理作業。

服務會根據初始查詢，傳回語意上適當的問題。

後續問題是由 LLM 模型生成，可以覆寫。系統會呼叫搜尋事件記錄，根據顧客使用問題的機率顯示問題。如果沒有搜尋事件記錄，系統會改用電子商務搜尋記錄。

系統會根據先前的查詢生成不同的問題。沒有固定重量。系統會根據查詢內容調整權重，例如「襯衫」會大幅加重類別權重，但「XL 紅色襯衫」則會加重類別、尺寸和顏色權重。

設定供應體驗

整合對話式篩選設定 API 與 Search API，設定放送體驗。

這項功能的設定 API ConversationalFilteringSpec 位於 Conversational API 的頂端。您可以平行呼叫這兩個 API，也可以依下列順序呼叫：

1. Conversational API
2. Search API

• ConversationalFilteringSpec：這項選用欄位已新增至 ConversationalSearchRequest，但如要使用對話式產品篩選功能，就必須填寫這個欄位。這個欄位會重複使用 SearchRequest 欄位、查詢和篩選器。此外，這個物件還包含一個欄位，可讓系統在使用者提出初始查詢後，向使用者顯示後續問題，以及一個 conversation_id，用於維護用戶端與伺服器之間的對話狀態。
• ConversationalFilteringResult：proto 檔案包含 ConversationalSearchResponse 中對話式 CRS 流程需要傳回的額外資訊。包括 conversation_id、refined_query、additional_filters、follow_up_question 和 suggested_answers。

對話式 API 的使用者歷程

使用者以初始查詢發起搜尋，並將 mode 旗標設為 CONVERSATIONAL_FILTER_ONLY。使用者選取答案後，系統會使用 user_answer 欄位將答案傳回 API。

Conversational API 會在回應中提供 additional_filter 欄位。使用者必須將這些篩選器套用至 Search API 後續要求。搜尋結果會根據使用者的輸入內容提供新的後續問題，提示使用者進行後續查詢，並在多輪對話中持續進行，直到使用者在零售商網站上找到所需商品為止。

注意： 對話式產品篩選介面會與兩個 API 互動，包括搜尋和對話。Search API 用於擷取搜尋結果，Conversational API 則用於擷取對話式回覆。Conversational API 不會傳回搜尋結果。

假設網站已啟用對話式產品篩選功能，使用者歷程和後續與 AI 輔助商務搜尋的互動會遵循以下路徑：

• 步驟 1：使用者向 Search API 和 Conversational API 提出第一項查詢。Search API 只會傳回搜尋結果。Conversational API 會傳回建議答案和後續問題。針對相同查詢或 page_category 呼叫 Search API，並擷取搜尋結果。系統會將要求後續對話傳送至對話式搜尋。使用正確的對話篩選模式呼叫 Conversational API。

• 步驟 2：初始搜尋回應，僅包含搜尋結果。Conversational API 會傳回建議答案和後續問題，藉此修正查詢。然後選取多個選項：

  • 選取的答案篩選器會傳送至 Conversational API。
  • 對話和搜尋 API 會套用篩選條件。

使用者初始查詢

使用者在 AI 商業搜尋中開始對話，並在搜尋框中尋找 dress 時，就會觸發第一次查詢。

• 使用者動作：使用者搜尋「洋裝」。
• 您的實作方式：發出兩次 API 呼叫。
• 對話式 API 要求：
  • query：「dress」
  • conversational_search_spec：
    • mode："CONVERSATIONAL_FILTER_ONLY"這是鍵參數。
• Search API 要求：
  • query：dress
• 對話式 API 回應：
  • conversation_id：「c15...」儲存這個變數。
  • followup_question：系統會生成「這是什麼顏色？」問題。
  • suggested_answers：[ {name: "colors", value: "yellow"}, {name: "colors", value: "blue"}, ... ]
• 動作：向使用者顯示 followup_question 和 suggested_answers。

注意： 有兩個不同的 API 端點。您必須使用核心搜尋 API 擷取搜尋結果，並使用對話式 API 擷取對話式體驗。對話式 API 不會傳回搜尋結果。

傳送要求至 Search API

建立下列搜尋要求，並將 dress 設為查詢 (或實際查詢內容)，藉此向 Search API 傳送要求：

Search API 要求

{
  query: "dress",
  Search_params : {
    "filter": string,
    "canonicalFilter": string,
    "sortBy": string,
    "boostSpec": {
       object (BoostSpec)
    }
  }
}

對話式產品篩選功能不會變更搜尋 API 要求。

傳送要求至 Conversational API

如要傳送要求至 Conversational API，請按照下列步驟操作：

• 將 dress 設為查詢 (或實際查詢內容)，建立對話式搜尋要求。

• 將 mode 設為 CONVERSATIONAL_FILTER_ONLY，即可取得對話式回覆。如果設為 DISABLED，系統就不會提供後續問題。

• 在對話式搜尋要求中填入 SearchParams。搜尋參數應與 Search API 呼叫相同。

對話式 API 要求

{
  "query": "dress",
  "conversational_search_spec":  {
    "mode": "CONVERSATIONAL_FILTER_ONLY"
  }
}

Conversational API 回應

對話式 API 的回應如下所示：

對話式 API 要求

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

如何處理回覆：

• conversation_id：這個 ID 可以儲存在瀏覽器工作階段儲存空間中，並用於繼續與伺服器進行對話式搜尋。由於一位購物者可能會開啟多個分頁，並進行多場對話，因此系統會使用 conversation_id 追蹤對話。
• refined_query：識別目前的查詢。您必須使用這項回應呼叫 Search API，才能擷取產品結果。
• followup_question：識別要向使用者顯示的問題。
• suggested_answers：應向使用者顯示的多項選擇題答案排序清單。如要減少顯示的答案，只要顯示前 N 筆結果即可。清單會按照結果的顯示順序排序。

這樣一來，初始查詢就會啟用對話功能。

對話式 API 要求

{
  "query": "dress",
  "conversational_search_spec":  {
    "mode": "CONVERSATIONAL_FILTER_ONLY"
  }
}

搜尋處理選擇題答案

• 使用者動作：點選黃色。
• 您的實作方式：發出兩次新的 API 呼叫。
• 對話式 API 要求：
  • query：dress
  • conversation_id："c15..."使用儲存的 ID。
  • user_answer: { selected_answer: { product_attribute_value: { name: "colors", value: "yellow" } } }
• Search API 要求：
  • query：dress。
• 對話式 API 回應：
  • additional_filter: { product_attribute_value: { name: "colors", value: "yellow" } }
  • followup_question：活動/場合類型為何？
• 動作：使用 additional_filter 更新網頁介面，例如勾選黃色篩選方塊，並顯示新問題。

Conversational API 回應

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

• conversational_filtering_result 欄位與 ConversationalFilteringResult 相關，後者是包含對話流程傳回額外資訊的 proto。ConversationalSearchResponse 中的 conversational_filtering_result 欄位提供補充資料，對使用者介面算繪作業至關重要。conversational_filtering_result 欄位會使用巢狀訊息 (例如 SuggestedAnswer 和 AdditionalFilter) 清楚明瞭地建構傳回的資料。這種階層式結構可確保用戶端和伺服器之間交換的資訊明確且可解讀。
• 系統會根據目錄中哪些層面值最常在使用者事件中做為所有查詢的篩選條件，排序建議答案。排序依據是 ConversationalSearch 服務生成的後續問題中的 engagement_rate 欄位。這個欄位會擷取篩選器顯示的過往參與度，該篩選器來自傳送至伺服器的零售商搜尋事件。
• 使用對話功能時，其他欄位不會變更。

如何處理對話式搜尋的初步結果

• 在用戶端，開發人員應將 conversation_id 儲存在瀏覽器工作階段儲存空間中，以便繼續與伺服器進行對話式搜尋。
• 這項資訊可用於追蹤進行中的對話，因為一位購物者可能會開啟多個分頁，同時進行多場對話。

refined_query 會告知零售商目前的查詢內容。

• 如果零售商想向使用者顯示目前的查詢，就應使用這項功能。

followup_question 會告知零售商要向使用者顯示的問題

suggested_answers。

• 這是應向使用者顯示的選擇題答案排序清單。
• 如要顯示的結果少於完整清單，請只顯示前 N 個結果
• 這個清單已排序，因此必須依正確順序顯示。換句話說，系統會先顯示清單中的第一個結果。

對話式產品篩選功能會提供下列選項，讓使用者繼續對話互動，更快縮小搜尋範圍：

使用者看到搜尋結果時，可以選取單選題選項。

這個程式碼範例顯示使用者選取了複選題答案「黃色」，並再次傳送查詢，同時套用正確的使用者篩選條件，將新的對話要求傳送至 Search API。

Search API 要求

{
  query: "dress",
  "search_params": {
    "boost_spec": {},
    "canonical_filter": "",
    "filter": "colors: ANY("yellow")"
    "sort_by": ""
  }
}

如要傳送要求至 Conversational API，請執行下列操作：

1. 從工作階段儲存空間還原 conversation_id。
2. 將 mode 設為 CONVERSATIONAL_FILTER_ONLY。
3. 針對使用者選取的項目設定 user_answer。

對話式 API 要求

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

Conversational API 的回應會如下所示：

Conversational API 回應

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

如何處理回覆：

• Google 回應基本上與第一個查詢的回應相同，但 additional_filter 欄位可用來勾選 color = yellow 的篩選方塊，且應新增至使用者選取的任何其他篩選條件。
• 此外，針對這項後續查詢和後續搜尋要求，傳送至 Google 的篩選器欄位事件也應加入 additional_filter。這項設定應套用至搜尋要求，以擷取搜尋產品，也應套用至對話式搜尋要求，以擷取後續對話。
• 應將 refined_query 傳送至 Search API，以擷取更多相關產品。

實作產品篩選器

本節將引導使用者在 API 層級導入對話式產品篩選功能。起始 (中性) 狀態是到達網頁，可能含有搜尋列、建議或行銷廣告活動，視您的 AI 商家搜尋應用程式而定。尚未呼叫 Search 或 Conversation API。

起始狀態

這是使用者介面、建議或廣告活動的到達網頁。尚未發送任何 Search for Conversational API 呼叫。

使用者輸入查詢

輸入查詢內容，例如「口紅」，對 Search 和 Conversation API 發出平行呼叫。

搜尋和對話服務會先顯示第一個問題

系統會顯示 API 回應，包括初始問題和一組答案選項。對話式和搜尋 API 對初始使用者查詢的回覆分別為非同步。

使用者選取顯示的答案或篩選條件

使用者選取顯示的答案或篩選條件。

使用者選取後，系統會使用使用者的篩選條件或答案，再次呼叫這兩個 API。

API 會提供後續問題

Search 和 Conversation API 都會以非同步方式回應，以服務另一個問題並顯示答案選項。

使用者會看到下一個問題，以及下一個問題的一組答案選項。

極端案例

實作作業涵蓋了其他幾種可能情況。

使用者輸入新查詢

如果使用者正在輸入查詢的對話篩選條件 (例如「口紅」)，網頁介面已填入 API 的初始回應。不過，當使用者輸入新查詢 (例如「防曬乳」) 時，系統會開啟新的對話。如果發生這種情況，API 實作會還原為新查詢，但 conversation_id 欄位會空白。這項新查詢會重新生成新的回覆，並在網頁介面中重新填入新的相應回覆。

使用者取消選取構面篩選器或先前回答的問題

如果使用者介面已填入先前查詢的回應，但使用者取消選取所選的構面篩選器或答案，系統會使用 searchParam 篩選器啟動新的對話工作階段。這是因為使用者中斷了目前的對話流程。