当前位置：首页 > article >正文

Spotify AI 技术（1）使用 TensorFlow 和 TF-Agents

article 2025/2/23 9:02:10

介绍

我们的许多音乐推荐问题都涉及为用户提供有序的项目集，以满足用户在那个时间点的收听偏好和意图。我们根据以前与应用程序的交互来提供当前的推荐，抽象地说，由于我们不断向用户推荐内容，因此我们面临着一个连续的决策过程。

强化学习（RL）是一种成熟的顺序决策工具，可用于解决顺序推荐问题。我们决定探索如何使用 RL 为用户打造聆听体验。在我们开始训练代理之前，我们需要选择一个 RL 库，使我们能够轻松地构建原型、测试和部署我们的解决方案。

在 Spotify，我们将 TensorFlow 和扩展的 TensorFlow 生态系统（TFX、TensorFlow Serving 等）作为我们生产机器学习堆栈的一部分。我们很早就决定将 TensorFlow Agents 用作我们的首选 RL 库，因为我们知道将我们的实验与我们的生产系统集成会大大提高我们的效率。

笔记

TFX

当您准备好将模型从研究状态切换到生产状态时，可以使用 TFX 创建和管理生产流水线。

TensorFlow Serving

TensorFlow Serving 是一种灵活的高性能机器服务系统专为生产环境设计的学习模型。TensorFlow Serving 使轻松部署新算法和实验，同时保持相同的服务器架构和 API 的 API 中。TensorFlow Serving 提供开箱即用的集成使用 TensorFlow 模型，但可以轻松扩展以服务于其他类型的模型和数据。

我们需要的一个缺失的技术是离线 Spotify 环境，我们可以在在线测试之前使用它来离线原型、分析、探索和训练代理。TF-Agents 库的灵活性，加上 TensorFlow 及其生态系统的更广泛优势，使我们能够干净利落地设计出一个强大且可扩展的离线 Spotify 模拟器。

我们的模拟器设计基于 TF-Agents Environment 基元，并使用这个模拟器我们开发、训练和评估了物品推荐、原版 RL 代理（PPG、DQN）和改进的深度 Q 网络（我们称之为动作头 DQN（AH-DQN））的顺序模型，它解决了我们的 RL 公式的大状态和动作空间所带来的特定挑战。

通过实时实验，我们能够证明我们的线下效果估计值与线上结果密切相关。这为 Spotify 的大规模实验和强化学习应用打开了大门，这得益于 TensorFlow 和 TF-Agents 解锁的技术基础。

在本文中，我们将提供有关 RL 问题的更多详细信息，以及我们如何使用 TF-Agent 端到端地启用这项工作。

RL 循环和模拟用户

在 RL 中，代理与环境持续交互。在给定的时间步长，Agent 使用来自环境的观察值，并使用此观察值在时间 t 生成给定其策略的作。然后，环境处理作并发出奖励和下一个观察值（请注意，虽然通常可以互换使用，但 State 是作后总结环境所需的完整信息，而 Observation 是实际暴露给 Agent 的此信息部分）。

在我们的例子中，从环境发出的奖励是用户对代理作驱动的音乐推荐的响应。在没有模拟器的情况下，我们需要将真实用户暴露给 Agent 以观察奖励。我们采用基于模型的 RL 方法来避免让未经训练的 Agent 与真实用户交互（在训练过程中可能会损害用户满意度）。

在这种基于模型的 RL 公式中，Agent 不会针对真实用户进行在线训练。相反，它使用用户模型来预测对通过 Agent作派生的跟踪列表的响应。使用此模型，我们以最大化（模拟的）用户满意度指标的方式优化作。在训练阶段，环境使用此用户模型返回预测的用户对 Agent 建议的作的响应。

我们使用 Keras 来设计和训练我们的用户模型。然后，模拟器解压缩序列化的用户模型，并用于计算代理训练和评估期间的奖励。

笔记

Keras 是一个高级神经网络 API，最初由 François Chollet 创建，并于2017年合并到 TensorFlow 中。Keras 的设计理念是简单、快速实验和模块化，使深度学习模型的构建变得轻松而愉快。Keras 提供了用户友好的接口，可以在 TensorFlow、Theano 和 Microsoft Cognitive Toolkit (CNTK) 等深度学习后端上运行。

模拟器设计

抽象地说，我们需要构建的内容很明确。我们需要一种方法来模拟 Agent 的用户监听会话。给定一个模拟用户和一些内容，实例化一个侦听会话，并让 Agent 在该会话中驱动推荐。允许模拟用户对这些建议 “做出反应”，并让 Agent 根据此结果调整其策略，以推动一些预期的累积奖励。

TensorFlow Agents 环境设计指导我们开发系统的模块化组件，每个组件负责整个模拟的不同部分。

在我们的代码库中，我们定义了一个环境抽象，它要求为每个具体实例定义以下内容：

class AbstractEnvironment(ABC):
    _user_model: AbstractUserModel = None
    _track_sampler: AbstractTrackSampler = None
    _episode_tracker: EpisodeTracker = None
    _episode_sampler: AbstractEpisodeSampler = None

    @abstractmethod
    def reset(self) -> List[float]:
      pass

    @abstractmethod
    def step(self, action: float) -> (List[float], float, bool):
      pass

    def observation_space(self) -> Dict:
      pass

    @abstractmethod
    def action_space(self) -> Dict:
      pass

设置

在代理训练开始时，我们需要实例化一个模拟环境，该环境包含假设用户的表示以及我们希望向他们推荐的内容。我们基于真实和假设的 Spotify 收听体验来实例化。定义这些实例化的关键信息通过传递到环境。如前所述，我们还需要为模拟器提供经过训练的用户模型，在本例中为。_episode_sampler_user_model

动作和观察

就像任何代理环境一样，我们的模拟器要求我们指定和。在我们的例子中，作可能是连续的或离散的，这取决于我们的 Agent 选择以及我们打算如何将 Agent 的动作转化为实际建议。我们通常建议从潜在项目池中提取的有序项目列表。直接制定这个动作空间会导致它在组合上变得复杂。我们还假设用户将与多个项目交互，因此之前在此领域依赖于单选假设的工作不适用。action_specobservation_spec

在没有由项目集合组成的离散作空间的情况下，我们需要为模拟器提供一种方法，用于将 Agent 的作转换为实际的推荐。此 logic 包含在 via 中。剧集采样器建议的 “示例播放模式” 包含有关可以呈现给模拟用户的项目的信息。Track Sampler 使用这些和代理的作，并返回实际的项目推荐。_track_sampler

终止和重置

我们还需要处理剧集终止动态。在我们的模拟器中，重置规则由模型生成器设置，并基于对与特定音乐聆听体验相关的交互数据的实证调查。作为假设，我们可以确定 92% 的监听会话在 6 次连续的轨道跳跃后终止，我们将构建我们的模拟终止逻辑来匹配。它还要求我们在模拟器中设计抽象，允许我们检查是否应该在每个步骤后终止该剧集。

重置剧集后，模拟器将对新的假设用户侦听会话对进行采样，并开始下一集。

剧集步骤

与标准 TF 代理环境一样，我们需要为模拟定义步骤动力学。我们有可选的模拟动力学，我们需要确保在每一步都强制执行。例如，我们可能希望同一商品不能多次推荐。如果 Agent 的作指示对之前推荐的项目的推荐，我们需要构建功能，以根据此作选择下一个最佳项目。

我们还需要在每个步骤中根据需要调用上面提到的终止（和其他支持函数）。

剧集存储和重播

到目前为止，提到的功能共同创建了一个非常复杂的仿真设置。虽然 TF 代理重放缓冲区为我们提供了存储用于代理训练和评估的剧集所需的功能，但我们很快意识到需要能够存储更多剧集数据以进行调试，以及特定于我们的模拟的更详细的评估，这与标准 Agent 性能测量不同。

因此，我们允许包含一个扩展版，它将存储有关用户模型预测的其他信息、记录采样用户/内容对的信息等。_episode_tracker

创建 TF-Agent 环境

我们的环境抽象为我们提供了一个与标准 TF-Agents Environment 类匹配的模板。在我们实际创建具体的 TF-Agents 环境实例之前，需要解决环境的一些输入。这分三个步骤进行。

首先，我们定义一个符合我们抽象的特定仿真环境。例如：

class PlaylistEnvironment(AbstractEnvironment):
    def __init__(
        self,
        user_model: AbstractUserModel,
        track_sampler: AbstractTrackSampler,
        episode_tracker: EpisodeTracker,
        episode_sampler: AbstractEpisodeSampler,
	 ....
    ):

接下来，我们使用一个环境构建器类，该类将用户模型、轨道采样器等作为输入，以及一个环境类（如 .构建器将创建此环境的具体实例：PlaylistEnvironment

self.playlist_env: PlaylistEnvironment = environment_ctor(
            user_model=user_model,
            track_sampler=track_sampler,
            episode_tracker=episode_tracker,
            episode_sampler=self._eps_sampler,
        )

最后，我们利用一个 conversion 类，它从我们的具体实例构造一个 TF-Agents Environment：

class TFAgtPyEnvironment(py_environment.PyEnvironment):
      def __init__(self, environment: AbstractEnvironment):
          super().__init__()
          self.env = environment

然后，这将在我们的 Environment Builder 内部执行：

class EnvironmentBuilder(AbstractEnvironmentBuilder):

      def __init__(self, ...):
          ...

      def get_tf_env(self):
          ...
          tf_env: TFAgtPyEnvironment = TFAgtPyEnvironment(
              self.playlist_env
              )
          return tf_env

然后，生成的 TensorFlow Agents 环境可用于 Agent 训练。

这种模拟器设计使我们能够根据需要轻松创建和管理具有各种不同配置的多个环境。

接下来，我们将讨论如何使用模拟器训练 RL 代理生成播放列表。

用于播放列表生成的自定义代理

如前所述，强化学习为我们提供了一套自然适应音乐听序性的方法集;使我们能够随着会话的进行而适应用户不断变化的偏好。

我们可以尝试使用 RL 来解决的一个具体问题是自动音乐播放列表生成问题。给定一组（大量）曲目，我们希望了解如何创建一个最佳播放列表来推荐给用户，以便最大限度地提高满意度指标。我们的用例与标准 slate 推荐任务不同，在标准 slate 推荐任务中，目标通常是在序列中最多选择一个项目。在我们的示例中，我们假设我们有针对 Slate 中多个项目的用户生成的响应，这使得 Slate 推荐系统不直接适用。另一个复杂之处在于，从中得出建议的轨道集在不断变化。

我们设计了一个能够处理这些约束的 DQN 变体，我们称之为 Action Head DQN （AHDQN）。