就这几天的事：Google已经开始用强化学习技术来设计芯片了！
如果说用强化学习来玩游戏、下围棋，甚至用来帮助提升互联网广告的点击率、收入，都不是什么新鲜事的话，那么用强化学习来设计芯片，就也太新鲜了吧？但Google就做到了^[1]：

我们提出了一种基于学习的芯片布局方法，这是芯片设计过程中最复杂、最耗时的阶段之一。与之前的方法不同，我们的方法具有从过去的经验中学习并随着时间的推移而改进的能力。特别是随着我们对更多的芯片块进行训练，我们的方法在快速生成以前未见过的芯片块的优化布局方面变得更好。为了实现这些结果，我们将芯片布局作为一个强化学习（RL）问题，并训练一个Agent将芯片网表的节点放置到芯片画布上。为了使我们的RL策略能够泛化到未见过的芯片块，我们将表征学习置于预测布局质量的有监督任务中。通过设计一个能够准确预测各种网表及其布局质量的神经架构，我们能够生成丰富的输入网表的特征嵌入。然后，我们使用这个架构作为我们的策略和价值网络的编码器来实现转移学习。我们的目标是将PPA（功率、性能和面积）降到最低，我们表明，在6个小时内，我们的方法可以在现代加速器网表上生成超越人类或可与之相媲美的芯片布局，而现有的基线需要人类专家在循环中进行，并需要几周的时间。

硬件工程师为之虎躯一颤。

这是我今年看到的第二个跟我多少有点关系，并且又让我马上喊出一句“卧槽”的技术应用了。
文章来源：https://www.codelast.com/
在机器学习领域，强化学习可能是目前人类发明的、最接近人类成长过程的机器学习范式了。从婴儿的咿呀学步，到掌握海量知识，人都是在不断接受外界反馈中对自我行为做出修正，而强化学习正是模仿了这一过程。
目前科学家们正在不断拓展强化学习的应用边界，从一开始的相对简单领域，到越来越复杂的工作，都尝试用强化学习来完成。
事实上，在现实世界，真正比较大规模的、普通人摸得着看得见的强化学习应用，还是当属游戏领域的AI玩家，但考虑到游戏受众占总人口数的比例很小，所以客观地说，强化学习并没有像人脸识别、语音识别等机器学习技术一样渗透到民生的方方面面。不过，由于强化学习的可预见潜力很大，我们有理由相信，它会在很多领域代替人类的工作，而这些工作，不是低水平的重复工作，而是需要较高知识储备才能胜任的。
文章来源：https://www.codelast.com/

还是Google，在今年1月的时候发布了一个聊天机器人：Meena^[2]（“米娜”？）。当然，说是发布，其实并没有公开地提供这个服务，也没有App提供下载，Google只是发了篇论文说他们达到了什么样的技术成果。
这个Meena有多牛呢？
举个大家生活中随处可见的例子：无论你是在京东淘宝上购物的时候在线咨询，还是在打各种客服电话的时候接线的是个“机器人”，可能都会很容易遇到这样一种情况：只要问题问得不是那么直接，那些“聊天机器人”就不知道怎么回答了。
再比如，我家里有一个“小爱同学”（小米的智能音箱），我问她“明天的天气怎么样”，她能完美回答我；但如果我用和人类随意聊天的方式来和她对话，她马上就会进入懵逼状态：“哎呀，你说的这个问题小爱不懂”。
理想和现实的差距，就是人类和市面上所有聊天机器人的差距。
而Google的Meena是一个“开放领域聊天机器人”。开放领域聊天机器人不会仅限于在某个特定领域，而是能够和用户聊近乎所有的话题——这不就是人类的正常表现嘛。
文章来源：https://www.codelast.com/

Meena是一个有着26亿参数的端到端神经对话模型，也就是GPT-2模型最大版本（15 亿参数）的1.7倍。通过实验可以看到，Meena 比现有的 SOTA 聊天机器人能够更好地完成对话，对话内容显得更为具体、清楚。

Google也给出了一些实例，用来说明Meena与人类的对话有多自然。
如果Meena真能达到真人水平，那她一定是我做梦都想拥有的一个chatbot。
我现在每周都在Cambly上和外国人聊天练口语，我当然想把这钱省下来，我曾经也找过英语的chatbot，但没有什么好的结果，在语言学习方面，和人类交流目前还是具有不可替代性。我可以和外国人聊新冠疫情的近况，聊时事政治的发展，但是我和一个chatbot讲这些，它可能当我是傻子（其实它才是傻子）。
所以，如果有一个像Meena那样的chatbot可以和我在开放领域以人类水平用英语聊天，那我真要笑开了花！
文章来源：https://www.codelast.com/

随着技术的发展，在我有生之年，我一定会看到很多本来“不可替代”的人类，会因为技术的发展而失业，这当中，或许就包含了我这样的工程师。而技术的目标之一就是节省更大的成本，我也相信在未来几十年，AI在语言学习上一定可以代替人类，和学生进行几乎无障碍的交流对话。
文章来源：https://www.codelast.com/

[1] https://ai.googleblog.com/2020/04/chip-design-with-deep-reinforcement.html
[2] https://ai.googleblog.com/2020/01/towards-conversational-agent-that-can.html

文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 本文是上一篇文章的续文，继续分析CpuSampler的源码。
本文将分析 CPU并行模式下的 ParallelSamplerBase 类的worker实现。

 worker的代码在哪
rlpyt/samplers/parallel/worker.py

 worker是做什么用的
用于采样agent与environment交互得到的数据。
文章来源：https://www.codelast.com/
 代码分析
我直接在代码里加了大量注释：

def initialize_worker(rank, seed=None, cpu=None, torch_threads=None):
    """
    初始化采样用的worker。

    :param rank: 采样进程的标识序号。
    :param seed: 种子，一个整数值。
    :param cpu: CPU序号，例如 0, 1, 2 等等。
    :param torch_threads: CPU并发执行的线程数。
    """
    log_str = f"Sampler rank {rank} initialized"
    cpu = [cpu] if isinstance(cpu, int) else cpu
    p = psutil.Process()
    try:
        if cpu is not None:
            p.cpu_affinity(cpu)  # 设置CPU亲和性(MacOS不支持)
        cpu_affin = p.cpu_affinity()
    except AttributeError:
        cpu_affin = "UNAVAILABLE MacOS"
    log_str += f", CPU affinity {cpu_affin}"
    torch_threads = (1 if torch_threads is None and cpu is not None else
        torch_threads)  # Default to 1 to avoid possible MKL hang.
    if torch_threads is not None:
        torch.set_num_threads(torch_threads)  # 设置CPU并发执行的线程数
    log_str += f", Torch threads {torch.get_num_threads()}"
    if seed is not None:
        set_seed(seed)
        time.sleep(0.3)  # (so the printing from set_seed is not intermixed)
        log_str += f", Seed {seed}"
    logger.log(log_str)


def sampling_process(common_kwargs, worker_kwargs):
    """
    Arguments fed from the Sampler class in master process.

    采样进程函数。

    :param common_kwargs: 各个worker通用的参数列表。
    :param worker_kwargs: 各个worker可能不同的参数列表。
    """
    c, w = AttrDict(**common_kwargs), AttrDict(**worker_kwargs)
    initialize_worker(w.rank, w.seed, w.cpus, c.torch_threads)
    # 初始化用于training的environment实例和collector实例
    envs = [c.EnvCls(**c.env_kwargs) for _ in range(w.n_envs)]
    collector = c.CollectorCls(
        rank=w.rank,
        envs=envs,
        samples_np=w.samples_np,
        batch_T=c.batch_T,
        TrajInfoCls=c.TrajInfoCls,
        agent=c.get("agent", None),  # Optional depending on parallel setup.
        sync=w.get("sync", None),
        step_buffer_np=w.get("step_buffer_np", None),
        global_B=c.get("global_B", 1),
        env_ranks=w.get("env_ranks", None),
    )
    agent_inputs, traj_infos = collector.start_envs(c.max_decorrelation_steps)  # 这里会做收集(采样)第一批数据的工作
    collector.start_agent()  # collector的初始化

    # 初始化用于evaluation的environment实例和collector实例
    if c.get("eval_n_envs", 0) > 0:
        eval_envs = [c.EnvCls(**c.eval_env_kwargs) for _ in range(c.eval_n_envs)]
        eval_collector = c.eval_CollectorCls(
            rank=w.rank,
            envs=eval_envs,
            TrajInfoCls=c.TrajInfoCls,
            traj_infos_queue=c.eval_traj_infos_queue,
            max_T=c.eval_max_T,
            agent=c.get("agent", None),
            sync=w.get("sync", None),
            step_buffer_np=w.get("eval_step_buffer_np", None),
        )
    else:
        eval_envs = list()

    ctrl = c.ctrl  # 用于控制多个worker进程同时运行时能正确运作的控制器
    ctrl.barrier_out.wait()  # 每个worker都有一个wait()，加上ParallelSamplerBase.initialize()中的一个wait()，刚好n_worker+1个
    while True:
        collector.reset_if_needed(agent_inputs)  # Outside barrier?
        ctrl.barrier_in.wait()
        if ctrl.quit.value:  # 在主进程中set了这个值为True时，所有worker进程会退出采样
            break
        if ctrl.do_eval.value:  # 在主进程的evaluate_agent()函数里set了这个值为True时，这里才会收集evaluation用的数据
            eval_collector.collect_evaluation(ctrl.itr.value)  # Traj_infos to queue inside.
        else:  # 不是做evaluation
            agent_inputs, traj_infos, completed_infos = collector.collect_batch(
                agent_inputs, traj_infos, ctrl.itr.value)
            for info in completed_infos:
                c.traj_infos_queue.put(info)  # 向所有worker进程共享的队列塞入当前worker的统计数据
        ctrl.barrier_out.wait()

    # 清理environment
    for env in envs + eval_envs:
        env.close()

文章来源：https://www.codelast.com/
在worker的代码中，比较绕的就是，worker是怎么把采样到的数据返回放到replay buffer里的？
在上一篇文章中，我们知道 ParallelSamplerBase.initialize() 函数初始化了replay buffer：

examples = self._build_buffers(env, bootstrap_value)

以及：

def _build_buffers(self, env, bootstrap_value):
    self.samples_pyt, self.samples_np, examples = build_samples_buffer(
        self.agent, env, self.batch_spec, bootstrap_value,
        agent_shared=True, env_shared=True, subprocess=True)
    return examples

在这里，self.samples_np 对应的是replay buffer的存储对象。而 worker 的参数 workers_kwargs 初始化的时候，会把 self.samples_np 拆分成多个slice，并传入 worker：

samples_np=self.samples_np[:, slice_B],

在 worker 中，构造 collector 对象的时候，会把这个传入的 samples_np 再传给 collector 的构造函数。这样，replay buffer 就与 collector 关联起来了。
最后，在 collector.collect_batch() 的时候，会把采样得到的数据放入 samples_np 中，也就是相当于放到了 replay buffer 里。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 本文是上一篇文章的续文，继续分析CpuSampler的源码。
我们已经知道了CpuSampler有两个父类：BaseSampler 和 ParallelSamplerBase。其中，BaseSampler主要是定义了一堆接口，没什么好说的，因此本文接着分析另一个父类 ParallelSamplerBase。在 ParallelSamplerBase 中，初始化函数 initialize() 做了很多重要的工作，已经够写一篇长长的文章来分析了，这正是本文的主要内容。

 初始化函数 initialize() 做了哪些重要工作
一句话总结 initialize() 的重要功能：计算一些特殊参数的值，初始化agent，创建并行控制器，创建并启动多个worker进程。
这里说的“并行控制器”(parallel ctrl)是指用Python multiprocessing模块来实现并行功能的时候，需要使用一些变量来协调各个并行的进程，使它们可以正确运作。这些用于协调的变量就是“并行控制器”。

 计算特殊参数的值
在并行模式下，有些参数（比如采样用的worker的数量）不是由用户直接设置的，而是计算出来的。而且这样的参数还挺多，所以有大段大段的代码都用来干这事了。
如果下面的代码没有注释的话，肯定会让人一头雾水：

n_envs_list = self._get_n_envs_list(affinity=affinity)  # 用户设置的worker数不一定与environment数相匹配，这里会重新调整
self.n_worker = n_worker = len(n_envs_list)  # 经过调整之后的worker数
B = self.batch_spec.B  # environment实例的数量
global_B = B * world_size  # "平行宇宙"概念下的environment实例的数量
env_ranks = list(range(rank * B, (rank + 1) * B))  # 含义可参考：https://www.codelast.com/?p=10932
self.world_size = world_size
self.rank = rank

if self.eval_n_envs > 0:  # 在example_*.py中传入的参数
    self.eval_n_envs_per = max(1, self.eval_n_envs // n_worker)  # 计算每个worker至少承载几个evaluation的environment(至少1)
    self.eval_n_envs = eval_n_envs = self.eval_n_envs_per * n_worker  # 保证至少有"worker数量"个eval environment实例
    logger.log(f"Total parallel evaluation envs: {eval_n_envs}.")
    self.eval_max_T = eval_max_T = int(self.eval_max_steps // eval_n_envs)

最为“神奇”的就是 self._get_n_envs_list() 这个函数，它用来计算每个worker承载几个environment实例。这个说法是不是特别奇怪？原因是：用户可以指定environment实例的数量，也可以指定worker的数量，但这两个数量可能是不相等的，于是，要么worker数不够，要么worker数有多；在第1种情况下，一个worker需要带>1个environment实例，在第2种情况下，不需要那么多worker，所以要减少worker的数量，才能保证一个worker刚好带一个environment实例。
文章来源：https://www.codelast.com/
我给 self._get_n_envs_list() 函数加上了注释，相信足以让大家理解它的功能了：

def _get_n_envs_list(self, affinity=None, n_worker=None, B=None):
    """
    根据environment实例的数量(所谓的"B")，以及用户设定的用于采样的worker的数量(n_worker)，来计算得到一个list，这个list的元素的总数，
    就是最终的worker的数量；而这个list里的每个元素的值，分别是每个worker承载的environment实例的数量。

    :param affinity: 一个字典(dict)，包含硬件亲和性定义。
    :param n_worker: 用户设定的用于采样的worker的数量。
    :param B: environment实例的数量。
    :return 一个list，其含义如上所述。
    """
    B = self.batch_spec.B if B is None else B  # 参考BatchSpec类，可以认为B是environment实例的数量
    n_worker = len(affinity["workers_cpus"]) if n_worker is None else n_worker  # worker的数量(不超过物理CPU数否则在别处报错)
    """
    当environment实例的数量<worker的数量时，例如有8个worker(即8个物理CPU)，5个environment实例，每一个物理CPU运行一个environment，
    那么此时会有3个物理CPU多余，此时就会把worker的数量设置成和environment实例数量一样，使得每个CPU都刚好运行一个environment实例。
    """
    if B < n_worker:
        logger.log(f"WARNING: requested fewer envs ({B}) than available worker "
            f"processes ({n_worker}). Using fewer workers (but maybe better to "
            "increase sampler's `batch_B`.")
        n_worker = B
    n_envs_list = [B // n_worker] * n_worker
    """
    当environment实例的数量不是worker数量的整数倍时，每个worker被分配到的environment实例的数量是不均等的。
    """
    if not B % n_worker == 0:
        logger.log("WARNING: unequal number of envs per process, from "
            f"batch_B {self.batch_spec.B} and n_worker {n_worker} "
            "(possible suboptimal speed).")
        for b in range(B % n_worker):
            n_envs_list[b] += 1
    return n_envs_list

文章来源：https://www.codelast.com/
 初始化agent
agent对象只有一个！并不是每一个worker进程都对应到不同的agent对象！这是理解CpuSampler时需要知晓的一个重要概念。
agent通过以下代码初始化（ParallelSamplerBase.initialize() 函数）：

env = self.EnvCls(**self.env_kwargs)
self._agent_init(agent, env, global_B=global_B,
    env_ranks=env_ranks)
examples = self._build_buffers(env, bootstrap_value)
env.close()
del env

可以看到，这里初始化了environment对象，并把它作为一个参数传给了agent初始化函数 self._agent_init()，事实上，在 self._agent_init() 函数里，只用到了 env 对象的 spaces 这个属性，而没有引用整个 env 对象，因此在使用完之后，使用 env.close() 以及 del env 来清理掉env不会有问题。
self._build_buffers() 是一个非常复杂的操作，它的主要功能是创建强化学习中必备的replay buffer。直觉上，有人可能认为replay buffer这个东西，不就是创建一个list或者类似的数据结构就能搞定的吗？但实际上不是这么简单，从这个函数一级级点进去就会发现代码还不少，而且它里面甚至还用到了Python multiprocessing，所以创建replay buffer的实现就不在本文分析了。
文章来源：https://www.codelast.com/
self._agent_init() 函数的实现很简单：

def _agent_init(self, agent, env, global_B=1, env_ranks=None):
    agent.initialize(env.spaces, share_memory=True,
        global_B=global_B, env_ranks=env_ranks)
    self.agent = agent

在这里看到：agent初始化之后，赋值给了 self.agent，这就是 CpuSampler 中唯一使用的 agent 对象。
文章来源：https://www.codelast.com/
 创建并行控制器
并行控制器(parallel ctrl)用于协调多个采样用的worker进程。
在 initialize() 里，创建并行控制器的代码只有一句：

def _build_parallel_ctrl(self, n_worker):
    """
    创建用于控制并行训练过程的一些数据结构。

    multiprocessing.RawValue：不存在lock的多进程间共享值。
    multiprocessing.Barrier：一种简单的同步原语，用于固定数目的进程相互等待。当所有进程都调用wait以后，所有进程会同时开始执行。
    multiprocessing.Queue：用于多进程间数据传递的消息队列。

    :param n_worker: 真正的worker数(不一定等于用户设置的那个原始值)。
    """
    self.ctrl = AttrDict(
        quit=mp.RawValue(ctypes.c_bool, False),
        barrier_in=mp.Barrier(n_worker + 1),
        barrier_out=mp.Barrier(n_worker + 1),
        do_eval=mp.RawValue(ctypes.c_bool, False),
        itr=mp.RawValue(ctypes.c_long, 0),
    )
    self.traj_infos_queue = mp.Queue()
    self.eval_traj_infos_queue = mp.Queue()
    self.sync = AttrDict(stop_eval=mp.RawValue(ctypes.c_bool, False))

这里AttrDict是一个“扩展的”dict，mp就是Python multiprocessing模块，而Python multiprocessing是一个巨大的话题，我自己也只是初步了解，所以没办法讲透彻，这里只举两个例子，来说明这些并行控制器的作用：
 ctrl.quit 可以理解为一个bool类型的进程间共享变量。在 minibatch_rl.py 中，训练完成后，会执行 shutdown()，它会调用 sampler.shutdown()，从而会把 ctrl.quit 的值设置为True；同时，在 worker.py 中会看到，当检测到 ctrl.quit 的值为True时，会退出采样过程。所有采样的worker进程都受这个变量控制。所以这样就做到了在主进程中控制并行跑的worker进程。
 multiprocessing.Queue() 用于在多进程间传递消息。在每个采样的worker进程中，会把收集到的trajectory info放到同一个traj_infos_queue中，在主进程中会把汇总的trajectory info进一步处理成统计数据，然后记日志、打印到屏幕上，等等。
文章来源：https://www.codelast.com/
 创建并启动多个worker进程
worker进程用于采样(agent与environment交互得到的)数据。
在创建这些进程之前，需要先为它们构建所需的参数：

common_kwargs = self._assemble_common_kwargs(affinity, global_B)
workers_kwargs = self._assemble_workers_kwargs(affinity, seed, n_envs_list)

为什么需要分成 common_kwargs 以及 workers_kwargs 两个参数？这是因为：对每个worker进程来说，有些参数是通用的，有些参数是不通用的（例如，每个worker使用的CPU数量、承载的environment实例的数量等），因此，rlpyt把它们分成了两拨，分别放在两个对象里。

在准备好了参数之后，就开始创建多个worker进程，并把它们启动起来了：

# 创建一批子进程
target = sampling_process if worker_process is None else worker_process
self.workers = [mp.Process(target=target,
    kwargs=dict(common_kwargs=common_kwargs, worker_kwargs=w_kwargs))
    for w_kwargs in workers_kwargs]
# 启动子进程
for w in self.workers:
    w.start()

self.ctrl.barrier_out.wait()  # Wait for workers ready (e.g. decorrelate).

在这里，使用的是 multiprocessing.Process() 来创建的进程，target 为进程函数名，进程函数是可以自行指定的，rlpyt也提供了默认的实现，即 worker.py 中的 sampling_process() 函数。采样进程的实现代码 worker.py 虽然不长，但要完全看懂并不容易，所以留到后面的文章再分析。
在worker进程启动之后，它就进入了持续的采样过程。注意上面代码的最后一句 self.ctrl.barrier_out.wait()，这里使用了 multiprocessing的Barrier来控制各个worker进程同步。由于 barrier_out 创建的时候是这样的：

barrier_out=mp.Barrier(n_worker + 1)

所以，它需要 n_worker + 1 个 wait() 才能让所有进程同时“解锁”（即同时开始执行），在 initialize() 函数里的 self.ctrl.barrier_out.wait() 算一个，每个worker函数——即 sampling_process()——里也分别有一个 barrier_out.wait()，所有这些 wait() 加起来刚好是 n_worker + 1 个，这使得 initialize() 函数执行完，所有 worker 就会“跑起来”开始采样。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

查看关于 rlpyt 的更多文章请点击这里。

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 

在单机上支持丰富的并行(Parallelism)模式是 rlpyt 有别于很多其他强化学习框架的一个显著特征。rlpyt可以使用纯CPU，或CPU、GPU混合的方式来并行执行训练过程。

 rlpyt的sampler模块概览
rlpyt有一种叫做“Sampler”的模块，我们姑且称之为“采样器”，它用于采样/收集agent与environment交互的数据，对于不同的训练模式(串行、并行、异步)，rlpyt有不同的sampler实现：

├── async_

│   ├── action_server.py

│   ├── alternating_sampler.py

│   ├── base.py

│   ├── collectors.py

│   ├── cpu_sampler.py

│   ├── gpu_sampler.py

│   └── serial_sampler.py

├── base.py

├── buffer.py

├── collections.py

├── collectors.py

├── parallel

│   ├── base.py

│   ├── cpu

│   │   ├── collectors.py

│   │   └── sampler.py

│   ├── gpu

│   │   ├── action_server.py

│   │   ├── alternating_sampler.py

│   │   ├── collectors.py

│   │   └── sampler.py

│   └── worker.py

├── serial

│   ├── collectors.py

│   └── sampler.py

直观感受：串行(serial)模式的sampler代码最简单，并行(parallel)模式下的cpu并行实现比gpu并行实现简单一些，异步(async_)模式下的实现最复杂。
不知道会不会有人好奇：为什么异步模式的module名是带下划线的async_而不是async呢？因为async在Python 3里是一个关键字，rlpyt的作者应该是为了避开这个问题才加了一个下划线。
文章来源：https://www.codelast.com/
在前面的系列源码分析文章中，我已经分析过了串行(serial)模式下的sampler代码，本文想分析的是并行(parallel)模式下的CPU并行实现代码，也就是树形图里的这一部分：

├── cpu

│   ├── collectors.py

│   └── sampler.py

CPU sampler在采样/收集数据的时候，完全不使用GPU，因此相对于GPU sampler来说会简单得多（只是相对而言）。它只有两个代码文件。当然，由于这两个文件里的class会继承其他父类，因此最终有关联的代码文件远不止这两个。下面我们就来详细分析一下。
文章来源：https://www.codelast.com/
 CPU sampler概览
CPU sampler的实现类是 CpuSampler，一级级向上，有多个父类：

这个BaseSampler，同时也是 GpuSampler 的最顶级父类。
文章来源：https://www.codelast.com/
前面的文章已经讲过，sampler是collector外面包装的一层，真正去做数据收集工作的是collector类。对 CpuSampler 来说，它对应的collector代码实现在collectors.py中，里面包含多个collector类：CpuResetCollector，CpuWaitResetCollector，CpuEvalCollector等。
所以应该从两条线来分析sampler class，一条线是 CpuSampler→ParallelSamplerBase→BaseSampler，另一条线是collector class。为了不让篇幅过长，本文只分析第一条线，把collector class留到后面的文章。

 BaseSampler：一个主要用于定义各种接口的父类
最顶层的父类BaseSampler主要定义了各种接口，很多函数都没有实现：

def initialize(self, *args, **kwargs):
    raise NotImplementedError

def obtain_samples(self, itr):
    raise NotImplementedError  # type: Samples

def evaluate_agent(self, itr):
    raise NotImplementedError

def shutdown(self):
    pass

而__init__()函数还是像之前见识过的套路一样，使用save__init__args()来把可变参数保存到对象属性里：

save__init__args(locals())

其余就没啥好说的了。
文章来源：https://www.codelast.com/
 CpuSampler：主要充当一个入口
CpuSampler类的代码相当少，它主要充当一个入口，而不是实现主要逻辑：

class CpuSampler(ParallelSamplerBase):

    def __init__(self, *args, CollectorCls=CpuResetCollector,
            eval_CollectorCls=CpuEvalCollector, **kwargs):
        # e.g. or use CpuWaitResetCollector, etc...
        super().__init__(*args, CollectorCls=CollectorCls,
            eval_CollectorCls=eval_CollectorCls, **kwargs)

    def obtain_samples(self, itr):
        self.agent.sync_shared_memory()  # New weights in workers, if needed.
        return super().obtain_samples(itr)

    def evaluate_agent(self, itr):
        self.agent.sync_shared_memory()
        return super().evaluate_agent(itr)

其中，obtain_samples() 用于采样一批数据，evaluate_agent() 用于评估agent——或者说是评估模型，差不多的意思。
这两个函数都调用父类ParallelSamplerBase的同名函数来实现对应功能，后面会在其他文章里具体分析。
在这两个函数的开头，都有一个 self.agent.sync_shared_memory() 的操作，这是干嘛？
其功能是：在并行模式下，采样/评估之前先同步shared model。
sync_shared_memory() 函数的实现是：

def sync_shared_memory(self):
    if self.shared_model is not self.model:
        self.shared_model.load_state_dict(strip_ddp_state_dict(
            self.model.state_dict()))

这里的意思是：当 self.model 被训练过之后，可能已经和 self.shared_model 不是一个东西了，此时需要把 self.model 的参数copy到 self.shared_model 里。
strip_ddp_state_dict()函数是一个很tricky的操作，为什么从 self.model 取出来的 state_dict 不能直接用 load_state_dict() 加载到 self.shared_model 里呢？关于这一点，我觉得代码的注释里写得比较清楚，建议直接去看它。
这里就产生了两个问题：✓ 什么是shared model？ ✓ 为什么要同步shared model？
文章来源：https://www.codelast.com/
 什么是shared model
从名字上猜测，shared model就是一个“共享的模型”，之所以会有“共享”这个概念，是因为在多个进程中都需要使用模型，所以才需要“共享”。
rlpyt在并行(parallel)模式下，会产生多个“worker”跑在多个进程里，这些worker会各自在environment中采样，采样得到的数据用于优化模型。
 worker在采样的时候会选择action，此时会用模型来做action selection。
 所有worker关联到同一个agent对象(agent包含了策略网络的参数)，只有一个进程会去做优化模型(也就是反向传播之类)的工作，这一点要特别注意，是一个进程，而不是所有worker进程！
 在每个agent对象内部，会有一个类型为 torch.nn.Module 的 self.model 对象，还有一个 self.shared_model 对象，我们可以从agent的父类 BaseAgent 的__init__()函数中看到这一点：

def __init__(self, ModelCls=None, model_kwargs=None, initial_model_state_dict=None):
    save__init__args(locals())
    self.model = None  # type: torch.nn.Module
    self.shared_model = None

在agent对象初始化的时候，即在 BaseAgent.initialize() 函数中，会把 self.shared_model 初始化成和 self.model 一样：

def initialize(self, env_spaces, share_memory=False, **kwargs):
    """In this default setup, self.model is treated as the model needed
    for action selection, so it is the only one shared with workers."""
    self.env_model_kwargs = self.make_env_to_model_kwargs(env_spaces)
    self.model = self.ModelCls(**self.env_model_kwargs,
        **self.model_kwargs)
    if share_memory:
        self.model.share_memory()
        self.shared_model = self.model

上面代码中的 if share_memory 这个条件是否得到满足呢？
在并行模式下，也就是从 ParallelSamplerBase._agent_init() 函数的代码我们可以发现，agent初始化的时候 share_memory 参数被设置成了 True：

agent.initialize(env.spaces, share_memory=True,
    global_B=global_B, env_ranks=env_ranks)

所以 if share_memory 的条件是满足的。
文章来源：https://www.codelast.com/
如果使用GPU训练模型，那么rlpyt会把model挪到用户指定的设备上，而shared_model需要放在CPU上(经查，PyTorch的Tensor或模型参数也是可以放在GPU上共享的，但有一些容易出错、需要谨慎处理的细节，所以我猜由于这个原因，作者选择了把shared_model放在CPU上)，因此，这里创建出来了一个self.shared_model，用来防止之后self.model有可能被挪到GPU的情况发生——如果发生了，self.shared_model这个放在CPU上的模型才是多个进程间的共享模型。
那么这个shared_model在CpuSampler中真的有用吗？下面我们就一层层地挖下去，看看这个东西到底有没有用。
文章来源：https://www.codelast.com/
 为什么要同步shared model
先说结论：在CpuSampler里，完全不需要同步。
为了确认这个结论，我们看看在使用CPU sampler的时候，BaseAgent类里的 self.shared_model 到底用在了什么地方。通过搜索代码，发现除了 sync_shared_memory() 函数之外，只有两个地方在用：
1、上面提到的 BaseAgent.initialize() 函数。在这里，对 self.shared_model 只有赋值操作，没有使用。
2、to_device() 函数：

def to_device(self, cuda_idx=None):
    if cuda_idx is None:
        return
    if self.shared_model is not None:
        self.model = self.ModelCls(**self.env_model_kwargs,
            **self.model_kwargs)
        self.model.load_state_dict(self.shared_model.state_dict())
    self.device = torch.device("cuda", index=cuda_idx)
    self.model.to(self.device)

在这一段代码中，当使用CPU sampler时，cuda_idx 为 None，因此直接return了，self.shared_model 根本触达不到。
此外，BaseAgent的其他所有使用 self.shared_model 的地方，都是和异步(async_)模式相关的，和并行(parallel)模式无关。
因此，对CpuSampler来说，shared_model没用，不需要调用 sync_shared_memory() 来同步shared_model。
文章来源：https://www.codelast.com/
 shared model在什么情况下有意义
对CpuSampler来说，BaseAgent里的 self.model 对各个采样的worker来说都会实时更新，在action selection的时候使用的也是 self.model，而不是 self.shared_model，所以 shared_model 对CpuSampler来说其实没有意义。
但在其他模式下 shared model 还是有意义的，而且机制更复杂。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 如果你想用这个框架来开发自己的强化学习程序（尤其是那些不属于Atari游戏领域的强化学习程序），那么需要对它的源码有一定的了解。
本文简要分析一下在rlpyt中，强化学习模型的参数是在什么地方被更新、怎么被更新的。

 概述
模型参数是在Algorithm模块的optimize_agent()函数里被更新的，它在Runner类(例如 MinibatchRl)的train()函数里被调用。
文章来源：https://www.codelast.com/
 Runner类的调用
以MinibatchRl这个Runner类为例，它的 train() 函数中有这么一句：

opt_info = self.algo.optimize_agent(itr, samples)

其中，self.algo 就是一个Algorithm类的对象，这里的optimize_agent()函数会用采样得到的一批数据(samples)更新一次模型参数。
文章来源：https://www.codelast.com/
 Algorithm类更新模型参数的实现
在前文中提到了rlpyt有一个模块叫做Algorithm，它们位于项目的 rlpyt/algos/ 路径下：

├── base.py

├── dqn

│   ├── cat_dqn.py

│   ├── dqn.py

│   └── r2d1.py

├── pg

│   ├── a2c.py

│   ├── base.py

│   └── ppo.py

├── qpg

│   ├── ddpg.py

│   ├── sac.py

│   ├── sac_v.py

│   └── td3.py

└── utils.py

self.optimizer.zero_grad()  # 将所有参数的梯度都置零
loss, td_abs_errors = self.loss(samples_from_replay)
loss.backward()  # 误差反向传播计算参数梯度
grad_norm = torch.nn.utils.clip_grad_norm_(self.agent.parameters(), self.clip_grad_norm)
self.optimizer.step()  # 通过梯度做一步参数更新

self.optimizer = self.OptimCls(self.agent.parameters(),
    lr=self.learning_rate, **self.optim_kwargs)

def __init__(self, params, lr=1e-3, betas=(0.9, 0.999), eps=1e-8,
             weight_decay=0, amsgrad=False):

def parameters(self):
    """Parameters to be optimized (overwrite in subclass if multiple models)."""
    return self.model.parameters()

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 

在单机上全面的并行（Parallelism）特性是 rlpyt 有别于很多其他强化学习框架的一个显著特征。在前面的简介文章中，已经介绍了 rlpyt 支持多种场景下的并行训练。而这种“武功”是怎么修炼出来的呢？它是站在了巨人的肩膀上——通过PyTorch的多进程(multiprocessing)机制来实现的。
所以你知道为什么 rlpyt 不使用TensorFlow这样的框架来作为后端了吧，因为TensorFlow根本就没有这种功能。TensorFlow只能靠类似于Ray这样的并行计算框架的帮助，才能支撑起全方位的并行特性。

 为什么说TensorFlow自身的并行能力并不适用于强化学习场景
限于我掌握的知识，我不保证下面的结论都是正确的，请专家们不吝赐教。
相信很多刚开始学写强化学习程序的人，都是从莫凡的强化学习教程开始的，莫凡的强化学习教程使用的是TensorFlow来实现的（很久以前看到是这样，后来我没有再去关注过，不知道他有没有发布在其他ML框架下的RL教程）。
看过一部分莫凡RL代码的人都会知道，里面用TensorFlow实现的静态图多进程“并行”训练逻辑有多么晦涩（而且并行其实是伪并行，说到底还是串行）。
我个人认为，如果一个初学者从这样的程序入手，其实就相当于“劝退”，也就是说：这程序这么难写，你还是别学了吧。如果有与莫凡的RL代码逻辑对等的PyTorch代码，那绝对会是另一番景象。
文章来源：https://www.codelast.com/
有人会说，明明TensorFlow就支持并行训练的啊！现在很多模型不就是通过多机多卡分布式训练的吗？
然而到了强化学习场景下，就不是这么一回事了：强化学习和监督学习很不一样。在强化学习场景下，如果要并行训练的话，会需要多个agent，与多个environment交互，对应到程序就是多个进程/线程。与environment交互的过程，可以是纯CPU计算，也可以是CPU/GPU混合计算（例如，inference得到action的过程就可以放在GPU上加速），但这个过程不能是纯GPU计算的过程。以Atari游戏模拟器为例，调用ALE接口得到Atari环境的反馈，这个过程就是CPU计算的，不能在GPU上计算。整个强化学习的流程，数据就是这样不断地在CPU/GPU之间流转，当然你可以使用纯CPU，但假设你使用了GPU的话，也只能在一小部分工作中使用GPU，其实CPU的工作也很重。反观supervised learning，当你把数据预处理好了之后，就可以一次性地喂给GPU，GPU在单机单卡训练的时候，可以把结果全部算完了再吐回给CPU；就算是Distributed TensorFlow，也不适用于强化学习，因为Distributed TensorFlow的并行功能是为了并行地使用GPU对吧？但强化学习的采样过程是使用CPU，按我的理解这部分工作不能使用Distributed TensorFlow来并行，相反PyTorch有multiprocessing可以做到；而计算梯度之类的工作用Distributed TensorFlow就可以并行了——但别的DL框架例如PyTorch也可以啊。
所以Distributed TensorFlow在RL场景下有什么优势？没看出来。
关于TensorFlow在强化学习场景下的应用，莫凡当时也在知乎向网友提问如何能在TF下较好地实现强化学习的并行功能，结论大概就是：还是用PyTorch吧！
另外，知乎上有一个讨论，提问者对GPU并行训练DRL模型的并行过程提出了疑问。第一个回答里面说“采样过程可以并行”，但作者说的并不是指Distributed TensorFlow支持这个功能。
所以我认为，TensorFlow由于缺少了类似于PyTorch multiprocessing那样的模块，它只能借助于类似于Ray的并行计算框架，也就是在外面再“包装一层”，才能把TF对“全面的并行强化学习”的缺陷给修补上。
文章来源：https://www.codelast.com/
 PyTorch的多进程处理功能
参考这段话：

由于全局解释器锁（global interpreter lock，GIL）的 Python 默认实现不允许并行线程进行并行执行，所以为了解决该问题，Python 社区已经建立了一个标准的多进程处理模块，其中包含了大量的实用程序（utility），它们可以使得用户轻易地生成子进程并能够实现基础的进程间通信原语（communication primitive）。

 

然而，原语的实现使用了与磁盘上持久性（on-disk persistence）相同格式的序列化，这在处理大规模数组时效率不高。所以，PyTorch 将Python 的 multiprocessing 模块扩展为 torch.multiprocessing，这就替代了内置包，并且自动将发送至其他进程的张量数据移动至共享内存中，而不用再通过通信渠道发送。

 

PyTorch 的这一设计极大地提升了性能，并且弱化了进程隔离（process isolation），从而产生了更类似于普通线程程序的编程模型。

看看就好，想深入了解的话请移步PyTorch文档。
文章来源：https://www.codelast.com/
 rlpyt的并行(parallelism)功能的局限
rlpyt瞄准的是单机上的RL训练效率的极致优化，它不支持多机训练。在单机硬件资源允许的范围内，rlpyt可以让RL模型训练很快，但如果你的训练数据占用的资源远远超过了单机硬件的范围，那么就只能利用支持分布式训练的框架了，例如构建在Ray之上的框架RLlib，又例如基于PaddlePaddle的PARL等。
这里值得一提的是，PARL号称它与RLlib进行了IMPALA算法下的对比测试，其数据吞吐量（同等计算资源下的数据收集速度）足以吊打RLlib，所以PARL看起来是一个有前途的框架。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

Atari是强化学习领域最常用的一个游戏实验环境，在很多文章以及代码中，会看到frame skipping（跳帧）这个概念，那么它到底是指什么呢？

使用ALE接口来实现agent与Atari环境的交互时，Atari环境会返回游戏的每一帧图像作为observation，agent需要为这个observation选择一个action，再让Atari环境去执行这个action。
由于游戏是一个持续不断进行的过程，因此，为了减少运算量，一种叫做 frame skipping（跳帧）的技术被发明出来了，即，原来agent与environment的交互应该是这种画风：
Atari给出一帧图像→agent选择一个action→Atari执行该action给出下一帧图像→agent选择下一个action→（如此循环下去）
现在变成了这种画风：
Atari给出一帧图像→agent选择一个action→Atari执行该action给出下一帧图像→agent重复使用上次的action给Atari执行→Atari执行该action给出下一帧图像→agent重复使用上次的action给Atari执行→Atari执行该action给出下一帧图像→（如此重复N帧）→agent重新选择一个action→Atari执行该action给出下一帧图像→......
文章来源：https://www.codelast.com/
注意上面的重复部分，简单地说就是：每经过N帧，agent才会选择一次action，在接下来的N帧内，会重复使用之前最后一次选择的那个action。
为什么要这样做？因为action selection的过程是一个计算量较大的过程（想像成model的inference过程），而Atari环境向前走一步相对来说是计算量较小的过程，让Atari每走N步才选择一次action的话，可以让玩一次游戏的时间大幅减少，因此agent就能在单位时间内得到更充分的训练。
这种每跳过N帧才选择一次action的技术，就叫 frame skipping（跳帧），在很多强化学习框架中，也会看到这个参数的设定。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 
本文描述了在 rlpyt 框架下，如何使用一个预训练过的（pre-trained）model作为起点，来训练自己的RL模型的过程。

 什么是预训练模型
引用一篇文章：

简单来说，预训练模型(pre-trained model)是前人为了解决类似问题所创造出来的模型。你在解决问题的时候，不用从零开始训练一个新模型，可以从在类似问题中训练过的模型入手。

比如说，如果你想做一辆自动驾驶汽车，可以花数年时间从零开始构建一个性能优良的图像识别算法，也可以从Google在ImageNet数据集上训练得到的inception model(一个预训练模型)起步，来识别图像。

一个预训练模型可能对于你的应用中并不是100%的准确对口，但是它可以为你节省大量功夫。

训练一个强化学习模型也可能会需要消耗大量计算资源，尤其是你手上没有强大算力的时候，靠一台普通电脑去train一个model可能会用掉很长时间，因此，在别人已经train好的model的基础上继续train自己的model是一个好办法。
文章来源：https://www.codelast.com/
 rlpyt 对预训练模型的支持
以使用 DQN 算法的 example_1 为例，class DQN(RlAlgorithm) 的 __init__() 函数有一个 initial_optim_state_dict 参数：

initial_optim_state_dict=None,

另外，AtariDqnAgent 类的其中一个父类：DqnAgent，它又有一个父类 BaseAgent，在 __init__() 初始化的时候也有一个 initial_model_state_dict 参数：

def __init__(self, ModelCls=None, model_kwargs=None, initial_model_state_dict=None):

这两个地方，就是当你使用预训练模型的时候需要传入的参数。
但为什么会有两个参数？它们有什么区别？
前一个是Optimizer（优化器，例如 torch.optim.Adam）的 state_dict，其包含的参数有 learning rate 等。
 后一个是model的 state_dict，其包含的参数有 model 的 weight、bias 等。
直观点，来个图（图片可放大）：

从图中可以清楚地看到model里存储的数据，optimizer_state_dict 就是 Optimizer 的 state_dict，agent_state_dict 就是model的 state_dict。
文章来源：https://www.codelast.com/
 代码实操：加载预训练模型
首先我们要有一个预训练模型文件，因此，我们先把没有修改过代码的 example_1 运行一段时间，生成一个 params.pkl 模型文件，假设此文件路径为：/home/codelast/rlpyt/data/local/20191111/example_1/run_0/params.pkl
现在修改 example_1.py，可以加载预训练模型了：

# 加载预训练模型
model_loaded = torch.load('/home/codelast/rlpyt/data/local/20191111/example_1/run_0/params.pkl')
optimizer_state_dict = model_loaded['optimizer_state_dict']
agent_state_dict = model_loaded['agent_state_dict']

algo = DQN(min_steps_learn=1e3, initial_optim_state_dict=optimizer_state_dict)
agent = AtariDqnAgent(initial_model_state_dict=agent_state_dict['model'])

其他代码无需修改，就这么简单！
再重新运行修改过的example，现在就已经是在pre-trained model的基础上继续进行的训练了。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 
本文描述了如何保存迭代训练过程的所有model，以及背后的逻辑。

 迭代训练过程中产生的所有model，能全部保存下来吗
当然可以。以 example_1 为例，它有如下代码：

with logger_context(log_dir, run_ID, name, config, snapshot_mode="last"):
    runner.train()

只需要把 snapshot_mode="last" 改成 snapshot_mode="all"，就可以把迭代过程中的所有模型全部保存到磁盘文件了。
“last”表示只保存最后一次迭代的model文件。
文章来源：https://www.codelast.com/
 保存model的逻辑
model是在 logger.py 里的 save_itr_params() 函数里保存到磁盘文件的：

def save_itr_params(itr, params):
    if _snapshot_dir:
        if _snapshot_mode == 'all':
            file_name = osp.join(get_snapshot_dir(), 'itr_%d.pkl' % itr)
        elif _snapshot_mode == 'last':
            # override previous params
            file_name = osp.join(get_snapshot_dir(), 'params.pkl')
        elif _snapshot_mode == "gap":
            if itr == 0 or (itr + 1) % _snapshot_gap == 0:
                file_name = osp.join(get_snapshot_dir(), 'itr_%d.pkl' % itr)
            else:
                return
        elif _snapshot_mode == 'none':
            return
        else:
            raise NotImplementedError
        torch.save(params, file_name)  # 模型参数保存到文件

其根据 _snapshot_mode 变量来控制保存逻辑：
 all：保存所有迭代的model文件。
 last：只保存最后一次迭代的model文件。
 gap：每N次迭代保存一个model文件，N可以通过logger.set_snapshot_mode()函数来设置。
 none：不保存任何model文件。
文章来源：https://www.codelast.com/
而 _snapshot_mode，正是由 logger_context() 函数的 snapshot_mode 参数最终设置进去的。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 
本文记录 rlpyt 的一些issue提及的问题以及解决方案。

 同时输出gaussian（高斯）和categorical（类别）的action
issue链接：在这里
 问题描述：一般来说，action要么是一个高斯分布（gaussian），要么是一个类别值（categorical），如何能把这二者混合起来，即同时输出gaussian和categorical的action？
 我的理解：gaussian的action，指的是policy network输出的是一个action的概率分布，而不是一个确定的action（例如，有70%的可能选择action 1，有30%的可能选择action 2），此时，我们是按这个概率分布来选择一个具体的action，举个例子，对应到Python程序，你可能会用 np.random.choice(a, size=None, replace=True, p=None) 函数来在一个指定的概率分布上选择一个action，其p参数可以指定概率值。
而categorical的action，指的是policy network输出的是一个确定的action，例如它直接输出的可能是action 1，或action 2，诸如此类，而不是给出action 1，action 2的概率值再让用户去选。
这个issue的目的，就是想实现一种“非常规”的用法，输出的action同时具有这两种性质——我想像不出来应该用什么来举例。
 解决方案：rlpyt 里面有一个 Composite（复合）的action space：

class Composite(Space):

可以分别实现两个action space：一个gaussian的和一个categorical的，再用一个Composite的action space把它们包在里面。和environment交互的action space，就是这个Composite的action space了。
文章来源：https://www.codelast.com/
但是要注意，algorithm（例如PPO）是不支持Composite的action space的，所以还需要对algorithm类再做一点改造：另外定义一个 distribution 类，它能根据Composite的action算出其 log probability。还是以PPO为例，它使用 self.agent.distribution 来对action space进行action的选取，此时要用自定义的 distribution 类来替换掉这个distribution，然后就OK了。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 如果你想用这个框架来开发自己的强化学习程序（尤其是那些不属于Atari游戏领域的强化学习程序），那么需要对它的源码有一定的了解。本文尝试从 rlpyt 自带的一个实例来分析它的部分源码，希望能帮助到一小部分人。

 观察训练日志引出的问题
以 example_1 为例，在训练的过程中，程序会不断打印出类似于下面的日志（部分内容）：

文章来源：https://www.codelast.com/
仔细看就会发现，最后的若干个模型指标都是“nan”，在训练了一段时间之后，这些值就变成了有意义的值，例如：

2019-11-08 20:40:40.941580  | lossAverage                 0.0129165

2019-11-08 20:40:40.941597  | lossStd                     0.0137061

2019-11-08 20:40:40.941614  | lossMedian                  0.0150348

2019-11-08 20:40:40.941631  | lossMin                     0.000105323

2019-11-08 20:40:40.941648  | lossMax                     0.0602407

2019-11-08 20:40:40.941665  | gradNormAverage             0.0283939

2019-11-08 20:40:40.941682  | gradNormStd                 0.0168219

2019-11-08 20:40:40.941699  | gradNormMedian              0.0301482

2019-11-08 20:40:40.941716  | gradNormMin                 0.00661218

2019-11-08 20:40:40.941732  | gradNormMax                 0.086334

2019-11-08 20:40:40.941749  | tdAbsErrAverage             0.0529054

2019-11-08 20:40:40.941766  | tdAbsErrStd                 0.168416

2019-11-08 20:40:40.941783  | tdAbsErrMedian              0.0233203

2019-11-08 20:40:40.941800  | tdAbsErrMin                 8.33329e-05

2019-11-08 20:40:40.941817  | tdAbsErrMax                 1

所以这些值是在什么时候才会从“nan”变成有意义的值呢？为什么刚开始训练不久的时候，会获取不到这些值？理论上，只要开始训练了，哪怕这些数字错得再离谱，它们也是有数的，不应该是“nan”才对，对吧？所以这里为什么会显示“nan”？
文章来源：https://www.codelast.com/
 nan 日志在哪记下来的
为了弄清楚上面的问题，我们要找到根源——打印“nan”日志的地方。上面那些显示为“nan”的日志，是 rlpyt/utils/logging/logger.py 的 record_tabular_misc_stat() 函数记录下来的：

def record_tabular_misc_stat(key, values, placement='back'):
    if placement == 'front':
        prefix = ""
        suffix = key
    else:
        prefix = key
        suffix = ""
    if len(values) > 0:
        record_tabular(prefix + "Average" + suffix, np.average(values))
        record_tabular(prefix + "Std" + suffix, np.std(values))
        record_tabular(prefix + "Median" + suffix, np.median(values))
        record_tabular(prefix + "Min" + suffix, np.min(values))
        record_tabular(prefix + "Max" + suffix, np.max(values))
    else:
        record_tabular(prefix + "Average" + suffix, np.nan)
        record_tabular(prefix + "Std" + suffix, np.nan)
        record_tabular(prefix + "Median" + suffix, np.nan)
        record_tabular(prefix + "Min" + suffix, np.nan)
        record_tabular(prefix + "Max" + suffix, np.nan)

文章来源：https://www.codelast.com/
这个函数用来计算某些模型指标，这些模型指标有一个共同的特征：它们都可以计算平均值、标准差等统计值。这是什么意思？举个例子，有一个指标“CumTrainTime”（累积的训练时间），它就没有“平均值”的概念；而像 loss（损失函数的值）这种指标，它在多轮训练迭代过程中，是可以有“平均值”的概念的。
而类似于 loss 这种指标，还不止一个。为了简化代码，这里采用了拼接模型指标名称的做法，例如日志里的"lossAverage"，"gradNormAverage"之类的名称都是拼出来的，而不是直接写死，正如你上面看到的代码一样。
从上面的代码可见，当传入的“values”为空的时候，记下来的某些模型指标就会变成“nan”。
所以现在的问题变成了：在什么时候，传入的“values”会为空？
文章来源：https://www.codelast.com/
 logger的调用者 MinibatchRlEval 更新模型指标的逻辑
example_1 使用的 runner 是 MinibatchRlEval，它就是 logger 的调用者。在 MinibatchRlEval.train() 函数中定义了模型的训练、评估流程。
下面这句代码：

opt_info = self.algo.optimize_agent(itr, samples)

会把 loss 等参数收集到 opt_info 对象中，而下面这句代码：

self.store_diagnostics(itr, traj_infos, opt_info)

则会把 opt_info 更新到内存里。最后，这一句代码：

self.log_diagnostics(itr, eval_traj_infos, eval_time)

会把内存里的信息记录到日志，以及print到屏幕上。

所以，其实我们只要弄清楚 self.algo.optimize_agent() 返回 opt_info 的逻辑，就知道在什么情况下 loss 等指标为“nan”了。
文章来源：https://www.codelast.com/
 找到根本原因：algorithm类更新模型指标的逻辑
example_1 使用的algorithm类是：

class DQN(RlAlgorithm):

它的 optimize_agent() 函数里有这样一段代码：

opt_info = OptInfo(*([] for _ in range(len(OptInfo._fields))))
if itr < self.min_itr_learn:
    return opt_info

这里的 opt_info 其实就是一个各字段为空list的 namedtuple 对象：

OptInfo(loss=[], gradNorm=[], tdAbsErr=[])

答案已经很明显了，当前模型训练的迭代次数 < self.min_itr_learn 的时候，就会造成 loss 等模型指标为“nan”。
self.min_itr_learn 是在 DQN.initialize() 函数里初始化的：

self.min_itr_learn = int(self.min_steps_learn // sampler_bs)

不用去管这个看似有点奇怪的逻辑，只需要知道：self.min_steps_learn 越大，“nan”打印出的次数就越多。
而 self.min_steps_learn 这个参数，是在 DQN 类对象构造的时候传入的(example_1.py)：

algo = DQN(min_steps_learn=1e3)

所以，你只要改小这个值，就可以让“nan”出现的次数减少。
文章来源：https://www.codelast.com/
 为什么要这样做，以及调整 min_steps_learn 参数的注意事项
rlpyt 为什么要用一个参数来控制模型指标的计算过程？其实它不是为了控制什么时候不显示“nan”，看 DQN.optimize_agent() 函数的这几句代码：

if samples is not None:
    samples_to_buffer = self.samples_to_buffer(samples)
    self.replay_buffer.append_samples(samples_to_buffer)
opt_info = OptInfo(*([] for _ in range(len(OptInfo._fields))))
if itr < self.min_itr_learn:
    return opt_info

就会发现：当训练迭代次数没有达到 self.min_itr_learn 的时候，算法会一直把与environment交互得到的采样数据收集到 Replay Buffer 里面，如果 Replay Buffer 里的数据太少，没有达到预设的数量，那么开始优化策略网络也是没有意义的。当满足 irt >= self.min_itr_learn 的条件之后，后面才会进行反向传播之类的工作。
所以我认为，min_steps_learn 的值确实不能设置得太小。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 
在训练强化学习模型的过程中，rlpyt 产生的大量训练日志看起来无比枯燥，本文展示了如何利用 viskit 把这些日志数据可视化。

 viskit是什么
viskit是rllab的一个可视化组件，rllab是一个曾经有一定知名度的强化学习框架，但可惜的是它早就停止开发了。不过，viskit却被人单独抽了出来，作为一个可视化工具来使用。rlpyt 生成的训练日志也可以利用它来可视化，这是因为 rlpyt 生成的日志格式遵循了 viskit 的规范。
viskit的功能是：读取它能解析的日志数据，启动一个网页，在网页上用图形展示日志内容。
文章来源：https://www.codelast.com/
 安装viskit
把代码下载到本地：

git clone git@github.com:vitchyr/viskit.git
cd viskit/

安装viskit的依赖包：

conda install -c anaconda matplotlib

conda install -c anaconda flask

conda install -c anaconda plotly

注意，在这里我是在Anaconda环境里装的，如果你不用Anaconda，也可以用对应的pip install命令来装。
需要flask是因为viskit会启动一个网页来可视化地展示数据，它正是使用了Flask来实现的（Flask 是一个 Python 实现的 Web 开发微框架）。
文章来源：https://www.codelast.com/
 使用viskit
在使用viskit之前，首先你得有供它读取的日志。这里假设日志的路径为：/path/to/your/log/dir
这个路径下的日志文件名应该是类似于这样的：

你可以用 rlpyt 跑一下自带的example，就会生成这样的日志数据。

设置PYTHONPATH：

export PYTHONPATH=/path/to/your/viskit:$PYTHONPATH

这里的 /path/to/your/viskit 是你的viskit源码所在路径。
运行viskit：

python viskit/frontend.py /path/to/your/log/dir

最后一个参数就是日志所在的目录。
不出错的话，你会看到命令行有这样的输出：

Importing data from ['/path/to/your/log/dir']...

Reading /path/to/your/log/dir/progress.csv

View http://localhost:5000 in your browser

 * Serving Flask app "frontend" (lazy loading)

 * Environment: production

   WARNING: This is a development server. Do not use it in a production deployment.

   Use a production WSGI server instead.

 * Debug mode: off

 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

文章来源：https://www.codelast.com/
 效果展示
用浏览器访问 http://localhost:5000/ 即可打开可视化网页：

在上面的“Y-Axis Attributes”下拉列表框里可以选择要把哪些指标绘制成图形，点击“Upadte”按钮即可刷新下面的图像。
文章来源：https://www.codelast.com/
各种指标图：

文章来源：https://www.codelast.com/
比较酷炫的是，这些图是可以进行缩放等操作的，在图的右上方有一排工具按钮，点一下就看到效果了。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 如果你想用这个框架来开发自己的强化学习程序（尤其是那些不属于Atari游戏领域的强化学习程序），那么需要对它的源码有一定的了解。本文尝试从 rlpyt 自带的一个实例来分析它的部分源码，希望能帮助到一小部分人。

 Mixin类简介
rlpyt 里面有大量的 *Mixin 类，例如 AtariMixin，MujocoMixin，RecurrentAgentMixin 等，作者并没有为这些名字很怪的class写任何注释，仅从使用的地方来看，很多Mixin类都与agent类有关联。

 分析具体实例：AtariMixin
要充分理解Mixin类的设计意图，可以从一个具体的class来分析：AtariMixin。它是 AtariDqnAgent 的其中一个父类：

class AtariDqnAgent(AtariMixin, DqnAgent):
    def __init__(self, ModelCls=AtariDqnModel, **kwargs):
        super().__init__(ModelCls=ModelCls, **kwargs)

其中，另一个父类 DqnAgent 是实现了agent逻辑的类。AtariMixin 里面只实现了一个非常简单的函数，返回了一个字典：

class AtariMixin:
    def make_env_to_model_kwargs(self, env_spaces):
        return dict(image_shape=env_spaces.observation.shape,
                    output_size=env_spaces.action.n)

这个函数是在哪里被调用的？这就有点tricky了：它是在 DqnAgent 的父类 BaseAgent 的 initialize() 函数里被调用的：

self.env_model_kwargs = self.make_env_to_model_kwargs(env_spaces)

文章来源：https://www.codelast.com/
我们来理一下，这个调用链很有意思：

从这幅图可以看到，在agent类 initialize() 的时候，它调用的 make_env_to_model_kwargs() 函数，实际上调用的是 Mixin 类实现的 make_env_to_model_kwargs() 函数。
看上面的继承关系图，如果你产生一种疑问：“Python还能这样做的？” 那么我建议你可以自己去写几个简单的class实验一下——确实可以这样。
然而这个绕了一大圈的逻辑，是不是太麻烦了？
文章来源：https://www.codelast.com/
 为什么要插入一个Mixin类
一开始我在想，为什么不直接在 DqnAgent 类中实现其父类 BaseAgent 定义的接口 make_env_to_model_kwargs() 呢？那样不就可以少写一个Mixin类？
为了想明白这个问题，我们来看看 BaseAgent 类在调用了 make_env_to_model_kwargs() 函数后干了什么事情：

self.env_model_kwargs = self.make_env_to_model_kwargs(env_spaces)
self.model = self.ModelCls(**self.env_model_kwargs, **self.model_kwargs)

可见，它用返回的字典(dict) self.env_model_kwargs 来实例化 model 类。
要知道，rlpyt 是一个强化学习的框架，而不是一个专用于Atari游戏的强化学习库，我们可以用它来实现跟游戏毫不相关的强化学习应用。每一种强化学习应用，都有其对应的model类，而model类的参数(通常是跟environment space相关)因应用而异，我们不可能强行规定这些model类的参数必须叫什么名字，而是应该具有普适性：由应用的开发者自己去定义。
以 AtariMixin 为例，它返回的dict里包含两个参数：image_shape 和 output_size，即输入图像的shape以及输出的size，如果我自己的强化学习应用不是游戏应用、完全没有image这种东西呢？
在这个时候，我就需要几个更合适的名字来描述它们。
文章来源：https://www.codelast.com/
所以，看似半路杀出来的无厘头 Mixin 类，其实是为了 rlpyt 框架的良好扩展性而设计的一个类，它用于向model类提供实例化所需的特殊参数。
不过，在 rlpyt 中，并不是所有 Mixin 类都是为model类服务的，例如 EpsilonGreedy 类的父类 DiscreteMixin，就和model类无关。但这个类它也带了“为子类提供一些额外的功能，但放在子类中实现又不太好”的思想。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 如果你想用这个框架来开发自己的强化学习程序（尤其是那些不属于Atari游戏领域的强化学习程序），那么需要对它的源码有一定的了解。本文尝试从 rlpyt 自带的一个实例来分析它的部分源码，希望能帮助到一小部分人。

 EpsilonGreedy 类从哪来，做何用
agent 在 environment 里步进的时候，会根据policy network的计算结果，选择一个 action，再去根据这个 action 计算相应的 reward。对 example_1 来说，agent 类是 DqnAgent，其 step() 函数就是用于执行步进操作的：

@torch.no_grad()
def step(self, observation, prev_action, prev_reward):
    prev_action = self.distribution.to_onehot(prev_action)
    model_inputs = buffer_to((observation, prev_action, prev_reward),
        device=self.device)
    q = self.model(*model_inputs)
    q = q.cpu()
    action = self.distribution.sample(q)
    agent_info = AgentInfo(q=q)
    return AgentStep(action=action, agent_info=agent_info)

action = self.distribution.sample(q) 这里会用到 rlpyt/distributions/epsilon_greedy.py 里实现的 EpsilonGreedy 类，从名字上看，猜测它是 ε-greedy 算法的实现（实际上它就是）。
ε-greedy 是强化学习算法使用的一种探索策略。这里的目的是使用 ε-greedy 算法来选择 action。
文章来源：https://www.codelast.com/
 EpsilonGreedy 类详解
EpsilonGreedy 类有两个父类：DiscreteMixin 和 Distribution。其中 DiscreteMixin 实现了一些辅助功能的函数；Distribution 里基本是各种未实现的接口定义。
对 EpsilonGreedy 类本身来说，其精华在于只有短短5行代码的 sample() 函数：

def sample(self, q):
    arg_select = torch.argmax(q, dim=-1)
    mask = torch.rand(arg_select.shape) < self._epsilon
    arg_rand = torch.randint(low=0, high=q.shape[-1], size=(mask.sum(),))
    arg_select[mask] = arg_rand
    return arg_select

乍一看的感觉就是：这都是些什么乱七八糟的操作啊？完全不知道它在干嘛。
但从前文的分析，我们可以猜测出来这个函数是 ε-greedy 算法的实现，带着这个想法，我们读起代码来就有方向了。 
文章来源：https://www.codelast.com/
下面用一些实例辅助，来一行行分析代码，包你看懂！
sample() 函数的输入参数 q 是一个 tensor，因为从上面的分析知道，q 是policy network前向传播的计算结果。在这里，我们假设 q 为下面这个矩阵：

[[-0.2187, -0.2758,  0.4933,  1.0700],
[ 0.2689,  3.5079,  1.5640,  1.1730],
[-0.6858,  0.2571,  1.0396,  0.6344]]

现在再假设 sample() 函数用到的一个变量 self._epsilon = 0.3。这里要提一下，尽管这里我为了简单，用一个标量 0.3 来举例，但不代表 self._epsilon 一定要是个标量。如果仔细研读另一个类 EpsilonGreedyAgentMixin 的代码，会发现它调用了 EpsilonGreedy.set_epsilon() 函数：

self.distribution.set_epsilon(self.eps_sample)

而EpsilonGreedy.set_epsilon() 函数的定义为：

def set_epsilon(self, epsilon):
    self._epsilon = epsilon

此时 set 进去的 epsilon 有可能是一个 tensor 而不是一个 scalar。
记住这一点，我们继续用简单的scalar的情况来举例，即令 self._epsilon = 0.3。
文章来源：https://www.codelast.com/
 第1行代码：

arg_select = torch.argmax(q, dim=-1)

这句的功能是：返回指定的维度(dim，-1表示最后一个维度)上，值最大的那个数的index。
结果，arg_select 值为 [3, 1, 2]，这是因为，对输入矩阵来说，第一行最大的值是 1.0700，其index为3；第二行最大的值是 3.5079，其index为0；第三行最大的值是 1.0396，其index为0，因此拼起来就是 [3, 0, 0]。
文章来源：https://www.codelast.com/
 第2行代码：

mask = torch.rand(arg_select.shape) < self._epsilon

会得到一个bool的矩阵，标识了torch.rand生成的随机数组里的每个元素是比self._epsilon大还是小。
结果，mask 值为[True, False, True]，这是因为，此时 torch.rand(arg_select.shape)得到的一个随机矩阵是[0.2983, 0.4749, 0.2926] (由于是随机的，因此不是每次都是这个结果，这里仅拿某一次运行的结果作为例子来陈述)，这个随机矩阵的3个数，分别和 self._epsilon 比小，得到的结果就是 [True, False, True]。
文章来源：https://www.codelast.com/
 第3行代码最为复杂：

arg_rand = torch.randint(low=0, high=q.shape[-1], size=(mask.sum(),))

torch.randint()返回均匀分布的[low,high)之间的整数随机值，mask.sum()得到bool矩阵中True元素的个数(假设为x)，因此得到的arg_rand是x个[low,high)之间的随机数。例如 print(torch.randint(0, 20, (6, ))) 的输出可能是：tensor([14,  4,  7, 17, 16,  3])。
mask.sum() 的值为 2，因为这等同于执行 torch.sum(mask)，即计算 mask 这个 Tensor 上的所有元素的和，对元素为 bool 类型的情况，True为1，False为0，因此结果为2。
q.shape[-1] 的值为 4，因为 shape 为(3, 4)，因此 shape[-1] 就是最后一个值，即 4。
因此 arg_rand 这一句执行的语句就是：torch.rand(low=0, high=4, size=(2, ))，即在 [0, 4) 间随机取两个整数，结果为 [2, 3]。
文章来源：https://www.codelast.com/
 第4行代码：

arg_select[mask] = arg_rand

mask是一个bool的Tensor，把它传给另一个Tensor arg_select的时候，返回的是mask中为True的那些entry。
arg_select[mask] = arg_rand 这句在执行之前，arg_select为[3, 1, 2]，mask为[True, False, True]，arg_rand为[2, 3]，对mask里为True的两个位置，找到arg_select里的对应位置，替换成arg_rand里的值，就是最后的结果：[2, 1, 3]。
文章来源：https://www.codelast.com/
从最后的结果 [2, 1, 3] 可以看到，它已经不能标识输入矩阵 q 的每一行的最大值的index了。
所以把上面的逻辑总结一遍，sample() 函数实现的功能就是：
找出输入矩阵某个维度上的最大值，然后按一定的机率(即epsilon)“不选取”那个值最大的index，最终得到一个具有“少量随机性”的最大值index矩阵。
这不正是 ε-greedy 算法干的事情吗？所以你明白 EpsilonGreedy 类为什么叫这个名字了吧。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：

rlpyt 是BAIR(Berkeley Artificial Intelligence Research，伯克利人工智能研究所)开源的一个强化学习(RL)框架。我之前写了一篇它的简介。 如果你想用这个框架来开发自己的强化学习程序（尤其是那些不属于Atari游戏领域的强化学习程序），那么需要对它的源码有一定的了解。本文尝试从 rlpyt 自带的一个实例来分析它的部分源码，希望能帮助到一小部分人。

 sampler的主要功能
训练强化学习模型需要训练数据，收集训练数据的工作就是由sampler类做的。
收集训练数据，就需要在environment中步进，因此environment的实例化工作也在sampler中完成。

在很多强化学习教程中，收集数据也叫采样数据，这也是sampler这个名字的由来。但需要注意的是，真正去做“收集数据”这个工作的，是一种叫做collector的class。sampler会在 initialize() 的时候，把 collector 对象也初始化。
所以 sampler 可以看做是在 collector 外面又包了一层。
文章来源：https://www.codelast.com/
 BatchSpec里的 T 和 B 的概念
在 SerialSampler 的 initialize() 函数里，会看到实例化 environment 的代码：

B = self.batch_spec.B
envs = [self.EnvCls(**self.env_kwargs) for _ in range(B)]

这里会把 B 个 environment 对象构造出来。
我觉得作者起了一个非常不好的变量名：B。仔细看一下，self.batch_spec 这个变量是在 SerialSampler 的父类 BaseSampler 中赋值的：

self.batch_spec = BatchSpec(batch_T, batch_B)

而 BatchSpec 是一个父类为 namedtuple 的class：

class BatchSpec(namedtuple("BatchSpec", "T B")):

由 Python namedtuple 的性质可以知道，当用 BatchSpec(batch_T, batch_B) 构造一个对象的时候，该对象内部会生成两个成员变量 self.T 和 self.B，它们的值分别为 batch_T 和 batch_B。
这也是为什么 BatchSpec 类的 size() 函数可以这样写的原因：

@property
def size(self):
    return self.T * self.B

从 BatchSpec 类的注释里可以知道，T 是时间步(time step)的概念，B 是 独立的trajectory分段的概念。
所谓时间步 T 是指agent与一个environment交互时，会按时间先后顺序不断地步进到下一个state，走一步即一个step。此值>=1。
所谓独立的trajectory分段，是指独立的trajectory的数量，即environment实例的数量。此值>=1。

说到这里，不难发现，environment按B的数量来实例化是有道理的。
进一步：

global_B = B * world_size

基于之前的文章里提到的 world_size 的概念，就可以看出来这里的 global_B 指的是多个“平行宇宙”下的所有 environment 的数量和。
文章来源：https://www.codelast.com/
 env_ranks的概念
env_ranks 又是一个“没有注释，又很难看懂是什么意思”的东西。

env_ranks = list(range(rank * B, (rank + 1) * B))

在 example_1 中，env_ranks 计算出来得到了一个 list：[0]。
这里得到的list是一个长度为 B 的list，B为environment的数量。你需要一层层挖下去才知道它是干嘛用的。

env_ranks 在 rlpyt/samplers/serial/sampler.py 的两个地方用到了：一个是 agent 的 initialize() 函数，另一个是 collector 类的构造函数，如下：

agent.initialize(envs[0].spaces, share_memory=False,
                 global_B=global_B, env_ranks=env_ranks)

以及：

collector = self.CollectorCls(
    rank=0,
    envs=envs,
    samples_np=samples_np,
    batch_T=self.batch_spec.T,
    TrajInfoCls=self.TrajInfoCls,
    agent=agent,
    global_B=global_B,
    env_ranks=env_ranks,  # Might get applied redundantly to agent.
)

作者对第2种情况做了注释：“Might get applied redundantly to agent.” 这里的意思是：可能和agent(里面的逻辑)重复了。通过下面的分析可以知道，第1种情况和第2种情况最终会调用到同一个函数，因此它们确实是做了重复的工作。
文章来源：https://www.codelast.com/
分别看看这两个地方用 env_ranks 来做什么。
★ agent 的 initialize() 函数
在 DqnAgent 类的 initialize() 函数里，和 env_ranks 有关的代码，只有一个地方是有用的：

if env_ranks is not None:
    self.make_vec_eps(global_B, env_ranks)

这里调用的是 EpsilonGreedyAgentMixin 类的 make_vec_eps() 函数。巧合的是，这与下面的第2种情况相同，所以直接来分析第2种情况。
文章来源：https://www.codelast.com/
★ collector类的构造函数
example_1 使用的 collector 类是 CpuResetCollector，在这个类的代码中（rlpyt/samplers/parallel/cpu/collectors.py）并没有使用 env_ranks，但是在其父类 DecorrelatingStartCollector 的父类 BaseCollector（这句话很拗口，“父类的父类”）的 start_agent() 函数里面，我们就会看到使用了 env_ranks：

def start_agent(self):
    if getattr(self, "agent", None) is not None:  # Not in GPU collectors.
        self.agent.collector_initialize(
            global_B=self.global_B,  # Args used e.g. for vector epsilon greedy.
            env_ranks=self.env_ranks,
        )
        self.agent.reset()
        self.agent.sample_mode(itr=0)

这里的 self.env_ranks 就是在 __init__() 里传入的，即 sampler 中传入的 env_ranks。
同时我们会看到，对 example_1 来说，if getattr(self, "agent", None) is not None 这个条件是满足的，因此这里会执行 agent.collector_initialize()。
example_1 的 agent 类是 DqnAgent，它有两个父类：BaseAgent 和 EpsilonGreedyAgentMixin，其中 BaseAgent 没有实现 collector_initialize() 函数：

def collector_initialize(self, global_B=1, env_ranks=None):
    """If need to initialize within CPU sampler (e.g. vector eps greedy)"""
    pass

而 EpsilonGreedyAgentMixin 类实现了 collector_initialize() 函数，所以最终调用的就是它（层层嵌套，已疯）：

def collector_initialize(self, global_B=1, env_ranks=None):
    if env_ranks is not None:
        self.make_vec_eps(global_B, env_ranks)

所以这里的 make_vec_eps() 又是干了啥？

def make_vec_eps(self, global_B, env_ranks):
    if self.eps_final_min is not None and self.eps_final_min != self._eps_final_scalar:  # vector epsilon.
        if self.alternating:  # In FF case, sampler sets agent.alternating.
            assert global_B % 2 == 0
            global_B = global_B // 2  # Env pairs will share epsilon.
            env_ranks = list(set([i // 2 for i in env_ranks]))
        self.eps_init = self._eps_init_scalar * torch.ones(len(env_ranks))
        global_eps_final = torch.logspace(
            torch.log10(torch.tensor(self.eps_final_min)),
            torch.log10(torch.tensor(self._eps_final_scalar)),
            global_B)
        self.eps_final = global_eps_final[env_ranks]
    self.eps_sample = self.eps_init

可以看到这个函数就是为了计算 self.eps_final 以及 self.eps_sample 的值。
对 example_1 来说，self.eps_final_min 为 None，因此 make_vec_eps() 函数里最外层的 if 为 False，只有最后一句代码 self.eps_sample = self.eps_init 有实效，因此，env_ranks 在这里啥用也没有！
“你让我看了这么多字，结果就告诉我它没用？!” 真不好意思，事实就是这样。
文章来源：https://www.codelast.com/
但是，env_ranks 对 example_1 没用，在其他的场景下还是有用的啊，我讲了这么多废话，还是没有说清楚 env_ranks 到底是干嘛的。我说一下我的理解：对不同的environment实例，对它们用ε-greedy来选择action的时候，ε 可能是不同的。由于rlpyt在不同的并行模式下，会形成不同的“虚拟environment数量”的概念（比如在Alternating模式下，每两个environment构成的一个pair会共享相同的 ε 值，两个 environment 视为一个虚拟的environment），因此在各种场景下都要确定一个对应到实际场景下的、虚拟的environment数量，这就是env_ranks的含义。
再次强调，这只是我目前的理解，如果有一天我有了新的领悟，那我可能会回来修正这些表述。
文章来源：https://www.codelast.com/
 收集训练数据发生的地方：obtain_samples() 函数
obtain_samples() 函数其实是调用了 collector 类的 collect_batch() 函数去收集训练数据：

def obtain_samples(self, itr):
    agent_inputs, traj_infos, completed_infos = self.collector.collect_batch(
        self.agent_inputs, self.traj_infos, itr)
    self.collector.reset_if_needed(agent_inputs)
    self.agent_inputs = agent_inputs
    self.traj_infos = traj_infos
    return self.samples_pyt, completed_infos

这里看上去有一点奇怪的是：收集到的数据 self.samples_pyt 并没有在 collect_batch() 函数中被更新，所以为什么每次收集一个batch的数据的时候，得到的 self.samples_pyt 都是最新的呢？
我觉得类似的现象在 rlpyt 中太多了，无形中增加了理解源码的难度。
文章来源：https://www.codelast.com/
要弄清楚这个问题，来看看 self.samples_pyt 是怎么定义的：在 initialize() 函数里有：

self.samples_pyt = samples_pyt

而 samples_pyt 是由另一个函数创建出来的：

samples_pyt, samples_np, examples = build_samples_buffer(agent, envs[0],
    self.batch_spec, bootstrap_value, agent_shared=False,
    env_shared=False, subprocess=False)

进这个函数里看一下就知道，samples_pyt 其实就是 samples_np 转成的对应 tensor 形式。而 PyTorch 和 NumPy array 是共享底层内存的，修改其中一个的数据会导致另一个也被修改，可以认为 samples_pyt 和 samples_np 在底层是对应到同一个东西（对这句话我持保留意见，目前还不能完全肯定这种说法正确，需要进一步理解 rlpyt 源码才能给出确定的答案，但姑且这么理解先）。
文章来源：https://www.codelast.com/
此外，samples_np 被传给了 collector 类的构造函数：

collector = self.CollectorCls(
    rank=0,
    envs=envs,
    samples_np=samples_np,
    batch_T=self.batch_spec.T,
    TrajInfoCls=self.TrajInfoCls,
    agent=agent,
    global_B=global_B,
    env_ranks=env_ranks,  # Might get applied redundantly to agent.
)

所以这就相当于把 samples_pyt 和 collector 类建立了联系。
再看一下 example_1 的 collector 类(即 CpuResetCollector)的 collect_batch() 函数，它在计算返回值的时候，果然有用到 samples_np：

agent_buf, env_buf = self.samples_np.agent, self.samples_np.env

经过这么一绕，obtain_samples() 函数中返回的 self.samples_pyt 就有意义了。
文章来源：https://www.codelast.com/
这一节就到这，且听下回分解。
文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：