안녕하세요. 오늘의 X-Review는 GUI Agent 방법론인 ShowUI를 소개해드리고자 합니다. 최근 GUI Agent 분야에 관심이 생겨 관련 논문들을 찾아보던 중 읽게 되었으며, 25년도 CVPR에 게재된 논문입니다.

그럼 바로 리뷰 시작하겠습니다.

1. Introduction

GUI(Graphical User Interface)는 우리가 컴퓨터나 스마트폰과 상호작용할 때 가장 기본적으로 마주하는 인터페이스입니다. 웹 브라우징부터 문서 작성, 모바일 앱 사용까지 대부분의 디지털 작업이 GUI를 통해 이루어지죠. 한편 최근 LLM은 복잡한 자연어 명령을 이해하고 다양한 도구를 활용할 수 있게 되면서, 단순히 질문에 답변하는 것을 넘어 사용자를 대신해 실제 작업을 수행하는 Agent로 발전하고 있습니다. 이러한 흐름은 자연스럽게 사용자의 명령을 이해하고 GUI를 직접 조작하는 GUI Agent 연구로 이어졌습니다.

그림 1에서 볼 수 있듯 ShowUI는 현재 화면의 screenshot과 사용자의 instruction을 입력으로 받아, 다음에 수행해야 할 action을 직접 생성하는 Vision-Language-Action 모델입니다. 예를 들어 사용자가 “CVPR Overleaf template을 만들어줘”라고 요청하면 현재 화면을 보고 클릭해야 할 위치를 예측하고, 실제 action을 실행한 뒤 변경된 화면을 다시 입력받아 다음 행동을 이어가는 방식입니다.

초기 GUI Agent 연구들은 주로 GPT-4와 같은 closed-source LLM을 이용한 language agent 형태로 시작했습니다. 이때 모델은 화면 자체를 보는 것이 아니라 HTML이나 accessibility tree처럼 GUI 내부의 구조가 텍스트로 정리된 metadata를 입력받았습니다. 쉽게 말하면 우리가 화면을 직접 보고 버튼을 찾는 것과 달리, 모델에게는 처음부터 “여기에 버튼이 있고, 이름은 무엇이며, 어떤 역할을 한다”는 정보를 어느 정도 알려준 셈입니다.

문제는 실제 환경에서는 이러한 structural oracle 정보를 항상 사용할 수 있는 것이 아니라는 점입니다. 사람은 HTML을 읽고 웹사이트를 사용하는 것이 아니라 화면을 보고 버튼이나 아이콘을 찾아 클릭합니다. 저자들은 GUI Agent 역시 사람처럼 screenshot 자체를 보고 화면을 이해하고 조작할 수 있어야 한다고 이야기합니다. 이 때문에 최근에는 VLM을 이용해 GUI 화면을 직접 이해하도록 만드는 GUI visual agent 연구가 등장하기 시작했습니다. SeeClick이나 UGround와 같은 연구들은 웹 screenshot을 이용해 모델의 UI element grounding 능력을 학습했고, 다른 연구들은 instruction tuning을 통해 여러 단계의 navigation을 수행하도록 모델을 학습했습니다.

그런데 저자들은 여기서 GUI visual agent를 학습하는 데 아직 세 가지 문제가 남아 있다고 지적합니다.

첫 번째는 높은 visual modeling 비용입니다. GUI screenshot은 일반 자연 이미지보다 해상도가 상당히 높은 경우가 많습니다. 실제 PC 화면은 2K 수준의 해상도를 사용하는 경우도 흔하기 때문에 이를 VLM에 그대로 넣으면 엄청나게 많은 visual token이 생성됩니다. 문제는 이 token들이 Transformer의 self-attention을 통과하면서 계산량을 크게 증가시킨다는 것입니다.

더군다나 GUI 화면에는 실제로 중요한 정보만 존재하는 것도 아닙니다. 화면의 넓은 빈 공간이나 동일한 색상의 background처럼 서로 거의 동일한 영역이 상당히 많습니다. 즉, visual token은 굉장히 많은데 실제 정보량은 그만큼 많지 않은 상황인 셈입니다.

저자는 바로 이 부분에서 GUI screenshot과 natural image가 다르다고 봅니다. 자연 이미지는 사물, 질감, 배경 등이 복잡하게 섞여 있어 주변 patch가 비슷하게 생겼다고 해서 쉽게 제거하기 어렵습니다. 반면 GUI는 readability와 usability를 목적으로 사람이 직접 설계하기 때문에 layout과 색상이 상당히 규칙적입니다. 흰 배경처럼 아무 정보가 없는 영역은 넓게 반복되는 반면, 작은 icon이나 text처럼 크기는 작아도 실제 action을 결정하는 데 중요한 요소도 존재합니다. 따라서 GUI에서는 중복되는 영역은 제거하면서도 작은 중요 요소는 그대로 유지하는 token selection이 가능하지 않을까? 라는 것이 저자의 첫 번째 관찰입니다.

두 번째는 Vision-Language-Action을 어떻게 하나의 모델 안에서 다룰 것인가에 대한 문제입니다. GUI Agent에서 action은 일반적인 text와 조금 다릅니다. 모델은 단순히 “버튼을 클릭해야 한다”라고 답하는 것이 아니라 어떤 action을 수행할지와 그 action에 필요한 parameter까지 함께 출력해야 합니다. 예를 들어 CLICK이라면 클릭할 좌표가 필요하고, TYPE이라면 입력할 문자열이 필요합니다.

더 복잡한 점은 device에 따라 사용할 수 있는 action 자체가 달라진다는 것입니다. Web에서는 CLICK이 존재하지만 Mobile에서는 다른 interaction이 사용될 수 있고, SCROLL 역시 Web에서는 위,아래 정도만 고려하면 되지만 Mobile에서는 네 방향을 모두 처리해야 할 수 있습니다. 또 GUI navigation은 대부분 multi-step task입니다. 이전 화면에서 어떤 action을 수행했는지, 그 결과 현재 화면이 어떻게 바뀌었는지를 함께 기억해야 다음 행동을 결정할 수 있습니다. 즉, Screenshot → Action → Screenshot → Action → …과 같이 vision과 action이 시간 순서대로 계속 교차하는 구조를 모델이 이해해야 합니다. 기존 VLM의 일반적인 image-text 입력 방식만으로 이런 interleaved history를 어떻게 효율적으로 표현할 것인지가 두 번째 문제입니다.

마지막은 training data를 어떻게 구성할 것인가입니다. GUI 관련 데이터는 Web, Mobile, Desktop 등 여러 환경에서 이미 상당히 많이 공개되어 있습니다. 하지만 데이터가 많다고 해서 이를 전부 집어넣는 것이 반드시 좋은 것은 아닙니다. 예를 들어 웹 데이터에서는 static text가 전체 element의 약 40%를 차지합니다. 그런데 Qwen2-VL과 같은 최근 VLM은 이미 OCR 능력이 상당히 강하기 때문에 이런 단순 text element를 계속 학습하는 것이 실제 GUI grounding 능력 향상에 얼마나 도움이 되는지는 의문입니다.

또 데이터 규모도 환경마다 크게 다릅니다. Web 데이터는 쉽게 수집할 수 있는 반면 Desktop 데이터는 수집하기 어려워 데이터 수가 훨씬 적습니다. 이를 그대로 섞으면 모델이 Web에만 지나치게 편향될 수 있습니다. 따라서 저자들은 단순히 “데이터를 얼마나 많이 모을 것인가”보다 “GUI Agent에게 실제로 필요한 데이터가 무엇인지 선별하고 어떻게 균형 있게 학습할 것인가”가 중요하다고 봅니다.

이 세 가지 문제를 해결하기 위해 저자는 Qwen2-VL-2B를 기반으로 ShowUI를 제안합니다. ShowUI의 핵심은 크게 세 가지입니다.

첫 번째는 UI-Guided Visual Token Selection입니다. GUI screenshot 내부에서 서로 비슷한 patch들을 찾아 redundant한 visual token을 제거합니다. 특히 동일하거나 유사한 RGB 값을 가지는 인접 patch들을 하나의 connected component로 묶고, 그 안의 token 일부만 선택해 self-attention에 전달합니다.

중요한 점은 단순히 patch를 합쳐버리는 token merging을 사용하지 않는다는 것입니다. UI grounding에서는 화면에서 어디에 있는가가 굉장히 중요하기 때문에 여러 patch를 하나의 token으로 pooling하면 positional information이 손상될 수 있습니다. ShowUI는 대신 component 내부에서 일부 token만 선택하되 각 token이 가지고 있던 기존 positional embedding은 그대로 유지합니다. 이를 통해 spatial relationship은 유지하면서 redundant token만 줄이는 것이 목적입니다.

두 번째는 Interleaved Vision-Language-Action Streaming입니다. ShowUI는 GUI action을 JSON 형태로 통일합니다. 예를 들어 CLICK은 {‘action’:’CLICK’, ‘value’:None, ‘position’:[x,y]}와 같이 표현할 수 있습니다. 그리고 system prompt에 각 action이 어떤 의미이며 어떤 parameter를 필요로 하는지 README 형태로 설명해줍니다.

저자들의 의도는 모델이 특정 action vocabulary를 단순히 암기하게 만드는 것이 아니라, 주어진 action space의 설명을 읽고 function calling처럼 action을 사용할 수 있도록 만드는 것입니다. 또 multi-step navigation에서는 이전 screenshot과 action을 순서대로 연결해 Vision → Action → Vision → Action 형태의 stream으로 입력합니다. 이를 통해 모델이 이전에 무엇을 했는지와 그 결과 화면이 어떻게 변했는지를 함께 참고하면서 다음 action을 예측할 수 있도록 합니다.

세 번째는 선별된 GUI Instruction Tuning Dataset입니다. 저자들은 존재하는 GUI dataset을 모두 사용하는 대신 각 데이터가 실제로 어떤 정보를 제공하는지 분석한 뒤 필요한 데이터만 선택합니다.

Web에서는 OCR로 쉽게 처리할 수 있는 static text보다 Button이나 Checkbox처럼 실제 interaction과 관련된 visual element를 중심으로 데이터를 수집합니다. Desktop 데이터의 경우 수집 자체가 어렵기 때문에 OmniAct의 적은 annotation을 그대로 사용하는 대신 GPT-4o를 이용해 query를 확장합니다. 하나의 element에 대해 단순한 이름만 사용하는 것이 아니라 Appearance, Spatial Relationship, Intention 세 종류의 query를 생성합니다.

이러한 설계를 바탕으로 ShowUI는 2B 규모의 Qwen2-VL을 기반으로 약 256K의 비교적 작은 데이터만 사용하면서도 zero-shot ScreenSpot grounding에서 75.1% accuracy를 달성합니다. 그림 2를 보면 CogAgent-18B, SeeClick-9.6B, UGround-7B 등 훨씬 큰 GUI 모델과 비교해도 상당히 높은 grounding 성능을 보이면서 모델 크기는 2B로 가장 작습니다. 또 UI-guided visual token selection을 적용하면 학습 과정에서 redundant visual token을 약 33% 감소시킬 수 있었고, 이에 따라 training speed 역시 약 1.4배 향상되었습니다.

2. ShowUI

앞에서 이야기한 것처럼 ShowUI는 Qwen2-VL-2B를 기반으로 만들어진 GUI visual agent입니다. 전체 구조는 크게 세 부분으로 구성됩니다.

1. UI-Guided Visual Token Selection
2. Interleaved Vision-Language-Action Streaming
3. GUI Instructional Tuning

그림 3을 보면 사용자의 task query와 현재 screenshot, 그리고 사용할 수 있는 action space가 모델에 입력됩니다. 모델은 이를 기반으로 다음 action을 생성하고, 해당 action이 실행되면서 새로운 screenshot이 만들어집니다. 이후 새로운 screenshot을 다시 입력으로 사용해 다음 action을 생성하는 과정을 반복합니다. 이제 각 모듈을 하나씩 살펴보겠습니다.

2.1. UI-Guided Visual Token Selection

먼저 ShowUI에서 가장 핵심적인 부분이라고 볼 수 있는 UI-Guided Visual Token Selection입니다. 고해상도 screenshot을 일반적인 VLM 방식으로 patching하면 visual token 수가 상당히 많아집니다. 논문에서 예로 든 1344×756 해상도의 PC screenshot을 보면 14×14 크기의 patch로 분할했을 때 처음에는 약 5,184개의 raw token이 만들어집니다. Qwen2-VL의 2×2 token merging을 거친 이후에도 약 1,296개의 visual token이 남습니다.

문제는 Transformer에서 sequence가 길어질수록 self-attention 연산량이 크게 증가한다는 것입니다. 저자들은 여기서 다시 한번 “GUI screenshot을 일반 natural image와 똑같이 처리해야 하는가?”라는 질문을 던집니다.

GUI는 구조적으로 반복되는 영역이 많습니다. Google 검색 화면을 생각해보면 대부분이 흰색 background이고 실제 정보가 존재하는 영역은 일부에 불과합니다. 반대로 Overleaf처럼 text와 UI component가 빽빽하게 존재하는 화면은 훨씬 많은 정보가 들어 있습니다. 따라서 두 이미지의 해상도가 동일하더라도 필요한 visual token의 수까지 같을 필요는 없다는 이야기입니다.

UI Connected Graph

이를 위해 ShowUI는 screenshot의 patch들을 이용해 UI Connected Graph를 만듭니다. 방법 자체는 상당히 직관적입니다. 먼저 screenshot을 일정 크기의 patch로 나누고 각각의 patch를 graph의 node로 봅니다. 이후 서로 인접한 두 patch의 RGB 값 차이가 일정 threshold보다 작으면 두 node를 연결합니다. 쉽게 말하면 옆에 붙어 있으면서 거의 똑같이 생긴 patch들을 하나의 영역으로 묶는 것입니다.

이 connected component를 찾는 데에는 Union-Find 알고리즘을 사용합니다. 이렇게 하면 넓은 흰색 background처럼 반복되는 영역은 하나의 큰 component를 형성하고, text나 icon처럼 RGB pattern이 달라지는 부분은 서로 다른 component로 분리됩니다.

실제로 같은 1,296개의 initial token을 가진 screenshot이라도 Google Search 화면에서는 이를 약 291개의 component로 압축할 수 있었던 반면, text가 많은 Overleaf 화면에서는 986개의 component가 만들어집니다. 즉, 사전에 token 수를 고정해서 줄이는 것이 아니라 현재 screenshot이 얼마나 복잡한지에 따라 redundancy를 adaptive하게 판단하는 구조입니다.

Token Merging vs. Token Selection

그렇다면 같은 component 안에 들어간 token을 어떻게 줄일지가 다음 문제입니다. 가장 간단한 방법은 Token Merging입니다. 같은 component 안의 token들을 pooling해서 하나의 token으로 만드는 방식입니다.

하지만 저자들은 이 방법이 GUI task에는 적합하지 않다고 이야기합니다. GUI grounding에서는 element의 의미뿐만 아니라 정확히 화면 어디에 존재하는가가 중요하기 때문입니다. 여러 위치의 token을 하나로 합쳐버리면 원래 각각의 patch가 가지고 있던 positional information이 손실되고, 이는 정확한 coordinate prediction에 악영향을 줄 수 있습니다.

그래서 ShowUI는 Token Merging 대신 Token Selection을 사용합니다. 같은 connected component에 속한 token 중 일부를 training 과정에서 random하게 skip하고 나머지만 self-attention에 전달합니다. 대신 선택된 token은 기존 positional embedding을 그대로 유지합니다. 즉, token 자체를 합치는 것이 아니라 필요 없는 token만 빼는 방식이라고 이해하면 됩니다.

또 하나 중요한 점은 text나 작은 icon처럼 하나의 patch만으로 component가 구성된 경우에는 pruning하지 않습니다. 저자 입장에서는 이런 unique patch가 중요한 UI element일 가능성이 높다고 보는 것이죠. 이 방식에는 추가적인 learnable parameter도 필요하지 않습니다.

Training에서는 일정 비율의 token을 random selection하지만, inference에서는 token selection을 적용하거나 전체 token을 모두 사용할 수 있습니다. token이 가지고 있는 원래 positional relationship 자체는 변하지 않기 때문에 두 방식 모두 동일한 모델에서 사용할 수 있다는 설명입니다.

2.2. Interleaved Vision-Language-Action Streaming

두 번째는 action을 어떻게 모델링할 것인지에 대한 Interleaved VLA Streaming입니다. GUI Agent의 최종 목적은 navigation입니다. 따라서 모델은 현재 화면과 사용자 instruction을 보고 어떤 action을 수행할 것인지, 해당 action에 필요한 parameter가 무엇인지 동시에 예측해야 합니다.

그런데 GUI action은 device마다 꽤 다릅니다. Web에서 사용할 수 있는 action과 Mobile에서 사용할 수 있는 action이 다를 수 있고, 같은 SCROLL이라도 환경에 따라 parameter 정의가 달라질 수 있습니다. 심지어 test 환경에서 training 때 보지 못했던 새로운 action이 추가될 가능성도 있습니다.

ShowUI는 이 문제를 해결하기 위해 모든 action을 JSON format으로 통일합니다. action type과 value, position을 동일한 구조로 표현하고, 각 action을 어떻게 사용해야 하는지는 system prompt 안의 README 형태로 모델에게 제공합니다. 즉, 모델에게 action을 외우게 하기보다는 “현재 사용할 수 있는 도구 목록은 이것이고 각각 이런 방식으로 사용한다”라고 설명한 뒤 이를 보고 action을 생성하게 만드는 방식입니다.

Action with Visual

다음 문제는 multi-step navigation입니다. GUI navigation에서는 이전 action만 알고 있다고 충분하지 않습니다. 예를 들어 모델이 이전 step에서 어떤 버튼을 클릭했다는 사실을 알고 있더라도 클릭 이후 화면이 어떻게 바뀌었는지는 action만으로 알 수 없습니다. 반대로 screenshot만 가지고 있으면 현재 상태는 알 수 있지만 어떤 action을 통해 이 화면까지 왔는지는 알기 어렵습니다.

따라서 ShowUI는 두 정보를 모두 사용합니다. 이전 screenshot 뒤에 해당 screenshot에서 실행한 action을 배치하고, 그다음 변경된 screenshot을 다시 배치합니다. 즉, Screenshot₁ → Action₁ → Screenshot₂ → Action₂ → Screenshot₃ … 형태의 interleaved stream을 구성합니다.

다만 모든 환경에서 과거 screenshot을 전부 유지할 필요가 있는 것은 아닙니다. Mobile처럼 application 자체가 바뀌면서 화면이 크게 변하는 환경에서는 이전 visual history가 중요합니다. 반대로 동일한 webpage 안에서 작은 interaction만 반복하는 경우에는 화면 변화가 적기 때문에 일부 visual history를 mask해 계산량을 줄일 수도 있습니다.

Action with Textual Query

Grounding task에서는 또 다른 비효율이 발생합니다. 하나의 screenshot은 1~2K개의 visual token을 사용할 정도로 굉장히 길지만, element를 설명하는 query나 coordinate action은 몇 token밖에 되지 않습니다.

그런데 하나의 screenshot에 여러 element annotation이 존재한다고 해서 Screenshot + Query₁ → Action₁, Screenshot + Query₂ → Action₂처럼 screenshot을 매번 새로 forward하면 상당한 계산 낭비가 발생합니다. ShowUI는 이를 해결하기 위해 하나의 screenshot에 여러 query-action pair를 multi-turn dialogue처럼 연결합니다. 즉, 같은 visual token을 한 번 입력한 뒤 여러 grounding annotation을 연속적으로 학습합니다. 저자들은 이를 통해 하나의 forward pass에서 더 많은 annotation을 활용할 수 있어 training efficiency를 높일 수 있다고 설명합니다.

2.3. GUI Instructional Tuning

마지막은 training data 구성입니다. GUI Agent 관련 dataset은 이미 상당히 많지만 ShowUI는 이를 전부 합쳐서 사용하는 방식을 선택하지 않습니다. 대신 각 dataset이 실제로 어떤 능력을 학습시키는지 분석하고, 필요한 데이터만 선별합니다.

Web: Visual Elements

먼저 Web입니다. HTML을 이용하면 대규모 UI 데이터를 상당히 쉽게 수집할 수 있지만, 저자들의 분석에 따르면 web element 중 약 40%가 static text입니다. 그런데 Qwen2-VL과 같은 VLM은 이미 OCR 성능이 상당히 좋습니다.

따라서 단순 text를 계속 grounding하도록 학습하는 것보다 Button이나 Checkbox처럼 실제 GUI interaction과 관련된 visual element에 집중하는 것이 더 효율적이라고 판단합니다. 이를 위해 저자들은 parser를 이용해 약 22K개의 screenshot을 수집하고, static text를 제외한 visual-related element를 중심으로 training data를 구성합니다.

Desktop: Diverse Query

Desktop 데이터는 Web과 달리 자동 수집이 어렵습니다. 저자들은 OmniAct를 사용했는데, 해당 데이터에는 약 100개의 이미지와 2K 정도의 element밖에 존재하지 않습니다. 또 기존 annotation도 message_ash처럼 단순한 element 이름 수준입니다.

그래서 GPT-4o를 이용해 하나의 element annotation으로부터 세 종류의 query를 생성합니다.

• Appearance
• Spatial Relationship
• Intention

예를 들어 message_ash라는 element가 있다면, Appearance 관점에서는 “대문자 A가 들어 있는 파란색 채팅 카드”, Spatial Relationship 관점에서는 “Clara의 채팅 박스 위에 위치한 요소”, Intention 관점에서는 “Ash에게 사진을 보내기 위해 눌러야 하는 요소”처럼 서로 다른 방식으로 동일한 element를 지칭하도록 만듭니다. 이를 통해 기존 2K 규모의 annotation을 약 6K개의 보다 다양한 query로 확장합니다.

Mobile: Functionality

Mobile에서는 icon의 이름을 단순히 caption하는 데이터보다 해당 element가 실제로 어떤 기능을 수행하는지 설명하는 annotation을 중요하게 사용합니다. 결국 Web에서는 visual appearance, Desktop에서는 query diversity, Mobile에서는 functionality라는 서로 다른 장점을 가져오는 셈입니다.

Balance Data by Sampling

마지막 문제는 데이터 규모의 불균형입니다. Web 데이터는 수만 개를 쉽게 확보할 수 있지만 Desktop 데이터는 수백 개 수준에 불과합니다. 이를 그대로 섞어 random sampling하면 training batch 대부분이 Web 데이터로 채워질 수밖에 없습니다.

ShowUI는 각 data type이 비슷한 확률로 batch에 포함되도록 sampling probability를 조절합니다. 즉, 단순히 sample 개수에 비례해서 학습하는 것이 아니라 적은 데이터라도 모델이 충분히 볼 수 있도록 rebalancing하는 방식입니다.

3. Experiments

3.1. Benchmark Datasets

ShowUI는 크게 Grounding과 Navigation 두 task에서 평가합니다.

Grounding에는 ScreenSpot을 사용합니다. Mobile, Desktop, Web 환경에서 주어진 instruction에 해당하는 UI element를 찾는 zero-shot benchmark이며, Text와 Icon을 따로 평가합니다.

Navigation은 세 가지 benchmark를 사용합니다. Web에서는 Mind2Web, Mobile에서는 AITW, online environment에서는 MiniWob을 사용합니다. 이 중 AITW는 총 11개의 action을 사용하고, MiniWob은 모델이 실제 환경과 상호작용하며 action을 수행한다는 점에서 앞의 offline benchmark들과 차이가 있습니다.

전체 training data는 Grounding과 Navigation을 포함해 약 256K task instance와 2.7M UI element로 구성됩니다.

3.2. Main Results

3.2.1. Grounding Tasks

먼저 Table 2에서 ScreenSpot의 zero-shot grounding 성능을 비교합니다.

ShowUI는 평균 75.1%로 가장 높은 성능을 기록합니다. 비교해보면 CogAgent-18B는 47.4%, SeeClick-9.6B는 53.4%, UGround-7B는 73.3%입니다. 특히 UGround가 약 1.3M의 training sample을 사용하는 반면 ShowUI는 2B 모델과 256K 데이터만으로 75.1%를 달성했습니다.

세부적으로 ShowUI는 Mobile에서 Text 92.3%, Icon 75.5%, Desktop에서 76.3%, 61.1%, Web에서 81.7%, 63.6%를 기록합니다. 모든 환경에서 Text grounding이 Icon보다 높은데, 저자들은 text grounding은 platform 간 transfer가 비교적 잘 되는 반면 visual feature를 직접 구분해야 하는 Icon grounding이 더 어렵다고 봅니다.

Grounding 데이터만 학습한 ShowUI-G도 74.9%로 full ShowUI의 75.1%와 거의 차이가 없습니다. 즉, 적절한 sampling strategy를 사용한다면 Navigation 데이터를 함께 학습해도 Grounding 성능이 크게 떨어지지 않는다는 결과입니다.

3.2.2. Navigation Tasks

Mobile: AITW

다음은 Table 3의 Mobile navigation 결과입니다.

Qwen2-VL-2B baseline은 overall 67.2%를 기록합니다. Visual history 없이 action history만 사용하는 ShowUI†는 68.3%, full ShowUI는 70.0%까지 올라갑니다. 즉, 기본 instruction tuning으로 1.1%p가 향상되고, 이전 screenshot까지 함께 사용하는 Action-Visual Streaming을 추가하면 다시 1.7%p 정도 향상됩니다.

저자들은 Mobile 환경에서는 application이 계속 바뀌면서 visual state 변화가 크기 때문에 이전 action뿐 아니라 그 action 이후 화면이 어떻게 바뀌었는지까지 기억하는 것이 중요하다고 해석합니다.

Website: Mind2Web

다음은 Table 4의 Web navigation 결과입니다.

Cross-Task 기준 Step Success Rate를 보면 Qwen2-VL-2B는 33.2%, ShowUI는 37.2%로 약 4%p 향상됩니다. Cross-Website에서는 27.6%에서 35.1%, Cross-Domain에서는 30.7%에서 35.2%까지 증가합니다. 반면 visual history의 효과는 AITW보다 크지 않습니다. 예를 들어 Cross-Website Step SR에서 ShowUI†는 34.2%, full ShowUI는 35.1%로 차이가 0.9%p 정도입니다.

저자들은 Mind2Web의 경우 Mobile과 달리 하나의 website 내에서 화면 변화가 비교적 작고 action도 세 종류밖에 없기 때문에 visual history의 중요성이 상대적으로 낮다고 봅니다. 또 Cross-Task보다 Cross-Website와 Cross-Domain이 더 어렵다는 점도 강조합니다. 새로운 instruction을 이해하는 것보다 training에서 보지 못한 새로운 UI layout이나 visual domain에 적응하는 것이 더 어렵다는 이야기입니다.

Online: MiniWob

Table 5에서는 online environment인 MiniWob을 평가합니다.

Fine-tuning한 ShowUI는 71.5%로 SeeClick의 67.0%, Qwen2-VL-2B의 66.8%보다 높은 성능을 보입니다. 하지만 ShowUI-ZS는 27.1%에 불과합니다. 앞의 Mind2Web에서는 zero-shot transfer가 어느 정도 가능했던 것과 달리 MiniWob에서는 성능이 크게 떨어집니다. 저자들은 이를 offline instruction tuning의 한계로 봅니다. Online 환경에서는 모델이 잘못된 action을 수행하면 training에서 보지 못했던 새로운 state로 이동하게 되고, 이후 error가 계속 누적될 수 있습니다. 따라서 정답 trajectory만 이용한 offline training만으로는 이러한 상황까지 충분히 학습하기 어렵다는 것입니다.

3.3. Ablation Studies

Impact of UI-Guided Token Selection

먼저 Figure 9(a)에서 여러 visual token compression 방법을 비교합니다. 아무런 optimization을 적용하지 않은 baseline은 평균 1,344개의 visual token을 사용하며 ScreenSpot에서 70.8%를 기록합니다. UI-Graph를 이용한 Token Merging은 visual token을 약 853개까지 줄이고 training speed를 1.6배 높이지만 성능은 42.3%까지 크게 떨어집니다. 저자들이 앞에서 이야기했던 것처럼 token을 하나로 pooling하면서 positional information이 손실되기 때문입니다.

Random Token Selection은 65.3%를 기록하는 반면 ShowUI의 UI-Graph 기반 Token Selection은 약 947개의 visual token만 사용하면서 70.4%를 유지합니다. Baseline과 비교하면 성능 차이는 0.4%p에 불과하면서 training speed는 약 1.5배 향상됩니다. 다만 inference에서도 token selection을 사용하면 성능이 64.9%까지 떨어집니다. 따라서 이 방법의 가장 큰 장점은 inference compression보다는 training 과정의 computation을 줄이는 데 있다고 보는 것이 적절합니다.

Selection of Layers

Figure 9(b)에서는 어느 layer에 token selection을 적용할지 비교합니다. 모든 28개 layer에 적용하면 65.7%, 앞쪽 14개 layer는 68.2%, 뒤쪽 14개 layer는 67.6%를 기록합니다. 반면 layer를 번갈아가며 적용하는 Cross 방식이 70.5%로 가장 높습니다. 즉, 같은 14개 layer에 적용하더라도 특정 구간에 몰아서 사용하기보다 전체 network에 분산해서 사용하는 것이 더 효과적이었다는 결과입니다.

Different Selection Ratio

Figure 9(c)에서는 얼마나 많은 token을 제거할지 비교합니다. Selection ratio가 0일 때 70.8%, 0.25에서는 70.6%, 0.5에서는 70.4%로 거의 성능이 유지됩니다. 반면 0.75에서는 68.3%, 1.0에서는 64.5%로 떨어집니다. 따라서 저자들은 0.5를 성능과 training efficiency 사이의 적절한 trade-off로 사용합니다.

4. Conclusion

개인적으로 ShowUI는 GUI screenshot의 특성을 이용해 visual token을 줄이고, 데이터 구성까지 함께 손봤다는 점이 흥미로웠습니다. 특히 방법 자체는 단순한 편인데, ablation을 통해 각 설계가 실제로 어떤 영향을 주는지 잘 보여준 논문이었던 것 같습니다. 다만 inference에서 token selection을 적용했을 때 성능이 떨어지고, online 환경의 zero-shot 성능도 낮아 아직 실제 GUI Agent 관점에서는 해결할 문제가 꽤 남아 있어 보입니다.

감사합니다.