Compressor de conhecimento corta tokens de documentação pela metade

Redundância virou custo na era dos tokens

Linguagem natural carrega muita repetição e redundância, algo útil para lidar com o ruído da comunicação, mas que ganhou um custo direto com modelos de linguagem: tudo isso vira tokens. Em sessões de agentes, conteúdo extenso e repetitivo ocupa espaço na janela de contexto que poderia abrigar documentação sobre outros temas. Para explorar esse limite, a equipe do GitHub Next construiu o protótipo Knowledge Compressor, que recebe artigos como entrada e reduz iterativamente sua contagem de tokens, buscando garantir que o conhecimento da fonte permaneça utilizável. A constatação é que documentação técnica típica pode ter o número de tokens cortado pela metade sem redução substancial de utilidade para modelos de linguagem. Na avaliação exibida, um texto sobre um sistema sintético de cache distribuído, a Ferryline, caiu de 996 para 480 tokens.

Fidelidade medida por perguntas

Os autores comparam o desafio ao de comprimir um WAV em MP3 ou um PNG em JPEG, com uma diferença: em vez de minimizar degradação perceptível para humanos, trata-se de minimizar a degradação perceptível para LLMs - e não adianta simplesmente perguntar ao modelo, que pode inventar respostas. A alternativa foi testar. O sistema extrai perguntas e respostas do conteúdo original, em número definido automaticamente conforme extensão e densidade ou ajustável manualmente, num espírito próximo aos testes unitários. Cada pergunta é validada em uma janela de contexto nova usando o texto original; as impossíveis de responder são descartadas. A própria equipe reconhece falhas: o modelo pode recorrer a conhecimento embutido ou chutar. As mitigações são instruir o uso apenas do contexto fornecido - técnica admitidamente incompleta - e concentrar as avaliações em fatos fora do conhecimento de mundo atual, por serem posteriores ao corte de treinamento ou inteiramente sintéticos.

Um agente comprime até o limite

Iniciada a compressão agêntica, um agente recebe instruções e recomendações técnicas, além de ferramentas para ler o conteúdo original, contar tokens, aplicar diffs e rodar as perguntas de teste. Ele itera até concluir que não há mais o que encurtar; então o sistema compara o resultado com critérios de conclusão e pode devolver o rascunho para revisão. Um risco destacado é o agente jogar seguro e quase não comprimir. Por isso, a execução pode exigir que pelo menos uma pergunta falhe antes de terminar: se nenhum conteúdo relevante se perdeu, provavelmente o limite inferior não foi alcançado. Quando uma pergunta falha, o resultado retorna ao agente, que restaura o material necessário para os testes passarem de novo. Na demonstração publicada - feed abreviado, mas fruto de uma execução real, segundo a equipe - foram extraídas 24 perguntas, e o modelo usado na avaliação foi o GPT-5.6 Sol.

Quando a compressão se paga

A compressão amplia o quanto cabe de informação em uma janela e reduz o custo recorrente de reapresentar o conteúdo, mesmo quando o contexto não está saturado. O processo, porém, consome tokens próprios ao gerar perguntas, testar rascunhos e produzir a versão final. Isso permite uma pergunta concreta: quantas vezes o conteúdo comprimido precisaria ser usado para quitar o custo da compressão? Na execução avaliada, reduzir de 996 para 480 tokens custou cerca de US$ 2. Ao preço vigente do mesmo modelo, cada inclusão não cacheada economiza aproximadamente US$ 0,001, situando o ponto de equilíbrio em torno de 2.000 usos. O resultado exato depende de preço do modelo, cache, material-fonte e decisões do agente, mas, para conhecimento consultado repetidamente, a compressão pode efetivamente se pagar.

Certeza parcial e próximos passos

A resposta provisória dos autores é sim: documentação pode ser comprimida. Restam dúvidas declaradas: como tipos distintos de conteúdo respondem à compressão, se gêneros diferentes exigem estratégias próprias e se o próprio processo pode ficar mais eficiente em tokens.