你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

使用学徒模式在不影响现有应用程序的情况下训练个性化体验创建服务

由于个性化体验创建服务模型的现实世界强化学习性质,只能在生产环境中对其进行训练。 部署新用例时,个性化体验创建服务模型的表现并不高效,因为充分训练该模型需要一段时间。 学徒模式是可以改善这种局面的一种学习行为,在此模式下,开发人员无需更改任何代码,就能获得对模型的信心。

重要

学徒模式(公共预览版)仅在 E0 定价层上可用。 有关详细信息,请参阅定价。 可以在创建资源时选择 E0 层,也可以从 Azure 门户的“订阅”选项卡升级到 E0。 如果你在另一层上并升级到 E0,则现有的个性化体验创建服务资源将自动迁移到 E0 层。

什么是学徒模式?

就像学徒从专家那里学习手艺一样,有了经验就可以做得更好;学徒模式是一种“行为”,它允许个性化体验创建服务通过观察从现有应用程序逻辑获得的结果来进行学习。

个性化体验创建服务通过模拟与应用程序相同的输出进行训练。 随着更多事件的流动,个性化体验创建服务可以赶上现有应用程序的进度,且不会影响现有的逻辑和结果。 Azure 门户和 API 提供的指标可帮助你了解模型在学习时的性能。

在个性化体验创建服务不断学习并达到一定程度的理解能力后,开发人员可将行为从学徒模式更改为联机模式。 此时,个性化体验创建服务将开始影响排名 API 中的操作。

学徒模式的用途

学徒模式可使你对个性化体验创建服务服务及其机器学习功能感到可信,并可确保为服务发送可从中习得知识的信息 - 而不会产生有风险的联机流量。

使用学徒模式的两个主要原因是:

  • 缓解冷启动:学徒模式可帮助管理和评估“新”模型在学习时(未返回最佳操作,且未达到约 60% - 80% 的令人满意的有效性级别时)产生的成本。
  • 验证操作和上下文特征:在操作和上下文中发送的特征可能不足或不准确 - 过少、过多、不正确,或者对于训练个性化体验创建服务而言过于具体,导致无法获得理想的有效率。 使用特征评估可以查找和修复特征存在的问题。

何时应使用学徒模式?

对于以下场景,可以使用学徒模式来训练个性化体验创建服务,这样既可以改善个性化体验创建服务的有效性,还可以避免个性化体验创建服务对用户体验造成影响:

  • 你要在新用例中实现个性化体验创建服务。
  • 你对在上下文或操作中发送的特征做了重大更改。
  • 你对计算奖励的时间和方式做了重大更改。

通过学徒模式并不能有效衡量个性化体验创建服务对奖励分数的影响。 若要衡量个性化体验创建服务对为每个排名调用选择最佳可能操作发挥的效力,请使用脱机评估

谁应该使用学徒模式?

开发人员、数据科学家和业务决策者适合使用学徒模式:

  • 开发人员可以使用学徒模式来确保在应用程序中正确使用排名和奖励 API,并确保从应用程序发送到个性化体验创建服务的特征不包含 bug 或不相关的特征,例如时间戳或 UserID 元素。

  • 数据科学家可以使用学徒模式来验证特征是否对于训练个性化体验创建服务模型有效,以及奖励等待时间是否过长或过短。

  • 业务决策者可以使用学徒模式来评估个性化体验创建服务相比现有业务逻辑在改善结果(即奖励)方面的潜力。 这样,他们就可以做出明智的决策来改善用户体验,确保利害攸关的实际收入和用户满意度不会受到负面影响。

行为比较 - 学徒模式和联机模式

学徒模式和联机模式下的学习存在以下差别。

区域 学徒模式 “联机” 模式
对用户体验的影响 可以使用现有的用户行为来训练个性化体验创建服务:让个性化体验创建服务观察(不是影响)你一贯的默认操作及其获得的奖励。 这意味着,用户的体验及其在体验中获得的业务成果不受影响。 显示排名调用返回的会影响用户行为的首个操作。
学习速度 个性化体验创建服务在学徒模式下的学习速度比在联机模式下要慢。 学徒模式只能通过观察你的默认操作获得的奖励进行学习,这会限制学习速度,因为无法执行探索。 学习速度更快,因为此模式可以利用当前模型并探索新趋势。
学习有效性“上限” 个性化体验创建服务可以接近、在极少情况下可以达到但永远不会超过基础业务逻辑的性能(每个排名调用的默认操作实现的奖励总数)。 通过探索可以降低此近似值上限。 例如,以 20% 的性能进行探索时,学徒模式的性能基本上不可能超过 80%,60% 是一个合理的目标,达到此目标即可提升到联机模式。 个性化体验创建服务应该超过应用程序基线,如果它有一段时间处于停滞状态,则你应该执行脱机计算和特征评估以持续改进模型。
rewardActionId 的排名 API 值 用户的体验不受影响,因为 rewardActionId 始终是在排名请求中发送的第一个操作。 换句话说,在学徒模式下,排名 API 不会执行任何对应用程序可见的操作。 应用程序中的奖励 API 不应改变应用程序在两种不同模式之间使用奖励 API 的方式。 个性化体验创建服务为应用程序选择的 rewardActionId 将改变用户的体验。
评估 个性化体验创建服务会不断地将默认业务逻辑获得的奖励总数,与个性化体验创建服务处于联机模式时在该时间点获得的奖励总数进行比较。 Azure 门户中提供了该资源的比较 通过运行脱机评估来评估个性化体验创建服务的有效性,这可以将个性化体验创建服务实现的奖励总数与应用程序基线的潜在奖励进行比较。

有关学徒模式有效性的说明:

  • 处于学徒模式的个性化体验创建服务的有效性极少接近应用程序基线的 100%;永远不会超过此基线。
  • 最佳做法是不要试图达到 100%,而是应该根据用例将 60% – 80% 的有效性范围定为目标。

学徒模式的限制

学徒模式通过尝试模拟选择基线项目的现有算法,并使用上下文中的特征和排名调用中使用的操作以及奖励调用的反馈,来尝试训练个性化体验创建服务模型。 以下因素将影响个性化体验创建服务学徒是否或何时学习足够的匹配奖励。

学徒模式可能不适用的场景:

以编辑身份选择的内容:

在一些场景(如新闻或娱乐)中,基线项目可由编辑团队手动分配。 这意味着人类正在利用他们对更广阔世界的了解,以及对可能吸引人的内容的理解,从池中选择特定的文章或媒体,并将它们标记为“首选”或“主要”文章。 由于这些编辑器并非算法,并且编辑器考虑的因素可能很细微且不包括为上下文和操作的特征,因此学徒模式不太可能能够预测下一个基线操作。 在这些情况下,你可以:

  • 在联机模式下测试个性化体验创建服务:学徒模式不预测基线并不意味着个性化体验创建服务不能实现良好甚至更好的结果。 如果具有基础结构,请考虑将个性化体验创建服务置于联机模式一段时间或置于 A/B 测试中,然后运行脱机评估来评估差异。
  • 添加编辑注意事项和建议作为特征:询问编辑哪些因素会影响其选择,看能否将这些因素作为特征添加到上下文和操作中。 例如,媒体公司的编辑器可能会在某位名人出现在新闻中时突出显示内容:此知识可作为上下文特征添加。

将改进和加速学徒模式的因素

如果学徒模式学习和获得零个以上的匹配奖励,但似乎增长缓慢(2 周内未达到 60% - 80% 的匹配奖励),则挑战可能在于数据太少。 采用以下步骤可以加速学习。

  1. 随时间添加更多具有正面奖励的事件:学徒模式在应用程序每天获得超过 100 个正面奖励的用例中表现得更好。 例如,如果一个奖励点击的网站有 2% 的点击率,则每天至少应有 5,000 次访问才能有显著的学习效果。
  2. 尝试更简单且发生更频繁的奖励分数。 例如,从“用户是否完成阅读文章”转到“用户是否开始阅读文章”。
  3. 添加区分特征:可以对排名调用中的操作及其特征进行目视检查。 基线操作是否具有区别于其他操作的特征? 如果它们看起来基本相同,则添加更多特征,使之不那么相似。
  4. 减少每个事件的操作数:个性化体验创建服务将使用探索百分比设置来发现首选项和趋势。 当排名调用具有更多操作时,一个操作被选择用于探索的概率就会降低。 将每个排名调用中发送的操作数减少到一个较小的数目,即少于 10。 这可以是一种临时调整,用于显示学徒模式具有匹配奖励的适当数据。

结合历史数据使用学徒模式进行训练

如果你有大量的历史数据并想要使用它们来训练个性化体验创建服务,则你可以使用学徒模式通过个性化体验创建服务重放数据。

在学徒模式下设置个性化体验创建服务,并创建一个脚本,用于结合历史数据中的操作和上下文特征调用“排名”。 根据此数据中记录的计算结果调用奖励 API。 需要大约 50,000 个历史事件才能看到一些结果,但建议使用 500,000 个历史事件以提高结果的置信度。

基于历史数据训练时,建议使发送的数据(上下文和操作的特征、这些特征在用于排名请求的 JSON 中的布局,以及此训练数据集中的奖励计算结果)与现有应用程序提供的数据(特征以及奖励计算结果)相匹配。

脱机和事后数据往往更不完整、干扰更多,而且格式也不尽相同。 尽管可以基于历史数据进行训练,但这种做法的结果可能不是结论性的,而且不能很好地预测个性化体验创建服务的学习表现如何,尤其是既往数据与现有应用程序之间的特征有差异时。

通常,与使用历史数据进行训练相比,将个性化体验创建服务的行为更改为学徒模式并从现有应用程序学习是生成有效模型,同时减少精力、数据工程和清理工作量的更有效途径。

学徒模式与 A/B 测试的比较

只有在验证个性化体验创建服务之后并且它在联机模式下学习时,对个性化体验创建服务处理执行 A/B 测试才有作用。 在学徒模式下只使用默认操作,这意味着所有用户都会实际看到控制体验。

即使个性化体验创建服务只是处理方式,但在验证数据是否适合用于训练个性化体验创建服务时也存在同样的挑战。 可以改用学徒模式,这样,100% 的流量以及所有用户都可以获得(不受影响的)控制体验。

使用个性化体验创建服务和联机学习模式建立用例后,可以使用 A/B 试验对可能比用于奖励的信号更复杂的结果执行受控的同期群和科学比较。 A/B 测试可以解答的一个示例问题是:In a retail website, Personalizer optimizes a layout and gets more users to _check out_ earlier, but does this reduce total revenue per transaction?

后续步骤