Docling의 등장배경
Rag system을 구축하는 경우에는 전체 문서를 LLM에 넣을 수는 없다. 원문 전처리 후 chunking 하여 관련 문서(조각)를 검색해온다. 하지만 대다수의 경우에 원문 PDF문서 이거나 구조화 된 형태 (이미지, 테이블 등)이다. PDF 파서나 OCR같은 유용한 도구들을 활용하여 이를 보완할 수 있다. 하지만 생각한것 보다는 복잡한 형태가 많고 완벽하게 추출해내는 것도 어렵다. 그래서 등장하게 된게 Docling같은 모델들이다. Docling은 IBM Research에서 Open Source로 공개하고 있는 문서 변환 툴이다. 다른 비슷한 모델들로는 Adobe Acrobat, Grobid, Maker, MinerU, Unstractured가 있다. 이 모델들도 주로 OCR을 사용하여 PDF 내 텍스트를 분석하고, 레이아웃 분석과 테이블 인식 모델 등 다양한 특화 모델을 활용한다.
Docling의 작동원리
Docling의 주요컨셉으로 3가지를 얘기할 수 있다. pipelines, parser backends, pydantic 기반의 DoclingDocument Model 각각의 컨셉을 디테일 하게 분석하는 것보다는 다음 이미지를 이해하는 것이 더 좋다.
위에 이미지에서 노란 부분은 pipeline을 표현하고 있다. 크게 Standard PDF pipeline과 Simple pipeline으로 나눌 수 있다. 그리고 PDF, 이미지, 각종 MS Office, HTML, Markdown과 같이 문서들은 별도로 파싱하는 도구가 필요하다. 예시로 PyPdfium과 Docling-Parse가 있는데 블로그 글 마지막쪽에 비교한걸 소개해 보겠다.
Standard PDF pipeline
우선 Standard PDF pipeline을 살펴보자 PDF 이미지가 입력이 들어오면, DoclingDocument 형태로 변환하는 것이 목적인 pipeline이다. 뒤에서 설명할 여러가지 AI모델들을 사용하여 단계적으로 정보를 구조화 한다.
1. OCR
OCR은 스캔퇸 비트맵 이미지에서 컨텐츠를 추출한다. Docling에서는 별도 개발한 OCR를 사용하지 않는거 같다. EasyOCR, Tesseract와 같이 유명한 오픈소스 OCR라이브러리를 통합해놓았다. 하지만 OCR의 경우 CPU에서는 속도가 매우 느려서 전체 파이프라인에서 병목이 될수 있다.
2. Layout Analysis Model
page기반으로 문서를 구성하는 다양한 요소 (텍스트, 표, 그림)의 경계박스 (bounding-box)와 그 클래스를 예측한다. DocLayNet 데이터셋을 기반으로 RT-DETR아키텍처로 re-trained 되었다. 예측된 bounding-box는 confidence와 사이즈에 따라 겹치는 부분이 제거되고 텍스트 토큰과 교차되어 문단, 제목, 리스트 아이템, 캡션들, 이 미지, 표와 같은 의미있는 단위로 그룹화 한다.
3. Table Structure Recognition
테이블 구조 인식모델은 TableFormer 모델을 사용한다. 이 모델은 텍스트가 포함된 테이블의 이미지를 입력으로 받아서 행과 열 구조를 예측한다. TableFormer은 복잡한 테이블 (불 완전한 경계선, 비어있는 셀, 계층이 있는 열과 행의 해더들 등)에 대하여 뛰어난 성능을 보여준다. 또한 언어에 상관없이 잘 동작하는 것이 특징이다.
4. Assembly
각 페이지에서 독립적으로 생성된 예측결과는 하나로 합쳐져서 전체결과를 만들어야 하는데, 이 역활을 하는 것이 assembly이다. 읽는 순서를 교정하거나 그림과 캡션을 연결하는 등의 후처리 로직이 여기에 포함된다.
Simple pipeline
다음으로 Simple pipeline를 살펴보자 Simple pipeline은 말그대로 간단하다. PDF나 이미지 말고 모든 문서들을 변환하는 과정이다. 여기서는 Markup-based Formats으로 진행하고 Assembly를 수행한 후 변환이 된다.
PyPdfium vs Docling-Parse
parser단계에서 backend는 PyPdfium과 Docling-Parse 두가지를 비교해 볼 수 있다.
항목 | PyPdfium | Docling-Parse |
|---|---|---|
기반라이브러리 | 크롬에서 쓰이는 고성는 C++ PDF 렌더러 | Docling 프로젝트의 기본 파서 - 텍스트 , 백터, 이미지를 문자, 단어, 행 레벨 좌표로 추출 |
장점 | 렌더 속도 빠르고 좌표 정확도가 높아 “태생적(프로그램 생성) PDF” 처리에 최적• 이미지가 적고 폰트가 살아있는 금융 보고서에 OCR 없이도 완전한 텍스트/벡터 좌표 확보 | Docling 내부 구조와 직접 호환되어 후처리·OCR·TableFormer 연동 비용↓ 파서→중간 데이터 포맷‑→TableFormer 단계가 tight coupling → 통합 성능 Good |
단점 | 스캔 PDF는 텍스트가 없으므로 OCR 엔진 병행 필요• PDFium 자체는 테이블 구조를 알지 못해 Docling의 테이블 모델을 별도로 호출해야 함 | 좌표 정밀도는 PDFium보다는 다소 낮다는 리포트도 있음 (폰트 힌팅 차이) |
Tesseract vs EasyOCR vs RapidOCR
다음은 대표적인 오픈소스 OCR엔진에 대해서 알아보자
항목 | Tesseract | EasyOCR | RapidOCR (ONNX) |
|---|---|---|---|
언어 지원 | 100+개 언어 지원 (한·중·일·라틴·아랍·인도어 등)으로 다국어 문서에 유리 | 90개 언어지원 딥러닝 기반으로 글자·단어 수준 인식 우수 | 제한적 (주로 EN/CN) |
정확도 | 높음 (단일 문자) | 단어/문장 수준 우수 | 검출+인식 모두 균형적 |
속도 (CPU) | 빠름 (전처리 필요) | 느림 | 매우 빠름 (GPU 최적) |
속도 (GPU) | 제한적 | 매우 빠름 | GPU에서 최상 성능 |
사용 편의성 | CLI/API 복잡함 | 매우 간단한 Python 인터페이스 | 초기 셋팅은 다소 복잡 |
형식 지원 | 레이아웃 무손실 텍스트 | 비정형, 사진 OCR 강함 | 구조추출용 파이프라인에 적합 |
마무리
다음에는 Docling의 성능 테스트랑 결과 구조에 대해서 살펴보자