Resumen Técnico: LEVI – Arquitecturas de Búsqueda Más Potentes Pueden Sustituir a LLMs Más Grandes en la Búsqueda Evolutiva

1. Declaración del Problema

Los métodos evolutivos guiados por LLM (por ejemplo, AlphaEvolve, FunSearch) han demostrado eficacia en dominios como el descubrimiento matemático, la optimización de código y la ingeniería de prompts. Sin embargo, estos marcos dependen actualmente en gran medida de Grandes Modelos de Lenguaje (LLM) fronterizos y costosos para cada paso de mutación y evaluación. Esta dependencia crea una alta barrera de entrada, con ejecuciones individuales que cuestan hasta 30 dólares y requieren miles de llamadas a modelos como Claude Opus o Gemini Pro.

Los autores argumentan que este costo no es un requisito inherente de la evolución guiada por LLM, sino un artefacto de arquitecturas de búsqueda ineficientes. Los marcos existentes a menudo fallan en preservar la diversidad de soluciones, forzando la dependencia de modelos más grandes para escapar de óptimos locales. También tratan todas las llamadas de mutación de manera uniforme, gastando presupuestos de modelos fronterizos en ediciones locales que modelos más pequeños podrían manejar, y desperdician recursos en evaluaciones redundantes en entornos con muchas simulaciones (rollouts).

2. Metodología: El Marco LEVI

LEVI (Marco Evolutivo de Ensamblaje Primero) está diseñado para desacoplar el rendimiento de la búsqueda de la escala del modelo optimizando tres ejes de costo específicos: la base de datos de soluciones, el enrutamiento de mutaciones y la estrategia de evaluación.

2.1. Base de Datos de Soluciones: CVT-MAP-Elites con Sembrado Inicial

LEVI reemplaza los archivos estándar con un archivo CVT-MAP-Elites (MAP-Elites de Teselación de Voronoi Centroidal).

• Preservación de la Diversidad: A diferencia de los MAP-Elites de cuadrícula regular, CVT-MAP-Elites escala elegantemente a espacios de descriptores de alta dimensión sin un crecimiento exponencial de celdas. Mapea candidatos a celdas conductuales basadas en una tupla de descriptores del lado de entrada (por ejemplo, características de AST como la complejidad ciclomática) y del lado de salida (por ejemplo, perfiles de tiempo de ejecución).
• Inicialización Sembrada: En lugar de comenzar con una sola semilla, LEVI realiza un "paso de semilla" previo donde un LLM genera una secuencia de soluciones estructuralmente diversas. Estas semillas, incluso si tienen puntuaciones bajas, se utilizan para calibrar los límites de los descriptores del archivo (mediante normalización z-score y transformaciones sigmoideas) y poblar las celdas iniciales.
• Dimensiones Conductuales: El archivo mantiene la diversidad asegurando que identidades algorítmicas distintas ocupen celdas diferentes, evitando que la búsqueda colapse en una sola cuenca de atracción.

2.2. Enrutamiento de Mutaciones Consciente del Rol

LEVI introduce un enrutador que asigna tareas de mutación a modelos basándose en el "rol" específico de la mutación, en lugar de usar un único modelo grande para todos los pasos.

• Ruta de Refinamiento (~90% de las llamadas): Las ediciones locales (ajustar constantes, intercambiar estructuras de datos) se enrutan a modelos más pequeños y económicos (por ejemplo, Qwen3-30B-A3B). La diversidad robusta del archivo absorbe el ruido y la redundancia típicos de los modelos más pequeños, evitando la deriva del archivo.
• Ruta de Cambio de Paradigma (~10% de las llamadas): Periódicamente, o ante estancamiento, se activa un modelo más grande (por ejemplo, Gemini Flash 3). En lugar de mutar un solo padre, el modelo grande recibe representantes de celdas del archivo distintas y bien separadas, y se le asigna la tarea de proponer un candidato que pertenezca a una nueva familia algorítmica. Esto apunta a reescrituras estructurales en lugar de refinamientos locales.

2.3. Selección de Referencia Proxy

Para configuraciones donde la evaluación está dominada por simulaciones (por ejemplo, optimización de prompts), LEVI construye una referencia proxy ($D_{proxy}$) a partir del conjunto de validación completo.

• Preservación de la Clasificación: La referencia se selecciona mediante selección secuencial voraz para maximizar la correlación entre la clasificación de candidatos en el conjunto proxy y el conjunto completo.
• Función Objetivo: La selección optimiza la fidelidad de la clasificación (acuerdo en el ordenamiento de candidatos), la separación (poder discriminatorio de los ejemplos) y la minimización de la redundancia. Esto permite que el bucle evolutivo se ejecute con significativamente menos simulaciones por iteración, manteniendo la señal de selección requerida para la evolución.

3. Contribuciones Clave

1. Eficiencia Arquitectónica: LEVI demuestra que invertir en la arquitectura de búsqueda (mantenimiento de la diversidad, enrutamiento consciente del rol y selección proxy) puede sustituir o superar el uso de LLMs más grandes.
2. Reducción de Costos: El marco logra resultados de vanguardia o competitivos a una fracción del costo de las líneas base existentes con modelos fronterizos.
3. Implementación de Código Abierto: LEVI se lanza como un marco de código abierto, proporcionando un ensamblaje reproducible para la búsqueda evolutiva de ensamblaje primero.

4. Resultados Experimentales

Los autores evaluaron LEVI en siete benchmarks de investigación de sistemas y cuatro benchmarks de optimización de prompts.

4.1. Benchmarks de Investigación de Sistemas

• Rendimiento vs. Costo: En seis de siete problemas (Cloudcast, EPLB, LLM-SQL, Prism, Txn Sched, Spot-M, Spot-S), LEVI logró las mejores puntuaciones utilizando un presupuesto 3.3–6.7 veces menor que las ejecuciones publicadas con modelos fronterizos de marcos como GEPA, OpenEvolve, ShinkaEvolve y AdaEvolve.
• Ganancias Específicas: En el problema LLM-SQL, LEVI superó al marco líder utilizando solo 0.50 dólares, una reducción de costos de 35 veces.
• Eficiencia de Muestra: En comparaciones controladas usando el mismo modelo (Qwen3-30B-A3B) y presupuesto, LEVI alcanzó un alto rendimiento 15 veces más rápido (en términos de evaluaciones) que las líneas base, continuando mejorando donde otras se estancaron.

4.2. Optimización de Prompts

• Eficiencia de Simulaciones: En cuatro benchmarks (HotpotQA, IFBench, Hover, PUPA), LEVI igualó o superó el rendimiento de GEPA mientras utilizaba menos de la mitad del presupuesto de simulaciones (2,191 frente a 4,985 simulaciones en total).
• Efectividad del Proxy: La selección de la referencia proxy preservó con éxito la señal de clasificación, permitiendo que el bucle evolutivo convergiera con menos evaluaciones del conjunto completo.

4.3. Estudios de Ablación

• Sembrado: Eliminar la inicialización sembrada causó caídas significativas en el rendimiento (por ejemplo, una caída de 5 puntos en la Programación de Puntos), confirmando la necesidad de diversidad temprana.
• Dimensiones de Diversidad: Descriptores más ricos fueron críticos para problemas que requieren múltiples familias algorítmicas (Programación de Puntos) pero menos críticos para problemas dominados por una sola familia (Programación de Transacciones).
• Enrutamiento de Modelos: La ruta "Cambio de Paradigma" fue decisiva para problemas que requieren saltos estructurales (EPLB), donde eliminar los modelos grandes causó estancamiento. Por el contrario, para tareas pesadas en refinamiento local (Programación de Transacciones), la ruta de modelo grande fue a veces un sobrecosto.

5. Significado y Afirmaciones

El artículo afirma que el alto costo de la búsqueda evolutiva guiada por LLM es en gran medida un problema de ingeniería resoluble en lugar de una limitación fundamental del paradigma. Al cambiar el enfoque de "modelos más grandes" a "arquitecturas de búsqueda más potentes", LEVI reduce la barrera de entrada para el descubrimiento evolutivo.

Los autores posicionan a LEVI como una prueba de concepto de que arquitecturas de búsqueda más potentes pueden sustituir a LLMs más grandes. Señalan que, aunque su enfoque reduce los costos en dólares al trasladar el trabajo a modelos más baratos y arquitecturas más fuertes, puede requerir más evaluaciones, un intercambio que es favorable cuando las evaluaciones son económicas (por ejemplo, ejecución de código) pero menos favorable cuando son costosas (por ejemplo, entrenamiento de modelos). El trabajo sugiere una dirección futura donde la búsqueda evolutiva dependa enteramente de modelos abiertos y económicos, siempre que el ensamblaje de búsqueda sea lo suficientemente robusto.