내 안드로이드폰이 강화학습을 위한 environment가 되게 해 주는 멋진 플랫폼이 나왔다니!! 역시 딥마인드!!
AndroidEnv라는 이름을 보자마자 무릎을 탁 치게 되었다. 게임 밖의 현실 세계에 적용하기가 너무나 어렵던 강화학습이 내 손안에 잡히는 구체적인 현실 문제에 적용 가능해 지는 무한한 가능성이 상상되지 않는가?
하지만 흥분은 잠시, 5초만에 몇가지 의문점들이 밀려온다.
강화학습이라고? environment가 게임이 아니라면 reward는 어떻게 정의하지?
그리고 action과 observation은 어떻게 정의되는 거지? agent는 사람처럼 행동하는 건가? 아니면 정말 마블의 자비스나 her의 사만다 같이 사람과 interaction할 수 있는 강화학습 agent를 만들 수 있는 건가?
결론부터 얘기하자면, AndroidEnv는 OpenAI Universe같이 강화학습 agent를 다양한 task에 최적화되도록 훈련시킬 수 있는 범용 environment platform이다. 정말 대강 후려쳐 정리하자면 OpenAI Universe같은 것을 Android 환경에서 돌릴 수 있게 한 것인데, 그렇기 때문에 훨씬 실용적일 수 있고, 모바일이라는 UI특성 때문에 action space가 터치스크린 이벤트 방식으로 구현되어 있다 정도의 차이가 있다. (하지만 논문을 읽어보면 행간에 많은 고민들이 녹아 있음을 알수 있다)
이 표 하나의 의미만 파악하면 AndroidEnv의 의미를 절반쯤 이해할 수 있다. 절반인 이유는, 이 표만 봐서는 AndroideEnv가 OpenAI Universe와 뭐가 다른지 알수 없기 때문이다.
그럼 AndroidEnv를 소개한 논문을 흐름에 따라 눈에 띄는 점만 정리하면서 이것의 의미를 좀더 생각해 보자.
I. Introduction
AndroidEnv에서 agent와 environment의 관계는 안드로이드폰의 유저(user)와 안드로이드 기기(device)의 관계와 같다.
•
Observation : Screen pixels
•
Action : Touchscreen gestures
이것은 안드로이드 기기를 사람처럼 다룰 수 있는 agent를 만들겠다는 의미이다.
그동안 우리가 보아왔던 OpenAi gym이나 universe가 사람처럼(혹은 사람보다) 게임을 잘 하는 강화학습 agent를 만들 수 있게 해주었다면, 그런 의미에서 AndroidEnv는 실행환경을 안드로이드 환경으로 가져왔다는 것을 제외하고는 하고싶은 것이 동일하다는 의미기도 하다. 물론 안드로이드 환경에서 agent가 그 수많은 유용한 app들을 자유자재로 다룰 수 있다면 agent가 real world에서 할수 있는 일의 가능성이 어마무시해질 거라는 잠재력은 여전히 유효하다.
하지만 introduction 어디에도 reward에 대한 언급은 없다. 아래 2장까지도 마찬가지이다. 이것이 의미하는 것은? 어쩌면 AndroidEnv에서조차 우리의 agent가 할수 있는 일은 고작 안드로이드게임 뿐일지도 모른다는 서늘한 우려가 든다.(이것은 어떤 의미에서는 진실일지도 모른다. 하지만 이것은 게임이 아닌 task조차 게임의 구조로 구현해야 RL을 적용할 수 있다는 뜻이 되기도 하다.)
2. Environment Features
AndroidEnv는 안드로이드 에뮬레이터 위에 dm_env API가 동작하도록 구현해 놓은 것이다. (dm_env는 딥마인드에서 2019년에 자체적으로 구현한 RL env인데, 이에 대해서는 https://github.com/deepmind/dm_env 참조) 안드로이드 에뮬레이터 위에서 돌아간다면 실제 디바이스에서 구동되는 app로 만드는 것도 어렵지 않다(고 한다).
하지만 안드로이드 환경이기 때문에, AndroidEnv는 기존과는 다른 훨씬 challenging한 env 특징을 보인다.
Real-time execution
아타리 게임을 하는 env와 매우 다른 주요한 특징이다. openAi gym에서 우리의 agent는 시간을 멈춘채 다음 action을 결정한다. 그 사이 게임은 전혀 진행되지 않은채 고정되어 있다.
이것은 적어도 안드로이드 환경에서는 비현실적이다. 안드로이드 OS는 우리의 agent가 다음 스텝을 고민하고 있는 동안에도 활발히 이벤트를 던질 것이다. app도 마찬가지다.
5장의 내용을 미리 가져와 보자면,
위 그림은 기존의 시간이 멈춘 RL 환경이다. Real time이 전혀 아니다.
그러나 AndroidEnv는 Real time이다. 여기서의 전략은, AndroidEnv 내에서 observation간의 간격 delta_t를 가능한한 일정하게 유지하도록 하는 것이다. AndroidEnv waits 타임을 적절히 조정하면서 가능한 전략이다. 결과적으로 AndroidEnv는 Real time 환경 속에서도 개발자가 env를 마치 synchronous한 것처럼 쉽게 이용할 수 있게 해준다. (AndroidEnv가 없었다면 귀찮은 async event handler 코딩을 해야 할 것이다)
Action Space
TYPE 1) Raw action space
안드로이드의 가장 기본적인 터치스크린 액션을 표현하는 방식은 position 좌표(x, y)와 actionType(TOUCH, LIFT, REPEAT)으로 표현하는 것이다. x, y는 둘다 0~1 사이의 값이다.
가장 low level로 action을 표현하는 가장 범용적인 방식이다. 하지만 agent가 이걸 제대로 구사하는 법을 익히는 방법은 어렵다. 예를 들어 LIFT 타입 action을 연속 2번 사용하는 것이 2번째에서는 의미가 없을 것이다. (OS 입장에서는 그냥 아무것도 안하는 것이다)
TYPE 2) Gestures
AndroidEnv는 Tapping, Swiping, Drag-and-drop 등 보다 구체적인 gesture를 raw action의 조합으로 표현한 high level (wrapper) API 를 함께 제공한다.
예를 들어, [LIFT, TOUCH, LIFT]의 그룹 시퀀스를 tapping으로 정의해 두는 방식이다. 이것 말고도 scroll, 확대/축소 등 배워야 할 gesture의 종류는 많다.
(참고) 위에서 다룬 delta_t 값은 gesture의 원활한 작동을 위해 매우 중요한 하이퍼파라미터가 된다.
Observation Space
기본적인 observation은 (pixels, timedelta, orientation)으로 이루어진다.
pixels : 현재 화면 프레임의 RGB image array
timedelta : 직전 observation으로부터의 이번 observation까지의 소요시간(realtime 환경임을 기억하자)
orientation : 부가정보(raw pixels로부터도 얻을 수 있는 텍스트 등 유용한 정보, 터치스크린 방향-가로/세로)
그리고 Task extras가 있다. orientation과의 차이는 task dependent하다는 점이다. 그리고, 기본적인 observation이 아니라 별도로 요청해야 얻을 수 있는 값이며, 항상 주어지지도 않는다는 점이다.
3. Tasks
AndroidEnv에서 agent가 다룰 수 있는 task를 자유롭게 정의할 수 있다. Task를 정의하는 아래와 같은 규격을 Task protocol buffer message라고 부른다.
•
How to initialise the environment: for example, installing particular applications on the device.
•
When should an episode be reset: for example, upon receiving a particular message from the
device or app, or upon reaching a certain time limit.
•
Events triggered upon an episode reset: for example, launching a given app, clearing the cache, or pinning the screen to a single app (hence restricting the agent’s interaction to that app).
•
How to determine the reward: for example, this might depend on different signals coming from Android, such as Android accessibility service or log messages implemented in applications.
잘 와닿지 않을 것이므로 AndroidEnv 깃허브에 있는 예시를 보는 편이 낫다.
그리고 현재 지원되는 Task는 다음 링크를 참고하자.
역시나 대부분의 task는 게임이다. Reward에 대한 언급이 논문에서 너무 부족하다는 것을 느꼈을 때의 슬픈예감은 잘 틀리지 않는다. reward를 주는 방식을 새롭게 정의하여 얼마든지 창의적인 task를 정의할 수 있겠지만, 게임이 아니고서는 reward를 설계하는 것 자체가 env를 새롭게 창조하는것 만큼의 어려운 일이기 때문이다.
4. Experimental results
위 6가지 게임에 대해 AndroidEnv에서 몇가지 알고리즘으로 agent를 구현해 본 결과이다. 모두 high resolution이 필요하지 않은 게임이라서 observation 도 80X120으로 다운샘플해서 ATARI 게임처럼 시도해 볼 수 있게 재구성했다.
Continuous action Agent인 DDPG 계열, finite action agent인 DQN, IMPALA, P2D2 등을 다양하게 실험해 보았다. (DQN 계열인 경우 action space를 discretize하기 위해 screen을 6X9로 나누어 Action Type 2가지(TOUCH, LIFT) 에 대해 총 108가지 action을 정의하였다.
결과적으로 Continuous agent는 쉬운 문제를 제외하고는 거의 풀지 못했고, Discrete agent는 좀더 성능이 좋았다.
테트리스 게임(f)가 매우 어려운 게임이라는 것을 새삼 깨닫게 된다. 복잡한 gesture가 필요하고 reward가 sparse하기 때문이다.
7. Conclusion
아직 시작단계이므로 게임 task 수준에서 동작을 확인하는데 머무르고 있지만, 이론상 AndroidEnv의 가능성은 무궁무진하다고 생각한다. 저자들은 보다 나은 핸즈프리 네비게이션, 모바일 테스트 자동화 등 다양한 실용적인 유스케이스로 발전시킬 수 있다고 주장한다. 사람 대신 모바일 디바이스를 직접 다룰 수있는 agent라면 분명 그런 가능성이 있을 것이다.
하지만, 나는 다른 가능성을 생각해 본다. 안드로이드는 핸드폰에서만 쓸 수 있는 기기가 아니다. 다른 디바이스를 제어할 수 있는 OS가 될수도 있고, 또 다른 장비를 제어하는 컨트롤러로서 기능할 수 있는 디바이스가 될 수 있다. 즉, 안드로이드를 핸들링할 수 있다는 자체만으로 RL이 이전보다 훨씬 손쉽게 real world에 다가갈 수 있는 길은 많다.
문제는 아이디어가 아닐까? 게임에서 벗어나 보다 명확한 reward를 설계할 수 있는, 실세계에서의 게임의 구조를 발견하는 멋진 아이디어에는 무엇이 있을지 고민해 본다.
