[Production RAG] Day 2: 임베딩 선택과 인덱스 설계 - 모델 비교와 HNSW/IVF 트레이드오프

서론: 임베딩이 바뀌면 인덱스 전체를 다시 만들어야 한다

임베딩 모델은 RAG 시스템에서 교체 비용이 가장 큰 컴포넌트다. 모델을 바꾸면 기존 벡터와 호환되지 않아 인덱스를 전면 재구축해야 한다. 처음에 올바른 모델을 선택하는 것이 중요한 이유다.

1. 임베딩 모델 선택 기준

1.1 도메인 적합성

범용 모델은 일반 텍스트에 강하지만 법률·의료·코드 같은 특화 도메인에서는 도메인 파인튜닝 모델이 우세한 경우가 많다.

1.2 벡터 차원 vs 성능

차원	특성
256 ~ 512	빠른 인덱싱·검색, 성능 약간 낮음
768 ~ 1024	균형적
1536 ~ 3072	높은 표현력, 스토리지·검색 비용 증가

Matryoshka Representation Learning(MRL) 지원 모델은 차원을 런타임에 축소할 수 있어 유연하다.

1.3 컨텍스트 길이

임베딩 모델의 최대 입력 길이가 청크 크기보다 작으면 청크가 잘린다.

청크 크기 ≤ 임베딩 모델 최대 입력 토큰

1.4 비용

• 클라우드 API: 비용 예측 용이, 지연 변동 있음
• 로컬 배포: 초기 비용 있지만 대량 처리에 유리

2. 벡터 인덱스 알고리즘

2.1 HNSW (Hierarchical Navigable Small World)

그래프 기반 근사 최근접 이웃(ANN) 검색이다.

장점:
  - 검색 속도 빠름 (쿼리 지연 낮음)
  - 높은 리콜(Recall)

단점:
  - 메모리 사용량 큼 (인덱스가 RAM에 상주)
  - 인덱스 구축 느림
  - 동적 삽입·삭제에 상대적 취약

적합: 쿼리 지연이 중요하고 데이터셋이 메모리에 맞는 경우

2.2 IVF (Inverted File Index)

벡터를 클러스터로 나누고, 쿼리 시 가장 가까운 클러스터만 탐색한다.

장점:
  - 대규모 데이터셋에 확장 용이
  - 디스크 기반 운용 가능

단점:
  - 클러스터 수(nlist) 튜닝 필요
  - HNSW 대비 리콜이 낮을 수 있음

적합: 수천만 벡터 이상의 대규모 인덱스

2.3 IVF + PQ (Product Quantization)

벡터를 압축해 메모리를 크게 줄인다. 리콜과 메모리의 트레이드오프가 있다.

3. 인덱스 설계 의사결정

데이터 규모
  └─ 수백만 이하 + 낮은 지연 필요 → HNSW
  └─ 수천만 이상 + 스토리지 절약 → IVF or IVF+PQ
  └─ 혼합 필요 → Weaviate/Qdrant 같은 라이브러리가 자동 선택

4. 메타데이터 스키마 설계

벡터만 저장하지 않는다. 검색 후 필터링과 권한 제어를 위한 메타데이터가 필수다.

{
  "id": "doc_001_chunk_03",
  "vector": [...],
  "metadata": {
    "source": "contract_2026.pdf",
    "page": 3,
    "section": "3조 납품 조건",
    "sensitivity": "confidential",
    "owner_team": "legal",
    "created_at": "2026-01-15",
    "chunk_index": 3,
    "parent_chunk_id": "doc_001"
  }
}

sensitivity와 owner_team 필드는 검색 시 권한 필터로 사용한다.

5. 운영 관측 지표

• 임베딩 생성 처리량 (tokens/sec)
• 인덱스 크기 및 증가율
• 검색 지연 p50/p95
• Recall@K (동일 쿼리 정확 매칭 비율)

6. Day 2 체크리스트

1. 임베딩 모델 컨텍스트 길이가 청크 크기를 초과하는지 확인했다.
2. 데이터 규모와 지연 요건에 맞는 인덱스 알고리즘을 선택했다.
3. 메타데이터 스키마에 권한 필터용 필드를 포함했다.
4. 임베딩 모델 교체 시 인덱스 재구축 계획을 수립했다.

다음 글 예고

Day 3에서는 하이브리드 검색과 리랭킹을 다룬다. 벡터 검색과 키워드 검색을 결합하는 방법과, 회수된 청크를 품질 순으로 재정렬하는 리랭킹 전략을 살펴본다.