단일 벡터 모델의 압축 손실과 정보 희석 문제

기존의 밀집 임베딩(Dense Embedding) 모델은 전체 텍스트를 384, 768 또는 1024개의 고정된 숫자로 구성된 단일 벡터로 압축한다. 모델은 텍스트의 모든 정보를 하나의 벡터에 담기 위해 평균화 과정을 거치며, 이 과정에서 정보가 손실되는 '손실 압축' 현상이 발생한다. 특히 제품 코드, 성함, 함수 이름과 같이 단 한 글자의 차이가 중요한 희귀 식별자나 긴 지문 속의 핵심 절은 동일한 벡터 공간 내에서 다른 정보들과 경쟁하며 희석된다.

단일 벡터 모델은 여러 요구사항이 포함된 복합 쿼리를 처리할 때 한계가 명확하다. 예를 들어 '나무 다리와 둥근 쿠션이 있는 초록색 소파'라는 쿼리를 입력하면, 모델은 네 가지 세부 조건을 하나의 점으로 뭉뚱그려 표현한다. 결과적으로 다리 모양이 다르더라도 색상이 일치하는 소파가 검색 결과 상단에 배치되는 등 정밀도가 떨어지는 결과가 나타난다. 이러한 압축 손실은 문서의 길이가 길어질수록 심화되며, 고정된 크기의 벡터에 더 많은 텍스트를 밀어 넣어야 하기 때문이다.

학습 데이터의 분포와 실제 운영 환경의 데이터 분포가 다른 '도메인 외(Out-of-domain)' 데이터 처리 시에도 문제는 발생한다. 모델은 학습 단계에서 중요하다고 판단한 정보 위주로 압축하는 법을 배우므로, 실제 서비스에서 사용자가 찾는 핵심 정보가 학습 분포에 없었다면 이를 무시하고 삭제할 가능성이 크다. 엔지니어는 이러한 단일 벡터의 구조적 한계로 인해 정밀한 토큰 매칭이 필요한 시나리오에서 검색 품질 저하를 경험하게 된다.

멀티 벡터 구조와 Late Interaction의 작동 원리

멀티 벡터 모델(Multi-vector model)은 텍스트 전체를 하나의 벡터로 압축하는 대신, 각 토큰당 하나의 벡터를 개별적으로 유지하는 방식을 채택한다. 이는 ColBERT 논문에서 제안된 '지연 상호작용(Late Interaction)' 구조를 따르며, 트랜스포머 모델을 통해 생성된 각 토큰 임베딩을 작은 차원(통상 128차원)으로 투영하여 모두 보존한다. 예를 들어 9개의 토큰으로 구성된 문서는 1x128 벡터가 아닌 9x128 행렬 형태로 저장된다.

지연 상호작용 방식은 상호작용 시점을 점수 계산 단계까지 미룸으로써 효율성과 정확성을 동시에 확보한다. 크로스 인코더(Cross-encoder)는 두 텍스트를 모델에 동시에 넣어 조기에 상호작용시키므로 정확하지만, 모든 문서를 매번 다시 인코딩해야 해 사전 계산이 불가능하다. 반면 바이 인코더(Bi-encoder)인 단일 벡터 모델은 요약된 두 벡터의 내적 한 번으로 계산을 끝내므로 매우 빠르지만 상호작용이 거의 없다. 멀티 벡터 모델은 문서를 독립적으로 인코딩하여 오프라인으로 인덱싱할 수 있으면서도, 검색 시점에는 쿼리 토큰과 문서 토큰 간의 모든 조합을 대조하여 상호작용의 깊이를 더한다.

이러한 구조는 시각적 문서 검색(Visual Document Retrieval) 분야에서 최신 기술(SOTA)로 활용된다. 텍스트 쿼리를 페이지 이미지와 직접 매칭할 때, 별도의 OCR(광학 문자 인식) 단계 없이 이미지의 시각적 특징을 토큰 수준의 벡터로 유지하여 검색할 수 있기 때문이다. 사용자는 텍스트의 각 성분이 개별 벡터로 살아있는 멀티 벡터 모델을 통해 문서의 시각적 구조와 세부 텍스트 정보를 동시에 활용하는 고정밀 검색을 구현할 수 있다.

MaxSim 연산자를 통한 소프트 정렬과 의미적 매칭

멀티 벡터 모델의 점수 계산은 MaxSim(Maximum Similarity) 연산자를 통해 수행된다. MaxSim은 쿼리의 각 토큰에 대해 문서 내의 모든 토큰 중 가장 유사도가 높은 토큰 하나를 찾아 그 최댓값을 선택하고, 쿼리의 모든 토큰에 대해 이 과정을 반복하여 합산하는 방식이다. 수식으로는 $\text{MaxSim}(Q, D) = \sum_{Q_i \in Q} \max_{D_j \in D} Q_i \cdot D_j$로 표현된다.

모든 토큰 임베딩은 L2 정규화를 거치므로, 각 토큰 간의 내적 값은 -1에서 1 사이의 코사인 유사도로 산출된다. 최종 점수는 쿼리 토큰 수의 음수 값부터 양수 값까지의 범위 내에서 결정되며, 이는 쿼리의 각 요소가 문서의 어느 부분에 의해 가장 잘 설명되는지를 나타내는 '소프트 정렬(Soft Alignment)'의 역할을 한다. 여러 개의 쿼리 토큰이 문서 내의 동일한 토큰 하나에 정렬될 수도 있으며, 이를 통해 문서가 쿼리의 요구사항을 얼마나 충실히 뒷받침하는지 수치화한다.

이 방식은 단순한 키워드 매칭을 넘어 문맥화된 의미 검색을 가능하게 한다. `lightonai/mLateOn` 모델로 'Where do penguins live?'라는 쿼리를 'Penguins inhabit Antarctica.'라는 문서와 대조하면, 쿼리의 'live' 토큰은 철자가 완전히 다른 'inhabit' 토큰과 0.94라는 높은 유사도로 매칭된다. 이는 BM25와 같은 어휘 검색(Lexical Retrieval)이 처리하지 못하는 동의어 및 패러프레이징 문제를 해결하는 동시에, 단일 벡터 모델이 놓치기 쉬운 정확한 식별자 매칭 능력까지 유지하는 결과로 이어진다.

인덱스 용량 증가와 fast-plaid 압축 최적화

멀티 벡터 모델의 가장 큰 비용은 인덱스 저장 용량의 급격한 증가다. 문서당 하나의 벡터만 저장하던 방식에서 토큰당 하나의 벡터를 저장하는 방식으로 바뀌면서 벡터의 총 개수가 크게 늘어나기 때문이다. `lightonai/LateOn` 모델을 사용하여 Natural Questions 지문 4,874개를 인코딩한 결과, 지문당 평균 124.8개의 토큰 벡터가 생성되어 총 608,414개의 벡터가 구축되었다.

이 수치는 기존 MiniLM 인덱스 대비 약 42배의 저장 공간이 필요함을 의미하며, 지문 하나당 약 62 KiB의 용량을 소모한다. 이러한 용량 부담을 해결하기 위해 `fast-plaid` 압축 인덱스를 사용할 수 있다. fast-plaid는 벡터의 원본 값을 그대로 저장하지 않고, 대표값인 중심점 ID(Centroid ID)와 실제 값과의 차이인 양자화된 잔차(Quantized Residual)만을 저장하는 방식을 사용한다.

압축 기술을 적용하면 608,414개의 토큰 벡터를 약 92 MB 수준으로 줄일 수 있다. 이는 4096차원의 고차원 밀집 모델인 `Qwen3-Embedding-8B`가 동일한 4,874개 지문을 저장할 때 필요한 약 80 MB와 유사한 수준이다. 결과적으로 엔지니어는 `fast-plaid`와 같은 압축 기법을 통해 멀티 벡터 모델의 정밀도를 챙기면서도, 기존 대형 밀집 임베딩 모델과 유사한 인프라 비용으로 시스템을 운영할 수 있다. 추가적으로 벡터 수를 사전에 줄이는 Token Pooling이나, 1차 후보군 추출 후 2차 정밀 계산을 수행하는 Retrieve and Rerank 전략을 통해 비용을 더 낮출 수 있다.

Sentence Transformers v6.0 구현 및 모델 선택 기준

Sentence Transformers v6.0은 `pip install -U sentence-transformers` 명령어로 설치하며, `transformers v5.x`, `torch 2.2+`, `huggingface-hub v1.x` 이상의 환경을 요구한다. v6.0부터는 기존에 PyLate 라이브러리를 통해 제공되던 지연 상호작용 모델의 학습, 추론, 검색 기능이 라이브러리 내부로 완전히 통합되었다. 사용자는 `model = SentenceTransformer('model_name')`라는 기존과 동일한 인터페이스로 멀티 벡터 모델을 로드할 수 있다.

Hugging Face Hub에서 사용할 모델을 찾을 때는 `multi-vector`와 `sentence-transformers`라는 두 가지 태그가 모두 부여된 모델을 선택해야 한다. 이 태그가 있는 모델은 PyLate 체크포인트, Stanford-NLP ColBERT 체크포인트, 또는 ColPali 계열 모델 등 원래의 학습 프레임워크와 상관없이 v6.0 인터페이스와 호환된다. 다만, ColPali 계열의 시각적 문서 검색 모델을 사용할 때는 이미지 처리 의존성 패키지를 추가로 설치해야 하며, 모델 저장소에 별도의 설정 파일을 추가하는 작업이 선행되어야 한다.

실무자가 단일 벡터 모델 대신 멀티 벡터 모델을 선택해야 하는 판단 기준은 다음과 같다. 첫째, 제품 코드나 함수명처럼 정확한 토큰 매칭이 검색 성패를 가르는 경우다. 둘째, 'A이면서 B이고 C인' 식의 다중 제약 조건이 포함된 복합 쿼리가 빈번한 환경인 경우다. 셋째, 문서 길이가 길어 단일 벡터 압축 시 핵심 정보가 소실되는 현상이 관찰되거나, 학습 데이터와 다른 도메인의 데이터를 처리해야 하는 경우다. 검색 정밀도가 최우선인 위 조건들에 해당한다면, 인덱스 용량 42배 증가(압축 전 기준)를 감수하고 멀티 벡터 모델을 도입하는 것이 타당하다.