EasyOCR vs docTR 영수증 벤치마크
속도 챔피언 vs 필드 추출기 (2026)

두 엔진은 딥러닝 OCR의 두 세대를 대표하며, 모두 OCR 대 VLM 구도에서 전통적인 쪽에 속합니다. EasyOCR은 클래식한 단일 패스 CNN + RNN + CTC 인식기입니다 — ResNet 특징 추출기가 시퀀스 모델에 데이터를 공급하고, 연결주의 시간 분류(Connectionist Temporal Classification)로 디코딩되며, 어텐션 기반 정교화가 적용됩니다. 그 설계 중심은 매우 넓은 언어 및 문자 커버리지와 간단한 설치로 유명합니다. docTR(v1.0.1)은 현대적인 2단계 신경망 파이프라인입니다: 감지 단계가 텍스트 영역을 찾고, 인식 단계가 이를 전사합니다 — DETR 스타일 트랜스포머 감지와 트랜스포머 인식기를 기반으로 구축되어, 인쇄 문서의 정확도를 위해 설계되었습니다. 문자 오류율(CER)은 삽입, 삭제, 대체를 정답 문자 수로 나눈 값입니다 — CER 0.197은 100자당 약 19.7자를 잘못 읽었음을 의미합니다. 단어 오류율(WER)은 동일한 편집 거리 논리를 전체 단어 수준에 적용합니다. 둘 다 낮을수록 좋습니다. 두 엔진 모두 비전-언어 모델(VLM)이 아닙니다 — 둘 다 이해된 구조가 아닌 원시 텍스트를 출력합니다.

SROIE에서의 텍스트 정확도: docTR의 명확한 우위

SROIE 2019 테스트 분할의 361개 영어 영수증에서, 현대적 아키텍처가 두 텍스트 지표 모두에서 승리합니다: CER 0.1971 대 0.2833 및 WER 0.3199 대 0.6158 — EasyOCR의 WER은 거의 두 배입니다. WER 격차(48%)는 CER 격차(30%)보다 훨씬 크며, 이는 이 말뭉치에서 EasyOCR의 문자 수준 실수가 전체 단어 실패로 이어지고 있음을 시사합니다. 두 엔진 모두 오류 없이 실행됩니다. 두 엔진 모두 벤치마크의 전체 CER 챔피언은 아닙니다 — 그 타이틀은 Surya2(0.1915)에게 있으며, docTR 자체가 2위; EasyOCR은 8개 중 4위를 차지합니다.

출처: summary_metrics.csv — cer 및 wer 열, sroie_2019 행. docTR cer 0.19707 / wer 0.31990; EasyOCR cer 0.28327 / wer 0.61578. 낮을수록 좋습니다. 엔진당 361개 샘플; 둘 다 error_rate 0.0.

테이블: summary_metrics.csv — cer / wer / error_rate 열, sroie_2019 행. 정확한 값: docTR cer 0.19707 / wer 0.31990; EasyOCR cer 0.28327 / wer 0.61578. 상대적 격차: docTR의 CER 30% 낮음, WER 48% 낮음. CER/WER가 낮을수록 좋습니다. 동일 8엔진 실행 내 CER 순위 맥락: Surya2 0.1915, docTR 0.1971, PaddleOCR 0.2045, EasyOCR 0.2833.

정규식 필드 반전: 더 나쁜 텍스트, 더 복구 가능한 필드

두 엔진의 원시 텍스트를 동일한 고정 정규식 패턴으로 SROIE 영수증 필드 4개에 대해 벤치마크 — 전통적인 OCR + 규칙 기반 핵심 정보 추출(KIE) 접근 방식 — 하면 순위가 뒤집힙니다: EasyOCR은 0.1477 필드 F1로 필드를 추출하는 반면 docTR은 0.0766을 기록하며, 문자 정확도가 더 낮은 엔진이 1.93×의 이점을 갖습니다. 이것은 벤치마크의 반복되는 "텍스트 정확도 ≠ 필드 정확도" 반전 — docTR vs Surya2에서 전통적인 OCR과 문서 파싱 VLM 사이에 보이는 것과 동일한 패턴 — 이제 동일한 종류의 원시 라인 텍스트를 출력하는 두 전통 엔진 사이에서 발생합니다.

필드 값 F1은 추출된 필드 값을 기준값과 비교하여 정밀도와 재현율의 조화 평균입니다: 1.0은 모든 영수증 필드가 완벽하게 복구됨을 의미하고, 0은 아무것도 없음을 의미합니다. 이 반전의 메커니즘은 인식 품질 자체가 아니라 정규식 패턴 세트의 속성입니다: 패턴은 RM 12.00이나 14/08/2020과 같은 포맷된 값에 대해 데이터셋당 한 번 작성되었습니다. docTR의 깨끗하지만 원시 라인 텍스트 — CER 기준으로 정확하지만 원래 대소문자와 구분자 노이즈를 유지 — 은 고정 패턴을 실패하게 만들고; EasyOCR의 출력은 우연히 더 자주 일치합니다. "정규식 필드 추출" 열은 벤치마크의 postprocessed_sroie_receipt_regex_* 지표입니다: 이들은 네이티브 구조화된 출력이 아닌 OCR 텍스트 + 하류 규칙 기반 추출을 측정합니다. 포맷별로 크게 조정된 패턴 라이브러리는 어느 엔진에 대해서든 다른 점수를 매길 수 있습니다 — 패턴 세트는 조정된 프로덕션 파서가 아닌 고정된 측정 도구입니다.

출처: field_method_comparison.csv — regex_field_value_f1 / llm_field_value_f1 열, sroie_2019 행. LLM 후처리기: deepseek-v4-flash. 엔진당 361개 샘플 (llm_ok_count).

표: field_method_comparison.csv — regex 열, sroie_2019 행. 이는 postprocessed_sroie_receipt_regex_* 지표로, 각 엔진의 OCR 텍스트에 고정 패턴을 적용한 결과입니다. docTR의 regex 필드 F1인 0.0766은 기본 실행에서 8개 엔진 중 두 번째로 낮은 수치인데, 이는 CER이 두 번째로 낮음에도 불구하고 패턴 세트가 데이터셋당 한 번만 작성되었고, docTR의 깨끗하지만 원시적인 줄 텍스트가 이 네 필드에서 regex 친화적이지 않기 때문입니다.

LLM 레버: 반전이 결정적으로 일어나다

두 엔진의 OCR 텍스트를 구조화된 추출 프롬프트와 함께 LLM 후처리기(deepseek-v4-flash, temperature 0)에 입력하면, 필드 순위가 다시 반전됩니다 — 벤치마크의 어떤 조합보다 가장 큰 차이를 보이며: docTR 0.6171 대 EasyOCR 0.3717 필드 값 F1, 1.66× 격차. docTR의 결과는 8개 엔진 중 가장 높은 LLM 필드 값 F1이고, EasyOCR의 결과는 가장 낮습니다. 정규식 패턴 세트가 docTR의 깔끔한 텍스트를 벌한 곳에서, LLM은 그것을 보상합니다 — 그리고 우연히 정규식에 유리했던 EasyOCR의 중간 수준 텍스트는 동일한 프롬프트 하에서 성능이 저하됩니다.

이것은 전체 8개 엔진 벤치마크에서 나타난 LLM 수렴 패턴과 동일합니다 — LLM 후처리는 건강한 엔진들을 0.57–0.62 필드 값 F1 밴드로 끌어올립니다. 문자 모양 매칭 대신 의미를 이해하기 때문입니다 — EasyOCR은 뚜렷한 예외입니다. 이 레버는 무료가 아닙니다: LLM 호출은 OCR 시간 외에 문서당 중간 지연 시간을 대략 2.0–2.1초 추가합니다. 또한 엔진이 근본적으로 읽지 못한 텍스트를 구제하지는 않습니다. 하지만 이 조합에서는 후처리기가 결정적인 구성 요소가 됩니다: 파이프라인에 LLM이 있으면 docTR 선택의 효과가 배가됩니다.

표: field_method_comparison.csv — llm_* 열, sroie_2019 행. LLM 모델: deepseek-v4-flash, temperature 0. LLM 지연 시간은 API로 인해 발생하며 엔진 지연 시간과 별개입니다(summary_metrics.csv latency_p50_ms). “문서 필드 완전 일치”는 모든 대상 필드가 정확히 일치한 문서의 비율입니다 — 필드별 F1보다 훨씬 엄격한 기준; EasyOCR은 영수증의 0.28%에서 네 개의 필드를 모두 정확히 맞춥니다.

EasyOCR LLM 역설: 중간 수준 텍스트, 최악의 후속 추출

이 비교에서 가장 직관에 반하는 데이터 포인트 — PaddleOCR vs EasyOCR에서 처음 기록되었고, 여기서 다른 경쟁 상대와 대조하여 확인됨: EasyOCR의 OCR 텍스트는 문자 정확도 기준으로 중간 수준 — 그런데 그 텍스트를 다른 모든 엔진에 사용된 것과 동일한 LLM 후처리기에 입력하면, SROIE LLM 필드 F1이 0.3717로 벤치마크의 8개 엔진 중 가장 낮습니다 — CER이 더 나쁜(0.3347) CPU 엔진인 Tesseract(0.4389)보다도 낮습니다. OCR 텍스트만 변경되었고, LLM, 프롬프트, 영수증은 동일했습니다.

관찰된 패턴, 메커니즘은 미검증. 하나의 그럴듯한 가설 — 더 이상은 아닙니다 — 출력 형식 관례입니다: EasyOCR이 텍스트 줄을 배치, 결합 또는 분리하는 방식이 원시 문자 정확도와는 무관한 이유로 후속 LLM 필드 추출을 저해하는 것으로 보입니다. 벤치마크는 이 메커니즘을 분리하지 않았으며, 결과는 여기서 재현 가능하고 안정적인 것으로 기록됩니다, 그러나 인과관계 주장은 하지 않습니다. docTR의 더 깨끗한 기본 텍스트 + LLM은 EasyOCR이 놓치는 동일한 범위의 최상위에 도달합니다.

출처: field_method_comparison.csv — llm_field_value_f1, sroie_2019의 8개 행 전체, 각 361개 샘플(llm_ok_count). 모든 엔진에 동일한 LLM 후처리기 사용: deepseek-v4-flash, temperature 0. CER 컨텍스트는 summary_metrics.csv, cer 열, sroie_2019 행에서 가져옴.

표: field_method_comparison.csv — llm_field_value_f1, 모든 sroie_2019 행; CER 열은 summary_metrics.csv의 cer, sroie_2019 행에서 가져왔습니다. docTR의 0.6171은 벤치마크에서 가장 높은 LLM 필드 F1 점수입니다. EasyOCR의 CER(0.2833)은 8개 중 4위로, 텍스트 인식은 중간 수준이지만 LLM 후속 필드 복원 성능은 가장 낮습니다. 이 역설은 관찰 및 재현 가능한 것으로 기록되었으며, 그 메커니즘은 이번 벤치마크에서 완전히 규명되지 않았습니다.

작동 범위: docTR은 벤치마크의 속도 및 비용 챔피언

정확도는 어떤 엔진이 가장 잘 읽는지 결정하지만, 작동 범위는 어떤 엔진이 완료하는지 결정합니다. 동일한 RTX 4090에서 동일한 기록된 $0.76/hr 요금으로, docTR은 페이지당 108.7 ms p50으로 449.3 pages/min을 유지하며 1,000페이지당 $0.048의 비용이 듭니다. EasyOCR은 페이지당 413.6 ms p50으로 124.5 pages/min을 유지하며 1,000페이지당 $0.110의 비용이 듭니다 — 이는 docTR에 유리한 3.8× 지연 시간 격차, 3.6× 처리량 격차, 그리고 2.3× 비용 격차입니다. 전체 8개 엔진 테스트에서 docTR의 108.7 ms p50, 449.3 pages/min, $0.048 비용은 각각 측정된 모든 엔진 중 최고 성능을 기록했습니다 — docTR은 동시에 벤치마크에서 가장 빠르고 가장 저렴한 엔진입니다.

비용은 벽시계 실행 시간 × RunPod RTX 4090 요금으로 계산되며, 모델 초기화 비용이 포함됩니다 — 이는 실제로 지불하게 될 GPU 시간 비용입니다. 처리량은 동일한 초기화를 포함한 벽시계 페이지/분입니다. 지연 시간 p50/p95는 모델 로딩을 제외한 워밍 후 점수 측정 방식(warm-then-scored)의 안정 상태 페이지별 추론 시간입니다. EasyOCR의 꼬리 지연 시간은 비례적으로 더 나쁩니다 — docTR의 281.4 ms에 비해 960.4 ms p95로 3.4배 격차가 있습니다. EasyOCR은 여전히 측정된 다른 대부분의 엔진보다 실제로 저렴합니다 — 이는 비용과 속도 모두 중간 수준이며, 비싸거나 느리지 않습니다.

출처: summary_metrics.csv — latency_p50_ms / latency_p95_ms 열, sroie_2019 행. docTR p50 108.72 / p95 281.38; EasyOCR p50 413.64 / p95 960.37. 안정 상태 지연 시간.

출처: summary_metrics.csv — cost_per_1000_pages 열, sroie_2019 행. docTR 0.0479, EasyOCR 0.1098. 비용 = 벽시계 실행 시간 × $0.76/hr, 실행 매니페스트에 가격 타임스탬프 기재. docTR의 $0.048는 벤치마크 내 모든 엔진 중 1,000페이지당 가장 낮은 비용입니다. EasyOCR의 $0.110은 두 번째로 낮은 비용입니다.

표: 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; EasyOCR p50 413.64 / p95 960.37 / 124.53 pg/min / $0.1098. 벤치마크 전체 최고 기록: docTR은 8개 엔진 중 가장 낮은 p50 지연 시간, 가장 높은 분당 페이지 수, 가장 낮은 비용을 기록했습니다.

CORD (Indonesian Receipts): Both Collapse on Text, the LLM Gap Widens

Neither engine was trained predominantly on Indonesian receipts, so CORD v2 (100 samples, nested fields menu/sub_total/total) functions as a cross-language stress test — and both collapse on raw CER: 0.9101 (docTR) and 0.9185 (EasyOCR), a language-mismatch wash with both engines effectively unable to read the text. Per the benchmark protocol, CORD numbers are kept quarantined from the SROIE comparison — not merged into any ranking — because CORD’s ground-truth text embeds annotation structure, which inflates raw CER for every engine on top of the genuine language mismatch.

The field metrics show the SROIE pattern extending — and widening. Through the LLM postprocessor, docTR’s field F1 holds at 0.5500 vs EasyOCR’s 0.3378 on CORD — a 1.63× gap, the same ordering as SROIE’s 1.66×, even when both text recognizers fail at the character level. Through regex patterns, docTR recovers no fields (0.0000 field F1 — a literal zero in the CSV, not a missing value) because the English-format patterns matched nothing in Indonesian text, while EasyOCR scrapes 0.0067. docTR’s cost edge also narrows and reverses on CORD ($0.094 vs EasyOCR’s $0.086 per 1,000 pages) — but its wall-clock throughput advantage grows to 500.4 vs 211.8 pages/min (2.4×). CORD is quoted here for language-robustness context; it is deliberately never pooled with the SROIE numbers into a single leaderboard.

표: summary_metrics.csv (문자 오류율(CER) / 페이지당 처리 시간 / 1,000페이지당 비용) 및 field_method_comparison.csv, cord_v2 행. CORD 수치를 어떤 SROIE 순위와도 병합하지 마세요: CORD 문자 오류율(CER)은 정답 데이터의 언어 불일치와 주석 구조로 인한 인플레이션을 결합한 것입니다. 정규식 패턴은 영어 형식용으로 작성되었으므로, 정규식 필드 값 F1은 두 엔진 모두에서 약 0~1%로 급락합니다. docTR의 0.0000은 결측치가 아니라 CSV에 기록된 실제 영점입니다. LLM 필드 값 F1 격차(0.5500 vs 0.3378)는 언어에 걸쳐 SROIE 패턴을 확장하며, 비용 순서는 역전됩니다(EasyOCR $0.086 vs docTR $0.094) 처리량 격차는 2.4배로 벌어집니다.

언제 누가 이기는가: 요약 격자표

“더 낫다”는 것은 작업 부하에 따라 다르며, 이 대결은 축을 명확히 나눕니다: 원본 텍스트 정확도, LLM 후속 필드, 속도, 처리량, 비용은 모두 docTR에 유리합니다. 고정 정규식 필드 추출과 배포 측면은 EasyOCR에 유리합니다 — 단, EasyOCR의 LLM 후속 결과는 가장 큰 리스크이지 장점이 아닙니다.

자주 묻는 질문

docTR는 영수증 처리에서 EasyOCR보다 더 정확한가요?

네, 이번 벤치마크의 모든 원시 텍스트 및 필드 추출 정확도 항목에서 그렇습니다. SROIE 2019 기준: 문자 오류율(CER) 0.1971 vs 0.2833 (30% 낮음), 단어 오류율(WER) 0.3199 vs 0.6158 (48% 낮음), LLM 후처리 필드 값 F1 0.6171 vs 0.3717 — 다만 정규식 필드 값 F1에서는 EasyOCR이 0.1477 vs 0.0766으로 앞섭니다. 두 엔진 모두 벤치마크의 종합 문자 오류율(CER) 챔피언은 아닙니다 — Surya2 (0.1915)가 docTR을 간신히 제치고 그 타이틀을 보유하고 있습니다.

왜 docTR은 텍스트 정확도는 더 높지만 정규식 필드 추출은 EasyOCR보다 낮나요?

두 지표가 고정된 측정 도구를 기준으로 서로 다른 출력을 평가하기 때문입니다. docTR은 깨끗한 원시 라인 텍스트를 반환합니다 — 문자 오류율(CER) 기준으로는 정확하지만, 원래 대소문자와 구분자를 보존합니다 — 그리고 포맷된 값을 위해 데이터셋별로 한 번 작성된 고정된 정규식 패턴은 대부분 이를 처리하지 못합니다: SROIE 정규식 필드 값 F1 0.0766. EasyOCR의 출력은 우연히 0.1477로 패턴과 일치합니다. 대신 둘 다 LLM에 입력하면 격차는 1.66배로 docTR에 유리하게 역전됩니다 — 병목은 OCR이 아니라 정규식 패턴 세트였습니다.

왜 EasyOCR은 문자 정확도는 괜찮음에도 불구하고 LLM 필드 추출은 최악인가요?

이것은 이번 벤치마크에 기록된 역설로, 현재 증명된 메커니즘은 없습니다. EasyOCR의 SROIE 문자 오류율(CER) (0.2833)은 8개 엔진 중 4위이지만, LLM 후처리 필드 값 F1 (0.3717)은 최하위입니다 — 문자 오류율(CER)이 더 나쁜 Tesseract (0.4389)보다도 낮습니다. 주요 가설은 EasyOCR이 텍스트 라인을 배치하거나 결합하는 방식의 출력 형식 관례가 하위 LLM 추출을 저하시킨다는 것입니다. 이는 메커니즘 미검증 상태로 관찰되고 재현 가능한 패턴으로 기록되어 있습니다. 같은 역설은 다른 상대를 대상으로 한 PaddleOCR vs EasyOCR에서도 기록되어 있습니다.

docTR는 EasyOCR보다 얼마나 빠르고 저렴한가요?

3.8× 낮은 p50 지연 시간(108.7 vs 413.6 ms), 3.4× 낮은 p95(281.4 vs 960.4 ms), 3.6× 높은 처리량, 그리고 동일한 RTX 4090($0.76/hr)에서 1,000페이지당 2.3× 낮은 비용($0.048 vs $0.110)을 보입니다. docTR은 세 가지 시계 모두에서 벤치마크에서 가장 빠르고 저렴한 엔진입니다. EasyOCR은 비용과 속도 모두 중간 수준입니다.

왜 두 엔진 모두 CORD 영수증에서 이렇게 낮은 점수를 받나요?

SROIE 순위와 별도로 유지되는 벤치마크 프로토콜의 두 가지 복합적인 원인이 있습니다: 진정한 언어 불일치와 CORD의 정답 텍스트 내 주석 구조의 과장 — CER은 docTR 0.9101, EasyOCR 0.9185입니다. 여전히 차이를 만드는 것은 LLM 후속 처리 복구 능력입니다: docTR 0.5500 vs EasyOCR 0.3378 필드 F1 — 두 인식기 모두 문자 수준에서 실패하더라도 SROIE 패턴은 지속되며 확대됩니다.

영수증 파이프라인은 EasyOCR과 docTR 중 어떤 엔진을 선택해야 하나요?

대량의 추출된 필드를 측정된 비용으로 처리하는 것이 목표인 파이프라인의 경우, docTR은 이 코퍼스에서 우위를 점합니다: 더 나은 원시 텍스트, 어떤 엔진보다 우수한 LLM 후속 필드(0.6171 vs 0.3717), 그리고 2.3× 비용 이점, 3.6× 처리량, 3.8× 지연 시간 — 네 가지 축 모두에서 동시에. EasyOCR는 저렴하고 설치가 쉬우며, 깨끗한 문서에 대한 다중 스크립트 대량 OCR이 필요하고, 정규식 추출이나 적당한 양의 원시 텍스트가 작업이며, LLM 후속 필드 품질이 덜 중요한 경우 여전히 합법적인 선택입니다 — 하지만 결정하기 전에 측정된 약한 LLM 후속 성능을 예산에 반영하세요. 이 결과는 2026년 8월 한 GPU 티어에서 영어 및 인도네시아 영수증에 대한 것이며, 프로도션 결정 전에 대상 코퍼스에서 다시 실행하세요.

이 페이지의 숫자는 어디서 오나요?

모든 수치는 1차 벤치마크의 공개 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로 계산하며, 가격은 각 실행의 편집된 manifest에 타임스탬프가 찍혀 있습니다.
• 엔진: 기본 제공 상태, 파인튜닝 없음. 버전 고정: EasyOCR 1.7.2 및 docTR v1.0.1** — 공개 저장소 모델 테이블(README.md) 및 실행 manifest 기준. EasyOCR의 SROIE 행은 2026-08-17 torch 2.8 재실행에서 재검증되었습니다; 공개 CSV에는 수정된 값이 포함되어 있습니다.
• LLM 후처리기: API를 통한 deepseek-v4-flash, 결정론적 출력을 위해 temperature 0 사용; 두 엔진의 모든 LLM 필드 행에 사용된 단일 모델입니다.
• 비용 기준: 벽시계 실행 시간 × $0.76/hr, 모델 초기화 포함 — 일괄 처리는 페이지당 비용을 낮춥니다.
• 필드 후처리: SROIE 정규식 필드 지표는 postprocessed_sroie_receipt_regex_*로, OCR 텍스트에서 데이터셋당 한 번 작성된 고정 패턴 세트로 추출된 필드입니다. 이는 OCR + 하위 추출을 측정하며, 두 모델의 네이티브 구조화된 출력이 아닙니다; LLM_* 열은 OCR 텍스트 + LLM 추출을 측정합니다. 두 파이프라인은 절대 혼합되지 않습니다.

지표 정의

• 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 시간.

출처 목록

1. 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, 지연 시간, 비용, 처리량 수치는 여기의 easyocr 및 doctr 행에서 추적됩니다.
2. field_method_comparison.csv (GitHub raw). 16행; 열 model, dataset, llm_model (= deepseek-v4-flash), regex/llm 필드 값 정확도 및 F1, document-fields-exact, llm_median_latency_ms, 토큰 수. 모든 regex/LLM 필드 F1 수치는 여기의 easyocr 및 doctr 행에서 추적됩니다.
3. ImageToTableai/benchmark-ocr 저장소. 결과 CSV, 비공개 처리 기록, 고정된 프로토콜 및 재현을 위한 데이터셋 샘플 목록을 호스팅하는 공개 저장소.
4. results/manifests/ (GitHub). 각 게시된 실행에 대한 비공개 manifest.json 파일로, 모델 버전, GPU/드라이버, torch/CUDA/Python 버전, 가격 타임스탬프가 포함된 비용 메타데이터 및 아티팩트 해시를 포함합니다.
5. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). SROIE 2019 데이터셋 정의, 작업 구조 및 라이선스(CC-BY-4.0).
6. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). CORD v2 데이터셋 정의, 중첩 필드 스키마 및 라이선스(CC-BY-4.0).

한계점

• 문서 범위 — 영수증만 해당: SROIE + CORD. 이 페이지에서는 영수증 외 텍스트에 대한 EasyOCR의 80개 이상 언어 지원 범위, 표/양식/긴 문서에 대한 docTR의 동작, 또는 다른 문서 유형은 측정하지 않습니다. 이 페이지를 근거로 어떤 엔진이 "모든 면에서 우월"하다고 결론짓지 마세요.
• 표본 크기: 영어 361건 + 인도네시아어 100건의 영수증. 필드 값 F1과 문자 오류율(CER)은 말뭉치에 민감합니다. 수백 분의 일 수준의 한 자리 차이는 노이즈로 간주해야지, 엔지니어링적 사실로 취급해서는 안 됩니다 — 다만 여기에 기록된 격차는 그 범위를 훨씬 벗어납니다.
• 단일 GPU 등급 및 단일 가격: 모든 수치는 $0.76/hr의 RTX 4090에서 나왔으며, 가격은 실행 매니페스트에서 2026년 8월로 타임스탬프가 찍혀 있습니다. 다른 GPU, 다중 GPU 서버링, 배치 스케줄링 또는 가격 변경은 지연 시간, 처리량 및 비용을 변화시킬 것입니다 — 예산 편성 전 현재 요금으로 비용을 다시 계산하세요.
• 단일 LLM 후처리기: 모든 LLM 행은 temperature 0의 deepseek-v4-flash를 사용합니다. 다른 LLM은 절대적인 필드 값 F1을 변화시킬 수 있습니다. EasyOCR 패러독스의 크기는 LLM에 따라 변할 수 있지만, 관찰된 패턴은 이 단일 후처리기에서 두 데이터셋 모두에 걸쳐 일관되었습니다. LLM 지연 시간은 API로 인한 것이며, 어느 엔진 자체 지연 시간의 일부가 아닙니다.
• EasyOCR 패러독스 메커니즘 미검증: 벤치마크는 EasyOCR의 중간 수준 CER 텍스트가 가장 나쁜 LLM 후속 필드 복구 성능(0.3717 SROIE / 0.3378 CORD)을 보인다는 것을 문서화합니다 — 이는 출력 텍스트 레이아웃 관례라는 가설 하에서 관찰되고 재현 가능한 결과이며, 인과 메커니즘은 명시적으로 격리되지 않았습니다. 이를 라이브러리의 검증된 특성으로 취급하지 말고, 계획을 세울 때 고려해야 할 측정된 결과로 다루세요.
• 정규식 튜닝: 패턴 세트는 데이터셋당 한 번 작성되었습니다. 형식별로 심하게 튜닝된 패턴 라이브러리는 자체 레이아웃에서 더 높은 점수를 받을 수 있습니다 — LLM이 제거하는 유지보수 비용을 감수하면서. docTR의 정규식 필드 불리(0.0766 vs 0.1477)는 이 고정된 도구의 특성이지, 튜닝된 파서가 복구할 수 있는 것에 대한 주장이 아닙니다.
• CORD CER는 모델별 품질 수치가 아닙니다: CORD 기준 정답은 주석 구조를 포함하고 있으며, 어느 엔진도 인도네시아어를 주로 학습하지 않았습니다. CORD CER(~0.91)는 언어 불일치 + 기준 정답 부풀려짐을 반영합니다. CORD 행은 맥락을 포함하여 인용되며, 어떤 SROIE 순위에도 합쳐지지 않습니다.
• 엔진 두 개만 해당: 이 대결은 의도적으로 기본 실행의 다른 여섯 엔진, 클라우드/API OCR 서비스, 호스팅 VLM API를 제외합니다. 이들의 지연 시간 및 가격 모델은 여기서 측정된 로컬 엔진과 근본적으로 다릅니다.
• 버전 고정: 결과는 EasyOCR 1.7.2 및 docTR v1.0.1에 해당합니다. 어느 엔진의 최신 릴리스도 이 페이지의 모든 수치를 변화시킬 수 있습니다.

관련 참고 자료: PaddleOCR vs EasyOCR 영수증 벤치마크 · docTR vs Surya2 영수증 벤치마크 · 기존 OCR vs 문서 파싱 VLM · 정규식 vs LLM 필드 추출 · 필드 수준 vs 문자 수준 정확도 · 1,000페이지당 OCR 비용

관련 읽을거리: AI OCR vs Traditional OCR Accuracy · AI Image Data Extraction vs Traditional OCR · AI Document Extraction Pricing (2026)