문서를 벡터 하나로 뭉개지 않는 검색: 센텐스 트랜스포머 v6.0이 들인 멀티벡터 모델 정리

센텐스 트랜스포머(Sentence Transformers)는 2026년 8월 18일 공개된 v6.0에서 콜버트(ColBERT) 계열의 지연 상호작용 검색을 다루는 네 번째 모델 유형 MultiVectorEncoder를 추가했다. 문서 전체를 벡터 한 개로 압축하는 기존 밀집 임베딩과 달리 멀티벡터 모델은 토큰마다 벡터를 하나씩 남기고 맥스심(MaxSim) 연산으로 질의와 문서를 채점하며, 같은 모던버트 백본과 같은 학습 데이터로 훈련된 149M 파라미터 모델끼리 비교한 나노BEIR 13종 평균에서 멀티벡터 LateOn이 0.6868, 밀집 DenseOn이 0.6764를 기록했다. 대가는 인덱스 크기이고, 자연어질의(Natural Questions) 지문 4,874개를 인코딩하면 토큰 벡터 608,414개가 나와 float32 기준 311.5MB로 MiniLM 인덱스의 약 42배가 된다. ASAP은 이 발표에서 실제로 검증된 수치를 정리한 뒤, 검색 품질 1포인트를 위해 저장 비용을 몇 배까지 감당할 가치가 있는지 판단 기준을 함께 짚는다.

지연 상호작용은 교차 인코더와 이중 인코더 사이에 자리를 잡는다

세 가지 검색 구조의 차이는 상호작용을 언제 계산하느냐에 있다. 교차 인코더는 질의와 문서를 함께 모델에 넣어 정확도가 높지만 미리 계산해 둘 것이 없어서 질의가 바뀔 때마다 모든 문서를 다시 인코딩해야 한다. 밀집 임베딩 모델이 속하는 이중 인코더는 완성된 요약 벡터 두 개의 내적 한 번으로 끝나므로 말뭉치를 한 번만 인코딩해 두면 되지만 상호작용이 사실상 없다. 지연 상호작용은 그 사이에 있다. 문서는 여전히 독립적으로 인코딩해 오프라인 색인이 가능하되, 채점 시점에는 질의의 모든 토큰을 문서의 모든 토큰과 대조한다.

맥스심 연산이 이 대조를 정의한다. 질의 토큰마다 문서 토큰 중 가장 유사한 것 하나를 골라 그 값을 취하고, 이를 질의 전체에 걸쳐 더한다. 토큰 임베딩이 L2 정규화되어 있으므로 개별 내적은 -1과 1 사이의 코사인 유사도이고, 합계는 질의 토큰 수의 음수부터 양수까지의 범위에 놓인다.

대조가 어휘 일치에 묶이지 않는다는 점이 중요하다. 토큰 임베딩이 문맥화되어 있기 때문에, 발표문의 예시에서 mLateOn으로 "Where do penguins live?"를 "Penguins inhabit Antarctica."와 대조하면 질의 토큰 live가 글자를 하나도 공유하지 않는 inhabit에서 0.94의 최고 유사도를 찾는다. 동시에 제품 코드나 사람 이름처럼 정확한 일치가 중요한 경우에는 해당 토큰이 자기 벡터를 그대로 들고 있으므로, 단일 벡터 모델이 다른 정보와 평균 내야 했던 신호가 살아남는다.

압축이 손해를 보는 지점은 질의가 여러 조건을 동시에 요구할 때다

발표문이 든 사례는 가구 검색이다. "green sofa with wooden legs and rounded cushions"처럼 조건이 네 개인 질의를 단일 벡터로 처리하면 네 조건을 한 점에 섞어야 하므로, 다리 모양이 다른 초록 소파가 실제로 찾던 소파 옆에 나란히 앉는다. 멀티벡터에서는 조건마다 자기 근거를 따로 찾는다.

압축 손실이 학습 질의의 성격에 좌우된다는 지적도 함께 나왔다. 단일 벡터가 무엇을 남기고 무엇을 버릴지는 학습 질의에서 배우므로, 운영 환경의 질의가 학습 분포와 다르면 정확히 필요한 정보가 버려져 있을 수 있다. 도메인 밖 데이터에서 멀티벡터의 이점이 커지는 이유가 여기에 있고, 문서가 길어질수록 같은 크기 벡터에 더 많은 내용을 밀어 넣어야 하므로 효과가 커진다.

장문에서 벌어지는 격차는 수치로도 제시됐다. 장문 검색 벤치마크 MLDR에서 다국어 형제 모델을 비교하면 mLateOn이 77.92, mDenseOn이 51.59였다.

같은 조건에서 겨룬 나노BEIR 비교가 이 발표의 핵심 근거다

벤치마크 설계가 이 발표에서 가장 신뢰할 만한 부분이다. lightonai/LateOn과 lightonai/DenseOn은 라이톤(LightOn)이 같은 데이터로, 같은 모던버트 백본에, 같은 149M 파라미터로 훈련한 모델이며, 토큰마다 벡터를 남기느냐 문서 하나로 풀링하느냐만 다르다. 두 모델을 나노BEIR 13종에 모두 돌리면 그 선택 하나가 무엇을 사는지가 분리된다.

결과는 평균 0.6868 대 0.6764로 멀티벡터가 앞섰고, 13개 데이터셋 중 9개에서 이겼다. 개별 격차가 가장 큰 곳은 MSMARCO로 0.7194 대 0.6517이었고, HotpotQA는 0.9295 대 0.8802였다. 진 네 곳은 ArguAna(0.5562 대 0.5660), FiQA2018(0.5871 대 0.6491), SCIDOCS(0.4469 대 0.4484), SciFact(0.7978 대 0.8057)다. 같은 조합을 전체 BEIR 15종으로 돌리면 57.22 대 56.20으로 격차의 크기가 비슷하게 유지되므로, 평균 차이가 소규모 벤치마크의 우연이 아니라는 확인이 된다.

인덱스 비용은 42배에서 시작하지만 그 자리에 머물지 않는다

비용을 정직하게 보려면 세 단계를 구분해야 한다. 첫 단계는 압축하지 않은 원값이다. 자연어질의 지문 4,874개를 LateOn으로 인코딩하면 토큰 벡터 608,414개가 나오고, 지문당 평균 124.8개다. float32 기준으로 128차원 벡터 608,414개는 311.5MB이며, 같은 지문을 384차원 벡터 4,874개로 담는 all-MiniLM-L6-v2가 7.5MB, 768차원의 gte-modernbert-base가 15.0MB다. 지문 한 개당 62KiB, MiniLM 대비 약 42배다.

두 번째 단계는 인덱스 압축이다. 같은 608,414개 벡터를 fast-plaid 인덱스로 담으면 92MB가 된다. PLAID가 벡터 자체 대신 중심점 식별자와 양자화된 잔차를 저장하기 때문이다. 발표문은 비교 기준을 하나 더 제시했는데, Qwen3-Embedding-8B 같은 4096차원 밀집 모델은 같은 지문 4,874개에 약 80MB가 필요하다는 것이다. 압축된 멀티벡터 인덱스가 이미 운영되고 있는 대형 밀집 인덱스와 같은 영역에 있다는 뜻이다.

세 번째 단계는 토큰 풀링이다. HierarchicalTokenPooling은 문서마다 토큰 벡터를 코사인 거리 기준 워드 연결로 군집화한 뒤 각 군집을 평균으로 대체해서 토큰의 약 1/pool_factor만 남긴다. 계수 2에서 305,438개(1.99배 감소, 156.4MB), 3에서 204,407개(2.98배, 104.7MB), 4에서 153,936개(3.95배, 78.8MB)가 됐고, 608k 벡터 전체를 풀링하는 데 약 6초가 걸렸다. 품질 손실은 원 실험에서 BEIR 기준 계수 2에서 평균 100.6%, 계수 3에서 99.0%로 보고됐다. 라이톤의 계층적 풀링 정규화로 훈련한 체크포인트는 5배 압축에서 99.4% 유지를 보고했다.

인덱스를 아예 만들지 않는 선택지도 있다. 빠른 이중 인코더로 상위 50건을 좁힌 뒤 그 후보만 멀티벡터로 재채점하는 구성이다. 이때 토큰 벡터는 일시적으로만 존재하고 인덱스는 평범한 밀집 인덱스로 남는다. 교차 인코더가 맡던 자리와 같지만 후보당 비용은 훨씬 낮은데, 질의와 문서 쌍마다 순전파를 한 번씩 돌리는 대신 문서를 한 배치로 인코딩하고 행렬 곱으로 채점하기 때문이다.

실제 속도와 검색 구성

말뭉치가 작으면 인덱스 없이 전수 계산이 가장 단순하다. 발표문의 예시에서 지문 4,874개를 RTX 3090으로 인코딩하는 데 20초가 걸렸고, 질의 하나를 608,414개 토큰 벡터 전체와 대조하는 검색은 종단간 122.7ms였다. 다만 이 방식은 말뭉치 총 토큰 수에 선형으로 비례하고 모든 토큰 벡터를 메모리에 올려 두므로, 문서 수천 건 규모에서 선택할 방식이지 수백만 건에서 쓸 방식은 아니다.

그 이상에서는 지연 상호작용 인덱스가 필요하고, 센텐스 트랜스포머는 이를 직접 제공하지 않는다. 네이티브로 색인과 채점을 지원하는 곳은 Qdrant v1.10 이후, Weaviate v1.29 이후, Vespa, LanceDB v0.15.0 이후, 그리고 포스트그레스에 맥스심 연산자를 더한 VectorChord다. Milvus는 v2.6.4에서 합류했다. 서버를 띄우고 싶지 않으면 라이톤의 fast-plaid가 PLAID를 직접 구현한다. 일부만 지원하는 곳도 있다. OpenSearch와 Elasticsearch는 맥스심으로 후보를 재채점할 수는 있으나 그것으로 검색하지는 못하며, Elasticsearch 쪽은 기술 프리뷰이자 엔터프라이즈 등급이다. turbopuffer는 비공개 베타 단계다.

추론 속도에서는 GPU 기준으로 fp16과 플래시 어텐션 조합이 가장 좋았고, fp32 대비 처리량 2.44배에 측정 가능한 검색 품질 손실이 없었다. 멀티벡터 모델이 플래시 어텐션의 이득을 특히 크게 보는 이유가 설명됐는데, 문서는 잘리기만 하고 공통 길이로 패딩되지 않으므로 배치 안에서 시퀀스 길이가 크게 달라지고 언패딩이 그 편차를 활용하기 때문이다. 다만 질의 확장을 어텐션 없이 처리하는 체크포인트, 즉 colbert-ir/colbertv2.0이나 answerdotai/answerai-colbert-small-v1 같은 스탠퍼드 계열은 로드 시점에 플래시 어텐션을 거부하므로 sdpa를 써야 한다. CPU에서는 OpenVINO가 낫고 int8 양자화가 약 0.4% 정확도 손실로 추가 가속을 준다.

OCR 없이 페이지 이미지를 검색하는 쪽이 더 큰 변화일 수 있다

지연 상호작용이 현재 최고 수준을 차지한 영역은 텍스트가 아니라 시각 문서 검색이다. 차트와 표와 레이아웃이 그대로 살아 있는 페이지 이미지를 텍스트 질의와 직접 대조하며, 중간에 OCR 단계가 없다. 콜팔리(ColPali) 계열 체크포인트가 이 일을 하고, v6.0에서는 같은 encode_query와 encode_document 호출로 페이지 이미지를 넘긴다.

페이지 한 장이 여러 영역으로 이루어져 있다는 점이 지연 상호작용과 잘 맞는 이유다. 단일 벡터라면 차트 하나와 표 하나와 문단 셋을 한 요약으로 평균 내야 한다. 대신 벡터 수가 늘어난다. vidore/colqwen2.5-v0.2에서 질의는 25개 토큰 벡터, 페이지 한 장은 755개였고, 앞서 나온 자연어질의 지문의 평균 약 125개와 비교된다. 토큰 풀링을 텍스트보다 이른 단계에서 꺼내야 하는 이유가 이 격차다.

모달리티는 더 넓다. vidore/colqwen-omni-v0.1은 텍스트, 이미지, 오디오, 비디오를 모두 받는다. 발표문의 오디오 예시에서 평균 28초짜리 대화 녹음 20건을 대상으로 "medicine for car nausea"를 질의했더니 질의의 nausea와 녹음의 carsickness가 다른 단어인데도 약국 대화를 큰 차이로 골라냈다. 이 모델은 이미지와 텍스트 쌍으로만 학습됐으므로 오디오 검색은 제로샷이고, 파이프라인 어디에도 전사 단계가 없다.

비디오는 프레임을 솎아야 한다. 1fps 전체 해상도에서 예시 영상 두 편은 토큰 벡터 8,426개와 5,137개를 만들고 VRAM 최대 20.8GB를 썼는데, 0.5fps 저해상도로 낮추면 4,240개와 2,446개에 12.5GB였다. 모델 자체가 9.0GB를 차지하며, 순위는 두 설정에서 동일했다.

이 통합이 지금 나온 맥락

라이브러리 통합이라는 형태를 과소평가하기 쉽다. 지금까지 지연 상호작용을 쓰려면 별도 스택을 골라야 했다. 센텐스 트랜스포머가 밀집과 희소는 다뤘지만 지연 상호작용은 다루지 않아서 라이톤이 그 위에 PyLate를 만들어 학습과 추론과 검색을 채웠고, 시각 문서 쪽은 colpali-engine이 자체 형식을 썼다. v6.0은 이 셋을 한 API 아래로 모으고, PyLate 체크포인트와 스탠퍼드 NLP 콜버트 체크포인트를 그대로 로드한다.

기술적 신규성보다 채택 장벽 쪽 사건이라고 보는 편이 정확하다. 콜버트 자체는 새 방법이 아니고 맥스심도 새 연산이 아니다. 바뀐 것은 이미 밀집 임베딩을 센텐스 트랜스포머로 돌리고 있는 팀이 모델 클래스 이름만 바꿔서 같은 파이프라인에 지연 상호작용을 넣어 볼 수 있게 됐다는 점이다. 검색 품질 개선을 검토할 때 드는 비용이 스택 교체에서 한 줄 교체로 내려가면, 실험해 볼 팀의 수가 달라진다.

동시에 지금이 그런 실험의 수요가 큰 시점이다. 검색 증강 생성에서 최종 답변 품질을 좌우하는 것은 생성 모델보다 검색 단계인 경우가 많고, 특히 사내 문서처럼 학습 분포 밖에 있는 말뭉치에서 밀집 임베딩의 압축 손실이 드러난다. 도메인 밖 데이터와 다조건 질의가 멀티벡터가 이기는 두 조건으로 지목됐다는 사실이, 이 방식이 겨냥하는 실무 상황을 그대로 설명한다.

1포인트를 위해 몇 배를 낼 것인가

숫자를 판단으로 옮기려면 비교 대상을 정확히 잡아야 한다. 나노BEIR 평균 격차 0.6868 대 0.6764는 약 1 NDCG 포인트이고, 원값 저장 기준 비용은 42배다. 두 숫자를 그대로 나란히 놓으면 수지가 맞지 않아 보인다. 그러나 42배는 압축 전 수치이고, fast-plaid 인덱스 92MB와 토큰 풀링 계수 2의 156.4MB를 거치면 실제 운영 부담은 4096차원 밀집 모델과 비슷한 영역으로 내려온다. 비교해야 할 대상은 MiniLM의 7.5MB가 아니라 현재 운영 중인 인덱스의 실제 크기다.

이긴 9개와 진 4개의 성격도 함께 봐야 한다. 격차가 가장 컸던 MSMARCO와 HotpotQA는 질의에 답하는 특정 대목이 문서 어딘가에 박혀 있는 유형이고, 진 네 곳 중 ArguAna와 SciFact와 SCIDOCS는 격차가 0.01 안쪽으로 작다. 반면 FiQA2018은 0.5871 대 0.6491로 밀집 쪽이 뚜렷하게 앞섰다. 자기 데이터에서 재는 일이 대체 불가능하다는 뜻이며, 발표문이 나노BEIR 평가기를 별도 준비 없이 돌릴 수 있게 만든 이유이기도 하다.

한국어 환경에서는 판단 근거가 하나 더 붙는다. 사내 검색 질의에는 제품 코드, 사번, 부서명, 사람 이름처럼 정확히 일치해야 하는 토큰이 자주 섞이고, 단일 벡터는 이런 토큰을 나머지 문맥과 평균 내야 한다. 토큰이 자기 벡터를 유지한다는 성질이 이 상황에 직접 대응한다. 다국어 체크포인트가 함께 제공되고 mLateOn이 MLDR 장문 검색에서 밀집 형제 대비 77.92 대 51.59의 격차를 보인 점도 긴 한국어 문서를 다루는 쪽에서 확인해 볼 값이다. 다만 이 수치들은 모두 영어 또는 다국어 벤치마크에서 나온 것이므로 한국어 말뭉치에서의 격차는 직접 측정해야 한다.

먼저 확인해야 할 함정과 남는 제약

가장 먼저 점검할 값은 문서 길이 상한이다. document_length는 자르는 설정이므로 상한을 넘어간 부분은 인덱스에 아예 도달하지 않는다. LateOn의 상한 300에 662토큰 지문을 넣으면 벡터 273개가 돌아오고 나머지는 사라진다. ColBERTv2는 질의를 정확히 32토큰으로 패딩하고 문서를 180에서 자르며, GTE-ModernColBERT-v1은 48과 300을 쓴다. 체크포인트마다 다르므로 print(model)로 실제 설정을 확인하고 자기 청크 길이와 대조해야 한다. 상한을 한 번의 호출에서 올릴 수는 있으나, 학습된 길이를 넘겨 모델을 돌리는 것이고 인덱스도 그에 비례해 커진다.

두 번째는 질의와 문서를 바꿔 쓸 수 없다는 점이다. 멀티벡터 모델은 비대칭이어서 질의와 문서가 서로 다른 접두 표지와 다른 길이 상한과 다른 채점 마스크를 통과하며, 밀집 모델에서 흔한 관행과 달리 encode_query와 encode_document를 반드시 구분해 호출해야 올바른 임베딩이 나온다.

세 번째는 점수의 해석이다. 맥스심은 질의 토큰에 걸쳐 합을 내므로 점수 크기가 질의 토큰 수에 비례하고, 질의 처리 방식이 다른 모델끼리는 점수를 비교할 수 없다. 같은 질의와 문서를 LateOn과 ColBERTv2로 채점하면 값의 범위 자체가 달라진다. 한 모델 안에서는 순위만 보면 되지만, 경계가 있는 척도가 필요하면 질의 토큰 수로 나누는 MeanMaxSim으로 유사도 함수를 바꿔 -1과 1 사이 값으로 받을 수 있다. 점수들이 서로 가깝게 붙는 현상도 알아 둘 필요가 있다. 맥스심이 질의 토큰마다 최댓값을 취하는 데다 문맥화된 토큰 임베딩이 좁은 원뿔에 몰리는 이방성을 가지므로, 무관한 토큰 쌍도 높은 값을 내고 점수에 바닥이 생긴다.

마지막으로 환경 요건이 있다. 센텐스 트랜스포머 v6.0은 transformers v5.x와 torch 2.2 이상, huggingface-hub v1.x를 요구하므로 이보다 낮게 고정해 둔 프로젝트는 업그레이드 계획이 먼저다. 시각 문서 모델은 콜팔리 자체 형식으로 배포되어 있어 저장소마다 별도 설정 추가가 필요하고, 발표 시점 기준으로 상당수가 병합 대기 상태다. 그리고 이들은 VLM이므로 메모리 계획이 필요하다. 지원 모델 표의 파라미터 범위가 252M에서 8.8B에 걸쳐 있고, CPU에서 실용적인 것은 작은 쪽뿐이다.

출처: 톰 아르선, 앙투안 샤팽, 라파엘 수르티가 작성한 허깅페이스 블로그 Multi-Vector (Late Interaction) Embedding Models with Sentence Transformers(2026년 8월 18일) 기반 ASAP 정리