2026년 6월 30일 | 개발 공부
Reliability diagram은 확률 예측을 표 하나로 끝내지 않게 해 주는 그림이다. 모델이 0.8이라고 말한 묶음이 실제로는 0.6만 맞는다면, accuracy 숫자만 보고는 늦게 알아차린다. 전날 Brier score를 보고, 이어서 Expected Calibration Error를 정리하면서 내가 다시 확인한 지점도 여기였다. 평균 점수는 필요하지만, 어느 confidence 구간에서 과신이 벌어졌는지를 눈으로 보는 장치가 없으면 운영 판단이 자꾸 뭉개진다.
나는 calibration 결과를 볼 때 처음부터 복잡한 보정 모델을 고르지 않는다. 먼저 예측 확률을 몇 개 구간으로 나누고, 각 구간의 평균 confidence와 실제 accuracy를 나란히 둔다. 그다음 점들을 대각선 위에 찍는다. 이 단순한 그림이 은근히 많은 말을 해 준다. 숫자 하나로는 “조금 안 맞는다”에 그치던 문제가, 그림에서는 “높은 확신 구간에서 계속 내려앉는다”처럼 구체적인 실패 위치로 바뀐다.
이 과정이 좋은 이유는 설명이 빨라진다는 데도 있다. 모델을 만든 사람과 결과를 쓰는 사람이 같은 표를 보면서, “평균을 더 깎자”가 아니라 “0.8 이상 구간의 자동 통과 기준을 잠깐 멈추자”처럼 행동 단위를 바로 맞출 수 있다.
대각선은 장식이 아니라 기준선이다
Reliability diagram에서 대각선은 “말한 확률만큼 실제로 맞았다”는 기준선이다. confidence가 0.7인 bin의 실제 accuracy도 0.7 근처라면, 그 구간은 대체로 보정이 맞는다. 점이 대각선 아래로 내려가면 모델이 자기 확신보다 덜 맞은 것이고, 위로 올라가면 조심스럽게 말한 것이다. 나는 여기서 아래쪽 gap을 더 먼저 본다. 후속 행동이 사람의 승인, 자동 실행, 검색 결과 노출처럼 이어지는 작업에서는 과신이 보수적 예측보다 더 비싼 오류가 되기 쉽기 때문이다.
특히 LLM 평가에서는 confidence라는 말이 꼭 softmax 확률만 뜻하지 않는다. judge score, ensemble vote ratio, retrieval answer score, reranker 점수도 운영에서는 확률처럼 쓰인다. 그래서 reliability diagram은 엄밀한 분류 모델뿐 아니라, 점수 기반 의사결정이 들어간 평가표 옆에도 붙일 수 있다. “이 점수를 넘기면 자동 통과” 같은 규칙을 만들기 전에, 그 점수 구간이 실제로 어느 정도 맞았는지 확인하는 용도다.
bin을 많이 나눈다고 더 정확해지지는 않는다
처음 이 그림을 만들 때 내가 헷갈렸던 부분은 bin 개수였다. 촘촘하게 나누면 더 정밀해 보이지만, 샘플 수가 적은 bin은 금방 흔들린다. 0.9 이상 구간에 샘플이 7개뿐인데 그중 5개가 맞았다고 해서, 그 구간의 accuracy 0.71을 너무 단정적으로 읽으면 안 된다. 반대로 bin을 너무 크게 잡으면 high-confidence에서 생긴 문제를 중간 구간이 덮어 버린다.
그래서 작은 실험에서는 bin별 샘플 수를 꼭 같이 남긴다. 그림 위에 막대나 숫자로 표기해도 되고, 표를 따로 둬도 된다. 내가 선호하는 최소 기록은 confidence range, sample count, mean confidence, accuracy, gap 다섯 칸이다. 이 다섯 칸이 있으면 나중에 ECE가 낮아진 이유가 정말 보정 개선인지, 아니면 bin 구성이 우연히 좋아 보인 것인지 다시 볼 수 있다.
ECE 숫자만 남기면 원인을 잃는다
Expected Calibration Error는 bin별 gap을 샘플 비율로 가중해 합친 값이라 요약 지표로 좋다. 문제는 좋은 요약일수록 원인을 접어 버린다는 점이다. 두 모델의 ECE가 비슷해도 하나는 전 구간에서 조금씩 어긋나고, 다른 하나는 0.9 이상 confidence 구간에서만 크게 무너질 수 있다. 배포 관점에서는 두 번째 모델이 더 부담스럽다. 사람이 “모델이 0.95라고 했으니 믿어도 되겠지”라고 받아들이는 순간이 바로 그 구간에 있기 때문이다.
Brier score도 마찬가지다. Brier score는 개별 확률과 실제 결과의 제곱 거리라 평균적인 확률 품질을 잘 보여 준다. 하지만 어떤 confidence 구간에서 거리가 벌어졌는지까지 바로 말해 주지는 않는다. 그래서 나는 calibration을 볼 때 Brier score, ECE, reliability diagram을 세트처럼 둔다. 하나는 거리, 하나는 평균 gap, 하나는 위치다. 셋 중 하나만 보면 자꾸 해석이 빨라진다.
평가표에 붙일 때의 작은 기준
실무 평가표에 reliability diagram을 붙일 때는 그림을 예쁘게 만드는 것보다 재현 조건을 남기는 쪽이 더 중요했다. bin 경계는 미리 정했는지, validation set에서 봤는지 test set에서 봤는지, confidence 값은 raw score인지 temperature scaling 뒤인지가 같이 있어야 한다. 같은 그림이라도 이 조건이 빠지면 다음 사람이 다시 열었을 때 “그래서 이 gap을 믿어도 되나?”부터 묻게 된다.
또 하나는 slice다. 전체 reliability diagram은 괜찮아 보여도 특정 언어, 특정 길이, 특정 retrieval 난이도에서만 과신이 튀어나올 수 있다. 모든 slice를 다 그리자는 뜻은 아니다. 다만 자동 승인이나 사용자 노출처럼 비용이 큰 구간은 별도 slice로 한 번 더 확인하는 편이 낫다. 평균 그림 한 장으로 배포 결정을 닫지 않겠다는 안전장치에 가깝다.
내가 남기는 결론
Reliability diagram을 만들고 나면 모델이 틀렸다는 말보다 더 구체적인 질문이 남는다. “어느 confidence 구간에서 틀렸나”, “그 구간의 샘플 수는 충분한가”, “그 gap이 실제 운영 행동을 바꿀 만큼 큰가” 같은 질문이다. 이 정도로 좁혀 두면 다음 단계도 덜 흐려진다. temperature scaling을 볼지, threshold를 낮출지, 특정 slice의 데이터를 다시 볼지 판단할 수 있다.
나는 확률 예측을 볼 때 이제 평균 점수 옆에 작은 그림 하나를 더 요구하는 쪽으로 마음이 기울었다. 그림 하나가 문제를 해결해 주지는 않지만, 과신이 어디서 생겼는지 숨기지는 않는다. 평가표가 길어지는 것보다 더 피하고 싶은 건, 모델이 높은 확률로 틀리는 구간을 평균 점수 안에 묻어 둔 채 다음 실험으로 넘어가는 일이다.
'[개발 공부]' 카테고리의 다른 글
| Precision-Recall Curve: 희소 양성 데이터의 점수표 (0) | 2026.07.02 |
|---|---|
| Log loss: 틀린 확신의 비용 (0) | 2026.07.01 |
| Expected Calibration Error: 확률 구간별 과신 (0) | 2026.06.30 |
| 원자적 파일 교체와 절반짜리 결과 파일 (0) | 2026.06.29 |
| Brier score: 확률 예측의 거리 (0) | 2026.06.29 |