Agentic RL: Como evitar o drift na precisão dos tokens em LLMs

O 'retokenization drift' não é um bug de implementação, mas um efeito colateral inevitável quando LLMs são forçados a operar como agentes ativos em loops de RL: o modelo gera uma string, essa string é decodificada para texto e, depois, re-convertida em tokens, mas a tokenização não é reversível. Palavras como 'HAVING' ou 'reinforcement' podem ser divididas de forma distinta na segunda passagem, gerando IDs diferentes dos originais amostrados. Isso faz com que o gradiente seja calculado sobre uma sequência que o modelo nunca realmente produziu, desestabilizando o treinamento e empurrando a política para fora da distribuição on-policy. A solução técnica, agora consolidada no vLLM (desde outubro de 2025) e adotada por frameworks como TRL e Hugging Face Transformers, é radicalmente simples: descartar a string intermediária. Em vez disso, manter um buffer imutável com os IDs exatos dos tokens amostrados, entrada e saída, e construir toda a perda diretamente sobre eles. É o que o blog da Hugging Face chamou de 'token-in, token-out done right'.

Essa exigência ganha urgência justamente porque sistemas agênticos estão deixando de ser experimentos acadêmicos. Com LLMs locais rodando via Ollama ou LM Studio (como destacado em 6 de junho), cada ciclo de ação, observação e planejamento passa por múltiplas chamadas de inferência, e cada retokenização errada se acumula. Mais do que estabilidade numérica, isso afeta a confiabilidade do agente: um drift silencioso pode levar a decisões coerentes em curto prazo, mas inconsistentes em longo prazo, especialmente em tarefas que exigem memória cruzada entre turnos, como pesquisa web com ferramentas ou RAG com estado persistente.

A cobertura anterior de 28 de maio sobre 'Delta Weight Sync' já apontava para uma tendência clara: otimizações de baixo nível em RL com LLMs estão migrando do nível de parâmetros para o nível de tokens. Antes, o foco era reduzir o tráfego de pesos sincronizados; agora, o foco é preservar a integridade dos tokens amostrados, o verdadeiro 'átomo' da ação agêntica. Enquanto o artigo de 26 de maio sobre destilação on-policy ainda assumia supervisão densa baseada em strings, a notícia atual mostra que frameworks maduros já exigem interfaces puramente tokenizadas. Isso não é mais um 'bom costume': é pré-requisito para qualquer implementação de RLFT em agentes que usem feedback denso em nível de token, como no KL-regularized training com modelos professor.

Evitar o drift de tokens não é só sobre evitar erros de treinamento, é sobre viabilizar agentes que aprendem com precisão temporal. Quando um agente decide usar uma ferramenta, espera que o resultado dessa ação seja incorporado corretamente ao próximo passo de raciocínio. Se o token 'search_results' for retokenizado como dois tokens distintos no cálculo da perda, o modelo começa a associar a ação 'buscar' com uma representação incorreta, e isso se propaga em cadeia. Em produção, isso se traduz em falhas sutis: respostas que parecem boas, mas que repetem erros lógicos em diferentes sessões, ou que falham ao interpretar resultados de APIs estruturadas. Para quem desenvolve fluxos agênticos locais (como em 6 de junho), essa é a diferença entre um protótipo funcional e um sistema escalável, onde cada milímetro de instabilidade no loop de RL se converte em latência, custo e perda de confiança.