임베딩 모델만 바꿨는데 검색이 이상해졌다면

같은 기준으로 만든 벡터끼리 비교해야 하는 관계를 비유한 AI 생성 이미지입니다.

임베딩 모델을 교체할 때는 질문만 새 모델로 바꾸지 말고 문서 벡터를 함께 다시 만들 전환 계획을 세우세요.

새 임베딩 모델을 연결했는데 검색 순위가 이상해졌습니다. API는 정상 응답하고 벡터 차원도 맞습니다. 이때 새 모델의 성능이 나쁘다고 결론 내리기 전에 문서 벡터는 어떤 모델로 만들었는지부터 확인해야 합니다.

문서는 기존 모델 A로, 질문은 새 모델 B로 표현했다면 서로 맞지 않는 공간에서 거리를 계산하고 있을 수 있습니다. 이 글은 2026년 9월 13일 Ollama·Sentence Transformers·모델 공식 문서를 기준으로 전환 절차를 설명합니다. 문서와 질문은 가상 예시이며 실제 벡터나 검색 점수를 생성한 결과는 아닙니다.

차원이 같다는 것은 숫자의 개수가 같다는 뜻입니다

벡터 검색은 문서와 질문을 같은 표현 공간에 놓고 가까운 대상을 찾는 방식입니다. Ollama도 색인과 질의에 같은 임베딩 모델을 사용할 것을 안내합니다. API 호출이 성공하고 벡터 길이가 맞는 것만으로 이 조건이 충족되지는 않습니다. Ollama 임베딩 사용 원칙

예를 들어 두 모델이 모두 768개의 숫자를 반환한다고 하겠습니다. 길이는 같지만 학습된 표현 방식까지 같다는 보증은 없습니다. 한쪽의 좌표와 다른 쪽의 좌표를 섞어 내적을 계산할 수는 있어도 그 값이 원하는 의미적 유사도를 나타낸다고 볼 수 없습니다.

숫자의 개수가 다른 경우에는 데이터베이스가 오류로 알려 줄 수 있지만 같은 차원으로 바뀐 경우에는 계산이 그대로 진행될 수 있습니다. 그래서 오류 로그가 없는데 검색 품질만 나빠지는 상황이 가능합니다.

모델 이름이 같아도 생성 조건은 함께 확인해야 합니다. 실제 모델 파일·리비전, 입력 전처리, 출력 차원과 정규화 같은 조건을 기록합니다. 모델 태그가 가리키는 파일이 바뀌었다면 기존 색인의 생성 조건과 다시 대조할 수 있어야 합니다.

질문과 문서는 같은 모델 안에서도 입력 방식이 다를 수 있습니다

같은 임베딩 모델을 쓴다고 질문과 문서에 완전히 같은 문자열 접두사를 붙여야 하는 것은 아닙니다. 짧은 질문으로 긴 문서를 찾는 검색에서는 모델이 질문용과 문서용 입력을 구분해 학습했을 수 있습니다.

Sentence Transformers는 비대칭 검색에서 encode_query와 encode_document를 구분하는 경로를 안내합니다. 모델에 설정된 프롬프트나 작업별 경로가 있다면 이를 사용할 수 있고, 그런 구분 없이 학습된 모델에서는 결과가 같을 수도 있습니다. 질문·문서 인코딩과 검색 유형

구체적으로 EmbeddingGemma의 공식 모델 카드는 검색 질문에 task와 query 형식을, 문서에는 title과 text 형식을 안내합니다. 프레임워크 설정에 이미 포함돼 있을 수도 있으므로 직접 한 번 더 붙이기 전에 실제 입력 경로를 확인해야 합니다. EmbeddingGemma 입력 지시

따라서 마이그레이션 기록에는 “모델 B 사용” 한 줄보다 더 많은 정보가 필요합니다. 질문 인코딩 방식, 문서 인코딩 방식, 제목 포함 여부, 청크를 나누는 규칙과 최대 길이를 묶어서 관리합니다. 모델은 같아도 한쪽에 제목을 두 번 넣거나 질문용 접두사를 문서에 잘못 적용하면 비교 조건이 달라집니다.

가상의 문서 세 개로 먼저 정답 근거를 고정합니다

예시 색인에는 세 문서가 있다고 하겠습니다. D1은 삭제된 파일을 이전 백업에서 복원하는 방법, D2는 여러 기기 사이에서 폴더를 동기화하는 방법, D3는 서비스에서 내보낸 파일에 일부 첨부가 빠질 수 있다는 주의를 설명합니다.

질문도 먼저 정합니다. “실수로 지운 파일을 어제 상태로 되돌리고 싶다”에는 D1의 복원 절차가 근거가 되어야 합니다. “노트북과 데스크톱에 같은 폴더를 유지하고 싶다”에는 D2가 직접 관련됩니다. “내보내기 파일에 첨부가 전부 들어 있나”에는 D3의 범위 설명이 필요합니다.

이것은 모델이 실제로 낸 검색 순위가 아니라 사람이 준비한 평가 기준입니다. 검색을 돌린 뒤 마음에 드는 문서를 정답으로 바꾸지 않도록 질문과 기대 근거를 먼저 적습니다.

“자동으로 복구해 주나”처럼 정보가 부족한 질문도 넣을 수 있습니다. 어떤 문서의 어떤 기능을 말하는지 불명확하다면 높은 점수 하나만으로 확정 답변을 만들기보다 추가 확인이 필요한 경우로 남깁니다. 평가에는 잘 맞는 질문뿐 아니라 혼동하기 쉬운 질문도 필요합니다.

문서 세 개는 처리 흐름을 점검하기 위한 작은 예시일 뿐 전체 검색 품질을 대표하지 않습니다. 실제 전환 판단에는 자주 묻는 질문, 한국어 표현 변형, 긴 문서와 누락 사례 등 서비스에서 중요한 범위를 포함해야 합니다.

기존 색인을 덮어쓰기 전에 새 색인을 따로 만듭니다

현재 문서 벡터를 모델 A로 만든 색인을 index-a라고 하겠습니다. 모델 B를 시험할 때는 같은 문서 원본에서 index-b를 별도로 만듭니다. 이 이름들은 설명용이며 특정 데이터베이스의 명령이나 실제 운영 색인 이름이 아닙니다.

중요한 연결은 두 쌍입니다. 기존 검색은 질문 A 인코더와 index-a를 함께 사용하고, 새 검색은 질문 B 인코더와 index-b를 함께 사용합니다. 문서 색인만 B로 바꾸거나 질문 인코더만 B로 바꾸는 중간 상태를 사용자 요청에 노출하지 않습니다.

새 문서 벡터를 저장할 때는 원문 문서 ID, 청크 ID, 원문 버전과 벡터 생성 조건을 연결합니다. “벡터가 만들어졌다”는 기록만 있고 어떤 원문 조각인지 찾을 수 없다면 순위가 바뀐 이유를 검토하기 어렵습니다.

원본을 다시 읽어 벡터를 만들므로 개인정보와 접근 권한도 다시 확인해야 합니다. 모델 교체를 이유로 기존에 검색에서 제외했던 문서까지 새 색인에 넣지 않습니다. 접근 제어 필터는 임베딩 모델과 별개의 요구입니다.

이처럼 색인을 분리하는 것은 새 모델을 무조건 채택하기 위한 절차가 아닙니다. 기존 결과를 유지하면서 비교하고 문제가 생기면 돌아갈 수 있도록 선택지를 남기는 방법입니다.

재임베딩 완료는 벡터 개수만으로 판정하지 않습니다

문서가 100개인데 벡터가 100개라는 이유만으로 처리가 끝났다고 볼 수는 없습니다. 문서를 여러 청크로 나눴다면 단위부터 다르고, 중간 실패나 중복 저장이 있어도 개수가 우연히 같을 수 있습니다.

원본 청크 목록과 성공한 결과를 ID 기준으로 대조합니다. 실패한 청크, 중복 ID, 빈 본문, 예상과 다른 차원, 숫자가 아닌 값이나 비정상 값을 별도로 기록합니다. 오류 난 입력을 0벡터로 대신하면 실패가 정상 검색 데이터처럼 들어가게 됩니다.

입력 길이 처리도 확인합니다. Ollama /api/embed의 truncate는 문서 확인일 기준 기본값이 true이며, 한도를 넘는 입력을 자를 수 있습니다. false를 지정하면 초과 입력에 오류를 반환하는 방식입니다. 긴 문서가 모두 반영됐는지 확인하려는 전환 검사에서는 잘림을 조용히 허용할지 의도적으로 정해야 합니다. Ollama embed API의 길이 처리

모델 B의 입력 한도가 더 짧다면 기존 청크를 그대로 넣는 것이 적절하지 않을 수 있습니다. 그렇다고 청크 규칙까지 동시에 바꾸고 순위 차이를 전부 모델 탓으로 해석하지 않습니다. 모델만 바꾼 비교와 청크까지 바꾼 비교를 분리해야 원인을 설명할 수 있습니다.

출력 차원을 줄이는 옵션을 지원하는 모델도 있습니다. 그때는 문서와 질문 양쪽에 같은 차원·후처리 계약을 적용하고, 데이터베이스의 벡터 설정도 맞춰야 합니다. 단순히 긴 벡터를 잘라 붙이면 모든 모델에서 유효한 축소가 되는 것은 아닙니다. 모델별 출력 차원과 재정규화 조건

새 모델의 점수가 더 크다고 개선은 아닙니다

기존 모델에서 유사도 0.6이던 질문이 새 모델에서 0.8이 됐다고 곧바로 성능이 좋아졌다고 판단하지 않습니다. 이 값들은 가상의 비교 숫자이며 실제 측정값이 아닙니다. 모델이 달라지면 점수 분포와 기준이 달라질 수 있기 때문입니다.

먼저 같은 질문에서 상위 k개 결과에 필요한 근거가 들어오는지 봅니다. D1이 필요한 질문에 D2만 반복해서 나온다면 숫자가 높아도 목적을 달성하지 못한 것입니다. 문서 제목뿐 아니라 반환된 청크 안에 실제 답의 근거가 있는지 확인합니다.

기존 검색의 점수 임계값을 새 모델에 그대로 가져오는 것도 검증 대상입니다. 답할 자료가 없는 질문을 근거 있는 질문처럼 받아들이거나, 필요한 문서를 점수가 낮다는 이유로 버릴 수 있습니다.

검색 엔진의 근사 탐색 설정과 거리 함수도 고정하거나 변경 사실을 기록합니다. 근사 최근접 검색은 일부 가까운 벡터를 놓칠 수 있으므로 모델 변경과 인덱스 탐색 설정 변경을 섞으면 품질 차이의 원인을 구분하기 어렵습니다. 근사 검색의 정확도·속도 절충

RAG라면 검색과 답변 생성도 나눠 봅니다. 근거 문서는 잘 찾았는데 생성 모델이 잘못 요약한 경우와, 애초에 필요한 근거를 못 찾은 경우에 같은 수정을 하면 안 됩니다. 임베딩 교체 검수의 첫 대상은 검색 결과입니다.

전환과 복구는 인코더·색인을 한 쌍으로 다룹니다

전환 전에 새 색인이 어떤 원문 버전까지 반영했는지 확인합니다. 재임베딩 중 추가·수정·삭제된 문서가 있다면 변경분을 새 색인에도 반영할 방법이 필요합니다. 처음 만든 스냅샷만 비교하고 그 뒤의 변경을 놓치지 않습니다.

실제 전환에서는 요청 하나가 질문 B 인코더와 index-a를 섞어 쓰지 않도록 설정을 묶습니다. 캐시된 질문 벡터나 검색 결과가 있다면 그 캐시 키에도 생성 조건이나 색인 버전이 구분돼야 합니다. 오래된 질문 벡터를 새 색인에 재사용하면 처음의 문제가 다시 생깁니다.

문제가 생겼을 때는 인코더와 색인을 함께 기존 조합으로 되돌립니다. 새 문서가 계속 들어오는 서비스라면 기존 색인도 어디까지 최신 상태인지 확인해야 합니다. 단순히 예전 색인이 남아 있다는 사실만으로 손실 없는 복구가 보장되지는 않습니다.

기존 색인을 지우는 시점은 새 조합의 품질·누락·운영 안정성을 확인한 뒤 별도로 정합니다. 모델 교체 버튼을 누르는 순간 검증 자료와 복구 경로까지 없애는 방식은 피하는 편이 좋습니다.

교체의 단위는 모델 이름이 아니라 검색 파이프라인입니다

임베딩 모델을 바꾼 뒤 검색이 이상하다면 문서와 질문의 모델, 입력 방식, 청크와 길이 처리, 벡터 차원·정규화, 거리 함수와 캐시를 순서대로 대조합니다. API의 정상 응답은 그중 한 단계의 성공일 뿐입니다.

새 모델을 채택할 근거는 높은 숫자 한 개가 아니라 필요한 문서를 더 안정적으로 찾고, 누락 없이 전환하며, 문제 때 기존 조합으로 돌아갈 수 있는지입니다. 질문 인코더와 문서 색인을 같은 계약으로 묶어 바꾸면 모델 교체를 검색 품질의 개선으로 연결할 수 있습니다.