5-4. AI 품질 회귀 테스트 전략 [Core]¶
AI 품질 회귀 테스트는 변경 이후 품질 기준이 이전보다 후퇴했는지 확인하는 활동입니다. 입력 분포 변화, 예측(prediction) 분포 변화, 검증 실패(validation failure), 지연 시간(latency)이 원인 후보로 남았다면, 이 문서에서는 그 후보를 비교 가능한 테스트 기준으로 정리합니다.
회귀 테스트의 핵심은 “새 배포가 기준을 벗어났는가”를 묻기 전에, 무엇을 고정하고 무엇을 바꾸어 비교했는지 먼저 밝히는 것입니다. 데이터셋, 특성(feature), 라벨(label), 모델 버전(model_version), 임계값(threshold), API 설정이 섞여 바뀌면 지표(metric) 변화의 원인을 설명하기 어렵습니다.
이 문서를 읽을 때는 다음 기준을 중심으로 확인합니다.
| 확인 기준 | 핵심 질문 |
|---|---|
| 변경 조건 분리 | 데이터, 모델, 임계값, API 설정 중 무엇이 바뀌었는가 |
| 지표 비교 | 정확도(Accuracy) 외에 정밀도(Precision), 재현율(Recall), FP/FN이 어떻게 달라졌는가 |
| 운영 연결 | API 계약(contract), 오류율(error rate), 지연 시간도 기준을 벗어났는가 |
| 다음 판단 | 회귀가 있으면 즉시 보류인지, 제한 사항을 남긴 추가 확인인지 설명할 수 있는가 |
5-4-1. 품질 회귀란 무엇인가¶
품질 회귀는 코드가 정상 동작하더라도 품질 지표가 이전 기준보다 후퇴하는 상황입니다. 일반 소프트웨어 회귀가 기능 동작의 깨짐을 주로 본다면, AI 품질 회귀는 데이터, 모델, 임계값, 운영 설정 변경이 품질 지표에 미치는 영향을 함께 봅니다.
품질 회귀는 배포 직후에만 발생하지 않습니다. 데이터 수집 방식이 바뀌거나, 운영 입력 분포가 바뀌거나, 임계값이 조정되거나, 모델 버전이 바뀌면 언제든 발생할 수 있습니다.
5-3 Lab의 출력처럼 평균 점수(score)가 올라가고 high_risk 예측 비율이 증가했으며 오류율과 지연 시간도 함께 증가했다면, 하나의 원인만으로 설명하기 어렵습니다. 회귀 테스트는 이런 상황에서 비교 조건을 나누어 “데이터 조건 때문인지, 모델 산출물 때문인지, 운영 설정 때문인지”를 확인합니다.
| 변경 조건 | 먼저 고정하거나 확인할 것 | 지표에서 볼 영향 |
|---|---|---|
| 데이터셋(dataset) 변경 | 행(row) 수, 클래스(class) 비율, 관심 클래스(Positive class) 표본 수, 결측과 이상 비율 | 지표 전체 흔들림 |
| 특성 변경 | 입력 스키마(schema), 전처리 방식, 파생 특성 정의 | 점수 분포 변화 |
| 라벨 기준 변경 | 관심 클래스와 비교 클래스(Negative class) 기준 | 정밀도, 재현율, FP/FN 해석 변화 |
| 모델 버전 변경 | 같은 평가 데이터와 같은 임계값 사용 여부 | 점수 분포와 지표 변화 |
| 임계값 변경 | 승인된 운영 설정과 로그 기록 일치 여부 | 예측 분포와 FP/FN 균형 변화 |
QA 관점에서는 회귀가 “있다/없다”보다 비교 조건이 설명 가능한지가 먼저입니다. 비교 조건이 맞지 않으면 지표가 낮아져도 실제 회귀인지, 평가 조건 변화인지 구분하기 어렵습니다.
5-4-2. 데이터셋, 특성, 라벨 변경 영향 분석¶
데이터 조건이 바뀌면 같은 모델도 다른 지표를 만들 수 있습니다. 새 데이터셋에서 재현율이 낮아졌다고 해서 바로 모델 자체 문제라고 말할 수는 없습니다. 관심 클래스 표본 수가 줄었거나, 라벨 기준이 바뀌었거나, 운영 입력과 다른 데이터가 평가에 섞였을 수 있기 때문입니다.
특성은 모델이 입력으로 받는 값입니다. 학습 때 사용한 특성과 API가 실제로 받는 특성이 다르면 학습-서빙 불일치(Train-Serving Skew)가 생길 수 있습니다. 예를 들어 학습에는 oxygen_saturation이 있었지만 API 응답 분석에서는 이 값이 누락되거나 다른 전처리 기준으로 들어온다면, 모델 버전이 같아도 점수 분포가 달라질 수 있습니다.
라벨은 평가에서 정답으로 쓰는 값입니다. 관심 클래스는 놓치지 않고 찾고 싶은 클래스이고, 이 교재에서는 high_risk입니다. 비교 클래스는 low_risk입니다. 이 기준이 바뀌면 FP/FN과 정밀도, 재현율의 의미도 함께 바뀌므로 이전 결과와 직접 비교하기 어렵습니다.
데이터 조건을 확인할 때는 다음 항목을 먼저 봅니다. 이 기준이 정리되어야 평가 데이터가 바뀐 것인지, 모델이나 운영 기준이 바뀐 것인지 분리할 수 있습니다.
| 변경 항목 | QA 확인 | 회귀 테스트에서의 해석 |
|---|---|---|
| 데이터셋 버전(dataset version) | 행 수, 클래스 비율, 관심 클래스 표본 수 | 평가에 포함된 샘플(sample) 구성이 달라져 지표가 흔들렸는지 확인 |
| 특성 집합(feature set) | 추가된 특성, 삭제된 특성, 파생 특성 정의 | 모델 입력 조건이 달라졌는지 확인 |
| 라벨 기준 | 허용 라벨, high_risk와 low_risk의 라벨 값 표준화 기준 |
FP/FN 해석 기준이 유지되는지 확인 |
| 전처리(preprocessing) | 결측값 처리, 스케일링(scaling), 인코딩(encoding) | 학습과 평가, 서빙의 입력 변환이 같은지 확인 |
QA 코멘트에는 “지표 하락”만 쓰지 않습니다. “평가 데이터의 high_risk 표본 수가 줄어 재현율 변동성이 커졌다”처럼 지표 변화와 데이터 조건을 함께 적어야 합니다.
5-4-3. 모델 버전과 임계값 변경 검증¶
모델 버전 변경은 점수 분포(score distribution)를 바꿀 수 있고, 임계값 변경은 예측 분포(prediction distribution)를 바꿀 수 있습니다. 두 변경이 동시에 일어나면 원인 분리가 어렵습니다.
점수는 모델이 만든 관심 클래스 가능성이고, 임계값은 그 점수를 최종 예측으로 바꾸는 기준입니다. 모델 버전이 바뀌면 점수 자체가 달라질 수 있고, 임계값만 바뀌면 같은 점수도 다른 클래스로 바뀔 수 있습니다.
QA는 가능하면 모델 버전 변경과 임계값 변경을 분리해서 검증해야 합니다. 새 모델을 같은 임계값으로 평가하고, 그다음 임계값 후보를 비교하면 “모델 변화”와 “운영 기준 변화”를 나누어 볼 수 있습니다.
| 비교 방식 | 고정하는 조건 | 해석 |
|---|---|---|
| 같은 모델(model), 다른 임계값 | 모델 버전, 평가 데이터 | 임계값 영향 분석 |
| 다른 모델(model), 같은 임계값 | 평가 데이터, 임계값 | 모델 버전 영향 분석 |
| 다른 모델(model), 다른 임계값 | 없음 또는 제한적 | 원인 분리가 어려워 추가 비교 필요 |
같은 예측 비율 증가도 점수 변화와 임계값 변화 중 무엇이 동반되었는지에 따라 해석이 달라집니다. 예를 들어 high_risk 예측 비율이 증가했을 때, 점수 분포도 함께 오른 경우와 임계값만 낮아진 경우는 해석이 다릅니다. 전자는 입력 특성, 데이터 분포, 모델 버전을 확인해야 하고, 후자는 승인된 운영 기준과 실제 배포 설정이 일치하는지 먼저 확인해야 합니다.
5-4-4. 지표 기준과 승인 조건 정의¶
품질 회귀 테스트는 단순히 정확도를 비교하는 작업이 아닙니다. 모델이 어떤 오류를 더 많이 만들었는지, 그 오류가 서비스 정책상 허용 가능한지를 함께 봐야 합니다.
승인 조건은 지표 기준, API 계약, 운영 지표를 함께 포함해야 합니다. 예를 들어 재현율이 높아졌지만 오류율이 증가하거나 API 계약이 깨졌다면 바로 승인하기 어렵습니다. 반대로 일부 모델 지표가 기준선보다 낮아졌더라도 영향 범위가 작고 원인이 설명되며 운영 감시 기준이 준비되어 있다면 추가 확인 조건을 붙여 판단할 수 있습니다.
승인 판단 실습에서는 configs/qa_strategy/approval_rules.yaml에 최소 정밀도, 최소 재현율, 최대 오류율, 최대 평균 지연 시간(average latency)을 둡니다. 이 설정은 회귀 테스트 결과를 “통과/실패”가 아니라 승인, 보류, 추가 확인 판단으로 바꾸기 위한 기준입니다.
| 기준 | 예시 | 회귀 테스트에서의 판단 |
|---|---|---|
| 모델 지표 | 정밀도, 재현율, PR-AUC 최소 기준 | 이전 기준보다 낮아졌는지 확인 |
| 오류 유형 | FP/FN 허용 범위 | 놓치면 안 되는 오류가 증가했는지 확인 |
| API 계약 | 입력 스키마와 오류 응답 통과 | 모델 지표와 별개로 서비스 계약이 유지되는지 확인 |
| 운영 지표 | 오류율, 지연 시간 기준 | 배포 후 사용자 경험이나 안정성 기준을 벗어났는지 확인 |
| 추적 가능성 | request_id, model_version, threshold 로그 기록 |
문제가 생겼을 때 요청과 설정을 추적할 수 있는지 확인 |
회귀 테스트의 결론은 “모델 승인” 하나로 끝나지 않습니다. 어떤 조건에서 비교했고, 어떤 지표가 기준을 넘지 못했으며, 배포 판단에서 어떤 실패 항목을 근거로 삼을지 남기는 것이 핵심입니다.