저희는 업무에서 많은 특허 문서를 처리하는데, 표가 합쳐지면서 구조를 잃거나, 화학 도표가 엉망이 되고, CJK(한중일) 및 라틴 문자 간의 수식 블록이 깨지는 것과 같은 동일한 OCR 실패 사례에 계속 직면해 왔습니다. 범용 모델들은 이를 위해 만들어지지 않았습니다.

그래서 저희는 특허 도메인 데이터를 핵심으로 하여 5,000만 개 이상의 샘플로 MOSS-OCR을 처음부터 학습시켰습니다. 설계 결정 사항은 블록 레벨(block-level)로만 유지하는 것이었습니다. 레이아웃 탐지(layout detection)와 읽기 순서(reading order)가 이미 처리되었다고 가정함으로써, 모델을 작고 빠르게 유지할 수 있었습니다. 이것이 모델 크기가 0.3B인 이유입니다.

OmniDocBench v1.6에서 이 모델은 MinerU 2.5의 전체 점수(94.46)와 대등한 성능을 보여주면서도 파라미터 수는 25% 수준에 불과합니다. 저희 자체 오픈 특허 도메인 벤치마크(patent-bench)에서는 93.49점으로 1위를 차지했습니다. vLLM을 통해 단일 RTX 4090에서 약 59 QPS로 실행되며, 이는 MinerU 2.5 처리량의 약 2배입니다.

솔직한 주의 사항을 하나 말씀드리자면, 이 모델은 페이지 레벨의 레이아웃이나 읽기 순서를 수행하지 않습니다. 이를 위해 저희는 RT-DETR 레이아웃 탐지와 MOSS-OCR을 하나의 FastAPI 서비스로 묶은 Hiro-Smart-Doc라는 별도의 파이프라인을 구축했습니다.

둘 다 Apache 2.0 라이선스입니다. 혹시라도 예외적인 사례(edge cases)를 발견하신다면 의견을 듣고 싶습니다.

GitHub (MOSS-OCR): https://github.com/patsnap/Hiro-MOSS-OCR
GitHub (Smart-Doc): https://github.com/patsnap/Hiro-Smart-Doc
Demo: https://huggingface.co/spaces/PatSnap/Document-Processing