Seu LLM favorito é um WinRAR disfarçado
Parece piada, mas a matemática não mente: o mesmo princípio que faz o ZIP encolher seus arquivos é o que permite ao GPT completar suas frases. Compressão e predição são, na prática, o mesmo problema visto por ângulos diferentes. E entender essa equivalência muda completamente a forma como você pensa sobre modelos de linguagem.
Essa conexão não é nova. Claude Shannon já tinha percebido isso em 1948, quando publicou “A Mathematical Theory of Communication”. Mas com a explosão dos LLMs, o tema voltou à tona com força total, inclusive viralizando no Hacker News com o artigo “Compression is Prediction” do blog da ngrok.
Vamos desmontar essa ideia peça por peça.
Shannon e a entropia: onde tudo começa
Em 1948, Shannon definiu o conceito de entropia da informação. A ideia é simples na superfície: quanto mais previsível é uma mensagem, menos informação ela carrega.
A fórmula clássica é:
H(X) = -Σ p(x) * log₂(p(x))
Onde p(x) é a probabilidade de cada símbolo aparecer. Se a letra “A” aparece 90% das vezes em uma sequência, você precisa de poucos bits para representá-la. Se a distribuição é uniforme entre 26 letras, cada uma exige mais bits.
O ponto crucial: a entropia define o limite teórico mínimo de compressão. Você nunca vai comprimir um arquivo abaixo da sua entropia sem perder informação. É uma lei da física da informação.
E aqui aparece a primeira ponte: para calcular a entropia, você precisa conhecer as probabilidades. E conhecer probabilidades é… prever o que vem a seguir.
Run-Length Encoding: compressão para crianças (e para entender o conceito)
Antes de mergulhar nos LLMs, vale ver o caso mais básico de compressão. Pega essa string:
AAAAAAAAABBBBCCDAAADDDDDDDDD
São 28 caracteres. Um compressor simples (Run-Length Encoding) transforma isso em:
A9B4C2D1A3D9
12 caracteres. Comprimiu 57%. Funciona porque existe repetição, e o compressor “previu” que sequências iguais são comuns.
Mas RLE é burro. Ele só detecta repetições consecutivas. Textos reais não funcionam assim. É aí que as coisas ficam mais interessantes.
Contexto muda tudo: modelos de ordem N
Em inglês, a letra U aparece em cerca de 2,8% do texto. Mas depois de um Q? A probabilidade salta para 99,9%. Se você sabe que o caractere anterior é Q, pode representar o U com uma fração de bit.
Isso é um modelo de contexto de ordem 1: a probabilidade do próximo caractere depende do anterior. Modelos de ordem 2 olham dois caracteres para trás. Ordem 3, três caracteres.
A compressão melhora dramaticamente com contexto. Segundo dados do artigo da ngrok, usar um modelo de ordem 1 cortou o tamanho comprimido pela metade comparado a um modelo sem contexto. Por quê? Porque com contexto, as previsões ficam melhores, e previsões melhores significam menos bits.
Aqui a equivalência fica nítida: melhor predição = melhor compressão. São a mesma coisa.
Codificação aritmética: transformando probabilidades em bits
OK, mas como exatamente você transforma probabilidades em dados comprimidos? A resposta é a codificação aritmética, um dos algoritmos mais elegantes da ciência da computação.
A ideia: represente uma sequência inteira de símbolos como um único número entre 0 e 1. Cada novo símbolo estreita o intervalo com base na sua probabilidade.
Funciona assim:
- Comece com o intervalo [0, 1)
- Divida o intervalo proporcionalmente às probabilidades dos símbolos
- Para cada símbolo na mensagem, selecione o sub-intervalo correspondente
- Repita até processar toda a mensagem
- O número final dentro do último intervalo é a mensagem comprimida
Vou dar um exemplo concreto. Suponha que você tem três símbolos: A (probabilidade 0,6), B (0,3) e C (0,1). O intervalo [0, 1) fica dividido assim: A ocupa [0, 0,6), B ocupa [0,6, 0,9), C ocupa [0,9, 1,0).
Para codificar a mensagem “AB”:
- Primeiro símbolo A: selecione [0, 0,6)
- Dentro desse sub-intervalo, divida novamente: A fica em [0, 0,36), B em [0,36, 0,54), C em [0,54, 0,6)
- Segundo símbolo B: selecione [0,36, 0,54)
- Qualquer número nesse intervalo (por exemplo, 0,4) representa a mensagem “AB”
Símbolos mais prováveis ocupam faixas maiores, então precisam de menos bits para serem especificados. Símbolos raros ocupam faixas minúsculas, exigindo mais bits.
A fórmula é direta: o número de bits necessários para um símbolo é -log₂(probabilidade). Se a probabilidade é 0,5 (50%), você precisa de 1 bit. Se é 0,25 (25%), 2 bits. Se é 0,9 (90%), apenas 0,15 bits.
Percebe o padrão? O codificador aritmético precisa de um modelo de probabilidades para funcionar. E quem fornece essas probabilidades? Um preditor. O compressor não é nada sem o modelo preditivo por trás dele. São duas peças da mesma engrenagem.
E o GPT nisso tudo?
Agora vem a parte que conecta tudo. O que um LLM faz durante o treinamento?
Ele recebe uma sequência de tokens e tenta prever o próximo. A função de perda que ele minimiza é a cross-entropy, que mede a diferença entre as probabilidades previstas pelo modelo e a distribuição real dos dados.
Traduzindo para português: o LLM está aprendendo a prever melhor o próximo token. E como acabamos de ver, prever melhor é comprimir melhor.
O paper “Language Modeling Is Compression” do DeepMind (Deletang et al., 2023) formalizou essa ideia. Os pesquisadores demonstraram que um Transformer treinado, combinado com codificação aritmética, funciona como um compressor de dados extremamente eficiente.
Os números impressionam. Segundo dados do artigo da ngrok, o GPT-2 conseguiu comprimir um trecho de Dickens para 10% do tamanho original. Um modelo de contexto básico (ordem 1) chegou a 24%. O GPT-2, com seu contexto massivo e compreensão profunda da estrutura da linguagem, comprime mais de duas vezes melhor.
E aqui está o insight que faz tudo clicar: a loss function do seu LLM é literalmente a quantidade de bits necessária para compressão sem perda. Quando você vê que o GPT-4 tem uma perplexidade menor que o GPT-3, isso significa, matematicamente, que ele é um compressor melhor.
Na prática: como isso funciona?
Imagine que você tem um texto de 10.000 tokens e quer comprimi-lo usando um LLM.
| Etapa | O que acontece |
|---|---|
| 1 | O LLM processa cada token e gera probabilidades para o próximo |
| 2 | O codificador aritmético usa essas probabilidades para codificar o token real |
| 3 | Tokens previstos com alta confiança gastam pouquíssimos bits |
| 4 | Tokens surpreendentes (baixa probabilidade) gastam muitos bits |
| 5 | O resultado é um bitstream menor que o original |
Para descomprimir, basta rodar o processo inverso: o decodificador aritmético usa o mesmo LLM para reconstruir as probabilidades e decodificar cada token.
O paper LLMZIP da Universidade de Stanford mostrou que essa abordagem funciona até com textos que não estavam nos dados de treinamento. O LLM generaliza tão bem que consegue comprimir textos nunca vistos melhor do que compressores tradicionais.
Se LLMs são tão bons, por que não usamos eles para comprimir tudo?
Boa pergunta. E a resposta é simples: overhead.
Um compressor como o gzip ocupa alguns kilobytes e roda em milissegundos. O GPT-2 ocupa 500MB. O GPT-4, provavelmente centenas de gigabytes. Para descomprimir um arquivo de 1KB, você precisaria carregar o modelo inteiro.
É como usar um caminhão de mineração para transportar uma caixa de sapatos. Tecnicamente possível, absurdamente ineficiente.
| Compressor | Tamanho do modelo | Velocidade | Taxa de compressão |
|---|---|---|---|
| gzip | ~100KB | Muito rápida | Boa |
| zstd | ~1MB | Rápida | Muito boa |
| GPT-2 + aritmético | ~500MB | Lenta | Excelente |
| GPT-4 + aritmético | ~???GB | Muito lenta | A melhor |
Na prática, o custo computacional inviabiliza o uso de LLMs como compressores de propósito geral. Mas a equivalência teórica permanece poderosa por motivos que vão além de comprimir arquivos.
Por que isso importa para quem trabalha com IA
Entender que compressão = predição traz vários insights práticos:
1. Scaling laws fazem mais sentido. Modelos maiores comprimem melhor. É por isso que modelos com mais parâmetros têm perplexidade menor: eles estão capturando padrões mais sutis nos dados, permitindo previsões mais precisas e, por consequência, compressão mais eficiente.
2. Tokenização é um truque de compressão. O BPE (Byte Pair Encoding) usado pelo GPT é, em si, um algoritmo de compressão. Ele encontra pares de bytes frequentes e os substitui por tokens únicos. A tokenização já comprime o texto antes do modelo sequer entrar em ação.
3. In-context learning é compressão adaptativa. Quando você dá exemplos no prompt e o modelo “aprende” a tarefa, ele está efetivamente atualizando seu modelo de probabilidades. Isso é exatamente o que compressores adaptativos como LZ77 fazem: ajustam suas previsões com base nos dados já processados.
4. Alucinação é descompressão com erro. Se o modelo é um compressor, alucinações são artefatos de descompressão. O modelo gera sequências que são estatisticamente plausíveis (alta probabilidade), mas factualmente incorretas. É como reconstruir um JPEG com qualidade muito baixa: a estrutura está lá, mas os detalhes estão errados.
5. Qualidade dos dados é tudo. Dados repetitivos ou de baixa qualidade são fáceis de comprimir (alta redundância), mas não ensinam padrões novos ao modelo. Dados diversos e de alta qualidade têm entropia mais alta, forçando o modelo a aprender representações mais ricas para comprimi-los.
O Prêmio Hutter: compressão como benchmark de inteligência
Marcus Hutter, pesquisador do DeepMind, criou em 2006 um prêmio para quem melhor comprimir os primeiros 1GB da Wikipedia em inglês. A premiação atual é de 500.000 euros.
A lógica é provocativa: se compressão e predição são equivalentes, então um compressor perfeito seria uma IA perfeita. Comprimir a Wikipedia significa entender a Wikipedia: capturar toda a estrutura, gramática, semântica e conhecimento factual contido nela.
O Prêmio Hutter é basicamente um benchmark de inteligência artificial disfarçado de competição de compressão. E os melhores resultados recentes, não surpreendentemente, usam modelos baseados em Transformers.
Limitações da analogia
Claro, dizer que “LLMs são compressores” não conta a história toda.
Compressores tradicionais são lossless: a descompressão reproduz os dados originais bit a bit. LLMs gerando texto são lossy por natureza. Eles produzem saídas plausíveis, não reproduções exatas. Quando o ChatGPT completa sua frase, ele não está “descomprimindo” um texto específico que existe em algum lugar. Ele está gerando uma continuação provável baseada em padrões estatísticos.
Além disso, LLMs fazem coisas que compressores puros não fazem: seguem instruções, raciocinam sobre problemas, escrevem código. A capacidade de generalizar para tarefas nunca vistas vai além da pura compressão de dados. Ninguém pede para o gzip resolver um problema de programação.
Existe também o argumento de que compreensão é mais do que compressão. Um papagaio pode repetir frases perfeitamente (compressão perfeita), mas isso não significa que ele entende o que está dizendo. A mesma crítica se aplica a LLMs: comprimir bem os padrões da linguagem não implica necessariamente em compreensão genuína.
Mas a base matemática é inescapável. O objetivo do treinamento (minimizar cross-entropy) é equivalente a maximizar a eficiência de compressão. Toda melhoria no modelo como preditor é, simultaneamente, uma melhoria como compressor. E na prática, os modelos que comprimem melhor também são os que performam melhor em tarefas downstream. Coincidência? A teoria de Shannon diria que não.
Ferramentas que já exploram essa conexão
Essa equivalência não é apenas acadêmica. Ferramentas reais já usam esse princípio.
O Headroom, criado por um engenheiro sênior da Netflix, é um proxy open source que comprime o contexto enviado aos LLMs, cortando 60% a 95% dos tokens sem perda de acurácia. Ele intercepta outputs de ferramentas (logs, resultados de busca, chunks de RAG), comprime usando seis engines diferentes (incluindo redução AST-aware de código e otimização de JSON), e envia a versão comprimida ao modelo. O conteúdo original fica em cache local para referência.
Em cinco meses, o Headroom acumulou mais de 39.000 estrelas no GitHub e economizou coletivamente cerca de US$ 700.000 em tokens. Em uma demo, um input de 10.144 tokens foi comprimido para 1.260 tokens, e a IA ainda identificou corretamente o mesmo erro FATAL que encontrou no input completo.
Isso funciona exatamente porque LLMs são bons compressores: eles não precisam de toda a informação, só da informação que não conseguiriam prever sozinhos. O Headroom remove o que é redundante, e o modelo continua performando igual porque aquela informação já estava “implícita” na sua distribuição de probabilidades.
De Shannon ao Transformer
Shannon não tinha como imaginar que sua teoria de 1948 seria a base de modelos com centenas de bilhões de parâmetros. Mas a conexão é direta e ininterrupta: entropia define o limite da compressão, compressão exige predição, predição é o que LLMs otimizam.
A próxima vez que você usar o ChatGPT, lembre que, no fundo, ele está fazendo a mesma coisa que o WinRAR. Só que em vez de comprimir seus arquivos, ele está “descomprimindo” a linguagem humana, token por token, prevendo o que provavelmente viria a seguir baseado em trilhões de exemplos.
A diferença? O WinRAR cabe em 3MB. Seu LLM favorito, não.
Quem diria que a resposta para “o que é inteligência artificial” estava escondida dentro de um arquivo .zip esse tempo todo.
Fonte de inspiração: Compression is Prediction (ngrok blog)













