표, 차트, 여러 단이 섞인 문서는 글자 인식만으로 부족하며, Qianfan-OCR처럼 읽기 순서와 영역을 먼저 계획하는 접근이 더 적합합니다. 다만 4B 단일 모델의 출력도 숫자와 표 구조를 완전히 보증하지 않으므로 원문 대조가 필요합니다.
Qianfan-OCR 논문 자료는 OCR, 레이아웃 분석, 표 복원을 여러 모델로 이어 붙이는 대신 이미지에서 Markdown까지 한 모델로 처리하는 방식을 제안합니다. 모델 규모는 4B이며 문서 변환뿐 아니라 표, 차트 이해와 문서 질의응답을 함께 다룹니다.
복잡한 페이지를 바로 텍스트로 쓰기 전에 모델은 영역 종류와 좌표, 읽기 순서를 생각 토큰으로 만듭니다. 좌표는 ymin, xmin, ymax, xmax 순서의 상자로 표현되고, 제목, 문단, 표 같은 요소 유형도 함께 둡니다. 이후 이 계획을 조건으로 Markdown을 생성하는 자기 조건화 구조입니다.
이 중간 결과는 누락 원인을 찾는 데 유용합니다. 문단 좌표가 빠졌다면 레이아웃 탐지 문제이고, 상자는 맞지만 셀 값이 틀렸다면 인식, 복원 문제로 좁힐 수 있습니다. 반면 생각 토큰이 길어지면 지연이 늘고, 잘못된 첫 계획이 뒤 출력 전체를 끌고 갈 수 있습니다.
논문은 레이아웃 엔트로피가 높은 문서에서 생각 단계를 쓰는 이점을 강조합니다. 여러 단, 삽입 그림, 병합 셀이 많은 페이지는 명시적 계획이 도움이 됩니다. 한 줄 영수증이나 단순 본문에서는 같은 과정이 불필요한 토큰과 오류를 더할 수 있습니다.
원문은 OmniDocBench v1.5에서 93.12, OlmOCR에 79.8을 보고합니다. 이는 해당 데이터의 평가 규칙에 따른 점수입니다. 한국어 특수 글꼴, 세로쓰기, 손글씨, 사내 양식에서 같은 수치를 기대하려면 별도 검증이 필요합니다.
도입 시험에서는 페이지를 일반 본문, 표, 수식, 차트, 혼합 레이아웃으로 나누고 각기 다른 오류율을 봐야 합니다. 표는 셀 값뿐 아니라 행, 열 병합과 헤더 관계를 확인하고, 차트는 축과 범례의 연결을 점검합니다. 문서 QA가 맞더라도 원문 Markdown이 정확하다는 뜻은 아닙니다.
원문에 제시된 요청 JSON은 호출 모양을 설명하는 예시일 뿐 인증, 실제 엔드포인트, 오류 처리까지 갖춘 완전 실행법이 아닙니다. 숫자 추출처럼 후속 계산에 쓰는 값은 규칙 검사나 사람 확인으로 다시 검증해야 합니다.
원문 시점에는 Baidu 클라우드 API를 통한 사용이 중심이고 공개 가중치는 제공되지 않은 것으로 설명됩니다. 민감한 계약서와 신분 문서를 외부 서비스로 보낼 수 있는지, 데이터 보존과 지역 규정은 어떤지 먼저 확인해야 합니다. 호출량에 따른 비용과 긴 문서의 페이지 분할 전략도 필요합니다.
Qianfan-OCR의 의미는 파이프라인 단계를 없앴다는 구호보다 레이아웃 계획을 모델 출력 안에서 관찰 가능하게 만든 데 있습니다. 복잡한 문서에서는 유용하지만, 단순 문서까지 무조건 같은 경로로 보내거나 벤치마크 점수만으로 무검수 자동화를 결정하는 것은 피해야 합니다.
사람이 표시한 영역 유형, 좌표와 읽기 순서를 중간 생각 토큰과 비교합니다. 문단 누락, 영역 중복, 잘못된 유형과 순서 오류를 따로 셉니다. 최종 Markdown만 보면 표가 깨진 원인이 영역 탐지인지 문자 인식인지 알기 어렵기 때문에 중간 계획을 보존하는 것이 유용합니다.
좌표 체계와 페이지 회전, crop, resize가 일치하는지도 확인합니다. 영역 상자가 맞지만 실제 텍스트가 다른 칸에서 왔다면 읽기 순서 연결이 틀린 것입니다. 계획을 사람이 수정했을 때 최종 출력이 개선되는지 보면 자기 조건화 단계의 기여를 분리할 수 있습니다.
페이지의 영역 수와 배열, 표, 그림 존재로 복잡도를 추정해 단순 OCR과 Layout-as-Thought 경로를 나눌 수 있습니다. 라우터가 복잡한 페이지를 단순 경로로 잘못 보내는 경우와 단순 페이지를 긴 경로로 보내는 비용을 함께 측정합니다. 문서 전체가 아니라 페이지별로 라우팅할 수도 있습니다.
경로별 출력 스키마와 후속 병합 규칙은 같아야 합니다. 페이지 사이의 제목, 표 연속과 각주가 끊기지 않는지 확인합니다. 라우팅으로 절약한 토큰이 병합 오류와 재처리로 상쇄되지 않는지 끝단 비용을 봅니다.
페이지별 OCR은 빠르게 병렬화할 수 있지만 제목과 본문, 표가 다음 페이지로 이어지는 관계를 놓칠 수 있습니다. 페이지 번호와 원본 좌표를 유지하고 표 헤더, 각주, 목차 참조를 문서 단위 후처리에서 연결합니다. 같은 문단을 두 페이지에서 중복 추출하거나 페이지 경계의 단어를 빠뜨리는지도 검사합니다.
문서 전체를 한 번에 넣으면 컨텍스트와 비용이 커지고 일부 페이지 오류의 원인을 찾기 어렵습니다. 페이지 처리와 문서 병합을 분리하되 최종 결과에서 원본 페이지로 돌아갈 수 있게 합니다. 페이지 하나의 실패가 전체 요청을 중단할지 부분 결과와 재처리 목록을 반환할지도 정해야 합니다.
제목 수준, 목록, 표와 수식 표현을 일정하게 정하고 모델 버전마다 형식이 바뀌지 않는지 확인합니다. downstream parser가 기대하는 fenced block, HTML 표와 Markdown 표 중 하나를 선택합니다. 시각적으로 비슷한 문서라도 구조 태그가 달라지면 검색, 청킹과 계산이 달라질 수 있습니다.
변환 결과에는 문서 ID, 페이지, 영역 좌표와 인식 확신도를 별도 메타데이터로 둘 수 있습니다. 본문에 좌표를 섞으면 사람이 읽기 어렵고 좌표를 버리면 감사가 어렵습니다. 원문 링크와 구조화 필드를 함께 제공하는 계약을 정하면 후속 시스템이 오류를 추적하기 쉽습니다.
레이아웃 계획이 비어 있거나 표가 파싱되지 않고 숫자 검사가 실패하면 기존 OCR, 표 전용 모델이나 사람 검토로 보냅니다. 같은 API를 무한 재시도하지 않고 입력 해상도, 페이지 유형별 최대 횟수를 둡니다. 단순 문서 fallback과 민감 문서의 로컬 경로를 구분할 수 있습니다.
fallback 비율과 성공까지의 총 비용을 기록합니다. Qianfan-OCR의 단일 모델 호출이 싸 보여도 후처리와 재시도가 많으면 기존 파이프라인보다 비쌀 수 있습니다. 최종 성공 문서 비율과 사람 수정 시간을 기준선과 비교해야 합니다.
안 됩니다. 레이아웃 계획, 글자, 표 복원과 Markdown 생성에서 오류가 날 수 있으므로 숫자, 셀 구조와 후속 계산에 쓰는 값은 원문과 다시 대조해야 합니다.
그렇지 않습니다. 여러 단, 표, 그림이 섞인 페이지에는 도움이 될 수 있지만 단순 문서는 추가 토큰과 잘못된 계획 때문에 느리거나 나빠질 수 있습니다.
조직 정책과 서비스 조건을 먼저 확인해야 합니다. 데이터 전송 지역, 보존, 학습 사용, 접근 통제와 삭제 조건이 요구 사항에 맞지 않으면 외부 API 경로를 쓰면 안 됩니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.