Resumo Técnico: ARES-LSHADE

Declaração do Problema

O artigo aborda o desafio da competição GECCO 2026: projetar um algoritmo de otimização com envolvimento explícito de um Modelo de Linguagem de Grande Escala (LLM) no processo de design, avaliado no Gerador de Benchmarks Numéricos Generalizados (GNBG). O conjunto GNBG consiste em 24 problemas de minimização contínua construídos como o mínimo de vários componentes quadráticos rotacionados e transformados. As principais restrições incluem:

• Tratamento de Caixa Preta: O algoritmo deve depender exclusivamente de avaliações de função; não pode acessar os parâmetros internos que definem a estrutura da função (por exemplo, posições de mínimos dos componentes).
• Envolvimento do LLM: Um LLM deve ser utilizado durante a fase de design do algoritmo.
• Avaliação: Os algoritmos são testados em 31 execuções independentes por função com orçamentos específicos de avaliação de função (500.000 para as funções f1–f15; 1.000.000 para f16–f24). Uma "vitória" é definida como alcançar uma lacuna absoluta abaixo de $10^{-8}$ em relação ao ótimo verdadeiro.

Metodologia

ARES-LSHADE (Autoresearch-Enhanced LSHADE) é uma variante memética de evolução diferencial que se baseia no vencedor de 2025, LLM-LSHADE. A arquitetura consiste em três componentes principais:

1. Framework Herdado

O algoritmo mantém o framework central LSHADE, incluindo:

• Inicialização e Cruzamento: Estratégias adaptativas (uniforme, espiral prima, Sobol-plus-cluster) e um operador de cruzamento adaptativo de parênteses projetado pelo LLM-LSHADE em 2025.
• Dinâmica da População: Redução linear do tamanho da população (LPSR) de ~180 para 4.

2. Loop de Pesquisa Autônoma (Operador de Mutação)

Um componente novo é o operador de mutação, gerado por um loop de pesquisa autônomo dirigido por LLM.

• Arquitetura: O loop executou aproximadamente 30 experimentos de design ao longo de várias semanas. Em cada iteração, o LLM (Claude) recebeu a fonte do operador atual, um CSV de resultados de benchmark e um log de experimentos. Ele propôs um novo operador de mutação em Python, que foi validado e testado.
• Restrições: A superfície de edição do loop foi restrita apenas ao operador de mutação. O espaço de observação incluiu traços de aptidão, descritores de paisagem ($\lambda, \omega$, rotação) e o log de experimentos, mas excluiu explicitamente os metadados Component_MinimumPosition encontrados nos arquivos de problemas do GNBG.
• Resultado: O loop convergiu para um platô estável de 16–17 vitórias em 24. O operador final submetido combina current-to-pbest/1 com um arquivo, uma subpopulação de "batedor" de 20% para diversidade e um ramo CMA-ES de 10% para funções de componente único rotacionadas.

3. Fase de Polimento Memético

Uma fase de busca local multi-início é executada nos últimos 5% do orçamento de avaliação de função.

• Mecanismo: Executa otimizações locais L-BFGS-B a partir de oito pontos de partida derivados estritamente das descobertas do Algoritmo Evolutivo (EA) e dos limites públicos de busca:
  1. O melhor ponto encontrado pelo EA.
  2. Quatro perturbações do melhor ponto (em 2%, 5%, 10% e 20% da largura do domínio de busca).
  3. Três reinícios aleatórios uniformes.
• Conformidade com Caixa Preta: Crucialmente, a versão submetida não sementeia a busca local usando os metadados Component_MinimumPosition. Os autores observam que uma variante anterior que usava esses metadados alcançou 24/24 vitórias, mas foi descartada por violar a regra de caixa preta, efetivamente "lendo" a solução do arquivo do problema em vez de descobri-la através da avaliação.

Resultados Principais

Na avaliação oficial de 31 execuções por função:

• Vitórias Totais: 510 de 744 vitórias possíveis.
• Precisão de Máquina: 15 das 24 funções foram resolvidas com precisão de máquina (lacuna < $10^{-8}$) em todas as 31 execuções.
• Análise de Falhas: Seis funções (f6, f13, f14, f15, f21, f24) falharam consistentemente em atingir o limiar. Essas falhas não foram aleatórias, mas exibiram assinaturas distintas:
  • Quase Falha Determinística (f21): Uma lacuna constante de 5,0 com variância zero, indicando que o algoritmo convergiu para um mínimo local específico.
  • Quase Falha Apertada (f6, f15): Lacunas de baixa variância (0,36 e 5,4), sugerindo que o algoritmo encontrou uma bacia, mas não a global.
  • Busca de Bacia de Alta Variância (f13, f14, f24): Grandes lacunas com alta variância, indicando que a busca caiu em diferentes bacias enganosas entre as execuções.
• Correlação: As seis funções falhantes foram identificadas independentemente como as "mais difíceis" pelo loop de autoresearch durante sua fase de design, sugerindo que o loop diagnosticou corretamente os limites de dificuldade da arquitetura.

Significado e Alegações Metodológicas

O artigo posiciona sua contribuição não meramente como um algoritmo de alto desempenho, mas como um estudo metodológico sobre o design de algoritmos dirigido por LLM:

1. Diagnóstico de Platô: Os autores argumentam que as seis funções falhantes representam um platô característico para algoritmos meméticos baseados em população sem priores estruturais no benchmark GNBG. As falhas são diagnosticamente informativas, revelando estruturas composicionais específicas (por exemplo, platôs, pequenas bacias globais) que são difíceis de superar sob restrições estritas de caixa preta.
2. Superfície de Edição e Espaço de Observação: O trabalho destaca que o "gargalo" no design dirigido por LLM é frequentemente a escolha da superfície de edição (o que o LLM pode alterar) e do espaço de observação (o que o LLM pode ver). A incapacidade do loop de romper o platô de 16–17 vitórias é atribuída à sua restrição a edições apenas de operadores e à falta de dados agregados de falha entre funções em seu prompt.
3. Integridade vs. Capacidade: O artigo documenta uma tensão crítica entre as capacidades do LLM e a integridade do benchmark. Os autores demonstram que, quando um LLM recebe acesso a metadados do benchmark (como posições de componentes), pode resolver trivialmente o problema, produzindo pontuações que refletem a estrutura interna do benchmark em vez da eficácia da busca do algoritmo. Eles defendem "divulgações de acesso a dados" explícitas em futuras pesquisas dirigidas por LLM para prevenir tal "exploração de oráculo".

Em conclusão, o ARES-LSHADE alcança um desempenho forte (510/744 vitórias) sob regras estritas de caixa preta, mas o valor principal do artigo reside em sua documentação transparente do processo de design, na identificação de limites algorítmicos em estruturas específicas de benchmark e no tratamento ético do acesso a metadados.