RAG 벡터 데이터베이스 활용법, 인덱싱 전략과 검색 전략으로 사내 챗봇 정확도 잡기 (Pinecone·ChromaDB·청킹·하이브리드검색)
사내 챗봇 만들어놓고 막상 써보면 이상한 답을 내놓는 경우, 꽤 흔하거든요.
분명 사내 규정 문서를 다 넣어줬는데, 작년에 바뀐 정책을 옛날 버전으로 답하거나 아예 없는 내용을 지어내기도 해요.
이게 LLM 모델 탓이라고 생각하기 쉬운데, 사실 문제의 절반 이상은 RAG 벡터 데이터베이스 설계에서 갈립니다.
문서를 어떻게 쪼개서 넣었는지, 어떤 벡터DB에 저장했는지, 검색할 때 뭘 우선순위로 뽑아오는지가 답변 품질을 좌우하는 거죠.
RAG 벡터 데이터베이스가 챗봇 정확도를 가르는 이유
RAG(검색 증강 생성)는 LLM이 학습 당시 외운 지식이 아니라, 실제 사내 문서에서 검색해온 내용을 근거로 답변을 만드는 구조예요.
삼성SDS가 사내 클라우드 플랫폼 기술지원용으로 만든 'SKE-GPT'가 대표적인 사례입니다. GPT-3.5-Turbo는 2021년까지의 데이터만 학습되어 있어서 최신 사내 정책에는 답을 못 했는데, RAG를 적용하니 현재 시점 정보로 답변할 수 있게 됐어요. 그 결과 SCP 컨테이너 기술지원 문의 중 약 68%가 가이드만으로 자가 해결됐다고 합니다. (출처: 삼성SDS 인사이트리포트)
KB국민카드도 비슷해요. LLM 챗봇에 이벤트 정보를 RAG로 연동한 뒤 고객 이벤트 문의 응답률이 85%에서 98%로 올라갔고, 상담원 만족도는 32% 향상됐습니다.
여기서 벡터 데이터베이스는 '검색' 파트를 전담하는 인프라예요.
문서를 임베딩(실수 벡터)으로 바꿔 저장해두고, 질문이 들어오면 의미적으로 가장 가까운 벡터를 찾아 LLM에 넘겨주는 역할이죠.
결국 LLM이 얼마나 똑똑한지보다, 벡터DB가 얼마나 정확하게 관련 문서를 찾아주는지가 답변 품질의 출발점이라는 얘기예요.
인덱싱 전략: 청킹부터 임베딩까지 4단계
RAG 인덱싱은 보통 로드(Load) → 분할(Split) → 임베딩(Embed) → 저장(Store) 4단계로 진행됩니다. (출처: 삼성SDS 인사이트리포트)
- 로드: TXT, PDF, 웹페이지, JSON, 코드, 이미지, CSV 등 다양한 형식의 사내 문서를 모읍니다.
- 분할: RecursiveCharacterTextSplitter 같은 방식으로 문서를 청크 단위로 쪼개요. 이때 chunk_overlap(중첩 구간)을 줘야 청크 경계에서 끊긴 문맥을 양쪽이 나눠 가져서 문장 이해도가 올라갑니다.
- 임베딩: 쪼갠 텍스트를 실수 벡터로 변환해요. OpenAI Embedding API를 쓸 수도 있고, 로컬 오픈소스 모델을 선택할 수도 있어요.
- 저장: 만들어진 벡터를 벡터 데이터베이스에 넣어 검색 가능한 상태로 만들어요.
청킹 크기는 생각보다 민감한 변수예요. 일반적인 텍스트는 400~512 토큰 단위로 재귀적 분할을 하고 10~20% 정도 중첩을 주는 게 출발점으로 권장되는데, PDF처럼 페이지가 명확히 나뉜 문서는 페이지 단위로 자르는 게 더 좋은 성능을 보였다고 해요.
반면 의미 단위로 나누는 시맨틱 청킹은 재현율은 높아지지만 처리 비용이 더 듭니다.
상위 청크엔 요약, 하위 청크엔 세부 내용을 담는 계층형 청킹 방식은 구조화된 문서에서 F1 점수가 3~5배 향상된 결과도 있었어요.
청킹 다음엔 인덱스 알고리즘도 봐야 해요. 대표적으로 HNSW(계층형 그래프 구조로 빠른 탐색과 높은 재현율을 동시에 챙기는 방식)와 IVF(데이터를 여러 클러스터로 나눠 검색 범위를 좁히는 방식)가 있습니다. 둘 다 FAISS 라이브러리에서 지원되고, 임베딩 모델은 보통 768~3072차원 사이의 벡터를 만들어내요.
임베딩 모델도 고민거리예요. OpenAI text-embedding-3-small은 100만 토큰당 0.02달러로 비용 대비 품질이 좋다는 평가를 받고, text-embedding-3-large는 R@1 34.6%, R@5 57.4%로 더 높은 정확도를 보였어요. 오픈소스 쪽에서는 Multilingual E5-Instruct가 R@1 26.4%, R@5 49.7%를 기록했는데, e5-small·e5-base-instruct·e5-large-instruct 같은 E5 계열 모델들은 Top-5 정확도 100%를 찍은 결과도 있어서, 도메인에 따라 순위가 꽤 달라지는 편이에요.
Pinecone과 ChromaDB, 사내 챗봇엔 뭐가 맞을까
벡터DB 선택을 두고 가장 많이 비교되는 게 Pinecone과 ChromaDB예요.
ChromaDB는 경량 오픈소스 벡터DB로, 임베디드 우선 구조라 로컬 환경에서 RAG 파이프라인에 빠르게 붙이기 좋아요. 신규 RAG 프로젝트라면 ChromaDB로 시작해서 프로토타입부터 대부분의 프로덕션 단계까지 끌고 가다가, 한계에 부딪히면 다른 DB로 옮기는 방식이 권장되기도 합니다.
다만 1억 개 벡터 규모로 가면 얘기가 달라져요. 그 규모 벤치마크에서는 Pinecone과 Weaviate가 별도 튜닝 없이도 재현율을 유지했는데, Chroma는 역부족이라는 평가를 받았거든요. 그러니까 중소 규모 사내 문서량이라면 충분하지만, 문서가 수억 건 단위로 쌓이는 대기업 환경에서는 한계가 있다는 뜻으로 봐야 해요.
Pinecone은 완전관리형 서비스로 대규모 벡터에서도 실시간 저지연 검색에 강해요. 500만 개 이상 벡터에서도 p95 지연시간 20ms 이하를 유지하지만, 동일 벡터 수 기준 Supabase Postgres보다 3~8배 비싸다는 평가도 있어요. 가격대는 10만 개 벡터까지 무료, 서버리스 소규모는 월 70달러, 중간 규모는 월 500~2,500달러, 대규모는 월 1만 달러 이상입니다. 보통 문서 청크 100만~500만 개를 인덱싱하는 RAG 앱이라면 월 100~500달러 정도 든다고 봐요.
Qdrant는 자체 호스팅 환경에서 처리량이 가장 좋다는 평가를 받아요. 공개 벤치마크 기준 100만 벡터에서 p95 지연 약 8ms, 약 850 QPS를 기록했고, 월 30달러짜리 VPS에 자체 호스팅해도 1,000만 개 이상의 벡터를 거뜬히 처리합니다. 동급 Pinecone 용량보다 10배 정도 저렴한 셈이에요. 그래서 가격 대비 성능을 우선한다면 Qdrant가 자주 추천되는 편이고요.
Weaviate는 하이브리드 검색을 지원하고 엔터프라이즈 환경에 친화적인 게 특징이에요. 클라우드 입문 요금제가 월 25달러로 관리형 벡터DB 중에서는 가장 저렴한 수준입니다.
벡터DB 관련 커뮤니티 후기들을 보면, "처음엔 Pinecone 무료 티어로 테스트하다가 운영 단계에서 비용 부담 때문에 Qdrant 자체 호스팅으로 옮겼다"는 이야기가 꽤 자주 보여요. 사내 챗봇처럼 문서량이 꾸준히 늘어나는 환경이라면, 처음 선택할 때부터 마이그레이션 가능성을 염두에 두는 게 안전합니다.
검색 전략 — 하이브리드 검색과 리랭킹이 진짜 차이를 만든다
인덱싱을 잘해놨어도 검색 단계에서 놓치면 소용없어요.
핵심은 하이브리드 검색과 리랭킹, 이 둘의 조합입니다.
하이브리드 검색은 의미 기반 유사도 검색(dense retrieval)에 키워드 기반 검색(sparse retrieval)을 같이 쓰는 방식이에요. 프로덕션 RAG 시스템의 72%가 이 방식을 쓰고 있고, Recall@10 기준 91%를 기록했다고 해요.
리랭킹은 1차로 후보를 빠르게 추린 다음, 쿼리와 문서를 함께 넣어 관련도 점수를 직접 계산하는 2차 정렬 과정이에요. 쿼리와 문서를 따로따로 임베딩하는 방식보다 정확도가 더 높습니다.
검색 결과를 다듬는 옵션도 따로 있어요. MMR(Maximum Marginal Relevance)은 검색된 문서들 사이의 유사도를 일부러 낮춰서 다양성을 확보하는 방식이고, 유사도 점수 임계값은 0~1 범위에서 특정 점수 이상인 문서만 반환하도록 걸러주는 방식이에요.
물론 사내 문서를 다루는 만큼 보안도 같이 챙겨야 해요. 데이터 암호화는 기본이고, 벡터 스토어·임베딩 모델·LLM 같은 구성 요소들이 외부에 노출되지 않도록 막는 설계가 필요합니다.
결국 벡터DB 선택보다 먼저 정해야 할 건 운영 시나리오
여러 벡터DB를 비교해보면서 느낀 건, "어떤 게 제일 좋아요"라는 질문 자체가 좀 잘못됐다는 거예요.
문서가 몇십만 건인지 몇억 건인지, 예산이 월 얼마인지, 직접 운영할 인력이 있는지에 따라 답이 완전히 달라지거든요.
작게 시작할 거면 ChromaDB로 빠르게 띄워보고, 비용이 부담스러우면 Qdrant 자체 호스팅을, 운영 부담을 줄이고 싶으면 Pinecone을 쓰는 식으로 갈리는 거죠.
청킹 전략과 하이브리드 검색·리랭킹까지 신경 쓰면 거기서 정확도가 한 번 더 갈립니다.
결국 벡터DB는 도구일 뿐, 진짜 승부는 우리 회사 문서 특성에 맞는 인덱싱·검색 조합을 찾는 데서 납니다.
참고: 삼성SDS 인사이트리포트 - Gen AI 해커톤 RAG 적용 사례, Vector Database Comparison 2026, 4xxi