안녕하세요 🐰

저희는 On Device상의 (인지/판단/실행) 모델 파이프라인 기술 개발 과제를 수행 중인 SKT AI Fellowship 6기 O.DA (On Device AI) 팀 이선민, 장윤서 입니다.

이번 포스트에서는 저희가 중간 발표까지 3개월동안 진행한 연구 내용에 대해 말씀드리겠습니다.

1. 연구 과제 및 목표

(1) 연구 과제

저희는 사용자로부터 받은 다양한 입력을 직접 인지, 판단, 실행할 수 있는 모델 파이프라인을 연구하고 있습니다.

인지, 판단 파이프라인은 사용자로부터 다양한 입력(ex. text, audio, image 등)을 받으면 On-Device 내에서 사용자의 입력을 처리하고 sLLM을 이용해 사용자의 의도를 파악합니다.

예를 들어 사용자가 “8월 22일에 SKT 중간 발표 일정을 등록해줘.”라고 말한다면,

사용자의 오디오를 prompt로 처리하여 sLLM에게 전달하면 sLLM은 ‘캘린더앱’을 열어야한다는 판단을 내리고 사용자의 task와 열어야하는 앱 정보를 실행 파이프라인에게 전달해줍니다.

실행 파이프라인은 해당 정보들을 전달받아, 디바이스 내에서 앱을 이용해서 사용자의 task를 실행합니다.

이때, ‘캘린더 앱’ 내에서 ‘SKT 중간 발표’라는 일정을 등록하기 위해 클릭해야하는 요소들, 전환되는 UI들을 메모리에 저장하고 추후 사용자가 다시 ‘캘린더 앱’을 이용하고자할 때,

서버 연결없이 바로 실행될 수 있도록 합니다.

(2) 연구 목표

인지, 판단 파이프라인은 기존에 존재하는 ML framework와 경량화 모델을 이용해서 개발할 수 있지만,

실행 파이프라인은 실행 모델 개발부터 메모리에 저장하고 온디바이스 내에서 실행될 수 있도록 개발해야했습니다.

그래서 저희는 중간 발표까지 3개월 동안 가장 많은 시간을 할애하여 ✨실행 파이프라인 개발✨했습니다.

2. 실행 파이프라인 개발

실행 파이프라인은 인지, 판단 파이프라인으로부터 내려온 사용자의 task와 실행해야 할 앱 정보가 모바일 기기에서 실행으로 이어질 수 있도록 단계별로 작업을 수행합니다.

만약 "8월 22일에 SKT 중간 발표 일정을 등록해줘." 라는 Task와 '캘린더' 앱 정보가 전달되었다면,

우선 agent가 Task를 해결하기 위해 어떤 UI 요소들에 어떠한 액션을 취해야 하는지 서버에서 결정하고, 결정된 UI요소에 액션을 취해서 UI 전환을 일으킵니다.

다음으로 이 UI 전환을 그래프 데이터로 기록해 UI Transition Graph를 생성하고, 서버 메모리에 저장합니다.

이 UTG는 다음에 사용자가 똑같은 Task를 요청했을 때, 가이드 역할을 합니다.

실행 파이프라인은 UTG를 사용자 모바일로 전송하여 온 디바이스에서 미리 결정된 액션을 단계별로 실행하고, 최종적으로 같은 Task가 재실행되게끔 합니다.

(1) LAM AI Agent 개발

위에서 실행 파이프라인은 Task가 주어졌을 때,

먼저 어떤 UI 요소들에 어떠한 액션을 취해야 하는지 서버에서 결정하고, 결정된 UI요소에 액션을 취해서 UI 전환을 일으키고 이를 UTG로 저장해야 한다고 설명했습니다.

저희는 LAM AI Agent를 개발하여 이 부분 작업이 파이프라인 안에서 자동으로 수행되게끔 하였습니다.

UI Transition

휴대폰 홈 버튼에서 캘린더 앱 아이콘을 누르면 캘린더 화면으로 넘어가는 것 처럼, 모바일 기기에서 한 UI 화면이 다른 UI 화면으로 넘어가는 경우 UI Transition (UI 전환)이 일어났다고 지칭합니다.

A. LAM의 개념

LAM은 Large Action Model 의 약자입니다. LLM (Large Language Model)은 텍스트로 된 프롬프트를 받아 텍스트로 된 답변을 생성합니다.

반면 LAM은 텍스트 프롬프트를 받아 모바일/웹 액션을 수행하는 새로운 형태의 모델 개념입니다.

저희의 LAM AI Agent는 사용자의 Task와 앱 정보를 텍스트 프롬프트로 입력받아 기기에서 UI 전환을 일으킴으로써 모바일 액션을 수행합니다.

B. LAM AI Agent 의 작동 방식

그럼 앞서 언급한 LAM AI Agent의 실행 단계들을 좀 더 자세히 설명해보겠습니다.

LAM AI Agent는 어떤 UI 요소들에 어떠한 액션을 취해야 하는지 결정하는 데에 LLM 추론을 사용합니다.

LAM 내부에는 LLM 추론을 수행하는 LLM 엔진이 있고, 이 LLM 엔진은 LAM agent와 상호작용해 결정된 액션들을 수행하고, 전환을 일으켜 이를 UTG로 저장하며, 최종적으로 Task를 수행하게 됩니다.

사용자가 “ 연락처 앱 켜서 Stephen Bob의 새 연락처를 12345678900로 저장해 줘.” 라는 Task를 요청했다고 가정해 봅시다.

LAM AI agent 안의 LLM 엔진은 전달받은 Task를 완료하기 위해 필요한 작업들을 다음과 같이 단계별로 자동 생성합니다.

1. 연락처 앱 시작

2. 연락처 탐색

3. 새 연락처 생성

4. 이름 작성

5. 번호 작성

6. 새 연락처

LLM은 매 action step에서 먼저 이전에 수행한 액션들과 현재 UI 상태 정보를 제공하는 chain of thought 프롬프트를 입력받아 Task가 완료 되었는지,

완료 되지 않았다면 어떤 UI 상태로 가야할지 추론한 다음, 해당 UI 상태로 전환하기 위해 어떤 UI 요소에 어떤 action을 해야할 지 답변합니다.

UI 상태

홈 화면, 캘린더 화면과 같이 모바일 기기의 각 화면 상태를 지칭하는 용어입니다.

LAM agent는 이 action step을 디바이스에서 play해 UI 전환을 발생시킵니다.

agents는 각 action이 수행될 때마다 자동으로 app을 탐색하여 각 UI 단계별로 구성요소를 파악하고 UI Transition Graph를 생성합니다.

LAM agent가 이 action step을 디바이스에서 실행하면 UI 전환이 일어나게 됩니다.

agents는 각 action이 수행될 때마다 자동으로 app을 탐색하여 각 UI 단계별로 구성요소를 파악하고 UI Transition Graph를 생성합니다.

Agent는 화면을 스크롤하며 app을 탐색합니다.

연결된 기기에서 스크롤 이벤트를 보내 현재 화면(current state) 정보를 가져옵니다.

current state에는 UI 각 요소인 view 정보가 담겨있습니다.

View 란?

여기서 view를 더 자세히 설명하자면, view는 우리가 핸드폰 화면을 볼 때 상호작용할 수 있는 화면의 각 요소들입니다.

클릭할 수 있는 버튼, 텍스트 입력을 할 수 있는 입력 칸 등이 이에 해당됩니다.

예를 들어 연락처 앱 시작 화면에서 새 연락처 추가 버튼, Search 란, 정렬 및 필터 아이콘, 즐겨찾기 버튼 등이 모두 view에 포함됩니다.

각 view는 클릭이나 텍스트 입력 등 사용자의 Action을 전달받으면 새로운 UI 화면을 불러오게 됩니다.

이를 현재 UI 화면에서 새 UI 화면으로의 전환(Transition)이라고 합니다. 이렇게 화면 전환을 일으키는 액션들을 이벤트(Event)라고 합니다.

Agent는 각 view의 정보들을 긁어와 view 설명과 처리 가능한 액션 정보를 추출하고 메모리에 저장합니다.

예를 들면, 새 연락처 추가 버튼의 경우 view 설명에는 “새 연락처 추가”가 들어갈 것이고 처리 가능한 액션은 클릭이 될 것입니다.

LLM engine은 주어진 Task와 이전에 수행한 Action 기록, 그리고 현재 UI state 정보를 포함해 프롬프트를 작성하는데 이때 UI 탐색기가 저장한 view 정보를 가져와 현재 UI state 정보로 사용합니다.

다음은 LLM Engine 테스트에서 생성한 입력 프롬프트입니다.

LLM은 프롬프트에서 주어진 Answer 가이드라인에 따라 Task가 완료되었는지,

만약 안 되었다면 현재 UI단계에서 어느 UI단계로 가야하는지 답변하고 그 후 필요한 action step을 답변하도록 유도되며 Chain of Thought 추론을 수행하게 됩니다

CoT (Chain of Thought)

Chain of Thought (CoT) 추론은 LLM이 주어진 질문을 여러 개의 작은 단계로 나누어 답변하게끔 하는 가이드를 프롬프트와 같이 입력함으로써 복잡한 문제에 대한 더 논리적인 추론을 유도하는 방법론입니다.

LLM Engine은 위와 같은 답변 생성 가이드를 입력 프롬프트에 포함해 LLM에게 전달합니다.

답변 생성 가이드에 따라 LLM은 다음과 같은 단계를 거쳐 최종적으로 수행할 액션을 결정하게 됩니다.

1. Task 완료 여부 판단 : 이전 액션들로 인해 Task가 완료 되었다고 판단될 시 'Finished'값을 'Yes’로, 아니라면 “No”로 답변하시오

2. 다음 UI 화면 단계 결정 : Task가 완료되지 않았을 경우 현재 UI 상태와 이전 액션들을 분석하여, 다음 UI 화면 단계를 ‘Next step' 값에 답변

3. 상호작용할 view 결정 : 다음 UI 화면 단계로 가기 위해 상호작용할 UI 요소의 ID를 ‘id’값에 반환하며, Task가 완료된 경우 '-1'로 설정합니다.

4. (최종) 다음 액션 결정 ('action') : 상호작용할 view id에서 수행할 액션을 '’action’값에 답변합니다.

LLM은 가이드라인에 따라 다음에 가아하는 UI 단계를 답변하고 (responce - step) 해당 step으로 가기 위해

트리거할 view id, 수행되어야 할 action type, 그리고 텍스트 입력이 필요할 시 입력될 텍스트를 답변하게 됩니다.

agent는 메모리의 <각 view id별 처리 가능한 이벤트 정보를 나타내는 available actions 데이터에서 id가 일치하는 view를 찾아

현재 ui 단계 (state) 트리거할 view, action 형식 및 입력 텍스트값으로 이루어진 event 를 생성하고 디바이스로 전달해 수행합니다.

UTG (UI Transition Graph) 란?

LAM AI Agent는 UI 전환(Transition)을 일으키고 UTG를 생성해 메모리에 저장한다고 앞서 설명하였습니다. UTG의 형식을 좀 더 자세히 알아봅시다.

하나의 UI 단계 step1 홈 화면에서 특정 이벤트 - 카메라 앱 터치를 수행해 카메라 앱이 켜진 UI 단계 step2로 전환되었다고 가정해봅시다.

이 때 각 State를 그래프 각 노드로 만들고, 각 이벤트가 기존 노드와 새 노드를 연결하는 edge가 되게 하면 전환을 graph 형식으로 표현할 수 있습니다.

LAM AI Agent가 Task를 수행하며 단계별로 앱 화면 전환을 기록하면 위와 같은 UTG가 생성됩니다.

agent는 매 action step이 끝날 때마다 가장 최근에 일어난 event, 이전 UI단계와 새 UI단계를 업데이트하고 UTG에 last event로 새 edge를, current state로 새 노드를 작성합니다.

이렇게 작성된 UTG는 메모리에 저장됩니다.

마지막으로 저희가 안드로이드 가상 머신에서 테스트한 LAM AI Agent Demo 입니다. (🔗 LAM AI Agent Demo 영상 확인하기)

(2) LAM AI Agent 실험

저희는 목표했던 일정보다 빠르게 LAM 파이프라인을 개발하게 되어,

중간발표에 저희가 개발한 LAM AI Agent를 실험하면서 발생한 문제점을 정의하고 선행 연구 조사를 통해 후반기 연구에서 LAM AI Agent를 개선하기 위해 적용할 방법들을 조사하고 발표할 수 있었습니다.

A. Task Completion Experiment (Prompt 관점)

먼저 저희가 개발한 LAM은 LLM CoT(Chain of Thought)를 이용해 app action이 실행되므로, LAM에 들어가는 prompt만 달리하면서 task completion 정도가 얼마나 달라지는지 실험했습니다.

Task에 대해 자세한 direction 없이 in, about과 같이 모호한 전치사를 사용해서 작성했던 prompt들은 모두 task를 제대로 실행하지 못했던 실험 결과를 확인할 수 있었습니다.

하지만 해당 text가 들어가야할 부분을 정확하게 지시하여 prompt를 작성했더니 task completion rate가 높아지는 것을 확인할 수 있었습니다.

이 실험을 통해, 저희는 CoT를 위한 prompt가 어떻게 작성되어 들어오느냐에 따라 task completion 결과가 달라진다는 것을 알게되었습니다.

그래서 저희 팀은 후반기 연구에서 상황에 맞는 prompt가 LAM에 전달될 수 있도록 on device llm을 In Context Learning을 진행할 예정 입니다.

B. Task Completion Experiment (UI Component 관점)

하지만 실험을 진행하다보니, prompt를 어떻게 조합해도 도저히 task를 성공할 수 없는 경우가 있었습니다. 바로 UI component(아이콘) 자체를 못잡는 문제였습니다.

위 사진은 UI component를 잘 잡았을 경우입니다. 전화번호부에서 선민의 전화번호를 찾아 누르고, 전화기 아이콘을 클릭하여 전화하는 task입니다.

출력된 CoT를 살펴보면 button을 클릭하라는 step에서 touch event가 발생했고, memory에서 touchevent가 발생한 view ID를 찾아 확인해보면 전화기 아이콘이 잘 캡처되어 저장되어있는 걸 확인할 수 있습니다.

Utg state도 확인해보면 해당 event에서 전화번호부 UI에서 전화거는 UI로 UTG가 잘 생성되어있음을 확인할 수 있습니다.

이렇게 CoT, Memory, UTG를 통해, task에 맞는 app action이 제대로 수행되었음을 알 수 있습니다.

위 사진은 UI component를 제대로 잡지 못했을 경우입니다. 이 경우를 살펴보면, 전화번호부에서 플러스 버튼을 찾아 두번째 번호를 저장하는 task 였습니다.

출력된 CoT를 살펴보면 button으로 저장되어있는 view ID가 플러스 버튼이 아닌 ‘Mobile’ 이라는 뜬금없는 버튼으로 저장되어있음을 확인할 수 있었습니다.

이런 문제가 발생하는 이유는 앞에서 설명드렸듯이 LAM agent가 각 view의 정보들을 긁어와 메모리에 저장하는 과정에서 view 정보 자체를 잘못 가져왔기 때문입니다.

그래서 Final output 외 CoT, Memory, UTG state를 모두 확인해봐도 task가 제대로 이루어지지 않았다는 것을 확인할 수 있었습니다.

이 경우 처럼 앱 내 아이콘을 클릭해야할 경우, UI Component view를 제대로 잡아내지 못하는 경우가 있기 때문에

저희는 후반기 연구에서 UI component tag가 되어있는 RICO dataset을 Region Representation Model에 학습시켜 UI region을 정확하게 가져올 수 있는 모델을 개발할 예정 입니다.

그리고 저희는 UTG의 state와 view를 포지션, 메타 정보 및 텍스트 데이터로 encoding 시켜주는

UI Transformer를 개발하여 UI component에 대한 이해도가 낮을 경우 이 UTG Transformer를 이용해서, UTG를 생성하도록 학습시킬 예정 입니다.

3. 인지, 판단 파이프라인 개발

8월 중순에 실행 파이프라인에 대한 개발이 마무리되어,

저희는 중간 발표가 있는 8월 말까지 Google Mediapipe를 이용해 사용자의 multi-modal input을 받아 처리할 수 있는 인지 파이프라인과

Google Gemma를 이용해 사용자의 task를 판단할 수 있는 판단 파이프라인을 개발하고 있었습니다.

현재는 실제 단말기 내에 Google Gemma 2B 모델을 넣어 온디바이스화하였고,

앞으로 9월 초까지 디바이스 내에서 사용자의 multi-modal input을 받을 수 있는 인지 파이프라인을 구축하여 Google Gemma 2B 모델을 이용한 판단 파이프라인과 연결할 예정입니다.

4. 연구 Contribution

(1) LAM AI Agent

저희 연구는 LAM(Large Action Model)을 사용해 사용자의 task를 파악하고 정보만을 제공해주는 기존 LLM 기술에서 벗어나 사용자의 task를 직접 실행시켜주는 기술을 적용하고 있습니다.

예를 들어 사용자가 교토 여행을 위해 숙소를 잡고 싶을 때, LLM은 사용자의 조건에 맞는 숙소를 추천하여 숙소에 대한 정보를 제공해줄 수 있습니다.

반면 LLM에 LAM을 적용한다면, 사용자의 조건에 맞는 숙소를 제공해줄 뿐만 아니라 숙소 예약까지 한번에 실행할 수 있게 됩니다.

이번 연구를 통해 저희는 ✨최근 주목받고 있는 LAM을 이용해 기존 LLM이 실행까지 이어지기 어렵다는 한계를 극복하고, app action 자동화할 수 있는 LAM AI Agent를 개발하는 연구✨ 를 진행하고 있습니다.

(2) On-Device

저희 연구는 디바이스 내에서 App action을 자동화해야하므로, 필요한 단계들을 작고 빠르고 편하게 처리하기 위해 온디바이스 기술을 적용했습니다.

저희는 사용자로부터 받은 multi-modal input을 처리하는 온디바이스 ML framework와 사용자의 task를 온디바이스에서 처리할 지,

서버에서 처리할지 판단하는 온디바이스 sLLM 모델을 연결하는 연구를 진행하고 있습니다.

Task가 이전에도 반복적으로 실행되었을 경우, memory DB를 이용해 server 없이 온디바이스 내에서 LAM 모델이 실행되도록하는 온디바이스 Event Play Engine도 개발하고 있습니다.

온디바이스 내부에서 사용자의 정보를 처리하기 때문에, 사용자의 개인 데이터에 대한 프라이버시를 지킬 수 있다는 장점도 있습니다.

이번 연구를 통해 저희는 ✨최근 주목받고 있는 온디바이스 기술을 이용해서 디바이스 내에서 사용자의 의도를 파악하고 앱 액션을 자동화하는 On Device Event Play Engine을 개발✨하고 있습니다.

(3) Pipeline

Pipeline

서비스 상황에 맞는 특정 Task에 특화된 모델 및 작은 기능 단위의 연계를 위해 각 단계에서 요구되는 작업들을 자동화하여 최종 목표까지 효율적으로 도달할 수 있게 하는 워크플로우

저희 연구는 여러 온디바이스 기술을 엮어서 사용해야하기 위해, 파이프라인 기술을 적용했습니다.

저희는 온디바이스 ML과 온디바이스 LLM을 엮어 들어오는 멀티모달 input에 대한 파라미터를 LLM에서 처리하여 task에 대한 skillset을 전달해주는 인지, 판단 파이프라인을 개발하고 있습니다.

이때 skillset은 LAM이 task를 앱에서 실행하기 위해 LLM으로부터 전달받는 text prompt 단위라고 생각하시면 됩니다!

그리고 LAM이 skillset을 전달받아 모바일에서 최종적으로 앱 액션을 실행하는 실행 파이프라인도 개발하고 있습니다.

이번 연구를 통해 저희는 ✨여러 모델들을 이용해 효율적으로 인지, 판단, 실행까지 가능한 파이프라인을 개발✨하고 있습니다.

(4) 기존 연구와의 차별점

RPA vs. Our Research

자동화 기술은 전통적으로 RPA (Robotic Process Automation) 분야에 연구되고 있었습니다.

RPA는 사전에 사용자 또는 개발자가 해당 Task를 수행하는 방법을 정의해줘야만 작동이 가능합니다.

따라서 정해진 Task만 수행이 가능하다는 한계점이 발생합니다.

그래서 저희 연구는 서버가 아닌 온디바이스에서 Flexible하게 새로운 task를 자동화할 수 있는 모델 파이프라인을 만드는 것이 목표입니다.

RPA 예시로 아이폰의 단축어 기능을 들 수 있습니다. 사진은 예약 문자 보내기 단축어를 사전에 설정하는 화면입니다.

Service vs. Our Research

• Apple Intelligence

  올해 6월 11일, 애플의 WWDC 2024에서도 LAM을 이용한 서비스가 발표되었습니다.

  새로운 기능인 Apple Intelligence 중에서는 App intent는 Siri를 이용해서 사용자의 특정 task를 실행하는 기능이 포함되어 있습니다.

• Google Live Gemini

  Google의 Gemini Live는 2023년 10월, Google이 새로운 하드웨어(예: Pixel 9 스마트폰)와 함께 발표된 기능입니다.

  Gemini Live는 사용자와 인간처럼 대화하며 사용자의 요구를 파악하고 LAM 기술을 활용해 여러 앱에서 Task를 수행할 수 있습니다.

하지만, 기존 연구들에 대한 어떤 기술적 방법 api를 노출되지 않은 상황입니다.

Piepline 기술을 적용한 것이 아니라, 서비스 형식으로 발표되었기 때문에 Rabbit, Apple, Google을 통해 PAA 서비스가 필요해졌다는 것을 알게 되었고

저희는 이런 PAA 서비스를 Pipeline으로 구현했다는 것이 기존 연구와의 차별점이라고 볼 수 있습니다.

5. 후반기 연구 계획

중간 발표를 진행한 후, 멘토님들과 Fellowship 동료들로부터 소중한 피드백을 받게 되었습니다.

그래서 피드백들을 바탕으로 저희 향후 계획을 수정해보았습니다.

저희가 10월 말까지 후반기 연구에서 집중할 부분은 크게 세 가지입니다.

💡LAM AI Agent 개선 연구

• Prompt로 인해 CoT가 정확한 추론을 유도하지 못하는 문제를 해결하기 위해, sLLM을 Incontext Learning할 예정

• UI Component를 탐색할 때 특정 view를 잡지 못하는 문제를 해결하기 위해, UI Representation Model을 개발하여 적용할 예정

• LLM Engine에서 LLM이 앱 정보를 몰라 부정확한 추론을 하는 문제를 해결하기 위해, UTG 데이터를 학습시킨 UTG Transformer를 개발하여 적용할 예정

💡 모델 성능 평가 연구

• UI Representation Model, UTG Transformer 성능 평가 지표 결정

• UI Representation Model, UTG Transformer 성능 평가

💡 AI PAA 서비스 개발 연구

• On-Device 인지, 판단, 실행 pipeline을 이용한 PAA 서비스 개발

• Personal Mobility Service를 위한 최종 user 시나리오 개발

6. 중간 발표까지 회고

저희는 3개월동안 매주 1-2번씩 회의를 진행하면서, 저희가 처음 생각했던 목표보다 3개월동안 더 많은 부분들을 연구할 수 있었습니다.

처음 목표였던 LAM AI Agent 개발에서 실험까지 진행하여, 후반기 연구를 통해 개선점을 적용할 수 있는 시간을 확보할 수 있게 되었습니다.

사용자의 불편함을 해소할 수 있는 최종 유저 시나리오를 구현할 수 있도록 앞으로 남은 2개월도 초심을 잃지 않고 끝까지 연구를 완료할 예정입니다.

아직 선행 연구가 많이 없고, 다소 생소할 수 있는 저희 연구를 관심있게 봐주셔서 감사드립니다.

마지막까지 최선을 다해 연구를 마치도록 하겠습니다! 🔥

이상 🐰 O.DA 팀 🐰 의 중간 연구 결과였습니다. 감사합니다! 🥰