CI/CD에서 회귀(Regression)를 방지하기 위한 RAG 평가 설정 방법

PR이 올라옵니다. RAG 평가가 1분 만에 실행됩니다. 초록색 체크 표시가 뜹니다. 코드를 머지합니다.

12시간 후, 고객 지원 티켓이 들어옵니다.

특정 쿼리 유형에 대해 리트리버(retriever)가 top-1 청크를 변경했습니다. 여러분의 30개 예시 데이터셋은 해당 케이스를 전혀 포함하지 않았습니다. 테스트 스위트는 잘못된 항목을 체크하고 있었기 때문에 계속 초록색을 유지했습니다.

대부분의 RAG 게이트(gate)는 단순한 스모크 테스트(smoke test)에 불과합니다. 작은 데이터셋과 고정된 하한선(floor)을 사용하죠. 평균값이 특정 수치 이상이면 통과됩니다. 하지만 데이터셋이 대표성을 띠지 못하고 임계값(threshold)이 노이즈를 고려하지 않기 때문에 이 방식은 실패합니다.

좋은 게이트에는 세 가지 요소가 필요합니다: 속도, 낮은 비용, 그리고 통계적 유의성입니다. 보통 이 중 두 가지만 충족하기 마련입니다.

여기 신뢰할 수 있는 RAG 게이트를 위한 저의 프레임워크를 소개합니다.

3단계 구조

  1. 모든 푸시 (PR 게이트)
  1. 야간 메인 빌드 (전체 스윕)
  1. 카나리 (운영 모니터링)

5가지 핵심 루브릭

시스템이 정확히 어디에서 고장 나는지 찾으려면, 레이어별로 루브릭을 나누어야 합니다:

참고: 검색 재현율을 점수화하려면 반드시 정답 문서 ID(expected_chunks)를 사용해야 합니다. 이것 없이는 검색 버그를 찾아낼 수 없습니다.

통계적 게이트

단순히 고정된 수치로 게이트를 설정하지 마세요. 고정된 하한선은 느린 드리프트(drift)를 놓칩니다. 두 가지 임계값을 사용하세요:

Welch의 t-검정(t-test)과 같은 통계적 테스트를 사용하세요. 하락폭이 통계적으로 유의미하고 무시할 수 없을 만큼 클 때만 PR을 실패 처리합니다. 이렇게 하면 개발자들이 오탐(false alarm) 때문에 게이트를 무시하는 것을 방지할 수 있습니다.

가장 중요한 규칙

베이스라인은 고정된 수치가 아니라, 지속적으로 업데이트되는 롤링 운영 윈도우(rolling production window)여야 합니다.

운영 데이터가 변경되면 데이터셋도 함께 변경되어야 합니다. 실패한 운영 트레이스를 수집하여 클러스터링하고, 이를 평가 세트(eval set)로 승격시키십시오. 이렇게 하면 여러분의 게이트는 하나의 학습 시스템으로 변모합니다.

출처: https://dev.to/kartik-nvjk/how-i-set-up-rag-evals-in-cicd-so-they-actually-catch-regressions-46hb

선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi