기술 문서의 다이어그램, 스크린샷, 아키텍처 그림에는 텍스트만으로 설명하기 어려운 핵심 정보가 담겨 있다. 쿼리 시점에 실시간으로 멀티모달 VLM을 호출하면 비용과 지연이 급증하고, 캐싱도 어렵다. kapa.ai가 기술 문서 AI 어시스턴트를 구축하며 찾아낸 실용적인 해법은 인덱싱 시점에 한 번 캡셔닝해두고, 이후 쿼리에서는 텍스트로 검색하는 것이다.

핵심 원칙: 인덱싱 시 설명, 쿼리 시 텍스트 검색

쿼리 시 멀티모달 처리를 하면 안 되는 이유:

• 쿼리마다 VLM 호출 → 비용 급증
• 지연(latency)이 실시간 응답에 맞지 않음
• 이미지 수천 개를 모든 쿼리에 처리하면 확장 불가

대신, 인덱싱 시 이미지당 한 번만 VLM으로 캡션(caption)을 생성하고, 이를 텍스트 청크로 저장하면 일반 텍스트 RAG와 동일한 방식으로 검색된다.

프로덕션에서 반드시 지켜야 할 3가지

1. 필터링: 대부분의 이미지는 쓸모없다

기술 문서의 이미지 대부분은 데코레이션, 로고, 아이콘처럼 실제 정보가 없다. 무작위 캡셔닝은 노이즈를 늘릴 뿐이다.

• 텍스트를 포함하거나 의미 있는 다이어그램인지 분류
• 분류 불가한 이미지는 건너뜀
• 처리 대상 이미지만 캡셔닝 → 비용·품질 동시 개선

2. 캡셔닝: 컨텍스트가 모델 크기보다 중요하다

이미지만 입력으로 주면 부정확한 캡션이 생성된다. 주변 텍스트(이미지 위·아래 단락, 섹션 제목)를 함께 제공하면 훨씬 정확한 캡션이 만들어진다.

[시스템 프롬프트]
다음 기술 문서 이미지의 내용을 설명하세요.

[컨텍스트]
섹션: "데이터 파이프라인 아키텍처"
앞 단락: "다음 그림은 ingest → transform → load 단계를 보여준다."

[이미지]
<image>

큰 VLM보다 컨텍스트가 풍부한 작은 VLM이 더 나은 결과를 낼 수 있다.

3. 저장: 이미지 캡션은 별도 청크로 저장한다

이미지 캡션을 원본 텍스트 청크에 인라인으로 삽입하면 청크 크기가 불균일해지고 검색 품질이 저하된다.

• 이미지 캡션은 별도의 독립 청크로 저장
• 출처 문서, 섹션, 원본 이미지 URL을 메타데이터로 포함
• 검색 결과에 원본 이미지 URL을 함께 반환해 LLM이 이미지를 인용 가능하게 함

{
  "text": "이 다이어그램은 ingest → normalize → embed → store 4단계 파이프라인을 보여준다.",
  "metadata": {
    "type": "image_caption",
    "source_doc": "pipeline_guide.pdf",
    "section": "데이터 파이프라인 아키텍처",
    "image_url": "https://docs.example.com/images/pipeline.png"
  }
}

요약

참고 자료

• How we index images for RAG — kapa.ai (2026-06-01)

관련 문서

• rag — RAG 기초 개념 및 구현 전략
• rag-anything — 텍스트·이미지·표·수식 통합 처리 멀티모달 RAG
• adaptive-chunking — 문서별 최적 청킹 전략 자동 선택