흔히 하는 실수
LLM으로 문의 분류나 문서 정보 추출 파이프라인을 만들다 보면 이런 프롬프트를 쓰고 싶어져요. '답과 함께 0~100 사이의 확신도(confidence)도 출력해줘.' 그리고 80점 이상이면 자동으로 처리하고, 그보다 낮으면 사람이 검토하도록 분기를 걸죠. 꽤 그럴듯해 보이는데요, 이번에 공개된 글은 제목 그대로 LLM에게 확신도를 직접 물어서 점수로 쓰는 건 나쁜 아이디어라고 주장해요. 왜 그런지, 대신 뭘 써야 하는지 하나씩 풀어볼게요.
말로 한 확신도는 '측정값'이 아니라 '생성된 텍스트'예요
핵심은 이거예요. LLM이 '확신도: 85'라고 출력할 때, 모델이 속으로 자기가 맞을 확률을 계산해서 알려주는 게 아니에요. '이런 맥락 뒤에는 이런 숫자가 나오는 게 자연스럽다'는 패턴을 따라 숫자처럼 생긴 토큰을 생성한 거예요. 시험지에 '자신감: 상/중/하'를 적으라고 하면 학생이 대충 분위기 보고 적는 거랑 비슷해요.
이 문제를 이해하려면 '캘리브레이션(calibration)'이라는 개념을 알아두면 좋아요. 이게 뭐냐면, 모델이 말한 확률이 실제 정답률과 얼마나 맞아떨어지는지를 말해요. 일기예보에서 '비 올 확률 70%'라고 한 날들을 모아봤더니 실제로 그중 70% 정도 비가 왔다면 잘 보정된 예보예요. LLM도 마찬가지로, '80% 확신'이라고 한 답들 가운데 실제로 80% 정도가 맞아야 그 숫자를 믿을 수 있어요.
그런데 여러 연구를 보면 LLM이 말로 표현하는 확신도는 대체로 과신(overconfidence) 쪽으로 치우쳐 있었어요. 숫자도 80, 90, 95 같은 특정 값에 몰리는 경향이 보고됐고, 틀린 답에 높은 점수를 붙이는 일도 흔해요. OpenAI의 GPT-4 기술 보고서에는 사전학습만 끝낸 모델은 꽤 잘 보정돼 있었는데, 사람 피드백 기반 강화학습(RLHF)을 거친 뒤에는 보정이 나빠졌다는 그래프가 실리기도 했어요. 사람이 좋아하는 '자신감 있는 답변'을 배울수록 숫자도 낙관적으로 변하는 거예요. 게다가 같은 질문이어도 점수 범위를 0~1로 주는지 0~100으로 주는지, 답을 먼저 쓰게 하는지 확신도를 먼저 쓰게 하는지에 따라 값이 달라질 수 있어요. 그래서 기준점으로 삼기엔 불안정해요.
그럼 대신 뭘 써야 할까요
첫째, 토큰 확률(logprobs)이에요. API가 지원한다면 모델이 실제로 각 토큰에 매긴 확률을 볼 수 있어요. 분류처럼 답이 짧은 작업이라면 정답 라벨 토큰의 확률이 말로 한 숫자보다 훨씬 정직한 신호예요. 다만 답이 긴 생성형 작업에는 적용하기 어렵다는 한계가 있어요.
둘째, 자기 일관성(self-consistency)이에요. 같은 질문을 temperature를 높여서 5~10번 돌려보고, 답이 얼마나 일치하는지 보는 방법이에요. 10번 모두 같은 답이면 믿을 만하고, 4:3:3으로 갈리면 사람이 봐야 해요. 비용은 늘지만 구현이 쉽고 효과도 좋아요. 이걸 한 단계 발전시킨 게 '의미 엔트로피(semantic entropy)'예요. 표현은 달라도 의미가 같은 답끼리 묶어서 불확실성을 재는 방식인데, 2024년 Nature에 관련 연구가 실렸어요.
셋째, 별도의 검증 단계예요. 다른 모델이나 프롬프트로 답을 교차 검증할 수도 있고, 추출한 값이 원문에 정말 있는지, JSON 스키마에 맞는지 같은 규칙 기반 체크를 붙일 수도 있어요.
그리고 어떤 신호를 쓰든 결국 정답이 있는 검증 데이터로 보정해야 해요. '이 점수 이상일 때 실제 정확도가 몇 %인지'를 재보고, 자동 처리 기준선도 감이 아니라 그 데이터로 정해야 해요.
공정하게 보면
반론도 있어요. 2023년에 나온 'Just Ask for Calibration' 연구처럼, RLHF를 거친 모델에서는 말로 물어본 확신도가 오히려 토큰 확률보다 나았다는 결과도 있거든요. 그러니 이 논쟁에서 얻을 교훈은 '절대 쓰지 마라'라기보다 검증 없이 그 숫자를 그대로 믿지 마라에 가까워요. 확신도를 받더라도 여러 신호 중 하나로만 다루고, 실제 정답률과 비교해서 보정 곡선을 그려보는 게 맞아요.
한국 개발자에게 주는 시사점
요즘 국내에서도 고객 문의 분류, 계약서·영수증 정보 추출, 콘텐츠 검수 같은 곳에 LLM을 붙이면서 '확신도가 높으면 자동, 낮으면 사람' 구조를 많이 만들어요. 그런데 JSON 출력에 confidence 필드 하나 넣고 끝내는 경우가 정말 많아요. 정답 데이터를 최소 수백 건 만들어서, 확신도 90 이상이 나온 건들의 실제 정확도를 한번 재보세요. 생각보다 낮게 나온다면, 거기서부터가 진짜 설계의 시작이에요.
마무리
한줄 정리: LLM이 말하는 확신도는 측정값이 아니라 생성된 텍스트예요. 쓰고 싶다면 반드시 실제 정답률로 검증하세요.
여러분은 LLM 출력을 얼마나 믿을지 어떻게 판단하고 계신가요? self-consistency나 logprobs를 실서비스에 적용해본 경험이 있다면 공유해주세요.
🔗 출처: Hacker News