[AI] 문서 변환, 구조화에 유용한 Docling 살펴보기

RAG 시스템을 구축하는 경우에 전체 문서를 LLM에 넣을 수는 없으니 일반적으로 원문을 전처리하여 chunking 하여 관련 문서(조각)를 검색해오게 된다. 하지만 많은 경우에 원문이 PDF 문서나 구조화 된 형태(이미지, 테이블 등)이고, 이를 단순 텍스트 추출하여 처리하거나 구조를 무시하게 된다면 답변 시 잘못된 정보를 제공하는 경우가 빈번하게 발생한다. 예를 들어, 테이블을 텍스트 그대로 추출하였을 때 헤더와 값들이 제대로 매핑되지 못하고 밀리게 된다면 관련 문서를 잘 가져왔다 하더라도 잘못된 답변을 제공하게 된다.


PDF 파서나 OCR 같은 유용한 도구들을 활용하여 이를 보완할 수 있지만, PDF는 우리가 생각하는 것 보다 훨씬 복잡한 형태가 많고 이를 완벽하게 추출해내는 것은 아직도 매우 어렵다. Docling 은 IBM Research에서 Open-source로 공개하고 있는 문서 변환 툴인데, 다양한 문서 형식을 통합된 구조 표현으로 변환할 수 있도록 제공해주고, 무엇보다 github stars 수가 상당히 높아 꽤 괜찮게 고려해볼 수 있는 솔루션일 것 같다.

• github: https://github.com/DS4SD/docling
• document: https://ds4sd.github.io/docling/
• Docling Technical Report: https://arxiv.org/abs/2408.09869

github 와 document 의 내용도 최신성 측면에서는 매우 중요하지만, 기본적으로 Technical Report 가 있는 경우에는 그것을 먼저 보는 경우가 많아서 이번에도 리포트를 중점으로 확인해보았다.

1. 제공 Features

제공해주는 features 는 github 에 잘 정리되어 있다. 기본적으로 다양한 document formats 을 지원하고, page layout, order, table 등을 해석할 수 있으며, LlamaIndex, LangChain 과 쉽게 통합 가능한 것이 특징이다.

• 🗂️ Reads popular document formats (PDF, DOCX, PPTX, XLSX, Images, HTML, AsciiDoc & Markdown) and exports to HTML, Markdown and JSON (with embedded and referenced images)
• 📑 Advanced PDF document understanding incl. page layout, reading order & table structures
• 🧩 Unified, expressive DoclingDocument representation format
• 🤖 Easy integration with 🦙 LlamaIndex & 🦜🔗 LangChain for powerful RAG / QA applications
• 🔍 OCR support for scanned PDFs
• 💻 Simple and convenient CLI

2. State of the Art

문서 변환은 오랫동안 논의된 주제로, 이미 많은 솔루션이 존재한다. 다양한 솔루션은 몇 가지 기준에 따라 분류할 수 있는데, 오픈소스 여부, 라이선스의 허용 여부, Web APIs 와 로컬 코드 배포 방식, 할루시네이션에 대한 민감성, 변환 품질, 속도, 컴퓨팅 리소스 등이 그에 해당한다. 최근에 널리 사용되는 솔루션은 Visual Language Models(VLMs) 을 사용하는 것인데, closed-source 의 대표적인 예로는 GPT-4, Claude, Gemini 가 있으며, open-source 에서는 LLaVA 기반 모델이 주목받고 있다. 그러나 당연하게도 이러한 생성 모델 기반의 솔루션은 문제점이 있을 수 밖에 없는데,

1. 할루시네이션에 취약하여 잠재적으로 문서 변환 시 중요한 문제를 일으킬 여지가 있다.
2. 계산 비용이 매우 비싸기 때문에 비효율적이다.

또 다른 유형의 솔루션으로는 On-premises 배포를 고려하여 Web APIs 나 라이브러리 형태로 제공된다. 대표적으로 Adobe Acrobat, Grobid, Maker, MinerU, Unstructured 등이 있다고 한다. 이런 솔루션들은 주로 OCR 을 사용하여 PDF(이미지) 내 텍스트를 분석하고, 레이아웃 분석과 테이블 인식 모델 등 다양한 특화 모델을 활용한다. Docling 은 이러한 솔루션들과 유사한 방식을 취하고, task-specific models 을 모듈 형태로 제공한다. 위에서 언급한 할루시네이션 문제가 방지되면서 정확하고 예상되는 변환을 보장하지만, 상대적으로 커버리지가 작고 이를 위해 다양한 특화 모델을 유지해야 한다는 점에서 복잡해질 수 밖에 없다. 솔루션 마다 장, 단점이 명확하기 때문에 이를 인지한 채로 Docling 솔루션을 접근해야 할 것이다. 또한 Docling 의 장점으로 상대적으로 자유로운 MIT 라이선스를 들 수 있다.

3. Design and Architecture

Docling 은 크게 3가지 주요 컨셉을 기반으로 설계되었는데, pipelines, parser backends, pydantic 기반의 DoclingDocument model 이 바로 그것이다. 각각의 컨셉을 디테일하게 분석하는 것 보다는 위 이미지를 이해하는 것이 더 좋을 것 같다. 위 그림의 노란 부분은 pipeline 을 표현하고 있는데, 크게 Standard PDF Pipeline 과 Simple Pipeline 으로 나눌 수 있다.

1. StandardPdfPipeline:

   • PDF 및 이미지 입력이 들어왔을 때, DoclingDocument 형태로 변환하는 것이 목적인 pipeline 이다.
   • 뒤에서 설명할 여러가지 AI 모델들을 사용하여 단계적으로 정보를 구조화한다.

2. SimplePipeline:

   • Office, HTML, Markdown 등의 구조화가 이미 잘 되어있는 포맷을 처리할 때 사용한다.
   • 필요할 때에는 이미지 분류와 같은 추가적인 기능을 적용할 수 있도록 모듈화가 잘 되어있다.

PDF, 이미지, 각종 Office, HTML, Markdown 과 같은 문서들은 별도 파싱하는 도구가 필요한데, Docling 에서는 직접 구현한 parser backends 를 활용한다. 위의 pipeline 과 짝을 이루어 크게 2가지 범주로 나눌 수 있는데,

1. Low-level Formats:

   • PDF 파일 및 스캔된 이미지 형태이다.
   • 문서로부터 별도 구조를 뽑아내기 어렵기 때문에 (이미지에 가까움) AI 기반 기술 (OCR, layout analysis 등)을 통해 내용과 구조를 복원해야 한다.

2. Markup-based Formats:

   • 상대적으로 쉬운 마크업 형태로, MS Office, HTML, Markdown 과 같은 형식이다.
   • 섹션, 리스트, 표, 그림의 의미를 보존하고 있다.

Docling 에서는 필요 시 parser backends 만 사용할 수 있도록 별도 패키지화 하여 docling-parse 라는 이름으로 제공하고 있다.

4. PDF Conversion Pipeline

사실 이 부분이 Docling 의 가장 중요한 내용인데, raw data에 가까운 PDF를 어떤 특화모델들을 가지고 파이프라인을 구성하여 처리하였는 지 설명하고 있다. 간단하게 설명하면 parser 를 통해 PDF를 우선 파싱하고, 페이지 단위로 AI 모델을 적용한 후에 모든 페이지 분석 결과를 aggregation 하고 post-processing 한다.

4.1. AI Models

Layout Analysis Model

이 모델은 페이지를 기반으로 문서를 구성하는 다양한 요소(텍스트, 표, 그림 등)의 경계 박스(bounding-box)와 그 클래스를 예측한다. DocLayNet 데이터셋을 기반으로 RT-DETR 아키텍처로 re-trained 되었다고 한다. 예측된 bounding-box는 confidence와 사이즈에 따라 겹치는 부분이 제거되고 텍스트 토큰과 교차되어 문단, 제목, 리스트 아이템, 캡션들, 이미지, 표와 같은 의미있는 단위로 그룹화된다.

Table Structure Recognition

테이블 구조 인식모델은 TableFormer 모델을 사용한다. 이 모델은 텍스트가 포함된 테이블의 이미지를 입력으로 받아서 행과 열 구조를 예측한다. 테이블의 경우 비어있는 셀이나 머지된 셀을 인식하여 올바르게 파싱하는 것이 어려운데, TableFormer 는 이러한 복잡한 테이블(불완전한 경계선, 비어있는 셀, 계층이 있는 열과 행의 헤더들 등)에 대하여 매우 뛰어난 성능을 보인다고 한다. 또한 언어에 상관 없이 잘 동작하는 것이 특징이다.

OCR

OCR은 스캔된 비트맵 이미지에서 컨텐츠를 추출한다. Docling 에서는 별도 개발한 OCR을 사용하는 것 같지는 않고, EasyOCR, Tesseract 와 같이 유명한 오픈 소스 OCR 라이브러리를 통합해놓았다. 다만 OCR의 경우, CPU 에서는 속도가 매우 느려서 전체 파이프라인에서 병목이 될 수 있으니 사용 시 감안해야 할 것이다.

Assembly

각 페이지에서 독립적으로 생성된 예측 결과는 하나로 합쳐져서 전체 결과를 만들어야 하는데, 이 역할을 하는 것이 assembly 이다. 읽는 순서를 교정하거나 그림과 캡션을 연결하는 등의 후처리 로직이 여기에 포함된다.

5. 성능 분석

문서의 페이지 수와 변환 시간 간에는 그렇게까지 strict 한 선형 관계는 없었다고 한다. 당연하게도 페이지 수 보다는 문서의 테이블 수나 이미지 요소 빈도에 따라 처리 시간이 달라졌는데 경쟁사 및 각 모듈 별 걸린 시간은 아래 그래프에 잘 정리되어 있다. OCR 이 상대적으로 오래 걸리기 때문에 활성화 여부에 따라 실행 시간을 유연하게 조정할 수 있다.

실제 사용해 본 Docling 은 생각보다 결과도 괜찮았고 속도도 나쁘지 않았다. 단, runtime 에 사용할 수 있는 솔루션은 아니고, RAG 인덱싱을 위해 데이터를 구조화하고 테이블을 markdown 형태로 잘 복원하고 싶을 때 사용하면 좋을 것 같다. 그리고 Mac 환경에서도 MPS device 를 사용하여 상당히 빠른 속도로 돌려볼 수 있으니 이제까지 기본적인 pdf parser 라이브러리만 사용해봤다면 한 번 결과를 보고 사용 여부를 결정해도 좋을 것 같다. 인기가 많고 변화 속도가 빠른 오픈 소스들은 그만큼 빠르게 업데이트 되기 때문에 자잘한 오류들을 다 잡지 못한 채 feature 업데이트에 급급한 모습을 보이기도 하지만, 그만큼 사용자들의 니즈를 빠르게 반영해주기 때문에 활용하는 입장에서는 매우 고마운 것 같다.