[AI] Vector Similarity — RAG에서 “가장 중요한 수학”

 

 

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해

 

ㅁ 들어가며

Embedding 글에서 이야기했던 핵심은 이것이었다.

Transformer가 만든 의미를 벡터로 “저장”했다면,
이제 남은 문제는 하나다.

 

이 벡터들을 어떻게 비교할 것인가.

많은 RAG 튜토리얼은 “임베딩하고 VectorDB에 넣으면 된다”에서 끝난다.

 

하지만 실제로 시스템을 만들어 보면 곧 느끼게 된다.

  모델보다,
  임베딩보다,
  심지어 Chunking보다도

  Similarity Metric이 검색 품질을 크게 좌우한다는 사실을.

 

Vector Similarity는 단순한 계산 공식이 아니다.

RAG에서 Vector Similarity는 곧,

의미를 어떻게 해석할 것인가에 대한 설계다.

 

 

ㅁ Vector Similarity란 무엇인가

Vector Similarity는 두 벡터가 얼마나 “가까운지”를 계산하는 방식이다.

조금 더 정확히 말하면,

두 문장이 의미 공간에서 얼마나 비슷한 위치에 있는지를 측정하는 방법이다.

 

중요한 점은 이것이다.

임베딩 벡터 자체보다 더 중요한 것은
그 벡터를 비교하는 방식이다.

 

같은 임베딩을 써도,
Similarity Metric이 달라지면 검색 결과가 달라진다.

그래서 Vector Similarity는 검색 알고리즘이 아니라
의미 해석 방식에 가깝다.

 

 

ㅁ 대표적인 세 가지 유사도 메트릭

실무에서 가장 많이 쓰이는 메트릭은 세 가지다.

• Cosine Similarity
• Dot Product
• L2 Distance

수식보다 직관이 중요하다.

 

 

ㅁ Cosine Similarity — 방향만 본다

Cosine Similarity는 두 벡터의 각도를 비교한다.

크기는 무시하고,
방향만 본다.

 

즉,

두 문장이 같은 “의미 방향”을 가리키고 있는지를 판단한다.

 

그래서 문서 길이나 정보량의 영향을 덜 받는다.

실무에서 RAG에 가장 널리 쓰이는 이유도 여기에 있다.

• 문서가 길어도
• Chunk 크기가 조금 달라도

의미 패턴만 비슷하면 가까운 것으로 판단된다.

대부분의 텍스트 임베딩 모델이 Cosine 기준으로 사용되는 것도 같은 이유다.

 

 

ㅁ Dot Product — 방향 + 크기

Dot Product는 방향뿐 아니라 벡터 크기까지 함께 반영한다.

직관적으로 보면,

의미가 비슷하면서, 정보량이 많은 쪽이 더 크게 평가된다.

 

추천 시스템이나 랭킹 모델에서 자주 사용된다.

다만 텍스트 RAG에서는 주의가 필요하다.

Chunk가 길어질수록 값이 커질 수 있기 때문이다.

정규화를 하지 않으면
  “길이가 긴 문서가 유리해지는” 현상이 발생할 수 있다.

 

 

ㅁ L2 Distance — 실제 공간 거리

L2 Distance는 두 벡터 사이의 실제 유클리드 거리를 잰다.

좌표 간의 절대 거리다.

클러스터링이나 이상 탐지에는 직관적이지만,
고차원 텍스트 임베딩에서는 안정성이 떨어질 수 있다.

그래서 일반적인 문서 RAG에서는 Cosine보다 덜 쓰인다.

 

 

ㅁ 중요한 사실 — 정답은 없다

Vector Similarity에서 가장 중요한 사실은 이것이다.

어느 메트릭이 “더 좋다”는 정답은 없다.

 

대신, 항상 다음을 함께 고려해야 한다.

• 임베딩 모델이 어떤 방식으로 학습됐는지
• 벡터가 정규화되어 있는지
• Chunk 크기
• 문서 길이
• 언어 특성

예를 들어,

L2 정규화를 한 벡터에서는:

• Cosine Similarity = Dot Product
• L2 Distance도 Cosine과 수학적으로 연결된다

즉, 조건에 따라 세 메트릭은 사실상 같은 의미가 되기도 한다.

그래서 Similarity 선택은 공식 문제가 아니라
시스템 조건에 맞춘 설계 문제다.

 

 

ㅁ 실무에서 느낀 가장 큰 차이

직접 RAG 파이프라인을 만들면서 가장 크게 느낀 점은 이것이었다.

Embedding 모델을 바꿔도 품질 변화는 크지 않았다.
Chunking을 바꾸면 체감이 됐다.
Similarity를 바꾸면 결과가 즉각 달라졌다.

그래서 요즘은 이렇게 생각한다.

LLM 성능보다 Embedding,
Embedding보다 Chunking,
Chunking보다 Similarity 설계가 더 중요하다.

Vector Similarity는 Retriever의 심장이다.

Retriever 품질이 곧 RAG 품질이다.

---

ㅁ VectorDB는 검색 엔진이 아니다

Embedding 글에서도 이야기했지만,
다시 정리하면 이렇다.

VectorDB는 검색 엔진이 아니다.

의미 공간 탐색기다.

흐름은 항상 같다.

질문 → 벡터화
→ 거리 계산
→ 가장 가까운 의미 좌표 선택

SQL처럼 조건을 필터링하는 게 아니라,
지도에서 가장 가까운 지점을 찾는 구조다.

그래서 Similarity Metric은

“정렬 옵션”이 아니라
지도 좌표계를 어떻게 정의하느냐의 문제다.

 

ㅁ Similarity는 RAG 전체 파이프라인의 일부다

Vector Similarity는 단독으로 존재하지 않는다.

항상 이 흐름 안에 있다.

Transformer → Embedding → Chunking
  → Vector Similarity → Retriever
  → Reranker → LLM

Similarity는 Retriever의 중심이고, Retriever는 RAG 품질의 핵심이다.

그래서 Similarity를 이해하지 못하면 RAG를 이해했다고 보기 어렵다.

 

 

ㅁ 마무리

Similarity는 수학이 아니라 설계다

 

Vector Similarity는 공식 암기 문제가 아니다.

    의미를 어떻게 나누고,
    어떻게 비교하고,
    어떻게 연결할 것인가에 대한 설계 문제다.

좋은 RAG는 모델에서 나오지 않는다.

의미를 다루는 방식에서 나온다.