🤖 machine learning

Evolving Executable Pipeline Programs for AutoML with Language Models

LACE es un novedoso marco de AutoML que emplea un bucle evolutivo guiado por un modelo de lenguaje de gran tamaño para generar y evolucionar programas de tuberías de Python ejecutables, logrando una precisión competitiva en 68 tareas de OpenML mientras ofrece una transparencia, capacidad de edición y flexibilidad del espacio de búsqueda superiores en comparación con los sistemas tradicionales.

Autores originales: Sofoklis Kitharidis, Cor J. Veenman, Jan N. van Rijn, Thomas Bäck, Niki van Stein

Publicado 2026-08-18

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Sofoklis Kitharidis, Cor J. Veenman, Jan N. van Rijn, Thomas Bäck, Niki van Stein

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

En el mundo de la ciencia de datos moderna, se le pide cada vez más a las máquinas que den sentido a información desordenada del mundo real: predecir si un solicitante de un préstamo podrá pagar, diagnosticar una enfermedad a partir de una hoja de cálculo de síntomas o pronosticar ventas basadas en tendencias pasadas. Para lograr esto, los investigadores construyen "pipelines" (tuberías), que son instrucciones paso a paso que limpian los datos, eligen un modelo matemático y ajustan ese modelo hasta que funciona bien. Durante años, las herramientas más potentes para este trabajo han sido sistemas automatizados que actúan como un maestro chef con un conjunto fijo de ingredientes. Estos sistemas pueden mezclar y combinar pasos de preprocesamiento y algoritmos de aprendizaje conocidos, ajustando las cantidades para encontrar el mejor sabor. Sin embargo, están estrictamente limitados a la despensa que se les dio; no pueden inventar un nuevo ingrediente o una nueva técnica de cocina que quede fuera de su lista predefinida. Esta limitación significa que, si la mejor solución requiere una estructura que el sistema nunca ha visto, esta permanecerá sin descubrir.

Un equipo de investigadores de la Universidad de Leiden ha introducido ahora un enfoque diferente, uno que trata la creación de estos pipelines de datos no como una selección de un menú, sino como la escritura de una nueva receta desde cero. Desarrollaron un sistema llamado LACE, que utiliza un modelo de lenguaje extenso —una inteligencia artificial entrenada en vastas cantidades de texto y código— para actuar como un motor evolutivo. En lugar de elegir de una lista fija de herramientas, LACE le pide a la IA que escriba programas informáticos completos y ejecutables que definan cómo procesar los datos y realizar predicciones. El sistema luego prueba estos programas, aprende de sus errores y le pide a la IA que escriba versiones mejoradas, repitiendo este ciclo hasta encontrar una solución altamente efectiva. El resultado es un sistema que no solo retoca herramientas existentes, sino que puede componer estructuras enteramente nuevas, produciendo código que los expertos humanos pueden leer, entender y modificar directamente.

Los investigadores probaron este método en 68 tareas diferentes de clasificación de datos, que van desde conjuntos de datos pequeños con unos pocos cientos de entradas hasta colecciones masivas con casi cinco millones de filas. Compararon LACE contra varios sistemas automatizados establecidos y un conjunto de modelos preentrenados fijos. Los resultados mostraron que LACE, cuando es impulsado por un modelo de lenguaje específico, funcionó tan bien como los sistemas automatizados más fuertes existentes y significativamente mejor que los métodos más antiguos. Crucialmente, aunque algunos de los modelos preentrenados más nuevos fueron ligeramente más precisos en las tareas específicas que podían manejar, fallaron al intentar trabajar en muchos de los conjuntos de datos más grandes o complejos del conjunto de pruebas. LACE, por el contrario, generó con éxito una solución funcional para cada una de las tareas que se le presentaron.

Lo que hace que este logro sea particularmente notable es la naturaleza del resultado. Los sistemas automatizados tradicionales suelen devolver una "caja negra": un objeto complejo y ajustado que funciona bien pero es difícil de inspeccionar o cambiar para un humano sin un profundo conocimiento técnico del marco de software. LACE devuelve código Python ordinario. Esto significa que un científico de datos puede mirar el programa final, ver exactamente cómo se limpiaron los datos, qué modelos se eligieron y cómo se combinaron, y luego editar el código para mejorarlo aún más o adaptarlo para un nuevo propósito. Los investigadores encontraron que la IA no solo copió patrones existentes; evolucionó soluciones diversas, combinando a menudo diferentes tipos de modelos de maneras novedosas y escribiendo lógica personalizada para mezclar sus predicciones. En muchos casos, la IA escribió su propio código para mezclar las salidas de múltiples modelos, un nivel de flexibilidad que los sistemas fijos no pueden replicar fácilmente.

El estudio también abordó una preocupación común en la investigación de la inteligencia artificial: que la IA simplemente estuviera memorizando las respuestas a las preguntas de la prueba porque las había visto antes durante su entrenamiento. Para evitar esto, los investigadores ocultaron los nombres y los detalles específicos de los conjuntos de datos, dándole a la IA solo una descripción general del tamaño y tipo de los datos. A pesar de esta falta de conocimiento específico, el sistema aun así encontró soluciones de alto rendimiento, lo que sugiere que estaba aprendiendo genuinamente cómo construir pipelines efectivos en lugar de recordar respuestas. Los investigadores verificaron además que la IA siguiera reglas estrictas, como no utilizar búsquedas internas ocultas para ajustar sus propios parámetros, asegurando que las mejoras provinieran del proceso de búsqueda evolutiva en sí mismo.

Uno de los hallazgos más impactantes fue la rapidez con la que el sistema mejoró. El primer programa generado por la IA era a menudo defectuoso o incompleto, pero a medida que el sistema iteraba, aprendía a corregir estos errores y a refinar la lógica. Para cuando el proceso terminó, los programas finales no solo eran válidos, sino significativamente más precisos que los intentos iniciales. Los investigadores observaron que el sistema tendía a favorecer ciertos tipos de modelos, como los ensambles basados en árboles, pero no se quedó estancado en un solo patrón; exploró una amplia variedad de combinaciones estructurales. Esta diversidad sugiere que el sistema es capaz de descubrir soluciones que un humano podría no pensar en intentar, o que un sistema rígido nunca consideraría.

El trabajo demuestra que tratar el aprendizaje automático automatizado como un proceso de escritura y evolución de código abre una nueva frontera. Va más allá de la restricción de una biblioteca fija de herramientas, permitiendo que el sistema adapte su estructura al problema específico en cuestión. Aunque el costo computacional de ejecutar estos experimentos fue alto, requiriendo un tiempo significativo para generar y probar miles de programas candidatos, los resultados sugieren que la capacidad de producir código transparente, editable y altamente efectivo es un intercambio valioso. Los investigadores concluyen que este enfoque ofrece un camino prometedor, donde la búsqueda del mejor pipeline de datos está definida por la creatividad del propio código, en lugar de por las limitaciones de un conjunto preseleccionado de componentes.

Resumen Técnico: Evolución de Programas de Pipeline Ejecutables para AutoML con Modelos de Lenguaje

Declaración del Problema

Los sistemas tradicionales de Aprendizaje Automático Automatizado (AutoML) operan dentro de un espacio de operadores, aprendices e hiperparámetros fijos y predefinidos. Si bien sistemas como auto-sklearn, AutoGluon y H2O AutoML pueden seleccionar y ajustar eficazmente componentes de bibliotecas curadas, no pueden generar innovaciones estructurales fuera de sus gramáticas especificadas. Por el contrario, los modelos fundacionales tabulares (por ejemplo, TabPFN) evitan la búsqueda por tarea aplicando predictores preentrenados, pero devuelven modelos fijos en lugar de programas editables y específicos para cada tarea. Además, los agentes de Modelos de Lenguaje de Gran Escala (LLM) existentes para la ciencia de datos suelen centrarse en la experimentación abierta o la ingeniería de características, careciendo de un marco riguroso para la evolución de programas de pipeline restringidos donde el espacio de búsqueda está definido por la generación de código en lugar de un inventario estático de operadores.

Un desafío crítico al aplicar LLMs al AutoML es el riesgo de contaminación de los benchmarks, donde los modelos pueden reconocer conjuntos de datos públicos de sus datos de preentrenamiento, confundiendo el diseño del pipeline con la memorización del conjunto de datos. Adicionalmente, los resultados de los AutoML clásicos suelen ser objetos de framework opacos, mientras que los modelos fundacionales son predictores de caja negra, lo que limita la inspectabilidad y la reutilización por parte del profesional.

Metodología: LACE

Los autores presentan LACE (LLM-Automated Code Evolution), un marco de AutoML que formula la búsqueda de pipelines tabulares como la optimización evolutiva de programas Python completos y ejecutables.

Arquitectura Central

LACE emplea un bucle evolutivo $(\mu + \lambda)$ donde el LLM actúa como el operador de variación:

Representación: Los candidatos son clases Python que implementan una interfaz compatible con scikit-learn: __init__(X, y) ajusta el modelo una sola vez, y __call__(X) devuelve predicciones. El espacio de búsqueda está definido implícitamente por los programas que el LLM puede generar bajo restricciones específicas, en lugar de una gramática fija.
Restricciones: El prompt restringe a los candidatos al uso de librerías estándar (scikit-learn, numpy, scipy, pandas), limita los ensambles a tres aprendices, impone una única etapa de preprocesamiento compartida y prohíbe explícitamente la validación cruzada interna, el AutoML anidado o los bucles internos de búsqueda de hiperparámetros. Los hiperparámetros ajustables deben exponerse como argumentos del constructor.
Proceso Evolutivo:
- Inicialización: Se genera una población inicial de $\mu=4$ pipelines a partir de un resumen de tarea grueso.
- Variación: Para cada generación, se selecciona un padre y el LLM genera un descendiente modificando el código del padre basándose en la retroalimentación de la evaluación y una instrucción de mutación seleccionada al azar (por ejemplo, cambiar la familia de modelos, refinar el preprocesamiento, ajustar el ensamble).
- Selección: Se retienen los $\mu$ individuos mejores del conjunto combinado de padres e hijos (truncamiento elitista).
Protocolo de Evaluación:
- Control de Fugas (Leakage): Para evitar el reconocimiento del conjunto de datos, el generador recibe solo un resumen grueso (tipo de tarea, conteo aproximado de muestras, conteo de características) y ningún nombre, identificador o valor bruto del conjunto de datos.
- Fitness: Los candidatos se evalúan en divisiones de validación interna derivadas de los pliegues (folds) oficiales de entrenamiento. Los pliegues de prueba oficiales nunca se acceden durante la búsqueda.
- Evaluación Final: Una vez agotado el presupuesto de candidatos ( $B=100$ ), el mejor pipeline se vuelve a ajustar en la totalidad de los datos de entrenamiento y se evalúa una sola vez en los pliegues de prueba oficiales.

Configuración Experimental

El marco fue evaluado en 68 tareas de clasificación del conjunto de benchmarks amlb-classification-all de OpenML. El estudio comparó LACE (utilizando tres backbones de LLM: gpt-5.4-mini, deepseek-v4-flash y qwen3-coder-next) contra:

AutoML Clásico: AutoGluon-Tabular, auto-sklearn, H2O AutoML.
Modelos Fundacionales Tabulares: TabPFN v2.5, TabPFN v3, TabICL.
Línea Base (Baseline): Un pipeline de XGBoost fijo.

Todos los métodos estuvieron sujetos a presupuestos de tiempo idénticos por repetición de tarea para asegurar una comparación justa de la eficiencia de búsqueda.

Resultados Clave

Rendimiento y Cobertura

Precisión Competitiva: En las 45 tareas donde todos los métodos produjeron resultados válidos, LACE con gpt-5.4-mini logró un rango medio de 4.71, superando significativamente a auto-sklearn, H2O y la línea base de XGBoost fijo. No mostró diferencias estadísticamente significativas con AutoGluon (el baseline de búsqueda más fuerte) y TabPFN v2.5.
Cobertura Superior: A diferencia de los modelos fundacionales (TabPFN v2.5, v3 y TabICL), que fallaron en tareas que excedían sus límites de tamaño de entrada o de características, LACE cubrió el 100% de las 68 tareas. Al contabilizar la cobertura (penalizando los resultados faltantes), LACE (gpt-5.4-mini) y AutoGluon permanecieron empatados en la posición superior, mientras que TabPFN v2.5 cayó significativamente en el ranking debido a su incapacidad para manejar 23 tareas.
Sensibilidad al Backbone: La elección del backbone del LLM impactó el rendimiento. gpt-5.4-mini fue la configuración más fuerte, superando a deepseek-v4-flash y qwen3-coder-next con ganancias consistentes, aunque pequeñas, en la mediana.

Dinámica de Búsqueda y Calidad del Programa

Recuperación Zero-Shot: Los candidatos iniciales zero-shot tuvieron tasas de validez que oscilaron entre el 37.6% y el 79.7% dependiendo del backbone. Sin embargo, el proceso evolutivo logró recuperar pipelines válidos en el 100% de las ejecuciones, demostando la robustez del marco ante fallos de generación inicial.
Generalización: La búsqueda mejoró la generalización, no solo el objetivo de validación interna. Cuando los programas iniciales válidos se volvieron a ajustar y probaron en datos no vistos, los pipelines evolucionados finales mejoraron la precisión en una mediana de 2.99 puntos porcentuales.
Diversidad Estructural: Los pipelines generados no colapsaron en una única plantilla. Entre los 1,020 pipelines finales, el 99.9% incluyó preprocesamiento personalizado y el 73.3% combinó múltiples aprendices. El espacio de búsqueda exhibió una alta diversidad estructural, con 65,298 firmas estructurales únicas a través de los candidatos válidos.
Inspectabilidad: Una contribución única de LACE es el formato de salida. A diferencia de los objetos específicos de un framework o los pesos preentrenados fijos, LACE devuelve código Python ordinario. Los autores auditaron 89 pipelines finales (8.7%) que implementaban la lógica de predicción (por ejemplo, ensambles ponderados) directamente en NumPy o Python, permitiendo a los profesionales inspeccionar, modificar y reutilizar decisiones específicas de la tarea directamente.

Significación y Reivindicaciones

El artículo afirma que LACE establece los programas ejecutables como una representación de búsqueda viable y prometedora para el AutoML. Sus principales contribuciones son:

Espacio de Búsqueda Definido por Código: Reemplaza las gramáticas de operadores fijos con un espacio de búsqueda definido por la capacidad del LLM para generar código restringido, permitiendo el descubrimiento de estructuras de pipeline y combinaciones de preprocesamiento novedosas que las gramáticas fijas podrían omitir.
Cobertura Completa con Editabilidad: Logra una cobertura completa de un benchmark diverso devolviendo programas editables y específicos para la tarea. Esto contrasta con los modelos fundacionales que ofrecen alta precisión en tareas soportadas pero carecen de flexibilidad, y con el AutoML clásico que devuelve objetos de framework opacos.
Evaluación Rigurosa: El estudio demuestra que la evolución impulsada por LLM puede competir con sistemas de AutoML basados en búsqueda de última generación cuando se evalúa bajo protocolos estrictos de control de fugas que ocultan la identidad del conjunto de datos.

Los autores señalan modestamente que el espacio de búsqueda efectivo está moldeado por los componentes anunciados en el prompt (como se muestra en un estudio de ablación donde los componentes de TabPFN no anunciados nunca fueron utilizados) y que el costo computacional es alto, aunque la dinámica de búsqueda sugiere un potencial para presupuestos adaptativos. El trabajo no pretende reclamar una superioridad de precisión bruta sobre todos los modelos fundacionales en todas las tareas, sino que enfatiza el compromiso entre la flexibilidad del código editable y el rendimiento de los predictores especializados preentrenados.