엔터프라이즈 환경에서 RAG의 성패는 “LLM을 무엇으로 쓰느냐”가 아니라 “무엇을 검색해서 넣어주느냐”에서 갈립니다. 벡터 검색만으로는 사번·계약번호·정확한 용어 매칭이 약하고, 키워드 검색만으로는 의미가 비슷한 문서를 놓칩니다. 두 방식을 결합한 하이브리드 RAG가 현실적인 정답인 이유입니다.
레퍼런스 아키텍처
아래는 저희가 고객사 현장에 배포하는 하이브리드 RAG의 기본 골격입니다. 데이터를 미리 색인하는 인덱싱 파이프라인(오프라인)과, 질문이 들어올 때 동작하는 질의 파이프라인(런타임)으로 나뉘며, 그 아래에 보안·거버넌스 레이어가 항상 깔려 있습니다.
인덱싱 파이프라인 (오프라인)
사내 데이터 소스
문서 · 위키 · 정산 로그
전처리 & 청킹
정제 · 메타데이터 부여
임베딩 모델
문서 → 벡터 변환
인덱스 저장
벡터 DB + 키워드(BM25)
질의 파이프라인 (런타임)
사용자 질문
현업 담당자 질의
하이브리드 검색
벡터 + 키워드 동시
Re-ranking
관련도 재정렬
LLM 응답 생성
컨텍스트 주입 + 출처
1. 인덱싱: 검색 품질의 80%는 여기서 결정됩니다
많은 RAG 프로젝트가 임베딩 모델 선택에만 집착하지만, 실제 정확도는 그 앞단인 청킹과 메타데이터 설계에서 대부분 결정됩니다.
- check_circle문맥 보존 청킹: 고정 길이로 자르지 않고 제목·섹션 단위로 분할해 의미가 끊기지 않게 합니다.
- check_circle메타데이터 부여: 부서·문서종류·작성일·접근권한을 함께 색인해 필터링과 권한 제어의 기반으로 씁니다.
- check_circle이중 인덱스: 같은 청크를 벡터 DB와 키워드(BM25) 인덱스에 동시에 적재합니다.
2. 질의: 하이브리드 검색 + Re-ranking
런타임에는 사용자의 질문을 벡터 검색과 키워드 검색에 동시에 던지고, 두 결과를 합친 뒤 Re-ranker로 관련도를 다시 정렬합니다. 이 과정에서 핵심은 두 점수를 어떻게 합치느냐입니다.
RRF(Reciprocal Rank Fusion)로 점수 합치기
벡터 유사도와 BM25 점수는 스케일이 달라 단순 가중합이 위험합니다. 각 검색 결과의 “순위”만 사용하는 RRF 방식이 튜닝 부담이 적고 안정적입니다. 합친 후보군을 Re-ranker(크로스 인코더)로 다시 평가하면 상위 컨텍스트의 정밀도가 크게 올라갑니다.
현장 팁
검색 결과 상위 3~5개만 LLM에 넣으세요. 컨텍스트를 많이 넣을수록 정확해질 것 같지만, 오히려 노이즈가 늘어 환각과 응답 지연이 증가합니다. “적게, 정확하게”가 원칙입니다.
3. 환각을 줄이는 생성 단계 설계
- check_circle출처 강제: 모든 답변에 근거 문서 ID를 함께 출력하게 해 검증 가능하게 만듭니다.
- check_circle모르면 모른다: 검색 결과가 부실하면 추측하지 말고 “자료 없음”을 답하도록 지시합니다.
- check_circle근거 추적: 답변 문장과 인용 청크를 매핑해 감사 로그로 남깁니다.
4. 보안 · 거버넌스는 옵션이 아닙니다
엔터프라이즈 RAG에서 가장 자주 터지는 사고는 “권한이 없는 사용자가 검색을 통해 민감 문서를 열람”하는 케이스입니다. 검색 단계에서 사용자 권한(ACL)으로 후보를 필터링하고, PII는 색인 전에 마스킹하며, 모든 질의·응답을 감사 로그로 남기는 구조를 처음부터 설계에 넣어야 합니다.
요약
하이브리드 검색 → Re-ranking → 출처 강제 → 권한 필터링. 이 네 가지만 제대로 갖춰도 사내 RAG의 체감 정확도는 데모 수준에서 운영 수준으로 올라섭니다.