바이두, 수십 페이지 문서를 한 번에 읽는 오픈소스 OCR 모델 공개

• 바이두가 장문 문서를 한 번에 판독하는 오픈소스 OCR 모델 언리미티드 OCR(Unlimited OCR)을 공개함

  • 이미지나 PDF 안의 문자를 읽는 모델이고, 특히 여러 페이지에 걸친 긴 문서 분석을 겨냥함
  • 종이 계약서 스캔본, 연구 논문, 매뉴얼, 회의록처럼 페이지가 많은 문서를 다루는 상황이 타깃임

• 기존 OCR 파이프라인은 긴 PDF를 페이지별로 쪼개 처리한 뒤 결과를 이어 붙이는 경우가 많았음

  • 이 방식은 처리 시간이 늘어남
  • 페이지를 나누는 순간 전후 문맥, 표 연결, 문단 흐름이 깨질 수 있음
  • 사람이 보기엔 이어진 문서인데 모델 입장에선 조각난 이미지 묶음이 되는 셈임

• 최근 AI 기반 OCR은 단순 문자 추출을 넘어 문서 구조와 흐름까지 읽으려는 방향으로 가고 있음

  • 표, 레이아웃, 문장 흐름을 함께 고려할 수 있다는 게 장점임
  • 대신 출력이 길어질수록 이전 내용을 기억하기 위한 KV 캐시가 커짐
  • 캐시가 커지면 메모리 사용량이 늘고 생성 속도도 떨어짐

• 언리미티드 OCR은 이 장문 처리 병목을 줄이기 위해 R-SWA(Reference Sliding Window Attention)를 도입함

  • 어텐션은 모델이 입력의 어느 부분에 집중할지 정하는 구조임
  • R-SWA는 문서 이미지 같은 참조 정보는 보되, 이미 출력한 전체 텍스트를 무제한으로 쌓지 않음
  • 대신 직전 일정 범위를 작업 기억처럼 유지해 KV 캐시를 일정하게 관리하는 설계임

• 논문에서는 최대 컨텍스트 길이 32K 조건에서 수십 페이지 문서를 1회 추론으로 전사할 수 있다고 설명함

  • 기준선으로는 2025년 10월 출시된 딥시크-OCR(DeepSeek-OCR)을 사용함
  • 장문 출력 때 메모리 사용량이 커지는 문제를 R-SWA로 억제하는 구조라고 소개됨

• 모델 규모도 계산 효율을 의식한 쪽임

  • 전체 파라미터 수는 3B, 즉 30억 개임
  • 실제 처리에서 활성화되는 파라미터는 500M, 즉 5억 개라고 함
  • 모든 파라미터를 매번 쓰지 않고 일부만 활성화해 장문 처리 능력과 계산 효율을 같이 노린 구조임

• 깃허브 샘플 코드에는 여러 페이지 이미지와 PDF 처리 예제가 포함돼 있음

  • PDF는 먼저 페이지를 이미지로 변환한 뒤 여러 페이지 분석을 수행하는 방식임
  • 문서 처리 제품을 만드는 팀이라면 기존 페이지 단위 OCR 파이프라인과 비교해볼 만함

---

기술 맥락

• 언리미티드 OCR이 풀려는 문제는 “글자를 읽을 수 있느냐”보다 “긴 문서를 문서답게 읽을 수 있느냐”예요. 페이지별 OCR은 구현은 쉽지만, 표가 다음 페이지로 이어지거나 앞 문단이 뒤 문단의 전제가 되는 순간 정보가 끊기거든요.

• R-SWA를 쓴 이유는 긴 출력을 만들 때 KV 캐시가 계속 커지는 비용 때문이에요. 모델이 이전 출력 전체를 다 붙잡고 있으면 메모리 사용량과 생성 시간이 같이 늘어나니까, 참조 문서와 최근 문맥만 중심으로 보는 절충을 택한 거예요.

• 전체 3B 파라미터 중 실제 활성화가 500M이라는 점도 같은 맥락이에요. 긴 문서를 처리하려면 모델이 너무 무거우면 안 되니, 필요한 부분만 활성화해 계산량을 줄이려는 설계로 볼 수 있어요.

• 실무에서는 계약서 분석, 매뉴얼 검색, 논문 파싱처럼 페이지 경계 때문에 품질이 흔들리는 작업에서 의미가 커요. 다만 기사에 나온 정보만으로는 정확도 벤치마크나 한국어 문서 성능이 충분히 검증된 건 아니라서, 도입 전에는 자체 문서셋으로 꼭 확인해야 해요.