A expansão dos limites do objeto evolutivo: dos parâmetros ao programa

Objeto evolutivorefere-se àquilo que, num sistema evolutivo, é de facto codificado, mutado, avaliado e selecionado. Os algoritmos evolutivos clássicos assumem, por defeito, que esse objeto é apenas um conjunto de parâmetros numéricos; contudo, na base moderna constituída por GPUs e grandes modelos, esta fronteira está a alargar-se: dos parâmetros numéricos, aos hiperparâmetros e à arquitetura do modelo, depois aos mecanismos algorítmicos e aos operadores, e, finalmente, ao programa e ao estado de engenharia de software persistente.

A chave para compreender esta escada é ter em conta três aspetos em simultâneo: como o objetoé representado, a querestrições está sujeitoe com quesinais é avaliado. Sempre que o objeto sobe um nível, estes três aspetos mudam em conjunto.

1. Nível dos parâmetros numéricos: o objeto é um vetor real contínuo θ \in \mathbb{R}^d, como a taxa de aprendizagem, os pesos ou o fator de mutação da evolução diferencial. As restrições são sobretudo intervalos de valores, e a avaliação é habitualmente um objetivo escalar f(θ).
2. Nível dos hiperparâmetros e da arquitetura do modelo: o objeto inclui escolhas discretas, como o número de camadas, a largura, o tipo de ligações e as estratégias de aumento de dados. O espaço de busca torna-se híbrido e expande-se rapidamente por combinação, pelo que a avaliação tem de prestar especial atenção à capacidade de generalização e ao sobreajuste.
3. Nível dos mecanismos algorítmicos e dos operadores: o objeto é o próprio mecanismo a executar, como a estratégia de mutação da evolução diferencial, a forma de combinar os coeficientes de inércia no enxame de partículas ou a forma concreta da função de perda. Os candidatos têm de satisfazer restrições sintáticas e semânticas, e a avaliação passa de «quem tem a pontuação mais alta» para a robustez, a estabilidade e o compromisso multiobjetivo.
4. Nível do programa e do estado de engenharia: o objeto passa a ser o script de treino, a configuração do pipeline, as dependências e o estado do projeto. Um candidato só é considerado válido se passar na compilação, nos testes e na validação, e a avaliação sobe ao nível de feedback sistémico: quanto melhora a precisão, se o custo de recursos é aceitável e se os resultados são reprodutíveis.

Porque é que a fronteira se expande para fora

Duas forças impulsionam este movimento. Em primeiro lugar, a escala de capacidade computacional abriu a possibilidade de exploração paralela: os ciclos sequenciais outrora escritos em torno de um único candidato foram substituídos pela tensorização e pelo paralelismo em lote, permitindo gerar e avaliar toda a população de uma só vez. Em segundo lugar, os grandes modelos conseguem compreender linguagem natural, código e contexto de domínio, permitindo ao sistema construir candidatos de estrutura complexa — formas de codificação e mutação que antes tinham de ser concebidas manualmente podem agora contar com a participação do modelo na sua geração.

Quando o próprio «método que gera candidatos» também pode ser expresso e avaliado, surge naturalmente uma questão: se as soluções candidatas podem ser evoluídas, poderá o método que as gera tornar-se também um objeto evolutivo? É precisamente este o degrau que conduz da «otimização de soluções» à «otimização do próprio algoritmo».

Os sinais de avaliação têm de ser atualizados juntamente com o objeto

No nível dos parâmetros, um único objetivo escalar é suficiente para orientar a busca, por exemplo \min f(θ). No nível do programa, nenhum escalar consegue resumir «se este código merece ser mantido»: a avaliação transforma-se num compromisso multiobjetivo com restrições, exigindo ter em conta simultaneamente a precisão f₁, o custo de avaliação f₂ e a estabilidade f₃, e, sob a restrição C(x) ≤ 0 , encontrar um conjunto de candidatos mutuamente não dominados. A lista de verificação habitualmente usada em engenharia inclui: se a compilação passa, se os testes têm cobertura, se o benchmark melhora, se o custo de recursos é aceitável e se os resultados são reprodutíveis.

Equívoco comum: expandir não é gerar aleatoriamente

Empurrar a fronteira do objeto para fora não significa que se possa gerar código à vontade. Quanto mais livre é o objeto, mais as restrições não desaparecem — apenas passam dos «intervalos de valores» para a «sintaxe, interfaces e executabilidade»; e a responsabilidade de validação também não diminui, antes aumenta. As equipas que abrem a evolução ao nível dos scripts deparam-se habitualmente com dois problemas concretos: a expansão abrupta do espaço de busca e uma grande quantidade de candidatos «que correm mas não trazem ganhos» a consumir o orçamento de avaliação.

Por isso, a abordagem mais segura é abrir por níveis: alargar progressivamente o âmbito das alterações permitidas, usar primeiro uma triagem de baixo custo ou modelos substitutos para excluir candidatos manifestamente inválidos, reservar a avaliação de alta fidelidade para as poucas soluções promissoras e assumir explicitamente o compromisso entre precisão e custo.