OmniDocBench 문서 OCR 평가 체계 심층 분석

이 글은 OmniDocBench가 무엇인지 소개할 뿐만 아니라, 더 중요하게는 다음을 논의한다. 그것이 어떻게 OCR / Document AI 모델을 평가하는지, 그리고 어떻게 자신의 오픈소스 모델, 폐쇄형 API 모델을 통일된 평가 체계에 접속시키는지.

1. 왜 OCR은 Accuracy만 봐서는 안 되는가?

신분증 한 장, 한 줄의 텍스트, 혹은 한 단락의 스캔 텍스트만 인식한다면, 전통적인 OCR(Optical Character Recognition, 광학 문자 인식)의 Accuracy(정확도)는 확실히 어느 정도 참고가 될 수 있다.

하지만 현실 세계의 PDF 문서는 "문자 인식"보다 훨씬 복잡하다.

예를 들어 아래와 같은 논문 한 페이지를 보자.

┌──────────────────────────────────────┐ │ Title │ ├───────────────────┬──────────────────┤ │ Paragraph │ Figure │ │ Paragraph │ │ │ Paragraph │ │ ├───────────────────┴──────────────────┤ │ Formula │ ├──────────────────────────────────────┤ │ Table │ │ │ └──────────────────────────────────────┘

완전한 Document AI(문서 인공지능) 시스템은 동시에 다음을 해결해야 한다.

- 텍스트 인식

- 제목 인식

- 문단 인식

- 표 인식

- 수식 인식

- 이미지 / 도표 인식

- 레이아웃 배치 인식

- 읽기 순서 복원

- 표 구조 복원

- 수학 수식 구조 복원

- Markdown / HTML 등 구조화 결과 생성

따라서:

Document Parsing(문서 파싱)은 단순한 OCR이 아니다.

두 모델이 최종적으로 모두 다음과 같이 인식했다고 가정하자.

The total revenue increased by 20 %.

전통적인 OCR의 관점에서 보면, 둘 다 100점일 수 있다.

하지만 원본 PDF가 다음과 같다면:

Revenue ┌───────────────────────────────┐ │ 2023 │ 100M │ +20% │ │ 2024 │ 120M │ +20% │ └───────────────────────────────┘

모델 A 출력:

| 2023 | 100M | +20% | | 2024 | 120M | +20% |

모델 B 출력:

둘의 텍스트 내용은 큰 차이가 없을 수 있지만, 문서 구조는 완전히 다르다.

이것이 바로 OmniDocBench가 해결하고자 하는 문제다.

2. OmniDocBench란 무엇인가?

OmniDocBench는 실제 PDF 문서 파싱 시나리오를 겨냥한 종합 Benchmark(벤치마크 / 기준 평가) 프레임워크로 이해할 수 있다.

그것은 단순히 OCR을 테스트하는 것이 아니라, 전체 문서 파싱 체인을 둘러싸고 평가 체계를 구축한다.

공식 데이터셋은 현재 다음을 포함한다.

- 1651개의 PDF 페이지

- 10가지 문서 유형

- 5가지 레이아웃 유형

- 5가지 언어 유형

- 28종 Block-Level(블록 레벨) 주석

- 4종 Span-Level(스팬 레벨) 주석

- Reading Order(읽기 순서)

- Page Attribute(페이지 속성)

- Text Attribute(텍스트 속성)

- Table Attribute(표 속성)

동시에 지원하는 것:

- End-to-End Evaluation(엔드투엔드 평가)

- Layout Detection(레이아웃 배치 검출)

- Table Recognition(표 인식)

- Formula Recognition(수식 인식)

- Text OCR(텍스트 인식)

그리고:

- Normalized Edit Distance(정규화 편집 거리)

- BLEU(n-gram 중첩 기반 텍스트 생성 평가 지표)

- METEOR(토큰 매칭 기반 텍스트 생성 평가 지표)

- TEDS(Tree Edit Distance based Similarity, 트리 편집 거리 기반 유사도)

- COCODet / COCO Detection Metrics(COCO 객체 검출 평가 지표)

등의 지표.

공식 저장소는 현재 v1.7까지 업데이트되었다.

그중 v1.6에서는 MGAM(Multi-Granularity Adaptive Matching, 다중 입도 적응형 매칭)을 도입했고, v1.7에서는 다시 Qianfan-OCR leaderboard(리더보드)와 skills-based evaluation(능력 항목 기반 평가)을 추가했다. 2026년 7월에는 커뮤니티가 유지 관리하는 EvalScope 통합도 추가되어, OpenAI-compatible model endpoint(OpenAI 호환 모델 서비스 엔드포인트)의 통일된 평가에 사용된다.

3. OmniDocBench의 핵심 사상

전체 평가 흐름을 추상화하면 대략 다음과 같이 이해할 수 있다.

OmniDocBench │ ▼ ┌─────────────────┐ │ Ground Truth │ │ 실제 주석 데이터 │ └────────┬────────┘ │ │ ▼ ┌───────────────┐ ┌───────────────┐ │ OCR / VLM / │──▶│ Prediction │ │ Document AI │ │ 예측 결과 │ └───────────────┘ └───────┬───────┘ │ ▼ ┌───────────────┐ │ Matching │ │ 매칭 │ └───────┬───────┘ │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ Text Table Formula 텍스트 표 수식 │ │ │ ▼ ▼ ▼ Metric Metric Metric 지표 계산 지표 계산 지표 계산 │ │ │ └──────────────┼──────────────┘ ▼ Result / Report 결과 / 보고서

여기서 가장 관건은 Metric(지표) 자체가 아니다.

바로:

Prediction → Matching → Metric

즉:

모델이 무엇을 출력하는가 → Ground Truth와 어떻게 대응하는가 → 마지막으로 어떻게 점수를 계산하는가.

이것이 또한 OmniDocBench 소스 코드를 이해하는 가장 중요한 한 줄기다.

4. OmniDocBench의 데이터셋 구조

전형적인 데이터 디렉터리는 다음과 같이 이해할 수 있다.

OmniDocBench/ ├── images/ │ ├── xxx.jpg │ ├── xxx.jpg │ └── ... │ ├── pdfs/ │ ├── xxx.pdf │ ├── xxx.pdf │ └── ... │ └── OmniDocBench.json

그중:

images/

페이지 이미지를 저장한다.

pdfs/

대응하는 PDF를 저장한다.

그리고:

OmniDocBench.json

완전한 구조화 Ground Truth(실제 주석 / 표준 답안)를 저장한다.

그것은 단순한 순수 텍스트만 저장하는 것이 아니라, 문서 요소의 위치, 범주, 내용, 속성 및 읽기 순서 등의 정보도 포함한다. 예를 들어:

layout_dets category_type poly ignore order anno_id text latex html attribute line_with_spans merge_list page_info

따라서 매우 중요한 인식은 이것이다.

OmniDocBench의 핵심 Ground Truth는 구조화 JSON이며, 단순한 Markdown이 아니다.

이 점은 뒤의 End-to-End Evaluation을 이해하는 데 매우 중요하다.

4.1 End-to-End Prediction은 왜 Markdown인가?

공식 End-to-End Evaluation(엔드투엔드 평가)에서 모델은 전체 페이지 PDF 파싱 결과를 제공해야 한다.

Prediction(예측 결과)은 보통 페이지마다 하나의 Markdown 파일 형태로 저장된다.

images/ page_001.jpg page_002.jpg prediction/ page_001.md page_002.md

대응 관계:

page_001.jpg │ ▼ OCR / VLM / Document Parser │ ▼ page_001.md

여기서 특히 주의할 점:

"모델의 End-to-End Prediction이 Markdown을 사용한다"는 것이 "OmniDocBench의 Ground Truth가 곧 Markdown이다"라는 뜻은 아니다.

공식은 실제로 두 가지 End-to-End Evaluation 방식을 제공한다.

End - to - End Evaluation │ ┌────────────┴────────────┐ ▼ ▼ end2end md2md │ │ JSON Ground Truth Markdown Ground Truth │ │ └────────────┬────────────┘ │ ▼ Markdown Prediction

end2end

는 공식이 더 권장하는 방식이다.

왜냐하면 그것은 OmniDocBench JSON의 다음 정보를 보존할 수 있기 때문이다.

category attribute ignore order page_info

등의 구조화 정보를 보존하여, 더 세밀한 평가, 필터링 및 Attribute-Level Evaluation(속성 레벨 평가)을 지원할 수 있다.

5. Block-Level과 Span-Level

OmniDocBench의 Annotation(주석) 체계를 이해하는 것은 매우 중요하다.

5.1 Block-Level

Block-Level(블록 레벨)은 주로 페이지 내의 비교적 큰 구조 영역을 설명한다.

예를 들어:

Text Title Table Figure Formula Header Footer ...

이렇게 이해할 수 있다.

Page ├── Title ├── Text ├── Figure ├── Table ├── Formula └── Text

각 Block은 보통 다음을 가진다.

bbox category text attribute order

- bbox : 영역 좌표

- category : 요소 범주

- text : 인식 내용

- attribute : 요소 속성

- order : 읽기 순서

6. Span-Level

Span-Level(스팬 레벨)은 더 세밀하다.

예를 들어 한 단락의 텍스트:

The equation x² + y² = z² is important.

그중에는 추가로 다음과 같이 표시될 수 있다.

Text ├── Text Line ├── Inline Formula ├── Subscript └── Text

따라서 OmniDocBench는 다음과 같은 것이 아니다.

Page → OCR

Page │ ├── Block │ ├── Text │ ├── Table │ ├── Formula │ └── Figure │ └── Span ├── Text Line ├── Inline Formula └── Subscript

이러한 설계는 평가가 "전체 페이지 점수"에서 한 걸음 더 나아가 다음까지 파고들 수 있게 한다.

도대체 어떤 문서 요소에서 문제가 발생했는가?

7. Attribute-Level Evaluation(속성 레벨 평가)

OmniDocBench의 매우 가치 있는 설계 중 하나는 Attribute-Level Evaluation이다.

예를 들어 일부 페이지는 다음 속성을 가질 수 있다.

handwritten dense_text multi_column complex_table formula

그러면 최종적으로 다음과 유사한 결과를 얻을 수 있다.

Overall Score: 82.4 Dense Text: 75.2 Complex Table: 61.8 Formula: 89.4 Handwritten: 72.1 Multi Column: 84.7

이는 단순히 다음을 출력하는 것보다:

Score = 82.4

훨씬 의미가 있다.

왜냐하면 엔지니어가 진짜로 알아야 하는 것은:

모델이 왜 82점밖에 안 나왔는가?

만약 다음을 발견했다면:

Text 95 Formula 92 Table 58

그렇다면 모델의 문제는 분명히 Table Recognition(표 인식)에 집중되어 있다.

이는 Model Selection(모델 선정)에 직접 영향을 미친다.

그리고 이것 또한 공식이 end2end를 권장하는 중요한 이유 중 하나이다. JSON Ground Truth는 더 풍부한 카테고리와 속성 정보를 보존하므로, 속성 수준의 결과 분석을 추가로 할 수 있다.

8. OmniDocBench의 Evaluation Pipeline

엔지니어링 관점에서 평가 흐름은 다음과 같이 나눌 수 있다.

Dataset │ ▼ Ground Truth Loader(실제값 로딩) │ ▼ Prediction Loader(예측값 로딩) │ ▼ Normalization(정규화) │ ▼ Matching(매칭) │ ▼ Metric Calculation(지표 계산) │ ▼ Attribute Aggregation(속성 집계) │ ▼ Report

대응되는 소스 코드는 보통 몇 개의 핵심 모듈로 이해할 수 있다.

dataset task metrics registry configs tools utils

dataset

데이터 읽기와 데이터 구조 처리를 담당한다.

task

서로 다른 task를 담당한다.

metrics

구체적인 지표 계산을 담당한다.

registry

Task, Dataset, Metric 등의 객체 등록을 담당한다.

configs

YAML 설정을 담당한다.

tools

데이터 변환, 시각화, 모델 추론 등의 도구를 담당한다.

9. Matching: 진짜로 가장 과소평가되기 쉬운 핵심 모듈

많은 사람이 Benchmark를 처음 접할 때 이렇게 생각한다.

Prediction ↓ Metric ↓ Score

실제로는 중간에 매우 중요한 과정이 하나 더 있다.

Ground Truth가 다음과 같다고 가정하자.

Paragraph A Paragraph B Paragraph C

모델 출력:

Paragraph A + B Paragraph C

그렇다면:

GT: A B C Prediction: A+B C

도대체 어떻게 비교해야 하는가?

만약 단순히 다음처럼 한다면:

A ↔ A + B B ↔ ? C ↔ C

뚜렷한 채점 편차가 발생한다.

Matching은 단순한 데이터 구조 조작이 아니라, 전체 Benchmark 공정성의 핵심 중 하나이다.

10. no_split / simple_match / quick_match

OmniDocBench는 여러 가지 매칭 방식을 제공한다.

10.1 no_split

match_method: no_split

다음과 같이 이해할 수 있다.

세밀한 텍스트 블록 매칭을 하지 않고, 내용을 전체적으로 이어 붙인 뒤 비교한다.

장점:

- 단순함

- 빠름

- 문단 분할의 영향을 받기 어려움

단점:

- 충분히 세밀한 결과를 제공하지 못함

- 문제를 특정하는 능력이 약함

- 복잡한 구조 차이를 분석하기에 적합하지 않음

11. simple_match

match_method: simple_match

먼저 문단 분할을 수행한다.

Prediction │ ├── Paragraph 1 ├── Paragraph 2 └── Paragraph 3

그런 다음 일대일 매칭을 수행한다.

no_split보다 더 정밀하지만, 모델의 Paragraph Segmentation(문단 분할)이 비교적 정확할 것을 요구한다.

12. quick_match(빠른 매칭)

공식 End-to-End 설정에서 quick_match는 매우 흔한 매칭 방식이다.

match_method: quick_match

이는 기본 분할에 다음을 더한다.

- Truncation(절단)

- Merging(병합)

- Adjacency Search(인접 검색)

목적은 바로:

모델이 단지 문단 분할 방식이 다르기 때문에 발생하는 불필요한 감점을 줄이는 것이다.

예를 들어 Ground Truth:

A B C

Prediction:

quick_match는 더 합리적인 매칭 관계를 찾으려 시도한다.

모델 인식 오류

와:

모델이 단지 분할 방식이 다른 것

을 더 잘 구분할 수 있다.

공식 현재 End-to-End 설정 예시도 quick_match를 사용하며, 매칭 타임아웃, Fallback(폴백) 관련 파라미터를 제공한다.

13. MGAM: v1.6 이후 매우 중요한 변화

OmniDocBench v1.6에서 MGAM을 도입했다.

MGAM(Multi-Granularity Adaptive Matching, 다중 입도 적응형 매칭)

이는 Matching Bias(매칭 편향) 문제를 해결한다.

핵심 사상은 다음과 같이 요약할 수 있다.

Ground Truth │ │ 변하지 않고 유지 ▼ ┌─────────────────────┐ │ Prediction │ │ │ │ Granularity 1 │ │ Granularity 2 │ │ Granularity 3 │ │ ... │ └──────────┬──────────┘ │ ▼ Search Best Match 최적 매칭 탐색

즉:

Ground Truth를 바꾸지 않고, Prediction(예측 결과) 측에서 더 합리적인 분할 입도를 찾는다.

이는 Document Parsing에서 특히 중요하다.

GT: ┌─────────────────────┐ │ 하나의 완전한 큰 문단 │ └─────────────────────┘

모델은 다음을 출력할 수 있다.

Line 1 Line 2 Line 3 Line 4 Line 5

만약 곧바로 Block-Level Matching을 하면, 모델은 예측 입도가 다르기 때문에 뚜렷한 영향을 받을 수 있다.

MGAM의 목표는 바로 이러한 예측 입도 차이로 인한 Matching Bias를 줄이는 것이다.

공식 v1.6 업데이트 설명도 이 설계를 명확히 기술한다. Ground Truth는 변하지 않게 유지하고, Prediction 한쪽에서만 적응형 입도 조정을 수행한다.

14. Text OCR의 평가

Text OCR은 주로 다음을关注한다.

GT Text ↕ Prediction Text

핵심 지표 중 하나는:

15. Edit Distance란 무엇인가?

Edit Distance(편집 거리)는 두 문자열이 서로 변환되기 위해 몇 번의 편집 연산이 필요한지를 측정한다.

GT: hello Prediction: helo

l 하나만 삭제하면 된다.

Edit Distance = 1

흔한 편집 연산은 다음과 같다.

Insert Delete Replace

- 삽입

- 삭제

- 교체

16. 왜 Normalized Edit Distance가 필요한가?

왜냐하면:

hello

This is a very long paragraph...

길이가 완전히 다르기 때문이다.

만약 곧바로 Edit Distance를 사용하면:

error = 5

이는 짧은 텍스트와 긴 텍스트에서 의미가 다르다.

따라서 정규화가 필요하다.

간단히 이렇게 이해할 수 있다.

Normalized Error ≈ Edit Distance / Reference Length

그런 다음 추가로 다음으로 변환한다.

Similarity = 1 - Normalized Error

실제 구현은 OmniDocBench 현재 코드에 있는 정의를 기준으로 해야 한다.

핵심 사상은 바로:

텍스트 길이 차이가 최종 점수에 미치는 영향을 줄이는 것이다.

17. CER / WER와 OmniDocBench

전통적인 OCR 시스템은 자주 다음을 사용한다.

CER WER

- CER(Character Error Rate, 문자 오류율)

- WER(Word Error Rate, 단어 오류율)

그러나 다국어 Document Parsing에서는:

중국어 영어 수식 기호 특수문자 Markdown

단순히 CER / WER만 사용하는 것으로는 문서 파싱 품질을 온전히 설명할 수 없다.

따라서 OmniDocBench는 해당 시나리오에 더 적합한 Normalized Edit Distance를 사용하며, 동시에 표, 수식, 레이아웃 등 다른 지표를 결합한다.

18. Table Recognition: 표는 왜 텍스트 비교만 해서는 안 되는가?

다음을 고려하자.

A | B --|-- 1 | 2 3 | 4

문자 내용은 완전히 같을 수 있다.

그러나 첫 번째는 다음을 보존한다.

Column Row Cell

구조를.

두 번째는 그렇지 않다.

따라서 Table Recognition(표 인식)은 동시에 평가해야 한다.

Content + Structure

이것이 바로 TEDS가 등장한 이유이다.

19. TEDS

TEDS:

그것은 HTML Table을 하나의 트리로 본다.

< table > < tr > < td > A </ td > < td > B </ td > </ tr > </ table >

다음과 같이 추상화할 수 있다.

table └── tr ├── td └── td

따라서 비교하는 것은 단지:

A B

만이 아니라:

Table Structure + Cell Structure + Cell Content

이것이 바로:

표 평가가 단순히 문자열 Edit Distance를 사용할 수 없는 이유이다.

20. Formula Recognition: 수식은 왜 더 특수한가?

Ground Truth가 다음과 같다고 가정하자.

x^2 + y^ 2 = z^ 2

문자열 관점에서는:

완전히 일치하지 않음

그러나 수식의 시각적 표현 관점에서는:

완전히 동등할 수 있음

따라서 Formula Recognition(수식 인식)에는 더 특수한 지표가 필요하다.

OmniDocBench에서는 다음을 사용한다.

CDM

수식의 시각적 차원 비교에 사용된다.

핵심 사고는 다음과 같이 이해할 수 있다.

LaTeX │ ▼ Rendering(렌더링) │ ▼ Image │ ▼ Visual Similarity(시각적 유사도)

Formula String

최종적으로 다음으로 변환된다.

Rendered Formula Image

그런 다음 시각적 비교를 수행한다.

이는 대량의:

LaTeX 표기 방식이 다름

그러나:

최종 시각적 결과가 동일함

인 경우를 해결한다.

21. Layout Detection

Layout Detection(레이아웃 검출)은 다음을关注한다.

Where ? What?

이 영역은 어디에 있는가? 이 영역은 어떤 유형인가?

┌─────────────────────────┐ │ Title │ ├─────────────┬───────────┤ │ Text │ Figure │ │ Text │ │ ├─────────────┴───────────┤ │ Table │ └─────────────────────────┘

모델은 다음을 예측해야 한다.

bbox category

이런 task는 본질적으로 객체 검출과 유사하다.

따라서 OmniDocBench는 다음을 사용한다.

포함:

mAP mAR

- mAP(mean Average Precision, 평균 정밀도 평균)

- mAR(mean Average Recall, 평균 재현율 평균)

22. End-to-End Evaluation

End-to-End Evaluation(엔드투엔드 평가)은 OmniDocBench에서 가장 주목할 만한 능력 중 하나이다.

그것은:

OCR만 평가하는 것

도 아니고:

Layout만 평가하는 것

도 아니며, 모델의 전체 페이지 PDF 문서에 대한 파싱 능력을 직접 평가한다.

전체 흐름은 다음과 같이 이해할 수 있다.

PDF Page ↓ Document Parser ↓ Markdown ↓ OmniDocBench ↓ 전체 평가

그러나 여기에는 매우 쉽게 오해되는 지점이 하나 있다.

OmniDocBench의 End-to-End Evaluation은 평가 방식이 하나만 있는 것이 아니다.

공식적으로 제공하는 것은 다음과 같다.

End - to - End Evaluation │ ├── end2end │ ├── Ground Truth：OmniDocBench JSON │ └── Prediction：Markdown │ └── md2md ├── Ground Truth：OmniDocBench Markdown └── Prediction：Markdown

공식 권장 사항은 다음과 같다.

단순히 End-to-End를 다음과 같이 이해하는 것이 아니다.

Markdown ↔ Markdown

22.1 end2end：JSON Ground Truth + Markdown Prediction

end2end는 공식적으로 더 권장하는 End-to-End Evaluation 방식이다.

그 입력 관계는 다음과 같다.

OmniDocBench.json │ │ Ground Truth ▼ Matching ▲ │ Prediction │ page_001.md

Ground Truth = OmniDocBench JSON

Prediction = 모델이 생성한 전체 페이지 Markdown

JSON Ground Truth + Markdown Prediction ↓ Matching ↓ Text / Formula / Table / Reading Order ↓ Metric

이 방식의 가장 큰 가치는 다음에 있다.

JSON Ground Truth에는 Markdown 자체로는 온전히 표현할 수 없는 구조화된 주석 정보가 저장되어 있다.

따라서 공식적으로 end2end를 명확히 권장하는데, 이는 샘플의 category와 attribute 정보를 보존할 수 있고, 특수 범주 무시 및 속성 수준 결과 출력을 지원하기 때문이다.

22.2 end2end는 어떤 차원을 평가하는가?

공식적으로 현재 End-to-End Evaluation은 네 가지 핵심 차원을 평가할 수 있다.

Text Paragraphs Display Formulas Tables Reading Order

예를 들어 공식 설정은 다음과 같이 이해할 수 있다.

end2end_eval: metrics: text_block: metric: [ Edit_dist , BLEU , METEOR ] display_formula: metric: [ Edit_dist , CDM ] table: metric: [ TEDS , Edit_dist ] reading_order: metric: [ Edit_dist ] dataset: dataset_name: end2end_dataset ground_truth: data_path: ./data/OmniDocBench.json prediction: data_path: ./prediction match_method: quick_match

ground_truth.data_path

는 OmniDocBench JSON을 가리킨다.

prediction.data_path

는 모델이 출력한 Markdown 파일 디렉터리를 가리킨다.

22.3 Prediction 디렉터리는 어떤 모습인가?

prediction/ ├── page_0001.md ├── page_0002.md ├── page_0003.md └── ...

만약 원본 페이지 이미지가 다음과 같다면

page_0001.jpg page_0002.jpg page_0003.jpg

Prediction은 그에 대응한다.

page_0001.md page_0002.md page_0003.md

.jpg → .md

파일명은 대응을 유지한다.

공식 README도 현재 Prediction이 모델이 전체 페이지 PDF 페이지를 파싱해 생성한 Markdown 파일 디렉터리라고 명확히 설명하고 있다.

23. 왜 공식적으로 end2end를 권장하는가?

그 이유는 다음이 아니다.

JSON이 Markdown보다 더 고급이기 때문

JSON Ground Truth에는 더 풍부한 평가 정보가 저장되어 있다.

category attribute ignore reading order page information

이 정보들은 모델 품질을 분석하는 데 매우 중요하다.

두 모델이 최종적으로 다음과 같다고 가정하자.

Overall Score

가 비슷하다.

모델 A:

Text 95 Table 62 Formula 94

모델 B:

Text 91 Table 89 Formula 91

단순히 Markdown-to-Markdown(Markdown에서 Markdown으로) 비교만 한다면, 많은 구조화 정보를 더 분석하기 어렵다.

반면 end2end는 JSON Ground Truth의 속성과 범주 정보를 보존하므로 추가로 다음을 할 수 있다.

Attribute-Level Evaluation Category Filtering Ignore Rules Page-Level Analysis

이것이 공식적으로 end2end를 권장하는 핵심 이유다.

24. md2md는 무엇인가?

md2md는 다음과 같이 이해할 수 있다.

Markdown-to-Markdown Evaluation(Markdown에서 Markdown으로의 평가).

이는 OmniDocBench가 제공하는 두 번째 End-to-End Evaluation 방법이다.

그 구조는 매우 직관적이다.

Ground Truth Markdown ↓ Matching ↑ │ Prediction Markdown ↓ Metric

여기서

Ground Truth = OmniDocBench Markdown

GT Markdown │ │ ▼ Markdown Parser │ ▼ Matching ▲ │ Prediction Markdown

공식적으로 md2md를 유지하는 주된 이유는 기존의 Markdown-to-Markdown 평가 방식과 일관성을 유지하기 위해서다.

따라서 그것이 잘못된 방식인 것은 아니다.

다만:

OmniDocBench의 구조화된 주석 정보를 충분히 활용하고자 한다면, 공식적으로는 end2end를 더 권장한다.

24.1 md2md의 Ground Truth

전형적인 디렉터리는 다음과 같이 이해할 수 있다.

ground_truth/ ├── page_0001.md ├── page_0002.md ├── page_0003.md └── ...

모델 Prediction:

그리고:

GT Markdown ↕ Prediction Markdown ↓ Matching ↓ Metrics

공식적으로 다음과 같은 설정도 허용한다.

ground_truth: data_path: ./data/mds page_info: ./data/OmniDocBench.json

page_info

는 주로 페이지 수준 속성을 가져오는 데 사용된다.

페이지 속성 평가가 필요하지 않다면 생략할 수 있다.

반면 페이지 속성을 기반으로 다음을 수행해야 한다면

filter

page_info를 제공해야 한다.

25. end2end와 md2md는 도대체 어떻게 선택하는가?

다음 그림처럼 바로 기억하면 된다.

End - to - End Evaluation │ ┌──────────────┴──────────────┐ │ │ ▼ ▼ end2end md2md │ │ ▼ ▼ JSON Ground Truth Markdown Ground Truth │ │ └──────────────┬──────────────┘ │ ▼ Markdown Prediction │ ▼ Matching │ ▼ Metrics

선택 제안:

만약 OmniDocBench 자체를 연구하고 있다면

우선:

JSON GT + Markdown Prediction

OmniDocBench의 주석 정보를 최대한 활용할 수 있다.

만약 이미 Markdown-to-Markdown 평가 체계를 갖추고 있다면

다음을 사용할 수 있다.

md2md

이렇게 하면 기존 Markdown 평가 결과와 일관성을 유지하기가 더 쉽다.

md2md는 공식적으로 지원하는 방식이지만, end2end는 공식적으로 더 권장하는 방식이다.

26. 자신의 OCR 모델은 어떻게 연동하는가?

이것이 실제 개발에서 가장 중요한 부분이다.

당신에게 다음과 같은 모델이 있다고 가정하자.

class My OCR: def predict ( self , image ): ...

목표가 End-to-End Evaluation을 하는 것이라면, 가장 흔한 연동 방식은 다음과 같다.

Image ↓ MyOCR / Document Parser ↓ Markdown ↓ Prediction Directory ↓ OmniDocBench

Image ↓ My Model ↓ page_0001.md ↓ end2end ↓ OmniDocBench

핵심은 OmniDocBench의 Metric을 수정하는 것이 아니다.

평가하려는 작업에 따라, 모델 출력을 OmniDocBench에 대응하는 Prediction 형식에 맞추는 것이다.

End-to-End의 경우:

모델 출력 ↓ 전체 페이지 Markdown ↓ end2end / md2md

반면 Text / Formula / Table Recognition(텍스트 / 수식 / 표 인식) 등 단일 모듈 작업의 경우, 공식적으로 구조화된 JSON Prediction도 지원하므로 "모든 작업을 반드시 Markdown으로 변환해야 한다"고 단순히 말할 수는 없다.

27. Model Adapter

Model Adapter(모델 어댑터)를 설계할 것을 권장한다.

class OmniDocBenchAdapter : def __init__ ( self , model ): self .model = model def predict ( self , image ): result = self .model.predict(image) return self .to_markdown(result) def to_markdown ( self , result ): ...

adapter = OmniDocBenchAdapter(model) for image in images: markdown = adapter.predict(image) save_prediction( image =image, markdown =markdown )

이렇게 하면:

Your Model ↓ Adapter ↓ Standard Prediction ↓ OmniDocBench

Standard Prediction = Page-level Markdown

반면 다른 단일 모듈 작업의 경우에는 해당 작업의 JSON Schema(JSON 데이터 구조)와 설정 요구 사항에 따라 Prediction을 생성해야 한다.

28. 왜 반드시 Adapter를 설계해야 하는가?

모델 출력의 차이가 매우 크기 때문이다.

OCR 모델

{ "text" : "hello world" , "bbox" : [ 10 , 20 , 100 , 50 ] }

Document VLM

Title This is a paragraph. | A | B | |---|---| | 1 | 2 |

클라우드 OCR API

{ "pages" : [ { "blocks" : [ ... ] } ] }

이 데이터를 그대로 Benchmark에 밀어 넣으면:

Benchmark ├── Model A format ├── Model B format ├── Model C format └── Model D format

곧 통제 불능이 된다.

더 합리적인 것은:

┌── Model A │ ├── Model B │ ├── Model C │ └── Model D │ ▼ ┌──────────────┐ │ Adapter │ └──────┬───────┘ ▼ Standard Output │ ▼ OmniDocBench

여기서 Standard Output(표준화 출력)은 구체적인 작업에 따라 결정해야 한다.

End - to - End ↓ Markdown Single - module Recognition / Detection ↓ JSON

이래야 진정으로 확장 가능한 아키텍처다.

29. 오픈소스 OCR 모델 평가

Open Source Model(오픈소스 모델)의 경우 보통 세 가지 접속 방식이 있다.

29.1 로컬 OCR Engine

PaddleOCR Tesseract EasyOCR

모델을 로컬에 배포한다.

흐름:

Image ↓ Local OCR Engine ↓ JSON / Text ↓ Markdown Builder ↓ Prediction ↓ OmniDocBench

이 방식의 장점:

- API 비용 없음

- 오프라인 가능

- 재현 가능

- 모델 버전 제어 가능

- GPU 제어 가능

- Debug 편의성

- 모델 환경 유지보수 필요

- GPU 자원 비용이 비교적 높음

- 모델마다 배포 복잡도가 다름

30. Document VLM

최근 많은 문서 모델이 전통적 OCR에서 다음으로 전환했다.

Document VLM(문서 시각 언어 모델)

전형적인 형태:

Image ↓ Vision Encoder ↓ LLM ↓ Markdown

Qwen-VL InternVL MinerU PaddleOCR-VL DeepSeek-OCR

이런 모델은 보통 다음에 더 적합하다.

복잡한 문서 표 수식 이미지·텍스트 혼합 배치 다단 레이아웃

모델 자체가 이미 전체 페이지 Markdown을 직접 출력할 수 있다면, End-to-End Benchmark에 접속하기가 매우 편리하다.

Image ↓ Document VLM ↓ Markdown ↓ Prediction Directory ↓ end2end

31. vLLM / OpenAI-compatible Server

모델을 다음과 같이 배포할 수 있다면:

vLLM SGLang OpenAI-compatible Server

평가가 더욱 간단해진다.

아키텍처:

OmniDocBench Runner │ ▼ OpenAI-compatible API │ ▼ Model │ ▼ Markdown

from openai import OpenAI client = OpenAI( base_url = "http://localhost:8000/v1" , api_key = "EMPTY" )

response = client.chat.completions.create( model = "my-ocr-model" , messages =[ { "role" : "user" , "content" : "Parse this document..." } ] )

이렇게 하면 모델을 통일되게 하나의

Model Provider

로 캡슐화할 수 있다.

공식 현재 저장소는 이미 커뮤니티가 유지보수하는 EvalScope 통합을 제공하며, OpenAI-compatible model endpoint의 OmniDocBench 평가에 사용할 수 있다.

32. 폐쇄형 OCR API 평가

폐쇄형 모델의 평가 방식과 로컬 모델의 가장 큰 차이는:

Inference(추론)

이 원격 서버에서 발생한다는 점이다.

OmniDocBench │ ▼ OCR API │ ▼ Cloud Model │ ▼ Prediction

이런 모델에는 다음이 포함된다.

Cloud OCR API Document AI API Multimodal API

End-to-End Evaluation의 경우, 최종적으로 원격 API의 결과를 다음으로 통일되게 변환할 수 있기만 하면:

page_0001.md page_0002.md ...

동일한 평가 흐름에 진입할 수 있다.

Benchmark는 모델이 로컬에서 실행되는지, 원격 API를 통해 실행되는지를 신경 써서는 안 된다.

그것은 오직 다음만 신경 써야 한다.

Input ↓ Prediction ↓ Evaluation

33. OCRProvider 추상화

통일된 인터페이스를 구축할 것을 권장한다.

from abc import ABC, abstractmethod class OCRProvider ( ABC ): @abstractmethod def parse ( self, image ): pass

class LocalOCRProvider ( OCRProvider ): def parse ( self , image ): return local_model.predict(image)

클라우드:

class CloudOCRProvider ( OCRProvider ): def parse ( self , image ): return api_client.parse(image)

최종적으로:

OCRProvider │ ┌────────┴────────┐ │ │ Local Provider Cloud Provider │ │ ▼ ▼ Local Model API Model

이렇게 하면 Benchmark Runner(벤치마크 테스트 실행기)는 다음을 신경 쓸 필요가 없다.

모델이 도대체 어디에 배포되었는가?

다음만 신경 쓰면 된다.

provider. parse (image)

34. DocumentParser Protocol(프로토콜)

더 나아가 다음과 같이 추상화할 수 있다.

from typing import Protocol class DocumentParser ( Protocol ): def parse ( self, image ) -> str : """ Return Markdown representation. """ ...

모든 End-to-End 모델은 다음을 따른다.

Image ↓ parse () ↓ Markdown

PaddleOCR MinerU Qwen-VL GPT Gemini Claude 자체 개발 모델

모두 통일되게 End-to-End Benchmark에 진입할 수 있다.

여기서 주의할 점:

이 Protocol은 당신 자신의 엔지니어링 추상화이며, OmniDocBench 공식이 모든 모델이 반드시 이 Python 인터페이스를 구현해야 한다고 요구하는 것은 아니다.

그것은 단지 당신의 Benchmark Runner가 서로 다른 모델을 더 쉽게 통일 관리할 수 있도록 하기 위한 것이다.

35. 폐쇄형 API 평가에서 가장 쉽게 간과하는 문제

실제로 API Benchmark(API 기준 평가)를 할 때, 가장 큰 함정은 보통 코드가 아니다.

Cost(비용) Latency(지연) Reliability(신뢰성) Version Prompt(프롬프트) Rate Limit(속도 제한)

이런 변수들을 잘 통제하지 못하면:

Model A = 90 Model B = 88

이것이 반드시 다음을 의미하지는 않는다.

가능한 것은 단지:

Prompt가 다름 Version이 다름 입력 해상도가 다름 Sampling이 다름

으로 인한 것일 수 있다.

36. Cost

가정:

1651 pages

페이지당 API 비용:

$0 .01

1651 × $0 .01 ≈ $16 .51

만약 다음을 수행하면:

10 회 실험

바로:

$165 .1

따라서:

API Benchmark는 반드시 Prediction Cache(예측 캐시)를 설계해야 한다.

37. Prediction Cache

권장되는 Cache Key(캐시 키)에는 다음이 포함된다.

model model_version prompt temperature image_hash input_resolution

cache_key = hash( model + model_version + prompt + temperature + image_hash + input_resolution )

같은 입력 + 같은 모델 + 같은 Prompt

바로 예측 결과를 재사용할 수 있다.

더 완전한 엔지니어링 구현에는 다음도 추가할 수 있다.

system_prompt max_tokens provider API parameters preprocessing version

실험 파라미터 변화로 인해 캐시가 잘못 적중하는 것을 방지한다.

38. Retry와 Backoff

API 호출에는 반드시 다음이 나타난다.

Timeout Rate Limit Network Error 5xx Service Unavailable

따라서 필요하다.

Retry(재시도)

Backoff(백오프)

for attempt in range (max_retries): try : return call_api() except Exception: sleep( min ( 2 ** attempt, 30 ) )

전형적인 전략:

1s 2s 4s 8s 16s

실제 프로덕션 환경에서는 다음을 구분해야 한다.

재시도 가능 오류 재시도 불가능 오류

429 5xx Timeout

보통 재시도할 수 있다.

Authentication Error Invalid Request Invalid Output

은 보통 직접 실패로 기록해야 한다.

39. Rate Limit

Rate Limit(속도 제한)은 폐쇄형 API Benchmark의 또 다른 문제다.

RPM = Requests Per Minute TPM = Tokens Per Minute QPS = Queries Per Second

만약 당신의 동시성이:

100 workers

인데 API가 다음만 허용한다면:

20 QPS

평가가 5배 빨라지지는 않는다.

오히려 다음을 초래할 수 있다.

429 Timeout Retry

결국 더 느려진다.

Concurrency(동시성 수)는 모델 서비스 능력에 의해 결정되어야 하며, 로컬 CPU 수에 의해 결정되어서는 안 된다.

40. Temperature

생성형 모델의 경우:

temperature

역시 결과에 영향을 미친다.

Benchmark가 모델 횡적 비교에 사용된다면, 보통 다음을 권장한다.

temperature = 0

또는 모델 API가 권장하는 결정론적 파라미터를 사용한다.

그렇지 않으면 같은 모델이:

Run 1 → 82.1 Run 2 → 80.7 Run 3 → 83.2

당신이 판단하기 어렵다.

모델 변화

인지:

Sampling Randomness(샘플링 무작위성)

으로 인한 것인지.

따라서 최소한 다음을 해야 한다.

무작위성 파라미터 고정 Prompt 고정 입력 고정 모델 버전 고정

41. Prompt는 반드시 고정해야 한다

만약 비교한다면:

Model A Model B Model C

그러나 사용한다면:

Prompt A Prompt B Prompt C

그렇다면 최종적으로 비교하는 것은 사실:

Model + Prompt

이며, 단순한 Model이 아니다.

따라서 다음을 고정해야 한다.

Prompt Image Resolution Temperature Max Tokens Model Version

그리고 다음만 변경한다.

Model

만약 서로 다른 모델이 반드시 서로 다른 Prompt를 사용해야 한다면, 이러한 차이를 명확히 기록해야 하며, 결과를 곧바로 순수한 모델 능력 비교로 이해해서는 안 된다.

42. Input Resolution

Input Resolution(입력 해상도)도 매우 중요하다.

예를 들어 같은 PDF라도:

72 DPI

200 DPI

얻어지는 이미지 품질 차이가 매우 크다.

특히:

작은 글씨 수식 스캔 문서 표 손글씨 내용

Benchmark의 입력은 반드시 표준화되어야 한다.

다음을 구축할 것을 권장한다.

Canonical Page Image

즉 표준화 페이지 이미지다.

그런 다음 모든 모델이 다음을 사용한다.

같은 Image

로 추론한다.

이래야 보장할 수 있다.

마주하는 것은 완전히 동일한 입력이다.

43. Open Source vs Closed Source의 통일된 평가

최종적으로 다음을 구축할 수 있다:

Benchmark Runner │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ Local Model API Model VLM Server │ │ │ └──────────────┼──────────────┘ ▼ Prediction │ ▼ OmniDocBench │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ Text Table Formula │ │ │ └──────────────┼──────────────┘ ▼ Report

이렇게 하면 다음을 할 수 있다:

Open Source Model(오픈소스 모델)과 Closed Source Model(클로즈드 소스 모델)을 동일한 데이터, 동일한 입력, 동일한 Metric 아래에서 비교한다.

진정으로 표준화가 필요한 것은 모델 자체가 아니라 다음이다:

Dataset Input Prediction Format Evaluation Config Metric

44. 다중 모델 횡적 평가

실제 프로젝트에서는 보통 다음과 같지 않다:

모델 하나를 평가

Model A Model B Model C Model D

models: - name: model_a provider: local - name: model_b provider: vllm - name: model_c provider: cloud

Benchmark Dataset │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ Model A Model B Model C │ │ │ ▼ ▼ ▼ Prediction Prediction Prediction │ │ │ └────────────────┼────────────────┘ ▼ OmniDocBench │ ▼ Quality Matrix 품질 행렬

최종적으로 다음을 얻는다:

Model Text Table Formula Overall Model A 94.2 72.1 89.4 85.2 Model B 91.7 86.3 92.1 89.4 Model C 96.1 80.2 91.7 89.3

이것이야말로 진정으로 엔지니어링 가치가 있는 Benchmark다.

45. Overall Score만 보지 말 것

보기에는:

Model A > Model B

그러나 더 분석해 보면:

Model A Model B Text 96 91 Table 62 89 Formula 94 91 Layout 95 90

당신의 업무가:

재무 보고서

라면 Model B가 확실히 더 나을 수 있다.

일반 텍스트 PDF

라면 Model A가 더 나을 수 있다.

Overall Score는 정렬에 사용되고, Attribute-Level Evaluation은 의사결정에 사용된다.

46. Benchmark의 공정성 문제

Benchmark는 본질적으로 공정하지 않다.

최소한 다음이 존재한다:

Dataset Bias Metric Bias Matching Bias Distribution Bias

각각은 다음과 같다:

- Dataset Bias(데이터셋 편향)

- Metric Bias(지표 편향)

- Matching Bias(매칭 편향)

- Distribution Bias(데이터 분포 편향)

Benchmark 80% English 20% Chinese

실제로는 English OCR에 더 편향되어 있다.

그래서 진짜로 모델 선정을 할 때:

Overall Score는 "평균적인 상황에서 누가 더 나은가"만 답할 수 있을 뿐, "누가 내 업무에 더 적합한가"를 직접 답할 수는 없다.

47. 더 합리적인 평가 행렬

최소한 다음에 따라:

Language Document Type Layout Content Type Attribute

분할할 것을 권장한다.

Text Table Formula Chinese 95 82 91 English 97 88 93 Japanese 91 79 88 Handwritten 76 70 81 Dense Layout 83 72 86

이렇게 해야 진정으로 다음을 답할 수 있다:

모델이 도대체 어떤 시나리오에 적합한가?

48. Docker 배포

OmniDocBench 공식은 현재 Docker 재현 환경을 제공한다.

docker pull ghcr.io/zeng-weijun/omnidocbench-eval:repro-ubuntu2204

현재 공식 검증 환경에는 다음이 포함된다:

Python 3.10 .x TeX Live 2025 ImageMagick 7.1 .1 -47 Ghostscript 9.55 .0

이러한 의존성은 특히 CDM 등 수식 평가 흐름과 관련이 있다. 공식 저장소는 현재 더 안정적인 재현 환경을 얻기 위해 Docker를 우선 사용할 것도 권장한다.

49. 왜 CDM에는 이렇게 많은 의존성이 필요한가?

왜냐하면 이것은 단순한:

string compare

이 아니기 때문이다.

LaTeX ↓ PDF / Image Rendering ↓ Image Comparison

그래서 다음이 필요하다:

TeX Live ImageMagick Ghostscript

Formula ↓ pdflatex ↓ PDF ↓ ImageMagick ↓ PNG ↓ CDM

이것이 바로:

git pip install이 반드시 환경이 이미 완전하다는 것을 의미하지는 않는 이유다.

현재 공식 설정도 CDM 환경이 작동 가능한 TeX Live, ImageMagick, Ghostscript를 갖출 것을 명확히 요구한다.

50. Conda 배포

Docker를 사용하지 않는다면 다음을 생성할 수 있다:

conda create -n omnidocbench python = 3.10 -y conda activate omnidocbench

git clone <repo_url> cd OmniDocBench pip install -e .

검증:

python -c \ "from src .core .pipeline import run_config_file; print ('OK')"

공식 현재 프로젝트는 Python 3.10 이상 3.12 미만을 요구하며, CDM은 추가적인 시스템 수준 의존성이 필요하다.

51. OmniDocBench 실행

핵심 진입점:

python pdf_validation.py \ --config configs/end2end.yaml

코드 + 데이터 + 모델 결과

최종적으로:

YAML Config

가 통일적으로 제어한다.

현재 공식 end2end 설정에서 핵심은 바로:

Ground Truth JSON + Prediction Markdown Directory + Evaluation Config

그런 다음 실행한다:

pdf_validation.py

공식 README도 현재 이러한 방식으로 End-to-End Evaluation을 실행하는 것을 명확히 채택하고 있다.

52. YAML 설정

전형적인 end2end 설정 구조는 다음과 같이 이해할 수 있다:

실제로 사용할 때는 저장소의 현재 버전이 제공하는 설정 템플릿을 기준으로 해야 한다.

설정 파일의 이점은:

코드 로직

실험 파라미터

를 철저히 분리하는 것이다.

53. Worker 동시성

OmniDocBench에는 현재 여러 병렬 단계가 존재한다. 예를 들어:

match_workers cdm_workers teds_workers

각각은 다음과 같이 이해할 수 있다:

페이지 매칭 수식 렌더링 표 TEDS

에 대응하는 동시성 Worker(작업 프로세스) 수다.

공식 현재 README는 사용 가능한 CPU / RAM에 따라 동시성을 제어할 것을 권장하며, CDM Worker의 메모리 오버헤드가 특히 크다는 점을 특별히 지적한다.

dataset: match_workers: 2 metrics: display_formula: cdm_workers: 2 table: teds_workers: 2

만약:

메모리 8 GB

workers = 20

이라면 분명 합리적인 설정이 아니다.

특히 CDM은 현재 대략적으로 높은 단일 Worker 메모리를 필요로 하므로, 단순히 CPU 코어 수에 따라 동시성을 무한정 늘릴 수 없다.

54. 주목할 만한 엔지니어링 문제

CDM은 비교적 무거운 계산 모듈에 속한다.

실제 배포에서 만약 다음이 나타난다면:

CDM = 0 CDM = NaN

곧바로 다음과 같이 생각해서는 안 된다:

모델 수식 인식이 완전히 틀렸다.

우선 다음과 같은 기반 시설 문제를 점검해야 한다:

CDM Runtime Worker Memory Rendering Ghostscript ImageMagick TeX Live

특히 다음 환경에서:

CI Docker 저메모리 서버 공유 서버

이런 문제는 더 주목할 가치가 있다.

55. Prediction 디렉터리 설계

End-to-End Evaluation의 경우 권장한다:

파일 이름은 페이지 이미지와 일대일로 대응해야 한다:

page_0001.jpg ↓ page_0001.md

다음과 같이 해서는 안 된다:

prediction/ ├── result1.json ├── result2.json └── random_output.txt

하지만 여기서 다시 한번 강조할 필요가 있다:

이 Markdown Prediction 디렉터리는 공식 End-to-End Evaluation의 입력 형식이며, OmniDocBench의 모든 작업이 반드시 Markdown을 사용해야 한다는 것을 의미하지는 않는다.

예를 들어 단일 모듈의:

Text Recognition Formula Recognition Table Recognition Layout Detection Formula Detection

은 공식 평가 코드에 구조화된 JSON Prediction 경로도 여전히 존재한다.

따라서 더 정확한 이해는 다음과 같다:

End - to - End ↓ Markdown Prediction Single Module ↓ 작업에 따라 대응하는 JSON / Prediction Schema 사용

56. Benchmark Runner

여러 모델을 장기적으로 평가할 계획이라면, 매번 수동으로 다음을 할 것을 권장하지 않는다:

python inference.py python pdf_validation.py

대신 자신만의 Benchmark Runner(벤치마크 테스트 실행기)를 작성하는 것이 좋다.

class BenchmarkRunner : def run_model ( self , model ): predictions = model.infer() self .save_predictions(predictions) def evaluate ( self ): return run_omnidocbench() def report ( self , result ): ...

BenchmarkRunner │ ├── Prepare Dataset │ ├── Run Model │ ├── Save Prediction │ ├── Run Evaluation │ ├── Aggregate Metrics │ └── Generate Report

End-to-End 모델의 경우:

Run Model ↓ Markdown Prediction ↓ OmniDocBench end2end

단일 모듈 작업의 경우:

Run Model ↓ Task -specific Prediction ↓ 대응하는 Evaluation

이렇게 하면 전체 엔지니어링이 더 명확해진다.

57. 권장 엔지니어링 디렉터리

정말로 장기적으로 유지보수하는 프로젝트라면, 나는 다음을 권장한다:

document-benchmark/ │ ├── configs/ │ ├── models.yaml │ ├── benchmark.yaml │ └── prompts.yaml │ ├── providers/ │ ├── base .py │ ├── local.py │ ├── vllm.py │ └── cloud.py │ ├── adapters/ │ ├── paddleocr.py │ ├── mineru.py │ ├── qwen_vl.py │ └── custom_model.py │ ├── inference/ │ └── runner.py │ ├── cache/ │ ├── predictions/ │ ├── evaluation/ │ └── omnidocbench.py │ ├── reports/ │ └── main.py

이것은 더 이상:

하나의 테스트 스크립트가 아니라

진정한:

Document AI Quality Platform(문서 인공지능 품질 플랫폼)

58. API 모델은 Failure Analysis를 추가할 것을 권장한다

폐쇄형 모델의 경우, 나는 다음만 저장할 것을 권하지 않는다:

prediction.md

또한 다음도 저장해야 한다:

{ "model" : "xxx" , "version" : "xxx" , "latency" : 2.31 , "status" : "success" , "retry_count" : 0 , "input_tokens" : 1234 , "output_tokens" : 2345 }

만약 실패한다면:

{ "status" : "failed" , "error_type" : "rate_limit" }

오류 유형은 최소한 다음을 구분할 것을 권한다:

network_error timeout rate_limit authentication_error server_error model_failure invalid_output infrastructure_failure

이것이 바로 Failure Analysis(실패 분석)이다.

그 가치는 다음과 같다:

"모델 품질이 나쁘다"와 "모델 서비스가 실패했다"를 구분하는 것.

Overall = 72

가 반드시 모델 자체가 72점밖에 받을 수 없다는 것을 의미하지는 않는다.

만약 그중:

10% pages = timeout

이라면, 실제 모델 품질은 완전히 다를 수 있다.

59. Latency도 기록해야 한다

Production(프로덕션) 모델의 경우:

Quality

는 하나의 차원에 불과하다.

또한 다음을 기록해야 한다:

Latency Cost Throughput Error Rate

Model Score Latency Cost/Page Error Rate A 91 2.1s $0.01 0.2% B 89 0.4s $0.002 0.1% C 94 8.3s $0.04 1.3%

Score

가 가장 높은 C가 반드시 최종 선택은 아닐 수 있다.

프로덕션 환경이 진정으로 중요하게 여기는 것은:

Quality + Cost + Latency + Reliability

이기 때문이다.

60. Production Benchmark

만약 당신의 목표가 연구 논문이 아니라 프로덕션 환경이라면, 다음과 같이 권한다:

Benchmark Score + Production Metrics

를 함께 보는 것.

최종적으로 다음을 얻을 수 있다:

Quality ├── Text ├── Table ├── Formula └── Layout Performance ├── Latency ├── Throughput └── GPU Memory Reliability ├── Error Rate ├── Timeout └── Retry Cost ├── Cost/Page └── Cost/ 1 M Pages

이것이야말로 기업이 진정으로 필요로 하는 모델 선정 근거다.

61. CI/CD에서 Benchmark 자동 실행

만약 팀이 OCR 모델을 개발하고 있다면, Benchmark를 CI/CD(지속적 통합 / 지속적 전달)에 넣을 수 있다.

Git Push ↓ Train Model ↓ Build Docker Image ↓ Inference ↓ OmniDocBench ↓ Quality Gate

Quality Gate(품질 게이트)는 다음과 같이 설정할 수 있다:

Text Score >= 0.95 Table TEDS >= 0.85 Formula CDM >= 0.90 Overall >= 0.90

Overall = 0.87

CI FAILED

이렇게 하면 모델 품질이:

수동 관찰

에서:

자동화된 엔지니어링 제약

으로 바뀐다.

62. Quality Regression

더 중요한 것은 Quality Regression(품질 회귀)이다.

v1.0 Text 95 Table 87 Formula 91

다음으로 업그레이드:

v1.1 Text 96 Table 81 Formula 93

Overall은 여전히 상승할 수 있다.

Table

은 뚜렷하게 하락했다.

Overall만 본다면:

문제없음

Regression을 본다면:

표 능력의 퇴화를 발견

이것이 Benchmark의 진정한 엔지니어링 가치다.

63. A/B Test

A/B Test(대조 실험) 역시 OmniDocBench 위에 바로 구축할 수 있다.

Model A vs Model B

다음을 고정하고:

Dataset Prompt Image Temperature Inference Parameters

다음만 바꾼다:

ΔText Δ Table ΔFormula ΔOverall

최종적으로 답한다:

새 모델이 정말로 실제 향상을 이루었는가?

만약 나아가 페이지 수준 결과를 결합하면, 다음과 같이 답할 수도 있다:

향상은 어느 페이지에서 발생했는가? 하락은 어느 페이지에서 발생했는가?

64. Benchmark를 최종 진리로 여기지 말 것

이것은 전체 글에서 가장 중요한 엔지니어링 결론 중 하나다.

Benchmark는:

Truth

가 아니라

Measurement

측정 도구다.

OmniDocBench = 90

이라고 해서 다음을 의미하지 않는다:

Production Quality = 90

당신의 실제 업무는 아마 다음과 같기 때문이다:

계약서 인보이스 병력 기록 재무 보고서 스캔본 중국어 필기체

그리고 Benchmark의 데이터 분포가 반드시 완전히 일치하지는 않는다.

Benchmark는 모델 능력의 참조 좌표이지, 업무 품질의 최종 답이 아니다.

65. 기업은 자신만의 Business Dataset을 구축해야 한다

따라서 실제 프로젝트에서는 다음을 권한다:

OmniDocBench + Business Dataset

OmniDocBench │ ├── Academic ├── Financial ├── Newspaper ├── Textbook └── Handwritten Business Dataset │ ├── Invoice ├── Contract ├── Receipt ├── Bank Statement └── Internal Report

Research Benchmark + Production Benchmark

가 함께 모델 선정을 결정한다.

이렇게 하면 다음 문제를 피할 수 있다:

공개 Benchmark는 매우 높은데

실제 업무 효과는 매우 나쁜

문제.

66. 하나의 완전한 기업급 평가 아키텍처

최종적으로 다음을 구축할 수 있다:

Document AI │ ┌────────┴────────┐ │ │ Open Source Closed Source │ │ ▼ ▼ Adapter Provider │ │ └────────┬────────┘ ▼ Benchmark Runner │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ Inference Cache Metadata │ │ │ └──────────────┼──────────────┘ ▼ Prediction │ ▼ OmniDocBench │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ Text Table Formula │ │ │ └──────────────┼──────────────┘ ▼ Quality Matrix │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ Dashboard CI / CD Model Selection

End-to-End

는 더 나아가 다음과 같이 전개할 수 있다:

Prediction │ ├── end2end │ ├── JSON Ground Truth │ └── Markdown Prediction │ └── md2md ├── Markdown Ground Truth └── Markdown Prediction

이것이야말로 완전한 Document AI Evaluation Pipeline(문서 인공지능 평가 파이프라인)이다.

67. 자주 묻는 질문

Q1: OmniDocBench는 OCR Benchmark인가?

완전히 그렇지는 않다.

더 정확하게 말하면, 그것은:

Document Parsing을 겨냥한 종합 Benchmark다.

OCR은 그중 하나의 모듈에 불과하다.

Q2: 왜 내 OCR은 매우 정확한데 Overall 점수는 높지 않은가?

아마도:

Table Formula Layout Reading Order

에 문제가 생겼기 때문이다.

다음을 확인할 것을 권한다:

Attribute-Level Result Per Page Result Per Element Result

Overall만 보지 말고.

Q3: 왜 모델은 Markdown을 출력하는가?

OmniDocBench의 End-to-End Evaluation의 경우, 모델은 전체 페이지 PDF 파싱 결과를 제공해야 하며, 공식은 Markdown을 Prediction의 표준 입력 형식으로 삼는다.

하지만 특히 주의해야 한다:

모델 Prediction = Markdown

이 다음을 의미하지는 않는다:

Ground Truth = Markdown

공식은 두 가지 방식을 제공한다:

end2end JSON Ground Truth + Markdown Prediction

md2md Markdown Ground Truth + Markdown Prediction

그중 공식이 권장하는 것은:

왜냐하면 JSON Ground Truth는 더 풍부한 category, attribute, ignore 등의 정보를 보존하여 더 세밀한 평가를 할 수 있기 때문이다.

Q4: 왜 Markdown 문자열을 직접 비교하지 않는가?

Markdown Segmentation

에는 구조상의 차이가 대량으로 존재한다.

Title

은 유사한 제목 구조를 표현한다.

혹은:

단지 단락을 나누는 방식이 다를 뿐이다.

Normalization + Matching + Metric

이며, 단순한:

pred == gt

가 아니다.

이것이 바로 OmniDocBench에서 Matching이 매우 중요한 모듈인 이유다.

Q5: end2end와 md2md의 차이는 무엇인가?

한마디로:

category attribute ignore

등의 구조화 정보.

이미 Markdown-to-Markdown 평가 요구가 존재하는 시나리오에 더 적합하다.

Q6: OmniDocBench의 모든 작업이 반드시 Markdown을 출력해야 하는가?

아니다.

이것은 매우 중요한 구분이다.

다음의 경우:

End-to-End Evaluation

모델의 전체 페이지 Prediction은 Markdown을 사용한다.

하지만 다음의 경우:

공식 평가 코드는 구조화된 JSON Prediction 방식도 제공한다.

따라서 단순히 다음과 같이 이해할 수는 없다:

OmniDocBench = 모든 모델이 Markdown을 출력

더 정확하게는:

End-to-End ↓ Markdown 예측 단일 모듈 ↓ Task-specific 예측

공식의 현재 스킬 설명도 End-to-End의 Markdown 입력과 단일 모듈 Recognition / Detection의 JSON 입력을 명확히 구분하고 있다.

Q7: 폐쇄형 모델도 공정하게 비교할 수 있는가?

가능하다. 다만 반드시 다음을 고정해야 한다:

Input Prompt Resolution Temperature Model Version Dataset

그리고 다음을 기록해야 한다:

Cost Latency Error Retry

그렇지 않으면 진정한 재현성을 확보하기 어렵다.

68. 마지막으로: 진짜 배울 가치가 있는 것은 pdf_validation.py가 아니다

단지 Benchmark를 한 번 빠르게 돌려보고 싶을 뿐이라면, 그것만으로도:

충분하다.

하지만 당신이 전문 Python 개발 엔지니어라면, 나는 OmniDocBench를 하나의 사례로 연구해볼 것을 더 권한다:

Benchmark는 어떻게 설계하는가? Dataset은 어떻게 설계하는가? Matching은 어떻게 설계하는가? Metric은 어떻게 설계하는가? 다중 모델은 어떻게 처리하는가? Local / API Model은 어떻게 통일하는가? Cache는 어떻게 처리하는가? Retry는 어떻게 처리하는가? Reproducibility는 어떻게 보장하는가? Regression Test는 어떻게 하는가? Quality Gate는 어떻게 하는가?

이것이 바로 OmniDocBench가 진정으로 배울 가치가 있는 지점이다.

69. 정리

OmniDocBench 전체는 한 문장으로 압축할 수 있다:

그것은 OCR이 "인식을 제대로 했는가"를 단순히 판정하는 것이 아니라, 더 복잡한 질문에 답하려고 시도한다: 하나의 Document AI 모델이 현실 세계의 복잡한 PDF를 안정적이고 정확하게 구조화된 문서로 복원할 수 있는가?

엔지니어링 관점에서 전체 체계는 이렇게 기억할 수 있다:

PDF │ ▼ Document AI │ ▼ Prediction │ ▼ Matching │ ┌─────────┼─────────┐ ▼ ▼ ▼ Text Table Formula │ │ │ ▼ ▼ ▼ EditDist TEDS CDM │ │ │ └─────────┼─────────┘ ▼ Evaluation │ ▼ Quality Matrix │ ▼ Model Selection

그리고 End-to-End 자체는 다시 다음과 같이 더 분해할 수 있다:

End - to - End │ ┌────────┴────────┐ ▼ ▼ end2end md2md │ │ ▼ ▼ JSON Ground Truth Markdown Ground Truth │ │ └────────┬────────┘ │ ▼ Markdown Prediction │ ▼ Matching │ ▼ Metric

공식은 end2end를 더 권장하는데, 그것은 두 개의 Markdown 파일을 단순히 비교하는 것이 아니라, OmniDocBench JSON에 있는 풍부한 category, attribute, ignore 등의 정보를 활용해 더 완전한 엔드투엔드 평가를 수행하기 때문이다.

그리고 실제 프로젝트에서는 한 걸음 더 나아간다:

OmniDocBench + Business Dataset + Production Metrics + Regression Test + CI/CD

최종적으로 완전한 다음을 형성한다:

Document AI Evaluation Pipeline(문서 인공지능 평가 파이프라인)

이것을 실제로 착지시킨다면, 당신은 더 이상 "OCR Benchmark 하나를 돌리는" 것이 아니라, 다음 질문들에 지속적으로 답할 수 있는 엔지니어링 시스템을 구축하는 것이다:

어느 모델이 가장 좋은가? 왜 가장 좋은가? 어떤 문서에서 가장 좋은가? 어느 모듈이 퇴화했는가? 새 버전에 회귀가 있는가? API 모델은 그 비용에 걸맞은 가치가 있는가? 로컬 모델은 배포할 가치가 있는가? 모델 업그레이드 후 품질이 향상되었는가?

이것이 또한 OmniDocBench가 전문 개발 엔지니어에게 가장 가치 있는 지점이다.

공식 자료

OmniDocBench 공식 저장소:

GitHub - opendatalab/OmniDocBench

논문:

OmniDocBench: Benchmarking Diverse PDF Document Parsing with Comprehensive Annotations

공식 저장소의 현재 README에는 이미 Docker, Conda, End-to-End, end2end / md2md, 각종 Metric, 모델 추론 스크립트 및 OpenAI-compatible endpoint 등의 사용 설명이 포함되어 있다.

ALLINAI

Python开发

132

文章

115k

阅读

205

粉丝