Gemini Embedding 2로 RAG 검색 품질 높이는 법

Gemini Embedding 2로 RAG 검색 품질 높이는 법

문서 검색형 AI를 운영해 본 팀이라면 다 비슷한 순간을 겪습니다. 답변은 그럴듯한데 정작 원하는 문서를 못 집고, 이미지·PDF·슬라이드가 섞이면 검색 품질이 급격히 떨어집니다. 특히 멀티모달 데이터가 늘수록 파이프라인은 복잡해지는데, 검색 정확도는 오히려 더 흔들립니다. 이때 많은 팀이 생성 모델 프롬프트를 계속 만지지만, 병목은 대개 retrieval 층에 있습니다.

Google이 공식 기술 글에서 소개한 Gemini Embedding 2는 이 지점에서 꽤 실용적인 옵션입니다. 핵심은 텍스트, 이미지, 비디오, 오디오, 문서(PDF)를 하나의 embedding space에 넣는다는 점입니다. 공식 설명 기준으로 한 번의 호출에서 최대 8,192 text tokens, 이미지 6개, 영상 120초, 오디오 180초, PDF 6페이지를 다룰 수 있고, 100개 이상의 언어를 지원합니다.

이 스펙만 보면 "멀티모달이네" 정도로 지나가기 쉽지만, 실무 포인트는 따로 있습니다. 데이터 형식이 다른 자료를 같은 검색 좌표계 안에 넣을 수 있다면, RAG 품질을 올리는 핵심이 프롬프트보다 인덱싱 전략으로 이동합니다.

왜 기존 RAG가 자주 실패하나

기존 텍스트 중심 RAG는 보통 이런 흐름으로 망가집니다.

• 문서를 텍스트로만 평탄화하면서 이미지·표·레이아웃 의미를 잃는다
• 질문은 짧은데 문서는 길어서 query-document 비대칭이 심하다
• 문서 청킹 단위가 제각각이라 retrieval noise가 커진다
• reranking을 붙여도 입력 표현 자체가 약하면 한계가 있다

특히 사내 위키, 슬라이드, 보고서, 매뉴얼, 스크린샷이 섞인 환경에서는 텍스트 추출만으로 중요한 문맥이 자주 날아갑니다. 그래서 검색이 안 맞으면 생성 모델이 거짓으로 메우기 시작합니다.

Gemini Embedding 2에서 진짜 중요한 부분

Google 글에서 핵심으로 봐야 할 부분은 두 가지입니다.

첫째, interleaved input 지원입니다. 텍스트와 이미지를 한 요청 안에 함께 넣어 하나의 embedding으로 만들 수 있습니다. 예를 들어 "에러 상태의 대시보드 스크린샷"과 "사용자 보고 문장"을 같이 표현하는 식입니다. 이건 UI 문서 검색, 시각 QA, 디자인 자산 검색에서 꽤 강력합니다.

둘째, task prefix 전략입니다. Google은 agentic retrieval, question answering, fact checking, code retrieval, search result, clustering, classification 같은 목적별 prefix를 붙여 embedding을 최적화하라고 제안합니다. 이게 중요합니다. 임베딩 모델은 하나여도 검색 의도에 맞게 query와 document 표현을 다듬어야 성능이 오릅니다.

공식 사례도 꽤 구체적입니다. Harvey는 이전 임베딩 대비 Recall@20 precision이 3% 상승했다고 밝혔고, Supermemory는 Recall@1이 40% 증가했다고 소개됐습니다. Nuuly의 시각 검색 도입 사례에서는 Match@20이 60%에서 거의 87%로, 전체 상품 식별률은 74%에서 90% 이상으로 올랐다고 설명합니다. 물론 이 수치는 각 서비스의 데이터셋과 파이프라인에 크게 좌우되므로 그대로 복제되진 않습니다. 하지만 "임베딩 교체가 실제 검색 품질 차이로 이어질 수 있다"는 근거로는 충분합니다.

실무 적용 순서: 모델 교체보다 인덱싱 설계부터

많은 팀이 임베딩 모델만 바꾸면 품질이 올라갈 거라 기대합니다. 그런데 실제로는 인덱싱 설계가 먼저입니다. Gemini Embedding 2를 쓸 때 제가 추천하는 순서는 이렇습니다.

1. 데이터 유형을 분리합니다. 텍스트 문서, 이미지 포함 문서, PDF, 스크린샷, 오디오/비디오 요약본처럼 검색 대상의 성격을 먼저 나눕니다.
2. query intent를 구분합니다. 질문응답용인지, 코드 검색인지, 사실검증인지, 유사 사례 찾기인지 먼저 정해야 합니다.
3. query와 document에 맞는 prefix를 맞춥니다. Google이 제안한 task prefix를 양쪽 모두 일관되게 적용해야 합니다.
4. 청킹 전략을 다시 잡습니다. 긴 문서를 무작정 500자씩 자르기보다 제목, 섹션, 표 캡션, 이미지 설명 단위를 고려해야 합니다.
5. retrieval 후 reranking을 붙입니다. embedding만 믿지 말고 cosine similarity나 dot product 기반 정렬과 후처리를 같이 둬야 합니다.

핵심은 "임베딩 모델 바꾸기"가 아니라 "검색 계약 다시 쓰기"입니다.

특히 잘 맞는 사용처

Gemini Embedding 2는 아래 상황에서 특히 써볼 가치가 있습니다.

• 매뉴얼, 스크린샷, 설계 문서가 섞인 사내 지원봇
• 코드 설명 텍스트와 코드 스니펫을 함께 검색하는 개발자 도구
• 상품 이미지와 설명이 같이 있는 이커머스 검색
• PDF 보고서와 표, 차트를 함께 다루는 분석형 QA
• 멀티언어 문서가 많은 글로벌 팀 위키

반대로 텍스트만 있는 단순 FAQ, 데이터량이 작고 검색 구조가 단순한 서비스라면 큰 차이를 못 느낄 수도 있습니다. 이 경우는 임베딩 모델보다 chunking과 metadata 필터링이 먼저일 수 있습니다.

평가할 때 꼭 봐야 할 지표

검색 품질 평가는 "답이 좋아 보이냐" 수준이면 안 됩니다. 최소 아래 항목은 분리해서 봐야 합니다.

• Recall@k: 필요한 문서를 상위 k개 안에 실제로 넣는가
• Precision@k: 상위 결과에 잡음이 얼마나 적은가
• MRR 또는 nDCG: 정답이 얼마나 위쪽에 오는가
• 멀티모달 쿼리 성공률: 텍스트+이미지 조합 질문에서 성능이 유지되는가
• 생성 최종 답변 정확도: retrieval 개선이 answer quality로 이어지는가

검색이 좋아졌는데 답변이 별 차이 없다면, 생성 단계나 컨텍스트 구성 문제가 따로 있을 수 있습니다. 그래서 retrieval 평가와 answer 평가를 같이 봐야 합니다.

결론: RAG 개선의 우선순위를 바꿔야 한다

Gemini Embedding 2의 가치는 새 모델이 나왔다는 데 있지 않습니다. 멀티모달 RAG를 운영할 때 검색 정확도 개선을 프롬프트보다 retrieval 표현 설계에서 먼저 풀 수 있게 해준다는 점이 더 큽니다. 특히 여러 형식의 자료를 같은 작업 흐름 안에서 찾아야 하는 팀이라면 충분히 검토할 만합니다.

지금 검색형 AI가 자꾸 헛짚는다면 생성 모델을 또 바꾸기 전에 한 번 물어보셔야 합니다. 우리는 답변기를 고치고 있는 걸까요, 아니면 검색기를 방치하고 있는 걸까요.

실행 체크리스트

• 현재 RAG 데이터가 텍스트, 이미지, PDF, 스크린샷 중 무엇으로 구성되는지 정리했다
• query intent를 질문응답, 코드 검색, 사실검증 등으로 분리했다
• Gemini Embedding 2 task prefix를 query/document 양쪽에 일관되게 설계했다
• 청킹 기준을 제목, 섹션, 캡션, 이미지 설명까지 포함해 재정의했다
• Recall@k, Precision@k, MRR, 최종 답변 정확도를 함께 측정했다
• 멀티모달 검색이 정말 필요한 영역부터 파일럿 적용했다

공식 출처: Google Developers Blog, Building with Gemini Embedding 2: Agentic multimodal RAG and beyond (2026-04-30)