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

SROIE 결과: 영어 영수증

영어 영수증에서 LLM은 8개 엔진 모두에 대해 regex를 능가합니다 — 가장 작은 향상은 1.76배(PaddleOCR-VL 0.337 → 0.592), 가장 큰 향상은 8.1배입니다. 또한 LLM은 모델 간 격차를 거의 없앱니다: Tesseract를 제외한 7개 엔진 중 6개가 0.05포인트 범위(0.569–0.617) 안에 들어오며, 이들의 regex 결과는 0.26포인트(0.077–0.338)에 걸쳐 분포했습니다.

SROIE(Scanned Receipt OCR and Information Extraction, ICDAR 2019)는 표준 영어 영수증 벤치마크입니다: 회사, 날짜, 주소, 합계의 네 가지 대상 필드가 있는 테스트 영수증 361개로 구성됩니다(Huang et al., 2019). 각 엔진은 공유 RTX 4090 설정에서 먼저 OCR 텍스트를 생성했습니다. 그 텍스트는 두 개의 병렬 후처리기에 입력되었습니다: 고정된 regex 패턴 세트와 구조화된 추출 프롬프트를 사용하는 LLM deepseek-v4-flash입니다. 둘 다 동일한 ground-truth 필드에 대해 점수를 매겼습니다. 차트는 엔진별 regex 필드 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).

출처: 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이 더 좋아져서가 아니라 — 실제로는 그렇지 않습니다 — regex가 붕괴하기 때문입니다: 8개 엔진 중 6개가 regex 필드 F1에서 10.8% 이하를 기록했고, 두 개(docTR 0.0%, EasyOCR 0.7%)는 거의 아무것도 복구하지 못했습니다. LLM은 여전히 Tesseract를 제외한 모든 엔진을 33.8% 이상으로 끌어올리며, 수작업 패턴이 따라갈 수 없는 언어와 레이아웃에서도 추출이 일반화됨을 입증합니다.

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

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

출처: 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포인트의 밴드로 전환합니다

regex에서는 어떤 엔진을 선택하느냐가 매우 중요했습니다. SROIE 필드 F1은 0.077(docTR)부터 0.338(Unlimited-OCR)까지 — 0.26포인트의 차이를 보였습니다. LLM에서는 Tesseract를 제외한 7개 엔진 중 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에서 Tesseract의 LLM 필드 F1은 0.1627(field_method_comparison.csv, tesseract/cord_v2, llm_field_value_f1)입니다. LLM은 읽을 수 없는 텍스트에서 회사 이름이나 합계를 추출할 수 없습니다. 모든 후처리기의 한계는 그 아래에 있는 OCR 기본 품질에 의해 결정되며, 이는 어떤 프롬프트 엔지니어링으로도 제거할 수 없는 제약입니다.

(c) docTR이 가장 큰 수혜자: regex 최하위에서 LLM 최상위로

docTR의 사례는 문제가 OCR이 아니라 후처리기였음을 가장 명확하게 보여줍니다. SROIE에서 docTR의 regex 필드 F1은 8개 엔진 중 가장 낮은 0.0766이었습니다 — 깨끗하고 정확한 텍스트가 천 단위 구분 기호가 있는 합계나 여러 줄 주소에 대한 regex 패턴과 일치하지 않았기 때문입니다. 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에서도 효과가 반복됩니다: regex에서는 0.0, LLM에서는 0.5500입니다.

Regex로 충분한 경우와 LLM을 사용해야 하는 경우

솔직한 트레이드오프는 "regex가 고장 났다"가 아니라 "영수증이 다양할 때 regex는 취약하다"입니다. Regex 후처리는 결정적이고, 무료이며, 즉각적입니다. LLM 후처리기는 토큰과 문서당 중앙값 1.8~2.4초를 추가합니다. 그 대가로 LLM은 SROIE에서 1.76~8.1배 더 많은 필드를 복구했습니다. 그리고 regex가 대부분의 엔진에서 거의 0으로 붕괴된 CORD에서는 LLM이 규칙 기반 추출로는 도달할 수 없었던 필드의 33.8~55.3%를 복구했습니다.

Regex로 충분한 경우: 문서가 소수의 안정적인 레이아웃에서 오고 필요한 필드가 거의 일정한 형식으로 나타난다면 regex가 올바른 도구입니다. 비용이 들지 않고, 마이크로초 단위로 실행되며, 실패도 예측 가능합니다. 벤치마크의 최저 사례가 이를 보여줍니다. 영수증에 맞춰진 regex를 가진 엔진은 SROIE에서 여전히 0.34의 필드 F1에 도달했습니다(Unlimited-OCR 0.3376, PaddleOCR-VL 0.3368).

LLM을 사용해야 하는 경우: 형식 변동이 들어오는 즉시 — 여러 통화, 지역별 날짜 형식, 여러 줄 주소, 다양한 스타일의 공급업체 이름, 또는 제2언어 — 각각이 패턴을 깨뜨립니다. 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 필드 추출이 regex 추출보다 더 정확한가요?

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

LLM 후처리 시 어떤 OCR 모델이 영수증 필드를 가장 잘 추출하나요?

SROIE에서 docTR이 필드 F1 0.6171로 가장 우수했습니다. 그러나 LLM이 개입하면 엔진 간 차이는 대부분 사라집니다. Tesseract를 제외한 7개 엔진 중 6개가 0.569에서 0.617 사이에 분포합니다. CORD에서는 PaddleOCR이 0.5527로 선두이며, docTR이 0.5500으로 근소한 차이로 2위입니다.

LLM을 사용해도 Tesseract가 뒤처지는 이유는 무엇인가요?

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은 regex 대비 필드 추출을 얼마나 개선하나요?

영어 영수증의 경우 엔진에 따라 1.76배에서 8.1배 사이이며, docTR에서 가장 큰 개선이 있었습니다. 인도네시아 영수증에서는 개선 폭이 훨씬 더 큽니다. PaddleOCR은 36배, docTR은 사실상 무한대(0.0 → 0.55)인데, 이는 regex가 거의 아무것도 복구하지 못했기 때문입니다.

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

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

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

이 벤치마크에서 LLM 호출은 문서당 중앙값 지연 시간 1.8–2.4초를 추가했으며, 전체 16개 그룹 실행은 약 1.33M 프롬프트 + 0.28M 완료 토큰을 소비했습니다. 이는 실시간 필드 추출 지연 시간이 아니며, 비동기 일괄 처리에는 적합하지만 대화형 조회에는 적합하지 않습니다.

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

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

방법론 및 출처

프로토콜

이 페이지는 ImageToTable.ai 오픈소스 OCR 벤치마크의 필드 추출 비교 결과를 보고합니다. 이는 독립적이고 재현 가능한 실험 실행이며, 제3자 주장에 대한 설문 조사가 아닙니다. 각 쌍의 파이프라인은 다음과 같습니다: OCR 엔진이 영수증 이미지에서 텍스트를 생성하고, 해당 텍스트는 고정된 regex 패턴 세트와 LLM 후처리기에 의해 각각 한 번씩 두 번 추출되며, 두 출력 모두 동일한 정답 필드에 대해 점수가 매겨집니다. LLM 후처리기는 deepseek-v4-flash이며, 결정적 출력을 위해 온도 0으로 실행됩니다. SROIE 361개 및 CORD 100개 샘플이 모두 성공적으로 완료되었습니다(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 텍스트는 다음 엔진 버전에서 생성되었습니다:

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

지표 정의

• 필드 값 F1: regex 후처리를 사용하여 추출된 필드 값의 정밀도와 재현율의 조화 평균 — 전통적인 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 상한을 설명하는 데만 사용됩니다.

산출물 접근

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

한계점

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

관련 참고 자료: 필드 정확도와 문자 정확도의 차이 · 영수증 OCR 정확도 · 문서 유형별 정확도 벤치마크

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