将贪婪策略与 DQN 策略进行比较时出现意外结果

人工智能 强化学习 深度学习
2021-10-24 11:14:37

我正在尝试解决 Sutton 的强化学习书 [1] 第 10 章中提出的访问控制队列任务问题的变体。

我的设置的具体细节如下:

  • 我有不同类型的任务到达系统(重/中/轻,需要更多时间处理的繁重任务。)。具体的任务类型是统一随机选择的。任务到达间隔时间为0.1s一般。
  • 我有不同类别的服务器可以处理这些任务(低容量;中等容量;高容量;高容量服务器具有更快的处理时间)。当我从给定类中选择特定服务器时,它在分配给它的任务的处理时间内变得不可用。请注意,服务器集(以及因此每个类的服务器数量)不是固定的,而是根据用于对服务器集建模的数据集定期更改(因此特定服务器可能会消失,而新的服务器可能会出现) ,而不是由分配引起的不可用)。每个类的最大服务器数为10.
  • 我的目标是决定哪类服务器应该处理给定的任务,以最小化所有任务的处理时间总和。

具体的强化学习公式如下:

  • 状态:任务类型(重/中/轻);可用的低容量服务器的数量;可用的中等容量服务器的数量;可用大容量服务器的数量
  • 动作(1)将任务分配给低容量服务器(2)将任务分配给中等容量服务器(3)将任务分配给高容量服务器(4)处理时间比服务器更差的虚拟动作容量低。当没有空闲服务器时选择它。
  • 奖励:与处理时间相反,处理时间如下(以秒为单位):

| | 慢速服务器 | 中型服务器 | 快速服务器 | “假动作” |
|---------------|----------------|---------------|--- ----------|----------------|
| 轻任务 | 0.5 | 0.25 | 0.166 | 0.625 |
| 中等任务 | 1.5 | 0.75 | 0.5 | 1.875 |
| 繁重的任务 | 2.5 | 1.25 | 0.833 | 3.125 |

我将问题表述为 RL 问题的直觉是“即使将轻量级任务分配给高容量服务器(即贪婪)可能会在短期内导致高回报,但它可能会减少可用的高容量服务器的数量。重任务来了。因此,繁重的任务将不得不由容量较低的服务器处理,这将减少累积的奖励。

然而,当我实现这个(特别是使用深度 Q 网络[2])并将其与贪婪策略进行比较时,我发现两种方法都获得了相同的奖励。事实上,深度 Q 网络最终会学习贪心策略。

我想知道为什么会发生这种行为,尤其是我希望 DQN 方法能够比贪婪的方法学习更好的策略。这可能与我的 RL 问题表述有关吗?或者说不需要强化学习来解决这个问题?

[1]Sutton, RS 和 Barto, AG (1998)。强化学习简介(第 135 卷)。剑桥:麻省理工学院出版社。

[2]Mnih, V., Kavukcuoglu, K., Silver, D., Rusu, AA, Veness, J., Bellemare, MG, ... & Petersen, S. (2015)。通过深度强化学习进行人工控制。自然,518(7540),529-533.f

1个回答

您的问题似乎源于非马尔可夫状态描述。简而言之,代理无法得知“繁重的工作将使服务器更长时间不可用”,并且每 10 步的任意状态转换进一步加剧了这种情况,而代理无法跟踪时间。

看看 Sutton & Barto 的例子,你应该注意到他们小心翼翼地为一个有效的 MDP 建模。服务器在每个时间步随机变为可用,并且没有隐藏状态。在您的情况下,您拥有三个系统地影响状态演变的隐藏数据来源。如果代理有一些关于这些的数据,那么它可能能够更好地优化选择:

  1. 由于代理分配的任务而使用的服务器在分配它们的操作之后确定性地返回 n 步。代理无法跟踪这可能是您最大的问题 - RL 中没有数据流允许代理将较重的作业或较慢的服务器与使服务器更长时间不可用相关联,因此它永远不会“看到”冲突您希望它解决的资源管理问题。

  2. 每 10 个时间步都会对服务器可用性进行任意更改。这是一个问题,因为它完全可以预测它可能发生在哪个时间步长上,但代理不知道当前时间步长。

  3. 您是从数据集中驱动它,而不是随机驱动,因此对它的影响将取决于数据集如何随着时间的推移而变化。一个特别糟糕的情况是,如果数据集代表“工作日”,那么当可用性遵循不同的模式时,会有明确的时区。代理在状态中没有数据输入以关联使用模式(例如一天中的时间),因此环境要么成为在线学习问题(代理必须不断学习并适应新模式的出现),要么它必须提出一种策略,该策略在所有可能的模式中均能发挥作用。

此外,我可以看到一个可能的次要影响,即模拟中的“利用”,这可能会产生明显的影响,具体取决于特定服务器退出池的频率。如果代理将任务分配给服务器,您将无法在服务器退出时取消分配该任务。因此,一个贪婪地分配给最佳可用服务器的激进代理将在高容量服务器上获得额外的“空闲”时间,如果它总是声称它们。由于代理不知道何时可能发生退出,因此这种效果与保持服务器可用以防繁重任务到达的平均值相竞争。

如何解决?这取决于您的要求修复了多少模拟。您可以调整模拟以匹配当前状态表示,也可以更改状态表示以从模拟中捕获更多系统数据。

可能最简单的状态更改是扩展服务器列表以始终包括所有服务器,并且为每个不可用的服务器有一个“代码”来显示它可用之前的时间步长。为了使问题更小,您可能只跟踪 1-10 个滴答声并具有 (>10) 的组合状态,因为这将暴露足够多的关键状态信息,代理可以决定将简单任务推向中等或低容量服务器。如果服务器确实可以互换,则不需要对级别服务器 ID 执行此操作。因此,不是按类型排列的空闲服务器数量的数组,而是将其扩展为一个表,其中包含按类型划分的空闲服务器数量,然后是按类型排列的服务器数量列,剩余 0.1 秒,直到它们空闲为止,然后仍然有 0 的服务器的列。