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

gzip으로 주제를 분류할 수 있음. 크기가 같은 스포츠·정치·경제 문서 sports.txt, politics.txt, business.txt를 준비하고, 각각 gzip -9 sports.txt testfile.txt, gzip -9 politics.txt testfile.txt, gzip -9 business.txt testfile.txt를 실행하는 방식임. 가장 작은 *.gz 파일을 만드는 주제가 테스트 파일의 주제에 해당함.
Waikato 대학의 Witten 연구팀이 아마 처음 이 분야를 연구했을 것임. 관심이 있다면 Hutter Prize도 살펴볼 만함.

약 20년 전에 이런 방식으로 언어 감지를 구현했음. 언어별 Wikipedia 문서로 gzip 압축기의 사전을 초기화한 뒤, 임의의 텍스트를 가장 잘 압축하는 사전의 언어를 정답으로 선택했음.
최선의 접근법은 전혀 아니지만, 아주 빠르고 구현도 무척 간단함.

기계 학습·압축·암호학 사이에는 정보 이론을 공통분모로 하는 깊은 연결이 있음. 그나저나 “aside”를 “ass.”로 줄인 것은 처음 봄. 나는 보통 N.B.를 쓰지만, 중요한 부연에만 쓰는 편임.

일반 텍스트 프롬프트를 주면 가장 잘 압축되는 바이트열을 찾아 이어 쓴다는데, 탐색이 얼마나 잘됐는지는 어떻게 알 수 있을까? 탐색 공간의 유의미한 부분을 훑는 것 자체가 불가능함.
따라서 이 결과는 gzip이 이어지는 텍스트의 그럴듯함을 평가하는 도구로서 얼마나 잘 작동하는지에 대한 하한만 보여줌. 가능한 바이트열의 공간은 실제 탐색한 범위보다 여러 자릿수만큼 크므로, 훨씬 잘 압축되는 바이트열이 남아 있을 수 있음. 빔 탐색을 썼다고는 하지만, gzip 압축성의 전역 최적해를 얼마나 잘 찾는지는 논의하지 않은 것 아닌가?

길이가 n인 모든 바이트열 x에 대해 len(gzip(context + prompt + x))를 전역 최소화할 수 있다고 가정해도, 그것이 생성 도구로 유용할지는 불분명함. 여기서 +는 문자열 연결임.
Deflate는 반복되는 부분 문자열을 앞서 나온 문자열에 대한 역참조로 바꿈. 예를 들어 n=200일 때 prompt+y가 이미 context에 있다면, 그 부분을 허프만 부호로 표현한 일치 길이와 거리만으로 저장할 수 있음. 이것이 전역 최적해가 아니더라도 상당히 좋은 근사해일 가능성이 큼. 결국 입력 문맥의 큰 덩어리를 그대로 반복하는 것이 압축 크기를 줄이는 데는 좋지만, 생성 모델로서는 별 도움이 안 됨.
실제로 실험해 보니 문맥에서 프롬프트를 찾아 뒤의 텍스트를 복사하는 방식이 빔 탐색보다 압축 목적함수를 훨씬 잘 최소화했음. 블로그와 동일하게 tinyshakespeare.txt의 첫 30,000바이트, 프롬프트 MENENIUS:\n, 출력 길이 200바이트를 사용했음.
빈 문자열은 길이 조건을 충족하지 않지만 압축 결과가 13,023바이트이고 0.04초가 걸림. gzipt 빔 탐색은 13,051바이트와 11.93초, rfind 기반 복사는 13,026바이트와 0.04초였음. 복사한 결과는 빈 문자열보다 겨우 3바이트 크고, 빔 탐색 결과보다 25바이트 작음.
구현도 context.rfind(prompt, 0, n-length)로 마지막 일치 위치를 찾고, 프롬프트 바로 뒤의 length바이트를 반환하는 것이 전부임. gzipt.py에서 out을 정의한 뒤 빔 탐색 전에 out += find_candidate_solution_from_context(corpus_window, prompt, length)를 넣으면 연결할 수 있음.

같은 프롬프트에 같은 출력을 내는 모델로 코드나 긴 텍스트를 재현할 수 있다면, 프롬프트 자체를 압축된 데이터로 볼 수 있을까? 코드베이스 전체를 생성하는 프롬프트가 있다면, 그 프롬프트의 토큰들이 압축본이 되는 셈임.
에이전트가 아니라 재현 가능한 방식으로 호출하는 모델을 뜻하며, 가능하면 프롬프트 하나로 한 번만 호출하는 형태를 생각하고 있음. 에이전트가 git clone을 실행해 코드베이스를 가져오는 것을 압축 해제라고 부르면 개념이 뒤섞임. 그 논리라면 커널의 압축본은 git clone과 저장소 주소 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... 한 줄이면 충분해짐.
내가 생각하는 것은 LLM이 프롬프트를 바탕으로 텍스트를 직접 재생성하는 방식임. 매우 비실용적이고 비효율적일 수 있겠지만, 이것도 압축에 해당할까?

약간 혼동하고 있는 듯함. LLM 신경망 자체는 앞선 토큰들이 주어졌을 때 다음 토큰의 확률을 계산함. 이 확률에 산술 부호화를 적용하면 결정론적인 압축·복원 알고리즘을 만들 수 있음.
텍스트 생성은 그 확률분포에서 표본을 뽑는 과정임. 진짜 난수를 쓸 수도 있고, 시드가 고정된 의사난수 생성기나 매번 최고 확률의 토큰을 고르는 방식으로 결정론적으로 만들 수도 있음. 하지만 핵심은 그쪽이 아니라 산술 부호화임. https://en.wikipedia.org/wiki/Arithmetic_coding

미래의 운영체제 기본 앱 배포에 흥미로운 방식이 될 수 있음. Android에서 계산기 버튼을 누르기 전까지는 앱이 존재하지 않고, 클릭하면 프롬프트로 생성하는 식임. 다만 매번 다른 UI가 나오면 곤란하므로, 단순하게 적용하기에는 문제가 있음.

나도 풀 리퀘스트나 변경 묶음과 관련해 생각해 본 적이 있음. 텍스트에서 코드로의 변환이 신뢰할 만하다면, 코드 대신 프롬프트를 전달하면 되지 않을까? 코드는 그저 중간 표현이 됨.

재미있지만, 이런 모델이나 n-그램 언어 모델이 대규모 신경망 모델에 근접한다고 지나치게 부풀리는 일이 과거에도 있었음. 물론 둘 사이에 연결은 분명히 있음.

두 방법이 같은 수학적 문제를 푼다는 통찰은 유용함. LLM을 마법처럼 보는 것보다 나음. 통계 배경이 없는 사람에게 교차 엔트로피 손실이라고 하면 Wikipedia를 잠깐 보고는 이해 불가능한 마법으로 받아들이기 쉬움.
핵심 차이를 허용되는 CPU·메모리·저장 공간 사이의 절충으로 이해하는 것도 완전히 틀리지는 않음. 다만 gzip이 비슷한 복잡성이나 일반화 능력에 도달할 수 있다고 보거나, 지시 학습·사고 사슬 LLM의 학습 데이터를 정교하게 선별하고 생성하는 과정을 무시하면 잘못됨.
그래도 LLM의 목표를 텍스트 압축으로 이해하는 것 자체는 틀리지 않음. 다음으로 물어야 할 것은 어떤 종류의 텍스트를 압축하려 하느냐임.

동영상 압축으로도 가능할까? 동영상 코덱은 화면 속 물체의 움직임을 추적하는 움직임 벡터처럼 상당한 의미 정보를 부호화함.

나는 반대 질문이 더 궁금함. 엄청나게 느리다는 점을 무시하면, LLM의 압축 성능은 gzip과 비교해 어느 정도일까?

Hutter Prize의 최상위 참가작은 압축에 신경망을 사용함. 그러니 LLM도 gzip에 비해 꽤 잘할 것이라고 볼 수 있음.

무손실인지 손실 압축인지가 관건임.

bzip2와 zstd에서는 어떻게 작동할지 궁금했음. 공개 소스 https://github.com/nathanrs/gzipt를 MiMo-V2.6-Flash에 포크하고 단순하게 수정해 달라고 요청했음. tinyshakespeare.txt와 프롬프트 MENENIUS:\n으로 200바이트를 생성해 보니, bzip2는 인간 언어와 닮지 않은 xyxyxy 같은 반복 문자열을 출력함. 대략 버로스–휠러 변환 결과가 최대한 반복적이 되도록 최적화한 듯함. 그런데 왜 한 기호의 반복이 아니라 여러 기호가 번갈아 나오는 걸까? https://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transf... Zstandard는 대부분 공백에 가끔 글자만 섞어서 출력함. MiMo의 설명에 따르면, zstd는 같은 바이트의 반복을 거의 비용 없는 반복 길이 부호로 표현하며, 이 말뭉치에서 공백과 줄바꿈이 가장 저렴한 리터럴임. 줄바꿈 10개를 추가하는 비용은 실제 말뭉치 텍스트 10바이트를 추가하는 것과 비슷하고, 무의미한 문자열보다는 작다고 함.

댓글을 올리기 전에 MiMo가 이 낯선 작업을 올바르게 수행했는지 확인했는가?

AI가 작성한 코드를 이해하지 못한 채, 이해하지 못하는 출력까지 다른 사람이 읽도록 인터넷에 올린 것인가?