“하나의 큰 임베딩에서, 앞부분만 잘라 써도 꽤 잘 동작하게 만들 수 있을까?”

TL;DR

• Matryoshka Representation Learning(MRL)은 하나의 고차원 임베딩을 학습할 때, 그 앞쪽 일부 차원만 사용해도 낮은 차원 임베딩처럼 꽤 잘 작동하도록 만드는 학습 방식이다.
• 즉, 별도의 64차원 모델, 128차원 모델, 256차원 모델을 각각 따로 학습하지 않고도, 하나의 모델로 여러 차원 크기에 대응하는 표현을 만들 수 있다는 아이디어다. (arXiv)
• 그래서 서비스 환경에 따라 작은 임베딩으로 빠르게 검색하고, 필요할 때 큰 임베딩으로 정밀하게 재검색하는 식의 유연한 운영이 가능하다.

Motivation

임베딩 모델은 보통 고정된 차원의 벡터를 만든다. 예를 들어 768차원, 1024차원, 2048차원처럼 말이다. 일반적으로 차원이 커질수록 표현력은 좋아질 수 있지만, 그만큼 다음과 같은 비용이 커진다.

• 벡터 DB 저장 공간 증가
• 검색 시 유사도 계산 비용 증가
• 대규모 retrieval에서 latency 증가
• 상황에 따라 “이 정도까지 큰 벡터가 꼭 필요한가?”라는 비효율 발생

MRL 논문은 바로 이 지점을 문제로 본다. 실제 서비스에서는 downstream task별 계산 자원 제약이 다르기 때문에, 항상 같은 큰 차원의 표현만 쓰는 것은 과하거나 부족할 수 있다고 설명한다. (arXiv)

Key Idea : 러시아 인형처럼 “중첩된 표현”

“Matryoshka”는 러시아 전통 인형처럼 큰 인형 안에 작은 인형이 들어 있는 구조를 뜻한다. MRL에서도 비슷하게 생각하면 된다. 예를 들어 최종 임베딩이 768차원이라고 하자.

• 앞 64차원만 써도 어느 정도 유용해야 하고
• 앞 128차원은 64차원보다 더 많은 정보를 담고
• 앞 256차원은 그보다 더 정교하고
• 전체 768차원은 가장 풍부한 표현이 되도록

이렇게 앞쪽 prefix 차원들이 각각 독립적으로도 쓸 만한 표현이 되도록 학습한다. 논문은 이를 coarse-to-fine representation으로 설명한다.

Methodology

MRL의 핵심은, 전체 임베딩 하나만 잘 학습시키는 것이 아니라 여러 개의 prefix 차원에 대해 동시에 loss를 걸어주는 것이다. 예를 들어 최종 임베딩 차원이 1024이면, 다음과 같은 차원 집합을 정할 수 있다.

• 64
• 128
• 256
• 512
• 1024

그리고 각 prefix 표현 z[:m]이 각각 좋은 representation이 되도록 loss를 합산해 학습한다. 논문은 모든 차원을 다 최적화하는 것이 아니라, 보통 이런 식으로 일관된 halving 구조의 일부 차원들만 선택하며, 최적화하는 중첩 차원 수는 대체로 O(log d) 수준이라고 설명한다.

직관적으로 보면

일반 임베딩 학습:

• “최종 768차원 벡터 전체가 좋으면 된다.”

MRL 학습:

• “768차원 전체도 좋아야 하고,
• 앞 512차원도 좋아야 하고,
• 앞 256차원도 좋아야 하고,
• 앞 128차원도 좋아야 한다.”

그래서 모델은 자연스럽게 중요한 정보를 앞 차원 쪽에 우선적으로 배치하도록 압력을 받는다. Hugging Face의 설명도 같은 맥락에서, 중요한 정보가 임베딩 앞부분에 오도록 학습이 유도된다고 정리한다. (Hugging Face)

오해하기 쉬운 부분

1. MRL은 “새 모델 구조”가 아니다 MRL은 Transformer, BERT, ViT 같은 특정 아키텍처 이름이 아니다. 핵심은 representation learning pipeline 위에 얹는 학습 전략이다. 논문도 MRL이 기존 표현 학습 파이프라인에 minimal modification으로 적용될 수 있다고 말한다. (arXiv)
2. “작게 잘라도 무조건 성능 손실이 없다”는 뜻은 아니다 MRL은 작은 차원에서도 독립적으로 학습한 저차원 표현에 가깝게 잘 동작하도록 만드는 방법이지, 아무 손실 없이 완전 동일하다는 뜻은 아니다. 차원을 많이 줄일수록 보통 정보는 줄어든다. 다만 그 감소를 훨씬 덜 아프게 만든다는 것이 포인트다. (arXiv)

3. 인코더 추론 자체가 항상 더 빨라지는 것은 아니다 실무에서 자주 헷갈리는 포인트다. MRL의 장점은 주로 downstream에서 나온다.

   • 저장 공간 감소
   • 벡터 검색 연산량 감소
   • shortlist → rerank 구조 최적화

   Hugging Face 설명도, 작은 임베딩으로 downstream task는 빨라지지만, 모델이 임베딩을 생성하는 과정 자체는 일반적으로 동일하다고 설명한다. 즉, “truncate 후 retrieval가 빨라진다”와 “encoder forward가 더 빨라진다”는 같은 말이 아니다. (Hugging Face)

Main Contributions

원 논문의 주요 기여점은 다음과 같다.

1. 하나의 임베딩으로 여러 차원 수준을 커버할 수 있다. (arXiv)
2. 낮은 차원의 Matryoshka 표현이 독립적으로 학습한 저차원 표현만큼 정확하거나 비슷한 수준을 낼 수 있다.
3. ImageNet-1K classification, retrieval, few-shot/long-tail setting 등에서 좋은 결과를 보였다. 논문 abstract는 동일 정확도에서 최대 14배 작은 embedding size, 대규모 retrieval에서 최대 14배 real-world speed-up, long-tail few-shot classification에서 최대 2% 개선을 보고한다. (arXiv)
4. 비전(ResNet, ViT), 비전+언어(ALIGN), 언어(BERT)까지 확장 가능성을 보였다. (arXiv)

무엇이 좋은가

1. 실무 친화적이다 서비스 환경에서는 항상 “최고 성능”만 중요한 게 아니다. 자주 나오는 고민은 다음과 같다.

   • 모바일/실시간 환경이라 latency가 중요함
   • 벡터 DB 비용이 부담됨
   • 후보군 shortlisting은 빠르게, reranking은 정교하게 하고 싶음

   MRL은 이런 환경에서 아주 자연스럽다. 처음에는 작은 차원으로 빠르게 후보를 추리고, 필요할 때만 큰 차원으로 정밀 계산하는 식의 adaptive retrieval이 가능하다. 논문 Figure 1도 adaptive retrieval, shortlisting, reranking, adaptive classification을 대표 응용으로 제시한다. 2. “여러 모델 따로 학습” 문제를 줄인다 보통 64차원용 모델, 128차원용 모델, 256차원용 모델을 각각 만들면 학습/배포/운영 비용이 커진다. MRL은 이걸 하나의 표현 공간 안에 중첩시켜 해결하려는 접근이라 운영상 매력이 크다. 3. 아이디어가 단순하고 확장성이 좋다 복잡한 새로운 모듈을 크게 추가하는 방식이 아니라, 여러 prefix 차원에 대해 같은 목적 함수를 걸어준다는 발상이어서 개념적으로 단순하다. 실제로 Sentence Transformers에서도 base loss를 MatryoshkaLoss로 감싸는 식으로 실용화돼 있다. (Hugging Face)

Limitation

1. 모든 상황에서 무조건 최고는 아니다 원 논문은 매우 인상적인 결과를 보였지만, 후속 연구들은 MRL에도 실무적 한계가 있다고 지적한다. 2025년 EMNLP 논문은 특히 새로운 저차원 타깃이 필요할 때 원래 MRL은 retraining from scratch가 필요할 수 있다고 비판하며, 이를 보완하는 SMRL 같은 후속 방법을 제안한다. 즉, MRL이 매우 유용한 틀인 것은 맞지만, 차원 축소 문제의 최종 해답으로 끝난 것은 아니다.
2. “앞 차원 = 더 중요한 의미”를 너무 문자적으로 이해하면 안 된다 실무 설명에서는 종종 “앞부분 차원이 더 중요한 의미를 담는다”고 쉽게 말하지만, 이것은 직관적 설명에 가깝다. 정확히는 “앞부분 prefix만 사용해도 downstream loss가 잘 나오도록 학습된다”가 더 엄밀하다. 즉, 각 차원 하나하나가 사람에게 해석 가능한 의미 순서로 정렬된다는 보장은 없다. 이는 설명할 때 조심해야 한다. 논문도 핵심을 “nested prefixes가 transferable representation이 되게 한다”로 설명한다.
3. truncate 후 정규화 이슈가 있다 실무에서 cosine similarity 기반 retrieval을 할 때는 특히 중요하다. Hugging Face 문서는 정규화된 임베딩을 truncate하면 다시 정규화가 필요할 수 있다고 안내한다. 이것은 구현에서 자주 놓치는 포인트다. (Hugging Face)

실무에서 어디에 특히 잘 맞나?

1. 벡터 검색 대규모 corpus에서 처음에는 작은 차원으로 빠르게 후보를 찾고, 상위 후보만 큰 차원으로 다시 비교하는 구조에 잘 맞는다. 원 논문도 adaptive retrieval과 shortlisting/reranking을 중요한 활용처로 제시한다.
2. 저장 비용이 민감한 시스템 벡터 DB에 1024차원 대신 128차원 혹은 256차원 수준으로 저장하면 저장 공간과 검색 비용을 줄일 수 있다. 다만 이 경우 성능과 비용 사이 trade-off를 검증해야 한다. (Hugging Face)

3. 하나의 모델을 여러 서비스 레벨에 공통 사용하고 싶을 때 예를 들어:

   • 고속 API는 128차원
   • 기본 API는 256차원
   • 고정밀 분석은 768차원

   이런 식으로 same encoder, different deployment budget 전략을 만들기 좋다. (arXiv)

Sentence Transformers

NLP 실무에서는 MRL이 보통 기존 embedding loss 위에 wrapper처럼 붙는 방식으로 이해하면 편하다. 예를 들어:

• base loss: MultipleNegativesRankingLoss 또는 CoSENTLoss
• wrapper: MatryoshkaLoss
• target dims: [768, 512, 256, 128, 64]

즉, “원래 잘 쓰던 loss”를 버리는 게 아니라, 여러 prefix 차원에서도 그 loss가 잘 나오게 합산해서 학습하는 방식이다. Hugging Face 글도 이 구조를 예시 코드로 설명한다. (Hugging Face)

참고문헌

1. Kusupati et al., Matryoshka Representation Learning, NeurIPS 2022. (NeurIPS Proceedings)
2. Hugging Face Blog, Introduction to Matryoshka Embedding Models. (Hugging Face)
3. RAIVNLab GitHub, MRL official code repository. (GitHub)
4. Zhang et al., SMEC: Rethinking Matryoshka Representation Learning for Embedding Compression, EMNLP 2025. (ACL Anthology)