사내 지식은 텍스트 문서에만 있지 않습니다. 제품 이미지는 폴더에 있고, 계약서는 PDF로 오가며, 고객 상담 녹취는 오디오로 남고, 데모 영상은 비디오로 쌓입니다. 기존 RAG 파이프라인은 보통 텍스트 chunk를 임베딩하고 벡터 DB에서 검색한 뒤 LLM에 넣는 방식입니다. 이 구조로는 이미지와 오디오, 영상, PDF를 같은 검색 경험으로 다루기 어렵습니다.
Google은 2026년 4월 30일 Gemini Embedding 2의 GA와 활용 글을 공개했습니다. 공식 설명 기준으로 Gemini API에서 처음 제공되는 unified embedding model이며, text, image, video, audio, document를 하나의 semantic space에 매핑합니다. 100개 이상 언어를 지원하고, 한 요청에서 최대 8,192 text tokens, 6 images, 120 seconds video, 180 seconds audio, 6 pages PDF를 처리할 수 있다고 안내됐습니다.
이 발표는 “새 embedding 모델이 나왔다”보다 큽니다. 개발팀 입장에서는 multimodal RAG 설계를 다시 생각해야 한다는 의미입니다. 검색 대상이 텍스트 문서뿐인지, 이미지와 PDF까지 포함하는지에 따라 indexing, metadata, reranking, storage cost 전략이 달라집니다.
멀티모달 embedding의 장점은 서로 다른 입력을 같은 벡터 공간에서 비교할 수 있다는 점입니다. 예를 들어 사용자가 “빨간색 패딩이 걸린 창고 사진”이라고 검색하면 텍스트 설명뿐 아니라 실제 이미지와도 유사도를 계산할 수 있습니다. PDF 페이지, 제품 이미지, 설명 문구를 각각 다른 검색 시스템으로 나누지 않아도 됩니다.
Google 공식 글은 interleaved input도 강조합니다. 텍스트와 이미지를 한 요청에 함께 넣어 하나의 aggregated vector를 만들 수 있습니다. 단순히 이미지 embedding과 텍스트 embedding을 따로 만든 뒤 평균내는 방식보다, 실제 사용자의 복합 질의를 더 자연스럽게 표현할 수 있습니다.
다만 모든 데이터를 무조건 한 벡터로 합치면 안 됩니다. 검색 목적이 “문서 안 특정 문단 찾기”라면 chunk 단위 embedding이 필요합니다. “이미지와 설명을 함께 이해한 상품 단위 검색”이라면 상품 단위 aggregated vector가 유리할 수 있습니다. 단위는 데이터 구조와 검색 intent에 맞춰야 합니다.
Gemini Embedding 2는 task-specific prefix를 제공합니다. 공식 글은 question answering, fact checking, code retrieval, search result, clustering, sentence similarity, classification 같은 prefix 예시를 제시합니다. 이 부분은 실무 품질에 직접 영향을 줍니다.
RAG 검색은 보통 asymmetric retrieval입니다. 사용자 query는 짧고 문서는 깁니다. 이때 query와 document를 같은 형식으로 embedding하면 의미가 흐려질 수 있습니다. query에는 “task: question answering | query: ...” 같은 prefix를 붙이고, document에는 title과 text를 나눠 넣는 식으로 모델에게 역할을 알려주는 편이 좋습니다.
반대로 clustering, classification, anomaly detection은 symmetric task에 가깝습니다. query와 document가 같은 성격의 텍스트라면 같은 prefix 전략이 적합합니다. 중요한 것은 prefix를 코드 어딘가에 흩뿌리지 않는 것입니다. index time과 query time prefix가 달라지면 검색 품질이 흔들립니다.
운영에서는 다음처럼 관리하는 것을 권합니다.
Google 공식 글은 Harvey, Supermemory, Nuuly 사례를 소개합니다. Harvey는 법률 리서치 플랫폼에서 이전 embedding 대비 legal-specific benchmark의 Recall@20 precision이 3% 증가했다고 밝혔습니다. Supermemory는 검색 Recall@1 accuracy가 40% 증가했다고 소개됐습니다. Nuuly는 창고 현장 사진을 카탈로그와 매칭하는 visual search에서 Match@20 accuracy가 60%에서 거의 87%로 올랐고, 전체 성공적인 제품 식별률이 74%에서 90% 이상으로 올랐다고 설명됐습니다.
이 수치는 각 회사의 데이터셋과 평가 기준에 묶여 있습니다. 따라서 그대로 우리 서비스 성과로 일반화하면 안 됩니다. 하지만 적용 범위는 분명합니다.
멀티모달 RAG가 특히 강한 곳은 “사용자가 찾는 표현”과 “데이터가 저장된 형태”가 다른 경우입니다. 사용자는 자연어로 찾지만 데이터는 사진, 표, PDF, 녹음으로 남아 있는 상황입니다.
Embedding 운영에서 품질만 보면 비용이 터집니다. Gemini Embedding 2는 기본 3072차원 vector를 제공하며, Matryoshka Representation Learning(MRL)을 사용해 output_dimensionality 파라미터로 1536 또는 768 차원까지 줄일 수 있다고 안내합니다. Google은 효율을 위해 1536 또는 768을 추천한다고 설명합니다.
차원 축소는 저장 비용, 검색 속도, 메모리 사용량에 영향을 줍니다. 하지만 무조건 낮추면 recall이 떨어질 수 있습니다. 따라서 운영 전에는 최소 세 가지 index를 비교해야 합니다.
테스트는 단순 top-k 눈대중으로 하면 안 됩니다. 실제 사용자 query 100~300개를 모으고, 정답 문서 또는 허용 가능한 문서 세트를 만들어 Recall@k, MRR, nDCG 같은 지표를 봐야 합니다. 멀티모달 검색에서는 텍스트 query로 이미지 정답을 찾는 케이스, 이미지 query로 텍스트 설명을 찾는 케이스를 따로 측정해야 합니다.
또한 Google은 Batch API가 embedding 기본 가격의 50%로 더 높은 throughput을 제공한다고 안내합니다. 실시간성이 필요 없는 대량 색인은 batch로 보내고, 사용자 query만 online embedding으로 처리하는 구조가 비용상 유리합니다.
Embedding 검색은 첫 후보를 잘 찾는 데 강하지만, 최종 답변 품질은 reranking과 filtering에서 갈립니다. 공식 글은 cosine similarity 또는 dot product로 initial result를 rerank하는 예시를 제공합니다. 실무에서는 여기에 metadata filter를 반드시 붙여야 합니다.
예를 들어 사내 문서 검색이라면 부서, 권한 등급, 문서 최신성, 언어, 파일 타입을 필터링해야 합니다. 상품 검색이라면 재고 상태, 브랜드, 시즌, 판매 가능 여부가 필요합니다. 법률 검색이라면 관할, 문서 유형, 날짜가 중요합니다. 벡터 유사도만 높다고 사용자에게 보여주면 안 되는 문서가 있을 수 있습니다.
추천 구조는 다음과 같습니다.
Gemini Embedding 2의 핵심은 멀티모달 입력을 “한 번에 넣을 수 있다”가 아닙니다. 텍스트 중심 RAG에서 빠졌던 실제 업무 데이터를 같은 검색 체계로 끌어오는 것입니다. 다음 RAG 개선을 고민한다면 먼저 물어보세요. “우리 사용자가 찾는 답은 텍스트 문서 안에만 있는가?”
