MinerU2.5: A Decoupled Vision-Language Model for Efficient High-Resolution Document Parsing Review

0. Introduction

Paper link

MinerU2.5는 고해상도 문서 파싱을 어떤 계산 단위로 분해해야 하는가를 심도깊게 다뤘다. 문서 파싱에서는 페이지 전체 구조를 빠르게 보는 능력과, 잘라낸 작은 영역을 원해상도에서 정밀하게 읽는 능력이 동시에 필요하다. 그런데 기존 end-to-end VLM은 이 두 요구를 같은 visual token budget 안에서 한 번에 해결하려다 보니, 긴 문서와 고해상도 입력에서 계산량과 hallucination 문제가 같이 커진다.

이 논문은 그 문제를 정면으로 쪼갠다. 먼저 downsampled page에서 global layout analysis 를 하고, 그 결과를 이용해 원본 해상도 crop들을 잘라 local content recognition 을 수행한다. 여기에 그치지 않고, layout task 자체를 position/class/rotation/reading order의 multi-task problem으로 재정의하고, formula와 table도 각각 ADR, OTSL 같은 중간 표현과 파이프라인으로 다시 설계한다. 즉, backbone만 바꾼 논문이 아니라 문제 정의 자체를 다시 짠 논문 에 가깝다.

한 줄 요약: MinerU2.5는 global layout와 local recognition을 분리한 two-stage parsing, layout/formula/table task reformulation, IMIC hard-case mining data engine, deployment-aware vLLM serving 을 하나로 묶어, high-resolution document parsing의 정확도와 효율을 동시에 잡으려는 문서 파싱 시스템 논문이다.

0-1. 왜 지금 읽을 가치가 있는가

• Document AI가 이제는 단순 OCR 정확도 경쟁보다, RAG / pretraining / enterprise ingestion pipeline 문제로 이동하고 있기 때문이다.
• 최근 문서 파싱 논문들은 native-resolution VLM과 multi-stage VLM으로 갈라지는 흐름이 있는데, 이 논문은 그 중에서도 왜 global-local decoupling이 실전적 해답이 되는지 비교적 선명하게 보여준다.
• 논문이 architecture에서 끝나지 않고, data engine -> task reformulation -> benchmark -> serving throughput 까지 연결되어 있어서 실무적으로 읽을 포인트가 많다.
• 1.2B라는 비교적 작은 모델 규모에서 나온 결과라서, “무조건 더 큰 general VLM이 답이다”라는 직관을 다시 보게 만든다.

0-2. 먼저 말하고 싶은 핵심 결론

1. 이 논문의 중심은 1.2B 모델 자체가 아니라 stage separation이다.
   문서 파싱의 병목은 “더 큰 backbone”보다 “어떤 해상도로 무엇을 먼저 볼 것인가”에 더 가깝다는 메시지가 강하다.

2. 정확도 개선의 상당 부분은 task reformulation에서 온다.
   layout에는 PageIoU와 multi-task prediction, formula에는 ADR, table에는 OTSL을 붙였다. 즉 성능은 backbone 하나에서 나온 게 아니다.

3. data engine과 IMIC는 부록이 아니라 본편이다.
   자동 주석 데이터의 ceiling을 hard-case mining + human correction으로 뚫는 구조가 논문의 성능 서사를 지탱한다.

4. 결과는 인상적이지만, “모든 문서 파싱 문제의 완전한 종결”로 읽으면 과장이다.
   일부 formula subset에서는 specialized formula model이 여전히 더 강하고, 재현성 측면에서도 내부 데이터와 인하우스 도구 의존성이 남아 있다.

0-3. 이 글의 관점

이 글은 MinerU2.5를 아래 네 층위에서 읽은 정리다.

• 논문에서 직접 확인되는 사실: two-stage parsing, backbone 구성, training recipe, data engine, benchmark 결과
• 설계 의도 해석: 왜 하나의 unified model을 쓰되 inference는 decoupled orchestration으로 가져갔는가
• 실험 해석: 어떤 benchmark가 진짜 의미 있는지, 무엇을 과장 없이 읽어야 하는지
• 내 해석: 이 논문의 핵심은 “OCR 모델”보다 고해상도 문서 인식 시스템 설계 원리 에 있다

1. Problem Setting

1-1. Problem definition

MinerU2.5가 겨냥하는 문제는 단순 text OCR이 아니다.

• 문서 이미지는 natural image와 다르게 매우 높은 해상도, 높은 텍스트 밀도, 복잡한 레이아웃, 표/수식/캡션/각주/머리말/꼬리말 을 동시에 가진다.
• 좋은 문서 파싱은 글자만 읽는 게 아니라, layout detection, reading order, element typing, table structure, formula fidelity 를 같이 만족해야 한다.
• 게다가 practical system에서는 page 하나를 잘 읽는 것만으로 부족하고, 대량 문서 batch 처리에서 계산량과 latency가 버틸 것 도 중요하다.

즉 문제는 “문자를 얼마나 정확히 읽느냐” 하나가 아니라, 아래를 동시에 만족하는 것이다.

1. 고해상도 원본의 detail을 잃지 않을 것
2. global layout과 reading order를 보존할 것
3. dense text와 long document에서 hallucination이 적을 것
4. 실제 batch inference 비용이 감당 가능할 것

1-2. Why previous approaches are insufficient

기존 접근의 한계는 꽤 분명하다.

1) 전통적인 pipeline 계열

Marker, MinerU2-pipeline, PP-Structure 같은 접근은 layout detection, OCR, table/formula recognition, reading order를 여러 모듈로 쪼갠다. 이 방식은 해석 가능하고 모듈별 최적화가 쉬운 대신, 다음 문제가 있다.

• stage가 많아질수록 error propagation 이 커진다.
• rotated element, reading order, ambiguous block boundary처럼 경계가 애매한 문제에서 brittle하다.
• 운영 관점에서는 dependency와 유지보수 비용이 증가한다.

2) end-to-end general VLM / domain-specific VLM

GPT-4o, Gemini 2.5 Pro, Qwen2.5-VL, dots.ocr 같은 계열은 unified parsing 능력을 보여준다. 하지만 문서 파싱에서는 두 가지 구조적 문제가 남는다.

• 고해상도 입력의 token redundancy
  빈 영역이나 low-information region이 많아 visual token이 낭비된다.
• native-resolution inference의 비용
  세밀한 정보를 유지하려면 token 수가 폭증하고, 결국 계산량과 latency가 크게 오른다.

3) 최근 multi-stage VLM 계열의 절충안

Dolphin이나 MonkeyOCR처럼 layout과 recognition을 분리하는 multi-stage 접근은 분명 진전이다. 하지만 이들도 각자 약점이 있다.

• fixed-resolution crop 기반이면 extreme aspect ratio에서 왜곡이 생긴다.
• 여러 specialized model을 조합하면 정확도는 좋아질 수 있어도 system complexity와 deployment overhead 가 커진다.

결국 이 논문이 던지는 질문은 단순하다.

하나의 unified model을 유지하면서도, global view와 local detail을 다른 계산 경로로 분리할 수 없는가?

MinerU2.5는 이 질문에 대한 꽤 설득력 있는 대답이다.

2. Core Idea

2-1. Main contribution

내가 보기에는 이 논문의 핵심 기여는 다섯 가지다.

1. global layout / local recognition decoupling
   Stage I에서는 1036 x 1036 thumbnail로 전체 페이지 구조를 빠르게 보고, Stage II에서는 원본 해상도 crop를 최대 2048 x 28 x 28 pixel budget 안에서 정밀하게 읽는다.

2. one-model, multi-prompt design
   backbone은 하나지만, layout detection / text recognition / formula recognition / table recognition을 task-specific prompt로 구동한다. 즉 여러 모델을 운영하지 않고도 multi-stage pipeline을 구성한다.

3. task reformulation
   • layout: position + class + rotation + reading order
   • formula: atomic/compound 분리 + ADR
   • table: HTML 대신 OTSL intermediate representation

4. data engine + IMIC
   large-scale pretraining data를 만들고, 이후 stochastic consistency 기반으로 hard case를 골라 human annotation을 집중한다.

5. deployment-aware serving
   asynchronous backend, Stage I/II decoupling, layout-type-aware sampling penalty, vLLM scheduler tuning까지 포함해 실제 throughput story를 만든다.

2-2. Design intuition

1) 문서 파싱은 “한 번에 전부 보기”보다 “무엇을 어떤 해상도로 볼지 분리하기”가 중요하다

페이지 전체 구조를 이해하는 데는 원본 해상도가 항상 필요하지 않다. 반대로 dense text, 작은 수식, 얇은 표 선을 읽으려면 thumbnail로는 부족하다. 이 논문은 이 둘을 같은 token budget 안에서 해결하려 하지 않고, global pass와 local pass를 분리 한다.

2) 문서 layout은 object detection보다 richer한 task다

기존 방식은 layout을 bbox + class detection으로 취급하고, reading order나 rotation 처리는 downstream heuristic에 맡기는 경우가 많다. MinerU2.5는 이걸 비효율로 본다. 그래서 layout stage에서부터 rotation angle과 reading order까지 같이 예측 한다. 이건 stage를 나눴지만 동시에 stage 간 coupling을 줄이려는 설계다.

3) 긴 formula와 긴 table은 그냥 더 크게 보여준다고 해결되지 않는다

long formula는 구조가 길어질수록 hallucination이 생기기 쉽고, table을 HTML로 직접 생성하면 token이 너무 길어진다. 그래서 이 논문은 문제를 더 쉬운 subproblem으로 바꾼다.

• formula는 atomic line 단위로 쪼개고 다시 recombine
• table은 HTML보다 더 짧고 시각 구조에 맞는 OTSL 로 먼저 생성

즉, 고해상도 detail을 보는 것만큼이나 target representation 자체를 바꾸는 것 이 중요하다는 관점이다.

4) 더 많은 데이터보다 더 가치 있는 hard case가 중요하다

자동 주석 기반 pretraining data는 넓게 커버하지만 noise ceiling이 있다. 그래서 MinerU2.5는 무작정 더 많은 데이터를 넣기보다, 현재 모델이 불안정한 샘플을 consistency 기반으로 찾고 그 샘플에 annotation budget을 집중 한다. 이게 IMIC의 핵심이다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	high-resolution document parsing에서 정확도와 효율을 동시에 확보
Backbone	675M NaViT vision encoder + 0.5B Qwen2-Instruct decoder + patch merger
Stage I	1036 x 1036 thumbnail 기반 global layout analysis
Stage II	native-resolution crop 기반 local content recognition
Prompted tasks	Layout Detection / Text Recognition / Formula Recognition / Table Recognition
Key reformulations	PageIoU, ADR, OTSL
Data engine	large-scale curated pretraining + IMIC hard-case mining + expert correction
Deployment	async vLLM, Stage I/II decoupling, layout-aware sampling penalty

이 표만 봐도 이 논문이 단순히 “OCR 잘하는 1.2B 모델”이 아니라는 게 드러난다. backbone보다도 어떻게 문제를 분해했고, 그 분해를 어떻게 학습/서빙과 이어 붙였는가 가 더 중요하다.

3-2. Module breakdown

1) Unified backbone, decoupled execution

MinerU2.5의 backbone은 Qwen2-VL 계열에서 영감을 받았지만, document parsing에 맞게 꽤 명확한 선택을 한다.

• Language Model: 0.5B Qwen2-Instruct
  저자들은 document parsing이 거대한 decoder capacity를 크게 요구하지 않는다고 본다.
• Vision Encoder: 675M NaViT initialized from Qwen2-VL
  arbitrary resolution과 aspect ratio를 다루기 위해 native-resolution encoding을 유지한다.
• Positional handling: cropped image parsing 일반화를 위해 1D-RoPE 대신 M-RoPE 를 사용한다.
• Patch merger: adjacent 2 x 2 vision token에 pixel-unshuffle를 적용해 효율과 성능의 균형을 잡는다.

중요한 건 이 backbone을 하나의 model로 유지하면서도, inference에서는 prompt와 crop orchestration으로 task를 분리한다는 점이다. 즉 “여러 모델을 쓰지 않는 multi-stage system” 이다.

2) Two-stage parsing strategy

Stage I: Layout Analysis

• 입력 페이지를 1036 x 1036 thumbnail로 통일 resize
• global layout과 reading order를 빠르게 파악
• fixed thumbnail size를 택해 bbox localization stability를 확보

여기서 포인트는 native aspect ratio thumbnail이 아니라 fixed thumbnail 을 쓴다는 점이다. 논문은 이 방식이 bounding box localization과 training 안정성 측면에서 더 낫다고 본다.

Stage II: Content Recognition

• Stage I 결과를 바탕으로 원본 문서에서 local crop 생성
• crop는 native resolution 으로 유지하되, 상한은 2048 x 28 x 28
• text / formula / table recognition을 task prompt로 분리 수행

이 설계가 좋은 이유는 두 가지다.

1. end-to-end native-resolution처럼 페이지 전체를 비싸게 보지 않는다.
2. crop-only method처럼 global context를 잃지 않는다.

즉, MinerU2.5의 two-stage design은 단순히 빠르기 위한 꼼수가 아니라 global semantics와 local fidelity의 operating point 를 찾는 구조다.

3) Layout analysis as a multi-task problem

이 논문의 layout 설계는 생각보다 중요하다. 저자들은 layout analysis를 단순 detection이 아니라, Position / Class / Rotation Angle / Reading Order 를 동시에 예측하는 multi-task problem으로 정의한다.

이 방식이 중요한 이유는 다음과 같다.

• rotated text/table을 downstream에서 따로 보정하지 않아도 된다.
• reading order를 later stage heuristic으로 미루지 않는다.
• 하나의 pass 안에서 문서 구조 representation을 더 풍부하게 만든다.

Unified tagging system

MinerU2.5는 레이아웃 태깅 체계도 다시 정리한다.

• Comprehensive coverage: header, footer, page number 같은 non-body element 포함
• Fine granularity: image/chart/chemical structure, caption, footnote를 더 잘게 구분
• Semantic distinction: code, algorithm, reference, list 같은 visually distinct block를 별도 category로 분리

내가 보기엔 이 부분이 꽤 실전적이다. RAG나 knowledge extraction에서는 본문만 읽는 것보다 어떤 블록을 어떤 semantic unit로 남길 것인가 가 훨씬 중요할 때가 많기 때문이다.

PageIoU

문서 layout은 paragraph boundary가 애매한 경우가 많아서, 일반적인 IoU/mAP만으로는 qualitative quality와 metric이 어긋날 수 있다. 그래서 저자들은 PageIoU 를 제안한다.

핵심 아이디어는 “bbox 매칭”보다 페이지 단위 coverage consistency 를 보자는 것이다. 이건 문서 레이아웃처럼 annotation granularity가 흔들리는 문제에 꽤 잘 맞는 발상이다.

다만 뒤에서 다시 말하겠지만, 이 metric은 장점이 있는 만큼 semantic class error를 얼마나 엄격하게 벌주느냐 는 별도 검토가 필요하다.

4) Formula recognition: ADR

formula recognition 쪽의 포인트는 atomic formula와 compound formula를 구분 한다는 점이다.

• Atomic formula: 하나의 fraction, matrix처럼 indivisible semantic unit
• Compound formula: 여러 atomic line이 vertical alignment를 이루는 multi-line derivation

이를 위해 저자들은 ADR (Atomic Decomposition & Recombination) 프레임워크를 제안한다.

1. layout detection으로 atomic/compound formula 영역 식별
2. compound formula를 line 단위 atomic formula로 분해
3. 각 atomic crop를 개별 LaTeX로 인식
4. positional information을 이용해 align 같은 구조로 재조립

이 접근은 꽤 설득력 있다. 긴 formula 하나를 통째로 맞히게 하는 대신, 더 쉬운 recognition subproblem들의 집합 으로 바꾸기 때문이다. 논문이 formula hallucination을 줄이는 방법으로 resolution만 키운 게 아니라 problem structure를 바꾼 점 이 좋다.

5) Table recognition: OTSL

table recognition에서는 HTML을 직접 target으로 두지 않는다. 저자들은 HTML이 문서 VLM에게 두 가지 점에서 불리하다고 본다.

1. visual structure와 직접 대응되지 않는 복잡한 syntax를 implicit하게 배워야 한다.
2. structural token 수가 많아서 긴 table일수록 sequence가 길어진다.

그래서 MinerU2.5는 OTSL (Optimized Table-Structure Language) 을 intermediate representation으로 사용한다.

• table bbox + rotation detection
• crop 및 rotation correction
• rectified image를 OTSL로 생성
• OTSL을 HTML로 변환

논문에서 특히 눈에 띄는 부분은, OTSL이 HTML 대비 structural token을 28개 이상에서 5개로 줄이고, 평균 sequence length도 약 50% 단축 한다는 점이다. table parsing에서 representation choice가 얼마나 중요한지 보여주는 대목이다.

6) IMIC: Iterative Mining via Inference Consistency

IMIC는 이 논문의 data engine 핵심이다.

• 동일 샘플에 대해 stochastic inference를 여러 번 수행
• 결과 간 consistency를 측정
• consistency가 낮은 샘플을 hard case로 간주
• human annotation budget을 그 샘플에 우선 배정

task별 consistency metric도 다르다.

• layout: PageIoU
• formula: CDM
• table: TEDS

이 구조가 좋은 이유는 명확하다. 현재 모델이 불확실해하는 샘플이야말로 gradient value가 큰 샘플 이기 때문이다. 문서 파싱처럼 도메인 다양성과 tail case가 큰 문제에서, 이 접근은 brute-force data scaling보다 훨씬 실전적이다.

4. Training / Data / Recipe

4-1. Data

MinerU2.5의 성능은 backbone보다도 data engine 설계 에 많이 의존한다.

1) Data curation

원천 데이터는 공개 웹 데이터와 commercially procured document를 포함하는 대규모 internal document pool이다. 이 raw pool의 long-tail imbalance를 줄이기 위해, 저자들은 아래 축으로 curation을 수행한다.

• Layout diversity: page-level image clustering 기반 exemplar selection
• Document type diversity: academic paper, textbook, report, presentation 등 stratified sampling
• Element balance: title, paragraph, table, formula, figure 등의 class distribution 균형
• Language balance: Chinese / English volume 균형

즉 그냥 데이터를 많이 모은 게 아니라, 레이아웃과 요소 분포까지 의식적으로 균형화 했다.

2) Pre-training annotation refinement

초기 주석은 MinerU2-pipeline으로 만들지만, 그 위에 더 강한 specialized model을 얹어 refinement한다.

• text: Qwen2.5-VL-72B-Instruct로 cropped text verification / correction
• formula: in-house UniMERNet model로 higher-fidelity formula output 생성
• table: in-house high-performance table parsing model로 구조 재생성

이 단계가 중요한 이유는, 문서 파싱 pretraining data의 품질이 전체 ceiling을 크게 좌우하기 때문이다. broad coverage는 MinerU2-pipeline이 주고, quality refinement는 stronger expert model이 담당하는 구조다.

3) Fine-tuning dataset construction

fine-tuning 단계에서는 방향이 바뀐다.

• 대규모 자동 주석 데이터 전체를 다시 쓰는 대신
• IMIC로 찾은 high-value hard case 에 human annotation을 집중하고
• 일부 random regular example을 섞어 기본 capability를 유지한다

또한 복잡한 table 같은 케이스는 foundation model로 pre-annotation한 뒤, human expert가 교정한다. 논문에는 human review를 보조하는 QA tool Dingo 도 언급된다. 이건 단순 labeling이 아니라 annotation quality control loop 를 갖추려는 시도다.

4-2. Training strategy

논문의 학습은 Stage 0, Stage 1, Stage 2의 세 단계로 나뉜다.

Stage	목적	데이터	Max Resolution	Sequence Length	Batch Size	Epoch
Stage 0-a	language-image alignment	Image Caption 558K	2048 x 28 x 28	4096	128	1
Stage 0-b	visual instruction tuning	VQA 665K	4096 x 28 x 28	4096	64	1
Stage 1	document parsing pre-training	Layout & OCR 6.9M	2048 x 28 x 28	8192	256	2
Stage 2	difficult-case fine-tuning	Layout & OCR 630K	2048 x 28 x 28	16384	256	3

Stage 0: modality alignment

Stage 0는 두 단계다.

• 0-a: patch merger의 2-layer MLP만 학습
• 0-b: 전체 parameter unfreeze 후 visual instruction tuning

이 단계는 OCR capability와 vision-language alignment의 바닥을 만드는 역할이다. 논문도 이 stage를 건너뛰면 loss가 높아지고 overall performance가 떨어진다고 말한다.

Stage 1: document parsing pre-training

Stage 1은 모델이 layout analysis와 content recognition의 기본기를 익히는 단계다.

• total 6.9M samples / epoch
• breakdown:
  • layout analysis: 2.3M
  • text blocks: 2.4M
  • formula blocks: 1.1M
  • table blocks: 1.1M

prompt도 명확히 분리한다.

• Layout Detection:
• Text Recognition:
• Formula Recognition:
• Table Recognition:

이 구조는 one-model multi-task이지만, supervision target과 prompting은 꽤 명시적으로 나눈 셈이다.

Stage 2: difficult-case fine-tuning

Stage 2는 hard case 보강 단계다.

• total 630K samples / epoch
• breakdown:
  • layout analysis: 43K
  • text blocks: 300K
  • formula blocks: 147K
  • table blocks: 140K

여기서 중요한 건 데이터 크기보다 샘플 선택 전략 이다. pretraining에서 넓게 커버하고, fine-tuning에서는 좁고 깊게 들어간다.

Learning rate

논문에는 learning rate도 stage별로 비교적 명시적으로 제시된다.

• LR: ψ_ViT
  • Stage 0-a: 1e-3
  • Stage 0-b: 1e-5
  • Stage 1: 4e-6
  • Stage 2: 4e-6
• LR: {θ_MLP, ϕ_LM}
  • Stage 0-a: 1e-3
  • Stage 0-b: 1e-5
  • Stage 1: 4e-5
  • Stage 2: 4e-5

숫자 자체보다 중요한 건, vision 쪽은 conservative하게, language/MLP 쪽은 상대적으로 더 공격적으로 업데이트한다는 점이다. 문서 파싱에서는 decoder를 완전히 새로 배우는 문제보다는 visual parsing behavior를 task-specific하게 맞추는 문제 가 더 크다는 해석과도 맞는다.

4-3. Engineering notes

1) augmentation은 꽤 실전적이다

논문은 Stage 1, 2에서 spatial/background/color/degradation augmentation을 사용한다.

• scaling, grid distortion, rotation
• texture, weather effect, watermark, scanlines, shadow
• brightness contrast, illumination, RGB shift
• blur, erosion/dilation

특히 watermark, scanline, shadow 같은 항목은 문서 실전 분포를 꽤 잘 의식한 설계다. 다만 layout analysis sample에는 spatial transformation을 적용하지 않는다. bbox supervision을 고려하면 합리적이다.

2) serving 설계가 논문 본문에 들어와 있다

vLLM 위에 아래 최적화를 얹는다.

• asynchronous backend
• Stage I / Stage II decoupling
• layout-type-aware frequency/presence penalty
• max_num_batched_tokens, max_num_seqs, cuda_graph_sizes tuning

특히 stage II에서 repetitive structure 억제를 layout type에 따라 다르게 주는 부분이 흥미롭다. text paragraph에는 penalty를 높이고, table에는 낮춘다. 이런 건 paper figure보다 현업 inference tuning 노트 에 더 가까운 가치가 있다.

5. Evaluation

5-1. Main results

1) Full-document parsing

OmniDocBench

논문은 최신 OmniDocBench 버전(총 1,355 pages)으로 평가한다. 이 버전은 Notes/Newspapers 해상도 상향, 374페이지 추가, evaluation methodology update가 반영되어 있다.

MinerU2.5의 핵심 수치는 다음과 같다.

• Overall: 90.67
• Text Edit Distance: 0.047
• Formula CDM: 88.46
• Table TEDS: 88.22
• Table TEDS-S: 92.38
• Read Order Edit Distance: 0.044

이 결과는 dots.ocr의 overall 88.41 보다 2.26점, Gemini-2.5 Pro의 88.03 보다 2.64점 높다. 특히 여기서 중요한 건 text만 이긴 게 아니라, formula / table / reading order까지 같이 강하다 는 점이다. 문서 파싱에서는 이 균형이 더 중요하다.

document-type별 Table 6도 꽤 의미 있다.

• textbook: 0.0499로 best
• newspaper: 0.054로 best
• financial report: 0.0104로 second-best
• slides: 0.0294로 second-best

즉 특정 문서 유형 한두 개만 잘한 게 아니라, broad coverage가 괜찮다.

Ocean-OCR

dense OCR 관점에서는 Ocean-OCR 결과가 꽤 강하다.

• English
  • edit distance: 0.033
  • F1: 0.945
  • BLEU: 0.909
  • METEOR: 0.950
• Chinese
  • edit distance: 0.082
  • F1: 0.965
  • precision: 0.966
  • BLEU: 0.817
  • METEOR: 0.887

이건 “문서 파싱 전체”뿐 아니라 dense OCR 자체도 꽤 잘한다 는 증거다.

olmOCR-bench

olmOCR-bench 결과도 인상적이지만, 읽을 때 caveat가 있다. 저자들은 AR / OSM formula 항목에 대해 원래 metric 대신 ExpRate of CDM 을 사용한다. 논문 설명대로라면 이는 syntax-variation sensitivity를 줄이기 위한 조정인데, 동시에 완전히 동일한 benchmark protocol comparison은 아니다 라는 점도 기억해야 한다.

그 조건 아래서 MinerU2.5는 다음 결과를 낸다.

• Overall: 75.2
• AR: 76.6
• OSM: 54.6
• LTT: 83.5

overall 기준으로 dots.ocr 73.6 보다 1.6점 높다. 특히 math-heavy subset과 long tiny text에서 강한 편이다.

2) Element-specific parsing

Layout analysis

zero-shot layout evaluation에서 MinerU2.5는 세 dataset 모두에서 Full Page F1@PageIoU가 가장 높다.

• OmniDocBench: 95.9
• D4LA: 90.2
• DocLayNet: 94.6

이건 꽤 중요한 결과다. full-document OCR 논문은 text extraction score가 높아도 layout이 약한 경우가 많다. MinerU2.5는 오히려 layout stage 자체가 강해서 전체 시스템이 안정적 인 타입에 가깝다.

Table recognition

Table 10은 내가 보기엔 이 논문의 강점을 가장 잘 보여주는 실험 중 하나다.

• PubTabNet: 89.07 / 93.11
• FinTabNet: 95.97 / 97.61
• CC-OCR: 79.76 / 85.16
• OCRBench v2: 87.13 / 90.62
• In-house TR Benchmark: 71.48 / 82.83

FinTabNet 쪽 gap이 특히 큰데, 논문은 이를 financial report table data의 대규모 고품질 수집과 연결한다. 또 PubTabNet에서는 학습 데이터를 20%만 사용하고도 competitive한 결과를 보인다고 설명한다. 즉 OTSL과 data curation이 같이 작동한 결과로 읽는 편이 맞다.

Formula recognition

Formula recognition 쪽은 “무조건 압도”로 읽으면 안 된다. specialized formula model이 더 강한 subset이 분명 있다. Table 11을 보면:

• CPE: 96.6
• HWE: 94.4
• SCE: 96.4
• SPE: 98.4
• LaTeX-80MM: 90.6
• Chinese: 90.7
• Fuzzy Math: 92.6
• Complex: 82.2

논문 표현대로, MinerU2.5는 4개 dataset에서 best, 1개에서 second-best 다.
내가 보기엔 이 결과의 의미는 “formula specialist를 모두 이겼다”가 아니라, document parsing unified model이 이 정도까지 formula quality를 끌어올렸다는 점 에 있다. 특히 LaTeX-80MM, Fuzzy Math, Complex 같은 harder subset에서 강한 게 눈에 띈다.

3) Throughput / deployment

이 논문의 실전성은 Table 3에서 더 잘 드러난다.

• RTX 4090 48G: 1875.82 tokens/s, 1.70 pages/s
• A100 80G: 2337.25 tokens/s, 2.12 pages/s
• H200 141G: 4938.31 tokens/s, 4.47 pages/s

논문은 page throughput 기준으로 MinerU2.5가

• MonkeyOCR-Pro-3B 대비 4x
• dots.ocr 대비 7x

라고 설명한다. 또 deployment optimization을 빼도 baseline 0.95 pages/s, 1045.14 tokens/s 라고 적고 있다. 즉 이 결과는 “조금 튜닝해서 겨우 돌아간다”가 아니라, 본질적으로 efficiency-oriented operating point 에 있다는 뜻이다.

5-2. What really matters in the experiments

1) 가장 중요한 건 text OCR이 아니라 full-document balance다

문서 파싱에서 text accuracy만 보면 일부 모델도 강하다. 그런데 MinerU2.5는 layout, reading order, formula, table 을 다 합친 overall에서 강하다. 이건 two-stage design이 단순 속도 최적화가 아니라 구조적 품질 개선 으로 이어졌다는 신호다.

2) layout zero-shot 결과가 surprisingly strong하다

세 layout benchmark에서 PageIoU 기준 full-page F1이 모두 최고라는 건, 이 모델의 Stage I가 단순 crop generator가 아니라는 뜻이다. 문서 파싱 multi-stage pipeline은 첫 단계가 약하면 결국 전체가 흔들리는데, MinerU2.5는 그 리스크를 꽤 잘 제어한 것처럼 보인다.

3) table과 hard formula에서 decoupling 효과가 잘 드러난다

긴 table과 multi-line formula는 end-to-end generation이 특히 불안정한 영역이다. OTSL과 ADR은 여기서 분명히 효과를 낸다. 즉 এই 논문은 “detail을 더 보게 했다”보다 difficulty를 더 좋은 representation으로 바꿨다 는 쪽이 더 정확하다.

4) benchmark win을 읽을 때는 protocol caveat를 같이 봐야 한다

• 일부 competitor 결과는 official report에서 가져온 수치가 있다.
• olmOCR-bench는 AR/OSM formula metric을 변경했다.
• 일부 in-house benchmark가 포함되어 있다.

그래서 이 결과를 “절대적 SOTA의 완전 증명”처럼 읽기보다, 설계 방향의 강한 evidence 로 보는 편이 더 균형 잡혀 있다.

6. Limitations

1. 재현성 한계가 남아 있다.
   internal document pool, commercially procured docs, in-house refinement model, in-house benchmark, human QA tool 등 공개 재현이 쉽지 않은 요소가 많다.

2. two-stage pipeline은 여전히 stage dependency를 가진다.
   Stage I layout miss가 나면 Stage II crop 자체가 틀어질 수 있다. unified model을 썼다고 해서 end-to-end coupling 문제가 완전히 사라지는 건 아니다.

3. PageIoU는 장점이 있지만, semantic class error를 상대적으로 약하게 볼 수 있다.
   full-page coverage alignment에는 좋지만, 어떤 블록을 어떤 category로 잘못 태깅했는지까지 항상 엄격하게 반영하지는 않는다.

4. formula recognition에서는 specialized model이 더 강한 subset이 여전히 있다.
   CPE, HWE, SPE 같은 일부 구간에서는 formula specialist가 앞선다. 따라서 “범용 unified model이 specialist를 완전히 대체했다”로 읽으면 과장이다.

5. single unified model이지만 시스템은 여전히 복합적이다.
   prompt switching, crop orchestration, OTSL/ADR conversion, asynchronous serving, type-aware decoding penalty 등 운영 레이어가 상당히 많다. 즉 모델은 하나지만, 실제 시스템은 단순하지 않다.

6. 비교 protocol이 완전히 동일하지 않은 부분이 있다.
   olmOCR-bench AR/OSM metric replacement 같은 조정은 합리적일 수 있으나, strict apples-to-apples comparison이라는 관점에서는 주의가 필요하다.

7. My Take

7-1. Why this matters for my work

내가 이 논문을 좋게 본 이유는, 문서 파싱을 “OCR accuracy competition”이 아니라 고해상도 VLM 시스템 설계 문제 로 다시 보게 만들기 때문이다.

특히 아래 세 가지가 중요했다.

• global/local split
  페이지 전체를 보는 pass와 crop를 읽는 pass를 분리하는 건, 문서뿐 아니라 GUI parsing, slide parsing, chart understanding 같은 문제에도 일반화 가능한 패턴이다.
• problem reformulation
  성능은 backbone이 아니라 representation과 task definition에서 크게 오를 수 있다.
• deployment awareness
  좋은 논문이 아니라, 실제 batch parser로 굴릴 수 있는 설계를 제시한다.

내가 보기엔 이 논문의 진짜 메시지는
문서 파싱에서 강한 모델은 giant end-to-end VLM이 아니라, stage separation과 representation design이 맞물린 시스템에서 나온다
에 가깝다.

7-2. Reuse potential

실무나 연구에서 바로 재사용하고 싶은 포인트는 아래와 같다.

1) global-local decoupling

고해상도 입력 전체를 항상 native-resolution으로 인코딩하지 말고,

• 먼저 cheap global pass로 structure를 잡고
• 이후 expensive local pass를 필요한 곳에만 쓰는 구조

를 기본 설계 원리로 삼을 가치가 크다.

2) self-consistency 기반 hard-case mining

IMIC는 문서 파싱 말고도 label noise가 큰 multimodal task에서 응용 가능하다. “모델이 자꾸 흔들리는 샘플”에 annotation budget을 집중하는 건 꽤 범용적인 아이디어다.

3) intermediate representation 설계

OTSL처럼 HTML보다 짧고 2D structure에 직접 대응되는 표현을 설계하는 태도는, table 외 다른 structured generation task에도 재사용 가능하다.

4) metric redesign

PageIoU처럼 “기존 detection metric이 실제 품질과 안 맞을 때는 metric부터 바꿔야 한다”는 태도도 중요하다. 문서/멀티모달 문제에서는 특히 그렇다.

5) layout-type-aware decoding control

type에 따라 frequency/presence penalty를 다르게 주는 방식은 단순하지만 실용적이다. 표, 수식, paragraph가 같은 decoding failure mode를 갖지 않는다는 점을 inference layer에서 반영한 셈이다.

7-3. Follow-up papers

• MonkeyOCR
  비슷한 multi-stage 방향이지만 여러 specialized model을 쓰는 쪽이다. MinerU2.5와 비교하면 “one-model multi-stage”의 장단점이 더 잘 보인다.

• dots.ocr
  end-to-end native-resolution VLM 계열과 decoupled parsing 계열의 차이를 보기 좋은 비교 대상이다.

• olmOCR
  문서 파싱을 OCR이 아니라 LLM ingestion / linearization problem으로 읽고 싶다면 이어서 보기 좋다. MinerU2.5가 element parsing에 강하다면, olmOCR는 downstream LM utility 관점이 더 강하다.

• Qwen2.5-VL Technical Report
  MinerU2.5 backbone이 어떤 native-resolution vision-language 설계 위에 올라가 있는지 이해하는 데 도움이 된다.

8. Summary

• MinerU2.5의 핵심은 1.2B 규모의 unified VLM보다 global layout / local recognition의 분리 에 있다.
• layout은 position/class/rotation/order의 multi-task로, formula는 ADR로, table은 OTSL로 다시 정의했다.
• training은 broad pretraining + hard-case fine-tuning의 구조이며, IMIC가 데이터 엔진의 중심 역할을 한다.
• 실험은 full-document parsing, layout zero-shot, table/formula subtask, throughput까지 포함해 꽤 설득력 있게 구성되어 있다.
• 다만 internal data/tool 의존성과 benchmark protocol caveat가 있으므로, “완전한 종결”보다 강한 설계 방향 제시 로 읽는 편이 맞다.