Eval-Gated AI 릴리스: 검색 품질을 단위 테스트처럼 다루기
요약
RAG 시스템의 품질을 단위 테스트처럼 관리하기 위해 평가(evals)를 CI/CD 파이프라인에 통합하는 방법을 소개합니다. 절대적 하한선과 회귀 대역을 설정하고, 결정론적인 카세트 재생 방식을 통해 비용과 품질을 공학적으로 제어하는 전략을 다룹니다.
핵심 포인트
- 품질 및 비용 회귀 발생 시 병합을 차단하는 평가 게이트 구축
- 엄격한 기준 대신 바닥값(Floors)과 회귀 대역(Regression bands) 활용
- CI 환경을 위해 GPU를 사용하지 않는 결정론적 카세트 재생 방식 채택
- 비용을 대시보드가 아닌 빌드 실패를 결정하는 핵심 메트릭으로 관리
어떤 백엔드 팀도 테스트 스위트를 통과하지 못한 PR(Pull Request)은 병합(merge)하지 않습니다. 하지만 많은 AI 팀들은 자동화된 품질 검사 없이 프롬프트와 모델 변경 사항을 배포하며, 몇 가지 응답만 눈으로 확인하고 기대를 걸 뿐입니다. 실패 양상은 조용합니다: 답변의 충실도가 약간 떨어지고, 인용 출처가 흐트러지며, 사용자가 알아차리기 전까지는 아무도 눈치채지 못합니다.
Atlas(저의 엔터프라이즈 RAG 코파일럿 프로젝트)는 평가(evals)를 테스트와 정확히 동일하게 다룹니다: 품질 또는 비용 회귀가 발생하면 병합이 차단됩니다. 여기에 파이프라인의 구조와 제가 이를 구축하며 배운 점을 소개합니다.
빌드를 제어하는 요소 (What gates the build)
모든 PR은 커밋된 카세트(cassettes)에 대해 오프라인적이고 결정론적이며 GPU를 사용하지 않는 평가 게이트를 실행합니다:
| Metric | Baseline | Floor | Policy |
|---|---|---|---|
| RAGAS faithfulness | 0.706 | 0.656 | blocking, regression band 0.05 |
| ... | |||
| 세 가지 설계 결정으로 이것이 가능해졌습니다: |
1. 완벽함이 아닌 바닥값(Floors) + 회귀 대역(regression bands). '충실도 ≥ 0.9'와 같은 엄격한 게이트는 영원히 모든 병합을 차단했을 것입니다. 대신, 절대적인 바닥값(이 이하로는 절대 배포하지 않음)과 커밋된 기준선 대비 상대적인 회귀 대역(의미 있게 나빠지지 않도록 함)을 사용합니다. 이는 코드 커버리지를 점진적으로 늘리는 것(ratcheting code coverage)의 평가 버전입니다.
2. CI에서 결정론적이고 GPU를 사용하지 않는 방식. CI 환경에서의 실시간 모델 평가는 느리고, 비용이 많이 들며, 불안정합니다. Atlas는 기록된 모델 상호작용인 커밋된 카세트를 재생(replays)하여 게이트가 빠르고 재현 가능하도록 만듭니다. 행동이 변경될 것으로 예상되는 경우에만 의도적으로 카세트가 다시 기록되며, 이는 '모델이 변경되었다'라는 상황을 주변적인 놀라움 대신 검토된 차분(diff)으로 바꿉니다.
3. 비용은 대시보드가 아닌 게이트 메트릭이다. 토큰 사용량을 두 배로 늘리는 프롬프트 변경이라도 품질이 유지된다면 회귀가 아닙니다. Atlas의 비용 게이트는 측정된 비용 절감액을 커밋된 기준선과 비교하여 주장하고, 비용이 대역 이하로 회귀하면 빌드를 실패시킵니다. 이는 p95 지연 시간(p95-latency) 예산이 백엔드 서비스를 제어하는 방식과 동일합니다.
이 게이트(gate)의 진가는 제가 인용 형식(citation formatting)을 위한 QLoRA 어댑터를 미세 조정(fine-tuning)했을 때 증명되었습니다. 벤치마크(paired bootstrap, McNemar) 결과는 다음과 같았습니다: 인용 형식 유효성(citation format validity) 0.00 → 0.955 (p ≈ 0), 동일 GPU 기준 서빙 비용(serving cost) -79% 감소 — 그리고 충실도(faithfulness) 트레이드오프(trade-off)는 -0.10이었으나 여전히 하한선(floor)을 상회했습니다. 프로모션 게이트(promotion gate)는 해당 결정을 명시적으로 내릴 수 있는 데이터를 보유하고 있었으며, 이 파이프라인은 CI(지속적 통합) 환경에서 후보 모델을 승격시키거나 차단하는 능력이 모두 입증되었습니다.
평가(evals)가 없다면 그것은 '느낌(vibes)'에 의존하는 결정입니다. 하지만 평가가 있다면, 그것은 기록(paper trail)이 남는 공학적 결정이 됩니다.
시작하는 방법 (생각보다 간단합니다)
첫날부터 RAGAS를 도입할 필요는 없습니다. 다음부터 시작하세요:
- **20~30개의 골든 질문(golden questions)**과 예상되는 소스 문서 — 즉, 여러분의 검색 적중률(retrieval hit-rate) 스위트(suite)를 만드세요.
- 몇 가지 적대적 프롬프트(adversarial prompts) (주입 시도(injection attempts), 범위를 벗어난 질문(out-of-scope questions))와 예상되는 거절 응답을 준비하세요.
- **둘 중 하나라도 회귀(regress)할 경우 실패하는 CI 작업(CI job)**을 구축하세요.
이는 반나절 정도의 작업량이며, 즉각적으로 문화를 변화시킵니다: 프롬프트는 코드가 되고, 모델 교체는 검토(review) 대상이 되며, "우리가 더 나빠졌나요?"라는 질문에 답을 할 수 있게 됩니다.
백엔드 엔지니어링은 20년 전에 이미 이 문제를 해결했습니다. 우리는 그것을 단지 테스트(testing)라고 불렀을 뿐입니다. AI 시스템에는 새로운 철학이 필요한 것이 아니라, 기존의 철학을 적용하는 것이 필요합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기