对话式商品过滤

启用对话式商品过滤功能后，Vertex AI Search for Commerce 会引导买家在商品销售商网站上使用对话功能进行商品搜索。在 Vertex AI Search for Commerce 中进行初始文本查询后，在线购物者会收到相关的后续问题和多选题选项。用户可以通过输入自由文本或点击对话式多选题选项来回答后续问题。

注意： “浏览”仅提供单选题选项，而“搜索”则提供完整的对话式搜索功能。

如果启用了对话式商品过滤功能，网站上的后续问题会引导对话，直到出现以下三种情况之一：

• 达到预配置的最低商品数量（如果只显示两件商品，对话就没有用）。
• 用户点击某件商品并将其添加到购物车（目标）。
• 搜索和浏览商家信息功能会耗尽 AI 生成的问题。

图 1. 对话式搜索用户历程。

动态分面的替代方案

动态细分与每次查询收入较低的广泛查询相关联。客户看到成千上万的搜索结果时可能会感到不知所措，从而导致他们放弃搜索体验。特别是，返回商品数量较多的搜索查询的每次查询收入异常偏低。对话式搜索能够优化查询，还可以与动态分面结合使用。与动态细分相比，对话式商品过滤功能具有一些优势，例如更人性化、互动性更强，并且占用更少的页面空间。

可自定义的生成式问题，可根据偏好设置进行调整

对话式商品过滤功能允许零售商根据上传的目录，根据自己的偏好预先修改、覆盖或取消选择 AI 生成的问题，从而鼓励用户与生成式 AI 问题进行人机互动。商家可以在搜索购物控制台或 API 中单独或批量修改或停用问题，以便根据自己的需求定制搜索结果中显示的问题。

管理体验

您可以直接在 API 或对话式商务控制台中管理生成式问题和对话式商品过滤功能，并在 Google 搜索的“购物”部分的数据质量和评估部分中进行设置。

Cloud 控制台

借助该控制台，零售商可以在对话式 Vertex AI Search for Commerce 体验中管理生成式问题。详细了解如何在对话式商品过滤中使用生成式问题。

使用生成式题目服务的步骤

1. 满足数据要求。

2. 配置手动替换项。

3. 开启该功能。

4. 预览和测试。

数据要求

如需了解您的搜索数据是否已准备好用于对话式商品过滤和浏览，请在控制台中依次前往对话式商品过滤和浏览或数据质量 > 对话下的覆盖率检查标签页。

如需启用对话式商品过滤功能，您需要满足特定的数据要求。

它们是：

• 每天 1,000 次询问：达到此第一个阈值后，系统会生成对话计划，以评估您的输入和输出：
• 输入：事件中的过滤器数
• 输出：对话覆盖率
• 25% 的对话覆盖率：由 Vertex AI Search for Commerce 模型计算得出，对话覆盖率是指包含一个问题的询问所占的百分比。按查询量加权的 25% 的查询中至少应有一个与其匹配的第一个问题。

如果您尚未达到 25% 的对话覆盖率，但满足第一个前提条件（每天 1,000 次询问），系统会开始分别对您的输出和输入应用屏蔽和建议检查。此时，Vertex AI Search for Commerce 会开始计算您基于用户事件应用的过滤条件需要增加多少百分比，才能达到 25% 的对话覆盖率阈值。上传的滤镜越多，覆盖面就越广。

如需查看对话就绪性，请执行以下操作：

1. 在搜索购物广告控制台中，前往数据质量页面中的对话标签页。这项指标可让您进行一项关键检查，即至少 25% 的搜索查询是否至少包含一个后续问题，还可提供建议性检查，以确定需要达到多少百分比的用户事件包含有效过滤条件，才能实现该对话覆盖率目标。

2. 如果您通过了关键检查，并且有足够的用户事件以及有效的过滤条件，请继续执行下一步。

3. 如需控制生成式问题的呈现方式，请前往 Vertex AI Search for Commerce 控制台中的对话式商品过滤和浏览页面。

生成式问题控件

生成式 AI 会为目录中的每个可编入索引的属性编写一个问题，同时使用系统属性和自定义属性的属性名称和值。这些问题由 LLM 生成，旨在提升搜索体验。例如，对于家具类型，值可以是室内或室外，AI 会综合生成一个关于您想要什么类型家具的问题。

每个分面都有一个生成的问题。系统会根据过往搜索事件数据中的历史用户事件和细分互动情况，按问题预计出现频率对问题进行排序。AI 会先查看顶部的问题，然后按属性查找相关内容。问题列表只会生成一次。如果添加了新属性，则该属性会在两小时内反映在列表中。

1. 前往 Google 搜索商务控制台中的对话式搜索和浏览页面。
   
   前往“对话式搜索和浏览”页面。

2. 在管理 AI 生成的问题标签页下，查看按使用频率（以查询加权频率表示，即在常见查询中显示的频率）排序的所有问题。排名使用 GenerativeQuestionConfig 配置中的频率字段。此字段负责按使用频率对 AI 生成的问题进行排序。

3. 您可以使用过滤选项过滤问题。

4. 选中相应复选框，为每个属性启用问题可见性。

5. 点击每行末尾的 ，为每个题目打开修改面板。

如需批量修改，请按以下步骤操作：

1. 选中或清除您希望在对话中包含或排除的问题旁边的复选框。

2. 点击列表顶部显示的 允许在对话中使用或 禁止在对话中使用按钮。或者，如需修改单个问题，请点击 ，然后在随即打开的窗格中清除或重新选中允许在对话中使用旁边的复选框：

在对话式产品过滤中使用生成式问题

生成式题目服务 API 提供了一些控件，以减少 LLM 输出中的潜在不一致性。您可以通过控制台管理这些设置。在这里，零售商还可以通过切换其启用状态并设置触发该功能所需的商品数量下限来配置对话式商品过滤功能。

您可以定义问题，指定问题本身、可能的回答，以及允许在对话中提出该问题。具体问题可以由 LLM 生成，也可以由零售商替换。该控制台支持审核 AI 生成的问题，让零售商可以替换这些问题或切换其对话状态。您还可以批量修改题目。

修改单个题目

您还可以使用控件来管理各个题目。建议您先执行此操作，然后再启用对话式产品过滤功能。

每个问题都有两个选项。点击最后一列中的 ，即可访问“用户可以看到的问题”面板：

1. 为所有查询停用某个问题：该问题默认处于启用状态。取消选中（或重新选中）允许在对话中使用旁边的复选框。此选项会完全跳过相应题目。如果某个问题与查询的属性无关，或者可能会被误解为不当（例如，“您要找什么尺码的连衣裙？”这类问题可能会被认为是在窥探买家的身材），零售商可能会选择完全停用该问题。
2. 重写问题：在该窗格中，您可以看到 AI 生成的问题、该问题所关联的属性以及该属性的值。点击铅笔图标即可重写。

开启对话过滤

在控制台中修改生成式 AI 问题后，您就可以开启对话式商品过滤功能了。

如需启用对话式商品过滤功能，请前往 Google 搜索购物控制台中的对话式商品过滤和浏览页面。

1. 前往 Google 搜索商务控制台中的对话式搜索和浏览页面。
   
   前往“对话式搜索和浏览”页面。

2. 在对话部分，前往配置和启用标签页下的系统级设置。在此标签页中，您可以配置在对话发生之前（即生成问题时）匹配查询所需的最低产品数量。此最小数量为 2 或更大。您可以将最小值配置为更高，但不得低于 2。考虑您希望在搜索中返回的商品清单中的产品数量，以便用户发起对话。例如，此数字的最佳值为每页一行，以便尽可能少的搜索结果触发对话。

3. 将切换开关切换到开启状态。此页面还会提供有关屏蔽和建议性检查状态的信息。如果您有足够的搜索查询包含至少一个后续问题，则您的网站现在已启用对话式搜索。

评估和测试

借助评估，您可以运行测试搜索，并针对显示的多个方面测试您的问题，以预览呈现体验。控制台的这一部分可让您预览启用对话式商品过滤功能后的投放体验。

如需进行评估和测试，请按以下步骤操作。在购物搜索控制台的评估页面上，搜索或浏览标签页的评估部分。

1. 前往 Search for Commerce 控制台中的评估页面。
   
   前往“评估”页面

2. 点击搜索或浏览。

3. 在“搜索评估”字段中，输入一个基于您上传到搜索引擎的目录合理的测试查询，例如，如果您的目录包含服装商品，则输入鞋子。点击搜索结果预览以查看搜索结果。如果您启用了对话式产品过滤功能，右侧面板上会启用生成式问题。

4. 右侧面板上会显示测试题目列表。

Generative Question API

本部分介绍了如何使用生成式问题 API 将对话式搜索 API 集成到您的界面中、管理生成式问题，以及在您的网站上提供该功能。

API 集成

对象：

• GenerativeQuestionsFeatureConfig
• GenerativeQuestionConfig
• GenerativeQuestions 服务
  • UpdateGenerativeQuestionsFeatureConfiguration
  • UpdateGenerativeQuestionConfig
  • ListGenerativeQuestionConfigs
  • GetGenerativeQuestionFeatureConfig
  • BatchUpdateGenerativeQuestionConfigs

集成此功能的核心是定义 question 资源。这包括问题本身以及该问题是否允许在对话中使用。该问题默认由 LLM 生成，但可以由管理员替换。

启用对话式商品过滤

对象：

• GenerativeQuestionsFeatureConfig

此对象是一个控制配置文件，用于启用生成式问题功能，以管理对话式商品过滤的整体服务体验。GenerativeQuestionsFeatureConfig 使用 GET 方法从与项目关联的目录中获取属性信息以及属性是否可编入索引。

feature_enabled 开关决定在投放时是否使用问题。它用于管理控制台中的顶级切换开关。

注意 ：您必须满足数据要求，才能启用此功能。如果未满足数据要求，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 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 为问题启用对话功能。它用于控制单个生成问题的配置。

字段（突出显示了对话控制行为）
目录	字符串	用于确定可用的一组属性（以及扩展问题）。这些值均在目录中定义。必填字段。
分面	字符串	与问题关联的细分。必填字段。
generated_question	字符串	LLM 生成的默认问题。仅限输出。
final_question	字符串	所问问题。此字段的最大长度为 300 字节。可选字段。
example_values	重复的字符串	可用于回答问题的值。仅限输出。
频率	浮点数	问题被问到的频率所占的比例。仅限输出。
allowed_in_conversation	布尔值	在投放时询问问题。此字段是可选字段。

投放体验

对话式商品过滤功能基于与用户进行持续对话（包含多个回合）来吸引用户。因此，至少需要第二个回答，对话式商品过滤功能才能正常运行。系统会在回答中向用户显示后续问题和建议的答案。用户可以通过输入答案或点击建议的答案（单选题选项）来回答此跟进问题。

• 单选题 单选题选项在后台的运作方式类似于细分（事件类型过滤条件），它会使用过滤功能缩小查询范围。在后台，当用户点击某个单选题答案时，系统会对查询应用过滤条件。使用对话式多选题应用过滤条件与使用动态细分或功能块应用相同的过滤条件完全相同。

• 自由文本 如果用户以自由文本形式进行回复，系统会生成一个范围更窄的新查询。详细了解对话式商品过滤功能如何在 API 级别丰富过滤条件和用户事件捕获。

该功能启用的服务

生成式问题服务 (service GenerativeQuestionService{...}) 用于管理 LLM 生成的问题。其父对象是目录，它会从目录中检索信息，以便针对给定目录返回问题。该服务用于管理生成式问题的整体功能状态、进行单个更改或批量更改，以及启用或停用问题。必须满足数据要求才能与 Service API 交互，并且需要先初始化问题，然后才能进行管理。

该服务通过两组处理脚本与功能级配置和题目级配置进行交互：

• GenerativeQuestionsFeatureConfig 处理程序（功能级别）：

  1. 通过更新，您可以更改最低商品数量和启用字段。
  2. Get 会返回一个对象。

• GenerativeQuestion 配置处理脚本（题目级）：

  1. List 会返回指定目录的所有问题。
  2. 更新用于管理单个题目。
  3. 批量更新用于执行分组问题管理。

该服务会根据初始查询返回语义相符的问题。

跟进问题由 LLM 模型生成，可以被替换。系统会根据客户调用搜索事件历史记录的可能性来显示问题。如果没有搜索事件历史记录，则回退到商务搜索日志。

系统会根据上一个查询生成不同的问题。没有固定权重。用于生成 LLM 问题的 AI 会从查询中学习，并更改每个查询的权重，例如，“衬衫”会对类别进行很高的权重分配，但“XL 红色衬衫”会对类别、尺寸和颜色进行权重分配。

配置投放体验

通过将对话过滤配置 API 与 Search API 集成，配置投放体验。

查看 API 集成

该功能的配置 API ConversationalFilteringSpec 位于新的对话式 API 之上。

• ConversationalFilteringSpec：此可选字段已添加到 ConversationalSearchRequest，但如果您想使用对话过滤功能，则必须填写此字段。该字段会重复使用 SearchRequest 字段、查询和过滤条件。它还包含一个字段，用于在初始查询后向用户提供后续问题，以及一个 `conversation_id`，用于维护客户端和服务器之间的对话状态。
• ConversationalFilteringResult：Proto 文件包含为 ConversationalSearchResponse 中的对话式 CRS 流程返回所需的额外信息。这包括 conversation_id、refined_query、additional_filters、follow_up_question 和 suggested_answers。

API 中的用户体验历程

对话流程的运作方式如下：用户使用初始查询发起搜索，并将新 API 中的 mode 标志设置为 true，然后将其设置为 mode。然后，用户选择一个答案或提供自由文本输入，系统会使用 user_answer 字段将其发送回 API。此新 API 会在响应中提供 additional_filter。用户必须将这些过滤条件应用于 Search API 跟进请求。系统会根据用户的输入生成搜索结果，并提供新的问题，提示用户进行跟进查询，然后在多次对话中继续对话，直到用户在零售商网站上找到所需内容。

注意 ：对话式商品过滤功能现在与两个 API 交互：搜索 API 和对话式 API。Search API 用于提取搜索结果，Conversational API 用于提取对话式响应。对话式 API 不会返回搜索结果。

假设网站上启用了对话式商品过滤功能，那么用户体验历程以及与 Vertex AI Search for Commerce 的后续互动会遵循以下路径：

• 场景 1。第一个查询来自用户，同时发送到 Search API 和 Conversation API。Search API 仅返回搜索结果。Conversation API 会返回建议的回答和后续问题。针对相同的查询或 page_category 调用 Search API，并提取搜索结果。
• 第 1a 步。系统会将请求的后续对话发送到对话式搜索。使用正确的对话过滤模式调用 Conversational API。
• 第 1b 步。仅包含搜索结果的初始搜索响应。Conversation API 会返回建议的答案和后续问题，以优化查询。
• 场景 2：用户选择多选题。
• 第 2a 步。发送到 Conversation API 的所选答案过滤条件。
• 第 2b 步。Conversation API 和 Search API 均会在应用过滤条件的情况下运行。
• 场景 3：用户选择“自由文本”。
• 第 3a 步。发送到 Conversation API 的文本回答。使用 Conversational API 发送用户回答。
• 第 3b 步。系统会在对话式回答中向用户提供对话式后续问题以及一些建议的答案。使用修改后的查询再次运行搜索。对话式 API 发送另一个问题和 additional_filter。此过滤条件必须应用于第一步中从 Search API 提取的搜索结果。

场景 1. 第一个查询来自用户

目前，只有对话式 API 支持对话式商务。Conversation API 中的 conversationalFilteringMode 用于区分对话式商务和对话式商品过滤。

首先，开发者需要将商品或商品项设置为查询（在本例中为 "dress"），以创建以下搜索请求：

Search API 请求

{
  query: "dress",
}

客户端上用于启用对话式过滤搜索的其他操作：

• 开发者还必须通过将 "dress" 设置为查询来创建对话式搜索请求。

• 开发者必须将 mode 设置为 "CONVERSATIONAL_FILTER_ONLY"，才能获得对话式响应。否则，如果将其设置为 "DISABLED"，则不会提供任何后续问题。

第 1a. 步：零售商 → 搜索：启用对话功能后的初始查询

Conversation API 请求

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

第 1b 步。搜索 → 零售商：对话 ID、优化后的查询、后续问题、建议的回答

Conversation 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 条结果即可
• 此列表已排序，因此必须按正确的顺序显示。也就是说，显示的第一个结果是列出的第一个结果。

对话式商品过滤功能会提供以下选项，以便持续对话互动，从而更快地优化搜索结果：

场景 2

场景 3

场景 2：用户选择一个多选题选项

如果用户选择了黄色的单选题答案：

• 开发者必须从会话存储区恢复 conversation_id。
• 将 mode 设置为 CONVERSATIONAL_FILTER_ONLY。
• 为用户选择的内容设置 user_answer。

第 2a 步。零售商 → 搜索：所选答案过滤器

JSON 请求

{
  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"  
        }
      }
    }
  }
}

第 2b 步。搜索 → 零售商：已应用过滤条件

JSON 响应

{
  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"
      }
    }
  }
 }
}

如何处理单选题回复

搜索响应与第一个查询的响应基本相同，只不过它还使用了 additional_filter。在此示例中，应使用它选中 color = "yellow" 的过滤条件复选框。 它应添加到用户选择的任何其他过滤条件中。换句话说，应将 additional_filter 添加到为此跟进查询和搜索请求发送的 filter 字段中的事件中，以便用于跟进搜索请求或事件上传，如 filter: "colors:ANY(\"yellow\")" 所示。

场景 3：用户选择自由文本输入

如果用户输入 lavender：

• 开发者应从会话存储区恢复 conversation_id。
• 将 followup_conversation_requested 设置为 true。
• 为用户输入内容（使用 "text_answer:" 前缀）设置 user_answer。

第 3a 步。零售商 → 搜索：文本回答

JSON 请求

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

第 3b 步。搜索 → 零售商：使用修改后的查询运行

JSON 响应

{
  conversation_id: "c154d073-87f5-4edb-accd-587eabe014ff"
  refined_query: "lavender dress"
  conversational_filtering_result {
    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"
      }
    }
  }
 }
}

如何处理免费文本响应

• 与初始响应类似，但请注意，refined_query 现已更新。
• 开发者应相应地更新 refined_query 的客户端界面，即显示面向用户的查询已从 "dress" 更改为 "lavender dress".
• 开发者必须在事件中向 Google 搜索发送正确的经过优化的查询。