표와 양식이 많은 기업 문서에 질문했을 때, 답변 품질을 좌우하는 요인이 모델의 추론력보다 검색 단위인 경우가 많다. 최근 arXiv에 올라온 MM-BizRAG: Rethinking Multimodal Retrieval-Augmented Generation for General Purpose Enterprise Q&A는 이 지점을 다룬다. 원문 발췌에 따르면, 이 논문은 페이지 이미지 중심 MM-RAG가 효율적이지만 복잡한 기업 문서의 구조 정보를 명시적으로 다루지 않는다고 문제를 제기한다. 이 쟁점은 연구 취향의 차이만은 아니다. 엔터프라이즈 RAG의 초점이 “얼마나 덜 파싱하느냐”에서 “어떤 구조를 살려 검색하느냐”로 옮겨갈 가능성이 있다.

세 줄 요약

• 핵심 이슈는 페이지 단위 이미지 임베딩 중심 MM-RAG가 표, 서식, 문서 계층 같은 구조 정보를 놓칠 수 있다는 점이다.
• 문서군을 페이지 단위로만 넣기보다, 구조 복원형 파싱+텍스트/OCR 인덱스+블록 단위 비전 검색의 조합을 작은 코퍼스에서 먼저 A/B 테스트하는 편이 낫다.

현황

기업형 멀티모달 RAG의 한 흐름은 “최소 파싱”이다. 문서를 세밀하게 해체하기보다 페이지 이미지를 통째로 임베딩하고, 그 결과를 검색과 생성에 함께 쓰는 방식이다. 원문 발췌도 이 흐름을 짚는다. 효율 면에서는 이점이 있지만, 표의 행·열 관계나 양식의 필드 구조, 다단 레이아웃의 읽기 순서 같은 정보는 모델이 암묵적으로 파악하길 기대하게 된다.

문제는 실제 기업 문서가 이런 가정을 자주 벗어난다는 점이다. 조사 결과에 따르면 arXiv 논문 MultiDocFusion은 긴 산업 문서 벤치마크에서 계층·멀티모달 청킹 파이프라인이 기존 베이스라인 대비 검색 정밀도를 8–15%, QA의 ANLS를 2–3% 개선했다고 보고했다. 다만 이 수치는 확인된 다른 연구인 MultiDocFusion의 결과다. 질문에 나온 MM-BizRAG와 같은 베이스라인을 비교한 것인지는 확인되지 않았다. 표·양식·다단 레이아웃 문서만 따로 분리해 비교했는지도 분명하지 않다.

그래도 방향 자체는 읽을 수 있다. 다른 조사 결과를 보면, 엔터프라이즈 문서 파이프라인은 비전 기반 문서 영역 탐지, OCR, 계층 구조 재구성, 표 설명 생성, 모달리티별 인덱싱과 융합을 함께 쓸 때 정확도가 올라가는 경향이 있다. NVIDIA 기술 블로그 사례에서는 엔터프라이즈급 멀티모달 문서 추출 파이프라인이 20% fewer incorrect answers와 3X improved ingestion throughput를 제시했다. 논문과 블로그 사례를 함께 놓고 보면, 문서를 “이미지 한 장”으로 다루는 접근은 구현은 단순하지만 기업 문서의 구조 신호를 놓칠 위험이 크다.

분석

의사결정 포인트는 비교적 분명하다. 다루는 문서가 보고서, 계약서, 매뉴얼, 인보이스처럼 표와 서식, 제목 계층이 뚜렷하다면 페이지 단위 MM-RAG만으로는 정보 손실이 생길 가능성이 높다. 이런 경우에는 구조를 먼저 복원한 뒤 검색하는 쪽이 더 맞다. 반대로 문서가 짧고 시각 구조가 단순하거나, 답변 정확도보다 구축 속도와 운영 단순성이 더 중요하다면 페이지 중심 접근이 여전히 유리할 수 있다. 즉 “최소 파싱 vs 구조 인식”은 철학의 문제가 아니라 문서 분포와 비용 제약의 문제다.

트레이드오프도 분명하다. 구조 정보를 살리려면 OCR, 레이아웃 분할, 문서 트리 재구성이 필요하다. 여기에 블록 단위 인덱싱, 텍스트와 비전 검색 결과의 융합, 경우에 따라 리랭킹까지 붙는다. 그러면 파이프라인 오케스트레이션은 복잡해지고, 인덱싱과 저장 비용이 늘며, 지연시간 관리도 까다로워진다. 정답률이 조금만 오르면 되는 환경이라면 과투자일 수 있다. 반대로 잘못된 필드 하나가 심사, 결제, 규정 준수 판단을 흔드는 환경이라면 그 복잡도는 감수할 만한 비용이 된다.

또 하나 중요한 점은 검색 단위다. 조사 결과상 LFRAG는 기존 MM-RAG가 페이지 단위의 거친 검색에 치우쳤다고 보고, 레이아웃 분할을 통해 의미적으로 응집된 더 세밀한 검색 단위를 만든다. 실무에서는 이 차이가 크다. 답이 페이지 전체에 있는 것이 아니라 표의 한 블록, 양식의 특정 필드, 다단 편집 문서의 왼쪽 하단 섹션에 있을 때는 페이지 전체 검색이 잡음을 키운다. 검색 단위를 더 잘게 나누면 정확도뿐 아니라 불필요한 컨텍스트도 줄일 수 있다.

실전 적용

기업이 지금 내려야 할 결정은 “멀티모달을 쓸까 말까”가 아니다. “어느 문서군에 어느 수준의 구조 인식을 넣을까”다. 보고서와 계약서는 layout-aware parsing을 먼저 검토하고, 슬라이드처럼 페이지 전체 시각 맥락이 중요한 문서는 holistic page representation을 유지하는 식의 동적 라우팅이 더 현실적이다. 조사 결과도 문서 유형에 따라 접근을 달리하는 편이 유리하다고 정리한다.

예를 들어 인보이스 Q&A 시스템을 만든다고 하자. 페이지 임베딩만 쓰면 “총액”과 “세액”이 붙어 있는 표의 셀 관계를 놓칠 수 있다. 구조 복원형 파이프라인을 쓰면 먼저 표 영역을 분리하고, OCR로 텍스트를 추출하고, 셀 관계를 보존한 채 블록 단위로 검색한다. 이때 생성 모델은 페이지 전체 대신 관련 필드 주변의 근거를 받아 답한다. 여기서 달라지는 것은 정확도만이 아니다. 왜 이런 답이 나왔는지 추적하기도 쉬워진다.

오늘 바로 할 일 체크리스트:

• 최근 오답 사례 20개를 모아, 페이지 단위 검색 실패인지 표·레이아웃 구조 손실인지부터 라벨링하라.
• 같은 문서셋에 대해 페이지 단위 검색과 블록 단위 하이브리드 검색을 병렬로 돌려 검색 정밀도와 답변 근거 길이를 비교하라.
• 문서 유형을 보고서·양식·슬라이드로 나눠, 유형별로 파싱 강도를 다르게 주는 라우팅 규칙을 설계하라.

FAQ

Q. 페이지 이미지 중심 MM-RAG는 이제 구식인가?
그렇지 않습니다. 구현 속도와 단순성이 중요한 환경에서는 여전히 합리적입니다. 다만 표, 양식, 계층 구조가 많은 기업 문서에서는 구조 손실이 성능 병목이 될 수 있습니다.

Q. 구조 인식형 파이프라인은 정확도만 높고 비용은 너무 크지 않나?
그럴 수 있습니다. OCR, 레이아웃 분할, 계층 재구성, 멀티 인덱싱이 추가되면 운영 복잡도와 지연시간이 올라갑니다. 그래서 전사 문서 전체에 일괄 적용하기보다, 오답 비용이 큰 문서군부터 적용하는 방식이 현실적입니다.

Q. 그럼 최적의 조합은 무엇인가?
현재 확인된 근거 기준으로는 구조 인식형 파싱으로 문서 영역과 계층을 복원하고, 텍스트/OCR 인덱스와 페이지·블록 단위 비전 인코딩을 함께 구축한 뒤, 세분화된 retrieval과 semantic-layout fusion 또는 late interaction을 결합하는 방식이 유력합니다. 다만 비용, 지연시간, 저장 제약까지 포함한 전역 최적해가 하나로 확정된 것은 아닙니다.

결론

이번 쟁점의 핵심은 단순하다. 기업형 멀티모달 RAG의 성능 차이는 생성 모델 자체보다 문서를 어떻게 나누고, 구조를 얼마나 보존하며, 어떤 단위로 검색하느냐에서 벌어질 가능성이 크다. 앞으로 봐야 할 점도 같다. 페이지 전체를 폭넓게 보는 시스템보다, 문서 구조를 잃지 않은 채 필요한 블록을 정확히 찾아오는 시스템이 실제 업무 Q&A의 기준이 될지다.

다음으로 읽기

• AI 자료 모음 (24h) - 2026-06-04
• 에이전트 개입 타이밍의 문제
• RL 안전, 배치 전 검증으로
• AI 자료 모음 (24h) - 2026-06-03
• 로컬 AI PC, 실무 대안일까

참고 자료

• Build an Enterprise-Scale Multimodal PDF Data Extraction Pipeline with an NVIDIA AI Blueprint | NVIDIA Technical Blog - developer.nvidia.com
• MultiDocFusion: Hierarchical and Multimodal Chunking Pipeline for Enhanced RAG on Long Industrial Documents - arxiv.org
• LFRAG: Layout-oriented Fine-grained Retrieval-Augmented Generation on Multimodal Document Understanding - arxiv.org
• arxiv.org - arxiv.org