对话式过滤开发者指南

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

满足最低数据要求才能启用对话式过滤

若要达到启用对话式商品过滤功能所需的 25% 配额，您必须增加包含有效过滤条件信息的用户事件数量。您在用户事件中上传的过滤条件越多，对话覆盖率就越高。

以下是增加覆盖面的具体步骤和逻辑：

• 上传用户事件中的过滤条件。您需要增加应用了用户事件过滤条件的输入。这样一来，当用户在您的网站上应用颜色或价格等过滤条件时，系统会在发送给 AI Commerce Search 的相应搜索用户事件的过滤条件字段中捕获该操作。

• 建立反馈环。LLM 会根据这些过滤器推断出方面的人气。如果某个属性被标记为可动态分面，那么在搜索事件中添加相应过滤条件即可启动模型的学习过程。理想情况下，您的界面应在搜索请求和事件中捕获并中继用户过滤条件选择，以推动这种持续的模型优化。

• 监控数据质量建议检查。如果您已达到每天 1,000 次查询的初始阈值，但覆盖率未达到 25%，控制台中的数据质量页面（位于对话标签页下）将提供具体的建议检查。这些检查会计算并显示用户事件应用过滤条件必须增加的确切百分比，才能达到覆盖率目标值。

• 确保属性配置。由于该模型会使用您过滤的属性来生成问题，因此请确保这些属性在您的目录中正确配置为可编入索引且可动态分面。

管理员体验

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

Cloud 控制台

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

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

1. 满足数据要求。

2. 配置手动问题替换。

3. 开启此功能。

4. 预览和测试。

数据要求

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

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

它们是：

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

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

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

1. 在 Gemini Enterprise for Customer Experience 控制台的 AI Commerce Search 中，前往数据质量页面中的对话标签页。这可让您关键性地检查至少 25% 的搜索查询是否至少有一个后续问题，并提供建议性检查，以确定需要多少百分比的具有有效过滤条件的用户事件才能实现该对话覆盖率目标。

图 1。对话式搜索就绪性检查。

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

2. 如需控制生成式问题的提供方式，请前往 AI 商务搜索控制台中的对话式产品过滤和浏览页面。

生成式问题控件

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

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

1. 前往 Gemini Enterprise for Customer Experience 控制台中的 AI Commerce Search 购物代理页面。
   
   前往“对话式搜索和浏览”页面。

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

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

4. 选中相应复选框，为每个属性启用问题显示功能。

5. 点击每行末尾的 ，打开每个问题的编辑面板。

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

1. 选中或取消选中您要在对话中包含或排除的问题旁边的框。

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

图 2. 修改每个 AI 生成的问题。

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

生成式问题服务 API 提供了一些控制措施，可用于缓解 LLM 输出中可能存在的不一致性。您可以在控制台中管理这些设置。零售商还可以在此处配置对话式商品过滤功能，方法是切换其启用状态并设置触发该功能所需的最低商品数量。

您可以定义问题，指定问题本身、可能的答案，以及是否允许在对话中使用该问题。单个问题可以由 LLM 生成，也可以由零售商替换。该控制台支持查看 AI 生成的问题，让零售商能够替换这些问题或切换其对话状态。您还可以批量修改问题。

修改单个问题

您还可以使用控件来精心挑选各个问题。建议您在开启对话式产品过滤功能之前执行此操作。

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

1. 针对所有查询停用某个问题：默认情况下，该问题处于启用状态。取消选中（或再次选中）允许在对话中使用旁边的复选框。此选项会完全跳过相应问题。如果某个问题与查询的属性无关，或者可能会被误解为不当问题（例如您在寻找什么尺码的连衣裙？这个问题可能会被视为在打探体重），零售商可以选择完全停用该问题。
2. 改写问题：在窗格中，您可以查看 AI 生成的问题、问题所附加的属性以及该属性具有的值。点击铅笔图标即可重写。

开启对话式过滤

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

如需启用对话式产品过滤，请前往 Gemini Enterprise for Customer Experience 控制台中的 Conversational product filtering and browse page（对话式产品过滤和浏览页面）。

1. 前往 Gemini Enterprise for Customer Experience 控制台中的 AI Commerce Search 购物代理页面。
   
   前往“对话式搜索和浏览”页面。

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

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

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

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

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

评估和测试

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

如需进行评估和测试，请按以下步骤操作。在 Gemini Enterprise for Customer Experience 控制台的 AI Commerce Search 的“评估”页面上，点击搜索或浏览标签页，然后点击评估部分。

1. 前往 Gemini Enterprise for Customer Experience 控制台中的 AI Commerce Search 评估页面。
   
   前往“评估”页面

2. 点击搜索或浏览。

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

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

图 4。预览结果。

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

Generative Question API

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

API 集成

物体：

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

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

启用对话式商品过滤

对象：

• GenerativeQuestionsFeatureConfig

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

feature_enabled 开关用于确定在提供服务时是否使用问题。它用于管理控制台中的顶级切换开关。

注意： 在满足数据要求之前，您无法启用对话式商品过滤功能。如果不满足数据要求，API 会触发验证错误。数据要求验证功能可在 Gemini Enterprise for Customer Experience 控制台中的 AI Commerce Search 中看到，该功能在后台调用 Conversational Configuration 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 位于 Conversational API 之上。您可以并行调用这两个 API，也可以按以下顺序调用：

1. Conversational API
2. 搜索 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，包括 Search 和 Conversational。Search API 用于获取搜索结果，而 Conversational API 用于获取对话式回答。对话式 API 不会返回搜索结果。

假设网站上已启用对话式产品过滤功能，用户历程以及后续与 AI 商务搜索的互动将遵循以下路径：

• 第 1 步：第一个查询来自用户，同时发送到 Search API 和 Conversational API。Search API 仅返回搜索结果。对话式 API 会返回建议的答案和后续问题。针对同一查询或 page_category 调用 Search API，并提取搜索结果。请求的后续对话已发送到对话式搜索。使用正确的对话过滤模式调用 Conversational API。

• 第 2 步：仅包含搜索结果的初始搜索响应。对话式 API 通过返回建议的答案和后续问题来优化查询。然后，最终用户选择多项选择：

  • 所选的回答过滤条件会发送到 Conversational API。
  • 对话和搜索 API 会在应用过滤条件后运行。

初始用户查询

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

• 用户操作：最终用户搜索连衣裙。
• 您的实现：进行两次 API 调用。
• 对话式 API 请求：
  • query：“dress”
  • conversational_search_spec：
    • mode："CONVERSATIONAL_FILTER_ONLY" 这是关键参数。
• Search API 请求：
  • query：连衣裙
• 对话式 API 响应：
  • conversation_id：“c15...”存储此变量。
  • followup_question：系统会生成这是什么颜色？问题。
  • suggested_answers：[ {name: "colors", value: "yellow"}, {name: "colors", value: "blue"}, ... ]
• 操作：向用户显示 followup_question 和 suggested_answers。

注意： 有两个不同的 API 端点。必须使用核心搜索 API 来获取搜索结果，并使用对话 API 来获取对话式体验。对话式 API 不会返回搜索结果。

向 Search API 发送请求

通过将 dress 设置为查询内容（或实际查询内容），创建以下搜索请求，以向 Search API 发送请求：

Search API 请求

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

在对话式商品过滤中，搜索 API 请求没有任何变化。

向 Conversational API 发送请求

通过执行以下操作向 Conversational API 发送请求：

• 通过将 dress 设置为查询内容（或实际查询内容）来创建对话式搜索请求。

• 将 mode 设置为 CONVERSATIONAL_FILTER_ONLY，以便获得对话式回答。如果设置为 DISABLED，则不提供后续问题。

• 在对话式搜索请求中填充 SearchParams。搜索参数应与 Search API 调用相同。

对话式 API 请求

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

对话式 API 响应

然后，Conversational 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 调用。
• 对话式 API 请求：
  • query：连衣裙
  • conversation_id："c15..." 使用存储的 ID。
  • user_answer: { selected_answer: { product_attribute_value: { name: "colors", value: "yellow" } } }
• Search API 请求：
  • query：连衣裙。
• 对话式 API 响应：
  • additional_filter: { product_attribute_value: { name: "colors", value: "yellow" } }
  • followup_question：是什么场合？
• 操作：使用 additional_filter 更新网页界面，例如选中黄色过滤框，并显示新问题。

对话式 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 以获取更多相关产品。

实现商品过滤条件

本部分旨在指导用户在 API 级别实现对话式产品过滤。起始（中性）状态是着陆页，可能包含搜索栏、推荐或营销活动，具体取决于您的 AI Commerce Search 应用。尚未对 Search 或 Conversation API 进行调用。

起始状态

这是用户界面（用于建议或广告系列）的着陆页。尚未进行任何 Search for Conversational API 调用。

用户输入查询

输入查询内容，例如 lipstick，以向 Search 和 Conversation API 发出并行调用。

搜索和对话服务第一个问题

系统会显示 API 响应，包括初始问题和一组答案选项。Conversational API 和 Search API 对初始用户查询的响应分别是异步的。

用户选择显示的回答或过滤条件

用户选择显示的答案或过滤条件。

然后，用户选择会向这两个 API 发出第二次调用，其中包含用户的过滤条件或答案。

API 提供后续问题

搜索和对话 API 都会异步响应，以处理另一个问题并显示答案选项。

用户会看到下一个问题以及下一个问题的一组答案选项。

边缘用例

实现中还涵盖了其他一些可能的情况。

用户输入新查询

如果用户正在为查询输入对话过滤条件（例如 lipstick），网页界面已填充了 API 的初始响应。不过，当用户输入新查询内容（例如防晒霜）时，系统会开始新的对话。如果发生这种情况，API 实现会恢复为新查询，但 conversation_id 字段为空。此新查询会重新生成新的回答，并相应地重新填充网页界面。

用户取消选择某个方面过滤条件或之前回答过的问题

如果用户位于已填充了之前查询的回答的界面中，但取消选择所选的分面过滤条件或回答，系统会使用 searchParam 过滤条件启动新的对话会话。原因是用户正在脱离当前的对话流程。