TECH 으로 돌아가기
TECH HACKER NEWS 오늘 7분 읽기 26 READS

LLM에게 신뢰도 점수를 묻지 말아야 하는 이유

LLM 기반 에이전트는 코드를 작성하고 논문을 요약하며 여행 일정을 짜고 양식을 채운다. 적어도 그렇게 하는 것처럼 보인다. 이 능력의 자연스러운 연장선에서 많은 설계자들이 에이전트에게 "이 답변에 얼마나 확신하느냐"를 묻고, 0.85 같은 숫자를 받아 이를 신뢰도 점수로 쓴다. 문제는 그 숫자를 믿을 근거가 사실상 없다는 데 있다. 이 글은 왜 LLM이 내놓는 신뢰도를 그대로 신뢰해서는 안 되는지를 날씨 예보라는 익숙한 비유로 풀어낸다.

신뢰도란 무엇인가

내일 비가 올 확률이 70%라고 말하는 예보관을 생각해 보자. 예보관은 '비가 온다'고 예측하고, 70%는 그 예측에 대한 확신의 정도다. 이 확신은 기분이 아니라 정보에서 나온다. 기압, 습도, 바람, 레이더에 잡힌 구름 같은 내일에 대한 정보와, 과거에 비슷한 날 뒤에 얼마나 자주 비가 왔는지를 담은 수년치 기록이 그것이다. 정보가 많고 한쪽을 강하게 가리킬수록 확신은 100%나 0%에 가까워진다. 이론적으로 이 과정은 의견이 아니라 계산이다. 같은 정보를 가진 두 예보관이 규칙을 올바르게 적용하면 같은 숫자에 도달해야 한다. 아직 2주 뒤의 날에 대해서는 아무 정보가 없으니, 이 계절에 비 오는 날이 30%라면 예보관이 할 수 있는 최선의 말은 "30% 확신한다"뿐이다. 날이 가까워지며 정보가 쌓여야 비로소 숫자가 움직인다.

정확한 신뢰도의 두 조건

하루만으로는 70%가 맞았는지 알 수 없다. 비는 왔거나 안 왔거나 둘 중 하나이기 때문이다. 확인은 여러 날에 걸쳐서만 가능하다. 예보관이 70%라고 말한 모든 날을 모아, 그중 실제로 약 70%에서 비가 왔다면 그 숫자는 정확하다. 40%에서만 왔다면 과신한 것이고, 90%에서 왔다면 과소평가한 것이다. 이렇게 공언한 확신과 실제 발생률이 맞아떨어지는 성질을 보정(calibration)이라 부른다. 다만 보정만으로는 부족하다. 내일 정보를 무시하고 늘 30%라고 말하는 예보관도 연간으로 보면 보정은 맞지만, 정보를 전혀 쓰지 않으니 그 숫자는 아무것도 알려주지 않는다. 좋은 예보는 대부분의 날을 10%나 90% 근처로 보내면서도 보정을 유지한다. 그리고 이 모든 검증은 매번의 예보와 실제 결과를 기록해 두어야만 성립한다. 기록이 없으면 신뢰도의 정확성을 판별할 길이 아예 없다.

LLM의 숫자에는 두 조건이 모두 없다

LLM은 텍스트를 한 토큰씩, 앞선 토큰에 기반해 생성한다. "얼마나 확신하느냐"는 물음에 나오는 0.85는 모델 내부의 계기판에서 읽은 값이 아니라, 대화의 그럴듯한 이어짐으로 쓰인 텍스트일 뿐이다. 그것은 측정이 아니다. 앞 절의 용어로 보면 이 숫자에는 두 성질이 모두 없다. 모델이 가진 정보의 양을 반영하지 못하는데, 증거의 요약이 아니라 문장의 연속이기 때문이다. 또한 한 번도 보정된 적이 없다. 사전학습은 모델을 결과에 대해 채점하지만 그 결과란 '다음 토큰'일 뿐, 모델이 쓴 신뢰도가 실제 정답률과 맞는지는 채점 대상이 아니었다. 모델은 신뢰도 점수가 텍스트에서 어떤 모습인지를 배웠을 뿐, 그 점수를 자기 정확도에 맞추는 법은 배우지 않았다.

그 결과 모델은 언제나 숫자를 주고, 그 숫자는 정밀해 보인다. 틀린 숫자도 맞는 숫자와 똑같이 그럴듯해 보인다. 많은 숫자를 정답지에 대조해 채점하기 전에는 신뢰성을 알 수 없는데, LLM에게 신뢰도를 묻는 대부분의 사람은 그 작업을 하지 않는다. 실무자가 이 점을 특히 경계해야 하는 이유가 여기 있다. 숫자의 존재가 곧 근거의 존재처럼 보이기 때문에, 측정된 적 없는 값이 자동화된 의사결정의 임계값으로 슬그머니 자리 잡기 쉽다.

그렇다면 신뢰도는 어디서 얻는가

해법은 예보관을 따라 하는 것이다. LLM은 여전히 답변 작성 같은 과제를 맡되, 신뢰도는 모델이 아니라 별도의 규칙에서 나오게 한다. 도움말을 검색해 고객 문의에 답하는 에이전트를 예로 들어 보자. 불확실한 답변만 사람에게 넘기고 싶다면, 먼저 모델의 기분을 묻는 대신 관찰 가능한 정보를 고른다. 검색이 관련 문서를 찾았는가, 몇 건인가, 전에 답해 본 유형인가, 같은 질문을 두 번 물었을 때 두 답이 일치하는가. 이것이 에이전트판 기압과 습도와 바람이다. 다음으로 과거에서 출발한다. 사람이 검토한 과거 답변 200건 중 150건이 옳았다면 모든 답변은 75%에서 시작한다.

그리고 모든 답변에 대해 1단계의 정보, 규칙이 매긴 신뢰도, 그리고 실제로 옳았는지를 기록한다. 검토자가 승인했거나 고객이 다시 묻지 않았다면 옳은 것으로 친다. 이 기록을 정보별로 묶어 규칙을 갱신한다. 일치하는 문서가 있고 두 답이 일치한 경우가 95% 옳았다면 다음 같은 답변에는 95%를, 일치 문서가 없을 때 40%만 옳았다면 40%를 부여한다. 매주 예보관과 똑같은 표를 만들어, 90%라고 한 답변이 실제로는 70%만 옳았다면 규칙이 과신하고 있음을 포착해 고친다. 이렇게 만든 규칙은 LLM의 숫자에 없던 성질을 갖는다. 같은 정보는 항상 같은 신뢰도를 내고, 숫자는 표현의 말투가 아니라 정보에 의존하며, 우리 자신의 기록에서 만들어졌으니 우리 질문에 대해 보정되어 있고, 쓸수록 나아진다. 다만 규칙은 기록만큼만 좋다. 아무도 답변의 정답 여부를 확인하지 않으면 배울 재료가 없고, 결국 아무도 측정하지 않은 숫자로 되돌아간다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://rumple.github.io/blog/2026/10/20/asking-llm-for-conf...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...