54 lines
2.7 KiB
Markdown
54 lines
2.7 KiB
Markdown
# 지속 모델 평가·개선 생명주기
|
|
|
|
## 1. 상태기계
|
|
|
|
`RESEARCH → CHALLENGER → SHADOW → CANDIDATE → APPROVED → RETIRED/ROLLED_BACK`
|
|
|
|
상태 변경은 이벤트와 승인 기록으로만 수행한다. 스케줄러는 상태를 변경하지 않는다. 스케줄러가 생성할 수 있는 것은 평가 요청, 관측값, 평가 스냅샷, 개선 제안, 검토 패킷, 롤백 훈련 증거뿐이다.
|
|
|
|
## 2. 일일 루프
|
|
|
|
1. J10이 만기가 도래한 1/5/20/63/126/252 거래일 Outcome을 계산한다.
|
|
2. J11이 운영 무결성, calibration, 매수·매도·재진입, 비용후 기대효용을 cohort별로 집계한다.
|
|
3. J17이 승인 baseline 대비 Data/Feature/Prediction/Calibration drift를 평가한다.
|
|
4. 결측·지연·정의 불일치가 있으면 `BUSINESS_HOLD`; 계산 오류나 무결성 위반은 `FAIL/QUARANTINED`로 분리한다.
|
|
|
|
## 3. 주간 루프
|
|
|
|
- J18은 Champion과 Challenger를 동일 Dataset, Cost, Cohort, Window로 비교한다.
|
|
- J24는 source revision이 영향을 주는 Decision/Outcome을 찾아 재평가 제안을 만든다.
|
|
- 비교 표본이 다르거나 VersionSet이 불일치하면 결과를 승격 근거로 사용하지 않는다.
|
|
|
|
## 4. 월간 루프
|
|
|
|
- J19는 동결 manifest로 Walk-forward OOS를 재현한다.
|
|
- J21은 Scorecard, Drift, Attribution, Data Gap, 기술부채를 근거로 개선 제안을 만든다.
|
|
- J22는 승격 후보가 있을 때 Gate 증거 패킷을 만든다.
|
|
- 개선 제안은 `DATA_REMEDIATION`, `FEATURE_REVIEW`, `THRESHOLD_REVIEW`, `POLICY_REFACTORING`, `CALIBRATION_REVIEW`, `RISK_LIMIT_REVIEW`, `TECH_DEBT_REPAYMENT`으로 분류한다.
|
|
|
|
## 5. 분기 루프
|
|
|
|
- J20은 전체 실험 원장에 대해 CSCV/PBO/DSR, parameter stability, block bootstrap, 비용 2배 stress를 수행한다.
|
|
- J23은 승인 Champion과 fallback manifest를 사용해 rollback drill을 수행한다.
|
|
- 독립 검증자와 운영 Secondary가 실제로 수행한 evidence가 없으면 Gate는 통과하지 않는다.
|
|
|
|
## 6. 개선 제안 처리
|
|
|
|
`DRAFT → REVIEW_REQUIRED → APPROVED_FOR_RESEARCH / REJECTED / EXPIRED`
|
|
|
|
`APPROVED_FOR_RESEARCH`는 생산 승격이 아니다. 연구 branch에서만 변경을 허용하며, Model Change 문서, Golden, OOS, 보안·데이터 영향, rollback을 다시 작성한다.
|
|
|
|
## 7. 승격 Gate
|
|
|
|
필수 최소조건은 첨부 기준을 보존한다.
|
|
|
|
- Shadow 252거래일 이상, 서로 다른 시장국면 2개 이상
|
|
- 운영 무결성 오류 0
|
|
- 비용후 기대효용 양수와 calibration 안정
|
|
- false-exit 연 2% 이하와 reentry capture 65% 이상
|
|
- PBO 20% 이하, DSR 95% 이상
|
|
- 비용 2배에서도 기대효용 양수
|
|
- 독립검증, 투자위, 리스크, 준법, 보안, 운영 승인
|
|
|
|
지표 정의가 미승인인 경우 수치가 좋아도 Gate는 `HOLD`다.
|