gzip은 언어 모델이 될 수 있을까요?

AI 요약

신경망도 학습 파라미터도 없이 gzip만으로 언어 모델을 만들 수 있는지 실험합니다. 출발점은 예측 모델과 압축 알고리즘이 서로 연결된다는 관찰입니다. 어떤 예측 모델이든 높은 확률의 데이터를 짧게 표현하는 압축기로 볼 수 있고, 압축기는 다음 데이터에 대한 확률 모델을 내부에 품고 있습니다.

압축기가 다음 텍스트를 예측하는 방식

정보 이론에서 기호를 표현하는 데 필요한 비트 수는 모델이 부여한 확률 p에 따라 -log₂ p로 정해집니다. 자주 나올 것으로 예상하는 기호에는 적은 비트를 쓰고, 예상하지 못한 기호에는 많은 비트를 씁니다.

gzip이 사용하는 DEFLATE는 최근 32KiB의 텍스트를 sliding window에 보관합니다. 새로 들어온 바이트열이 창 안의 기존 텍스트와 일치하면, 원문을 다시 쓰는 대신 이전 위치와 길이를 가리키는 back-reference로 짧게 표현합니다. 따라서 현재 문맥에서 후보 텍스트를 gzip으로 압축한 뒤 결과 길이를 재면 후보의 예측 정도를 점수화할 수 있습니다.

score(candidate) = len(gzip(context + candidate))

압축 결과가 짧을수록 gzip이 해당 후보를 더 잘 예상했다고 봅니다. 코퍼스를 먼저 압축 창에 넣으면 코퍼스에 등장했던 표현은 짧게 압축되고, 코퍼스와 다른 표현은 상대적으로 길게 압축됩니다. 실제 구현은 gzip 프로세스를 실행하지 않고 Python 표준 라이브러리의 zlib를 사용합니다. 둘 다 DEFLATE를 사용하기 때문에 프로젝트 이름은 GziPT로 정했습니다.

한 바이트씩 고르지 않는 beam search

다음 바이트 하나를 매번 고르는 단순한 방식은 잘 작동하지 않습니다. gzip이 반환하는 압축 길이가 정수 단위이기 때문입니다. 후보에 바이트 하나를 추가해도 압축 길이가 그대로인 경우가 많아 여러 후보가 동률을 이루고, 작은 차이가 양자화 잡음에 묻힙니다.

GziPT는 여러 바이트를 미리 살펴본 뒤 한 번에 확정합니다. 각 단계에서 문맥은 코퍼스 window와 prompt 및 생성 결과의 최근 tail로 구성합니다. 가능한 다음 바이트를 코퍼스에 실제로 등장한 바이트로 제한하고, 후보별로 문맥과 후보를 압축합니다. 그중 압축 길이가 가장 짧은 일부 후보만 beam_width만큼 남긴 뒤 다음 바이트를 확장합니다. horizon 길이만큼 탐색한 뒤 가장 압축이 잘 되는 전체 span을 출력하고, 다시 같은 과정을 반복합니다. temperature가 양수면 최종 후보 중 하나를 샘플링합니다.

처음부터 시작하는 별도 start token은 없습니다. 사용자가 입력한 prompt 바이트 자체가 gzip이 보는 문맥이 됩니다. 생성 결과 전체를 계속 문맥에 넣지도 않습니다. DEFLATE는 가까운 위치의 일치에 더 싼 코드를 부여하므로 전체 생성 기록을 보여주면 방금 출력한 문장을 그대로 반복하는 loop에 빠지기 쉽습니다. 그래서 최근 tail만 점수 계산에 남깁니다.

Shakespeare 실험과 한계

tiny Shakespeare를 코퍼스로 넣고 MENENIUS:\n을 prompt로 주자 다음과 같은 결과가 나왔습니다.

MENENIUS: 'Though all at once canq MARCIUS: Pray now, nocamest thou to a morsel . LARTIUS: Hence, and I' the end admire, where G again; and after it ag .

문법과 의미가 안정된 문장은 아니지만 Shakespeare 텍스트에 등장하는 인물명, 표현, 철자 패턴을 반영합니다. 저자는 gzip이 예상보다 많은 정보를 텍스트에서 포착했다고 설명합니다. 논문에서도 같은 방향의 실험을 시도했지만 결과는 좋지 않았고, beam search를 추가하자 생성 품질이 크게 나아졌다고 정리합니다. 다만 이 실험은 압축 길이를 줄이는 후보를 찾는 방식이며, 신경망 언어 모델과 같은 범용적인 문맥 이해나 생성 능력을 보여주는 실험은 아닙니다.

Hacker News 반응

• @mg — 이 검색이 얼마나 잘 수행됐는지 어떻게 알 수 있나요? 의미 있는 검색 공간을 탐색할 방법이 없습니다. 따라서 결과는 gzip이 텍스트 연속 부분의 그럴듯함을 검사하는 능력에 대한 하한만 보여줍니다. 가능한 시퀀스 공간은 실제로 탐색한 공간보다 몇 자릿수나 큽니다. 그 안에 훨씬 더 잘 압축되는 시퀀스가 있을 수도 있습니다. 글에서 beam search를 언급하지만, gzip 압축성이 가장 높은 전역 최적해를 찾는 데 beam search가 얼마나 잘 작동하는지는 설명하지 않는 것 같습니다.
  • @shoo — 길이 n인 모든 시퀀스 x 중 len(gzip(context + prompt + x))를 전역적으로 최소화하는 x를 찾는 방법이 있다고 해도, 그것이 유용한지는 분명하지 않습니다. DEFLATE는 평문 입력에서 반복 부분 문자열을 찾아 이전 위치에 대한 back-reference로 바꾸기 때문입니다. 예를 들어 문맥 안에 prompt + y가 포함된 길이 200의 y가 있다면, DEFLATE는 그 부분을 이전 문자열에 대한 참조로 매우 짧게 표현할 수 있습니다. y가 목적 함수의 전역 최솟값이 아니더라도 거의 최적에 가까운 후보가 될 가능성이 큽니다. 입력 문맥의 큰 부분을 반복하면 압축 길이는 줄어들지만, 생성 모델로서는 별로 도움이 되지 않습니다.
• @bob1029 — attention이나 그에 가까운 무언가가 없으면 어렵습니다. gzip이 상대적으로 빠르다는 사실부터 뭔가 빠져 있다는 단서를 얻을 수 있습니다. gzip은 하나의 특정한 서사에 대해서는 다음 토큰을 잘 예측하지만, LLM은 모든 종류의 서사에 대해 다음 토큰을 예측합니다. 가능한 공간에서 올바른 다음 토큰을 찾는 작업은 입력 크기에 따라 대략 제곱으로 늘어나고, gzip은 선형으로 확장됩니다. 1TB 파일도 gzip으로 처리할 수 있지만, 그만큼의 입력을 LLM에 넣는 장면을 상상해 보세요. 둘은 아주 작은 영역에서 겹칠 뿐 전혀 다른 종류입니다. 압축과 지능을 동일시하는 주장은 점점 우스워 보입니다. 언어 모델을 압축과 비교해야 한다면 gzip이나 flac보다는 JPEG나 MP3에 더 가깝습니다. JPEG 파일은 비트스트림을 꽤 심하게 건드려도 디코딩 결과가 어느 정도 성능을 유지하지만, gzip은 전혀 그렇지 않습니다.
  • @Retr0id — gzip이 선형으로 확장되는 이유 중 하나는 window 크기가 32KiB로 제한되어 있기 때문입니다. 최적 압축을 찾으려 한다면 적어도 그 window 안에서는 제곱 시간에 가까워질 것 같습니다.
  • @Sesse__ — match를 찾는 작업에 제곱 시간이 필요하지는 않습니다. 다만 gzip block을 진정으로 최적으로 나누는 작업은 실제로 매우 느립니다.
  • @bob1029 — window에 관한 지적은 인정합니다. 그래도 gzip은 단일 CPU 코어의 물리적 한계 안에서 실행되고 대개 로컬 캐시에 전부 들어갑니다. 중요한 점은 단순히 제곱 확장이 아니라 무엇을 기준으로 확장하느냐입니다. 초당 300MB로 실행되는 LLM을 보여주세요. 가중치를 칩에 구워 넣은 전용 ASIC도 이 속도를 내지는 못할 것입니다.
  • @fedeb95 — 동의하지만 LLM을 지능과 동일시하는 것도 잘못입니다.
• @tromp — 반대 방향이 더 궁금합니다. 엄청나게 느리다는 점을 무시하면 LLM은 gzip과 비교해 압축기로 얼마나 잘 작동하나요?
  • @gkbrk — Hutter Prize의 상위 참가작은 신경망을 압축에 사용합니다. 따라서 LLM도 gzip과 비교하면 꽤 잘 작동한다고 봐도 됩니다.
  • @computably — Hutter Prize의 평가 지표에는 압축 해제기의 크기도 포함됩니다. LLM은 압축 해제기가 1GB보다 크기 때문에 탈락합니다.
  • @londons_explore — Hutter Prize는 GPU도 금지합니다. 강력한 GPU 사용을 허용하면 훨씬 더 나은 결과를 낼 수 있습니다.
• @mentalgear — 흥미로운 접근입니다. 이 방법을 classifier로 사용할 수 있을지 궁금합니다.
  • @Sesse__ — 채팅에서 LZO를 spam classifier로 사용한 적이 있습니다. spam은 대체로 내용이 없고 반복적이기 때문입니다.
  • @networked — Python 3.14의 zstd 모듈을 이용한 텍스트 분류 글을 확인해 보세요. 이 댓글에 연결하고 싶었습니다.
• @jll29 — gzip으로 다음과 같이 텍스트 파일의 주제를 분류할 수 있습니다. gzip -9 sports.txt testfile.txt, gzip -9 politics.txt testfile.txt, gzip -9 business.txt testfile.txt를 각각 실행합니다. 세 파일이 같은 크기이고 sports, politics, business 주제의 문서라면, 가장 작은 .gz 파일을 만든 주제가 테스트 파일의 주제입니다. Waikato University의 Witten 연구팀이 이 작업을 처음 시도한 그룹 중 하나였을 것입니다. 이 분야에 관심이 있다면 Hutter Prize도 확인해 보세요.
• @montebicyclelo — 재미있는 실험이지만, 이런 모델이나 n-gram 언어 모델이 대형 신경망 모델에 근접했다는 식으로 말하면 역사적으로 과장하는 경우가 많았습니다. 둘 사이에 연결점은 분명히 있습니다.
• @berkes — 관련된 질문을 생각해 본 적이 있습니다. 같은 prompt에 같은 출력을 내는 재현 가능한 LLM이 있다고 합시다. 그런 모델로 코드를 생성하도록 연결하면, 전체 codebase나 긴 텍스트를 만들어내는 prompt를 만들 수 있습니다. 이때 prompt, 더 정확히는 token이 codebase나 텍스트의 압축 버전이 됩니다. 다만 한 번의 호출과 하나의 prompt로 LLM이 텍스트를 다시 생성하게 만드는 구상입니다. 아주 비현실적이고 비효율적일 것 같지만, 이것을 압축이라고 부를 수 있을까요?
  • @evgpbfhnr — Fabrice Bellard가 만든 Text Compression using Large Language Models를 설명하는 것 같습니다.
• @relevant_stats — 또 하나의 AI 작성 글과 vibe-coded aesthetics입니다. 어떤 사람은 형식이 아니라 아이디어를 평가해야 한다고 말하겠지만, 작성자가 자신의 작업을 설명하는 짧은 700단어 글조차 직접 쓰지 않을 만큼 관심이 없었다면 다른 사람이 왜 신경 써야 하나요? 이런 낮은 노력은 작업 전체가 피상적이고 파생적일 가능성을 보여줍니다.

원문: Nathan.rs / 번역·요약: Trawling