Reinforcement Learning Tips and Tricks

signer do·2024년 8월 22일

RL에 대한 일반적인 조언

어디서 시작할지
어떤 알고리즘을 선택할지
알고리즘을 어떻게 평가할지

1. 강화학습 사용시 일반적 조언

agent를 훈련하는데 사용되는 data는 agent 자체가 환경과 상호 작용하여 수집.
이러한 종속성은 악순환으로 이어질 수 있음.
agent가 품질이 좋지 않은 data(보상이 없는 trajectory)을 수집하면 개선되지 않고 나쁜 trajectory를 축적
이 요인은 다른 요인들 중에서도 RL의 결과가 실행마다 다를 수 있음.
즉, random seed만 변경될 때, 이러한 이유로 정량적 결과를 얻으려면 항상 여러 번 실행

일반적으로 RL에서 좋은 결과는 적절한 hyperparameter를 찾는데 달려 있음.
최근 알고리즘(PPO, SAC, TD3, DroQ)는 일반적으로 hyperparameter 튜닝이 거의 필요하지 않음.
기본 알고리즘이 어떤 환경에서도 작동할 것이라고 기대 X

따라서, tuning된 hyperparameter에 대한 RL zoo를 살펴보는 것이 필요.
RL을 새로운 문제에 적용할 때 가장 좋은 방법은 자동 hyperparameter를 최적화하는 것
https://github.com/DLR-RM/rl-baselines3-zoo/tree/master/hyperparams

1.1 custom environment 생성 시 Tips and Tricks

custom 문제에 강화학습 적용시, agent에 normalize된 input을 줘야함. 즉 VecNormalize for PPO/A2C. 그리고 또한 Atari나 frame-stack 등을 살펴봐야 함.

가능하면 항상 observation space를 정규화해야됨. boundary를 알고 있어야함.
action space를 정규화하고 연속적인 경우에 대칭이어야함. 좋은 방법은 action을 $[-1,1]$ 범위 내에 있도록 재조정하는 것. 이는 제한되지 않으며, env 내에서 action을 다시 조정할 수 있기 때문
shape reward(즉, informative reward)에서 시작하고 문제를 심플화하기
각 action이 주는 피드백을 더 구체적으로 만들어 agent의 학습을 촉진하는 것이 핵심
check_env함수: random actions으로 debug하여 env 환경이 동작하고, gym interface를 따르는 지 확인

Markov 가정이 깨지는 것을 피해야하고, timeout으로 인한 종료(episode 내 최대 step)를 적절히 처리하는 것. ex) action과 observation 사이에 time delay가 있는 경우(wifi 통신 등) observation의 history를 input으로 제공해야 한다.

timeout으로 인한 종료는 분리해서 다루어야 한다.
truncated=True를 return 하도록.
TimeLimit wrapper를 사용하면, 자동적으로 종료된다.
Time Limits in Reinforcement Learning

Partial-Episode Bootstraping: training할 때 고정된 시간을 넘어 계속되는 문제의 경우에 다른 종결과 시간으로 종결하는 경우를 달리해야한다. 미래 잠재 보상을 설명하기 위해 시간 제한된 episode 끝에 상태로부터 가치 추정을 bootstrap한다. 미래 잠재적 gain과 중간 action value의 균형 전략을 촉진시키는데.

env = YourEnv()
obs, info = env.reset
n_steps = 10
for _ in range(n_steps):
	# Random action
    action = env.action_space.sample()
    obs, reward, terminated, truncated, info = env.step(action)
    if done:
    	obs, info = env.reset()

1.2 왜 action space를 정규화해야하는가?

초기에 중심이 0이고 std가 1인 Gaussian 분포에 따라 대부분 강화학습 알고리즘. 만약에 custom 환경에서 action space를 정규화하는 것을 잊으면, 학습과 debug에 어려울 수 있음.
Gaussaian distribution 사용의 다른 결과는 action range가 제한되지 않음. 그렇기 때문에 clipping은 일반적으로 유효한 간격을 유지하기 위해 임시방편으로 사용. 더 나은 해결책으로 SAC의 squashing function 이나 Beta 분포를 이용

정규화되지 않은 action space는 DDPG, SAC와 같은 알고리즘에서만 작동.
이 알고리즘은 policy를 정의하기 위해 직접적으로 Gaussian을 직접적으로 사용하지 않음
즉, DDPG 또는 sac는 ouTput이 action space 한계에 맞도록 다시 조정된다.

limit이 매우 큰 경우, 추출된 action이 오직 0 가까이 값을 얻게 됨.space의 limit으로 부터 멀어질 수 있음
action_space = spaces.Box(low=-1000, high=1000, shape=(n_actions,), dtype="float32")
limit이 너무 작은 경우, 추출된 action이 항상 satruate됨.(limit보다 클 수 있음)
action_space = spaces.Box(low=-0.02, high=0.02, shape=(n_actions,), dtype="float32")
2 크기의 구간을 대칭적으로 가지며 Action space가 정규화되면, policy를 정의하기 위해 사용된 Gaussian의 초기 표준편차로써 같은 크기이다. (ex. sb3에서 초기 표준편차가 1인 가우시안)
action_space = spaces.Box(low=-1, high=1, shape=(n_actions,), dtype="float32")

1.3 RL의 현재 한계

Model-free RL algorithms(즉 모든 알고리즘이 SB에서 구현된)은 비효율적으로 sample된다. 이것은 수많은 sample들을 필요하게 하고(때로는 수백만 interaction). RL에서 대부분 성공한 것은 game과 simulation 뿐이다. 예를 들어, 취리히 공대에 의한 WORK인 ANYmal 로봇은 시뮬레이션으로 학습되었고 real world에서 테스트한다.
일반적인 더 나은 성능을 얻기 위해, agent의 예산을 증강시켜야한다.(training timesteps 수)
요구된 행동을 달성하기 위해, 전문적인 지식이 요구되는 적절한 reward function 디자인이 필요하다 이 reward engineering은 여러번 반복이 필요하다. 좋은 reward shaping의 예시는, Deep Mimic paper에서 볼 수 있다.(모방 학습과 actorbatic 움직임을 하기 위한 강화학습이 합쳐진 형태)
RL의 마지막 남은 한계는 학습에 있어서 불안정성이다. 성능에서 큰 drop를 관찰할 수 있는데, 이 행동은 특히 DDPG에서 나타난다. 이러한 이유로 TD3에서 이 문제를 해결하고자 했다. 다른 방법인 TRPO와 PPO는 너무 큰 UPDATE는 피하고 문제를 최소화하기 위해서 TRUST REGION을 사용한다.

1.4 RL 알고리즘을 평가하는 방법

agent와 평가하거나 다른 결과와 비교할 때 enviroment wrapper에 주의해야함.
episode reward 또는 episode 길이에 대한 수정은 바람직하지 않은 결과를 초래
evaluate_policy 함수를 확인하기
대부분 알고리즘들이 훈련 중에 탐색 noise를 사용하기 때문에 주어진 시간에 agent의 성능 평가하려면 별도의 test 환경이 필요하다. 좋은 추정치를 얻으려면 n test episode 갯수마다 agent를 주기적으로 평가하는 것 (5, 20 사이) 그리고 각 episode의 reward를 평균하는 것이 좋다.

episode에 대한 policy를 n_eval_episodes 실행하고 평균 reward를 return한다. vector env가 전달되면 episode를 나누어 vector env의 다른 요소에 평가한다. 이러한 static한 작업 분할은 bias를 제거하기 위해 수행됨.

stable_baseline3.common.evaluation.evaluate_policy(
	model, env, n_eval_episodes=10, deterministic=True, render=False, 
    reward_threshold=None, return_episode_rewards=False, warn=True
)
'''
	n_eval_episodes (int) – Number of episode to evaluate the agent
    return_episode_rewards (bool) – If True, a list of rewards and episode lengths per episode will be returned instead of the mean.
'''

return: Mean reward per episode, std of reward per episode.

evaluation할 때 EvalCallback을 제공한다.
PPO나 A2C에 의한 POLICY는 확률적인데, deterministic=True로 설정해야 .predict() method일 때, 이것은 흔히 더 나은 성능을 보임. training curve에서 (timesteps별 episode reward 함수)는 좋은 평가일 수 있지만 agent의 실제 성능을 과소형가할 수 있다.
참고:

2. 어떤 알고리즘을 이용?

discrete action space인지, 특정 속도로 가야하는 continous action인지
DQN은 discrete만, SAC는 continous action만
parallize한 학습이 필요한지 안한지. wall clock training time(실제로 소요되는 시간)이 문제라면, A2C와 파생인 PPO 알고리즘을 사용하는 것이 좋다. 여러개의 worker를 이용하여 훈련해야하면 Vectorized Environments를 이용.
훈련을 가속화하기 위해, SBX(Stable Baseline3+ Jax)를 보거나, SB3보다 더 기능은 작지만 SB3 Pytorch보다 20배더 빠를 수 있다. JIT compliation(호환) gradient update에 의해서
희소적인 reward의 경우, HER와 같은 전용 방법 또는 ARS 알고리즘을 쓰는 것이 방법