매주 RAG 디버깅에 막혔는데, 알고 보니 트레이드오프를 이해하지 못했던 거였네요.
I got stuck debugging RAG every week. Turns out I just didn't understand the tradeoffs.
핵심 요약
RAG 구현 시 발생하는 다양한 문제의 원인을 파악하고, 9가지 RAG 방식을 비교 테스트할 수 있는 도구를 개발해 공유함.
- RAG 디버깅 — 할루시네이션과 성능 문제로 매주 고생하던 경험을 공유함.
- 트레이드오프 분석 — Naive, Hybrid, Rerank 등 각 RAG 방식의 장단점과 실패 유형을 파악함.
- 비교 테스트 도구 — Streamlit 기반으로 9가지 RAG 방식을 한 번에 테스트할 수 있는 툴을 제작함.
- 오픈소스 공유 — 코드와 로컬 실행 방법을 GitHub 저장소에 공개함.
문제: RAG 관련 이슈(할루시네이션, 느린 검색, 관련 없는 청크)가 발생할 때마다 구글링을 하면 10가지 다른 해결책이 나옵니다. Hybrid RAG, Rerank RAG, Self-Reflective RAG 등 모두가 정답이라고 주장하죠.
하지만 제 데이터에서 왜 하나가 다른 것보다 더 나은지 알려주는 사람은 아무도 없었습니다.
그래서 게으른 엔지니어가 늘 그렇듯, 각 방식을 수동으로 구현하는 대신 9가지 변형을 나란히 테스트할 수 있는 도구를 만들었습니다.
배운 점:
Naive RAG는 긴 문서에서 할루시네이션을 일으킵니다. Hybrid RAG는 빠르지만 정확도가 떨어집니다. Rerank RAG는 느리지만 Naive가 놓치는 것을 잡아냅니다. Corrective RAG는 신뢰도를 평가합니다. Self-Reflective RAG는 스스로 답을 검증합니다.
각 방식은 서로 다른 실패 모드를 가지고 있습니다. '최고'를 고를 수는 없습니다. 그저 내가 감당할 수 있는 방식으로 실패하는 것을 고르는 것뿐이죠.
도구:
그냥 Streamlit 앱입니다. 문서를 업로드하고 질문을 던지면, 각 RAG 유형이 무엇을 검색하고 얼마나 빨리 답변하는지 볼 수 있습니다. 어떤 게 필요한지 파악하는 데 2분이면 충분합니다.
별거 없습니다. Python, FAISS, BM25, LangChain을 사용했습니다.
RAG를 구축 중이라면 아마 이 벽에 부딪혔을 겁니다. 댓글로 트레이드오프에 대해 자유롭게 토론해 보죠.
저장소: https://github.com/AnkitSingh36/rag-universe (코드를 보거나 로컬에서 실행해보고 싶다면 확인하세요)
