[LLM] ReALM: 화면을 텍스트로 재구성해 reference resolution을 language modeling으로 푸는 on-device 접근
[LLM] ReALM: Reference Resolution As Language Modeling
- paper: https://arxiv.org/abs/2403.20329
- arXiv:2403.20329v2 (‘24-08-19, v1은 ‘24-03-29)
- 저자: Apple — Joel Ruben Antony Moniz*, Soundarya Krishnan*, Melis Ozyildirim, Prathamesh Saraf, Halim Cagri Ates, Yuan Zhang, Hong Yu (* equal contribution)
- downstream task: Reference Resolution — 사용자 발화의 모호한 지시어(“그거”, “맨 아래 것”, “Rainbow St에 있는 거”)가 어떤 entity를 가리키는지 해소. 음성 비서의 전처리 모듈로 on-device 동작을 가정
- 주요 용어
- Reference Resolution: 주어진 entity 후보 집합과 사용자 query에 대해, query 수행에 필요한 entity(들)를 골라내는 태스크. 본 논문은 이를 multiple choice 문제로 정식화 — 모델은 관련 entity의 index 목록을 출력하고, 해당 없으면
0(“None of these”)을 출력 - 3가지 entity type
- On-screen Entities: 현재 사용자 화면에 떠 있는 entity
- Conversational Entities: 이전 턴에서 등장해 대화 맥락에 살아있는 entity (“Call Mom” $\to$ “Text her”의 her)
- Background Entities: 화면·대화 어디에도 없지만 배경 프로세스에서 올라온 entity (울리고 있는 alarm, 재생 중인 음악)
- Type-based vs Descriptive reference: 전자는 entity type만으로 해소되는 참조(“play this” $\to$ song/video), 후자는 entity의 속성으로 특정하는 참조(“the one in Times Square”)
- Onscreen Parse (Turn Object Injection): 화면의 entity와 주변 텍스트 박스를 bounding box 중심 좌표 기준으로 top$\to$bottom, left$\to$right 정렬해, margin 안이면 같은 줄(tab 구분) / 밖이면 다음 줄(newline 구분)로 쓰는 순수 텍스트 화면 표현. entity는 `` 형태로 태깅되어 주변 문맥 속에 “주입”됨
- MARRS: 비교 baseline이 되는 Apple의 기존 non-LLM reference resolver (Ates et al., 2023). category module + 수작업 textual-overlap feature + threshold 기반
- Reference Resolution: 주어진 entity 후보 집합과 사용자 query에 대해, query 수행에 필요한 entity(들)를 골라내는 태스크. 본 논문은 이를 multiple choice 문제로 정식화 — 모델은 관련 entity의 index 목록을 출력하고, 해당 없으면
1. Motivation
- 음성 비서가 “Call the one on Rainbow Rd.” / “Call the bottom one” 같은 발화를 처리하려면 대화 맥락 + 화면 맥락 + 배경 맥락을 모두 다뤄야 함
table1 첨부 (user-agent 대화 예시 — 동일 리스트에 대한 3가지 서로 다른 참조 방식)
- “그냥 큰 LLM 하나로 end-to-end 처리하면 되지 않나?”에 대해 저자들은 pipeline이 여전히 필요한 4가지 이유를 제시
- on-device 제약: privacy/latency 때문에 스마트폰 위에서 완전히 돌아야 하는데, 긴 프롬프트를 쓰는 대형 end-to-end LLM은 비현실적
- 시스템 통합: API 호출, upstream 컴포넌트의 출력 소비, downstream 전달이 필요한 경우 end-to-end 전환은 전체 파이프라인 재설계를 요구
- 모듈성: reference resolution 모듈만 교체 가능해야 hill-climbing과 interpretability가 확보됨
- 본 태스크는 전통적 coreference를 넘어 화면/배경 entity까지 포함 $\to$ 범용 LLM이 암묵적으로 잘한다는 보장이 없음
- 핵심 난제: LM에게 화면을 “보게” 만들기
- Vision transformer 계열은 자연 이미지 분포로 학습되어 UI 스크린샷 분포와 괴리가 크고, pre-training 비용이 큼
- text-heavy 이미지에서 성능이 떨어지고, LayoutLM류 문서 이해 모델은 bounding box detection + OCR 같은 다중 모듈과 이미지 품질에 크게 의존
- 반면 on-screen reference는 이미 upstream parser가 텍스트와 위치를 뽑아둔 상태 $\to$ 굳이 무거운 vision 모델을 쓸 필요가 없음
$\to$ (Research Question) 화면을 텍스트만으로 재구성해서, reference resolution 전체를 하나의 language modeling 문제로 환원할 수 있는가?
2. Contribution
- Reference resolution을 multiple-choice language modeling으로 재정식화. threshold 의존과 category module 수작업 온보딩을 제거하고, 여러 entity가 정답인 경우(순서 무관 집합 매칭)도 자연스럽게 지원
- 화면의 textual encoding 알고리즘 제안 (Algorithm 1). LLM으로 screen context를 인코딩한 최초의 시도라고 주장
- conversational / on-screen / background 3종 entity를 단일 모델로 동시에 처리
- 80M~3B의 FLAN-T5 fine-tuning만으로 MARRS를 전 데이터셋에서 상회, GPT-3.5를 크게 상회, 스크린샷을 입력받는 GPT-4와 대등
3. Task 정식화
- 입력: 사용자 query + entity 후보 리스트 (type과 속성 포함, upstream entity puller가 high-recall로 추출했다고 가정)
- 출력: 관련 entity의 index 집합. 없으면
0 - 평가: 예측 집합 == ground truth 집합이면 정답, 아니면 오답 (순서 무관, 즉 GT가 {8,7,4}면 어떤 permutation도 인정)
table10/table11 첨부 (단일 정답 / 다중 정답 입력 샘플)
- 실제로 모델은 유효한 정수(또는 정수 리스트)만 안정적으로 출력했고,
0과 다른 index를 동시에 뱉지 않는 등 제약도 자발적으로 지킴- 유일한 예외는 같은 entity를 연속 중복 출력하는 경우 $\to$ set으로 변환하는 것이 유일한 post-processing
4. Datasets
table2 첨부 (Conversational / Synthetic / On-screen train·test 크기)
| Dataset | Train | Test |
|---|---|---|
| Conversational | 2.3k | 1.2k |
| Synthetic | 3.9k | 1.1k |
| On-screen | 10.1k | 1.9k |
- Conversational: annotator에게 user-agent 대화와 합성 entity 리스트를 주고, 임의로 지정된 entity를 모호하지 않게 가리키는 query를 작성하게 함 (“Take me to the one that’s second from the bottom”)
- Synthetic: language template + slot list 조합으로 자동 생성. type-based reference에 특히 유효하며, 다른 type의 entity를 random negative로 섞음
- 예:
"share [mention] with [name]"+[mention]$\in$ {this address, that address} $\to$ “share that address with Mom”, GT type은 email address / physical address
- 예:
- On-screen: 전화번호·이메일·주소가 있는 웹페이지 스크린샷 수집 후 2단계 annotation
- green/red box가 그려진 스크린샷에서 green box를 entity type으로 분류하고, 그에 대한 unique query 3개 작성
- box 없는 스크린샷 + entity 리스트를 주고, query가 자연스러운지 / 어떤 entity를 가리키는지 / query의 어느 부분이 그 entity를 지칭하는지 태깅
figure1 첨부 (on-screen annotation 1차·2차 프로젝트에 쓰인 스크린샷 예시)
5. Method
5.1 Baselines
- MARRS: Apple 내부의 non-LLM reference resolver. 동일한 데이터로 재학습해 비교. reference resolution 전용 설계라는 점에서 ReALM(범용 off-the-shelf LLM)보다 유리한 조건
- ChatGPT: GPT-3.5 / GPT-4 (2024-01-24 기준) in-context learning
- GPT-3.5는 텍스트만, GPT-4는 스크린샷까지 제공 (성능이 크게 올라감)
- 저자들은 semantically similar example few-shot sampling 같은 고도화는 future work로 남김
5.2 ReALM
- backbone: FLAN-T5 fine-tuning. baseline과 달리 hyperparameter search 없이 기본 설정 사용
- entity는 입력 전에 shuffle $\to$ 특정 위치에 overfit 방지
- 각 entity는 type + 속성을
Type: LocalBusiness | Name: Walgreens | Address: ...형태의 문장으로 직렬화
table9 첨부 (alarm/app/local business/phone number 등 entity domain별 텍스트 표현)
Conversational reference
- type-based / descriptive 두 종류를 구분하지 않고, type과 속성을 그대로 인코딩하는 단일 포맷으로 흡수
- “play the one from Abbey Road” vs “directions to the one on Abbey Road”처럼 type과 description이 함께 작동하는 케이스도 동일 포맷으로 커버
On-screen reference (Algorithm 1)
algorithm1 첨부 (Turn Object Injection을 포함한 onscreen parse 구성)
- 핵심 가정: 모든 entity와 주변 객체의 위치는 bounding box의 중심점으로 대표 가능
- 절차
- 각 turn object $t$에 대해 주변 객체 집합
surrounding_objects를 구성 - turn object 자신을 `` 태그 형태로 그 집합에 주입
- 중심 좌표로 정렬: top$\to$bottom (y축) 후 left$\to$right (x축, stable sort)
|o.center_top - other.center_top| <= margin이면 같은 vertical level로 묶음- 같은 level의 객체는 tab으로, level 간은 newline으로 연결 $\to$ 좌→우, 상→하 순서의 plain text 화면
- 각 turn object $t$에 대해 주변 객체 집합
figure2/figure3 첨부 (대화 턴과 user screen을 나타낸 technical diagram — 점선 사각형이 parser가 검출하는 화면 요소)
table8 첨부 (최종 Injected Onscreen Encoding 예시 — “Save the phone number at the bottom-right”, GT 1, 2)
탐색했던 다른 인코딩 (Appendix A)
- Clustering (Algorithm 2): DBSCAN으로 주변 객체를 공간 클러스터링하고, turn object가 속한 클러스터의 객체만
surrounding_object키로 프롬프트에 넣음. 추가로distance_from_top,distance_from_left를 전역 위치 정보로 제공- 문제: 클러스터 내 entity 수가 늘면 각 객체가 서로를 surrounding으로 가져 프롬프트 길이가 폭발
table6 첨부 (clustering 기반 인코딩 예시)
- Onscreen Grab: 최종안과 유사하되 turn object를 parse 안에 태깅하지 않고 별도 리스트로 제공
table7 첨부 (Onscreen Grab 인코딩 예시)
6. Experiments
6.1 Main results
table3 첨부 (데이터셋별 모델 정확도)
| Model | Conv | Synth | Screen | Unseen |
|---|---|---|---|---|
| MARRS | 92.1 | 99.4 | 83.5 | 84.5 |
| GPT-3.5 | 84.1 | 34.2 | 74.1 | 67.5 |
| GPT-4 | 97.0 | 58.7 | 90.1 | 98.4 |
| ReALM-80M | 96.7 | 99.5 | 88.9 | 99.3 |
| ReALM-250M | 97.8 | 99.8 | 90.6 | 97.2 |
| ReALM-1B | 97.9 | 99.7 | 91.4 | 94.8 |
| ReALM-3B | 97.9 | 99.8 | 93.0 | 97.8 |
- 전 데이터셋에서 MARRS 상회. 가장 작은 ReALM-80M조차 on-screen에서 83.5 $\to$ 88.9 (+5.4pp)
- GPT-3.5는 수 자릿수 많은 파라미터에도 불구하고 전반적으로 열세. 특히 Synth 34.2로 붕괴
- GPT-4와 동급: ReALM-3B의 Screen 93.0 vs GPT-4 90.1. GPT-4가 스크린샷을 추가로 받는 조건임에도 텍스트 인코딩만으로 앞섬
- 모델 크기 효과는 on-screen에서 가장 뚜렷 $\to$ 화면 태스크가 본질적으로 더 복잡함을 시사
- Unseen(held-out domain = Alarms) 컬럼만 비단조: 80M 99.3 $\to$ 250M 97.2 $\to$ 1B 94.8 $\to$ 3B 97.8. 저자들은 double descent(Nakkiran et al., 2019)로 추정
table12 첨부 (Unseen 도메인 Alarms 샘플 — “Switch off the one reminding me to pick up didi”, GT 3)
6.2 Ablation: 인코딩 전략 (3B 기준)
figure4 첨부 (인코딩 전략별 성능 변화 a$\to$h)
- (a) Baseline Finetuned LLM $\to$ (b) OCR로 화면 요소 획득 $\to$ (c) UI element + Clustering $\to$ (d) instruction과 user request 사이 newline 추가 $\to$ (e) Onscreen Grab $\to$ (f) Onscreen Grab + injected turn objects $\to$ (g) + 줄 분리에 최소 Margin 요구 $\to$ (h) 같은 줄 요소를 tab으로 분리
- 단조 상승은 아니지만 (a)에서 (h)까지 큰 폭의 누적 개선. 즉 성능의 상당 부분은 모델 크기가 아니라 화면을 어떤 텍스트로 쓰느냐에서 나옴
6.3 Analysis
GPT-4 $\approx$ ReALM $\gg$ MARRS (새로운 use-case)
- held-out 도메인 Alarms에서 LLM 기반 접근(ReALM, GPT-3.5, GPT-4)이 모두 FT된 MARRS를 상회
- 그중 ReALM과 GPT-4는 거의 동률 (99.3 / 98.4)
table4 첨부 (ReALM이 가능케 하는 복합 능력 정성 예시 4종)
- Semantic Understanding: “Call the evening Number” $\to$
5 PM - 9 PM옆 번호인 4번 선택 - Summarisation: “Remind me to get printouts before the tax deadline” $\to$ April 18(2번) 선택
- World Understanding: “Take me to the one in Washington” $\to$ Seattle 주소(2번)
- Commonsense Reasoning: “Save the link to the breakfast Recipe” $\to$ Strawberry Granola의 Recipe link(1번)
ReALM > GPT-4 (도메인 특화 query)
table5 첨부 (“Can you make it brighter?” — GPT-4는 1(Settings)만, GT는 1, 2(home automation device))
- GPT-4는 화면의 setting만 가리킨다고 가정 $\to$ 배경의 home automation 기기도 후보라는 도메인 지식 부재
- ReALM은 도메인 데이터로 fine-tune되어 이 실패를 겪지 않음
7. Conclusion & Limitations
- 텍스트만으로 학습된 LM이 extra-linguistic context(화면, 배경)의 reference까지 해소할 수 있음을 보임. entity 후보를 자연어로 인코딩하고, 화면을 상대적 공간 관계를 보존한 텍스트로 요약하는 것이 핵심
- 파라미터가 훨씬 적으면서 GPT-4와 대등, 도메인 특화 query에서는 상회 $\to$ 성능 타협 없는 on-device reference resolution의 현실적 후보
저자들이 명시한 한계
- 정교한 공간 추론 부족: 위치 인코딩이 작동하긴 하지만, 미세한 positional 이해에 의존하는 복잡한 query는 못 풀 수 있음. 화면을 grid로 분할해 상대 위치를 텍스트로 넣는 방향을 future work로 제시
- 모든 on-screen entity가 텍스트라는 가정: 이미지·그래픽·UI 요소 커버는 본 논문 범위 밖
- anaphoric / deictic reference 중심: bridging reference 등 다른 참조 유형은 미지원
- Ethics Statement: 실제로는 hallucination이나 포맷 이탈이 거의 없어 decoding을 constrain하지 않았으나, 필요 시 제약 디코딩이 가능하다고 언급
Takeaways
- 화면 이해 = vision 문제라는 가정을 깨고, upstream parser 출력이 있다면 중심 좌표 정렬 + tab/newline 직렬화만으로 LM이 충분히 “본다”는 것을 보임
- Figure 4 ablation이 이 논문의 실질적 기여. 같은 3B 모델에서 인코딩 설계만 바꿔 성능이 크게 움직임 $\to$ 표현 설계가 모델 스케일보다 레버리지가 큼
- reference resolution을 set-valued multiple choice로 정식화하면 threshold/카테고리 모듈 같은 운영 부채가 한 번에 사라짐. 새 entity type 온보딩 비용도 제거
- 80M 모델이 Unseen 도메인에서 99.3을 찍는 등, 좁고 잘 정의된 태스크는 작은 모델로 on-device에 내릴 수 있다는 실증
- 다만 데이터셋(Conversational/Synthetic/On-screen)과 MARRS baseline이 모두 Apple 내부 자산이라 외부 재현이 불가능하다는 점은 감안 필요