05. 드리프트와 이상 감지, AI QA 전략¶
AI QA 전략은 데이터 검증, 모델 평가, API 응답, 운영 로그로 이어진 근거를 배포 승인, 조건부 보류, 추가 확인 판단으로 연결하는 흐름입니다. 5장의 목적은 high_risk 예측 비율 증가 운영 시나리오에서 이상 징후를 발견했다는 사실이 아니라, 왜 지금 승인할 수 없고 어떤 조건을 만족하면 재평가할 수 있는지 근거로 설명하는 것입니다.
운영 로그와 대시보드에서는 오류, 지연 시간, 점수 분포, 예측 분포 변화가 함께 나타났습니다. 하지만 이상 신호를 발견했다는 사실만으로 배포 승인이나 보류를 결정할 수는 없습니다. 이번 장에서는 이 근거를 current batch 입력 구성 변화 리포트, 원인 후보 추적, 회귀 테스트, 승인 기준으로 묶습니다.
| 기준 | 내용 |
|---|---|
| 맡는 일 | 이상 징후와 회귀 테스트 결과를 근거로 배포 승인, 조건부 보류, 추가 확인을 판단 |
| 이번 장의 상황 | 기능 테스트는 통과했지만 current batch 입력 구성 변화와 운영 품질 기준 때문에 바로 승인하기 어려움 |
| 확인 증거 | 입력 구성 변화 리포트, 예측 변화 리포트, 품질 이슈 추적 결과, 회귀 테스트, 승인 기준 |
| 판단 산출물 | 배포 승인 리포트와 AI QA 체크리스트 |
1. 공통 운영 시나리오 적용¶
공통 운영 시나리오 high_risk_prediction_shift는 5장에서 release gate 판단으로 정리됩니다. 이 장은 원인을 하나로 확정하는 단계가 아니라, 현재 증거로 바로 승인할 수 있는지, 보류한다면 어떤 owner가 어떤 evidence path를 확인한 뒤 재평가할지 정하는 단계입니다.
| 항목 | 5장에서의 적용 |
|---|---|
| 이번 장의 역할 | 앞 장의 증거를 release gate 판단과 재평가 조건으로 묶음 |
| 새로 확인하는 증거 | drift_report.md, quality_issue_trace.md, release_approval.md, ai_qa_checklist.md |
| 후보 상태 변화 | 기능 테스트 통과만으로 바로 승인할 수 있다는 후보를 약화함 |
| 보고서 문장 | 운영 품질 기준 일부 미충족과 미검증 live evidence 때문에 조건부 보류하고, owner 확인 후 같은 approval rule로 재평가합니다 |
| 재평가 조건 | owner별 next action 완료 후 같은 approval rule로 다시 판단 |
2. 이번 장에서 다룰 배포 판단 상황¶
배포 판단 사건은 기능 테스트를 통과한 후보를 운영 품질 근거로 다시 보는 상황입니다. 입력 분포가 기준선(baseline)과 달라지고, 점수 분포(score distribution)와 예측 분포(prediction distribution)가 함께 움직였으며, 일부 요청에서는 검증 실패(validation failure)가 늘었습니다.
운영 관측: 점수와 예측 분포 변화 확인
→ 입력 구성 변화 확인: 입력 특성 분포 변화 확인
→ 품질 이슈 추적: input case-mix shift, prediction_shift, api_validation 확인
→ 승인 기준 적용: recall, error_rate 실패
→ 최종 판단: 조건부 보류와 재평가 조건 판단
이 사건의 핵심은 이상 징후를 발견하는 데서 끝내지 않고, 승인 기준으로 결론을 남기는 것입니다. current batch 입력 구성 변화와 예측 분포 변화는 원인 후보를 좁히는 근거이고, 회귀 테스트와 승인 기준은 그 후보를 배포 판단으로 바꾸는 기준입니다.
3. AI QA 전략의 역할¶
AI QA 전략의 역할은 앞에서 확인한 데이터, 모델, 서빙, 운영 관측 정보를 배포 판단 기준으로 묶는 것입니다. 입력 구성 변화와 이상 징후는 단순 경고가 아니라 배포 승인, 조건부 보류, 추가 확인으로 이어지는 판단 근거가 되어야 합니다.
학습 초점은 모델 지표 향상이 아니라 품질 회귀(regression)를 설명하고 통제하는 데 있습니다. 여기서 회귀(regression)는 회귀 모델(regression model)이 아니라, 변경 이후 품질 기준이 이전보다 후퇴한 상태를 뜻합니다. 입력 분포 변화, 점수(score) 분포 변화, 예측(prediction) 분포 변화, 임계값(threshold) 기준, 운영 로그를 함께 보고 최종 QA 체크리스트로 정리합니다.
4. 핵심 기준¶
핵심 기준은 이상 징후를 발견하는 것에서 끝내지 않고, 어떤 조치를 해야 하는지 설명하기 위한 판단 기준입니다.
| 확인 관점 | 핵심 질문 |
|---|---|
| 입력 구성 변화 | 현재 운영 입력 샘플이 기준선과 달라졌는가 |
| 예측 분포 변화 | 점수와 예측 분포가 함께 변했는가 |
| 원인 추적 | 데이터 품질, 모델 버전, 임계값, API 설정 중 어디를 확인해야 하는가 |
| 회귀 테스트 | 변경 후 품질 기준을 만족하는가 |
| 승인 기준 | 배포 승인, 조건부 보류, 추가 확인 조건을 설명할 수 있는가 |
5. 학습 흐름¶
학습 흐름은 관측된 이상 신호를 최종 판단 문장으로 바꾸는 순서입니다.
입력 데이터 분포 변화 확인
→ 점수/예측 분포 변화 확인
→ 운영 이상 징후 원인 추적
→ 품질 회귀 테스트 기준 정의
→ 테스트 데이터 설계
→ 배포 승인/조건부 보류 기준 정리
→ AI QA 체크리스트 작성
6. 산출물과 확인 기준¶
최종 QA 판단 문서는 핵심 산출물입니다. 각 산출물은 이상 징후를 발견하고, 원인 후보를 좁히고, 배포 여부를 설명하기 위한 근거입니다. Lab 산출물은 uv run --group lab python labs/ch05_qa_strategy/build_qa_artifacts.py로 만들 수 있고, 시간이 부족하면 아래 준비된 리포트에서 같은 값을 확인합니다.
승인 기준은 configs/qa_strategy/approval_rules.yaml에 있는 값으로 확인합니다. 예시 기준은 minimum_precision: 0.6, minimum_recall: 0.6, maximum_error_rate: 0.05, maximum_latency_average_ms: 250입니다. 준비된 artifacts/reports/release_approval.md에서는 approved=False와 failed_checks=('recall', 'error_rate')가 남고, 실제 관측값은 Precision 1.0000 >= 0.6000, Recall 0.5926 < 0.6000, error rate 0.0667 > 0.0500입니다. prepared_api_contract=True는 로컬 또는 준비된 계약 증거가 통과했다는 뜻이고, live /health, /predict, Pod readiness, 응답 model_version, threshold 증거는 live_deployment 미검증 리스크로 따로 남깁니다.
| 산출물 | 실행 또는 확인 경로 | 보고서에 남길 필드 | 판단에 쓰는 방식 |
|---|---|---|---|
| 입력 구성 변화 리포트 | artifacts/reports/drift_report.md |
heart_rate +10.4917, oxygen_saturation -1.4698, high_risk_rate_delta 0.2417 |
current batch 입력 분포 변화가 예측 변화와 함께 움직였는지 확인 |
| 라벨 기준 확인 | artifacts/reports/label_basis_check.md |
allowed_labels, invalid_count=0, missing_count=0, high_risk=37, low_risk=33 |
라벨 값 기준이 뒤집혔다는 후보를 약화하거나, 평가 제한 사항을 표시 |
| 예측 변화 리포트 | artifacts/reports/drift_report.md와 5-2 문서 |
점수 평균 변화, high_risk 비율 변화, 기준선 대비 차이 |
특정 클래스 예측 급증이 우연한 변화인지 판단 |
| 품질 이슈 추적 결과 | artifacts/reports/quality_issue_trace.md |
input_case_mix_shift, prediction_shift, api_validation, service_latency, owner, audit reference, 다음 조치 |
input_case_mix_shift를 current batch 입력 구성 변화 후보로 해석하고 배포 판단 전에 정리 |
| 배포 승인 리포트 | artifacts/reports/release_approval.md |
approved=False, precision 1.0000 >= 0.6000, recall 0.5926 < 0.6000, error_rate 0.0667 > 0.0500, live_deployment=unverified |
승인보다 조건부 보류와 추가 확인이 적절한지 판단 |
| AI QA 체크리스트 | artifacts/reports/ai_qa_checklist.md |
status=hold, 실패 항목, 미검증 항목, 담당자, 다음 조치 |
같은 사건을 이후 릴리스에도 반복 적용 |
5장의 보고서는 단순 요약이 아니라 의사결정 문서입니다. 현재 예시에서는 라벨 기준은 유지되는 것으로 확인되지만, current batch 입력 구성 변화와 운영 이상 후보가 남아 있고 승인 기준 중 Recall과 error rate가 실패했습니다. live deployment 증거도 준비된 로컬 계약 증거와 분리해 미검증 상태로 남아 있으므로, 최종 문장은 “배포를 승인하지 않고 실패 기준 검토, 입력 분포 원인 확인, live smoke evidence 확보를 완료한 뒤 재평가합니다”에 가까워야 합니다. 이때 승인 보류는 무료 결정이 아니므로, 릴리스 지연 리스크도 함께 남기고 어떤 owner가 어떤 audit reference를 확인하면 재평가할 수 있는지 적어야 합니다.
7. 문서 목록¶
문서 목록은 이상 신호를 배포 판단과 QA 체크리스트로 정리하는 순서입니다.
| 순서 | 문서 | 확인할 내용 |
|---|---|---|
| 1 | 입력 데이터 분포 변화 확인 | 입력 분포, 히스토그램(histogram), 평균값 변화, 이상 징후 해석 |
| 2 | 점수와 예측 분포 분석 | 점수 분포, 예측 분포, 특정 클래스 예측 급증 |
| 3 | 운영 이상 징후 탐지와 원인 추적 | 정상/이상 상태 비교, 지표 변화, 로그 기반 원인 추적 |
| 4 | AI 품질 회귀 테스트 전략 | 데이터셋, 특성(feature), 라벨(label), 모델 버전(model_version), 임계값 변경 검증 |
| 5 | 테스트 데이터 설계 전략 | 정상 입력, 오류 입력, 경계값, 클래스 불균형 평가 데이터 |
| 6 | 배포 승인과 운영 전환 기준 | 지표 기준, API 계약, 운영 준비, 배포 전후 비교 |
| 7 | 실제 장애 사례 분석 | 데이터 품질, 드리프트, 모델 버전, 임계값 설정 오류 사례 |
| 8 | AI QA 체크리스트 정리 | 데이터, 모델, 임계값, 운영 품질 체크리스트 |
| 9 | 5장 마무리 | 최종 산출물의 형태 |
| 10 | 전체 참고문헌 | 출처와 추가 학습 자료 |