AI 품질과 이상 신호¶
기존 운영 모델의 API는 정상 응답하지만 high_risk 예측 비율이 갑자기 늘었습니다. 이때 API 오류가 없다는 이유로 서비스를 그대로 유지하거나, 예측 비율이 변했다는 이유로 곧바로 모델을 교체해서는 안 됩니다.
예측 비율은 모델 출력과 들어온 요청의 구성에 따라 함께 달라질 수 있습니다. 배포 판단에 참여하는 사람은 직무와 관계없이 데이터, 모델, API, 운영 기록을 차례로 살펴보고, 확인한 근거의 범위에서만 결론을 내립니다.
이 문서에서 먼저 구분할 것
- API가 응답했다는 사실과 모델 품질이 충분하다는 결론은 다릅니다.
- 정답이 있는 평가 자료와 정답이 없는 운영 기록은 서로 다른 질문에 답합니다.
- Candidate A/B는 비교할 모델이고, 입력 변화·실행 환경·API 오류는 조사할 원인 후보입니다.
규칙으로 만든 소프트웨어와 데이터로 학습한 모델¶
규칙 기반 소프트웨어의 기능 시험은 명세에 적힌 규칙과 실제 실행 결과를 비교합니다. 소프트웨어 1.0(Software 1.0)은 사람이 함수, 분기, 입출력 계약으로 처리 규칙을 적는 방식을 가리킵니다. 명세에서 특정 입력의 기대 결과를 정할 수 있으므로, 대표 입력과 경계값, 잘못된 입력을 넣어 결과와 오류 처리를 확인합니다. 이 방법은 명시한 기능의 구현 여부를 확인하는 중심 수단이며, 보안이나 성능 같은 모든 품질을 단독으로 보장한다는 뜻은 아닙니다.
학습 기반 소프트웨어는 코드가 실행됐는지에 더해 배운 규칙이 새 자료에도 통하는지 확인해야 합니다. 소프트웨어 2.0(Software 2.0)에도 입력 검증과 학습, 예측을 수행하는 코드가 있습니다. 다만 모든 입력을 high_risk와 low_risk로 나누는 조건을 사람이 하나씩 적는 대신, 학습 알고리즘이 특성과 정답의 관계에서 모델 파라미터를 정합니다. 모델은 학습 자료를 잘 맞히면서도 처음 보는 자료에서는 틀릴 수 있습니다. 이처럼 학습에 사용하지 않은 자료에서도 성능을 유지하는 성질을 일반화라고 합니다.
AI 서비스의 기능 시험과 모델 평가는 정답을 확인하는 방식이 다릅니다. API가 요청을 받고 올바른 형식의 prediction을 반환하면 응답 계약은 통과할 수 있습니다. 그러나 high_risk와 low_risk는 모두 허용된 클래스이므로, 형식 검사는 그 선택이 실제 정답과 맞는지 검사하지 않습니다. 정답이 있는 별도 평가 자료에서 오류의 종류와 비율을 확인해야 이 빈틈을 채울 수 있습니다.
확인 범위는 기존 기능 시험에 데이터와 모델 근거를 더하는 방향으로 넓어집니다. 같은 입력값, 전처리, 모델 파일, 임계값과 결정적인 실행 조건을 모두 고정한 추론이 이유 없이 달라진다고 가정하지 않습니다. 결과가 바뀌었다면 실제 입력이나 실행 조건 중 무엇이 달랐는지 조사합니다.
| 품질 질문 | 기존 시험에서 사용하는 근거 | 학습 기반 서비스에서 추가할 근거 |
|---|---|---|
| 명시한 기능이 실행됐는가 | 입력, 기대 출력, 경계값, 오류 응답 | 같은 기능 시험을 유지하고 클래스와 점수의 응답 계약 확인 |
| 새 사례를 적절히 분류하는가 | 명세가 정한 개별 기대 결과 | 학습에 쓰지 않은 정답 자료, 혼동 행렬, 지표와 평가 조건 |
| 변경 뒤 결과를 설명할 수 있는가 | 소스와 설정의 변경 이력 | 데이터 내용, 전처리, 모델 파일, 임계값과 운영 입력 |
| 지금 운영 중 품질을 판단할 수 있는가 | 상태 응답, 오류율, 지연 시간 | 점수와 예측 분포, 뒤늦게 확보한 정답과 비교 가능한 평가 |
보고서에는 어느 질문을 시험했는지 먼저 적습니다. “준비 상태 200을 확인했다”와 “평가 자료에서 재현율 기준을 충족했다”는 서로 다른 근거이므로, 하나의 기능 정상 표시로 합치지 않습니다. 데이터 역할을 분리하는 이유는 학습과 최종 평가의 분리 원칙과 연결되며, 이 과정에서는 다음의 같은 100건 사례에 적용합니다.
같은 100건에서 달라진 예측을 읽는 방법¶
첫 사건에서 확인한 것은 예측 분포 변화이며, 모델 성능 저하가 아닙니다. 준비된 tta-aiqa/docs/evidence/incident/initial-signal.json은 기준 모델과 임계값 0.5를 고정하고 같은 운영 레코드 100건을 바탕으로 만든 두 시나리오를 비교합니다. same_base_rows_for_both_scenarios=true는 같은 레코드가 비교의 바탕이라는 뜻이며, 모든 요청의 특성값과 처리 조건까지 동일하다는 뜻은 아닙니다. 이 파일은 실제 운영에서 수집한 최신 로그가 아니라 수업용 사전 재현 자료입니다.
예측 건수는 임계값을 넘긴 결과를 세고, 점수 백분위수는 점수 분포의 위치를 봅니다. baseline에서는 100건 중 3건을, current-shift에서는 6건을 high_risk로 분류했습니다. 이는 3%에서 6%로 3%포인트 증가한 것입니다. 점수의 95백분위수는 0.3859에서 0.5133으로 달라졌습니다. 슬라이드의 “상위 5% 경계 점수”는 이 위치를 가리키며 상위 5건의 평균이나 정답률을 뜻하지 않습니다.
정답이 없으면 분포를 성적표로 바꿀 수 없습니다. 정밀도는 알린 사례 중 실제 양성인 수를, 재현율은 실제 양성 중 알린 수를 알아야 계산합니다. 현재 파일에는 운영 정답을 제외했으므로 예측 6건 중 몇 건이 맞았는지, 알리지 않은 사례 중 몇 건을 놓쳤는지 알 수 없습니다. 숫자 증가만으로 좋아졌다거나 나빠졌다고 판정할 수 없는 이유입니다.
판단 기록에는 “같은 기준 모델과 같은 100건 범위의 두 시나리오에서 점수와 예측 분포 변화가 확인됐다. 성능 저하와 단독 원인은 미확인이다”라고 남깁니다. 원인 조사는 입력 조건, 변환 규칙, 모델과 임계값, API 처리와 실행 환경 순으로 근거를 모읍니다. 준비 상태 200은 이 100건을 정답과 비교해 채점한 결과가 아니므로 성능 근거로 합치지 않습니다.
API 응답과 품질 확인 범위¶
AI 품질 보증(AI quality assurance, AI QA)은 API가 요청을 처리하는지뿐 아니라, 입력이 정해진 형식과 맞는지, 어떤 모델이 결과를 만들었는지, 평가 결과와 운영 기록을 섞지 않았는지도 확인하는 일입니다. HTTP 200은 한 요청을 처리했다는 뜻입니다. 모델 품질과 운영 배포가 모두 승인됐다는 뜻은 아닙니다.
준비 상태 경로가 성공해도 예측 품질을 확인한 것은 아닙니다. 이 경로는 점수 계산기가 요청을 받을 준비가 됐는지만 알려 주며, high_risk 예측이 늘었는지나 정밀도·재현율이 기준을 통과했는지는 말하지 않습니다. 경로 이름은 /health/ready이고, 강사가 안내한 공개 Risk API 베이스 뒤에 붙입니다.
준비 상태와 예측 요청은 같은 성공으로 읽지 않습니다.
| 확인한 응답 | 확인한 사실 | 아직 모르는 것 |
|---|---|---|
| 준비 상태 | 프로세스가 요청을 받을 준비가 됐는지 | 예측 분포, 정밀도, 재현율, 배포 승인 |
| 예측 요청 | 그 요청이 API 규약에 맞게 처리됐는지 | 대상 환경 전체의 품질이나 배포 성공 |
1교시에는 배정된 공개 HTTPS의 준비 상태와 /v1/model을 GET으로 확인합니다. 예측 POST는 측정한 특성만 넣어 볼 수 있습니다. 3건과 6건의 비교는 준비된 자료로 읽고, 그 점수만으로 예측 품질이나 운영 비율 변화의 원인을 단정하지 않습니다. 지금은 준비 상태를 예측 품질의 근거로 쓰지 않겠다는 판단만 기록합니다.
회의에서 “예측 비율이 늘었으니 모델을 바꾸자”는 의견이 나와도 바로 후보를 선택해서는 안 됩니다. 담당자는 어떤 입력을 받았는지, 기존 운영 모델이 그대로 실행됐는지, 점수와 임계값은 무엇인지, 운영 기록은 어느 시점의 것인지 확인한 뒤 두 후보의 평가 결과를 비교합니다.
데이터 문제와 모델 문제, 로컬 확인과 대상 환경 확인, 운영 기록과 모델 성능을 섞지 않기 위한 순서입니다.
확인 목록
- 입력 데이터가 정한 규약과 평가 조건에 맞는지 확인합니다.
- 정답이 있는 평가 자료에서 후보 모델이 배포 기준을 통과했는지 확인합니다.
- API가 어떤 모델 정보를 내보내는지와 실제로 확인한 환경을 기록합니다.
- 운영 기록에서는 관측값, 아직 모르는 것, 담당자와 다음 조치를 분리합니다.
입력 데이터, 모델 평가, API와 실행 환경, 운영 기록은 서로 다른 질문에 답하며, 각 결과의 근거와 확인 범위를 따로 기록합니다.
| 확인할 대상 | 확인할 질문 | 남겨 둘 내용 |
|---|---|---|
| 입력 데이터 | 모델이 받는 값과 관측 범위가 정해 둔 형식과 맞는가 | 데이터 규약(data contract)과 평가 조건 |
| 모델 평가 | 정답과 비교한 결과가 미리 정한 배포 기준을 만족하는가 | 모델 승인 근거 |
| API와 실행 환경 | 평가한 모델이 실제로 확인한 API에서도 사용되는가 | 실행 중인 모델 정보와 확인한 환경 |
| 운영 기록 | 지표, 로그, 추적 기록이 무엇을 알려 주는가 | 관측값, 아직 모르는 것, 담당자와 다음 조치 |
표의 네 항목은 서로 대신할 수 없습니다. 예를 들어 데이터 검증에 성공했다는 사실은 입력 구조가 맞다는 근거가 될 뿐, 모델 승인이나 대상 환경 배포 완료까지 뜻하지는 않습니다.
교육용 데이터와 예시 수치의 범위
생체신호 기반 위험 알림 시스템은 분류와 품질 운영을 익히기 위한 예시입니다. high_risk, low_risk, In-hospital_death는 실제 의료 판단이나 조언을 뜻하지 않습니다.
첫 사건의 3건과 6건은 출처가 명시된 수업용 사전 재현 값입니다. Candidate A와 Candidate B의 공식 평가 결과와 배포 기준은 2장에서 확인하며, 예시 숫자를 실제 배포 근거로 사용하지 않습니다.
원본 데이터에서 품질 지표까지¶
AI 서비스는 원본 데이터를 가공해 특성을 만들고, 정답과 비교해 평가합니다. 모델은 입력마다 점수를 내고 임계값을 적용해 예측을 정합니다. 여러 예측을 정답과 비교해서 계산한 수치가 품질 지표입니다. 이 문서에서는 이후에 각각 원본 데이터, 특성, 정답, 점수, 임계값, 예측, 품질 지표라고 부릅니다.
원본 데이터의 한 행이 곧바로 모델 입력 한 행이 되는 것은 아닙니다. 이 교재의 원본 레코드(record)는 Time, Parameter, Value로 이루어진 여러 관측 행입니다. 가공 과정은 한 레코드에 쌓인 반복 관측을 모델이 사용할 특성 한 행으로 바꿉니다.
결측 표식을 처리하는 일과 정답을 연결하는 일은 서로 다른 품질 확인 작업입니다. -1은 측정값이 아니라 결측을 표시한 값입니다.
원본 관측은 가공한 특성, 정답, 점수와 임계값, 예측을 거쳐 품질 지표로 이어집니다. 앞 단계의 확인만으로 다음 단계의 결론을 보장할 수 없습니다.
| 단계 | 예시 | 확인할 점 |
|---|---|---|
| 원본 관측 | 00:00 / Age / 54, 00:00 / Height / -1, 00:07 / HR / 73 |
시간, 항목, 값의 형식과 결측 표식이 정해 둔 규칙과 맞는가 |
| 가공한 특성 | age=54, height=null, height__missing=true, heart_rate__mean=... |
결측과 반복 관측을 같은 방식으로 특성으로 바꿨는가 |
| 교육용 정답 | target을 high_risk 또는 low_risk와 비교 |
정답은 평가용이며 운영 API 요청에는 넣지 않는가 |
| 점수와 임계값 | score=0.42, threshold=0.35 |
모델 출력과 예측 기준을 구분해 적었는가 |
| 예측 | 0.42 >= 0.35이므로 high_risk |
어떤 기준으로 결과가 바뀌었는가 |
| 품질 지표 | 여러 예측을 정답과 비교한 정밀도, 재현율, 미탐 수 | 정답이 있는 평가 자료로 계산했는가 |
점수는 high_risk 쪽으로 분류될 정도를 나타내는 모델 출력입니다. 실제 의료 확률이나 진단 결과가 아닙니다. 같은 점수라도 임계값이 다르면 최종 예측이 달라질 수 있으므로, 두 값을 함께 확인해야 합니다.
데이터 품질 문제가 평가를 흔드는 방식¶
데이터 품질 문제는 모델이 실행되지 않게 만드는 오류만을 뜻하지 않습니다. 파일을 정상적으로 읽고 모델 평가까지 끝냈더라도 결측값 처리, 값의 범위, 정답 연결, 클래스 구성에 문제가 있으면 품질 지표를 잘못 해석할 수 있습니다.
데이터 품질 문제를 볼 때는 문제 이름보다 어떤 값을 확인하고 어떤 결론을 보류해야 하는지가 중요합니다.
- 결측값: 측정되지 않은 값을 0 같은 실제 값으로 바꾸지 않았는지와 처리 규칙을 확인합니다.
- 이상치: 허용 범위·단위·원본 기록을 먼저 확인하고, 범위를 벗어난 값을 자동으로 삭제하지 않습니다.
- 라벨 오류: 정답 연결 키와 허용 클래스를 확인합니다. 잘못 연결된 정답은 지표를 왜곡할 수 있습니다.
- 클래스 불균형: 클래스별 건수를 보고, 정확도 하나가 적은 클래스의 놓침을 숨기지 않는지 확인합니다.
결측·이상치·라벨 오류·클래스 불균형은 먼저 관측값과 지표 영향을 확인해야 합니다. 발견만으로 데이터 삭제, 모델 실패 또는 품질 충분을 단정하지 않습니다.
| 데이터 문제 | 먼저 확인할 관측값 | 품질 지표에 생길 수 있는 영향 | 바로 내려서는 안 되는 결론 |
|---|---|---|---|
| 결측값 | 컬럼별 결측 수, 결측 표시값, 처리 규칙 | 일부 특성의 의미가 달라지고 평가 대상 수가 변함 | 결측값이 있으므로 모델이 실패함 |
| 이상치 | 허용 범위, 단위, 극단값의 원본 기록 | 점수 분포와 오류 유형이 일부 값에 민감해질 수 있음 | 범위를 벗어난 값은 모두 삭제해야 함 |
| 라벨 오류 | 정답 연결 키, 허용 클래스, 중복, 충돌 여부 | FP와 FN, 정밀도와 재현율이 잘못 계산될 수 있음 | 지표가 낮으므로 모델만 고치면 됨 |
| 클래스 불균형 | 클래스별 건수와 high_risk 표본 수 |
높은 정확도가 적은 클래스를 놓치는 문제를 숨길 수 있음 | 정확도가 높으므로 품질이 충분함 |
현재 PhysioNet 자료에서 확인한 사실은 구조, 결측 표시, 정답 분포와 분할 이력입니다. 모든 오류 유형이 지금 데이터에 있다고 가정하지 않으며, 직접 관측한 결과와 일반적인 위험을 구분해 기록합니다.
품질 지표와 운영 기록의 차이¶
품질 지표는 정답이 있는 여러 사례에서 예측을 비교해 계산합니다. 정밀도(Precision)는 high_risk라고 알린 사례 가운데 실제로도 high_risk인 비율입니다. 재현율(Recall)은 실제 high_risk 사례 가운데 모델이 놓치지 않고 알린 비율입니다.
운영 기록(telemetry)은 서비스가 요청을 처리하면서 남기는 지표, 로그, 추적 기록을 말합니다. 운영 요청에는 보통 정답이 없습니다. 따라서 점수 분포가 달라지거나 HTTP 422가 늘어도, 그 사실만으로 새 재현율이나 미탐 수를 계산할 수는 없습니다.
4장에서 보는 운영 신호는 입력 조건, API 검증, 지연 시간, 실행 환경을 더 살펴봐야 한다는 신호입니다. 정답이 확보된 별도 평가를 같은 조건에서 다시 해야 품질 지표를 새로 계산할 수 있습니다.
두 자료의 역할을 한 줄로 구분하면 다음과 같습니다.
- 공식 평가는 “후보 모델이 고정한 기준을 통과했는가”에 답합니다.
- 운영 기록은 “어느 시간대와 요청을 더 조사해야 하는가”에 답합니다.
구조 검사와 모델 평가는 서로 다른 질문에 답합니다. 둘의 해석 범위를 나란히 비교하면 한쪽 결과를 다른 쪽 결론으로 과장하는 일을 막을 수 있습니다.
| 확인한 값 | 확인한 사실 | 아직 모르는 것 |
|---|---|---|
| 공식 평가의 재현율과 미탐 수 | 그 평가에서 후보 모델이 배포 기준을 만족했는가 | 다른 시간대 운영 요청의 성능 |
| 준비 상태 응답 | 확인한 프로세스가 요청을 받을 준비가 됐는가 | 예측 분포 변화나 모델 성능 |
| 예측 요청 응답 | 확인한 요청이 API 규약에 맞게 처리됐는가 | 대상 환경 전체의 배포 성공 |
| HTTP 422 증가 | 입력 형식 문제를 살펴봐야 하는가 | 모델 자체의 품질 문제 |
| 점수의 95백분위수(P95) 또는 예측 비율 변화 | 입력 조합이나 실행 조건이 달라졌을 가능성 | 정답으로 계산하는 모델 성능이 나빠졌는가 |
후보 모델과 원인 후보(hypothesis)는 뜻이 다릅니다. Candidate A와 Candidate B는 평가해 비교하는 모델입니다. 반면 입력 변화, 잘못된 모델 패키지, API 검증 실패, 지연 시간은 관측값을 설명할 수 있는 가능성입니다. 새 근거가 나오면 각 원인 후보를 강화, 약화, 유지, 제외합니다.
장별 확인의 흐름¶
앞 장에서 남긴 질문이 다음 장의 입력이 됩니다.
- 1장 데이터 품질에서 후보를 비교할 데이터 범위를 고정합니다.
- 2장 모델 품질에서 비교 기준 모델과 두 후보를 같은 조건으로 평가합니다.
- 3장 서빙에서 선택한 모델과 API가 사용하는 모델 정보를 대조합니다.
- 4장 운영 관측에서 기준 상태와 변경 뒤 기록을 비교해 더 살펴볼 원인 후보를 정리합니다.
- 5장 배포 판단에서 모델 평가와 운영 환경 확인을 따로 적고, 위험·담당자·재평가 조건을 한 기록으로 묶습니다.
Candidate A와 B의 수치는 같은 평가 조건에서만 비교할 수 있으므로, 다음 단계에서는 그 조건과 지표의 뜻을 확인해야 합니다. 분류 지표와 곡선을 읽고 이 흐름으로 돌아옵니다.