퍼플렉시티
더 많은 작업
- Perplexity, PPL; 퍼플렉시티
- 언어 모델이 테스트 텍스트의 각 토큰에 준 확률의 기하 평균의 역수. 모델이 다음 토큰을 고를 때 평균적으로 몇 개의 후보 사이에서 헷갈리는지를 나타내며 낮을수록 좋다
퍼플렉시티(perplexity, PPL)는 언어 모델이 처음 보는 텍스트를 얼마나 잘 예측하는지 재는 가장 기본적인 내재적 평가 지표다. 이름은 "당혹, 혼란"을 뜻하는 영어 단어에서 왔다. 국내 자료에서는 퍼플렉시티, 퍼플렉서티, 펄플렉서티(Hugging Face 한국어 문서) 등으로 표기가 엇갈린다. AI 검색 서비스 기업 퍼플렉시티(Perplexity AI)와는 관계없다.
1977년 IBM의 프레더릭 젤리넥(Frederick Jelinek) 연구진이 음성 인식 과제의 난이도를 재는 척도로 제안했고,[1] n-gram 시대부터 대형 언어 모델 시대까지 사전 학습 손실과 함께 모델 비교에 쓰여 왔다. 상위 개념과 다른 평가 방법은 언어 모델의 평가 절 참고.
토큰열 에 대해 자기회귀 언어 모델인 의 퍼플렉시티는
이다. 지수 안은 토큰당 평균 음의 로그우도, 즉 테스트 데이터에 대한 모델의 교차 엔트로피 (단위 nat)다. 그러므로 이고, 밑을 2로 쓰면 (는 토큰당 비트)다. 학습 때 보는 교차 엔트로피 손실이 2.0(nat)이면 퍼플렉시티는 다.
모델이 매 위치에서 정답을 포함한 개 후보에 똑같이 씩 확률을 준다면 퍼플렉시티는 정확히 다. 그래서 퍼플렉시티 20은 "평균적으로 20개의 동등한 후보 사이에서 고르는 것만큼 불확실하다"고 읽는다. 어휘 크기 에 균등 분포를 주는 모델은 이고, 모든 정답에 확률 1을 주는 모델은 1이다. 정답 토큰에 확률 0을 한 번이라도 주면 무한대가 되므로 실제 모델은 소프트맥스 출력처럼 어디에나 0보다 큰 확률을 준다.
교차 엔트로피 는 실제 분포 의 엔트로피보다 작아질 수 없으므로, 퍼플렉시티에는 텍스트 자체의 불확실성에서 오는 하한이 있다. 모델이 나아질수록 줄어드는 것은 쿨백-라이블러 발산 부분이다. 또한 산술 부호화를 쓰면 모델의 확률로 텍스트를 토큰당 약 비트로 무손실 압축할 수 있어, 퍼플렉시티를 낮추는 것은 압축률을 높이는 것과 같다. 2023년 구글 딥마인드 연구진은 이 관점에서 친칠라 70B가 이미지넷 이미지 조각을 원래 크기의 43.4%로 압축해 PNG(58.5%)보다 낫다고 보고했다.[2]
위 정의의 은 토큰 수다. 같은 문장이라도 토크나이저가 다르면 토큰 수가 달라지고, 토큰 하나에 담긴 정보량도 달라진다. 따라서 토크나이저가 다른 모델끼리는 토큰 단위 퍼플렉시티를 직접 비교할 수 없다. 토큰을 잘게 쪼갤수록 쪼개진 조각 대부분은 앞 조각에서 쉽게 예측되므로 토큰당 퍼플렉시티는 낮아지지만, 문장 전체를 맞히는 능력은 그대로이거나 오히려 나쁠 수 있다.
해결책은 전체 음의 로그우도 를 토크나이저와 무관한 단위로 나누는 것이다.
| 지표 | 식 | 비고 |
|---|---|---|
| 토큰 퍼플렉시티 | 같은 토크나이저끼리만 비교 | |
| 단어 퍼플렉시티 | 공백으로 단어를 나누는 언어에 적합. 교착어·띄어쓰기 없는 언어에서는 모호 | |
| 문자당 비트(BPC) | 문자 수준 모델 평가에 쓰임. 유니코드 문자 정의가 모호할 수 있음 | |
| 바이트당 비트(BPB) | UTF-8 바이트 기준. 토크나이저·언어에 가장 덜 민감 |
EleutherAI의 The Pile 논문은 토큰화 방식에 무관하고 유니코드 문자 정의의 모호함도 피할 수 있다는 이유로 UTF-8 바이트당 비트를 기본 지표로 삼았다. 토큰당 손실 에서 로 바꾸며(는 토큰 수, 는 바이트 수), Pile 전체에서 는 바이트당 GPT-2 토큰 0.29335개였다.[3] 평가 도구 lm-evaluation-harness도 word_perplexity, byte_perplexity, bits_per_byte를 함께 계산한다.[4]
영어 위주로 학습한 GPT-2(124M)에 짧은 영어 문장과 한국어 문장을 넣고 두 지표를 비교하면 차이가 분명하다(아래 코드로 측정).
| 입력 | 예측 토큰 수 | 토큰 퍼플렉시티 | 바이트당 비트 |
|---|---|---|---|
| 영어 두 문장(76바이트) | 18 | 55.7 | 1.37 |
| 한국어 두 문장(91바이트) | 82 | 8.3 | 2.76 |
GPT-2의 바이트 수준 BPE는 학습 때 한국어를 거의 보지 못해 한글 한 글자를 여러 바이트 조각으로 쪼갠다. 한 글자 안의 뒤쪽 바이트 조각은 앞 조각만 보면 거의 확정되므로 토큰당 퍼플렉시티는 영어보다 훨씬 낮게 나온다. 하지만 바이트당 비트는 한국어 쪽이 두 배 높아, 실제로는 한국어를 훨씬 못 예측한다는 것을 보여 준다.
Hugging Face Transformers에서 인과 언어 모델에 labels=input_ids를 넘기면 내부에서 레이블을 한 칸 밀어 토큰당 평균 교차 엔트로피(자연로그)를 돌려준다. 이를 지수화하면 퍼플렉시티다.
import math, torch
from transformers import AutoModelForCausalLM, AutoTokenizer # transformers 4.49에서 실행 확인
tok = AutoTokenizer.from_pretrained("gpt2")
model = AutoModelForCausalLM.from_pretrained("gpt2").eval()
def score(text):
ids = tok(text, return_tensors="pt").input_ids
with torch.no_grad():
loss = model(ids, labels=ids).loss.item() # 토큰당 평균 NLL(nat)
n_pred = ids.shape[1] - 1 # 첫 토큰은 예측 대상이 아니다
nll = loss * n_pred # 전체 NLL
n_bytes = len(text.encode("utf-8"))
return {"tokens": n_pred,
"ppl_token": math.exp(loss),
"bits_per_byte": nll / math.log(2) / n_bytes}
print(score("The quick brown fox jumps over the lazy dog. It was a sunny day in the park."))
print(score("빠른 갈색 여우가 게으른 개를 뛰어넘었다. 공원은 화창한 날이었다."))
엄밀히는 첫 토큰의 바이트도 분모에서 빼야 하지만, 긴 텍스트에서는 차이가 무시할 만하다. 실제 평가에서는 문서 앞에 BOS 토큰을 붙여 첫 토큰까지 예측 대상에 넣기도 한다.
모델의 최대 문맥 길이보다 긴 텍스트는 잘라서 계산해야 한다. 겹치지 않는 조각으로 자르면 각 조각 앞부분의 토큰은 문맥 없이 예측되어 퍼플렉시티가 실제보다 나쁘게 나온다. Hugging Face 문서는 창을 일정 간격(stride)으로 밀면서, 겹치는 앞부분은 문맥으로만 쓰고(레이블 -100) 새로 들어온 토큰만 손실에 넣는 방식을 권한다.[5]
max_length, stride = model.config.n_positions, 512 # GPT-2는 1024
ids = tok(long_text, return_tensors="pt").input_ids
nll_sum, n_tokens, prev_end = 0.0, 0, 0
for begin in range(0, ids.size(1), stride):
end = min(begin + max_length, ids.size(1))
trg_len = end - prev_end # 이번 창에서 새로 채점할 토큰 수
input_ids = ids[:, begin:end]
target = input_ids.clone()
target[:, :-trg_len] = -100 # 문맥으로만 쓰는 토큰은 손실에서 제외
with torch.no_grad():
loss = model(input_ids, labels=target).loss
n = (target != -100).sum().item() - 1 # 내부에서 레이블을 한 칸 밀기 때문
nll_sum += loss.item() * n; n_tokens += n
prev_end = end
if end == ids.size(1):
break
ppl = math.exp(nll_sum / n_tokens)
같은 문서에 따르면 GPT-2 large로 WikiText-2 시험 세트를 계산할 때 겹침 없이(stride 1024) 자르면 19.44로 GPT-2 논문의 19.93과 비슷하고, stride를 512로 줄이면 16.44로 내려간다. 보고된 퍼플렉시티를 비교할 때는 이런 계산 방식까지 같아야 한다.[5]
- 사전 학습 진행 상황과 스케일링 법칙: 검증 손실(로그 퍼플렉시티)은 모델·데이터·연산량에 따라 매끄럽게 줄어들어 스케일링 법칙을 재는 기본 지표가 된다.
- 학습 데이터 거르기: CCNet은 웹 크롤 문서 가운데 위키백과 같은 고품질 말뭉치와 가까운 문서를 고르는 단계를 두었는데, 위키백과로 학습한 언어 모델로 잰 퍼플렉시티를 그 기준으로 썼다.[7]
- 학습 데이터 포함 여부 추정: 모델이 외운 텍스트는 퍼플렉시티가 비정상적으로 낮다. 벤치마크 오염 탐지와 멤버십 추론 공격이 이 성질을 쓴다.
- 양자화·압축 평가: 양자화나 가지치기 전후의 퍼플렉시티 변화로 성능 손실을 빠르게 가늠한다. GPTQ, AWQ 같은 양자화 기법도 퍼플렉시티 변화로 품질 손실을 보고했다.
- 과제 성능과 별개: 퍼플렉시티가 낮다고 질의응답, 추론, 지시 따르기를 잘한다는 보장은 없다. 그래서 MMLU, SWE-bench 같은 벤치마크를 함께 본다.
- 긴 문맥: 긴 문서 퍼플렉시티는 대부분의 토큰이 가까운 문맥만으로 예측되므로 장거리 이해 능력을 거의 반영하지 못한다. 2024년 연구는 퍼플렉시티와 긴 텍스트 이해 능력 사이에 상관이 없다고 보고했고,[8] 긴 문맥에서만 예측이 쉬워지는 핵심 토큰만 골라 재는 LongPPL은 긴 문맥 벤치마크 성능과 피어슨 상관 -0.96을 보였다.[9]
- 생성문 품질 평가에 부적합: 다른 모델로 생성문의 퍼플렉시티를 재서 유창성을 판단하면, 짧은 글일수록 값이 크게 나오고 반복 구간과 문장 부호에 크게 흔들린다는 분석이 있다.[10] 같은 말을 되풀이하는 퇴화한 문장도 낮은 퍼플렉시티를 받을 수 있다.
- 비교 조건: 토크나이저, 평가 말뭉치, 문맥 길이, stride, BOS 토큰 처리, 대소문자·전처리가 모두 같아야 수치를 비교할 수 있다.
- ↑ F. Jelinek, R. L. Mercer, L. R. Bahl, J. K. Baker, 〈Perplexity: a measure of the difficulty of speech recognition tasks〉, Journal of the Acoustical Society of America 62(S1), 1977.
- ↑ Grégoire Delétang 외, 〈Language Modeling Is Compression〉, 2023. arXiv:2309.10668
- ↑ Leo Gao 외, 〈The Pile: An 800GB Dataset of Diverse Text for Language Modeling〉, 2020. arXiv:2101.00027
- ↑ EleutherAI, lm-evaluation-harness lm_eval/api/metrics.py.
- ↑ 5.0 5.1 5.2 Hugging Face, Perplexity of fixed-length models, Transformers 문서.
- ↑ Julian Salazar 외, 〈Masked Language Model Scoring〉, ACL 2020. arXiv:1910.14659
- ↑ Guillaume Wenzek 외, 〈CCNet: Extracting High Quality Monolingual Datasets from Web Crawl Data〉, 2019. arXiv:1911.00359
- ↑ Yutong Hu 외, 〈Can Perplexity Reflect Large Language Model's Ability in Long Text Understanding?〉, 2024. arXiv:2405.06105
- ↑ Lizhe Fang 외, 〈What is Wrong with Perplexity for Long-context Language Modeling?〉, 2024. arXiv:2410.23771
- ↑ Yequan Wang 외, 〈Perplexity from PLM Is Unreliable for Evaluating Text Quality〉, 2022. arXiv:2210.05892