# Sistema de Evolución Inteligente EvoX y Práctica Científica AI Native — Material Didáctico del Curso

Duración de la lección: 1 · Páginas de la presentación: 16

## Navegación de Lectura

- [Lección 1｜Tema: Los orígenes de la evolución inteligente y el contexto del nacimiento de EvoX](#lecture-lesson-1)

---

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

## Lección 1｜Tema: Los orígenes de la evolución inteligente y el contexto del nacimiento de EvoX

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

### Los orígenes de la evolución inteligente y el contexto del nacimiento de EvoX

*Página 1*

> **Objetivo de la página:** Explorar el proceso de evolución de la inteligencia humana, la visión de Turing sobre la "máquina niña", y cómo EvoX construye un bucle de evolución entre la capacidad del modelo y la capacidad del sistema.

**Puntos clave de la enseñanza**

- Comprender la profundidad histórica y la velocidad de la evolución inteligente
- Distinguir las limitaciones de la generación única de los grandes modelos y la necesidad de la evolución sistémica

Objetivo de la página

Primero, la profundidad histórica y la velocidad de la evolución inteligente; segundo, la necesidad de pasar de la generación única de grandes modelos a la evolución sistémica. Después del aprendizaje, se debe poder explicar por qué EvoX no se limita a invocar modelos, sino que construye un bucle de evolución entre la capacidad del modelo y la capacidad del sistema.

Orden de explicación

La evolución no es uniforme; los saltos clave suelen ser impulsados por herramientas, lenguaje, colaboración y mecanismos de retroalimentación.

En lugar de crear una mente adulta de una sola vez, es mejor diseñar una máquina que pueda aprender, ser educada y crecer gradualmente. Esto sienta las bases para la perspectiva posterior de "evolución".

Es fuerte en compresión de conocimiento y salida inmediata, pero débil en objetivos sostenidos, memoria a largo plazo, interacción con el entorno, autocorrección y colaboración multi-turno.

Se trata el modelo como un eslabón en la evolución, y a través de tareas, retroalimentación, evaluación, selección e iteración, se construye un bucle cerrado desde la capacidad del modelo hasta la capacidad del sistema.

Puntos clave de la enseñanza

La evolución inteligente tiene profundidad histórica, pero la velocidad de la evolución tecnológica es extremadamente rápida; ambas constituyen el contexto.

Lo clave en la visión de Turing no es que "la máquina se parezca a un niño", sino que "la máquina puede crecer a través de la experiencia".

La generación única es como una instantánea, la evolución sistémica es como un proceso; la instantánea puede ser impresionante, pero solo el proceso puede acumularse.

Lo que EvoX busca resolver no es reemplazar el modelo, sino hacer que el modelo obtenga dirección, memoria y presión selectiva dentro del bucle.

Verificación de comprensión

Se puede pedir a los estudiantes que distingan en una frase "la generación única del modelo" de "la evolución sistémica", y que ejemplifiquen qué eslabón adicional tiene la segunda.

Sugerencia de transición

Si solo se permite al modelo responder una vez, ¿qué le faltaría? A partir de aquí se entra naturalmente en la siguiente parte sobre la capacidad del sistema y el bucle de evolución.

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

### La tendencia acelerada de la evolución inteligente y la compresión de ciclos

*Página 2*

> **Objetivo de la página:** El estudiante debe comprender que la velocidad de la evolución inteligente humana presenta una curva de ascenso abrupto, y que el ciclo de evolución se comprime desde las generaciones genéticas hasta una sola iteración de software e IA.

> **Objetivo de la página**
>
> Comprender la tendencia acelerada y la compresión de ciclos de la evolución inteligente. Lo que esta página busca establecer no es un evento concreto, sino una escala temporal: la evolución no avanza a velocidad uniforme, sino que es un proceso de aceleración impulsado por el cambio de soporte; su velocidad sigue una curva no lineal que se mantiene baja al principio y se eleva abruptamente al final, y el ciclo de evolución se comprime desde las generaciones genéticas hasta una sola iteración de software, cómputo e inteligencia artificial.

> **Orden de explicación**
>
> Primero se observa la forma de la curva, luego se explican las dos cadenas y su correspondencia, después se describe el mecanismo de aceleración, y finalmente se señala el eslabón comprimido —la selección y verificación— y se introduce la necesidad del bucle de evolución.

**Puntos clave de la enseñanza**

- 1. La curva no es una línea recta de ascenso suave, sino un ascenso abrupto no lineal. El eje vertical mide la duración de un solo ciclo de evolución, en cambios de orden de magnitud, por lo que no se puede extrapolar el futuro con intuición lineal, pues se subestimaría sistemáticamente la elevación de la parte final. Acumulación genética → lenguaje y cultura → software, cómputo e inteligencia artificial. Cada migración cambia las condiciones fundamentales: dónde puede existir la información, qué tan rápido puede copiarse, cuánto dura un intento. Generación → año → mes → iteración única. Una ronda completa de "intentar—conservar o eliminar" se acorta de generaciones a años, a meses, y finalmente a una generación, una compilación, una ronda de entrenamiento y evaluación. Donde se traslada el soporte, el ciclo se comprime a ese nivel. Al repasar, usar una cadena para recordar la otra es más efectivo que memorizarlas por separado. 5. El mecanismo de aceleración radica en que el costo unitario y la duración unitaria del circuito "prueba y error—replicación—selección" se reducen continuamente: replicar candidatos es cada vez más barato, verificar una ronda requiere cada vez menos tiempo, y el número de intentos por unidad de tiempo se multiplica. 6. Cuanto más corto el ciclo, más barato generar candidatos
- Pero lo que realmente determina el éxito o el fracaso es siempre "qué candidato es verdaderamente efectivo". Cuando la generación se acelera enormemente, lo que queda comprimido relativamente es precisamente la selección y verificación, que pasa de ser una premisa implícita a un cuello de botella explícito. La línea discontinua gris en la figura representa el retraso relativo del "costo de selección y verificación". 7. Una generación única no puede autoprobar su corrección, ni mantenerse efectiva cuando el entorno y el modelo cambian constantemente. Lo que señala es una interfaz constituida por un bucle de evolución de generación, retroalimentación del entorno, evaluación y selección, y herencia. ¿La inteligencia es un producto diseñado de antemano, o un proceso que se forma continuamente en el entorno? Esta página solo se encarga de establecer esta escala temporal; el desarrollo del problema se deja para contenidos posteriores.

**Cobertura de palabras clave**

- Evolución inteligente
- Migración de soporte
- Compresión de ciclos
- Aceleración no lineal
- Cuello de botella de selección y verificación
- Bucle de evolución.

> **Pistas de materiales**
>
> - Gráfico de líneas o gráfico escalonado con el eje horizontal como eras temporales y el eje vertical como duración de un ciclo de evolución (escala logarítmica), con cuatro escalones correspondientes a acumulación genética, lenguaje y cultura, software y cómputo, e iteración única de grandes modelos
> - La línea discontinua gris representa el retraso relativo del costo de selección y verificación. Al explicar, se puede usar un gesto descendente a lo largo de los escalones, enfatizando "el ciclo se contrae hacia abajo, la aceleración se eleva hacia arriba".

> **Pistas de ejercicios**
>
> - La causa fundamental de la aceleración es el cambio de soporte evolutivo, desde los genes al lenguaje y la cultura, y luego al software, el cómputo y la inteligencia artificial
> - No es que los individuos sean más diligentes, que el volumen total de datos aumente o que el hardware sea más barato. El orden correcto de la cadena de compresión de ciclos es "generación → año → mes → iteración única". La comprensión adecuada es que la curva presenta un ascenso abrupto no lineal, y no se puede extrapolar linealmente la velocidad de evolución futura. Tras la compresión de ciclos, lo que más necesita redistribuir la atención es el eslabón de selección y verificación, que "determina qué candidato es verdaderamente efectivo". Una generación única carece de la verificación repetida del entorno y de la selección evaluativa, por lo que no puede formar un bucle heredable.

**Tratamiento de ejercicios**

Primero se pide a los estudiantes que juzguen de forma independiente, y luego que expliquen su fundamento. Si se equivocan, se les guía de vuelta a las dos evidencias clave: "cambio de soporte" y "generación barata, juicio comprimido". En el análisis de caso se puede sugerir: el cambio que perciben los investigadores proviene de la migración de soporte; el conocimiento ya no reside principalmente en artículos y en la memoria humana, sino en repositorios de código, recursos de cómputo y pesos de modelos; con la migración de soporte viene la compresión de ciclos, una ronda completa se acorta de semestres a horas. El cuello de botella se traslada a la selección y verificación; una generación única no puede sustituir el bucle de evolución continua, porque las conclusiones necesitan ser verificadas repetidamente en el entorno y sedimentarse como base de selección heredable.

**Verificación de comprensión**

Se pide a los estudiantes que digan en una frase el núcleo de esta página. Una formulación válida debe incluir "el cambio de soporte impulsa la aceleración" y "generar es cada vez más barato, el juicio se convierte en cuello de botella"; si solo pueden decir "los modelos son cada vez más fuertes", es necesario volver a la curva y a las dos cadenas.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden distinguir la cadena de migración de soporte de la cadena de compresión de ciclos, y comprenden el cuello de botella de selección y verificación, se pasa a la siguiente página sobre el desarrollo del bucle de evolución.

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

### Las poderosas capacidades actuales de los grandes modelos y las limitaciones de la generación única

*Página 3*

> **Objetivo de la página:** El estudiante debe reconocer que, aunque los grandes modelos actuales poseen poderosas capacidades de comprensión y generación, una generación única no puede autoprobar su corrección y difícilmente se adapta de manera continua al cambio.

> **Objetivo de la página**
>
> Distinguir las limitaciones de la generación única de los grandes modelos y la necesidad de la evolución sistémica. El núcleo es que los estudiantes distingan "la capacidad de generar contenido" de "la capacidad del sistema para hacer que el contenido sea verificado e iterado": el modelo es fuerte, pero sin ejecución, verificación, evaluación, retroalimentación y herencia, la salida sigue siendo solo una sugerencia desechable.
>
> Primero se afirma la fuerte comprensión, generación y razonamiento de los grandes modelos, luego se señalan las tres limitaciones de la generación única, después se explica con un plan de reducción de latencia por qué no se puede poner en producción directamente, y finalmente se resume el bucle de evolución, retomando la visión de la "máquina niña" de Turing.

**Puntos clave de la enseñanza**

- El modelo puede formar rápidamente explicaciones, planes y contenido candidato; es un eficiente "generador de posibilidades". No puede autoprobar su corrección, porque carece de ejecución, verificación y evaluación independiente
- No puede autoactualizarse, porque cuando el entorno, las restricciones o los objetivos cambian, no reevalúa automáticamente
- No puede autoacumularse, porque una salida no produce experiencia heredable. 3. Por lo tanto, el cuello de botella a menudo no está en si el modelo "sabe o no", sino en si la capacidad inteligente se incorpora a un proceso explorable, ejecutable, verificable e iterable. Generación → ejecución y verificación → evaluación → selección/mutación → regeneración. Solo explicando las entradas, salidas y señales de juicio de cada paso, los estudiantes pueden entender cómo se acumula la capacidad en el bucle. 5. En el diagrama comparativo, el lado izquierdo representa la generación única "que termina aquí", y el lado derecho representa el bucle de evolución "que itera continuamente, con evaluación sistémica y herencia", lo que sirve para destacar la diferencia entre una respuesta única y la evolución continua. Un equipo quiere reducir la latencia del servicio de inferencia en línea; el modelo da una vez sugerencias de poda, cuantización y destilación, pero solo introduciéndolas en el hardware objetivo, las restricciones de precisión y las fluctuaciones de carga, y luego iterando según la retroalimentación, se pueden obtener candidatos verificables y evolucionables.

**Cobertura de palabras clave**

- Limitaciones de los grandes modelos, generación única, autoprobación de corrección, retroalimentación continua, bucle de evolución, selección/mutación, evaluación sistémica y herencia.

**Tratamiento de ejercicios**

La generación única es una salida desechable y abierta; no puede autoprobarse porque carece de ejecución, verificación, señales de retroalimentación y evaluación independiente; un plan desechable se queda en los supuestos del momento de la generación; el primer paso ante un problema real es transformarlo en un proceso explorable, ejecutable y verificable; la estructura del bucle es generación, ejecución y verificación, evaluación, selección/mutación, regeneración. En el caso de "plan de reducción de latencia", se puede pedir a los estudiantes que en grupos escriban los pasos del bucle y las entradas y salidas de cada paso, y que verifiquen si incluye un entorno de verificación ejecutable, métricas de evaluación cuantificables y un mecanismo de regeneración basado en retroalimentación. Si los estudiantes atribuyen el problema a falta de cómputo o a indicaciones poco detalladas, se les recuerda que el cuello de botella está en la capacidad del sistema; si solo escriben "iteración" sin señales de evaluación, se les pide añadir métricas para juzgar lo bueno y lo malo.

Se pide a los estudiantes que con un ejemplo familiar repitan "las tres incapacidades", y luego digan en qué situaciones es obligatorio introducir el bucle de evolución. Se pide aleatoriamente a un estudiante que resuma los puntos clave de esta página con sus propias palabras, y el profesor complementa las palabras clave omitidas según la respuesta.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar la diferencia entre la generación única y el bucle de evolución, se pasa a la siguiente página para discutir el origen histórico o las aplicaciones concretas del pensamiento evolutivo.

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

### La convergencia de las rutas inteligentes y los orígenes de la computación evolutiva

*Página 4*

> **Objetivo de la página:** El estudiante debe comprender el punto de convergencia de las diferentes rutas de desarrollo de los sistemas inteligentes, y la posición de la computación evolutiva como fuente técnica central.

> **Objetivo de la página**
>
> Comprender por qué múltiples rutas de desarrollo de sistemas inteligentes convergen en el nivel sistémico, y por qué la computación evolutiva se considera la fuente técnica más directa en este punto de convergencia; al mismo tiempo, establecer la perspectiva meta de "algoritmos que optimizan algoritmos", y aprender a evaluar una ruta por su costo de migración.

> **Orden de explicación**
>
> Cuando el cómputo y la capacidad del modelo ya no son escasos, el problema central pasa de ser un problema de muestreo de "generar una buena respuesta una vez" a un problema de búsqueda de "cómo buscar, retroalimentar y filtrar continuamente". Se puede señalar: una generación única no puede autoprobar su corrección, ni mantenerse efectiva tras cambios en el entorno o el modelo.
>
> Las dimensiones de comprensión, expresión, acción-retroalimentación y selección de resultados no pueden cerrar el bucle por sí solas; la comprensión se calibra con retroalimentación, la acción converge mediante la selección de resultados, la expresión se verifica en el entorno. Por eso vuelven a converger en el nivel sistémico, formando la cadena de observación "plantear el problema → generar candidatos → retroalimentación del entorno → evaluación y filtrado → retener y regenerar".
>
> Población, mutación, selección e iteración corresponden naturalmente al bucle de "generación—evaluación—retención—regeneración", por lo que es el mecanismo que hace funcionar el bucle, y no otra forma de capacidad expresiva.
>
> La mutación, el cruce y la selección cambian las soluciones candidatas, pero rara vez cambian "el método que produce las soluciones candidatas"; la capa meta permanece durante mucho tiempo en la etapa de diseño manual; el algoritmo es bueno buscando respuestas, pero no es bueno buscándose a sí mismo. Se puede usar la evolución diferencial para ilustrar: la selección de la estrategia de mutación, el vector base, el factor de mutación y la probabilidad de cruce, y el ajuste de parámetros, ocurren fuera de la búsqueda, no son reutilizables y difícilmente se sedimentan.
>
> Se hace que el método de resolución mismo entre también en el proceso de búsqueda, es decir, "algoritmos que optimizan algoritmos"; el algoritmo pasa de ser una herramienta a ser un objeto buscado y mejorado. EvoX es el vehículo que sistematiza esta perspectiva; los detalles de arquitectura se dejan para páginas posteriores.

**Puntos clave de la enseñanza**

- Al evaluar una ruta inteligente, no solo se mira la capacidad expresiva de una vez, sino también si puede formar un bucle sostenible y automajorable, y si tras la deriva del problema puede seguir buscando a un costo menor. No es si puede generar, sino si puede buscar, retroalimentar y filtrar continuamente. ¿Lo que se cambia son solo las soluciones candidatas, o también "el método que produce las soluciones candidatas"? Solo lo segundo cuenta como entrar en "algoritmos que optimizan algoritmos". Los mecanismos adaptativos y de autotuning suelen reducir el costo de migración, pero traen consigo sobrecarga computacional adicional y menor interpretabilidad; este es un compromiso que hay que pensar con antelación.

> **Pistas de materiales**
>
> - El diagrama de la página muestra múltiples rutas inteligentes convergiendo en un problema sistémico, y luego conectándose con "computación evolutiva: la fuente técnica más directa"
> - Al mismo tiempo, se marca con línea discontinua naranja el circuito de la capa meta, enfatizando que los algoritmos evolutivos tradicionales carecen de él. Al explicar, se puede usar el diagrama para mostrar la diferencia de nivel entre el "algoritmo actual" y "el método que genera y selecciona soluciones candidatas".

**Tratamiento de ejercicios**

La respuesta a la pregunta 1 recae en "pasar de un problema de muestreo a un problema de búsqueda", enfatizando que el cuello de botella es la búsqueda, retroalimentación y filtrado continuos, no los datos, el cómputo o la escala de etiquetado.

La respuesta a la pregunta 2 es que ninguna dimensión puede cerrar el bucle por sí sola y necesita acoplarse a nivel sistémico; no se debe elegir nomenclatura, costo u orden histórico.

La respuesta a la pregunta 3 es que el mecanismo de la computación evolutiva corresponde uno a uno con la estructura del bucle cerrado del sistema; no es velocidad, ausencia de parámetros o campo de aplicación.

La respuesta a la pregunta 4 es que cambia las soluciones candidatas, pero rara vez cambia el método que produce las soluciones candidatas; la capa meta depende del diseño manual; el punto ciego es que el método mismo no es buscado.

La respuesta a la pregunta 5 es que la selección y el ajuste de parámetros ocurren fuera de la búsqueda y difícilmente se sedimentan, lo que muestra que el algoritmo mismo no entra en el proceso de búsqueda; el punto clave no es la densidad de barrido de parámetros ni la automatización total.

En el caso de programación de taller, los parámetros de la evolución diferencial dejan de ser efectivos por la incorporación de restricciones de cambio de formato y ventanas de tiempo de dos turnos, lo que refleja la ausencia de la capa meta. Si se hace que el método entre en la búsqueda, se puede usar autoadaptación o autotuning para reconstruir automáticamente estrategias y parámetros, reduciendo el costo de migración y los experimentos repetidos; el precio es la sobrecarga computacional adicional y la menor interpretabilidad. El compromiso consiste en: intercambiar cómputo e interpretabilidad por un menor costo de migración cuando el problema deriva.

**Verificación de comprensión**

Se pide a los estudiantes que distingan con sus propias palabras "buscar respuestas" de "buscar el método que produce respuestas", y que digan por qué esta página sitúa la computación evolutiva como la fuente técnica más directa en el punto de convergencia.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar la línea principal "convergencia de múltiples rutas—la computación evolutiva corresponde al bucle—los algoritmos tradicionales carecen de capa meta—algoritmos que optimizan algoritmos", se pasa al contenido posterior sobre la arquitectura de EvoX.

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

### La visión de la "máquina niña" de Turing

*Página 5*

> **Objetivo de la página:** El estudiante debe comprender la visión de la "máquina niña" propuesta por Turing en 1950 y su idea de que la capacidad se adquiere en el entorno mediante educación y recompensas y castigos.

> **Objetivo de la página**
>
> Comprender la visión de la "máquina niña" propuesta por Turing en 1950: la máquina parte de un estado incompleto similar al de un niño, y mediante educación, experimentación y recompensas y castigos adquiere capacidades gradualmente en el entorno, entendiendo así la inteligencia como "un proceso en continua formación", y no como "un producto previamente diseñado".

> **Orden de explicación**
>
> Primero se señala en una frase la ruta alternativa que propuso Turing en su momento, luego se usa el diagrama comparativo izquierda-derecha para explicar las dos fuentes de capacidad; después se desarrollan los tres juicios clave; luego se aterriza en el significado ingenieril actual, añadiendo el bucle externo; finalmente se aclaran las malinterpretaciones comunes y se consolidan con ejercicios.

**Puntos clave de la enseñanza**

- En 1950, al discutir "¿pueden pensar las máquinas?", Turing propuso una ruta alternativa con gran sentido ingenieril: en lugar de construir de una vez una mente madura como la de un adulto, es mejor construir primero una "máquina niña". Al salir de fábrica no está completa, sino que es "criada" en el entorno, pasando por educación, experimentación y recompensas y castigos, y así sus capacidades crecen gradualmente. El giro clave de esta página es: la inteligencia no es un resultado escrito de antemano, sino un proceso moldeado por el entorno. El lado izquierdo, "producto previamente diseñado", sigue la ruta análisis de requisitos → diseño de módulos → fijación de parámetros → despliegue en línea (unidireccional), la capacidad se fija en la entrega y no se autocambia durante la operación
- El lado derecho, "proceso formado en el entorno", sigue el ciclo educación → experimentación → recompensas y castigos, y la capacidad se genera gradualmente. La recompensa retiene comportamientos efectivos, el castigo elimina estrategias ineficaces. Al explicar, se puede pedir a los estudiantes que primero describan las diferencias entre ambos lados, y luego resumir en "la capacidad se escribe de antemano" y "la capacidad se genera gradualmente en la retroalimentación del entorno". La capacidad no se diseña previamente ni se escribe de una vez
- La inteligencia es un proceso en continua formación; evaluar un sistema depende de si puede volverse mejor en la interacción continua
- La retroalimentación del entorno es el mecanismo central de generación de capacidad; las estrategias de comportamiento se filtran repetidamente en el ciclo "educación → experimentación → recompensas y castigos". Los grandes modelos son buenos generando, pueden dar de una vez una gran cantidad de respuestas posibles, pero el resultado de una generación única no puede autoprobar su corrección, ni mantenerse efectivo tras cambios en el entorno. ¿Quién verifica, quién elimina, quién retiene? Esto requiere un bucle externo: el modelo genera posibilidades → el entorno proporciona retroalimentación → el sistema evalúa, selecciona y hereda. Esta es precisamente la interfaz entre esta página y el bucle de evolución posterior. No se debe tomar la "máquina niña" como una estructura de red específica o el nombre de un algoritmo de entrenamiento concreto; lo que ofrece es una tesis metodológica sobre el origen de la capacidad.

**Cobertura de palabras clave**

- Máquina niña, educación, experimentación, recompensas y castigos, proceso y no producto, retroalimentación del entorno, bucle externo, evaluación—selección—herencia.

> **Pistas de materiales**
>
> - El concepto central es "la visión de la máquina niña de Turing", el término central es "máquina niña", y se puede acompañar de un diagrama comparativo para explicar la diferencia entre "la capacidad se escribe de antemano" y "la capacidad se genera gradualmente en la retroalimentación del entorno". Las cinco preguntas de opción múltiple de la página verifican respectivamente "la tesis central", "el papel de la retroalimentación del entorno", "el cambio metodológico desde la perspectiva del proceso", "la falta de un bucle externo" y "la explicación del origen de la capacidad". Al acertar, enfatizar el fundamento
> - Al fallar, llevar al estudiante de vuelta a la frase original: no se exige que sea completa desde el principio, sino que la capacidad crezca gradualmente en la interacción con el entorno, y distinguir "definido al salir de fábrica" de "formado gradualmente"
> - El problema no está en la longitud de la indicación, la cantidad de parámetros o el cómputo, sino en la falta de un bucle que permita que los resultados sean verificados, filtrados y retenidos. En la pregunta de caso "¿De dónde viene la capacidad del robot de almacén?", se sugiere pedir primero a los estudiantes que marquen las diferencias entre el plan A y el plan B, y luego responder en correspondencia con los tres eslabones: educación, experimentación y recompensas y castigos
> - La segunda pregunta debe recaer en "una generación única no puede autoprobar su corrección y difícilmente es efectiva a largo plazo", y explicar cómo el bucle retiene estrategias efectivas y elimina estrategias ineficaces.

**Actividad en clase**

Se pide a los estudiantes que con un ejemplo cercano a su propia experiencia repitan "educación → experimentación → recompensas y castigos", y que expliquen su relación con "proceso y no producto".

**Verificación de comprensión**

Se pide aleatoriamente a un estudiante que resuma los puntos clave de esta página con sus propias palabras, y el profesor complementa las palabras clave omitidas según la respuesta.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar la cadena "generación única → retroalimentación del entorno → evaluación, selección y herencia del sistema", se pasa a la siguiente página de aplicación o resumen.

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

### La nueva fuente de generación de candidatos bajo la expansión de la escala de cómputo

*Página 6*

> **Objetivo de la página:** El estudiante debe comprender cómo, al abrirse la escala de cómputo, los grandes modelos ayudan al sistema a producir planes candidatos estructurados más ricos.

**Puntos clave de la enseñanza**

- Recordar las tres nuevas fuentes de generación de candidatos: exploración paralela en GPU, construcción estructurada por grandes modelos, y participación del modelo en codificación y mutación. Resuelven respectivamente los problemas de búsqueda paralela, generación de estructuras complejas y automatización de reglas de mutación.
- Antes de comenzar la evolución, preguntarse tres cosas: ¿qué puede cambiarse? ¿qué puede observarse? ¿qué criterio determina la retención? Si estas tres preguntas no tienen respuesta, la evolución perderá dirección.
- Al evaluar, seguir el principio de estratificación: las evaluaciones de bajo costo se paralelizan tanto como sea posible; las evaluaciones de alto costo se aproximan con modelos sustitutos. Así se equilibra el costo computacional y la precisión de la evaluación, y se amplía el espacio de candidatos explorable.

Objetivo de la página

El sistema ya no solo se preocupa por "si puede generar una respuesta", sino que además pregunta "qué cambios pueden generarse, observarse, retenerse y heredarse". El núcleo de esta página es comprender las tres nuevas fuentes —exploración paralela en GPU, construcción estructurada por grandes modelos, y participación del modelo en codificación y mutación— dentro de la definición de límites antes de entrar en la evolución, la evaluación estratificada, la preservación de resultados y el bucle de EvoX.

Orden de explicación

Primero se usan "las tres nuevas fuentes" para explicar de dónde vienen los candidatos, luego se explican los tres tipos de límites que deben aclararse antes de que los candidatos entren en la evolución, después se explica cómo se estratifica la evaluación, y finalmente se conectan la estructura evolucionable, la preservación de resultados y el bucle de EvoX. Así los estudiantes pueden ver primero la expansión del espacio de candidatos, y luego entender por qué la evolución necesita dirección, criterios y memoria.

Puntos clave de la enseñanza

1. Las tres nuevas fuentes de generación de candidatos

Una gran cantidad de posibilidades se exploran simultáneamente; la generación de candidatos pasa del ensayo y error en serie a la búsqueda en el espacio paralelo. Por ejemplo, en el espacio de parámetros se muestrean simultáneamente miles de puntos y se evalúan en paralelo. Principalmente resuelve el problema de la "búsqueda paralela".

Los grandes modelos pueden comprender lenguaje natural y código, y construir planes candidatos de estructura compleja, no solo generar respuestas de texto. Pueden generar programas completos, casos de prueba o configuraciones de sistema. Principalmente resuelven el problema de la "generación de estructuras complejas".

La codificación y las formas de mutación comienzan a ser generadas con la participación del modelo. La fuente de candidatos se expande de reglas escritas por humanos a reglas y estructuras generadas por el modelo, por ejemplo, haciendo que el modelo proponga nuevos operadores de mutación o estrategias de codificación. Principalmente resuelve el problema de la "automatización de reglas de mutación".

Estas tres no se sustituyen entre sí, sino que juntas amplían la fuente de candidatos. La expansión del cómputo no solo aumenta la velocidad de generación, sino que cambia la naturaleza misma de la generación de candidatos.

2. Definición de límites antes de entrar en la evolución

Antes de que los candidatos entren en la evolución, deben responderse tres preguntas:

¿Lo evolucionable es la estructura del código, los hiperparámetros, o toda la arquitectura?

¿Cómo se definen y recogen métricas como precisión, latencia y consumo de recursos?

Por lo general se requiere una función de evaluación multiobjetivo o umbrales.

Si estas tres preguntas no tienen respuesta, la evolución perderá dirección. Por lo tanto, la definición de límites debe preceder al inicio de la evolución.

3. Estrategia de evaluación estratificada

La evaluación necesita estratificarse:

Las evaluaciones paralelizables se paralelizan tanto como sea posible.

Las evaluaciones costosas se reducen con modelos sustitutos.

Por ejemplo, las métricas de rendimiento simples pueden calcularse en paralelo en GPU; las evaluaciones costosas que requieren interacción con el entorno real se aproximan con modelos sustitutos. Así se equilibra el costo computacional y la precisión de la evaluación bajo un cómputo limitado, y se amplía el espacio de candidatos explorable.

4. Identificación de estructuras evolucionables y preservación de resultados

Es necesario identificar qué estructuras de los métodos existentes pueden evolucionar aún más, en lugar de ajustar solo parámetros numéricos. Por ejemplo, tomar como objetos mutables la forma de conexión de módulos en la red neuronal y la estructura de flujo de control del código. Al mismo tiempo, deben guardarse el código, las pruebas y la evidencia de verificación, para que la siguiente ronda no tenga que empezar de cero y se evite el trabajo repetido.

5. Conexión con el bucle de EvoX

El modelo propone candidatos, las herramientas ejecutan cambios, el entorno devuelve retroalimentación, el mecanismo evolutivo completa la selección, el Runtime organiza el cómputo, y el sistema persistente hereda los resultados que han pasado la verificación. Así, los componentes inteligentes dispersos se acumulan continuamente, formando un sistema en evolución constante.

Pistas de materiales

El diagrama de flujo de esta página puede ayudar a los estudiantes a encadenar "tres nuevas fuentes → generación de candidatos → evaluación → selección → persistencia". Al explicar, se puede usar la frase del diagrama "núcleo: qué cambios pueden generarse, observarse, retenerse y heredarse" como cierre, y luego conducir a la "transformación clave": pasar de "si puede generar" a "qué genera, cómo se observa, cómo se retiene, cómo se hereda".

Pistas de ejercicios

Los ejercicios de esta página verifican principalmente si los estudiantes pueden distinguir las tres nuevas fuentes y explicar su papel con evidencia o ejemplos. Al tratarlos, no hay que quedarse en la memorización de términos, sino hacer que los estudiantes digan escenarios concretos.

Una respuesta razonable debe conectarse con "búsqueda simultánea de una gran cantidad de candidatos, muestreo y evaluación paralelos", en lugar de cambiar todos los factores a la vez para comparar resultados.

Una respuesta razonable debe ejemplificar que un gran modelo puede generar programas, casos de prueba o configuraciones de sistema, y no solo respuestas de texto.

Una respuesta razonable debe explicar que el modelo puede proponer nuevos operadores de mutación o estrategias de codificación, ampliando la fuente de candidatos de reglas manuales a reglas generadas por el modelo.

Si aciertan, se pide a los estudiantes que añadan un ejemplo para demostrar comprensión; si fallan, se les guía de vuelta a la explicación de esta página, para encontrar la evidencia clave o el ejemplo antes de juzgar, evitando conclusiones solo por intuición.

Tratamiento del caso

El caso exige aplicar los conceptos de esta página a una "tarea de optimización conectada a EvoX".

Qué objetos pueden cambiarse, por ejemplo, el tipo de capa de red, la forma de conexión, los hiperparámetros o solo parámetros numéricos; qué resultados pueden observarse, por ejemplo, la precisión en el conjunto de validación, la latencia de inferencia, la cantidad de parámetros; qué criterio determina la retención, por ejemplo, umbrales multiobjetivo o puntuación ponderada.

Guardar el código, las pruebas y la evidencia de verificación que han pasado la verificación en el sistema persistente; la siguiente ronda puede partir de estructuras ya verificadas y evitar trabajo repetido; el modelo puede proponer nuevos candidatos basados en estructuras exitosas históricas, y la evaluación paralela en GPU también puede reutilizar resultados existentes, acelerando así el bucle de evolución.

Verificación de comprensión

¿Pueden decir las tres nuevas fuentes? ¿Pueden responder las tres preguntas de límite antes de entrar en la evolución? ¿Pueden explicar el principio de estratificación de la evaluación? ¿Pueden decir el papel del sistema persistente en la herencia de resultados? Si los estudiantes solo recuerdan los nombres, se les puede preguntar por un ejemplo concreto, por ejemplo, "en la búsqueda de arquitecturas de redes neuronales, ¿qué objetos pueden cambiarse? ¿qué métricas pueden observarse? ¿qué resultados merecen guardarse?"

Sugerencia de transición

Tras confirmar que los estudiantes pueden expresar la relación entre "las tres nuevas fuentes, los tres tipos de límites, la evaluación estratificada y la herencia de resultados del bucle de EvoX", se pasa a la siguiente página de ejemplos, aplicaciones o resumen.

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

### La expansión del objeto de evolución desde parámetros numéricos hasta sistemas de software

*Página 7*

> **Objetivo de la página:** El estudiante debe comprender que el objeto de evolución ha superado los parámetros numéricos y se ha extendido a programas, estructuras de modelos, mecanismos de algoritmos y estados de ingeniería de software.

> **Objetivo de la página**
>
> Comprender que el objeto de evolución ya no se limita a parámetros numéricos, sino que se ha extendido a programas, estructuras de modelos, mecanismos de algoritmos e incluso estados de ingeniería de software; al mismo tiempo, captar el desplazamiento del centro de gravedad en los dos eslabones de "generación" y "evaluación", y los compromisos ingenieriles que ello conlleva.

> **Orden de explicación**
>
> Primero se vuelve a la práctica típica de la computación evolutiva temprana: los objetos evolucionados eran casi todos parámetros numéricos, como la tasa de aprendizaje, el tamaño de lote, la intensidad de regularización, la forma de inicialización de pesos. En ese momento el espacio de búsqueda era un conjunto de números, y la evaluación era un entrenamiento más una validación. Luego se señala que, con el aumento de la escala de cómputo y la madurez de la capacidad de los grandes modelos, los objetos evolucionables se amplían claramente, formando una cadena de expansión clara: parámetros numéricos → programas y estructuras de modelos → estados de ingeniería de software y candidatos a nivel de sistema. Cuanto más a la derecha, mayor capacidad expresiva, más tipos de cambios puede cubrir, y por eso la evolución a nivel de sistema se vuelve posible. Finalmente se aterriza en la realidad ingenieril de que "la carga de evaluación aumenta en sincronía", recordando a los estudiantes: más candidatos no equivale a mejor evolución; la clave está en si los dispositivos de ejecución y evaluación se actualizan en sincronía.

**Puntos clave de la enseñanza**

- Primer nivel, parámetros numéricos. El candidato es un conjunto de números, barato de generar y rápido de evaluar; normalmente un entrenamiento más una validación basta para puntuar. Pero solo puede responder "¿está bien ajustado?", no puede añadir un mecanismo que faltaba desde el principio. Segundo nivel, programas y estructuras de modelos. El candidato es la estructura de red, combinaciones de operadores, flujos de trabajo de indicaciones o parches de código; los cambios alteran "qué puede hacer el sistema", no solo "con cuánta precisión lo hace". La evaluación pasa entonces a ejecución en sandbox y pruebas de regresión. Tercer nivel, estados de ingeniería de software y candidatos a nivel de sistema. El candidato es la configuración, las versiones de dependencias, los contratos de interfaz, las estrategias de despliegue y operación, que determinan directamente si el sistema puede funcionar de forma estable y ser reproducido. La evaluación pasa a la comparación con referencia y la comprobación de reproducibilidad. La generación determina qué tan grande es el espacio de candidatos, la evaluación determina cuáles pueden quedarse. Cuando el candidato pasa de número a programa, "generar candidatos" deja de ser el cuello de botella: los grandes modelos pueden producir en lote estructuras, mecanismos y parches
- Quien puede hacer que el candidato realmente se ejecute, y quien puede juzgar a un costo aceptable si merece retenerse. El aislamiento de ejecución en sandbox, las pruebas de regresión, la comparación con métricas de referencia, las restricciones de costo y riesgo, y el registro de reproducibilidad son precisamente los dispositivos ingenieriles que restringen costo, riesgo y reproducibilidad, y permiten que los cambios se retengan o eliminen de forma estable. Equiparar directamente "más candidatos" con "evolución más efectiva". El aumento del número de candidatos solo amplía el alcance de la búsqueda
- Solo cuando el mecanismo de ejecución y evaluación es capaz de filtrar cambios inválidos, más candidatos se convierten en un mejor sistema. En otras palabras, cuanto mayor la capacidad expresiva, mayor la carga de evaluación; beneficios y costos deben mirarse juntos.

**Tratamiento de ejercicios**

La pregunta 1 pregunta "el cambio más central en la expansión del objeto de evolución"; la respuesta correcta es "pasar de ajustar solo parámetros numéricos a extenderse a programas, estructuras de modelos, mecanismos de algoritmos y estados de ingeniería de software". Se puede sugerir a los estudiantes que capten "el objeto evolucionado mismo experimenta un salto de nivel", mientras que el entrenamiento distribuido y los cambios de paradigma de aprendizaje son medios de implementación.

La pregunta 2 pregunta "por qué más candidatos no equivale a evolución más efectiva"; la respuesta correcta es "porque solo cuando el mecanismo de ejecución y evaluación puede filtrar cambios inválidos, más candidatos se convierten en un mejor sistema". Punto de retroalimentación: el aumento del número de candidatos amplía el alcance de la búsqueda; si los cambios efectivos pueden quedarse depende de si dispositivos de evaluación como sandbox, pruebas de regresión y referencias se actualizan en sincronía.

La pregunta 3 pregunta "por qué se necesitan sandbox, pruebas de regresión y referencias"; la respuesta correcta es "para juzgar, a un costo controlable, si el candidato es efectivo, si trae riesgo y si el resultado puede reproducirse". Se puede añadir: el candidato es un programa directamente ejecutable, por lo que primero debe ejecutarse aislado, luego verificarse con regresión, y después compararse con la línea base.

La pregunta 4 pregunta "el cambio de centro de gravedad entre generación y evaluación"; la respuesta correcta es "con el fortalecimiento de la capacidad de los grandes modelos, el problema clave pasa de cómo generar candidatos a cómo ejecutar y evaluar, y retener cambios efectivos". Se recuerda a los estudiantes: la mejora de la capacidad de generación sigue siendo una premisa, pero lo que decide el éxito o el fracaso de la evolución ya se inclina hacia los mecanismos de ejecución y evaluación.

La pregunta 5 pregunta "tras expandir el objeto de evolución de hiperparámetros a flujos de trabajo de indicaciones, ¿qué debería completarse en sincronía?"; la respuesta correcta es "dispositivos de ejecución y evaluación como sandbox, pruebas de regresión y referencias, y hacer bien el compromiso entre costo, riesgo y reproducibilidad". Se puede preguntar: ¿qué pasa si se siguen acumulando candidatos? Se agrava la carga de evaluación; comprimir los candidatos a uno solo abandona el sentido de la búsqueda; la clave es actualizar el mecanismo de evaluación.

Se puede organizar la discusión con el escenario "el servicio de recomendación pasa de hiperparámetros a parches de código". La primera pregunta, "por qué la producción de candidatos es más rápida pero la proporción de adopción disminuye", se guía desde el desplazamiento del centro de gravedad: generar ya no es el eslabón más ajustado; el cuello de botella se traslada a la ejecución y la evaluación; el candidato es un programa y no un número, por lo que primero debe ejecutarse en un entorno controlado, luego pasar por pruebas de regresión y comparación con referencias, para poder juzgar efectividad, seguridad y reproducibilidad. La segunda pregunta, "qué dispositivos ingenieriles completar y qué tipo de riesgo restringe cada uno", puede resumirse así: el aislamiento de ejecución en sandbox restringe el riesgo de "contaminar el sistema existente, las dependencias o el entorno en línea"; las pruebas de regresión restringen el riesgo de "que los cambios rompan funciones existentes"; la comparación con métricas de referencia restringe el riesgo de juicio erróneo de "parecer mejor sin mejora real";

el presupuesto de costo y el control de tiempo de espera restringen el riesgo de costo de "que la evaluación misma se descontrole"; el registro de semillas y resultados restringe el riesgo de "resultados no reproducibles". En conjunto, se trata de un compromiso entre capacidad expresiva, costo de evaluación, reproducibilidad y seguridad, y no de perseguir simplemente la cantidad de candidatos.

**Verificación de comprensión**

Se pide a los estudiantes que repitan con sus propias palabras la cadena de expansión, y que expliquen por qué "cuando el nivel del objeto sube, los dispositivos de evaluación deben actualizarse en sincronía". Si además pueden explicar que "la generación determina el espacio de candidatos, la evaluación determina quién se queda", se cumple el requisito central de esta página.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar las formas candidatas y los métodos de evaluación de los tres niveles de objetos de evolución, y pueden usar el marco "generación—evaluación—retención/eliminación" para explicar por qué más candidatos no equivale automáticamente a mejor evolución, se pasa a la siguiente página de ejemplos, aplicaciones o resumen.

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

### La complejidad del mundo real y el compromiso multiobjetivo

*Página 8*

> **Objetivo de la página:** El estudiante debe comprender que en el mundo real múltiples objetivos se condicionan mutuamente, y que el sistema no debe dar prematuramente una única solución óptima, sino retener planes candidatos diferenciados.

**Puntos clave de la enseñanza**

- Escribir primero los límites que deben cumplirse, por ejemplo, el límite superior de latencia de extremo a extremo y el presupuesto de costo unitario. Cualquier candidato que viole los límites, aunque alguna métrica sea muy destacada, no debe retenerse; solo los candidatos dentro de la región factible tienen derecho a participar en la comparación multiobjetivo.
- Al comparar dos candidatos, hacer primero un juicio por pares: ¿existe un candidato que no sea peor en todos los objetivos y además sea mejor en al menos uno? Si es así, el que es superado en todos los aspectos puede eliminarse; si no, ninguno domina al otro y ambos deben retenerse. Así, el conjunto de candidatos obtenido no pierde información de compromiso.
- Retener un conjunto de candidatos claramente diferenciados es para tener margen de elección cuando cambie el escenario o se ajusten las prioridades. Converger prematuramente a una respuesta puntual parece limpio y eficiente a corto plazo, pero una vez que el entorno o los requisitos cambian, a menudo se paga un precio mayor por volver a explorar.

> **Objetivo de la página**
>
> Comprender que en el mundo real la optimización multiobjetivo rara vez tiene una única solución óptima; captar el significado de restricciones duras, región factible, soluciones no dominadas y frente de Pareto; comprender por qué EvoX debe retener un conjunto de candidatos diferenciados y situar el juicio del investigador por encima de la implementación en código.
>
> Orden de explicación y puntos clave de la enseñanza:
>
> Un mismo sistema suele perseguir simultáneamente rendimiento, latencia, consumo energético y costo, y estos objetivos se condicionan mutuamente. Aumentar la precisión suele aumentar el cómputo y el consumo energético, y con ello la latencia y el costo; reducir la latencia a menudo sacrifica precisión. No hay mejoras gratis, por lo que los problemas reales de optimización rara vez tienen una sola respuesta.
>
> El eje horizontal representa latencia, costo y consumo energético; el eje vertical representa precisión y rendimiento. Los puntos sobre la curva discontinua son soluciones no dominadas y constituyen el frente de Pareto; los puntos grises por debajo de la curva son soluciones dominadas y pueden eliminarse. En el frente deben retenerse tanto los planes de baja latencia y baja precisión, como los planes de compromiso equilibrado y los de alta precisión y alto costo, para que el decisor elija según el escenario. Converger prematuramente a una respuesta puntual hace perder información de compromiso; una vez que el entorno o las prioridades cambian, se paga un precio mayor por volver a explorar.
>
> Los objetivos pueden compensarse, las restricciones son límites que no pueden violarse. El límite superior de latencia de extremo a extremo, el presupuesto de costo unitario de inferencia, el límite de memoria de video y de consumo energético, etc., deben aclararse primero. Los candidatos que violan los límites, aunque alguna métrica sea muy destacada, no deben entrar en la comparación; solo los candidatos dentro de la región factible tienen derecho a participar en la comparación multiobjetivo.
>
> Si un candidato no es peor que otro en todos los objetivos y es mejor en al menos uno, entonces el otro es una solución dominada y puede eliminarse; si ninguno domina al otro, ambos deben retenerse. Todos los candidatos que no se dominan entre sí, unidos, forman el frente de Pareto, que conserva íntegramente la relación de intercambio de "cuánto de un objetivo hay que sacrificar para mejorar otro".
>
> ¿Qué objetos pueden cambiarse? ¿Qué retroalimentación demuestra que el cambio es efectivo? ¿Qué restricciones no pueden violarse? ¿La comparación es justa? ¿Los resultados bastan para sustentar una conclusión? ¿Qué se retiene y qué se descarta en la siguiente ronda? Estas preguntas determinan directamente el espacio de búsqueda, las señales de evaluación, la región factible y las reglas de eliminación.
>
> La capacidad de generación puede acelerar la realización de respuestas, pero si la pregunta merece respuesta, si la evidencia es creíble y si el resultado es suficientemente bueno, sigue siendo decisión del investigador. El código es barato; el gusto y el juicio son escasos; lo que EvoX quiere construir es una infraestructura capaz de entrar en entornos reales, recibir retroalimentación real, y producir, verificar y retener mejoras en operación prolongada.

**Cobertura de palabras clave**

- Compromiso multiobjetivo, restricciones duras, región factible, soluciones no dominadas, soluciones dominadas, frente de Pareto, candidatos diferenciados, convergencia prematura, comparación justa, juicio.

**Tratamiento de ejercicios**

La opción correcta de la pregunta 1 es "múltiples objetivos se condicionan mutuamente; mejorar uno suele implicar sacrificar otro". Punto de retroalimentación: rendimiento, latencia, consumo energético y costo se tensionan entre sí; esta es la raíz del compromiso multiobjetivo.

La opción correcta de la pregunta 2 es "se pierde la información de compromiso entre candidatos, y el decisor no puede comparar beneficios y costos". Si fallan, se les sugiere entender la convergencia prematura desde la "pérdida de información", no desde la "velocidad de cómputo".

La opción correcta de la pregunta 3 es "no es peor que otros candidatos en todos los objetivos y es mejor en al menos uno, por lo que no puede ser superado en todos los aspectos". Punto de retroalimentación: no dominado no es lo mejor en un solo aspecto, sino no poder ser superado en todos.

La opción correcta de la pregunta 4 es "aclarar primero qué restricciones no pueden violarse y tomarlas como límites que los planes candidatos deben cumplir". Punto de retroalimentación: las restricciones duras son límites y no fichas de negociación; quienes violan los límites de latencia o costo no deben entrar en el conjunto de candidatos.

La opción correcta de la pregunta 5 es "juzgar qué preguntas merecen respuesta, qué evidencia merece confianza y qué resultados son suficientemente buenos". Punto de retroalimentación: la generación puede automatizarse; la selección de problemas, el juicio de evidencia y el criterio de suficientemente bueno deben ser custodiados por el investigador.

Tratamiento del estudio de caso:

En el lanzamiento de un modelo de recomendación, el requisito duro es que la latencia de extremo a extremo no supere los 80 milisegundos y que el costo de una inferencia no supere el presupuesto; los candidatos incluyen un gran modelo de alta precisión, un modelo pequeño de baja latencia y un modelo destilado intermedio.

No se puede entregar solo el de mayor precisión, porque puede violar restricciones duras; aun cumpliendo las restricciones, un plan puntual oculta la relación de intercambio entre precisión, costo y latencia. Debe entregarse un conjunto de candidatos no dominados sobre el frente de Pareto.

Se puede preguntar por objetos modificables, retroalimentación efectiva, restricciones inviolables, justicia de la comparación, suficiencia de las conclusiones, y qué retener y descartar en la siguiente ronda. El proceso es: primero eliminar a quienes violan restricciones duras, luego eliminar las soluciones dominadas, y retener candidatos no dominados y claramente diferenciados, para responder a cambios de prioridad.

Se pide a los estudiantes que con un ejemplo de la vida o de la ingeniería expliquen "mejorar un aspecto suele requerir sacrificar otro", y luego determinen en el ejemplo qué son restricciones duras y qué son objetivos compensables. Se pide aleatoriamente a un estudiante que explique el frente de Pareto con sus propias palabras, y el profesor complementa las palabras clave omitidas. Si los estudiantes pueden distinguir objetivos de restricciones, no dominado de dominado, y decir la razón para retener candidatos diferenciados, se puede pasar a la siguiente página; de lo contrario, se vuelve al diagrama y a la definición de juicio y se explica de nuevo.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden responder "por qué el mundo real difícilmente tiene una única solución óptima" y "por qué EvoX retiene un conjunto de candidatos diferenciados", se pasa a la siguiente página de ejemplos, aplicaciones o resumen.

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

### La automajora de los métodos de resolución y la evolución de algoritmos

*Página 9*

> **Objetivo de la página:** El estudiante debe comprender que los algoritmos evolutivos tradicionales rara vez cambian el método que produce las soluciones candidatas, mientras que la evolución sistematizada puede hacer que el algoritmo de resolución mismo entre en el proceso de búsqueda.

> **Objetivo de la página**
>
> Comprender el paradigma por defecto de los algoritmos evolutivos tradicionales, "método fijo, soluciones candidatas en evolución", y poder explicar cómo la evolución de algoritmos convierte el método de resolución mismo en un objeto buscable, evaluable y reemplazable.

> **Orden de explicación**
>
> Primero se señala la configuración por defecto: lo que evoluciona son las soluciones candidatas, mientras que el método que las genera permanece invariable; luego se usa un diagrama comparativo para mostrar "la capa de solución se mueve, la capa de método no"; después se explica el segundo circuito de retroalimentación que añade la evolución de algoritmos; y finalmente se cierra en el giro clave: pasar de "usar un algoritmo fijo para obtener mejores soluciones" a "hacer que el algoritmo se mejore a sí mismo durante la resolución".

**Puntos clave de la enseñanza**

- 1. En el paradigma por defecto, la forma de cruce, la estrategia de mutación y los hiperparámetros suelen elegirse una sola vez antes de la ejecución, y luego ya no cambian durante toda la búsqueda. Determinan directamente cómo se generan las soluciones candidatas y afectan significativamente el resultado, pero la capa de método en sí no recibe retroalimentación. Solución candidata → evaluación → selección → herencia. El problema es que la capa de método no se mueve, por lo que tras un cambio de tarea el mecanismo de generación puede volverse gradualmente inadecuado para la nueva tarea. 3. El ajuste manual de parámetros lo decide una persona; una vez modificado, el método se bloquea de nuevo, y la velocidad y cobertura de mejora quedan limitadas por la experiencia humana. Ampliar la población o aumentar el número de iteraciones solo prolonga la búsqueda dentro del mismo método, sin tocar la capa de método. Se toman como objetos susceptibles de ser propuestos como candidatos, evaluados y reemplazados elementos del método como la forma de cruce, la estrategia de mutación y los hiperparámetros, y se someten junto con las soluciones candidatas a la prueba del rendimiento de resolución. Elementos del método → generación de soluciones candidatas → evaluación del rendimiento de resolución → retención o reemplazo → actualización del método
- Al mismo tiempo, dentro de las soluciones candidatas sigue operando "generación → evaluación → selección → herencia". Lo primero cambia "cómo buscar", lo segundo cambia "qué se encontró". 6. Para juzgar si un sistema realmente está haciendo evolución de algoritmos, la clave es ver si los elementos del método se han incorporado a la búsqueda y si es el rendimiento de resolución el que decide su permanencia, en lugar de quedar fijados de una vez por una persona.

> **Pistas de materiales**
>
> - El diagrama comparativo tiene dos alturas: arriba está la capa de método, abajo la capa de solución. En el diagrama izquierdo, la capa de método está bloqueada y solo se mueve la capa de solución
> - En el diagrama derecho aparece una flecha naranja adicional, desde "evaluación del rendimiento de resolución" hacia la capa de método; este es el circuito de mejora adicional de la evolución de algoritmos.

**Tratamiento de ejercicios**

La pregunta 1 evalúa el paradigma por defecto. La dirección correcta es "el método de búsqueda permanece fijo y solo las soluciones candidatas cambian en la iteración". Si los estudiantes se equivocan, se les puede sugerir volver a la estructura de dos capas y comprobar si están tomando también la capa de método como objeto evolucionado.

La pregunta 2 evalúa los elementos del mecanismo de generación. La respuesta correcta es estrategia de mutación, forma de cruce e hiperparámetros. En la retroalimentación se puede preguntar: "¿cómo se crea la nueva solución?", para descartar distractores como hardware, numeración o división del conjunto de datos.

El ajuste manual de parámetros lo hace una persona; los elementos del método no se evalúan ni reemplazan automáticamente según el rendimiento de resolución. Si fallan, se recuerda a los estudiantes que presten atención a "quién cambia y con base en qué cambia".

Se pasa de "usar un algoritmo fijo para obtener mejores soluciones" a "hacer que el algoritmo se mejore a sí mismo durante la resolución". Se puede sugerir a los estudiantes fijarse en los dos extremos del giro: uno es el algoritmo fijo, el otro es el algoritmo que será mejorado.

La pregunta 5 evalúa la manifestación de que el método entre en la búsqueda. La respuesta correcta es tomar la forma de cruce, la estrategia de mutación, etc. como objetos buscables, que según el rendimiento de resolución son propuestos como candidatos, evaluados y reemplazados. Hay que explicar: ampliar solo la población, aumentar las iteraciones o cambiar la función de evaluación sigue modificando el mismo método fijo.

El equipo adopta el paradigma por defecto; el método queda bloqueado antes de la ejecución. Tras cambios en la estructura de pedidos, el número de equipos y las reglas de plazo de entrega, el método bloqueado no recibe retroalimentación, y las soluciones candidatas se vuelven cada vez más inadecuadas para la nueva tarea. La diferencia de mecanismo es: el ajuste manual de parámetros lo juzga una persona, y una vez modificado se bloquea de nuevo; la evolución de algoritmos pone los elementos del método en la búsqueda, y es el rendimiento de resolución el que decide automáticamente su permanencia.

Los elementos que pueden incorporarse a la búsqueda incluyen la forma de cruce, la estrategia de mutación y los hiperparámetros; también pueden considerarse la presión selectiva, las condiciones de activación de la búsqueda local, etc.; la señal de evaluación puede usar resultados ponderados como retrasos de entrega, número de cambios de línea y utilización de equipos en tareas reales de programación, comparando en lo posible sobre el mismo lote de instancias de tarea; se retienen las combinaciones de métodos con buen rendimiento y se eliminan las malas, conservando al mismo tiempo una pequeña perturbación aleatoria para mantener la diversidad; el flujo del bucle es elementos del método → generación de soluciones candidatas → evaluación del rendimiento de resolución → retención o reemplazo → actualización del método, y luego de vuelta a la generación, mientras dentro de las soluciones candidatas continúa la iteración convencional.

**Verificación de comprensión**

Se pide a los estudiantes que repitan con sus propias palabras la diferencia entre "la capa de solución se mueve, la capa de método no" y "la capa de método también entra en la búsqueda"; luego se les pide escribir de memoria el bucle de cinco pasos; si falta "evaluación" o "reemplazo", significa que el método aún no se ha automajorado realmente.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden distinguir "ajuste de parámetros" de "evolución de algoritmos", y pueden decir el criterio de que los elementos del método se incorporan a la búsqueda y su permanencia la decide el rendimiento de resolución, se pasa a la siguiente página de ejemplos, aplicaciones o resumen.

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

### MetaDE: arquitectura anidada de algoritmos que optimizan algoritmos

*Página 10*

> **Objetivo de la página:** El estudiante debe comprender cómo MetaDE implementa la mejora de algoritmos evolutivos mediante algoritmos evolutivos a través de dos capas internas y externas de evolución diferencial.

> **Objetivo de la página**
>
> Comprender cómo MetaDE usa la evolución diferencial anidada para implementar "algoritmos que optimizan algoritmos": la capa externa evoluciona la configuración del algoritmo, la capa interna resuelve la tarea real.

> **Orden de explicación**
>
> 1. Primero se retoma el bucle "generación—evaluación—selección—herencia" de la lección anterior, y se señala que esta página lo empuja un nivel hacia dentro: no solo hacer que el algoritmo resuelva problemas, sino hacer que el algoritmo mejore algoritmos.
>
> La DE interna (capa de tarea) mantiene la población de soluciones candidatas, ejecuta mutación, cruce y selección, y produce el rendimiento de la tarea; los individuos de la DE externa (capa meta) no son soluciones de tarea, sino una configuración completa de "estrategia de mutación + parámetros", como forma de mutación, factor de escala y probabilidad de cruce.
>
> La capa externa produce la configuración → la transmite a la capa interna → la capa interna ejecuta y devuelve retroalimentación de rendimiento → la capa externa retiene y recombina mejores configuraciones, y entra en la siguiente ronda. Puede resumirse como "configuración externa → resolución interna → rendimiento de tarea → actualización externa".
>
> La estrategia y los parámetros del algoritmo interno ya no son fijados de una vez por una persona, sino reescritos continuamente por la búsqueda externa; el algoritmo obtiene así un canal de automajora.
>
> Cada evaluación externa requiere ejecutar completamente una vez la capa interna; la evaluación anidada amplifica la sobrecarga; el paralelismo en GPU puede evaluar simultáneamente múltiples configuraciones y comprimir el tiempo de reloj de una iteración externa, lo que es la premisa de que la arquitectura sea utilizable. Si los recursos son insuficientes, debe priorizarse reducir la escala externa o disminuir la precisión de evaluación interna, en lugar de ampliar ciegamente la búsqueda.

**Puntos clave de la enseñanza**

- La capa externa cambia el algoritmo, la capa interna resuelve la tarea. Al ver "estrategia de mutación, configuración de parámetros, plan de algoritmo", pensar en la capa externa
- ¿El objeto modificado es el algoritmo o la solución? MetaDE no equivale al ajuste manual de parámetros ni a una búsqueda en cuadrícula de una sola vez. El ajuste manual es una persona probando fuera del bucle, de una vez
- MetaDE incorpora la configuración al bucle de evolución; la configuración se genera, evalúa y recombina continuamente; el objeto de búsqueda es la combinación de "estrategia + parámetros". ¿Cuántas configuraciones debe evaluar la capa externa en cada ronda? ¿Cuán costosa es una evaluación interna? ¿Cuántos recursos de aceleración hay disponibles? Si el tiempo de reloj no puede comprimirse a un rango aceptable mediante paralelismo, primero se reduce la escala externa o la precisión de evaluación interna, y luego se considera ampliar la búsqueda.

**Tratamiento de ejercicios**

Las 5 preguntas de opción múltiple de esta página sirven para verificar la división de tareas entre las dos capas y la conciencia de costos. La pregunta 1 elige "iterar soluciones candidatas en una tarea de optimización concreta y dar el rendimiento de la tarea", enfatizando que la capa interna es la capa de tarea. La pregunta 2 elige "una configuración de estrategia de mutación y parámetros de la DE interna", enfatizando que el individuo externo es configuración y no solución de tarea. La pregunta 3 elige "la retroalimentación de rendimiento obtenida por la capa interna tras ejecutarse en la tarea", correspondiente al canal ascendente del bucle. La pregunta 4 elige "la evaluación anidada multiplica la sobrecarga computacional; el paralelismo puede comprimir el costo temporal de la búsqueda meta", notando que el paralelismo reduce el tiempo de reloj y no el cómputo total. La pregunta 5 elige "MetaDE incorpora la configuración del algoritmo al bucle de evolución; la configuración se genera, evalúa y recombina continuamente", distinguiéndolo del ajuste manual.

Tratamiento del caso:

El espacio de búsqueda externo es el "conjunto de configuraciones del algoritmo", incluyendo la estrategia de mutación y parámetros como el factor de escala y la probabilidad de cruce; el proceso de resolución interno consiste en mantener soluciones candidatas en una tarea fija de optimización de rutas, ejecutar la evolución y producir la calidad de la ruta. El valor de poner la estrategia de mutación en la evolución externa radica en que el objeto de búsqueda se expande de valores numéricos a la combinación "estrategia + parámetros", y puede cambiar automáticamente de estrategia según la estructura de la tarea o la fase de búsqueda, reduciendo la suboptimalidad y el ensayo y error repetido que trae fijar manualmente una sola estrategia.

Evaluar en lote y en paralelo múltiples configuraciones, comprimiendo el tiempo de reloj de la iteración externa; evaluación jerárquica, primero con una población más pequeña o menos iteraciones para un filtrado grueso, y luego evaluación completa de las configuraciones destacadas; restringir el alcance de búsqueda, limitar la población y el número de rondas externas, y almacenar en caché las configuraciones ya evaluadas. El compromiso es: cuanto más gruesa la evaluación interna, mayor el ruido de retroalimentación y mayor la posibilidad de elegir una configuración con ventaja accidental; cuanto mayor el paralelismo, mayor la sobrecarga de memoria de video y de programación; el paralelismo no reduce el cómputo total, solo comprime el tiempo de reloj, por lo que hay que equilibrar precisión de evaluación, amplitud de búsqueda y presupuesto de hardware.

**Verificación de comprensión**

Se puede pedir aleatoriamente a un estudiante que resuma en una frase "quién cambia el algoritmo, quién resuelve la tarea", y que ejemplifique si un elemento pertenece a la capa externa o interna, por ejemplo, "el factor de escala" pertenece a la capa externa, "la calidad de la ruta" pertenece a la capa interna. Si los estudiantes pueden explicar la razón, se pasa a la siguiente página de aplicación o resumen.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar el bucle "configuración externa → resolución interna → retroalimentación de rendimiento → actualización externa", se pasa a la siguiente página de ejemplos, aplicaciones o resumen.

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

### La arquitectura del sistema de bucle de evolución de EvoX

*Página 11*

> **Objetivo de la página:** El estudiante debe comprender cómo EvoX construye una infraestructura completa de bucle de evolución entre la capacidad del modelo y la capacidad del sistema.

**Puntos clave de la enseñanza**

- El modelo genera posibilidades → el entorno proporciona retroalimentación → el sistema evalúa y selecciona → herencia. Al encontrarse con una pregunta sobre EvoX, primero hay que juzgar qué papel desempeña este paso en el bucle: producir posibilidades, proporcionar verificación, tomar decisiones o retener resultados.
- Si alguna opción describe EvoX como "un modelo más grande" o "una llamada única más rápida", básicamente puede identificarse como distractor. EvoX describe el mecanismo de operación entre componentes: cómo se conectan y ciclan la generación, la retroalimentación, la evaluación, la selección y la herencia.
- Retroalimentación distorsionada, criterios de evaluación desviados del objetivo, mecanismos de herencia que retienen lo incorrecto: si cualquiera de los tres falla, la desviación se hereda y amplifica repetidamente en el bucle. Al repasar, usar tres preguntas de autocomprobación: ¿la retroalimentación es real? ¿la evaluación apunta al objetivo? ¿la herencia retiene lo correcto?

【Objetivo de la página】

Los grandes modelos ya pueden escribir código, proponer hipótesis y dar planes; ¿por qué se necesita todo un sistema? El estudiante debe comprender cómo EvoX construye una infraestructura completa de bucle de evolución entre la capacidad del modelo y la capacidad del sistema, y dominar los cuatro eslabones del bucle y su orden, el significado arquitectónico, el mecanismo de acumulación continua, el origen del pensamiento y los riesgos.

【Orden de explicación】

Una generación única no puede autoprobar su corrección, ni mantenerse efectiva cuando el entorno y el modelo cambian constantemente. La posición de EvoX es tender un puente entre la capacidad del modelo y la capacidad del sistema, organizando los resultados generados una y otra vez en capacidades que pueden ser verificadas, seleccionadas y retenidas. Luego se explican los cuatro eslabones del bucle: el modelo genera posibilidades → el entorno proporciona retroalimentación → el sistema evalúa y selecciona → herencia. Después se explica el significado arquitectónico: EvoX no es un algoritmo puntual, ni una llamada única, sino un mecanismo de sistema reutilizable. Luego se habla de la acumulación continua y su eco con el origen de la "máquina niña" de Turing en 1950, y finalmente se advierte que el bucle también puede amplificar desviaciones.

【Puntos clave de la enseñanza】

El modelo es bueno dando en una sola llamada una "posibilidad": una hipótesis, un fragmento de código, un plan. Pero la posibilidad no es conclusión: si el resultado se sostiene o no lo dice el entorno real; después de que el entorno da el resultado, quién juzga cuál es mejor y cuál peor, qué retener y qué eliminar, y quién lleva la parte retenida a la siguiente ronda; estos eslabones el modelo mismo no los asume. EvoX se orienta precisamente a ese vacío "después de la generación", transformando el resultado generado en capacidad sistémica acumulable.

2. Los cuatro eslabones del bucle:

El modelo da planes candidatos, hipótesis o código; proporciona posibilidades, no conclusiones.

El experimento, la simulación o la ejecución real devuelven resultados observables, permitiendo que los candidatos pasen por la prueba de la realidad.

El sistema compara los candidatos según objetivos y restricciones, juzga lo bueno y lo malo, y decide cuáles pueden quedarse.

La estrategia, los parámetros o los componentes seleccionados entran en la siguiente ronda de evolución y se convierten en un nuevo punto de partida.

El modelo genera posibilidades → el entorno proporciona retroalimentación → el sistema evalúa y selecciona → herencia → vuelve al modelo a generar nuevas posibilidades. Mientras el bucle funcione, cada ronda no tiene que empezar de cero. La clave del orden es: la retroalimentación debe ocurrir antes de la evaluación, y la evaluación antes de la herencia. De lo contrario, la evaluación carece de fundamento y la herencia también.

Organizar la generación, la retroalimentación de ejecución, la evaluación, la selección y la herencia en una arquitectura de sistema reutilizable es la diferencia fundamental entre EvoX y un algoritmo puntual o una llamada única. Un algoritmo puntual se preocupa por "cómo se calcula este paso"; una llamada única se preocupa por "si esta vez respondió bien"; EvoX se preocupa por "si este mecanismo puede funcionar ronda tras ronda y mejorar cada vez más". Por eso describe interfaces entre componentes, criterios de evaluación y reglas de herencia, y no solo los parámetros de un modelo o la respuesta de una pregunta.

En el bucle, las estrategias que pasan la evaluación se heredan, y las que no pasan se eliminan o corrigen. Componentes inteligentes dispersos en diferentes eslabones, como generadores, simuladores y evaluadores, comparten así un mismo "registro de supervivencia": sus capacidades se superponen en múltiples rondas de evolución, en lugar de reiniciarse en cada ronda. Esta es precisamente la clave por la que el bucle agrega componentes dispersos en capacidad acumulada continua.

La "máquina niña" de Turing en 1950. Ya en 1950, Turing propuso la visión de la "máquina niña": la máquina es como un niño que, mediante educación, experimentación y recompensas y castigos, adquiere capacidades gradualmente en la interacción con el entorno. EvoX puede verse como una extensión sistematizada de esta visión en la práctica científica AI Native: la educación corresponde a la generación y la guía, la experimentación a la retroalimentación del entorno, las recompensas y castigos a la evaluación y selección, y el crecimiento a la herencia y la acumulación.

El bucle también amplifica desviaciones. El efecto del bucle no equivale automáticamente a algo mejor. Depende de que la calidad de los tres eslabones se mantenga consistente: si la retroalimentación del entorno es real, si los criterios de evaluación apuntan al objetivo, y si el mecanismo de herencia retiene lo correcto. Si la retroalimentación se distorsiona o la definición del objetivo se desvía, el error no desaparece por sí solo, sino que se amplifica ronda tras ronda en el bucle. Diseñar un bucle es, en esencia, diseñar las reglas de evaluación y herencia. Al repasar, usar tres preguntas de autocomprobación: ¿la retroalimentación es real? ¿la evaluación apunta al objetivo? ¿la herencia retiene lo correcto?

【Cobertura de palabras clave】

Sistema de bucle de evolución, capa puente de EvoX, el modelo genera posibilidades, el entorno proporciona retroalimentación, el sistema evalúa y selecciona, herencia, capacidad sistémica acumulable, máquina niña, distorsión de la retroalimentación, criterios de evaluación, mecanismo de herencia, amplificación de desviaciones, investigación AI Native.

【Pistas de ejercicios】

Esta página incluye 5 preguntas de opción múltiple y 1 caso, para verificar la comprensión del orden del bucle, el significado arquitectónico, la visión de Turing y los riesgos.

【Tratamiento de ejercicios】

¿Cuál es la razón fundamental por la que EvoX es necesario?

Los grandes modelos son fuertes en generación única, pero carecen de un vehículo de bucle que transforme los resultados generados en capacidad sistémica acumulable.

Cómo se verifica, evalúa y hereda el resultado en el entorno. EvoX proporciona precisamente ese vehículo de bucle. Si los estudiantes eligen erróneamente opciones como "capacidad de generación insuficiente", se les recuerda que la pregunta es "por qué se necesita un sistema", no "en qué falla el modelo".

¿Cuál es el orden correcto de los cuatro eslabones del bucle de evolución de EvoX?

El modelo genera posibilidades → el entorno proporciona retroalimentación → el sistema evalúa y selecciona → herencia.

Primero se generan posibilidades, luego el entorno da retroalimentación, después el sistema evalúa y selecciona, y finalmente la parte efectiva se hereda a la siguiente ronda; el final se conecta con el inicio formando el bucle. La retroalimentación debe ocurrir antes de la evaluación, y la evaluación antes de la herencia.

La explicación más precisa de la frase "EvoX es una arquitectura de sistema" es:

EvoX es un diseño integral que organiza generación, retroalimentación de ejecución, evaluación, selección y herencia como mecanismo reutilizable.

El significado de arquitectura radica en las interfaces entre componentes, los criterios de evaluación y las reglas de herencia, y en si estos mecanismos pueden funcionar de forma estable ronda tras ronda. Hay que distinguir "algoritmo puntual/llamada única" de "arquitectura de sistema": lo primero resuelve un paso o una vez, lo segundo resuelve si el mecanismo puede operar de forma continua.

¿Qué enfatiza la visión de la "máquina niña" propuesta por Turing en 1950?

Que la máquina, mediante educación, experimentación y recompensas y castigos, adquiere capacidades gradualmente en la interacción con el entorno.

La educación da dirección, la experimentación proporciona verificación, las recompensas y castigos forman presión selectiva. No se trata de inculcar conocimiento de una vez, sino de hacer que la máquina, como un niño, adquiera capacidades gradualmente en el entorno.

Si la retroalimentación del entorno se distorsiona y los criterios de evaluación se desvían del objetivo real, ¿cuál es la consecuencia más probable en el bucle de evolución?

El error se hereda repetidamente en el bucle y se amplifica ronda tras ronda.

El bucle amplifica fielmente la señal que recibe, incluidas las señales erróneas. La coherencia entre la calidad de la retroalimentación, los criterios de evaluación y el mecanismo de herencia es la premisa de la efectividad del bucle. La característica del bucle es el "uso cíclico": el resultado de la ronda anterior entra en la siguiente, por lo que la desviación no se autocorrige, sino que puede heredarse repetidamente y crecer cada vez más.

【Tratamiento del caso】

Una ronda de evolución en la investigación AI Native. Un grupo de investigación busca fórmulas viables para un nuevo catalizador: el gran modelo genera 20 fórmulas candidatas basadas en la literatura; se envían a un entorno de simulación y a una plataforma de experimentación a pequeña escala, donde se miden actividad y estabilidad y se registran las causas de fallo; el sistema ordena según "actividad × estabilidad ÷ costo" y restricciones de seguridad, retiene las 5 primeras y organiza las causas de fallo en una base de experiencia; en la siguiente ronda, el modelo genera un nuevo lote de candidatos basándose en las 5 fórmulas retenidas y en todas las causas de fallo. El equipo descubre que, al no registrar las causas de fallo, la calidad de los candidatos se estanca después de la tercera ronda; al incorporar las causas de fallo como base para la generación de la siguiente ronda, la viabilidad de los candidatos mejora notablemente.

¿Qué paso asume la responsabilidad de "hacer que las posibilidades pasen por la prueba de la realidad"? Si se elimina este paso, ¿en qué forma degenera el bucle?

El entorno de simulación y la plataforma de experimentación a pequeña escala devuelven mediciones reales de actividad, estabilidad, etc., y registran una a una las causas de fallo. Sin este paso, el sistema solo puede evaluar los candidatos según el juicio del propio modelo, y el bucle degenera en un giro en vacío de "generación—autoevaluación—generación": la calidad de los candidatos ya no está restringida por la realidad, los fallos no pueden explicarse y las conclusiones de la ronda anterior no pueden verificarse.

Al incorporar las causas de fallo como base para la generación de la siguiente ronda, la viabilidad de los candidatos mejora notablemente. Explique este fenómeno combinando los dos eslabones de "evaluación y selección del sistema" y "herencia", y señale la premisa de diseño que revela.

El eslabón de "evaluación y selección del sistema" no solo retiene los candidatos exitosos mejor clasificados, sino que además guarda estructuradamente las causas de fallo en la base de experiencia; el eslabón de "herencia" no solo lleva "qué planes son efectivos", sino también "qué caminos ya se ha demostrado que no lo son". Esta información entra en la generación de la siguiente ronda, lo que equivale a señalar las regiones que deben evitarse en el espacio de búsqueda, y los candidatos son naturalmente más viables. La premisa de diseño que revela es: el mecanismo de herencia debe ser coherente con los criterios de evaluación; toda información efectiva identificada por el eslabón de evaluación, sea de éxito o de fracaso, debe poder heredarse; de lo contrario, la capacidad de acumulación del bucle se desperdicia a medias.

【Verificación de comprensión】

¿Por qué EvoX necesita un bucle? ¿Cuáles son los cuatro eslabones del bucle? ¿En qué se diferencia la arquitectura de una llamada única? ¿Qué riesgos puede traer el bucle? El profesor complementa las palabras clave omitidas según la respuesta, como "capacidad sistémica acumulable", "la retroalimentación debe ocurrir antes de la evaluación", "coherencia entre mecanismo de herencia y criterios de evaluación", etc.

【Sugerencia de transición】

Tras confirmar que los estudiantes pueden expresar el orden del bucle y las responsabilidades de cada eslabón, se pasa a la siguiente página de ejemplos, aplicaciones o resumen. Si los estudiantes siguen entendiendo EvoX como "un modelo más grande" o "una llamada única más rápida", es necesario volver a la parte del significado arquitectónico de esta página para analizarlo de nuevo.

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

### Los límites centrales y las preguntas clave para conectar tareas a EvoX

*Página 12*

> **Objetivo de la página:** El estudiante debe comprender que al conectar problemas reales a EvoX es necesario aclarar los objetos de cambio, los resultados observables y los criterios de evaluación.

> **Objetivo de la página**
>
> Explicar "conectar tareas reales a EvoX" como un proceso de contractualización primero y ajuste de parámetros después. El estudiante debe poder expresar con claridad los tres límites: qué objetos pueden cambiarse (espacio de búsqueda), qué resultados pueden observarse (canal de retroalimentación), y qué cambios deben retenerse (criterios de evaluación), y comprender que los límites preceden a la elección de búsqueda y operadores.

**Puntos clave de la enseñanza**

- ¿Puede cambiarse? ¿Puede observarse? ¿Puede retenerse? Los límites determinan la dirección de la evolución; los operadores solo determinan qué tan rápido se avanza en esa dirección
- Si los límites están mal, cuanto más intensa la búsqueda, más lejos se desvía. Declarar explícitamente las variables de decisión y la estructura (genotipo) y su mapeo al producto real (fenotipo), y señalar al mismo tiempo el entorno de solo lectura, los datos, las interfaces, el hardware y las restricciones de cumplimiento. Un límite demasiado amplio introduce una gran cantidad de candidatos inválidos; uno demasiado estrecho no deja margen de evolución. Cada candidato debe producir una señal que pueda ser capturada por el programa, y debe aclararse el canal de observación, la latencia, el nivel de ruido y la reproducibilidad. Las dimensiones no observables no pueden usarse como base de optimización, solo para explicación posterior
- Incluir en la función de aptitud cosas no observables hará que la evolución derive hacia el ruido. Definir la función de aptitud o el vector de objetivos, las restricciones y el juicio de factibilidad, explicar si se comprime a un único valor o se retiene según el Pareto multiobjetivo, y establecer la forma de penalización, reparación o parada temprana para candidatos fallidos, bloqueados o con tiempo de espera agotado. Una vez determinado el criterio de evaluación, se determina la dirección de convergencia de la evolución. El grado de paralelismo y la latencia única determinan directamente el ritmo del circuito de evolución y el número de generaciones soportables. La evaluación en serie alarga el circuito y reduce drásticamente las generaciones soportables
- La evaluación por lotes o asíncrona puede acelerar significativamente la iteración. También deben aclararse el presupuesto total de evaluación, el criterio de convergencia y las condiciones de parada, para evitar el consumo ilimitado de cómputo y también la terminación prematura de soluciones que aún no han tomado forma. Hay que estar atentos al desajuste entre métricas sustitutas y objetivos reales, la fuga de objetivos y la explotación inversa del evaluador por parte de los candidatos para inflar puntuaciones. La forma de responder es conservar un conjunto de validación independiente o revisión humana, y hacer que la evaluación sea lo más sin estado y reproducible posible, para facilitar la reproducción de fallos y la atribución de resultados. Encapsular la tarea en una interfaz unificada, con entrada de un candidato y salida de métricas y restricciones, garantizando que la evaluación sea lo más sin estado y reproducible posible. Si el contrato es estable, el bucle de evolución es estable.

> **Pistas de materiales**
>
> - El diagrama de la página presenta el flujo de datos "tarea y entorno real—objetos modificables permitidos—evaluador y canal de observación—bucle de evolución de EvoX", y usa la comparación de tiempos entre evaluación en serie y por lotes o asíncrona para ilustrar la diferencia de ritmo. Puede usarse el diagrama para enfatizar: primero dibujar los tres límites, luego ajustar operadores y parámetros.

**Tratamiento de ejercicios**

Elegir "las variables de decisión y la estructura modificables permitidas (genotipo) y su mapeo al producto real (fenotipo)". Sugerencia: el presupuesto de cómputo pertenece al límite de evaluación, la frecuencia de muestreo y el ruido al límite de observación, y los operadores de mutación son detalles de implementación.

Elegir "cada candidato debe poder producir una señal capturable por el programa, y deben aclararse el canal de observación, la latencia y el ruido; las dimensiones no observables solo pueden usarse para explicación posterior". Sugerencia: la base de optimización debe provenir de señales capturables.

Elegir "la forma de evaluación determina qué se retendrá; si primero se amplía el espacio de búsqueda, la evolución se sobreajustará a métricas fáciles de observar y de inflar". Sugerencia: qué retener precede a qué buscar.

Elegir "el grado de paralelismo y la latencia de una sola evaluación determinan directamente el ritmo del circuito de evolución y las generaciones soportables". Sugerencia: la serie alarga el circuito, el lote o la asincronía aceleran la iteración.

Elegir "el candidato explota una vulnerabilidad del evaluador para obtener una puntuación muy alta, pero en realidad no resuelve el problema de la tarea". Sugerencia: las decisiones clave de lanzamiento deben mirar los resultados de validación independientes.

La selección de operadores, el orden de ejecución y los hiperparámetros de cada operador constituyen el genotipo; la salida real de la línea de producción es el fenotipo. Resultados observables: precisión de extremo a extremo, latencia de extremo a extremo y tasa de fallo, explicando latencia, ruido y reproducibilidad. Criterios de retención: precisión y latencia pueden retenerse según el Pareto multiobjetivo; el límite de latencia se establece como restricción dura, y quien no cumpla la restricción se juzga inviable; los candidatos fallidos, bloqueados o con tiempo de espera agotado se penalizan o reparan antes de reevaluarse. Restricciones de solo lectura: definición de la estructura de datos de entrada, requisitos de cumplimiento, interfaces upstream, hardware y entorno de ejecución. Contrato de conexión: entrada de candidato, salida de métricas y restricciones, evaluación lo más sin estado y reproducible posible, envío por lotes en contenedores y recogida asíncrona.

Aclarar el presupuesto total de evaluación, el criterio de convergencia y las condiciones de parada.

**Verificación de comprensión**

Se pide aleatoriamente a un estudiante que resuma con sus propias palabras "las tres preguntas preceden al ajuste de parámetros", y que ejemplifique qué pasaría si se tomara la puntuación del conjunto de entrenamiento como único criterio de retención. Si los estudiantes solo repiten el ajuste de operadores, se vuelve a "los límites determinan la dirección" para explicarlo de nuevo.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar los tres límites de objetos de cambio, resultados observables y criterios de evaluación, y su relación con el bucle de evolución, se pasa a la siguiente página de ejemplos, aplicaciones o resumen.

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

### Inicio rápido con EvoX: configuración del entorno y uso

*Página 13*

> **Objetivo de la página:** El estudiante debe dominar el método básico para instalar y configurar EvoX rápidamente en herramientas de IA.

> **Objetivo de la página**
>
> Esta página busca resolver la ruta más corta "de cero al primer entorno EvoX ejecutable": completar la instalación y la configuración básica con la menor cantidad de comandos posible, y luego verificar con una importación y un ejemplo mínimo, confirmando que EvoX puede ser invocado por tareas. La idea central es que "instalarlo no significa que funcione"; solo cuando los cuatro pasos producen salidas reales se considera completado el inicio rápido.

> **Orden de explicación**
>
> Primero se explica que la configuración del entorno no es simplemente ejecutar un comando de instalación, sino un bucle de "aislamiento—instalación—configuración—verificación"; luego se desarrollan los cuatro pasos en orden, y finalmente se añaden los límites de la asistencia de IA y los requisitos de reproducibilidad.

**Puntos clave de la enseñanza**

- Antes de instalar cualquier paquete, crear primero un entorno Python independiente con venv o conda. Los paquetes en el entorno global son compartidos por múltiples proyectos, y tras un conflicto de versiones el costo de diagnóstico es muy alto
- Un entorno independiente equivale a asignar a EvoX una mesa de experimentación separada; si se estropea, puede reconstruirse todo el entorno. La práctica común es python -m venv .venv, y luego activar el entorno
- En Windows corresponde al script de activación en el directorio Scripts. Tras activar, ejecutar primero pip install -U pip, para evitar que una versión antigua del gestor de paquetes falle al resolver dependencias. Normalmente se ejecuta pip install evox, y también puede usarse conda o el método desde código fuente. El nombre del paquete, la versión y la fuente de descarga deben regirse siempre por la publicación oficial; no confundir nombres de paquetes similares con EvoX. Que el proceso de instalación no tenga errores en rojo solo significa que "se instaló", no que "pueda usarse", así que no detenerse en este paso. En el primer contacto no es necesario ajustar todos los parámetros; basta confirmar cuatro puntos de partida: si la versión de Python cumple los requisitos oficiales, si las versiones de dependencias son compatibles, si este experimento usa CPU o GPU, y si la semilla aleatoria está fijada. Los dos primeros determinan si el programa puede ejecutarse normalmente; los dos últimos, si el resultado puede reproducirse. La verificación más confiable no es ver si la terminal tiene texto rojo, sino hacer que EvoX se ejecute de verdad. Primero import evox e imprimir el número de versión, para confirmar que el paquete se carga en el entorno actual
- Luego ejecutar el ejemplo mínimo o completar una ronda de iteración evolutiva, para confirmar que puede ser invocado normalmente por la tarea. Los indicadores de aceptación incluyen que el número de versión se imprima correctamente, que el ejemplo mínimo no dé errores y que se complete una ronda de iteración evolutiva. Se puede decir a la IA el sistema operativo, la versión de Python y la situación del hardware, para que genere comandos de instalación, configuración y diagnóstico, ahorrando tiempo de consulta de documentación
- Pero los nombres de paquetes, las combinaciones de versiones y las operaciones a nivel de sistema deben verificarse con la documentación oficial y la matriz de versiones antes de ejecutarse, especialmente los comandos que implican modificar la configuración del sistema o desinstalar dependencias. Registrar los comandos de instalación, el archivo de dependencias del entorno y los números de versión, para poder reproducir el mismo entorno al cambiar de máquina y evitar "funciona en mi máquina, pero falla en otra".

> **Pistas de materiales**
>
> - La página usa un diagrama de flujo de cuatro pasos para mostrar "entorno aislado—instalar EvoX—configuración básica—verificación del inicio rápido", y enumera la lista de aceptación
> - Puede combinarse con un cuadro de ejemplo de terminal para explicar los comandos y los identificadores del entorno.

**Tratamiento de ejercicios**

La respuesta a la pregunta 1 es "aislar dependencias, evitando la contaminación mutua con otros proyectos del entorno global". En la retroalimentación se enfatiza que el valor central del entorno aislado es que las dependencias no interfieran entre sí, y no tiene relación con la capacidad de red o la velocidad de ejecución.

La respuesta a la pregunta 2 es "importar evox con éxito, imprimir el número de versión y ejecutar correctamente un ejemplo mínimo". Hay que explicar que la instalación sin errores es solo un estado intermedio.

La respuesta a la pregunta 3 es "decir primero a la IA el sistema operativo, la versión de Python y el hardware de la máquina, y luego verificar con la documentación oficial y la matriz de versiones antes de ejecutar". Hay que recordar que lo que da la IA son comandos candidatos, y antes de ejecutarlos hay que verificar su alcance de impacto.

La respuesta a la pregunta 4 es "garantizar que los resultados experimentales sean reproducibles, y que sigan coincidiendo al cambiar de máquina o de versión". Las semillas y las versiones afectan la reproducibilidad, no la velocidad, la memoria de video o la garantía de convergencia.

La respuesta a la pregunta 5 es "los conflictos de dependencias o el desajuste de versiones se exponen recién cuando se ejecuta la tarea de verdad". La falta de verificación pospone el problema a un momento más problemático.

Se dan los pasos mínimos viables según los cuatro pasos, y se explica la señal de aceptación de cada paso, por ejemplo, tras la activación aparece el identificador del entorno en la línea de comandos y python -V apunta a la versión objetivo, la instalación termina sin conflictos de dependencias, se aclara CPU o GPU y se fija la semilla, la importación es exitosa y se ejecuta el ejemplo mínimo. Pregunta 2: organizar el sistema operativo, la versión de Python, el hardware y el error completo y entregarlo a la IA, pidiendo comandos de diagnóstico en orden de mínima intrusión y explicando su función y efectos secundarios; antes de ejecutar, verificar el nombre oficial del paquete, el rango de compatibilidad de versiones y la fuente de instalación; guardar la lista de dependencias y los números de versión clave para poder reconstruir el entorno.

**Verificación de comprensión**

Se pide a los estudiantes que repitan con sus propias palabras "instalarlo no significa que funcione", y que digan las señales de aceptación de cada uno de los cuatro pasos.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden distinguir entre instalación completada y verificación superada, se pasa a la siguiente página de ejemplos, aplicaciones o resumen.

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

### Las capacidades centrales del investigador y el juicio estético

*Página 14*

> **Objetivo de la página:** El estudiante debe reconocer que en el sistema EvoX, plantear preguntas clave y mantener un sentido estético científico es más importante que escribir código.

> **Objetivo de la página**
>
> Hacer que los estudiantes reconozcan que, en el sistema de evolución inteligente EvoX, la competitividad central del investigador se está trasladando de "escribir cada línea de código a mano" a "plantear preguntas clave, definir evidencia creíble y emitir juicios estéticos". Cuando generar y probar se vuelve barato, lo verdaderamente escaso es el juicio, no la velocidad para escribir código.

> **Orden de explicación**
>
> Primero se usa "Code is cheap. Taste matters." para señalar la posición de esta página, luego se explica por qué, tras la expansión de la generación de candidatos, el cuello de botella se traslada a la capacidad de selección, después se desarrollan las cuatro acciones de cómo operan los criterios estéticos, luego se aclara que la estética científica no es preferencia subjetiva, y finalmente se verifica la comprensión con preguntas de opción múltiple y estudios de caso.

> **Pistas de materiales**
>
> - El póster conceptual de esta página puede usarse como esqueleto de la pizarra. En el centro está "el código es barato, el gusto es supremo", y alrededor hay cuatro nodos: "plantear preguntas clave, definir evidencia creíble, juzgar la dirección de la evolución, establecer criterios estéticos". Al enseñar, primero se puede señalar la idea central, y luego pedir a los estudiantes que digan qué problema resuelve cada nodo.

**Puntos clave de la enseñanza**

- El modelo puede generar rápidamente planes candidatos; el costo de prueba y error disminuye, y el techo de resultados ya no lo determina la velocidad para escribir código, sino el juicio del investigador sobre la dirección y el valor. La oferta de candidatos se expande rápidamente; en un mismo día pueden producirse cientos o miles de planes "que parecen todos bastante buenos"
- ¿Qué preguntas merecen respuesta? ¿Qué evidencia merece confianza? ¿Qué resultados bastan para sustentar una conclusión? Plantear preguntas, juzgar si una dirección merece inversión
- Definir evidencia creíble: aclarar primero "qué tipo de resultado cuenta como evidencia", y luego seleccionar candidatos en consecuencia
- Establecer criterios estéticos: usar una escala estable para filtrar problemas, objetivos, evidencia y dirección de evolución
- Juzgar la dirección de la evolución: entre muchos próximos pasos viables, elegir el que pueda llevar el sistema a un valor superior. No equivale a preferencia subjetiva personal, no es "qué estilo me gusta más", sino un criterio de filtrado reutilizable, explicable y verificable por colegas. Determina qué preguntas se plantean, qué métricas se creen y qué direcciones se retienen. No se debe tomar la estética como metafísica o embellecimiento posterior. Ocurre en el frente mismo de la decisión: al decidir en qué problema invertir, en qué conjunto de métricas creer y qué ruta de evolución retener, la estética ya está moldeando el resultado. Cuanto más barato generar, más importante el gusto. Antes de actuar, preguntarse: ¿la pregunta que planteo merece respuesta? ¿la evidencia en que me baso es creíble? ¿mi criterio de evaluación puede filtrar el ruido y retener los planes verdaderamente valiosos?

**Cobertura de palabras clave**

- Migración de la competitividad central, plantear preguntas clave, definir evidencia creíble, establecer criterios estéticos, juzgar la dirección de la evolución, capacidad de selección, escasez del juicio, estética científica, criterios de filtrado reutilizables, Code is cheap. Taste matters.

**Tratamiento de ejercicios**

La opción correcta de la pregunta 1 es "cuando el costo de generar candidatos y probar y errar disminuye, plantear preguntas clave y el juicio estético se convierten en el verdadero recurso escaso". Punto de retroalimentación: al ampliarse la capacidad de generación, el cuello de botella se traslada a capacidades de alto nivel como plantear preguntas, definir evidencia y emitir juicios. Si los estudiantes se equivocan, se les invita a pensar qué es realmente escaso cuando generar se vuelve barato.

La opción correcta de la pregunta 2 es "cuando el costo de generar y probar y errar disminuye, el juicio (el gusto) se convierte en la clave del valor de los resultados". Punto de retroalimentación: el lema enfatiza el desplazamiento de la escasez; al abaratarse la generación, lo valioso es el juicio capaz de filtrar ruido y señalar la dirección.

La opción correcta de la pregunta 3 es "juzgar qué problemas merecen inversión, qué métricas son realmente importantes y qué resultados bastan para sustentar conclusiones". Punto de retroalimentación: cuantos más candidatos, más crítica la selección; no se puede retener todo ni renunciar a definir objetivos y criterios de evaluación.

La opción correcta de la pregunta 4 es "la estética científica es un conjunto de juicios de alto nivel reutilizables y explicables, usado para filtrar problemas, objetivos y evidencia". Punto de retroalimentación: distinguir la preferencia personal del criterio de filtrado reutilizable; este último es la estética científica de la que habla esta página.

La opción correcta de la pregunta 5 es "aclarar primero qué tipo de resultado cuenta como evidencia, y luego seleccionar los planes candidatos en consecuencia". Punto de retroalimentación: la evidencia creíble debe ser un criterio definido de antemano, no una propiedad por defecto del resultado generado.

La decisión ante la explosión de candidatos. El escenario es que el equipo usa el sistema para generar y probar miles de planes candidatos en pocas horas; las métricas preliminares "parecen todas buenas", y luego el equipo debe decidir si sigue ampliando la escala o se detiene a redefinir el problema y las métricas de evaluación.

En ese momento lo más escaso es el juicio del investigador, es decir, el "gusto". La razón es que el costo de generar candidatos y probar y errar ya ha disminuido mucho; seguir ampliando simplemente la escala tiene rendimientos marginales decrecientes, y cuantos más planes, más difícil distinguirlos; lo que realmente decide el éxito o el fracaso es juzgar qué preguntas merecen respuesta, qué métricas son realmente importantes y qué resultados bastan para sustentar conclusiones.

Aclarar las preguntas clave que debe responder esta etapa, sustituyendo "generar más" por "responder con más precisión"; definir criterios de evidencia creíble, enumerando qué métricas y a qué nivel cuentan como evidencia; establecer criterios estéticos y de evaluación estables, usándolos para filtrar objetivos y dirección de evolución; hacer una selección razonada de los candidatos, eliminando los planes "que parecen buenos pero no pueden sustentar conclusiones", y concentrando los recursos en las pocas rutas más valiosas.

**Verificación de comprensión**

Se pide a los estudiantes que expliquen con sus propias palabras la lógica de "cuanto más barato generar, más importante el gusto", y que digan al menos dos acciones de juicio concretas. Se puede preguntar: si solo pudieras conservar un criterio de evaluación, ¿cuál conservarías? ¿Por qué?

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden distinguir "capacidad de generación" de "capacidad de juicio", y pueden decir las cuatro acciones de plantear preguntas, definir evidencia, establecer criterios y juzgar la dirección, se pasa a la siguiente página de aplicación, ejemplos o resumen.

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

### Comparación entre el sistema tradicional de preguntas y respuestas únicas y el sistema de evolución continua EvoX

*Página 15*

> **Objetivo de la página:** El estudiante debe aclarar, mediante la comparación, las diferencias centrales entre las preguntas y respuestas tradicionales de grandes modelos y el sistema de evolución continua EvoX al enfrentar entornos complejos.

> **Objetivo de la página**
>
> Esta página busca que los estudiantes aclaren, mediante la comparación, las diferencias centrales entre las preguntas y respuestas únicas de grandes modelos tradicionales y el sistema de evolución continua EvoX al enfrentar entornos complejos. Retoma la visión de la "máquina niña" de Turing: la capacidad viene de la experiencia, no de formarse de una vez. Al explicar, hay que captar dos puntos de juicio: cuán larga es la cadena y si después del final hay retorno; y si la verificación ocurre fuera o dentro del sistema.

> **Orden de explicación**
>
> Primero se vuelve a la visión de Turing de 1950, y luego se desarrollan las dos rutas. Las preguntas y respuestas únicas tradicionales son un circuito abierto: indicación → generación → salida, y la salida es el final. No tiene una vía que devuelva automáticamente el resultado de la ejecución al sistema; la verificación se completa en su mayoría fuera del sistema, dependiendo del juicio humano del investigador, el filtrado, la reproducción y el volver a preguntar; las mejoras quedan dispersas en el juicio humano y en registros temporales, y difícilmente se sedimentan como capacidad del sistema; está básicamente desacoplado del entorno físico real y queda fijo tras una generación. Por eso, cuando la tarea puede generarse de una vez y el costo de verificación es bajo, es más directo y eficiente.
>
> Generación de candidatos → verificación en el entorno → acumulación de retroalimentación → nueva evolución; el final se conecta con el inicio y el ciclo opera continuamente. El resultado de la verificación, como retroalimentación, impulsa la generación, selección y retención de la siguiente ronda de candidatos; el entorno de la tarea, el evaluador o la interfaz de ejecución real entran en el límite del sistema; los candidatos no solo se generan, sino que además se ejecutan y verifican realmente; las mejoras se sedimentan mediante mecanismos de retroalimentación y retención, y la capacidad puede acumularse con las rondas; está profundamente acoplado con el entorno, y los cambios del entorno entran directamente en la siguiente ronda de evolución. Cuando la tarea es compleja, el entorno real y se requiere verificación continua y acumulación de mejoras, debe adoptarse el bucle cerrado.

**Puntos clave de la enseñanza**

- Los cuatro eslabones del bucle tienen responsabilidades propias. Generar candidatos se encarga de proponer posibilidades
- La verificación en el entorno hace que los candidatos se ejecuten realmente en condiciones reales
- La acumulación de retroalimentación registra los resultados de la verificación
- La nueva evolución genera y retiene la siguiente generación de candidatos según la retroalimentación acumulada. Los cuatro se conectan de principio a fin; un fallo no desaparece al terminar la salida, sino que se convierte en el punto de partida de la siguiente ronda. Al mismo tiempo, hay que enfatizar que el bucle no elimina el papel humano, sino que cambia la posición de la persona: pasa del juicio ronda por ronda, la reproducción y el volver a preguntar, a diseñar criterios de evaluación, establecer reglas de selección y retención, y revisar condiciones de límite. Esta es la forma más concreta en que la "máquina niña" de Turing se aterriza hoy: no formarse de una vez, sino crecer en la experiencia. Un error común es equiparar directamente "alta calidad de generación" con "sistema confiable": que el modelo dé un plan aparentemente razonable no significa que el plan se sostenga en el entorno real
- Solo los candidatos que han pasado por ejecución y verificación reales pueden retenerse y convertirse en capacidad acumulable sostenible.

**Tratamiento de ejercicios**

Esta página tiene 5 preguntas de opción múltiple y 1 caso. Se sugiere usarlas después de explicar la tabla comparativa y los cuatro eslabones del bucle. La pregunta 1 elige "indicación → generación → salida, y tras la salida el proceso termina". Punto de retroalimentación: la cadena de preguntas y respuestas únicas solo tiene tres segmentos; la salida es el final y falta la vía que devuelve automáticamente el resultado de la ejecución al sistema; si los estudiantes eligen erróneamente los cuatro segmentos del bucle, se les recuerda que el enunciado pregunta por las preguntas y respuestas únicas tradicionales. La pregunta 2 elige "fuera del sistema, dependiendo del juicio humano, el filtrado y la reproducción del investigador". Punto de retroalimentación: la ubicación de la verificación es la clave del juicio; la verificación de las preguntas y respuestas únicas generalmente no se completa automáticamente dentro del sistema. La pregunta 3 elige "generación de candidatos → verificación en el entorno → acumulación de retroalimentación → nueva evolución".

Primero hay candidatos, luego entran al entorno para ser verificados realmente, y solo tras acumularse los resultados de la verificación se impulsa la siguiente ronda de evolución; la retroalimentación debe volver al eslabón de generación para cerrar el bucle. La pregunta 4 elige "los planes candidatos no solo se generan, sino que también se ejecutan y verifican realmente, y el resultado se convierte en la entrada de la siguiente ronda". Punto de retroalimentación: que el entorno entre en el límite significa que la verificación se incorpora al sistema; no reemplaza la generación ni omite la acumulación de retroalimentación. La pregunta 5 elige "cuando la tarea es compleja, el entorno real y se requiere verificación continua y acumulación de mejoras, debe adoptarse el bucle cerrado al estilo EvoX". Punto de retroalimentación: la base de selección es la complejidad de la tarea y el costo de verificación, no la velocidad de generación o la longitud de la salida. Si los estudiantes dudan, se les guía de vuelta a las tres filas de "mecanismo de verificación", "acumulación de mejoras" y "juicio de selección" de la tabla comparativa para buscar evidencia.

Sistema de agarre con brazo robótico en un almacén no estructurado. La respuesta a la pregunta 1 puede organizarse así: en la ruta de preguntas y respuestas únicas, la verificación se completa fuera del sistema; los ingenieros observan manualmente el resultado del agarre, reproducen escenarios de fallo y vuelven a preguntar; las mejoras quedan en el juicio del ingeniero y en registros documentales, y difícilmente se sedimentan automáticamente como capacidad del sistema. En la ruta de EvoX, el evaluador, la interfaz de ejecución real o el entorno de la tarea entran en el límite del sistema; los planes candidatos de agarre se ejecutan y verifican realmente; el resultado de la verificación vuelve a participar en la generación, selección y retención de la siguiente ronda de candidatos; las mejoras se sedimentan con las rondas en el mecanismo de retención. El papel humano no desaparece, sino que asciende del juicio y la reproducción ronda por ronda al diseño de criterios de evaluación (por ejemplo, cómo determinar que un agarre fue exitoso), al establecimiento de reglas de selección y retención, y a la revisión de seguridad y condiciones de límite.

Si la tarea puede generarse de una vez y el costo de verificación es bajo, por ejemplo, agarre repetitivo en una estación fija con objetos fijos, las preguntas y respuestas únicas son más directas y de menor costo; pero el entorno de este caso es no estructurado: las formas y pesos de los objetos varían, el apilamiento es aleatorio, la iluminación cambia, los estantes se mueven; si el plan se sostiene debe confirmarse mediante interacción repetida con el entorno real, y los modos de fallo también cambian constantemente, por lo que debe adoptarse el bucle cerrado al estilo EvoX, haciendo que los candidatos se verifiquen en el entorno real, que los resultados de la verificación se acumulen como retroalimentación, y que la retroalimentación impulse la siguiente ronda de generación y retención, haciendo que la capacidad del sistema crezca continuamente con las rondas. La fórmula es: si se logra de una vez y verificar es barato → preguntas y respuestas únicas; si es complejo y real y requiere verificación continua y acumulación → bucle cerrado evolutivo.

**Verificación de comprensión**

La diferencia de cadenas entre los tres segmentos del circuito abierto y los cuatro del bucle cerrado; si la verificación ocurre fuera o dentro del sistema; la selección depende de la complejidad de la tarea y el costo de verificación. El profesor complementa las palabras clave omitidas y la base de juicio según la respuesta.

> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar la relación central de esta página, se pasa a la siguiente página de ejemplos, aplicaciones o resumen. Se puede pedir a los estudiantes que primero repitan las dos cadenas, y luego tomen un sistema dado para juzgar si pertenece al circuito abierto o al bucle cerrado, explicando dónde ocurre la verificación y si las mejoras pueden sedimentarse.

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

### La visión de una infraestructura de evolución inteligente orientada al mundo real

*Página 16*

> **Objetivo de la página:** El estudiante debe comprender que el objetivo final de EvoX es construir una infraestructura que produzca, verifique y retenga mejoras continuamente en un mundo real complejo y cambiante.

> **Objetivo de la página**
>
> Cerrar el curso en la posición final de EvoX: no es un modelo ni un optimizador, sino una infraestructura de evolución inteligente orientada al mundo real. El estudiante debe poder explicar que EvoX debe poder conectarse a tareas reales, recibir retroalimentación real y, en operación prolongada, producir, verificar y retener mejoras de forma continua, formando finalmente un bucle de evolución sostenible.

**Puntos clave de la enseñanza**

- "¿En qué quiere convertirse finalmente EvoX?" La respuesta es un "campo de evolución" capaz de operar a largo plazo. Se explica con el diagrama: en el centro está la infraestructura de evolución inteligente EvoX, y los cuatro eslabones forman el bucle: generar candidatos → verificar efectos → retener mejoras → nueva evolución
- Externamente puede conectarse a tareas del mundo real, plataformas de experimentación y sistemas de producción; en la base, está sostenida por cómputo, modelos y evaluadores. La flecha circular vuelve al punto de partida, enfatizando que la acumulación de capacidad proviene del bucle, y no de una entrega lineal. Hacer del bucle un sistema que pueda funcionar siempre. EvoX sostiene la investigación y la práctica AI Native, organizando la conexión de tareas → generación de candidatos → evaluación y retroalimentación → bucle de evolución en una cadena estable
- No persigue que una salida sea bonita, sino convertirse en una capa base de la que otros sistemas puedan depender. Retroalimentación real, evolución a largo plazo, retención de mejoras. La retroalimentación real exige que el objeto de evolución entre en el entorno real; las métricas fuera de línea, los efectos de demostración y las salidas únicas no pueden sustituirla
- La evolución a largo plazo exige producir continuamente nuevos candidatos, verificar efectos reales y retener mejoras efectivas, para que la capacidad sea acumulable, reutilizable y evolucionable de nuevo
- La retención de mejoras exige que la parte verificada como efectiva se quede, en lugar de empezar de cero en cada ronda. Los objetivos se tensionan entre sí, el entorno deriva, los resultados traen incertidumbre. Por eso este sistema no promete una solución óptima de una vez, sino que se aproxima ronda tras ronda a la respuesta disponible en el momento mediante el bucle. Reconocer la incertidumbre es precisamente la premisa de la operación a largo plazo. Esta página solo responde a una pregunta de juicio: si el sistema ha organizado "retroalimentación real + evolución a largo plazo + retención de mejoras" en un bucle sostenible
- La visión solo se sostiene si las tres se cumplen simultáneamente.

**Tratamiento de ejercicios**

La pregunta 1 elige "una infraestructura de evolución inteligente orientada al mundo real"; la retroalimentación debe recaer en que la infraestructura puede conectarse a tareas reales, recibir retroalimentación real y, en operación prolongada, producir, verificar y retener mejoras de forma continua; si se elige erróneamente un modelo generativo, un optimizador único o una herramienta para inflar puntuaciones, se guía a los estudiantes de vuelta a la posición de esta página. La pregunta 2 elige "retroalimentación real, evolución a largo plazo, retención de mejoras", enfatizando que escala, velocidad y efectos de demostración no son condiciones de validez. La pregunta 3 elige "porque el objeto de evolución debe entrar en el entorno real y recibir retroalimentación real", explicando que las métricas fuera de línea no pueden sustituir la verificación en el entorno real; el punto clave no es el costo o la difusión.

La pregunta 4 elige "en operación continua, producir nuevos candidatos, verificar efectos reales y retener mejoras efectivas", enfatizando que producción—verificación—retención—nueva evolución constituyen un ciclo; la clave no es la cantidad de candidatos o lograrlo de una vez. La pregunta 5 elige "reconocer el compromiso multiobjetivo, la incertidumbre y la deriva del entorno, y no prometer una solución óptima de una vez", explicando que el entorno deriva, los objetivos entran en conflicto y el sistema necesita evolucionar continuamente.

En torno al escenario "conectar EvoX a una línea de producción real", primero se pide a los estudiantes que pregunten punto por punto con los tres criterios: ¿el objeto de evolución entra en la línea de producción real y recibe retroalimentación real, en lugar de evaluarse solo en un conjunto de prueba fuera de línea? ¿el sistema produce continuamente nuevos candidatos en operación continua, verifica efectos reales y retiene mejoras verificadas como efectivas? ¿la capacidad es acumulable, reutilizable y evolucionable de nuevo, en lugar de empezar de cero en cada ronda? Si la respuesta es negativa, sigue siendo una herramienta de generación única o de entrega desechable. Al diseñar más el bucle, pueden devolverse como base de verificación los resultados de inspección de calidad en línea, las conclusiones de reinspección humana y el rendimiento real tras la ejecución de la programación; explicitar el compromiso multiobjetivo y retener múltiples estrategias candidatas verificadas;

usar una ventana móvil para que los datos más antiguos pierdan peso gradualmente, identificando la deriva del entorno y activando una nueva ronda de evolución; en cada ronda retener solo las mejoras verificadas como efectivas, haciendo que la nueva capacidad se superponga sobre la antigua.

**Verificación de comprensión**

¿Hay retroalimentación real? ¿Hay evolución a largo plazo? ¿Hay retención de mejoras? Solo si las tres respuestas son "sí" el sistema se sostiene; si alguna es "no", sigue en la generación única o la entrega desechable. Al mismo tiempo, se recuerda a los estudiantes que el bucle no es una línea recta, sino un círculo que vuelve continuamente al punto de partida; hay que desconfiar de las afirmaciones de "de una vez y para siempre".

> **Sugerencia de transición**
>
> Esta es la página de cierre del curso; tras confirmar que los estudiantes pueden distinguir la infraestructura de evolución de las herramientas de generación única, se puede retomar la línea principal de este módulo: la tendencia acelerada de la evolución inteligente y las limitaciones de los grandes modelos, y la idea central de construir un bucle de evolución con EvoX.

--- FIN DEL TEXTO FUENTE ---

Idioma de origen: Chino (simplificado) 中文 (简体)
Idioma de destino: Español español
Por favor, traduzca el texto anterior al español, preservando la estructura y el formato originales.
Devuelva directamente el texto traducido sin envoltorios ni explicaciones adicionales.