GziPT: cómo gzip imita a un modelo de lenguaje sin redes neuronales

Qué significa que gzip pueda "hablar"

El ingeniero Nathan Basyal demostró en un experimento reciente que el compresor gzip, esa utilidad que cualquier sistema operativo trae de fábrica desde los años 90, puede generar texto parecido al de Shakespeare si lo "primingas" con un corpus y le pides que continúe un prompt. La salida no es coherente como la de un LLM, pero conserva vocabulario, nombres propios y estructuras métricas del inglés isabelino. Todo sin una sola neurona artificial, sin parámetros entrenados y sin GPU: solo el algoritmo DEFLATE corriendo dentro de zlib, la librería estándar de Python.

La idea fuerza del experimento se apoya en un resultado teórico conocido como equivalencia compresión-predicción, formalizado en el paper "Language Modeling Is Compression" de Grégoire Delétang y colegas de Google DeepMind, publicado como preprint en arXiv en septiembre de 2023 (arXiv:2309.10668). El paper demuestra empíricamente que todo predictor de secuencias es, en el fondo, un compresor, y que todo compresor esconde un modelo probabilístico.

Por qué comprimir es predecir (y viceversa)

La intuición es vieja: data de Shannon, de 1948. Si un modelo asigna probabilidad p a un símbolo, el número óptimo de bits para codificarlo es -log₂(p). Alta probabilidad significa pocos bits; baja probabilidad significa muchos. gzip no sabe nada de probabilidades, pero cuando comprime un archivo busca exactamente lo mismo: si el texto que viene repite algo que ya vio en su ventana deslizante de 32 KiB, lo codifica como referencia barata. Si no, gasta más bytes.

Esa longitud comprimida se convierte, sin quererlo, en un score de verosimilitud: si añades un candidato al contexto y el resultado comprimido baja de tamaño, el candidato era "esperado" por el modelo implícito del compresor. El paper de DeepMind confirma que esta propiedad permite construir un predictor condicional a partir de cualquier compresor, formalizando lo que el código de Basyal aplica con un comando tan simple como len(gzip(context + candidate)).

Cómo GziPT genera texto con beam search

El primer intento de Basyal fue naive: elegir el byte que más bajara la longitud comprimida tras añadirlo. Fracasó. El motivo es sutil: gzip devuelve longitudes enteras, así que muchos candidatos empatan en "mismo número de bytes" y la señal queda enterrada en ruido de cuantización.

La solución que implementó en su proyecto GziPT (publicado en GitHub como un único archivo de Python puro basado en zlib) es hacer beam search: en cada paso, mantiene las N mejores continuaciones parciales, las extiende probando cada byte presente en el corpus, las puntúa por longitud comprimida y poda de vuelta a las mejores. Repite durante un horizon de bytes antes de comprometerse con una continuación final.

El contexto que ve el compresor en cada paso es: ventana del corpus + cola reciente del prompt y de los bytes ya generados. Ese detalle es crítico: DEFLATE codifica más barato los matches cercanos que los lejanos, así que si el modelo pudiera ver toda su historia caería en bucles de copia literal. Limitando el contexto se fuerza a generar texto "nuevo" con el estilo del corpus.

El paper de DeepMind ya había intentado generar con gzip mirando un solo paso adelante, con resultados pobres. El propio paper menciona que extender la búsqueda a múltiples pasos (beam search) mejoraría la calidad, y eso es exactamente lo que valida el experimento de Basyal. La salida del comando gzipt --corpus data/tinyshakespeare.txt --prompt $'MENENIUS:\n' --length 200 incluye parlamentos atribuidos a MENENIUS, MARCIUS y LARTIUS con palabras reconocibles del original, aunque mezcladas con tokens rotos.

Qué dice el paper de DeepMind sobre la equivalencia

El paper "Language Modeling Is Compression" va mucho más allá del experimento con Shakespeare. Mide tasas de compresión cruda (sin contar el tamaño del modelo) sobre datasets de texto, imágenes y audio, comparando gzip, LZMA2, PNG, FLAC y modelos como Chinchilla 70B y Llama 2 (7B).

Según la Tabla 1 del paper, sobre el dataset enwik9 (1 GB de Wikipedia en inglés):

• gzip alcanza una tasa cruda del 32,3%
• LZMA2 llega al 23,0%
• Llama 2 (7B) baja al 8,9%
• Chinchilla 70B llega al 8,3%

El resultado más contraintuitivo es que los LLMs, entrenados básicamente con texto, también comprimen bien modalidades donde nunca fueron entrenados explícitamente. El paper reporta que Chinchilla 70B comprime patches de ImageNet al 43,4% (mejor que PNG, que se queda en 58,5%) y muestras de LibriSpeech al 16,4% (mejor que FLAC, en 30,3%). El paper interpreta esto como evidencia de in-context learning: el modelo usa su contexto para adaptarse a la tarea sin reentrenarse.

Eso sí: cuando se ajusta la tasa contando el tamaño del modelo en bytes, la historia cambia. Chinchilla 70B dispara su tasa ajustada a 14.008,3% sobre enwik9, porque los parámetros pesan cientos de GB. El paper demuestra que las leyes de escalado (más parámetros = mejor predicción) tienen un tope: si el dataset es finito, llega un punto en que añadir parámetros empeora la compresión ajustada porque el costo de codificar el modelo supera al beneficio de predecir mejor.

¿Qué significa esto para tu startup?

Tres ideas prácticas si trabajás con IA o construís herramientas sobre texto:

• No necesitás un transformer para todo. Para tareas de clasificación de texto cortas (detección de spam, sentimiento, categorías), técnicas basadas en distancias sobre gzip han demostrado resultados competitivos sin entrenar nada. El paper cita el trabajo de Jiang et al. 2023 ("Low-resource text classification") que muestra a gzip rivalizando con modelos neuronales en benchmarks NLP con costo computacional casi nulo. Si tu cuello de botella es latencia o costo por inferencia, vale la pena probar enfoques no-paramétricos con compresores.
• Tu corpus es tu modelo. El experimento de GziPT muestra que la "calidad" de un predictor basado en compresión depende totalmente del corpus que metés en la ventana. Para founders que construyen sistemas de RAG o búsqueda semántica, esto refuerza una lección conocida: la calidad del contexto que le das al modelo importa más que el modelo en sí. Curar bien el corpus de priming es, literalmente, programar el modelo implícito.
• Las fronteras entre "comprimir" y "predecir" se están borrando. Los papers recientes tratan la tokenización como pre-compresión y el entrenamiento de LLMs como maximización de compresión (cross-entropy = longitud de codificación aritmética). Si tu producto toca alguno de estos temas (fine-tuning, cuantización,destilacion, retrieval), entender la equivalencia te da un marco más limpio para razonar sobre trade-offs de tamaño de modelo vs. tamaño de dataset.

Lecciones técnicas que deja el experimento

El proyecto es didáctico por una razón: condensa en un solo archivo las piezas mínimas que necesita cualquier sistema de sequence modeling (incluso uno no neuronal): un mecanismo de scoring (longitud comprimida), un algoritmo de búsqueda (beam search), una función de poda (quedarse con los N mejores), y un bucle autoregresivo (comprometerse a un span y reiniciar el contexto). Los LLMs actuales reemplazan el primer elemento por una red neuronal entrenada, pero la estructura del bucle es la misma.

El detalle de mantener solo la cola reciente en el contexto, descartando la historia lejana, también recuerda técnicas que verás en implementaciones modernas de sliding window attention o en RAG con ventana deslizante. La intuición es idéntica: lo reciente pesa más, y truncar evita que el optimizador haga trampa cayendo en patrones de copia.

Por último, el paper de DeepMind demuestra que el beam search no es solo un truco para que gzip mejore: aplicado a Chinchilla 1B y Chinchilla 7B, permite generar muestras de texto casi indistinguibles del ground truth en el ejemplo de los Lords of Appeal que el paper reproduce (la continuación ground truth era "she remains a member of the House of Lords without a need for an election. In [[2000]], the governm", y Chinchilla 70B genera "she may use either title, but the hereditary peerage is considered to be superior" con sintaxis perfectamente inglesa). La diferencia con gzip, que genera texto ruidoso tipo "Suasa8g thformp0iufoof Lo e7vkoasaeka w8viiufoounb", es exactamente la diferencia entre un buen modelo y uno malo.

Fuentes

• Can gzip be a language model? — Nathan Basyal
• Language Modeling Is Compression — Delétang et al., arXiv:2309.10668