필드별 OCR 정확도:
전체 95%, 중요한 필드에서는 60%

"95% 정확도"의 문제

기존 OCR 엔진은 문자 수준 정확도, 즉 문서 이미지에서 개별 문자가 올바르게 인식된 비율로 자신을 평가합니다. Google이 유지 관리하는 오픈소스 벤치마크인 Tesseract 5는 깨끗한 인쇄 문서에서 95%의 문자 정확도를 달성합니다. ABBYY FineReader와 같은 엔터프라이즈 엔진은 실험실 조건에서 97–99%에 도달합니다. 이는 실제 테스트 세트에서 측정된 실제 수치입니다.

하지만 문자 정확도는 기업이 실제로 필요로 하는 것, 즉 완전하고 정확한 데이터 필드를 측정하기에는 부적절한 대용 지표입니다. 10자리 송장 번호에서 한 자리 숫자를 잘못 읽으면 전체 필드가 틀리게 됩니다. 1,000자 페이지에서 99%의 문자 정확도는 10자가 틀렸다는 뜻입니다. 그리고 그 10개의 잘못된 문자가 15개 대상 필드 중 3개에 포함된다면 필드 수준 정확도는 80%로 떨어집니다. TDWI는 실제 운영 중인 OCR 파이프라인에서 정확히 이런 시나리오를 문서화했습니다. 대시보드는 99%를 보고하지만, 추출된 비즈니스 필드 5개 중 1개에는 오류가 포함되어 있습니다.

상황을 더 악화시키는 것은 오류가 고르게 분포하지 않는다는 점입니다. 기존 OCR은 일부 필드 유형은 거의 항상 정확하게 처리합니다. 다른 필드 유형은 추출 자체가 무의미할 정도로 심각하게 실패합니다. 문제는 실패할 가능성이 가장 높은 필드(라인 항목의 금액, 손글씨 날짜, 표 구조 데이터)가 동시에 오류 수정 비용이 가장 높은 필드라는 점입니다.

인쇄된 날짜와 숫자 — OCR이 정확히 처리하는 부분

깨끗하고 인쇄된 고대비 문서에서 기존 OCR은 표준 위치에 있는 날짜와 달러 금액을 잘 처리합니다. 흰 배경에 11pt Arial로 인쇄된 "06/09/2026" 형식의 송장 날짜는 300 DPI에서 거의 완벽한 문자 정확도로 OCR 처리됩니다. 공급업체 송장에서 일관된 위치(오른쪽 하단)에 인쇄된 "$1,234.56" 총액은 잘 관리된 템플릿과 결합하면 안정적으로 추출됩니다.

이것이 OCR 공급업체가 인용하는 95–99% 수치를 만들어내는 필드입니다. 표준화된 글꼴, 예측 가능한 위치, 높은 대비라는 최상의 시나리오를 나타냅니다. 기존 OCR이 진정으로 작동하는 영역입니다.

형식이 다양해지면 균열이 나타나기 시작합니다. "09/06/2026"으로 작성된 날짜 — 6월 9일(미국)인가요, 9월 6일(영국)인가요? 기존 OCR은 차이를 감지할 메커니즘이 없습니다. 숫자를 충실히 읽을 뿐이며, 다운스트림 시스템은 추측하거나 미국 형식을 기본값으로 사용합니다. Python 기반 유럽 송장 파이프라인을 구축한 Reddit 사용자가 정확히 이 문제를 문서화했습니다: 이탈리아 송장은 31/12/2024를 사용하고, 독일 송장은 31.12.2024를 사용하며, 영국 송장은 31/12/2024를 사용합니다(동일한 구문, 다른 일/월 순서). 로케일 인식 정규화가 없으면 여러 국가의 송장 배치에서 추출된 날짜는 조용히 월 단위로 뒤섞입니다.

달러 금액에는 더 미묘한 실패 모드가 있습니다. 깨끗하게 인쇄된 "$1,234.56"은 잘 읽힙니다. 그러나 라인 항목 소계 "$1,234.56"이 송장 합계 "$1,234.56" 바로 위 행에 있는 경우 — 같은 숫자, 다른 의미 — 템플릿 기반 추출은 잘못된 것을 가져올 위험이 있습니다. 통화 기호 변형이 문제를 악화시킵니다: "€1.234,56"(유럽식 소수점 쉼표), "¥1,235"(일본 엔, 소수점 없음), 또는 통화 기호 없이 인쇄된 금액은 각각 다른 구문 분석 규칙을 트리거할 수 있습니다.

이름과 주소 — 문자는 정확, 맥락은 오류

표면적으로 이름과 주소는 OCR에 쉬워 보입니다. 읽을 수 있는 글꼴로 인쇄된 텍스트이며 특이한 글리프가 없습니다. 기존 OCR 엔진은 "John Smith" 문자열을 높은 신뢰도로 정확히 인식하고 "123 Main Street, Springfield, IL 62701" 주소도 거의 그만큼 잘 인식합니다.

실패는 문자 인식이 아닙니다. 필드 식별입니다. OCR은 "John Smith"를 페이지의 문자로 읽습니다. 그 텍스트가 고객 이름인지, 공급업체 이름인지, 배송처 연락처인지, 승인 관리자인지 알지 못합니다. 이러한 관계는 문서 레이아웃에 의해 정의됩니다 — John Smith는 "Bill To:", "Ship To:", 또는 "From:" 옆에 인쇄될 수 있습니다 — 그리고 기존 OCR의 하향식 문자 파이프라인은 레이아웃이 공급업체마다 다를 때 레이블을 관련 값에 연결할 수 없습니다.

이것이 템플릿 기반 시스템이 공급업체 레이아웃마다 별도의 좌표 맵을 요구하는 이유입니다. 템플릿은 "고객 이름이 픽셀 좌표 (450, 320)에 있다"고 말합니다. 새 공급업체가 고객 이름을 (520, 280)에 배치하면 템플릿은 빈 공간이나 잘못된 필드를 캡처합니다. 문제는 공급업체 수에 따라 확장됩니다: 20개 공급업체는 구축하고 유지 관리할 20개 템플릿을 의미합니다. 200개 공급업체는 템플릿 유지 관리가 전일제 작업이 됩니다.

이 실패의 비용은 종종 감지되지 않기 때문에 교활합니다. 잘못 매핑된 이름 필드는 형식 오류를 발생시키지 않습니다 — "Sarah Chen"은 고객 필드에 있든 공급업체 필드에 있든 유효한 이름입니다. 실수는 나중에 지불이 잘못된 엔터티로 가거나 보고서가 잘못된 상대방 아래에 거래를 그룹화할 때 표면화됩니다.

라인 항목 및 테이블 — OCR이 구조를 잃는 지점

테이블은 기존 OCR의 가장 큰 실패 지점이며, 거의 모든 비즈니스 문서에서 발견됩니다: 송장 라인 항목, 구매 주문 세부 정보, 경비 보고서 내역, 은행 거래 내역 행. 문제는 구조적인 것입니다. OCR 엔진은 읽기 순서(왼쪽에서 오른쪽, 위에서 아래)에 따라 문자를 선형 스트림으로 출력합니다. 3열 5행 테이블은 단일 텍스트 조각 시퀀스로 평탄화되며, 어떤 값이 어떤 헤더에 속하는지를 정의하는 열 경계는 사라집니다.

실제 벤치마크는 그 손실을 수치로 보여줍니다. 복잡한 테이블 레이아웃(병합된 셀, 중첩 헤더, 불규칙한 열 너비)에서 기존 OCR의 행 수준 정확도는 60–80%로 떨어집니다. "수량" 열에 들어가야 할 값이 "단가" 열에 들어가게 됩니다. 두 줄에 걸친 설명 행이 두 개의 별도 항목으로 분할됩니다. OCR이 열 구분선을 숫자 "1"과 혼동하면 소수점이 한 자리 이동합니다.

이것은 문자 인식 실패가 아닙니다. OCR 엔진은 개별 문자("5", "pcs", "$12.50")를 올바르게 읽지만, 다운스트림 시스템은 어떤 문자가 어떤 행과 열에 속하는지 재구성할 방법이 없습니다. 출력은 행별로 수동 재구성이 필요한 뒤섞인 텍스트 덩어리입니다.

템플릿 기반 접근 방식은 테이블 영역을 정의하여 이 문제를 해결하려고 합니다: "라인 항목 테이블은 Y=600에서 시작하여 Y=900에서 끝납니다." 그러나 테이블 높이는 라인 항목 수에 따라 달라집니다. 같은 공급업체의 한 줄 주문과 20줄 주문은 완전히 다른 길이의 테이블을 생성합니다. 템플릿의 고정 영역은 테이블의 일부만 캡처하거나, 더 나쁘게는 테이블 아래의 관련 없는 텍스트를 마지막 행으로 끌어옵니다. 테이블 데이터를 구조화된 스프레드시트로 추출하는 실용적인 가이드에서 핵심 변수는 추출 엔진이 테이블 구조를 의미론적으로 이해하는지 여부입니다 — 단순히 경계 상자 내의 문자를 읽는 것이 아니라.

체크박스, 스탬프, 혼합 콘텐츠 — 기존 OCR이 볼 수 없는 것들

기존 OCR이 실패하지 않는 것이 아니라 아예 감지조차 하지 못하는 문서 요소 범주가 있습니다. 이러한 요소는 출력을 생성하지 않거나, 쓰레기 문자를 생성하거나, 최악의 경우 인접한 텍스트 필드의 추출을 오염시킵니다.

체크박스. 체크된 박스(✓)와 체크되지 않은 박스(☐)는 사람의 눈에는 명확히 구분되지만, 기존 OCR 엔진에게는 둘 다 감지 임계값 근처의 저대비 블롭(blob)일 뿐입니다. OCR은 하나를 얼룩으로, 다른 하나를 "아무것도 아님"으로 등록하거나, 체크 표시를 "V", "7" 또는 임의의 글리프 같은 잘못된 문자로 읽을 수 있습니다. "이 박스는 체크됨"이라는 의도는 결코 포착되지 않습니다. 체크박스 필드에 의존하는 양식(보험 신청서, 검사 보고서, 규정 준수 체크리스트)은 OCR이 문서를 처리한 후 모든 체크박스를 100% 수동 검토해야 합니다.

스탬프와 워터마크. 송장 본문에 겹쳐진 "PAID" 스탬프, 계약서 페이지를 가로지르는 "CONFIDENTIAL" 워터마크, 또는 구매 주문서에 겹쳐진 빨간 회사 도장은 모두 동일한 실패를 만듭니다: 동일한 공간 영역을 차지하는 두 겹의 시각적 정보. 기존 OCR은 전경과 배경을 분리할 수 없습니다. 단일 노이즈 이미지 영역으로 보고 깨진 텍스트나 아무것도 생성하지 않습니다. 스탬프 텍스트와 기본 문서 텍스트 모두 읽을 수 없게 됩니다.

혼합 콘텐츠. 색상 배경에 인쇄된 텍스트, 어두운 헤더의 흰색 텍스트, 또는 음영 처리된 표 셀 안의 데이터 값은 모두 OCR 엔진이 필요로 하는 대비를 낮춥니다. "Invoice"라고 적힌 흰색 텍스트가 있는 진한 파란색 헤더 막대는 비어 있는 것으로 나올 수 있습니다 — 엔진의 이진화 단계가 전체 영역을 검은색으로 변환하고 흰색 텍스트를 완전히 잃어버리기 때문입니다. 밝은 회색 교대 행 밴드에 인쇄된 달러 금액은 회색 배경과 검은색 텍스트 사이의 대비가 엔진의 감도 곡선 아래로 떨어지면 문자가 누락될 수 있습니다.

이러한 실패는 표나 손글씨 문제와 근본적으로 다릅니다. 표는 OCR이 구조를 잃어버리기 때문에 실패합니다. 체크박스와 스탬프는 OCR이 처음부터 감지하지 못하기 때문에 실패합니다. 이 차이는 수정 작업에 중요합니다: 깨진 표는 후처리할 수 있지만, 추출된 적이 없는 것은 후처리할 수 없습니다.

손글씨 — 30–60%의 절벽

손글씨 텍스트는 OCR에서 가장 어려운 문제이며, 정확도 수치가 이를 반영합니다. 기존 OCR 엔진의 경우, 제한된 문자 상자에 인쇄체 손글씨는 약 75%의 문자 정확도를 달성합니다. 필기체 손글씨는 50% 이하로 떨어집니다. 이는 OCRSolutions가 실제 양식 처리 파이프라인에서 수행한 프로덕션 벤치마킹 데이터로, 깔끔하게 작성된 학습 샘플이 있는 실험실 조건이 아닙니다.

그 이유는 기계적입니다. 기존 OCR은 알려진 문자 모양 데이터베이스에 대해 개별 글리프를 패턴 매칭하는 방식으로 작동합니다. 인쇄된 "A"는 항상 인쇄된 "A"처럼 보입니다 — 약간의 글꼴 변형은 있지만 문자 골격은 일관됩니다. 손글씨 "A"는 일관된 골격이 없습니다. 기울기, 획 두께, 연결 획, 문자 간격, 기준선 변동은 작성자마다 다르며, 한 페이지 내에서 같은 작성자의 출력에서도 자주 다릅니다. 고정된 글리프 데이터베이스에 대한 패턴 매칭은 일치시킬 안정적인 패턴이 없을 때 실패합니다.

필기체는 모든 문제를 악화시킵니다. 문자가 연결되면 엔진은 한 문자가 끝나고 다음 문자가 시작되는 위치를 결정할 수 없습니다. 연결된 시퀀스 "tion"은 문자 데이터베이스의 어떤 것과도 일치하지 않는 단일 미분화 글리프가 됩니다. 필기체에 대한 일반적인 OCR 출력은 무작위 문자 문자열입니다 — "total"에 대해 "totl", "January"에 대해 "Jnury" — 엔진이 인쇄된 OCR을 신뢰할 수 있게 만드는 시각적 분할 단서 없이 개별 문자 모양을 추측하는 경우입니다.

실질적인 결과는 손글씨 구성 요소가 있는 모든 문서 워크플로우 — 서명된 배송 메모, 손으로 작성한 검사 양식, 연필로 적은 시간이 있는 종이 타임시트 — OCR이 완료된 후 수동 데이터 입력 단계를 만든다는 것입니다. 수동 입력을 없애기로 되어 있던 도구는 인쇄된 부분만 처리할 수 있습니다. 사람이 손으로 쓴 모든 것은 원본을 읽는 사람이 여전히 필사해야 합니다. 손글씨 양식을 디지털 텍스트로 변환과 같은 손글씨 문서를 구체적으로 다루는 워크플로우의 경우, 추출 엔진의 선택에 따라 전체 문서가 자동으로 처리되는지 아니면 인쇄된 헤더만 살아남는지가 결정됩니다.

AI 추출이 필드 유형별로 다르게 처리하는 이유

AI 기반 추출은 단일한 방식으로 이러한 모든 문제를 해결하지 않습니다. 각 필드 유형은 서로 다른 이유로 실패하며, AI 추출은 각 이유에 대해 서로 다른 기능으로 대응합니다 — 마치 정비사가 개스킷 누수와 전기 결함을 엔진 성능 저하라는 같은 증상이라도 다르게 고치는 것과 같습니다.

이름과 주소의 경우(맥락 문제): AI 비전 모델은 각 텍스트 조각이 문서 구조와 어떤 관계에서 어떤 의미를 갖는지 이해하면서 문서를 위에서 아래로 읽습니다. ImageToTable.ai 같은 도구에서 맞춤 열 추출을 구성할 때 — "고객 이름", "공급업체 주소", "송장 번호" 같은 필드 이름을 입력하면 — AI는 픽셀 좌표를 찾지 않습니다. 의미적 설명과 일치하는 값을 문서에서 스캔합니다. "Bill To:" 옆의 "John Smith"는 페이지의 어느 위치에 있든 고객 이름으로 매핑됩니다. 템플릿도, 좌표 맵도, 공급업체가 송장을 재설계할 때 재구축할 필요도 없습니다. 이것이 다중 공급업체 문서 배치에서 템플릿 기반 정확도 60%와 AI 추출 95%+ 사이의 격차를 줄이는 메커니즘입니다.

라인 항목과 테이블의 경우(구조 문제): AI 비전 모델은 페이지를 텍스트 스트림으로 평면화하는 대신 공간 레이아웃(열, 행, 병합 셀, 중첩 헤더)의 내부 표현을 유지합니다. 송장에서 라인 항목을 추출할 때 모델은 테이블 영역을 식별하고, 행과 열로 분할하며, 각 셀 값을 해당 열 헤더와 연결합니다. 출력은 기존 OCR이 버리는 테이블 구조를 보존합니다. 이를 통해 복잡한 레이아웃에서 행 수준 정확도가 60–80%에서 90%+ 범위로 향상됩니다.

체크박스와 혼합 콘텐츠의 경우(감지 문제): AI 비전 모델은 텍스트로 변환하기 전에 문서를 이미지로 처리합니다. 즉, 사람이 읽는 것처럼 체크박스, 도장, 워터마크를 주변 텍스트와 분리된 별개의 시각적 요소로 "볼" 수 있습니다. 체크된 박스는 임의의 글리프가 아닌 체크 표시로 인식됩니다. 텍스트 위에 겹쳐진 도장은 별도 레이어로 식별되며, 모델은 그 자리에 있어야 할 내용을 추론하여 아래 텍스트를 추출할 수 있습니다.

손글씨의 경우(패턴 실패): 수백만 개의 손글씨 샘플로 훈련된 AI 모델은 글리프 골격을 매칭하는 것이 아니라 획 패턴 뒤의 의도를 이해하여 문자를 인식합니다. 맥락이 개별 문자 인식이 놓치는 부분을 채웁니다. 모델이 송장 하단의 "Amount Due" 필드에서 "Totl"을 읽으면 "Total"로 해석합니다 — 갑자기 "a"를 인식했기 때문이 아니라, 해당 라벨과 위치에서 "Totl"은 반드시 "Total"이어야 하기 때문입니다. 이러한 맥락적 보정이 손글씨 정확도를 블록체 기준 50%에서 85–93%, 필기체 기준 75–85%로 끌어올립니다.

이러한 메커니즘 중 어느 것도 마법이 아닙니다. 각각은 극한 조건(심각하게 훼손된 스캔, 사람도 읽을 수 없는 손글씨, 눈에 보이는 열 경계가 없는 테이블)에서 실패합니다. 그러나 각 메커니즘은 기존 OCR이 해결책이 없는 특정 실패 모드를 겨냥합니다. 모든 필드 유형에 걸친 누적 효과는 문서 배치를 "수동 검토 40% 필요"에서 "수동 검토 5% 필요"로 바꿉니다.

직접 시도해 보면 그 차이가 즉시 눈에 보입니다. 아래 데모는 위에서 논의한 동일한 필드 유형(날짜, 달러 금액, 공급업체 이름, 라인 항목, 세금)이 포함된 송장을 AI 추출 파이프라인으로 처리합니다. 템플릿도, 좌표 매핑도, 원하는 열 이름을 입력하는 것 외의 사전 구성도 필요 없습니다.

OCR 감사 방법: 어떤 필드를 수정하는 데 비용이 가장 많이 드는가

현재 문서 처리 파이프라인을 운영 중이라면, 전체 정확도 비율이 아닌 필드 유형별 수정 비용을 측정하는 것이 가장 유용합니다. 95%의 전체 정확도는 대시보드에서 좋아 보입니다. 하지만 필드별 분석은 5%의 오류가 어디에 집중되어 있는지, 그리고 그 오류를 수정하는 데 실제로 얼마나 드는지를 알려줍니다.

현재 추출 파이프라인에서 필드 수준 정확도 감사를 실행하는 방법은 다음과 같습니다:

팀이 다중 공급업체 송장을 처리하는 기존 OCR 파이프라인에서 이 감사를 실행하면 일관된 패턴이 나타납니다. 라인 항목과 표가 가장 많은 수정 시간을 소비합니다. 오류 수가 가장 많아서가 아니라(손글씨가 그 범주에서 1위), 각 표 오류를 수정하려면 원본 문서에서 행과 열의 관계를 재구성해야 하기 때문입니다. 송장 500개에 각각 라인 항목 5개가 있고 표 오류율이 20%라면 수동으로 재구성해야 할 행이 500개입니다. 행당 2분이면 수정 시간이 16시간입니다. OCR이 자동으로 처리했어야 할 배치에 대해 이틀 이상의 작업 시간이 소요되는 셈입니다.

금액과 날짜는 원시 오류율이 낮음에도 불구하고 두 번째로 비용이 많이 드는 범주입니다. 놓친 오류의 결과가 크기 때문입니다. ERP로 유입된 잘못된 송장 합계는 필드 수준 수정으로 잡았을 때보다 훨씬 더 많은 비용이 드는 대사 불일치를 만듭니다. 이러한 필드 수준 실패가 전체 파이프라인 비효율로 어떻게 집계되는지에 대한 더 넓은 관점은 AI OCR 대 기존 OCR 정확도 벤치마크 분석과 AI 데이터 입력에 대한 정확도 기대치 설정 실용 가이드를 참조하세요.

어떤 필드 유형이 팀의 시간을 가장 많이 소모하는지 파악했다면, 다음 질문은 추출 엔진이 해당 필드 유형을 더 잘 처리할 수 있는지입니다. 병목이 테이블 구조라면, 의미론적 테이블 이해 기능이 없는 엔진으로 전환하는 것은 같은 문제를 다른 이름으로 바꾸는 것에 불과합니다. 병목이 손글씨나 체크박스라면, 이를 감지하지 못하는 엔진으로는 절대 개선되지 않습니다. 감사는 추출이 실패하고 있다는 사실뿐만 아니라 어디서 실패하는지도 알려줍니다. 그리고 그 위치가 업그레이드가 실제로 병목을 해결하는지, 아니면 같은 오류 로그의 로고만 바꾸는 것인지를 결정합니다.

FAQ

기존 OCR은 문서 유형에 따라 성능 차이가 있나요?

네. 기존 OCR은 레이아웃이 일관된 깨끗한 인쇄물, 단일 컬럼 텍스트 문서(계약서, 편지, 단일 출처의 표준화된 양식)에서 우수한 성능을 보입니다. 테이블, 손글씨, 혼합 글꼴, 낮은 대비, 출처별 레이아웃 차이가 있는 문서에서는 정확도가 떨어집니다. 그 격차는 미미한 수준이 아닙니다. 타자기로 작성된 편지는 필드 정확도 98%로 추출될 수 있지만, 라인 항목 테이블이 포함된 다중 공급업체 송장 배치는 60~85% 수준에 그칩니다.

더 높은 해상도로 스캔하면 기존 OCR 정확도를 개선할 수 있나요?

어느 정도는 가능합니다. 300 DPI(표준 권장 사양)로 스캔하면 150 DPI나 멀리서 찍은 스마트폰 사진보다 문자 인식이 개선됩니다. 하지만 해상도 개선은 문자 수준의 오류에만 영향을 미칩니다. 생산 파이프라인에서 수정 시간의 대부분을 차지하는 구조적 실패(테이블, 필드 매핑, 체크박스)에는 아무런 효과가 없습니다. 깨진 테이블의 더 선명한 이미지는 여전히 깨진 테이블일 뿐입니다.

어떤 추출 시스템에서도 가장 처리하기 어려운 필드 유형은 무엇인가요?

손글씨 — 특히 필기체 — 는 AI 기반 추출을 포함한 모든 시스템에서 가장 어려운 필드 유형입니다. 다양한 손글씨 데이터셋으로 학습된 AI 모델은 인쇄체에서 85~93%, 필기체에서 75~85%의 정확도를 달성합니다. 이는 기존 OCR의 30~60%보다 크게 개선된 수치이지만 99%는 아닙니다. 손글씨 필드가 중요한 데이터(결제 금액, 환자 이름, 규정 준수 확인 값)를 담당하는 워크플로우에서는 낮은 신뢰도의 추출 결과에 대한 인간 검토가 여전히 가장 안전한 방법입니다.

ImageToTable.ai가 손글씨 문서를 처리할 수 있나요?

ImageToTable.ai는 동일한 문서 내에서 손글씨, 인쇄된 텍스트, 체크박스, 도장, 표 구조를 인식할 수 있는 비전-언어 모델을 사용합니다. 손글씨 인식 정확도는 가독성과 필체에 따라 달라집니다 — 또렷한 블록체는 안정적으로 추출되지만, 과도하게 장식된 필기체는 여전히 수동 검증이 필요할 수 있습니다. 모델은 문서의 어느 영역에서 읽었는지 보여주는 시각적 단서를 제공하므로, 전체 문서를 다시 읽지 않고도 손글씨 필드를 빠르게 점검할 수 있습니다. 문서가 주로 손글씨라면, 규모를 확장하기 전에 특정 손글씨 샘플에 대한 정확도를 측정하기 위해 소규모 배치 테스트부터 시작하는 것을 고려하세요.

ImageToTable.ai는 기존 OCR과 어떻게 다르게 표 추출을 처리하나요?

기존 OCR은 선형 텍스트 스트림을 출력합니다. 표는 평면화됩니다. ImageToTable.ai는 문서를 시각적 레이아웃으로 처리하여 표 영역을 감지하고, 행과 열을 분할하며, 각 셀 값을 해당 열 헤더와 연결합니다. 출력은 표 구조를 보존합니다 — 각 행은 출력 스프레드시트의 행이 되고, 각 열은 지정한 열 이름에 매핑됩니다. 이는 템플릿 없이 작동하므로, 동일한 공급업체의 5행 송장과 20행 송장 모두 표 높이와 관계없이 올바르게 추출됩니다. 기존 접근 방식과 어떻게 다른지에 대한 자세한 설명은 AI 데이터 입력 개요를 참조하세요.