마지막 검토: 2026-08-14 · 실행 등급: 공식 · 자체 벤치마크 · 8개 모델 × 2개 영수증 데이터셋

아래 모든 수치는 벤치마크의 results/field_method_comparison.csvresults/summary_metrics.csv에서 가져왔으며, 공개 GitHub 저장소에 미러링되어 행별로 인용됩니다. F1 값은 CSV에서 0–1 소수로 저장되며 여기서는 백분율로 표시됩니다. 두 가지 필드-F1 정의 — regex 기반 접근 방식과 LLM 기반 접근 방식 —은 모든 그래프에 레이블이 지정되며 절대 혼합되지 않습니다.

OCR 텍스트에서 구조화된 필드를 추출하는 작업에서 후처리기의 선택이 OCR 엔진의 선택보다 더 중요합니다. regex 규칙을 LLM(deepseek-v4-flash)으로 대체하면 영어 영수증에서 필드 F1이 0.08–0.34에서 0.37–0.62로, 인도네시아어 영수증에서 0.00–0.34에서 0.16–0.55로 향상됩니다 — 8개 엔진 모두, 모든 엔진에서, 벤치마크의 모든 행에서.

기억해야 할 반전: docTR은 8개 엔진 중 regex 필드 F1이 가장 낮았으며 LLM 필드 F1이 가장 높았습니다(0.617). Its OCR text was fine — regex patterns just could not survive the format variance (dates, currencies, multi-line addresses) of real receipts. The same text that regex mined into 7.7% of fields yielded 61.7% under an LLM. Upstream OCR only needs to be "good enough"; the postprocessor decides how much of that text becomes usable fields.

SROIE 결과: 영어 영수증

영어 영수증에서 LLM은 8개 엔진 모두에서 정규식을 능가합니다 — 가장 작은 향상폭은 1.76배(PaddleOCR-VL 0.337 → 0.592), 가장 큰 것은 8.1배입니다. 그리고 LLM은 모델 격차를 거의 없앴습니다: 7개의 비-Tesseract 엔진 중 6개가 0.05점 밴드(0.569–0.617) 안에 들어오는데, 이들의 정규식 결과는 0.26점(0.077–0.338) 범위에 퍼져 있었습니다.

SROIE(Scanned Receipt OCR and Information Extraction, ICDAR 2019)는 표준 영어 영수증 벤치마크입니다: 회사, 날짜, 주소, 합계의 4개 대상 필드를 가진 361개의 테스트 영수증(Huang et al., 2019). 각 엔진은 먼저 공유된 RTX 4090 환경에서 OCR 텍스트를 생성했고, 그 텍스트는 두 개의 병렬 후처리기에 입력되었습니다: 고정된 정규식 패턴 세트와 구조화된 추출 프롬프트를 사용하는 LLM deepseek-v4-flash입니다. 둘 다 동일한 정답 필드로 채점되었습니다. 차트는 엔진별 정규식 필드 F1 대비 LLM 필드 F1을 보여줍니다.

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

OCR 엔진	유형	정규식 F1	LLM F1	정규식 Acc	LLM Acc
Tesseract	전통적 (CPU)	23.3%	43.9%	21.4%	43.4%
PaddleOCR	전통적	32.5%	58.1%	29.5%	58.1%
EasyOCR	전통적	14.8%	37.2%	12.7%	37.1%
docTR	전통적	7.7%	61.7%	6.2%	61.7%
Docling	파이프라인 파서	22.4%	56.9%	20.4%	56.6%
Surya2	문서 VLM	31.8%	61.4%	30.0%	61.4%
Unlimited-OCR	문서 VLM	33.8%	60.5%	30.9%	60.5%
PaddleOCR-VL	문서 VLM	33.7%	59.2%	31.0%	58.5%

출처: field_method_comparison.csv — sroie_2019 행: regex_field_value_f1 / llm_field_value_f1 / regex_field_value_accuracy / llm_field_value_accuracy. docTR F1 0.0766 → 0.6171; Surya2 0.3183 → 0.6139; PaddleOCR 0.3254 → 0.5810.

CORD 결과: 인도네시아 영수증

CORD는 격차를 벌립니다. LLM이 더 나아지기 때문이 아닙니다 — 그렇지 않습니다 — 정규식이 무너지기 때문입니다. 8개 엔진 중 6개의 정규식 필드 F1은 10.8% 이하이고, 2개(docTR 0.0%, EasyOCR 0.7%)는 거의 회복하지 못합니다. LLM은 여전히 모든 비-Tesseract 엔진을 33.8% 이상으로 끌어올리며, 수동 패턴이 작동하지 않는 언어와 레이아웃에서도 추출이 일반화됨을 증명합니다.

CORD v2는 중첩된 필드를 가진 인도네시아어 영수증 데이터셋입니다(Park et al., 2019). 교차 언어 스트레스 테스트로 실행되었으며, 8개 엔진 중 인도네시아 영수증을 주로 학습한 것은 없습니다. 이 표를 읽을 때 두 가지 주의사항이 있습니다. 첫째, CORD의 정답 텍스트에는 주석 구조와 VLM 출력 정규화 차이가 포함되어 있어 모든 엔진의 원시 CER을 체계적으로 부풀립니다 — 따라서 아래 필드 지표가 공정한 교차 모델 비교입니다. 둘째, 정규식 패턴은 평면 영어 SROIE 스키마용으로 작성되었습니다. CORD의 중첩 스키마와 인도네시아 형식은 이를 무력화합니다 — 이것이 바로 발견입니다: 한 시장에 맞춘 규칙은 통용되지 않습니다.

출처: field_method_comparison.csv — 데이터셋=cord_v2 행, 열 regex_field_value_f1 / llm_field_value_f1. 엔진당 100개 샘플(llm_ok_count).

OCR 엔진	유형	정규식 F1	LLM F1	정규식 Acc	LLM Acc
Tesseract	전통적 (CPU)	7.5%	16.3%	5.6%	14.3%
PaddleOCR	전통적	1.5%	55.3%	1.1%	50.7%
EasyOCR	전통적	0.7%	33.8%	0.4%	30.5%
docTR	전통적	0.0%	55.0%	0.0%	51.8%
Docling	파이프라인 파서	6.1%	46.9%	4.6%	44.3%
Surya2	문서 VLM	24.6%	52.0%	18.9%	49.0%
Unlimited-OCR	문서 VLM	10.8%	46.8%	8.4%	45.0%
PaddleOCR-VL	문서 VLM	34.1%	52.0%	28.7%	49.3%

출처: field_method_comparison.csv — cord_v2 행. PaddleOCR LLM F1 0.0154 → 0.5527; docTR 0.0 → 0.5500; tesseract 0.0752 → 0.1627.

LLM이 격차를 왜 평탄화하는지 — 그리고 그 한계는 어디에 있는가

숫자에 나타나는 세 가지 패턴이 표면 아래에서 무슨 일이 일어나고 있는지 설명합니다. 각 패턴은 아래의 정확한 CSV 셀로 검증 가능한 주장입니다.

(a) LLM은 0.26점 모델 격차를 0.05점 밴드로 만든다

정규식 기반에서는 어떤 엔진을 선택했느냐가 매우 중요했습니다: SROIE 필드 F1은 0.077(docTR)에서 0.338(Unlimited-OCR)까지 — 0.26점 차이를 보였습니다. LLM 기반에서는 7개 비-Tesseract 엔진 중 6개가 0.569(Docling)에서 0.617(docTR) 사이에 위치합니다 — 0.05점 밴드. 상위 OCR은 읽을 수 있는 텍스트만 생성하면 되며, LLM은 이를 엔진과 거의 무관한 품질로 추출합니다. 이 밴드 뒤처지는 두 엔진이 있습니다: EasyOCR 0.372과 Tesseract 0.439. CORD에서는 Tesseract가 명백한 최하위가 됩니다 — 0.163은 전체 표에서 가장 낮은 LLM 결과입니다.

(b) Tesseract의 한계는 OCR에 의해 설정되며, 후처리기에 의해 설정되지 않는다

"쓰레기 입력, 쓰레기 출력"은 LLM 후처리에도 적용됩니다. Tesseract의 인도네시아 영수증 원본 OCR 텍스트는 문자 오류율이 0.9523(summary_metrics.csv, tesseract/cord_v2, cer)입니다 — 100자 중 약 95자가 잘못되었거나 순서가 뒤섞여 있습니다. CORD에서의 LLM 필드 F1은 결과적으로 0.1627(field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1)입니다: LLM은 읽을 수 없는 텍스트에서 회사명이나 합계를 추출할 수 없습니다. 어떤 후처리기의 한계도 그 아래에 있는 OCR 기본 품질에 의해 설정됩니다 — 이 제약은 어떤 프롬프트 엔지니어링도 제거할 수 없습니다.

(c) docTR이 가장 큰 수혜자: 정규식 바닥에서 LLM 정상으로

docTR의 사례는 문제가 OCR가 아니라 후처리기에 있었다는 것을 가장 명확하게 보여줍니다. SROIE에서의 정규식 필드 F1은 8개 엔진 중 가장 낮은 0.0766였습니다 — 그 깨끗하고 정확한 텍스트는 천의 자리 구분 기호가 있거나 여러 줄로 된 주소의 합계에 대한 정규식 패턴과 일치하지 않았습니다. LLM 기반에서는 동일한 텍스트가 벤치마크 최고의 SROIE 결과인 0.6171를 산출합니다 — 8.1배 향상으로 표에서 가장 큰 수치입니다(field_method_comparison.csv, doctr/sroie_2019, regex_field_value_f1 0.0766 → llm_field_value_f1 0.6171). CORD에서도 효과가 반복됩니다: 정규식 기반 0.0, LLM 기반 0.5500.

Regex로 충분할 때 vs LLM을 사용해야 할 때

솔직한 트레이드오프는 "regex가 망가졌다"가 아니라 "영수증이 변동적일 때 regex가 취약하다"는 것입니다. Regex 후처리는 결정적이고 무료이며 즉시 수행되지만, LLM 후처리는 토큰을 추가하고 문서당 중간값 1.8~2.4초가 소요됩니다. 그 대가로 LLM은 SROIE에서 1.76~8.1배 더 많은 필드를 복구했으며, 대부분의 엔진에서 regex가 거의 제로로 붕괴된 CORD에서는 규칙 기반 추출이 도달할 수 없었던 필드의 33.8~55.3%를 복구했습니다.

Regex로 충분할 때: 문서가 소수의 안정적인 레이아웃 집합에서 나오고 필요한 필드가 거의 일정한 형식으로 나타나는 경우 — 고정된 송장 번호 패턴, 단일 날짜 규칙, 단일 통화 — regex가 적절한 도구입니다: 비용이 들지 않고 마이크로초 단위로 실행되며 실패가 예측 가능합니다. 벤치마크의 최저 사례가 이를 보여줍니다: 영수증에 맞춘 regex를 사용한 엔진도 SROIE에서 0.34 필드 F1에 도달했습니다(Unlimited-OCR 0.3376, PaddleOCR-VL 0.3368).

LLM을 사용해야 할 때: 형식 변동이 발생하는 즉시 — 여러 통화, 지역별 날짜 형식, 여러 줄 주소, 다양한 스타일의 공급업체 이름, 또는 두 번째 언어. 각각이 패턴을 깨뜨리지만, LLM은 하나의 프롬프트로 이를 모두 흡수합니다. 벤치마크의 CORD 결과는 "하나의 언어 추가"가 규칙 기반 파이프라인에 어떤 비용을 수반하는지 정량화합니다: regex 필드 F1은 0.08~0.34에서 0.00~0.34로 떨어졌지만, LLM은 0.16~0.55를 유지했습니다 — 이 패널티를 regex 방식은 100% 부담했고 LLM은 부분적으로만 부담했습니다. 대부분의 프로덕션 흐름에 적합한 올바른 아키텍처는 하이브리드입니다: 변동적인 필드에 대한 LLM 추출, 엄격한 예상 형식을 가진 필드에 대한 regex 또는 규칙 기반 검증, 그리고 1.8~2.4초의 문서당 LLM 비용은 동기적 사용자 대기 대신 비동기 일괄 처리로 분산됩니다.

자주 묻는 질문

LLM 필드 추출이 정규식 추출보다 더 정확한가요?

네, 이 벤치마크에서는 모든 행에서 LLM 후처리(deepseek-v4-flash)가 두 데이터셋의 모든 8개 OCR 엔진에서 정규식 후처리를 능가했습니다. SROIE 영어 영수증에서 LLM 필드 F1은 0.37–0.62인 반면 정규식은 0.08–0.34였고, CORD 인도네시아 영수증에서는 0.16–0.55 대 0.00–0.34였습니다.

LLM 후처리와 함께 사용할 때 어떤 OCR 모델이 영수증 필드를 가장 잘 추출하나요?

SROIE에서는 docTR이 필드 F1 0.6171로 가장 우수했지만, LLM이 개입되면 엔진 간 차이가 대부분 사라집니다. 7개 비Tesseract 엔진 중 6개가 0.569에서 0.617 사이에 위치합니다. CORD에서는 PaddleOCR이 0.5527로 선두를 달리고, docTR이 0.5500으로 뒤를 잇습니다.

Tesseract가 LLM을 사용해도 왜 뒤처지나요?

OCR 텍스트가 너무 열악하여 어떤 후처리기도 필드를 복구할 수 없기 때문입니다. 인도네시아 영수증에서의 문자 오류율은 0.9523(summary_metrics.csv, tesseract/cord_v2)으로, LLM 필드 F1을 0.1627로 제한합니다. 이는 벤치마크 내 최악의 LLM 결과입니다(field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1).

LLM이 정규식 대비 필드 추출을 얼마나 개선하나요?

영어 영수증에서는 엔진에 따라 1.76배에서 8.1배 향상되며, docTR에서 가장 큰 상승폭을 보입니다. 인도네시아 영수증에서는 상승폭이 훨씬 더 큽니다. PaddleOCR은 36배이고, docTR은 정규식이 거의 아무것도 복구하지 못했기 때문에 사실상 무한대에 가깝습니다(0.0 → 0.55).

LLM 후처리가 모든 필드를 정확히 추출하나요?

아니요 — 독자들도 그렇게 기대해서는 안 됩니다. 벤치마크에서 최고의 LLM 필드 F1 점수는 0.617(docTR, SROIE)로, 약 38%의 필드가 여전히 누락되었거나 잘못되었음을 의미합니다. 최고의 전체 문서 정확 일치율은 15.5%(Surya2, SROIE, llm_document_fields_exact)로, 즉 최대 약 6개 문서 중 1개만 네 가지 필드가 모두 정확했습니다. LLM 추출은 정규식에 비해 큰 개선이지만 만능은 아닙니다. 프로덕션 환경에서는 필드 수준 신뢰도 점수와 사람이 여전히 검토가 필요합니다.

LLM 후처리는 얼마나 느리거나 비용이 많이 드나요?

이 벤치마크에서 LLM 호출은 문서당 중간값 지연 시간을 1.8–2.4초 추가했습니다. 전체 16그룹 실행은 대략 133만 프롬프트 + 28만 완료 토큰을 소비했습니다. 이는 실시간 필드 추출 지연 시간이 아닙니다. 대화형 조회가 아닌 비동기 일괄 처리에 적합합니다.

LLM 후처리가 비영어 영수증에서도 작동하나요?

정규식보다는 낫지만, 한계가 더 낮습니다. 인도네시아어 CORD 영수증에서 LLM은 필드 F1을 0.16–0.55로 유지한 반면, 정규식은 0.00–0.34로 급락했습니다. 그러나 최고의 CORD 결과(0.5527)는 최고의 영어 결과(0.6171)에 여전히 미치지 못하며, 이는 더 어려운 문자 체계와 열화된 OCR 기반을 반영합니다. 영어 영수증용으로 작성된 규칙은 본질적으로 작동을 멈췄고, LLM은 대신 우아하게 성능이 저하되었습니다.

방법론 및 출처

프로토콜

이 페이지는 ImageToTable.ai 오픈소스 OCR 벤치마크의 필드 추출 비교 결과를 보고합니다 — 이는 제3자 주장을 조사한 것이 아니라 독립적이고 재현 가능한 실험 실행입니다. 각 쌍의 파이프라인은 다음과 같습니다: OCR 엔진이 영수증 이미지에서 텍스트를 생성합니다; 그런 다음 해당 텍스트를 두 번 추출합니다 — 한 번은 고정된 정규식 패턴 세트로, 다른 한 번은 LLM 후처리기로 — 그리고 두 출력 모두 동일한 기준 필드에 대해 점수가 매겨집니다. LLM 후처리기는 비교 CSV의 llm_model 열인 deepseek-v4-flash이며, 결정론적 출력을 위해 온도 0으로 실행됩니다. 361개의 SROIE와 100개의 CORD 샘플이 모두 성공적으로 완료되었습니다(llm_ok_count = 361 / 100).

런타임 환경

하드웨어: 모든 GPU 실행은 NVIDIA RTX 4090(24GB)에서 이루어졌습니다. PyTorch 기반 엔진(docTR, EasyOCR, Docling)은 PyTorch 2.8.0+cu128(CUDA 12.8)로 실행되었고; Tesseract는 CPU 전용으로 실행되었습니다; vLLM으로 제공되는 엔진(Surya2, Unlimited-OCR, PaddleOCR-VL)은 vLLM 팟에서 실행되었습니다. 드라이버 및 Python 버전은 실행마다 약간 다르며, 비공개 실행 매니페스트에 정확히 기록되어 있습니다.
LLM 후처리기: API를 통한 deepseek-v4-flash, 온도 0.
측정 모드: warm_then_scored — 점수가 매겨지는 실행 전에 고정된 워밍업 패스가 선행되므로 지연 시간 수치는 정상 상태입니다.
데이터셋: SROIE 2019 테스트 — 361개의 영어 영수증, 단일 필드, CC-BY-4.0; CORD v2 테스트 — 100개의 인도네시아 영수증, 중첩 필드, CC-BY-4.0.
샘플 수: SROIE 361 / CORD 100, 모두 고정된 테스트 분할에서 추출.

두 후처리기가 사용한 상류 OCR 텍스트는 다음 엔진 버전에서 나왔습니다:

OCR 엔진	버전	백엔드
Tesseract	5.3.4	CPU
PaddleOCR	3.7.0	PaddlePaddle-GPU 3.3.1
EasyOCR	1.7.2	PyTorch
docTR	1.0.1	PyTorch
Docling	2.119.0	PyTorch
Surya2	0.22.1	vLLM
Unlimited-OCR	baidu/Unlimited-OCR	vLLM
PaddleOCR-VL	1.6	vLLM

전체 실행별 재현성 지문은 공개 저장소의 results/manifests/ 아래에 있는 벤치마크의 비공개 실행 매니페스트에 있습니다. 각 매니페스트는 다음을 공개합니다: 실행 ID, 모델 + 버전, 실행 스크립트 해시(SHA-256), GPU 모델/드라이버/VRAM, torch/CUDA/torchvision/torchaudio 버전, Python 버전, pip-freeze 해시, 비용 메타데이터, 측정 모드, 아티팩트 해시.

지표 정의

필드 값 F1: 추출된 필드 값에 대한 정밀도와 재현율의 조화 평균. 정규식 후처리를 사용합니다 — 전통적인 OCR + 규칙 기반 KIE 접근 방식입니다. 열: regex_field_value_f1.
필드 값 F1: LLM 후처리기의 출력에 대해 동일한 지표를 계산한 것입니다 — OCR + LLM 후처리 접근 방식입니다. 열: llm_field_value_f1. 이 두 접근 방식은 서로 다른 파이프라인이며, 절대 혼합되지 않습니다.
필드 값 정확도: 추출된 필드 값이 ground truth와 정확히 일치하는 비율 (regex_field_value_accuracy / llm_field_value_accuracy).
문서-필드-정확: 모든 대상 필드가 정확히 일치한 문서의 비율 (regex_document_fields_exact / llm_document_fields_exact).
CER/WER (컨텍스트 전용): 원본 OCR 텍스트의 문자/단어 오류율. 이 페이지에서는 Tesseract의 LLM 상한선을 설명하기 위해서만 사용됩니다.

아티팩트 접근

field_method_comparison.csv (GitHub raw). 16행 = 8개 모델 × 2개 데이터셋; 열: model, dataset, llm_model (= deepseek-v4-flash), regex/llm 필드 F1 + 정확도, document-fields-exact, llm_median_latency_ms, llm_prompt_tokens, llm_completion_tokens. 이 페이지의 모든 필드-F1 및 정확도 수치는 이 파일의 한 행에서 추적할 수 있습니다.
summary_metrics.csv (GitHub raw). 모델 × 데이터셋별 CER/WER. Tesseract 상한선 설명 (tesseract/cord_v2 cer 0.9523) 및 docTR의 SROIE CER 0.1971에 사용되었습니다.
ImageToTableai/benchmark-ocr 저장소. 결과 CSV, 실행 매니페스트 및 재현을 위한 데이터셋 샘플 목록을 호스팅하는 공개 저장소입니다.
results/manifests/ (GitHub). 게시된 각 실행에 대한 편집된 manifest.json 파일. 위에 나열된 실행별 환경 지문 및 아티팩트 해시가 포함되어 있습니다.
Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). SROIE 데이터셋 정의 및 라이선스.
Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2019). CORD v2 데이터셋 정의 및 라이선스.

한계점

문서 범위: 영수증만 해당 (SROIE + CORD). 추가 테스트 없이는 청구서, 양식, 긴 문서에는 일반화되지 않습니다.
표본 크기: 영어 361건 + 인도네시아어 100건의 영수증. 필드 F1은 말뭉치 구성에 민감하며, 수백 분의 일 수준의 단일 지점 차이는 노이즈로 간주하십시오.
단일 LLM 모델: 모든 LLM 행은 deepseek-v4-flash를 사용합니다. 다른 LLM은 다른 절대 수치를 생성할 것이며, 정규식 대비 LLM 순위는 경계에서 변동될 수 있습니다.
CORD 기준 데이터 주의사항: CORD gt_text에는 어노테이션 구조와 VLM 정규화 차이가 포함되어 있으므로, 모든 엔진에 대해 CORD의 원시 CER은 체계적으로 높게 나타납니다. 필드별 지표가 공정한 비교 기준이며, CER은 여기서 Tesseract 설명 목적으로만 사용됩니다.
지연 시간은 실시간 추출 지연이 아닙니다: llm_median_latency_ms는 필드별 조회가 아닌 전체 OCR 텍스트 → LLM 필드 추출 호출을 포함하며, OCR 시간 자체는 포함하지 않습니다.
정규식 튜닝: 정규식 패턴은 데이터셋당 한 번 작성된 고정 세트입니다. 벤더별로 심하게 튜닝된 정규식 라이브러리는 자체 형식에서 더 높은 점수를 얻을 수 있지만, LLM이 제거하는 유지보수 부담을 대가로 합니다.

관련 읽을거리: OCR 정확도 주장을 읽는 방법

영수증 필드 추출: Regex vs LLM자체 벤치마크 결과 (2026)