LLM이 뱉는 신뢰도 점수는 측정값이 아니라 그럴듯한 텍스트다

에이전트를 설계할 때 LLM에게 "이 답에 얼마나 확신하나"를 물어 0에서 1 사이 숫자를 받아 쓰는 방식이 흔히 쓰인다. 요약, 코드 생성, 폼 채우기처럼 다양한 작업을 시키는 김에 확신도까지 받아내는 것이다. 문제는 그 숫자를 신뢰할 근거가 어디에도 없다는 점이다.

LLM은 토큰을 하나씩 이어 붙여 텍스트를 만든다. "0.85"라는 답도 모델 내부의 계기판에서 읽어낸 값이 아니라, 앞선 대화에 이어 붙이기 좋은 다음 조각일 뿐이다. 사전학습 과정에서 모델이 채점받은 대상은 '다음에 올 토큰'이지, '내가 쓴 확신도와 실제 정답률이 일치하는가'가 아니다. 결과적으로 모델은 확신도가 텍스트에서 어떻게 생겼는지는 배웠지만, 자신의 정확도에 맞춰 숫자를 조정하는 법은 배우지 않았다.

이 사실은 몇 가지 간단한 실험으로 바로 드러난다. 같은 질문을 다시 던지면 0.85가 나왔다가 다음에는 0.7이 나온다. 정보가 달라진 게 없는데 숫자가 흔들린다면, 그것은 규칙을 적용한 결과가 아니다. 질문의 표현만 바꿔도 값이 움직이고, 숫자 앞에 "이건 명백히 정답" 같은 문장이 먼저 놓이면 높은 값이 자연스러운 이어짐이 된다. 게다가 모델은 어떤 경우에도 정밀해 보이는 숫자를 내놓기 때문에, 틀린 값과 맞는 값을 겉모습으로 구분할 수 없다.

신뢰도라는 개념 자체를 정의부터 짚어볼 필요가 있다. 일기예보관이 "내일 비 올 확률 70%"라고 할 때, 그 70%는 기압·습도·바람·과거 기상 기록을 종합한 계산의 결과다. 검증은 하루로는 불가능하다. 70%라고 말한 날들을 모아 실제로 그중 70%에서 비가 왔다면 그 숫자는 보정(calibrated)된 것이다. 여기에 조건이 하나 더 붙는다. 매번 30%만 말하는 예보관도 보정은 되지만, 그는 아무 정보도 쓰지 않았으므로 쓸모가 없다. 신뢰도가 쓸 만하려면 정보를 반영해야 하고, 같은 종류의 질문에 대해 실제 결과와 대조 검증된 기록이 있어야 한다. LLM이 내놓는 숫자는 두 조건 모두를 만족하지 못한다.

대안은 예보관이 하는 일을 그대로 따라 하는 것이다. LLM은 답을 쓰게 하되, 신뢰도는 별도의 규칙이 계산한다. 고객지원 에이전트를 예로 들면, 먼저 모델의 기분을 묻지 않고 관측 가능한 특징을 모은다. 검색이 해당 주제 문서를 찾았는지, 몇 건이나 찾았는지, 과거에 다뤄본 유형인지, 같은 질문을 두 번 던졌을 때 두 답이 일치하는지 같은 항목이다. 다음으로 과거 실적을 출발점으로 삼는다. 사람이 검수한 과거 응답 200건 중 150건이 정확했다면 모든 새 응답은 75%에서 시작한다. 이후 응답마다 특징, 규칙이 매긴 신뢰도, 실제로 검수에서 통과됐는지(또는 고객이 다시 묻지 않았는지)를 모두 기록하고, 그 기록을 특징별로 묶어 정답률을 다시 계산하면 규칙이 갱신된다. 문서가 일치하고 두 샘플의 답이 같았던 응답이 95% 정확했다면, 다음 같은 응답에는 95%를 붙인다.

실무적으로 달라지는 것은 에스컬레이션 기준의 근거다. 불확실한 응답을 사람에게 넘기는 임계값을 모델의 자기 보고에 걸어두면, 그 값이 흔들릴 때마다 라우팅이 같이 흔들린다. 반면 관측 특징과 누적 기록으로 만든 규칙은 왜 그 응답이 사람에게 갔는지 설명할 수 있고, 시간이 지날수록 데이터가 쌓여 정확해진다. 대신 로그 수집과 결과 라벨링 파이프라인이 사실상 필수 구성요소가 된다.

주의할 점도 분명하다. 기록 없이는 어떤 신뢰도도 검증할 수 없고, 보정만 잘 맞춰도 정보를 반영하지 않으면 쓸모가 없다. 규칙 기반 방식도 초기에는 과거 평균 정답률이라는 거친 값에서 출발하므로, 데이터가 충분히 쌓이기 전까지는 그 숫자를 맹신해서는 안 된다.