사람들이 꼭 알아야 할 근본적인 문제가 여러 가지 있음
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의 캐시나 어텐션 맵을 수정해서 더 큰 이미지 배치가 잘 작동하도록 연구 중임
슬라이딩 윈도우나 무한 리트리벌 같은 접근법이 유망해 보임
개인적인 추측이지만, 멀티모달 모델의 발전이 가속화되는 걸 보면 곧 이미지 롱컨텍스트도 큰 문제가 안 될 거라 생각함
이 블로그 포스트가 리트리벌에 비전 모델을 사용하는 것에 대해 좋은 지적을 하고 있지만 몇 가지 문제를 짚고 싶음
블로그가 인덱싱/리트리벌과 문서 파싱을 혼동함
문서 파싱은 문서를 마크다운/JSON(혹은 추출할 때는 스키마에 맞춘 아웃풋) 같은 구조화된 텍스트로 바꾸는 작업임
그중 하나가 RAG이고, 그 외에도 다양한 용도가 있음
ColPali는 리트리벌에는 훌륭하지만, (최소한 네이티브로는) 순수 문서 파싱에는 쓸 수 없음
저자는 주로 비주얼 리트리벌 벤치마크만 언급함
페이지 스크린샷으로 DIY 문서 파싱이 이미 널리 거론된 방식임
표준 OCR보다 더 잘 작동하는 경우가 많지만,
a. 여전히 롱테일 정확성 문제가 있음
b. confidence score, bounding box 등 메타데이터가 빠짐
c. 스크린샷 파이프라인 자체도 고도화하려면 노력이 필요함
일반적으로 리트리벌에는 텍스트와 이미지 표현 모두가 필요함
이미지 토큰이 훨씬 더 강력하지만, 텍스트 토큰은 저장비용이 훨씬 저렴해서 리트리벌 할 때 전체 문서로 쿼리할 수 있음 (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가 바로 우리가 주장하는 방향임
다만 초기 상태의 멀티벡터(멀티모달 RAG의 근간)는 매우 다루기 어렵고 유사도 계산이 매우 비싸서 스케일업 어려움
양자화, 단일 벡터 변환(고정 차원 인코딩), 인덱싱 최적화 등이 필요함
이게 바로 우리가 Morphik에서 하는 일임
나 역시 모든 청구서를 한꺼번에 스캔해보려고 우편함에서 첨부파일만 추출 후, 하나씩 업로드하는 스크립트를 돌려서 “인보이스: 예/아니요”와, 각 항목/업체명/날짜/인보이스 번호 등을 추출하게 함
결과적으로 판독률 높았고 3시간 넘게 LLM 콜이 걸렸지만 자동화라 신경 안 씀
이후 은행 명세서와 매칭까지 LLM에 시켰고, 첨부파일로 오지 않은 일부 인보이스만 누락됨
단, 인보이스-명세서 매칭은 LLM이 꽤 부실하게 했음(몇 달러 차이만 있어도 그냥 이 명세서라고 답함)
그래서 당분간은 회계사가 필요한 듯
비용은 대충 예상 못 했고, Claude 3.7 같은 저렴한 모델을 씀
이런 단순 데이터 매칭의 경우, LLM이 직접 매칭하기보단 LLM이 매칭용 코드를 짜게 한 뒤 그걸 실행하는 게 더 정확할 듯함
ColPali가 직관적이고 강력한 점은 이해하지만, 그래도 문서처리 방식이 가지는 장점들이 있음
Hacker News 의견
사람들이 꼭 알아야 할 근본적인 문제가 여러 가지 있음
LLM은 일반적으로 4k 텍스트 토큰에서 미리 학습되고, 그 후 긴 컨텍스트 윈도우로 확장하는 식임 (4000에서 4001로 가는 건 쉽지만, 이미지는 토크나이즈 방식이 달라서 이게 불가능함)
그 결과, 분포에서 벗어나게 되어 두세 장 이상의 이미지를 다루면 환각 문제가 심각하게 발생함
1536×2048 해상도의 PDF는 텍스트보다 3~5배 더 많은 토큰을 사용하므로 추론 비용이 증가하고 답변 속도가 느려짐
저해상도로 내리면 이미지가 흐려짐
이미지는 원본 크기 자체가 무거워서 필요한 이미지를 다운로드 하는 것만으로도 요청마다 대기 시간이 추가됨
작은 벤치마크에서는 차트와 테이블이 많은 금융문서에 대해 기본 텍스트 청킹 방식보다 당연히 더 잘 작동함
개인적으로는 Gemini처럼 OCR로 이미지 주석 가능하게 하고 결과를 비교해보고 싶음
종단 간 이미지 접근법은 특수 사례(특허, 건축 다이어그램 등)에서는 말이 되지만, 정말 마지막 수단임
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 계열의 흥미로운 특성은 입력 이미지 크기를 늘려도 처리 메모리 요구량이 증가하지 않는다는 것임
두 번째 단계 인코더가 고정 크기 토큰으로 압축하기 때문임
실제로 상당히 유용함
하지만 그렇게 하면 처리하는 전체 문서 집합이 대형 VLM을 반드시 거치게 됨
너무 비싸고 느려질 수 있음
여기엔 분명히 트레이드오프가 있음
대부분의 경우에는 지금 방식이 가장 효과적이었음
무엇이든 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이 그걸 위해 최적화된 반면, 이미지 롱컨텍스트 리콜은 아직 많이 부족함
이미지에서 바로 LLM 변환 레이어를 작게 얹는 것도 꽤 효과적임 (즉 직접 OCR하는 대신, 이미지 5장을 한 번에 소규모 비전 모델에 보내 문서의 가장 중요한 포인트들만 추출하는 방식)
현재는 LLM의 캐시나 어텐션 맵을 수정해서 더 큰 이미지 배치가 잘 작동하도록 연구 중임
슬라이딩 윈도우나 무한 리트리벌 같은 접근법이 유망해 보임
개인적인 추측이지만, 멀티모달 모델의 발전이 가속화되는 걸 보면 곧 이미지 롱컨텍스트도 큰 문제가 안 될 거라 생각함
이 블로그 포스트가 리트리벌에 비전 모델을 사용하는 것에 대해 좋은 지적을 하고 있지만 몇 가지 문제를 짚고 싶음
문서 파싱은 문서를 마크다운/JSON(혹은 추출할 때는 스키마에 맞춘 아웃풋) 같은 구조화된 텍스트로 바꾸는 작업임
그중 하나가 RAG이고, 그 외에도 다양한 용도가 있음
ColPali는 리트리벌에는 훌륭하지만, (최소한 네이티브로는) 순수 문서 파싱에는 쓸 수 없음
저자는 주로 비주얼 리트리벌 벤치마크만 언급함
표준 OCR보다 더 잘 작동하는 경우가 많지만,
a. 여전히 롱테일 정확성 문제가 있음
b. confidence score, bounding box 등 메타데이터가 빠짐
c. 스크린샷 파이프라인 자체도 고도화하려면 노력이 필요함
이미지 토큰이 훨씬 더 강력하지만, 텍스트 토큰은 저장비용이 훨씬 저렴해서 리트리벌 할 때 전체 문서로 쿼리할 수 있음 (chunk 단위가 아니라)
(참고: 나는 llamaindex CEO고 LlamaCloud로 파싱/리트리벌 모두 해봄, 그냥 일반적인 시각임)
작년에 특허 문서 분석 시스템을 만드는 데 시간을 꽤 들임
특허는 추상적 다이어그램, 화학식, 수식 등 다양한 콘텐츠가 포함돼서, LLM에 맞게 데이터를 준비하는 게 정말 까다로움
내가 찾은 가장 간단한 방법은 각 페이지를 “사진 찍듯” 전환한 다음 LLM에게 그 내용을 설명하는 JSON과 메타데이터(페이지 넘버, 시각적 요소 개수 등)를 생성하게 하는 것임
복잡한 이미지는 모델에게 묘사하게 시키면 됨
이렇게 하면 원하는 벡터스토어 등에 JSON을 쉽게 임베딩 가능
비용 대비 효율성은 따져보기 어렵지만, 이 방식이 저자가 제안한 것보다 더 간편하고 효과적임
예를 들어 차트에서 x, y 쌍을 모델이 대부분 잘 뽑더라도, 사용자가 특정 x/y를 꼬집어 물으면 빠뜨릴 수도 있음
모델 추론 단계에서 이미지를 직접 보여주면, 사용자가 묻는 것에 정확히 답할 수 있으므로 이 접근법이 더 효과적임
여기서 유일한 진짜 장애물은 리트리벌의 품질이고, 이건 비교적 작은 문제임
즉, 적절한 컨텍스트 전달만 잘하면 나머지는 LLM이 알아서 커버해줌
그렇지 않으면 OCR, 파싱, 이미지 묘사 등 해야 할 문제가 급격히 늘어남
다만 LLM의 기회는 기존 가치(특허 문서 등)를 재분류/재처리하는 곳에 집중됨을 보여줌
90-00년대는 소프트웨어 기업들이 기존 종이 서류를 DB로 바꿔 사업 성공
새롭고 가치 있는 데이터셋을 처음부터 만들어내는 건 여전히 투자와 노력이 많이 필요함
경험상, 이 방식은 별로임
폰트에 따라 o(오)와 0(영)은 구별이 어려움
문서(doc/xls/pdf/html)를 이미지로 변환하면 그런 구별 정보를 잃게 됨
일련번호 등은 사람도 보고 구별 못하는 경우도 있음
그래서 PDF는 이미지를 렌더링해서 추출하는 게 꽤 합리적임
나머지 포맷은 문서를 직접 파싱하는 게 더 나음
다만 실무적으로 페이지 디자인을 할 때, 실제 이미지를 모델에 보여주는 것이 코드만 전달하는 것보다 디버깅에 훨씬 효과적임
1 vs I, 0 vs O 문제가 실제로 존재하지만, 데이터 자체에 다이어그램/차트가 많은 문서는 이미지만으로 훨씬 쉽게 처리한 경험이 많음
(선택 편향이 있을 수도 있음)
Gemini에 스케줄을 복사해서 질의해보려고 수분간 시도했지만, HTML로 돼있어도 제대로 안 됨
결국 스크린샷을 찍어 필요 없는 부분은 검은 박스로 가리고 이미지를 넣었더니 아주 잘 작동함
멀티모달 RAG로 이미 이 문제가 해결되는 것 같아 궁금함
Flash 2.5, Sonnet 3.7 등으로 꽤 만족스러운 이미지 분석 결과를 얻음
오히려 텍스트에 비해 이미지를 줬을 때 더 좋은 응답을 받는 느낌임
https://www.youtube.com/watch?v=p7yRLIj9IyQ
다만 초기 상태의 멀티벡터(멀티모달 RAG의 근간)는 매우 다루기 어렵고 유사도 계산이 매우 비싸서 스케일업 어려움
양자화, 단일 벡터 변환(고정 차원 인코딩), 인덱싱 최적화 등이 필요함
이게 바로 우리가 Morphik에서 하는 일임
나 역시 모든 청구서를 한꺼번에 스캔해보려고 우편함에서 첨부파일만 추출 후, 하나씩 업로드하는 스크립트를 돌려서 “인보이스: 예/아니요”와, 각 항목/업체명/날짜/인보이스 번호 등을 추출하게 함
결과적으로 판독률 높았고 3시간 넘게 LLM 콜이 걸렸지만 자동화라 신경 안 씀
이후 은행 명세서와 매칭까지 LLM에 시켰고, 첨부파일로 오지 않은 일부 인보이스만 누락됨
단, 인보이스-명세서 매칭은 LLM이 꽤 부실하게 했음(몇 달러 차이만 있어도 그냥 이 명세서라고 답함)
그래서 당분간은 회계사가 필요한 듯
비용은 대충 예상 못 했고, Claude 3.7 같은 저렴한 모델을 씀
ColPali가 직관적이고 강력한 점은 이해하지만, 그래도 문서처리 방식이 가지는 장점들이 있음