Compactação de contexto

O gateway enxuga o histórico da conversa antes de a requisição chegar ao provedor, removendo resultados de ferramenta que um classificador rápido julga não serem mais necessários. Nunca resume: o texto do usuário e do assistente sai idêntico byte a byte. Vem desligado.

O que faz, e o que nunca faz

Na saída, antes de a requisição chegar ao provedor, o gateway lê o histórico da conversa e emparelha cada chamada de ferramenta com o seu resultado. Para cada par, um classificador responde a duas perguntas: esta chamada ainda precisa estar aqui, e o resultado inteiro dela ainda precisa estar aqui. O que o classificador marca como não mais necessário é removido. Todo o resto passa intacto.

Cliente (Agente, CLI ou aplicação) -> Gateway (Emparelha chamadas e resultados, consulta o motor, reescreve) -> Provedor (Recebe um histórico menor, com a mesma prosa). A compactação acontece no caminho de saída de uma requisição. Nada é armazenado, nada é reescrito do lado do cliente.

A garantia: Se você comparar a requisição que saiu do gateway com a que entrou, a diferença é sempre uma subtração. Nada do que saiu foi escrito pelo motor de compactação.

  • A prosa nunca é tocada. Mensagens do usuário e do assistente saem idênticas byte a byte, caractere por caractere.
  • Nada é reescrito. Não há resumo, não há paráfrase, não há versão condensada de coisa alguma. A única operação é remoção.
  • A chamada de ferramenta e o resultado dela são julgados como par. Um resultado pode sair com a chamada ficando, mas uma chamada nunca sai sem o resultado sair junto.
  • A decisão é por chamada, não por conversa. Dois resultados da mesma ferramenta na mesma sessão podem receber vereditos diferentes.

Dois motores, um protocolo

Quem decide pode ser um modelo que o cliente roda na própria máquina (o motor local) ou um serviço de decisão hospedado (o motor remoto). Os dois falam o mesmo protocolo de fio, então a única diferença de configuração é o endpoint. Nada mais no bloco muda.

  • O modelo roda na máquina do próprio cliente. Nenhum trecho de conversa sai da rede.
  • O motor local recusa qualquer endpoint que não seja um endereço local. O endereço configurado é resolvido no boot, e se resolver para um endereço público o boot falha. Não existe flag para afrouxar isso.
  • É a configuração recomendada para ambiente regulado e a única disponível em instalação air-gapped.
  • Exige uma flag de consentimento explícita na configuração. Sem ela o gateway se recusa a subir o motor, porque trechos da conversa de fato saem da rede para serem julgados.
  • Anuncia o destino no boot, no log, para ninguém descobrir depois para onde foram os trechos.
  • Registra o consentimento, com data, na trilha de auditoria assinada. O registro sobrevive a uma alteração posterior no arquivo de configuração.

Motor local

Motor remoto

Vem desligado, e falha aberto

A compactação vem desligada na instalação nova. Sem bloco de configuração e sem variável de ambiente que a ligue, o gateway nunca chama motor nenhum e o histórico vai ao provedor exatamente como chegou. Ligar é um ato deliberado.

Uma vez ligada, todo caminho de falha termina no mesmo lugar: vai o histórico ORIGINAL.

A regra: Nenhuma requisição é quebrada para economizar token. A compactação é otimização, então qualquer dúvida se resolve a favor de mandar tudo.

  • Motor fora do ar ou respondendo erro: histórico original.
  • Prazo estourado: histórico original. A requisição não espera motor lento.
  • Redução pequena demais para valer a reescrita: histórico original. A compactação desiste sozinha.
  • Resposta malformada ou que não parseia: histórico original.

A credencial é o nome de uma variável

O campo de credencial do motor guarda o NOME de uma variável de ambiente, nunca um valor colado. O gateway lê a variável na subida. Um arquivo de configuração que carregue o segredo em si é recusado, com mensagem dizendo qual campo, para uma credencial nunca chegar por acidente a um backup, a um repositório ou a um chamado de suporte.

"api_key_env": "ATLASBERG_COMPACTACAO_API_KEY"   ok: o nome da variável
"api_key_env": "sk-live-9f2c..."                 recusado: valor no arquivo

Por que o limiar importa

Esta é a parte que decide se a compactação vale alguma coisa, e ela não é intuitiva. Numa sessão longa de agente, a maior parte dos tokens de entrada não é lida a preço cheio: é leitura de cache, cobrada a 0,1x. O prefixo da conversa fica estável turno após turno, então permanece em cache e custa quase nada para ser enviado de novo.

A compactação reescreve esse prefixo. Prefixo novo é cache miss, e entrar no cache custa 1,25x. Ou seja, toda compactação começa no negativo: paga 1,25x uma vez, sobre um histórico menor, para depois ler a 0,1x enquanto o novo prefixo durar. Só vira lucro se houver turnos suficientes depois dela.

  • Uma compactação sobre histórico curto, ou seguida de mais dois turnos, perde dinheiro mesmo tendo removido tokens.
  • É por isso que ela dispara por limiar: abaixo de certo tamanho de histórico a reescrita não se paga, então nada é tentado.
  • E é por isso que ela desiste sozinha quando a redução não justifica a reescrita, mesmo com o motor já tendo respondido.
  • Compactar mais vezes não é o mesmo que economizar mais. Passado certo ponto, é o contrário.

Modo de medição

Antes de ligar a compactação, o gateway consegue medir o que a compactação ECONOMIZARIA no tráfego do próprio cliente sem compactar nada. Ele roda o motor ao lado das requisições reais, registra o que teria removido e quanto aquilo valeria, e envia toda requisição intacta. Nenhum comportamento muda enquanto ele mede.

Comece por aqui. Perfil de tráfego varia enormemente: uma carga de conversas curtas com poucas chamadas de ferramenta não tem quase nada a remover, e uma semana de medição custa alguns centavos para descobrir isso. Os números abaixo saíram exatamente desse modo.

A variavel funciona com a feature ainda desligada. O que ela produz sao contagens, nunca texto: quantas chamadas teriam virado pergunta, quantos tokens teriam saido do historico e quanto aquilo valeria. Nenhum conteudo de prompt chega a metrica nem a trilha.

ATLASBERG_COMPACTACAO_MEDIR=1

Resultados medidos, com as premissas declaradas

Sobre 30 sessões reais de agente, 6.892 turnos e 250 consultas reais ao motor:

Os dois números do fim andam juntos. 40,6% das remoções apagaram material que a conversa voltou a citar depois, o que soa alarmante até se olhar o que foi removido: 97,6% de tudo que saiu veio de ferramenta determinística, um arquivo que continua no disco, um comando que roda de novo com a mesma saída. O material é recuperável repetindo a chamada. Por isso o custo máximo de um erro do classificador é uma chamada de ferramenta repetida, e por isso o pior caso acima é US$ 4,32 e não uma sessão quebrada.

Dois limites, ditos com todas as letras: O modelo de custo cobre só o lado de entrada da conversa. E a qualidade de conclusão de tarefa com e sem compactação NÃO foi medida: nada aqui afirma que o agente terminou o mesmo trabalho igualmente bem.

  • Medida: Economia | Resultado: 17,01% (US$ 101,58 de um custo de entrada modelado em US$ 597,22)
  • Medida: Custo do motor | Resultado: US$ 0,26
  • Medida: Perda no pior caso | Resultado: US$ 4,32, se tudo que foi removido tivesse de ser buscado de novo
  • Medida: Saldo | Resultado: US$ 97,00, uma razão de 22x
  • Medida: Latência | Resultado: 330 ms, pagos por 1,20% das requisições
  • Medida: Remoções citadas depois de novo | Resultado: 40,6%
  • Medida: Remoções vindas de ferramenta determinística | Resultado: 97,6%

O que a compactação não alcança

A compactação só endereça parte da conta, e vale saber qual parte antes de esperar um número dela.

  • O prefixo fixo. A mediana é de 162.811 tokens por turno de prompt de sistema, definições de ferramenta e memória, que chegam antes de a conversa começar. A compactação não toca nisso, e limiar nenhum muda esse fato.
  • As entradas das chamadas de ferramenta. São 46,9% do histórico, contra 44,0% dos resultados. Uma entrada fica enquanto a chamada dela ficar, então a maior metade do histórico está em boa parte fora de alcance.
  • O que sobra é a parte sobre a qual a compactação trabalha, e 17,01% do custo de entrada foi o que saiu dela neste tráfego.

Configuração

Ordem recomendada: medir primeiro no tráfego da casa, ler a redução contra o prefixo fixo que não dá para tocar, e só então colocar enabled em verdadeiro, começando pelo motor local.

  • Campo: enabled | O que muda ao mexer: A chave geral. Falso na instalação nova; com falso, nenhum motor é chamado.
  • Campo: engine | O que muda ao mexer: Escolhe quem decide: o motor local ou o motor remoto.
  • Campo: endpoint | O que muda ao mexer: Endereço do motor de decisão. O motor local recusa o que não for endereço local e falha o boot se resolver para um endereço público.
  • Campo: model | O que muda ao mexer: Qual modelo de decisão o endpoint deve carregar. Modelo mais pesado decide melhor, custa mais e soma latência.
  • Campo: api_key_env | O que muda ao mexer: O NOME da variável de ambiente com a credencial. Valor colado aqui é recusado.
  • Campo: limiar_tokens | O que muda ao mexer: Tamanho de histórico a partir do qual a compactação é tentada. Subir torna a compactação mais rara e cada uma mais propensa a se pagar.
  • Campo: piso_bytes | O que muda ao mexer: Tamanho mínimo de resultado para sequer entrar na análise. Subir impede o motor de gastar decisão com resultado pequeno demais para importar.
  • Campo: preservar_recentes | O que muda ao mexer: Quantos turnos recentes nunca são tocados. Subir protege mais da cauda e reduz a economia.
  • Campo: limiar_decisao | O que muda ao mexer: Confiança que o classificador precisa ter para remover. Subir o deixa mais conservador e remove menos.
  • Campo: truncar_cabeca_chars | O que muda ao mexer: Quantos caracteres da cabeça de cada resultado vão ao classificador. Subir dá base melhor para a decisão e aumenta a conta do motor e a latência.
  • Campo: timeout_ms | O que muda ao mexer: Prazo para a resposta do motor. Estourou, vai o histórico original.
  • Campo: min_reducao | O que muda ao mexer: Redução mínima aceita para a reescrita acontecer. Abaixo dela, vai o histórico original.
  • Campo: consentimento_exportar_prompt | O que muda ao mexer: Consentimento explícito para enviar trechos da conversa ao motor remoto. Sem ele, o motor remoto não sobe. Fica registrado, com data, na trilha de auditoria.
"compactacao": {
  "enabled": true,
  "engine": "local",
  "endpoint": "http://127.0.0.1:8080",
  "model": "<modelo de decisão>",
  "api_key_env": "ATLASBERG_COMPACTACAO_API_KEY",
  "limiar_tokens": 40000,
  "piso_bytes": 2048,
  "preservar_recentes": 6,
  "limiar_decisao": 0.7,
  "truncar_cabeca_chars": 800,
  "timeout_ms": 1500,
  "min_reducao": 0.1,
  "consentimento_exportar_prompt": false
}

Sobre a Atlasberg Platform

A Atlasberg Platform é a camada de controle entre uma empresa e todos os modelos de IA: cada requisição é autenticada com uma chave virtual, filtrada por política e DLP, roteada para o provedor certo e gravada numa trilha de auditoria encadeada por hash. Expõe uma API compatível com a OpenAI, então as aplicações só trocam a URL base.

O mesmo artefato roda na Atlasberg Cloud, na sua VPC, on-premises ou totalmente air-gapped, e é cobrado por capacidade e módulos, nunca por assento.

Esta página faz parte da documentação oficial. Para falar com o time de engenharia, escreva para [email protected] ou use https://atlasberg.com/pt-br/contato. A resposta vem em até um dia útil.

Agentes: esta página também está disponível em Markdown em /pt-br/docs/console/compactacao-de-contexto.md, ou pedindo esta URL com o cabeçalho Accept: text/markdown. Índice de tudo: /llms.txt.