EmbeddingGemma로 검색을 만들 때 질문과 문서를 다르게 넣는 이유

모양이 다른 나무 틀에 맞춰 놓인 종이 띠. 이해를 돕기 위한 AI 생성 개념 이미지입니다.

검색용 임베딩 모델을 바꾼 뒤 결과가 어색해졌다면 모델의 순위표보다 입력 형식부터 확인할 만합니다. 같은 문장이라도 질문인지 문서인지에 따라 모델이 기대하는 형식이 다를 수 있습니다.

임베딩 모델을 바꿀 때는 질문 형식, 문서 형식, 벡터 차원을 한 묶음으로 고정하세요.

EmbeddingGemma는 답변을 쓰는 모델이 아닙니다

Google 모델 카드는 EmbeddingGemma를 텍스트를 벡터로 표현하는 308M 파라미터 모델로 설명합니다. 100개가 넘는 언어의 텍스트를 다루며 최대 입력 문맥은 2K 토큰입니다. 생성형 챗봇처럼 답변 문장을 길게 만드는 용도가 아니라 검색·분류·유사도 같은 작업의 표현을 만드는 용도입니다.

공개 소개와 모델 카드를 보면 검색 질문과 문서 입력에 서로 다른 프롬프트가 안내됩니다. 따라서 “문장을 넣으면 벡터가 나온다”는 함수 모양만 맞춰 다른 모델과 교체하면, 필요한 전처리가 빠질 수 있습니다. 2K 토큰보다 긴 원문은 청크 분할 규칙도 함께 설계해야 하며, 긴 문서를 그대로 넣을 수 있다는 뜻은 아닙니다.

질문과 문서가 맡은 역할을 입력에 표시합니다

공식 모델 카드의 검색용 형식은 질문에 task: search result | query:, 문서에 title: ... | text: 같은 접두부를 사용합니다. 이 모델 카드에는 검색 외에도 질문 답변·사실 확인·분류·문장 유사도처럼 작업별 프롬프트가 따로 제시됩니다. 아래 내용은 검색 형식을 보여주는 가상 텍스트입니다.

질문:
task: search result | query: 전원이 꺼진 뒤 설정은 남나요?

문서:
title: 설정 저장 안내 | text: 설정은 비휘발성 저장소에 기록됩니다.

문서 제목이 있으면 본문과 구분해 넣습니다. 사용하는 프레임워크가 이미 이런 형식을 자동으로 붙이는지도 확인해야 합니다. 수동으로 한 번, 라이브러리에서 한 번 더 붙이면 의도한 입력과 달라질 수 있습니다.

Sentence Transformers 예시는 역할을 함수로 분리합니다. 실행 결과나 검색 품질을 재현한 코드는 아니지만, 질문과 문서가 같은 함수에 뒤섞이지 않게 하는 형태를 보여줍니다.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("google/embeddinggemma-300m")
query_vector = model.encode_query(["전원이 꺼진 뒤 설정은 남나요?"])
document_vectors = model.encode_document([
    "설정 저장 안내: 설정은 비휘발성 저장소에 기록됩니다."
])

이 예시가 실제로 가장 가까운 결과를 반환한다는 뜻은 아닙니다. 모델에 들어가는 두 경로와 프레임워크의 prompt mapping을 확인할 수 있도록 풀어 쓴 것입니다.

벡터 길이만 같다고 섞을 수는 없습니다

모델 카드는 기본 768차원 출력과 512·256·128차원 선택지를 제시합니다. Matryoshka Representation Learning으로 앞부분을 잘라 차원을 줄인 뒤 재정규화하는 방식이지만, 차원을 줄이면 저장·검색 비용과 품질의 교환이 생깁니다. 다른 모델이 같은 길이의 벡터를 내놓는다고 서로 같은 공간을 공유한다고 가정해서는 안 됩니다.

실무적인 전환 방법으로는 기존 인덱스를 바로 덮어쓰기보다 새 모델·새 입력 형식·새 차원으로 별도 인덱스를 만들고 비교하는 방식을 제안합니다. 새 질문 벡터를 오래된 문서 벡터와 비교하면, 검색 시스템은 실행돼도 의미 있는 비교가 아닐 수 있습니다.

인덱스 기록에는 적어도 모델 식별자, 질문·문서 전처리, 출력 차원, 정규화 여부를 함께 남겨야 무엇이 바뀌었는지 추적하기 쉽습니다. 이것은 이 글의 운영 제안이며 모델 카드의 필수 파일 형식은 아닙니다.

한국어 검색은 한국어 질문으로 판단합니다

여러 언어를 지원한다는 설명이나 평균 벤치마크는 내 자료의 검색 품질을 대신하지 않습니다. 한국어 질문에 영문 제품 코드가 섞이는 경우, 줄임말, 띄어쓰기 변형, 문서에 없는 질문을 포함해 봅니다.

예를 들어 “설정이 날아가요”와 “비휘발성 저장소”를 연결해야 하는 질문, 제품 번호를 정확히 맞춰야 하는 질문은 다른 실패를 드러낼 수 있습니다. 정답 문서가 후보에 들어오는지와 틀린 문서가 과도하게 높아지는지를 같이 보세요.

검색 코드에서 질문과 문서 함수를 분리합니다

같은 embed(text) 함수 하나로 모두 처리하면 접두부 누락을 발견하기 어렵습니다. 다음은 역할을 분리하는 가상 의사 코드입니다.

embed_query(q):
    return model("task: search result | query: " + q)

embed_document(title, body):
    return model("title: " + title + " | text: " + body)

실제 문자열은 현재 모델 카드와 사용 라이브러리를 따라야 합니다. 프레임워크가 접두부를 자동으로 넣는다면 위 처리를 중복하지 않습니다. 중요한 것은 질문 경로와 문서 인덱싱 경로가 같은 모델 버전, 호환되는 입력 계약, 같은 출력 차원과 정규화 규칙을 사용한다는 점입니다.

요청 로그에는 원문 전체 대신 전처리 버전과 모델 식별자를 남길 수 있습니다.

{
  "index": "manuals-v3",
  "model": "embeddinggemma-...",
  "document_template": "doc-v2",
  "query_template": "query-v2",
  "dimension": 768,
  "normalized": true
}

모델 이름만 기록하면 접두부나 차원 변경으로 결과가 달라진 이유를 찾기 어렵습니다.

모델 교체는 재인덱싱 작업입니다

새 모델이 같은 차원의 벡터를 반환해도 기존 벡터와 같은 의미 공간이라는 보장은 없습니다. 안전한 전환은 새 인덱스를 따로 만드는 것입니다.

1. 기존 인덱스의 모델·전처리·차원을 고정해 기록합니다.
2. 같은 문서 집합을 새 입력 계약으로 다시 임베딩합니다.
3. 새 질문도 새 질문 형식으로 임베딩합니다.
4. 평가 질문을 두 인덱스에 각각 실행합니다.
5. 정답 포함, 오답 상승, 지연과 저장 공간을 비교합니다.
6. 전환 후에도 되돌릴 수 있도록 이전 인덱스를 일정 기간 유지합니다.

새 질문 벡터를 기존 문서 벡터와 섞는 상태를 막기 위해 인덱스 메타데이터와 요청의 모델 버전이 다르면 실패시키는 검사도 둘 수 있습니다. 검색 결과가 나온다는 것과 비교가 유효하다는 것은 다릅니다.

한국어 평가 묶음을 실제 검색 의도대로 만듭니다

유형	가상 질문	확인할 것
자연어↔전문 용어	설정이 꺼졌다 켜도 남나요?	비휘발성 저장 설명을 찾는가
영문 코드 혼합	ZX-41 초기화 방법	코드를 다른 모델과 혼동하지 않는가
띄어쓰기 변형	계정 복구 / 계정복구	같은 근거 후보에 도달하는가
부정 표현	삭제되지 않는 설정	반대 의미 문서를 올리지 않는가
문서 밖 질문	지원하지 않는 기능	무관한 문서를 억지로 높이지 않는가

정답 문서가 상위 k에 포함되는지뿐 아니라 명백한 오답이 1위로 올라오는 경우와 빈 결과가 필요한 질문도 봅니다. 다국어 평균 벤치마크가 이 자료의 제품 코드와 한국어 표현을 대체하지 않습니다.

차원 선택은 저장 공간만의 문제가 아닙니다

출력 차원을 줄이면 벡터 저장량과 검색 계산량이 달라질 수 있지만 검색 품질도 실제 자료에서 비교해야 합니다. 문서 벡터만 다른 차원으로 바꾸거나 질문 경로가 기본 차원을 유지하면 아예 비교할 수 없습니다. 인덱스 스키마, 질문 임베딩, 검색 엔진 설정을 한 번에 맞춥니다.

후보 검색 뒤 리랭커를 쓰는 시스템이라면 임베딩 단계의 목표는 정답을 초기 후보에 넣는 것입니다. 최종 1위만 보지 말고 초기 후보 회수와 후속 재정렬을 구분해야 어느 모델을 고칠지 알 수 있습니다.

확인일과 한계

2026년 9월 7일 확인한 EmbeddingGemma 공개 자료 기준입니다. 설치·추론을 실행하지 않았고 한국어 성능 순위를 제시하지 않습니다. 도입 전에 현재 모델 카드의 이용 조건과 프레임워크별 입력 처리를 확인해야 합니다.