Al integrar una tarea real en EvoX, la dificultad nunca está en «cambiar por un operador evolutivo más potente», sino en primeroformalizar un contrato para la tarea: qué objetos pueden modificarse (espacio de búsqueda), qué resultados pueden observarse (canal de retroalimentación) y qué cambios deben conservarse (criterio de evaluación). Estos tres límites determinan conjuntamente si el ciclo evolutivo puede sostenerse, por lo que deben definirse antes de poner en marcha el sistema, y no explorarse poco a poco durante el proceso evolutivo.
I. Límite de objetos modificables: delimitar el espacio de búsqueda
Declarar explícitamente las variables de decisión y su estructura (genotipo), así como su correspondencia con el producto real (fenotipo), señalando además las restricciones de solo lectura del entorno, los datos, las interfaces y el hardware. Un límite demasiado amplio introduce una gran cantidad de candidatos inválidos en la búsqueda; un límite demasiado estrecho no deja margen alguno para la evolución. Tomando como ejemplo una canalización de procesamiento de datos, lo modificable es la selección de operadores, el orden de ejecución y los hiperparámetros, mientras que la estructura de los datos de entrada y las restricciones de cumplimiento son partes de solo lectura.
II. Límite de resultados observables: habilitar el canal de retroalimentación
Cada candidato debe poder generar señales capturables por el programa. Hay que definir el canal de observación, la latencia, el nivel de ruido y la reproducibilidad. Las dimensiones que no pueden observarse no pueden servir como base de optimización, solo como explicación a posteriori: incluir en la función de aptitud aquello que no se observa solo hace que la evolución derive hacia el ruido.
III. Criterio de evaluación y regla de conservación: definir qué merece perdurar
Definir la función de aptitud o el vector de objetivos, las condiciones de restricción y la determinación de viabilidad; especificar si se comprime en un único valor o si se conserva mediante Pareto multiobjetivo, y estipular cómo penalizar, reparar o detener de forma anticipada los candidatos fallidos, bloqueados o con tiempo de espera agotado. Una vez fijado el criterio de evaluación, se determina en la práctica hacia qué dirección convergerá la evolución.
IV. El ritmo de la evaluación: paralelismo, coste y presupuesto
Confirmar si la evaluación puede ejecutarse por lotes o de forma asíncrona, el coste por evaluación y el presupuesto total. El grado de paralelismo y la latencia individual determinan directamente el ritmo del ciclo evolutivo y las generaciones asumibles: la evaluación en serie alarga el ciclo y reduce drásticamente las generaciones asumibles, mientras que la evaluación por lotes o asíncrona acelera notablemente las iteraciones. Las condiciones de parada y el presupuesto también deben quedar claros: definir el presupuesto de evaluación, el criterio de convergencia y las condiciones de parada, para evitar tanto un consumo ilimitado de cómputo como la terminación prematura de soluciones aún incipientes.
V. Fiabilidad de la evaluación: cuidado con «optimizar la métrica sin resolver el problema»
Hay que estar atentos a tres tipos de riesgo: el desajuste entre la métrica proxy y el objetivo real, la fuga de objetivos y el aprovechamiento inverso del evaluador por parte de los candidatos (explotar fallos de puntuación para inflar la nota). La forma de afrontarlo es mantener un conjunto de validación independiente o una etapa de revisión manual, y procurar que el proceso de evaluación sea sin estado y reproducible, para poder reproducir fallos y atribuir resultados.
VI. El contrato de integración
Por último, encapsular la tarea como una interfaz que EvoX pueda invocar: recibe un candidato, devuelve métricas y restricciones, y garantiza que la evaluación sea lo más sin estado y reproducible posible. Solo con un contrato estable el ciclo puede ser estable. Si se toma la puntuación sobre el conjunto de entrenamiento como único criterio de conservación, la evolución se sobreajustará rápidamente a esa métrica; precisamente por eso el límite de evaluación debe definirse antes que el límite de búsqueda.
Cuestiones clave al integrar tareas en EvoXLa ilustración gira en torno a los tres límites de la integración de tareas en EvoX: los objetos modificables delimitan el espacio de búsqueda, los resultados observables habilitan el canal de retroalimentación, y el criterio de evaluación determina qué merece conservarse; además, se extiende a aspectos como el ritmo de evaluación, el presupuesto y la fiabilidad, y culmina en un contrato de integración que recibe candidatos y devuelve métricas y restricciones. Subraya que el límite debe fijarse antes que el operador, porque el límite determina la dirección de la evolución.
