“零售”已重命名为 Vertex AI Search 零售解决方案。我们正在更新内容，以反映新的品牌形象。

此页面由 Cloud Translation API 翻译。

对话式搜索

本页介绍 Vertex AI Search 中用于零售对话式搜索的“引导式搜索功能”。

借助对话式搜索，零售商能够为用户提供更具互动性的搜索体验。对话式搜索功能是引导式搜索套件的一部分，通过缩小用户查询范围并更快地展示相关产品，使客户受益。

请阅读以下内容，了解详情：

对话式搜索的工作原理
通过主（查询）API 提供的服务体验
通过控制 API 和控制台的管理员体验

对话式搜索的运作方式

启用对话式 Vertex AI Search 零售解决方案后，系统会引导买家在商品销售商网站上通过对话进行商品搜索。在面向零售的 Vertex AI Search 中完成初始文本查询后，在线买家会收到相关的后续问题和单选题选项。后续问题可由用户以自由文本形式回答，也可通过点击对话式单选题来回答。

如果零售商网站上启用了对话式搜索，则后续问题会引导后续对话，直到出现以下三种情况之一：

达到预配置的商品数量下限（例如，如果只显示两件商品，对话就没有什么用处）。
用户点击某个产品并将其添加到购物车中（即目标）。
搜索和浏览零售业时，出现了 AI 生成的问题。

内部机制

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

单选题 多选选项像分面（事件类型过滤器）那样在后台发挥作用，它使用过滤功能来缩小查询范围。在后台，当用户点击某个单选题答案时，系统会对查询应用过滤条件。使用对话式单选题来应用过滤器等同于使用动态分面或图块应用相同过滤器。
自由文本 如果用户以自由文本形式进行回复，系统会生成一个范围更小的新查询。详细了解对话式搜索如何在用户历程中丰富过滤条件和用户事件捕获。

对话式搜索的优势

通过对话式搜索来增强零售业 Vertex AI Search 体验，可为零售商和用户带来诸多好处。

只需点击几下即可缩小查询范围

对话式搜索可让您更高效地快速缩减 1 万件商品的搜索结果，将其缩减到 100 件以下。这样，用户就更有可能决定购买，从而提高每次搜索带来的收入率。

动态分面的替代方案

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

可自定义的生成式问题，可根据零售商的偏好进行调整

对话式搜索让零售商能够根据上传的目录，预先修改、覆盖或取消选择 AI 生成的问题，从而鼓励与生成式 AI 问题进行人机协同互动。您可以在 Play 管理中心的 Search for Retail 或 API 中逐个或批量修改问题，以便定制想要在搜索中显示的问题。

控制台：管理员体验

借助该控制台，零售商可以在对话式 Vertex AI Search 零售解决方案体验中管理生成式问题。详细了解如何在对话式搜索中使用生成式问题。

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

满足数据要求。
配置手动替换。
开启该功能。
预览和测试。

数据要求

在控制台中，您可以在对话式搜索和浏览的覆盖率检查标签页下，或在数据质量 > 对话下，查看您的搜索数据是否已做好支持对话式搜索的准备。

如需启用对话式搜索，您需要满足特定的数据要求。

它们是：

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

如果您还未达到 25% 的对话覆盖率，但每天第一个前提条件达到 1,000 次查询，系统便会开始分别对输出和输入应用屏蔽检查和咨询检查。此时，Vertex AI Search for Retail 会开始计算您应用了用户事件的过滤条件的覆盖率需要提高多少百分比，才能达到 25% 的对话式覆盖率阈值。上传的滤镜越多，覆盖面就越大。

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

在 Search for Retail 控制台中，前往数据质量页面中的对话标签页。在这里，您会看到一项关键检查，用于检查至少 25% 的搜索查询是否至少包含一个后续问题，以及一项建议性检查，用于检查需要有多少百分比的用户事件包含有效的过滤条件才能实现该对话覆盖率目标。
如果您通过了关键检查，并且有足够的用户事件以及有效的过滤条件，请继续执行下一步。
如需控制生成问题的方式，请前往对话式搜索和浏览页面（位于 Search for Retail 控制台。

生成式问题控件

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

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

前往 Search for Retail 控制台中的对话式搜索和浏览页面。

前往“对话式搜索和浏览”页面。
在管理 AI 生成的问题标签页下，您可以看到所有问题按问题使用频率排序，按查询加权频率（即常见查询显示问题的频率）排序。排名使用 GenerativeQuestionConfig 中的频率字段。此字段负责对 AI 生成的问题按使用频率进行排序。
您可以使用过滤选项过滤问题。
选中该复选框即可为每个属性启用问题显示设置。
点击每行末尾的，为每个问题打开修改面板。

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

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

替代文本

如何在对话式搜索中使用生成式问题

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

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

修改个别问题

您还可以使用控件来管理各个题目。建议您先完成此操作，然后再开启对话式搜索。

每个问题都有两个选项。点击最后一列中的，以访问向用户显示的问题：

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

开启对话式搜索

在控制台中修改生成式 AI 问题后，您就可以开启对话式搜索了。

要启用对话搜索，请转到对话式搜索和浏览页面（位于 Search for Retail 控制台。

前往 Search for Retail 控制台中的对话式搜索和浏览页面。

前往“对话式搜索和浏览”页面。
在 Retail Search 的配置标签页下，您会看到系统级设置。这包括设置商品必须至少符合查询条件才能进行对话，即生成问题时。此最小值为 =>2。您可以将最小值配置为更高，但不得低于 2。考虑一下，您希望在用户开始对话时，您希望系统返回多少目录中的商品。例如，此数字的最佳值为每页一行，以便尽可能少的搜索结果触发对话。
将开关切换为“开启”。此页面还会提供有关屏蔽和建议性检查状态的信息。如果您拥有足够多的搜索查询，且至少有一个跟进问题，那么您的网站现已启用对话式搜索。

评估和测试

借助评估，您可以通过运行测试搜索并针对显示的详情测试您的问题，从而预览服务体验。您可以通过控制台的此部分预览使用对话式搜索时的呈现体验。

为此，请在评估工具的评估页面中的搜索或浏览标签页下找到此模块 Search for Retail 控制台。

前往 Search for Retail 控制台中的评估页面。

转到“评估”页面
在“搜索评估”字段中，输入一个基于您上传的清单进行搜索的合理测试查询。点击搜索预览。您会看到搜索结果，如果您启用了对话式搜索，则会在右侧面板中看到生成式问题。
在右侧面板中，您会看到一系列测试题目。

生成式问题 API：管理体验

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

API 集成

使用以下命令通过 Search for Retail 管理 GenerativeQuestion API：

对象：

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

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

启用功能

对象：

GenerativeQuestionsFeatureConfig

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

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

详细了解如何在控制台中开启对话式搜索。

在 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 will be used at serving time.
  // Note: This feature cannot be enabled 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	string LLM 生成的默认问题。仅限输出。
final_question	string 要询问的问题。其长度上限为 300 字节。可选字段。
example_values	可用于回答问题的重复字符串值。仅限输出
频次	浮点数问题被问及的频率比率。仅限输出。
allowed_in_conversation	布尔值表示在投放时是否询问问题。此字段是可选字段。

此功能带来的投放体验

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

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

GenerativeQuestionsFeatureConfig 处理程序（功能级别）：
1. 更新：可让您更改最小商品数并启用字段
2. Get：返回一个对象
GenerativeQuestion 配置处理脚本（题目级）：
1. 列表：返回指定目录的所有问题
2. 更新：单个题目管理
3. 批量更新：管理分组问题

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

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

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

对话式搜索配置 API：服务体验

对话式搜索配置 API 与 Vertex AI API 搜索 API 集成。

API 集成

该功能的配置 API ConversationalSearchSpec 位于现有 Vertex AI Search for Retail API 之上。为了支持新功能“对话式搜索”，我们对现有的 Vertex AI Search for Retail 主要（查询）API 进行了以下更改：

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

用户体验历程

对话流程的运作方式如下：用户使用初始查询发起搜索，并将 followup_conversation_requested 标志设置为“true”。然后，用户选择答案或提供自由文本输入，系统会使用 user_answer 字段发送回 API。然后，该 API 会根据用户的输入优化搜索结果，并提供新的跟进问题，提示用户后续查询并分多轮继续对话，直到用户在零售商网站上找到所需商品。

假设网站上启用了对话式搜索，那么用户体验历程以及随后与 Vertex AI Search for Retail 的互动会遵循以下路径：

第 1 步：第一条查询来自用户
第 1a 步。已请求将后续对话发送至搜索
第 1b 步。初始搜索响应，包含经过优化的查询和建议的答案
情景 2：用户选择单选题
第 2a 步：发送到搜索的所选答案过滤条件
第 2b 步。在应用过滤条件的情况下重新运行搜索
场景 3：用户选择自由文本
第 3a 步：向 Google 搜索发送了文本回答
第 3b 步。使用修改后的查询再次运行搜索

第 1 步：第一条查询来自用户

conversational_search_spec：在 SearchRequest 消息中引入此字段后，系统可以区分对话式搜索和常规搜索。此确定会影响用户是否会收到其他对话式回答，从而保留原始搜索功能，同时将其扩展为对话式互动。conversational_search_spec 字段采用消息格式，其中包含对话流所必需的详细信息，例如用户回答、对话 ID 以及用户是否需要后续对话。这些信息将指导系统了解上下文和用户互动。

如果 followup_conversation_requested 布尔值如果此字段设置为 TRUE，API 会返回一组初始结果和一个后续问题。用户在搜索时将获得对话式体验。如果此字段设置为“FALSE”，则不会显示任何后续问题。

第 1a 步。零售商 → 搜索：在启用对话的情况下进行初始查询

JSON 请求

{
  "query": "dress",
  "conversational_search_spec":  {
    "followup_conversation_requested": true
  }
}

第 1b 步。搜索 → 零售商：对话 ID、经过优化的查询、跟进问题、建议的答案

JSON 响应

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

conversational_search_result：“ConversationalSearchResult”是一个 proto，包含从对话流返回的额外信息。SearchResponse 中的 conversational_search_result 字段提供对客户端界面呈现至关重要的补充数据。conversational_search_result 字段使用 SuggestedAnswer 和 AdditionalFilter 等嵌套消息，以清晰易懂的方式组织返回的数据。这种层次结构可确保客户端和服务器之间交换的信息清晰定义且可解释。
系统会按目录中哪些细分值在用户事件中作为所有查询的过滤条件最常被使用来对建议的回答进行排序。排序使用 ConversationalSearch proto 生成的后续问题中的 engagement_rate 字段。此字段用于捕获过滤器根据发送到服务器的零售商搜索事件显示的历史互动率。

如何处理初始对话式搜索返回结果

conversation_id：正在进行的搜索会话的唯一标识符，必须存储并在后续请求中使用。在初始查询时，此字段为空，并且服务器将回复 conversation_id。此字段用于跟踪“正在进行的对话”，因为一位买家可能会打开多个标签页或使用多部设备。
refined_query：跟踪当前查询，并在用户与 Google 搜索互动时更新。如果买家选择自由文本输入，这种情况会发生变化。如果买家选择的是单选题，此字段将与请求中的查询相同。
followup_question：告知零售商要向用户显示什么问题。其中包含 question、suggested_answers 字段
suggested_answers：包含每个建议回答的名称和值键值对的商品属性值。它提供了一个多选题选项列表。此字段可设置为仅显示前 N 个多选题结果。这些问题会按 engagement_rate 字段进行排序，该字段表示相应问题在搜索中出现的概率。

场景 2：用户选择单选题

如果用户选择了单选题 yellow：

系统会从会话存储空间恢复 conversation_id。
followup_conversation_requested 设置为 true。
user_answer 字符串，使用“selected_answer”（包含一个 product_attribute_value 键值对）或 text_answer（包含值自由文本输入）来指明用户的选择。此字段在 conversational_search_spec 字段中，包含更多嵌套消息，如“SelectedAnswer”以指定用户输入类型（文本或选定的答案）。
结果会恢复为调用 SearchResults 对象及其字段。
selected_answer此字段会传递商品属性来指导对话式搜索。

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

JSON 请求

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

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

JSON 响应

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

如何处理单选题回复

搜索响应与第一个查询的响应基本相同，只不过它还使用了 additional_filter。在本示例中，它应该用于“勾掉”表示颜色 = 黄色。应将其添加到后续搜索请求或事件上传中的 filter 字段，如 filter: "colors:ANY(\"yellow\")" 所示。

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

如果用户输入 lavender：

conversation_id 会从会话存储空间恢复
将 followup_conversation_requested 设置为 true
user_answer 会根据用户输入的内容进行设置（使用 text_answer: 前缀）

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

JSON 请求

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

请注意，自由文本请求中缺少过滤器字段。

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

JSON 响应

{
  "conversational_search_result": {
    "conversation_id": "c154d073-87f5-4edb-accd-587eabe014ff",
    "refined_query": "lavender dress",
    "followup_question": "What is the occasion?",
    "suggested_answers": [
      {
        "product_attribute_value": {
          "name": "attribute.occasion",
          "value": "wedding"
        }
      },
      {
        "product_attribute_value": {
          "name": "attribute.occasion",
          "value": "party"
        }
      }
    ]
  }
}

如何处理免费文本响应

与初始响应类似，但请注意 refined_query 现在会相应地更新。
使用优化后的查询更新搜索界面（“搜索框”）。
在后续搜索请求或事件上传事件中发送经过优化的查询。
如果用户给出的自由文本答案与建议答案相符（例如，当存在 colors="yellow" 建议的答案时，答案为 text_answer="yellow"），这种情况将被视为单选题答案（参见上文）。