你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用学徒模式在不影响现有应用程序的情况下训练个性化体验创建服务
重要
从 2023 年 9 月 20 日开始，将无法创建新的个性化体验创建服务资源。 个性化体验创建服务将于 2026 年 10 月 1 日停用。
部署新的个性化体验创建服务资源时，会使用未训练的模型或空白模型将其初始化。 也就是说，它尚未从任何数据中学习，因此在实践中表现不佳。 这称为“冷启动”问题，可通过使用生产环境中的真实数据训练模型，随时间推移解决该问题。 学徒模式是一种学习行为，有助于缓解“冷启动”问题，并在模型在生产环境中做出决策之前，让你无需更改任何代码也能对模型充满信心。
什么是学徒模式？
与学徒通过观察专家来学习手艺一样，学徒模式使个性化体验创建服务能够通过观察应用程序当前逻辑所做的决策不断学习。 个性化体验创建服务模型通过模仿与应用程序相同的决策输出进行训练。 通过每次调用排名 API，个性化体验创建服务可以在不影响现有逻辑和结果的情况下不断学习。 Azure 门户和 API 提供的指标可帮助你了解模型在学习时的性能。 具体而言，这种表现是指个性化体验创建服务与现有逻辑（也称为基线策略）的匹配程度。
一旦个性化体验创建服务能够在 60-80% 的时间内与现有逻辑合理匹配，则就可以将行为从学徒模式更改为联机模式。 此时，个性化体验创建服务会返回排名 API 中由基础模型确定的最佳操作，并且可以学习如何做出比基线策略更好的决策。
为何使用学徒模式？
在做出由应用程序使用的联机决策之前，可以通过学徒模式来模拟现有的决策逻辑。 这有助于缓解上述冷启动问题，让你更加信任个性化体验创建服务，并确保发送到个性化体验创建服务的数据对模型训练有价值。 这种做法不会带来风险，也不会影响联机流量和客户体验。
使用学徒模式的两个主要原因是：
- 缓解冷启动：学徒模式通过不断学习，无需做出不知情的决策，来帮助降低在生产环境中训练“新”模型的成本。 模型会试着模拟现有应用程序逻辑。
- 验证操作和上下文特征：上下文和操作特征可能不充分、不准确或设计欠佳。 如果特征太少、太多、不正确、杂乱或格式错误，个性化设置将难以训练出性能良好的模型。 在学徒模式下执行特征评估时，可以发现这些特征在训练个性化体验创建服务方面的效果，并识别需要改进特征质量的领域。
何时应使用学徒模式？
对于以下场景，可以使用学徒模式来训练个性化体验创建服务，这样既可以改善个性化体验创建服务的有效性，还可以避免个性化体验创建服务对用户体验造成影响：
- 你要在新方案中实现个性化体验创建服务。
- 你已对上下文或操作特征做出重大更改。
但是，学徒模式并不能有效衡量个性化体验创建服务对提高平均奖励或业务 KPI 的影响。 它只能评估在你提供的当前数据下，该服务对现有逻辑的学习程度。 若要衡量个性化体验创建服务对为每个排名调用选择最佳可能操作发挥的效力，个性化体验创建服务必须处于联机模式，或者你可以在个性化体验创建服务处于联机模式时使用脱机评估一段时间。
谁应该使用学徒模式？
开发人员、数据科学家和业务决策者适合使用学徒模式：
开发人员可以使用学徒模式来确保在应用程序中正确实现排名和奖励 API，并确保发送到个性化体验创建服务的特征没有错误和常见错误。 详细了解如何创建良好的上下文和操作特征。
数据科学家可以使用学徒模式来验证特征是否对于训练个性化体验创建服务模型有效。 也就是说，这些特征包含有用的信息，使个性化体验创建服务能够学习现有的决策逻辑。
业务决策者可以使用学徒模式来评估个性化体验创建服务相比现有业务逻辑在改善结果（即奖励）方面的潜力。 具体而言，就是个性化体验创建服务能否在进入联机模式之前从所提供的数据中学习。 这样，他们就可以做出明智的决策来改善用户体验，确保利害攸关的实际收入和用户满意度不会受到负面影响。
行为比较 - 学徒模式和联机模式
学徒模式和联机模式下的学习存在以下差别。
| 区域 | 学徒模式 | “联机” 模式 |
|---|---|---|
| 对用户体验的影响 | 用户的体验和业务指标不会改变。 个性化体验创建服务是在不影响当前应用程序逻辑的基线操作的情况下，通过观测这些操作训练的。 | 用户体验可能会改变，因为做决策的是个性化体验创建服务，而不是基线操作。 |
| 学习速度 | 个性化体验创建服务在学徒模式下的学习速度比在联机模式下要慢。 学徒模式只能通过观察默认操作获得的奖励进行学习，而无法进行探索，这会限制个性化体验创建服务的学习程度。 | 学习速度更快，因为它既可以利用当前模型中的最佳操作，又可以探索其他操作以获得更好的结果。 |
| 学习有效性“上限” | 个性化体验创建服务只能接近但永远无法超过应用程序当前逻辑的性能（基线操作获得的总平均奖励）。 个性化体验创建服务不太可能与当前应用程序的逻辑达到 100% 匹配，建议在达到 60%-80% 的匹配后，将个性化体验创建服务切换到联机模式。 | 个性化体验创建服务应超过基线应用程序逻辑的性能。 如果个性化体验创建服务的性能随时间推移而停滞，你可以进行脱机评估和特征评估，寻求进一步的改进。 |
| rewardActionId 的排名 API 返回值 | rewardActionId 始终是默认操作的 ID。 即，作为排名 API 请求 JSON 中的第一个操作发送的操作。 换句话说，在学徒模式下，排名 API 不会执行任何对应用程序可见的操作。 | rewardActionId 将作为个性化体验创建服务模型确定的排名 API 调用中提供的 ID 之一。 |
| 评估 | 个性化体验创建服务会不断地将当前应用程序逻辑获得的奖励总数，与个性化体验创建服务处于联机模式时在该时间点获得的奖励总数进行比较。 可以在 Azure 门户中个性化体验创建服务资源的“监视”边栏选项卡中查看这些比较结果。 | 通过运行脱机评估来评估个性化体验创建服务的有效性，这可以将个性化体验创建服务实现的奖励总数与应用程序基线的潜在奖励进行比较。 |
请注意，个性化体验创建服务不太可能与应用程序基线逻辑的性能 100% 匹配，而且永远不会超过后者。 60%-80% 的性能匹配足以将个性化体验创建服务切换到联机模式，在此模式下，个性化体验创建服务可以学习更好的决策并超过应用程序基线逻辑的性能。
学徒模式的限制
学徒模式通过使用排名调用中存在的上下文和操作特征来尝试模仿现有应用程序的基线逻辑，以此训练个性化体验创建服务模型。 以下因素会影响学徒模式的学习能力。
学徒模式可能不适用的场景：
以编辑身份选择的内容：
在一些场景（如新闻或娱乐）中，基线项目可由编辑团队手动分配。 这意味着人类正在利用他们对更广阔世界的了解，以及对可能吸引人的内容的理解，从池中选择特定的文章或媒体，并将它们标记为“首选”或“主要”文章。 由于这些编辑器并非算法，编辑器考虑的因素可能是主观性的，并可能与上下文或操作特征无关。 在这种情况下，学徒模式可能难以预测基线操作。 在这些情况下，你可以：
- 在联机模式下测试个性化体验创建服务：考虑将个性化体验创建服务暂时置于联机模式或 A/B 测试模式（如果你有基础结构），然后运行脱机评估以评估应用程序基线逻辑与个性化体验创建服务之间的差异。
- 添加编辑注意事项和建议作为特征：询问编辑哪些因素会影响其选择，看能否将这些因素作为特征添加到上下文和操作中。 例如，媒体公司的编辑器可能会在某位名人经常出现在新闻中时突出显示内容：此知识可作为上下文特征添加。
将改进和加速学徒模式的因素
如果学徒模式正在学习并达到高于零的匹配性能，但是性能提升非常缓慢（在两周内未达到 60% 到 80% 的匹配奖励），可能是因为发送到个性化体验创建服务的数据太少。 以下步骤可能有助于加快学习速度：
- 添加区分特征：可以对排名调用中的操作及其特征进行目视检查。 基线操作是否具有区别于其他操作的特征？ 如果它们看起来大致相同，请添加更多特征以提高特征值的多样性。
- 减少每个事件的操作数：个性化体验创建服务将使用“用于探索的排名调用的百分比”设置来发现首选项和趋势。 当排名调用具有更多操作时，任何特定操作被选择用于探索的概率就会降低。 作为临时调整，可以将每个排名调用中发送的操作数减少到一个较小的数字（低于 10），这可能指示学徒模式是否有足够的数据来学习。
结合历史数据使用学徒模式进行训练
如果你有大量的历史数据并想使用它们来训练个性化体验创建服务，则可以使用学徒模式通过个性化体验创建服务重放数据。
在学徒模式下设置个性化体验创建服务，并创建一个脚本，用于结合历史数据中的操作和上下文特征调用“排名”。 根据此数据中记录的计算结果调用奖励 API。 可能需要大约 50,000 个历史事件才能使个性化体验创建服务达到与应用程序基线逻辑的 60-80% 匹配度。 可以通过增加或减少事件来获得满意的结果。
基于历史数据训练时，建议使发送的数据 [上下文和操作的特征、这些特征在用于排名请求的 JSON 中的布局，以及此训练数据集中的奖励计算结果] 与现有应用程序提供的数据 [特征以及奖励计算结果] 相匹配。
脱机和历史数据往往更不完整、干扰更多，并且格式可能与生产（或联机）方案不同。 虽然可以基于历史数据进行训练，但这种做法的结果可能不是结论性的，而且不一定能够很好地预测个性化体验创建服务在联机模式下的学习表现，尤其是当历史数据和当前方案的特征不同时。
学徒模式与 A/B 测试的比较
只有在验证个性化体验创建服务之后并且它在联机模式下学习时，对个性化体验创建服务处理执行 A/B 测试才有作用，因为在学徒模式下，仅使用基线操作并学习现有逻辑。 这实质上意味着个性化体验创建服务返回的是 A/B 测试的“控制”分支的操作，因此学徒模式下的 A/B 测试没有作用。
使用个性化体验创建服务和联机学习模式建立用例后，可以使用 A/B 试验创建受控的队列，并对可能比用于奖励的信号更复杂的结果执行比较。 A/B 测试可以解答的一个示例问题是：“在零售网站中，个性化体验创建服务优化了布局并让更多用户提前结帐，但这是否会降低每笔交易的总收入？”