docTR vs Docling 영수증 벤치마크
단일 패스 속도 vs 문서 파이프라인 (2026)
마지막 검토: 2026-08-18 · 실행 등급: 공식 · 1차 대등 벤치마크 · 2개 엔진 × 2개 영수증 데이터셋
이 페이지에서 다루지 않는 범위: 영수증 이외의 모든 문서 유형 — 표, 양식, 송장, 계약서 또는 긴 문서는 포함되지 않습니다. Docling이 마케팅하는 강점은 여기서 범위 밖이며, 부정된 것이 아닙니다 — 이 벤치마크는 이를 측정하도록 설계되지 않았습니다. 클라우드/API OCR 서비스, 다른 오픈소스 엔진, 미세 조정된 모델, 그리고 Docling의 네이티브 구조화된 출력은 범위 밖입니다. 전체 8개 엔진 비교는 전통 OCR vs 문서 파싱 VLMs에서 확인할 수 있습니다.
범위 설명: 이 페이지의 모든 수치는 영수증에만 적용됩니다 — SROIE 2019 영어 영수증과 CORD v2 인도네시아어 영수증. 하드웨어 등급 1개, LLM 후처리기 1개(deepseek-v4-flash, temperature 0), 고정 모델 버전(docTR v1.0.1, Docling 2.119.0). 이 결과를 송장, 표 또는 복잡한 레이아웃에 외삽하지 마세요 — 벤치마크는 영수증 OCR와 영수증 필드 추출만 측정하며, Docling의 구조화된 문서에 대한 파이프라인 기능은 정확히 측정하지 않는 것입니다. 모든 수치는 벤치마크의 results/summary_metrics.csv와 results/field_method_comparison.csv에서 제공되며, 공개 GitHub 저장소에 미러링되고 행별로 인용됩니다.
간단한 영수증에 대한 아키텍처 비용: Docling의 단계별 파이프라인 — 레이아웃 박스, 테이블 감지, 읽기 순서 재구성 — 은 단일 페이지 영어 영수증에서 거의 이점을 제공하지 않으며, 측정 결과가 이를 보여줍니다. 동일한 361개의 SROIE 영수증, 동일한 RTX 4090, 동일한 프로토콜에서 Docling의 원시 CER은 docTR보다 3.0배 나쁩니다 (0.5909 vs 0.1971), p50에서 6.7배 느립니다 (732.0 ms vs 108.7 ms), 1,000페이지당 비용은 8.3배 더 높습니다 ($0.3978 vs $0.0479). 이 비교를 공정하게 만드는 반전: 원시 텍스트 품질이 훨씬 나쁨에도 불구하고, Docling의 SROIE 정규식 필드 F1 (0.2237)은 docTR (0.0766)보다 2.9배 높습니다 — 그런 다음 LLM 후처리기가 순위를 다시 docTR (0.6171 vs 0.5685)으로 뒤집습니다.
한 쌍의 숫자로 보는 트레이드오프: docTR은 영수증 페이지를 p50에서 108.7 ms에 1,000페이지당 $0.048로 읽고; Docling은 p50에서 732.0 ms에 1,000페이지당 $0.398로 읽습니다 — 동일한 영수증, 동일한 테스트 분할, 동일한 GPU. 어느 엔진도 "승리"하지 않습니다; 이 페이지는 파이프라인 오버헤드가 일반 영수증에서 그 비용을 정당화하는지를 측정합니다. 여기서는 그렇지 않습니다 — 그리고 Docling의 오버헤드가 제공하는 것은 이 벤치마크에서 의도적으로 측정되지 않았으며, 그것에 의해 반증되지도 않았습니다.
Docling이란: 단일 패스 OCR vs 파싱 파이프라인
두 엔진은 근본적인 아키텍처적 분기의 양쪽에 위치하며, 그 분기 — 코드 차이나 튜닝 차이가 아닌 — 가 이 페이지의 전부입니다. docTR은 단일 패스 신경망 OCR 엔진입니다: 감지 단계가 텍스트 바운딩 박스를 위치시키고 인식 단계가 그 안의 문자를 전사하여, 하나의 OCR 예측기로 구성되어 순방향 패스를 통해 원시 텍스트 라인을 생성합니다. 레이아웃 모델, 테이블 파서, 읽기 순서 재구성은 없습니다 — 인식기가 읽는 순서대로 출력됩니다. Docling은 OCR 엔진도 아니고 비전-언어 모델도 아닙니다; 문서 파싱 파이프라인입니다. 자체 기술 보고서에 따르면, 페이지별로 일련의 모델 — 레이아웃 분석, 테이블 감지, 읽기 순서 추론 — 을 단계적으로 구성하고, 이를 집계하여 텍스트를 내보내기 전에 중간 문서 객체를 조립합니다. 이것이 바로 docTR의 라인에는 없는 구조를 출력에 담을 수 있는 이유입니다.
이 메커니즘이 벤치마크에 중요한 이유: Docling의 체인에 있는 모든 단계별 모델은 레이아웃 구조를 활용하기 위해 존재합니다 — 파싱할 테이블, 2열 양식, 어휘 순서가 아닌 읽기 경로. 일반 영어 영수증에는 거의 그런 것이 없습니다: 단일 열, 몇 개의 영역, 대부분 예측 가능한 상하 경로, 테이블 없음. 단계별 기계 장치는 여전히 모든 페이지에서 실행됩니다 — 이것이 더 느리고 비용이 더 드는 이유입니다 — 하지만 활용할 구조가 없으면, 오버헤드가 더 나은 텍스트로 전환될 수 없습니다. 이 페이지는 바로 그 비용을 격리하고 그것이 무엇을 — 그리고 무엇을 하지 못하는지 — 제공하는지 보여줍니다.
문자 정확도: 원본 텍스트에 대한 파이프라인 비용
SROIE 2019에서 원본 텍스트 격차는 크습니다: CER 0.1971 (docTR) 대비 0.5909 (Docling) — 3.0×의 불이익 — 및 WER 0.3199 대비 0.7596입니다. 문자 오류율(CER)은 삽입, 삭제, 대체를 정답 문자 수로 나눈 값으로, CER 0.197은 100자당 약 19.7자의 오독을 의미합니다. 단어 오류율(WER)은 동일한 편집 거리 논리를 단어 단위로 적용합니다. Docling의 0.5909는 기본 실행에서 8개 엔진 중
출처: summary_metrics.csv — cer 및 wer 열, sroie_2019 행. docTR cer 0.19707 / wer 0.31990; Docling cer 0.59092 / wer 0.75961. 낮을수록 좋습니다. 엔진당 361개 샘플; error_rate 모두 0.0.
| 지표 (SROIE 2019, n=361) | docTR | Docling | 출처 |
|---|---|---|---|
| 문자 오류율 (CER) | 0.1971 | 0.5909 | summary_metrics.csv · cer, doctr/sroie_2019 및 docling/sroie_2019 행 |
| 단어 오류율 (WER) | 0.3199 | 0.7596 | summary_metrics.csv · wer, 동일 행 |
| 오류율 | 0.0 | 0.0 | summary_metrics.csv · error_rate, 동일 행 |
표: summary_metrics.csv — cer / wer / error_rate 열, sroie_2019 행. 정확한 값: docTR cer 0.19707 / wer 0.31990; Docling cer 0.59092 / wer 0.75961. Docling의 SROIE CER는 기본 실행에서 8개 엔진 중 두 번째로 낮은 수준입니다 — 원본 문자 정확도는 파이프라인 비용이 가장 먼저 드러나는 부분입니다.
반전: 정규식 필드 추출이 결과를 뒤집다
네 가지 SROIE 영수증 필드에 대해 동일한 고정 정규식 패턴으로 두 엔진의 텍스트를 벤치마크하면 — 전통적인 OCR + 규칙 기반 핵심 정보 추출(KIE) 접근 방식 — 순위가 뒤집힙니다. Docling은 0.2237 필드 F1을 기록하며 docTR의 0.0766을 크게 앞서 2.9배의 이점을 보입니다. 이는 벤치마크의 postprocessed_sroie_receipt_regex_* 지표입니다: 각 엔진의 OCR 텍스트에 고정 패턴을 적용한 결과 — 후처리된 것이며, 어느 엔진의 네이티브 구조화된 출력이 아니며, Docling의 네이티브 문서 모델은 여기서 평가되지 않습니다.
필드 값 F1은 추출된 필드 값을 기준 데이터와 비교한 정밀도와 재현율의 조화 평균입니다 — 1.0은 모든 영수증 필드가 완벽하게 복원됨을 의미하고, 0은 아무것도 복원되지 않았음을 의미합니다. 이 반전의 메커니즘은 CER 격차를 초래한 것과 동일한 아키텍처 차이가 반대 방향으로 작용하는 것입니다: Docling의 문서 모델은 텍스트를 읽기 경로로 재배열하고 레이블을 값과 연결하므로, 출력 텍스트가 고정 패턴이 기대하는 형태에 더 가깝습니다. 반면 docTR의 깨끗하지만 원시적인 줄 텍스트 — CER 기준으로는 정확하지만 원래 대소문자와 구분자 노이즈가 있으며 레이블 프레이밍이 없어 — 패턴을 무력화합니다. docTR의 정규식 필드 F1 0.0766는 최고 수준의 CER에도 불구하고 기본 실행에서 8개 엔진 중 최악의 성적를 보입니다. Docling의 0.2237는 6위를 차지합니다. 정확도 사다리 상단의 형제 간 직접 비교(docTR vs Surya2)에서 문서화된 것과 같은 분리 현상이 여기 하단에서 다시 나타납니다: 텍스트 정확도는 필드 정확도가 아닙니다.
출처: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1 열, sroie_2019 행. LLM 후처리기: deepseek-v4-flash. 엔진당 361개 샘플 (llm_ok_count).
| Regex 후처리 (SROIE 2019, n=361) | docTR | Docling | 출처 |
|---|---|---|---|
| 필드-값 F1 (regex) | 0.0766 | 0.2237 | field_method_comparison.csv · regex_field_value_f1, doctr/sroie_2019 및 docling/sroie_2019 행 |
| 필드-값 정확도 (regex) | 0.0623 | 0.2043 | field_method_comparison.csv · regex_field_value_accuracy, 동일 행 |
| 문서-필드 정확 일치 (regex) | 0.0000 | 0.0000 | field_method_comparison.csv · regex_document_fields_exact, 동일 행 |
표: field_method_comparison.csv — regex 열, sroie_2019 행. 이는 postprocessed_sroie_receipt_regex_* 지표로, 각 엔진의 OCR 텍스트에 고정 패턴을 적용한 것이며, 네이티브 구조화 추출이 아닙니다. 어떤 엔진도 단일 SROIE 영수증에서 regex로 네 개의 필드를 모두 정확히 맞추지 못했습니다. docTR의 regex 필드 F1 0.0766은 기본 실행의 8개 엔진 중 가장 낮은 값입니다.
LLM 후처리가 순위를 복원합니다 — 부분적으로
두 엔진의 텍스트를 구조화된 추출 프롬프트와 함께 LLM 후처리기(deepseek-v4-flash, temperature 0)에 입력하면, docTR이 선두를 탈환합니다: 필드 F1 0.6171 대 0.5685 — 0.049점 차이. 이는 원시 CER 차이에 비해 작지만 사라지지는 않습니다. 더 깨끗한 기본 텍스트는 복구 가능한 필드 값을 더 많이 드러내며, LLM은 Docling의 레이아웃 아티팩트를 부분적으로 보상하지만 완전히 제거하지는 않습니다.
이것은 전체 8엔진 벤치마크에서 나타나는 동일한 수렴 대역입니다 — LLM 후처리는 의미를 이해하기 때문에 건강한 엔진들을 끌어당깁니다 — 그리고 잔여 차이는 중요합니다: docTR의 0.6171은 8개 엔진 중 최고 LLM 필드 F1인 반면, Docling의 0.5685는 6위를 차지합니다. 더 엄격한 기준 — 네 개의 필드가 모두 정확히 일치하는 문서 —는 2.7× 차이를 보입니다: docTR 0.1496 대 Docling 0.0554. 이 레버에는 두 가지 비용이 따릅니다: LLM 호출은 OCR 시간 외에 문서당 중간 지연 시간을 ~2.0–2.4초 추가합니다, 그리고 엔진이 근본적으로 읽지 못한 텍스트는 구제할 수 없습니다.
| LLM 후처리 (SROIE 2019, n=361) | docTR | Docling | 출처 |
|---|---|---|---|
| 필드-값 F1 (LLM) | 0.6171 | 0.5685 | field_method_comparison.csv · llm_field_value_f1, doctr/sroie_2019 및 docling/sroie_2019 행 |
| 필드-값 정확도 (LLM) | 0.6170 | 0.5665 | field_method_comparison.csv · llm_field_value_accuracy, 동일 행 |
| 문서-필드 정확 일치 (LLM) | 0.1496 | 0.0554 | field_method_comparison.csv · llm_document_fields_exact, 동일 행 |
| LLM 후처리 중간 지연 시간 (ms) | 1,996.3 | 2,365.1 | field_method_comparison.csv · llm_median_latency_ms, 동일 행 |
표: field_method_comparison.csv — llm_* 열, sroie_2019 행. LLM 모델: deepseek-v4-flash. LLM 지연 시간은 API로 인한 것이며 엔진 지연 시간(summary_metrics.csv latency_p50_ms)과 별개입니다. 두 행 모두 llm_ok_count 361로 완료되었습니다.
작동 범위: 6.7배 지연 시간, 7.9배 처리량, 8.3배 비용
파이프라인 비용은 처리량 계획이 수립되는 곳에서 가장 무겁습니다. 동일한 RTX 4090에서 동일한 기록된 $0.76/hr 요율로, docTR은 페이지당 108.7 ms p50의 지연 시간으로 449.3페이지/분을 유지하며 1,000페이지당 $0.048의 비용이 듭니다. Docling은 732.0 ms p50의 지연 시간으로 56.7페이지/분을 유지하며 1,000페이지당 $0.398의 비용이 듭니다 — 이는 6.7배의 지연 시간 격차, 7.9배의 처리량 격차, 그리고 8.3배의 비용 격차입니다. 파이프라인의 꼬리 구간은 비례적으로 더 나쁩니다: p95 지연 시간이 281.4 ms 대 3,239.8 ms로 11.5배 격차가 나는데, 이는 Docling의 단계별 모델들이 페이지마다 최악의 시간을 누적하기 때문입니다.
비용은 벽시계 실행 시간 × RunPod RTX 4090 요율을 기준으로 계산되며, 모델 초기화 비용이 포함되어 있습니다 — 이는 실제로 지불하게 될 GPU 시간 비용입니다. 처리량은 동일한 초기화 시간을 포함한 벽시계 기준 페이지/분입니다. 지연 시간 p50/p95는 모델 로딩을 제외한 웜-THEN-스코어 방식으로 측정된 정상 상태의 페이지별 추론 시간입니다. docTR은 SROIE 기반 실행의 8개 엔진 중 가장 빠르고 가장 저렴한 엔진입니다. Docling은 56.7페이지/분, 1,000페이지당 $0.398로, 작동 범위 표의 하위 절반에 위치합니다.
출처: summary_metrics.csv — latency_p50_ms / latency_p95_ms 열, sroie_2019 행. docTR p50 108.72 / p95 281.38; Docling p50 732.00 / p95 3239.79. 정상 상태 지연 시간.
출처: summary_metrics.csv — cost_per_1000_pages 열, sroie_2019 행. docTR 0.0479, Docling 0.3978. 비용 = 벽시계 실행 시간 × $0.76/hr. docTR은 기반 실행의 8개 엔진 중 가장 저렴한 엔진입니다.
| 작업 범위 (SROIE 2019, n=361) | docTR | Docling | 출처 |
|---|---|---|---|
| 지연 시간 p50 (ms) | 108.7 | 732.0 | summary_metrics.csv · latency_p50_ms, doctr/sroie_2019 및 docling/sroie_2019 행 |
| 지연 시간 p95 (ms) | 281.4 | 3,239.8 | summary_metrics.csv · latency_p95_ms, 동일 행 |
| 분당 처리 페이지 수 | 449.3 | 56.7 | summary_metrics.csv · pages_per_minute, 동일 행 |
| 1,000페이지당 비용 | $0.048 | $0.398 | summary_metrics.csv · cost_per_1000_pages, 동일 행 |
표: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute / cost_per_1000_pages, sroie_2019 행. 두 엔진 모두 GPU; 비용에는 모델 초기화 비용 포함. 정확한 값: docTR p50 108.72 / p95 281.38 / 449.31 pg/min / $0.0479; Docling p50 732.00 / p95 3239.79 / 56.66 pg/min / $0.3978.
CORD: 둘 다 붕괴, docTR의 LLM 필드 복구가 여전히 선두
두 엔진 모두 인도네시아 영수증을 주로 학습하지 않았으므로, CORD v2는 언어 간 스트레스 테스트 역할을 합니다 — 그리고 둘 다 원시 CER에서 붕괴합니다: 0.9101 (docTR) 및 0.9219 (Docling), 언어 불일치로 인한 동일한 결과입니다. 벤치마크 프로토콜에 따라, CORD 수치는 SROIE 비교에서 격리되어 유지됩니다 — 어떤 순위에도 절대 합쳐지지 않습니다 — 왜냐하면 CORD의 정답 텍스트에 주석 구조가 포함되어 있어, 실제 언어 불일치 위에 모든 엔진의 원시 CER을 부풀리기 때문입니다.
필드 지표에서 Docling의 유일한 보존된 이점은 거의 없어집니다: 정규식 패턴을 통해, 두 엔진 모두 거의 모든 CORD 필드를 복구하지 못합니다. LLM 후처리기가 양쪽 모두에서 언어 충격을 흡수하지만 docTR을 앞서게 유지합니다: 필드 F1 0.5500 vs 0.4695. CORD는 언어 견고성 맥락에서 여기에 인용되며, 의도적으로 SROIE 수치와 단일 리더보드로 합쳐지지 않습니다.
| CORD v2, 인도네시아 영수증 (n=100) | docTR | Docling | 출처 |
|---|---|---|---|
| 문자 오류율 (CER) | 0.9101 | 0.9219 | summary_metrics.csv · cer, doctr/cord_v2 및 docling/cord_v2 행 |
| 필드 값 F1 | 0.0000 | 0.0612 | field_method_comparison.csv · regex_field_value_f1, 동일 행 |
| 필드 값 F1 (LLM) | 0.5500 | 0.4695 | field_method_comparison.csv · llm_field_value_f1, 동일 행 |
| 1,000페이지당 비용 | $0.094 | $0.538 | summary_metrics.csv · cost_per_1000_pages, 동일 행 |
| 분당 페이지 수 | 500.4 | 123.2 | summary_metrics.csv · pages_per_minute, 동일 행 |
표: summary_metrics.csv (cer / cost_per_1000_pages / pages_per_minute) 및 field_method_comparison.csv (field F1), cord_v2 행. CORD 수치를 어떤 SROIE 순위에도 병합하지 마세요: CORD CER는 실제 언어 불일치와 지상 진실의 주석 구조적 팽창을 결합한 것이며, 정규식 패턴은 영어 형식용으로 작성되었습니다. docTR의 CORD 정규식 field F1 0.0000은 CSV에 기록된 실제 0이지, 결측값이 아닙니다.
언제 누가 이기는가: 요약 격자
“더 나은” 것은 작업량에 따라 다르며, 이 대결은 축을 명확히 나눕니다: 일반 영어 영수증에서는 모든 속도/비용 축과 원본 텍스트 축이 docTR에 유리하고; 기본 제공 정규식 필드 역전은 Docling에 유리하며; LLM 후처리기로 다시 0.049점 docTR 우위로 돌아오며; Docling이 존재하는 이유인 레이아웃, 테이블, 읽기 순서, 긴 문서 등의 기능은 여기서 측정되지 않았을 뿐, 반증된 것은 아닙니다.
자주 묻는 질문
Docling이 영수증 처리에서 docTR보다 더 정확한가요?
아니요 — 원시 문자 정확도 기준으로 docling은 3.0배 낮습니다: SROIE CER 0.5909 vs 0.1971, WER 0.7596 vs 0.3199. Docling은 측정된 축 중 하나에서만 "우위"를 점합니다: 기본 제공 정규식 필드 추출 — 그리고 LLM 후처리기로 그마저도 docTR 쪽으로 기울어집니다 (0.6171 vs 0.5685).
왜 Docling은 원시 텍스트 품질이 훨씬 나음에도 정규식으로 필드를 더 잘 추출하나요?
두 지표가 다른 것을 평가하기 때문이며, Docling의 출력 형식이 우연히 패턴에 맞기 때문입니다. Docling의 문서 파이프라인은 텍스트를 읽기 순서로 재배열하고 레이블을 값과 연결하므로, 출력 텍스트가 고정된 정규식 패턴이 기대하는 구조에 더 가깝습니다. docTR은 CER 기준으로 정확한 깨끗한 원시 줄 텍스트를 출력하지만, 패턴을 무력화합니다. 이 점수들은 postprocessed_sroie_receipt_regex_* 점수 — 고정된 패턴을 통과시킨 OCR 텍스트 —이며, 네이티브 구조화 출력이 아닙니다. 이 텍스트 정확도 ≠ 필드 정확도의 분리는 이 벤치마크 전반에 걸쳐 나타납니다.
왜 Docling은 페이지당 훨씬 느리고 비용이 많이 드나요?
페이지에 활용할 구조가 없는 단순 영수증일지라도, 모든 페이지에서 레이아웃 분석, 테이블 감지, 읽기 순서 재구성, 중간 문서 모델과 같은 단계별 문서 파이프라인을 실행하기 때문입니다. SROIE에서 이 비용은 p50 기준 6.7배 (108.7 vs 732.0 ms), p95 기준 11.5배, 처리량 7.9배 낮음, 1,000페이지당 비용 8.3배 높음 ($0.048 vs $0.398) — 동일한 GPU, 동일한 프로토콜.
LLM 후처리가 docTR과 Docling의 격차를 좁히나요?
대부분 좁히지만, 완전히는 아닙니다: LLM 후처리된 필드 F1은 SROIE에서 docTR이 0.6171, Docling이 0.5685로 나타납니다 — Docling의 레이아웃 아티팩트를 LLM이 부분적으로 보상해도 docTR이 0.049점 앞서는 격차가 유지됩니다. 수렴의 비용은 문서당 추가 중간 LLM 지연 시간 약 2.0~2.4초입니다.
이 벤치마크가 Docling이 나쁘다는 뜻인가요?
아니요 — Docling의 강점이 여기서 측정되지 않았다는 뜻입니다. Docling은 레이아웃 구조, 테이블, 읽기 순서, 양식, 긴 문서 등 문서 파이프라인으로서의 가치를 제공하지만, 영수증 전용 벤치마크로는 테스트할 수 없습니다. 이 페이지가 보여주는 것은 더 좁은 범위입니다: 단일 페이지 영수증에서는 파이프라인 오버헤드가 가치를 증명하지 못합니다, 측정된 유일한 이점도 LLM 후처리기에 의해 상쇄됩니다. 솔직한 평가는 범위에 대한 것이지, 결론이 아닙니다.
왜 두 엔진 모두 CORD 영수증에서 이렇게 낮은 점수를 받나요?
SROIE 순위와 별도로 유지되는 두 가지 복합적 원인이 있습니다: 진정한 언어 불일치와 CORD의 정답 텍스트 내 주석 구조 팽창입니다 — CER은 docTR 0.9101, Docling 0.9219로 나타납니다. LLM 후처리기 하에서 docTR의 필드 F1은 0.5500을 유지하고 Docling은 0.4695입니다 — SROIE 순서가 압축된 형태입니다. CORD 행은 인용되며 결합된 순위에 절대 포함되지 않습니다.
영수증 파이프라인은 docTR과 Docling 중 어떤 엔진을 선택해야 하나요?
과금 기반의 대량 영수증 텍스트의 경우, docTR의 성능은 결정적입니다: p50 108.7ms, 분당 449.3페이지, 1,000페이지당 $0.048 — 8개 엔진 비교에서 가장 빠르고 저렴한 엔진입니다. 파이프라인이 후처리 없이 바로 사용할 수 있는 구조화된 텍스트를 필요로 한다면, Docling의 정규식 필드 우위는 실질적인 초기 이점입니다. LLM 후처리가 설계에 포함되어 있다면, docTR이 0.049 포인트 앞서며 공급 비용도 더 저렴합니다. 작업 대상이 레이아웃이 많은 문서 — 표, 양식, 긴 보고서 — 라면, 이 벤치마크는 결정에 적합한 근거가 아닙니다. 영수증만 측정했기 때문입니다.
이 페이지의 수치는 어디서 가져온 것인가요?
모든 수치는 자체 벤치마크의 공개 CSV 파일의 행입니다 — results/summary_metrics.csv 및 results/field_method_comparison.csv — ImageToTableai/benchmark-ocr에 호스팅되며, 각 실행마다 환경 지문용으로 편집된 manifest.json이 하나 포함됩니다. 데이터셋 정의는 아래에 인용된 SROIE 2019 및 CORD 논문에서 가져왔습니다.
방법론 및 출처
프로토콜
이 페이지는 독립적이고 재현 가능한 벤치마크 실행의 대조 분석 결과를 보고합니다 — 제3자 주장에 대한 조사나 벤더 비교 페이지가 아닙니다. 고정된 테스트 분할만 사용합니다: SROIE 2019 테스트 및 CORD v2 테스트; 학습 분할은 평가하지 않았습니다. 두 엔진 모두 동일한 이미지, 동일한 정답, 동일한 측정 프로토콜을 사용했습니다. 두 실행 모두 오류율 0.0으로 두 데이터셋 모두 완료했습니다. 기본 실행에는 총 8개의 엔진이 포함되어 있으며, 이 페이지는 순위 맥락으로만 다른 엔진을 언급하며 지정된 두 엔진만 비교합니다. 전체 8개 엔진 결과는 Traditional OCR vs Document Parsing VLMs에서 별도로 공개됩니다.
실행 환경
- 하드웨어: 두 엔진 모두 동일한 NVIDIA RTX 4090 (24 GB)에서 실행; GPU 비용은 RunPod 온디맨드 요금 $0.76/hr로 계산, 각 실행의 마니페스트에 가격 타임스탬프 기록.
- 엔진: 기본 설정 그대로, 파인튜닝 없음. 버전 고정: docTR v1.0.1 및 Docling 2.119.05> — 공개 저장소 모델 표(README.md) 및 실행 마니페스트 기준.
- LLM 후처리기: deepseek-v4-flash API 사용, 결정적 출력을 위한 temperature 0 설정; 두 엔진의 모든 LLM 필드 행에 사용된 단일 모델.
- 비용 기준: 벽시계 실행 시간 × $0.76/hr, 모델 초기화 포함 — 일괄 처리로 페이지당 비용 절감.
- 필드 후처리: SROIE 정규식 필드 지표는
postprocessed_sroie_receipt_regex_*— 고정 패턴 세트로 OCR 텍스트에서 추출된 필드. OCR + 후속 추출을 측정하며, 두 모델의 네이티브 구조화 출력이 아님; LLM_* 열은 OCR 텍스트 + LLM 추출을 측정. 두 파이프라인은 절대 혼합되지 않으며, Docling의 네이티브 문서 모델은 이 벤치마크로 점수화되지 않음.
지표 정의
- CER: OCR 텍스트와 정답 간의 편집 거리를 정답 문자 수로 나눈 값. 낮을수록 좋음.
- WER: 단어 단위로 동일한 편집 거리 계산.
- 필드 값 F1: OCR 텍스트에 고정 정규식 패턴을 사용하여 추출된 필드 값에 대한 정밀도/재현율 조화 평균. 열: regex_field_value_f1. 점수가 0이면 필드 값이 복구되지 않음.
- 필드 값 F1 (LLM): LLM 후처리기 출력에 대한 동일 지표. 열: llm_field_value_f1. 두 파이프라인은 다르며 절대 혼합되지 않음.
- 문서 필드 정확 일치: 모든 대상 필드가 정확히 일치한 문서의 비율 — 필드별 F1보다 훨씬 엄격한 기준.
- 지연 시간 p50/p95 및 페이지/분: 안정 상태 페이지당 추론 시간 및 모델 초기화 포함 벽시계 처리량. 서로 다른 시계를 측정.
- 1,000페이지당 비용: 기록된 $0.76/hr 요금으로 1,000페이지에 대한 과금 GPU 시간, 모델 초기화 포함.
출처 목록
- summary_metrics.csv (GitHub raw). 16행 = 8개 모델 × 2개 데이터셋. 열: model, compute_type, dataset, cer, wer, field_f1_regex, field_acc_regex, latency_p50_ms, latency_p95_ms, cost_per_1000_pages, pages_per_minute, error_rate. 이 페이지의 모든 CER/WER, 지연 시간, 비용, 처리량 수치는 여기의 doctr 및 docling 행에서 추적됩니다.
- field_method_comparison.csv (GitHub raw). 16행; 열 model, dataset, llm_model (= deepseek-v4-flash), regex/llm field-value accuracy and F1, document-fields-exact, llm_median_latency_ms, token counts. 모든 regex/LLM field-F1 수치는 여기의 doctr 및 docling 행에서 추적됩니다.
- ImageToTableai/benchmark-ocr 저장소. 결과 CSV, 편집된 실행 매니페스트, 고정된 프로토콜, 재현을 위한 데이터셋 샘플 목록을 호스팅하는 공개 저장소.
- results/manifests/ (GitHub). 각 게시된 실행에 대한 편집된 manifest.json으로, 모델 버전, GPU/드라이버, torch/CUDA/Python 버전, 가격 타임스탬프가 포함된 비용 메타데이터, 아티팩트 해시를 포함합니다.
- Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). SROIE 2019 데이터셋 정의, 작업 구조 및 라이선스 (CC-BY-4.0).
- Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). CORD v2 데이터셋 정의, 중첩된 필드 스키마 및 라이선스 (CC-BY-4.0).
- Auer et al., "Docling Technical Report" (2024). 아키텍처 배경만 — Docling의 단계별 파이프라인을 설명합니다. 이 페이지의 어떤 벤치마크 수치도 여기서 가져오지 않았습니다.
한계점
- 문서 범위 — 영수증만 해당: SROIE + CORD. Docling의 가치를 정의하는 레이아웃/테이블/읽기 순서/긴 문서 처리를 여기서 측정하는 것은 없습니다. 이러한 기능은 범위 밖이며, 반증된 것이 아닙니다. 이 페이지를 근거로 “Docling은 나쁘다”는 결론을 내리지 마세요. 결론은 다음과 같습니다: 단일 페이지 영수증에서는 파이프라인 오버헤드가 그 가치를 충분히 발휘하지 못합니다.
- 표본 크기: 361개 영어 + 100개 인도네시아어 영수증. 필드 F1 및 CER은 말뭉치에 민감합니다. 여기서 문서화된 격차는 노이즈 밴드를 훨씬 초과하지만, 단일 퍼센트 차이는 노이즈로 취급해야지 엔지니어링 진실로 취급해서는 안 됩니다.
- 단일 GPU 등급 및 단일 가격: 모든 수치는 $0.76/hr의 RTX 4090에서 나왔으며, 가격은 실행 매니페스트에서 2026년 8월로 타임스탬프가 찍혀 있습니다. 다른 GPU, 다중 GPU 서버링, 배치 스케줄링 또는 가격 변경은 지연 시간, 처리량 및 비용을 변화시킬 것입니다 — 예산 편성 전 현재 요금으로 비용을 다시 계산하세요.
- 단일 LLM 후처리기: 모든 LLM 행은 temperature 0의 deepseek-v4-flash를 사용합니다. 다른 LLM은 절대 필드 F1을 변화시킵니다. docTR의 0.049점 리드는 경계선에서 움직일 수 있습니다. LLM 지연 시간은 API로 인한 것이며, 어느 엔지니어의 자체 지연 시간에도 포함되지 않습니다.
- 정규식 튜닝: 패턴 세트는 데이터셋당 한 번 작성되었습니다. 형식별로 심하게 튜닝된 패턴 라이브러리는 자체 레이아웃에서 더 높은 점수를 받을 수 있습니다 — LLM이 제거하는 유지보수 비용을 감수하면서요. Docling의 2.9배 정규식 이점은 이 단일 고정 패턴 세트에 대해 측정되었습니다.
- Docling의 네이티브 출력은 점수화되지 않았습니다: Docling은 구조화된 문서 모델을 출력하지만, 벤치마크는 텍스트 + 후처리기를 점수화하며, 네이티브 구조화된 출력은 점수화하지 않습니다. Docling의 네이티브 필드를 점수화하는 벤치마크 변형은 다른 실험이 될 것입니다; 이 페이지는 이를 시도하지 않습니다.
- CORD CER는 모델별 품질 읽기가 아닙니다: CORD ground truth는 주석 구조를 포함하고 있으며, 어느 엔지니어도 인도네시아어를 주로 학습하지 않았습니다. CORD CER(~0.91~0.92)는 언어 불일치 + ground-truth 인플레이션을 반영합니다. CORD 행은 프레이밍과 함께 인용되며, 어떤 SROIE 순위에도 합쳐지지 않습니다.
- 버전 고정: 결과는 docTR v1.0.1 및 Docling 2.119.0에 해당합니다. 어느 엔지니어의 최신 릴리스도 이 페이지의 모든 수치를 변화시킬 수 있습니다.
관련 참고 자료: docTR vs Surya2 영수증 벤치마크 · PaddleOCR vs EasyOCR 영수증 벤치마크 · 기존 OCR vs 문서 파싱 VLM · 정규식 vs LLM 필드 추출 · 필드 수준 vs 문자 수준 정확도
관련 읽을거리: AI OCR vs 기존 OCR 정확도 · AI 이미지 데이터 추출 vs 기존 OCR · AI 문서 추출 가격 (2026)