Ensinando o treinador: evoluir a recompensa em vez de ajustá-la à mão
Uma execução chegou a 1780 px e ainda perdeu para um campeão mais cauteloso com 1828 fitness. A penalidade de morte de -100 castigou tanto o comportamento que avançava mais que ele foi descartado duas vezes. Reduzi a penalidade de 100 para 25 à mão — e revelei um treinador que dependia de eu reabrir a função de fitness sempre que o aprendizado dava errado.
O registro de construção anterior definiu as recompensas de Skyline Run antes da primeira execução de treinamento. O sistema em funcionamento mostrou por que essa correção não poderia ser a última. A próxima construção coloca o ajuste dentro do experimento: o AI Trainer AI evolui pequenas redes que definem as recompensas do laboratório de IA de Skyline Run interno.
Isso não significa que podemos entregar o design de recompensas a uma máquina e esquecê-lo. É uma comparação controlada entre cronogramas de recompensa aprendidos e o cronograma ajustado à mão que eles devem substituir.
Eu sou o proprietário e desenvolvo este site e o canal AI Maker Lab — este é um registro de construção, não uma análise independente.
Quando o ajuste manual virou o problema
Os coeficientes de recompensa pareciam constantes comuns: 250 por checkpoint, 1500 por uma conclusão, 0.5 por tick não utilizado e uma penalidade por morte. Juntos, decidiam qual comportamento sobreviveria à reprodução. Alterar um deles não ajustava apenas um gráfico; mudava a definição de uma boa execução para o treinador.
A edição manual resolveu um sintoma e revelou o problema maior. Até então, toda correção consistia em uma pessoa alterar uma constante depois de observar uma falha no treinamento, e cada edição invalidava as linhas de base anteriores. Se a recompensa precisa de ajustes repetidos, seu design pertence ao sistema de aprendizado, não a uma configuração externa.
A pesquisa aponta para recompensas que aprendem
A recompensa com a qual um agente aprende não precisa ser aquilo que seu designer valoriza no fim. “Where Do Rewards Come From?”, de Singh, Lewis e Barto, separa a recompensa primária do agente do fitness sobre a distribuição de ambientes do designer. Nesse enquadramento, a recompensa de aprendizado é uma variável de design, escolhida porque a política que ela produz maximiza um objetivo separado do designer. As duas funções nem precisam ter a mesma forma.
AutoRL transforma esse enquadramento em uma busca evolutiva externa. “Evolving Rewards to Automate Reinforcement Learning”, de Faust, Francis e Mehta, trata o ajuste de recompensas como otimização de hiperparâmetros: uma população de agentes de RL internos treina com recompensas candidatas, enquanto a camada externa seleciona a recompensa que maximiza o objetivo da tarefa. Essa separação é o precedente direto para pontuar nossos controladores por progresso e conclusão, e não pelo fitness moldado que eles mesmos criaram.
Population Based Training indica que a resposta útil pode ser um cronograma, não uma constante. “Population Based Training of Neural Networks”, de Jaderberg et al., adapta modelos e hiperparâmetros em conjunto durante o treinamento. A etapa de exploração do que já funciona copia um membro melhor da população; a etapa de busca perturba ou reamostra hiperparâmetros. O resultado é um cronograma de hiperparâmetros que muda ao longo do aprendizado, em vez de uma configuração fixa escolhida de antemão. PBT não é especificamente um método de busca de recompensas, mas sustenta a ideia de permitir que seus coeficientes mudem junto com o treinador interno.
Recompensas de shaping e parâmetros de aprendizado podem evoluir em conjunto. “Co-evolution of Shaping Rewards and Meta-Parameters in Reinforcement Learning”, de Elfwing, Uchibe, Doya e Christensen, evolui recompensas de shaping baseadas em potencial junto com a taxa de aprendizado α, o fator de desconto γ e a temperatura de softmax τ, em experimentos com mountain car e transferência da simulação para hardware robótico de forrageamento. O resumo verificado estabelece essa otimização conjunta. Ele não estabelece se a seleção externa usou uma métrica de verdade fundamental definida separadamente, por isso não o uso como evidência para essa parte do nosso design.
A busca pode operar sobre programas de recompensa, não apenas coeficientes. “Genetic Programming for Reward Function Search”, de Niekum, Barto e Spector, aplica programação genética a funções de recompensa alternativas para melhorar o desempenho do aprendizado. O registro DOI verificado estabelece a busca por funções de recompensa, mas não expõe texto metodológico suficiente para determinar se o fitness da programação genética era um objetivo de tarefa separado ou derivado do retorno moldado. É um precedente para o espaço de busca, não uma evidência para nossa regra de pontuação externa.
Eureka é a versão da era dos LLMs para a busca de recompensas. “Eureka: Human-Level Reward Design via Coding Large Language Models”, de Ma et al., usa um LLM de programação para gerar código de recompensa e aprimoramento evolutivo para refiná-lo. Seu problema formal busca uma recompensa R cuja política aprendida maximize uma função de fitness separada F(π), usando a recompensa de verdade fundamental ou esparsa da tarefa para a avaliação. O gerador mudou; a separação bilevel permaneceu.
O shaping de recompensa tem uma condição de segurança. “Policy Invariance Under Reward Transformations”, de Ng, Harada e Russell, mostra que, além de transformações lineares positivas, o shaping na forma de diferença de potencial F(s, s') = γΦ(s') - Φ(s) preserva políticas ótimas no cenário geral relevante. Uma busca de recompensas sem restrições pode mudar qual política é ótima, em vez de apenas facilitar o aprendizado da tarefa original. Nossos limites de multiplicador [0.25×, 4×] são uma proteção pragmática contra coeficientes extremos. Não são uma prova de invariância de política.
Um controlador altera quatro recompensas
O design usa evolução em dois níveis (bilevel evolution): um ciclo externo evolui a recompensa, enquanto um ciclo interno treina contra ela. A população externa é NEAT, mas cada genoma não é um jogador de Skyline Run. É um controlador com 12 entradas e 4 saídas que observa uma execução interna de treinamento NEAT e emite multiplicadores para o bônus de checkpoint, o bônus de conclusão, o bônus de tempo e a penalidade de morte. A topologia inicial é densa e plana: cada entrada se conecta a cada saída.
As doze observações são deliberadamente pequenas e limitadas. Na geração interna 0, as entradas 1–7 são forçadas a zero porque ainda não existem estatísticas de geração. As entradas 8–11 também começam em zero porque cada multiplicador atual começa em 1.
| Entrada | Telemetria | Codificação | Intervalo |
|---|---|---|---|
0 | Progresso no orçamento interno | gen / innerGenerations | [0, 1] |
1 | Melhor progresso entre as gerações concluídas | bestPx / levelWidthPx | [0, 1] |
2 | Progresso obtido desde a chamada anterior do controlador | (bestPx - pxAtLastCall) / 200 | [0, 1] |
3 | Gerações desde a melhora do melhor progresso | gensSinceBestImproved / 20 | [0, 1] |
4 | Razão entre o fitness moldado médio e o melhor | mean / max(1, best) | [-1, 1] |
5 | Taxa média de mortes | meanDeaths / MAX_DEATHS | [0, 1] |
6 | Taxa de conclusão | completions / innerPopulationSize | [0, 1] |
7 | Carga de especiação | species / (2 * innerTargetSpecies) | [0, 1] |
8 | Multiplicador atual do bônus de checkpoint | log2(multiplier) / 2 | [-1, 1] |
9 | Multiplicador atual do bônus de conclusão | log2(multiplier) / 2 | [-1, 1] |
10 | Multiplicador atual do bônus de tempo | log2(multiplier) / 2 | [-1, 1] |
11 | Multiplicador atual da penalidade de morte | log2(multiplier) / 2 | [-1, 1] |
Cada saída se torna 2 ** (2 * tanh(output)). Isso mapeia qualquer saída finita da rede para um multiplicador entre 0.25× e 4×. Uma saída zero produz exatamente 1×; portanto, quatro saídas zero reproduzem os coeficientes ajustados à mão sem nenhum caso especial.
O controlador emite recompensas antes da geração interna 0 e volta a emiti-las a cada 5 gerações internas concluídas. NeatTrainer.setRewards aplica os novos valores na próxima fronteira de geração, pois o fitness moldado só é calculado quando essa geração termina. Ele nunca reavaliou uma população em andamento com regras alteradas no meio da execução.
O controlador é avaliado pelos agentes que produz
A seleção externa nunca usa o fitness moldado como sua pontuação. O meta-fitness de um candidato — a qualidade de uma função de recompensa, pontuada pelos agentes que ela produz — é:
média ponderada para o fim, sobre as gerações internas avaliadas, de runningMax(bestMaxPx),
em que a geração g tem peso g
+ 2000 se alguma geração interna produziu uma conclusão
+ 500 * (conclusões da geração final / innerPopulationSize) O primeiro termo recompensa o progresso que persiste até o fim da execução: gerações finais têm peso linearmente maior, e cada candidato é avaliado 25% além do horizonte nominal, para que o controlador treine no regime saturado pós-horizonte em que será implantado. (O teste rápido abaixo é anterior a essa revisão e foi pontuado com média simples sobre o horizonte nominal.) Os outros termos tornam a conclusão o evento de verdade fundamental. A linha de base ajustada à mão e sem alterações é executada primeiro, como candidata 0 de cada meta-geração, de modo que sua pontuação seja conhecida antes da avaliação de qualquer controlador. Ela e todos os controladores da mesma meta-geração recebem a mesma seed interna derivada por hash. Isso é o uso de números aleatórios comuns (common random numbers): as mesmas seeds são reutilizadas entre os candidatos para que a comparação não dependa da sorte. A primeira execução fornece baselineFitness como controle contemporâneo, em vez de depender de uma linha de base medida com outra fase ou seed.
A seed mudou qual campeão merecia sobreviver
A seed interna ainda muda entre meta-gerações segundo innerSeed = hashSeed(seed, metaGen, 0x1177), portanto o fitness bruto de meta-gerações diferentes não é comparável. O campeão de toda a execução é, por isso, o controlador com a maior vantagem best - baselineFitness, e a estagnação das espécies usa a mesma escala. Esta execução mostrou por quê: uma seleção pelo fitness bruto teria mantido o controlador da meta-geração 1, com valor bruto 1274.04 e vantagem de apenas +25.90, em vez do controlador da meta-geração 2, com valor bruto 1043.85 e vantagem de +91.60, somente porque a meta-geração 1 recebeu uma seed interna mais fácil.
O teste rápido encontrou uma pista, não um veredito
Executei um teste rápido deliberadamente pequeno em createDistrict01(), no nível expert, com seed 7, meta-população 6, 10 gerações internas por candidato, cadência do controlador 5 e população interna 150. Seu candidateCount foi 7: uma linha de base ajustada à mão, seguida por seis controladores. Estas são medições de um teste rápido, não uma evidência de que o treinador aprendido generaliza.
| Meta-geração | Melhor | Média | Linha de base ajustada à mão | Vantagem |
|---|---|---|---|---|
0 | 877.43 | 850.42 | 845.02 | +32.41 |
1 | 1274.04 | 1242.25 | 1248.14 | +25.90 |
2 | 1043.85 | 978.66 | 952.26 | +91.60 |
A execução levou 16.92 s para 21 treinamentos internos e 231781 ticks no total. O campeão de toda a execução veio da meta-geração 2, com bestMetaFitness 1043.85, championBaselineFitness 952.26 e a maior vantagem dentro da própria geração. Avaliado na geração interna 0 com telemetria zerada, ele emitiu [1.05, 0.68, 0.94, 0.81], produzindo bônus de checkpoint 261.64, bônus de conclusão 1016.50, bônus de tempo por tick 0.47 e penalidade de morte 20.34.
O rastreamento também revelou uma condição inicial segura na topologia. Na geração interna 0, o vetor de telemetria inteiro é zero, portanto os multiplicadores emitidos dependem apenas dos vieses de saída. Todos os vieses da população inicial são zero. Assim, cada controlador da meta-geração 0 começa exatamente em [1, 1, 1, 1] e só pode divergir na primeira chamada de cadência 5. Multiplicadores diferentes da unidade na geração 0 aparecem apenas depois de uma mutação dos vieses; os coeficientes ajustados à mão são o ponto de partida por construção, não por sorte.
O melhor controlador superou seu próprio controle ajustado à mão da mesma geração nas três meta-gerações. A média da população ficou abaixo da linha de base somente na meta-geração 1. Nenhuma geração interna produziu uma conclusão dentro do orçamento de 10 gerações. Todos os campeões permaneceram topologicamente densos e planos, com 0 nós ocultos e 48 conexões. Uma segunda execução idêntica produziu sequências de MetaGenStats idênticas byte a byte; somente os campos de tempo real diferiram.
Três meta-gerações são muito pouco para sustentar uma conclusão. O novo campeão manteve o bônus de checkpoint praticamente inalterado em 1.05×, reduziu mais fortemente o bônus de conclusão para 0.68× e suavizou a penalidade de morte para 0.81×. Essa direção é uma hipótese sobre o que ajudou nessa seed, não um resultado sobre um bom design de recompensas.
Este teste rápido decidiu o protocolo de avaliação, não se a recompensa aprendida funciona. Ele mostrou repetibilidade determinística e encontrou um controlador que superou seu controle ajustado à mão em três meta-gerações curtas, mas nenhuma geração interna concluiu o nível. A próxima etapa definida é uma execução completa na página AI Trainer AI com seeds internas repetidas e ainda não vistas.
O design só contará como evidência se produzir conclusões, continuar superando o controle correspondente e mantiver essa vantagem em meta-gerações posteriores. Perder em seeds não vistas, vencer apenas em progresso ou perder a vantagem numa busca mais longa refutaria o resultado. O controlador exportado, a configuração, o conjunto de seeds, a linha de base de cada geração e o registro de conclusões teriam de permanecer disponíveis para que a comparação pudesse ser repetida.
O próximo registro, Um genoma deve guardar o que sua rede aprendeu? Três formas de combinar gradientes e evolução, investiga o que deve acontecer com o aprendizado depois que cada genoma é avaliado.
Fontes
- Singh, Satinder; Lewis, Richard L.; Barto, Andrew G. “Where Do Rewards Come From?” Proceedings of the 31st Annual Conference of the Cognitive Science Society, 2009. https://all.cs.umass.edu/pubs/2009/singh_l_b_09.pdf. Acessado em 2026-08-21.
- Faust, Aleksandra; Francis, Anthony; Mehta, Dar. “Evolving Rewards to Automate Reinforcement Learning.” arXiv:1905.07628, 18 de maio de 2019. https://arxiv.org/abs/1905.07628. Acessado em 2026-08-21.
- Jaderberg, Max; Dalibard, Valentin; Osindero, Simon; Czarnecki, Wojciech M.; Donahue, Jeff; Razavi, Ali; Vinyals, Oriol; Green, Tim; Dunning, Iain; Simonyan, Karen; Fernando, Chrisantha; Kavukcuoglu, Koray. “Population Based Training of Neural Networks.” arXiv:1711.09846, 27 de novembro de 2017. https://arxiv.org/abs/1711.09846. Acessado em 2026-08-21.
- Elfwing, Stefan; Uchibe, Eiji; Doya, Kenji; Christensen, Henrik I. “Co-evolution of Shaping Rewards and Meta-Parameters in Reinforcement Learning.” Adaptive Behavior, dezembro de 2008. DOI:10.1177/1059712308092835. https://doi.org/10.1177/1059712308092835. Acessado em 2026-08-21.
- Niekum, Scott; Barto, Andrew G.; Spector, Lee. “Genetic Programming for Reward Function Search.” IEEE Transactions on Autonomous Mental Development 2(2):83–90, junho de 2010. DOI:10.1109/TAMD.2010.2051436. https://doi.org/10.1109/TAMD.2010.2051436. Acessado em 2026-08-21.
- Ma, Yecheng Jason; Liang, William; Wang, Guanzhi; Huang, De-An; Bastani, Osbert; Jayaraman, Dinesh; Zhu, Yuke; Fan, Linxi; Anandkumar, Anima. “Eureka: Human-Level Reward Design via Coding Large Language Models.” arXiv:2310.12931, 19 de outubro de 2023. https://arxiv.org/abs/2310.12931. Acessado em 2026-08-21.
- Ng, Andrew Y.; Harada, Daishi; Russell, Stuart. “Policy Invariance Under Reward Transformations: Theory and Application to Reward Shaping.” Proceedings of the Sixteenth International Conference on Machine Learning, 1999. http://robotics.stanford.edu/~ang/papers/shaping-icml99.ps. Acessado em 2026-08-21.
Eu sou o proprietário e desenvolvo este site e o canal AI Maker Lab — este é um registro de construção, não uma análise independente.