Problem
어떤 문제를 풀었나
블로그·논문에서 단편적으로 접하는 RAG 기법들의 상대적 효용과 한계를 체감하기 어려웠고, 특히 '언제 어떤 기법을 써야 하는가'에 대한 감이 없었습니다. 이를 직접 만들고 측정해서 정리해보고자 했습니다.
Project Detail
RAG Playground
공공데이터로 RAG 파이프라인을 단계별로 실험한 학습 프로젝트
공공데이터로 Naive RAG부터 Agentic RAG까지 7단계 파이프라인을 직접 쌓고, NDCG·MRR·P@5로 정량 비교한 학습 프로젝트.
기간
2026.02 ~ 2026.04
팀 구성
개인
기술 스택
9개 기술 사용
Contribution
내 핵심 기여
공공데이터포털 API 수집 및 임베딩 친화적 문서 변환 · Qdrant Cloud 기반 Dense/Sparse 인덱스 설계
Outcome
무엇을 증명했나
OpenAI text-embedding-3-small 기반 Dense와 Qdrant server-side BM25 Sparse를 RRF로 결합. 별도 BM25 서버 없이 단일 컬렉션에서 동시 인덱싱.
한눈에 보기
공공데이터로 Naive RAG부터 Agentic RAG까지 7단계 파이프라인을 직접 쌓고, NDCG·MRR·P@5로 정량 비교한 학습 프로젝트.
Target User
누구를 위한 프로젝트인가
공공데이터로 RAG 파이프라인을 단계별로 실험한 학습 프로젝트
Core Experience
사용자에게 주는 핵심 경험
공공데이터로 RAG 파이프라인을 단계별로 실험한 학습 프로젝트
Why It Matters
왜 의미 있는가
Naive RAG → BM25 → Hybrid(RRF) → Rerank → HyDE/Multi-Query → Agentic RAG까지 7단계 파이프라인을 단일 저장소에 누적
Naive RAG → BM25 → Hybrid(RRF) → Rerank → HyDE/Multi-Query → Agentic RAG까지 7단계 파이프라인을 단일 저장소에 누적Qdrant Cloud server-side inference로 BM25 sparse vector 인덱싱 — 외부 별도 인덱스 불필요novita.ai BGE-reranker-v2-m3의 relevance score를 '참고값'이 아닌 신뢰도 지표로 활용해 fallback 경계선 설계
Background
Purpose | 목적
RAG 시스템의 각 검색 전략(Dense, Sparse, Hybrid, Re-ranking, Query Rewriting, Agentic)이 실제 검색 품질과 응답 시간에 어떤 영향을 주는지 직접 구현하고 비교
Problem | 해결하려던 문제
블로그·논문에서 단편적으로 접하는 RAG 기법들의 상대적 효용과 한계를 체감하기 어려웠고, 특히 '언제 어떤 기법을 써야 하는가'에 대한 감이 없었습니다. 이를 직접 만들고 측정해서 정리해보고자 했습니다.
Key Features | 핵심 기능
What makes this project special
1
Naive RAG → BM25 → Hybrid(RRF) → Rerank → HyDE/Multi-Query → Agentic RAG까지 7단계 파이프라인을 단일 저장소에 누적
2
Qdrant Cloud server-side inference로 BM25 sparse vector 인덱싱 — 외부 별도 인덱스 불필요
3
novita.ai BGE-reranker-v2-m3의 relevance score를 '참고값'이 아닌 신뢰도 지표로 활용해 fallback 경계선 설계
4
Agentic RAG에서 질의 분석 → 소스 라우팅 → 기법 선택 → relevance 기반 재질의까지 오케스트레이션 계층 구현
5
10개 질의 × 7개 모드에 대해 NDCG@5 / MRR / Precision@5 정량 측정, '데이터에 없는 질의'까지 평가셋에 포함
6
모든 구현·결과를 시리즈 9편 블로그로 문서화 (프롤로그 → Quest 1~7 → 에필로그)
Technical Specifications | 기술 사양
Engineering details and infrastructure
Engineering Highlights | 기술 하이라이트
Hybrid Search (Dense + BM25 RRF)
OpenAI text-embedding-3-small 기반 Dense와 Qdrant server-side BM25 Sparse를 RRF로 결합. 별도 BM25 서버 없이 단일 컬렉션에서 동시 인덱싱.
Re-ranker 2단계 파이프라인
Hybrid로 상위 20건 후보를 뽑고 BGE-reranker-v2-m3로 재정렬. NDCG@5를 0.52 → 0.77로 끌어올리며 이 프로젝트에서 가장 비용 대비 효율이 높은 모드.
HyDE + Multi-Query Rewriting
사용자 질의를 그대로 쓰지 않고 LLM이 만든 가상 문서(HyDE)나 여러 변형(Multi-Query)으로 검색. HyDE+Rerank 조합이 NDCG 0.82로 최상위 기록.
Agentic RAG 오케스트레이션
질의 분석 → 소스 라우팅(가족사랑카드/도서관) → 기법 선택 → relevance score 기반 fallback까지 실행 루프 구현. '언제 어떤 기법을 쓸지' 판단 계층을 분리.
relevance score 임계값 기반 fallback
Re-ranker score 0.9+/0.5~0.9/0.5 미만 구간을 '확실함/애매함/없을 가능성'으로 매핑해 재질의·데이터 없음 응답 정책을 자동화.
정량 평가셋 설계
grade 3/2/1 라벨링한 10개 질의를 직접 작성. '아이스크림 가게'처럼 데이터에 없는 질의를 일부러 포함해 '없는 걸 없다고 말하는 능력'도 평가.
Technology Stack | 기술 스택
PythonQdrant
OpenAIBM25
RRF
Re-ranking
HyDE
Multi-Query
Agentic RAG
Challenges & Solutions | 도전 과제
Technical challenges encountered during the project and solutions
1
Naive RAG의 한계 — 의미는 비슷하지만 맞지 않는 결과
Problem
Dense 임베딩 단독으로는 '동래구 목욕탕'처럼 지역·업종이 명확한 질의에서도 엉뚱한 지역 결과가 상위에 올라오는 현상이 발생했습니다.
Solution
BM25 Sparse 벡터를 추가하고 Reciprocal Rank Fusion(RRF)으로 Dense·Sparse 순위를 결합. Qdrant server-side inference를 써서 외부 인덱스 추가 없이 단일 컬렉션 내에서 구성했습니다.
Benefits
✓ 키워드 정확 매칭이 필요한 질의에서 상위 결과 품질 개선✓ Dense/Sparse 가중치 튜닝 없이 RRF로 즉시 결합 가능✓ 인프라 추가 비용 없이 Hybrid 달성
2
Hybrid만으로는 상위 정렬이 흔들리는 문제
Problem
Hybrid로 관련 문서가 후보군엔 들어왔지만, 1~3위 순위가 여전히 안정적이지 않아 사용자가 체감하는 검색 품질이 좋지 않았습니다.
Solution
Hybrid로 상위 20건을 뽑은 뒤 novita.ai의 BGE-reranker-v2-m3으로 2단계 재정렬하는 파이프라인을 구축했습니다. relevance score를 응답 신뢰도 지표로도 활용.
Benefits
✓ NDCG@5 0.52 → 0.77, Precision@5 0.66으로 최상위권 정확도 확보✓ relevance score를 fallback 트리거로 재사용 (0.5 미만 = 데이터 없음 시그널)✓ '비용 대비 효율이 가장 좋은 실용 모드'로 자리매김
3
탐색형·모호한 질의에 약한 검색기
Problem
'이번 주말에 아이들이랑 갈 만한 데'처럼 의도가 분산된 질의는 Dense·Hybrid·Rerank 어느 모드에서도 retrieval이 잘 안 됐습니다.
Solution
HyDE(LLM이 만든 가상 정답 문서로 검색)와 Multi-Query(질의 여러 변형 생성 후 합산) 두 전략을 Query Rewriting으로 도입했습니다.
Benefits
✓ HyDE+Rerank가 NDCG 0.82·MRR 0.78로 전체 1위✓ 모호한 질의에서의 recall 향상✓ Rewriting 비용이 응답 시간에 미치는 영향(2,259ms → 3,714ms)도 함께 측정
4
'언제 어떤 기법을 쓸지' 판단 부재
Problem
기법이 늘어날수록 모든 질의에 일괄 적용할 수 없었습니다. 명확한 질의에 HyDE를 쓰면 오히려 노이즈가 되고, 단일 소스 질의에 멀티 라우팅을 돌리면 불필요한 fallback이 붙었습니다.
Solution
질의 분석 → 소스 라우팅(가족사랑카드/도서관) → 기법 선택 → relevance score 기반 fallback까지 실행 루프를 오케스트레이션하는 Agentic RAG 계층을 분리했습니다.
Benefits
✓ 멀티 소스 질의(도서관+카드)에서 단일 파이프라인 대비 성능 향상✓ 데이터 없는 질의에 대해 '없음'을 명시적으로 응답 가능✓ 기법 추가를 '판단 룰 추가'로 흡수하는 구조 확보
5
수동 평가셋의 한계
Problem
10개 질의로는 통계적 유의성이 부족해 Agentic RAG의 NDCG가 Rerank보다 낮게 측정되는 등 평가셋 구성이 결과를 크게 좌우했습니다.
Solution
grade 3/2/1 라벨링 기준을 문서화하고, 데이터에 없는 질의를 일부러 포함. 향후 확장을 위해 평가 스크립트(compare.py)와 라벨 파일을 함께 버전 관리.
Benefits
✓ '없는 걸 없다고 말하는 능력'을 별도 지표 없이도 relevance score로 확인✓ 평가 기준이 재현 가능한 형태로 남아 후속 실험 시 비교 가능✓ 평가셋 설계 자체가 결과에 미치는 영향을 직접 체감
Retrospective | 프로젝트 회고
두 달간 매주 한 퀘스트씩 쌓아 Naive RAG에서 Agentic RAG까지 7단계를 직접 구현·비교했습니다. 'RAG의 품질은 retrieval에서 거의 결정된다'는 것을 숫자로 확인한 학습 프로젝트였습니다.
Successes | 잘한 점
정량 평가로 기법 간 우위 확인
HyDE+Rerank가 NDCG 0.82·MRR 0.78로 1위, Rerank가 Precision@5 0.66으로 실용 우위. '무엇이 얼마나 좋은지'를 숫자로 말할 수 있게 됨
relevance score의 실용적 활용
Re-ranker score 0.9+/0.5~0.9/0.5 미만 구간을 신뢰도 지표로 활용해 fallback 정책 설계. Agentic RAG의 핵심 로직으로 재사용
문서 품질의 중요성 체감
Quest 2에서 API 원본을 그대로 저장하지 않고 LLM 친화 포맷으로 변환한 결정이 이후 모든 단계의 검색 품질을 뒷받침
오케스트레이션 계층 분리
'어떤 검색 기법을 추가할까'(Quest 3~6)에서 '언제 어떤 기법을 쓸까'(Quest 7)로 문제의식이 이동. 기법과 판단 로직을 분리한 구조 확보
Improvements | 아쉬운 점
평가셋 규모의 한계
수동 라벨링 10개로는 통계적 결론을 내리기 부족. Agentic RAG가 멀티 소스 특화 질의 비중이 낮은 평가셋에서 불리하게 나옴
Agentic 응답 시간 트레이드오프
Agentic 모드 평균 응답 8,085ms — 다른 모드의 2~4배. '복잡한 질의에서 진가를 발휘한다'는 전제와 실제 데이터셋의 간극 확인
멀티 소스 라우팅의 확장성
키워드 휴리스틱 기반 소스 라우팅은 2개에선 동작하지만 5~10개로 늘면 한계 명확. '소스 선택 자체도 RAG로 풀어야 한다'는 숙제
Future Directions | 향후 방향
1
평가셋 50~100개 이상으로 확장 (LLM-as-a-judge 병행)
2
Text-to-SQL 에이전트 + RAG 결합으로 정형/비정형 동시 질의 처리
3
소스 라우팅 자체를 LLM/임베딩 기반으로 일반화
4
멀티 소스 특화 질의 비중을 높인 공정한 평가셋 설계