RAG 방식 선택 가이드 (RAG Selection Guide)

RAG 시리즈에서는 벡터 RAG, 하이브리드 검색, 리랭킹, 쿼리 변환, Vectorless RAG, Agentic RAG, 롱 컨텍스트/CAG, Graph RAG, 온톨로지 RAG까지 여러 방식을 다뤘습니다. 각 노트는 "이 방식이 무엇인가"를 설명했고, 이 문서는 "내 상황에는 무엇을 쓰는가"를 정리합니다.

먼저 기억할 원칙은 세 가지입니다.

1. 가장 단순한 방식에서 시작합니다. 문서가 적으면 검색 없이 통째로 넣는 것부터 시도합니다.
2. 측정된 실패에 맞춰 기법을 더합니다. 평가 세트 없이 기법을 쌓으면 무엇이 효과였는지 알 수 없습니다.
3. 방식은 서로 배타적이지 않습니다. 실무 시스템은 대부분 두세 가지를 조합합니다.

RAG 방식들은 "무엇을 인덱스로 쓰는가"와 "누가 검색을 결정하는가" 두 축으로 나눌 수 있습니다.

                     검색을 결정하는 주체
                 고정 파이프라인          LLM(에이전트)
              ┌──────────────────────┬──────────────────────┐
  인덱스 없음 │ 롱 컨텍스트 / CAG     │ Agentic RAG          │
              │ (통째로 넣기)         │ (grep, 파일 읽기)    │
              ├──────────────────────┼──────────────────────┤
  키워드/구조 │ BM25 RAG             │ Vectorless RAG       │
              │                      │ (목차 트리 추론 탐색) │
              ├──────────────────────┼──────────────────────┤
  벡터        │ Naive / Advanced RAG │ Agentic RAG          │
              │ (+하이브리드, 리랭킹) │ (벡터 검색을 도구로)  │
              ├──────────────────────┼──────────────────────┤
  그래프      │ Graph RAG            │ Text2Cypher 에이전트  │
              │ 온톨로지 RAG          │                      │
              └──────────────────────┴──────────────────────┘

Advanced RAG의 개선 기법(청킹, 하이브리드 검색, 리랭킹, 쿼리 변환)은 따로 쓰는 방식이라기보다 벡터 RAG 파이프라인의 한 단계를 바꾸는 부품입니다.

질문 → [쿼리 변환] → [검색: dense + BM25 → RRF] → [리랭킹] → 프롬프트 조립 → 생성
                         ↑
              인덱싱: 로드 → [청킹] → 임베딩 → 저장

4-1. 시작점: 데이터 크기 확인하기

전체 문서가 컨텍스트 윈도우에 들어가는가?
├── 예 → 자주 바뀌지 않는가? 사용자별 권한이 같은가?
│        ├── 예 → 롱 컨텍스트 + 프롬프트 캐싱 (검색 없음)
│        └── 아니오 → 아래로
└── 아니오 → 검색이 필요하다 → 4-2

문서가 수십 개 수준이고 잘 바뀌지 않는다면 RAG를 만들기 전에 통째로 넣어 보는 것이 가장 쌉니다. 인덱싱 파이프라인, 청킹 튜닝, 벡터 DB 운영이 모두 사라집니다.

4-2. 질문 유형으로 고르기

대부분의 프로젝트는 아래 순서로 성장합니다. 각 단계는 앞 단계에서 측정된 문제가 있을 때만 넘어갑니다.

0단계  롱 컨텍스트 + 캐싱
       └ 문서가 윈도우를 넘거나 비용이 커짐
1단계  Naive 벡터 RAG + 평가 세트
       └ 고유명사 실패 / 순서 문제
2단계  하이브리드 검색 + 리랭킹 (Advanced RAG)
       └ 구어체·복합 질문 실패
3단계  쿼리 변환 + 라우팅
       └ 다중 홉·탐색형 질문 실패
4단계  Agentic RAG (기존 검색을 도구로)
       └ 관계·전역 질문이 핵심 요구사항
5단계  Graph RAG 또는 온톨로지 RAG를 하나의 경로로 추가

이후 모든 단계에서 "넘어갈지"를 판단하는 근거가 평가 세트이므로, 1단계에서 평가 세트를 만드는 일이 가장 중요합니다.

6-1. 사내 규정 Q&A 챗봇

• 문서: 인사·보안 규정 수십 개, 분기마다 개정
• 구성: 롱 컨텍스트 + 프롬프트 캐싱으로 시작합니다. 문서가 늘면 벡터 RAG로 바꾸고, 조항 번호 검색을 위해 하이브리드 검색을 붙입니다.
• 청킹: 조항 단위 (문서 구조 기반)

6-2. 고객 지원 문서 검색

• 문서: 제품 매뉴얼, FAQ, 장애 공지 수천 건
• 구성: 하이브리드 검색 + 리랭킹 + 대화 맥락 독립화
• 이유: 에러 코드와 제품명이 많아 BM25가 필요하고, 고객은 후속 질문을 많이 합니다.

6-3. 코딩 에이전트

• 데이터: 계속 바뀌는 코드베이스
• 구성: Agentic RAG (grep, glob, 파일 읽기)
• 이유: 벡터 인덱스는 코드가 바뀔 때마다 낡습니다. 에이전트가 직접 찾는 편이 단순하고 최신입니다.

6-4. 재무 보고서 분석

• 문서: 수백 쪽짜리 사업보고서 여러 건
• 구성: 문서 선택은 메타데이터 필터/BM25, 문서 안은 Vectorless 트리 탐색
• 이유: 목차가 잘 정리된 긴 문서라 저자의 구조를 그대로 인덱스로 쓸 수 있습니다.

6-5. 리서치 인터뷰 분석

• 문서: 인터뷰 녹취록 수백 건

도입 전에 확인합니다.

• 전체 문서 크기는? 컨텍스트 윈도우에 들어가는가?
• 데이터는 얼마나 자주 바뀌는가?
• 사용자별 권한 필터가 필요한가?
• 주된 질문 유형은? (단일 사실 / 정확한 용어 / 다중 홉 / 전역 요약 / 집계)
• 질문당 허용 지연과 비용은?
• 답의 근거를 설명해야 하는가?
• 골든 데이터셋이 있는가? 없으면 이것부터 만든다.
• 검색 지표(recall@k)와 생성 지표(faithfulness)를 나눠서 보고 있는가?

RAG 방식은 "무엇을 인덱스로 쓰는가(없음/키워드·구조/벡터/그래프)"와 "누가 검색을 결정하는가(파이프라인/LLM)"로 나눌 수 있습니다. 문서가 컨텍스트 윈도우에 들어가고 잘 바뀌지 않으면 통째로 넣고 캐싱하는 것이 가장 쌉니다. 그보다 크면 Naive 벡터 RAG와 평가 세트로 시작하고, 측정된 실패에 따라 하이브리드 검색(정확한 용어), 리랭킹(순서), 쿼리 변환(구어체·복합 질문), Agentic RAG(탐색형·다중 홉)를 차례로 더합니다. 길고 구조화된 문서에는 Vectorless 트리 탐색, 관계와 전역 요약 질문에는 Graph RAG, 정확한 조건 질의와 설명 가능성이 중요한 도메인에는 온톨로지 RAG가 맞습니다. 실무 시스템은 대부분 여러 방식을 라우팅으로 조합하며, 모든 선택의 근거는 검색과 생성을 나눠 측정하는 평가 세트입니다.