- Vector DB 자체보다 top-k, context 길이, re-ranking 같은 검색 전략이 RAG 품질을 좌우한다.
- Top-k를 키우면 recall은 좋아지지만 latency와 비용이 증가한다.
- 운영 가능한 RAG는 정확도, 속도, 비용의 허용 기준을 먼저 정해야 한다.
RAG를 처음 도입할 때 가장 많이 나오는 질문 중 하나는 이것이다. “Vector DB는 어떤 걸 쓰는 게 좋을까요?”
물론 DB 선택도 중요하지만, 실제 운영 경험상 DB 종류보다 훨씬 중요한 것은 검색 전략이다.
Vector DB는 생각보다 큰 차이를 만들지 않는다
FAISS, Pinecone, Azure AI Search 등 대부분의 Vector DB는 기본적인 유사도 검색 성능이 충분히 좋다.
문제는 보통 어떤 DB를 쓰느냐보다 “어떻게 검색하느냐”, “검색 결과를 어떻게 쓰느냐”에 있다.
Top-k는 단순한 숫자가 아니다
Top-k는 유사한 문서 몇 개를 가져올 것인가를 의미한다.
Top-k가 크면
- 검색 recall은 좋아진다.
- context가 길어진다.
- latency가 증가한다.
Top-k가 작으면
- 응답은 빨라진다.
- 중요한 문서를 놓칠 수 있다.
그래서 실무에서는 초기에는 넉넉하게 가져오고, 운영 단계에서는 3~5 수준으로 줄이는 경우가 많다.
Top-k는 고정 값이 아니라 질문 유형과 운영 환경에 따라 조정해야 하는 변수다.
Re-ranking이 필요한 순간
유사도 검색만으로는 항상 가장 적절한 문서가 위에 오지 않는다. 이럴 때 사용하는 것이 Re-ranking이다.
- 1차로 Vector DB에서 후보 문서를 검색한다.
- 2차로 LLM이나 별도 모델로 후보를 재정렬한다.
모든 시스템에 반드시 필요한 것은 아니지만, 문서 수가 많아지고 질문이 복잡해질수록 Re-ranking은 검색 품질을 한 단계 끌어올리는 역할을 한다.
검색 전략은 항상 트레이드오프다
검색 품질을 올리면 latency가 증가하고 비용이 늘어난다. 반대로 속도와 비용을 줄이면 검색 정확도가 떨어질 수 있다.
그래서 기업용 RAG에서는 항상 질문이 하나로 귀결된다.
- 완벽한 정확도인가?
- 충분히 빠른 응답인가?
- 예측 가능한 비용인가?
이 기준을 먼저 정하지 않으면 검색 전략은 끝없이 흔들리게 된다.
정리하며
Vector DB는 RAG의 기반이지만, RAG의 품질을 결정짓는 것은 결국 검색 전략이다.
- Top-k 설정
- Context 길이
- Re-ranking 여부
- 운영 환경에 따른 튜닝
이 요소들을 어떻게 설계하느냐가 데모용 RAG와 운영 가능한 RAG를 가른다.