01 임베딩

임베딩(Embedding)이란?

• 임베딩은 텍스트를 고차원 벡터(숫자 배열)로 변환하는 기술이다. 이를 통해 컴퓨터가 단어와 문장의 "의미"를 수치적으로 이해할 수 있다.

• 임베딩의 핵심 = 의미가 비슷한 단어/문장은 벡터 공간에서 가깝게 위치 (by transformer)

				Redis 캐싱
				●
			 ●
	Spring Redis Cache


					 MySQL index
						 ●


일본 여행
   ●

EmbeddingModel의 동작 원리

"laptop" → EmbeddingModel → [0.23, -0.45, 0.12, ..., 0.67]  (384차원 벡터)
"gaming" → EmbeddingModel → [0.31, -0.22, 0.45, ..., 0.89]  (384차원 벡터)

1. 토큰화(Tokenization): 입력 텍스트를 토큰(단어/서브워드)으로 분리
   • 나는 개발자입니다 -> ["나는", "개발", "자", "입니다"]
2. 초기 토큰 임베딩(Token Embedding): 각 토큰을 embedding matrix에서 초기 벡터로 변환
   • 아직 문맥이 반영되지 않은 초기 표현
   • Transformer가 처리할 입력 벡터 역할
3. 문맥 반영(Contextual Embedding): Transformer의 Self-Attention을 통해 각 토큰의 문맥적 표현 생성
   • 같은 단어라도 주변 문맥에 따라 서로 다른 벡터가 생성됨
4. Pooling (Sentence Embedding): Transformer 결과로 나온 토큰별 벡터들을 하나의 문장 벡터로 통합
   • Mean Pooling, CLS Pooling, Last Token Pooling 등의 방식 사용
5. Projection / Normalization: 필요에 따라 차원을 변환하고 벡터를 정규화
   • Projection: 벡터가 표현되는 공간 자체를 변환하는 과정
     • 차원을 줄이거나, 검색이나 유사도 계산에 더 적합한 표현용 임베딩 공간으로 다시 매핑하는 역할
     • ex) 4096차원 → 1024차원
   • Normalization: 벡터의 방향은 유지하면서 크기만 일정하게 맞추는 과정
     • 유사도 비교를 안정적으로 수행하기 위함.
     • L2 normalization을 수행하면 벡터 크기가 1이 되어 dot product와 cosine similarity가 동일해짐 -> 벡터 검색 엔진 입장에서도 계산이 단순해짐.
     • ex) 길이 5 → 길이 1
6. 최종 임베딩 출력: 문장의 의미를 표현하는 고정 길이 벡터 출력
   • 예: [0.12, -0.31, 0.84, ...]

임베딩 차원(Dimension) 크기

임베딩 차원 = 한 문장/문서의 의미를 몇 개의 숫자로 표현할 것인가 = 모델이 의미를 표현하기 위해 사용하는 벡터 공간의 크기를 의미

차원 크기에 따른 트레이드 오프

• 저차원일수록:
  • 장점: 빠른 검색, 적은 저장공간
  • 단점: 정보 손실 가능
• 고차원일수록:
  • 장점: 높은 표현력, 정확한 유사도
  • 단점: 느린 검색, 큰 저장공간

차원 크기에 왜 384 / 768 / 1024 같은 숫자가 자주 나올까?

Transformer에서는 attention head 하나가 64차원을 처리하도록 설계하는 경우가 흔해서 hidden size가 6×64=384, 12×64=768, 16×64=1024처럼 잡히는 경우가 많다. 다만 head당 64차원이 규칙은 아니며, 모델에 따라 다른 head dimension을 사용할 수도 있다.

차원의 저주 (Curse of Dimensionality)

• 개념: 차원이 높아질수록 데이터 분석과 검색이 기하급수적으로 어려워지는 현상
• 발생 원인
  1. 거리의 의미 상실: 고차원 공간에서는 모든 점들 사이의 거리가 비슷해짐
  2. 데이터 희소성 (Data Sparsity): 차원이 증가하면 공간을 채우기 위해 필요한 데이터 양이 증가하여 같은 양의 데이터로는 공간을 채우기 어려워짐
  3. 계산 복잡도 증가: KNN 검색 시간 복잡도가 브루트포스 방식에서는 선형 증가하고, 인덱스를 사용하더라도 고차원에서 인덱스 효율이 급감
• 차원의 저주 완화 전략
  • 적절한 차원 선택: 빠른 검색용인지, 정확도가 중요한지 등을 고려
  • 차원 축소: PCA(주성분 분석), OpenAI의 Matryoshka 임베딩 방식 고려

결론: 무조건 높은 차원이 좋은 것이 아니다. 데이터 규모, 검색 속도 요구사항, 정확도 필요 수준을 고려하여 적절한 차원을 선택해야 한다. (일반적으로 384~1536 차원 사용)

관련 노트

• 01 Elasticsearch 벡터 검색
• 02 Elasticsearch 하이브리드 검색

---