멀티모달 RAG Multimodal RAG

쓸 수 있는 것에만
갇혀 있던 지식

여기까지 대체로 텍스트 기반 RAG에 집중했다. 응답을 근거지우는 지식은 글로 쓸 수 있는 것에 갇혀 있었고, 표와 이미지와 음성과 영상으로 표현된 지식은 무시되었다.

현실에서 기업의 지식은 여러 모달리티로 존재한다. 재무 보고서의 손익(P&L) 표, 작업자 매뉴얼의 시각적 지시, 고객 서비스 통화에 담긴 말의 미묘함이 그런 것들이다. 차트를 보고 통화를 듣고 표를 읽을 능력이 없으면 RAG 시스템의 정확도는 상한다. 텍스트 문서에 근거한 고품질 답변은 내놓지만, 정확한 답에 필요한 정보가 표나 이미지 안에 있을 때는 저품질이거나 환각된 응답을 내놓는다.

이 지형을 항해하려면 프로덕션 환경에서 “멀티모달”이 어떤 모습인지 분명히 해두는 것이 도움이 된다. 원시 음성과 영상을 텍스트처럼 손쉽게 소비하는 단일 “네이티브” 멀티모달 모델이 꿈이지만, 현실은 흔히 더 복잡하다. 실무에서 엔터프라이즈 멀티모달 RAG의 현재 접근은 대개 두 범주 가운데 하나에 속한다.

이 장은 변환 접근에 집중한다. 신뢰성과 관측성 면에서 여전히 업계 표준이기 때문이다. 그러면서 네이티브 멀티모달 역량이 이 복잡한 파이프라인을 어떻게 단순화하기 시작했는지도 함께 내다본다.

표가 박힌 문서

대다수 엔터프라이즈 환경에서 값이 높은 문서 다수가 중요한 정보를 전달하는 표를 품고 있으면서, 그것을 파이프라인에 반영하기 위해 전문적인 전략을 요구한다.

표가 왜 중요한가

표는 SEC 보고서, 연구 논문, 제품 매뉴얼 같은 복잡한 문서에서 꽤 흔하다. 주변 텍스트가 서술이나 정성적 분석을 제공한다면, 표 자체는 고밀도의 구조화된 “진실의 원천”을 담은 구별되는 의미론적 마이크로 문서로 기능한다.

모든 산업과 사용 사례에서 표는 흔히 극히 값진 정보를 담는다. 그러나 이 효용에는 상당한 구조적 복잡성이 따라온다. 엔터프라이즈 표는 불규칙한 행 높이, 논리 계층을 넘나드는 병합 셀, 특정한 각주를 빈번히 갖추고 있어, 정보가 풍부하면서도 처리하기 계산상 까다로운 구성요소가 된다.

문서에서 표를 추출하기

표를 제대로 처리하는 첫 단계는 표의 표현을 디지털 형식으로 추출하는 일이다. 보통 세 개의 구별되는 단계를 거친다.

도구의 지형 — 상용과 오픈소스

이 모든 단계를 상용 서비스나 오픈소스 소프트웨어로 구현할 수 있다.

상용 관리형 서비스는 강력한 OCR이 요구되는 스캔 문서, 이미지, 필기를 다룰 때 훌륭한 선택이다. Amazon Textract가 강한 업계 표준으로 여겨지고, Azure Document Intelligence와 Google Cloud Document AI가 강력한 대안이다. API 호출로만 제공되므로, 클라우드 호출의 추가 비용과 지연이 우월한 OCR의 필요로 정당화되는, 스캔된 고가치 문서에 남겨 두는 것이 좋다. 프로덕션 적재 파이프라인이 온프레미스나 외부와 차단된 에어갭 환경에 있다면 이 서비스는 아예 쓸 수 없다. LlamaParse는 최근의 또 다른 선택지로 PDF, PPTX 등을 지원하며 텍스트·표·이미지·다이어그램을 추출해 마크다운으로 출력한다. 코드는 오픈소스이지만 LlamaCloud 사용을 요구하는 상용 제품이다.

오픈소스 라이브러리는 로컬에서 무료로 돌고 “네이티브” 디지털 파일에는 흔히 더 나은 선택이다. IBM의 Docling과 Unstructured는 AI/LLM 워크플로를 위해 설계된 오픈소스 패키지로, 병합 셀과 표 헤더를 보존하는 복잡한 구조 이해에 뛰어나며 파이프라인에 곧바로 쓸 수 있는 깨끗한 JSON이나 HTML로 변환한다. gmft는 표 추출(우리 3단계 과정의 첫 단계)만 전문으로 하며 병합 셀, 다중 수준 헤더, 이미지 기반 표를 지원한다. 이 로컬 도구들은 에어갭 배포나, 클라우드 API 비용이 감당 못 할 만큼 커지는 대량 처리의 일차 선택이다.

# pip install --quiet docling
from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.pipeline_options import PdfPipelineOptions
from docling.datamodel.base_models import InputFormat

pipeline_options = PdfPipelineOptions()
pipeline_options.generate_picture_images = True

res = DocumentConverter(
    format_options={
        InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline_options),
    }
).convert(local_file)
doc = res.document

# doc은 텍스트 · 표 · 이미지 전체에 접근한다. 여기서는 표만 본다.
table = doc.tables[13]
table_df = table.export_to_dataframe()

table = doc.tables[10]
table_df = table.export_to_dataframe()
print(table_df.shape)

순진한 청킹이 표에서 실패하는 이유

표를 추출했다고 해서 그것을 일반 텍스트처럼 청킹하고 임베딩할 수는 없다. 제품 정보를 담은 표를 마크다운으로 표현하고 표준 텍스트 처리를 적용하면 무슨 일이 벌어지는지 보자.

raw_text = df.to_markdown()

from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=100,     # 파열을 보이기 위해 의도적으로 작게
    chunk_overlap=20    # 작은 겹침
)
chunks = text_splitter.split_text(raw_text)

문제는 청킹이 맥락의 유실을 야기한다는 점이다. 첫 청크는 헤더 행과 마크다운 구분선을 올바르게 포착한다. 그러나 이후의 모든 청크는 “머리 없는(headless)” 상태로, 표 아래쪽의 두 행만 담고 있다.

RAG를 위해 표를 처리하는 방법

표를 제대로 처리하는 흔한 관행은 표를 JSON 구조로 변환하는 것이다(마크다운 형식도 훌륭한 선택이다). 표를 행의 목록으로 표현하고, 각 행은 열 이름을 키로, 셀 값을 값으로 갖는 딕셔너리가 된다.

{
  "('Product', '')": {
    "0": "Model-A", "1": "Model-B",
    "2": "Model-C", "3": "Model-X"
  },
  "('Price', 'USD')": {
    "0": "$299", "1": "$449",
    "2": "$199", "3": "$899"
  },
  "('Price', 'EUR')": {
    "0": "€257.25", "1": "€386.95",
    "2": "€171.50", "3": "€774.77"
  },
  "('Rating', '')": {
    "0": "4.5 Stars", "1": "4.2 Stars",
    "2": "3.9 Stars", "3": "4.8 Stars"
  }
}

다음 단계는 이 표를 LLM에 보내 내용의 포괄적 요약을 요청하고, 그 요약을 전체 표 내용을 가리키는 특수한 유형의 청크로 저장하는 일이다. 질의 시점에 그 요약 청크가 질의에 관련된다고 판단되면 표의 전체 내용을 끌어와 완전한 표를 생성 LLM의 맥락으로 제공한다.¹

import json
import pandas as pd

def format_context_item(item, max_rows=100):
    """문자열, 데이터프레임, 중첩 JSON을 안전 점검과 함께 동적으로 포맷한다."""
    # 1. 표준 텍스트 청크
    if isinstance(item, str):
        return f"- FACT: {item}"

    # 2. 데이터프레임 — 스키마가 동적이다
    if isinstance(item, pd.DataFrame):
        # 표가 너무 길면 잘라내되 헤더는 지킨다
        if len(item) > max_rows:
            item = item.head(max_rows)
            truncation_note = f"\n[Note: Table truncated to first {max_rows} rows]"
        else:
            truncation_note = ""
        return f"""- DATAFRAME (Columns: {list(item.columns)}):
{item.to_json(orient='records', indent=2)}{truncation_note}"""

    # 3. 일반 구조화 데이터(JSON/Dict)
    try:
        return f"- STRUCTURED DATA:\n{json.dumps(item, indent=2)}"
    except (TypeError, ValueError):
        return f"- DATA (Raw): {str(item)}"

formatted_context = "\n".join(format_context_item(c) for c in context)

prompt = f"""
You are an assistant for question-answering tasks. Use the following pieces of
retrieved context to answer the question. If you don't know the answer, just say
that you don't know.

<question>{question}</question>
<context>{formatted_context}</context>
Answer:
"""

이 프롬프트로 생성 LLM은 “보통” 사실은 전과 같이 텍스트 문자열로 받고, 표 정보는 포맷된 JSON으로 받는다. 그래서 그것을 표로 인식하고 셀 수준의 모든 정보에 접근해 필요할 때 사용자 질문에 답할 수 있다.

여러 페이지에 걸친 표 다루기

표가 여러 페이지에 걸치면 물리적 레이아웃이 데이터의 논리적 연속성을 끊어 놓는다. 대부분의 파서가 하나의 긴 표를 두 개 이상의 별개 표로 해석하기 때문에 독특한 난관이 된다.

이 단편화는 두 개의 구별되는 문제를 만든다. 중복과 모호성이다. 서식이 잘 갖춰진 문서에서는 사람이 읽기 편하도록 새 페이지 상단에 헤더 행이 반복되는 일이 많다. 이를 제대로 처리하지 않으면 데이터셋에 중복 헤더가 주입된다. 반대로 헤더가 반복되지 않으면 표의 두 번째 부분은 앞서 서술한 청킹 문제와 비슷하게 “머리 없는” 숫자 행렬이 되어, 모델이 열의 의미론적 정의를 잃는다.

이에 대응하려면 초기 추출 이후 “스티칭” 계층으로 작동하는 후처리 발견법을 구현할 수 있다. 연속된 페이지에 걸친 표들의 근접성과 구조를 분석하는 일이다. “표 A”가 N페이지 하단에서 끝나고 “표 B”가 N+1페이지 상단에서 동일한 열 개수와 호환되는 데이터 타입으로 시작한다면(예컨대 3열이 두 쪽 모두 통화 데이터라면) 시스템은 그것을 하나의 실체로 취급해야 한다. 두 번째 단편에서 반복된 헤더가 검출되면 데이터 오염을 막기 위해 프로그램적으로 제거해야 한다. 논리적 연속성이 확립되면, 요약이나 임베딩이 일어나기 전에 단편들을 하나의 마스터 데이터프레임이나 JSON 객체로 이어 붙여야 한다.

예로 유엔 경제사회국의 World’s Women 2010 PDF를 보자. 여섯 페이지에 걸친 하나의 표를 담고 있다. Docling으로 표를 추출하면 여섯 개의 별개 표가 나온다.

fragments = []
for table in doc.tables:
    df = table.export_to_dataframe(doc)
    page = table.prov[0].page_no if table.prov else 0
    fragments.append({'df': df, 'page': page})
    print(f"Page {page}: {df.shape[0]:>2} rows × {df.shape[1]} cols")

def has_duplicate_header(df):
    """첫 데이터 행이 열 이름을 그대로 반복하는지 확인한다."""
    if len(df) == 0:
        return False
    first_row = [str(v).strip() for v in df.iloc[0]]
    columns = [str(c).strip() for c in df.columns]
    return first_row == columns


def stitch_tables(extracted_tables):
    """열 개수가 일치하는 연속 단편을 이어 붙인다."""
    if not extracted_tables:
        return []

    tables = sorted(extracted_tables, key=lambda t: t['page'])
    result = []
    current = tables[0]['df'].copy()
    current_page = tables[0]['page']

    for entry in tables[1:]:
        next_df = entry['df'].copy()
        next_page = entry['page']

        if next_page == current_page + 1 and \
           next_df.shape[1] == current.shape[1]:
            if has_duplicate_header(next_df):
                print(f'  Page {next_page}: removing dup header row')
                next_df = next_df.iloc[1:].reset_index(drop=True)
            next_df.columns = current.columns
            print(f'  Stitching page {current_page} + {next_page}'
                  f' → {len(current) + len(next_df)} rows')
            current = pd.concat([current, next_df], ignore_index=True)
        else:
            result.append(current)
            current = next_df
        current_page = next_page

    result.append(current)
    return result

stitched = stitch_tables(fragments)

여섯 페이지의 표를 모두 이어 붙인 최종 표는 205행이다. 적재 전에 표를 통일해 두면, 질의 시점에 사용자 질문에 답할 가장 관련성 높은 정보를 얻기 위해 LLM이 전체 데이터셋에 접근할 수 있다.

그러나 복잡한 문서에 박혀 있는 모달리티는 표만이 아니다. 아주 흔하게 이미지가 있다.

이미지가 박힌 문서

“그림 한 장이 천 마디 말의 값을 한다”는 오랜 격언이 RAG 애플리케이션에 완벽히 적용된다. 그러나 LLM이 손쉽게 해석할 수 있는 정의된 구조를 가진 표와 달리, 이미지와 다이어그램에는 그런 구조가 없어 지원이 더 까다롭다.

NASA 기술 핸드북 36쪽의 순서도를 생각해 보자. PDF에 박힌 다이어그램이다. 텍스트 전용 RAG는 “Figure 10—Flowdown and Traceability of Needs, Goals and Objectives”라는 텍스트와 상자 안이나 화살표 근처의 일부 텍스트를 찾아낼 수 있다. 그러나 공간 관계와 전체 맥락을 놓치고, 노드 사이의 관계에 관한 질문에는 답하지 못할 가능성이 높다.

다이어그램과 순서도가 소프트웨어로 생성된 합성 도해라면, 많은 경우 문서에는 픽셀만으로 된 순수한 이미지가 박혀 있다. 미국 국립의학도서관(NLM)의 2014 회계연도 예산 설명 자료 9쪽의 이미지들이 그런 예다. 이 이미지들은 모두 래스터 그래픽이다. 제목과 축 라벨 같은 텍스트 요소가 비트맵에 눌려 있어 OCR 없이는 기계가 읽을 수 없다. 게다가 상당한 데이터가 막대 높이, 파이 차트 섹터, 색 변이 같은 시각적 속성만으로 부호화되어 있다.

그러므로 기술적 난제는 이렇다. 이미지나 다이어그램을 어떻게 검색 가능하면서 해석 가능하게 만드는가. 텍스트 기반 구성요소는 텍스트를 읽는 방식으로 픽셀을 “읽을” 수 없다. 이를 풀기 위해 적재 단계에서 보통 두 전략 가운데 하나를 채택한다. 선택은 흔히 선행 비용과 질의 시점 지능 사이의 교환으로 귀결된다.

이미지 요약 접근

이 접근에서는 시각 데이터를 표준 RAG 검색 파이프라인이 손쉽게 이해하는 텍스트 기반 형식으로 변환한다. 시각 정보를 사실상 또 하나의 텍스트 지식으로 취급해, 전문 멀티모달 임베딩 모델 없이도 기존 청크와 나란히 색인할 수 있게 한다.

과정은 적재 단계에서 시작한다. 이미지를 버리거나 원시 픽셀을 임베딩하려 하는 대신, 각 이미지를 유능한 비전-언어모델(GPT-5, Gemini 3, Claude 4.5 등)에 관련 세부를 뽑아내도록 설계된 프롬프트와 함께 통과시킨다.

Analyze all the details in this image, including any diagrams, graphs, or visual
data representations. Your task is to provide a concise but comprehensive
summary of the image (4-6 sentences) with as much detail as possible. Your
response should include:

- A detailed description of the main focus or subject of the image.
- For any diagrams or graphs: what information they convey, a detailed
  description of the data, and any observed trends or conclusions that can be
  drawn.
- Any other detail or information that a human observer would find useful or
  relevant.
- Respond in complete sentences, and aim to provide a comprehensive and
  informative response.
- For any schemas or flowcharts, describe them in a way that a human reading
  your description could recreate the diagram.
- Any specific text that is shown in the image (with context).

If you are unable to summarize it, respond with an empty string. Do not respond
with "I can't do that" or similar.

VLM이 포괄적인 텍스트 요약을 생성하고, 그것이 검색을 위한 “청크”가 된다. 결정적으로 원본 이미지는 AWS S3 같은 객체 저장소에 별도로 저장하고, 텍스트 청크의 메타데이터에 참조 링크나 ID를 유지한다. 사용자가 질의하면 파이프라인은 평소처럼 관련 청크를 검색하고, 이미지 요약 청크가 관련된다면 파이프라인의 생성 LLM 유형에 따라 두 가지 선택지가 있다.

• 생성 모델이 텍스트 전용이면 검색된 요약을 맥락으로 그냥 먹인다. 적재 시점에 생성된 이미지 요약에 근거해 질문에 답하게 된다.
• 최종 생성에 VLM을 쓴다면 저장된 ID로 원본 이미지 파일을 가져와 실제 이미지 바이트를 (보통 Base64로) 컨텍스트 창에 넣는다. 그러면 모델이 답변 생성 중에 이미지를 다시 “볼” 수 있어 최종 응답의 충실도가 가장 높아진다.

세 개의 벡터 스토어로 비교하기

LangChain 예제 코드로 이것을 확인한다. 앞의 NLM 2014 보고서를 쓴다. 벡터 스토어 세 개를 만든다. 원시 텍스트만(이미지 무시), 텍스트와 이미지 요약, 그리고 실제 이미지 바이트를 저장하는 완전 멀티모달이다.

CHROMA_DB_DIR = "chroma_db"

def build_vectorstore(chunks: List[Dict], persist_dir: str,
                      include_image_summaries: bool = True):
    """이미지 요약을 포함하거나 제외한 텍스트 벡터 스토어를 만든다."""
    suffix = "_with_summaries" if include_image_summaries else "_text_only"
    full_path = _safe_persist_path(persist_dir + suffix)

    # 버전 불일치와 문서 중복을 피하려 낡은 DB를 제거한다
    if os.path.exists(full_path):
        shutil.rmtree(full_path)

    vectorstore = Chroma(
        collection_name=f"nlm_report{suffix}",
        embedding_function=embeddings,
        persist_directory=full_path
    )

    filtered_chunks = (chunks if include_image_summaries
                       else [c for c in chunks if c['type'] == 'text'])

    documents = [
        Document(
            page_content=chunk['text'],
            metadata={**chunk['metadata'],
                      'page': chunk['page'],
                      'chunk_type': chunk['type']}
        )
        for chunk in filtered_chunks
    ]
    vectorstore.add_documents(documents)
    return vectorstore

text_only_vectorstore  = build_vectorstore(chunks, CHROMA_DB_DIR,
                                           include_image_summaries=False)
summaries_vectorstore  = build_vectorstore(chunks, CHROMA_DB_DIR,
                                           include_image_summaries=True)

def query_text_rag(vectorstore: Chroma, query: str, top_k: int = 5) -> str:
    """텍스트 검색기로 RAG에 질의한다(텍스트 전용과 요약 포함 모두 동작)."""
    llm = ChatOpenAI(model="gpt-4.1-mini", temperature=0.1)
    retriever = vectorstore.as_retriever(search_kwargs={'k': top_k})

    template = """Answer the question based only on the following context:
<context>
{context}
</context>
Your response should include the answer to the question without mention of
the context. Do not use your internal knowledge to answer the question.

Question: {question}
Answer:"""
    prompt = ChatPromptTemplate.from_template(template)

    def format_docs(docs):
        return "\n\n".join(doc.page_content for doc in docs)

    rag_chain = (
        {"context": retriever | format_docs, "question": RunnablePassthrough()}
        | prompt | llm | StrOutputParser()
    )
    return rag_chain.invoke(query)

같은 질의를 세 구성에 던진다. “What was the growth of GenBank Base Pairs between PubMed and PubMed Central?”

첫 답변은 좋지 않다. 질문에 관련된 상당한 정보를 담은 이미지를 포함하지 않았으니 예상된 결과다. 요약을 쓰면 훨씬 나아진다. 그리고 실제 이미지를 VLM에 넘기면 최선의 답을 얻는다. “높은 성장”이라고 뭉뚱그리는 데 그치지 않고 염기쌍의 수치까지 알려 준다. 그 정보는 LLM과 공유된 시각 그래프에서만 얻을 수 있다.

def query_with_actual_images(retriever: MultiVectorRetriever, query: str,
                              top_k: int = 5):
    """MultiVectorRetriever로 실제 이미지를 VLM에 보낸다."""
    retriever.search_kwargs = {'k': top_k}

    # 메타데이터 접근을 위해 요약 문서를 먼저 가져온다
    summary_docs = retriever.vectorstore.similarity_search(query, k=top_k)

    # doc_id로 docstore에서 실제 내용을 조회한다
    doc_ids = [doc.metadata.get('doc_id') for doc in summary_docs]
    raw_contents = retriever.docstore.mget(doc_ids)

    def split_image_text_types(summary_docs, raw_contents):
        """메타데이터로 이미지와 텍스트를 분리한다."""
        images, texts = [], []
        for doc, content in zip(summary_docs, raw_contents):
            if content is None:
                continue
            if doc.metadata.get('type') == 'image':
                images.append(content)   # base64 문자열
            else:
                texts.append(content)
        return {"images": images, "texts": texts}

    context = split_image_text_types(summary_docs, raw_contents)

    content = [{"type": "text", "text": f"""
Answer the question based on the provided context and images.
<context>{chr(10).join(context['texts'])}</context>
Question: {query}
Answer:"""}]

    # 이미지를 Base64 데이터 URL로 붙인다
    for img_base64 in context['images']:
        content.append({
            "type": "image_url",
            "image_url": {"url": f"data:image/png;base64,{img_base64}"}
        })

    llm = ChatOpenAI(model="gpt-4.1-mini", temperature=0.1)
    return llm.invoke([HumanMessage(content=content)]).content

앞의 query_text_rag와 달리 이 함수는 일치하는 텍스트와 원본 이미지를 함께 검색한다. 이미지 요약이 일치하면 시스템은 기저 문서 저장소로 되돌아가 실제 Base64 이미지 바이트를 가져온다. 이 원시 이미지를 VLM에 직접 제공하면 모델이 텍스트 서술에만 의존하지 않고 복잡한 차트나 다이어그램 같은 원본 시각 데이터에 대해 추론할 수 있다.

공유 임베딩 공간을 이용한 멀티모달 검색

이미지 요약 방법과 대비되는 이 접근은 이미지와 텍스트를 공유 벡터 공간(임베딩 공간)에 직접 사상한다. 시각 데이터와 텍스트 질의를 같은 근원적 실재를 서술하는 두 개의 다른 언어로 사실상 취급한다. 이미지를 영어 텍스트로 번역하는 대신, OpenAI의 CLIP, OpenCLIP, 구글의 SigLIP, 메타의 ImageBind, LanguageBind 같은 멀티모달 임베딩 모델로 두 모달리티를 공유된 “잠재 공간”으로 번역한다.

학습 중에 모델은 이미지–텍스트 쌍의 방대한 데이터셋을 받고(고양이 사진과 “a cute cat”이라는 캡션), 대조 표현 학습²이라는 기법을 쓴다. 이미지와 그에 대응하는 텍스트의 벡터 임베딩을 수학적으로 서로 당기고, 무관한 쌍은 멀리 밀어낸다. 결과는 통일된 잠재 공간을 가진 모델이다. 이미지에 메타데이터도 태그도 다른 텍스트 주석도 전혀 없어도, “자동차”라는 텍스트 개념의 벡터가 자동차 이미지에서 나온 벡터와 수학적으로 가까워진다.

실무 파이프라인에서 이는 적재 단계를 유의미하게 정돈해 준다. 모든 이미지를 문장으로 요약하기 위해 연산이 비싼 VLM을 호출할 필요가 없어진다. 대신 원시 이미지를 모델의 비전 인코더에 통과시켜 임베딩 벡터를 생성하고 벡터 데이터베이스에 색인한다. 사용자가 “a dog”라고 질의하면 시스템이 그 텍스트를 텍스트 인코더에 통과시키고, 표준 벡터 유사도 검색으로 의미상 가장 가까운 이미지를 검색한다.

device = "cuda" if torch.cuda.is_available() else "cpu"
model_id = "google/siglip-so400m-patch14-384"
model = AutoModel.from_pretrained(model_id).to(device)
processor = AutoProcessor.from_pretrained(model_id)

image_inputs = processor(images=images, return_tensors="pt", padding=True).to(device)
with torch.no_grad():
    image_features = model.get_image_features(**image_inputs)
    # 코사인 유사도를 위해 정규화가 결정적이다
    image_features = image_features / image_features.norm(p=2, dim=-1, keepdim=True)

def retrieve_images(query_text, top_k=1):
    """SigLIP으로 질의에 맞는 이미지를 검색한다."""
    # SigLIP은 일관된 텐서 형태를 위해 max_length 패딩을 선호한다
    text_inputs = processor(text=[query_text], return_tensors="pt",
                            padding="max_length").to(device)

    with torch.no_grad():
        # 1. 텍스트 임베딩과 정규화
        text_features = model.get_text_features(**text_inputs)
        text_features = text_features / text_features.norm(p=2, dim=-1, keepdim=True)

        # 2. 내적 — 정규화했으므로 코사인 유사도와 같다
        raw_scores = (text_features @ image_features.t())

        # 3. 모델이 학습한 스케일과 바이어스를 적용한다
        logits = (raw_scores * model.logit_scale.exp()) + model.logit_bias

        # 4. 시그모이드로 확률을 계산한다
        sigmoid_probs = torch.sigmoid(logits)

    top_probs, indices = torch.topk(sigmoid_probs, top_k)
    ...

raw_scores = (text_features @ image_features.t())가 무거운 일을 한다. 텍스트 질의 벡터와 이미지 벡터의 전치를 행렬 곱한다. 사전에 모든 벡터를 정규화해 크기를 1로 만들었으므로, 이 연산은 질의와 목록의 모든 이미지 사이의 코사인 유사도를 동시에 계산하는 것과 수학적으로 동등하다. 물론 이 메모리 내 “완전 탐색”은 무차별 대입이며 시연을 위한 것이다. 실제 파이프라인에서는 2장에서 서술한 ANN 벡터 검색으로 대체한다.

공유 임베딩의 강점과 명확한 한계

공유 임베딩 공간 접근은 명시적 키워드나 수작업 태깅 없이 개념과 객체와 미감을 식별할 수 있다. 특정한 시각적 질감, 스타일, 공간 관계처럼 텍스트 요약으로 서술하기 어려운 것을 검색하게 해준다(“자연광이 드는 현대적 거실” 같은 질의). 게다가 ImageBind나 LanguageBind 같은 모델은 이 개념을 더 확장해 텍스트와 이미지만이 아니라 음성이나 깊이 데이터까지 공유 공간에 넣어 진정한 멀티모달 질의를 가능하게 한다.

표준 CLIP이나 SigLIP 임베딩 모델은 어떤 이미지가 “매출을 보여 주는 막대 차트”임은 이해할 수 있지만, 벡터 자체에 구체적 수치나 세밀한 추세선까지 담아내지는 대체로 못한다. 이유는 학습 손실 함수에 있다. 텍스트와 이미지 쌍을 맞추기 위해 이 모델들은 모든 세부를 정밀하게 이해할 필요가 없고, 텍스트와 맞출 만큼의 이미지 의미론만 충분히 이해하면 된다. 그러므로 이 접근은 사진·슬라이드·제품 카탈로그처럼 시각 중심 데이터셋에 가장 적합하고, 이미지 안의 데이터와 텍스트와 그래프를 검색하고 이해해야 하는 “추론”이 필요할 때는 요약 접근이 일반적으로 선호된다.

더 나아가 공유 임베딩은 표준 파이프라인의 하류 구성요소, 구체적으로 하이브리드 검색과 재순위에 추가적 마찰을 들여온다. 대부분의 하이브리드 검색 구현은 BM25 같은 희소 벡터 방법에 의존하며 그것은 작동하려면 텍스트 토큰이 필요하다. 원시 이미지에는 텍스트 토큰이 없으므로 별도의 캡셔닝 단계 없이는 키워드 기반 검색이 불가능하다. 마찬가지로 검색 정확도 향상에 필수적인 표준 크로스 인코더 재순위기는 거의 전적으로 텍스트–텍스트 쌍으로 학습되어 있다.

RAG의 음성과 영상

음성과 영상 데이터는 사실을 아는 것과 그것을 진짜로 경험하는 것 사이의 결정적 간극을 잇는다. 텍스트 기반 RAG가 무엇이 말해졌는지를 포착한다면, 그것이 어떻게 말해졌는지(어조)와 무엇이 보였는지(시각적 맥락)에는 흔히 눈이 멀어 있다. 프로덕션 엔터프라이즈 환경에서 방대한 기능적 지식이 이 형식들에 잠겨 있다. 줌 전략 회의에서 합의를 만들어 가는 고갯짓에서, 공장 현장의 수리를 시연하는 기술 영상에까지.

기준선 — 고충실도 전사

멀티미디어를 시스템에 넣는 가장 직접적인 방법은 그것을 텍스트 추출 문제로 취급하는 것이다. 파일에서 음성 트랙을 벗겨내 OpenAI의 Whisper, 구글의 Chirp, Deepgram의 Speech to Text API 같은 자동음성인식 모델에 통과시킨다.

청킹은 어떻게 하는가. 전사 텍스트의 흔한 접근은 여러 화자 턴을 함께 묶는 것이다. 보통 정해진 토큰 수(예컨대 512토큰)를 목표로 하되, 화자의 문장이 중간에서 잘리지 않도록 절단점이 문장 경계를 존중하게 한다.

import os, json, sys
from deepgram import DeepgramClient

deepgram_api_key = os.getenv("DEEPGRAM_API_KEY", None)
if not deepgram_api_key:
    print("Please setup your DeepGram API KEY")
    sys.exit(1)

AUDIO_URL = ("https://static.deepgram.com/examples/"
             "en_NatGen_CallCenter_BethTom_CancelPhonePlan.wav")

deepgram = DeepgramClient(api_key=deepgram_api_key)
response = deepgram.listen.v1.media.transcribe_url(
    url=AUDIO_URL,
    model="nova-2",
    smart_format=True,
    diarize=True,      # 화자 분할
    utterances=True    # 발화 단위로 반환
)

chunks = []
current_chunk_text = []
current_chunk_meta = {"start": None, "end": None, "speakers": set()}
WORD_LIMIT = 512

utterances = response.results.utterances
for u in utterances:
    speaker = f"Speaker {u.speaker}"
    text = u.transcript
    timestamp = u.start

    # 새 청크의 시작 시간을 초기화한다
    if current_chunk_meta["start"] is None:
        current_chunk_meta["start"] = timestamp

    current_chunk_text.append(f"{speaker}: {text}")
    current_chunk_meta["speakers"].add(speaker)
    current_chunk_meta["end"] = u.end   # 종료 시간을 계속 갱신한다

    # 단어 수 한계를 확인한다
    current_word_count = sum(len(s.split()) for s in current_chunk_text)
    if current_word_count >= WORD_LIMIT:
        chunks.append({
            "content": "\n".join(current_chunk_text),
            "metadata": {
                "start_time": current_chunk_meta["start"],
                "end_time": current_chunk_meta["end"],
                "speakers": list(current_chunk_meta["speakers"])
            }
        })
        current_chunk_text = []
        current_chunk_meta = {"start": None, "end": None, "speakers": set()}

# 마지막 청크를 잊지 않는다
if current_chunk_text:
    chunks.append({...})

Deepgram의 구조화된 발화를 메타데이터에 직접 사상하면 화자 ID와 타임스탬프를 일급 스키마 필드로 취급하게 되고, 시스템이 화자별 필터링을 다룰 수 있게 된다. 이것이 사용자 신뢰를 쌓는 “원본으로 점프” 인터페이스를 가능하게 하고, 세밀한 “누가 무엇을 말했는지” 필터링을 허용하며, 데이터셋의 나머지를 훼손하지 않고 민감한 구간만 프로그램적으로 삭제할 수 있게 한다.

시각적 의미론 — “빨간 버튼” 문제

전사는 음성과 영상 모두에서 효과적이다. 말로 표현된 언어를 포착하기 때문이다. 그러나 영상에서 전사만으로는 “침묵의 의미론”을 포착하지 못한다.

이는 적재 시점에 보통 두 방법으로 해결한다. 시각 캡셔닝(VLM으로 텍스트 서술을 생성)³ 또는 교차 모달 임베딩(시각 데이터를 텍스트와 공유하는 벡터 공간에 직접 사상)이다. 어느 경우든 이 시각 정보를 어떻게 추출하느냐가 시스템의 비용과 정확도를 결정한다. 세 개의 주요 전략이 있다.

어떤 방법을 쓰든 질의 시점에 사용자가 “기계를 어떻게 멈추나요?”라고 물으면 검색 파이프라인이 시각 캡션과 일치를 찾아, 발화된 대화가 모호했더라도 올바른 구간을 식별한다.

표에서 보듯 영상을 다루는 단 하나의 “올바른” 방법은 없다. 세밀도와 맥락과 비용 사이의 교환이 있을 뿐이다. 4장에서 논의한 대로 견고한 멀티모달 파이프라인은 흔히 혼합 접근을 요구한다. 이 경우에는 넓은 색인에 경량 프레임 추출을 쓰면서, 비싼 시간 구간 분할은 복잡하고 값이 높은 영상 데이터에 남겨 두는 것이다.

프로덕션 고려사항

멀티모달 RAG의 프로덕션 배포는 고유한 마찰과 복잡성을 파이프라인에 들여온다. 프로덕션에서 이미지가 완벽히 잘려 있고 명료하게 읽히는 “행복한 경로”는 규칙이 아니라 예외다. 부실한 스캔 품질, 회전된 이미지나 표, 알아들을 수 없는 음성에 견디는 시스템을 설계해야 하며, 그러면서도 프로젝트의 투자수익을 지키기 위해 추론 비용을 낮게 유지해야 한다.

연산 경제와 지연

가장 즉각적인 관심사는 적재 시점의 연산 비용이다. CLIP이나 SigLIP 같은 비전 인코더와 자동음성인식 파이프라인은 텍스트 기반 대응물보다 몇 자릿수 무겁다. 텍스트 전용 시스템에서 문단 하나를 임베딩하는 데는 표준 CPU에서 밀리초가 걸린다. 반면 고해상도 PDF 페이지를 OCR 엔진에 통과시키고, 레이아웃 의미론을 포착하고 표나 이미지를 추출하기 위해 비전 인코더를 돌리고, 요약을 위해 VLM을 호출하는 일은 훨씬 값비싼 연산이다.

이 연산 비용을 관리하려면 4장에서 논의한 병렬화된 구성요소 기반 아키텍처를 그대로 채택해, 적재 중 이미지 처리를 견고하고 효율적으로 만들 수 있다. 적재에 GPT-5.1이나 Gemini 3 Pro 같은 외부 VLM API에 의존하면 상당한 네트워크 지연과 속도 제한 위험이 생기므로, 파이프라인은 재시도 로직과 백오프 전략을 구현해야 한다. 늘 그렇듯 광범위한 로깅과 모니터링이 프로덕션 문제를 식별하고 빠르게 고치도록 돕는다.

모달리티 정렬과 고아 청크

멀티모달 RAG에서 문서의 모든 구성요소, 즉 텍스트와 이미지와 음성과 영상 사이의 엄격하고 추적 가능한 연결을 유지하는 능력이 중요하다. 이 새로운 종류의 모달리티 정렬을 잃으면 검색 맥락은 검증 목적에 사실상 무용해진다. 재무 보고서에서 표를 추출했는데 그것이 페이지의 어디에 있었는지 정의하는 경계 상자 좌표를 잃으면, LLM은 사용자에게 원본을 가리킬 수 없다. 전사록이 영상 프레임 타임스탬프와 분리되면 재생의 그 순간으로 점프할 능력이 사라진다.

이를 규모에서 제대로 하려면 “청크”를 텍스트 문자열이 아니라 복합 객체로 취급해야 한다. 의미론적 내용(벡터), 원시 내용(텍스트나 이미지나 음성), 그리고 공간·시간 메타데이터(경계 상자, 타임스탬프)를 함께 캡슐화하는 객체다. 프로덕션 파이프라인은 스키마를 엄격히 강제해 고아 청크를 방지해야 한다.

이 정렬 난제는 레이아웃이 무거운 문서를 다룰 때 악화된다. 개념검증의 흔한 실패 유형이 PDF를 고정된 문자 수로 순진하게 청킹하는 것인데, 그러면 차트가 그 캡션과 분리될 수 있고 레이아웃을 인식하지 못한다. 적재 중에 문서의 시각적 위계를 존중하면 검색된 맥락이 의미론적으로 완전해지고, LLM이 존재하지 않는 관계를 환각할 가능성이 줄어든다.

인터페이스 계층 — 시각적 인용

3장에서 논의한 대로 UI는 백엔드의 복잡성이 투명성과 사용 편의에 대한 사용자 기대와 만나는 지점이다. 텍스트 기반 RAG에서 인용이 각주나 원본 문서 링크라면, 멀티모달 RAG에서 인용은 사용자 인터페이스에 박힌 실제 이미지여야 한다.

사용자가 “매출 전망이 왜 하락했는가?”라고 묻고 모델이 40쪽의 막대 차트에 근거해 답한다면, UI는 그 특정 차트를 링크로 가리키는 데 그치지 않고 렌더링해야 할 수 있다. 시스템은 차트의 정확한 좌표를 돌려주어야 하고, 그래야 프런트엔드가 그것을 잘라 표시하거나 원본 PDF를 렌더링한 캔버스 위에 강조할 수 있다.

이 요구는 API 설계에 영향을 준다. 검색 엔드포인트는 텍스트 문자열만 돌려줄 수 없고, 답변과 텍스트 인용과 “미디어 참조”를 담은 구조화된 객체를 돌려주어야 한다. 이 참조는 S3 같은 객체 저장소에 있는 이미지 잘라내기의 서명된 URL이거나, 영상 플레이어를 위한 시간 표식일 수 있다. 프런트엔드와 백엔드 팀은 이런 사용자 경험의 매끄러운 구현을 위해 개발 초기에 좌표 체계에 합의해야 한다.

보안, 프라이버시, 거버넌스

텍스트 기반 RAG 보안이 프롬프트 인젝션과 PII 마스킹에 집중한다면, 멀티모달 RAG는 표준 텍스트 필터가 잡을 수 없는 완전히 새로운 공격면과 컴플라이언스 골칫거리를 들여온다.

심층 관측성과 트레이싱

시각 데이터의 도입은 잠재적 실패 유형을 확장한다. 텍스트가 흔히 표나 이미지나 음성이나 영상과 다르게 저장되기 때문이다. 사용자가 실패를 신고할 때 데브옵스 팀은 텍스트 로그만 들여다볼 수 없다. 오류가 적재 파이프라인에서 왔는지 생성 계층에서 왔는지 판단하기 위해 원시 OCR 출력이나 검색된 정확한 이미지 같은 특정 시각 자산을 감사할 수 있어야 한다.

이 세밀한 가시성의 요구는 심층 트레이싱 통합 전략을 필요하게 만든다. 표준 로깅 도구는 멀티모달 데이터에 내재한 페이로드 크기와 형식에 흔히 힘들어한다. 데브옵스 팀은 검색 중에 쓰인 특정 경계 상자 좌표나, 토큰화 전 표에서 추출한 원시 텍스트 같은 중간 상태를 포착하고 보존할 수 있는 로깅 파이프라인을 설계해야 한다. 이런 세밀한 데이터가 없으면 디버깅은 어렵고 시간을 잡아먹는다. 검색 시스템이 차트를 찾지 못한 것인지, OCR이 그 안의 숫자를 뒤엉키게 한 것인지, 모델이 시각 맥락을 그냥 무시한 것인지 구별할 수 없다.

멀티모달 RAG의 환각과 평가

파이프라인을 만드는 일은 첫 단계일 뿐이고, 그것을 신뢰하는 일이 두 번째다. 멀티모달 RAG는 텍스트 전용 시스템에 존재하지 않는 고유한 품질 난제를 들여온다. 구체적으로 모델이 시각적 세부를 어떻게 환각하는지, 그리고 검색된 객체가 문단이 아니라 이미지일 때 성공을 어떻게 수학적으로 평가하는지의 문제다.

멀티모달 환각의 검출 — 시각적 아첨

텍스트 기반 RAG에서 환각은 보통 검색된 텍스트에 없는 사실을 모델이 조작하는 것이다. 그러나 멀티모달 RAG에서 환각은 흔히 시각적 아첨(visual sycophancy)으로 나타난다. VLM이 시각적 증거보다 사용자의 프롬프트를 우선하는 현상이다.

이를 완화하려면 맹검 검증 워크플로(blind verification workflow)를 쓸 수 있다. 사용자의 유도적 질문을 VLM에 직접 넘기는 대신, 먼저 이미지를 중립적 프롬프트와 함께 VLM에 넘긴다. “표면의 상태를 상세히 서술하라” 같은 것이다. 그다음 이 중립적 서술을 정답으로 취급한다. 이어 텍스트 전용 이차 LLM이 사용자의 구체적 질문을 이 중립적 서술과 비교한다. 중립적 서술이 “흠 없는 표면”을 언급하는데 사용자가 “손상”을 물었다면, 시스템은 존재하지 않는 손상을 환각하는 대신 그 불일치에 표시를 달거나 답변을 거부할 수 있다.

멀티모달 검색과 생성의 평가

6장에서 RAG 평가와 그것이 프로덕션 안정성과 품질에 갖는 중요성을 논의했다. 멀티모달 RAG도 다르지 않고, 텍스트와 마찬가지로 검색(올바른 이미지를 검색했는가)과 생성(검색된 이미지를 올바르게 이해했는가)의 측정을 포함한다. 다만 ROUGE나 BLEU 같은 표준 텍스트 지표는 여기서 무용하며, UMBRELA나 AutoNuggetizer 같은 기준 없는 지표도 그렇다. 그러나 일반적 방법은 꽤 유사하다.