Meridian PDF 처리 파이프라인 공개

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Raj Suthan은 스캔본, 깨진 표, 도표, 수식이 포함된 PDF를 검색 가능한 청크로 바꾸는 Apache 2.0 프로젝트 meridian을 공개했습니다. Docling이 문서 레이아웃과 시각 영역을 추출하고, 수식 페이지에는 번호 상자를 그린 뒤 Qwen3-VL-8B를 vLLM에서 동시 호출해 표·그림·수식 설명을 생성합니다. 설명은 원래 순서에 맞춰 청크에 삽입되고 Ollama 임베딩과 Qdrant 저장을 거치며, CPU Celery 워커와 장기 실행 GPU 서비스를 분리해 모델 중복 로딩을 피합니다. 단일 H200에서 20개 논문은 118.7 pages/min, 조정 후 Apollo 시대 NASA 보고서 25개는 77.2 pages/min과 zero failures를 기록했지만 단일 문서 처리 속도는 약 10 pages/min입니다. GPU를 쓰지 않는 pypdfium2 경로는 32개 CPU 워커로 NASA 문서 1,000개를 1분 이내 처리하는 대신 표와 그림을 버리는 절충을 택합니다.

실용적 조언

표·그림·수식의 검색 가능성이 중요하면 Docling으로 시각 영역을 분리한 뒤 VLM 설명을 청크의 원래 순서에 다시 삽입하는 GPU 경로를 사용하십시오.
대량 문서에서 텍스트 검색만 필요하면 pypdfium2와 CPU 워커 경로를 선택하십시오. 이 경로는 32개 CPU 워커로 NASA 문서 1,000개를 1분 이내 처리했지만 표와 그림은 보존하지 않습니다.
문서별 처리 시간이 아니라 전체 처리량을 높이려면 CPU 워커와 장기 실행 GPU 서비스를 분리하고, 여러 문서를 서로 다른 파이프라인 단계에 동시에 배치하십시오.
Celery soft limit에 걸리는 문서가 있으면 배치 상태를 Redis에 저장하고 인스턴스 수와 작업 설정을 조정해 재시도 가능한 실행 구조를 유지하십시오.

섹션별 상세

복잡한 문서의 검색 시스템에서는 스캔본과 깨진 표처럼 일반적인 PDF 텍스트 추출만으로 처리하기 어려운 요소가 병목이 됩니다. meridian은 Docling으로 레이아웃을 감지하고 표·그림·수식 영역을 분리한 뒤, 수식 페이지에 번호 상자를 그려 VLM이 요청 대상을 식별하게 합니다. 이후 각 시각 자료 페이지를 Qwen3-VL-8B에 동시 전달하고 생성된 설명을 원래 순서의 청크에 삽입한 다음 Ollama 임베딩과 Qdrant 저장으로 검색 경로를 완성합니다. 이 구조는 108k NASA 기술 보고서처럼 시각 정보가 많은 문서에서 텍스트만 남기는 처리보다 표·그림·수식의 의미를 검색 데이터에 보존하는 방식입니다.

처리량은 한 문서를 빠르게 끝내는 방식이 아니라 여러 문서를 파이프라인의 서로 다른 단계에 겹쳐 배치하는 방식에서 나옵니다. CPU 기반의 무상태 Celery 워커는 HTTP로 장기 실행 GPU 서비스를 호출하고, 모델은 워커별로 다시 로드하지 않고 한 번 로드된 서비스를 공유합니다. 8개의 Docling 인스턴스는 Redis 원자적 카운터로 작업을 나누며 watchdog과 Redis 배치 상태가 장애 재시작, 일시 중지, 재개, 재시도를 뒷받침합니다. 단일 H200에서 전체 VLM·임베딩 파이프라인은 학술 논문 20개 기준 118.7 pages/min을 기록했고, Apollo 시대 NASA 보고서 25개는 첫 설정에서 82.9 pages/min이었지만 5개 문서가 9분 Celery soft limit에 걸렸으며 재조정 후 77.2 pages/min과 zero failures를 기록했습니다.

프로젝트는 정확한 문서 이해와 대량 텍스트 수집을 같은 경로로 처리하지 않고 GPU 경로와 CPU 전용 경로로 분리합니다. GPU 경로는 표와 그림을 VLM으로 읽어 정보 손실을 줄이지만 단일 문서 처리 속도는 약 10 pages/min이며, 전체 처리량은 동시 파이프라인 구성에 의존합니다. 반면 pypdfium2와 32개 CPU 워커를 사용하는 텍스트 전용 경로는 GPU 없이 NASA 문서 1,000개를 1분 이내 처리하지만 표와 그림을 제거합니다. 따라서 문서 검색 시스템을 구축할 때 필요한 정보 수준과 대량 처리 속도에 따라 두 경로의 절충점을 선택할 수 있습니다.

이미지 분석

Screenshot
이미지는 meridian 저장소가 PDF에서 표·그림·수식을 추출하고 vision-language model로 읽어 검색 가능한 결과를 만드는 프로젝트임을 보여줍니다. 본문에서 설명한 파이프라인의 목적과 저장소 공개 사실을 시각적으로 뒷받침하지만, 처리량 수치나 세부 실행 구조는 포함하지 않습니다.
GitHub의 Rajsuthan/meridian 저장소 화면에 GPU 가속 문서 처리 파이프라인과 PDF의 표·그림·수식 추출 기능이 요약되어 있습니다.

용어 해설

비전 언어 모델(VLM): — VLM은 이미지와 텍스트를 함께 입력받아 이미지 속 표·그림·수식의 의미를 자연어로 변환하는 모델입니다. 이 글에서는 PDF에서 추출한 시각 자료를 읽고 검색 가능한 청크에 설명을 삽입하는 역할을 맡습니다. 따라서 일반적인 텍스트 추출만으로 누락되는 문서 정보를 보완합니다.
무상태 워커(Stateless Workers): — 무상태 워커는 작업 진행 정보를 프로세스 내부에 고정하지 않고 외부 저장소와 서비스에 의존하는 실행 단위입니다. 이 파이프라인에서는 CPU 기반 Celery 워커가 HTTP로 장기 실행 GPU 서비스를 호출하므로 워커마다 모델을 중복 로드하지 않습니다. 장애가 난 워커를 교체하거나 작업을 재시도하기 쉬운 구조입니다.
부하 분산(Load Balancing): — 부하 분산은 여러 처리 인스턴스에 작업을 나누어 특정 인스턴스에 요청이 몰리지 않게 하는 방식입니다. 글에서는 8개의 Docling 인스턴스를 Redis의 원자적 카운터로 배정하고 watchdog으로 중단된 인스턴스를 재시작합니다. 여러 문서가 서로 다른 단계에서 동시에 처리되도록 해 전체 페이지 처리량을 높입니다.
벡터 데이터베이스(Vector Database): — 벡터 데이터베이스는 문서 청크를 임베딩 벡터로 저장하고 의미가 가까운 항목을 검색하는 저장소입니다. meridian은 표·그림·수식 설명이 삽입된 청크를 Ollama로 임베딩한 뒤 Qdrant에 저장합니다. 이 단계가 PDF 내용을 키워드뿐 아니라 의미 기반으로 찾는 검색 경로를 구성합니다.

언급된 도구

meridian중립링크

복잡한 PDF를 표·그림·수식 설명이 포함된 검색 가능한 청크로 변환하는 오픈소스 파이프라인입니다.

Docling중립

PDF 레이아웃을 감지하고 표·그림·수식 영역을 추출합니다.

Qwen3-VL-8B중립

추출된 표·그림·수식 페이지를 읽고 자연어 설명을 생성하는 VLM입니다.

vLLM중립

Qwen3-VL-8B를 장기 실행 GPU 서비스로 호스팅합니다.

Ollama중립

문서 청크를 임베딩하는 데 사용됩니다.

Qdrant중립

임베딩된 검색 청크를 저장합니다.

Celery중립

CPU 기반 무상태 워커에서 문서 처리 작업을 실행하고 soft limit과 재시도를 관리합니다.

pypdfium2중립

GPU 없이 PDF에서 텍스트만 대량 추출하는 경로에 사용됩니다.

언급된 리소스

GitHubRajsuthan/meridian