요약
LLM이 말하는 신뢰도 숫자는 측정값이 아니라 그럴듯하게 이어 쓴 글자일 뿐입니다.
개발자 암루트 조시가 블로그에 쓴 글입니다. 에이전트를 만드는 사람들이 LLM에게 신뢰도 점수를 직접 묻는 일이 흔해지자, 그 숫자를 믿을 근거가 없다고 지적했습니다.
왜 중요한가
- 사람 검토로 넘길 답을 LLM의 자기 평가로 고르면, 틀린 답도 높은 점수를 받고 그대로 통과할 수 있습니다.
- 신뢰도는 모델에게 물어서 얻는 값이 아니라 결과 기록으로 검증해야 하는 값이라는 점을 짚었습니다.
핵심 내용
- LLM은 다음 토큰을 맞히도록 학습했을 뿐, 말한 신뢰도가 실제 정답률과 맞는지로 평가받은 적이 없다고 했습니다.
- 같은 질문을 다시 하거나 "확실해?"라고 되물으면 정보가 그대로인데도 숫자가 바뀝니다.
- 앞에서 "명백히 정답"이라고 썼다면 높은 점수가 가장 자연스러운 다음 말이 됩니다.
- 좋은 신뢰도는 보정(말한 확률과 실제 빈도가 맞는 성질)이 되어 있으면서 0%나 100% 쪽으로 갈라져야 한다고 했습니다.
- 대안으로 검색 결과 일치 같은 관찰 가능한 신호로 규칙을 만들고, 실제 결과를 기록해 주기적으로 보정하자고 제안했습니다.
HN 반응
- 0~100 척도로 묻는 방식이 문제일 뿐 채점 기준표를 주면 잘 매긴다는 반론에, 그건 사람이 기준을 잘 짠 덕이라는 재반론이 나왔습니다.
- 데이터 없이 주장만 한다는 지적도 있었고, 일부 이용자는 브라이어 점수(확률 예측의 오차 지표) 벌점으로 보정을 학습시키는 연구를 소개했습니다.
물론 LLM에는 자기 확신도에 대한 잠재적 개념이 있고, 그 개념은 내부적으로 일관되며, 그걸 완벽하게 말로 표현할 수도 있습니다. 글쓴이가 물어보는 방식을 최악으로 골랐을 뿐이에요. 무엇이든 0~100 척도로 매기는 건 LLM에게나 사람에게나 나쁜 생각입니다. 0~100으로 점수를 매기게 하는 대신, 문제를 여러 차원/축으로 쪼개서 각각에 작고 의미 있는 열거형이나 덜 세분화된 숫자 척도(가장 좋은 건 이진 선택)를 주세요. 그런 다음 결과에 가중치를 적용해 점수를 내면 됩니다. 이렇게 하면 확신도를 의미 있게 표현하는 능력이 훨씬 좋아져서 놀라실 겁니다.
유튜브가 1~5점 척도를 없앤 것도 같은 이유입니다. 사람들은 그걸 어떻게 써야 할지 몰라요.
저도 이 주장의 출처를 알고 싶습니다. "LLM에는 내부적으로 일관된, 자기 확신도에 대한 잠재적 개념이 있다"는 말은 사실이라고도, 근거가 있다고도 생각하지 않습니다.
LLM은 일반적으로 자기 활성화 함수의 출력을 보고할 수 없습니다. softmax 출력을 확률 점수로 받아들이는 건 박사과정 1학년생이 흔히 하는 오해로 통합니다.
리커트 척도와 평가 기준표(rubric)를 주면 대체로 꽤 괜찮게 해냅니다. 확신도 점수와 똑같은 건 아니고 보정(calibration)도 전혀 안 되어 있겠지만, 사용자에게는 오히려 그쪽이 나을 수 있어요.
연속 척도나 아주 세분화된 이산 척도로 된 확신도 점수는 스큐어모피즘(skeuomorphism)이라고 볼 여지가 있습니다. 정말로 그게 필요했던 건지, 아니면 회귀 계열 모델을 다뤘던 경험 때문에 익숙해서 그런 건 아닌지 한번 돌아볼 만합니다.
제 경험도 딱 그렇습니다. 점수를 3~5개로 정하고 각 점수를 받으려면 어때야 하는지 한두 문장씩 적어서 주면 LLM이 정확하게 점수를 매기는 데 꽤 효과적입니다. 기준표를 안 주면 맥락이 부족하고, 값이 많으면(1~100처럼) 결과가 더 제멋대로 나옵니다.
네. 다만 그걸 LLM이 내놓는 (전통적 의미의) 확신도 점수로 봐야 한다고는 생각하지 않습니다. 좋은 기준표의 가치는 대부분, 어떤 입력이 각 확신 수준을 뒷받침하는지를 사람인 프롬프트 엔지니어가 얼마나 명확하고 구체적으로 서술하느냐에서 나옵니다. 기준을 정하지 않고 LLM이 알아서 하게 두면 제 경험상 만족스러운 결과가 나오지 않았습니다.
결국 좋은 "확신도" 점수는 사람의 좋은 분석과 프롬프트 엔지니어링을 반영하는 것이지, LLM에게 어떤 내성(introspection) 능력이 있다는 뜻이 아닙니다.
믿을 만한 출처를 제시해 주실 수 있나요?
"LLM"은 말 그대로 통계적 추론으로 대화하고 계산합니다.
매개변수/데이터 집합을 받아서, 허용 가능한 확신 수준에 따라 응답을 추론하는 겁니다. 이 부분의 병목은 연산 능력과 모델/프롬프트/가드레일/통합 환경이에요.
LLM이 일관성을 유지하고 어느 정도 궤도를 벗어나지 않으리라 믿을 수 있는 이유는, 자기 맥락/범위와 그 맥락에 대한 확신도를 모두 인지하고 있기 때문입니다.
그게 아니라면... 독창적인 사고와 표현이어야 하겠죠, 아마도요. 우리 뇌도 똑같다고 할 수 있겠네요. 즉, 무의식적인 통계 분석이 확신에 기반한 추론으로 이어지는 겁니다.
당신도 전기 신호와 근육 수축으로 대화하지만, 그렇다고 그 둘의 전문가가 되지는 않습니다.
마찬가지로 말을 흉내 내고, 지시를 따르고, 문제를 풀도록 훈련된 언어 모델이 자기 자신의 통계를 암묵적으로 이해하게 되지는 않습니다. 연구 결과도 그걸 뒷받침하지 않고, 곰곰이 생각해 보면 애초에 말이 안 됩니다.
LLM이 내놓는 것 중에 "확신도"라고 볼 만한 건 토큰 로짓 값뿐인데, 그마저도 연결 고리가 미심쩍습니다.
모델의 출력이 그런 세부 사항을 들여다볼 수 있나요? 우리 뇌가 전기 전위로 작동한다고 해서 우리가 그걸 타고난 통찰로 안다는 뜻은 아니잖아요.
네, 사용자 입장에서는 그게 컨텍스트 메모리라는 이름으로 마케팅되는 것입니다.
물론 어떤 모델은 이 컨텍스트 메모리를 강제로 쓰고, 어떤 모델은 안 쓰고, 어떤 모델은 "발동 수준"을 켜고 끌 수 있게 해 줍니다.
예를 들어 앤트로픽은 메모리를 적게 쓰는 질의나 리서치에는 haiku를 쓰고, 정리/분석/설계에는 Opus/Fable을 씁니다. 이쪽은 LLM의 추론이 계속 컨텍스트 메모리로 되돌아가는 데 의존하죠.
또 다른 예는 OpenAI/GPT입니다. "무료" 등급은 구독 상태(또는 구독하지 않은 상태)에 따라 "쓸 수 있는 최고 모델"로 컨텍스트 메모리를 강제로 쓰다가, 한도에 도달하면 컨텍스트가 작은 모델로 내려보내고, 결국에는 그 채팅을 아예 막아 버립니다.
(이 토론이 고맙습니다. 가르치려는 건 아니에요. 아마 이미 아시겠지만, 이렇게 적다 보면 제가 이해가 부족한 곳을 파악하는 데 도움이 되어서요.)
무지해서 죄송한데, 컨텍스트 메모리가 모델의 내부 작동을 들여다보는 데 어떻게 도움이 되나요? 제가 말하는 건 이겁니다.
아니면 LLM이 어떤 출력에 대해서든 자기 확신도라고 주장하는 것 말인가요?
잘못된 결론입니다. 통계적 추론에 대한 말씀은 맞지만, 처음에 하신 말씀, 특히 "그걸 완벽하게 말로 표현할 수도 있다"는 부분은 그걸로 설명되지 않습니다.
좋은 판별 기준이 하나 있습니다. 일반적인 인공 신경망, 퍼셉트론, 심지어 단순한 선형 회귀 모델도 가중치에 기반한 통계적 추론을 하고 확신 수준에 따라 선택을 합니다. 이건 범용적인 특성이라 LLM에만 해당하는 어떤 것도 설명해 주지 못합니다.
이건 "이 일 다음에 일어났으니 이 일 때문이다"라는 오류(post hoc ergo propter hoc)입니다.
어떤 관점에서는 똑같이 "느껴진다"는 건 이해하지만, 실제로 그런지는 우리가 알지 못합니다.
LLM은 열린 라벨링 작업에 어려움을 겪는데, 이건 연구된 바 있습니다. 하지만 점수 매기는 방법을 알려 주면 사람과 그리 멀지 않게 해낸다는 것도 연구된 바 있습니다. 지침을 빼면 열린 코드북으로 볼 수 있고, 그래서 아마 잘 안 될 거라고 생각합니다.
저는 통계학 학위가 있는데, 그 시절을 떠올려 보면 모델을 만드는 법을 배우는 데 시간의 10% 정도를 쓰고, 나머지 90%는 모델 출력을 올바르게 해석하는 데 썼습니다. 물론 제가 통계학을 배우던 때는 거의 전적으로 자연과학, 금융, 보험계리에만 응용되던 시절이었어요. 머신러닝이라는 무법지대는 아직 시작도 안 했을 때죠. 요즘은 가르치는 방식이 다른지 궁금하네요.
n이 수천만 단위로 들어가는 큰 데이터셋을 쓰기 시작하면서, 오차 범위가 워낙 작아서 어떤 범위의 평균을 찾았다는 게 사실상 확실했기 때문에 우리는 신경을 쓰지 않게 됐습니다. 하지만 그러는 사이에 확신도 점수가 실제로 무엇인지, 그리고 곱해진 알파(alpha)가 얼마나 빨리 부풀어 오를 수 있는지를 잊어버린 것 같습니다.
저는 2016~2023년에 ML 모델을 만들었는데, 평가와 해석이 작업의 큰 부분을 차지했습니다. 저는 주로 "무차별 대입" 방식의 해석 방법을 썼지만 SHAP [1]이나 LIME [2] 같은 것도 있었죠. ML 작업의 또 다른 큰 축은 피처 엔지니어링과 데이터 준비였고요. 지금 LLM 에이전트 시대에는 이게 다 날아갔습니다. "evals"는 있지만 아무도 진지하게 하지 않고, 해석은 흔히 소비자에게 떠넘겨집니다.
[1] https://shap.readthedocs.io/en/latest/
[2] https://christophm.github.io/interpretable-ml-book/lime.html
고품질 평가가 유행에서 밀려났다니 반가운 소식입니다. 평가가 규제 요건인 EU에서는 경쟁이 훨씬 덜 어려워지겠네요.
한편으로는 AI/ML 엔지니어링에서 어려운 부분은 소홀히 하고, 소셜 미디어에서 자랑할 수 있는 부분에만 매달리는 게 어느 정도 예상되는 일이기도 합니다. 깊이 우려되지만 안타깝게도 이해는 됩니다.
ML 하는 사람인 척 롤플레이하면서, 작동한다는 증거가 명백히 없는 것들을 그냥 만들어 내는 사람이 너무 많아서 부끄러울 지경입니다. 제가 일한 마지막 세 곳에서 다 봤는데, 대부분은 꾸준히 좋은 결과를 내는 법을 배우는 데 관심이 없고 일단 출시하고 다음 일로 넘어가는 데만 집중하는 것 같아요.
모델 가정을 검토하던 시절이 정말 그립네요…
이 글이 흥미로웠다면, 이 글의 5절을 읽어 보세요. LLM을 어떻게 훈련하면 확신도 점수를 잘 매기게 할 수 있는지 알 수 있습니다: https://magazine.sebastianraschka.com/i/217935364/51-on-calibration
글쓴이는 LLM이 정확성을 기준으로 점수를 받은 적이 없다고 했는데, 그건 최적화 과정에 대한 가정입니다.
이 정도는 맞는 말입니다.
사전훈련은 다음 토큰을 기준으로 점수를 매기고, 확신도에 대해서는 아무 말도 하지 않습니다
RLHF와 RLVR의 점수는 이진값(1=선호됨/정답, 0=더 나쁨/오답)이라서, 그 피드백은 보정/확신도를 개선하는 방향으로 가중치를 밀어 주는 일을 전혀 하지 않습니다
하지만 모델에게 확신도를 출력하게 한 다음 더 정확해지도록 훈련할 수 있습니다. (위에 링크한 글에서 언급된) RLCR은 보상에 Brier 페널티를 추가해서, 모델의 성능을 정답률(%)로만 측정하지 않습니다. (TypeSafeAI의 RLCD도 아마 RLCR과 비슷하겠지만, 그쪽은 아무것도 공개하지 않았습니다.)
이렇게 하면 글쓴이가 언급한 "항상 30%라고 답하는" 허점이 사라집니다. Brier 페널티 (q-c)^2는 개별 사례의 정보를 무시하는 예측자에게 불이익을 줍니다. 예를 들어 60% 확률로 정답을 맞히는 모델이 있다면, 확신도를 내놓는 전략으로 다음 중 하나를 쓸 수 있습니다.
두 전략 모두 완벽하게 보정되어 있지만(평균 확신도와 평균 정답률이 둘 다 60%), B가 페널티는 더 낮습니다. 물론 이건 LLM이 실제로 쓰는 전략이 아닙니다. 다만 훈련이 모델을 사례별 확신도를 최적화하는 쪽으로 밀 수 있는 이유를 말하고 싶었을 뿐입니다.
LLM이 스스로 생성한 확신도 점수를 어떤 검증 장치도 없이 맹목적으로 쓰는 사람들이 있다는 게 제게는 늘 말이 안 되고(어쩌면 좀 게으르다고) 보였습니다.
그리고 다른 분이 말씀하셨듯이, 평가를 가능한 한 많은 차원으로 분해하는 것이 사실에 근거한 확신도 점수를 만드는 더 나은 방법입니다.
확신도 점수 매기기는 LLM과 관련된 다른 모든 것처럼 맥락만 제대로 주면 괜찮습니다. 저는 직접 측정할 수 있는 것에는 채점 스크립트를 써서 LLM은 그 결과만 다루게 합니다. 덜 명확하게 정의되는 것에는 A부터 F까지 각 등급이 무엇인지 명시적인 기준을 담은 채점 매트릭스를 쓰는데, 보통 A 등급을 가정하고 시작해서 구체적인 발견 사항에 따라 깎아 내려갑니다.
확신도를 물어보는데 그걸 수학적으로도, 채점 기준표로도 정의할 수 없다면, 그때는 구현하는 당신이 스스로에게 질문을 던져야 합니다. 어떻게 측정해야 할지도 모르는 목표를 갖고 있다는 뜻이니까요. 이 지경이면 LLM은 문제도 아닙니다. 다른 사람이 해도 그냥 감으로, 맞을 수도 틀릴 수도 있는 숫자를 분위기로 찍을 테니까요.
네, 동의합니다. 점수를 매기라고 아주 명확하고 일관되게 요청하면 잘합니다. 코드를 짤 때 명확한 지시를 주는 것과 근본적으로 다르지 않아요.
점수 매기기를 더 일관되게 만드는 데 도움이 된 것 중 하나는 감점 방식의 기준표입니다. 모든 걸 만점에서 시작해서 구체적인 사항(문체, 놓친 사실 등)마다 감점하는 거죠. 제 경우에는 이 조건에서 최종 점수가 기준표+예시를 줄 때보다 훨씬 촘촘하게 나왔습니다.
제 식대로 말하면, 보정 세트(calibration set) 없이는 모델의 확신도를 보정할 수 없습니다. 확신도는 어떤 라벨링된 데이터셋에 상대적인 것이고, 구간(bucket)이나 범위를 기준으로 정해지며, 모집단에 기반합니다. 즉 하나의 예측에 대해서는 확인할 수 없는 거죠. 사례별로 부여하되, 모집단 단위로 검증하는 겁니다.
Jev가 소개된 방식은 교묘하다고 생각했습니다. "모델을 대신 보정해 드렸습니다"라고 말하면서 과제별 보정 세트를 건너뛸 수는 없어요. 우리의 미래 과제를 전부 알 수는 없었을 테니까요.
Jev는 그의 LLM 훈련 시점 이후에 나왔으니까요.
jev 훈련이 바로 이걸 개선하기 위한 것 아닌가요? 다음 토큰을 예측하도록 훈련하는 게 아니라 다음 토큰들의 분포를 예측하도록 훈련한다거나, 뭐 그런 거였던 것 같은데요.
Jev가 목표인 것 같은데, 그렇다고 말은 하지 않네요. Jev는 이런 문제를 피하려고 일반적인 LLM과 다르게 훈련됩니다.
글쓴이가 LLM의 확신도 점수의 품질이라는 흥미로운 틀을 제시했으니, 아첨 성향 때문에 나쁘다고 선언만 할 게 아니라 그게 얼마나 좋은지에 대한 데이터도 이어서 보여 주길 기대했습니다. 누군가 측정 가능한 대상으로 데이터를 모은다면, LLM의 확신도 수치가 그렇게 많이 벗어나지는 않을 거라는 데 걸겠습니다.
저는 그 실험을 해 봤습니다. 상업적으로 한 거라 데이터는 공유할 수 없어요. 하지만 글에서 설명한 내용이 제가 본 것과 대체로 일치한다고는 말할 수 있습니다. 점수가 얼마나 잘 보정되는지는 모델, 적용 대상, 미묘한 표현 변화에 따라 달라집니다. 저는 어느 정도 괜찮게 작동하게 만들었다는 점에서 글쓴이보다 조금 낙관적입니다. 하지만 SaaS LLM으로 제품화하는 건 권하지 않습니다. 벤더가 쓰던 모델을 단종할 때마다 깨질 테고, 새 모델에서 다시 작동하게 만드는 건 정말 끔찍하게 골치 아픈 일일 테니까요.
그게 LLM 제공업체들의 짜증 나는 부분이에요. API 뒤에서 모델이 바뀌어도 아무 말도 안 해 줍니다. 오픈 모델이 따라잡기를 바랍니다.
최근 나온 이 프리프린트 같은 걸 말씀하시는 거죠?
https://arxiv.org/html/2607.20526v1
그 논문에 따르면 모델의 정확도가 완벽하진 않지만 전반적으로 꽤 긍정적입니다. 모델 확신도의 정확도가 추론 노력(reasoning effort)에 따라 커진다는 것을 비롯해 고무적인 결과도 있고요.