Log loss: 틀린 확신의 비용

2026년 7월 1일 | 개발 공부

---

Log loss는 모델이 정답 class에 준 확률을 음의 로그로 바꿔 평균내는 평가 지표다. Negative log likelihood, 줄여서 NLL이라고 부르는 경우도 많다. 이름만 보면 통계 교과서 쪽으로 멀어 보이지만, 내가 실험 로그에서 쓰는 감각은 단순하다. 모델이 틀렸을 때 그냥 틀렸다고만 적지 않고, 얼마나 자신 있게 틀렸는지까지 비용으로 남기는 점수다.

Figure 1. 정답 class에 준 확률이 낮아질수록 log loss는 완만하게가 아니라 급격히 커진다.

전날까지 Brier score, Expected Calibration Error, reliability diagram을 이어서 봤다. 셋은 모두 확률 예측을 accuracy 밖으로 끌어내는 도구였다. Log loss도 같은 가족에 놓을 수 있다. 다만 결이 조금 다르다. Brier score가 확률과 결과 사이의 제곱 거리라면, log loss는 정답에 낮은 확률을 준 순간 더 세게 벌점을 준다. 특히 0.9로 틀린 예측과 0.55로 틀린 예측을 같은 오답으로 취급하지 않는다.

정답 확률 하나만 본다

분류 모델이 각 class에 확률을 내놓으면 log loss는 그중 실제 정답 class에 할당된 확률만 집어 본다. 정답 class 확률이 0.9면 손실은 작고, 0.1이면 손실은 크다. 식으로 쓰면 -log(p)인데, 여기서 p는 정답 class에 준 확률이다. 수식 자체보다 중요한 건 방향이다. 모델이 정답을 높은 확률로 밀면 비용이 줄고, 정답을 낮게 밀어내면 비용이 커진다.

이 방식은 accuracy와 다르게 움직인다. 어떤 샘플에서 모델 A는 정답 class에 0.49를 주고 다른 class에 0.51을 줘서 틀렸고, 모델 B는 정답 class에 0.01을 주고 다른 class에 0.99를 줘서 틀렸다고 해 보자. accuracy에서는 둘 다 오답 1개다. 하지만 실제 운영에서는 두 오답의 의미가 다르다. A는 거의 맞힐 뻔한 애매한 판단이고, B는 정답을 거의 배제한 강한 오판이다. Log loss는 이 차이를 숫자에 남긴다.

높은 확신의 오답을 크게 본다

내가 log loss를 보는 가장 큰 이유는 high-confidence mistake를 숨기지 않기 위해서다. 모델이 0.99라고 말한 답이 틀렸다면, 그건 단순히 한 문제를 틀린 것이 아니다. 그 확률을 기준으로 자동 승인, 상단 노출, 후속 검색 생략 같은 행동이 붙을 수 있기 때문이다. 이때 accuracy만 보면 “전체적으로 92% 맞았다”에서 멈추기 쉽다. Log loss는 그 안에 섞인 과한 확신을 평균 점수에 강하게 반영한다.

물론 이 성질이 늘 편한 것은 아니다. 데이터에 라벨 노이즈가 있거나, 애초에 정답 경계가 흐린 문제에서는 log loss가 몇 개의 극단 샘플에 민감하게 흔들린다. 그래서 나는 log loss가 크게 튀면 먼저 모델이 망했다고 결론내리지 않는다. 해당 샘플을 열어 보고, 라벨이 이상한지, class 정의가 겹치는지, 데이터 전처리에서 누락된 정보가 있는지 먼저 본다. 점수 하나가 커졌다는 사실보다, 큰 비용을 만든 샘플의 모양이 더 중요할 때가 많았다.

Brier score와 같이 보면 역할이 갈린다

Brier score와 log loss는 둘 다 확률 예측을 평가하지만 벌점 곡선이 다르다. Brier score는 p와 y 사이의 제곱 거리라서 비교적 완만하다. Log loss는 p가 0에 가까워질수록 급하게 커진다. 그래서 같은 모델을 두 지표로 보면, “전체 확률 거리는 괜찮은데 몇 개의 자신 있는 오답이 너무 크다” 같은 상황을 분리할 수 있다.

나는 이 둘을 경쟁 지표처럼 놓지 않는 편이다. Brier score는 calibration 전체 감각을 보기에 좋고, log loss는 probability model이 정답 후보를 얼마나 잔인하게 밀어냈는지 보기에 좋다. 여기에 reliability diagram을 붙이면 어느 confidence 구간에서 비용이 생겼는지도 보인다. 결국 한 숫자가 정답이라기보다, 평균 거리, 극단 오답, 구간별 과신을 나눠 보는 셋업이 더 안전하다.

한 번 더 좁혀 보려면 평균 log loss만 보지 말고 샘플별 loss 상위 목록을 따로 뽑는다. 평균은 좋아졌는데 상위 10개 손실이 더 커졌다면, 모델은 전반적으로 나아졌지만 특정 slice에서 더 위험해졌을 수 있다. 반대로 상위 손실이 줄었는데 평균이 비슷하면, 극단 오답은 줄었지만 중간 confidence 구간이 넓게 흔들리는 신호일 수 있다.

LLM 평가에서도 바로 붙일 수는 없다

LLM 작업에 log loss를 붙일 때는 조심할 점이 있다. 객관식 문제처럼 후보 class가 고정되어 있고 각 후보의 확률을 안정적으로 뽑을 수 있으면 해석이 비교적 선명하다. 하지만 자유 생성 답변에서는 토큰 확률, 정답 문자열, paraphrase, 길이 차이가 모두 섞인다. 답은 맞았는데 표현이 달라서 확률이 낮게 보이거나, 반대로 흔한 문구라 확률은 높은데 내용은 틀릴 수 있다.

그래서 나는 log loss를 LLM에 쓸 때 먼저 평가 단위를 좁힌다. 예를 들어 binary judge, multiple-choice routing, retrieval answer accept/reject처럼 class가 작고 명확한 작업에 먼저 붙인다. 생성 품질 전체를 log loss 하나로 재단하기보다, 모델이 선택해야 하는 좁은 결정 지점에서 “정답 class를 어느 정도 확률로 밀었는가”를 본다. 이렇게 하면 지표가 말하는 범위와 실제 판단 범위가 덜 어긋난다.

실험표에 남길 때의 최소 메모

Log loss를 실험표에 넣을 때 나는 세 가지를 같이 적는다. 첫째, class imbalance와 label noise가 어느 정도인지. 둘째, 극단적으로 큰 loss를 만든 샘플 몇 개의 id. 셋째, 같은 결과를 Brier score나 reliability diagram으로 봤을 때도 같은 신호가 보이는지. 이 세 줄이 없으면 log loss는 쉽게 “낮을수록 좋음”이라는 칸 하나로 납작해진다.

확률 예측을 쓰는 모델은 결국 숫자로 행동을 움직인다. threshold를 넘기면 통과시키고, confidence가 낮으면 사람에게 넘기고, 상위 후보만 다음 단계로 보낸다. Log loss는 그 숫자가 틀렸을 때의 책임을 조금 더 날카롭게 기록한다. 나는 이 지표를 볼 때마다 accuracy 옆에 작은 주석을 하나 더 붙이는 느낌이 든다. “맞았나”만 보지 말고, 틀렸다면 얼마나 확신하며 틀렸는지까지 같이 보자는 주석이다.