其他注意事项和测试

在实施最佳实践和测试对话智能体界面时，必须考虑其他注意事项。

实施最佳实践

在实施对话智能体界面时，请考虑以下最佳实践：

  • 访问者 ID 一致性：确保为给定最终用户的每个请求始终发送唯一的 visitor_id。这对于准确的个性化和模型训练至关重要。理想情况下，此标识符对于最终用户在会话和登录/退出账号状态之间应保持一致。
  • 分支管理：虽然 default_branch 很常见，但如果您的产品目录采用多个分支的结构，请确保使用正确的分支 ID。
  • Search API 交互：对于 SIMPLE_PRODUCT_SEARCH 和提供 refined_search 的任何情况，请记得使用 refined_search 字段中的 query 或原始查询单独调用核心 Search API (SearchService.Search)，以获取实际的产品列表。Conversational API 主要侧重于对话式体验和用户意图理解，而不是直接返回产品结果。
  • 用户界面设计：设计您的网页界面，以直观的方式清晰呈现 conversational_text_response、followup_question 和 refined_search 选项，从而引导用户。

为 LLM 生成配置属性

为确保对话智能体可以生成响应，必须在属性控件 中将属性设置为 Retrievable 。

如果某个属性是 Indexable 但不是 Retrievable ，则对话智能体将找到该产品，但无法读取详细信息来回答用户问题。对话智能体通常会触发回退响应，例如抱歉，我们没有该产品。

因此，您应将语义属性（Title、Description、Brand、Specs）设置为 Retrievable: True ，以便 LLM 可以使用它们。如果您的前端需要用户界面或应用属性（BrandID、SkuID）进行呈现，请将它们设置为 Retrievable: True 。将后端元数据设置为 Retrievable: False ，以优化上下文窗口使用情况。

规划 A/B 测试

虽然相关性是一项重要的输入指标，但 AI Commerce Search 还会考虑其他变量，以优化业务结果：

指标
每次访问带来的收入 (RPV) 每次访问带来的收入是衡量搜索效果的最有效指标，因为它考虑了转化率、平均订单价值 (AOV) 和相关性。
转化次数 - 平均订单价值 (AOV) 转化率百分比和 AOV 都会影响 RPV。
相关性 - 可购买性 - 价格 相关性（以及其他输入）用于生成效果出色的搜索结果。

A/B 测试准备情况核对清单

以下是使用的成功指标：

推荐项 定义 阶段
事件归因方案 与 Google 合作，正确细分用户事件以进行衡量。 实验前
监控数据输入 能够快速了解训练数据何时包含可能会影响性能的异常值。 实验前
事件覆盖率 我们是否对与搜索或推荐 AI 会话相关的所有可能结果进行了检测？ 实验前
可衡量的成功标准 已记录的完成定义（以可衡量的术语表示）。 实验前
能够衡量用户体验偏差 确保各实验组的用户体验一致。 实验期间
VAIS 数据与消费之间的一致性 验证归因令牌、过滤器、排序依据、偏移量等是否正在从 API 传递到 UserEvents。事件和 API 请求之间的访问者/用户 ID 是否匹配。 实验期间
批准在实验期间进行调整 规划调整活动、记录更改，并相应地调整衡量和解读。 实验期间

实施概念验证或最简可行产品

数据注入 A/B 测试设计 性能指标 治理和流程

注入最新且完整的产品目录

遵循建议的事件注入方法，确保 Google 与您之间的数据同步。
Google 建议进行实时事件跟踪，包括展示次数数据。

传递必要的属性（例如实验 ID、访问者 ID），并在适用情况下正确实现搜索令牌。

 采用实验最佳实践，确保结果可靠：
  • 验证集成。
  • 一次测试一项更改。
  • 避免激进的缓存。
  • 确保网页界面在测试组和对照组之间公平。
  • 确保使用访问者 ID 进行流量分配时流量公平。
  • 确保产品数据一致。
  • 在测试组和对照组中应用相同的业务规则。
 所有评估标准都应是经验性的、客观衡量的，并且由指标驱动。

就跟踪的指标的确切定义达成一致对于准确衡量效果至关重要。

跟踪的标准指标包括：
  • 搜索点击率（结果相关性）
  • 空搜索率（意图理解）
  • 每位访问者带来的收入 / 每位用户带来的收入
  • 促成转化的搜索次数
 数据集成、测试、功能发布和优化将是一个迭代过程，需要资源。

实验节奏示例

满足最简可行产品依赖项 校准衡量 部署生产深色模式 继续/不继续决策
  • 合同
  • 训练后的模型和服务配置
  • 产品和事件数据注入
  • 将（客户端）数据与 Commerce 搜索遥测数据进行比较，并进行相应调整
  • 就衡量基准达成一致
  • 执行离线评估
  • 调整配置
  • A/A 测试以验证流量分配
  • 获得质量保证 (QA) 批准
  • 承诺逐步推进

AB 实验节奏示例

持续性测试 逐步增加到 X% 的流量 衡量、调整和重复 逐步增加到 X% 的实时路况
  • 继续调整/优化
  • 测试增量功能
  • 分析各个搜索细分的效果
  • 进行任何建模/规则调整
  • 交叉检查效果
  • 识别并解释异常值
  • 启动实验
  • 每日分享效果指标
  • 执行调整

成功实验的组成部分

校准衡量并建立成功标准 保持实验公平性 监控数据质量
  • 规划时间，以便在正式发布之前验证目录、用户事件和 API 消费的一致性。
  • 提前建立可量化的成功标准（理想情况下，以 RPV 的变化表示）。
  • 主动识别并解释回归或异常值，然后修复它们。
  • 经常分享衡量结果，了解并记录各实验组的指标定义。
  • 最大限度减少细分之间的用户体验差异（布局和视觉效果相同，只是数据不同）。
  • 注意商品推销 / 业务规则（确保它们不会引入偏差）。
  • 衡量目录漂移。
  • 正确注释实验结果（通过用户事件）。

角色和实验所有权

Google 您
质量评估 Commerce 搜索结果 用户体验影响
衡量结果 备份/验证 权威
遥测/数据 平台容量指标（验证性能）
事件和索引异常值		 归因令牌和重现步骤（验证问题）
搜索平台 商品级项
  • 数据映射
  • 模型/训练调整
  • 质量/服务异常值
  • 平台配额/限制
  • 产品/客户端库缺陷
 查询/服务项
  • 请求扩充（包括上下文路由、缓存和意图处理）
  • 服务配置（调整）
  • 源数据丰富化
  • 客户端性能（例如 WC 线程）
  • 用户体验/API/平台/库缺陷
继续/不继续 推荐 批准

在控制台中进行实验

  1. 前往 Gemini Enterprise for Customer Experience 控制台中的 AI Commerce Search 的实验 页面。

    前往“实验”页面

  2. 使用控制台进行高级自助式分析，以了解 AI Commerce Search 的新手入门和 A/B 测试，方法是应用 Google 的归因方法：

  • 监控流量细分、业务指标以及搜索和浏览效果。

  • 在关键字搜索和浏览中应用每次搜索访问级别指标。

  • 以时间序列形式查看实验效果，并提供具有统计显著性的指标。

  • 使用嵌入式 Looker 平台。