对话式过滤开发者指南

以下是有关如何在 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 Commerce Search 模型计算得出，是指包含一个问题的查询所占的百分比。按量计算，至少有 25% 的查询应至少有一个匹配的第一个问题。

如果您尚未达到 25% 的对话覆盖率，但已满足第一个前提条件（每天 1,000 次查询），系统会开始对您的输出和输入分别应用屏蔽检查和建议检查。此时，AI Commerce Search 开始计算用户事件应用过滤条件必须增加多少百分比才能达到 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 控制台中的 AI Commerce Search 对话式商品过滤和浏览页面。

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. 在 Search Evaluation 字段中，输入一个根据您上传的目录进行搜索的合理测试查询，例如，如果您的目录包含服装商品，则输入鞋子。

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。

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

注意： 对话式商品过滤界面与两个 API（包括 Search 和 Conversational）进行交互。Search API 用于提取搜索结果，而 Conversational API 用于提取对话式回答。对话式 API 不会返回搜索结果。

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

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

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

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

初始用户查询

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

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

注意： 有两个不同的 API 端点。必须使用核心 Search API 来获取搜索结果，并使用 Conversational 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" } } }
• 搜索 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"
        }
      }
    }
  }
}

然后，对话 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 API 或 Conversation API。

起始状态

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

用户输入查询

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

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

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

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

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

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

API 提供后续问题

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

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

边缘用例

该实现还涵盖了其他一些可能的情形。

用户输入新查询

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

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

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