텍스트·이미지·음성을 같은 공간에서 찾는 EmbeddingGemma 2

배경과 문제

임베딩은 문장이나 이미지의 의미를 숫자 벡터로 바꾸는 기술이다. 검색 엔진은 질문과 후보 자료의 벡터가 얼마나 가까운지 비교해 관련 자료를 찾는다. 이번 모델의 목적은 자료 형식이 달라도 같은 공간에서 비교할 수 있게 하는 것이다. 예를 들어 글로 쓴 질문과 사진, 음성 질의와 영상 장면을 서로 연결할 수 있다.

스마트폰에서는 검색 정확도뿐 아니라 모델을 올리는 메모리와 자료마다 저장하는 벡터의 크기도 중요하다. 서버로 자료를 보내지 않고 기기 안에서 검색하면 네트워크 없이도 동작하는 앱을 만들 수 있다. 구글은 여러 미디어를 처리하는 능력과 이런 기기 내 사용을 함께 겨냥해 모델을 설계했다고 설명한다.

기존 접근의 한계

이전 EmbeddingGemma는 텍스트 임베딩을 중심으로 사용되었다. 새 버전은 이미지·음성·비디오를 함께 다루고 코드 검색 성능도 개선하는 데 초점을 맞춘다. 이전 모델 역시 코드 벤치마크의 비교 대상이므로, 코드를 전혀 처리할 수 없었다고 이해하면 안 된다. 변화는 여러 입력 형식을 같은 벡터 공간으로 연결하는 범위와 평가 성능에 있다.

모델 크기와 검색용 벡터 크기는 별개의 제약이다. 모델은 입력을 변환할 때 메모리에 올라가고, 벡터 데이터베이스는 검색할 모든 자료의 표현을 보관한다. 새 버전은 필요 없는 인코더를 빼는 방법과 벡터 차원을 줄이는 방법을 각각 제공한다. 컨텍스트도 이전 텍스트 모델보다 넓어졌지만, 이전 모델의 토큰 한도를 오디오나 이미지 처리량으로 환산할 수는 없다.

연구방법을 단계별로

EmbeddingGemma 2는 Gemma 4 아키텍처를 기반으로 설계되었다. 전체 740M 파라미터는 270M 텍스트 백본(130M 트랜스포머 + 140M 임베더), 170M 비전 인코더, 300M 오디오 인코더로 구성된다. 이 모듈식 구조 덕분에 텍스트만 쓰면 270M, 텍스트+이미지는 440M, 텍스트+오디오는 570M만 로드하면 된다. 사용하지 않는 인코더는 메모리에서 제외할 수 있어 온디바이스 배포의 유연성이 높아진다.

학습에는 Matryoshka Representation Learning(MRL)이 적용되었다. MRL은 하나의 모델이 768차원 전체 벡터뿐 아니라 앞부분 512, 256, 128차원만 잘라낸 벡터도 유사도 순위를 보존하도록 학습시키는 방법이다. 러시아 전통 인형 마트료시카처럼 큰 벡터 안에 작은 벡터가 의미를 유지한 채 들어 있는 구조다. 같은 수치 정밀도라면 768에서 128차원으로 줄여 벡터 저장량을 6분의 1로 만들 수 있다. 모델 가중치나 전체 앱 메모리가 6분의 1이 된다는 뜻은 아니다.

모델은 문장 사이에 이미지나 오디오를 넣는 혼합 입력을 하나의 벡터로 표현한다. 총 8,192토큰의 예산을 모든 형식이 공유한다. 기본 설정에서 이미지는 장당 280토큰, 비디오 프레임은 140토큰, 오디오는 초당 25토큰을 쓴다. 따라서 다른 입력을 넣지 않는 단일 형식 기준으로 약 29개 이미지, 58개 프레임 또는 327초 오디오까지 들어간다. 여러 형식을 섞거나 설명 문장을 붙이면 각 형식에 남는 양은 줄어든다.

텍스트 검색에서는 질문과 문서의 역할을 구분하는 짧은 작업 지시를 입력 앞에 붙인다. 같은 문장이라도 찾고 싶은 질문인지, 검색 대상 문서인지 알려주는 장치다. 분류나 문장 유사도 비교처럼 역할이 대칭인 작업은 동일한 형식을 적용한다. 실제 적용에서는 모델 카드의 입력 형식을 유지해야 발표된 설정과 가까운 조건에서 품질을 확인할 수 있다.

결과와 숫자의 의미

모델 카드의 벤치마크 결과에 따르면, EmbeddingGemma 2는 텍스트 벤치마크 MTEB 다국어 v2에서 61.36점으로 이전 버전(61.15점)과 비슷한 수준을 유지했다. 반면 코드 벤치마크 MTEB Code v1에서는 78.68점을 기록해 이전 버전의 68.76점보다 9.92점 높아졌다. 이는 자연어 질의로 코드베이스를 검색하거나 코딩 에이전트가 관련 코드 조각을 찾는 작업에서 의미 있는 개선이다.

멀티모달 성능은 이미지 벤치마크 MIEB lite에서 64.64점, 비주얼 문서 검색 MMEB v2 VisDoc에서 67.84점, 비디오 검색 MMEB v2 Video에서 50.67점, 오디오 검색 MSEB Retrieval에서 69.54점을 기록했다. 이 점수들은 10억 파라미터 미만 모델 중 최고 수준이며, 일부는 두 배 이상 큰 전문 모델을 능가한다고 블로그는 밝힌다. 다만 벤치마크별 지표가 NDCG@10, Hit@1, MRR@10 등으로 서로 달라 직접 비교는 어렵고, 각 작업의 난이도도 다르다.

차원을 줄이는 실험에서 768→256으로 바꾸면 코드 점수는 78.68→76.18, MMEB 종합은 59.01→56.24, 오디오 MSEB는 69.54→66.76이었다. 저장량을 줄이는 대신 수 점의 성능을 내주는 예다. 128차원에서는 MMEB가 45.65, MSEB가 56.71까지 떨어졌다. 따라서 모델 카드는 128차원을 주로 텍스트 전용에 권장한다. 6배 절약이라는 최대치만 보고 멀티모달 검색에도 같은 품질이 유지된다고 기대해서는 안 된다.

구글은 양자화한 Pixel 11 Pro 측정에서 텍스트 전용 가중치에 약 191MB, 전체 모델 가중치에 약 567MB의 활성 RAM이 들었다고 보고한다. 모든 기기와 앱에서 보장되는 총메모리 수치는 아니다. 검색 대상 벡터와 앱의 다른 구성요소에도 공간이 필요하다. 앞의 정확도 표는 전체 정밀도 체크포인트 기준이므로, 실제 양자화 배포의 품질과 속도는 따로 측정해야 한다.

구체적인 예시

블로그의 Instant Media Search는 글이나 이미지로 개인 미디어에서 관련 항목을 찾고, Video Moments Finder는 글이나 오디오로 영상 속 순간을 찾는 데모다. 원리를 이해하기 위한 예로, 「해변에서 달리는 사람」을 입력해 사진을 찾거나 음성으로 원하는 장면을 설명해 영상 구간을 찾는 상황을 생각할 수 있다. 이 예문 자체가 공개 성능 시험의 결과라는 뜻은 아니다.

모델 카드에는 방수 신발의 설명과 사진 두 장, 젖은 바위 위 그립 시험 영상을 하나로 묶는 입력 예시가 있다. 모델은 묶음 전체를 하나의 벡터로 바꾸고, 트레일 러닝용 방수 신발을 찾는 텍스트 질의와 유사도를 비교한다. 사용자는 파일 이름이나 특정 단어가 일치하지 않아도 상품의 여러 단서를 한꺼번에 검색에 활용할 수 있다.

온디바이스 RAG에서는 이 모델이 관련 로컬 문서를 찾고, Gemma 4 같은 생성 모델이 검색한 자료를 받아 답한다. EmbeddingGemma 자체가 문장 답변을 쓰는 것은 아니다. 블로그는 Gemma 4와 텍스트 토크나이저·오디오 인코더를 공유해 통합 메모리를 줄일 수 있다고 설명한다. 실제 공유 방식과 앱 전체 사용량은 배포 환경에서 확인해야 한다.

한계와 오해하기 쉬운 점

EmbeddingGemma 2는 사전 학습된 임베딩 모델이지 생성 모델이 아니다. 사후 정렬이나 안전 튜닝, 출력 수준 검열을 거치지 않았다. 안전 완화는 학습 데이터 필터링에 집중되었으며, 실제 위험은 임베딩을 어떻게 사용하느냐에 따라 하류 애플리케이션에서 나타난다. 따라서 개발자가 검색 결과 필터링이나 공정성 테스트 같은 애플리케이션 수준 안전장치를 직접 구현해야 한다.

수치 해석에서 주의할 점이 있다. 블로그의 '9.92점 향상'은 MTEB Code v1의 평균 점수 차이이며, 절대적인 코드 이해 능력의 14% 향상을 의미하지 않는다. 모델 카드에는 '~14% improvement on code tasks relative to its predecessor'라고 표현되어 있는데, 이는 68.76에서 78.68로의 상대적 상승률((78.68-68.76)/68.76 ≈ 14.4%)을 가리킨다. 또한 벤치마크 점수는 전체 정밀도 체크포인트 기준이며, 양자화된 온디바이스 배포에서는 성능이 다를 수 있다.

MRL로 벡터를 자른 뒤에는 길이를 다시 맞추는 L2 정규화를 해야 한다. 모델 카드는 이를 건너뛰면 검색 품질이 조용히 떨어질 수 있다고 설명한다. 질문 벡터와 검색 대상 벡터도 같은 차원이어야 한다. 저장량만 줄여 놓고 두 조건을 지키지 않으면 발표된 비교와 다른 설정이 된다.

모델 카드는 float16의 수치 범위가 부족해 NaN이나 품질 저하가 생길 수 있으므로 bfloat16 또는 float32를 사용하라고 안내한다. 지원 언어가 100개 이상이라는 점도 모든 언어에서 같은 정확도를 뜻하지 않는다. 실제 한국어 검색이나 특정 전문 분야에 도입할 때는 자신이 찾을 자료로 별도 평가하는 것이 필요하다.

학습 자료의 수집 기준 시점은 2025년 1월이다. 새 모델 공개일과 학습 자료의 시점은 다르다. 새로운 문서를 입력해 검색용 벡터를 만들 수 있어도, 전문 용어의 의미나 미묘한 풍자·비유를 정확히 연결하는 정도는 입력 분야에 따라 달라질 수 있다.

실제로 어떻게 활용할까

가중치는 Hugging Face와 Kaggle에 공개되며, 모델 카드는 Apache 2.0 라이선스를 명시한다. 기기 내 앱은 Google AI Edge의 MediaPipe나 LiteRT, 일반 실험은 Transformers나 Sentence Transformers 등 문서가 안내하는 도구로 시작할 수 있다. 지원 도구 이름이 많다는 사실보다 자신의 하드웨어에서 원하는 입력 형식과 정밀도가 작동하는지 확인하는 편이 중요하다.

특정 분야에 맞춘 추가 학습 경로도 안내된다. 다만 소량의 레이블만으로 항상 충분하다고 보장하지는 않는다. 먼저 실제 질문과 관련 자료의 쌍으로 기본 모델을 평가하고, 실패 사례가 분야 특유의 표현 때문인지 입력 형식이나 벡터 절단 때문인지 확인하면 추가 학습이 필요한지 판단하기 쉽다.

예를 들어 로컬 코드 검색은 텍스트 전용 구성으로 시작하고, 상품 사진이나 녹음까지 검색하려면 필요한 인코더를 추가한다. 같은 질문 집합으로 768·256·128차원의 결과를 비교하면 저장량과 검색 품질의 절충을 직접 볼 수 있다. 답변을 생성하는 앱에서는 검색 오류와 생성 모델의 답변 오류를 나누어 확인해야 개선 지점을 찾기 쉽다.