문서를 뭉개지 않는 '멀티벡터' 검색

Hugging Face의 임베딩 라이브러리 Sentence Transformers가 '멀티벡터(늦은 상호작용, late interaction)' 임베딩 모델을 정식 지원하기 시작했습니다. 기존 방식은 문서 전체를 하나의 벡터로 압축하지만, 멀티벡터는 토큰마다 벡터를 그대로 유지하고 질의와 문서의 상호작용을 검색 시점까지 미룹니다 — 이때 각 질의 토큰과 문서 토큰들 사이의 최대 유사도를 취해 더하는 MaxSim 연산을 씁니다.

"멀티벡터 모델은 토큰마다 벡터 하나를 유지하고, MaxSim 연산으로 질의와 문서의 점수를 매긴다."Hugging Face

왜 중요한가

단일 벡터가 평균으로 뭉개버리는 토큰 단위 매칭 정보를 멀티벡터는 보존합니다 — 그래서 여러 조건이 섞인 질의나 정확한 일치가 필요한 상황에서 더 강합니다. NanoBEIR 벤치마크에서 LateOn이 NDCG@10 0.6868로 단일 벡터 DenseOn(0.6764)을 앞섰고, 장문서 검색(MLDR) 다국어 설정에서는 77.92 대 51.59로 격차가 컸습니다. OCR 없이 페이지 이미지를 텍스트 질의로 찾는 시각 문서 검색에서는 사실상 최고 수준입니다.

실무 적용

다만 비용은 분명한 트레이드오프입니다 — 4,874개 패시지를 인코딩하면 60만 개가 넘는 토큰 벡터, 311.5MB가 필요해 MiniLM 대비 42배 조밀합니다. 그래서 토큰 풀링(2배 압축)으로 기준 성능의 100.6%를 유지하는 압축 기법이 함께 제시됐습니다. RAG·시맨틱 검색을 다루는 팀이라면 정밀도가 결정적인 구간에만 멀티벡터를 얹고, 압축으로 인덱스 비용을 관리하는 하이브리드 설계가 현실적입니다.

교차 참고

• Hugging Face: State of Open Models — Summer 2026 — 오픈 모델·데이터셋이 빠르게 불어나는 생태계 흐름을 수치로 보여줍니다.
• Hugging Face: Training and Finetuning Multimodal Embedding & Reranker Models — 임베딩·리랭커를 직접 학습·파인튜닝하는 실전 가이드입니다.

Wemeet의 관점

Wemeet은 검색 품질의 승부가 모델 크기가 아니라 '정보를 언제 뭉개느냐'에서 갈린다고 봅니다. 상호작용을 늦출수록 검색은 정밀해지지만 인덱스는 무거워집니다 — RAG의 진짜 설계는 이 저울질을 어디에 둘지 정하는 일이며, 정밀도와 비용의 균형점을 아는 팀이 유리합니다.