당신의 AI 모델의 신뢰도 점수(Confidence Score)가 아마도 거짓말을 하고 있는 이유 (그리고 해결 방법)

실제로 이러한 모델들을 배포하는 개발자들을 위해, 프로덕션 환경에서 현대적 AI를 망가뜨리는 데이터 분포 변화(Distribution shift) 문제를 설명합니다.

당신은 모델을 학습시켰습니다. 지표(Metrics)는 훌륭해 보였습니다. 당신은 모델을 배포했습니다. 6개월 후, 무언가 조용히 잘못되고 있지만 당신의 정확도 대시보드는 정상으로 보입니다.

무슨 일이 일어난 걸까요?

만약 당신이 대규모로 현대적인 AI 시스템을 운영하고 있다면, 특히 Mixture-of-Experts (MoE) 아키텍처를 사용하는 시스템이라면, 모델의 신뢰도 점수(Confidence scores)가 현실과 어긋나게 표류(drift)했을 가능성이 높습니다. 모델의 예측 능력이 떨어졌기 때문이 아닙니다. 오류나 경고 없이, 조용히 보정(Calibration)이 깨졌기 때문입니다.

이 포스트에서는 그것이 무엇을 의미하는지, 왜 특히 MoE 모델에서 발생하는지, 그리고 개발자로서 무엇을 할 수 있는지 설명합니다.

빠른 용어 체크

본격적으로 시작하기 전에, 알아야 할 두 가지 용어가 있습니다:

보정 (Calibration): 만약 모델이 "80% 확신합니다"라고 말한다면, 모델이 그렇게 말할 때마다 80%의 확률로 정답을 맞춰야 합니다. 보정된(Calibrated) 모델의 신뢰도 점수는 정직한 확률 추정치입니다. 보정되지 않은(Uncalibrated) 모델의 신뢰도 점수는 기본적으로 노이즈에 불과합니다.

분포 변화 (Distribution shift): 모델이 프로덕션 환경에서 마주하는 데이터는 학습할 때 사용한 데이터와 동일하지 않습니다. 입력값의 분포(Distribution)는 시간이 지남에 따라 표류합니다. 이것은 예외적인 사례가 아니라, 배포된 모든 모델의 정상적인 상태입니다.

아키텍처: Mixture-of-Experts (MoE)

오늘날 대부분의 대규모 AI 모델은 MoE를 사용합니다. 개념은 간단합니다:

• 하나의 거대한 네트워크 대신, 전문가(experts)라고 불리는 많은 전문화된 서브 네트워크(sub-networks)를 가집니다.
• 라우터(router)가 각 입력을 살펴보고 어떤 전문가(들)가 이를 처리할지 결정합니다.
• 이를 통해 연산량(compute)을 선형적으로 늘리지 않고도 모델 용량(capacity)을 확장할 수 있습니다.

라우팅의 두 가지 방식:

하드 라우팅 (Hard Routing): 입력 → 라우터 → 단 하나의 전문가 → 출력
소프트 라우팅 (Soft Routing): 입력 → 라우터 → 여러 전문가의 가중치 혼합 (weighted blend) → 출력

소프트 라우팅은 표현력이 더 뛰어납니다. 또한 보정(Calibration)이 복잡해지는 지점이기도 합니다.

문제점: 완벽하게 보정된 전문가들, 깨져버린 집계(Aggregate)

다음은 모든 ML 엔지니어가 우려해야 할 시나리오입니다.

당신의 MoE (Mixture of Experts)에 있는 모든 전문가(Expert)가 개별적으로 잘 보정(Well-calibrated)되어 있다고 가정해 봅시다. 전문가 A가 0.8이라고 말하면, 그것은 80%의 확률로 맞습니다. 전문가 B, 전문가 C도 마찬가지입니다.

당신은 결합된 모델(Combined model) 또한 잘 보정되어 있을 것이라고 가정할 수도 있습니다.

하지만 분포 변화 (Distribution shift) 상황에서는 그렇지 않습니다.

그 이유는 다음과 같습니다.

소프트 라우팅 (Soft routing)을 사용할 때, 최종 예측값은 다음과 같습니다:

f(x) = r1(x) * f1(x) + r2(x) * f2(x) + ... + rK(x) * fK(x)

여기서 r1, r2, ...rK는 라우팅 가중치 (Routing weights)이고, f1, f2, ...fK는 전문가의 예측값 (Expert predictions)입니다.

동일한 최종 점수(예: 0.75)가 완전히 다른 구성(Configuration)으로부터 나올 수 있습니다:

Config A: r1=0.9, f1=0.75, r2=0.1, f2=0.75  → f(x) = 0.75
Config B: r1=0.5, f1=0.9,  r2=0.5, f2=0.6   → f(x) = 0.75
...

학습 분포 (Training distribution) 상에서 이러한 구성들은 특정 비율로 실행됩니다. 그 비율들이 보정 (Calibration)이 작동하도록 만듭니다. 즉, 편차들이 서로 상쇄되어 0.75가 결과적으로 75%의 확률로 맞게 됩니다.

그러다 분포 변화 (Distribution shift)가 발생합니다.

새로운 데이터는 다양한 유형의 입력이 나타나는 빈도를 변화시킵니다. 서로 다른 라우팅 구성들이 실행되는 비율도 달라집니다. 보정의 균형을 맞추어 주었던 그 비율들이 더 이상 유지되지 않습니다.

이제 모델이 0.75라고 말할 때, 그것은 아마도 58%의 확률로만 맞거나, 혹은 91%의 확률로 맞을 수도 있습니다. 신뢰도 점수 (Confidence score)는 신뢰할 수 없게 되었지만, 외부에서는 이를 쉽게 알 수 있는 방법이 없습니다.

하드 라우팅 (Hard routing)이 이 문제를 겪지 않는 이유

하드 라우팅 (Hard routing)을 사용하면, 각 입력은 정확히 하나의 전문가에게 전달됩니다. 당신의 집계된 예측값 (Aggregate prediction)은 단순히 그 전문가의 예측값일 뿐입니다. 전체 라우팅 정보는 (어떤 전문가인가, 신뢰도는 얼마인가)라는 단순한 쌍으로 축소됩니다.

만약 전문가 2가 0.75라고 말하고 전문가 2가 잘 보정되어 있다면, 테스트 분포 (Test distribution)가 학습 분포 (Training distribution)보다 전문가 2에게 더 많거나 적은 입력을 보내더라도 0.75는 신뢰할 수 있습니다.

하드 라우팅은 이 특정 차원에서 분포 변화 (Distribution shift)에 더 견고 (Robust)합니다. 트레이드오프 (Tradeoff)는 표현력 (Expressiveness)입니다. 하드 라우팅은 여러 전문가의 지식을 진정으로 혼합해야 하는 경우를 포착할 수 없습니다.

상황이 얼마나 나빠질 수 있을까요?

이러한 실패는 특히 다음과 같은 취약한 구성(fragile configurations)을 유발하는 입력값에서 가장 심각하게 나타납니다:

• 여러 전문가가 상당한 라우팅 가중치(routing weight)를 받는 경우 (특정 전문가 한 명에 의해 지배되지 않는 경우)
• 해당 전문가들의 예측이 크게 상충하는 경우
• 따라서 집계된 예측(aggregate prediction)이 정확한 라우팅 가중치에 크게 의존하게 되는 경우

이러한 사례들은 데이터 분포의 미세한 변화 — 정답이 무엇인지나 전문가의 행동을 바꾸지는 않지만, 특정 입력 유형이 나타나는 빈도만 바꾸는 변화 — 가 신뢰할 수 있는 보정(calibration) 상태를 쓸모없는 상태로 뒤집어버릴 수 있는 경우들입니다.

그리고 이것들은 바로 여러분에게 신뢰할 수 있는 불확실성 추정치(uncertainty estimates)가 가장 절실히 필요한 종류의 입력값들입니다. 전문가들이 동의한다면 이미 신호(signal)를 얻은 셈입니다. 하지만 전문가들이 의견이 일치하지 않아 집계된 결과가 가이드를 제공해야 할 때, 바로 그때 보정(calibration)의 신뢰도가 가장 낮아지는 경향이 있습니다.

해결책: 훈련 중 적대적 재가중치 부여 (Adversarial Reweighting During Training)

해결 방법은 모델이 단순히 평균적인 훈련 분포(training distribution)뿐만 아니라, 해당 분포의 스트레스 테스트 버전(stressed versions)에서도 보정되도록 훈련하는 것입니다.

핵심 통찰: 모델의 손실(loss)이 높은 예시들은 취약한 구성(fragile configurations)을 나타내는 대리 지표(proxy)입니다. 이는 라우팅 가중치가 불안정한 균형을 만드는 예시들입니다. 손실이 높은 예시들을 강조하는 적대적으로 재가중치 부여된 분포(adversarially reweighted distributions)를 대상으로 훈련하면, 모델이 필요한 부분에서 더 견고(robust)해집니다.

실제로는 훈련 중에 지수적 기울기(exponential tilt)를 사용하는 것을 의미합니다:

# Robust MoE 훈련 목적 함수의 개념적 구현
def robust_moe_loss(losses, eta=1.0):
    """...

또한, 라우팅과 관련된 예시들에만 재가중치를 적용하는 'Robust Filtered'라고 불리는 더 표적화된 변형 방식도 있습니다. 구체적으로는 다음과 같습니다:

• 혼합된 예측(blended prediction)이 개별 전문가 중 최선의 예측보다 나쁜 예시
• 전문가들이 집계된 예측(aggregate prediction)을 중심으로 크게 의견이 일치하지 않는 예시

def robust_filtered_loss(losses, predictions, expert_predictions, routing_weights, eta=1.0):
    """
    라우팅 관련 예시에 대해서만 강건한 재가중치(robust reweighting)를 적용합니다.
...```

두 접근 방식 모두 유의미한 정확도 손실 없이 분포 변화(distribution shift) 상황에서 보정-정확도 트레이드오프(calibration-accuracy tradeoff)를 일관되게 개선합니다.

개발자로서 지금 당장 할 수 있는 일

오늘 당장 모델을 재학습시키지 못할 수도 있습니다. 즉시 실행할 수 있는 방법은 다음과 같습니다:

1. 평가 파이프라인(eval pipeline)에 보정 모니터링(calibration monitoring) 추가

```python
import numpy as np

def expected_calibration_error(y_true, y_prob, n_bins=10):
...

2. 신뢰도 도표(reliability diagrams)를 정기적으로 시각화

import matplotlib.pyplot as plt
from sklearn.calibration import calibration_curve

...

과잉 확신(overconfidence)을 향해 표류하는 모델은 대각선 아래로 휘어지는 곡선을 보여줍니다. 이를 조기에 포착하세요.

3. 입력 분포 드리프트(input distribution drift) 추적

from scipy.stats import ks_2samp

def detect_distribution_shift(train_features, current_features, threshold=0.05):
...

4. 빠른 사후 교정(post-hoc fix)을 위해 온도 스케일링(temperature scaling) 사용

재학습을 할 수 없는 경우, 온도 스케일링은 배포 후 모델을 재보정(recalibrate)하는 가장 빠른 방법입니다:

import torch
import torch.nn as nn

...

참고: 온도 스케일링은 평균적으로는 도움이 되지만, 분포 변화(distribution shift)로 인한 특정 하위 집합(subset-specific)의 보정 실패 문제는 해결하지 못합니다. 이는 임시방편(patch)이지 근본적인 해결책(solution)은 아닙니다.

요약

라우팅 유형	변화 상황에서의 보정(Calibration)	이유
Hard routing	강건함(Robust) ✅	보정이 (전문가, 신뢰도) 쌍에만 의존함
Soft routing	취약함(Fragile) ⚠️	서로 다른 설정들이 동일한 점수로 붕괴됨; 변화가 그 균형을 바꿈

해결책: 적대적 재가중치(adversarial reweighting) (Robust MoE 또는 Robust Filtered)를 사용하여 모델이 가장 어려운 예시들에 대해 스트레스를 받도록 학습시키세요. 최소한, 운영 환경(production)에서 ECE와 분포 변화(distribution shift)를 모니터링하십시오.

더 깊은 교훈: 보정(calibration)은 시스템 수준의 속성입니다. 보정된 부분들이 자동으로 보정된 전체를 구성하지는 않습니다. 특히 분포 변화(distribution shift)가 그 부분들이 상호작용하는 방식을 바꿀 때는 더욱 그렇습니다.

운영 환경에서 캘리브레이션 드리프트 (calibration drift)를 경험해 보신 적이 있나요? 어떤 모니터링 설정이 효과적이었나요? 댓글로 공유해 주세요.