문서 파싱 벤치마크 두 개 — 하나는 1위, 하나는 중위권, 그리고 그 차이의 원인

PDF와 이미지를 마크다운으로 바꾸는 파이프라인을 공개 벤치마크 두 개로 평가했습니다. DP-Bench는 문서를 요소 단위 JSON으로 뽑아 표 구조와 텍스트 시퀀싱을 채점하고, OmniDocBench은 페이지 이미지를 마크다운으로 바꿔 편집 거리와 표 정확도와 읽기 순서를 채점합니다.

두 벤치마크의 결과는 갈렸습니다. 그 사실 자체가 이 기록의 내용입니다.

평가 대상은 프로덕션 경로다

벤치마크용으로 따로 만든 파이프라인이 아닙니다. 제품의 OCR 로직을 파이썬으로 충실히 복제해 투입했고, 모델과 프롬프트와 후처리가 전부 같습니다. 유일한 차이는 인증입니다. 프로덕션은 세션 토큰으로 프록시를 거치지만 벤치에서는 API에 직접 호출합니다. 변환 로직 자체는 동일합니다.

이 구성이 중요한 이유는, 벤치마크 전용 경로로 잰 숫자는 사용자가 실제로 받는 품질에 대해 아무것도 보장하지 않기 때문입니다.

DP-Bench — 표 구조 1위

문서 200개, 공식 리더보드와 같은 지표입니다.

파서	TEDS	TEDS-S	NID
이 파이프라인	94.63	98.11	92.21
Upstage (enhanced)	95.59	97.62	96.62
Upstage (standard)	96.06	97.25	96.29
AWS	95.48	96.99	95.97
LlamaParse	90.73	93.20	90.53
Microsoft	77.85	85.74	87.03
Google	78.30	80.71	82.17

표 구조를 재는 TEDS-S에서 98.11로 1위입니다. 문서 파싱 전용으로 파인튜닝한 상용 파서들을 상회했는데, 이쪽은 범용 VLM에 프롬프트만 얹은 구성입니다.

셀 내용까지 포함하는 TEDS와 텍스트 시퀀싱을 재는 NID에서는 상위권이지만 1위가 아닙니다. 셀 배치는 맞는데 셀 안의 텍스트를 틀리는 경우가 남아 있다는 뜻이고, 이 구분은 아래 OmniDocBench 결과에서 다시 나타납니다.

문서당 평균 6.5초, 200개 변환 총 $2.39입니다.

OmniDocBench — 중위권, 그리고 왜 졌는가

페이지 1,651장, end-to-end 마크다운 채점입니다.

지표	이 파이프라인	리더보드 최상위
Text-Edit (낮을수록 좋음)	0.094	0.036
Table-TEDS	79.23	93.42
Table-TEDS-S	85.50	95.92
Read-Order-Edit (낮을수록 좋음)	0.183	0.116

졌습니다. 상위권은 전부 문서 파싱 전용으로 파인튜닝된 소형 VLM입니다. 지는 이유를 언어와 문서 유형으로 분해하면 어디서 지는지가 분명해집니다.

구분	Text-Edit (낮을수록 좋음)
영어	0.060
학술 문헌	0.043
시험지	0.172
중국어 간체	0.113
영중 혼합	0.203
손글씨	0.365

영어와 정형 문서에서는 상위권 수준이고, 중국어와 혼합 문서와 손글씨에서 무너집니다. 범용 VLM이 밀집 CJK와 필기 OCR에서 전용 모델에 밀리는 것이며, 프롬프트로 메울 수 있는 종류의 격차가 아닙니다.

따라서 이 벤치마크의 정상은 문서 전용 모델을 요구합니다. 제품의 목표는 범용 소스 추출과 지식그래프 구축이라 범용 VLM이 합리적 선택이고, 이 결과는 그 선택의 대가를 숫자로 적어둔 것입니다.

낮은 점수 하나를 끝까지 파고든 것

DP-Bench의 Table-F1이 0.5654로 낮았습니다. 정답 표 55개에 대해 예측 표가 136개였고, 정답 표가 0개인 문서 49개에서 표를 예측했습니다. 표를 남발하는 결함으로 읽히는 숫자입니다.

이 49개를 전부 원본 마크다운과 정답 카테고리에 대조했습니다.

원인	문서 수
차트를 데이터 표로 변환 (정답 라벨은 Chart)	44
목차를 표로 렌더링 (정답 라벨은 Index)	2
그림 캡션을 1행 표로 감쌈	2
콜아웃 레이아웃을 HTML 표로 표현	1

44건은 의도한 동작입니다. 프롬프트가 명시적으로 차트를 데이터 표로 바꾸라고 지시합니다. 지식그래프 추출이 목적이므로 차트에 실린 숫자를 그림으로 흘려보내지 않고 구조화하는 것이 옳고, 그것이 벤치마크의 Chart/Table 분류 체계와 충돌해 점수로 나타난 것입니다.

어댑터가 표를 날조한 것도 아닙니다. 원본 마크다운의 파이프 표 개수와 어댑터 산출 표 개수가 정확히 일치합니다. 모델 환각도 아닙니다.

실제로 고칠 값어치가 있는 것은 3건뿐이고 영향은 미미합니다. 프로덕션 동작은 유지하는 것이 맞습니다.

이 규명이 없었다면 선택지는 두 가지였습니다. 점수를 위해 차트 구조화를 끄거나, 낮은 점수를 결함으로 오해한 채 두거나. 둘 다 틀린 답이고, 어느 쪽인지는 문서 49개를 열어봐야만 알 수 있었습니다.

한계

절대값 비교는 근사치입니다. OmniDocBench 리더보드는 v1.6_full 기준이고, 채점에 쓴 정답은 1,651페이지 스냅샷입니다. 스코어러와 지표 정의는 같지만 정답 구성이 완전히 같지는 않습니다.
종합 점수는 산출하지 않았습니다. 종합에는 수식 지표가 필요한데 채점 시간을 줄이려고 비활성화했습니다.
읽기 순서는 레이아웃 검출 없이 모델 출력 순서에 의존합니다. 다단 문서용 후처리로 일부 개선할 수 있지만 상한은 모델에 달려 있습니다.

측정 기록

항목	값
실행 시점	2026년 7월
모델	`gemini-3.5-flash`, OpenRouter 경유 — 프로덕션과 동일
프롬프트	제품의 `ingest.rs`에 있는 OCR 프롬프트 원문 (병합셀을 HTML 표로, 차트를 데이터 표로, 수식을 LaTeX로)
후처리	제품의 `tidy_markdown`을 그대로 복제
DP-Bench	문서 200개, 지표 NID / TEDS / TEDS-S, 문서당 6.5초, 총 $2.39
OmniDocBench	페이지 1,651장, 지표 Text-Edit / Table-TEDS / Read-Order-Edit
채점 환경	Python 3.11 가상환경 3개 분리 (러너 / OmniDocBench 채점 / DP-Bench 채점)

복제 모듈은 harness/ocr_common.py, 배치 러너는 harness/run_omni.py와 harness/run_dp.py이며, 데이터셋은 HuggingFace 스냅샷으로 harness/download_data.py가 받습니다. 측정 기록 원본과 설정 파일은 Consilience 저장소의 docs/pdf-parse-eval/ 아래에 있습니다.