LLM 컨텍스트 압축을 숫자로 증명하기: tiktoken 벤치마크 설계

amdb의 존재 이유는 LLM에 들어가는 컨텍스트를 줄이는 것이다. 그렇다면 "얼마나 줄이는가"에 숫자로 답해야 한다. 측정 없는 압축 주장은 마케팅 문구지 엔지니어링이 아니다. v0.3.0에서 벤치마크를 설계하며 정리한 것들.

무엇을 세는가: 문자가 아니라 토큰

LLM 비용과 컨텍스트 윈도우의 단위는 문자도 줄 수도 아닌 토큰이다. 같은 1만 자라도 자연어와 코드는 토큰 수가 다르고, 코드 중에서도 식별자 길이와 기호 밀도에 따라 달라진다. 파일 크기 절감률을 토큰 절감률처럼 말하면 거짓말이 된다.

토크나이저는 tiktoken의 cl100k_base를 골랐다. 특정 모델의 정확한 토크나이저라서가 아니라, 공개돼 있고 재현 가능하며 주요 모델들의 토큰 수를 근사하는 기준으로 널리 쓰이기 때문이다. 벤치마크에서 토크나이저 이름을 명시하는 것 자체가 재현성의 절반이다.

Rust에서 토큰 세기

tiktoken-rs를 쓰면 측정 코드가 몇 줄로 끝난다.

bench/tokens.rs

use tiktoken_rs::cl100k_base;
 
fn count_tokens(text: &str) -> anyhow::Result<usize> {
    let bpe = cl100k_base()?;
    Ok(bpe.encode_with_special_tokens(text).len())
}
 
fn compression_ratio(original: &str, compressed: &str) -> anyhow::Result<f64> {
    let before = count_tokens(original)? as f64;
    let after = count_tokens(compressed)? as f64;
    Ok(1.0 - after / before)
}

측정 대상은 두 값이다. 원본: 파일들을 그대로 이어붙여 LLM에 넣었을 때의 토큰 수. 압축본: amdb가 생성한 컨텍스트 마크다운의 토큰 수.

방법론: 자기 자신을 먹여라

벤치마크 대상은 amdb 자신의 Rust 모듈 30개다. 자기분석(dogfooding)을 고른 이유는 세 가지다.

코드베이스를 완전히 알고 있어 검색 결과의 정답 여부를 직접 판정할 수 있다.
누구나 저장소를 클론해 같은 측정을 재현할 수 있다.
도구가 자기 자신에게 쓸모없다면 남에게도 쓸모없을 가능성이 높다.

측정 항목은 토큰 절감률만이 아니다. 컨텍스트가 아무리 작아도 필요한 파일을 못 찾으면 실패다. 그래서 질의별로 "이 질의에 반드시 포함돼야 할 파일" 정답 세트를 만들고, 생성된 컨텍스트가 그것을 포함하는지를 함께 쟀다.

결과

v0.3.0, cl100k_base, Rust 모듈 30개 기준:

컨텍스트 토큰 91.5% 절감
핵심 파일 94.2% 압축 (11~18배)
파일 검색 정밀도 96.7%
LLM API 토큰 비용 약 12배 절감

절감률과 정밀도를 반드시 함께 봐야 한다. 절감률은 컨텍스트를 통째로 비우면 100%가 나오는 지표다. 정밀도가 그 절감이 유효했음을 보증한다.

밟은 함정들

마크다운 오버헤드를 빼먹지 마라

생성된 컨텍스트에는 헤딩, 코드 펜스, 구분자 같은 구조 마크업이 붙는다. 심볼 텍스트만 세면 절감률이 실제보다 좋게 나온다. 측정은 항상 최종 산출물 전체를 대상으로 해야 한다.

평균이 아니라 분포를 보라

"핵심 파일 94.2% 압축 (11~18배)"에서 범위를 함께 적은 이유다. 파일마다 압축률이 다르다. 평균 하나로 뭉개면 최악 케이스가 숨는다. 11배로 압축되는 파일과 18배로 압축되는 파일이 있다는 사실 자체가 정보다.

토크나이저를 바꾸면 숫자가 바뀐다

같은 텍스트도 토크나이저가 다르면 토큰 수가 다르다. 벤치마크 수치를 인용할 때 토크나이저 명시가 없다면 그 수치는 비교 불가능하다.

정리

압축 주장의 단위는 토큰이다. 토크나이저 이름까지 명시해야 재현 가능한 벤치마크다.
절감률은 정밀도와 쌍으로만 의미가 있다. 못 찾으면 절감이 아니라 손실이다.
자기분석은 가장 정직한 첫 벤치마크다. 정답 판정이 가능하고 누구나 재현할 수 있다.