RAG를 운영하다 보면 “좋아졌다"는 느낌만으로는 개선을 끝낼 수 없습니다. 어떤 변경이 검색 품질을 바꿨는지, 어떤 설정이 답변 품질을 흔드는지, 어떤 실험이 재현 가능한지까지 봐야 합니다.
이 글은 RAG 실험 설계를 시작하는 팀을 위한 실무 가이드입니다. 실험 단위를 어떻게 쪼갤지, 오프라인과 온라인을 어떻게 나눌지, 어떤 문서를 남겨야 나중에 회고가 쉬운지 정리합니다.
왜 중요한가 #
RAG는 검색, 재랭킹, 프롬프트, 모델, 캐시가 모두 얽혀 있습니다. 그래서 하나를 바꾸면 다른 부분의 결과가 같이 바뀌기 쉽습니다. 실험 설계가 없으면 원인과 결과를 분리하기 어렵고, 개선이 아니라 우연한 흔들림을 학습하게 됩니다.
실험 설계는 팀의 합의 장치이기도 합니다. 무엇을 바꿨는지, 무엇을 고정했는지, 무엇을 성공으로 볼지 정해 두면 회의가 줄고 결론이 빨라집니다.
실험 설계 #
실험은 크게 세 층으로 나누는 편이 안정적입니다.
- 검색 층: chunking, embedding model, hybrid search, reranking, query rewriting
- 답변 층: system prompt, context window, tool calling, output format
- 운영 층: cache, monitoring, alerts, fallback, cost control
한 번에 여러 변수를 바꾸면 해석이 어려워집니다. 처음에는 한 번에 하나만 바꾸는 단일 변수 실험으로 시작하고, 이후에 조합 실험으로 넘어가는 편이 좋습니다.
아키텍처 도식 #
실험 구조는 보통 아래 순서로 움직입니다.
- baseline 트래픽 또는 고정 평가셋 준비
- 후보 변경안 정의
- 오프라인 평가 실행
- 작은 온라인 샘플로 검증
- 결과 기록 및 다음 실험으로 이관
이 흐름을 유지하면 실험이 쌓여도 지식이 흩어지지 않습니다.
체크리스트 #
- 실험 가설이 한 문장으로 설명되는가
- 변경한 변수와 고정한 변수가 분리되는가
- 성공 지표와 실패 기준이 모두 있는가
- 오프라인 평가와 온라인 검증이 둘 다 있는가
- 결과가 재현 가능한 형태로 기록되는가
결론 #
RAG 실험 설계의 핵심은 복잡한 시스템을 단순한 비교 구조로 바꾸는 데 있습니다. 가설, 변수, 지표, 기록이 분리되면 팀은 빠르게 배우고 덜 혼동합니다.