# EvoX Sistema de Evolución Inteligente y Práctica de Investigación AI Native — Apuntes del Curso

Duración: 1 · Páginas de diapositivas: 16

## Navegación de lectura

- [Lección 4｜Tema: Base computacional moderna y evolución paralela tensorizada](#lecture-lesson-1)

---

<a id="lecture-lesson-1"></a>

## Lección 4｜Tema: Base computacional moderna y evolución paralela tensorizada

<a id="lecture-page-1"></a>

### Base computacional moderna y evolución paralela tensorizada

*Página 1*

> **Objetivo de la página:** Aprender cómo EvoX organiza la población, la evaluación y el estado como tensores computables de forma integral, superando los cuellos de botella seriales tradicionales para lograr una aceleración a gran escala.

> **Objetivo de la página**
>
> Esta página sirve como apertura de la cuarta lección y señala el problema central que se abordará: cuando el tamaño de la población, el número de evaluaciones y los pasos de iteración de los algoritmos evolutivos crecen continuamente, el procesamiento serial tradicional individuo por individuo y paso por paso se convierte en un cuello de botella evidente. La línea principal de esta lección es ver cómo EvoX reorganiza la población, la evaluación y el estado en tensores que pueden participar en el cálculo de forma integral, obteniendo así una aceleración sustancial en escenarios a gran escala.

> **Orden de explicación**
>
> Se puede comenzar lanzando una pregunta intuitiva: "Si hay cien mil individuos en la población, ¿qué pasaría si tuviéramos que procesarlos uno por uno en un bucle?" Esto ayuda a los estudiantes a reconocer el doble desperdicio del bucle serial en tiempo y utilización del hardware. Luego se presenta la dirección de respuesta de esta lección: tratar toda la población como un lote de datos y la actualización de una generación como una operación por lotes, permitiendo que el cálculo se ejecute de forma paralela en hardware. Finalmente, se introduce el papel de la capa Runtime, explicando que se encarga de programar recursos de cómputo heterogéneos mientras mantiene la composabilidad de los algoritmos.

**Puntos clave de enseñanza**

- 1. Expresión tensorizada — La población, la evaluación de aptitud y el estado interno del algoritmo ya no son objetos dispersos, sino que se organizan en tensores con formas uniformes, lo que permite expresar una generación de evolución como varias operaciones por lotes. La ventaja es que el patrón de cómputo es regular, facilita la vectorización y permite que la misma descripción algorítmica se adapte a poblaciones de diferentes tamaños. 2. Superación del cuello de botella serial — En implementaciones tradicionales, la evaluación y la actualización de estado suelen realizarse individuo por individuo; cuando la escala crece, la sobrecarga de bucles y la espera de sincronización dominan el tiempo de ejecución
- tras la batched processing, estas sobrecargas se diluyen y el rendimiento aumenta significativamente. 3. El papel de programación del Runtime — El Runtime se sitúa entre la descripción algorítmica y el hardware subyacente, encargándose de distribuir las operaciones por lotes a recursos de cómputo heterogéneos como CPU y GPU, de modo que los autores de algoritmos no necesiten reescribir la lógica para cada dispositivo. Al mismo tiempo, mantiene la composabilidad de los componentes algorítmicos, permitiendo que diferentes operadores y estrategias se combinen libremente sin destruir la capacidad de paralelización.

**Cobertura de palabras clave**

- Tensorización, computación por lotes, cuello de botella serial, aceleración a gran escala, programación de cómputo heterogéneo, composabilidad algorítmica.

**Verificación de comprensión**

Pida a los estudiantes que expliquen con sus propias palabras qué cambia realmente "convertir la población en un tensor" — la respuesta esperada debe centrarse en "pasar de un bucle individuo por individuo a una operación por lotes integral, haciendo que el hardware paralelo se utilice realmente"; si solo repiten terminología sin explicar la causalidad, se les puede sugerir que reorganicen su explicación desde las dos perspectivas de número de cómputos y utilización del hardware.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes han establecido la cadena causal básica "tensorización → computación por lotes → aceleración paralela", pasar a las páginas siguientes para ver en detalle cómo se organizan la población y el estado en tensores, y cómo el Runtime completa la programación.

<a id="lecture-page-2"></a>

### Base computacional moderna y evolución paralela tensorizada

*Página 2*

> **Objetivo de la página:** Los estudiantes deben comprender la contradicción entre las demandas de cómputo a gran escala de la computación evolutiva moderna y las arquitecturas tradicionales.

> **Objetivo de la página**
>
> Comprender la contradicción entre las demandas de cómputo a gran escala de la computación evolutiva moderna y las arquitecturas seriales tradicionales; dominar el enfoque de organizar la población, la evaluación y el estado como tensores para impulsar la evolución de forma paralela por lotes; reconocer la expansión de la generación de candidatos por parte de los grandes modelos y las compensaciones arquitectónicas a nivel de sistema que esto conlleva.

> **Orden de explicación**
>
> Primero señalar la contradicción central "diversidad → número de evaluaciones → costos de gestión de estado y programación", luego explicar por qué el bucle serial alcanza su límite primero; a continuación desarrollar los tres niveles de la tensorización — tensor de población, tensor de evaluación, tensor de estado — y resumir el término central "paralelismo por lotes"; después explicar cómo los grandes modelos llevan la generación de candidatos a nuevas fronteras; finalmente aterrizar en ejemplos de escenarios de EvoX y compensaciones a nivel de sistema, y abordar ejercicios y casos.

**Puntos clave de enseñanza**

- La evolución depende de la diversidad de la población, y la diversidad se traduce directamente en número de evaluaciones, gestión de estado y costos de programación. En el bucle tradicional de CPU individuo por individuo, cada individuo debe llamar individualmente a la función objetivo, actualizar individualmente el estado y registrar individualmente en el log
- cuando la población crece de decenas a miles, el número de evaluaciones y el tiempo de reloj crecen casi linealmente; una vez que una sola simulación tiene un costo elevado, el rendimiento general queda bloqueado al "ritmo de un solo núcleo". Cuanto mayor la diversidad y más costosa la evaluación, más evidente el cuello de botella serial. El enfoque de tensorización reorganiza la población, la evaluación y el estado en tensores computables de forma integral. El tensor de población apila todos los parámetros candidatos en un tensor bidimensional de "número de individuos × dimensión", y una sola llamada a un operador completa la mutación y actualización de toda la población
- el tensor de evaluación empaqueta las solicitudes de evaluación por lotes y las envía, ejecutándose en paralelo mediante GPU o servicios de procesamiento por lotes, y luego fusiona los valores de retorno
- el tensor de estado mantiene la aptitud, la violación de restricciones, el ranking y otros estados intermedios en forma de tensor, permitiendo que la selección, ordenación y actualización se calculen de forma integral. Los tres juntos constituyen el "paralelismo por lotes", que convierte la carga computacional generada por la diversidad de una carga a una escala absorbible por el rendimiento, por lo que no es un detalle de optimización, sino un problema de infraestructura de la computación evolutiva moderna. Una vez abierta la escala de cómputo, la pregunta clave pasa de "¿se puede calcular?" a "¿de dónde vienen los candidatos?". Los grandes modelos pueden comprender lenguaje natural, código, conocimiento de dominio y contexto del proyecto, y a partir de ello construir candidatos de estructura compleja, expandiendo el objeto de evolución de parámetros numéricos a programas, algoritmos e incluso estados completos de sistemas
- los métodos de codificación y mutación que antes dependían del diseño manual ahora pueden ser generados con la participación de modelos. Dos fuerzas se encuentran así: la GPU permite explorar simultáneamente una gran cantidad de posibilidades, el gran modelo permite al sistema generar posibilidades más ricas, y el mecanismo evolutivo se encarga de enviar los candidatos a tareas reales, determinando mediante ejecución y evaluación qué cambios merecen conservarse. Para los ingenieros de algoritmos y desarrolladores de sistemas, esto no es una optimización local, sino una compensación arquitectónica: se necesita un equilibrio a nivel de sistema entre la riqueza de la generación de candidatos, el rendimiento de la computación por lotes y la complejidad de ingeniería. La diversidad es un requisito previo para la efectividad evolutiva, pero debe ser absorbida por el rendimiento. En escenarios de EvoX, si se sigue usando un bucle serial de CPU para evaluar individuo por individuo, el tamaño de la población quedará limitado por el rendimiento
- al cambiar a paralelismo por lotes tensorizado, en la misma ronda se pueden organizar simultáneamente los parámetros, estados de evaluación y actualizaciones de una gran cantidad de candidatos, haciendo que "mantener la diversidad" y "exploración a gran escala" sean simultáneamente viables en ingeniería.

**Cobertura de palabras clave**

- Paralelismo por lotes, tensorización, tensor de población, tensor de evaluación, tensor de estado, cuello de botella serial, generación de candidatos, compensaciones a nivel de sistema.

**Manejo de ejercicios**

Esta página tiene 5 preguntas de opción múltiple y 1 pregunta de caso, con 2 preguntas en total. Las preguntas de opción múltiple verifican respectivamente la contradicción central, la forma de implementación del paralelismo por lotes, el papel de los grandes modelos, las compensaciones a nivel de sistema tras la migración y los cambios directos en escenarios de EvoX. Al responder, agarrar dos líneas principales: primero, la cadena causal "diversidad → carga computacional → cuello de botella serial → paralelismo por lotes"; segundo, la división "el gran modelo se encarga de generar candidatos más ricos, el mecanismo de evaluación se encarga de determinar qué candidatos merecen conservarse". La primera pregunta del caso requiere diagnosticar el cuello de botella serial y explicar cómo la tensorización cambia la organización desde tres aspectos: población, evaluación y estado; la segunda pregunta requiere dar juicios de compensación desde dimensiones como riqueza de candidatos vs rendimiento por lotes, beneficio de exploración vs complejidad de ingeniería, rendimiento por lotes vs fidelidad de evaluación.

Las respuestas correctas deben poder conectar con los conceptos de esta página y explicar la base; si el juicio es incorrecto, volver a la cadena causal "diversidad → número de evaluaciones → costos de gestión de estado y programación", y distinguir entre "acelerar el mismo bucle serial" y "cambiar la forma de organizar el cómputo".

**Verificación de comprensión**

Pida aleatoriamente a un estudiante que resuma los puntos clave de esta página con sus propias palabras, especialmente cómo la diversidad se convierte en carga computacional, por qué el serial alcanza su límite y cómo el paralelismo por lotes tensorizado organiza la población, la evaluación y el estado. Si el estudiante solo puede repetir terminología sin explicar la causalidad, se le puede guiar de vuelta a la comparación de pendientes en el gráfico y a la marca "cuello de botella serial: rendimiento en su límite".

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden expresar la relación central de esta página — la diversidad genera carga computacional, la ejecución serial alcanza su límite, el paralelismo por lotes tensorizado absorbe la escala mediante cómputo integral — pasar a los ejemplos, aplicaciones o resumen de la página siguiente.

<a id="lecture-page-3"></a>

### Desafíos de diversidad evolutiva y escala computacional

*Página 3*

> **Objetivo de la página:** Los estudiantes deben comprender la presión computacional que generan las compensaciones multiobjetivo y la diversidad de candidatos en problemas reales.

> **Objetivo de la página**
>
> Comprender la presión computacional que generan las compensaciones multiobjetivo y la diversidad de candidatos, dominar el frente de Pareto, las relaciones de dominancia y la tensión entre mantener la diversidad y el costo de evaluación.

**Puntos clave de enseñanza**

- Solo cuando el problema tiene un único objetivo existe una solución óptima única. Los problemas de ingeniería reales generalmente tienen múltiples objetivos que se contrarrestan mutuamente (sustentación y resistencia, precisión y latencia, rendimiento y costo); en este caso, la "buena respuesta" es un conjunto de soluciones de compromiso mutuamente no dominadas, es decir, el frente de Pareto. Comparar elemento por elemento si A no es peor que B en todos los objetivos → si A es estrictamente mejor en al menos un objetivo → ambas condiciones deben cumplirse para que A domine a B. Si A es peor en al menos un aspecto, ambos son mutuamente no dominados y pueden permanecer en el frente. El eje horizontal f1 y el eje vertical f2 son ambos "cuanto menor, mejor"
- el grupo A se inclina hacia f1 bajo, el grupo B es un compromiso, el grupo C se inclina hacia f2 bajo
- los puntos grises son soluciones dominadas. El decisor necesita el espacio de compensación representado por todo el frente, no un punto único seleccionado por el algoritmo. Se refiere a las diferencias estructuradas distribuidas a lo largo de diferentes direcciones de compensación en el frente de Pareto. Cobertura de direcciones — llenar el extremo superior izquierdo, la sección media y el extremo inferior derecho del frente
- preservación de diferencias — candidatos casi idénticos equivalen a uno solo
- valor de decisión — las preferencias a menudo se aclaran a posteriori; conservar candidatos diferenciados permite reelegir a costo cero. Cuanto mayor la diversidad, más amplio el espacio de búsqueda, mayor el tamaño de la población y más numerosas las evaluaciones. Cuando la evaluación depende de simulaciones de alta fidelidad (como el cálculo aerodinámico de perfiles supercríticos que tarda horas), el costo de una sola evaluación se amplifica hasta convertirse en el cuello de botella principal. Respuestas comunes: modelos sustitutos que reemplazan la mayoría de las evaluaciones de alta fidelidad
- asignar el presupuesto limitado de alta fidelidad prioritariamente a los candidatos que más puedan ampliar la cobertura del frente
- redistribuir el presupuesto entre el tamaño de la población y el número de generaciones. Equiparar la diversidad con ruido aleatorio o simplemente ejecutar más veces. La verdadera diversidad es la diferencia estructurada de direcciones
- la perturbación puramente aleatoria no amplía la cobertura del frente ni reduce la dificultad de decisión. Pistas de ejercicios (5 preguntas de opción múltiple + 1 análisis de caso): El frente de Pareto es un conjunto de soluciones de compromiso mutuamente no dominadas; cualesquiera dos soluciones tienen ventajas y desventajas en diferentes objetivos. A es mejor en f1 y B es mejor en f2, ambos son mutuamente no dominados y pueden permanecer en el frente. La diversidad es la diferencia estructurada distribuida a lo largo de diferentes direcciones de compensación en el frente de Pareto, que sirve directamente a la decisión. Una cobertura más amplia de direcciones de compensación requiere un mayor espacio de búsqueda, tamaño de población y número de evaluaciones objetivo, por lo que cuanto mayor la diversidad, mayor el desafío de escala computacional. Usar modelos sustitutos para asumir la mayor parte de las evaluaciones y concentrar el presupuesto limitado de alta fidelidad en ampliar la cobertura del frente puede aliviar la tensión entre escala y diversidad. Diseño de perfil supercrítico. El entregable debe ser un conjunto de soluciones candidatas ubicadas en el frente de Pareto que cubran diferentes direcciones de compensación, no una solución única
- las medidas para aliviar la tensión incluyen modelos sustitutos, asignación prioritaria de presupuesto, ajuste de la proporción entre población y generaciones, cribado multifidelidad por etapas, etc.

**Verificación de comprensión**

Pida a los estudiantes que expliquen con sus propias palabras las relaciones de dominancia y el frente de Pareto, y que den ejemplos de por qué la diversidad genera presión computacional. Si los estudiantes confunden diversidad con perturbación aleatoria, se puede volver al "truco de autoverificación" — por muchos candidatos que haya, si se apiñan en la misma esquina del frente, sigue sin haber diversidad.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden distinguir entre óptimo puntual y conjunto de soluciones de compromiso, y que comprenden el costo de la diversidad, pasar a la página siguiente sobre evolución paralela tensorizada.

<a id="lecture-page-4"></a>

### Cuello de botella de eficiencia del bucle serial tradicional de CPU

*Página 4*

> **Objetivo de la página:** Los estudiantes deben reconocer las limitaciones de rendimiento del bucle serial tradicional de CPU al procesar decenas de miles de evaluaciones de candidatos.

**Puntos clave de enseñanza**

- Número total de evaluaciones ≈ tamaño de población × número de generaciones; tiempo de evaluación serial ≈ número total de evaluaciones × tiempo por evaluación. Primero calcular estas dos cantidades, luego juzgar si el cuello de botella merece una reingeniería.
- El bucle a nivel de intérprete, las verificaciones de límites y distribución de tipos individuo por individuo, el acceso no contiguo a memoria, y la sincronización y transferencia de datos frecuentes se acumulan como sobrecarga constante del serial. Solo optimizar el operador en sí solo elimina una pequeña parte.
- Graficar el tiempo de reloj bajo diferentes tamaños de población: una línea aproximadamente recta indica que la ejecución sigue siendo serial; una forma escalonada indica que ya está organizada por lotes. La forma de la curva explica mejor la atribución del cuello de botella que un número puntual.

> **Objetivo de la página**
>
> Esta página busca que los estudiantes reconozcan que cuando las evaluaciones de candidatos alcanzan el orden de decenas de miles, el bucle serial tradicional de CPU se convierte en el segmento más estrecho de toda la cadena de evolución; este cuello de botella pertenece al nivel del modelo de ejecución, no a la forma de escribir un operador individual o a defectos del código. El procesamiento por lotes, la tensorización y la programación paralela posteriores son precisamente las direcciones de reingeniería dirigidas a este cuello de botella estructural.
>
> Orden de explicación y puntos clave de enseñanza:
>
> La evolución depende de la diversidad, y la diversidad trae un crecimiento multiplicativo del tamaño de la población y el número de evaluaciones. Número total de evaluaciones ≈ tamaño de población × número de generaciones; tiempo de evaluación serial ≈ número total de evaluaciones × tiempo por evaluación. Cuando el número de evaluaciones alcanza el orden de 10⁵, el tiempo de reloj serial crece de forma aproximadamente lineal.
>
> El gráfico compara el procesamiento serial individuo por individuo con el procesamiento paralelo por lotes. El eje horizontal es el número de evaluaciones de candidatos: 10³, 10⁴, 10⁵; el eje vertical es el tiempo de reloj normalizado. La curva serial crece de forma aproximadamente lineal; la curva paralela crece de forma escalonada. Los segmentos oscuros representan la sobrecarga de programación y transferencia de datos. La conclusión clave es: bajo la misma carga de trabajo, el crecimiento del tiempo paralelo está determinado principalmente por el número de lotes, no por el número de individuos. Usar la forma de la curva explica mejor la atribución del cuello de botella que mirar solo números puntuales.
>
> La implementación más básica trata toda la población como una lista, recorriéndola en bucle para tomar cada individuo → decodificar a parámetros concretos → llamar a la función de evaluación → escribir de vuelta la aptitud. Las iteraciones adyacentes casi no pueden solaparse: si los resultados de evaluación no regresan, la escritura no puede avanzar; si la escritura no se completa, el siguiente individuo no tiene dónde colocar el resultado. Así, las unidades paralelas como múltiples núcleos, SIMD y GPU permanecen inactivas la mayor parte del tiempo.
>
> El número de evaluaciones se infla linealmente; la ejecución individuo por individuo a nivel de intérprete, incluyendo el bucle individuo por individuo, las verificaciones de límites y la distribución de tipos, aporta una sobrecarga constante fija pero elevada; el acceso no contiguo a memoria y la transferencia de datos, los individuos tomados uno por uno a menudo no son contiguos en memoria, con baja tasa de aciertos de caché; la sincronización y programación, para obtener el siguiente individuo, el flujo de ejecución se detiene y reanuda repetidamente. Solo optimizar el interior del operador solo elimina una pequeña parte.
>
> Tomando como ejemplo una población de 1000 y 100 generaciones, el número total de evaluaciones es aproximadamente 1000 × 100 = 10⁵. Si cada evaluación tarda en promedio 1 ms, solo la etapa de evaluación en serie requiere aproximadamente 100 segundos, sin contar aún el cómputo de operadores y la sobrecarga de programación; si para mantener la diversidad se aumenta el número de reinicios de 1 a 5, el costo asciende de forma aproximadamente lineal a unos 500 segundos. Bajo la misma carga de trabajo, si se organiza por lotes y se procesa en hardware paralelo, el tiempo de reloj está determinado principalmente por el número de lotes y el tiempo por lote.
>
> Cuando una sola evaluación es extremadamente barata (nivel de microsegundos) o la población es muy pequeña (por debajo de cientos), la sobrecarga de programación y memoria puede superar la sobrecarga de cómputo, la diferencia entre serial y paralelo se reduce notablemente, el beneficio marginal de la tensorización disminuye y el cuello de botella se traslada a la granularidad de programación y el ancho de banda de memoria. Por lo tanto, si vale la pena rediseñar el modelo de ejecución debe evaluarse conjuntamente con el costo de evaluación y la escala.
>
> El cuello de botella de eficiencia del bucle serial de CPU es estructural. Para resolverlo realmente, se necesita reconstruir el procesamiento individuo por individuo en procesamiento por lotes, es decir, procesamiento por lotes, tensorización y programación paralela, lo que constituye la motivación directa para el diseño del grafo computacional tensorizado posterior.

**Cobertura de palabras clave**

- Bucle serial de CPU, paralelismo por lotes, tiempo de reloj, número de evaluaciones de candidatos, número de lotes, sobrecarga a nivel de intérprete, acceso no contiguo a memoria, sincronización y programación, cuello de botella estructural, tensorización.

**Manejo de ejercicios**

Esta página tiene 5 preguntas de opción múltiple. Se sugiere que en cada pregunta primero se pida a los estudiantes que expresen la base de su juicio y luego se dé retroalimentación.

La pregunta 1 pregunta cuál es la limitación más importante del modelo de ejecución del bucle serial. La respuesta es "las iteraciones adyacentes difícilmente se solapan, y las unidades paralelas como múltiples núcleos, SIMD y GPU permanecen inactivas la mayor parte del tiempo". Punto clave de retroalimentación: el flujo de ejecución individuo por individuo — tomar individuo → decodificar → evaluar → escribir de vuelta — hace que cada individuo sea un paso serial independiente, y el hardware carece de trabajo independiente ejecutable simultáneamente; el cuello de botella no es que no se pueda calcular la aptitud, sino que en un mismo instante solo se está procesando un individuo.

La pregunta 2 pregunta el tiempo de reloj serial solo de la etapa de evaluación cuando la población es 1000, las generaciones son 100 y cada evaluación tarda 1 ms. La respuesta es aproximadamente 100 segundos. Guía de cálculo: número total de evaluaciones ≈ 1000 × 100 = 10⁵, luego multiplicar por 1 ms.

La pregunta 3 pregunta cuál elemento NO amplifica la sobrecarga constante del bucle serial. La respuesta es "programación de procesamiento por lotes tensorizado". Punto clave de retroalimentación: el procesamiento por lotes tensorizado es una dirección de reingeniería para aliviar el cuello de botella, no una fuente de amplificación de sobrecarga del propio bucle serial; la sobrecarga serial proviene del acceso no contiguo a memoria, las verificaciones de límites y distribución de tipos individuo por individuo, el bucle a nivel de intérprete, etc.

La pregunta 4 pregunta de qué depende principalmente el tiempo de reloj al completar la misma carga de trabajo total bajo paralelismo por lotes. La respuesta es "el número de lotes y el tiempo por lote". Punto clave de retroalimentación: el procesamiento por lotes convierte el individuo por individuo en lote por lote; el tiempo de reloj crece de forma escalonada con el número de lotes, y ya no crece de forma aproximadamente lineal con el número de individuos.

La pregunta 5 pregunta en qué situación es más probable que NO se cumpla el juicio de que el bucle serial es un cuello de botella estructural. La respuesta es "cuando el tiempo por evaluación se reduce a microsegundos y el tamaño de la población es solo de cientos". Punto clave de retroalimentación: en este caso la sobrecarga de programación y memoria puede superar la sobrecarga de cómputo, la diferencia entre serial y paralelo se reduce; juzgar el cuello de botella requiere evaluar conjuntamente el costo de evaluación y la escala.

**Actividad en clase**

Se puede usar el caso de esta página "Selección del modelo de ejecución bajo cien mil evaluaciones". Primero pedir a los estudiantes que estimen, luego discutir los límites de la reingeniería.

Estimar el tiempo de reloj actual solo de la etapa de evaluación en la implementación serial, y explicar el cambio al aumentar el número de reinicios de 1 a 5, juzgando así la prioridad de optimización. Respuesta de referencia: 1000 × 100 = 10⁵ evaluaciones, multiplicado por 1 ms es aproximadamente 100 segundos; con 5 reinicios serían aproximadamente 5 × 10⁵ evaluaciones, es decir, unos 500 segundos, y el tiempo de reloj se infla de forma aproximadamente lineal. Esto indica que los ajustes constantes dentro del operador tienen un beneficio limitado; la prioridad de optimización debe estar en el nivel del modelo de ejecución, es decir, procesamiento por lotes, tensorización y programación paralela, haciendo que el tiempo de reloj dependa del número de lotes y no del número de individuos.

Si se cambia a un modelo de ejecución paralelo por lotes, ¿qué condiciones límite adicionales deben considerarse para juzgar si vale la pena la reingeniería? Respuesta de referencia: primero, el costo de evaluación y la escala; si el tiempo por evaluación baja a microsegundos, o la población se reduce por debajo de cientos, la sobrecarga de programación y transferencia de memoria puede superar la de cómputo, y el beneficio paralelo disminuye; segundo, las restricciones del número de lotes y el tamaño de lote; el tamaño de lote está limitado por la memoria de video, el ancho de banda de memoria y el tiempo de cómputo por lote; un lote demasiado grande eleva el tiempo por lote y el costo de sincronización; tercero, el diseño de datos y acceso a memoria; si los individuos candidatos no pueden organizarse en tensores contiguos y vectorizables, el procesamiento por lotes se verá penalizado por el acceso no contiguo. En conjunto, solo cuando tanto el número de evaluaciones como el costo por evaluación son suficientemente grandes, el beneficio de rediseñar el modelo de ejecución es significativo.

**Verificación de comprensión**

Pida aleatoriamente a un estudiante que resuma los puntos clave de esta página con sus propias palabras, por ejemplo "por qué el bucle serial es un cuello de botella estructural" y "de qué depende el tiempo de reloj tras la paralelización". Si el estudiante solo dice "es lento", preguntar por las dos dimensiones: orden de magnitud y número de lotes. Se puede agregar un truco de cálculo rápido: número total de evaluaciones ≈ tamaño de población × número de generaciones; tiempo de evaluación serial ≈ número total de evaluaciones × tiempo por evaluación. Recordar no fijarse solo en el interior del operador, y usar la forma de la curva para autoverificar: aproximadamente recta indica que la ejecución sigue siendo serial; escalonada indica que ya está organizada por lotes.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden expresar "el serial es un cuello de botella del modelo de ejecución, y tras la organización por lotes paralela el tiempo de reloj está determinado por el número de lotes", pasar al contenido posterior sobre el diseño del grafo computacional tensorizado y la programación paralela.

**Base documental**

La evolución depende de la diversidad, y la diversidad implica una enorme carga computacional. El bucle serial tradicional de CPU es ineficiente al procesar decenas de miles de evaluaciones de candidatos.

<a id="lecture-page-5"></a>

### De la lista de candidatos al grafo computacional tensorizado

*Página 5*

> **Objetivo de la página:** Los estudiantes deben dominar la transformación central de convertir el proceso evolutivo de una representación en lista a un grafo computacional tensorizado.

> **Objetivo de la página**
>
> Los estudiantes deben dominar la transformación central de convertir el proceso evolutivo de una representación en lista a un grafo computacional tensorizado, y poder explicar por qué la evolución necesita computación tensorial por lotes, y cómo la tensorización cambia la forma de expresar el proceso evolutivo.

**Puntos clave de enseñanza**

- La evolución depende de la diversidad y necesita evaluar decenas de miles o incluso millones de soluciones candidatas. Si los candidatos se escriben como arreglos de objetos ordinarios y se evalúan con bucles elemento por elemento, la mayor parte del tiempo se consumirá en la programación elemento por elemento y el flujo de control del lenguaje anfitrión, en lugar de en operaciones numéricas reales. Aquí está la causa raíz de la ineficiencia del bucle serial tradicional de CPU. El conjunto de candidatos, los resultados de evaluación y el estado del algoritmo se organizan de forma unificada como tensores. Toda una generación de candidatos se escribe como un tensor de candidatos de forma [tamaño de población, dimensión de solución]
- un candidato ya no es un objeto independiente, sino un segmento o una fila dentro del tensor. El diagrama de la página también se desarrolla en este orden: a la izquierda la lista de candidatos procesada elemento por elemento, en el medio el tensor de candidatos, a la derecha en el grafo computacional sucesivamente mutación, evaluación, selección, actualización de estado. Operaciones como la mutación actúan directamente sobre toda la población, y una sola llamada completa la actualización de todos los candidatos
- la evaluación se escribe como evaluate(tensor de candidatos), obteniendo en una sola vez los resultados de toda la generación; la unidad de evaluación pasa de "individuo" a "lote". La selección y la actualización de estado ya no son solo lógica de control serial, sino nodos en el grafo, obteniendo así oportunidades de optimización de compilación como fusión de operadores y programación paralela. La lógica del algoritmo, como la distribución de mutación y la presión de selección, no ha sido reescrita
- lo que se ha reescrito es la forma de expresión. No se trata simplemente de mover el bucle a un dispositivo más rápido, sino de organizar datos y operadores tomando el tensor como unidad mínima de procesamiento. Si se insiste en "un candidato equivale a un objeto independiente", por muy amplio que sea el hardware paralelo, solo se le podrán alimentar datos de forma serial. La transición clave de esta página puede resumirse como "de la lista de candidatos al grafo computacional tensorizado"
- al ver operadores por lotes, pensar "calcular toda la población junta".

**Cobertura de palabras clave**

- Computación tensorizada, tensor de candidatos, operadores por lotes, evaluación por lotes, grafo computacional, optimización de compilación, tamaño de población, dimensión de solución.

**Manejo de ejercicios**

La respuesta a la pregunta de opción múltiple 1 debe apuntar a la sobrecarga fija de la programación elemento por elemento y el flujo de control del lenguaje anfitrión, no a la falta de potencia de cómputo o de diversidad. Al retroalimentar, enfatizar que cuantos más candidatos, mayor es la proporción de esta sobrecarga.

Una solución candidata corresponde a un segmento del tensor de candidatos, por ejemplo una fila; ya no está vinculada como un objeto independiente del lenguaje anfitrión.

La selección y la actualización de estado, al entrar en el grafo computacional, pueden obtener oportunidades de optimización de compilación como fusión de operadores y programación paralela, reduciendo tensores intermedios y sobrecarga de sincronización.

La salida de evaluación más probable es [tamaño de población] o [tamaño de población, número de objetivos]; la evaluación produce uno o un conjunto de indicadores para cada candidato a lo largo de la dimensión de población.

EvoX, a nivel de expresión, cambia el procesamiento en lista candidato por candidato por un grafo computacional por lotes que trata el tensor como ciudadano de primera clase.

Búsqueda de 50000 perfiles de ala candidatos. El cuello de botella de la implementación original está principalmente en la capa de organización de datos y programación: acceso a objetos candidato por candidato, llamadas a funciones elemento por elemento, comparaciones una a una y actualización manual de estado, y el procesamiento de solo un candidato a la vez, sin poder llenar el ancho de paralelismo del hardware. La reingeniería tensorizada no cambia la presión de selección ni la distribución de mutación, sino que unifica candidatos, resultados de evaluación y estado del algoritmo como tensores, haciendo que la mutación y la evaluación actúen sobre toda la población de una vez. Si se desea que la selección y la actualización de estado también obtengan optimización de compilación, se debe configurar el tensor de candidatos como [50000, 48]; la salida de evaluación como [50000] o [50000, número de objetivos]; la mutación actúa sobre todo el tensor de candidatos; la selección usa indexación o máscaras tensoriales;

la actualización de estado se escribe como un nodo de reducción a lo largo de la dimensión de población, como tomar el mínimo o calcular el promedio.

**Verificación de comprensión**

¿Cuál es la forma del tensor de candidatos? ¿Cuál es la forma de la salida de una evaluación? ¿Qué dos etapas pasaron de ser lógica de control serial a nodos del grafo computacional? Si se responden los tres puntos, significa que se ha dominado la transición central de esta página.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden explicar con sus propias palabras el cambio "de la lista de candidatos al grafo computacional tensorizado", pasar a la aplicación, ejemplo o resumen de la página siguiente.

<a id="lecture-page-6"></a>

### Organización tensorizada de población, evaluación y estado

*Página 6*

> **Objetivo de la página:** Los estudiantes deben comprender cómo mapear de forma unificada los datos de población, la evaluación de aptitud y las variables de estado en estructuras tensoriales.

> **Objetivo de la página**
>
> Comprender cómo mapear de forma unificada los datos de población, la evaluación de aptitud y el estado de ejecución del algoritmo en estructuras tensoriales, formando un contrato de datos unificado que permite computación por lotes, residencia en dispositivo y reproducibilidad.

> **Orden de explicación**
>
> Comenzar con tres preguntas — qué es la población, cómo se evalúa, en qué paso va la ejecución; luego corresponder con tres tipos de contenedores — tensor de población [N, D], matrices de evaluación y restricciones [N, M] y [N, K], y contenedor de estado unificado; finalmente explicar cómo la evaluación por lotes y la residencia de estado convierten el bucle individuo por individuo en operaciones por lote completo.

**Puntos clave de enseñanza**

- Organizar N soluciones candidatas como un tensor de codificación [N, D]. N es la dimensión de lote, D es la dimensión de características; generalmente se coloca N en la capa más externa para que un mismo operador pueda actuar sobre todo el lote de una vez. Si un individuo se compone de múltiples segmentos de parámetros, se puede dividir en bloques de campos como [N, D1] + [N, D2] + …
- los individuos de longitud variable se manejan con relleno más máscara o agrupación por cubos, evitando que estructuras heterogéneas rompan el cálculo por lote completo. Una evaluación por lotes produce una matriz de aptitud [N, M]
- los multiobjetivo, multirestricción e indicadores adicionales pueden colocarse en paralelo como [N, M+K] o almacenarse en tablas separadas; la clave es evitar llamar a la función de evaluación en bucle individuo por individuo. La generación, el estado del generador de números aleatorios, los hiperparámetros de estrategia, la mejor solución, la caché histórica, el ranking o el estado de muestreo también entran en tensores o contenedores de estado estructurados, garantizando reproducibilidad, trazabilidad y actualización por lotes. Los tensores unificados reducen los viajes entre host y dispositivo, disminuyen la sobrecarga de bucles y proporcionan la base de datos para la paralelización posterior de operadores
- pero hay que prestar atención a la validez de las máscaras, el desperdicio por relleno, el ensanchamiento de la matriz de evaluación por el aumento del número de objetivos, y el costo de sincronización de estado.

> **Pistas de materiales**
>
> - El diagrama de diseño de memoria coloca el tensor de población, la matriz de evaluación, la matriz de restricciones y el contenedor de estado unificado bajo la misma semántica de memoria de dispositivo. Se puede recordar a los estudiantes que presten atención a que la flecha de "evaluación por lotes" indica que una sola llamada procesa todo el lote, en lugar de llamar individuo por individuo. Cuando N=1024, D=50, M=2, la población es [1024, 50], los valores de evaluación son [1024, 2], las restricciones son [1024, K]. generation puede almacenarse como escalar, best_x puede almacenarse como un tensor unidimensional [D], rng_state puede representarse como un tensor de enteros de longitud adecuada. Cada actualización generacional puede completarse íntegramente en la misma dimensión de lote.

**Manejo de ejercicios**

La comprensión central es "población, evaluación y estado mapeados de forma unificada en estructuras tensoriales". Si se elige correctamente, significa que esta comprensión es consistente con la línea principal de esta página; si se elige incorrectamente, volver al inicio de la página para repasar el contrato de datos unificado.

Una afirmación razonable debe enfatizar que la evaluación por lotes genera [N, M] y [N, K], en lugar de un bucle individuo por individuo. Al juzgar, basta con poder conectar con las formas matriciales y la base de la evaluación por lotes.

Una afirmación razonable debe explicar que la generación, el estado del generador aleatorio, la mejor solución, etc., también se incorporan al contenedor de estado unificado, facilitando puntos de control y reproducibilidad. Si la respuesta se queda solo en "poner los datos en tensores", recordar que también hay que prestar atención a la gestión de estado y la reproducibilidad.

Para el escenario N=2048, D=100, M=3, K=5, se sugiere población [2048, 100], evaluación [2048, 3], restricciones [2048, 5]; variables de estado como generation en tensor escalar, best_x en [100], rng_state en tensor de enteros, caché histórica en [T, 2048, 100] o almacenamiento comprimido. En la evaluación por lotes, vectorizar la función de evaluación para que acepte [N, D] y devuelva [N, M] y [N, K]; los individuos de longitud variable usan relleno más máscara o agrupación por cubos, ignorando las partes inválidas según la máscara tras el cálculo.

**Verificación de comprensión**

Pida a un estudiante que explique en una frase por qué N debe ser la dimensión de lote más externa, y que mencione al menos una variable de estado y por qué debe tensorizarse. Si la respuesta se queda en "poner los datos en tensores", complementar: la clave es el contrato de datos unificado y la ejecución de operadores por lote completo.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden distinguir los cuatro tipos de contenedores: población, evaluación, restricciones y estado, pasar a los ejemplos, aplicaciones o resumen de la página siguiente.

<a id="lecture-page-7"></a>

### Paralelismo de operadores y optimización de compilación

*Página 7*

> **Objetivo de la página:** Los estudiantes deben comprender el mecanismo de optimización de compilación subyacente cuando operaciones como mutación y cruce actúan sobre toda la población.

> **Objetivo de la página**
>
> Comprender que en la base computacional moderna de EvoX, la unidad mínima de ejecución de los operadores evolutivos pasa de "individuo" a "tensor de población"; dominar cómo los operadores tensorizados y la compilación de grafos computacionales mejoran el rendimiento de la evolución por lotes, manteniendo inalterada la semántica del algoritmo.

> **Orden de explicación**
>
> Primero establecer el juicio de "¿sobre quién actúa el operador?", luego comparar las diferencias de ejecución entre el bucle individuo por individuo y los operadores a nivel de tensor, después explicar cómo la compilación de grafos computacionales optimiza desde la secuencia de operadores hasta el plan de ejecución, y finalmente consolidar con casos y ejercicios el principio de "la eficiencia cambia, la semántica no".

**Puntos clave de enseñanza**

- 1. La forma del tensor de población es [N, D], donde N es el tamaño de la población y D es la dimensión de las variables de decisión. Operadores como mutación, cruce y selección pueden actuar directamente sobre todo el tensor de población, y una sola llamada cubre los N individuos
- la dimensión de individuo actúa como dimensión de lote, el dispositivo puede ejecutar en paralelo a gran escala, y el rendimiento se amplifica con el tamaño de la población. 2. La escritura individuo por individuo como for ind in population: ind = mutate(ind) divide cada operador en N llamadas pequeñas, trayendo frecuente programación del framework y lanzamiento de kernels
- cada lote es solo de 1, las unidades paralelas del dispositivo difícilmente se llenan, y la creación y liberación repetida de resultados intermedios también aumenta la asignación de memoria de video y la sobrecarga de transferencia de datos. La clave de la reingeniería es population = mutate(population_tensor), haciendo que el operador se ejecute tomando el tensor de población como unidad. 3. La compilación de grafos computacionales organiza "mutación → cruce → selección" en un grafo computacional, realizando optimización global sobre todo el grafo: la fusión de operadores puede combinar múltiples operaciones elemento por elemento en menos kernels, reduciendo tensores intermedios y lecturas/escrituras
- la generación y programación de kernels completa la evolución de toda una generación con menos lanzamientos de kernels
- la reutilización de memoria preplanifica buffers para resultados intermedios, reduciendo costos de asignación y transferencia. La optimización solo cambia "cómo se calcula", no "qué se calcula". El número de kernels, la escala de tensores intermedios y la estrategia de memoria y programación pueden cambiar, pero el significado lógico de mutación, cruce y selección, el orden de composición de operadores y la forma de uso de números aleatorios deben mantenerse consistentes
- bajo la misma semilla aleatoria, las trayectorias generacionales y los resultados antes y después de la optimización deben ser consistentes. Confundir la tensorización con haber cambiado el algoritmo evolutivo, o creer que la optimización de compilación hará al algoritmo "más inteligente". La tensorización solo aplica el mismo operador a todo el tensor de población
- la optimización de compilación también actúa solo en la capa de ejecución. Si tras la optimización no se realiza verificación de regresión, es fácil confundir diferencias de implementación con mejoras del algoritmo.

> **Pistas de materiales**
>
> - En el diagrama, a la izquierda está el tensor de población [N, D] con todos los individuos, en el medio el grafo computacional de operadores evolutivos "mutación → cruce → selección", y a la derecha se compara antes de la compilación "bucle individuo por individuo, múltiples lanzamientos de kernel, dimensión de lote igual a 1" y después de la compilación "grafo computacional fusionado, pocos kernels GPU eficientes, una sola pasada por lotes completa la evolución de toda una generación". Este flujo puede ayudar a los estudiantes a conectar la tensorización con la optimización de compilación.

**Manejo de ejercicios**

Los ejercicios de esta página giran en torno a la granularidad de ejecución y la preservación de la semántica.

El operador de mutación en una sola llamada generalmente actúa sobre todo el tensor de población [N, D]; no es un vector de valores de la función objetivo, ni el vector de decisión de un solo individuo.

El bucle Python/CPU individuo por individuo es lento porque una gran cantidad de llamadas de pequeña escala genera sobrecarga de programación y framework, y la dimensión de lote es 1, con baja utilización del dispositivo.

El beneficio principal de la fusión de operadores es combinar múltiples operaciones elemento por elemento en menos kernels, reduciendo tensores intermedios y lanzamientos de kernel; no cambia la distribución de probabilidad ni el significado del operador.

Solo cambia la forma de ejecución, no el significado lógico ni el orden de composición de mutación, cruce y selección.

La reingeniería de population[i] = mutate(ind) debe cambiarse a population = mutate(population_tensor), y entregar la secuencia de operadores a la optimización de compilación de grafos computacionales; reducir N, cambiar la sintaxis del bucle o usar solo múltiples hilos de CPU no resuelve el problema de la granularidad de ejecución.

Tomando como ejemplo una estrategia evolutiva con tamaño de población N = 4096 y dimensión D = 128, la implementación inicial tiene una utilización del dispositivo inferior al 30%, el tiempo por generación crece de forma aproximadamente lineal con N, y el uso de memoria de video es elevado. El diagnóstico debe centrarse en la granularidad de ejecución: el bucle individuo por individuo amplifica la sobrecarga fija N veces, la dimensión de lote degenera a 1, las unidades paralelas no se llenan, y los resultados intermedios se crean y liberan repetidamente. La reingeniería se divide en tres pasos: primer paso, tensorizar los operadores, haciendo que mutación, cruce y selección actúen directamente sobre el tensor [N, D]; segundo paso, habilitar la compilación de grafos computacionales para fusión de operadores, generación de kernels, reutilización de memoria y optimización de programación; tercer paso, fijar la semilla aleatoria para verificación de regresión, comparando las curvas de mejor aptitud por generación y las estadísticas de población antes y después de la optimización.

Si las curvas coinciden básicamente, significa que solo cambió la forma de ejecución; si divergen, primero verificar si se cambió el orden de operadores, el número de usos de números aleatorios o las reglas de selección.

**Verificación de comprensión**

¿Un operador evolutivo debe actuar sobre un solo individuo o sobre todo el tensor de población? ¿Cuál es la cadena de equivalencia de la fusión de operadores hasta la utilización del dispositivo? ¿Cómo verificar que la optimización no ha cambiado la semántica del algoritmo? Respuesta esperada: actúa sobre el tensor de población [N, D]; cuanta más fusión, menos lanzamientos de kernel, menos lecturas/escrituras de tensores intermedios, mayor utilización del dispositivo; usar la misma semilla aleatoria para comparar las curvas de mejor aptitud por generación y las estadísticas de población antes y después de la optimización.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden distinguir entre tensorización y compilación de grafos computacionales, y que pueden verificar la invariancia semántica con regresión de misma semilla, pasar a los ejemplos, aplicaciones o resumen de la página siguiente.

<a id="lecture-page-8"></a>

### Diseño arquitectónico de base abierta y desacoplada

*Página 8*

> **Objetivo de la página:** Los estudiantes deben comprender los principios de diseño desacoplado y la división de componentes centrales de la arquitectura base de EvoX.

> **Objetivo de la página**
>
> Comprender los principios de diseño de la base abierta y desacoplada de EvoX y la división de responsabilidades de los cinco módulos centrales, pudiendo usar "límites de módulo" para juzgar dónde ubicar un requisito.

> **Orden de explicación**
>
> Primero dar el juicio central — los investigadores no deben gastar tiempo en comunicación paralela, asignación de dispositivos y tolerancia a fallos distribuida; luego presentar los cinco módulos de primer nivel, y finalmente usar el diagrama de arquitectura para explicar la relación jerárquica entre la lógica evolutiva superior y la programación unificada inferior.

**Puntos clave de enseñanza**

- El módulo de algoritmo define "cómo evolucionar"
- el módulo de problema proporciona una interfaz de evaluación unificada
- el flujo de trabajo organiza la evolución por etapas
- el módulo de monitoreo observa el proceso evolutivo
- el planificador Runtime actúa como capa de ejecución unificada, respondiendo "dónde calcular, cómo calcular de forma eficiente". Se puede memorizar como: "la lógica evolutiva arriba, la programación de cómputo abajo", en el orden: algoritmo → módulo de problema → flujo de trabajo → módulo de monitoreo → planificador Runtime. El módulo de algoritmo solo describe la lógica de búsqueda como selección, cruce, mutación y actualización; no se vincula a un problema específico ni percibe en qué tarjeta está el tensor
- el módulo de problema encapsula la simulación, la función objetivo o el entorno en una interfaz de evaluación unificada
- el flujo de trabajo determina el orden de las etapas de inicialización, evolución iterativa y juicio de convergencia
- el módulo de monitoreo recopila métricas, registra el estado de la población y las curvas de convergencia
- el planificador Runtime oculta las diferencias entre GPU, dispositivos aceleradores y clústeres distribuidos, y se encarga de los detalles de computación por lotes, paralelismo y comunicación. Algoritmo y problema son mutuamente independientes, y problema y cómputo son mutuamente independientes. Al agregar un nuevo operador de mutación, solo se necesita modificar el módulo de algoritmo
- el módulo de problema sigue proporcionando la interfaz de evaluación unificada, el flujo de trabajo y el módulo de monitoreo mantienen su forma de organización original, y el planificador Runtime completa automáticamente la computación tensorial por lotes y la asignación de dispositivos, sin necesidad de modificar el código de ejecución subyacente. Por lo tanto, la misma base puede soportar escenarios como aprendizaje por refuerzo, programación genética y optimización combinatoria, evitando la construcción repetida de infraestructura de ingeniería paralela, de programación y distribuida. Desacoplamiento no significa que el rendimiento necesariamente empeore. Lo que realmente afecta el rendimiento es la forma en que el planificador Runtime maneja la computación por lotes y la utilización del dispositivo, no el número de módulos. Para juzgar si la estratificación es eficiente, se deben comparar el tiempo de extremo a extremo, la utilización del dispositivo y la proporción de comunicación
- si la sobrecarga de programación aumenta, se debe optimizar la estrategia de computación por lotes y utilización de dispositivos del planificador Runtime, en lugar de reescribir el código paralelo en el módulo de algoritmo. Usar "¿hay que cambiar?" para verificar el desacoplamiento. Cambiar el hardware o la escala del clúster solo debe modificar el planificador Runtime
- cambiar el problema solo debe modificar el módulo de problema
- cambiar un operador solo debe modificar el módulo de algoritmo. Si un cambio pequeño afecta a más de tres capas, significa que la implementación ya está excesivamente acoplada. El desacoplamiento ahorra ingeniería repetitiva, no tiempo de cómputo; aún se necesitan experimentos de referencia para verificar si la sobrecarga de programación es aceptable.

**Manejo de ejercicios**

El elemento excluido de los cinco módulos centrales (la respuesta es "buscador de hiperparámetros", que pertenece a la configuración experimental o estrategia algorítmica, no es un módulo de primer nivel de la base); la manifestación precisa de alta cohesión y bajo acoplamiento (la respuesta es que la lógica interna del módulo de algoritmo es coherente y no se vincula a un problema específico, y el módulo de problema tampoco percibe el cómputo subyacente); la responsabilidad central del planificador Runtime (la respuesta es ocultar las diferencias entre GPU, dispositivos aceleradores y clústeres distribuidos y programar la ejecución de forma unificada); el alcance de los cambios al agregar un nuevo operador de mutación (la respuesta es que solo se necesita implementar la nueva lógica en el módulo de algoritmo, mientras que problema, flujo de trabajo, monitoreo y planificador Runtime permanecen sin cambios); el significado más directo del acceso abierto unificado (la respuesta es que diversos dominios reutilizan el mismo conjunto de infraestructura de ingeniería).

Al retroalimentar, primero pedir a los estudiantes que vuelvan a los "límites de responsabilidad de los cinco módulos" para buscar evidencia, y luego explicar por qué las otras opciones romperían límites o confundirían responsabilidades.

En la expansión a clúster GPU multinodo, el módulo de algoritmo, el módulo de problema, el flujo de trabajo y el módulo de monitoreo deben permanecer sin cambios, porque sus responsabilidades no tienen relación con la forma del cómputo; lo que necesita modificarse o reconfigurarse es el planificador Runtime. Si se debate entre "escribir a mano la asignación de dispositivos y la comunicación dentro del operador" o "depender completamente del planificador Runtime", la clave de evaluación es en qué capa recae el cambio: la asignación de dispositivos y la comunicación pertenecen a la capa de ejecución; escribirlas dentro del operador acopla los detalles de cómputo al módulo de algoritmo. El plan de verificación es comparar, en el mismo problema de optimización combinatoria, el tiempo de extremo a extremo, la utilización del dispositivo y la proporción de sobrecarga de comunicación entre la programación puramente Runtime y la programación manual, y registrar el costo al migrar a otro tipo de hardware o a una tarea de aprendizaje por refuerzo;

solo cuando un beneficio significativo y reproducible pueda compensar el costo de acoplamiento y migración, se considerará un descenso local.

**Verificación de comprensión**

Pida a los estudiantes que reciten con sus propias palabras los cinco módulos y las preguntas que responde cada uno, y que elijan un requisito para juzgar qué capa debe modificarse. Sugerencia de transición: después de confirmar que los estudiantes pueden distinguir entre "lógica evolutiva" y "programación de cómputo", pasar a los detalles de implementación de la evolución paralela tensorizada posterior.

<a id="lecture-page-9"></a>

### División de módulos de algoritmo y problema

*Página 9*

> **Objetivo de la página:** Los estudiantes deben comprender las responsabilidades y formas de interacción de los módulos de algoritmo y problema en la arquitectura base.

> **Objetivo de la página**
>
> Comprender los límites de responsabilidad, el contrato de interfaz entre el módulo de algoritmo y el módulo de problema en la base abierta y desacoplada de EvoX, y el significado de esta división para problemas multiobjetivo, con restricciones y con retroalimentación costosa.

> **Orden de explicación**
>
> Primero anclar la división con una frase — el módulo de algoritmo responde "cómo buscar", el módulo de problema responde "qué evaluar y cómo el entorno retroalimenta". Luego desarrollar las entradas y salidas de ambos, y finalmente aterrizar en la expansión independiente, composabilidad y migrabilidad que trae la estabilidad del contrato de interfaz.

**Puntos clave de enseñanza**

- 1. El módulo de algoritmo encapsula la estrategia de búsqueda y el mecanismo evolutivo. Se encarga de la generación de soluciones candidatas, la inicialización de la población, la mutación, el cruce, la selección, la preservación de élites, así como el control de búsqueda: número de iteraciones, tamaño de población, reinicio y criterios de convergencia, programación de parámetros de operadores, etc. El punto clave es que solo depende de la premisa abstracta de que "las soluciones candidatas serán evaluadas", y no le importa el significado físico ni la forma concreta de la función objetivo. 2. El módulo de problema define los criterios de evaluación y la retroalimentación del entorno. Transforma las soluciones candidatas en retroalimentación comparable, como valores objetivo, aptitud, violación de restricciones o el resultado de una interacción con el entorno
- también declara la dimensión de las variables, los rangos de valores y las reglas del dominio factible, para que el algoritmo sepa dónde generar soluciones candidatas. El módulo de problema da una evaluación consistente para el mismo lote de soluciones candidatas, permitiendo la comparación transversal entre diferentes individuos, diferentes generaciones e incluso diferentes algoritmos. El módulo de algoritmo envía un lote de soluciones candidatas, el módulo de problema devuelve resultados de evaluación estructurados (vector de objetivos, violación de restricciones e información de diagnóstico opcional), y el módulo de algoritmo actualiza la población y avanza a la siguiente generación con base en ello. Un ciclo "envío—retorno" es una generación de evolución. La dirección correcta es importante: el lado del algoritmo envía las soluciones candidatas a evaluar, el lado del problema devuelve los resultados de evaluación. Expansión independiente — agregar o reemplazar algoritmos no afecta la definición del problema, y modificar o agregar problemas tampoco requiere reescribir el módulo de algoritmo
- composabilidad — el mismo módulo de problema puede conectarse con diferentes algoritmos evolutivos, y el mismo módulo de algoritmo puede cambiarse a diferentes módulos de problema
- migrabilidad — siempre que el contrato sea estable, ambos lados pueden reutilizarse, reemplazarse y migrarse entre tareas. Los problemas de ingeniería reales como el diseño de perfiles supercríticos a menudo tienen simultáneamente múltiples objetivos que se contrarrestan, restricciones anidadas mutuamente y retroalimentación costosa y dispersa. El módulo de problema convierte de forma unificada los múltiples objetivos y restricciones en resultados de evaluación comparables, recurriendo a modelos sustitutos cuando sea necesario para reducir costos
- el módulo de algoritmo, por su parte, mantiene un conjunto de soluciones candidatas diversificadas, apoyando a los expertos en la compensación de preferencias entre sustentación, resistencia y margen de seguridad. Por lo tanto, el contrato no puede limitarse a una única aptitud escalar, sino que debe soportar vectores de objetivos y violaciones de restricciones; de lo contrario, la información multiobjetivo y de restricciones se perderá permanentemente en la interfaz.

**Cobertura de palabras clave**

- Módulo de algoritmo, módulo de problema, lote de soluciones candidatas, resultados de evaluación, vector de objetivos, violación de restricciones, contrato de interfaz, expansión independiente, composabilidad, migrabilidad, modelo sustituto. Escribir la función objetivo, el manejo de restricciones o reglas heurísticas específicas del problema dentro del módulo de algoritmo, o implementar la selección y actualización de población en el módulo de problema, hará que ambos lados se recoplen de nuevo. La pregunta de autoverificación es: "Si solo cambio el modelo físico, ¿solo necesito reemplazar el módulo de problema?" La respuesta debe ser afirmativa. La interfaz debe ser "estrecha pero completa": estrecha significa pocos campos y estables, transmitiendo solo dos tipos de información: el lote de soluciones candidatas y los resultados de evaluación
- completa significa que la información clave no debe estar incompleta; el vector de objetivos, la violación de restricciones, la dimensión de variables y los límites deben conservarse. Devolver solo una única aptitud escalar es el defecto de diseño más difícil de remediar a posteriori.

> **Pistas de ejercicios**
>
> - Las cinco preguntas de opción múltiple verifican respectivamente — quién se encarga de la búsqueda, la responsabilidad central del módulo de problema, la dirección del flujo de datos del contrato, la expansión independiente tras el desacoplamiento, y las consecuencias de una única aptitud escalar. Las respuestas correctas apuntan sucesivamente a: el módulo de algoritmo genera soluciones candidatas y actualiza la población
> - el módulo de problema transforma las soluciones candidatas en valores objetivo, violaciones de restricciones o resultados de interacción con el entorno
> - el módulo de algoritmo produce lotes de soluciones candidatas, el módulo de problema devuelve resultados de evaluación
> - siempre que el contrato no cambie, al reemplazar cualquiera de los dos lados el otro no necesita reescribirse
> - descartar la información de restricciones impide que el algoritmo obtenga retroalimentación de restricciones, y los problemas con restricciones difícilmente pueden manejarse correctamente. Al retroalimentar, si el estudiante acierta, pedirle que explique la base
> - si falla, guiarlo de vuelta a los dos puntos "quién busca, quién evalúa" y "si el contrato está completo" para rejuzgar. Al migrar de la optimización aerodinámica de perfiles al aligeramiento estructural de alas, cambiar el algoritmo evolutivo no requiere reescribir el módulo de problema, porque el módulo de problema solo promete externamente "entrada: lote de soluciones candidatas; salida: resultados de evaluación", sin relación con los mecanismos internos de selección, actualización u ordenación del algoritmo. Al reutilizar el mismo algoritmo para la minimización del peso estructural, el módulo de problema debe devolver al menos tres tipos de información: valores objetivo (peso estructural; si hay indicadores de rigidez, vector de objetivos), violación de restricciones (grado de infracción de las restricciones de rigidez y viabilidad geométrica), y dimensión y rango de valores del espacio de búsqueda. Ninguno puede faltar, porque el algoritmo solo se encarga de la búsqueda; necesita los valores objetivo para juzgar lo bueno y lo malo, necesita la violación de restricciones para distinguir lo factible de lo infactible, y necesita límites consistentes para generar soluciones candidatas legales.

**Actividad en clase**

Pedir a los estudiantes que reciten con anclas mnemotécnicas — módulo de algoritmo = cómo buscar (generación, mutación, cruce, selección, control de iteraciones); módulo de problema = qué evaluar (valores objetivo, violación de restricciones, retroalimentación del entorno). Luego pedir a un estudiante que responda: "Si solo cambio el modelo físico, ¿qué lado debe reemplazarse?"

**Verificación de comprensión**

Pida aleatoriamente a un estudiante que exprese con sus propias palabras el flujo de datos "lote de soluciones candidatas ⇄ resultados de evaluación", y que explique por qué devolver solo una única aptitud escalar rompería el manejo de problemas con restricciones.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden distinguir entre búsqueda y evaluación, y que pueden explicar que el contrato debe ser "estrecho pero completo", pasar a los ejemplos, aplicaciones o resumen de la página siguiente.

<a id="lecture-page-10"></a>

### Gestión de módulos de flujo de trabajo y monitoreo

*Página 10*

> **Objetivo de la página:** Los estudiantes deben comprender el papel de los módulos de control de flujo de trabajo y monitoreo en la gestión del proceso evolutivo.

> **Objetivo de la página**
>
> Al terminar esta página, los estudiantes deben poder distinguir las responsabilidades del módulo de flujo de trabajo y del módulo de monitoreo, y explicar cómo ambos convierten el bucle evolutivo de "caja negra desconocida" en un proceso controlado, observable, determinable, intervenible y reproducible.

> **Orden de explicación**
>
> Primero establecer la división con una frase — el flujo de trabajo responde "en qué orden ejecutar", el monitoreo responde "dónde vamos ahora, qué tal va, hay que actuar". Luego desarrollar el orden, los bucles de retorno y los límites de etapa del flujo de trabajo, después explicar cómo el monitoreo recopila estado, expone métricas e impulsa decisiones. Finalmente cerrar con los tres límites de responsabilidad y el costo de la observabilidad, y usar un ejemplo de evolución tensorizada en GPU para entrelazar toda la lógica.

**Puntos clave de enseñanza**

- 1. El módulo de flujo de trabajo orquesta pasos y dependencias, no la lógica del algoritmo en sí. Define el orden, los bucles de retorno y los límites de etapa de "inicialización → evaluación (por lotes) → selección → mutación/cruce → actualización de estado → juicio de terminación", y conecta el módulo de algoritmo con el módulo de problema mediante una interfaz unificada. La clave de la orquestación está en la granularidad y los límites: tratar "una evaluación por lotes" como una etapa programable de forma integral, en lugar de avanzar individuo por individuo
- los límites de etapa son simultáneamente puntos de muestreo de monitoreo y puntos de cambio de programación. 2. El módulo de monitoreo es la capa de recolección y exposición del estado de ejecución; rastrea continuamente métricas como el tamaño de la población, el número de evaluaciones, la distribución de aptitud, la convergencia y diversidad, el tiempo por generación, la memoria de video y el rendimiento. Pero el propósito de la observación no es registrar, sino decidir: las métricas se usan para activar la terminación, la parada temprana, el reinicio, el cambio de parámetros o estrategia, formando así un ciclo cerrado de "monitoreo → juicio → intervención". 3. La controlabilidad también requiere que el estado sea serializable. El guardado y la restauración de puntos de control permiten que la evolución de larga duración se interrumpa y continúe, que los fallos se localicen y que los experimentos sean reproducibles. Además, el desacoplamiento requiere que el monitoreo se monte mediante callbacks o hooks, sin invadir los módulos de algoritmo y problema, de modo que diferentes backends de monitoreo como consola, logs y paneles de curvas puedan intercambiarse sin modificar el algoritmo central. El flujo de trabajo gestiona "orden y etapas", el monitoreo gestiona "estado y métricas", y el planificador de ejecución gestiona "recursos y mapeo paralelo". Un error común es meter el mapeo de recursos o la lógica del algoritmo en el flujo de trabajo, o meter el control de orden en el monitoreo, causando acoplamiento e irreproducibilidad. La observabilidad también tiene un costo: el muestreo de alta frecuencia y la retransmisión sincrónica pueden interrumpir la línea de paralelismo, por lo que la frecuencia de muestreo, la forma de agregación de métricas y la estrategia de escritura asíncrona a disco deben equilibrarse según el propósito del experimento. El flujo de trabajo programa "evaluación por lotes" como una etapa integral
- el módulo de monitoreo registra por generación la mejor aptitud y la aptitud promedio, la diversidad de la población y el tiempo por generación
- cuando el indicador se estanca durante N generaciones consecutivas, se activa el juicio de terminación o se cambia a una estrategia con mayor perturbación, y se guarda sincrónicamente un punto de control, haciendo que esa evolución sea reproducible y pueda continuar desde el punto de interrupción.

**Cobertura de palabras clave**

- Módulo de flujo de trabajo, módulo de monitoreo, pasos y dependencias, límites de etapa, bucles de retorno, evaluación por lotes, observabilidad, monitoreo→juicio→intervención, puntos de control, callbacks/hooks, límites de responsabilidad, costo de muestreo.

> **Pistas de ejercicios**
>
> - Los ejercicios de esta página giran en torno a cinco juicios. El objeto directo de orquestación del flujo de trabajo son pasos y dependencias, no fórmulas de operadores, mapeo de memoria de video o codificación de funciones objetivo
> - tratar la evaluación por lotes como una etapa integral se debe a que la granularidad y los límites son más adecuados; los límites de etapa asumen simultáneamente el muestreo de monitoreo y el cambio de programación
> - el propósito fundamental del monitoreo es la decisión, no el archivo a posteriori
> - el montaje mediante callbacks o hooks es para el desacoplamiento, permitiendo que los backends de monitoreo se intercambien
> - la observabilidad requiere equilibrar la frecuencia de muestreo, la agregación de métricas y la estrategia de escritura a disco, porque el muestreo de alta frecuencia puede interferir con la línea de paralelismo. Al acertar, enfatizar que la base proviene de las dos líneas "orden y etapas" y "monitoreo→juicio→intervención"
> - al fallar, volver a los límites de responsabilidad, distinguiendo las cuatro categorías: lógica del algoritmo, mapeo de recursos, control de orden y recolección de estado.

**Verificación de comprensión**

Se puede usar el caso de "pausa sospechosa en evolución tensorizada de larga duración" para verificar el dominio. Primero usar los límites de etapa para desglosar el tiempo de evaluación por lotes, selección, mutación y actualización de estado, y juzgar de qué etapa proviene el aumento del tiempo por generación; luego superponer las curvas de estancamiento de la aptitud promedio y descenso de la diversidad para juzgar si es una convergencia estabilizándose o una trampa en un óptimo local. El plan de acción se organiza según "monitoreo → juicio → intervención": la capa de monitoreo recopila el número de generaciones con estancamiento de aptitud, la diversidad y el tiempo por generación; la capa de juicio establece "N generaciones consecutivas con mejora por debajo del umbral y diversidad por debajo del límite inferior" como estancamiento, y "tiempo por generación por encima del umbral" como anomalía de recursos; la capa de intervención activa el cambio de estrategia, la parada temprana o el reinicio, y ajusta el tamaño de lote o el mapeo paralelo para la anomalía de tiempo.

Antes de actuar, guardar primero un punto de control para garantizar la reproducibilidad del experimento, la localización de fallos y la posibilidad de interrumpir y continuar la evolución de larga duración.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden expresar "el flujo de trabajo gestiona orden y etapas, el monitoreo gestiona estado y métricas, el planificador gestiona recursos y mapeo paralelo", pasar a la página siguiente.

<a id="lecture-page-11"></a>

### Planificador Runtime y gestión de cómputo heterogéneo

*Página 11*

> **Objetivo de la página:** Los estudiantes deben dominar el papel central del planificador Runtime en la asignación de hardware heterogéneo y la composabilidad algorítmica.

> **Objetivo de la página**
>
> Dominar la posición del planificador Runtime en EvoX — es el centro de ejecución que conecta la lógica del algoritmo con el hardware físico, encargándose de mapear el algoritmo evolutivo superior, la definición del problema y el flujo de trabajo a recursos de cómputo heterogéneos como GPU, dispositivos aceleradores (TPU/NPU) y clústeres distribuidos, y manteniendo la alta composabilidad del módulo de algoritmo mientras oculta las diferencias de hardware.

> **Orden de explicación**
>
> 1. Primero distinguir la capa de algoritmo de la capa de ejecución. La capa de algoritmo se centra en "qué hacer", el Runtime en "dónde hacerlo y cómo hacerlo". Esta separación es la clave para entender la arquitectura de EvoX.
>
> Programación de cómputo heterogéneo, gestionando de forma unificada GPU, dispositivos aceleradores y clústeres distribuidos, asignando tareas, operadores y grafos computacionales tensoriales al backend adecuado; coordinación de dependencias y estado, garantizando la sincronización correcta de las relaciones de dependencia entre tareas y el estado de ejecución; interfaz de programación unificada, de modo que la capa de algoritmo no necesite vincularse a un dispositivo o forma de clúster específico al enviar tareas; composabilidad de módulos, soportando la combinación, reemplazo y reutilización modular de algoritmos, problemas, operadores y backends de ejecución.
>
> Al cambiar el mismo conjunto de algoritmos evolutivos de una GPU de un solo equipo a un clúster multimáquina, el código de la capa de algoritmo permanece sin cambios, y el Runtime remapea las tareas de cómputo y los backends de ejecución. Los investigadores pueden así centrarse en la innovación algorítmica sin reescribir código para cada tipo de hardware.
>
> La capa superior es la capa de algoritmo y flujo de trabajo (módulo de algoritmo, definición del problema, flujo de trabajo), en el medio está el planificador Runtime y la interfaz de programación unificada, y la capa inferior es la capa de cómputo heterogéneo (GPU, TPU/NPU, clústeres distribuidos); hacia abajo se transmiten tareas, operadores y grafos computacionales, hacia arriba se devuelven estados y resultados.

**Puntos clave de enseñanza**

- El Runtime no implementa la lógica del algoritmo evolutivo ni define la función objetivo del problema
- su responsabilidad es la programación y el mapeo. Los recursos de ejecución que gestiona son recursos de hardware, como GPU, dispositivos aceleradores y clústeres distribuidos
- el código fuente del módulo de algoritmo pertenece a la capa de algoritmo, no es un objeto de programación del Runtime. La capa de algoritmo solo necesita describir qué hacer, sin preocuparse por en qué hardware hacerlo, por lo que el mismo conjunto de algoritmos puede migrarse a entornos de un solo equipo, múltiples tarjetas o entre clústeres. La composabilidad significa que algoritmos, problemas, operadores y backends de ejecución pueden combinarse, reemplazarse y reutilizarse libremente, en lugar de estar bloqueados en un único backend de hardware.

**Cobertura de palabras clave**

- Planificador Runtime, programación de cómputo heterogéneo, coordinación de dependencias y estado, interfaz de programación unificada, composabilidad de módulos, GPU, dispositivos aceleradores, TPU/NPU, clústeres distribuidos, capa de algoritmo, capa de ejecución.

> **Pistas de materiales**
>
> - Esta página incluye un diagrama de arquitectura del planificador Runtime conectando dispositivos de hardware con el algoritmo superior. En el diagrama, la capa superior es la capa de algoritmo y flujo de trabajo, en el medio el planificador Runtime y la interfaz de programación unificada, y la capa inferior la capa de cómputo heterogéneo
> - las flechas indican que tareas/operadores/grafos computacionales se distribuyen hacia abajo, y estados/resultados se devuelven hacia arriba. Al explicar el diagrama, se puede pedir a los estudiantes que reciten siguiendo las flechas "qué envía la capa superior, qué hace el Runtime, qué devuelve la capa inferior".

**Manejo de ejercicios**

La respuesta correcta a la pregunta de opción múltiple 1 es mapear el algoritmo y el flujo de trabajo a recursos de cómputo heterogéneos y ocultar las diferencias de hardware. Punto clave de retroalimentación: el Runtime es el centro de ejecución, no implementa la lógica del algoritmo ni define el problema.

El Runtime gestiona recursos de ejecución de hardware; el código fuente pertenece al contenido de la capa de algoritmo.

La respuesta correcta a la pregunta de opción múltiple 3 es que mediante la interfaz de programación unificada, la capa de algoritmo no necesita vincularse a un dispositivo o forma de clúster específico. Punto clave de retroalimentación: reducir el acoplamiento significa que la capa de algoritmo no necesita escribir código diferente para cada tipo de hardware.

La respuesta correcta a la pregunta de opción múltiple 4 es que algoritmos, problemas, operadores y backends de ejecución se combinan, reemplazan y reutilizan de forma modular. Punto clave de retroalimentación: la composabilidad se refleja en que los componentes pueden combinarse y reemplazarse libremente.

La respuesta correcta a la pregunta de opción múltiple 5 es remapear las tareas de cómputo y los backends de ejecución, manteniendo el código de la capa de algoritmo sin cambios. Punto clave de retroalimentación: el Runtime ajusta dinámicamente el mapeo de tareas, y la capa de algoritmo no necesita modificaciones.

En el escenario de diseño multiobjetivo de perfiles alares, el equipo optimiza simultáneamente el coeficiente de sustentación y la relación sustentación-resistencia de crucero, y migra el mismo código de algoritmo entre una GPU de un solo equipo y un clúster distribuido. Al responder, agarrar dos puntos: primero, el Runtime mapea tareas, operadores y grafos computacionales a backends de hardware concretos mediante la interfaz de programación unificada; cuando el hardware cambia, el código de la capa de algoritmo no cambia, y el Runtime remapea y divide el grafo computacional, coordinando las dependencias de tareas y la sincronización de estado. Segundo, al programar se deben considerar las características computacionales y relaciones de dependencia de las tareas, las capacidades del hardware (como el grado de paralelismo de la GPU, la sobrecarga de comunicación del clúster), la ejecución paralela de evaluaciones multiobjetivo y la sincronización bajo retroalimentación dispersa, así como el retorno de estado, garantizando una implementación eficiente entre hardware sin romper la composabilidad.

**Verificación de comprensión**

Pida a los estudiantes que expliquen con sus propias palabras "la capa de algoritmo se centra en qué hacer, el Runtime en dónde hacerlo y cómo hacerlo", y que den un ejemplo de qué capa cambia y qué capa permanece sin cambios al pasar de GPU a clúster. Si el estudiante solo recuerda nombres de hardware sin explicar la relación de programación y mapeo, se le puede guiar de vuelta a las relaciones de flechas del diagrama de arquitectura.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden expresar el papel de programación y mapeo del Runtime, y que pueden explicar la migración entre hardware mediante la interfaz unificada y la composabilidad, pasar a los ejemplos, aplicaciones o resumen de la página siguiente.

<a id="lecture-page-12"></a>

### Aplicaciones multidominio soportadas por la base unificada

*Página 12*

> **Objetivo de la página:** Los estudiantes deben comprender cómo esta base unificada soporta tareas amplias como aprendizaje por refuerzo, programación genética y optimización combinatoria.

> **Orden de explicación**
>
> Primero señalar con una frase "base unificada = acceso abierto + ejecución tensorizada + programación Runtime. Al ver 'aplicaciones multidominio', autoverificar con estas tres preguntas: ¿cómo se accede a la tarea? ¿cómo se evalúan por lotes las soluciones candidatas? ¿quién gestiona de forma unificada el cómputo y el estado?", y luego explicar por qué es importante combinando con los ejemplos, diagramas o palabras clave de la página.

**Puntos clave de enseñanza**

- Base unificada = acceso abierto + ejecución tensorizada + programación Runtime. Al ver "aplicaciones multidominio", autoverificar con estas tres preguntas: ¿cómo se accede a la tarea? ¿cómo se evalúan por lotes las soluciones candidatas? ¿quién gestiona de forma unificada el cómputo y el estado?
- El paralelismo de pasos del entorno, la evolución de estructuras de árboles de programas y el mapeo de tensores discretos pertenecen a la capa de adaptación
- el flujo de evaluación, la gestión de estado, la organización de operadores y la programación pertenecen a la capa compartida. Si se escribe la estructura específica de un dominio directamente en la lógica de programación compartida, significa que se eligió mal el nivel de abstracción.
- Esta página solo responde "qué puede soportar la base unificada". Ante preguntas sobre rendimiento, sobrecarga de programación o detalles de implementación de tensores por lotes, remitirse primero al ámbito de aprendizaje posterior sobre eficiencia computacional y métodos de tensores por lotes, sin detenerse aquí.

Aplicaciones multidominio soportadas por la base unificada

11

AI999

Base computacional moderna y evolución paralela tensorizada

Las tareas de control y decisión requieren interacción continua con un entorno cambiante, las tareas de diseño estructural requieren buscar en espacios de programas y expresiones de longitud variable, y las tareas de asignación de recursos y planificación de rutas requieren resolver en permutaciones y restricciones discretas. Si se reconstruyera un sistema para cada tipo de problema, la interfaz de evaluación, el almacenamiento de estado, la biblioteca de operadores y la programación de cómputo tendrían que implementarse repetidamente, con un costo de migración de ingeniería altísimo. La idea central de la base unificada es usar la misma infraestructura evolutiva para soportar estas tareas heterogéneas, haciendo que las aplicaciones multidominio compartan evaluación, estado, operadores y gestión de cómputo.

Acceso abierto (acceder a tareas con especificaciones unificadas de registro e interfaz), ejecución tensorizada (organizar las soluciones candidatas en lotes, evaluación paralela por lotes), programación en tiempo de ejecución (asignar tareas y mantener estado en cómputo heterogéneo). Los tres garantizan conjuntamente la reutilización entre dominios, y también explican por qué la capacidad de "proporcionar una base de acceso abierto unificada para aprendizaje por refuerzo, programación genética y optimización combinatoria" merece una discusión aparte.

Aplicaciones multidominio soportadas por la base unificada — La misma base de acceso abierto · Flujo de evaluación, gestión de estado, organización de operadores y programación de cómputo compartidos — Capacidad de la base / Dominio de tarea: Aprendizaje por refuerzo, Programación genética, Optimización combinatoria — Acceso abierto: Interfaz de acceso al entorno, Acceso a estructura de programas, Acceso a soluciones y restricciones — Interacción paralela con el entorno, Muestreo por lotes multi-entorno — — Evolución de estructuras de árboles de programas — Mutación/Cruce — — Resolución tensorizada: Evaluación de lotes de estrategias, Tensorización de estructuras, Lotes de candidatos y restricciones — Programación Runtime y gestión de estado: Programación y estado compartidos, Programación y estado compartidos, Programación y estado compartidos — Capa de adaptación: absorber diferencias de dominio — Paralelismo de pasos del entorno · Evolución de estructuras de árboles de programas · Mapeo de tensores discretos — Base unificada: acceso abierto · ejecución tensorizada · programación Runtime y gestión de estado — Cómo tres tipos típicos de tareas aterrizan en la misma base — Aprendizaje por refuerzo: la base proporciona capacidad de interacción paralela con el entorno, soportando muestreo por lotes de múltiples instancias de entorno, evaluación paralela de un lote de estrategias candidatas, y formando un ciclo cerrado con la optimización evolutiva.

La base soporta la evolución de estructuras de longitud variable y jerárquicas como árboles de programas, pudiendo manejar la representación estructural y su mutación y cruce dentro de un flujo unificado de población y evaluación. Optimización combinatoria: adaptar decisiones discretas, selecciones, permutaciones y objetivos con restricciones a resolución tensorizada, mejorando el rendimiento de búsqueda mediante candidatos por lotes y evaluación paralela. Qué se comparte, qué se adapta — Las diferencias de dominio son absorbidas por la capa de adaptación: el aprendizaje por refuerzo se centra en el paralelismo de pasos del entorno, la programación genética en la evolución de estructuras de árboles de programas, y la optimización combinatoria en el mapeo de decisiones discretas a tensores. Los tres comparten la programación Runtime y la gestión de estado subyacentes — comparten el flujo de evaluación, el portador de estado, la forma de organización de operadores y la gestión de cómputo, en lugar de reconstruir el sistema para cada tipo de problema.

Si se escribe la estructura específica de un dominio directamente en la lógica de programación compartida, significa que se eligió mal el nivel de abstracción. Alcance de esta página — Esta página se centra en "qué puede soportar la base unificada", sin desarrollar comparaciones de rendimiento específicas ni detalles de implementación del planificador; estos se dejan para la discusión posterior sobre eficiencia computacional y métodos de tensores por lotes.

¿Cuál es el valor principal de la base de acceso abierto unificada?

Permitir que diferentes dominios reutilicen evaluación, estado, operadores y gestión de cómputo, reduciendo significativamente el costo de migración de ingeniería

Reemplazar el aprendizaje por refuerzo, la programación genética y la optimización combinatoria con un único algoritmo unificado

Comprimir todas las tareas en una misma representación vectorial de longitud fija

Reconstruir un sistema y una cadena de herramientas independientes para cada nuevo tipo de problema

Las formas de las tareas son diferentes, pero las especificaciones de acceso, la evaluación por lotes, la gestión de estado y la programación de cómputo pueden compartirse; las nuevas tareas solo necesitan describir sus diferencias en la capa de adaptación.

"Reconstruir el sistema para cada tipo de problema" es precisamente el problema que la base busca resolver; al mismo tiempo, la base tampoco exige que todas las tareas compartan el mismo algoritmo o la misma representación; las diferencias son absorbidas por la capa de adaptación.

Correcto. Esta respuesta puede conectar con los conceptos de esta página y explicar la base.

Vuelva a la explicación de esta página, encuentre evidencia clave o ejemplos y luego juzgue.

En el escenario de aprendizaje por refuerzo, ¿qué capacidad clave proporciona principalmente la base unificada?

Operadores de mutación y cruce de árboles de programas

Solo soporte de paso serial para una única instancia de entorno

Muestreo por lotes de múltiples instancias de entorno y recolección de trayectorias, evaluación paralela de un lote de estrategias candidatas

Interfaz de modelado de permutaciones y restricciones discretas

Múltiples instancias de entorno avanzan simultáneamente, las trayectorias se recopilan por lotes, y las estrategias candidatas se evalúan en paralelo, formando un ciclo cerrado con la optimización evolutiva.

La evolución de estructuras de árboles de programas pertenece al punto de adaptación de la programación genética, y el modelado de restricciones discretas pertenece al punto de adaptación de la optimización combinatoria; la clave del aprendizaje por refuerzo es el paralelismo por lotes de la interacción con el entorno, no el serial de una sola instancia.

Cuando una tarea de programación genética se conecta a la base unificada, ¿qué característica clave debe soportar la base?

Solo procesar vectores de números reales de longitud fija

Representación y evolución de estructuras de longitud variable y jerárquicas como árboles de programas, incluyendo mutación y cruce estructural

Debe codificar forzosamente el árbol de programas como una cadena binaria de longitud fija antes de evolucionar

Solo puede procesar funciones objetivo continuas sin restricciones

Las soluciones candidatas de la programación genética son estructuras de programas de longitud variable y jerárquicas; la base necesita acomodar esta representación en un flujo unificado de población y evaluación, y soportar la mutación y el cruce correspondientes.

El vector de longitud fija es la representación típica de la optimización continua; la característica central de la programación genética es precisamente la estructura de árbol de programas de longitud variable y jerárquica, y las operaciones evolutivas sobre la estructura.

Cuando una tarea de optimización combinatoria se conecta a la base unificada, ¿cuál es el trabajo de adaptación más crítico?

Eliminar todas las restricciones y conservar solo un único objetivo

Reescribir el problema como una tarea de entrenamiento de red neuronal continua y diferenciable

Compilar un solucionador dedicado para cada instancia de problema

Adaptar las decisiones discretas, selecciones, permutaciones y objetivos con restricciones a resolución tensorizada

Las soluciones candidatas y las restricciones se organizan en lotes, reutilizando así la capacidad de candidatos por lotes y evaluación paralela de la base.

Compilar un solucionador dedicado por instancia equivale a volver al viejo camino de "reconstruir el sistema"; abandonar las restricciones también cambia el problema en sí; ninguna de las dos es la adaptación que requiere la base.

Sobre la división entre capa compartida y capa de adaptación, ¿cuál de las siguientes comprensiones es correcta?

La lógica de programación debe escribirse por separado para aprendizaje por refuerzo, programación genética y optimización combinatoria

La capa de adaptación solo hace presentación de interfaz, sin participar en ninguna conversión semántica de tareas

La capa compartida se encarga de la evolución de estructuras de árboles de programas, y la capa de adaptación del paralelismo de pasos del entorno

Las diferencias de dominio son absorbidas por la capa de adaptación, y los tres tipos de tareas comparten la programación Runtime y la gestión de estado subyacentes

El paralelismo de pasos del entorno, la evolución de estructuras de árboles de programas y el mapeo de tensores discretos pertenecen a la capa de adaptación; el flujo de evaluación, la gestión de estado, la organización de operadores y la programación pertenecen a la capa compartida.

Escribir estructuras específicas de dominio en la lógica de programación compartida, o hacer que la capa compartida maneje la evolución estructural específica de un dominio, son errores de división de niveles.

El mismo runtime soporta tres tipos de tareas heterogéneas

Lea el escenario y responda las preguntas.

Un equipo de algoritmos está construyendo una plataforma de computación evolutiva. Anteriormente mantenían tres sistemas independientes para control con aprendizaje por refuerzo, regresión simbólica (búsqueda de estructuras de programas) y planificación de rutas logísticas: cada uno con su propia interfaz de evaluación, almacenamiento de estado y programación de cómputo, con grave duplicación de código; cambiar de tarea implicaba reescribir todo el flujo. La nueva solución cambia a una base unificada que soporta estos tres tipos de tareas: las tareas de aprendizaje por refuerzo avanzan en paralelo múltiples instancias de entorno y recopilan trayectorias; las tareas de programación genética evalúan en paralelo poblaciones de árboles de programas; las tareas de optimización combinatoria organizan soluciones candidatas y restricciones en lotes tensoriales, y la programación unificada asigna cómputo heterogéneo.

1. ¿Por qué el equipo abandona mantener sistemas separados para cada tipo de problema? Explique desde la perspectiva de reutilización y costo de migración.

Acceso a tareas, evaluación por lotes de soluciones candidatas, gestión de estado de candidatos y población, organización de operadores y programación de cómputo. Mantenerlos por separado significa que estas capacidades se implementan tres veces repetidamente, y cualquier tarea nueva requiere reconstruir todo el flujo, con un costo de migración de ingeniería muy alto. La base unificada permite que los tres tipos de tareas reutilicen el mismo flujo de evaluación, portador de estado, forma de organización de operadores y gestión de cómputo; las nuevas tareas solo necesitan describir sus diferencias en la capa de adaptación para conectarse.

2. Indique las diferencias que los tres tipos de tareas absorben respectivamente en la capa de adaptación, y explique qué reutilizan en la capa compartida.

El aprendizaje por refuerzo se centra en el paralelismo de pasos del entorno (muestreo por lotes de múltiples instancias de entorno, recolección de trayectorias y evaluación por lotes de estrategias); la programación genética se centra en la representación y evolución de estructuras de longitud variable y jerárquicas como árboles de programas (mutación y cruce estructural); la optimización combinatoria se centra en mapear decisiones discretas, selecciones, permutaciones y objetivos con restricciones a resolución tensorizada. Reutilización de la capa compartida: especificaciones de acceso abierto, ejecución tensorizada por lotes, programación Runtime y gestión de estado, y asignación unificada de cómputo heterogéneo. Precisamente porque las diferencias se concentran en la capa de adaptación y los elementos comunes se depositan en la capa compartida, no es necesario reconstruir el sistema para cada tipo de problema.

Recuerde primero los tres pilares

Base unificada = acceso abierto + ejecución tensorizada + programación Runtime. Al ver "aplicaciones multidominio", autoverificar con estas tres preguntas: ¿cómo se accede a la tarea? ¿cómo se evalúan por lotes las soluciones candidatas? ¿quién gestiona de forma unificada el cómputo y el estado?

Distinga la capa compartida de la capa de adaptación

El paralelismo de pasos del entorno, la evolución de estructuras de árboles de programas y el mapeo de tensores discretos pertenecen a la capa de adaptación; el flujo de evaluación, la gestión de estado, la organización de operadores y la programación pertenecen a la capa compartida. Si se escribe la estructura específica de un dominio directamente en la lógica de programación compartida, significa que se eligió mal el nivel de abstracción.

Los límites de esta página

Esta página solo responde "qué puede soportar la base unificada". Ante preguntas sobre rendimiento, sobrecarga de programación o detalles de implementación de tensores por lotes, remitirse primero al ámbito de aprendizaje posterior sobre eficiencia computacional y métodos de tensores por lotes, sin detenerse aquí.

step-1

Los estudiantes deben comprender cómo esta base unificada soporta tareas amplias como aprendizaje por refuerzo, programación genética y optimización combinatoria.

lesson_4

lesson_4_slide_11

Del borrador de EvoClass

Proporciona una base de acceso abierto unificada para aprendizaje por refuerzo, programación genética y optimización combinatoria

lesson_id_distribution

67ee25ab22558e4ae0e13f24b7c34c2da1218107cceb1cd331b38fc3521a9743

**Base documental**

Del borrador de EvoClass (página 4-4)

> **Pistas de materiales**
>
> - Proporciona una base de acceso abierto unificada para aprendizaje por refuerzo, programación genética y optimización combinatoria

**Actividad en clase**

Pida que se repita el contenido de esta página con un ejemplo cercano a la experiencia de los estudiantes, y que ellos expliquen la relación entre este ejemplo y "base unificada = acceso abierto + ejecución tensorizada + programación Runtime. Al ver 'aplicaciones multidominio', autoverificar con estas tres preguntas: ¿cómo se accede a la tarea? ¿cómo se evalúan por lotes las soluciones candidatas? ¿quién gestiona de forma unificada el cómputo y el estado?".

> **Objetivos correspondientes**
>
> - Dominar el método de expresar el proceso evolutivo como computación tensorial por lotes
> - Comprender el papel del Runtime en la programación de cómputo heterogéneo y el mantenimiento de la composabilidad algorítmica

**Verificación de comprensión**

Pida aleatoriamente a un estudiante que resuma los puntos clave de esta página con sus propias palabras, y el instructor complementará las palabras clave faltantes según la respuesta.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden expresar la relación central de esta página, pasar a los ejemplos, aplicaciones o resumen de la página siguiente.

<a id="lecture-page-13"></a>

### Práctica de análisis comparativo de eficiencia computacional

*Página 13*

> **Objetivo de la página:** Los estudiantes deben comprender mediante comparación práctica la diferencia de eficiencia entre el recorrido serial en CPU y el procesamiento por lotes tensorial en GPU.

> **Objetivo de la página**
>
> Aterrizar la comparación de eficiencia computacional en una práctica reproducible, comprendiendo la diferencia de eficiencia de extremo a extremo entre el recorrido serial individuo por individuo en CPU y el procesamiento por lotes tensorial en GPU, aclarando de dónde viene la aceleración, cuál es el costo y dónde están los límites.

> **Orden de explicación**
>
> Primero presentar dos líneas base sobre la misma tarea evolutiva, luego ver el gráfico de barras de comparación de eficiencia, después explicar el protocolo de medición reproducible, y finalmente resumir las fuentes de beneficio, las condiciones limitantes y las conclusiones prácticas.

**Puntos clave de enseñanza**

- Usar un bucle para llamar a la función de evaluación individuo por individuo; cada generación requiere N programaciones independientes, actualizaciones de estado y agregación de resultados. El control de bucle, la sobrecarga del intérprete y el acceso disperso a memoria diluyen la potencia de cómputo efectiva
- cuantos más individuos, mayor la proporción de estos costos no computacionales. Organizar la población, las entradas de evaluación y el estado de ejecución como tensores, ejecutando por lotes la evaluación y los operadores en GPU, cubriendo todo el conjunto de candidatos con una sola llamada, reduciendo así considerablemente los bucles seriales y las programaciones. Bajo las condiciones de mismo problema, misma población, misma semilla aleatoria, y medición tras precalentamiento y sincronización de dispositivo, el bucle serial en CPU es la referencia de 1.0×, el procesamiento por lotes en GPU con b=64 es aproximadamente 2.2×, con b=256 aproximadamente 4.5×, con b=1024 aproximadamente 7.1×. El gráfico muestra el valor relativo del tiempo por generación; cuanto mayor el tamaño de lote, más fácil es diluir la sobrecarga fija. Fijar problema, tamaño de población, número de generaciones y semilla aleatoria
- registrar el tiempo real por generación, el tiempo total, el rendimiento (evaluaciones/segundo), la tasa de aceleración, la utilización de GPU y el uso de memoria de video. Antes de medir, precalentar para excluir el impacto de la primera compilación y la asignación de memoria de video
- los puntos de medición deben tener sincronización de dispositivo
- contabilizar por separado el tiempo de cómputo y el tiempo de transferencia de datos host-dispositivo. Si falta cualquiera de estos elementos, la tasa de aceleración puede distorsionarse. El beneficio proviene del paralelismo por lotes, los operadores tensorizados y el paralelismo dentro del dispositivo, haciendo que una sola llamada procese todo el conjunto de candidatos
- las restricciones incluyen el tamaño de lote, la dimensión del problema, el grado de vectorización de la función de evaluación, la sobrecarga de copia host-dispositivo y la sobrecarga de lanzamiento de kernel. Un lote demasiado pequeño verá su beneficio devorado por la sobrecarga de lanzamiento
- si la función de evaluación no puede vectorizarse, el procesamiento por lotes difícilmente puede desplegarse. El orden correcto es primero verificar si la función de evaluación puede procesarse por lotes, luego comparar las implementaciones en CPU y GPU. La ventaja de eficiencia debe aterrizar finalmente en "obtener más generaciones o más soluciones candidatas bajo el mismo presupuesto computacional", y decidir a partir de ello la forma de despliegue y el diseño experimental, en lugar de perseguir simplemente el número de la tasa de aceleración.

**Manejo de ejercicios**

La respuesta correcta a la pregunta 1 es "la sobrecarga de programación, intérprete y acceso disperso a memoria que genera llamar individualmente a la función de evaluación para cada individuo". La línea base serial produce N programaciones y actualizaciones de estado independientes por generación; el control de bucle, la sobrecarga del intérprete y el acceso disperso a memoria diluyen la potencia efectiva; en este punto aún no hay lanzamiento de kernel de GPU ni copia.

La respuesta correcta a la pregunta 2 es organizar la población, las entradas de evaluación y el estado de ejecución como tensores, cubriendo todo el conjunto de candidatos con una sola llamada. El núcleo de la aceleración es el paralelismo por lotes y la tensorización, no cambiar la precisión, el tamaño de población o el número de semillas.

El protocolo estándar de la pregunta 3 es fijar problema, tamaño de población, generaciones y semilla, precalentar y sincronizar el dispositivo antes de medir, y distinguir el tiempo de cómputo del de transferencia de datos.

La GPU a menudo ejecuta de forma asíncrona; sin sincronización, la medición puede omitir cómputos aún no completados, subestimando el tiempo y sobreestimando la tasa de aceleración; la sincronización en sí no mejora la potencia de cómputo ni elimina la transferencia de datos.

Cuando el grado de vectorización de la función de evaluación es bajo, la ventaja del procesamiento por lotes en GPU disminuye notablemente, e incluso puede tener beneficios limitados por la sobrecarga de copia y lanzamiento de kernel; la aceleración no es constante ni crece sin límite con el aumento del lote.

Práctica del caso:

1. La aceleración de aproximadamente 9× obtenida sin sincronización de dispositivo es probablemente poco fiable. El host, tras enviar el kernel, no espera a que se complete y continúa ejecutándose; si los puntos de medición no se sincronizan, el tiempo medido puede cubrir solo la fase de envío del kernel, omitiendo el cómputo real aún en ejecución, subestimando gravemente el tiempo de GPU y sobreestimando la tasa de aceleración. La corrección es: llamar a la sincronización de dispositivo en cada punto de medición, asegurando que todo el trabajo enviado se complete realmente antes de leer la marca de tiempo; hacer primero iteraciones de precalentamiento, y contabilizar por separado el tiempo de transferencia de datos host-dispositivo y el tiempo de cómputo puro. Solo el tiempo por generación y el tiempo total medidos bajo semilla fija, precalentamiento y sincronización pueden usarse como base fiable.

2. Una aceleración de solo aproximadamente 1.2× con lote pequeño b=8 no es contradictoria. El beneficio del procesamiento por lotes está restringido conjuntamente por el tamaño de lote, la sobrecarga de lanzamiento de kernel y la sobrecarga de transferencia de datos; con un lote demasiado pequeño, el trabajo paralelizable en el dispositivo es insuficiente, la sobrecarga fija representa una proporción grande del tiempo por generación, y el grado de paralelismo efectivo no puede diluir estos costos, por lo que la aceleración se acerca naturalmente a 1. Se sugiere aumentar el tamaño de lote dentro de los límites de la memoria de video, vectorizar en lo posible toda la función de evaluación y la lógica de postprocesamiento, y volver a medir según el protocolo estándar, reportando por separado el tiempo por generación, el tiempo total, el rendimiento y la tasa de aceleración, para juzgar si el beneficio realmente aterriza en el objetivo de obtener más generaciones o más candidatos bajo el mismo presupuesto.

**Verificación de comprensión**

Pida aleatoriamente a los estudiantes que expliquen con sus propias palabras por qué primero se verifica si la función de evaluación puede vectorizarse antes de comparar CPU y GPU; y que expliquen qué problema resuelven respectivamente el precalentamiento y la sincronización de dispositivo.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden distinguir las fuentes de beneficio y las condiciones limitantes, y que pueden convertir la aceleración en beneficio presupuestario, pasar a los ejemplos, aplicaciones o resumen de la página siguiente.

<a id="lecture-page-14"></a>

### Métodos centrales de la computación tensorial por lotes

*Página 14*

> **Objetivo de la página:** Los estudiantes deben consolidar el método central de expresar el proceso evolutivo como computación tensorial por lotes.

> **Objetivo de la página**
>
> Consolidar el método central de expresar el proceso evolutivo como computación tensorial por lotes, comprender la relación entre la dimensión de lote, los operadores por lotes, la optimización de grafos computacionales y las métricas de rendimiento, y poder identificar la pseudotensorización.

> **Orden de explicación**
>
> El tensor de candidatos X es [N × D], los objetivos y restricciones F son [N × M], la salida de evaluación Y es [N × M]; la dimensión de lote N siempre está en la capa más externa, D y M describen el número de variables y el número de elementos objetivo de un solo candidato.
>
> Mapear de forma unificada la población, los objetivos/restricciones, la salida de evaluación y el estado evolutivo a tensores con dimensión de lote, manteniendo las cantidades de estado con escalares o buffers de tensores pequeños, en lugar de registrarlas individuo por individuo en objetos Python.
>
> Mutación X′ = X + σ·randn(X), cruce emparejando y recombinando a lo largo de la dimensión N, selección idx = topk(F, k), evaluación Y = fθ(X). Lo importante no es una expresión individual, sino que todos los candidatos comparten el mismo grafo de operaciones tensoriales, y una llamada por lotes reemplaza N llamadas de un solo candidato; las restricciones y violaciones de límites pueden manejarse con tensores de máscara dentro de la misma operación por lotes.
>
> La fusión de operadores reduce el lanzamiento de kernels, el paralelismo intra-lote permite que todos los candidatos se ejecuten simultáneamente, la ejecución asíncrona solapa cómputo y transferencia, y la reutilización de memoria reduce la asignación de tensores intermedios.
>
> Pasar de la latencia de un solo paso a candidatos/segundo o generaciones/segundo, porque una llamada por lotes soporta todo el lote de candidatos, y el rendimiento global es lo que refleja la eficiencia de búsqueda.
>
> Incrustar operadores por lotes dentro de un bucle Python individuo por individuo reintroduce la sobrecarga del intérprete y el lanzamiento de kernels, dejando la dimensión de lote como meramente nominal. Método de autoverificación: en un paso evolutivo, el nivel de programación debe ser solo "lote", sin "individuo".

**Puntos clave de enseñanza**

- La dimensión de lote N es el número de candidatos; cuando las formas coinciden, mutación, cruce, selección y evaluación pueden ejecutarse directamente a lo largo de la dimensión N. El beneficio directo de la tensorización proviene de reducir el número de llamadas y la sobrecarga de programación, no de cambiar el número de candidatos o mejorar la precisión puntual. randn(X) genera un tensor de perturbación aleatoria de la misma forma que X; la perturbación es elemento por elemento, y σ controla la intensidad. topk(F, k) selecciona a lo largo de la dimensión de lote N los índices de los primeros k candidatos; el objeto de selección son candidatos, no variables ni elementos objetivo. La ejecución por lotes cambia la ubicación del cuello de botella de rendimiento; la latencia sigue siendo medible, pero para medir la eficiencia de escala hay que ver cuántos candidatos o cuántas generaciones se completan por unidad de tiempo.

**Cobertura de palabras clave**

- Computación tensorial por lotes, dimensión de lote N, contrato de formas, operadores por lotes, optimización de grafos computacionales, rendimiento, candidatos/segundo, generaciones/segundo, pseudotensorización.

> **Pistas de materiales**
>
> - El diagrama de esta página tiene como tema "proceso evolutivo → grafo computacional tensorial por lotes", con tres columnas: ① organización tensorizada, ② operadores por lotes, ③ optimización de compilación y rendimiento. La pizarra o el mapa mental pueden desarrollarse según estas tres columnas, destacando en la tercera la métrica de rendimiento "candidatos/segundo · generaciones/segundo".

> **Pistas de ejercicios**
>
> - Las 5 preguntas de opción múltiple verifican respectivamente el contrato de formas, el beneficio de rendimiento de la tensorización, el significado de la expresión de mutación, la semántica de selección de topk y la razón del cambio de métrica. La retroalimentación puede enfatizar: al acertar, explicar la base conectando con el contrato de formas o la forma de llamada
> - al fallar, volver a la explicación de esta página y buscar evidencia clave antes de juzgar. La pregunta de caso "migrar el bucle evolutivo individuo por individuo a ejecución tensorial por lotes" requiere explicar cómo organizar candidatos, objetivos y estado como tensores y procesarlos por lotes a lo largo de N, así como las compensaciones entre optimización de grafos computacionales y memoria de video insuficiente. Los puntos de respuesta incluyen X:[N×D], F:[N×M], Y=fθ(X), estado con escalares o buffers de tensores pequeños
> - mutación, cruce, selección y evaluación se ejecutan todos por lotes a lo largo de la dimensión N
> - la optimización puede hacer fusión de operadores, paralelismo intra-lote, ejecución asíncrona y reutilización de memoria
> - con memoria de video insuficiente se puede usar ejecución por bloques o minilotes, reducir la precisión numérica y acortar el ciclo de vida de tensores intermedios, pero todos los candidatos dentro de la misma generación deben mantener un criterio de comparación consistente.

**Actividad en clase**

Pida a los estudiantes que expliquen con sus propias palabras "por qué la dimensión de lote N debe estar en la capa más externa", y que den un ejemplo simple, como N=4, D=3, M=2, escribiendo las formas de X, F, Y, explicando cómo una llamada por lotes reemplaza múltiples llamadas de un solo candidato.

**Verificación de comprensión**

Pida a los estudiantes que resuman el contrato de formas, señalen una forma de pseudotensorización y expliquen por qué la métrica pasa de la latencia de un solo paso al rendimiento. Si los estudiantes solo pueden repetir términos sin explicar los cambios en el número de llamadas y el nivel de programación, se puede volver a la sección de operadores por lotes y errores comunes para reforzar.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden expresar la relación entre el contrato de formas y la ejecución por lotes, pasar a la aplicación, el resumen o la discusión de optimización de grafos computacionales más compleja de la página siguiente.

<a id="lecture-page-15"></a>

### Programación Runtime y composabilidad algorítmica

*Página 15*

> **Objetivo de la página:** Los estudiantes deben consolidar el conocimiento central sobre la programación de cómputo heterogéneo y la composabilidad algorítmica del Runtime.

> **Objetivo de la página**
>
> Establecer la posición del Runtime como capa intermedia — no es un algoritmo concreto, sino una capa de programación y abstracción que conecta lo superior y lo inferior: hacia arriba soporta la combinación flexible de algoritmos, problemas y flujos de trabajo; hacia abajo gestiona cómputo heterogéneo como CPU y GPU, manteniendo así la composabilidad algorítmica y la independencia del hardware.

> **Orden de explicación**
>
> Primero dar el juicio de "capa intermedia"; luego desglosar los objetos de programación, los recursos heterogéneos y los mecanismos de desacoplamiento; después explicar los beneficios y costos de la composabilidad; finalmente usar ejemplos de reemplazo de algoritmos y ejercicios para verificar la comprensión.

**Puntos clave de enseñanza**

- Según el estado del flujo de trabajo y del módulo de monitoreo, programar tareas como población, evaluación y operadores al dispositivo adecuado, gestionando de forma unificada la ejecución paralela y el uso de recursos. Recibe de los módulos de algoritmo, problema y flujo de trabajo, y hacia abajo llama a CPU, GPU y aceleradores. Algoritmos, problemas y operadores se combinan mediante interfaces modulares, sin vincularse directamente al hardware subyacente, a las estrategias de paralelismo o a los detalles de compilación. Por lo tanto, al reemplazar algoritmos como DE o PSO o cambiar el problema de optimización, no es necesario reescribir el código paralelo subyacente de GPU/CPU. Las diferencias de dispositivo, la ejecución tensorizada y la optimización de compilación son absorbidas por el Runtime, y la capa de algoritmo permanece independiente del dispositivo, facilitando el reemplazo y la reutilización. La abstracción trae sobrecarga de programación y transferencia de datos, y requiere un equilibrio entre flexibilidad, rendimiento y complejidad de ingeniería, por ejemplo usando procesamiento por lotes, ejecución asíncrona o caché para reducir la transferencia de datos. El mismo Runtime puede soportar aplicaciones multidominio, y también proporciona un entorno de ejecución estable para la evolución de métodos y el reemplazo de algoritmos.

> **Pistas de materiales**
>
> - El diagrama de esta página puede leerse en tres capas. La capa superior es la capa de algoritmo, que contiene el módulo de algoritmo, la definición del problema y el flujo de trabajo, los tres conectados mediante una interfaz unificada
> - la capa intermedia es la capa de programación Runtime, encargada de la programación de tareas, la ejecución paralela, la gestión de recursos y el aislamiento de interfaces
> - la capa inferior es el cómputo heterogéneo, incluyendo CPU, GPU y aceleradores. Las indicaciones laterales enfatizan respectivamente "algoritmo reemplazable, independiente del hardware" y "compensación: flexibilidad · rendimiento · complejidad", y la indicación inferior "el mismo Runtime soporta aplicaciones multidominio". Al explicar, se puede seguir la dirección de las flechas de arriba hacia abajo: la capa de algoritmo no toca directamente el hardware, sino que el Runtime programa la ejecución según el flujo de trabajo.

**Cobertura de palabras clave**

- Programación de cómputo heterogéneo, composabilidad algorítmica, interfaz unificada, programación de flujo de trabajo, abstracción independiente del hardware, aislamiento de interfaces, sobrecarga de programación, sobrecarga de transferencia de datos.

**Manejo de ejercicios**

Las cinco preguntas de opción múltiple pueden usarse para una verificación rápida. La dirección correcta de la pregunta 1 es "proporcionar una capa de programación y abstracción, gestionar cómputo heterogéneo y mantener la composabilidad algorítmica"; si el estudiante elige incorrectamente "implementar directamente algoritmos de optimización", hay que enfatizar que el Runtime no implementa algoritmos concretos. La dirección correcta de la pregunta 2 es "combinarse mediante interfaces modulares, sin vincularse al hardware subyacente ni a las estrategias de paralelismo"; si elige incorrectamente API de CUDA o código paralelo escrito a mano, explicar que esto rompería el desacoplamiento. La dirección correcta de la pregunta 3 es "absorber las diferencias de dispositivo, la ejecución tensorizada y la optimización de compilación, haciendo que la capa de algoritmo sea independiente del dispositivo". La dirección correcta de la pregunta 4 es "la abstracción trae sobrecarga de programación y transferencia de datos, y requiere equilibrar flexibilidad, rendimiento y complejidad de ingeniería".

La dirección correcta de la pregunta 5 es "el mismo Runtime puede soportar aplicaciones multidominio y proporciona un entorno de ejecución estable para la evolución de métodos". Al retroalimentar, vincular de forma unificada con las tres evidencias: capa intermedia y no implementación de algoritmos, la composabilidad requiere desacoplamiento del hardware, la abstracción no es de costo cero.

El Runtime, como capa intermedia, combina los módulos de algoritmo, problema y flujo de trabajo mediante una interfaz unificada, y programa tareas como población, evaluación y operadores para su ejecución en CPU o GPU; la capa de algoritmo no se vincula directamente al hardware, a las estrategias de paralelismo o a los detalles de compilación, por lo que cuando el equipo cambia DE, PSO o ajusta el tamaño de población, no necesita reescribir el código paralelo subyacente. La segunda pregunta puede responderse: la abstracción trae sobrecarga adicional de programación y transferencia de datos, lo que puede afectar el rendimiento de extremo a extremo; además, el mantenimiento y la depuración del propio Runtime aumentan la complejidad de ingeniería. El equipo puede reducir la transferencia de datos mediante procesamiento por lotes, ejecución asíncrona o caché, logrando un equilibrio entre flexibilidad, rendimiento y complejidad de ingeniería.

**Verificación de comprensión**

Pida a los estudiantes que expliquen en una frase por qué el Runtime permite reemplazar algoritmos sin tocar el código de hardware; luego que den un ejemplo de objeto de programación y un ejemplo de recurso heterogéneo, confirmando que no confunden "población, evaluación, operadores" con "CPU, GPU, aceleradores".

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden distinguir entre objetos de programación y recursos heterogéneos, y que pueden expresar los beneficios y costos de la composabilidad, pasar a los ejemplos, aplicaciones o resumen de la página siguiente.

<a id="lecture-page-16"></a>

### Piedra angular de la exploración evolutiva de alta intensidad en paralelo

*Página 16*

> **Objetivo de la página:** Los estudiantes deben resumir de forma integral el valor global y el significado práctico de la base computacional de EvoX y la evolución paralela tensorizada.

> **Objetivo de la página**
>
> Resumir de forma integral el valor global y el significado práctico de la base computacional de EvoX y la evolución paralela tensorizada. Los estudiantes deben poder explicar la transición de la lista de candidatos al grafo computacional tensorizado, dominar los tres tipos de objetos tensorizados: población, evaluación y estado, y comprender cómo el Runtime unificado y la arquitectura desacoplada soportan la exploración evolutiva de alta intensidad en paralelo.

> **Orden de explicación**
>
> Primero señalar el cuello de botella del flujo serial tradicional, luego presentar el grafo computacional tensorizado como piedra angular, después desarrollar los tres tipos de objetos tensorizados, a continuación explicar la grafización computacional y la arquitectura unificada, y finalmente aterrizar en beneficios, significado práctico y el caso del perfil supercrítico.

**Puntos clave de enseñanza**

- 1. Los experimentos evolutivos tradicionales tratan cada individuo como un objeto Python independiente, modelando y evaluando uno por uno. Cuando la escala de candidatos se expande a miles o decenas de miles, el verdadero cuello de botella a menudo ya no es el algoritmo en sí, sino la sobrecarga de programación, sincronización y E/S candidato por candidato. La piedra angular de EvoX puede resumirse como: de la lista de candidatos al grafo computacional tensorizado. Reorganiza la población, la evaluación y el estado de ejecución en tensores computables de forma integral, y luego el Runtime unificado los programa a GPU y cómputo heterogéneo para su ejecución por lotes, soportando así búsquedas evolutivas de gran escala, multiobjetivo y multi-solución en paralelo. 2. Tres tipos de objetos tensorizados: Los parámetros individuales, genes o estrategias ya no se recorren uno por uno como objetos Python, sino que se organizan como tensores según la dimensión de lote; las diferencias entre individuos son soportadas por una dimensión del tensor. La aptitud, las restricciones, los indicadores multiobjetivo y los resultados de evaluación de simulación o modelo pueden calcularse por lotes; los candidatos dentro del mismo lote comparten una llamada al dispositivo, reduciendo significativamente la sobrecarga de programación y E/S candidato por candidato. El estado de ejecución, como la generación evolutiva, la semilla aleatoria, la caché y las métricas de monitoreo, se gestiona de forma unificada, haciendo que los experimentos tras la aceleración paralela sigan siendo reproducibles y trazables. La tensorización no es una optimización local de un solo punto, sino que atraviesa los tres niveles del bucle evolutivo. Si cualquier nivel vuelve a un bucle objeto por objeto, el paralelismo quedará bloqueado en ese nivel. Una vez que la lista de candidatos se eleva a grafo computacional tensorizado, el paralelismo de operadores y la optimización de compilación tienen espacio para desplegarse, y el tamaño de la población y el paralelismo de evaluación pueden escalar con el cómputo, en lugar de quedar bloqueados por el bucle del intérprete. A esto le acompaña la arquitectura unificada: algoritmo, problema, flujo de trabajo y monitoreo, y planificador Runtime mutuamente desacoplados, haciendo que los algoritmos sean componibles, los problemas conectables y el cómputo heterogéneo gestionado de forma unificada. Los usuarios no necesitan preocuparse simultáneamente por la programación subyacente al escribir algoritmos. Reemplaza el bucle serial tradicional de CPU, logrando aceleración a gran escala en GPU y cómputo heterogéneo, proporcionando una base de rendimiento estable para la exploración de alta intensidad
- en el mismo tiempo de reloj, se pueden explorar más candidatos, más combinaciones de objetivos o más repeticiones aleatorias. Cuando la ingeniería de bucles y programación subyacente es absorbida por la base, los investigadores pueden dirigir su energía al modelado del problema, la compensación de objetivos y el diseño de hipótesis experimentales, sin tener que sumergirse primero en la ingeniería de bucles y programación subyacente. Esta división del trabajo es a la vez el requisito previo para la exploración evolutiva de alta intensidad en paralelo y la base de ingeniería para la evolución de métodos posterior y la investigación AI Native. En la optimización multiobjetivo de perfiles supercríticos, la relación sustentación-resistencia de crucero y el coeficiente de sustentación crítico de buffeting se contrarrestan mutuamente, y es necesario conservar un conjunto de soluciones candidatas diferenciadas para que los expertos hagan compensaciones. Una sola simulación de alta precisión es costosa, la escala de candidatos alcanza miles, el bucle serial temprano en CPU requería días por experimento, y las semillas aleatorias y los resultados intermedios dispersos eran difíciles de verificar. Idea de reingeniería: primero tensorizar la población, organizando los parámetros de los perfiles candidatos como tensores según la dimensión de lote
- luego tensorizar la evaluación, evaluando por lotes objetivos y restricciones como la relación sustentación-resistencia y el coeficiente de sustentación de buffeting, pudiendo primero predecir por lotes con modelos sustitutos y luego llamar a simulaciones de alta precisión para unos pocos candidatos
- al mismo tiempo tensorizar el estado, registrando de forma unificada la generación, la semilla aleatoria, la caché y las métricas de monitoreo
- finalmente grafizar computacionalmente y programar con el Runtime unificado a GPU y cómputo heterogéneo para ejecución por lotes. Las etapas de mejora del rendimiento incluyen el paralelismo de evaluación por lotes, el paralelismo de operadores y la optimización de compilación, la eliminación de la sobrecarga de programación y sincronización Python candidato por candidato, y la exploración simultánea de más candidatos, más combinaciones de objetivos y más repeticiones aleatorias en el mismo tiempo de reloj. Sobre la verificabilidad: no conviene emitir demasiado pronto una única solución óptima, porque los objetivos se contrarrestan mutuamente y la convergencia temprana a un solo punto perdería información de compensación
- conservar candidatos diferenciados permite a los expertos elegir según beneficio, costo y condiciones de aplicabilidad. En cuanto a la verificabilidad, la generación, la semilla aleatoria, la caché y las métricas de monitoreo deben registrarse de forma unificada como estado de ejecución y gestionarse junto con el grafo computacional, permitiendo la reproducción y trazabilidad completas de los resultados de la ejecución paralela por lotes; los registros de evaluación de los lotes de candidatos también deben poder rastrearse hasta parámetros y configuraciones de evaluación concretos.

**Manejo de ejercicios**

Esta página incluye cinco preguntas de opción múltiple y una pregunta de caso, que pueden usarse para verificar la comprensión conceptual y la aplicación por transferencia.

La piedra angular es la transición de la lista de candidatos al grafo computacional tensorizado, con programación por lotes unificada del Runtime. Pista de respuesta: el cuello de botella está en el bucle Python candidato por candidato, la programación y la E/S, no en el algoritmo en sí, ni en comprimir la población o aumentar la frecuencia del núcleo.

La tensorización de la población es organizar tensores según la dimensión de lote, con las diferencias individuales soportadas por dimensiones del tensor. Pista de respuesta: el bucle objeto por objeto es precisamente lo que se busca abandonar; la tensorización no tiene relación con el número de objetivos ni sacrifica la reproducibilidad.

El beneficio principal de la tensorización de la evaluación es el cálculo por lotes de aptitud, restricciones e indicadores multiobjetivo, reduciendo la sobrecarga de programación y E/S candidato por candidato. Pista de respuesta: no mejora la precisión numérica de una sola evaluación, no puede reemplazar el modelo de simulación, ni significa abandonar el registro.

La gestión unificada del estado de ejecución es para mejorar la reproducibilidad y trazabilidad del experimento. Pista de respuesta: la tensorización de estado gestiona conjuntamente generación, semilla, caché y métricas de monitoreo, no tiene relación con reducir la memoria de video, y tampoco elimina semillas aleatorias ni limita el paralelismo.

El significado del desacoplamiento es que los algoritmos sean componibles, los problemas conectables y el cómputo heterogéneo gestionado de forma unificada. Pista de respuesta: el desacoplamiento libera capacidades de reutilización y paralelismo, no limita los algoritmos a implementaciones seriales, y menos aún elimina la necesidad de hipótesis experimentales y compensación de objetivos.

Primero explicar la reingeniería en cuatro pasos: población, evaluación, estado, grafo computacional y Runtime, y luego señalar las etapas de mejora del rendimiento; la segunda pregunta debe explicar por qué se conservan candidatos diversificados y cómo garantizar la verificabilidad mediante la tensorización de estado y el registro unificado.

Cuando el estudiante acierta, reconocer que puede conectar con los conceptos de esta página y explicar la base; cuando falla, guiarlo de vuelta a la explicación de esta página, encontrar evidencia clave o ejemplos y luego juzgar.

**Actividad en clase**

Se puede pedir a los estudiantes que busquen un escenario de computación evolutiva o evaluación por lotes que conozcan, y determinen si existe un bucle Python explícito; si existe, discutir si se debe priorizar la tensorización en la capa de población, evaluación o estado, y explicar por qué.

**Verificación de comprensión**

Pida aleatoriamente a un estudiante que resuma los puntos clave de esta página con sus propias palabras, y el profesor complementará según la respuesta palabras clave como los tres tipos de tensorización, el Runtime unificado, la superación del cuello de botella serial, la reproducibilidad y la arquitectura desacoplada. Se puede preguntar además: ¿por qué la reproducibilidad no es un elemento adicional? Si la semilla aleatoria, la generación, la caché y las métricas de monitoreo no se registran de forma unificada con el grafo computacional, el beneficio de la aceleración se verá compensado por la falta de trazabilidad.

> **Sugerencia de transición**
>
> Después de confirmar que los estudiantes pueden expresar la relación central de la lista de candidatos al grafo computacional tensorizado, y que pueden distinguir los tres tipos de objetos tensorizados: población, evaluación y estado, pasar a los ejemplos, aplicaciones o resumen de la página siguiente.

--- FIN DEL TEXTO FUENTE ---