구글의 설명만 믿고 100개 이상 다국어 RAG 용도로 EmbeddingGemma를 얹었습니다.
그런데 테스트 결과가 이상해서 조사 보고를 지시했더니, 상당히 많은 이슈들이 이미 보고되어 있더군요.
유료 서비스인 Gemini 3~3.5 시리즈의 환각조차 통제하지 못해 난리인 상황에서, 연관된 오픈소스 임베딩 모델의 성능이 안정적일 거라고 기대한 것 자체가 잘못이었다는 생각이 듭니다.
결론적으로는 해당 부분을 튜닝해서 쓰거나, 다른 모델을 메인으로 두고 EmbeddingGemma를 백폴로 남기는 선택지가 있습니다. 다만 이 상태의 백폴은 오히려 더 치명적일 수 있어 제거하기로 결정했습니다.
대안으로 BGE-M3, Snowflake, Qwen3-Embedding 등을 검토했으나, 가장 안정적인 BGE-M3는 모바일 디바이스에서 부담이 커서 결국 며칠 전 발표된 IBM의 Granite 97M R2를 사용하기로 했습니다.
Granite는 4.0 시절부터 영어 + 유럽권 + 아시아권 언어의 밸런스가 워낙 좋았던 기억이 있어 우선적으로 테스트를 돌려봤는데, 역시나 튜닝 없이도 상당히 좋은 결과가 나와줘서 다른 모델들의 검증을 대충 건너뛰어 버린 건 약간 아쉽습니다.
EmbeddingGemma 확인된 리스크
모델 자체의 한계 Google 모델 카드에 따르면 EmbeddingGemma는 300M급, 100개 이상 언어 지원, 2K 입력 길이, 768차원 임베딩 모델입니다. 공식 한계로는 학습 데이터 범위·편향·언어 뉘앙스 문제가 명시되어 있습니다. 즉, 미묘한 문맥에서는 자체 평가가 필수입니다. https://ai.google.dev/gemma/docs/embeddinggemma/model_card
프롬프트/모드 설정 오류 시 검색 품질 저하 공식 문서상 query / document / fact-checking / classification / sentence-similarity마다 prefix가 다릅니다. 특히 sentence similarity는 retrieval용이 아니라고 명시되어 있습니다. RAG에서 query와 document를 같은 방식으로 임베딩하거나 prefix를 빼버리면 품질이 크게 흔들릴 수 있습니다.
Hugging Face 커뮤니티의 성능 이상 사례 "검색 성능이 매우 나쁘다"는 discussion이 있었고, 원인은 상당 부분 transformers 버전 및 구현 문제로 정리되었습니다. 다만 그 과정에서 한국어 retrieval 점수가 bge-m3, snowflake-arctic, KURE-v1 대비 낮게 나온 사례가 있었고, 최종 코멘트도 "good but not SOTA", "bad crosslanguage performances"로 정리됩니다. https://huggingface.co/google/embeddinggemma-300m/discussions/3
NaN 임베딩 이슈 Hugging Face discussion에 model.encode, encode_query, encode_document에서 일부 입력이 [nan, nan, ...]로 출력되는 사례가 있습니다. MPS / Apple Silicon, batch size, Torch 버전과 관련된 것으로 보이며, CPU에서는 정상 동작했다는 보고도 있습니다. 이건 RAG에 치명적입니다 — NaN 벡터가 색인되면 검색 결과 자체가 무너질 수 있습니다. https://huggingface.co/google/embeddinggemma-300m/discussions/15
Ollama에서 PDF/공백 많은 텍스트 처리 성능 저하 Ollama issue에 EmbeddingGemma가 PDF 추출 텍스트처럼 공백이 많은 입력에서 최대 164배 느려지는 성능 저하가 보고되어 있습니다. workaround는 embedding 이전에 공백을 정규화하는 것입니다. https://github.com/ollama/ollama/issues/12508
Apple Silicon / GGUF / Local Memory 경로 안정성 문제 OpenClaw issue에서는 EmbeddingGemma GGUF를 local memory embedding으로 사용할 때 Apple Silicon Metal 경로에서 gateway crash, concurrency/deadlock, fresh chunk 검색 empty 등의 문제가 함께 언급됩니다. 모델 자체보다는 런타임/서빙 경로 리스크에 해당합니다. https://github.com/openclaw/openclaw/issues/44202
임베딩 유사도만으로 환각 검증을 해서는 안 됨 2025년 논문은 embedding similarity 기반 hallucination detection이 실제 RAG 환각 상황에서 실패할 수 있다고 지적합니다. 즉 EmbeddingGemma든 OpenAI embedding이든, "답변 claim이 근거와 semantic하게 비슷하다"만으로 사실 검증을 해서는 안 됩니다. https://arxiv.org/abs/2512.15068