以下是開發人員指南,說明如何在 API 中整合對話式產品篩選功能。
管理員體驗
直接在 API 或搜尋商務控制台中管理生成式問題和對話式產品篩選功能,並在搜尋商務控制台的「資料品質」和「評估」部分進行設定。
Cloud 控制台
零售商可透過控制台,在對話式產品篩選體驗中管理生成的問題。進一步瞭解如何在對話式產品篩選功能中使用生成式問題。
使用生成問題服務的步驟
資料條件
如要確認搜尋資料是否已準備好進行對話式產品篩選,請在控制台的「對話式產品篩選和瀏覽」或「資料品質」>「對話」下方,前往「涵蓋範圍檢查」分頁。
如要啟用對話式產品篩選功能,必須符合特定資料規定。
包括:
- 每天 1,000 次查詢:達到這個門檻後,系統會產生對話方案,評估您的輸入和輸出內容:
- 輸入內容:事件中的篩選器數量
- 輸出內容:對話涵蓋範圍
- 25% 的對話涵蓋率:由 Vertex AI Search for Commerce 模型計算,對話涵蓋率是指含有一個問題的查詢百分比。加權頻率為 25% (依數量) 的查詢應至少有一個相符的第一個問題。
如果對話涵蓋率尚未達到 25%,但已符合每日 1000 筆查詢的第一項先決條件,系統就會開始對輸出內容套用封鎖檢查,並對輸入內容套用建議檢查。此時,Vertex AI Search for commerce 會開始計算使用者事件套用的篩選條件必須增加多少百分比,才能達到 25% 的對話涵蓋率門檻。上傳的篩選器越多,觸及範圍就越廣。
如要查看對話準備程度,請按照下列步驟操作:
- 前往 Search for commerce 控制台的「資料品質」頁面,然後點選「對話」分頁標籤。這項功能會進行重要檢查,判斷至少 25% 的搜尋查詢是否至少有一個後續問題,並提供建議檢查,判斷需要多少百分比的有效篩選器使用者事件,才能達成對話涵蓋率目標。
圖 4. 檢查對話式搜尋準備程度。
如果通過重要檢查,且有足夠的使用者事件和有效篩選條件,請繼續下一個步驟。
如要控管生成問題的顯示方式,請前往 Vertex AI Search for commerce 控制台的「對話式產品篩選和瀏覽頁面」。
生成問題控制選項
生成式 AI 會為目錄中的每個可建立索引的屬性撰寫問題,並使用系統和自訂屬性的名稱和值。這些問題是由 LLM 生成,目的是提升搜尋體驗。舉例來說,如果家具類型的值是室內或室外,AI 就會合成問題,詢問你要找哪種家具。
每個面向都會生成一個問題。系統會根據歷來使用者事件和過去搜尋事件資料中的構面參與度,依問題預期出現的頻率排序。AI 會先查看頂端的提問,然後依據屬性找出相關內容。系統會產生一次問題清單,如果新增屬性,清單會在兩小時內反映變更。
前往 Search for commerce 控制台的「Conversational search and browse」(對話式搜尋和瀏覽) 頁面。
前往「對話式搜尋和瀏覽」頁面。在「管理 AI 生成的問題」分頁中,查看所有問題,並依查詢加權頻率排序,也就是問題與常見查詢一起顯示的頻率。排名會使用
GenerativeQuestionConfig設定中的頻率欄位。這個欄位負責根據使用頻率排序 AI 生成的問題。你可以使用篩選選項篩選問題。
勾選方塊,為每個屬性啟用問題顯示功能。
按一下每列結尾的 edit,即可開啟每個問題的編輯面板。
如要大量編輯,請按照下列步驟操作:
選取或取消選取要納入或排除在對話中的問題旁的方塊。
按一下清單頂端的「允許在對話中使用」add或「禁止在對話中使用」remove按鈕。如要編輯個別問題,請按一下 edit,然後在開啟的窗格中,清除或重新勾選「允許在對話中使用」旁邊的方塊:
圖 5. 編輯每個 AI 生成的問題。
在對話式產品篩選功能中使用生成的問題
生成問題服務 API 提供控制項,可減少 LLM 輸出內容可能出現的不一致情形。這些設定可透過控制台管理。零售商也可以在這裡設定對話式產品篩選功能,方法是切換啟用狀態,並設定觸發這項功能所需的最低產品數量。
您可以定義問題、指定問題本身、可能的答案,以及是否允許在對話中提出問題。個別問題可由 LLM 生成,或由零售商覆寫。零售商可以在控制台中查看 AI 生成的問題,並覆寫問題或切換對話狀態。你也可以大量編輯問題。
編輯個別問題
你也可以使用控制項來管理個別問題。建議您先完成這項作業,再開啟對話式產品篩選功能。
每個問題都有兩個選項。按一下最後一欄的 edit,即可存取「使用者可見的問題」面板:
- 為所有查詢關閉問題:問題預設為啟用。取消勾選 (或再次勾選)「允許在對話中使用」旁的方塊。這個選項會直接略過問題。如果問題與查詢的屬性無關,或可能被誤解為不當內容 (例如「你要找什麼尺寸的洋裝?」這類問題可能會被視為探詢體重),零售商可以選擇完全停用問題。
- 改寫問題:在窗格中,你可以查看 AI 生成的問題、附加的屬性,以及屬性的值。按一下鉛筆圖示即可重新撰寫。
開啟對話過濾功能
在管理中心編輯生成式 AI 問題後,即可啟用對話式產品篩選功能。
如要啟用對話式產品篩選功能,請前往 Search for commerce 控制台中的「對話式產品篩選和瀏覽頁面」。
前往 Search for commerce 控制台的「Conversational search and browse」(對話式搜尋和瀏覽) 頁面。
前往「對話式搜尋和瀏覽」頁面。請考量要傳回目錄中至少多少產品,系統才會生成問題。這個數字可以更高,但絕不會低於 2。通常一列就足以觸發對話。
設定號碼,然後將切換鈕設為「開啟」。如果相符的產品數量較少,就會遭到篩除。
圖 6. 將切換鈕設為開啟,啟用對話式搜尋。
本頁面提供封鎖和建議檢查的狀態資訊。如果搜尋查詢中至少有一個後續問題,表示網站已啟用對話式搜尋功能。
評估及測試
評估功能可讓您執行測試搜尋,並根據顯示的構面測試問題,預覽放送體驗。控制台的這部分會顯示提供對話式產品篩選功能的服務預覽畫面。
如要評估及測試,請按照下列步驟操作。在「Search for commerce」控制台的「評估」頁面,點選「搜尋」或「瀏覽」分頁,然後前往「評估」部分。
前往 Search for commerce 控制台的「評估」頁面。
前往「評估」頁面按一下「搜尋」或「瀏覽」。
在「搜尋評估」欄位中,根據你上傳至搜尋的目錄輸入合理的測試查詢,例如目錄包含服飾,則輸入「鞋子」。
按一下「搜尋預覽」即可查看搜尋結果。
圖 7. 預覽結果。
啟用對話式產品篩選功能後,系統就會啟用生成問題功能。
Generative Question API
本節說明如何使用生成問題 API,將 Conversational API 整合至網頁介面、管理生成問題,以及在網站上提供對話式產品篩選功能。
API 整合
物件:
- GenerativeQuestionsFeatureConfig
- GenerativeQuestionConfig
- 生成問題服務
- UpdateGenerativeQuestionsFeatureConfiguration
- UpdateGenerativeQuestionConfig
- ListGenerativeQuestionConfigs
- GetGenerativeQuestionFeatureConfig
- BatchUpdateGenerativeQuestionConfigs
整合對話式產品篩選功能的關鍵在於定義 question 資源。包括問題本身,以及是否允許在對話中使用該問題。問題預設由 LLM 生成,但管理員可以覆寫。
啟用對話式產品篩選
物件:
- GenerativeQuestionsFeatureConfig
這個物件是控制項設定檔,可啟用生成式問題的對話式產品篩選功能,以管理整體放送體驗。GenerativeQuestionsFeatureConfig 會使用 GET 方法,從與專案相關聯的目錄取得屬性資訊,以及屬性是否可建立索引。
feature_enabled 切換鈕可決定在放送時是否使用問題。管理控制台中的頂層切換按鈕。
服務體驗
對話式產品篩選功能會與使用者進行多輪對話,因此,對話式產品篩選功能至少需要第二個回覆才能運作。使用者會在回覆中看到後續問題和建議答案,並可輸入答案或點選建議答案 (選擇題選項) 回覆後續問題。
選擇題選項在幕後運作時,就像是層面 (事件類型篩選器),會使用篩選功能縮小查詢範圍。在背景中,使用者點選選擇題答案時,系統會將篩選器套用至查詢。使用對話式多重選擇套用篩選器,與使用動態分頁或圖塊套用相同篩選器的方式相同。
透過對話式產品篩選器啟用的服務
生成問題服務 (service GenerativeQuestionService{...}) 用於管理 LLM 生成的問題。其父項物件為目錄,可從中擷取資訊,並傳回特定目錄的問題。這項服務可用於管理整體生成問題狀態、進行個別或批次變更,以及開啟或關閉問題。如要與 Service API 介接,必須符合資料規定,且必須先初始化問題,才能管理問題。
這項服務會透過兩組處理常式,與功能層級和問題層級的設定檔互動:
GenerativeQuestionsFeatureConfig處理常式 (功能層級):- 更新:可變更最低產品數量,以及啟用欄位。
- Get:傳回物件。
GenerativeQuestion Config 處理常式 (問題層級):
- 清單:傳回指定目錄的所有問題。
- 更新:管理個別問題。
- 批次更新:執行分組問題管理作業。
服務會根據初始查詢,傳回語意適當的問題。
後續問題是由 LLM 模型生成,可以覆寫。系統會呼叫搜尋事件記錄,根據顧客使用問題的機率顯示問題。如果沒有搜尋事件記錄,系統會改用電子商務搜尋記錄。
系統會根據先前的查詢生成不同的問題。沒有固定重量。系統會根據查詢內容調整每項查詢的權重,因此「襯衫」一詞的權重會非常高,但「XL 紅色襯衫」的權重則會平均分配給類別、尺寸和顏色。
設定供應體驗
整合對話式篩選設定 API 與 Search API,設定放送體驗。
這項功能的設定 API ConversationalFilteringSpec 位於 Conversational API 的頂端。您可以平行呼叫這兩個 API,也可以依下列順序呼叫:
- Conversational API
- 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 後續要求。搜尋結果會根據使用者的輸入內容提供新的後續問題,提示使用者進行後續查詢,並在多輪對話中持續進行,直到使用者在零售商網站上找到所需商品為止。
假設網站已啟用對話式產品篩選功能,使用者歷程和後續與 Vertex AI Search for Commerce 的互動會遵循下列路徑:
步驟 1:使用者會先向 Search API 和 Conversational API 提出查詢。Search API 只會傳回搜尋結果。Conversational API 會傳回建議答案和後續問題。針對相同查詢或
page_category呼叫 Search API,並擷取搜尋結果。系統會將要求後續對話傳送至對話式搜尋。使用正確的對話篩選模式呼叫 Conversational API。步驟 2:初始搜尋回應,僅包含搜尋結果。Conversational API 會傳回建議答案和後續問題,藉此修正查詢。然後選取多個選項:
- 選取的答案篩選器會傳送至 Conversational API。
- 對話和搜尋 API 會套用篩選條件。
初始使用者查詢
使用者在 Vertex AI Search for Commerce 中開啟對話,並在搜尋框中尋找 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。
傳送要求至 Search API
建立下列搜尋要求,並將 dress 設為查詢 (或任何實際查詢),藉此向 Search API 傳送要求:
對話式產品篩選功能不會變更搜尋 API 要求。
傳送要求至 Conversational API
如要傳送要求至 Conversational API,請按照下列步驟操作:
將
dress設為查詢 (或實際查詢內容),建立對話式搜尋要求。將
mode設為CONVERSATIONAL_FILTER_ONLY,即可取得對話式回覆。如果設為DISABLED,系統就不會提供後續問題。在對話式搜尋要求中填入
SearchParams。搜尋參數應與 Search API 呼叫相同。
Conversational API 回應
對話式 API 的回應如下所示:
如何處理回覆:
conversation_id:這個 ID 可以儲存在瀏覽器工作階段儲存空間中,並用於繼續與伺服器進行對話式搜尋。因為一位購物者可能會開啟多個分頁,並進行多場對話,因此系統會使用conversation_id追蹤對話。refined_query:識別目前的查詢。您必須使用這項回應呼叫 Search API,才能擷取產品結果。followup_question:識別要向使用者顯示的問題。suggested_answers:應向使用者顯示的多項選擇題答案排序清單。如要顯示較少答案,請只顯示前 N 筆結果。清單會按照結果的顯示順序排序。
這樣一來,初始查詢就會啟用對話功能。
搜尋處理選擇題答案
- 使用者動作:點選黃色。
- 您的實作方式:發出兩項新的 API 呼叫。
- 對話式 API 要求:
query:dressconversation_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更新網頁介面,例如勾選黃色篩選方塊,並顯示新問題。
對話式產品篩選功能會提供下列選項,讓使用者繼續對話互動,更快縮小搜尋範圍:
使用者看到搜尋結果時,可以選取單選題選項。
這個程式碼範例顯示使用者選取了複選題答案「黃色」,並再次傳送查詢,同時套用正確的使用者篩選條件,將新的對話要求傳送至 Search API。
如要傳送要求至 Conversational API,請按照下列步驟操作:
- 從工作階段儲存空間還原
conversation_id。 - 將
mode設為CONVERSATIONAL_FILTER_ONLY。 - 針對使用者選取的項目設定
user_answer。
對話式 API 的回應如下所示:
如何處理回覆:
- Google 回應基本上與第一個查詢的回應相同,但
additional_filter欄位可用來勾選color = yellow的篩選方塊,並應新增至使用者選取的任何其他篩選條件。 - 此外,針對這項後續查詢和後續搜尋要求,傳送至 Google 的篩選器欄位事件也應加入
additional_filter。這項設定應套用至搜尋要求,以擷取搜尋產品,並套用至對話式搜尋要求,以擷取後續對話。 refined_query應傳送至 Search API,以擷取更多相關產品。