멀티모달 RAG: 요약 기반 방식이 충분하지 않은 시점

지난 분기에 한 SaaS 창업자가 익숙하게 들리는 불만 사항을 가지고 저희에게 연락을 해왔습니다. 연구 논문 지식 베이스를 기반으로 구축된 그들의 AI 어시스턴트는 "3분기 매출이 긍정적인 추세를 보이고 있습니다"와 같은 답변만 계속 내놓았고, "3분기 매출은 420만 달러로, 2분기 대비 18% 증가했습니다"와 같은 답변은 하지 못했습니다. 검색(Retrieval)은 올바른 페이지를 찾아냈습니다. 비전 LLM (Vision LLM)은 일관된 응답을 생성했습니다. 파이프라인은 설계된 대로 정확히 작동했습니다. 문제는 설계 자체가 구조적으로 정보 손실(lossy)이 발생하도록 되어 있었다는 점입니다. 이것이 대부분의 팀이 자신들의 멀티모달 RAG (Multimodal RAG) 패턴이 모델의 문제가 아니라 병목 현상(bottleneck)임을 깨닫게 되는 순간입니다.

실제로 일어나고 있었던 일
그들의 파이프라인은 표준적인 요약 기반 방식(대부분의 튜토리얼과 관리형 서비스가 기본으로 채택하는 방식)을 사용하고 있었습니다: PDF를 파싱(Parse)하고, 텍스트 + 표 + 이미지를 추출합니다. 각 이미지를 "이 이미지를 자세히 설명해 주세요"와 같은 프롬프트와 함께 비전 LLM (Vision LLM)에 전달합니다. 결과로 나온 텍스트 요약을 일반 텍스트 청크 (Text chunks)와 함께 임베딩 (Embed)합니다. 쿼리(Query) 시점에는 텍스트 요약을 검색하여 텍스트 LLM (Text LLM)에 전달합니다. 각 단계는 개별적으로 보면 합리적입니다. 누적되는 정보 손실은 50개의 질문으로 구성된 데모에서는 눈에 보이지 않습니다. 하지만 CFO나 분석가가 데이터를 심층적으로 질문하려고 할 때, 어시스턴트가 몇 주 전에 인덱서 (Indexer)가 기록해 둔 내용을 단순히 의역하는 수준에 그칠 때 문제가 드러납니다. 2단계의 비전 LLM (Vision LLM)은 "자세히 설명하라"는 지시를 받았습니다. 그것은 유창한 문장을 만들어냈습니다: "이 차트는 1분기부터 3분기까지 긍정적인 성장 궤도를 보이는 분기별 매출을 보여줍니다." 하지만 축 레이블 (Axis labels), 데이터 포인트 (Data points), 또는 범례 (Legend)를 전사 (Transcribe)하지는 않았습니다. 사용자 쿼리가 도착했을 때, 실제 수치는 인덱스 (Index)에 더 이상 존재하지 않았습니다.

명백한 해결책이 항상 정답은 아닌 이유
이 시점에서 대부분의 팀이 갖는 본능적인 생각은 CLIP이나 SigLIP을 사용하여 "네이티브 멀티모달 (Native multimodal)"로 전환하는 것입니다. 이미지를 텍스트와 공유된 벡터 공간 (Vector space)에 직접 임베딩하고, 쿼리 시점에 원본 이미지를 검색하여 비전 LLM (Vision LLM)이 즉석에서 읽도록 하는 방식입니다. 이 방식은 작동합니다.

또한 쿼리당 비용이 대략 5배에서 10배 더 많이 들고, 멀티 벡터 컬렉션 (multi-vector collections)을 지원하는 벡터 데이터베이스 (vector database)가 필요하며, 운영 범위 (operational surface area)가 두 배로 늘어납니다 (두 개의 임베딩 모델, 이미지 저장소, 인덱싱 시점이 아닌 쿼리 시점의 비전 LLM (Vision LLM) 사용). 20만 달러의 시드 머니 (seed cheque)로 운영하는 B2B SaaS 창업자에게 이러한 전환은 공짜 업그레이드가 아닙니다. 올바른 질문은 손실이 구조적인지, 아니면 기존 패턴 내에서 해결 가능한지 여부입니다. Sapota가 결정하는 방식: 우리는 이 선택을 다음 세 가지 질문 순서에 따라 다룹니다.

1. 정답을 담고 있는 콘텐츠 중 이미지, 차트, 또는 표 (tables)가 차지하는 비중은 얼마인가? 만약 10% 미만이라면, 요약 기반 (summary-based) 방식이 거의 항상 옳은 선택입니다. 아키텍처 (architecture)를 바꾸지 말고 프롬프트 (prompt)를 수정하세요. "차트를 설명하기 전에 보이는 모든 숫자, 축 레이블, 범례를 전사(transcribe)하라"라고 명시하는 프롬프트는 약간 더 긴 요약 비용만으로 손실된 충실도 (fidelity)의 대부분을 회복할 수 있습니다. 만약 10%에서 30% 사이라면, 더 엄격한 이미지 추출 프롬프트를 결합한 요약 기반 방식과 표를 HTML 형식으로 보존하는 방식을 사용하면 대개 기준을 충족합니다. 또한 원본 이미지 URL을 청크 (chunk) 메타데이터에 캐싱(caching)할 것을 권장합니다. 그래야 프론트엔드 (front end)에서 정답 옆에 소스 도표를 인라인 (inline)으로 렌더링할 수 있습니다. 사용자는 모델이 직접 읽지 않았더라도 이를 "AI가 차트를 보여주었다"라고 인식합니다.

2. 30%를 초과한다면, 프롬프트 템플릿 (prompt template)이 변경될 때마다 발생하는 지속적인 재인덱싱 (re-indexing) 비용으로 인해 파이프라인의 비용이 정당화되기 시작합니다. 이 지점이 네이티브 멀티모달 (native multimodal) 방식이 운영상의 복잡성을 감수할 가치가 있는 지점입니다. 사용자의 쿼리가 "유사한 시각적 요소 보여줘"와 같은 검색으로부터 이득을 얻는가? 패턴 A는 이미지 대 이미지 (image-to-image) 검색을 수행할 수 없습니다. 만약 제품에 진정으로 "이것과 비슷해 보이는 슬라이드를 찾아줘" 또는 "이 제품 사진을 우리 카탈로그와 매칭해줘"와 같은 기능이 필요하다면, 해당 기능은 요약 기반 파이프라인에는 존재하지 않으며 앞으로도 존재하지 않을 것입니다. CLIP을 추가하는 것이 유일한 경로입니다.

3. 쿼리당 비용의 상한선은 얼마인가? 쿼리 시점의 비전 LLM (Vision LLM) 호출 비용은 제공업체에 따라 이미지당 대략 $0.005에서 $0.03 사이입니다.

상위 5개의 이미지를 Claude 또는 GPT-4V 호출로 가져오는 파이프라인은 입력 텍스트 토큰(tokens) 비용을 제외하고 질문당 $0.05에서 $0.15가 소요됩니다. 한 달에 10,000건의 쿼리가 발생한다면 이는 $500에서 $1,500에 달합니다. 소비자 대상 어시스턴트라면 괜찮은 수준이지만, 일주일에 한 번 실행되는 내부 컴플라이언스(compliance) 도구라면 계산이 달라집니다.

창업자를 위해 우리가 출시한 솔루션: 진단 결과, 전체 코퍼스(corpus)의 약 20%가 차트와 표였으며, 사용자 쿼리 분포는 "유사한 다이어그램을 찾아줘"가 아니라 거의 전적으로 "X의 값은 무엇인가"에 집중되어 있었고, 이미 비용에 민감한 상태였습니다. 패턴 B (Pattern B)로 완전히 마이그레이션하는 것은 과잉 엔지니어링 (over-engineering)이 될 것이었습니다.

해결책은 패턴 A (Pattern A) 내부에서 세 가지를 변경하는 것이었습니다:

1. 이미지 추출 프롬프트 (Image extraction prompt) 재작성: "이 이미지를 설명해줘"를 차트 유형, 축 레이블 (axis labels), 전사된 데이터 포인트 (transcribed data points), 범례 (legend entries)를 요청하고 그 후에만 한 문장의 해석을 제공하도록 하는 구조화된 템플릿으로 교체했습니다. 요약 길이는 두 배로 늘어났지만 정밀도 (precision)를 회복했습니다.
2. 청크 메타데이터 내 HTML 형식의 표 보존: 기존의 비구조화된 파서 (unstructured parser)는 이미 text_as_html을 생성하고 있었으나, 인덱서 (indexer)가 이를 버리고 있었습니다. 우리는 이를 저장하기 시작했고, 답변 시점에 LLM 프롬프트에 인라인 (inline)으로 포함했습니다.
3. 이미지 URL 패스스루 (Image URL passthrough): 이제 모든 차트 요약에는 소스 이미지의 원래 S3 URL이 포함됩니다. 프런트엔드는 답변과 함께 이미지를 렌더링합니다. 사용자는 어시스턴트가 잘못 읽었을 때 소스를 직접 볼 수 있으므로 스스로 수정할 수 있습니다.

80개의 질문으로 구성된 내부 평가 세트 (eval set)에서 수치 관련 질문의 재현율 (recall)은 "자주 틀림"에서 "반올림 범위 내에서 수동 분석가와 일치함" 수준으로 올라갔습니다. 벡터 데이터베이스 (vector database) 마이그레이션도 없었고, 쿼리 시점의 비전 LLM (Vision LLM) 호출도 없었습니다. 비용은 그대로 유지되었습니다.

패턴 B로 전환해야 하는 시점은 다음과 같습니다:

• 코퍼스가 구조적으로 시각적인 경우: 제품 카탈로그, 과학적 다이어그램, 슬라이드 덱, 인포그래픽 등.
• 이미지 대 이미지 검색 (Image-to-image retrieval)이 있으면 좋은 기능이 아니라 실제 제품 요구사항인 경우.
• 법률 또는 의료 문맥에서 모델이 의역이 아닌 실제 결과물을 직접 보아야 하는 경우.

컴플라이언스 검토자(Compliance reviewers)들은 "AI가 X-ray를 요약했습니다"라는 말은 거부하겠지만, "AI가 X-ray를 판독했습니다"라는 말은 수용할 것입니다. 여러분은 멀티 벡터 벡터 DB (Qdrant, Weaviate)를 운영할 수 있는 성숙도를 갖추고 있으며, 쿼리 시점에 Vision LLM을 사용할 예산도 확보하고 있습니다. 우리가 가장 자주 목격하는 실수는, 요약 기반 방식이 "한계가 있다고 느껴진다"는 이유로 팀들이 곧바로 패턴 B(Pattern B)로 넘어가는 것입니다. 하지만 실제로는 프롬프트(Prompt)가 부실했거나 검색 후 렌더링(Post-retrieval rendering) 과정이 누락되었던 경우가 많습니다.

ColPali에 대하여: 문서 중심의 유스케이스(연구 논문, 금융 공시, 슬라이드 덱 등)를 위해 알아둘 가치가 있는 세 번째 옵션이 있습니다. ColPali는 OCR/추출 파이프라인을 완전히 건너뛰고 각 페이지를 단일 이미지로 취급하며, 시각-언어 모델(Vision-language model)을 사용하여 패치 수준의 임베딩(Patch-level embeddings)을 계산합니다. 공개된 벤치마크에서 시각적으로 복잡한 문서에 대해 패턴 A와 패턴 B 모두보다 뛰어난 성능을 보여주지만, 바이-인코더(Bi-encoder)보다 32배 높은 저장 비용이 발생하며 GPU 추론(GPU inference)이 필요합니다. 이는 별도의 논의 가치가 있는 주제이며, 다음 글에서 상세히 다룰 예정입니다.

만약 이러한 트레이드오프(Trade-off) 문제에 직면해 있다면, Sapota는 멀티모달 RAG를 출시하는 팀을 위해 아키텍처 리뷰를 제공합니다. 작동 중인 파이프라인, 대표적인 평가 세트(Eval set), 그리고 질문 분포 샘플을 바탕으로, 여러분의 구체적인 비용 및 재현율(Recall) 제약 조건에 맞춰 어떤 패턴이 적합한지에 대한 구체적인 권장 사항을 제시합니다. 만약 여러분의 AI 어시스턴트가 사용자가 숫자를 원할 때 차트를 의역하거나, 환각(Hallucination)으로 판명된 숫자를 인용하고 있다면, 그것이 바로 우리가 진행하는 진단 상담의 대상입니다. AI 엔지니어링 페이지를 통해 연락하여 현재 겪고 있는 상황을 알려주세요.