ShowUI: One Vision-Language-Action Model for GUI Visual Agent
Apr 12, 2026
- Task
- 스크린샷 기반으로 GUI를 이해하고 다음 액션을 예측하기
- 예:
- 어떤 버튼을 클릭해야 하는지 찾기
- 특정 텍스트를 어디에 입력해야 하는지 찾기
- 여러 단계에 걸쳐 웹/모바일 UI를 탐색하기
- 즉, 단순한 VLM 질의응답이 아니라
- screenshot + user query + action history
- 를 바탕으로
- 다음 GUI action을 생성하는 문제
- 기존 접근 방식
- gpt 같은 closed 모델에 html같은 text 데이터를 넣음
- 하지만 텍스트기반은 real world랑 다른 점이 많음
- 그래서 gui 기반의 접근이 필요함
- 하지만 gui 스크린샷을 그대로 쓰는건 비용이 많이 듦
- 어려운 점
- GUI 화면은 자연 이미지와 다름
- 자연 이미지는 texture와 semantic이 풍부함
- GUI는 빈 공간, 단색 배경, 반복 패턴이 많음
- 그런데도 작은 아이콘/버튼/텍스트는 매우 중요함
- 스크린샷이 고해상도라 visual token 수가 많음
- 예: 1344×756 화면을 patching하면 raw token이 매우 길어짐
- 14×14 patch + merge 후에도 1296 token 수준이라 self-attention 비용이 큼
- action이 자연어와 다름
- action type 자체도 맞춰야 하고
- 좌표, 문자열 같은 parameter도 같이 맞춰야 함
- 디바이스마다 action space가 다름
- web에는 CLICK이 있지만 mobile에는 PRESS HOME 같은 action이 있음
- 같은 SCROLL도 web/mobile에서 방향 체계가 다를 수 있음
- navigation에서는 현재 화면만 보면 안 되고
- 이전 screenshot
- 이전 action
- 둘 다 같이 봐야 함
- 데이터가 다양하지만 품질과 형식이 제각각임
- web / mobile / desktop
- grounding / navigation
- element coordinate / trajectory
- 이런 것들이 섞여 있어서 아무거나 다 쓰는 게 능사가 아님.
- 기존 방식들
- HTML, accessibility tree 같은 구조화된 메타정보를 쓰는 language agent
- 텍스트 기반으로는 잘 동작할 수 있음
- 하지만 실제 사용자는 내부 HTML을 못 보고 화면만 보므로 한계가 있음
- GUI용 VLM들
- screenshot grounding 위주 모델
- navigation instruction tuning 모델
- 하지만 기존 방식들의 한계
- 고해상도 GUI screenshot의 긴 visual token 처리 비효율
- action을 어떻게 표현하고 모델링할지 불명확
- 데이터 선택 기준이 명확하지 않음
- 이 논문의 핵심 아이디어
- 하나의 VLA 모델로 GUI과 네비게이션을 같이 다루자
- 이를 위해 세 가지를 제안함
- UI-guided visual token selection
- Interleaved vision-language-action streaming
- Small-scale high-quality GUI instruction-following dataset
- 모델 구조
- 기반 모델
- Qwen2-VL-2B 위에 GUI 특화 설계를 얹음.
- 전체 입력
- user task query
- action space 설명(README처럼 문서화)
- 현재/과거 screenshot
- 과거 action
- 전체 출력
- 다음 action 1개
- JSON 형식으로 생성함
{action: ..., value: ..., position: [x,y]}- 좌표는 0~1 상대좌표를 사용.
- UI-guided visual token selection
- 핵심 문제
- GUI screenshot은 token 수가 많고
- 많은 patch가 서로 거의 같은 정보라 비효율적임
- 기본 아이디어
- screenshot을 patch로 자른 뒤
- 각 patch를 graph의 node로 봄
- 인접 patch끼리 RGB가 거의 같으면 같은 connected component로 묶음
- 즉 UI connected graph를 만든다고 보면 됨
- GUI는 배경색, 박스, 빈 공간, 단색 영역이 많아서 인접 patch가 사실상 같은 정보인 경우가 많기 때문
- 예
- 같은 1296 token이라도
- 구글 검색 화면처럼 단순한 UI는 291 component
- Overleaf 같은 복잡한 텍스트 화면은 986 component
- 즉, 화면 복잡도에 따라 적응적으로 중복 정도를 파악함.
- Token merging vs token selection
- 단순한 방법
- 같은 component 안 patch들을 하나의 token으로 merge
- 문제점
- pooling으로 하나로 합치면 원래 patch들의 위치 관계가 사라짐
- GUI grounding에서는 위치 정보가 매우 중요해서 불리함
- 근데 원래 vit 계열에선 안 하긴 했음
- 이 논문의 방식
- merge하지 않고 같은 component 안에서 일부 token만 랜덤 선택
- 예를 들어 글자가 있는 경우는 서로 다른 개별 토큰이니까 항상 선택 하지만(single-patch component), 배경은 그 중 같은 컴포넌트 안에서 일부만 랜덤선택
- 선택된 token은 원래 positional embedding 유지
- 하나의 컴포넌트의 여러 토큰 중 하나를 선택했어도, 해당 토큰의 Positional embedding 사용
- 기존 vit랑 비슷하긴한듯
- 장점
- 연산량은 줄이면서 위치 관계는 최대한 보존 가능
- 추가 파라미터도 없음
- 학습 시 token selection을 적용하고 추론 시에는 선택적으로 켜거나 끌 수 있음.
- Interleaved Vision-Language-Action Streaming
- 핵심 문제
- GUI action은 자연어와 다름
- action type + parameter를 같이 다뤄야 함
- 그리고 navigation은 screenshot/action history가 섞여 들어감
- action 표현 방식
- 모든 action을 JSON으로 통일
- action: 액션 타입
- value: 입력 문자열 등
- position: 클릭 좌표
- action space 문서화
- system prompt에 action 설명을 같이 넣음
- 예:
- CLICK은 좌표 필요
- TYPE은 문자열과 위치 필요
- 그래서 모델이 액션 이름을 외우기보다
- 문서를 보고 action schema를 해석하는 식으로 동작하게 유도함.
- 네비게이션용: Action-Visual Streaming
- 이전 action 후에 다음 screenshot이 들어오고
- 그걸 바탕으로 다음 action을 예측
- 즉
- ... screenshot_t → action_t → screenshot_t+1 → action_t+1 ...
- 이런 interleaved sequence로 다룸
- 모바일은 앱 전환 등으로 화면 변화가 커서 스크린샷 히스토리가 중요함
- 그라운딩용: Action-Query Streaming
- grounding 또는 one-step action용
- grounding: 화면 안에서 특정 UI 요소가 어디에 있고 어떤 역할이고 어떨 때 누르는지
- 한 screenshot에 대해 여러 query/action이 붙을 수 있음
- 그런데 screenshot token은 1K 이상으로 길고
- query/action은 10 token 이하로 짧은 경우가 많음
- screenshot 하나마다 action 하나씩 따로 학습하면 비효율적임
- 그래서
- 하나의 screenshot에 대해
- 여러 query-action pair를 multi-turn처럼 묶어서
- 한 번의 forward pass에서 여러 action을 학습함.
- Training strategy / 데이터 구성
- 핵심 철학
- 데이터를 무작정 많이 쓰지 않음
- 작고 질 좋은 instruction-following 데이터를 선별해서 사용
- Web 데이터
- 웹은 수집하기 쉽고 텍스트가 많음
- 그런데 static text가 40% 정도를 차지함
- 대부분의 VLM이 OCR을 이미 꽤 잘한다고 보고 button, checkbox 같은 시각적으로 중요한 요소 위주로 선택함
- Desktop 데이터
- 데스크톱 데이터는 자동 수집이 어렵고 양도 적음
- OmniAct 데이터를 사용
- 원래는 단순 element name만 있었는데
- GPT-4o를 이용해 query를 다양화함
- appearance query
- spatial relationship query
- intention query
- 예:
- “message_ash”
- → “A가 적힌 파란 채팅 카드”
- → “Clara의 채팅 박스 위”
- → “Ash에게 사진 보내기”
- 이런 식으로 annotation 다양성을 늘림.
- Mobile 데이터
- Android 기반 데이터 사용
- 단순 element name뿐 아니라
- 기능 설명(functionality description)이 있는 데이터를 중요하게 봄.
- Navigation 데이터
- GUIAct의 web/mobile trajectory를 사용.
- 전체 학습/설계 순서
- 1단계: screenshot을 visual token으로 바꿈
- patch 단위로 쪼갬
- UI connected graph 구성
- 2단계: redundant patch를 component 단위로 파악
- 같은 component 안의 token 일부만 선택
- 위치 정보는 유지
- 3단계: query + action space 설명 + screenshot/history를 interleaved sequence로 넣음
- 4단계: 다음 action을 JSON 형식으로 생성
- 5단계: grounding / one-step action / multi-step navigation을 같은 프레임워크 안에서 instruction tuning.
- 실험
- 그라운딩 실험
- 아이콘이 텍스트보다 어려움. 모바일에서 더 심함
- 적은 양의 데이터 & 작은 모델 사이즈로 좋은 성능을 냄
- 네비게이팅
- 모바일
- 모바일은 이전 화면 히스토리를 넣는게 정확도가 더 좋았음
- 모바일은 화면이 바뀌는게 커서 그런듯 함
- 제로샷이 잘 되지는 않았지만 발전 가능성은 있어보임
- html과 같은 오라클 정보 없이, 외부 API 모델을 사용하지 않고 standalone 모델로도 효과적임
- 웹
- 모바일만큼 스크린샷 히스토리가 중요하지 않았다
- 크로스
- 크로스 타스크/도메인/웹사이트에서 정확도가 낮아짐. 못 보던 ui에 잘 안 됨
- 좀 더 general 하게 ui를 다룰 수 있도록 학습이 필요함
- fine tuinng으로 인한 성능 차이가 큼
- ui 변화에 대비하여 zero shot에서도 잘 되는 방향으로 가야 함
- 토큰 머지 안 하는게 정확도에 더 좋음
- 토큰 셀렉션
- 어느 특정 레이어에서 하는 것보다 섞어서(cross)하는게 제일 좋았음
- 너무 초반에 하면 정보를 잃을 수 있고, 너무 마지막에 하면 유추한 정보를 잃을 수 있음
- 다하면 너무 정보가 압출 될 수도 있음
- 학습 시 밸런스 맞춰서 학습시키는게 가장 좋았음
Share article