가이드
튜토리얼: 분류기와 회귀 모델
명령줄에서 평가하는 세 가지 예측 모델에 대한 실행 가능한 안내입니다. 이진 이탈 분류기, 한 번에 한 클래스씩 평가하는 세 클래스 티켓 라우터, 그리고 선언한 범위 안의 절대 오차로 점수를 매기는 배송 시간 회귀 모델입니다. 각각 제공자, 키, 네트워크 없이 로컬에서 실행되며, 각각 기준선에 대해 측정한 후보 변경으로 끝납니다.
이 페이지는 모든 필드를 설명하는 분류기와 회귀 모델의 실습 짝입니다. 참조는 그 페이지를, 처음부터 끝까지 한 번 해 보려면 이 페이지를 읽으세요. 구간, 결정 상태, 릴리스 조치 같은 용어는 개념에 정의되어 있습니다.
Oloproof가 예측 모델에 대해 측정하는 것과 측정하지 않는 것
| 모델 | 얻는 것 | 얻지 못하는 것 |
|---|---|---|
| 이진 분류기 | 정확도, 재현율, 정밀도, Brier 점수, 로그 손실, ROC-AUC와 평균 정밀도, 그리고 혼동 개수, 보정 표, 임계값 스윕 | 권장 임계값 |
| 다중 클래스 분류기 | 클래스마다 재현율 하나와 정밀도 하나, 각각 그 클래스를 양성 클래스로 하는 이진 지표(일대다) | 매크로 또는 마이크로 평균 지표 |
| 회귀 모델 | 여러분이 선언한 target_range로 경계 지은 평균 절대 오차 | 제곱 오차, R 제곱, 또는 범위를 선언하지 않은 모든 오차 |
모델 자체는 여러분의 것으로 남습니다. Oloproof는 여러분이 가리킨 Python 함수를 호출하고, 그것이 반환한 예측을 읽으며, 특성, 가중치, 내부는 절대 보지 않습니다.
사전 준비
- 빠른 시작에서처럼 가상 환경에 Python 3.11 이상과 pip install oloproof.
- 패키지와 함께 제공되는 예제 파일. 실행의 저장소가 그곳에 생기도록 새 디렉터리에 복사하세요.
oloproof init --example predictive ~/oloproof-predictive
cd ~/oloproof-predictive아래의 모든 명령은 세 하위 디렉터리 중 하나에서 실행합니다. 각 실행은 읽은 oloproof.yaml 옆의 .oloproof/ 디렉터리에 증거를 씁니다.
predictive/
binary/ app.py oloproof.yaml candidate.yaml release.yaml comparison.yaml data/accounts.jsonl
multiclass/ app.py oloproof.yaml candidate.yaml release.yaml data/tickets.jsonl
regression/ app.py oloproof.yaml candidate.yaml release.yaml data/orders.jsonl1부: 이진 분류기
어댑터
binary/app.py는 모델과 어댑터를 한 파일에 담습니다. 모델은 churn_model 예제(oloproof init --example churn_model)와 같은 결정론적 이탈 모델이며, 어댑터는 Oloproof가 호출하는 데코레이터가 붙은 함수입니다.
from oloproof import system
@system(name="churn-model", version="baseline")
def run(account):
score = churn_score(account)
return {"label": score >= 0.5, "score": round(score, 4)}
@system(name="churn-model", version="candidate-cutoff-0.4")
def run_candidate(account):
score = churn_score(account)
return {"label": score >= 0.4, "score": round(score, 4)}자신의 모델을 평가하려면 형태는 유지하고 churn_score를 그 모델 호출로 바꾸세요. 예를 들어 임포트 시 한 번 로드하는 scikit-learn 모델이라면 model.predict_proba([features(account)])[0][1]입니다. 모델이나 그 기준값이 바뀔 때마다 version을 바꾸세요. 버전은 캐시 키의 일부이므로, 같은 버전으로 다시 학습한 모델은 예전 예측을 재사용하게 됩니다.
입력과 출력의 형태
data/accounts.jsonl의 한 줄이 케이스 하나입니다.
{"expected": {"label": false}, "id": "account_000", "input": {"recent_upgrade": true, "support_contacts": 0, "tenure_months": 0}, "metadata": {"plan": "enterprise"}}| 부분 | 형태 | 읽는 쪽 |
|---|---|---|
| input | 함수가 받는 객체 | 어댑터 |
| expected.label | true 또는 false, 정답 | 평가기 |
| metadata.plan | 임의의 JSON | 슬라이스만 |
| 반환된 label | true 또는 false, 예측 | 평가기 |
| 반환된 score | [0, 1] 범위의 숫자, 양성 클래스의 확률 | Brier, 로그 손실, 순위, 보정, 스윕 |
평가기, 그리고 이것을 고른 이유
binary/oloproof.yaml:
version: 1
project: churn-tutorial
dataset: data/accounts.jsonl
system:
name: churn-model
version: baseline
callable: app:run
evaluators:
- {type: predictive_correct, criterion: accuracy}
- {type: predictive_recall, criterion: recall}
- {type: predictive_precision, criterion: precision}
- {type: predictive_brier, criterion: brier}
- {type: predictive_log_loss, criterion: log_loss, clip: 0.02}
- {type: predictive_ranking, criterion: rank}
metrics:
- {id: roc_auc, type: ranking, criterion: rank, statistic: roc_auc}
- {id: pr_auc, type: ranking, criterion: rank, statistic: average_precision}
predictive:
label_field: label
score_field: score
expected_field: label
positive: true
calibration_bins: 10
thresholds: [0.3, 0.4, 0.5, 0.6, 0.7]
slices: [metadata.plan, "confidence:0.5"]
min_slice_support: 20- 정확도, 재현율, 정밀도는 서로 다른 세 행 집합에 대한 세 비율입니다. 모든 계정, 이탈한 계정, 모델이 표시한 계정입니다. 이탈 모델에는 셋 모두가 필요한데, 계정의 약 3분의 1이 이탈하므로 아무도 이탈하지 않는다고 예측하는 모델은 68% 정확하면서 아무도 찾지 못하기 때문입니다.
- Brier와 로그 손실은 레이블 뒤의 확률에 점수를 매깁니다. 로그 손실에는 clip이 필요합니다. 그렇지 않으면 확신에 찬 실수 하나가 무한대가 되기 때문입니다.
- predictive_ranking과 두 metrics: 항목은 ROC-AUC와 평균 정밀도를 줍니다. 이것들은 기준값이 어디에 있는지와 별개로, 모델이 계정의 순서를 얼마나 잘 매기는지에 답합니다.
- predictive: 블록은 레이블, 점수, 정답이 어디 있는지 알려 주고, 지표 옆에 혼동 개수, 보정 표, 임계값 스윕을 만들어 냅니다.
정책
binary/release.yaml은 각 비율에 하한을 둡니다.
version: 1
confidence_level: 0.95
block_on: [FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW]
rules:
- {id: accuracy-floor, metric: accuracy, min: 0.75}
- {id: recall-floor, metric: recall, min: 0.60}
- {id: precision-floor, metric: precision, min: 0.60}규칙은 구간의 하한이 하한값을 넘으면 통과하고, 상한이 그보다 아래면 실패하며, 그 밖에는 INSUFFICIENT_EVIDENCE를 읽습니다.
실행하기
cd binary
oloproof run줄이면 다음과 같습니다.
Run run_... [DECIDED/COMPLETE]
Gate: ALLOW (exit 0)
│ accuracy-floor │ accuracy │ PASS │ lower_bound_meets_minimum │
│ recall-floor │ recall │ PASS │ lower_bound_meets_minimum │
│ precision-floor │ precision │ PASS │ lower_bound_meets_minimum │
│ accuracy │ 88.5% │ [83.2%, 92.6%] │ 177 / 200 observed · 0 missing · 0 excluded │
│ recall │ 81.2% │ [69.5%, 90.0%] │ 52 / 64 observed · 0 missing · 136 excluded │
│ precision │ 82.5% │ [70.9%, 91.0%] │ 52 / 63 observed · 0 missing · 137 excluded │
│ brier │ 0.120 │ [0.094, 0.154] │ mean of 200 observed · 0 missing · 0 excluded │
│ log_loss │ 0.389 │ [0.323, 0.499] │ mean of 200 observed · 0 missing · 0 excluded │
│ roc_auc │ 92.3% │ [69.3%, 100.0%] │ roc_auc over 64 positive · 136 negative · 0 missing · 0 excluded │
│ pr_auc │ 86.5% │ │ average_precision over 64 positive · 136 negative · 0 missing · 0 excluded │읽는 방법은 다음과 같습니다.
- Gate: ALLOW (exit 0)은 어떤 규칙도 정책이 차단하는 상태에 이르지 않았다는 뜻입니다. 여러분이 쓴 세 하한을 넘어 모델이 좋다는 주장이 아닙니다.
- excluded 개수는 분모가 작동하는 모습입니다. 재현율은 이탈한 64개 계정에 대해 측정되므로, 이탈하지 않은 136개는 실패로 세지 않고 제외합니다.
- pr_auc에는 구간이 없습니다. 200행에서 엔진은 뒷받침할 수 없는 경계를 보류합니다. 그 위의 규칙은 interval_unavailable과 함께 INSUFFICIENT_EVIDENCE를 읽을 것입니다.
지표 아래에 같은 출력이 혼동 개수, 보정 표, 임계값 스윕을 출력합니다.
│ actually positive │ 52 │ 12 │
│ actually negative │ 11 │ 125 │
│ 0.2-0.3 │ 26.7% │ 0.0% │ 34 rows │
│ 0.5-0.6 │ 53.4% │ 81.0% │ 21 rows │
│ 0.3 │ 57.4% │ 96.9% │ 62/108 predicted positive · 62/64 actual positive │
│ 0.4 │ 62.6% │ 89.1% │ 57/91 predicted positive · 57/64 actual positive │
│ 0.5 │ 82.5% │ 81.2% │ 52/63 predicted positive · 52/64 actual positive │
│ 0.6 │ 83.3% │ 54.7% │ 35/42 predicted positive · 35/64 actual positive │
│ 0.7 │ 100.0% │ 37.5% │ 24/24 predicted positive · 24/64 actual positive │개수는 비율이 아니며 어떤 규칙도 그것을 지정할 수 없습니다. 보정 행은 모델의 확률이 어긋나 있다고 말합니다. 0.2에서 0.3 구간에서 모델은 네 명 중 한 명꼴로 이탈한다고 주장하지만, 34명 중 아무도 이탈하지 않았습니다. 스윕의 제목은 Thresholds (exploratory; recommends nothing)입니다. 각 기준값이 무엇을 측정했을지 보여 주고 선택은 여러분에게 맡기는데, 놓친 이탈 고객 하나의 비용을 헛된 유지 연락과 비교해 아는 것은 여러분뿐이기 때문입니다.
실패 살펴보기
oloproof inspect RUN_ID --failures --limit 523 of 200 cases failed, errored or did not finish
account_032
output: {"label": false, "score": 0.07}
accuracy: failed
recall: failed
account_037
output: {"label": false, "score": 0.37}
accuracy: failed
recall: failed
...RUN_ID는 실행 출력의 첫 줄에 있는 id입니다. oloproof inspect RUN_ID --case account_037은 케이스 하나의 입력, 기대값, 출력, 모든 판정을 보여 줍니다. 놓친 이탈 고객 여럿이 0.5 기준값 바로 아래(0.37, 0.43)에 있는데, 이는 스윕의 0.4 행이 이미 시사한 것입니다.
의미 있는 다음 조치는 게이트가 아니라 여러분이 본 것에서 나옵니다. 여기서는 놓친 경우가 기준값 아래에 몰려 있으므로, 후보는 더 낮은 기준값을 시도합니다. 확신에 찬 놓침(0.07)이었다면 다음 조치는 모델의 특성이었을 것이며, 어떤 기준값도 도움이 되지 않았을 것입니다.
후보 변경과 비교
binary/candidate.yaml은 두 줄을 바꾼 oloproof.yaml입니다.
system:
name: churn-model
version: candidate-cutoff-0.4
callable: app:run_candidateoloproof run --config candidate.yamlGate: BLOCK (exit 3)
│ accuracy-floor │ accuracy │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │
│ recall-floor │ recall │ PASS │ lower_bound_meets_minimum │
│ precision-floor │ precision │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │
│ accuracy │ 79.5% │ [73.2%, 84.9%] │ 159 / 200 observed · 0 missing · 0 excluded │
│ recall │ 89.1% │ [78.7%, 95.5%] │ 57 / 64 observed · 0 missing · 136 excluded │
│ precision │ 62.6% │ [51.8%, 72.6%] │ 57 / 91 observed · 0 missing · 109 excluded │정확히 스윕의 0.4 행입니다. 재현율은 오르고 정밀도는 내려갑니다. 종료 코드 3은 FAIL이 아니라 INSUFFICIENT_EVIDENCE입니다. 하한값이 구간 안에 있으므로, 계정 200개로는 후보가 어느 쪽에 있는지 말할 수 없습니다. 점수는 바뀌지 않았으므로 Brier, 로그 손실, ROC-AUC는 동일합니다.
이제 두 실행을 케이스별로 비교합니다. binary/comparison.yaml은 비교 규칙을 담습니다.
version: 1
confidence_level: 0.95
block_on: [FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW]
rules:
- {id: recall-no-worse, kind: non_inferiority, metric: recall, margin: 0.05}
- {id: accuracy-no-worse, kind: non_inferiority, metric: accuracy, margin: 0.05}oloproof compare CANDIDATE_RUN_ID BASELINE_RUN_ID --policy comparison.yamlComparison sha256:... of run_... against run_... · 200 paired cases
accuracy: -9.0 points [-17.9, -1.4] · 200 paired · 0 missing · 0 excluded
recall: +7.8 points [-2.8, +21.9] · 64 paired · 0 missing · 136 excluded
excluded 136: not_a_positive_case
precision: +0.0 points [-8.3, +8.3] · 63 paired · 0 missing · 137 excluded
excluded 137: not_predicted_positive
...
Decisions
recall-no-worse recall non-inferiority, margin 5.0 points PASS lower_bound_above_margin
accuracy-no-worse accuracy non-inferiority, margin 5.0 points INSUFFICIENT_EVIDENCE interval_overlaps_margin
no sample size would make this PASS: the difference itself (-9.0 points) is outside the margin, so more cases would move it toward FAIL
Gate: BLOCK (exit 3)정밀도 줄을 주의 깊게 읽으세요. 후보 자체의 정밀도는 82.5%에서 62.6%로 떨어졌는데도, 짝지은 차이는 63쌍에 대해 +0.0입니다. 비교는 행을 짝짓습니다. 정밀도 차이는 두 모델이 모두 표시한 계정에 대해서만 측정되며, 그 63개에서는 둘 다 맞았습니다. 후보가 추가로 표시한 28개 계정, 그중 23개의 오경보는 그 집합 밖에 있습니다. 그래서 comparison.yaml은 기준값 변경에 대해 정밀도가 아니라 정확도를 지킵니다. 규칙 종류는 비교 규칙에 있습니다.
결정이 유용한 부분입니다. 재현율은 나빠지지 않았음이 보였고, 정확도는 5포인트 이내임을 보일 수 없습니다. 조언 줄은 데이터가 더 많으면 그것이 FAIL 쪽으로 갈 것이라고 말합니다. 정확도 9포인트를 재현율 8포인트와 바꿀 가치가 있는지는 게이트가 드러내 보인 비즈니스 결정입니다.
2부: 다중 클래스 분류기, 한 번에 한 클래스씩
multiclass/app.py는 지원 티켓을 세 대기열 중 하나로 보내며, 의도적인 결함이 하나 있습니다. 모바일 앱에서 보낸 티켓은 모두 technical로 갑니다.
@system(name="ticket-router", version="baseline")
def route(ticket):
if ticket["channel"] == "app":
return {"queue": "technical"}
return {"queue": classify(str(ticket["subject"]))}케이스 하나입니다.
{"expected": {"queue": "billing"}, "id": "ticket_000", "input": {"channel": "email", "subject": "update the card on file"}, "metadata": {"channel": "email"}}켤 수 있는 다중 클래스 지표는 없습니다. 각 클래스는 자신의 이진 블록을 받습니다. billing의 재현율은 billing을 양성 클래스로 하는 이진 재현율입니다. multiclass/oloproof.yaml:
evaluators:
- {type: predictive_correct, criterion: accuracy, field: queue, expected_field: queue}
- {type: predictive_recall, criterion: recall_billing, field: queue, expected_field: queue, positive: billing}
- {type: predictive_precision, criterion: precision_billing, field: queue, expected_field: queue, positive: billing}
- {type: predictive_recall, criterion: recall_technical, field: queue, expected_field: queue, positive: technical}
- {type: predictive_precision, criterion: precision_technical, field: queue, expected_field: queue, positive: technical}
- {type: predictive_recall, criterion: recall_account, field: queue, expected_field: queue, positive: account}
- {type: predictive_precision, criterion: precision_account, field: queue, expected_field: queue, positive: account}
slices: [metadata.channel]Oloproof는 이것들에 대한 매크로나 마이크로 평균을 계산하지 않습니다. 필요하다면 클래스별 개수에서 직접 유도하는 숫자이며, 어떤 규칙도 그것으로 게이트할 수 없습니다. 정책은 중요한 클래스에 하한을 둡니다. 라우터는 전체적으로 정확하면서도 대기열 하나를 놓칠 수 있기 때문입니다.
rules:
- {id: billing-recall-floor, metric: recall_billing, min: 0.80}
- {id: account-recall-floor, metric: recall_account, min: 0.80}
- {id: technical-precision-floor, metric: precision_technical, min: 0.80}cd ../multiclass
oloproof runGate: BLOCK (exit 1)
│ billing-recall-floor │ recall_billing │ FAIL │ upper_bound_below_minimum │
│ account-recall-floor │ recall_account │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │
│ technical-precision-floor │ precision_technical │ FAIL │ upper_bound_below_minimum │
│ accuracy │ 81.3% │ [74.1%, 87.3%] │ 122 / 150 observed · 0 missing · 0 excluded │
│ recall_billing │ 66.0% │ [51.2%, 78.8%] │ 33 / 50 observed · 0 missing · 100 excluded │
│ precision_billing │ 100.0% │ [89.4%, 100.0%] │ 33 / 33 observed · 0 missing · 117 excluded │
│ recall_technical │ 100.0% │ [92.8%, 100.0%] │ 50 / 50 observed · 0 missing · 100 excluded │
│ precision_technical │ 64.1% │ [52.4%, 74.7%] │ 50 / 78 observed · 0 missing · 72 excluded │
│ recall_account │ 78.0% │ [64.0%, 88.5%] │ 39 / 50 observed · 0 missing · 100 excluded │
│ precision_account │ 100.0% │ [90.9%, 100.0%] │ 39 / 39 observed · 0 missing · 111 excluded │종료 코드 1은 적어도 하나의 규칙이 FAIL이라는 뜻입니다. 각 클래스에는 자신의 분모가 있습니다. 78개 티켓이 technical로 분류되었으므로, 그것이 technical의 정밀도 분모입니다. 슬라이스 표가 원인을 가리킵니다. 슬라이스는 탐색용이며 게이트하지 않지만, 표시된 슬라이스는 읽어 볼 만한 단서입니다.
│ metadata.channel=app │ accuracy │ 42.9% │ [28.8%, 57.8%] │ 21 / 49 observed · ... │ marked (p 0.0001) │oloproof inspect RUN_ID --failures --limit 228 of 150 cases failed, errored or did not finish
ticket_011
output: {"queue": "technical"}
accuracy: failed
precision_technical: failed
recall_account: failed
...후보(route_candidate, oloproof run --config candidate.yaml로 실행)는 채널 지름길을 없앱니다. 이 합성 데이터에서는 모든 티켓을 올바르게 보내고 게이트는 허용합니다.
Gate: ALLOW (exit 0)
│ billing-recall-floor │ recall_billing │ PASS │ lower_bound_meets_minimum │
│ account-recall-floor │ recall_account │ PASS │ lower_bound_meets_minimum │
│ technical-precision-floor │ precision_technical │ PASS │ lower_bound_meets_minimum │oloproof compare는 여기서도 1부와 똑같이 작동하며, 클래스 지표마다 차이 하나입니다.
3부: 절대 오차로 점수를 매기는 회귀 모델
regression/app.py는 배송 일수를 추정하며, 상품의 재고 여부를 무시합니다.
@system(name="delivery-estimator", version="baseline")
def estimate(order):
return {"days": round(base_days(order), 1)}정답을 숫자로 가진 케이스 하나입니다.
{"expected": {"days": 11}, "id": "order_000", "input": {"distance_km": 468, "express": false, "in_stock": false}, "metadata": {"in_stock": false}}회귀 평가기는 절대 오차 하나뿐이며, 모든 목표값이 놓이는 범위가 필요합니다. 절대 오차는 그 범위 안에서만 구간이 성립하는 경계 있는 평균이므로, 기본값 없이 반드시 선언해야 합니다. 여기서 배송은 0일에서 20일이 걸립니다.
evaluators:
- type: predictive_absolute_error
criterion: days_error
field: days
expected_field: days
target_range: [0, 20]
slices: [metadata.in_stock]정책은 예산, 즉 max: 규칙입니다. 구간의 상한이 그 값 이하이면 통과합니다.
rules:
- {id: error-budget, metric: days_error, max: 2.0}cd ../regression
oloproof runGate: BLOCK (exit 1)
│ error-budget │ days_error │ FAIL │ lower_bound_above_maximum │
│ days_error │ 2.66 │ [2.01, 3.57] │ mean of 120 observed · 0 missing · 0 excluded │
│ metadata.in_stock=false │ days_error │ 5.18 │ [4.60, 6.65] │ mean of 53 observed · ... │
│ metadata.in_stock=true │ days_error │ 0.67 │ [0.51, 2.19] │ mean of 67 observed · ... │구간의 하한조차 이틀 예산보다 위에 있으므로 FAIL입니다. 점수 평가기에는 케이스별 통과나 실패가 없으므로 oloproof inspect RUN_ID --failures는 아무것도 나열하지 않습니다. 대신 케이스를 읽으세요.
oloproof inspect RUN_ID --case order_000output: {
"days": 6.1
}
judgments:
days_error: score 4.9슬라이스가 볼 곳을 알려 줍니다. 재고가 없는 주문은 5일 어긋납니다. 후보(estimate_candidate)는 재고가 없는 상품에 5일을 더합니다.
oloproof run --config candidate.yamlGate: ALLOW (exit 0)
│ error-budget │ days_error │ PASS │ upper_bound_meets_maximum │
│ days_error │ 0.70 │ [0.56, 1.57] │ mean of 120 observed · 0 missing · 0 excluded │문제 해결
| 증상 | 원인과 해결 |
|---|---|
| Configuration error: evaluator 'recall' counts 'churned' as the positive class, and no case's 'label' is 'churned' | positive:가 어떤 케이스에도 없는 값을 지정합니다. true와 "true"의 차이까지 포함해 expected 아래에 나타나는 그대로의 값을 쓰세요. |
| release rule ... refers to unknown metric 'false_positives' | 혼동 개수는 지표가 아닙니다. 재현율이나 정밀도로 게이트하세요. |
| 회귀 평가기가 실행 전에 거부됨 | target_range가 없거나 비어 있습니다. 목표값이 실제로 가질 수 있는 범위를 선언하세요. 범위가 넓으면 구간도 넓어집니다. |
| 순위 규칙이 INSUFFICIENT_EVIDENCE (interval_unavailable)를 읽음 | 스위트가 그 통계량의 구간을 내기에 너무 작습니다. 보통 pr_auc입니다. roc_auc로 게이트하거나 케이스를 추가하세요. |
| 후보가 기준선의 숫자를 보고함 | 두 실행이 version을 공유해서 캐시된 예측이 재사용되었습니다. 모든 변경에 자신의 버전을 주세요. |
| 케이스가 틀린 것이 아니라 missing임 | 함수가 예외를 일으켰거나, 평가기가 읽는 필드가 없거나 숫자가 아닙니다. oloproof inspect RUN_ID --case ID가 오류를 보여 줍니다. |
제한 사항
- 권장 임계값 없음. 스윕은 선언한 각 기준값이 무엇을 측정했을지 보고합니다.
- 다중 클래스에 대한 매크로나 마이크로 평균 지표 없음, 레이블마다 블록 하나를 넘는 다중 레이블 지원 없음.
- 회귀는 선언한 target_range 안의 절대 오차뿐입니다. 제곱 오차, R 제곱, 경계 없는 오차는 없습니다.
- 보정은 표로 보여 줄 뿐, 게이트하지도 교정하지도 않습니다.
- 1부가 보여 주듯, 짝지은 정밀도 차이는 두 모델이 모두 표시한 행만 다룹니다.
- 예제는 결정론적이고 합성입니다. 그 결정은 작동 방식을 보여 줄 뿐, 실제 모델이 실제 데이터에서 어떻게 동작하는지를 보여 주지 않습니다.
다음 단계
- 분류기와 회귀 모델은 필드별 참조입니다.
- 후보를 기준선과 비교하기와 비교 규칙은 비교 작업 흐름을 다룹니다.
- 슬라이스는 confidence: 구간대와 슬라이스 지지도를 다룹니다.
- CI 게이팅은 종료 코드를 나열합니다.