Resumo Técnico: LEVI – Arquiteturas de Busca Mais Fortes Podem Substituir LLMs Maiores em Busca Evolutiva

1. Declaração do Problema

Métodos evolutivos guiados por LLM (como AlphaEvolve, FunSearch) demonstraram eficácia em domínios como descoberta matemática, otimização de código e engenharia de prompts. No entanto, esses frameworks dependem atualmente fortemente de Modelos de Linguagem Grandes (LLMs) de ponta, caros, para cada etapa de mutação e avaliação. Essa dependência cria uma alta barreira de entrada, com execuções individuais custando até US$ 30 e exigindo milhares de chamadas a modelos como Claude Opus ou Gemini Pro.

Os autores argumentam que esse custo não é um requisito inerente à evolução guiada por LLM, mas sim um artefato de arquiteturas de busca ineficientes. Frameworks existentes frequentemente falham em preservar a diversidade de soluções, forçando a dependência de modelos maiores para escapar de ótimos locais. Eles também tratam todas as chamadas de mutação de forma uniforme, gastando orçamentos de modelos de ponta em edições locais que modelos menores poderiam lidar, e desperdiçam recursos em avaliações redundantes em cenários com muitos rollouts.

2. Metodologia: O Framework LEVI

O LEVI (Framework Evolutivo Primeiro-Harness) foi projetado para desacoplar o desempenho da busca da escala do modelo, otimizando três eixos de custo específicos: o banco de dados de soluções, o roteamento de mutações e a estratégia de avaliação.

2.1. Banco de Dados de Soluções: CVT-MAP-Elites com Inicialização Bootstrap

O LEVI substitui arquivos padrão por um arquivo CVT-MAP-Elites (MAP-Elites de Tesselação Voronoi Centroidal).

• Preservação de Diversidade: Diferentemente do MAP-Elites de grade regular, o CVT-MAP-Elites escala elegantemente para espaços de descritores de alta dimensão sem crescimento exponencial de células. Ele mapeia candidatos para células comportamentais com base em uma tupla de descritores do lado de entrada (por exemplo, características AST como complexidade ciclomática) e do lado de saída (por exemplo, perfis de tempo de execução).
• Inicialização Bootstrap: Em vez de começar a partir de uma única semente, o LEVI realiza uma "passagem de semente" prévia onde um LLM gera uma sequência de soluções estruturalmente diversas. Essas sementes, mesmo com pontuação baixa, são usadas para calibrar os limites de descritores do arquivo (via normalização z-score e transformações sigmoide) e preencher as células iniciais.
• Dimensões Comportamentais: O arquivo mantém a diversidade garantindo que identidades algorítmicas distintas ocupem células diferentes, impedindo que a busca colapse em uma única bacia de atração.

2.2. Roteamento de Mutação Consciente de Função

O LEVI introduz um roteador que atribui tarefas de mutação a modelos com base no "papel" específico da mutação, em vez de usar um único modelo grande para todas as etapas.

• Rota de Refinamento (~90% das chamadas): Edições locais (ajuste de constantes, troca de estruturas de dados) são roteadas para modelos menores e mais baratos (por exemplo, Qwen3-30B-A3B). A diversidade robusta do arquivo absorve o ruído e a redundância típicos de modelos menores, impedindo o desvio do arquivo.
• Rota de Mudança de Paradigma (~10% das chamadas): Periodicamente, ou em caso de estagnação, um modelo maior (por exemplo, Gemini Flash 3) é acionado. Em vez de mutar um único pai, o modelo grande recebe representantes de células distintas e bem separadas do arquivo e recebe a tarefa de propor um candidato que pertença a uma nova família algorítmica. Isso visa reescritas estruturais em vez de refinamentos locais.

2.3. Seleção de Benchmark Proxy

Para configurações onde a avaliação é dominada por rollouts (por exemplo, otimização de prompts), o LEVI constrói um benchmark proxy ($D_{proxy}$) a partir do conjunto de validação completo.

• Preservação de Classificação: O proxy é selecionado via seleção progressiva gulosa para maximizar a correlação entre a classificação dos candidatos no conjunto proxy e no conjunto completo.
• Função Objetivo: A seleção otimiza a fidelidade de classificação (acordo na ordenação dos candidatos), separação (poder discriminativo dos exemplos) e minimização de redundância. Isso permite que o loop evolutivo seja executado com significativamente menos rollouts por iteração, mantendo o sinal de seleção necessário para a evolução.

3. Contribuições Principais

1. Eficiência Arquitetural: O LEVI demonstra que investir em arquitetura de busca (manutenção de diversidade, roteamento consciente de função e seleção de proxy) pode substituir ou superar o uso de LLMs maiores.
2. Redução de Custos: O framework alcança resultados state-of-the-art ou competitivos a uma fração do custo das bases de modelos de ponta existentes.
3. Implementação de Código Aberto: O LEVI é lançado como um framework de código aberto, fornecendo um harness reprodutível para busca evolutiva primeiro-harness.

4. Resultados Experimentais

Os autores avaliaram o LEVI em sete benchmarks de pesquisa de sistemas e quatro benchmarks de otimização de prompts.

4.1. Benchmarks de Pesquisa de Sistemas

• Desempenho vs. Custo: Em seis dos sete problemas (Cloudcast, EPLB, LLM-SQL, Prism, Txn Sched, Spot-M, Spot-S), o LEVI alcançou as melhores pontuações usando um orçamento 3,3–6,7× menor do que execuções publicadas de modelos de ponta de frameworks como GEPA, OpenEvolve, ShinkaEvolve e AdaEvolve.
• Ganhos Específicos: No problema LLM-SQL, o LEVI superou o framework líder usando apenas US$ 0,50, uma redução de custo de 35×.
• Eficiência de Amostra: Em comparações controladas usando o mesmo modelo (Qwen3-30B-A3B) e orçamento, o LEVI alcançou alto desempenho 15× mais rápido (em termos de avaliações) do que as bases, continuando a melhorar onde outras estagnaram.

4.2. Otimização de Prompts

• Eficiência de Rollout: Em quatro benchmarks (HotpotQA, IFBench, Hover, PUPA), o LEVI igualou ou superou o desempenho do GEPA usando menos da metade do orçamento de rollouts (2.191 vs. 4.985 rollouts no agregado).
• Eficácia do Proxy: A seleção de benchmark proxy preservou com sucesso o sinal de classificação, permitindo que o loop evolutivo convergisse com menos avaliações do conjunto completo.

4.3. Estudos de Ablação

• Semente: A remoção da inicialização bootstrap causou quedas significativas de desempenho (por exemplo, uma queda de 5 pontos no Agendamento Spot), confirmando a necessidade de diversidade inicial.
• Dimensões de Diversidade: Descritores mais ricos foram críticos para problemas que exigem múltiplas famílias algorítmicas (Agendamento Spot), mas menos críticos para problemas dominados por uma única família (Agendamento de Transações).
• Roteamento de Modelo: A rota "Mudança de Paradigma" foi decisiva para problemas que exigem saltos estruturais (EPLB), onde a remoção de modelos grandes causou estagnação. Por outro lado, para tarefas pesadas em refinamento local (Agendamento de Transações), a rota de modelo grande foi às vezes um overhead.

5. Significado e Alegações

O artigo afirma que o alto custo da busca evolutiva guiada por LLM é amplamente um problema de engenharia solucionável, e não uma limitação fundamental do paradigma. Ao mudar o foco de "modelos maiores" para "arquiteturas de busca mais fortes", o LEVI reduz a barreira de entrada para a descoberta evolutiva.

Os autores posicionam o LEVI como uma prova de conceito de que arquiteturas de busca mais fortes podem substituir LLMs maiores. Eles observam que, embora sua abordagem reduza os custos em dólares ao transferir o trabalho para modelos mais baratos e arquiteturas mais fortes, pode exigir mais avaliações, uma compensação que é favorável quando as avaliações são baratas (por exemplo, execução de código), mas menos favorável quando são caras (por exemplo, treinamento de modelos). O trabalho sugere uma direção futura onde a busca evolutiva depende inteiramente de modelos baratos e de pesos abertos, desde que o harness de busca seja suficientemente robusto.