AI 에이전트의 자신감 점수: 90% 확신은 무엇을 뜻할까

AI가 “90% 확신한다”고 말해도 그 답이 맞을 확률이 90%로 검증된 것은 아니다. 무엇의 성공을 예측한 점수인지 정하고, 비슷한 점수를 받은 여러 사례의 실제 결과와 비교해야 한다. 예측한 확률과 관측 빈도가 얼마나 맞는지를 나타내는 개념이 calibration, 즉 확률의 보정 상태다.

이번 AI Agent Fast Learning은 성공 횟수에서 한 걸음 옮겨 성공하기 전에 붙인 점수를 읽는다. “10건 중 몇 건을 맞혔나”와 “90%라고 예측한 사례는 얼마나 맞았나”는 다른 질문이다. 아래 40건은 원리를 설명하려고 만든 합성 데이터이며, 실제 에이전트나 서비스의 측정값이 아니다.

먼저 90%의 대상부터 좁힌다

가상의 문서 답변 에이전트가 질문마다 답변과 0~1 점수를 남긴다고 하자. 이 글에서 성공은 “지정한 문서의 근거와 답변의 핵심 주장이 일치한다”로 한정한다. 성공이면 y=1, 실패면 y=0이다. 점수 p는 이 사건의 성공확률을 예측한 값으로 취급한다. 결과를 본 뒤 점수를 붙이면 사전 예측을 평가하는 문제가 아니므로, 점수는 채점 전에 고정한다.

문장이 자연스러울 확률, 다음 토큰의 확률, 검색 결과의 유사도, 작업 전체의 완료확률을 이 점수와 섞으면 안 된다. 그중 어떤 값으로 시작하든, 답변의 근거 일치라는 사건을 얼마나 잘 예측하는지는 따로 확인해야 한다. 숫자가 소수점 둘째 자리까지 있다는 이유로 더 정확한 확률이 되지는 않는다.

말로 낸 확신을 전부 무의미하다고 볼 필요도 없다. Tian 등의 EMNLP 2023 연구는 당시 일부 RLHF 언어 모델과 TriviaQA·SciQ·TruthfulQA에서 출력으로 표현한 확신이 모델의 조건부 확률보다 대체로 잘 보정됐다고 보고했다. 그 결과가 현재의 모든 모델, 프롬프트, 도구 작업에 적용된다는 뜻은 아니다. 지금 쓰는 점수는 지금의 과업에서 검증해야 한다.

90%를 준 열 건 중 여섯 건만 맞았다면

네 점수에 각각 10건을 배정한 합성 기록을 보자. 각 묶음 안에서는 열 건 모두 같은 p를 받았다. 성공 수는 미리 정한 예시값이다.

  • p=0.3인 10건: 성공 3건, 실패 7건 → 관측 성공률 30%
  • p=0.5인 10건: 성공 5건, 실패 5건 → 관측 성공률 50%
  • p=0.7인 10건: 성공 7건, 실패 3건 → 관측 성공률 70%
  • p=0.9인 10건: 성공 6건, 실패 4건 → 관측 성공률 60%

마지막 묶음에서는 예측 90%와 관측 60%가 30%p 벌어진다. 이 표본에서 높은 점수가 결과보다 낙관적이었다는 신호다. 그러나 열 건만 보고 앞으로도 정확히 60% 성공할 것이라고 확정할 수는 없다. 첫 세 묶음의 숫자가 일치한 것도 모집단의 완벽한 보정을 입증하지 않는다.

교육용 합성 40건의 확률 보정 그림. 점수0.3,0.5,0.7,0.9 묶음 각10건의 성공 수는3,5,7,6건이다. 0.9 묶음은 예측90%와 관측60%가30%포인트 차이난다.
각 점은 같은 예측확률을 받은 합성10건이다. 점선은 예측과 관측이 같은 기준이며, 점선과의 일치가 작은 표본의 불확실성을 없애지는 않는다. 실제 모델 측정값이 아니다.

Reliability diagram은 이런 비교를 좌표에 옮긴 그림이다. 가로축은 묶음의 평균 예측확률, 세로축은 그 묶음의 관측 성공률이다. 점선 아래라면 해당 묶음에서는 예측이 관측보다 높다. 실제 점수가 제각각이면 구간을 정해 묶는다. 구간 경계와 표본 수가 달라지면 그림도 달라지므로, 점마다 사례 수를 함께 남긴다. scikit-learn 공식 설명에서도 구간별 평균 확률과 양성 비율을 비교한다.

틀린 확신에 얼마만큼의 점수를 줄까

구간 그림과 함께 볼 수 있는 값이 Brier score다. 여기서는 이진 사건의 (p−y)²를 모든 사례에서 평균낸다. 이 정의의 범위는 0~1이고 낮을수록 좋다. 다중분류에서 모든 클래스의 오차를 합하는 다른 정의와 숫자를 그대로 비교하지 않는다.

90%를 준 답변이 맞으면 (0.9−1)²=0.01이다. 틀리면 (0.9−0)²=0.81이 된다. 따라서 마지막 열 건의 평균은 (6×0.01+4×0.81)÷10=0.33이다. 큰 확신으로 틀린 네 건이 점수를 크게 올린다.

from fractions import Fraction as F

groups = [(F(3,10),3), (F(5,10),5),
          (F(7,10),7), (F(9,10),6)]
losses = []
for p, successes in groups:
    outcomes = [1]*successes + [0]*(10-successes)
    errors = [(p-y)**2 for y in outcomes]
    losses.extend(errors)
    print(float(p), float(sum(errors)/10))
print("all", float(sum(losses)/len(losses)))

위 합성값을 Python으로 계산한 결과는 순서대로 0.21, 0.25, 0.21, 0.33이며, 전체 40건의 Brier score는 0.25다. 여기서 실행한 것은 산술 코드다. 모델에 질문하거나 확신을 추출한 실험은 하지 않았다.

다만 0.25라는 전체 숫자만으로 “보정이 좋다”거나 “배포해도 된다”고 판정할 수는 없다. Brier score에는 보정뿐 아니라 사례를 구별하는 능력과 데이터의 불확실성도 함께 반영된다. 더 낮은 Brier score가 항상 더 나은 calibration을 뜻하지 않는다는 점은 공식 문서의 주의사항에도 명시돼 있다. 이 예시에서는 전체값 옆에 0.9 묶음의 6/10을 남겨야 문제가 드러난다.

점수를 보정하는 일과 답을 고치는 일

가령 관측한 결과를 보고 모든 0.9를 0.6으로 바꾸면 어떨까. 같은 열 건에서 계산한 Brier score는 0.24로 내려간다. 하지만 답변의 성공 수는 여전히 여섯 건이다. 더구나 그 열 건의 정답을 이용해 숫자를 고쳤으므로, 이 개선값은 새로운 사례에서 검증한 성과가 아니다.

Guo 등의 ICML 2017 연구는 이미지·문서 분류 모델에서 사후 확률 보정과 temperature scaling을 분석했다. 여기서 배울 구분은 예측의 맞고 틀림과 확률의 신뢰성이 별개의 평가 대상이라는 점이다. 그 연구를 근거로 대화 모델의 생성 temperature만 낮추면 작업 성공확률이 보정된다고 말할 수는 없다. 대상과 절차가 다르다.

실무에서는 점수를 만드는 시스템을 고정한 뒤 보정용 사례에서 변환 규칙을 정하고, 그 결정에 쓰지 않은 사례로 확인하는 절차를 설계할 수 있다. 데이터 분리의 자세한 이유는 이전 평가 설계 글에서 다뤘다. 모델·프롬프트·문서 범위가 바뀌면 기존 보정이 계속 맞는지도 다시 점검해야 한다.

0.8 이상만 맡기면 안전할까

우리 합성 기록에서 p≥0.8인 답변만 선택하면 40건 중 10건이 남는다. 선택 비율은 25%, 선택한 사례의 관측 실패율은 4/10=40%다. 높은 점수 기준을 세웠다는 사실만으로 낮은 실패율이 생기지 않는다. 이 수치는 자동화 임계값의 추천값이 아니라, 선택한 집합의 결과를 직접 계산해야 한다는 반례다.

점수를 업무 분기에 쓰려면 다음 내용을 함께 기록하는 편이 좋다. 아래 목록은 이 문서 답변 사례에 대한 설계 제안이다.

  • 예측 사건: 근거 일치처럼 성공과 실패를 판정할 수 있는 문장
  • 점수의 출처: 생성된 확신 문구인지, 별도 분류기인지, 보정된 값인지
  • 검증 조건: 사례 범위·판정 기준·시스템 버전·구간별 사례 수
  • 분기 결과: 선택 비율, 선택한 사례의 실패 수, 보류한 사례의 처리 경로

마지막으로 점수와 실행 권한은 별개로 둔다. 충분히 검증된 높은 점수라도 결제·발행·개인정보 전송의 승인을 대신하지 않는다. 근거 문서를 읽지 못했다면 그 사실을 표시해야지, 자신감 숫자로 빈칸을 메워서는 안 된다.

지금 에이전트 화면에 90%가 표시된다면 그 숫자 옆에 질문 하나를 붙여 보자. “어떤 사건을 예측했으며, 그 점수를 받은 사례는 실제로 몇 건 중 몇 건 성공했는가?” 답이 없다면 먼저 만들 것은 더 정밀한 소수점이 아니라 점수와 결과가 짝지어진 기록이다.

자료와 재현 범위

자료 확인: 2026년 10월 10일. 본문과 그림의 40건은 교육용 합성값이며 Python으로 산술만 검산했다. 실제 모델 호출, 운영 성능 측정, 보정 모델 학습, 자동화 임계값 실험은 수행하지 않았다. 문서 답변 과업과 기록 절차는 설계 제안이다.


다른 글 보기 · 주제 탐색 · 작성자와 편집 기준 · 문의·정정 요청

RUDA DIRECTOR에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기