안녕하세요, 예순 두번째 X-Review입니다. 이번 논문은 2025년도 arXiv에 올라온 OmniParser V2: Structured-Points-of-Thought for Unified Visual Text Parsing and Its Generality to Multimodal Large Language Models입니다. 바로 시작하도록 하겠습니다. 🪨

1. Introduction

본 논문은 VIsually-situated Text Parsing(이하 VsTP)와 관련된 논문으로, VsTP는 문저 이미지 혹은 scene 이미지에서 text를 인식하고 , 이 text의 위치 정보나 시각적인 구조를 파악해서 최종적으로 구조화된 형태로 바꾸는 task를 의미합니다. 아래 Fig1에 나와있는 것처럼 Text Spotting, Key Information Extraction, Table Recognition, Layout Analysis과 같은 여러 task를 한번에 수행하는 것이 VsTP task이며, 단순 text를 읽는 ocr을 넘어 text의 시각적인 맥락이나, 문서 내에서 어떤 역할을 하고 있는지 등등 주변 요소들과의 관계까지 함께 이해하는 것을 목표로 한다고 보면 됩니다.

기존 연구들은 크게 generalist 모델과 specialist 모델로 나눠지는데요. Generalist 모델은 다양한 task를 하나의 모델로 처리할 수 있다는 장점이 있지만, 외부 OCR engine에 대한 의존도가 높다는 점과, prediction 과정에 black-box 형태여서 결과 해석이 어렵다는 단점이 존재합니다. 반면 specialist 모델은 각 task에서 높은 정확도를 달성할수는 있지만, 여러 task를 동시에 처리하기 위해서는 복잡한 파이프라인을 구성해야하구, 각 모듈간의 연결이 되어 있지 않아 확장성이 어렵다는 단점이 존재합니다.

이런 문제를 해결하기 위해 최근 여러 VsTP task를 동시에 통합적으로 수행할 수 있는 unified 모델에 대한 연구가 이뤄지고 있습니다.

위 Table1을 보시면 여러 unified 모델과 해당 모델이 수행할 수 있는 VsTP task가 표시되어 있는데요. 보시면 대부분 기존 방법들은 특정 task에만 초점을 맞추고 있거나, text의 위치 정보 없이 단순 text만 추출하는 식(E2E, w/o Loc 참고)으로 좀 제한적으로 처리하는 경우가 많습니다. 즉, 여전히 task간의 상호작용이나 구조적인 정보를 전부 다루는 모델이 없는 것이죠.

이런 여러 task를 동시에 처리할 수 있는 unified 프레임워크를 설계하기에는 여러 challenge가 존재합니다. 첫 번째로, task-specific head나 adapter를 사용하는 것은 결국 모델이 task에 종속되게 되어 범용성을 확보하기 어렵다는 것입니다. 또, table recognition은 기본적으로 text를 먼저 인식해야 가능한 task라고 볼 수 있는데, 이런 식으로 task간의 종속 관계를 잘 고려하지 않으면 unified 설계 자체가 무의미해질 수 있죠. 마지막으로 text 자체 뿐 아니라 이걸 둘러싸고 있는 시각적인 element들 (단어, 점, 선, 셀과 같은)까지 표현할 수 있어야 진정한 unified라고 할 수 있다는 점입니다.

본 논문에서는 이런 challenge한 점을 고려하여 VsTP task를 수행할 수 있는 새로운 unified 모델인 OmniParserV2를 제안합니다. 해당 모델은 OmniParser v1을 베이스로 하기에, v1에 대한 자세한 내용이 궁금하시다면 다음 리뷰를 참고해주세요. 이 Omniparserv2는 Fig1에 그려진 것과 같은 구조로 되어 있으며 하나의 architecture를 기반으로 모든 task에 대한 output 형식을 모두 통일시켜서 Text spotting, KIE, Table Recognition, layour analysis 등 다양한 VsTP task를 하나의 모델로 가능하도록 설계하였습니다. 해당 모델은 Fig1에 그려진 것처럼 총 두개의 스텝으로 구성이 되어 있는데요. 첫 번째 단계에서는 input 이미지와 task prompt embedding 정보를 기반으로 text segment의 중심 좌표들과 task 관련 structured token이 포함된 structured point sequence를 생성하는 과정입니다. 이후 두 번째 단계에서는 이전 단계에서 생성한 각 text center point를 prompt로 사용해 해당 위치에 대한 polygon 좌표와 text content를 prediction하게 됩니다. 이부분은 omniparserv1에서 제안된 방식이었는데요. 본 v2에서 추가된 부분이라고 하면 해당 방식을 MLLM에 접목하는 부분인 것 같습니다. 좀 더 구체적인 설명은 method단에서 하도록 하겠습니다.

2. Methodology

2.1. Task Unification

OmniParserV2는 다양한 VsTP task를 하나의 unified 구조로 통일해 처리할 수 있도록 설계되었습니다. Fig2에 이 프레임워크가 도식화되어 있는데요. 보시면, 앞서 언급한 것처럼 step1: structured poitn sequence를 생성하는 부분과 step 2: 이 point sequence를 기반으로 polygon과 content를 생성하는 부분으로 구성된 것을 확인할 수 있습니다.

Structured Points Sequence Construction

step 1에서는 먼저 각 text들의 center point와 structural token으로 구성된 sequence를 생성하는데요. 여기서 structural token이란 그림에서 SPS for Table Recongition 부분에 있는 <tr>, KIE task 에서는 <Date><Time>, Layout Analysis에서는 <line>과 같은 token을 의미하는데요. 이런 token을 활용해 해당 text가 어떤 구조적인 역할을 하는지도 같이 sequence에 포함시킨 것입니다. 여기서 spotting task에서는 text의 위치와 그 내용만을 prediction하게 되니 이런 structured token없게 되겠죠.

Polygon & Content Sequence Construction

다음 2단계는 모든 task에 동일하게 적용이 됩니다. curved text는 16개의 point로 구성된 polygon 형식으로, 평평한 text는 4개 점으로 구성된 bbox로 표현이 되구요. Text의 content는 character 단위로 분해되어 character-level tokenizing을 통해 seuqnece로 분해됩니다. 즉, 그림에서처럼 Time이라는 단어가 각각 t, i, m, e로 나뉘고 각 문자가 고유한 token으로 변환되 sequence를 구성하게 되는 것입니다.

2.2. Unified Architecture

다음으로는 이 unified architecture에 대해 좀 더 살펴보도록 하겠습니다. OmniParserV2는 encoder-decoder 구조이구요. decoder는 모두 shared되는 디코더입니다.

Image Encoder

먼저 입력 영상은 ImageNet데이터셋으로 사전학습한 Swin-B 백본을 타고 나오게 되구, 이후 FPN을 통해 여러 scale의 feature map을 통합하였습니다.

Shared Decoder

shared decoder는 omniparserv2에서 structured point sequence, polygon coordinates, text content와 같은 모든 sequence를 생성하는 데 사용되는 shared decoder입니다. 이 decoder는 transformer 구조를 기반으로 하되, 내부적으로는 token-router 방식을 통해 처리하도록 했는데요. 일반적인 transformer decoder는 self attention과 하나의 ffn으로 구성이 되어 있겠지만, 위 Fig3과 같이 omnniparser v2에는 각 decoder layer에 3개의 FFN을 따로 두고, token 유형에 따라 이 중 하나만 사용되도록 설계하였습니다. 구체적으로, sequence에서 <point>나 <box> 토큰이 있다면 detection FFN을 사용하게 되고, <tr> 등의 structured tag가 있다면 Structured 으로 라우팅 되는 식입니다.

이 방식은 MoE랑 유사하지만, 차이점이 존재하는데요. 일반적인 MoE 에서는 어떤 토큰을 어떤 expert FFN에 보낼지 모델이 학습 과정에서 스스로 결정하게 되지만 (즉, 라우팅까지도 학습 대상) Omniparser v2에서는 각 token 종류가 명시적으로 지정이 되어 있어서 FFN 선택하는 과정을 학습하지는 않습니다. 따라서 routing 결정에 필요한 추가적인 계산량이 줄어들고 학습이 안정적이게 되겠죠.

Objective

본 모델은 사전학습 과정과 각 벤치마킹 데이터셋에 대해 fine-tuning하는 식으로 학습되는데요. (사전학습 관련해서는 아래에 추가적으로 설명하도록 하겠습니다.) 두 학습 과정에서 negative log-likelihood를 최소화하도록 학습되었습니다.

수식은 아래 식1을 참고하시면 됩니다.

식에서 \tilde{s}j는 j번째 target token이며 v는 image에서 추출한 visual embedding, s{k:j-1}는 j시점 전까지의 입력 sequence를 의미합니다. 또, w_j는 j번째 토큰에 부여된 가중치를 의미하는데요. 저자는 여기서 structual token이나 entity tag와 같은 중요한 토큰에는 학습 시에 더 많은 비중을 두기 위해 다른 일반 토큰보다 4배 더 줬다고 합니다.

2.3. Pre-training Methods

Omniparserv2에서 첫 번째 step인 structured point sequence를 생성하는 과정은 다른 polygon이나 content를 생성하는 것에 비해 상대적으로 더 어려운 task입니다. 왜냠 이 과정은 단순 text를 인식하는 것을 넘어 해당 text가 어떤 구조적 역할을 하는지, 어떤 의미를 내포하는지 image만 가지고 예측해야 하기 때문입니다. 특히 앞서 설명한 token-router 기반 shared decoder는 text가 위치하는 공간적인 맥락과 함께, 해당 text가 어떤 종류의 entity인지 동시에 파악해야 하기 때문에 보다 복합적인 representation 학습이 요구됩니다.

이런 문제를 해결하기 위해 본 논문에서는 pre-training 단게에서 두 종류의 prompt 전략을 제안합니다. 첫 번째는 image 내의 spatial한 정보를 활용하는 spatial-window prompting이구요. 두번째는 text의 content 정보를 활용하는 prefix-window prompting입니다. 각각에 대해 설명드리도록 하겠습니다.

Spatial-Window Prompting

이 방식은 이미지 내의 특정 영역에 대해서만 예측하도록 하는 방식입니다. 위 그림4를 보면 (x left, y top, x right, y bottom)으로 저으이된 하나의 window가 지정이되게 되구요. 이 window 내부에 center point가 포함된 text들만 decoder가 prediction 대상으로 삼게 됩니다. 예를 들어서 그림에서 ‘Colchester’와 ‘Greenstead’ 단어는 이 window 안에 있기 때문에 prediciton되겠지만, 이 window 밖에 center point가 존재하는 ‘FootPath’ ‘To’는 포함이 되지 않겠죠.

이런 방식은 decoder가 한 번에 image 전체를 다 보지 않고, 부분적으로 나누어 집중적으로 prediction하도록 학습함으로써 spatial 정보에 대해 좀 더 sensitive한 표현을 학습하도록 하는 것입니다.

Prefix-Window Prompting

다음 이 방식은 text의 첫 글자에 기반애 prediction 범위를 제한하는 방식입니다. 그림에서 “B”, “H”라는 범위가 prompt로 주어진 것을 볼 수 있는데, 이는 알파벳 순서상 ‘B’ 부터 ‘H’까지 시작하는 단어만 예측하라는 의미입니다. 그림에 있는 단어 “Colchester”는 C로 시작하는 단어이구. “Greenstead”는 G로 시작하기 때문에 둘 다 이 prompt 범위 내에 해당하는 단어기에 모두 decoder의 output 대상이 됩니다. 반면에 “and”는 A로 시작하기에 이 범위를 벗어나는 단어로 prediction되지 않는 것을 확인할 수 있습니다.

이런 방식은 decoder가 character-level의 semantic한 정보를 학습하도록 하며, 특히 KIE(Key Information Extraction) task 처럼 특정 유형의 entity만 추출해야 하는 경우에 강인하게 동작한다고 합니다.

2.4. SPOT Applied to MLLM

다음으로 이 2-stage generation 방식 (Structure-Points-of-Thought 이하 SPOT)을 MLLM에 적용하게 된 배경과, 그 MLLM을 기반으로 SPOT prompting을 구현하는 파이프라인을 간략 설명하도록 하겠습니다.

Overview

최근 Chain-of-Thought(이하 CoT) prompting이라고 하는 기법이 많이 사용되고 있는데요. CoT는 모델이 정답을 한 번에 예측하는 것이 아니라, 중간에 추론 과정을 먼저 생성한 후에 최종 response를 생성하도록 유도하는 방식입니다. OmniParser V2에서 제안되고 있는 SPOT prompting 방식 역시 이런 CoT prompting과 유사한 느낌이죠. 한 번에 복잡한 작업을 처리하도록 하지 않고 중간 단계로 나눠서 먼저 center point와 structured token을 추출하도록 한 다음 최종 polygon과 content를 추출하도록 한 것을 생각해보면 되겠습니다.

Pipeline

마찬가지로 MLLM을 기반으로 SPOT Prompting을 구현할 때도 유사한 방식을 가져갑니다. 위 Fig5에 전체 파이프라인이 그려져 있는데 앞서 omniparser v2와 같이 두 단계로 구성이 되어 있는 것을 볼 수 있으며 각 step에서 MLLM은 prompt를 입력으로 받아 sequence를 출력해냅니다. 먼저 step1인 get structured point sequence 부분을 보시면 입력으로 input image와 함께 첫 번째 instruction이 들어가게 되는데. 보시면 “To answer the question ‘Text spotting’, let’s think step by step. What is the structured points in the image?”라는 prompt가 적혀져 있습니다. 이 prompt는 MLLM에게 image 내에 존재하는 각 text instance의 center point를 예측하도록 하고 있으며, 모델은 이 prompt에 따라 각 text의 center point를 <point>(x, y)</point> 형태로 나열하게 됩니다. 이 결과가 Response1에 해당하게 되고, step2의 기준이 됩니다.

다음 step으로는 polygon과 content를 예측하는 부분으로 response 1을 포함하여 “Provide the location coordinates and texts of the structured points respectively in the image.”다음과 같은 instruction 2를 입력으로 넣습니다. 이 prompt는 MLLM에게 각 center point에 대응되는 text의 경계 좌표와 실제 text content를 prediction하도록 지시하고 있습니다. 이에 대한 output이 response2에 해당합니다.

이렇게 MLLM 기반으로 SPOT을 구현할 때도 두 단계로 수행하는 것은 MLLM의 추론 과정을 명시적이고 구조화된 방식으로 유도하는 효과가 있다고 합니다. 특히 각 text instance를 center point level로 고정시킴으로써 기존 MLLM이 흔히 보였던 hallucination을 줄일 수 있다고 하네요.

3. Experiments

이제 실험 부분으로 넘어가도록 하겠습니다. 실험은 각 task인 spotting, key information extraction, table recognition, Layout Analysis에 대해 수행되었습니다.

3.1. Comparisons with State-of-The-Art

먼저 spotting 부분입니다. 위 table3은 세 benchmark 데이터셋에서의 성능을 보여주고 있는데요. 이전 모델인 omniparser와 비교해봤을 때 엄청난 성능 갭차이를 보여주고 있지만 않지만, 모든 부분에서 약간의 성능 향상을 보여주면서 sota를 달성하였습니다. 특히 볼만한 점은 detection보다는 e2e 성능이 더 큰폭으로 향상된 것을 확인할 수 있는데, 이는 omniparserv2가 detection과 recognition 과정을 분리하면서 각 task를 독립적으로 최적화한 결과라고 해석해볼수 있겠습니다.

다음은 Key information부분인데, 위 table4에서는 CORD와 SROIE 데이터셋을 기반으로 성능을 비교하고 있습니다. 직접적으로 비교해볼 모델은 SeRum으로 이 모델이 generation 기반의 e2e 방식이기에 전체 key information sequence를 token level에서 생성하는 방식입니다. 보시면 OmniParserv2는 CORD에서 85.0%의 F1 score를 달성하면서 sota를 달서앟였고 SROIE에서도 F1은 좀 떨어지지만, Acc 부문에서 SOTA를 달성하였습니다.

특히, 본 모델은 character level prediction에서도 높은 정확도를 보이고 있으며, localization 능력이 있다는 점에서 document 분석 및 수정 작업에 좀 더 적합하다는 점을 어필하고 있습니다. 또한 OmniParser V2는 대규모 문서 corpus없이 scene text 데이터만을 기반으로 사전학습한 성능인 것을 보아 모델의 일반화 능력이 높다는 점을 살펴볼 수 있습니다.

다음으로 table recognition task에 대한 실험인데요. 여기서 보이는 S-TEDS와 TEDS 평가지표는 둘 다 HTML 형식으로 복원된 table 결과를 평가하는 것으로 각각 구조만 평가 구조 + 내용까지 평가하는데 차이가 있습니다. Table5를 보시면 기존 방법론들 대시 sota를 달성하고 있습니다.

기존 다른 방법론들은 table의 구조와 내용을 분리해서 처리를 해왔었는데요. 학습에는 cell의 bbox를 사용하고 최종 output은 offline ocr을 활용해 html을 재구성하는 방식이었다는 것이죠. 반면 OmniParser는 이런 복잡한 파이프라인이 필요 없이 center point 기반 방식으로 table 구조와 내용을 동시에 e2e 학습할 수 있다는 장점을 갖습니다.

마지막으로 layout 분석 task인데, 이는 기존 omniparser v1에서는 수행하지 않았던 task로 v2에서 새로 추가하여 수행한 task입니다. 이 layout 분석 task는 HierText 데이터셋을 기반으로 수행이 되었고, 단어, 문장, 단락 level에서 PQ score를 기준으로 성능을 평가하였습니다. 위 Table6을 보면 Omniparser V2는 기존 Hi-SAM-B 대비 각각 1.9, 1.2, 0.8 더 높은 성능을 달성하였습니다.

여기서 볼만한 점은, 기존 모델인 GCP-PP나 Mask-RCNN-Cluster, MaX-DeepLab-Cluster 같은 모델은 e2e로 수행되지 않는 모델로 bbox와 offline OCR 모델에 의존하는 모델들인데요. 이에 반해 OmniParser v2는 e2e로 동작하면서 더 높은 성능을 달성하고 있다는 점입니다. 이는 SPOT prompting을 통해 모델이 text의 기하적인 구조와 계층 관계를 같이 학습할 수 있었기 때문이라고 해석해볼 수 있겠죠.

3.2. Analysis

Ablating Pre-training Strategies

위 table7는 본 논문에서 제안된 사전학습 기법에 대한 ablation study입니다. 보시면 spatial window prompting과 prefix window prompting을 각각 적용했을 때 성능이 약간씩 상능하고 둘 다 적용하면 그보다는 좀 더 올라가는 것을 확인할 수 있습니다. 두 사전학습 방식이 각기 다른 부분, spatial 측면과 content 측면에서 모델의 표현 능력을 보완해주는 것으로 보입니다.

Ablating Architectural Designs

다음으로 OmniParserv2의 decoder 설계와 관련한 ablation study입니다. 본 실험은 decoder내 weight sharing 방식과 token routing 방식의 유무가 모델 성능에 미치는 영향을 살펴보는 것인데요. 위 Table8을 보시면, 단순 파라미터를 공유하는 natiave shared decoder를 사용하는 두번째 행의 경우 text spotting 성능이 오히려 공유하지 않고 따로 decoder를 두는 것에 비해 성능이 하락하는 것을 보입니다. 이는 center point와 polygon, content를 prediction하는 서로 다른 task를 한 decoder에서 처리하고자 하다보니 내부 feature가 충돌하면서 일어난 결과라고 해석하고 있습니다.

반면에, 본 논문에서 제안한 token-router 기반의 shared decoder는 이런 문제를 완화시키고 있는데, 성능 측면에서 보시면 native shared decoder 대비 1.7정도의 성능 향상을 보이고 기존 omniparser 대비 0.4 정도의 향상을 보입니다. 이 방식은 기존 native MoE decoder 3행 성능과 비교해봤을 때도 더 좋은 결과를 보이고 있는데, MoE 구조에서는 router가 학습 대상이기 때문에 학습이 불안정해질 수도 있고, 전체 모델 크기도 더 커지는 문제가 있습니다. 하지만 token-router 방식은 불필요한 파라미터를 줄여 기존 omniparser 대비 모델크기를 24% 줄이면서 더 좋은 성능을 보이고 있죠.

3.3. SPOT Applied to Existing MLLMs

마지막으로, SPOT prompting이 기존 MLLM에도 효과적으로 적용될수 있는지 검증하기 위해 다양한 MLLM에 SPOT prompting을 적용해 spotting 성능을 비교한 실험입니다. 평가 지표는 TextMonkey에서 제안한 방식을 따라서 Trans와 Pos를 사용하였는데, 이들 각각은 문자열 정확도 기반 평가지표와 center point 좌표 기반 평가지표입니다. 위 Table10을 보시면, SPOT prompting을 적용한 결과 세 모델 전부 spotting 성능이 일관되게 향상되는 결과를 보이고 있습니다.

특히 볼만한 점은 StrucTextv3가 TIM-30M라는 대규모 데이터셋을 사용해 학습하여 좋은 성능을 보인 반면에 본 방법론은 훨씬 더 적은 데이터셋을 사용하였음에도 불구하고 SPOT prompting을 통해 이와 유사하거나 더 좋은 성능을 달성하면서 prompting을 어떻게 하는지가 중요하다는 점을 시사하고 있습니다.

또, tab3에서 봤었던 spotting 성능과 비교하면 table10에서의 spotting 성능은 좀 떨어지는 것을 확인할 수 있는데요. 아무래도 SPOT prompting이 MLLM의 text localization 능력을 향상시킬 수 있다고 해도 아직까지 spotting에 완전 초점을 맞춰 학습한 모델과 MLLM간에는 일정 성능 격차가 존재한다고 볼 수 있습니다.