검색이나 RAG (Retrieval-Augmented Generation) 파이프라인에서는, Embedding (임베딩) 모델의 성능이 시스템 전체의 검색 품질을 거의 결정합니다. 질의(query)와 검색 대상 문서가 벡터 공간 위에서 잘 정렬되어 있지 않으면, 후단에서 아무리 우수한 LLM이나 Reranker를 사용하더라도, 놓쳤던 문맥을 되찾아올 수 없습니다.
최근 Google이 Gemma Family의 Open-weight (오픈 웨이트) Embedding 모델을 Hugging Face에 공개했습니다. 클라우드 상용 API뿐만 아니라, 로컬에서 가중치(weights)를 구동하는 선택지도 현실적으로 가능해지고 있습니다. 이에 본 글에서는 이 로컬 모델이 Google의 관리형 API인 Gemini Embedding 2와 비교하여 어느 정도 활용 가능한지, 텍스트와 이미지 검색을 통해 실제로 시험해 보았습니다.
학술적인 벤치마크가 아닌, 실무를 상정한 비교입니다. 관리된 텍스트 문서, 이미지, 캡션 데이터를 사용하여 다국어에서의 검색 정확도와 로컬 운영의 현실적인 비용 감각을 조사했습니다.
이번 일본어 캡션은 원 데이터를 번역한 것이므로, 네이티브 일본어 데이터셋에 대한 엄밀한 평가라기보다는, 다국어에서 어느 정도 작동하는지 참고용으로 봐주시기 바랍니다.
인덱스 크기와 스토리지 조건을 맞추기 위해, 두 모델 모두 768 차원의 임베딩으로 테스트를 진행했습니다.
Hugging Face에 공개된 Open-weight 모델입니다 (EmbeddingGemma 2 model card). 가중치를 줄여 자체 서버에서 구동할 수 있기 때문에, 데이터를 외부로 내보낼 수 없는 프로젝트나 API의 종량 과금을 줄이고 싶은 환경에 적합합니다.
Google의 관리형 멀티모달 API입니다 (Gemini Embedding 2 documentation). GPU 서버 준비나 드라이버 관리를 신경 쓸 필요 없이, 텍스트와 이미지를 모두 하나의 API 엔드포인트에서 벡터화할 수 있습니다.
로컬 측 추론은 Google Colab의 NVIDIA T4 GPU로 구동했습니다. 또한, GPU가 없을 경우의 비용 감각을 보기 위해 CPU에서의 실행 시간도 측정했습니다. 계정이나 플랜(Google AI Plan 등)에 따라 Colab의 컴퓨팅 자원을 사용할 수 있는 경우도 있습니다.
- 임베딩 차원 수: 768
- L2 정규화
- 유사도: 코사인 유사도 (Cosine Similarity)
- 순위 평가 지표: hit@1, hit@5, hit@10, MRR, nDCG@10
- 로컬 측: 정확도 평가는 GPU 사용 (CPU는 실행 시간 체크만)
- Gemini: API 요청의 실시간 레이턴시
모든 벡터는 L2 정규화되었으며, 코사인 유사도로 순위를 매겼습니다. 유사도의 절대값이 아니라, 정답이 몇 번째에 들어갔는지로 평가했습니다.
모든 평가 점수는 0부터 1 사이입니다. 1은 해당 지표에서의 완전한 검색 성공을 의미하며, 0은 단 하나도 정답을 찾지 못했음을 나타냅니다. hit@k 지표의 점수는, 검색에 성공한 질의의 비율과 대략적으로 동일합니다. 예를 들어 hit@1 = 0.80인 경우, 전체 질의의 80%에서 정답 후보가 1위에 반환되었음을 의미합니다. MRR과 nDCG@10은 순위 지정 품질을 평균화한 점수이며, 수치가 높을수록 정답이 더 상위에, 더 적절한 순서로 배열되었음을 나타냅니다:
hit@1: 1위에 정답이 들어갈 확률 -hit@5 / hit@10: 상위 5개 또는 10개 안에 정답이 들어갈 확률 -MRR (Mean Reciprocal Rank): 첫 번째 정답이 얼마나 상위에 왔는지의 지표 -nDCG@10: 상위 10개의 배열 순서의 좋음. 하나의 이미지에 여러 개의 정답 캡션이 있는 경우 차이가 납니다.
질의에 대해, 후보 문서 중에서 올바른 1개를 찾아낼 수 있는지 테스트했습니다.
| 지표 | EmbeddingGemma 2 | Gemini Embedding 2 | 차분 |
|---|
| hit@1 | 0.7000 | 0.8200 | +0.1200 |
| hit@5 | 0.8800 | 0.9200 | +0.0400 |
| hit@10 | 0.9200 | 1.0000 | +0.0800 |
| MRR | 0.7662 | 0.8669 | +0.1007 |
| nDCG@10 | 0.7991 | 0.8980 | +0.0989 |
Gemini는 1위 적중률이 더 높았고(82% 대 70%), MRR과 nDCG@10에서도 차이를 보였습니다. 하지만 후단에 Reranker를 배치하여 top-k 후보군을 넓게 가져가는 설계라면, EmbeddingGemma의 70%도 나쁘지 않습니다.
베트남어와 일본어 설명문으로부터 해당하는 이미지를 찾는 태스크입니다.
| 언어 | 지표 | EmbeddingGemma 2 | Gemini Embedding 2 | 차이점 |
|---|
| 베트남어 | hit@1 | 0.7167 | 0.7667 | +0.0500 |
| hit@5 | 0.9500 | 0.9833 | +0.0333 | |
| hit@10 | 0.9667 | 1.0000 | +0.0333 | |
| MRR | 0.8061 | 0.8533 | +0.0472 | |
| nDCG@10 | 0.8442 | 0.8897 | +0.0455 | |
| 일본어 | hit@1 | 0.7000 | 0.7833 | +0.0833 |
| hit@5 | 0.9667 | 0.9833 | +0.0166 | |
| hit@10 | 0.9667 | 1.0000 | +0.0333 | |
| MRR | 0.8107 | 0.8658 | +0.0551 | |
| nDCG@10 | 0.8485 | 0.8993 | +0.0508 | |
Gemini가 1위에 해당할 확률은 더 높지만, EmbeddingGemma 역시 상위권에서 확실한 정답을 남기고 있습니다. 두 언어 모두 hit@5에서 95%를 넘고 있기 때문에, 1차 필터링용(First-stage retriever)으로는 충분히 실용적인 수준입니다.
이미지를 주고 해당하는 설명문을 찾는 태스크입니다. 이 테스트에서는 하나의 이미지에 대해 여러 개의 정답 설명문이 존재합니다.
| 언어 | 지표 | EmbeddingGemma 2 | Gemini Embedding 2 | 차이점 |
|---|
| 베트남어 | hit@1 | 0.7333 | 0.8000 | +0.0667 |
| hit@5 | 0.9333 | 1.0000 | +0.0667 | |
| hit@10 | 0.9667 | 1.0000 | +0.0333 | |
| MRR | 0.8280 | 0.8900 | +0.0620 | |
| nDCG@10 | 0.7913 | 0.8634 | +0.0721 | |
| 일본어 | hit@1 | 0.6667 | 0.7333 | +0.0666 |
| hit@5 | 0.9333 | 0.9667 | +0.0334 | |
| hit@10 | 0.9667 | 1.0000 | +0.0333 | |
| MRR | 0.7846 | 0.8381 | +0.0535 | |
| nDCG@10 | 0.7541 | 0.8350 | +0.0809 | |
역방향에서도 Gemini가 안정적으로 상위에 위치했습니다. nDCG@10의 차이가 큰 것은, Gemini가 '정답 하나를 맞히는' 것뿐만 아니라 '여러 정답 캡션을 모아서 상위권에 배치하는' 것이 가능하기 때문입니다.
클라우드의 편리함과 로컬 운영 시 하드웨어 사양 간의 트레이드오프 문제입니다.
Gemini Embedding 2 API는 이번 측정에서 입력당 평균 약 0.8초가 소요되었습니다. 실제 서비스(Production) 환경에서의 지연 시간(Latency)은 네트워크나 배치 처리 방식에 따라 달라질 수 있습니다.
EmbeddingGemma는 NVIDIA T4 GPU로 구동했을 경우 입력당 약 0.427초로 충분히 실용적이었습니다. 반면, CPU만으로 구동할 경우 약 15.4초가 걸렸습니다. 로컬에서 이미지 검색 시스템을 구축하려면 GPU는 필수 조건입니다.
정확도만 놓고 보면 Gemini Embedding 2의 승리이지만, 직접 사용해 보니 재미있었던 것은 EmbeddingGemma 2의 높은 실용성이었습니다.
특히 베트남어 텍스트에서 hit@1이 70%를 넘고, 이미지 검색의 hit@5가 95%를 넘은 것은 추가 학습 없이도 뛰어난 성능을 보여주는 768차원 로컬 모델로서는 상당히 우수합니다. 상용 API와 비교해도 기대 이상으로 경쟁력이 있습니다.
- Reranker를 거치지 않고, 첫 검색에서 높은 정확도로 결과를 얻고 싶을 때
- GPU 인스턴스 관리나 드라이버 업데이트 같은 운영 관리가 번거로울 때
- 즉시 사용할 수 있는 멀티모달 검색 환경이 필요할 때
• 보안이나 규정상 텍스트나 이미지를 외부 API로 전송할 수 없는 경우
• 대량 데이터를 주기적으로 인덱싱하기 때문에, API 종량제 과금 방식이 아닌 고정된 머신 비용으로 운영하고 싶은 경우
• GPU 서버가 있어서, 2단계 검색의 첫 단계(빠른 후보군 필터링)로 사용하고 싶은 경우
GPU를 준비할 수 있다면, EmbeddingGemma 2는 데이터를 로컬에 보관하면서도 실용적인 검색 기반을 구축할 수 있는 선택지가 됩니다. 운영의 편리함과 최고 정밀도를 모두 원한다면, 계속해서 Gemini API가 기준이 될 것이라고 생각합니다.
