요약: LLM을 제품에 넣을 때 가장 위험한 순간은 틀린 답을 자신 있게 내보낼 때다. 특히 JSON 추출, 라벨 분류, 자동 승인, 티켓 라우팅 같은 구조화 출력에서는 “모르면 모르겠다”가 필요하다. 최근 arXiv 논문 Reading Calibrated Uncertainty from Language Model Trajectories는 maximum softmax probability(MSP)가 종종 miscalibrated하다고 지적하고, 모델 내부 trajectory의 기하학적 특징으로 불확실성을 더 잘 읽는 접근을 제안한다. 실무자는 연구 구현을 그대로 쓰기보다 selective abstention, confidence bucket, human review queue를 먼저 설계해야 한다.
많은 LLM 제품은 모델 출력 뒤에 confidence를 붙이고 싶어 한다. 고객 문의 분류, 영수증 정보 추출, 법률 문서 태깅, 보안 알림 triage 같은 작업에서 확신도가 낮으면 사람에게 넘기고 싶기 때문이다. 가장 쉬운 방법은 확률 또는 logprob을 보는 것이다. 하지만 이 값이 실제 정답 가능성과 잘 맞는다는 보장은 없다.
논문은 maximum softmax probability가 싸고 흔한 방법이지만 종종 calibration이 맞지 않는다고 설명한다. 최종 token probability만 보면 모델이 어떤 경로로 그 답에 도달했는지 알기 어렵다. 비슷한 최종 확률을 가진 답도 내부적으로는 안정적으로 수렴했을 수도 있고, 중간에 여러 번 방향이 뒤집혔을 수도 있다.
검색 의도로 보면 이 글의 핵심 키워드는 LLM 불확실성, 구조화 출력 confidence, selective abstention이다. 중요한 목표는 논문 기법을 서비스에 바로 붙이는 것이 아니라, 틀릴 때 피해가 큰 AI 기능에 거절과 검토 흐름을 넣는 것이다.
자유 텍스트 답변은 사용자가 어느 정도 판단할 여지가 있다. 문장이 이상하거나 근거가 부족하면 의심할 수 있다. 반면 구조화 출력은 시스템이 바로 소비한다. 모델이 refund_approved: true를 내거나, severity: low를 내거나, assignee: billing-team을 내면 다음 자동화가 실행될 수 있다.
이때 confidence가 잘못 보정되어 있으면 두 가지 문제가 생긴다. 첫째, 틀린 자동 처리가 발생한다. 고객 환불, 보안 알림, 의료·법무 문서 같은 영역에서는 비용이 크다. 둘째, 사람 검토 큐가 망가진다. 실제로 어려운 케이스는 자동 처리되고, 쉬운 케이스만 사람이 보게 되면 운영 효율이 떨어진다.
따라서 구조화 출력에는 정답 생성 로직과 별도로 불확실성 처리 정책이 필요하다. “모델이 답했으니 처리”가 아니라 “모델이 답했고, 근거가 있고, 검증 규칙을 통과했고, 위험도가 낮으면 처리”가 되어야 한다.
Reading Calibrated Uncertainty from Language Model Trajectories 논문은 모델의 layer-wise MLP update 경로에서 11개의 scale-invariant geometric features를 추출하고 sparse linear probe로 불확실성을 읽는 방식을 제안한다. 논문은 selective abstention에서 MSP보다 나은 결과를 보였고, baseline miscalibration이 큰 경우 최대 21 AURC point 개선을 보고한다.
실무 개발자가 당장 내부 activation에 접근하기는 어렵다. 대부분은 OpenAI, Anthropic, Google 같은 API 모델을 쓰고, hidden state를 받지 못한다. 그래도 메시지는 분명하다. 최종 답의 확률 하나보다, 답이 만들어진 과정과 주변 신호를 함께 봐야 한다.
API 기반 제품에서는 대체 신호를 만들 수 있다. 예를 들어 모델에게 근거 문장을 같이 반환하게 한다. 같은 입력을 작은 변형으로 두 번 실행해 결과 일관성을 본다. JSON schema validation, business rule validation, retrieval evidence overlap을 확인한다. 불일치가 있으면 자동 처리하지 않는다. 내부 trajectory를 직접 읽지 못해도 “경로의 안정성”을 외부 지표로 근사할 수 있다.
가장 단순한 설계는 confidence를 high, medium, low 세 bucket으로 나누는 것이다. high는 자동 처리, medium은 제한적 자동 처리 또는 샘플링 리뷰, low는 사람 검토로 보낸다. 숫자 threshold는 처음부터 정답이 아니다. 실제 운영 데이터로 조정해야 한다.
처음에는 conservative하게 시작한다. 예를 들어 자동 처리 비율을 30%로 제한하고, 나머지를 사람 검토로 둔다. 2주간 결과를 라벨링해 high bucket의 실제 precision이 98% 이상인지 확인한다. 목표 precision이 맞으면 자동 처리 범위를 넓힌다. 반대로 low bucket에 쉬운 케이스가 너무 많으면 threshold를 조정한다.
중요한 것은 사용자에게도 상태를 명확히 보여주는 것이다. 내부 시스템에는 auto_approved, needs_review, insufficient_evidence, schema_failed, conflict_detected 같은 상태가 있어야 한다. “AI 실패” 하나로 묶으면 재시도, 리뷰, 개선이 어려워진다.
LLM에게 “확실하면 답하고 아니면 모른다고 해”라고만 지시하는 것은 부족하다. 모델은 종종 확신을 과장한다. 따라서 검증 규칙은 모델 밖에서 실행해야 한다. JSON schema validation, enum 제한, 숫자 범위 체크, 날짜 파싱, 필수 근거 존재 여부, 권한 정책, 중복 데이터 확인 같은 규칙은 코드로 강제한다.
예를 들어 계약서에서 갱신일을 추출하는 기능을 만든다고 하자. 모델이 날짜를 반환해도 원문 근거 문장에 해당 날짜가 없으면 low confidence로 내려야 한다. 날짜가 오늘보다 과거인지, 계약 유형과 맞는지, 여러 날짜가 충돌하는지도 확인해야 한다. 환불 승인 분류라면 주문 상태, 결제 수단, 정책 기간, 과거 환불 이력을 모델 밖에서 대조해야 한다.
이 구조는 비용도 줄인다. 모든 애매한 케이스를 더 큰 모델로 재시도하는 대신, 규칙으로 걸러낼 수 있는 오류는 빠르게 잡고, 진짜 어려운 케이스만 사람 또는 고성능 모델로 보낸다.
