Logprobs란 무엇이며 이를 통해 실제로 무엇을 할 수 있는가
요약
Logprobs의 개념과 활용법을 설명하며, 생성 모델을 스코어러로 변환하는 기술적 방법을 다룹니다. 수치적 안정성을 위한 로그 사용 이유와 API 활용 시 주의해야 할 온도(Temperature) 설정 및 재정규화 과정을 안내합니다.
핵심 포인트
- Logprobs는 토큰 확률의 자연로그 값으로 수치적 안정성을 제공함
- 생성 모델을 특정 답변의 확률을 측정하는 스코어러로 활용 가능
- API 제공업체의 온도(Temperature) 적용 여부를 반드시 확인해야 함
- 분류 작업 시 토크나이저 특성과 재정규화 과정을 고려해야 함
Logprobs는 채팅 API가 자신의 출력에 대해 정량적인 정보를 제공하는 유일한 채널입니다. 주의해서 사용하면 생성 모델 (Generative Model)을 스코어러 (Scorer)로 변환할 수 있습니다. 하지만 부주의하게 사용하면 실제 의미보다 과장된 신뢰도 수치를 만들어낼 수 있습니다.
Logprob이란 무엇인가
생성된 각 토큰 (Token)에 대해 샘플러 (Sampler)가 할당한 확률의 자연로그 (Natural Logarithm) 값입니다. 확률은 (0, 1] 범위에 있으므로, logprobs는 0 또는 음수입니다. -0.01은 거의 확실한 상태를, -0.7은 동전 던지기 정도의 확률을, -4.6은 1%를 의미합니다. 지수 함수 (Exponentiating)를 통해 확률을 복원할 수 있으며, 유용한 기준점은 다음과 같습니다 — e−0.69 ≈ 0.5, e−2.3 ≈ 0.1, e−4.6 ≈ 0.01.
실무에서 중요한 두 가지 이유 때문에 확률 대신 로그를 사용합니다. 희귀한 토큰의 확률은 부동 소수점 (Floating Point) 연산 시 언더플로 (Underflow)되어 0이 되지만, 로그는 그렇지 않습니다. 또한 시퀀스 (Sequence)의 확률은 각 토큰 확률의 곱인데, 이는 logprobs의 합 (Sum)이 되어 수치적으로 안정적이며 다루기가 훨씬 쉽습니다.
API가 반환하는 것
일반적으로 두 가지를 반환합니다: 모델이 실제로 방출한 각 토큰의 logprob, 그리고 top_logprobs를 요청할 경우 각 위치에서 logprob를 가진 상위 몇 개의 대안들입니다. 대안들은 모델이 거의 말할 뻔했던 것이 무엇인지 알려주기 때문에 흥미로운 부분입니다.
이를 기반으로 시스템을 구축하기 전에 확인해야 할 세부 사항이 하나 있습니다. 제공업체마다 다르며 명시적으로 문서화되는 경우가 드물기 때문인데, 바로 반환된 값이 원본 분포 (Raw Distribution)인지, 아니면 사용자의 온도 (Temperature) 및 절단 (Truncation)이 적용된 후의 분포인지 여부입니다. 만약 변환 후의 값이라면, 온도를 0.2로 설정할 경우 모델의 아무런 변화 없이도 보고된 모든 신뢰도가 더 높게 보이게 됩니다. 두 가지 온도에서 동일한 프롬프트를 요청하고 동일한 토큰에 대해 반환된 logprobs를 비교하여 이를 확인하십시오. 값이 변한다면 변환 후의 값이며, 당신이 보정하는 모든 임계값 (Threshold)은 해당 설정에 종속됩니다. 또한 많은 추론 모델 (Reasoning Models)은 logprobs를 전혀 반환하지 않을 수 있다는 점을 유의하십시오.
확률을 이용한 분류
이것은 가장 가치가 높은 활용법이며, 핵심은 답변을 정확히 하나의 토큰 (token)으로 만들어 해당 토큰의 확률이 곧 답변의 확률이 되도록 하는 것입니다.
import math, os
from openai import OpenAI
...
마지막 줄의 재정규화 (renormalisation) 과정이 해당 수치를 사용할 수 있게 만들어 줍니다. 만약 API가 "Y"에 대해 -0.12, "N"에 대해 -2.30의 logprob를 반환한다고 가정해 봅시다. 지수화 (Exponentiating)하면 0.887과 0.100이 되며, 이 둘의 합은 1이 아닌 0.987이 됩니다. 이는 나머지 1.3%가 두 클래스 중 어느 쪽도 아닌 다른 토큰들에 배정되어 있기 때문입니다. 이 합계로 나누면 0.899와 0.101이 되는데, 이는 질문에 답변한다는 조건 하에서의 확률이며, 바로 이 수치를 기준으로 임계값 (threshold)을 설정하게 됩니다.
두 가지 구현상의 함정이 있습니다. 토크나이저 (Tokenizer)는 대개 앞선 공백을 토큰의 일부로 취급하므로, "Y"와 " Y"는 서로 다른 항목입니다. 위에서와 같이 공백을 제거 (strip)하고 비교하십시오. 또한, 특정 클래스가 여러 개의 토큰을 필요로 하는 경우, 그 확률은 해당 토큰들의 곱 (logprobs의 합)이 되며, 이는 구조적으로 더 긴 라벨 (label)에 불이익을 줍니다. 단일 토큰 라벨을 사용하면 이 문제를 완전히 피할 수 있습니다.
세 가지 추가 활용법
- 생성하지 않은 후보군 점수 매기기. 제공된 연속된 텍스트의 logprobs를 모두 더한 뒤 토큰 수로 나누어 평균을 구합니다. 이것이 토큰당 교차 엔트로피 (per-token cross-entropy)이며, 이를 지수화하면 퍼플렉서티 (perplexity)가 됩니다. 이는 두 문구 사이에서 선택하거나 재작성된 문구들의 순위를 매길 때 유용하며, 단 두 문구 모두 동일한 모델과 프롬프트 (prompt) 하에서 점수가 매겨져야 합니다.
- 사람의 검토로 라우팅 (Routing). 재정규화된 클래스 확률에 임계값을 설정하여, 신뢰도가 낮은 하위 구간을 사람에게 보냅니다. 이는 가장 신뢰할 수 있는 실제 운영 (production) 활용법입니다. 왜냐하면 수치가 절대적인 관점에서 잘 보정 (well-calibrated)될 필요는 없으며, 단지 하위 10%가 상위 10%보다 확실히 나쁘다는 것을 보여줄 만큼 충분히 단조성 (monotone)을 갖추기만 하면 되기 때문입니다.
- 범위를 벗어난 답변 감지. 만약 상위 대안들 중 어느 클래스 토큰도 나타나지 않는다면, 모델은 당신이 질문한 것에 답변하고 있지 않은 것입니다. 이는 잘못된 답변을 하는 것과는 다른 별개의 실패이며, 별도의 처리가 필요합니다 — abstention을 참조하십시오.
오해를 불러일으키는 지점
로그확률 (logprob)는 모델의 학습 데이터를 바탕으로, 특정 토큰이 다음에 올 가능성이 얼마나 높은지에 대한 모델의 추정치입니다. 이는 해당 주장이 사실인지에 대한 추정치가 아닙니다. 자신감 있게 표현된 허구(fabrication)는 전체 과정에서 높은 토큰 확률을 보입니다. 즉, 그것이 유창한 이유가 바로 이것입니다. 따라서 토큰의 확신도 (token confidence)와 사실적 정확성 (factual correctness)은 서로 다른 양이며, 이 둘 사이의 간극이 교정 (calibration)의 주제입니다.
두 가지 한계가 더 있습니다. 긴 답변의 첫 번째 토큰에 대한 확신도는 나머지 부분에 대해 거의 알려주는 바가 없으므로, 토큰별 수치는 어떠한 원칙적인 방식으로도 답변 수준의 확신도로 집계되지 않습니다. 또한, 이 수치들이 생성되는 전체 분포는 소프트맥스 병목 (softmax bottleneck)에 의해 설명되는 부분 공간 (subspace) 내에 존재합니다. 이는 로그확률이 세상에 대한 측정값이 아니라 모델의 출력층 (output layer)의 속성임을 상기시켜 줍니다.
이 모든 것을 관통하는 실질적인 규칙은 다음과 같습니다: 로그확률를 인증 (certify) 용도가 아닌, 순위를 매기거나 (rank) 분류 (triage) 하는 용도로 사용하십시오. 특정 설정에서의 한 모델에 대해 직접 라벨링한 예시로 교정한 임계값 (threshold)은 유용한 도구입니다. 하지만 "모델이 89% 확신했다"라고 인용되는 가공되지 않은 수치는 도구가 아닙니다.
관련 항목
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기