마지막 검토: 2026-08-18 · 실행 등급: 공식 · 1차 벤치마크 · 8개 엔진 × 2개 영수증 데이터셋

범위 진술: 메커니즘은 영수증에서 1차 벤치마크 데이터를 사용하여 설명됩니다. ~76%/~18%/~10% CER 분해는 프로토콜 노트 기반 추정치이며 CSV 열이 아닙니다. CORD는 SROIE 순위에 절대 병합되지 않습니다 — 언어가 다르고 정답 구조가 다릅니다.

문자 오류율(CER)은 정확한 문자 매칭 알고리즘이지 품질 측정기가 아닙니다: 정답과 다른 모든 문자에 대해 오류 하나를 부과합니다. 이번 벤치마크에서, 그 점수 매기기 규칙 자체만으로 — 실제 오독이 발생하기도 전에 — 엔진들이 순위의 상위와 하위를 오가게 됩니다: Unlimited-OCR는 동일한 361개 SROIE 영수증에서 최악의 CER(0.6552)과 최고의 정규식 필드 F1(0.3376)을 기록하는 반면, docTR는 2위의 CER(0.1971)과 최악의 필드 F1(0.0766)을 기록합니다.

작가들이 가장 자주 필요로 하는 세 가지 수치: VLM의 SROIE CER 예산 중 ~18%가 대소문자 대체만으로 차지합니다 — TAN CHAY YEE를 tan chay yee로 접는 것은 필드 값이 올바르더라도 오류로 점수를 매깁니다; 1.0805, PaddleOCR-VL의 CORD CER — 8개 엔진 중 최악으로, CORD의 구조가 풍부한 정답의 산물인 반면, its CORD 필드 F1은 0.3412로 벤치마크 최고입니다; 그리고 0.6552 / 0.3376 CER 최악 / 필드 최고의 역전은 CER만으로 순위를 매길 때 잘못된 승자를 선택하게 만듭니다.

CER는 정확한 일치 기반 점수 알고리즘이지, 품질 측정기가 아닙니다

CER는 인식된 텍스트와 정답 텍스트 사이의 레벤슈타인 편집 거리입니다 — 하나를 다른 것으로 변환하는 데 필요한 최소 문자 삽입, 삭제, 대체 횟수를 정답 긴이로 나눈 값입니다. 이는 차이를 셀 뿐, 오독과 합법적인 재포맷을 구별할 수 없습니다. 엔진의 출력 관례가 정답과 다를 때 — 대소문자, 구분자, 줄 순서 — CER은 오독과 전혀 다른 행위에 대해 오류를 부과합니다.

전통적인 OCR 엔진(Tesseract, PaddleOCR, EasyOCR, docTR)은 원래 대소문자와 줄 배치를 보존하는 원시 문자 스트림을 출력하므로, 출력 관례가 정답에 가깝고 CER은 실제 읽기 오류에 가까운 것을 측정합니다. 문서 파싱 VLM(Surya2, Unlimited-OCR, PaddleOCR-VL)은 이해한 텍스트를 출력합니다: 이들은 대소문자 통합, 라벨/값 병합, 줄 재정렬을 적용합니다 — 이는 스캐너가 아닌 독자의 출력 관례입니다. 모든 대소문자 통합과 병합된 줄은, 기반 필드 값이 올바르더라도 편집 거리 패널티가 됩니다.

벤치마크의 프로토콜 분석에 따르면, 공개된 SROIE 예측에서 VLM의 원시 CER 예산은 대략 ~76%가 정답과 동일한 문자, ~18%가 대소문자 대체, ~10%가 줄 병합/구분자 누락으로 분해됩니다 — 실제 필드 값은 올바릅니다. 이 분해는 벤치마크 분석 노트에서 도출된 프로토콜 기반 추정치이며, CSV 열이 아닙니다; 이 분할은 방향성을 나타내지, 정확하지는 않습니다. 중요한 것은 방향성입니다: 대소문자 통합만으로도 깨끗한 영수증에서 VLM의 “나쁜” CER의 상당 부분을 설명할 수 있습니다.

두 개의 CSV 행이 분해 없이 메커니즘을 명확히 보여줍니다. Unlimited-OCR는 SROIE에서 CER 0.6552이지만 WER 0.4779를 기록합니다 — 문자는 망가져 보이지만 단어는 살아남는데, 이는 대소문자 통합이 단어를 깨뜨리지 않고 문자를 대체하기 때문입니다. 그리고 정규화를 가장 적게 하는 VLM인 Surya2는 CER 0.1915를 기록합니다 — 이는 전체 8엔진 실행에서 가장 낮은 원시 CER로, 강력한 전통 엔진과 구별할 수 없습니다. CER 열이 주로 측정하는 것은 VLM의 읽기 능력이 아닌 VLM의 출력 관례입니다.

증거는 역순에 있다: 문자 오류율과 필드 F1은 불일치한다

벤치마크의 문자 오류율 순위와 필드 추출 순위는 실질적으로 불일치합니다. SROIE 문자 오류율로 여덟 엔진을 순위를 매기면 승자는 Surya2(0.1915)입니다. 정규식 필드 F1 — 실제 프로덕션 파이프라인이 사용하는 것에 근접하는 지표 — 으로 순위를 매기면 승자는 Unlimited-OCR(0.3376)이며, 이 엔진은 문자 오류율 순위에서 꼴찌입니다. 두 열 중 하나는 하위 시스템이 실제로 사용하는 것을 측정하지 못하고 있습니다.

필드 F1은 추출된 필드 값에 대한 정밀도와 재현율의 조화 평균입니다. 필드는 이진 단위입니다 — 일치하거나 실패합니다. 정규식 열은 모든 엔진의 텍스트에 동일한 고정 패턴 세트를 적용하므로, 유일한 변수는 엔진의 출력입니다. 아래 표는 361개 영수증에서 각 엔진의 문자 오류율과 정규식 필드 F1을 쌍으로 보여주며, 각 엔진의 두 지표별 순위도 포함되어 있습니다.

출처: summary_metrics.csv — cer 및 field_f1_regex 열, sroie_2019 행. 두 시리즈는 크기 면에서 서로 비교할 수 없지만, 순위는 불일치하며, 이것이 핵심입니다.

모델	유형	문자 오류율	단어 오류율	정규식 필드 F1	문자 오류율 순위	필드 F1 순위	출처
Surya2	문서 파싱 VLM	0.1915	0.2735	0.3183	1	4	summary_metrics.csv · surya2/sroie_2019 행
docTR	기존 OCR (GPU)	0.1971	0.3199	0.0766	2	8	summary_metrics.csv · doctr/sroie_2019 행
PaddleOCR	기존 OCR (GPU)	0.2045	0.3256	0.3254	3	3	summary_metrics.csv · paddleocr/sroie_2019 행
EasyOCR	기존 OCR (GPU)	0.2833	0.6158	0.1477	4	7	summary_metrics.csv · easyocr/sroie_2019 행
Tesseract	기존 OCR (CPU)	0.3347	0.5591	0.2335	5	5	summary_metrics.csv · tesseract/sroie_2019 행
PaddleOCR-VL	문서 파싱 VLM	0.3370	0.6462	0.3368	6	2	summary_metrics.csv · paddleocr_vl_vllm/sroie_2019 행
Docling	파이프라인 파서	0.5909	0.7596	0.2237	7	6	summary_metrics.csv · docling/sroie_2019 행
Unlimited-OCR	문서 파싱 VLM	0.6552	0.4779	0.3376	8	1	summary_metrics.csv · unlimited_ocr/sroie_2019 행

표: summary_metrics.csv — cer / wer / field_f1_regex 열, sroie_2019 행. 순위는 이 표의 8개 행 내에서 계산됨. 이 지표들은 postprocessed_sroie_receipt_regex_* 지표입니다: 각 엔진의 OCR 텍스트에 고정 패턴을 적용한 것이며, 네이티브 구조화 출력이 아닙니다. Tesseract는 CPU 전용(compute_type=cpu)으로 실행되었습니다.

두 가지 역전 쌍을 명확히 읽어보세요. Unlimited-OCR: 최악의 CER (0.6552), 최고의 필드 F1 (0.3376) — 원본 OCR 지표로는 최하위로 평가된 엔진이 필드 관점에서는 1위를 차지합니다. docTR: 2위 CER (0.1971), 최악의 필드 F1 (0.0766) — 텍스트는 완벽하지만 필드는 실패입니다. PaddleOCR-VL도 경계선에서 역전됩니다. 반면, 두 엔진은 순위가 일치하는데, 이들은 모두 텍스트 출력 관행이 CER가 평가하도록 설계된 대로인 전통적인 엔진입니다. CER만으로 엔진을 순위 매기면 실제 프로덕션에서 사용하는 기준으로 순위를 매길 때와 다른 승자가 나옵니다 — 이 역전은 이상 현상이 아니라 이를 증명하는 것입니다.

필드 지표가 신뢰할 수 있는 교차 패밀리 관점입니다

각 엔진의 원본 텍스트를 동일한 LLM 필드 추출 후처리기(deepseek-v4-flash, temperature 0)에 통과시키면, 사용 가능한 OCR 텍스트를 가진 6개 엔진은 0.57–0.62 필드 F1로 수렴합니다 — CER 순위에서 거대해 보이던 VLM 대 전통적 패밀리 경계가 거의 사라집니다. 두 엔진이 이 범위 아래로 떨어집니다: EasyOCR은 0.3717, Tesseract는 0.4389입니다. 필드 지표는 실제로 중요한 것 — 후속 필드 복원 — 을 기준으로 엔진을 구분하며, 이는 패밀리 경계를 넘어 일관되게 작동합니다.

이는 위의 CER 표와 동일한 엔진 세트를 필드 차원에서만 다시 평가한 것입니다: Unlimited-OCR과 docTR 사이의 CER 역전은 사라졌습니다. 왜냐하면 파이프라인이 실제로 사용하는 것은 필드 값 복원이기 때문입니다. 메커니즘은 후처리기가 CER이 처벌했던 출력 관행 차이를 흡수한다는 것입니다 — 대소문자 통합되고 라벨/값 병합된 텍스트를 읽어 값을 추출합니다. 여기서의 LLM 필드 F1은 벤치마크의 방법 비교에서 `llm_field_value_f1` 열이며, 각 행에 LLM 모델이 기록되어 있습니다.

모델	유형	CER	LLM 필드 F1	수렴 대역 내 (0.57–0.62)	출처
docTR	기존 OCR (GPU)	0.1971	0.6171	예 — 최고	field_method_comparison.csv · llm_field_value_f1, doctr/sroie_2019 행
Surya2	문서 파싱 VLM	0.1915	0.6139	예	field_method_comparison.csv · llm_field_value_f1, surya2/sroie_2019 행
Unlimited-OCR	문서 파싱 VLM	0.6552	0.6054	예	field_method_comparison.csv · llm_field_value_f1, unlimited_ocr/sroie_2019 행
PaddleOCR-VL	문서 파싱 VLM	0.3370	0.5921	예	field_method_comparison.csv · llm_field_value_f1, paddleocr_vl_vllm/sroie_2019 행
PaddleOCR	기존 OCR (GPU)	0.2045	0.5810	예	field_method_comparison.csv · llm_field_value_f1, paddleocr/sroie_2019 행
Docling	파이프라인 파서	0.5909	0.5685	예 — 대역 경계	field_method_comparison.csv · llm_field_value_f1, docling/sroie_2019 행
Tesseract	기존 OCR (CPU)	0.3347	0.4389	아니오 — 미달	field_method_comparison.csv · llm_field_value_f1, tesseract/sroie_2019 행
EasyOCR	기존 OCR (GPU)	0.2833	0.3717	아니오 — 미달	field_method_comparison.csv · llm_field_value_f1, easyocr/sroie_2019 행

표: field_method_comparison.csv — llm_field_value_f1 열, sroie_2019 행, llm_model=deepseek-v4-flash. CER 열은 교차 참조용으로 summary_metrics.csv에서 반복되었습니다. "수렴 대역"은 사용 가능한 텍스트를 가진 6개 엔진의 관찰된 0.5685–0.6171 범위이며, 대역 미달의 두 행은 엔진 분류가 아닌 관찰 결과로 기술되었습니다.

CORD는 두 번째 인플레이션 레이어를 추가합니다: 정답 구조

CORD가 공개한 정답 텍스트(gt_text)는 순수한 가시 텍스트 대신 주석 구조 — 필드 레이블, 메뉴 항목, 좌표 —를 포함하고 있습니다. CER은 해당 구조적으로 강화된 문자열에 대해 편집 거리를 계산하므로, 모든 엔진의 CORD CER는 읽기 오류가 고려되기 전에 체계적으로 인플레이션됩니다. 결과: 모든 8개 엔진이 CORD CER 0.90–1.08 범위에 집중됩니다 — 이는 텍스트 품질에 대해 거의 아무것도 말해주지 않는, 쓸모없을 정도로 압축된 범위입니다.

극단적인 사례는 PaddleOCR-VL의 1.0805 CORD CER로, 8개 엔진 중 가장 나쁩니다 — 이는 텍스트 품질에 대한 읽기가 아니라, 가장 깔끔하고 짧은 출력에 대해 가장 크게 작용하는 구조적 인플레이션 때문이며, 이 출력은 CORD의 구조가 포함된 정답에 대해 가장 큰 상대적 편집 거리를 갖기 때문입니다. 필드 관점에서 볼 때, 동일한 엔진이 벤치마크의 최고 CORD 정규식 필드 F1 (0.3412)을 기록합니다. CORD CER는 구조적으로 사용 불가능합니다. 필드 지표만이 공정한 CORD 관점이며, 이 벤치마크에서는 SROIE 순위와 엄격히 분리되어 유지됩니다.

출처: summary_metrics.csv — cer 및 field_f1_regex 열, cord_v2 행. CORD CER는 엔진 계열 간 또는 엔진 간에 비교할 수 없습니다 — 정답이 주석 구조를 포함하고 있으므로, CER은 가시 텍스트가 아닌 구조적으로 강화된 문자열까지의 거리를 측정합니다.

모델	유형	CORD 문자 오류율	정규식 필드 F1	출처
PaddleOCR-VL	문서 파싱 VLM	1.0805	0.3412	summary_metrics.csv · paddleocr_vl_vllm/cord_v2 행
Surya2	문서 파싱 VLM	0.8959	0.2458	summary_metrics.csv · surya2/cord_v2 행
Unlimited-OCR	문서 파싱 VLM	0.9224	0.1079	summary_metrics.csv · unlimited_ocr/cord_v2 행
Tesseract	기존 OCR (CPU)	0.9523	0.0752	summary_metrics.csv · tesseract/cord_v2 행
Docling	파이프라인 파서	0.9219	0.0612	summary_metrics.csv · docling/cord_v2 행
PaddleOCR	기존 OCR (GPU)	0.9083	0.0154	summary_metrics.csv · paddleocr/cord_v2 행
EasyOCR	기존 OCR (GPU)	0.9185	0.0067	summary_metrics.csv · easyocr/cord_v2 행
docTR	기존 OCR (GPU)	0.9101	0.0000	summary_metrics.csv · doctr/cord_v2 행

표: summary_metrics.csv — cer / field_f1_regex 열, cord_v2 행. CORD는 어떤 SROIE 순위에도 포함되지 않습니다: 정답 구조가 모든 엔진의 문자 오류율을 부풀리며, 정규식 패턴은 영문 형식용으로 작성되었습니다. 필드 지표만이 CORD를 공정하게 평가하는 기준입니다. 필드 F1 기준으로 정렬했으며, 문자 오류율 기준이 아닙니다 — 문자 오류율 열에는 정렬 신호가 없기 때문입니다.

필드 관점은 CORD 표를 완전히 뒤집습니다. 벤치마크에서 가장 높은 CORD 문자 오류율을 보인 엔진(PaddleOCR-VL, 1.0805)이 가장 높은 CORD 필드 F1(0.3412)을 기록하며, docTR의 CORD 필드 F1은 0.0000으로 사실상 아무것도 추출하지 못했지만, CORD 문자 오류율(0.9101)은 중간 수준으로 아무런 정보도 전달하지 못합니다. CORD에서 필드 지표 없이 문자 오류율만 공개하는 것은 단순히 정보가 부족한 것이 아닙니다. 엔진을 잘못된 순서로 평가하게 됩니다.

CER가 실제로 적합한 지표인 경우

CER는 여전히 실제적인 것을 측정합니다 — 정확한 문자 재현 — 그리고 하위 소비자가 그대로의 텍스트가 아닌 필드가 필요할 때는 적합한 지표입니다. 이 페이지의 결론은 “CER는 VLM 스타일 출력의 교차 패밀리 비교에서 오해를 유발합니다,”는 것이지 “CER는 항상 잘못되었습니다”가 아닙니다.

원시 OCR 패밀리 내에서 CER는 그 가치를 유지합니다. 전통적인 엔진은 대소문자와 레이아웃을 보존한 원시 텍스트를 출력하므로, CER는 진정한 읽기 품질을 측정합니다: 이 벤치마크의 전통 엔진 CER 열은 VLM보다 필드 성능을 훨씬 더 밀접하게 추적합니다.
그대로의 텍스트 사용 사례. 정확한 일치 하위 소비자 — 리터럴 문자열을 찾아야 하는 전문 검색, 문서의 문자를 재생하는 감사 추적, 또는 필수 문자 시퀀스에 대한 합격/불합격 검사 —는 필드가 아닌 문자를 소비합니다. 이를 위해 정확한 문자 재현(CER)은 충실한 측정치이며, 필드 F1은 잘못된 관점입니다.
발행 규칙-of-thumb. CER 수치를 발행할 때, 엔진의 출력 관례와 정답 구성을 모두 명시하십시오. 둘 중 하나라도 알 수 없으면, 해당 수치는 엔진이나 데이터셋 간에 이식할 수 없습니다.
이 벤치마크의 경계 규칙. CER는 원시 OCR 패밀리 내에서는 공정하지만, 전통 OCR / 문서 파싱 VLM 경계를 넘어선 비교에서는 공정하지 않습니다; 필드 수준 F1은 양쪽에서 공정합니다. 동일 패밀리 원시 텍스트 품질에는 CER를, 교차 패밀리 비교에는 필드 F1을 사용하십시오 — 그리고 VLM 행에 대해서는 항상 분해 주의 사항을 보고하십시오.

자주 묻는 질문

OCR 엔진과 VLM을 비교할 때 CER이 왜 오해의 소지가 있나요?

CER은 정확한 문자 편집 거리 점수이기 때문입니다. 문서 파싱 VLM은 의도적으로 문자를 정확히 재현하지 않습니다 — 대소문자를 통합하고, 라벨/값 줄을 병합하며, 텍스트를 재정렬합니다. 이러한 모든 정규화는 필드 값이 올바르더라도 오류로 점수를 매깁니다. 이 벤치마크에서 Unlimited-OCR은 동일한 361개 영수증에서 최악의 SROIE CER(0.6552)를 기록하면서도 최고의 정규식 필드 F1(0.3376)을 달성했습니다 — CER 순위와 필드 순위가 서로 다른 승자를 선택합니다.

CER은 여전히 유용한 OCR 지표인가요?

네 — 원시 OCR 계열 내에서 그리고 정확한 텍스트 소비자에게는 유용합니다. 기존 엔진(Tesseract, PaddleOCR, EasyOCR, docTR)은 CER이 공정하게 측정하는 원시 문자 스트림을 출력합니다. 이 벤치마크에서 이들의 SROIE CER는 0.1971–0.3347 범위이며 필드 성능과 일치합니다. CER은 엔진이 출력을 정규화할 때 또는 정답이 보이는 텍스트가 아닌 구조를 포함할 때(CORD) 잘못된 지표입니다.

VLM OCR 모델의 문자 오류율이 높은 이유는 무엇인가요?

주로 읽기 능력이 아닌 출력 관례 때문입니다. 이 벤치마크의 프로토콜 분석에 따르면, VLM의 SROIE CER 예산 중 약 ~18%는 대소문자 변환, ~10%는 줄 병합/구분자 누락에 기인합니다 — 반면 필드 값 자체는 올바릅니다. Unlimited-OCR의 CER 0.6552 대비 WER 0.4779는 특징을 보여줍니다: 문자는 통합되지만 단어는 살아남습니다.

OCR 엔진과 문서 파싱 VLM을 비교하는 데 가장 적합한 지표는 무엇인가요?

필드 수준 F1 — 순수 OCR 파이프라인의 경우 정규식 후처리, 두 계열 모두의 경우 LLM 후처리를 적용합니다. SROIE에서 LLM 필드 F1은 계열에 관계없이 6개 엔진을 0.57–0.62로 수렴시킵니다. 또한 정규식 필드 F1은 CORD 테이블을 합리적으로 순위 매기는 유일한 지표이며, 여기서 PaddleOCR-VL의 0.3412가 벤치마크 최고 성능입니다. 항상 숫자와 함께 후처리기와 출력 규칙을 명시해야 합니다.

PaddleOCR-VL의 CER이 CORD에서 왜 그렇게 높은데 필드 F1은 가장 뛰어난가요?

CORD의 정답 데이터에는 순수한 가시 텍스트 대신 주석 구조가 포함되어 있기 때문입니다. 그리고 PaddleOCR-VL의 출력이 가장 깔끔하고 — 가장 짧고 가장 정규화되어 — 구조적으로 강화된 문자열과의 편집 거리가 가장 큽니다. 필드 수준 지표에서는 동일한 텍스트가 인도네시아 영수증 필드를 0.3412 필드 F1으로 추출하며, 이는 벤치마크 최고 성능입니다. CORD CER는 모든 엔진에서 구조적으로 사용 불가능합니다. 필드 수준 지표만이 CORD를 공정하게 비교할 수 있는 방법입니다.

대소문자 통합이란 무엇이며, 왜 CER을 부풀리나요?

대소문자 통합은 모든 텍스트를 하나의 대소문자로 정규화하는 것입니다 — TAN CHAY YEE가 tan chay yee가 됩니다. CER은 문자를 정확히 비교하므로, 값이 동일하더라도 정답의 대문자에 대해 모든 통합된 문자가 치오로 간주됩니다. 이번 벤치마크의 프로토콜 분석에서 대소문자 치오는 VLM의 SROIE CER 예산에서 약 18%를 차지합니다 — 이것이 VLM이 영수증을 완벽하게 읽고도 실패한 모델처럼 보이는 CER을 보고할 수 있는 이유입니다.

OCR 엔진을 비교할 때 CER과 필드 F1 중 어떤 것을 사용해야 하나요?

전통적인 OCR과 VLM 엔진을 모두 포함하는 비교에서는 필드 F1을 사용해야 합니다. 파이프라인이 문자 스트림이 아닌 필드를 사용하기 때문이며, CER은 정규화된 VLM 출력과 구조가 보강된 정답 데이터에 대해 체계적으로 높게 측정되기 때문입니다. CER은 순수 OCR 엔진 간 비교나 후속 처리에서 정확한 텍스트가 필요한 경우에만 사용하세요. 이 벤치마크에서 두 지표는 크게 다르게 나타납니다. CER은 docTR을 2위, Unlimited-OCR을 8위로 평가하지만, 정규식 필드 F1은 docTR을 8위, Unlimited-OCR을 1위로 평가합니다.

이 CER 및 필드 F1 수치는 어디서 가져온 것인가요?

모든 테이블 수치는 자체 벤치마크의 공개된 results/summary_metrics.csv 또는 results/field_method_comparison.csv의 행으로, ImageToTableai/benchmark-ocr에 호스팅되어 있으며, 각 실행마다 모델 버전과 환경 지문을 기록한 manifest.json이 하나씩 있습니다. ~76%/~18%/~10% CER 분해는 벤치마크의 분석 노트에서 도출된 프로토콜 기반 추정치이며, CSV 열이 아닙니다. 데이터셋 정의는 아래에 인용된 SROIE 및 CORD 논문에서 가져왔습니다.

방법론 및 출처

프로토콜

이 페이지는 제3자 주장을 조사한 것이 아니라, 독립적이고 재현 가능한 벤치마크 실행의 지표 공정성 차원을 보고합니다. 고정된 테스트 분할만 사용합니다: SROIE 2019 테스트 및 CORD v2 테스트; 학습 분할은 평가되지 않았습니다. 8개 엔진이 파인튜닝 없이 기본 설정으로 실행되었으며, 고정된 프로토콜 reports/receipt_v1_official_protocol.md에 따랐습니다. 16개의 점수 매긴 실행이 모두 error_rate 0.0으로 완료되었습니다. 데이터는 2026년 8월에 수집되었습니다.

실행 환경

하드웨어: 모든 GPU는 단일 NVIDIA RTX 4090 (24 GB)에서 실행됩니다. Tesseract는 CPU 전용 (compute_type=cpu)으로 실행되었으며, 모든 테이블에 그렇게 표시됩니다.
엔진 및 버전: Tesseract 5.3.4, PaddleOCR 3.7.0, EasyOCR 1.7.2, docTR v1.0.1, Docling 2.119.0, Surya2 0.22.1, Unlimited-OCR vLLM-served, PaddleOCR-VL 1.6.
필드 후처리기: 정규식 필드 F1 = 각 엔진의 OCR 텍스트에 적용된 고정 sroie_receipt_regex/cord_receipt_regex 패턴; LLM 필드 F1 = 동일한 텍스트를 읽는 deepseek-v4-flash (temperature 0) (field_method_comparison.csv의 llm_model 열).

지표 정의

문자 오류율 (CER): 인식된 텍스트와 정답 텍스트 사이의 레벤슈타인 편집 거리 — 최소 삽입/삭제/대체 횟수를 정답 길이로 나눈 값. 낮을수록 좋습니다. 정확한 문자 재현만 측정합니다.
단어 오류율 (WER): 단어 단위의 동일한 편집 거리 로직 — 단어는 단일 대소문자 대체를 견디므로, CER/WER 차이는 단어를 깨뜨리지 않고 문자를 변경하는 정규화를 보여줍니다.
필드 값 F1: 추출된 필드 값에 대한 정밀도와 재현율의 조화 평균; 필드는 정답과 정확히 일치할 때만 일치합니다. 정규식 및 LLM 열은 동일한 OCR 텍스트에 대한 두 가지 후처리기이며, 절대 혼합되지 않습니다.
출력 규칙: 엔진이 텍스트를 포맷하는 방식. 기존 엔진은 이를 보존하지만, 문서 파싱 VLM은 이를 정규화합니다 — 이 페이지가 측정하는 축입니다.
정답 구조: 참조 텍스트가 순수한 가시 텍스트(SROIE)인지, 아니면 주석 구조가 추가된 것(CORD gt_text)인지 여부. 후자는 모든 엔진의 CER을 증가시킵니다.

소스 목록

summary_metrics.csv (GitHub raw). 16행 = 8개 엔진 × 2개 영수증 데이터셋. 열에는 cer, wer, field_f1_regex, field_acc_regex, compute_type, error_rate가 포함됩니다. 이 페이지의 모든 CER/WER 및 정규식 필드 F1 수치는 이 파일의 행에서 추적되며, 파일/모델/데이터셋/지표 수준으로 인용됩니다.
field_method_comparison.csv (GitHub raw). 정규식 대비 LLM 필드 추출 비교 (llm_field_value_f1, llm_model=deepseek-v4-flash). LLM 필드 F1 테이블의 소스입니다.
ImageToTableai/benchmark-ocr 저장소. 결과 CSV, 비공개 실행 매니페스트, 고정된 프로토콜 (reports/receipt_v1_official_protocol.md), 재현을 위한 고정 샘플 목록을 호스팅하는 공개 저장소입니다.
results/manifests/ (GitHub). 모델 버전, 환경 지문 및 아티팩트 해시가 포함된, 게시된 각 실행에 대한 비공개 manifest.json 파일입니다.
receipt_v1_official_protocol.md. 고정된 실행 계약: 고정된 테스트 분할, 공식 등급, 워밍업 후 측정, CORD-vs-SROIE 분리 규칙. 이 페이지에 인용된 프로토콜 수준 규칙의 소스입니다.
벤치마크 프로토콜 분석 노트. VLM 정규화 메커니즘, CORD 정답 구조 메커니즘, SROIE CER 분해. 여기서는 명시적 라벨 “프로토콜 기반 추정치 — CSV 열이 아님”으로 인용됩니다. 이 분할은 방향성을 나타내며 정확한 수치가 아닙니다.
OCR-D 프로젝트 — 품질 보증 사양. 공식 CER 정의 / 전체 문자 수 및 WER 유사 지표. 공식 정의 기준점입니다.
Huang 외, “ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction” (2019). SROIE 2019 데이터셋 정의, 작업 구조, 라이선스 (CC-BY-4.0).
Park 외, “CORD: A Consolidated Receipt Dataset for Post-OCR Parsing” (2020). CORD 데이터셋 정의, 중첩 필드 스키마, 라이선스 (CC-BY-4.0).

한계점

분해 수치는 프로토콜 기반 추정치이며, 측정값이 아닙니다: ~76%/~18%/~10% SROIE CER 분해는 벤치마크의 프로토콜 분석 노트(WRITING_BRIEF §8.2)에서 나온 것이지, CSV 열에서 나온 것이 아닙니다. 방향성은 확실하지만, 정확한 백분율은 방향성 추정치로 취급해야 하며, 정확한 측정값으로 취급해서는 안 됩니다.
영수증만 해당: SROIE 및 CORD 영수증입니다. 송장, 양식, 표 또는 긴 문서에서의 동작은 측정되지 않았으며, 메커니즘은 일반화되지만 수치는 그렇지 않습니다.
단일 LLM 후처리기: 모든 LLM 필드 F1 수치는 temperature 0의 deepseek-v4-flash를 사용합니다. 다른 LLM은 절대 F1 값을 변화시키고 수렴 대역도 변화시킬 수 있지만, 대역 내 교차 패밀리 순서는 안정적인 신호입니다.
CER은 그대로 텍스트의 경우에 여전히 유효합니다: 결론은 VLM 스타일 출력의 교차 패밀리 비교에 한정됩니다. 원시 OCR 동일 패밀리 비교 및 정확한 문자 하위 처리의 경우, CER은 여전히 합법적인 지표입니다 — 이 페이지는 이러한 맥락에서의 CER에 대한 반론이 아닙니다.
CORD는 SROIE 순위에 병합되지 않았습니다: 언어가 다르고 정답 구조가 다릅니다. CORD는 벤치마크 프로토콜에 따라 필드 지표로만 비교됩니다.
버전 및 하드웨어 고정: 수치는 위에 나열된 2026년 8월 모델 버전 및 단일 GPU 티어(RTX 4090)에 해당합니다. 최신 릴리스는 CER과 필드 F1을 변화시키며, 한 자릿수 퍼센트 차이는 노이즈로 취급해야 합니다.
표본 크기: 361 + 100개 표본; 부트스트랩 신뢰 구간은 벤치마크의 평가 출력에 보고되지만 이 페이지에는 행별로 재현되지 않습니다.

문서 파싱 VLM에서 CER이 왜 오해를 유발하는가1차 벤치마크 데이터로 정량화 (2026)