Retrieval A/B Testing은 RAG의 검색 전략을 비교할 때 가장 직관적인 방법입니다. 같은 질문에 대해 서로 다른 검색 경로를 붙이고, 결과를 정량과 정성으로 함께 비교합니다.
핵심은 “무엇이 더 좋아졌는가"보다 “어떤 조건에서 더 좋아졌는가"를 보는 것입니다. 이 차이를 잡아야 운영 중에 안전하게 롤아웃할 수 있습니다.
왜 중요한가 #
검색 계층은 RAG 품질의 절반 이상을 좌우합니다. query rewriting, hybrid search, reranking, chunking 변경은 모두 결과를 바꿉니다. A/B 테스트 없이 바꾸면 개선인지 퇴화인지 판단하기 어렵습니다.
실험 설계 #
실무에서는 다음 조합이 가장 자주 사용됩니다.
- baseline: 현재 운영 중인 검색 전략
- candidate: chunking 또는 retrieval strategy를 바꾼 버전
- evaluation set: 대표 질문, 쉬운 질문, 실패 질문을 함께 포함
- metric set: retrieval metrics, answer quality, latency, cost
실험 단위는 작게 잡는 편이 좋습니다. 한 번에 search pipeline 전체를 바꾸기보다, query rewriting만 바꾸거나 reranking만 바꾸는 식으로 범위를 줄이면 해석이 선명해집니다.
아키텍처 도식 #
A/B 테스트 파이프라인은 보통 다음으로 구성됩니다.
- 요청 샘플링
- baseline/candidate 분기
- 오프라인 metric 계산
- 온라인 로그 수집
- 승패 판단 및 롤아웃
체크리스트 #
- 비교 대상이 하나의 변수만 다르게 유지되는가
- 동일한 평가셋으로 반복 실행 가능한가
- 승패 기준이 사전에 정해져 있는가
- 지표가 latency와 quality를 함께 포함하는가
- 실패 케이스를 회고 문서로 남기는가
결론 #
Retrieval A/B Testing은 검색 전략을 감으로 바꾸지 않게 해줍니다. 작은 비교를 빠르게 반복하면, RAG 개선은 더 예측 가능해집니다.