gzip만으로 셰익스피어를 생성한 실험: 압축이 곧 예측이라는 가정을 빔 서치로 구현한 gzipt

gzip이 그 탐색을 얼마나 잘했는지 알 방법이 없다는 게 문제임. 탐색 공간의 의미 있는 부분을 다 뒤질 수가 없으니 결과는 gzip의 그럴듯함 판정 성능 하한일 뿐임. 빔 서치가 gzip 압축률 기준 전역 최적을 얼마나 잘 찾는지에 대한 얘기는 글에 없더라.

전역 최소를 찾는다 해도 별로 쓸모없을지 모름. DEFLATE는 반복되는 부분 문자열을 이전 위치에 대한 backreference로 바꾸는데, context 안에 prompt+y가 부분 문자열로 들어 있으면 그걸 통째로 backreference로 인코딩해버림. 압축은 엄청 작아지지만 생성 모델로는 도움이 안 됨. 직접 실험해봤는데 그렇더라.

글 끝까지 읽어봐. 걔들은 압축이 제일 잘 되는 출력을 찾는 게 아님. 그렇게 하면 aaaaaaaaa로 수렴해버려서, 최근 텍스트 일부만 슬라이딩 윈도우로 두고 씀. 그 선택 때문에 전제 자체가 무너진다고 봄.

attention이나 그 비슷한 게 없으면 안 됨. gzip이 빠르다는 게 뭔가 빠졌다는 첫 단서임. gzip은 입력 크기에 선형으로 늘고, 다음 토큰을 제대로 찾으려면 제곱으로 늘어남. 1TB 파일도 gzip은 돌리는데 LLM에 그걸 넣을 수는 없음. 압축과 지능을 같다고 보는 건 점점 우스워지고, LLM은 gzip보다 jpeg나 mp3에 가까움.

그럼 반대로 LLM을 압축기로 쓸 때는 얼마나 잘 될지가 더 궁금함.

gzip이 선형인 건 32KiB 윈도우 때문임. 그 윈도우 안에서 최적 압축을 노리면 적어도 제곱이 될 거라고 봄.

LLM을 지능과 동일시하는 것도 틀린 건 마찬가지임.

그 페이지 이전 논의도 있음. news.ycombinator.com/item?id=48557691

LLM이 압축기로서 gzip보다 얼마나 잘하나가 더 궁금함. 속도는 무시하고. Hutter Prize 상위 참가자는 신경망으로 압축하니 꽤 잘할 거임.

lossless냐 lossy냐가 문제임. 환각은 lossy 압축 아티팩트라고 봄.

이걸 분류기로 쓸 수 있을까 싶음. 채팅 스팸 분류에 LZO를 쓴 적 있는데, 스팸은 내용이 없고 반복이 많아서 잘 걸리더라. Python 3.14의 zstd 모듈로 텍스트 분류하는 글도 있음.

재밌긴 한데 예전부터 n-gram 같은 모델이 큰 신경망 모델에 근접한다는 식으로 과하게 말하는 사람이 많았음. 물론 연결은 있음.

근데 두 방법이 같은 수학 문제를 푼다는 통찰 자체는 유용함. LLM을 마법으로 보는 것보단 나음. cross-entropy loss를 이해 불가능한 마법으로 넘기는 사람한테는 특히. 틀린 건 gzip이 비슷한 복잡도나 일반화에 도달할 거라고 보는 쪽임.

3blue1brown이 이 주제로 시리즈를 했음. youtube.com/watch?v=l6DKRf-fAAM 과 GlYgs6v2YfU.

재현 가능한 모델에 프롬프트 하나로 코드베이스를 통째로 생성시키면 그 프롬프트가 코드베이스의 압축본이 되는 셈 아닌가. git clone을 압축 해제라고 하면 커널 압축본이 한 줄이 되어버리니 그건 아님. 프롬프트로 다시 생성시키는 걸 말하는 건데, 이게 압축이라고 볼 수 있나?

그건 bellard.org/ts_zip 아닌가. LLM으로 텍스트 압축하는 프로젝트임.

좀 헷갈려하는 것 같은데. LLM 자체는 다음 토큰 확률을 주는 거고, 그 확률에 arithmetic coding을 적용하면 결정적인 압축/해제 알고리즘이 나옴. 생성할 때 샘플링하든 최고 확률만 고르든 그건 부차적인 문제임.

PR이나 change set 맥락에서 생각해봤는데, 텍스트에서 코드로 가는 과정이 믿을 만하면 코드 대신 프롬프트를 주면 되지 않나. 코드는 중간 표현이 되는 거임.