과학 논문을 대상으로 RAG (Retrieval-Augmented Generation)를 구축해 보았다면, 아마 다음과 같은 상황을 겪어보셨을 것입니다: PDF는 멀쩡해 보이고 텍스트 추출도 잘 되는 것 같은데, 셀이 병합된 표는 세 개의 쓰레기 같은 열로 변해버리거나, 적분 기호가 있어야 할 자리에 ?123? 같은 수식이 나타나고, LaTeX 표기법이 필요한 그림과 도표가 단순 이미지로 처리되는 등의 문제입니다.

이 포스트는 이를 해결하려고 시도하며 발견한 내용에 관한 것이며, 다른 분들도 같은 문제에 부딪혔다면 의견을 듣고 싶습니다.

왜 과학 논문 PDF 파싱은 다른 문서보다 더 어려운가?

대부분의 문서 파싱 도구는 송장(invoices), 계약서(contracts), 양식(forms)과 같은 비즈니스 문서에 맞춰 조정되어 있습니다. 논문은 차원이 다른 문제입니다:

• 단순한 상단에서 하단 방향(top-to-bottom)의 텍스트 추출 방식을 방해하여 두 열의 문장을 뒤섞어버리는 2단 구성 레이아웃 (Two-column layouts)
• PDF 내에서 텍스트가 아닌 이미지나 벡터 그래픽으로 존재하는 수식들; OCR (Optical Character Recognition)은 단순히 문자를 인식하는 것을 넘어 실제 수학적 구조를 재구성해야 합니다.
• 벤치마크 결과 섹션에서 흔히 볼 수 있는, 셀이 병합되거나 다중 행 헤더를 가진 중첩된 표 (Nested tables)
• 참고 문헌(References) 목록으로 다시 매핑되어야 하는 인용구들; 대부분의 파서(parser)는 이를 일반 텍스트로 취급하여 구조를 놓치게 됩니다.

VLM 기반 파서가 잘못되었을 때 어떤 일이 발생하는가?

저는 MinerU, Docling, Maker 등 몇 가지 서로 다른 추출 파이프라인(extraction pipelines)을 통해 논문 배치를 실행해 보았습니다. 정확도는 대체로 좋았지만, 저를 더 걱정하게 만든 것은 실패율보다 실패의 양상(failure mode)이었습니다.

파싱은 요란하게 실패하지 않습니다. 에러를 던지지도 않습니다. 그저 표의 숫자를 조용히 틀리게 적거나, 수식을 그럴듯해 보이지만 원문과는 다른 방식으로 재구성할 뿐입니다. 만약 이를 나중에 사용자가 질문할 RAG 파이프라인에 입력한다면, 그것은 경고 라벨이 없는 환각된 사실 (hallucinated fact)이 됩니다.

그래서 저는 무엇을 시도했는가?

저는 첫 번째 추출 결과를 그대로 믿는 대신, 작은 검증 단계 (verification pass)를 구축하게 되었습니다:

평소처럼 추출 (레이아웃 분석 (layout analysis) → 수식 (equations) → 표 (tables))
원본 페이지와 추출된 내용을 교차 검증 (cross-check)합니다. 다시 생성하는 것이 아니라, 단순히 확인하는 과정입니다: 이 표가 이미지에 실제로 있는 내용과 일치하는가? 신뢰도 임계값 (confidence threshold) 미만인 항목은 그대로 통과시키지 말고 플래그(flag)를 지정합니다.

120개의 수식이 포함된 500개의 논문 샘플을 대상으로 테스트한 결과, 모델의 출력값과 원본 페이지의 실제 내용이 일치하지 않는 80개의 사례를 잡아낼 수 있었습니다.

해당 실행 결과의 구체적인 내용은 다음과 같습니다: MinerU는 수식 추출에서 약 80%의 성공률을 보이며 가장 강력한 원시 추출 (raw extraction) 성능을 보였습니다. Docling은 단순한 방정식은 잘 처리했지만, 드문 표기법 (notation)에는 많이 어려움을 겪었습니다. 그리고 가장 성능이 좋은 파이프라인 (pipeline)을 사용하더라도 검증 계층 (verification layer)은 여전히 필요했습니다. 놓치게 되는 오류는 완전히 틀린 답이 아니라 아주 사소한 것들입니다. 예를 들어, 원본에는 \mathbb{2}가 있는데 모델은 2로 추출하는 경우인데, 이는 특별히 확인하지 않으면 육안으로는 동일해 보입니다.

이 문제가 이미 해결되었는가?

제가 알기로는 그렇지 않습니다. 대부분의 파서 (parser)들은 전체 정확도 수치를 보고하지만, 특정 문서의 어느 부분을 믿어야 하고 어느 부분을 재확인해야 하는지는 공개하지 않습니다. LLM을 루프 (loop)에 포함하여 과학 문헌을 기반으로 무언가를 구축하려는 사람들에게 가장 중요한 격차는 바로 이 지점이라고 생각합니다. 파이프라인을 망가뜨리는 것은 평균값이 아니라, 태그가 지정되지 않은 이상치 (outlier)입니다.

제가 살펴본 바로는: Datalab의 서비스는 기업용 영업 주기 (enterprise sales cycle)를 동반하는데, 이는 단순히 제품을 출시하려는 개인 개발자에게는 너무 큰 부담입니다. LlamaParse는 일반적인 추출 작업은 탄탄하게 수행하지만, 섹션 수준에서의 신뢰도/검증 — 즉, 정확히 무엇을 재확인해야 하는지 아는 것 — 은 이 도구가 설계된 핵심 기능이 아닙니다.

내가 도달한 결론

이 모든 것이 도구들이 나쁘다는 것을 의미하지는 않습니다. 특히 MinerU는 원시 추출 (raw extraction) 능력이 진정으로 강력하며, 저는 그것을 처음부터 다시 만들기보다는 그 위에 구축하는 쪽을 택하겠습니다. 하지만 "대체로 정확하다"는 것이 "비감독 상태로 파이프라인에 입력해도 안전하다"는 것과 동일하지는 않습니다. 특히 실패 모드 (failure mode)가 요란하지 않고 조용할 때는 더욱 그렇습니다. 그럴듯해 보이는 잘못된 숫자는 에러 메시지보다 더 나쁩니다. 왜냐하면 다운스트림 (downstream)의 어떤 것도 그 숫자에 의문을 제기해야 한다는 사실을 알지 못하기 때문입니다.

그것이 제가 원시 정확도 (raw accuracy)보다 결국 더 신경 쓰게 된 부분입니다. 단순히 "이것이 얼마나 자주 맞는가"가 아니라, "틀렸을 때 사용자가 알기 전에 내가 먼저 알 수 있는가" 하는 점 말입니다.

만약 여러분이 이와 유사한 작업 — 논문 기반 RAG, 연구 에이전트 (research agents), 혹은 상당한 양의 과학 PDF를 처리하는 그 어떤 것이든 — 을 하고 있다면, 여러분의 파이프라인이 어디에서 깨지는지에 대해 진심으로 의견을 나누고 싶습니다. 실패 사례 (failure cases)가 유용한 부분입니다. 해피 패스 (happy path)에서는 흥미로운 문제가 발생하는 경우가 거의 없기 때문입니다.

참고: 어차피 제 업무에 필요했기 때문에 결국 이것을 작은 도구로 만들게 되었습니다 — sciparse.com . 아직 초기 단계이며, 다른 사람들의 논문에서 어디가 깨지는지에 대한 의견을 듣는 데 주로 관심이 있습니다.