▲

RAG에서 문서 파싱은 필요 없음: 이미지만 사용하세요

 (morphik.ai)
18P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 복잡한 문서에서 정보를 추출하기 위해 전통적 OCR과 파싱 방식이 의미를 제대로 보존하지 못함
  • Morphik은 ColPali 모델 기반의 비주얼 문서 임베딩 방식을 통해 표, 차트, 레이아웃 맥락까지 직접적으로 이해하는 방법을 구현함
  • 기존 파이프라인 대비 이 방법이 정확도와 정보 보존 면에서 월등하며, 벤치마크 테스트에서 최대 95.56% 정확도 달성함
  • 추가적으로, MUVERA와 Turbopuffer의 도입으로 대규모 문서 검색에서 속도 향상을 이뤄냈음
  • 앞으로는 멀티문서 추론, 워크플로우 통합, 전문가급 해석 등 실질적 문서 업무 자동화가 목표임

복잡한 문서 파싱의 한계와 RAG의 고난

  • 차트, 도표, 표가 혼합된 복잡한 PDF 문서에서 정보를 추출하려 할 때, OCR과 파싱 파이프라인이 원하는 정보를 자주 손실하는 문제 발생
  • 중첩 표, 중요한 도표, 주석이 많은 기술 문서, 심지어 텍스트가 없는 매뉴얼 등 실제 상황에서 기존 파이프라인의 한계 체감
  • 기존 파이프라인의 단계:
    • PDF에 OCR 적용 (숫자나 문자를 잘못 읽을 수 있음)
    • 레이아웃 감지 모델로 표/도표 구분 시도 (실패 확률 높음)
    • 읽기 순서 복원 (시각적 흐름을 놓칠 수 있음)
    • 도표 캡션 인식 (뉘앙스 누락 잦음)
    • 텍스트 청킹 (연관 정보가 분리될 수 있음)
    • 벡터 임베딩 생성 및 벡터DB 저장 (위치 정보·문맥 상실)
  • 예시: 단순한 표도 "1,000"을 "l,0O0"으로 읽거나, 표와 헤더가 분리되어 총합 계산에 실패하는 사례 다수
  • 도표의 범례를 본문으로 오인, 퍼센트 값이 엉뚱한 위치에 흩어지는 문제 등 실제 정보 손실 사례 빈번

새로운 접근: 시각 기반 문서 이해로의 전환

  • Morphik팀은 "문서를 사람처럼 시각 객체로 이해하면 어떨까?" 라는 질문에서 전환점 발견
  • 최신 연구(ColPali) 및 Vision Language Model(VLM) 의 발전으로, 이미지를 직접 임베딩하여 파싱이나 OCR 없이 문서 전체 맥락 및 시각 정보를 보존 가능
  • 각 문서 페이지를 고해상도 이미지로 처리하고, 패치 단위로 분할하여 시각적·텍스트적 정보를 모두 반영한 임베딩 생성
  • SigLIP-So400m Vision Transformer가 시각 패치 임베딩을 생성하고, PaliGemma-3B 언어 모델이 문서 구조를 이해
  • 질의어("Q3 매출 추이" 등)에 대해, 텍스트·차트·표·색상 등 다양한 시각적 단서까지 포함한 late interaction 검색 방식으로 관련 정보 정확히 추출
  • 문서 내 위치, 레이아웃, 색상, 그래프 변화 등 모든 시각 정보 유지—사람이 문서를 한눈에 보는 것과 유사

전통적 파싱과 ColPali 방식 비교

  • 기존 파싱 기반 파이프라인은 각 단계마다 정보가 손실되며, 텍스트·이미지 임베딩이 분리되어 문서 내 공간적 관계 해석이 불가능
  • 반면, ColPali 방식은 하나의 시각 임베딩 공간에서 모든 정보를 통합하여 문서 전체 의미와 맥락 보존
  • 실제 벤치마크(재무 문서 중심, 공개 데이터셋)에서 Morphik(ColPali 기반)은 최대 95.56% 정확도 기록(기존 LangChain+OpenAI text-embedding은 72%, OpenAI 파일 검색은 13.33%에 불과)
  • ViDoRe 벤치마크에서 시각 기반 방식이 기존 파싱 방식 대비 nDCG@5 기준 14%p 이상 높은 성능 달성

성능 최적화와 실전 적용

  • 초기 방식의 단점은 연산 부하에 따른 속도 저하였으며, 패치마다 벡터 검색이 필요한 구조로 초당 수천 만건 이상의 쿼리에는 부적합했음
  • MUVERA 논문을 참고, 멀티 벡터 검색을 단일 벡터 검색으로 치환하는 방식(고정 차원 인코딩) 도입
  • Turbopuffer 특화 벡터 DB와의 결합으로 쿼리 속도를 3-4초에서 30ms 수준으로 개선
  • 이로 인해 기존 텍스트 파싱 대비 월등히 빠른 속도로 수백만 건 문서 검색 가능해짐

활용 분야 및 쉬운 API 제공

  • 다양한 유형 문서에서 시각적 구조와 정보 손실 없이 고정확도 검색 지원
    • 복잡한 표와 차트가 중요한 금융 문서
    • 도면 중심의 기술 매뉴얼
    • 송장, 영수증에서의 레이아웃 기반 정보 추출
    • 연구 논문 속 시각자료/수치자료 이해
    • 의료 기록에서의 레이아웃 기반 관계 인식
  • API는 문서 업로드 후 자연어로 질의하는 매우 단순한 구조로, "1만 달러 초과 벌금 조항 계약서 모두 보여줘" 같은 요청 처리 지원

미래 방향: 멀티문서 지능과 더 깊은 이해

  • 멀티문서 인텔리전스: 여러 문서 간 상호 참조 및 정보 추적 기능 개발 중
    • 단일 문서 검색을 넘어, 여러 문서간 관계 추적 및 추론(예: 계약서 조항→규제 문서→실행 매뉴얼까지 연계) 지원
  • 에이전트 이해 체계: 문서 내 단순 질의응답을 넘어, 조항 추출→타 문서 검증→세부사항 크로스체크 등 청크간 논리 추론 자동화
  • 워크플로우 통합: 여러 계약서 간 조건 비교, 기술 결정의 이력 추적 등 실무 프로세스에 맞는 문서 자동화 지능 고도화

한계와 앞으로의 목표

  • 현재 방식은 전문가 수준의 해석과 맥락적 판단력까지는 도달하지 못함
  • 금융 전문가의 심층적 해석과 같은 부분은 아직 기술적으로 미흡하고, 신뢰성, 불확실성 정량화 등 엔터프라이즈 요구에 추가 개발 필요
  • 비주얼 이해와 도메인 지식 그래프의 결합, 인과관계 추론, 신뢰성 지표 제공 등이 앞으로의 주요 과제임

결론

  • 문서는 시각적 지식 객체로 다루어져야 하며, Parsing의 한계를 넘어 이미지 기반 문서 이해가 RAG 환경에서 더 뛰어난 해법임
  • Morphik은 문서 정보 추출의 새로운 표준을 제시하고자 하며, 복잡한 문서 워크플로우 자동화, 실제 업무 적용을 노리고 있음
  • 자세한 기능 체험은 morphik.ai에서 가능
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 사람들이 꼭 알아야 할 근본적인 문제가 여러 가지 있음
    LLM은 일반적으로 4k 텍스트 토큰에서 미리 학습되고, 그 후 긴 컨텍스트 윈도우로 확장하는 식임 (4000에서 4001로 가는 건 쉽지만, 이미지는 토크나이즈 방식이 달라서 이게 불가능함)
    그 결과, 분포에서 벗어나게 되어 두세 장 이상의 이미지를 다루면 환각 문제가 심각하게 발생함
    1536×2048 해상도의 PDF는 텍스트보다 3~5배 더 많은 토큰을 사용하므로 추론 비용이 증가하고 답변 속도가 느려짐
    저해상도로 내리면 이미지가 흐려짐
    이미지는 원본 크기 자체가 무거워서 필요한 이미지를 다운로드 하는 것만으로도 요청마다 대기 시간이 추가됨
    작은 벤치마크에서는 차트와 테이블이 많은 금융문서에 대해 기본 텍스트 청킹 방식보다 당연히 더 잘 작동함
    개인적으로는 Gemini처럼 OCR로 이미지 주석 가능하게 하고 결과를 비교해보고 싶음
    종단 간 이미지 접근법은 특수 사례(특허, 건축 다이어그램 등)에서는 말이 되지만, 정말 마지막 수단임

    • 전통적인 OCR과 LLM을 조합해서 오류도 수정하고 다이어그램까지 표현할 수 있으면 좋겠다고 생각함
      LLM은 읽지 못하는 부분에 그럴듯한 텍스트를 만들어내는 문제가 있어 결과를 더 엉망으로 만들 수 있음
      예를 들어, GPT4.1은 1296×179 사이즈의 스크린샷에서는 완벽하게 작동했지만, 50%로 축소해 650×84로 주면 "Pdf's at 1536 × 2048 use 3 to 5X more tokens"를 "A PNG at 512x 2048 is 3.5k more tokens"로 바꿔서 반환함
      대부분은 맞게 해주지만, 이렇게 미묘한 디테일이 바뀌는 점은 주의해야 함
    • gemma3 같은 최신 모델, pan & scan, 다양한 해상도에서 학습 등은 이런 문제를 완화시켜줌
      gemma3 계열의 흥미로운 특성은 입력 이미지 크기를 늘려도 처리 메모리 요구량이 증가하지 않는다는 것임
      두 번째 단계 인코더가 고정 크기 토큰으로 압축하기 때문임
      실제로 상당히 유용함
    • Gemini에 OCR을 추가하면 기존 OCR 모델보다 더 나은 결과가 나올 것으로 예상
      하지만 그렇게 하면 처리하는 전체 문서 집합이 대형 VLM을 반드시 거치게 됨
      너무 비싸고 느려질 수 있음
      여기엔 분명히 트레이드오프가 있음
      대부분의 경우에는 지금 방식이 가장 효과적이었음
    • 그게 바로 그들이 내놓은 document parse 제품의 역할임
      무엇이든 LLM에 넣는 경우가 있는데, 상황에 따라 맞지 않을 수도 있음
      모든 것을 반드시 LLM으로 처리할 필요는 없음
    • 논리에 공감함
      이게 RAG 파이프라인을 바꾸는 아이디어로 확장될 수 있을 것 같음
      각 RAG 결과별로 모델 처리 단계에서 이미지에서 유저 쿼리에 직접 관련된 정보를 추출하고 그 (텍스트) 결과를 모아 최종 생성의 입력으로 삼을 수 있음
      이렇게 하면 여러 이미지의 토큰 한도를 우회하고, 이미지 이해 과정을 병렬화할 수 있음

  • 나와 동료들은 6개월 전 프랑스 정부기관을 위해 이런 구현을 해봤음
    오픈소스로 여기서 제공함: https://github.com/jolibrain/colette
    우리 주 사업은 아니고 그냥 방치 중이지만, 약간의 튜닝으로 꽤 효율적으로 작동함
    진정한 묘미는 전체 파이프라인을 완전히 미분 가능하게 만들어 특정 데이터셋에 특화해 viz rag를 파인튜닝할 수 있다는 점임
    레이아웃 모델도 커스터마이징해서 정밀한 문서이해가 가능함

    • 최상단에 라이선스가 없어서, 라이선스 신경쓰는 사람들은 참고만 해도 사용할 수 없는 상황임
    • 파인튜닝이 진짜 최고의 부분이라는 데 동의함
      보통의 경우 가장 큰 장애물은 고품질 평가셋이 필요한 점임 (이게 늘 장애물임)

  • OCR 대 이미지 + 범용 LLM 벤치마킹 연구를 다수 진행해봄: https://getomni.ai/blog/ocr-benchmark
    이미지에서 직접 추출하는 방식의 가장 큰 문제는 다중페이지 문서임
    단일 페이지에서는 (OCR=>LLM vs Image=LLM)에서 미세하게 직접 이미지가 더 나았으나, 5개 이상 이미지를 넘어서면 OCR 우선 방식에 비해 정확도가 급격히 떨어짐
    사실 텍스트에서의 롱컨텍스트 리콜도 어려운 과제인데 LLM이 그걸 위해 최적화된 반면, 이미지 롱컨텍스트 리콜은 아직 많이 부족함

    • 대부분의 실사용 사례에서는 5페이지 이상의 컨텍스트가 과한 경우가 많았음
      이미지에서 바로 LLM 변환 레이어를 작게 얹는 것도 꽤 효과적임 (즉 직접 OCR하는 대신, 이미지 5장을 한 번에 소규모 비전 모델에 보내 문서의 가장 중요한 포인트들만 추출하는 방식)
      현재는 LLM의 캐시나 어텐션 맵을 수정해서 더 큰 이미지 배치가 잘 작동하도록 연구 중임
      슬라이딩 윈도우나 무한 리트리벌 같은 접근법이 유망해 보임
      개인적인 추측이지만, 멀티모달 모델의 발전이 가속화되는 걸 보면 곧 이미지 롱컨텍스트도 큰 문제가 안 될 거라 생각함

  • 이 블로그 포스트가 리트리벌에 비전 모델을 사용하는 것에 대해 좋은 지적을 하고 있지만 몇 가지 문제를 짚고 싶음

    1. 블로그가 인덱싱/리트리벌과 문서 파싱을 혼동함
      문서 파싱은 문서를 마크다운/JSON(혹은 추출할 때는 스키마에 맞춘 아웃풋) 같은 구조화된 텍스트로 바꾸는 작업임
      그중 하나가 RAG이고, 그 외에도 다양한 용도가 있음
      ColPali는 리트리벌에는 훌륭하지만, (최소한 네이티브로는) 순수 문서 파싱에는 쓸 수 없음
      저자는 주로 비주얼 리트리벌 벤치마크만 언급함
    2. 페이지 스크린샷으로 DIY 문서 파싱이 이미 널리 거론된 방식임
      표준 OCR보다 더 잘 작동하는 경우가 많지만,
      a. 여전히 롱테일 정확성 문제가 있음
      b. confidence score, bounding box 등 메타데이터가 빠짐
      c. 스크린샷 파이프라인 자체도 고도화하려면 노력이 필요함
    3. 일반적으로 리트리벌에는 텍스트와 이미지 표현 모두가 필요함
      이미지 토큰이 훨씬 더 강력하지만, 텍스트 토큰은 저장비용이 훨씬 저렴해서 리트리벌 할 때 전체 문서로 쿼리할 수 있음 (chunk 단위가 아니라)
      (참고: 나는 llamaindex CEO고 LlamaCloud로 파싱/리트리벌 모두 해봄, 그냥 일반적인 시각임)

  • 작년에 특허 문서 분석 시스템을 만드는 데 시간을 꽤 들임
    특허는 추상적 다이어그램, 화학식, 수식 등 다양한 콘텐츠가 포함돼서, LLM에 맞게 데이터를 준비하는 게 정말 까다로움
    내가 찾은 가장 간단한 방법은 각 페이지를 “사진 찍듯” 전환한 다음 LLM에게 그 내용을 설명하는 JSON과 메타데이터(페이지 넘버, 시각적 요소 개수 등)를 생성하게 하는 것임
    복잡한 이미지는 모델에게 묘사하게 시키면 됨
    이렇게 하면 원하는 벡터스토어 등에 JSON을 쉽게 임베딩 가능
    비용 대비 효율성은 따져보기 어렵지만, 이 방식이 저자가 제안한 것보다 더 간편하고 효과적임

    • 모델에게 이미지를 묘사하게 할 수는 있어도, 그 자체가 손실이 크다는 점이 있음
      예를 들어 차트에서 x, y 쌍을 모델이 대부분 잘 뽑더라도, 사용자가 특정 x/y를 꼬집어 물으면 빠뜨릴 수도 있음
      모델 추론 단계에서 이미지를 직접 보여주면, 사용자가 묻는 것에 정확히 답할 수 있으므로 이 접근법이 더 효과적임
      여기서 유일한 진짜 장애물은 리트리벌의 품질이고, 이건 비교적 작은 문제임
      즉, 적절한 컨텍스트 전달만 잘하면 나머지는 LLM이 알아서 커버해줌
      그렇지 않으면 OCR, 파싱, 이미지 묘사 등 해야 할 문제가 급격히 늘어남
    • 좋은 LLM 활용 사례라고 생각함
      다만 LLM의 기회는 기존 가치(특허 문서 등)를 재분류/재처리하는 곳에 집중됨을 보여줌
      90-00년대는 소프트웨어 기업들이 기존 종이 서류를 DB로 바꿔 사업 성공
      새롭고 가치 있는 데이터셋을 처음부터 만들어내는 건 여전히 투자와 노력이 많이 필요함
    • 모델이 이미지를 환각(잘못 해석)한 적은 얼마나 자주 있었는지 궁금함

  • 경험상, 이 방식은 별로임
    폰트에 따라 o(오)와 0(영)은 구별이 어려움
    문서(doc/xls/pdf/html)를 이미지로 변환하면 그런 구별 정보를 잃게 됨
    일련번호 등은 사람도 보고 구별 못하는 경우도 있음

    • PDF는 항상 실제 텍스트를 포함하는 게 아니라, 때로는 그림 그리듯 글자만 그리게 되어 있음
      그래서 PDF는 이미지를 렌더링해서 추출하는 게 꽤 합리적임
      나머지 포맷은 문서를 직접 파싱하는 게 더 나음
    • 이건 OCR 대안으로 이미지를 쓴다는 맥락이고, OCR 역시 비슷한 문제에 더 복잡해진 인프라와 비용이 추가됨
    • HTML의 경우 태그로 청킹하면 더 나은 결과를 얻는 경우가 많음
      다만 실무적으로 페이지 디자인을 할 때, 실제 이미지를 모델에 보여주는 것이 코드만 전달하는 것보다 디버깅에 훨씬 효과적임
      1 vs I, 0 vs O 문제가 실제로 존재하지만, 데이터 자체에 다이어그램/차트가 많은 문서는 이미지만으로 훨씬 쉽게 처리한 경험이 많음
      (선택 편향이 있을 수도 있음)

  • Gemini에 스케줄을 복사해서 질의해보려고 수분간 시도했지만, HTML로 돼있어도 제대로 안 됨
    결국 스크린샷을 찍어 필요 없는 부분은 검은 박스로 가리고 이미지를 넣었더니 아주 잘 작동함

  • 멀티모달 RAG로 이미 이 문제가 해결되는 것 같아 궁금함
    Flash 2.5, Sonnet 3.7 등으로 꽤 만족스러운 이미지 분석 결과를 얻음
    오히려 텍스트에 비해 이미지를 줬을 때 더 좋은 응답을 받는 느낌임
    https://www.youtube.com/watch?v=p7yRLIj9IyQ

    • 멀티모달 RAG가 바로 우리가 주장하는 방향임
      다만 초기 상태의 멀티벡터(멀티모달 RAG의 근간)는 매우 다루기 어렵고 유사도 계산이 매우 비싸서 스케일업 어려움
      양자화, 단일 벡터 변환(고정 차원 인코딩), 인덱싱 최적화 등이 필요함
      이게 바로 우리가 Morphik에서 하는 일임

  • 나 역시 모든 청구서를 한꺼번에 스캔해보려고 우편함에서 첨부파일만 추출 후, 하나씩 업로드하는 스크립트를 돌려서 “인보이스: 예/아니요”와, 각 항목/업체명/날짜/인보이스 번호 등을 추출하게 함
    결과적으로 판독률 높았고 3시간 넘게 LLM 콜이 걸렸지만 자동화라 신경 안 씀
    이후 은행 명세서와 매칭까지 LLM에 시켰고, 첨부파일로 오지 않은 일부 인보이스만 누락됨
    단, 인보이스-명세서 매칭은 LLM이 꽤 부실하게 했음(몇 달러 차이만 있어도 그냥 이 명세서라고 답함)
    그래서 당분간은 회계사가 필요한 듯
    비용은 대충 예상 못 했고, Claude 3.7 같은 저렴한 모델을 씀

    • 이런 단순 데이터 매칭의 경우, LLM이 직접 매칭하기보단 LLM이 매칭용 코드를 짜게 한 뒤 그걸 실행하는 게 더 정확할 듯함

  • ColPali가 직관적이고 강력한 점은 이해하지만, 그래도 문서처리 방식이 가지는 장점들이 있음

    • BM25, TFIDF 등 어휘 기반 검색이 특정 용어를 훨씬 잘 잡아냄
    • 본문 전체 검색 가능함
답변달기