임베딩: 텍스트를 숫자로 바꾸는 기술

임베딩이란?

임베딩(Embedding) = 텍스트를 숫자 벡터로 변환하는 기술

"CNC 서보 에러" → [0.23, -0.45, 0.67, ..., 0.12]  (1536차원)

왜 숫자로 바꾸나?
→ 컴퓨터는 텍스트의 "의미"를 이해 못한다.
→ 숫자 벡터로 바꾸면 의미의 유사도를 계산할 수 있다.

핵심 원리: 의미가 비슷하면 벡터도 비슷하다

"CNC 서보 에러"     → [0.23, -0.45, 0.67, ...]
"CNC 서보 알람"     → [0.24, -0.44, 0.66, ...]  ← 매우 유사!
"유압 프레스 사양"  → [0.78, 0.12, -0.34, ...]   ← 완전 다름

코사인 유사도:
  "서보 에러" vs "서보 알람"    = 0.97 (매우 유사)
  "서보 에러" vs "유압 사양"    = 0.23 (관련 없음)
  "서보 에러" vs "서보 모터"    = 0.82 (관련 있음)

임베딩 모델 비교: 2024-2025 기준

API 기반 (클라우드)

모델	차원	최대 토큰	가격	한글 성능
OpenAI text-embedding-3-small	1536	8191	$0.02/1M	양호
OpenAI text-embedding-3-large	3072	8191	$0.13/1M	우수
Voyage-3	1024	32000	$0.06/1M	우수
Cohere embed-v3	1024	512	$0.10/1M	양호

오픈소스 (로컬)

모델	차원	최대 토큰	크기	한글 성능
BGE-M3	1024	8192	2.3GB	최우수
multilingual-e5-large	1024	512	2.2GB	우수
gte-multilingual	768	8192	1.5GB	우수
KoSimCSE	768	512	500MB	한국어 특화

제조 한글 문서에 뭘 써야 하나?

결론부터:

[프로토타입 / 빠른 구현]
→ OpenAI text-embedding-3-small
  이유: API 한 줄이면 동작, 한글 성능 충분

[프로덕션 / 비용 절감]
→ BGE-M3
  이유: 무료, 한국어 최강, 로컬 실행

[보안 제약 (공장 내 데이터 반출 불가)]
→ BGE-M3 또는 KoSimCSE
  이유: 완전 로컬 실행, API 호출 없음

임베딩 차원(Dimension)의 의미

차원이 높을수록:
├── 더 정밀한 의미 표현 가능
├── 저장 공간 더 많이 필요
├── 검색 속도 약간 느림
└── 반드시 더 좋은 것은 아님!

실제 비교 (MTEB 벤치마크):
  text-embedding-3-small (1536차원): 62.3점
  text-embedding-3-large (3072차원): 64.6점
  BGE-M3 (1024차원):                 65.1점

→ 차원 수보다 모델 학습 품질이 더 중요!

코사인 유사도 직관적 이해

코사인 유사도 = 두 벡터가 같은 방향을 향하는 정도

1.0:  완전히 같은 방향 (동일한 의미)
0.8~0.9: 매우 유사한 의미
0.5~0.7: 관련 있는 의미
0.2~0.4: 약간 관련
0.0:  직교 (관련 없음)
-1.0: 정반대 (반대 의미)

RAG에서 보통 0.7 이상을 "관련 문서"로 판단
제조 도메인에서는 0.75 이상을 권장 (정확도 중요)

주의: 임베딩 모델 일관성

인덱싱과 검색에 반드시 같은 모델을 사용해야 한다.

❌ 잘못된 예:
   인덱싱: text-embedding-3-large (3072차원)
   검색:   text-embedding-3-small (1536차원)
   → 차원이 달라서 검색 자체가 불가능!

❌ 미묘한 실수:
   인덱싱: BGE-M3 v1.0
   검색:   BGE-M3 v1.5 (업데이트됨)
   → 같은 모델이지만 벡터 공간이 달라져 정확도 저하

✅ 올바른 방법:
   EMBEDDING_MODEL = "text-embedding-3-small"
   # 인덱싱과 검색 모두 이 변수 참조