EmbeddingGemma 2 검색 평가: 양자화의 수치 오차와 정답 자료의 순위를 가르는 요인

EmbeddingGemma 2 도입 여부를 판단하려면, 구현체가 참조 모델의 출력과 유사한지, 그리고 검색을 통해 원하는 자료를 찾을 수 있는지를 각각 확인해야 한다. 정답과 오답의 점수가 근접하면 작은 벡터 차이로도 순위가 바뀔 수 있다.

본 글에서는 MLX-VLM 작성자의 수치 검증 결과를 어떻게 해석할지, 그리고 정답 자료와 까다로운 오답 사례를 가진 평가 데이터를 어떻게 구성할지를 다룬다. 마지막으로, 직접 입력한 합성 벡터를 이용해 '수치 차이가 작아도 순위가 역전되는' 사례를 pure Python으로 재현한다.

실행된 것은 합성 벡터의 평가 코드만이다. EmbeddingGemma 2 본체, BF16・4bit 추론, 한국어 검색 품질, 실제 RAM이나 속도는 측정하지 않았다.

새로운 모델을 평가하는 단위

Google이 2026년 10월 7일 01:00 JST에 발표한 EmbeddingGemma 2는 텍스트, 이미지, 음성, 비디오 등을 공통의 검색 표현으로 변환하는 모델이다. 출력의 기본은 768차원이며, 512・256・128차원으로 축소할 수 있다. 공식 발표, 고정 공식 카드

고려해야 할 단위는 단순히 모델 이름만으로는 충분하지 않다. checkpoint, processor, 태스크 지정, 차원, 정밀도(precision), runtime을 통합한 구성별로 평가해야 한다. 여러 조건을 동시에 변경했을 경우 품질 차이를 하나의 원인으로 귀속시키지 않아야 한다.

예를 들어 256차원을 선택할 때, query와 자료를 같은 차원으로 맞춘 후 축소하고 L2 정규화한다. 공식 카드는 128차원에서 다중 미디어의 품질이 크게 저하될 수 있다고 설명하며, '요소 수가 6분의 1이니 품질도 유지된다'고 단정할 수 없다. 또한 추론 정밀도는 BF16 또는 F32를 지정하고, F16을 피해야 하는 조건을 확인한다. 공식 카드의 축소 및 정밀도 설명

여기서 구성을 결정하는 목적은 좋은 결과만 나중에 선택하기 위함이 아니다. 어떤 변경 사항을 평가했는지 추적할 수 있도록 하기 위함이다.

작성자의 4bit 검증이 답하는 질문

MLX-VLM의 고정 main README에는 Apple M5 Max에서의 BF16・4/6/8bit 검증이 기재되어 있다. 통상 4bit의 최소 embedding cosine은 0.96716으로, 작성자가 문서화한 정밀도 조건을 충족하지 못했다는 결과였다. 이는 참조 측의 출력과 얼마나 일치하는지를 확인한 작성자의 결과이다. MLX-VLM 고정 README

이 cosine 값은 같은 입력에 대한 후보 구현체와 참조 구현체의 embedding끼리 비교하는 값이다. 검색어와 정답 자료의 점수나 한국어 검색의 정답률과는 무관하다. 작성자가 확인한 대상・reference revision・전처리・장비에 묶여서 읽어야 한다. README 검증에서는 checkpoint fc77679a26fcb86250765859d04ce2fcc6cb0b2c와 extras f6c512df20896fd06f85d39db10c45a0a9849ef8를 사용하고 있으며, 이번에 확인한 Google 공식 카드의 revision과 동일하다고 취급해서는 안 된다. 다른 양자화 recipe나 runtime에 같은 결과를 그대로 옮겨서는 안 된다.

설계상으로는 검증을 세 가지로 나눈다.

같은 query라도 정답 자료가 여러 개 있다면, 정답 집합(gold set)을 갖는다. 코퍼스에 답이 없는 query는 별도의 그룹으로 분류하여, 실수로 높은 스코어의 자료를 채택하는 비율이나 보류(retention)되는 행동을 평가한다. 정답 집합이 비어있을 경우 Recall은 계산하지 않는다.

매체를 섞은 전체 평균 외에도 text→text, text→image, text→audio로 나누어 본다. 동영상까지 포함할 경우에는 그 실행 경로의 입력 대응과 샘플링 조건을 먼저 확인해야 한다. 확인일 2026년 10월 7일 기준 Ollama v0.40.0의 고정 runner는 이미지와 음성을 분리하고, 동영상에는 대응하지 않는다.

순위와 스코어 여유 기록하기

Recall@k는 정답 집합 중 상위 k개에 몇 개가 포함되었는지 측정한다. 정답 집합을 R, 상위 k개를 T라고 할 때, |T ∩ R| / |R|이다. 첫 번째 정답의 순위를 r로 하여 1 / r를 취하는 지표가 reciprocal rank (RR)이며, 여러 query의 평균이 MRR이 된다.

본 기사의 작은 예시에서는 코퍼스 전체를 나열하여 평가한다. 실제 근사 검색(approximate search)에서 상위 k개만 얻은 경우에는, 범외(out of scope)를 어떻게 계산할지 평가 절차에 명기해야 한다.

더불어, 정답과 가장 혼동하기 쉬운 부정 예시(negative example)의 스코어 차이를 기록한다.

margin = 정답 자료의 스코어 - 어려운 부정 예시의 스코어

정답이 상위권에 있더라도 margin이 매우 작다면, 조건 변경 시 순위가 움직이기 쉬운 사례로 점검할 수 있다. 다만 margin 값을 그대로 '정답 확률'로 해석해서는 안 된다. 동점일 경우의 순위 규칙도 고정하고, 그 규칙에 의한 우연한 성공을 구별해야 한다.

작은 수치 차이로 순위가 바뀌는 합성 예시

다음 코드는 query, 정답 예시, 부정 예시의 벡터를 모두 수동으로 정의했다. reference와 changed는 두 가지 합성 출력의 이름이며, BF16과 4bit 모델 출력이 아니다.

Python 3.9 이후 표준 라이브러리만으로 구동 가능하다. retrieval_eval.py로 저장한다.

"""Toy paired ranking evaluation; vectors are manually defined."""
import math
def unit(vector):
...

python3 retrieval_eval.py

2026년 10월 7일, macOS 27.0.1 / Apple Silicon / CPython 3.9.6에서 실행한 결과는 다음과 같다.

max-vector-l2-drift: 0.001999991
reference: Recall@1=1.0 RR=1.0 margin=0.000002500
reference-order: ['gold', 'hard-negative', 'unrelated']
...

정규화된 벡터의 L2 차이는 최대 약 0.002이다. 그럼에도 정답 예시와 부정 예시의 스코어가 가깝기 때문에, 맨 앞 자료가 바뀌었다. 상위 1개 Recall은 1에서 0으로, 단일 query의 RR은 1에서 0.5로 변하고 있다.

이는 작은 차이로 순위가 바뀔 수 있음을 보여주는 합성 예시이다. EmbeddingGemma 2의 양자화(quantization)로 인해 이러한 역전이 발생했다는 측정은 아니다. reference의 품질을 보장한 예시도 아니며, 평가 지표의 의미를 확인하기 위한 것이다.

추가 검사 11건에서는 순위와 margin의 변화, 정답이 여러 개일 때의 Recall 분모, 차원 불일치(dimension mismatch), 정답 자료가 코퍼스에 없을 경우, 빈 정답 집합 등을 확인했다. 모두 합성 입력상의 평가 코드 검사이며, 일본어 검색 벤치마크는 아니다.

구성 변경을 비교하는 절차

실제 데이터로 시도할 경우에는, 같은 자료・query・정답 레이블을 사용하여 다음과 같이 구성별 쌍 비교를 수행한다.

• 기준 구성(baseline configuration)으로 query와 자료를 모두 임베딩하고, 인덱스와 평가 결과를 저장한다.
• 후보 구성(candidate configuration)에서도 모두 임베딩하여 다른 인덱스에 저장한다.
• 같은 query 그룹으로 Recall@k, MRR, 매체별 실패, margin을 비교한다.
• 대상 용도에서 허용하는 실패를 점검하고, 채택 조건을 결정한다.

768→256의 변경이나 양자화 변경에서는, 기준 인덱스의 자료 벡터에 후보 구성의 query만 적용하는 방법을 피해야 한다. 호환성을 검증하지 않은 구성을 섞으면, 비교하는 조건이 불분명해진다. 모델・프로세서(processor)・런타임(runtime)・차원・정규화・프롬프트 방침도 결과에 연결한다.

평가용 데이터로 조정하는 후에는, 미사용의 확인용 데이터를 남겨 최종 점검을 한다. 작은 평가 그룹의 평균값만으로 모든 용도의 품질을 보장하지 않으며, query별 개선/악화 추이와 건수도 살펴본다. 레이턴시나 RAM을 측정할 때는 로드 포함/제외 여부, 매체, 입력 길이, 장비, 동시 처리 수를 별도로 기록한다. 배포 파일의 크기를 실제 RAM 용량으로 오해해서는 안 된다.

점검 시점에서 MLX-VLM 통합 PR은 main 브랜치에 들어와 있지만, 정식 배포 버전은 0.7.6을 유지한다. main 내의 0.7.7 표기는 이미 공개된 동일한 공식 패키지로 간주하지 않는다. 위의 합성 Python 코드는 이 MLX-VLM 실행 환경을 도입한 것이 아니다. 통합 PR과 정식 릴리스

EmbeddingGemma 2를 채택할지 여부를 판단하는 데 필요한 것은, 출력의 수치적 일관성, 실제 자료 순위, 운영상의 비용을 동일한 구성에 맞춰 대응시키는 것이다. 작성자의 검증을 출발점으로 삼으면서도, 자신의 자료에 대한 정답과 실패 사례(negative example)를 고정하면, 어떤 조건을 테스트했고 어떤 실패를 허용했는지 설명할 수 있다.

Discussion