PDF 추출하기
PDF 내용 추출하기
pdf를 RAG에 적용하기 위해선 pdf의 내용을 추출해야 한다.
간단한 방법으론 paser와 OCR로 내용을 추출하는 방법이지만 그림이나 표, 그래프는 추출하지 못한다.
가장 간단한 방법은 PDF 자체를 VLM으로 처리하면 된다, 물론 비싸다.
또한 추출이 가능한 글자의 경우도 LLM을 거쳐 비효율적이다.
이런 문제를 해결하기 위한 프레임워크는 이미 존재하니 적극 사용하자.
후보
주요 PDF 처리 프레임워크는 다음과 같다.
- Docling
- MinerU
- Marker
- PyMuPDF4LLM
Docling
DoclingDocument라는 중간 문서 모델을 중심으로 OCR, layout, table, picture, chunking 등을 하나의 파이프라인으로 구성한다. 따라서 RAG ingestion pipeline을 직접 설계하기에 가장 편하다.
OCR 엔진을 RapidOCR, EasyOCR, Tesseract 등을 교체할 수 있으며 현재 RapidOCR를 통해 PP-OCR v4/v5/v6까지 지원한다. 그림 설명은 로컬 VLM뿐 아니라 OpenAI-compatible remote API로 넘기는 구성도 지원한다.
MinerU
OCR, layout, table, formula 등의 문서 이해용 모델을 적극적으로 사용한다. 현재 Pipeline backend는 PP-OCRv6를 사용하며, 한국어 전용 korean OCR 설정도 공식적으로 존재한다. 공식적으로 OCR 109개 언어, 표→HTML, 수식→LaTeX, 이미지/표/각주 추출 등을 제공한다.
PDF → layout → text/OCR → table/formula → reading order → Markdown/JSON
별도로 VLM/Hybrid backend도 있다. VLM 쪽에는 MinerU2.5-Pro-2604-1.2B 같은 문서 전용 VLM을 사용하며 차트, 이미지, cross-page table 같은 복잡한 문서 요소까지 처리한다.
Marker
PDF 자체 text layer를 최대한 활용하고 필요한 경우에만 Surya VLM/OCR을 호출한다. Layout은 fast 모드에서 경량 RF-DETR 계열 모델을 사용할 수 있으며 OCR 자체를 끄는 것도 가능하다.
PDF text → layout → 필요한 영역만 Surya OCR/VLM → table/math → Markdown
Surya 자체가 OCR, layout, reading order, table recognition, LaTeX OCR을 지원하는 90+ 언어 문서 모델이다.
PyMuPDF4LLM
PyMuPDF 기반이라 PDF 내부에 이미 존재하는 텍스트를 활용하는 데 강하다. Markdown, JSON, TXT로 바로 출력할 수 있고 multi-column, 이미지/vector extraction, page chunking, layout 등을 지원한다.
Native PDF text → 문제가 있는 영역 판단 → 필요한 부분만 OCR
Tesseract뿐 아니라 RapidOCR나 custom OCR adapter도 연결할 수 있다.
문서 자체를 AI로 해석하는 시스템은 아니다. 따라서 born-digital PDF에는 굉장히 효율적이지만 스캔 문서, 복잡한 표, 수식, 그래프까지 의미적으로 복원하려면 다른 모델을 붙이는 편이 좋다.
프레임워크 선정
우선 PyMuPDF4LLM은 그림, 차트의 추출이 불가능하기에 제외하였다.
또한 현재 서버는 2OCPU로 상당히 가벼운 서버다 보니 가장 무거운 VLM을 openAI API로 대체할 것이다.
Marker의 경우 Docling, MinerU와 다르게 하나의 모델이 여러 기능을 지원하는 형태이다 보니. API로 대체시 사실상 대부분의 기능을 잃어 제외하였다.
Docling, MinerU 비교
Docling은 모델을 변경하여 튜닝하여 사용이 가능하며, MinerU는 지정된 모델만을 사용한다.
Dolcing의 기본 Granite-Docling 258M 이며 이미 openAI API 변경을 지원한다. 또한 거대 모델로
MinerU의 경우 기본 MinerU2.5-Pro-2604-1.2B 으로 1.2B급 무거운 모델이며 API 변경을 지원하지는 않지만 API로 대체는 가능하다.
기본 파이프라인 설정에서 PDF를 처리하여 비교해보았다.
논문- docling
- minerU
docling 의 수식 모델인 codeformulav2의 경우 drop → dop, ω → a 로 오독이 존재한다
인라인 수식에서 10 - 4 처럼 minerU에 비해 성능이 떨어진다.
한국어 OCR- docling
- minerU
한국어 OCR의 경우 docling에서 내용이 소실되는 문제가 있다.
- minerU
- docling
표의 경우 글자를 인식 못하거나 잘못 인식하기도 한다.
이외에도 Docling의 경우 그림, 이미지를 하나의 큰 패널로, minerU의 경우 더 작은 단위로 추출.
Docling의 경우 토크나이저 모델을 통해 청크를 나눠 결과물을 주는 등의 차이가 있다.
결론: MinerU 선택
기본 설정으로 비교한 결과, MinerU가 한국어 OCR과 수식 인식에서 더 안정적인 결과를 보였다. Docling에서는 일부 한글이 누락되거나 수식 기호가 잘못 인식됐는데, 이런 오류는 이후 청킹과 검색 품질에도 영향을 줄 수 있다고 판단했다. 이에 Vantage의 PDF 파서로 MinerU를 선택했다.
다만 Docling은 모델 교체와 후속 파이프라인 구성에 장점이 있었고, MinerU 역시 복잡한 표와 이미지까지 완벽하게 처리하지는 못했다. 이번 비교는 일부 문서를 기본 설정으로 처리한 결과이므로 모든 PDF에서 MinerU가 우수하다고 단정할 수는 없다.
결국 파서 선정으로 끝나는 문제가 아니었다. 실제 운영에서는 추출 정확도뿐 아니라 대용량 PDF의 메모리 사용량, 처리 시간, 실패 시 재처리 방식까지 함께 고려해야 했다.