Resumo Técnico: Treinamento Interativo 2 – Plano de Controle Auditável para Treinamento de Modelos ao Vivo

Declaração do Problema

Embora os rastreadores de experimentos modernos (ex: Aim, Weights & Biases) visualizem efetivamente o progresso do treinamento, eles carecem de um mecanismo geral para executar intervenções em execuções de treinamento ao vivo. Atualmente, modificar um experimento em execução — como ajustar taxas de aprendizado, rebalancear dados ou salvar checkpoints — requer código específico do treinador, callbacks customizados ou lógica manual adaptada a um único framework. Essa fragmentação impede que pesquisadores apliquem facilmente o direcionamento humano ou automatizado através de diferentes fluxos de trabalho de treinamento. Embora os pesquisadores frequentemente tomem decisões baseadas no comportamento ao vivo, as ferramentas para agir sobre essas observações permanecem desarticuladas e não reutilizáveis.

Metodologia

Os autores propõem o Interactive Training 2 (IT2), um plano de controle de código aberto que desacopla a lógica de treinamento da lógica de controle através de um protocolo compartilhado. O sistema opera sobre três princípios fundamentais:

1. A Arquitetura do Plano de Controle

O sistema introduz uma camada entre o código de treinamento e seus controladores (humanos, scripts ou agentes de LLM).

• Declaração: As aplicações de treinamento declaram explicitamente quais configurações (ex: taxa de aprendizado, pesos de origem) e ações (ex: avaliação, checkpointing) estão expostas. Estas são registradas como "knobs" (parâmetros ajustáveis) tipados e ações estruturadas via uma API Python (register_knob).
• Submissão: Os controladores submetem requisições através de uma interface unificada (API HTTP ou WebSocket). Todos os controladores, independentemente do tipo, utilizam o mesmo formato de requisição.
• Execução: O loop de treinamento retém o controle total. Ele processa as requisições em pontos de controle seguros (definidos explicitamente pelo desenvolvedor) em vez de imediatamente após o recebimento. Nesses pontos, o sistema valida as requisições, aplica as mudanças e registra os resultados antes de prosseguir para a próxima etapa de treinamento.

2. O Diário Auditável

Um espaço de trabalho Aim customizado serve como a interface central, combinando métricas ao vivo com um diário cronológico e ordenado. Este diário vincula:

• Decisões do controlador (planos).
• Requisições submetidas e suas fontes.
• Resultados de execução (sucesso/falha).
• Métricas de avaliação e checkpoints.
• Reflexões (no caso de agentes de LLM).

Esta estrutura permite a reconstrução de todo o histórico de treinamento: quem solicitou o quê, quando foi aplicado e o impacto resultante.

3. Mecanismos de Integração

O sistema suporta três métodos para conectar o código de treinamento ao plano de controle:

• Callbacks de Treinador: Para o Trainer da Hugging Face, um callback registra controles do otimizador e mapeia decisões de sessão para flags do treinador.
• Patching de Otimizador: Um wrapper opcional transforma o optimizer.step() em um ponto de controle para loops difíceis de editar.
• Integração Direta: Loops customizados de PyTorch e loops de Aprendizado por Reforço com Recompensas Verificáveis (RLVR) chamam session.step diretamente, permitindo controle total sobre a lógica de diagnósticos e checkpointing.

4. Agente de LLM Opcional

O sistema inclui um agente de LLM opcional que opera em três fases:

• Plano (Plan): Gera uma configuração inicial e uma estratégia baseada em objetivos da tarefa e rodadas anteriores.
• Agir (Act): Emite chamadas de ferramentas (ex: alterar hiperparâmetros) com base nas métricas atuais e ações registradas.
• Refletir (Reflect): Analisa a trajetória completada e escreve lições acionáveis para a próxima rodada.
  Crucialmente, o agente de LLM utiliza o mesmo protocolo que os usuários humanos, e cada nova rodada começa com um modelo e um otimizador novos, passando apenas um resumo textual das configurações e reflexões para a próxima iteração.

Principais Contribuições

O artigo delineia três contribuições primárias:

1. Um Protocolo Compartilhado para Direcionamento: Uma interface reutilizável onde aplicações expõem configurações e ações tipadas, enquanto os loops de treinamento determinam pontos de aplicação seguros. Isso vai além das implementações específicas de treinadores para um padrão geral.
2. Uma Interface Unificada para Observação e Controle: Um espaço de trabalho Aim customizado que integra métricas ao vivo com um diário ordenado, conectando decisões de controladores a resultados de execução e avaliações em uma única visualização.
3. Implementação de Código Aberto: Um sistema demonstrado em cinco fluxos de trabalho diversos (NLP e RL), suportando callbacks, wrappers de otimizadores e loops diretos. O código está disponível para ser usado por humanos, scripts e agentes de forma intercambiável.

Resultados e Validação

O sistema foi validado através de cinco fluxos de trabalho, demonstrando a flexibilidade do protocolo e a capacidade do sistema de produzir registros auditáveis:

• Fluxos de Trabalho Testados:
  • Classificação de sentimento (Hugging Face Trainer).
  • Mistura de sentimentos (Loop direto de PyTorch).
  • Layerwise GPT (Loop direto de PyTorch com 27 taxas de aprendizado distintas).
  • Muon–AdamW GPT (Loop direto de PyTorch com diagnósticos de otimizador).
  • RLVR Countdown (Loop direto de RL com controles de currículo).
• Desempenho: Em todos os casos, o sistema registrou com sucesso o caminho da requisição ao resultado. Por exemplo, na tarefa de mistura de sentimentos, o macro-F1 melhorou de 0,568 para 0,656 ao longo de 11 rodadas. Na tarefa RLVR, a acurácia mais difícil melhorou de 0,032 para 0,232.
• Auditabilidade: O sistema demonstrou com sucesso que rodadas posteriores puderam utilizar visivelmente reflexões de rodadas anteriores. Por exemplo, após uma regressão na Rodada 8 da tarefa de sentimento, a reflexão propôs ajustes específicos de pesos, que foram explicitamente registrados e aplicados nas Rodadas 9 e 10, levando a melhorias na pontuação.
• Rastreabilidade: Os diários JSONL liberados permitem a verificação de cada ação, desde a requisição inicial até o checkpoint final, garantindo que a sequência de decisões seja reconstruível.

Significância e Alegações

O artigo posiciona o Interactive Training 2 como uma mudança da lógica específica de experimento para uma interface reutilizável para intervenção de treinamento ao vivo.

• Modularidade: Ao separar a definição do que pode mudar e quando isso se aplica de quem (controlador), o sistema permite que pesquisadores adicionem direcionamento humano ou automatizado a diferentes fluxos de trabalho sem reconstruir a maquinaria de monitoramento e registro para cada experimento.
• Auditabilidade: O sistema afirma fornecer uma base para o "treinamento guiado por humanos e agentes auditável", permitando o estudo sistemático de como as decisões são tomadas e seus efeitos no progresso do aprendizado.
• Limitações: Os autores observam modestamente que o loop de treinamento aguarda as respostas do LLM (bloqueante), o sistema ainda não lida com respostas de chegada tardia, e as garantias de segurança (ex: prevenir mudanças hiperparamétricas catastróficas) dependem de verificações de nível de aplicação, limites de valores e permissões, em vez de serem inerentes ao próprio protocolo. Casos de alto risco exigem portões de aprovação adicionais e políticas de rollback.

Em resumo, o Interactive Training 2 fornece um plano de controle auditável que torna as execuções de treinamento ao vivo direcionáveis, reutilizáveis e inspecionáveis através de diversos frameworks de aprendizado de máquina.