콘텐츠로 이동

승인 조건과 후보 비교

기존 운영 모델의 예측 비율 증가에 대응할 후보로 Candidate A와 Candidate B가 준비되어 있습니다. 두 후보 가운데 하나를 고르려면 현재 운영 신호가 아니라, 같은 평가 조건에서 계산한 품질 지표와 미리 정한 배포 기준을 비교해야 합니다.

Candidate A의 정밀도는 더 높은데도 HOLD이고 Candidate B는 APPROVE입니다. 이 장에서는 1장에서 확인한 최종 평가 데이터로 두 후보를 비교하고, 이미 나온 결과를 본 뒤 임계값(threshold)을 다시 찾거나 후보 모델을 재학습하지 않습니다. 이렇게 해야 두 후보의 판단 차이를 같은 조건에서 설명할 수 있습니다.

지표가 만들어지는 과정을 보기 위해 개발용 학습 자료로 작은 모델을 한 번 학습할 수 있습니다. 이 숫자는 두 후보의 승인 근거와 분리합니다.

이 장의 모델 승인은 1장에서 고정한 최종 평가 결과에만 적용됩니다. 대상 환경에서 그 모델이 실제로 실행 중인지, 운영 신호가 어떤 상태인지는 다음 장에서 따로 확인합니다.

이 장에서 분리할 세 가지

  • 개발용 train/valid 활동은 지표 계산을 이해하기 위한 학습입니다.
  • 공식 평가는 고정한 test와 정책으로 Candidate A/B의 모델 승인을 기록합니다.
  • 대상 API·운영 기록은 이 장의 결과가 아니라 3~4장에서 확인할 별도 근거입니다.

이 장에서 나누는 확인

5교시에는 지표와 서비스 위험을 연결합니다. 6교시에는 공식 평가로 두 후보를 판정하고, 개발용 학습은 계산 과정을 볼 때만 사용합니다. 7교시에는 그 숫자가 어느 데이터와 실행, 모델 파일에서 나왔는지 다시 찾습니다.

이 장의 핵심 질문

두 후보의 판단 차이는 어느 한 수치가 아니라 사전에 정한 보호 기준 전체로 설명해야 합니다.

후보를 비교하는 순서

  1. 같은 데이터 분할과 고정 임계값에서 나온 결과인지 확인합니다.
  2. 재현율, 재현율 하한, 정밀도, PR-AUC 변화, 미탐 감소를 모두 확인합니다.
  3. 필수 기준 하나라도 통과하지 못한 후보는 HOLD로 기록합니다.
  4. 모델 승인 결과를 대상 환경의 실행 성공으로 확장하지 않습니다.

이 판단은 1장의 데이터 분할에서 정한 범위 안에서만 유효합니다. 실행 중인 API가 Candidate B의 모델 패키지를 쓰는지와 운영 신호가 달라졌는지는 다음 장에서 확인할 별도 질문입니다.

품질 지표의 해석

Candidate A의 높은 정밀도와 Candidate B의 높은 재현율은 서로 다른 질문에 답합니다. 정밀도는 high_risk라고 알린 것 중 맞은 비율이고, 재현율은 실제 high_risk를 얼마나 놓치지 않았는지를 나타냅니다. 따라서 어느 한 수치가 더 크다는 사실만으로 배포 결론을 내릴 수 없습니다.

공식 평가에서는 점수와 임계값으로 만든 최종 예측을 최종 평가 데이터의 정답과 비교합니다. 정밀도, 재현율, 미탐, PR-AUC, 재현율 하한을 함께 보며, Candidate B의 계산 방법은 분류 지표와 곡선에서 먼저 확인할 수 있습니다.

공식 평가 결과는 모델 승인 판단에만 사용합니다. 운영용 입력에는 정답이 없으므로 같은 표를 새로 계산할 수 없습니다. 대상 API가 어떤 모델을 쓰는지와 운영 관측은 3장과 4장에서 확인합니다.

모델 학습에서 품질 지표까지

모델 학습은 특성과 정답의 관계를 데이터에서 찾는 과정입니다. 이 장의 개발용 실습에서는 train 자료로 로지스틱 회귀를 학습하고, 학습에 사용하지 않은 valid 자료에서 점수를 만듭니다. 같은 행으로 학습과 평가를 모두 하면 실제보다 좋은 결과를 얻을 수 있으므로 역할을 분리합니다.

모델은 먼저 각 행의 high_risk 점수를 만들고, 고정한 임계값을 적용해 예측을 정합니다. 이 예측과 valid 정답을 비교하면 TP, FP, FN, TN이 나오고, 여기에서 정확도, 정밀도, 재현율과 F1을 계산합니다. AUROC와 PR-AUC는 임계값 하나에 고정하지 않은 점수 구분력을 보여 줍니다.

개발용 로지스틱 회귀의 정확도는 0.8550이지만 재현율은 0.2169이고 FN은 65입니다. 클래스 구성이 치우친 자료에서는 low_risk를 많이 맞힌 결과가 높은 정확도를 만들 수 있으므로, 정확도만 보고 품질이 충분하다고 판단하면 안 됩니다.

학습과 개발 평가는 지표 생성 과정을 이해하는 근거이고, 고정한 test의 공식 평가만 후보 승인에 사용합니다. 정답 없는 운영 관측으로 새 정밀도나 재현율을 만들지 않습니다.

단계 사용하는 자료 생성되는 값 이 장에서의 해석
학습 train 2,900건 학습된 모델 지표 생성 과정을 이해하기 위한 개발용 모델
개발 평가 valid 600건 점수, 예측, 혼동 행렬과 지표 정확도 착시와 오류 유형을 확인하는 학습 근거
공식 평가 최종 평가 데이터 400건 Candidate A/B의 확정된 평가 결과 사전에 정한 기준에 따른 모델 승인 근거
운영 관측 정답 없는 operational과 실제 요청 점수, 예측 분포와 운영 신호 새 정밀도나 재현율로 계산하지 않음

개발용 결과와 공식 평가 결과를 나누면 수강생이 계산 과정은 직접 경험하면서도 최종 평가의 독립성을 지킬 수 있습니다. 보고서의 E-03 근거 행에는 개발용 수치를 쓰지 않고, 공식 평가 파일과 사전에 정한 배포 기준만 기록합니다.

다섯 조건을 동시에 지키는 이유

승인 정책은 결과를 보기 전에 허용할 오류와 보호할 수준을 정합니다. 정밀도만 높이면 알림을 매우 적게 내면서 놓침을 키울 수 있고, 재현율만 높이면 불필요한 알림 부담이 커질 수 있습니다. 좋은 항목의 점수로 다른 실패를 상쇄하는 평균 점수 대신, 이 과정은 다섯 필수 조건을 모두 만족하는지 검사합니다.

슬라이드의 재현율 0.55와 실제 판정의 0.60은 기본 기준과 여유를 포함한 기준의 차이입니다. 정책 tta-aiqa/configs/qa/revisions/v2.yaml에는 minimum_recall=0.55와 recall_safety_margin=0.05가 따로 있습니다. 판정 코드 packages/aiqa-qa/src/aiqa_qa/domain/release.py는 두 값을 더해 recall >= 0.60을 검사합니다. 화면의 0.55만으로 자동 승인 기준을 낮춰 읽지 않습니다.

필수 조건 실제 적용 기준 보호하려는 것
재현율 0.55 + 0.05 = 0.60 이상 최소 포착 수준과 정책상 안전 여유
재현율 부트스트랩 하한 0.45 이상 한 표본의 높은 성적만으로 승인하는 위험
정밀도 0.20 이상 불필요한 알림 부담
비교 기준 모델 대비 PR-AUC 변화 0 이상 점수 순위 품질의 저하
비교 기준 모델 대비 FN 감소 15건 이상 놓침의 실질적 감소

재현율 하한은 별도 계산한 표본 변동의 근거이며 안전 여유 0.05를 다시 더하는 항목이 아닙니다. 이 값들은 교육용 정책으로 고정한 조건이고 일반적인 AI 서비스에 적용할 보편적인 합격선은 아닙니다. 조건을 바꿀 필요가 있으면 이미 본 테스트 결과에 맞춰 수정하는 대신 새로운 평가 계획과 근거 범위를 정합니다.

후보 모델의 공식 평가 결과

비교 기준 모델(baseline)은 후보 모델의 품질 지표와 개선 폭을 비교하는 출발점입니다. 표의 “후보 비교의 출발점”은 이 모델 자체의 승인 여부가 아니라 Candidate A와 Candidate B를 판단할 기준값이라는 뜻입니다.

고정한 평가 조건에서 Candidate A는 HOLD, Candidate B는 APPROVE입니다. 한 수치가 아니라 사전에 정한 필수 기준 전체로 판단합니다.

모델 후보 임계값 정밀도 재현율 PR-AUC 놓친 high_risk 수 모델 승인 판단
비교 기준 모델 (baseline) 0.50 0.5652 0.2364 0.5244 42 후보 비교의 출발점
Candidate A 0.40 0.7727 0.3091 0.5942 38 HOLD
Candidate B 0.35 0.3793 0.8000 0.5743 11 APPROVE

Candidate A의 정밀도가 높아도 다른 기준을 생략할 수는 없습니다. Candidate A는 재현율 0.3091 < 0.60, 재현율 하한 0.1864 < 0.45, 미탐 감소 4 < 15를 충족하지 못했습니다. Candidate B는 재현율 0.8000, 하한 0.6956, 정밀도 0.3793, PR-AUC 변화 +0.0499, 미탐 감소 31로 모든 필수 기준을 통과했습니다.

혼동 행렬과 품질 지표

Candidate B의 혼동 행렬은 TP 44, FP 72, FN 11, TN 273입니다. TP, FP, FN, TN은 각각 high_risk를 맞게 알린 수, low_risk를 high_risk로 잘못 알린 수, high_risk를 놓친 수, low_risk를 맞게 분류한 수를 뜻합니다. 재현율은 44를 44와 11의 합으로 나눈 0.8000이고, 정밀도는 44를 44와 72의 합으로 나눈 0.3793입니다. 두 지표는 분모가 다르므로 하나로 합쳐 “더 좋다”라고 판단하지 않습니다.

Candidate A는 TP 17, FP 5, FN 38, TN 340입니다. A의 정밀도 0.7727은 높지만, 재현율 0.3091과 미탐 38은 사전에 정한 정책의 놓침 감소 목표를 만족하지 못합니다.

미탐 감소는 비교 기준 모델의 FN 42에서 후보 모델의 FN을 빼서 계산합니다. A는 42 - 38 = 4로 기준인 15에 못 미치고, B는 42 - 11 = 31로 기준을 넘습니다. 재현율 하한도 A는 0.1864로 기준 0.45 아래이고 B는 0.6956으로 기준을 넘으므로, 정책은 A를 HOLD, B를 APPROVE로 기록합니다.

보호 기준은 정밀도부터 하나씩 고르는 대신 모든 필수 기준의 통과 여부를 차례로 확인합니다.

확인 순서 Candidate A Candidate B 해석할 내용
정밀도 0.7727 0.3793 두 후보 모두 최소 기준은 넘지만, A의 높은 정밀도만으로 승인하지 않습니다.
재현율 0.3091 0.8000 A는 필요한 0.60에 못 미치고 B는 통과합니다.
재현율 하한 0.1864 0.6956 평균적인 결과만 보지 않고 불확실성까지 고려합니다.
비교 기준 모델 대비 미탐 감소 4 31 A는 필요한 15에 못 미치고 B는 통과합니다.

실제 API의 프로필, 모델 패키지 식별정보, 운영 신호가 다르게 확인돼도 공식 평가의 모델 승인 결과를 바꾸지는 않습니다. 이 계산은 모델 승인 판단을 설명하기 위한 것이며, 실행 환경에서 확인한 범위와 다음 조치는 별도로 기록합니다.

통과한 후보에서도 남는 오류 비용

후보 B의 승인은 모든 오류가 줄었다는 뜻이 아닙니다. 기준 모델 대비 FN은 42 - 11 = 31건 줄었지만 FP는 72 - 10 = 62건 늘었습니다. 알림 총수도 기준 모델의 13 + 10 = 23건에서 B의 44 + 72 = 116건으로 늘었습니다. 같은 공식 평가 400건에서 계산한 변화이므로 두 비용을 같은 범위에서 비교할 수 있습니다.

모델 평가와 운영 수용 능력은 다른 근거가 필요합니다. B는 다섯 필수 모델 조건을 통과했지만 실제 운영에서 116건의 알림이 발생한다거나 처리할 수 있다고 단정할 수 없습니다. 운영에서는 요청 수와 클래스 구성, 알림 처리 체계가 다를 수 있습니다. 따라서 모델 담당자는 평가 결과를 남기고 운영 담당자는 알림량과 처리 여력을 확인할 다음 조치를 맡습니다.

판단 기록은 “FN 31건 감소, FP 62건 증가, 고정 평가에서 모델 승인”까지 함께 적습니다. 낮은 재현율의 A를 정밀도만 보고 승인하는 위험과, B가 통과한 모델 조건을 무시해 검토를 지연하는 비용을 모두 설명할 수 있어야 합니다. 대상 환경 확인이 부족하면 모델 결론은 보존하고 운영 판단을 미확인으로 남깁니다.

평가 결과와 선언 파일의 시점

tta-aiqa/docs/reference/evidence/model/revisions/의 평가 자료는 같은 시점에 만들어진 파일이 아닙니다. model-bootstrap.json의 candidate_deployment_allowed=false와 후보 모델 패키지의 deployed=false는 최종 평가 전에 학습과 검증을 마친 상태를 뜻합니다. 최종 평가 뒤의 공식 결과와 배포 선언 파일은 Candidate B를 배포 검토 대상으로 지정합니다.

MLflow는 모델 학습과 평가에 사용한 설정, 지표, 실행 ID를 기록하는 도구입니다. 생성 시점이 다른 파일은 초기 상태·고정 정책·공식 결과·배포 검토 근거로 구분해 읽습니다. 화면에 보이는 실행 하나를 공식 승인으로 보지 않습니다.

자료 파일 확인하는 내용 이 장에서 사용하는 방법
model-bootstrap.json train/valid 모델 패키지, 프로필별 MLflow 실행 기록, 최종 평가 전의 초기 배포 상태 프로필과 실행 이력을 확인하되, 최종 판단과 혼동하지 않습니다.
release-freeze.json 테스트 전에 확정한 정책, 품질 지표 해시값, 모델 패키지 해시값 테스트 결과를 본 뒤 임계값이나 정책을 바꾸지 않았는지 확인합니다.
final-benchmark.json 최종 평가 데이터로 한 번 계산한 품질 지표 사전에 확정한 평가 수치를 확인합니다.
canonical-benchmark.json A=HOLD, B=APPROVE, deployment_allowed=true 모델 승인 판단을 기록합니다.
release-manifest.json 공식 판단, 최종 평가 자료, 모델과 메타데이터의 해시값, MLflow 실행 ID의 연결 승인된 B 모델 패키지의 배포 검토 근거와 추적 정보를 기록합니다.

deployment_allowed=true는 고정된 모델 평가 결과에서 Candidate B를 배포 검토 대상으로 올릴 수 있다는 조건입니다. 대상 Kubernetes 환경이 이미 Candidate B를 실행하고 운영 관측이 정상이라는 뜻은 아닙니다. 모델 승인 판단과 운영 환경 확인을 구분한 채 3장에서 실행 환경을 확인합니다.

이 장에서 정리할 내용

모델 평가가 끝났다는 기록만으로는 대상 API나 운영 환경의 상태를 설명할 수 없습니다. 이 장의 기록에는 다음을 분리해 남깁니다.

  • 1장에서 이어받은 범위: 원본·특성 규칙, 데이터 분할, 최종 평가 데이터의 범위
  • 모델 평가 결론: Candidate A/B의 품질 지표, 임계값, 기준 통과 여부, 정책과 선언 파일 이력
  • 현재 결론: Candidate A는 HOLD, Candidate B는 고정한 모델 평가에서 APPROVE
  • 아직 모르는 점: 실행 중인 모델 패키지 식별정보, API 규칙, 요청과 운영 관측 범위
  • 다음 장으로 넘길 질문: 승인된 Candidate B 산출물과 API·선언 파일이 같은 고정 모델 패키지를 가리키는가

보고서 문장 예시

보고서의 model_approval 항목은 공식 평가의 승인 범위와 대상 환경에서 아직 확인하지 못한 사실을 분리해 남겨야 합니다. 아래 문장은 공식 평가에서 확인한 모델 승인 판단을 기록할 때 사용할 수 있습니다.

Candidate B는 공식 평가 결과에서 재현율, 재현율 하한, 정밀도, PR-AUC 변화, 미탐 감소 기준을 충족해 APPROVE입니다. Candidate A는 정밀도가 높아도 필요한 재현율, 재현율 하한, 미탐 감소 기준을 충족하지 못해 HOLD입니다. 이 문장은 모델 승인 판단이며 대상 환경 배포가 끝났다는 뜻은 아닙니다.

배포 판단 기록에서는 모델 승인과 실행 환경 확인을 분리해야 합니다. 이 문장은 작업본의 model_approval 항목에 남기고, 다음 장에서는 승인된 Candidate B와 실행 중인 산출물이 같은 식별정보를 가리키는지 확인합니다.

함께 볼 자료와 실습