对话式过滤开发者指南

以下是开发者指南，介绍了如何在 API 中集成对话式商品过滤功能。

管理员体验

直接在 API 或 Search for commerce 控制台中管理生成式问题和对话式商品过滤，并在 Search for commerce 控制台的数据质量和评估部分中进行设置。

Cloud 控制台

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

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

1. 满足数据要求。

2. 配置手动问题替换。

3. 开启此功能。

4. 预览和测试。

数据要求

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

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

它们是：

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

如果您尚未达到 25% 的对话覆盖率，但已达到每天 1,000 次查询的第一个前提条件，系统会开始对您的输出和输入分别应用屏蔽检查和建议检查。此时，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 控制台中的对话式搜索和浏览页面。
   
   前往“对话式搜索和浏览”页面。

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 控制台中的对话式搜索和浏览页面。
   
   前往“对话式搜索和浏览”页面。

2. 考虑在生成问题之前，您希望在搜索结果中返回的目录中的最低商品数量。此值可以大于 2，但绝不能小于 2。每页一行通常是触发对话的合适数量。

3. 配置数量，然后将开关切换为开启。如果匹配的商品数量少于该数字，则会被过滤掉。

图 6. 将开关切换为开启，以启用对话式搜索。

注意： 如果生成式 AI 已启用，并且 LLM 将 AI 生成的问题与任何相关属性值相关联，则可能会显示 AI 问题。

本页面提供有关阻塞性检查和建议性检查状态的信息。如果您有足够的搜索查询包含至少一个后续问题，那么您的网站现在已启用对话式搜索。

评估和测试

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

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

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

2. 点击搜索或浏览。

3. 在搜索评估字段中，输入一个根据您上传到搜索的目录有意义的测试查询，例如，如果您的目录包含服装商品，则输入鞋子。

4. 点击搜索结果预览以查看搜索结果。

图 7. 预览结果。

如果您启用了对话式产品过滤功能，则生成式问题功能也会启用。

Generative Question API

本部分介绍了如何使用生成式问题 API 将 Conversational 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 为问题启用对话功能。它用于控制单个生成问题的配置。

字段（用于控制突出显示的对话的行为）
目录	字符串	用于标识哪些属性（以及相应的问题）可用。这些值均在目录中定义。必填字段。
facet	字符串	问题所关联的方面。必填字段。
generated_question	字符串	LLM 生成的默认问题。仅限输出。
final_question	字符串	提出的问题。最长可包含 300 个字节。选填字段。
example_values	重复的字符串	可用于回答问题的值。仅限输出。
频次	float	问题被问到的频率比率。仅限输出。
allowed_in_conversation	布尔值	问题是否在投放时提出。此字段是可选字段。

服务体验

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

多项选择选项在幕后充当分面（一种事件类型过滤条件），通过过滤来缩小查询范围。在后台，当用户点击多项选择题的回答时，系统会向查询应用过滤条件。使用对话式多项选择应用过滤条件与使用动态分面或板块应用同一过滤条件的效果相同。

功能启用的服务

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

该服务通过两组处理程序与功能级和问题级配置文件进行交互：

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

  1. 更新：可让您更改最低商品数量并启用字段。
  2. Get 返回一个对象。

• GenerativeQuestion 配置处理程序（问题级）：

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

该服务会根据初始查询返回语义上合适的问题。

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

系统会根据上一个查询生成不同的问题。没有固定权重。生成 LLM 问题的 AI 会从查询中学习，并更改每个查询的权重，例如，“衬衫”这个查询的类别权重非常高，但“XL 红色衬衫”这个查询的类别、尺寸和颜色权重都比较高。

配置投放体验

通过将对话过滤配置 API 与 Search API 集成，配置提供内容时的体验。

该功能的配置 API ConversationalFilteringSpec 位于对话式 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。

对话式 API 在响应中提供 additional_filter 字段。用户必须将这些过滤条件应用于 Search API 后续请求。搜索结果基于用户输入，并提供新的后续问题，提示用户进行后续查询，并以多轮对话的方式继续对话，直到用户在零售商网站上找到所需内容。

注意： 对话式商品过滤界面使用两个 API，包括 Search 和 Conversational。Search API 用于获取搜索结果，而 Conversational API 用于获取对话式回答。对话式 API 不会返回搜索结果。

假设网站上启用了对话式商品过滤功能，用户体验历程以及后续与 Vertex AI Search 商务解决方案的互动将遵循以下路径：

• 第 1 步：第一个查询来自用户，同时发送到 Search API 和 Conversational API。Search API 仅返回搜索结果。Conversational API 会返回建议的答案和后续问题。针对同一查询或 page_category 调用 Search API 并提取搜索结果。
• 第 2 步：请求的后续对话已发送到对话式搜索。使用正确的对话过滤模式调用 Conversational API。
• 第 3 步。仅包含搜索结果的初始搜索响应。对话式 API 会通过返回建议的答案和后续问题来优化查询。
• 用户选择：用户选择多项选择题。
  • 所选的回答过滤条件会发送到 Conversational API。
  • Conversation API 和 Search API 会在应用过滤条件后运行。

第一个查询来自用户，用户发起对话

第一个查询是指用户在 Vertex AI Search for Commerce 中开始对话，并在搜索框中查找 dress。

注意： 有两个不同的 API 端点。必须使用核心 Search API 来获取搜索结果，并且必须使用新的 Conversational 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 字段提供对客户端界面渲染至关重要的补充数据。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 的响应如下所示：

对话式 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 的过滤条件框，并且应添加到用户已选择的任何其他过滤条件中。
• 还应将 additional_filter 添加到为后续查询和后续搜索请求发送给 Google 的过滤字段事件中。它应应用于搜索请求以提取搜索产品，还应应用于对话式搜索请求以提取后续对话。
• refined_query 应发送到 Search API 以获取更多相关产品。