[AI] RAG용 VectorDB 튜닝

 

 

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

 

ㅁ 들어가며

RAG를 처음 설계할 때는 자연스럽게 LLM과 Embedding에 시선이 간다.
하지만 실제로 RAG를 붙여서 질의응답을 반복해보면,
어느 순간 이런 느낌을 받게 된다.

“모델은 괜찮은데, 답변이 뭔가 애매하다”

 

이때 많은 경우 문제는 LLM이 아니다.
VectorDB 설정, 더 정확히 말하면 검색 튜닝에 있다.

 

이번 글에서는
  RAG 파이프라인에서 VectorDB가 어떤 역할을 하고,
  왜 튜닝이 성능을 좌우하는지,
  그리고 어떤 기준으로 설정을 조정해야 하는지를 정리해보려 한다.

 

 

ㅁ RAG에서 VectorDB가 병목이 되는 이유

RAG의 흐름을 단순화하면 다음과 같다.

질문 → 임베딩 → VectorDB 검색 → 컨텍스트 구성 → LLM 응답

 

이 중 VectorDB는 단순한 저장소가 아니다.
검색 품질과 응답 속도를 동시에 책임지는 지점이다.

여기서 항상 충돌하는 두 가지 지표가 있다.

• 검색 정확도 (Recall)
• 응답 지연 (Latency)

검색 범위를 넓히면 더 정확해지지만 느려지고,
빠르게 응답하면 관련 문서를 놓치기 쉽다.

 

그래서 VectorDB 튜닝의 본질은

Recall과 Latency 사이의 균형점을 찾는 일
이라고 볼 수 있다.

 

 

ㅁ HNSW, RAG 검색의 사실상 표준

현재 대부분의 VectorDB는
  HNSW(Hierarchical Navigable Small World) 알고리즘을 사용한다.

  HNSW는 모든 벡터를 전부 비교하지 않고도,
  그래프 탐색을 통해 근사 최근접 이웃(ANN) 을 빠르게 찾는 방식이다.

 

중요한 점은
  HNSW는 “알고리즘 하나”라기보다
  파라미터에 따라 성격이 완전히 달라지는 구조라는 것이다.

  같은 데이터, 같은 임베딩이라도 설정값에 따라 결과 품질이 크게 달라진다.

 

 

ㅁ RAG에서 꼭 이해해야 할 핵심 파라미터

HNSW 튜닝에서 실제로 중요한 값은 많지 않다.
하지만 의미를 잘못 이해하면 튜닝 방향이 틀어진다.

 

ㅇ 튜닝을 위한 핵심 개념 한 줄 정의

개념	정의
ef (efConstruction)	HNSW 인덱스 빌드 시 탐색 범위 (높을수록 정확, 느림)
ef (efSearch)	HNSW 검색 시 탐색 범위 (높을수록 정확, 느림)
M (maxConnections)	HNSW 그래프의 연결 수 (높을수록 정확, 메모리 증가)
Recall@K	상위 K개 중 실제 관련 문서 비율
QPS	초당 처리 쿼리 수 (Queries Per Second)

 

efConstruction
인덱스를 만들 때 얼마나 정성 들여 구성할지를 결정한다.
빌드 시간과 인덱스 품질에 영향을 주며,
검색 성능에는 간접적으로 작용한다.

개발 단계에서는 낮게,
프로덕션에서는 한 번만 높게 설정하는 경우가 많다.

 

efSearch
검색 시 탐색하는 후보 벡터 수를 의미한다.
값이 커질수록 더 넓게 탐색하고, Recall은 좋아지지만 응답은 느려진다.

RAG 품질이 낮다고 느껴질 때
가장 먼저 조정해볼 수 있는 파라미터다.

 

M
각 노드가 가질 수 있는 연결 수를 의미한다.
그래프가 촘촘해질수록 검색 품질은 좋아지지만
메모리 사용량이 선형적으로 증가한다.

운영 환경에서는 보통
메모리 예산을 기준으로 상한을 먼저 정한다.

 

ㅁ Recall과 Latency, 피할 수 없는 선택

VectorDB 튜닝을 하다 보면 반드시 마주치는 현실이다.

• efSearch를 올리면 → 정확하지만 느려진다
• M을 올리면 → 정확하지만 메모리를 더 쓴다

그래서 중요한 것은
  최대 성능이 아니라, 서비스 요구사항에 맞는 성능이다.

  RAG는 연구용 시스템이 아니라 운영 대상 시스템이기 때문이다.

 

ㅁ 청크 크기와 VectorDB 튜닝의 관계

VectorDB 설정만 바꾼다고 모든 문제가 해결되지는 않는다.
청크 전략이 함께 맞지 않으면 효과가 제한적이다.

• 작은 청크
  • 검색은 정밀하지만 컨텍스트가 잘게 쪼개진다
• 큰 청크
  • 컨텍스트는 풍부하지만 검색 정확도가 떨어질 수 있다

일반적인 RAG에서는
  256~512 토큰 + overlap 구성이 가장 안정적인 경우가 많았다.

  VectorDB 튜닝과 청크 전략은 항상 함께 봐야 한다.

 

 

ㅁ 프로덕션 관점에서의 튜닝 기준

운영 환경에서는 한 번의 튜닝으로 끝나지 않는다.

지속적으로 확인해야 할 지표는 다음과 같다.

• p50 / p95 / p99 검색 Latency
• Recall@K 추정치
• QPS 증가 시 성능 변화
• 메모리 사용량

정적인 설정값보다 중요한 것은 조정 가능한 구조와 관측 가능한 지표다.

 

ㅁ Week 2를 관통하며 정리한 결론

Week 2를 관통하며 하나의 결론에 도달했다.

Embedding, Chunking, Similarity, HNSW를 각각 따로 보면 개별 기술처럼 보이지만,  
실제 RAG에서는 이 모든 요소가 Retriever라는 하나의 품질로 수렴한다.

RAG 품질은  
모델보다, Embedding보다, Prompt보다  
Retriever 설계에서 가장 크게 갈린다.

그리고 Retriever의 품질은 결국 다음 요소들로 정리된다.

- Chunking 전략  
- Similarity 메트릭  
- ANN(HNSW) 파라미터  
- VectorDB 인덱스 설정과 운영 전략  

즉, RAG용 VectorDB 튜닝은  
  선택 가능한 옵션이 아니라 처음부터 전제로 깔고 가야 할 필수 설계 영역이다.

 

ㅁ 마무리

RAG 품질이 기대에 미치지 못할 때,
많은 경우 가장 먼저 LLM이나 임베딩 모델을 의심한다.

하지만 실제로는
  VectorDB 설정 하나로 결과가 극적으로 달라지는 경우가 많다.

  VectorDB는 단순한 저장소가 아니라,
  RAG의 검색 품질을 결정하는 핵심 컴포넌트다.

모델을 바꾸기 전에,
  VectorDB 튜닝부터 점검해보는 것이 운영 관점에서 훨씬 합리적인 선택일 수 있다.