ASE —— 第一次结对作业

秒速五厘米 2023-08-17 16:15 58阅读 0赞

# 问题定义 #

--------------------

**游戏规则：**

N个玩家，每人写一个或两个0~100之间的有理数 (不包括0或100)，提交给服务器，服务器在当前回合结束时算出所有数字的平均值，然后乘以0.618，得到G值。 提交的数字最靠近G（取绝对值）的玩家得到N分，离G最远的玩家得到－2分，其他玩家得0分。 只有一个玩家参与时不得分。

我们的比赛中，每个玩家在每个回合提交两个数，最后的得分也即两个数字分别的得分之和。

**难点分析：**

这个游戏的难点在于他是一个多人决策游戏，如果采用强化学习作为策略，它的state和action都不是那么好去定义，而且很难去直接的判断定义的优劣，即使是在某一场游戏中表现的很好，也很难直接地认为是由于state和action定义的好。再一个就是它也很难像其他游戏那样可以预先去训练好一个通用的模型，因为每次一起参与游戏的玩家都不一样，很难有一个通用的model去应对所有的情况。

# **方法建模** #

--------------------

在选择方法上面，我们选择了DQN（深度强化学习）来作为我们的策略，选择DQN的原因一个就是之前提到的state定义的问题，传统的Q Learning需要定义若干个离散的state，而DQN则可以将连续的state作为输入，还有一个原因也是我们两个之前接触这方面不多，也想通过这次机会对DQN有个更深入的了解。

DQN的伪代码和算法流程如下所示：

![1342010-20190922160846553-2042720517.png][]

![1342010-20190922155234088-749274.png][]

简单来说，就是输入state到定义的网络Q中，得到n个输出，n为定义的action的数目，每个输出代表了该action的一个得分（reward）。而通过游戏中实际选择的action和执行action后得到的next state，可以计算出该action对应的一个target reward，用这个target就可以更新网络参数，其实也就类似于Q Table的一个学习过程，只不过state连续化了。还一个不同就是DQN会存放一个记忆单元，每次从中采样出若干个样本来作为一个batch更新网络，而不仅仅是使用最近的这一次的数据。

在我们的这次任务中，state（即图中的s）为倒数十个黄金点组成的一维向量，而action（即图中的a）为提供的RLDemo里前7个action两两组合再加上第8个action，所以总共有22个action，每个action产生两个不一样的数。我们的实验中采用的网络模型比较简单，为三层的全连接网络，具体网络定义如下：

class DQN(nn.Module):
    
        def __init__(self, state_size, action_size, mid_dim=128):
            super().__init__()
            self.net = nn.Sequential(
                nn.Linear(state_size, mid_dim),
                nn.ReLU(inplace=True),
                nn.Linear(mid_dim, mid_dim),
                nn.ReLU(inplace=True),
                nn.Linear(mid_dim, action_size)
            )
    
        def forward(self, x):
            return self.net(x)

我们之前也尝试过了更复杂一些的网络模型，如LSTM等，但似乎在我们自己测试的时候效果表现的并不好。由于也不确定更复杂的其他网络模型效果会不会更好，所以还是先采用了简单的网络结构。

在实验测试时，我们发现有一些固定策略的Bot会表现的特别好，于是我们后来有在代码里增加了一个策略比较简单的Bot，然后根据每个Bot历史得分情况，按照概率去选择，有些类似于“集成学习”的思想。

# **结果分析** #

--------------------

在正式比赛前进行测试的时候，我们的Bot表现的其实非常好，当然也可能是测试的Bot中有许多类似于我们的action的简单Bot，以至于我们对最后的比赛还是比较有信心。

在第一轮的表现中，我们的Bot也能排到第三，而且领先其他组较多，因此第一轮后也没有对Bot进行调整。第二轮比赛中，我们的Bot则表现的有些可怜，一开始还能在中下游起起伏伏，到了后期直接变成倒数第一。分析原因，我们的state定义、action定义以及网络结构其实都并不是那么合理，但是由于测试时表现还不错，也就没有过多的去思考有没有更合理的方式。从比赛结果来看，我们的策略确实不够通用，可能只能再某一些特定的情况，才会有较好的表现。

如果每轮提交数字变为3个，我们的代码中action的定义需要做一些调整，因为每个action对应的数目还是固定的。

我的合作伙伴是一个代码能力非常强的人，我们大部分的代码是由他来完成具体编写的，我主要是在后期对代码进行了一些测试，以及完善了一些细节（包括概率选择部分代码等）。虽然比赛结果可能不是特别理想，但这次合作还是非常愉快的，也学到了不少东西。

转载于:https://www.cnblogs.com/hytu/p/11568003.html

[1342010-20190922160846553-2042720517.png]: /images/20230810/dcbc38c768a3415c8dba30cd79c33ce3.png
[1342010-20190922155234088-749274.png]: /images/20230810/272542f53fb34c05b8d2afe1641371d2.png