對話過濾開發人員指南

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

管理員體驗

直接在 API 或搜尋商務控制台中管理生成式問題和對話式產品篩選，並在搜尋商務控制台的「資料品質」和「評估」部分中進行設定。

Cloud 控制台

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

使用生成問題服務的步驟

1. 符合資料規定。

2. 設定手動問題覆寫。

3. 開啟這項功能。

4. 預覽及測試。

資料條件

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

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

包括：

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

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

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

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

圖 4. 檢查對話式搜尋準備程度。

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

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

生成問題控制選項

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

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

1. 前往 Search for commerce 控制台的「Conversational search and browse」(對話式搜尋和瀏覽) 頁面。
   
   前往對話式搜尋和瀏覽頁面。

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

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

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

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

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

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

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

圖 5. 編輯每個 AI 生成的問題。

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

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

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

編輯個別問題

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

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

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

開啟對話式篩選功能

在管理中心編輯生成式 AI 問題後，即可啟用對話式產品篩選功能。

如要啟用對話式產品篩選功能，請前往 Search for commerce 控制台的「對話式產品篩選和瀏覽頁面」。

1. 前往 Search for commerce 控制台的「Conversational search and browse」(對話式搜尋和瀏覽) 頁面。
   
   前往對話式搜尋和瀏覽頁面。

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

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

圖 6. 開啟切換鈕，啟用對話式搜尋。

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

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

評估及測試

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

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

1. 前往 Search for commerce 控制台的「評估」頁面。
   
   前往「評估」頁面

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

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

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

圖 7. 預覽結果。

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

Generative Question API

本節說明如何使用生成問題 API，將 Conversational API 整合至 UI、管理生成問題，以及在網站上提供這項功能。

API 整合

物件：

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

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

啟用對話式產品篩選功能

物件：

• GenerativeQuestionsFeatureConfig

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

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

注意： 您必須先符合資料規定，才能啟用這項功能。如果未符合資料規定，API 會觸發驗證錯誤。資料規定驗證會顯示在 Search for Commerce 控制台中，而這項工具實際上會呼叫對話式設定 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	重複字串	可用於回答問題的值。僅供輸出。
頻率	浮點數	問題的詢問頻率比率。僅供輸出。
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. 對話式 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 互動，包括搜尋和對話式 API。Search API 用於擷取搜尋結果，Conversational API 則用於擷取對話式回應。Conversational API 不會傳回搜尋結果。

假設網站已啟用對話式產品篩選功能，使用者歷程和後續與 Vertex AI Search for Commerce 的互動會遵循下列路徑：

• 步驟 1：使用者會先向 Search 和 Conversational API 提出查詢。Search API 只會傳回搜尋結果。Conversational API 會傳回建議答案和後續問題。針對相同查詢或 page_category 呼叫 Search API，並擷取搜尋結果。
• 步驟 2：系統會將要求後續對話傳送至對話式搜尋。使用正確的對話篩選模式呼叫 Conversational API。
• 步驟 3：初始搜尋回應，僅包含搜尋結果。對話式 API 會傳回建議答案和後續問題，藉此修正查詢。
• 使用者選取：使用者選取多個選項。
  • 選取的答案篩選器會傳送至 Conversational API。
  • 對話和搜尋 API 會套用篩選條件。

使用者發起對話時傳送的第一項查詢

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

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

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

Search API 要求

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

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

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

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

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

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

對話式 API 要求

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

對話式 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 回覆

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

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

• 在用戶端，開發人員應將 conversation_id 儲存在瀏覽器工作階段儲存空間中，以便繼續與伺服器進行對話式搜尋。
• 由於一位購物者可能會開啟多個分頁，並進行多場對話，因此系統會使用這項 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"
        }
      }
    }
  }
}

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

對話式 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，以擷取更多相關產品。