[EMNLP 2025] ZoomEye: Enhancing Multimodal LLMs with Human-Like Zooming Capabilities through Tree-Based Image Exploration

안녕하세요. 이번에는 ZoomEye: Enhancing Multimodal LLMs with Human-Like Zooming Capabilities through Tree-Based Image Exploration 논문을 읽어보았습니다. 요즘 MLLM 추론 연구가 죄다 “텍스트를 더 길게 생각하게 만들자”로 흘러가는데, 이 논문은 이미지 자체를 트리로 놓고 사람처럼 확대/축소하면서 찾아보게 하자는 이야기를 합니다. 학습이 전혀 필요 없는 방법이라는 점도 재밌는 부분입니다. 그럼 시작해보겠습니다!

---

1. Introduction

MLLM의 추론 능력을 끌어올리려는 시도는 지금까지 대부분 text-level이었습니다. o1이나 DeepSeek-R1이 보여준 test-time scaling을 멀티모달로 가져와서, LLM backbone이 토큰을 더 많이 뱉게 만드는 식이죠. 그런데 이 논문이 지적하는 핵심은 바로 그 과정에서 시각 입력은 처음부터 끝까지 고정되어 있다는 것입니다.

이게 왜 문제가 되냐면, 이미지 인코더가 받을 수 있는 해상도는 정해져 있는데 실제 이미지는 4032×4032, 심하면 7680급도 들어오는 경우도 있습니다. 다운샘플링 한 번 거치고 나면 작은 물체는 이미 정보가 소실되거나 날아간 상태인데, 그 상태로 텍스트를 아무리 길게 생각해봐야 없는 정보가 생기지는 않는다는 거죠.

Figure 1을 통해 예시를 들 수 있을 것 같네요. 위쪽이 conventional MLLM인데요. 4032×4032 이미지를 주고 “배경 산의 색이 뭐냐”고 물으면 gray라고 잘 맞춥니다. dominant한 물체니까 잘 답변하는 것이죠. 그런데 “배에 적힌 숫자가 뭐냐”고 물으면 12라고 틀립니다. 정답은 15입니다. 배는 전체 이미지에서 아주 작은 영역이라 인코더 해상도로 줄이는 순간 뭉개져 버리는 거죠.

아래쪽이 본 논문에서 제안한 방법론인 Zoom Eye를 붙인 경우입니다. 산 색깔은 그냥 바로 답하고(“I could answer the question directly”), 배 숫자에 대해서는 “I could not answer the question”이라고 판단한 뒤 이미지를 4분할해서 patch별 confidence를 계산합니다. Confidence 3이 0.55로 제일 높으니 3번으로 파고들고, 거기서 또 나누고… 하다가 배가 충분히 크게 보이는 시점에 “I could answer the question now. The number is 15″로 끝냅니다.

저자들이 말하길, 해당 행동들은 사람이 고해상도 이미지를 볼 때 하는 행동 그대로인데요. 일단 전체를 훑고, 관심 영역으로 확대하고, 없으면 다시 축소해서 다른 데를 본다. 이걸 MLLM에게 시키기 위해서 이미지를 루트가 전체 이미지, 자식이 확대된 부분 영역, 깊이가 곧 배율인 트리로 보게 한 것이죠.

Figure 2가 실제 탐색 행동을 보여주는데요. (a)는 정보가 충분해서 바로 답하는 경우, (b)는 점점 확대해 들어가는 경우, (c)가 개인적으로 제일 중요하다고 보는 부분인데 backtracking입니다. 빨간 점선이 zoom out인데요. 수영장 쪽으로 파고들었다가 튜브가 없으니 되돌아 나와서 다른 가지로 가는 모습입니다. 단순히 “한 번 더 확대해서 본다”를 위해서가 아니라 틀린 가지를 포기하고 돌아올 수 있다는 게 트리 탐색을 쓰는 이유라고 보시면 되겠습니다.

Contribution을 정리하면 다음과 같습니다.

1. Method: 이미지를 계층적 트리로 모델링하고 그 위를 탐색하는 training-free, model-agnostic 알고리즘 Zoom Eye 제안.
2. Performance: 여러 MLLM에 붙여서 일관된 성능 향상 확인. 3~8B 모델이 GPT-4o를 넘김.
3. Analysis: 실패 케이스를 통해 현재 MLLM의 시각 이해 결함(방향 인식, global-local 위치 관계)을 드러냄.
4. Finding: 탐색 스텝이 늘어날수록 성능이 오르는 vision-level test-time scaling 현상을 관찰.

2. Preliminary

방법론에 들어가기 전에 이미지 전처리 방식을 간략하게 정리하고자 합니다.

먼저, naive resize입니다. naive resize는 말 그대로 이미지를 미리 정한 해상도로 줄여서 인코더에 넣는 방식을 의히마는데요.

$\mathcal{F}$가 vision encoder, R이 resize입니다. 구조가 단순한 대신 해상도가 고정이라 손실이 크게 발생할 수 있죠.

AnyRes는 원본을 동일 면적 블록 여러 개로 나누고(최대 M개) 각 블록과 전체 이미지를 따로 인코딩한 뒤 합칩니다.

$a \le M$이고, $a = 0$이면 naive와 같아집니다.

여기서 미리 감을 잡아두면 좋은 게 있는데요. AnyRes를 쓴다고 해상도 문제가 해결되지는 않는다는 것입니다. 블록 수에 상한 M이 있으니 원본이 8K급이면 각 블록도 여전히 크고, 그 블록을 또 인코더 해상도로 줄여야 하니까요.

3. Methodology

3.1 Abstraction of Tree Search

먼저 트리 탐색을 ($\mathcal{T}, \mathcal{Q}, \mathcal{R}, \mathcal{S}$) 4개 요소로 추상화합니다.

• $\mathcal{T}$: 노드 집합으로 이루어진 트리 구조
• $\mathcal{Q}$: 다음 스텝에 방문할 수 있는 후보 노드를 담는 컨테이너
• $\mathcal{R}$: 우선순위가 가장 높은 노드를 고르는 랭킹 함수
• $\mathcal{S}$: 종료 조건

탐색 자체는 아주 평범합니다. $\mathcal{Q}$에서 노드를 꺼내고, $\mathcal{S}$를 만족하면 멈추고, 아니면 자식들을 $\mathcal{Q}$에 넣고 $\mathcal{R}$로 정렬한다.

그래서 Zoom Eye를 구현한다는 건 다음의 질문에 답변하는 것과 같은데요. (1) 이미지를 어떻게 트리 $\mathcal{T}$로 만들 것인지, (2) 랭킹 함수 $\mathcal{R}$을 어떻게 정의할 것인지, (3) 종료 조건 $\mathcal{S}$를 어떻게 잡을 것인지. 아래에서 하나씩 보도록 하겠습니다.

3.2 Tree Representation for Image

노드 n_t는 이미지 패치 뷰 $\{\mathbf{I}, \mathbf{b}_t\}$입니다. $\mathbf{I}$는 원본 이미지, $\mathbf{b}_t = (x_{1,t}, y_{1,t}, x_{2,t}, y_{2,t})$는 정규화된 bounding box 좌표입니다.

분할 규칙은 단순합니다. 노드의 패치 크기가 인코더의 사전 정의된 해상도를 넘으면 동일 크기 4등분해서 자식으로 삼고, 해상도 한계에 닿을 때까지 재귀적으로 나눕니다. 루트는 $\mathcal{T}.\text{root} = \{\mathbf{I}, (0,0,1,1)\}$, 전체 이미지죠.

그 다음에 노드를 모델에게 어떻게 보여줄까는 Figure 3를 통해 확인할 수 있는데요.

• Local Input: 로컬 패치만 넣습니다. naive 전처리를 쓰는 초기 단일 이미지 MLLM용(예를 들어서 LLaVA-v1.5 등)입니다.
• Global + Local Input: 전역 이미지와 로컬 패치를 같이 넣습니다. AnyRes를 쓰는 최신 MLLM용이고, 전역 이미지에는 빨간 사각형의 visual prompt를 그려서 지금 보고 있는데가 여기다라는 것을 표시합니다.

식으로 정리하면 다음과 같습니다.

Global+Local 쪽을 보면 전역에는 naive resize를, 로컬 패치에는 AnyRes를 적용합니다.

3.3 Ranking Function

여기가 본 논문의 핵심이라고 느껴지는 데요. 노드를 어떤 순서로 볼 것인지를 정해야 하는데, Zoom Eye는 별도 모델을 쓰지 않고 MLLM 자기 자신에게 물어봅니다.

질문에 답하는 데 필요한 시각 단서를 o라고 하면, 모델에게 필요한 능력은 두 가지입니다.

1. 지금 보이는 뷰 안에 o가 존재하는지 지각하는 능력
2. o가 너무 작아서 잘 안 보이더라도, 상식을 동원해서 더 확대하면 찾을 수 있을 것 같은지 추론하는 능력

이 두 개를 각각 프롬프트 $p_e(o)$, $p_l(o)$로 수행합니다. 실제 프롬프트는 “Is there a {o} in the image?”와 “According to your common sense knowledge and the content of the image, is it possible to find a {o} in the image?”입니다. 그리고 다음 토큰이 “Yes”일 확률과 “No”일 확률의 비율을 confidence로 씁니다.

$z_1$이 Yes 로짓, $z_2$가 No 로짓입니다. 0.5를 빼고 2를 곱해 (-1,1)로 옮긴 거라 부호가 곧 판단을 뜻하고, 절댓값을 확신의 세기로 볼 수 있습니다. 이렇게 얻은 두 값이 각각 existing confidence $c_e$와 latent confidence $c_l$입니다.

최종 우선순위는 이 둘의 가중합으로 보시면 되겠습니다.

Algorithm 2가 랭킹 함수와 종료 조건을 합쳐놓은 것인데요. 13번 줄이 위의 가중합이고, 16~20번 줄이 Yes/No 로짓 비율을 나타냅니다.

3.4 Stopping Criterion

종료 조건은 훨씬 단순한데요. “지금 뷰로 이 질문에 답할 수 있겠냐”를 프롬프트 $p_a(q_s)$로 묻고, 같은 방식으로 answering confidence $c_a$를 뽑습니다. 그리고 $c_a \ge \tau$면 탐색을 끝냅니다.

여기서 $\tau$를 어떻게 잡느냐가 은근히 까다로운 문제인데요. 너무 낮으면 엉뚱한 패치에서 멈춰서 잘못된 근거로 답하게 되고, 너무 높으면 트리에 있는 어떤 노드도 $\tau$를 못 넘어서 전체를 다 뒤지게 됩니다. 그래서 저자들은 $\tau$를 점진적으로 낮추는 스케줄러를 사용했다고 합니다.

3.5 Overall Search Algorithm

전체 흐름을 순서대로 보면 이렇습니다.

<(1) Generating visual cues to guide the search>
탐색을 시작하기 전에 “이 질문에 답하려면 뭘 찾아야 하는가”를 먼저 접합니다. 여기서도 별도 모델을 쓰지 않고, MLLM의 LLM backbone이 가진 in-context 능력을 씁니다. 몇 개의 예시를 prefix로 주고 단서 $\{o_1, \dots, o_k\}$를 뽑게 하는 거죠.

Table 1을 통해 예시를 확인할 수 있습니다. 두가지 타입을 가지는데요.

• type 1: 인스턴스 하나만 찾으면 되는 cue (“dog”)
• type 2: 이미지 안의 모든 인스턴스를 찾아야 하는 cue (“all dogs”)

2번 행처럼 cue가 여러 개인 경우도 있습니다. 개와 고양이의 상대 위치를 물으면 둘 다 type 1으로 각각 찾아야 하죠.

<(2) searching for cues>
type 1은 $\mathcal{R}$로 안내받으며 탐색하다가 $\mathcal{S}$를 만족하는 순간 그 노드를 리스트 $L$에 담고 끝냅니다. 단서가 여러 개면 각 cue마다 “What is the appearance of the {$o_i$}?” 같은 질문 템플릿을 써서 개별적으로 찾습니다. type 2는 애초에 전부 찾아야 하니 $\mathcal{S}$를 적용하지 않고, existing confidence가 임계치($\tau_2 = 0.8$)를 넘는 노드를 전부 담습니다. 대신 비용 때문에 최대 탐색 깊이를 2로 제한합니다.

<(3) Answering the question using the searched cues>
찾은 노드들 $L = \{n_1^*, \dots, n_K^*\}$의 bounding box를 합집합으로 묶습니다.

그리고 해당 영역을 식(1)로 인코딩해서 질문과 함께 넣고 최종 답을 받습니다.

4. Experiments

4.1 Results on High-Resolution Benchmark

3개의 벤치마크에서 평가를 진행했는데요. 두 벤치에 대해서 간략히 설명하면, V*Bench는 평균 해상도가 2246×1582에 attribute recognition과 spatial reasoning task로 구성되어 있고, HR-Bench 8K는 평균 7680으로 FSP(Fine-grained Single-instance Perception)와 FCP(Fine-grained Cross-instance Perception) 두 서브태스크가 있다고 합니다. 마지막으로 HR-Bench 4K는 8K 이미지를 질문 대상 물체 주변으로 크롭해서 만든 것입니다.

Table 2가 메인 결과입니다. Zoom Eye를 붙였을 때 꽤 인상적인 성능 향상을 가져온 것을 볼 수 있는데요.

가장 많은 변화를 보여준 모델은 LLaVA-v1.5-7B로, 무려 V*Bench에서 +34.57을 가져왔습니다. Attribute만 보면 40점이 오르는데요. 같은 모델, 같은 가중치인데 이미지를 어떻게 보여주느냐만 바꿔서 이 정도가 나온다는 건, 뒤집어 말하면 원래 모델이 정보를 못 봐서 틀렸던 것이지 몰라서 틀렸던 게 아니었다는 뜻으로 해석될 수 있을 것 같네요.

추가로 인상적인 부분은 Qwen2.5VL-3B w/ Zoom Eye가 GPT-4o의 성능을 넘었다는 것인데요. 3B 오픈소스가 GPT-4o를 넘겼다는 것에서 박수를 보내지만, 조금 주의해야할 점은 이 벤치마크들이 애초에 고해상도에서 세밀하게 보는 것에 특화된 것이라 일반적인 비교는 아니라는 점은 감안해야 할 것. ㅏㅌ습니다.

또 보면, 유일하게 성능이 떨어진 모델이 있었는데요. LLaVA-ov-7B w/ Zoom Eye의 HR-8K에서 FCP를 보면 성능이 떨어지는 것을 볼 수 있습니다. FSP는 인스턴스 하나를 세밀하게 보는 태스크고 FCP는 인스턴스 간 관계를 봐야 하는 태스크라고 볼 수 있는데요. 확대는 단일 물체 지각에는 압도적으로 효과적이지만, 전역 관계를 요구하는 순간 이득이 거의 사라지거나 오히려 손해라고 해석할 수 있을 것 같습니다.

4.2 Results on Real-World Benchmark

Table 3은 MME-RealWorld 결과입니다. 평균 해상도 2000×1500에 5개 카테고리, 43개 서브태스크로 구성된 벤치마크인데, 지면 문제로 변화가 뚜렷한 13개만 뽑았다고 하네용

표를 보면 대체로 성능이 잘 오르는 것을 볼 수 있고, 사람 옷 색깔이나 차량 움직임같은 작게 찍힌 대상을 크게 봐야하는 태스크에서 강인한 것을 볼 수 있습니다. 다만 여기서도 성능이 하락하는 경우가 존재하는데, Position은 원격 탐사 이미지에서 물체의 위치를 묻는 태스크인데 확대하면 그 물체는 잘 보이지만 전체 이미지 안에서 어디쯤에 있는지는 잘 알지 못하죠. 그래서 성능이 하락한 것은 아닐까 싶고, Orientation도 비슷하게 기준 프레임이 필요한 태스크라 성능 하락을 한 것이 아닐까 싶습니다.

4.3 Ablation Studies

Vision-level test-time scaling

Figure 4는 answering confidence 임계치 \tau를 점점 낮춰가며 탐색 스텝 수와 성능의 관계를 본 것입니다. 보시면, 스텝이 늘수록 성능이 오르다가 결국 평평해지는데, 저자들이 말하길 이걸 텍스트 CoT의 test-time scaling과 유사하며, 더 많은 CoT 토큰을 탐색할 수록 최종 답변의 정확도가 올라가는데 이러한 것이 vision-level의 test-time scailing의 한 형태라고 볼 수 있다고 합니다.

Zoom operation contribution

Table 4는 zoom이 성공했을 때와 실패했을 때 정답률을 비교한 것인데요. 탐색된 박스가 대상 물체의 50% 이상을 덮으면 성공으로 봤습니다. 성공 시 93.45%, 실패 시 54.55%의 성능을 보이는 것을 볼 수 있습니다. zoom이 굉장한 역할을 하네요.

4.4 Case Study

Figure 5가 실제 케이스입니다. 왼쪽 위가 single type 1 cue인데, 4032×4032 폭포 사진에서 표지판 하나를 찾아 베트남어 문구까지 읽어냅니다. 오른쪽 위가 type 2 cue로 7360×4912 항공 사진에서 노란 부표 3개를 전부 찾아내고요. 왼쪽 아래는 multiple type 1 cues로, 유모차와 주황 옷 사람 두 패치를 union해서 좌우 관계를 답합니다.

개인적으로 더 눈여겨본 건 에러 케이스인데요.
첫번째 에러케이스는 세발자전거의 방향을 물어보는 것인데, 세발자전거는 정확히 찾았으나 방향을 답변하는 것에서 틀린 것을 볼 수 있습니다. 저자들은 학습 데이터에 방향 정보가 부족해 틀린 것으로 추측하였습니다.
두번째 에러케이스는 파란 육각형을 찾는 것인데요. 차란 육각형을 정확히 찾았느아 전역 이미지에서의 위치를 틀려 에러가 발생한 경우입니다.
두 케이스 모두 탐색은 성공했지만 최종 답이 틀린 것을 볼 수 있는데, Zoom Eye가 못 보는 문제는 해결해주지만 봤음에도 못 푸는 문제는 해결해주지 않는다를 알 수 있습니다.

---

지금까지 Zoom Eye 논문 리뷰를 마쳐봤습니다. 방법이 단순한 만큼 읽기 편하면서도, 표를 뜯어볼수록 생각할 거리가 계속 나오는 논문이었습니다. 지금까지 읽어주셔서 감사합니다.