하나의 프라이빗 검색 시스템에서 여러 임베딩 모델을 함께 사용할 수 있나요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Can Multiple Embedding Models Coexist in One Private Search System?

예. 하나의 비공개 검색 시스템에서 여러 모델의 임베딩을 동시에 저장하고 쿼리할 수 있습니다. 안전한 방법은 각 임베딩 모델을 명시적인 차원, 거리 측정 지표, 버전 및 인덱스 구성과 함께 고유한 벡터 공간으로 취급하는 것입니다. 호환되지 않는 벡터를 하나의 이름 없는 열에 섞어 저장하고 서로 비교할 수 있다고 가정하지 마세요.

여러 모델은 마이그레이션, 다국어 검색, 이미지와 텍스트를 결합한 검색, 도메인별 임베딩 또는 A/B 테스트에 유용합니다. 이러한 공간 전반에서 결과를 결합해야 할 때 복잡성이 나타납니다.

왜 둘 이상의 임베딩 모델을 유지해야 할까요?

이유	예시
모델 마이그레이션	새 벡터를 백필하는 동안 기존 인코더를 계속 활성 상태로 유지
다국어 검색	일반 영어 모델 + 다국어 모델
서로 다른 모달리티	텍스트 임베딩 + 이미지 임베딩
도메인 특화	일반 문서 + 코드 임베딩
품질 테스트	프로덕션 모델을 교체하기 전 A/B 검색
지연 상호작용	밀집 검색기 + ColBERT 스타일 재순위 지정

비공개 지식 기반은 계속 발전합니다. 선택한 첫 임베딩 모델에 모든 문서를 영구적으로 고정하면 업그레이드가 불필요하게 큰 부담이 됩니다.

모델마다 서로 다른 벡터 공간을 생성합니다

두 모델이 모두 768차원 벡터를 출력하더라도 호환되지 않을 수 있습니다. 좌표는 해당 벡터를 생성한 모델을 기준으로 할 때만 의미가 있습니다.

문서 A
  |
  +-- Model v1 -> vector_v1 [768]
  |
  +-- Model v2 -> vector_v2 [1024]
  |
  +-- 이미지 모델 -> vector_image [512]

Model v2로 생성된 쿼리는 v2 공간을 검색해야 합니다. API가 차원을 허용하더라도 이를 Model v1 벡터와 직접 비교하는 것은 의미가 없습니다.

Qdrant의 현재 명명된 벡터 문서에서는 동일한 포인트에 서로 다른 크기와 유형의 여러 벡터를 저장할 수 있도록 명시적으로 지원하며, 각 벡터는 별도의 명명된 벡터 공간에 저장됩니다.

단순한 벡터 이름이 아닌 모델 레지스트리를 사용하세요

모든 임베딩을 재현할 수 있도록 충분한 메타데이터를 기록하세요:

임베딩 공간: text_v2
모델 ID:        example/model-name
모델 리비전:  sha 또는 버전
벡터 차원:      1024
측정 지표:          코사인
정규화됨:      true
청킹 정책: 의미 기반 v3
생성 시각:      2026-09-03

청킹도 레지스트리에 포함해야 합니다. 임베딩 모델과 문서 분할 방식을 모두 변경하면 두 가지 이유로 검색 결과가 달라집니다. 파이프라인 버전을 명시적으로 관리하면 비교와 롤백이 가능합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

동일한 객체에서 명명된 벡터를 사용할까요, 아니면 별도의 컬렉션을 사용할까요?

두 설계 모두 올바를 수 있습니다.

설계	적합한 경우	절충안
동일한 객체의 명명된 벡터	모델 간 동일한 문서/페이로드	더 큰 객체/인덱스 사용 공간
별도 컬렉션	스키마, 수명 주기, 규모 또는 권한이 서로 다름	더 많은 동기화 작업
Postgres 테이블 하나 + model_id	SQL 중심 스택	인덱스의 범위를 올바르게 설정해야 합니다

Weaviate의 컬렉션 문서도 객체마다 여러 개의 명명된 벡터 공간을 지원하며, 각 공간에는 고유한 벡터라이저와 인덱스 구성이 적용됩니다.

권한이 다르다면(예: 가족 문서와 업무 문서) 모든 표현을 하나의 객체에 넣는 것보다 별도의 컬렉션을 사용하는 편이 더 깔끔할 수 있습니다.

Pgvector는 서로 다른 차원을 저장할 수 있나요?

Pgvector의 문서에는 model_id가 포함된 일반적인 vector 열을 보여 주며, 특정 차원에 해당하는 행에 대해 표현식 인덱스와 부분 인덱스를 사용합니다.

원칙은 동일합니다. 데이터 모델에 모델 식별 정보를 유지하고 호환되는 행에 대해서만 ANN 인덱스를 구축하세요.

모델 간 원시 유사도 점수를 비교하지 마세요

가장 미묘한 실패는 이것입니다. 모델 A의 코사인 유사도 0.78이 모델 B의 0.78과 반드시 같은 품질을 의미하지는 않습니다. 점수 분포는 모델 학습, 정규화, 메트릭, 도메인 및 인덱스 동작에 따라 달라집니다.

두 임베딩 모델에서 하나의 결과 목록을 만들려면 먼저 별도로 검색합니다.

쿼리
  |
  +-- 모델 A -> 상위 20개 결과 + 순위
  |
  +-- 모델 B -> 상위 20개 결과 + 순위
                      |
                      v
               융합 / 재순위 모델
                      |
                      v
                  최종 상위 10개

더 안전한 결합 방법으로는 순위 융합, 데이터에 맞게 보정한 모델별 점수 정규화, 또는 검색 후 후보 텍스트를 평가하는 크로스 인코더/재순위 모델이 있습니다.

Weaviate의 다중 대상 검색 문서에서는 정규화/가중 조합을 포함한 결합 전략을 설명합니다. 이는 서로 다른 공간 간의 퓨전에는 단순한 원시 점수 정렬이 아니라 명시적인 전략이 필요하다는 점을 보여줍니다.

다운타임 없이 새 임베딩 모델로 마이그레이션하려면 어떻게 해야 할까요?

기존 임베딩을 먼저 삭제하지 마세요. 병렬 마이그레이션을 사용하세요.

새 모델과 벡터 공간을 등록하세요.
새로 수집되는 문서에 대해 새 임베딩을 생성하세요.
기존 문서를 일괄 처리로 백필하세요.
두 공간에 대해 섀도 검색을 실행하세요.
실제 질문을 대상으로 재현율과 작업 성공률을 비교하세요.
기본 쿼리 공간을 전환하세요.
롤백 기간 동안 기존 벡터를 유지하세요.
확신이 충분히 높아진 후에만 삭제하세요.

Weaviate는 새 명명된 벡터를 추가해도 기존 객체가 자동으로 다시 벡터화되지는 않는다고 설명합니다. 이 동작을 기억해 두면 유용합니다. “스키마가 새 모델을 지원함”과 “기존 모든 데이터에 새 벡터가 있음”은 서로 다른 단계이기 때문입니다.

여러 임베딩은 많은 사용자가 예상하는 것보다 빠르게 스토리지를 늘립니다

추가되는 각 벡터 표현은 또 하나의 밀집 배열과 ANN 인덱스를 추가할 수 있습니다. 따라서 두 번째 임베딩 모델을 사용하면 원본 문서는 한 번만 저장되더라도 데이터베이스의 벡터/인덱스 부분이 대략 두 배가 될 수 있습니다.

추정:

벡터 바이트 ≈
  문서 청크
  × 차원 수
  × 요소당 바이트 수
  × 임베딩 공간 수

+ ANN 인덱스 오버헤드
+ 메타데이터 / 페이로드 인덱스

양자화 또는 반정밀도 인덱스를 사용하면 용량을 줄일 수 있지만, 모든 모델에 압축을 적용하기 전에 검색 품질을 테스트하세요.

이는 로컬 지식 베이스 아키텍처에 대한 질문과도 연결됩니다. 임베딩은 교체 가능한 파생 데이터인 반면, 원본 문서와 메타데이터는 재구축을 가능하게 하는 지속적인 자산입니다.

쿼리 경로마다 다른 모델 사용

모든 질문마다 모든 벡터 공간을 검색할 필요는 없습니다. 필요에 따라 라우팅하세요.

쿼리	임베딩 공간
영어 홈 매뉴얼	general_text_v2
중국어 + 영어 메모	multilingual_v1
소스 코드 질문	code_v1
유사한 사진 찾기	image_v1
알 수 없는 검색 / 광범위한 검색	두 개의 공간 + 순위 퓨전

간단한 쿼리 분류기가 적절한 공간을 선택할 수 있으며, 모호한 검색은 두 표현 공간으로 확장한 후 결과를 병합할 수 있습니다.

권한은 퓨전보다 먼저 적용되어야 합니다

모든 벡터 공간에서 권한이 없는 후보를 검색한 뒤 최종 재순위화 모델이 이를 숨기기를 기대하지 마세요. 각 검색 단계에서 사용자/문서 권한을 적용하여 민감한 청크가 후보 집합, 로그 또는 재순위화 프롬프트에 들어가지 않도록 하세요.

프라이빗 NAS 검색에서는 모델을 마이그레이션할 때도 동일한 접근 제어 규칙이 유지되어야 합니다. 새 인덱스는 문서의 권한 메타데이터를 상속해야 하며, 일시적으로 보호되지 않는 복사본이 되어서는 안 됩니다.

프라이빗 AI 어시스턴트 가이드에서 더 큰 맥락을 확인할 수 있습니다. 벡터 검색은 파일 저장소와 동일한 프라이빗 데이터 경계를 준수할 때만 유용합니다.

다중 임베딩 QA 체크리스트

각 임베딩 공간에 고유한 모델/버전 ID를 부여하세요.
차원, 정규화 및 거리 측정 지표를 기록하세요.
청킹과 전처리의 버전을 관리하세요.
한 모델의 벡터를 다른 모델의 인덱스에 절대 쿼리하지 마세요.
보정 없이 서로 다른 공간의 원시 점수를 직접 비교하지 마세요.
모든 검색 경로에 권한을 적용하세요.
기본값을 변경하기 전에 새 벡터를 백필하세요.
실제 질문과 관련성이 이미 확인된 문서를 사용해 평가하세요.
롤백 기간 동안 이전 인덱스를 유지하세요.
추가 벡터와 인덱스를 디스크/RAM 용량 계획에 포함하세요.

자주 묻는 질문

두 임베딩 모델이 하나의 데이터베이스에서 서로 다른 차원을 사용할 수 있나요?

예. 데이터베이스가 호환되는 차원별로 별도의 이름이 지정된 벡터 공간, 컬렉션 또는 인덱스를 지원한다면 가능합니다. Qdrant, Weaviate, pgvector는 모두 이를 위한 패턴을 제공합니다.

기존 문서를 다시 임베딩하지 않고 임베딩 모델을 전환할 수 있나요?

새 모델의 벡터 공간에서 기존 문서를 검색하려는 경우에는 보관할 필요가 없습니다. 새 쿼리 벡터는 다른 모델이 생성한 임베딩과 호환되지 않습니다.

기존 임베딩을 영원히 보관해야 하나요?

아니요. 평가와 롤백을 위해 유지하세요. 새 모델이 검증되고 마이그레이션이 완료되면 오래된 벡터를 제거하여 상당한 저장 공간과 인덱스 메모리를 확보할 수 있습니다.

최종 결론

벡터 공간을 명확하게 유지하면 여러 임베딩 모델이 하나의 프라이빗 검색 시스템에서 문제없이 공존할 수 있습니다. 모델 및 파이프라인 메타데이터를 저장하고, 일치하는 인코더로 각 공간을 검색하며, 결과를 신중하게 결합하고, 병렬로 백필하여 마이그레이션하세요. 위험한 설계는 “모델이 둘 이상인 것”이 아닙니다. 어떤 모델이 어떤 벡터를 생성했는지 추적하지 못하고 모든 유사도 점수가 같은 의미를 가진다고 가장하는 것이 문제입니다.