# Sistema de Evolución Inteligente EvoX y Práctica de Investigación AI Native — Material del Curso
Duración: 1 · Páginas de diapositivas: 16
## Navegación de Lectura
- [Lección 7｜Tema: Paradigma de investigación AI Native y entrada práctica a EvoX](#lecture-lesson-1)
---
## Lección 7｜Tema: Paradigma de investigación AI Native y entrada práctica a EvoX
### Paradigma de investigación AI Native y entrada práctica a EvoX
*Página 1*
> **Objetivo de la página:** Dominar la ruta práctica para abordar EvoX en un entorno AI Native, y experimentar el principio central de la investigación: "Code is cheap. Taste matters."
> **Objetivo de la página**
>
> Esta es la página de apertura de la séptima lección, que establece el tono para toda la unidad "Paradigma de investigación AI Native y práctica de EvoX". Los estudiantes deben desarrollar dos comprensiones: primera, la ruta práctica para llevar a cabo experimentos de EvoX de manera eficiente con herramientas de IA como Codex en un entorno AI Native; segunda, cuando el código puede generarse automáticamente, las capacidades verdaderamente irremplazables del investigador — el criterio y la capacidad de formular preguntas clave, es decir, la frase que se enfatiza repetidamente en esta página: Code is cheap. Taste matters.
> **Orden de explicación**
>
> 1. Primero, presentar el escenario. Explicar que en la forma de trabajo AI Native, tareas "físicas" como escribir scripts de experimentos, construir flujos de optimización con EvoX y ejecutar experimentos comparativos pueden ser asumidas en gran parte por herramientas de IA, y el investigador ya no necesita escribir línea por línea. Esto cambia directamente el ritmo de hacer investigación: de "¿puedo escribirlo?" a "¿vale la pena hacerlo?".
>
> 2. Luego, aterrizar en el método. Al realizar experimentos con EvoX usando herramientas como Codex, el enfoque típico es explicar claramente la intención del experimento, la formulación del problema y los criterios de evaluación, dejar que la herramienta genere un esqueleto de programa ejecutable, y que el investigador se concentre en verificar si el diseño experimental es válido y si los resultados son confiables.
>
> 3. Finalmente, señalar el principio central. Dado que el código se ha vuelto barato, lo escaso se convierte en el juicio: si el tema tiene valor, si la línea base es justa, si las métricas explican el problema, si las conclusiones se sostienen. El Taste determina la dirección de la investigación, y la capacidad de formular preguntas determina la profundidad de la investigación.
**Puntos clave de enseñanza**
- Las herramientas de IA reducen el costo de implementación, no el umbral de la investigación
- El umbral se ha desplazado de la "competencia en programación" al "gusto por los problemas". Al usar herramientas como Codex, el rol humano es formular buenas preguntas, establecer criterios de evaluación y examinar los resultados generados, en lugar de aceptar pasivamente la salida. "Code is cheap. Taste matters." no niega la capacidad de ingeniería, sino que recuerda: en la era de la programación automatizada, el criterio y la capacidad de formular preguntas son el verdadero foso defensivo del investigador.
**Verificación de comprensión**
Pedir a un estudiante que explique con sus propias palabras, si el código puede generarse automáticamente, hacia dónde debería redirigirse el tiempo del investigador en los experimentos con EvoX. Una respuesta aceptable debe apuntar a trabajo de juicio como la selección del problema, el diseño experimental y la evaluación de resultados, no solo a "hacer que la IA escriba más rápido".
> **Indicación de transición**
>
> Después de confirmar que el estudiante puede expresar la relación central de "disminución del costo de implementación, aumento del valor del juicio", pasar a las páginas siguientes para desarrollar los pasos prácticos concretos y ejemplos de EvoX.
### Paradigma de investigación AI Native y entrada práctica a EvoX
*Página 2*
> **Objetivo de la página:** Comprender la ruta general para abordar EvoX en un entorno AI Native y los principios centrales de investigación.
> **Objetivo de la página**
>
> Conectar el "paradigma de investigación AI Native" y la "entrada práctica a EvoX" en una sola ruta — cuando el costo de implementación disminuye, el investigador debe desplazar su atención de escribir código hacia formular preguntas, definir evaluaciones, juzgar direcciones y criticar resultados, y recordar el principio central "Code is cheap. Taste matters.".
> **Orden de explicación**
>
> Primero explicar el cambio de paradigma, luego leer el diagrama de arquitectura, después explicar que EvoX no es una herramienta de un solo algoritmo, sino un sistema de evolución inteligente ejecutable, combinable y sosteniblemente explorable; finalmente aterrizar en la entrada práctica: cambiar de "seleccionar algoritmo" a "diseñar el proceso".
**Puntos clave de enseñanza**
- Los grandes modelos, GPU, Agentes y flujos de trabajo automatizados se convierten en infraestructura predeterminada de investigación. La implementación de código, los experimentos por lotes y la ampliación de la búsqueda son cada vez más baratos
- La IA se encarga de implementar respuestas, acelerar experimentos y ampliar la búsqueda
- El humano se encarga de la dirección, las restricciones, el gusto y las decisiones clave. La atención humana se eleva de "escribir código" a "definir estándares, tomar decisiones, evaluar resultados". Partiendo de "problemas reales · gusto por la investigación", el humano formula preguntas, define estándares y juzga direcciones
- Tras convertirse en exploración ejecutable, la infraestructura de IA lo asume y luego se entrega a EvoX. Dentro de EvoX hay cuatro eslabones: definición del problema (conflictos de objetivos, restricciones), diseño de evaluación (métricas, pesos, umbrales), proceso evolutivo (soluciones candidatas, iteración por lotes), programación de Runtime (cómputo, concurrencia, reproducibilidad). Se producen múltiples soluciones candidatas, resultados verificables y evolución continua, formando una salida de investigación criticable y reproducible, que a través del bucle de retroalimentación de "crítica y aceptación" regresa al punto de partida. Hereda la corriente del cómputo evolutivo, orientado a problemas complejos multiobjetivo, exploración abierta y evolución continua a nivel de sistema. No es un solucionador único, sino una base de ingeniería ejecutable, combinable y sosteniblemente explorable: los productos de un experimento pueden ser heredados por el siguiente, y el proceso de búsqueda en sí mismo puede evolucionar continuamente. Los cuatro pilares siguen siendo la definición del problema, el diseño de evaluación, el proceso evolutivo y la programación de Runtime. El error típico es tratar el punto de entrada como "elegir uno entre varios algoritmos". El punto de partida correcto es identificar primero los conflictos de objetivos y las restricciones, y transformar el problema en un proceso de exploración ejecutable, comparable y sosteniblemente evolutivo. El humano define primero los conflictos de objetivos, las restricciones y los criterios de aceptación
- La IA genera e itera código rápidamente
- EvoX ejecuta por lotes y compara soluciones candidatas
- Finalmente se forman resultados criticables y verificables. Por ejemplo, en un experimento de optimización multiobjetivo, no se debe dejar que la IA escriba todo el código y aceptar directamente la salida, sino que la máquina debe encargarse de la implementación y exploración, y el humano de la definición y el juicio. Code is cheap. Taste matters. Cuando el código ya no es escaso, el gusto por los problemas, los criterios de evaluación, el juicio de equilibrio y la capacidad de aceptación son las competencias de investigación más difíciles de reemplazar.
**Tratamiento de ejercicios**
Esta página incluye 5 preguntas de opción múltiple. La respuesta correcta de la pregunta 1 es "pasar de escribir código a formular preguntas, definir criterios de evaluación y juzgar direcciones"; punto de retroalimentación: la implementación y la exploración por lotes pueden delegarse a la IA, la responsabilidad central del humano es formular preguntas, definir estándares y juzgar resultados. La respuesta correcta de la pregunta 2 es "un sistema de evolución inteligente y base de ingeniería ejecutable, combinable y sosteniblemente explorable"; si hay error, recordar no simplificar EvoX a un algoritmo particular. La respuesta correcta de la pregunta 3 es "identificar primero los conflictos de objetivos y las restricciones, y transformar el problema en un proceso de exploración ejecutable"; enfatizar que el punto de entrada no es la selección de algoritmo ni la configuración de parámetros. La respuesta correcta de la pregunta 4 es "cuando el código ya no es escaso, el gusto por los problemas, los criterios de evaluación y el juicio de aceptación se convierten en capacidades más escasas";
no niega la implementación y verificación, sino que enfatiza el desplazamiento de la escasez. La respuesta correcta de la pregunta 5 es "dejar que la IA escriba todo el código y adoptar directamente sus resultados de ejecución, sin definir manualmente objetivos y estándares"; esto entra en conflicto con la división de "IA implementa y explora, humano define y juzga".
Diseñar un experimento de optimización multiobjetivo con EvoX. El escenario requiere optimizar simultáneamente costo, rendimiento y robustez, con tres métricas que entran en conflicto mutuo, y sujetas a restricciones de presupuesto de cómputo y plazo de entrega. La división humano-máquina debe escribirse así: el humano se encarga de la definición y el juicio — formular preguntas, escribir explícitamente los conflictos de objetivos y las restricciones, diseñar métricas de evaluación y umbrales de aceptación, y hacer juicios de dirección y aceptación crítica frente a los resultados; la IA se encarga de la implementación y exploración — generar e iterar código rápidamente, ejecutar candidatos por lotes, ampliar la búsqueda y acelerar experimentos. Ambos forman el bucle cerrado de "el humano define la dirección — la IA amplía la exploración — el humano hace la aceptación".
Si los conflictos de objetivos no se definen explícitamente, los criterios de evaluación son vagos y las restricciones se ignoran, los resultados son difíciles de juzgar en cuanto a mérito, reproducibilidad y sedimentación; se debe cambiar el enfoque hacia el diseño del proceso, aclarar la definición del problema y el método de evaluación, planificar la generación de soluciones candidatas, la comparación por lotes y la programación de Runtime, e incorporar los resultados de cada ronda a la crítica y aceptación.
**Actividad en clase**
Pedir a los estudiantes que elijan un problema familiar, escriban en una frase el conflicto de objetivos y el criterio de aceptación, y luego expliquen qué segmento asume la IA y cuál EvoX. Verificación de comprensión: pedir aleatoriamente a un estudiante que repita "por qué primero definir la evaluación y luego tocar el código", y que señale la función del bucle de retroalimentación en el diagrama de arquitectura. Indicación de transición: después de confirmar que los estudiantes pueden distinguir capacidades baratas de capacidades escasas, pasar a la siguiente página con ejemplos, aplicaciones o resumen.
### Límites de capacidad de los grandes modelos y sistemas de evolución continua
*Página 3*
> **Objetivo de la página:** Comprender la brecha entre el crecimiento de capacidad de los grandes modelos y la construcción de sistemas que se adapten al mundo real a largo plazo.
**Puntos clave de enseñanza**
- Al ver afirmaciones como "mejora de la capacidad del modelo", preguntar dos cosas: ¿dónde se sedimentan los resultados efectivos de esta ronda? ¿Quién los hereda en la siguiente ronda? Si no se puede responder, lo que mejora es solo la capacidad de una invocación única, no la capacidad de adaptación a largo plazo del sistema.
- Primero producir candidatos → luego verificar en el mundo real → sedimentar en el repositorio → heredar y evolucionar de nuevo. El orden no se puede cambiar: sin candidatos no hay nada que verificar, sin verificación no se puede hablar de sedimentación, sin sedimentación no hay punto de partida heredable.
- Dos malentendidos frecuentes: tomar "buen desempeño en una tarea única" como "el sistema puede adaptarse a largo plazo"; tomar "candidatos no verificados" como "conclusiones existentes". El método de autoverificación es ver si este resultado ha pasado la verificación real y si se ha escrito en una versión de proyecto heredable.
Objetivo de la página**
El "crecimiento de capacidad" de los grandes modelos y la "adaptación a largo plazo" del sistema no son lo mismo. Los estudiantes necesitan entender por qué fortalecer la capacidad del modelo no equivale automáticamente a que el proyecto pueda evolucionar continuamente en el mundo real, y de qué eslabones debe componerse un bucle cerrado a nivel de sistema.
Orden de explicación**
Se recomienda avanzar en el orden de "componentes de capacidad → por qué no es suficiente → bucle cerrado de cuatro pasos → relación entre componentes y sistema → autoverificación de errores". Primero explicar claramente qué puede hacer el gran modelo, luego crear la brecha cognitiva (fuerte en una ocasión ≠ estable a largo plazo), después dar la estructura de bucle cerrado como solución, y finalmente cerrar con el par conceptual "componente—sistema".
Puntos clave de enseñanza**
Uno. Tres tipos de capacidad que ofrecen los grandes modelos. Ya pueden asumir de manera estable comprensión fuerte, generación e invocación de herramientas: analizar objetivos y restricciones en descripciones de tareas ejecutables; producir hipótesis candidatas, código, diseños experimentales y documentación; conectar recursos externos como recuperación, cómputo, compilación y simulación. Por lo tanto, integrar grandes modelos como "componentes inteligentes" en flujos de investigación e ingeniería ya es una práctica viable en la realidad. Pero hay que aclarar: estas tres capacidades responden a "¿puede hacerse bien una tarea única?", no a "¿puede hacerse bien de forma continua una tarea a largo plazo?".
Dos. Por qué ser fuerte en una ocasión no es suficiente. Los proyectos de ingeniería reales suelen durar meses o incluso años, y el contexto de un solo Agente eventualmente se agota. Si la experiencia no puede sedimentarse, cada ronda de trabajo comienza desde cero, y el crecimiento de capacidad no se traducirá automáticamente en capacidad de adaptación a largo plazo. Aquí se puede plantear: es necesario expandir el objeto de evolución a un "mundo de software" persistente, y depender de la persistencia a nivel de proyecto para que la experiencia no se pierda con cada experimento único.
Los componentes inteligentes proponen hipótesis, modificaciones o implementaciones; en ese momento son solo candidatos, no conclusiones; verificación real: los candidatos deben pasar por entornos reales, simulación o experimentos, y superar barreras como compilación, pruebas, verificación de comportamiento y aceptación de nivel superior; sedimentación de resultados: solo los resultados efectivos que pasan la verificación se escriben en la versión aceptada del proyecto, convirtiéndose en activos reutilizables; re-evolución: el trabajo posterior hereda los resultados sedimentados y continúa proponiendo candidatos sobre esa base. La fórmula es "primero producir candidatos → luego verificar en el mundo real → sedimentar en el repositorio → heredar y evolucionar de nuevo". Hay que enfatizar la dependencia lógica: sin candidatos no hay nada que verificar, sin verificación no se puede hablar de sedimentación, sin sedimentación no hay punto de partida heredable.
Cuatro. Tomar como ejemplo de bucle cerrado un sistema de colaboración multi-Agente como Genesis. Los Agentes que participan en el trabajo tienen un ciclo de vida limitado; el ejecutor de nivel superior comprende los objetivos y descompone tareas recursivamente, el ejecutor de nivel inferior completa la implementación y prueba local, y si es necesario continúa la recursión hacia abajo; las modificaciones candidatas se envían solo como candidatas, y deben pasar compilación, pruebas, verificación de comportamiento y aceptación de nivel superior para ser aceptadas, los intentos fallidos son rechazados, y los resultados verificados se escriben en la versión del proyecto, convirtiéndose en la base histórica para ejecutores posteriores. En escenarios como la refactorización de compiladores y la actualización de software científico, este mecanismo muestra alta confiabilidad y altas tasas de aceleración de ejecución.
Los componentes de capacidad se encargan de producir candidatos de alta calidad en un punto único; el bucle cerrado del sistema se encarga de determinar qué candidatos merecen quedarse, cómo quedarse y cómo ser heredados por la siguiente ronda. Sin el bucle cerrado, cuanto más fuerte sea la capacidad, más candidatos no verificados se producirán; sin componentes fuertes, el bucle cerrado carece de fuentes de candidatos de alta calidad.
Seis. Errores comunes y métodos de autoverificación. La mala interpretación más común es equiparar directamente "mejora de la capacidad del modelo" con "el sistema puede adaptarse a largo plazo". El criterio no es qué tan bien se desempeña el modelo en una tarea particular, sino si los resultados efectivos pueden sedimentarse de manera estable y ser heredados por la siguiente ronda de trabajo. Se puede enseñar a los estudiantes dos preguntas: ¿dónde se sedimentan los resultados efectivos de esta ronda? ¿Quién los hereda en la siguiente ronda? Si no se puede responder, lo que mejora es solo la capacidad de invocación única. Otro error es tomar "candidatos no verificados" como "conclusiones existentes"; el método de autoverificación es ver si ha pasado la verificación real y se ha escrito en una versión de proyecto heredable.
Pistas de material**
A la izquierda está el área de componentes de "capacidad del gran modelo", que enumera comprensión, generación e invocación de herramientas; a la derecha está el "bucle cerrado del sistema de evolución continua", compuesto por cuatro nodos: producción de candidatos, verificación real, sedimentación de resultados y re-evolución, con la anotación central "los componentes de capacidad necesitan ser organizados por el sistema". Al explicar, se puede recorrer el bucle cerrado con los estudiantes siguiendo las flechas, y luego señalar a la izquierda, explicando que los componentes solo tienen valor a largo plazo cuando son organizados por el sistema.
Pistas de ejercicios y guía de respuestas**
La posición correcta del gran modelo en el flujo (componente inteligente que puede ser organizado por el sistema, encargado de comprensión, generación e invocación de herramientas); por qué el crecimiento de capacidad no equivale a adaptación a largo plazo (el contexto de una sesión única se agota, y los resultados no verificados no pueden sedimentarse como activos heredables); el orden correcto de los eslabones del bucle cerrado (producción de candidatos → verificación real → sedimentación de resultados → re-evolución); el umbral para que el código entre en la historia del proyecto en Genesis (pasar compilación, pruebas y verificación de comportamiento, y ser aceptado por el nivel superior); y la formulación precisa de la relación "componente—sistema".
La pregunta de caso requiere diseñar un bucle cerrado a nivel de sistema para un laboratorio de cómputo científico de largo plazo, y dar mecanismos para "soluciones fallidas reintentadas repetidamente" y "nuevos miembros que no pueden heredar conclusiones tempranas". Los puntos clave de la respuesta son: usar una puerta de aceptación estricta y registros de decisiones para rechazar candidatos no aprobados y conservar las razones del fallo, y usar persistencia a nivel de proyecto para escribir los resultados aceptados en la versión aceptada del proyecto; también señalar que simplemente mejorar la capacidad del modelo solo eleva la calidad de los candidatos individuales, mientras que la raíz de estos dos problemas es la falta de verificación, registro y sedimentación.
Verificación de comprensión**
Por qué un modelo más fuerte no equivale a un proyecto que evoluciona mejor a largo plazo, y qué problema resuelve cada uno de los cuatro pasos del bucle cerrado. Si la respuesta se queda en "el modelo es muy poderoso", se puede sugerir volver a las dos preguntas de "¿dónde se sedimentan los resultados efectivos y quién los hereda?" para completarla.
Indicación de transición**
Después de confirmar que los estudiantes pueden distinguir "la calidad de un candidato único" de "el filtrado, la sedimentación y la herencia a nivel de sistema", pasar a la siguiente página con aplicaciones, ejemplos o práctica.
### Transformar problemas reales en procesos de exploración con EvoX
*Página 4*
> **Objetivo de la página:** Dominar cómo definir objetos variables, criterios de evaluación y mecanismos de retención frente a problemas reales.
> **Objetivo de la página**
>
> Dominar cómo definir objetos variables, criterios de evaluación y mecanismos de retención frente a problemas reales, y comprender el orden de "primero hacer la transformación del problema, luego hablar de selección de algoritmo".
> **Orden de explicación**
>
> Problema real (demanda descriptible) → definición de objetos variables (variables muestreables) → construcción de criterios de evaluación (objetivos calculables) → mecanismo de retención y selección (candidatos heredables) → exploración iterativa con EvoX (cada generación reproducible) → salida de soluciones candidatas (conclusiones medibles).
>
> Cuando la evaluación se distorsiona, retroceder a la construcción de criterios de evaluación; cuando la diversidad colapsa, retroceder al mecanismo de retención.
>
> 3. Luego desarrollar en orden las cuatro condiciones de aceptación, y usar el diseño de perfil supercrítico para ilustrar el método de mapeo.
>
> 4. Finalmente, verificar la comprensión con cinco preguntas de verdadero/falso y el caso de la placa de refrigeración de la batería.
**Puntos clave de enseñanza**
- Transformar un problema real en un proceso de exploración con EvoX consiste en, antes de escribir cualquier configuración de algoritmo, reescribir una demanda vaga de ingeniería o investigación como una definición de problema evolutivo "muestrable, evaluable, retenible e iterativamente verificable". EvoX asume una línea de exploración, y necesita saber en qué espacio muestrear, con qué criterios puntuar y qué resultados merecen continuar. Esta información solo puede venir del problema mismo. El algoritmo solo puede buscar respuestas dentro de la definición, y no puede recuperar la respuesta correcta de un problema mal definido. Traducir la demanda real a variables de decisión, determinar la forma de representación, las dimensiones y los límites, y distinguir parámetros continuos, estructuras discretas e incluso objetos a nivel de programa. Unos límites demasiado estrechos excluirán la verdadera solución óptima del espacio de búsqueda
- Variables muestreables. Descomponer objetivos vagos en funciones objetivo y restricciones calculables, aclarar métricas de maximización, restricciones duras y compensaciones multiobjetivo. Cuando la retroalimentación es escasa o la simulación es costosa, introducir modelos sustitutos para reemplazar el cómputo de alto costo. Condición de aceptación: objetivo calculable, y resultados estables y reproducibles con la misma entrada. Definir cómo se guardan, comparan y continúan los candidatos, para que el proceso evolutivo tenga memoria, dirección y diversidad, en lugar de ser rondas de prueba y error desechables e inconexas. Condición de aceptación: candidatos heredables. El resultado de la transformación debe ser reproducible, medible e iterativamente verificable, y cada paso debe poder responder "¿este cambio es realmente mejor?". Omitir variables lleva a malinterpretar el espacio de soluciones, y la distorsión de la evaluación desvía toda la optimización
- Ambos tipos de desviación no pueden compensarse con operadores posteriores o más iteraciones. En el diseño de perfil supercrítico, los objetos variables son los parámetros de perturbación geométrica del perfil base
- Los criterios de evaluación son métricas multiobjetivo como la relación sustentación-arrastre, la divergencia de arrastre y la robustez, y se usan modelos sustitutos para controlar el costo de simulación
- El mecanismo de retención es producir un conjunto diversificado de soluciones candidatas que equilibren las distintas métricas, para que expertos del dominio tomen decisiones de compromiso. Para un mismo problema real, basta cambiar un conjunto de límites de variables o un criterio de evaluación para que las conclusiones de exploración sean completamente diferentes.
**Cobertura de palabras clave**
- Transformación del problema, definición de objetos variables, variables muestreables, construcción de criterios de evaluación, objetivos calculables, mecanismos de retención y selección, candidatos heredables, exploración iterativa con EvoX, cada generación reproducible, distorsión de la evaluación, colapso de la diversidad, modelos sustitutos, perfil supercrítico.
**Tratamiento de ejercicios**
La respuesta correcta es "porque la transformación determina el espacio de búsqueda y el criterio de evaluación, y el algoritmo solo puede buscar respuestas dentro de esta definición". Al explicar, enfatizar que la transformación responde a "qué puede cambiar" y "cómo se evalúa después del cambio", y que tanto el límite superior del espacio de exploración como la dirección de optimización son determinados por ella; el costo de muestreo o el tipo de operador no son lo clave.
La respuesta correcta es "el espacio de búsqueda es demasiado estrecho, la verdadera solución óptima no está en él, y los operadores e iteraciones posteriores no pueden compensarlo". La omisión de variables es una desviación en la etapa de transformación; la función de evaluación, el mecanismo de retención y los operadores no pueden crear dimensiones no definidas de la nada.
La respuesta correcta es "usar modelos sustitutos para aproximar la evaluación a bajo costo, y al mismo tiempo preservar explícitamente las relaciones de compensación multiobjetivo y las restricciones duras". Cuando la evaluación es costosa y los objetivos entran en conflicto, la práctica correcta es reducir el costo de evaluación individual y expresar explícitamente los conflictos y restricciones, no reducir las generaciones de iteración ni hacer una simple combinación ponderada.
La respuesta correcta es "hacer que los candidatos se guarden, comparen y continúen, para que el proceso evolutivo tenga memoria, dirección y diversidad". El mecanismo de retención no se encarga de la evaluación ni de corregir los límites de las variables.
La respuesta correcta es "cada paso debe ser reproducible y poder responder '¿este cambio es realmente mejor?', de lo contrario la desviación se amplificará en las iteraciones". Una evaluación global a posteriori no puede sustituir la verificación paso a paso; la omisión de variables y la distorsión de la evaluación ocurren en la etapa de transformación, y las iteraciones solo amplifican la desviación.
Cuando aciertan, confirmar que el estudiante puede conectar con los conceptos de esta página y explicar la base; cuando fallan, pedir al estudiante que vuelva al párrafo correspondiente, encuentre la evidencia clave o el ejemplo y luego juzgue.
> **Pistas de ejercicios**
>
> - Optimización geométrica de los canales de flujo de la placa de refrigeración de la batería. Tomar solo el ancho del canal como variable de decisión, ignorando la dirección del canal, la forma topológica, el número de niveles de ramificación, la posición de entrada y salida y otros grados de libertad de estructura discreta, es una definición demasiado estrecha de los objetos variables, y la geometría verdaderamente óptima puede no estar en el espacio de búsqueda
> - Tomar solo la temperatura máxima como objetivo único, dejando la caída de presión y la uniformidad de temperatura al juicio empírico, es una distorsión de los criterios de evaluación, y el conflicto multiobjetivo no se modela explícitamente
> - Una simulación de 3 horas por vez multiplicada por 200 generaciones, sin control del costo de evaluación ni criterio de verificación reproducible, seleccionando directamente de los resultados el individuo que "parece mejor", no puede responder "¿este cambio es realmente mejor?". En objetos variables, incluir tanto parámetros continuos (ancho, profundidad, espesor de pared del canal) como estructuras discretas (topología del canal, número de niveles de ramificación, posición de entrada y salida), escribir los rangos de valores o el método de codificación, y distinguir cantidades fijas; la condición de verificación es que las variables sean muestreables. En criterios de evaluación, escribir la temperatura máxima, la caída de presión y la uniformidad de temperatura como funciones objetivo multiobjetivo explícitas, escribir el límite superior de caída de presión y la viabilidad de fabricación como restricciones duras, usar modelos sustitutos para asumir la mayor parte de la evaluación y calibrar periódicamente con simulación real; la condición de verificación es que el objetivo sea calculable y estable y reproducible con la misma entrada. En el mecanismo de retención, guardar un conjunto diversificado de candidatos que equilibren los objetivos, en lugar de una única solución óptima, definir reglas de comparación y reglas de continuación, y monitorear la homogeneización con métricas de diversidad; la condición de verificación es que los candidatos sean heredables. En la ejecución y verificación, registrar generación por generación métricas reproducibles
> - Si la confiabilidad de la evaluación disminuye, retroceder a la construcción de criterios de evaluación para recalibrar
> - Si la diversidad colapsa, retroceder al mecanismo de retención para ajustar la estrategia de filtrado y continuación.
**Actividad en clase**
Pedir a los estudiantes que reescriban en una frase "hacer mejor este diseño" como una definición de problema de exploración que incluya objetos variables, criterios de evaluación y mecanismos de retención, y que se revisen mutuamente si cumple con "muestrable, calculable, heredable, reproducible".
**Verificación de comprensión**
Pedir aleatoriamente a un estudiante que resuma con sus propias palabras los puntos clave de esta página, y el profesor complementa las condiciones de aceptación y los bucles de retroalimentación omitidos según la respuesta.
> **Indicación de transición**
>
> Después de confirmar que los estudiantes pueden expresar "primero definir, luego encender el optimizador" y los dos tipos de mecanismos de retroceso, pasar a la siguiente página con ejemplos, aplicaciones o resumen.
### Optimización multiobjetivo y exploración multi-solución
*Página 5*
> **Objetivo de la página:** Reconocer la complejidad de las compensaciones multiobjetivo en el mundo real y la necesidad de retener un conjunto de soluciones candidatas.
> **Objetivo de la página**
>
> Reconocer la complejidad de las compensaciones multiobjetivo en el mundo real, comprender por qué es necesario retener un conjunto de soluciones candidatas, y dominar la dominancia de Pareto, el frente de Pareto, el costo de la escalarización y la evaluación bidimensional de convergencia y diversidad.
**Puntos clave de enseñanza**
- ¿Es realmente un problema multiobjetivo? El criterio no es "el número de objetivos es mayor que 1", sino si los objetivos se compensan mutuamente. Tomando el diseño de perfil supercrítico como ejemplo: la relación sustentación-arrastre, la resistencia estructural, el margen de pérdida y el costo de fabricación/simulación se compensan mutuamente; mejorar la relación sustentación-arrastre suele implicar un aumento simultáneo de la carga estructural y el costo de fabricación. Si todos los objetivos pueden mejorarse simultáneamente sin pérdida, el problema degenera en uno de objetivo único, y la exploración multi-solución no solo es innecesaria, sino que desperdicia cómputo. Direcciones opuestas y compensación mutua son lo que constituye un verdadero problema multiobjetivo. Dos. Dominancia de Pareto y frente de Pareto. La solución A domina a la solución B si y solo si A no es peor que B en todos los objetivos (para cada objetivo i, fᵢ(A) ≤ fᵢ(B)), y es estrictamente mejor en al menos un objetivo (existe j tal que fⱼ(A) < fⱼ(B)). Cualquier solución dominada tiene un sustituto que es "al menos igual de bueno y mejor en algún aspecto", por lo que no tiene valor de retención. Todas las soluciones no dominadas por ninguna otra constituyen el frente de Pareto — las soluciones del frente no se dominan entre sí, y cuál es más adecuada depende de las preferencias, no de las matemáticas. Tres. El costo de la unificación a objetivo único. Métodos de escalarización como la suma ponderada y las ε-restricciones comprimen objetivos vectoriales en un escalar, lo cual es conveniente en ingeniería, pero el costo es muy concreto: Oculta la estructura de compensaciones — una vez fijados los pesos, la forma del frente y las direcciones alternativas se vuelven invisibles, y el decisor solo ve una puntuación. Los pesos deben darse de antemano — pero las preferencias reales a menudo no pueden formalizarse de antemano, y suelen aclararse gradualmente hasta la etapa de revisión. Cobertura limitada — la suma ponderada normalmente solo alcanza puntos individuales del frente, y algunas secciones del frente no convexo son difíciles de alcanzar. Una vez que una revisión posterior cambia los pesos, toda la búsqueda debe re-ejecutarse, lo cual es exactamente lo contrario de "una exploración a cambio de libertad de decisión múltiple". Convergencia y diversidad. Convergencia (si el conjunto de soluciones se aproxima al frente real) y diversidad (si las soluciones cubren diferentes secciones del frente). Ambas frecuentemente se tensionan mutuamente: una vez que la presión selectiva se inclina demasiado hacia "mejor", la población colapsa a un punto o un pequeño segmento del frente, pareciendo converger rápido, pero perdiendo la información de compensaciones. Por lo tanto, es necesario mantener explícitamente la diversidad de la población, y combinar presiones selectivas como el hacinamiento, la descomposición y las métricas impulsadas (como el hipervolumen). La posición de decisión se desplaza. El optimizador solo se encarga de producir grupos de candidatos comparables, y la selección final la realizan las preferencias o expertos del dominio; el optimizador no debe converger prematuramente en lugar del decisor. La razón práctica para retener grupos de candidatos diferenciados es la "cobertura" — cuando las preferencias son desconocidas, cambian según el contexto, o las restricciones se corrigen en la etapa de implementación, un grupo diversificado de soluciones es más valioso que una única "solución óptima". En cuanto a la interfaz de implementación, un problema multiobjetivo debe definirse como una función de evaluación de valor vectorial (que devuelve múltiples valores objetivo a la vez) y una salida de conjunto de soluciones candidatas, en lugar de una aptitud escalar con un único valor de retorno. El número de valores de retorno de la función de evaluación determina la dimensión de los objetivos, y la estructura de salida determina si se puede preservar la diversidad.
> **Pistas de material**
>
> - La página ofrece un diagrama de dispersión del frente de Pareto bidimensional, con el eje horizontal como objetivo 1: calidad estructural (cuanto menor, mejor), y el eje vertical como objetivo 2: costo de fabricación (cuanto menor, mejor). En el diagrama se marcan soluciones no dominadas, soluciones dominadas, el frente de Pareto, puntos de impacto de la escalarización, direcciones de mejora, zonas dispersas y zonas densas. Con este diagrama se puede explicar intuitivamente la relación de dominancia, la forma del frente y la diversidad, y mostrar que la suma ponderada normalmente solo puede alcanzar puntos individuales del frente.
> **Pistas de ejercicios**
>
> - La página contiene 5 preguntas de opción única y 1 estudio de caso. La pregunta 1 evalúa la determinación de dominancia de Pareto, y la respuesta correcta es "la solución A domina a la solución B si y solo si A no es peor que B en todos los objetivos y es estrictamente mejor en al menos un objetivo". Al guiar, enfatizar que ambas condiciones deben cumplirse simultáneamente; las soluciones con ventajas y desventajas mutuas no se dominan entre sí y permanecen simultáneamente en el frente de Pareto. La pregunta 2 evalúa el criterio para juzgar un problema multiobjetivo, y la respuesta correcta es "las direcciones de los objetivos son opuestas, mejorar uno necesariamente tiene como costo el deterioro de otro". Al guiar, señalar que el conflicto es la esencia de lo multiobjetivo, y que lo clave no es el número de objetivos, sino la relación de compensación mutua. La pregunta 3 evalúa el juicio sobre los métodos de escalarización, y la respuesta correcta es "la escalarización oculta la estructura de compensaciones y requiere que los pesos se den de antemano, mientras que las preferencias reales a menudo no pueden formalizarse de antemano". Al guiar, recordar dos costos: ocultar la estructura de compensaciones y requerir pesos predeterminados. La pregunta 4 evalúa la relación entre convergencia y diversidad, y la respuesta correcta es "ambas frecuentemente se tensionan mutuamente, y perseguir excesivamente la convergencia fácilmente hace que la población colapse a secciones individuales del frente". Se puede preguntar: si todas las soluciones se aglomeran en un punto del frente, aunque parezca convergencia, ¿puede el decisor aún elegir? La pregunta 5 evalúa la división del trabajo entre el optimizador y el decisor, y la respuesta correcta es "el optimizador produce un conjunto de candidatos no dominados comparables, y la selección final se deja a las preferencias o expertos del dominio". Al guiar, explicar que la posición de decisión se ha desplazado, y que el valor de la optimización multiobjetivo radica precisamente en retener el grupo de candidatos. El estudio de caso gira en torno a las compensaciones multiobjetivo del perfil supercrítico. La pregunta 1 requiere explicar por qué constituye un verdadero problema multiobjetivo, y el riesgo de usar una puntuación ponderada total para producir una única "ala óptima" en la etapa de revisión. Puntos clave de la respuesta: las direcciones de los objetivos son opuestas y se compensan mutuamente, no pueden mejorarse simultáneamente sin pérdida
> - La puntuación ponderada total oculta la estructura de compensaciones y requiere pesos predeterminados; una vez ajustados los pesos, se debe re-ejecutar, y el presupuesto de simulación difícilmente lo soporta. La pregunta 2 requiere explicar cómo definir la función de evaluación y la estructura de salida, y cómo seleccionar en el sitio de revisión. Puntos clave de la respuesta: cambiar la función de evaluación a forma de valor vectorial, devolviendo una cuádrupla (relación sustentación-arrastre, calidad estructural, margen de pérdida, costo de fabricación y simulación)
> - la salida es un conjunto de soluciones candidatas, es decir, un conjunto de soluciones del frente de Pareto mutuamente no dominadas
> - a nivel de algoritmo, mantener explícitamente la diversidad, combinando presiones selectivas como hacinamiento, descomposición o hipervolumen
> - en el sitio de revisión, seleccionar del grupo de candidatos según las preferencias reales. Cuando aciertan, confirmar que el estudiante puede conectar con los conceptos de esta página y explicar la base
> - cuando fallan, pedir al estudiante que vuelva a la explicación de esta página, encuentre la evidencia clave o el ejemplo y luego juzgue.
**Actividad en clase**
Se puede pedir a los estudiantes que den un ejemplo cotidiano de conflicto multiobjetivo (como la compensación entre rendimiento, precio y autonomía al comprar un teléfono), que expliquen por qué no existe una única solución óptima y el valor de retener un conjunto de soluciones candidatas.
**Verificación de comprensión**
Pedir aleatoriamente a un estudiante que resuma con sus propias palabras los puntos clave de esta página, y el profesor complementa las palabras clave omitidas, como dominancia de Pareto, frente de Pareto, convergencia, diversidad, colapso de población, función de evaluación de valor vectorial.
> **Indicación de transición**
>
> Después de confirmar que los estudiantes pueden expresar la esencia del problema multiobjetivo (conflicto de objetivos) y el significado del frente de Pareto y la diversidad, pasar a la siguiente página con ejemplos, aplicaciones o resumen.
**Base documental**
Del borrador de EvoClass, página 7-7.
### MetaDE: mejorar algoritmos evolutivos con algoritmos evolutivos
*Página 6*
> **Objetivo de la página:** Comprender cómo tomar el método mismo que produce soluciones candidatas como objeto de evolución.
**Puntos clave de enseñanza**
- La capa interna responde "qué se calcula", la capa externa responde "cómo calcular mejor". Entre ambas capas solo se transmite una señal — el rendimiento en la tarea, es decir, la aptitud.
- No tomar la solución obtenida por la capa interna como el resultado final de MetaDE. El verdadero producto es una configuración de algoritmo transferible: al cambiar a nuevas instancias de la misma clase, la configuración sigue siendo válida, mientras que una solución individual a menudo ya ha caducado.
- Cerrar el material y preguntarse: ¿a cuántas ejecuciones completas de la capa interna equivale aproximadamente una evaluación de la capa externa? Si no se puede responder, significa que aún no se ha captado la estructura de costos de MetaDE y por qué el paralelismo es necesario.
【Objetivo de la página】
Comprender cómo tomar el método mismo que produce soluciones candidatas como objeto de evolución, es decir, el bucle cerrado de optimización de dos capas en el que MetaDE mejora algoritmos evolutivos con algoritmos evolutivos.
【Orden de explicación】
¿Quién eligió estas configuraciones como la estrategia de mutación, la tasa de cruce CR, el factor de escala F y el tamaño de población NP?
La capa externa codifica configuraciones y evoluciona, la capa interna ejecuta DE en paralelo sobre tareas reales y devuelve la evaluación de rendimiento.
Pasar de "encontrar soluciones" a "encontrar métodos que sepan encontrar soluciones".
Distribución de configuración → resolución en la capa interna → retorno de rendimiento → actualización de la capa externa; el costo de evaluación es alto, y el paralelismo con GPU es la condición habilitante clave.
5. Resumir la esencia en una frase y los errores comunes, realizar ejercicios y verificación de comprensión.
【Puntos clave de enseñanza】
La capa interna recibe un conjunto concreto de configuraciones de DE, ejecuta una resolución completa sobre una tarea real, produce soluciones candidatas y devuelve una evaluación de rendimiento comparable; la capa externa codifica las configuraciones, hiperparámetros o combinaciones de estrategias de DE como individuos, usa el rendimiento en la tarea como aptitud, y actualiza la configuración de la siguiente generación mediante selección, recombinación y mutación.
La salida del DE tradicional es un vector de solución; la salida de MetaDE es un conjunto de configuraciones de algoritmo capaces de producir de manera estable mejores soluciones en este tipo de tareas. El objeto de búsqueda asciende de "la respuesta" a "la máquina que produce respuestas", lo que permite que los resultados de una búsqueda de la capa externa se transfieran y reutilicen en otras instancias de la misma familia.
Todo el sistema se conecta mediante un bucle cerrado — la capa externa distribuye configuraciones → la capa interna ejecuta la resolución → el rendimiento retorna → la capa externa actualiza la siguiente generación de configuraciones sobre esa base. Para que un individuo de la capa externa obtenga aptitud, debe pagar el costo de una ejecución completa de la capa interna (a menudo múltiples en paralelo), por lo que la gestión del costo de evaluación y la programación paralela son el núcleo del diseño del sistema. Es precisamente la capacidad de la GPU de ejecutar simultáneamente una gran cantidad de tareas de la capa interna lo que hace que esta meta-optimización de "evaluación costosa" sea viable en ingeniería.
La capa interna se encarga de "qué se calcula", la capa externa se encarga de "cómo calcular mejor". Ambas capas comparten la misma señal de aptitud — el rendimiento en la tarea, lo cual es precisamente la razón por la que pueden formar un bucle cerrado.
【Cobertura de palabras clave】
Optimización de dos capas, capa interna, capa externa, aptitud, distribución de configuración, retorno de rendimiento, paralelismo con GPU, costo de evaluación, configuración de evolución diferencial (estrategia de mutación, tasa de cruce CR, factor de escala F, tamaño de población NP).
【Pistas de ejercicios】
El objeto de evolución de la capa externa es la configuración del algoritmo; la responsabilidad de la capa interna es recibir la configuración, resolver sobre la tarea real y devolver la evaluación de rendimiento; el orden del bucle cerrado de información es distribución de configuración → resolución en la capa interna → retorno de rendimiento → actualización de la capa externa; en comparación con el DE tradicional, el desplazamiento de objetivo es de buscar la solución óptima de un problema individual a buscar algoritmos y configuraciones que produzcan mejores soluciones; el principal costo computacional proviene de que evaluar un individuo de la capa externa requiere el costo de una ejecución completa de la capa interna, y el paralelismo con GPU ejecuta simultáneamente una gran cantidad de tareas de la capa interna, haciendo viable en ingeniería la meta-optimización.
Cuando aciertan, confirmar que pueden conectar con los conceptos de esta página y explicar la base; cuando fallan, sugerir volver a la explicación de esta página, encontrar la evidencia clave o el ejemplo y luego juzgar.
Configuración de MetaDE para un solucionador de rutas logísticas. La capa interna ejecuta completamente DE sobre tareas reales de distribución, obtiene soluciones de ruta y el costo promedio de transporte, y lo devuelve como evaluación de rendimiento comparable. La capa externa codifica las configuraciones de DE (como [estrategia de mutación DE/best/1, CR = 0.7, F = 0.5, NP = 60]) como individuos, usa el costo promedio de transporte como aptitud, ejecuta selección, recombinación y mutación, y genera la siguiente generación de configuraciones. Cuando el presupuesto de GPU es limitado, se puede usar evaluación por capas (primero un filtrado grueso con pocas tareas representativas, y reevaluar solo las configuraciones mejor posicionadas sobre el conjunto completo de tareas) y programación paralela por lotes (empaquetar en lotes las ejecuciones de la capa interna correspondientes a todos los individuos de la misma generación y enviarlas a la GPU) para reducir el costo de evaluación o mejorar la eficiencia de búsqueda;
también se puede reducir el tamaño de la población de la capa externa o usar modelos sustitutos para predecir el rendimiento, pero hay que sopesar entre diversidad de búsqueda y sesgo de estimación. Las razones giran en torno a "la aptitud de la capa externa depende de una ejecución completa de la capa interna" y "el paralelismo puede diluir el tiempo de espera de un individuo individual".
【Errores comunes】
No tomar la solución obtenida por la capa interna como el resultado final de MetaDE. El verdadero producto es una configuración de algoritmo transferible: al cambiar a nuevas instancias de la misma clase, la configuración sigue siendo válida, mientras que una solución individual a menudo ya ha caducado.
【Verificación de comprensión】
¿A cuántas ejecuciones completas de la capa interna equivale aproximadamente una evaluación de la capa externa? Si no se puede responder, significa que aún no se ha captado la estructura de costos de MetaDE y por qué el paralelismo es necesario. También se puede pedir a los estudiantes que resuman con sus propias palabras las responsabilidades de las capas interna y externa y el orden del bucle cerrado.
【Indicación de transición】
Después de confirmar que los estudiantes pueden expresar "la capa interna responde 'qué se calcula', la capa externa responde 'cómo calcular mejor', y ambas capas comparten la señal de aptitud del rendimiento en la tarea", pasar a la siguiente página con ejemplos, aplicaciones o resumen.
### Forma de trabajo AI Native y entrada conveniente
*Página 7*
> **Objetivo de la página:** Experimentar un flujo de trabajo AI nativo sin necesidad de memorizar comandos de instalación o interfaces complejas.
> **Objetivo de la página**
>
> Comprender la forma de trabajo AI Native y la entrada conveniente, desplazando el punto de partida del uso de EvoX de memorizar comandos de instalación e interfaces complejas hacia expresar la intención del experimento en lenguaje natural. Después del aprendizaje, se debe poder explicar el significado de "la conversación como entrada", y distinguir qué segmentos asumen respectivamente las herramientas de IA y el investigador.
> **Orden de explicación**
>
> Primero comparar el método tradicional con el método AI Native; luego explicar el flujo completo según "intención en lenguaje natural → comprensión y ejecución por IA → producción del experimento con EvoX"; finalmente usar el caso de navegación con evitación de obstáculos del robot de almacén para demostrar cómo describir un experimento a la IA con el trío "objetivo—restricciones—aceptación".
**Puntos clave de enseñanza**
- Explicar la tarea, las restricciones y los objetivos de aceptación en lenguaje natural; la IA se encarga de comprender el código y ejecutarlo. No es necesario dominar de antemano comandos de instalación, configuración de dependencias e invocaciones de interfaces complejas. La instalación del framework, la configuración de ejecución, la selección o generación de algoritmos pueden completarse con asistencia de IA. La conversación se convierte en la entrada conveniente que conecta la intención del investigador con la producción del experimento con EvoX. El investigador se concentra en el gusto por los problemas, las compensaciones multiobjetivo, la aceptación de soluciones y el juicio crítico. En el método tradicional, para iniciar un experimento con EvoX, primero hay que memorizar comandos, dependencias e interfaces
- La forma de trabajo AI Native eleva la entrada a la "expresión de intención". Describes sobre qué problema, bajo qué restricciones y con qué criterio de aceptación, y herramientas como Codex se encargan de traducir la intención en código ejecutable y operaciones de entorno, y devolver el estado de ejecución. Así, el punto de partida del experimento ya no es la memorización de comandos, sino una definición clara del problema. Navegación con evitación de obstáculos del robot de almacén. Se puede pedir en lenguaje natural que la IA invoque EvoX NSGA-II, realice optimización multiobjetivo en GPU y produzca rutas visualizadas. Aquí hay que distinguir tres tipos de información: la intención es "navegación con evitación de obstáculos para el robot de almacén, usando EvoX NSGA-II para optimización multiobjetivo en GPU"
- los objetivos son longitud de ruta mínima, distancia de seguridad máxima y consumo de energía mínimo
- la restricción es devolver resultados en 5 minutos
- el objetivo de aceptación es producir el frente de Pareto y rutas visualizadas, y conservar resultados de ejecución reproducibles. Las herramientas de IA se encargan de comprender el código, configurar el entorno y las dependencias, seleccionar o generar algoritmos, ejecutar en GPU y devolver el estado
- las responsabilidades humanas ascienden a la definición del problema, el establecimiento de criterios de evaluación, las compensaciones multiobjetivo, la aceptación de soluciones y el juicio crítico.
**Tratamiento de ejercicios**
Si se pregunta "¿cuál es el concepto central?", se debe captar "experimentar un flujo de trabajo AI nativo sin necesidad de memorizar comandos de instalación o interfaces complejas". Si se pide juzgar cuál afirmación es la más razonable, se debe elegir la opción que pueda conectar con los conceptos de esta página y dar evidencia o ejemplos; basarse solo en la intuición, cambiar todos los factores a la vez, o saltarse el material y memorizar respuestas no cumple los requisitos. Sobre "completar rápidamente la configuración del entorno y el diseño del algoritmo", también hay que poder explicarlo con evidencia o ejemplos, no solo memorizar conclusiones.
**Verificación de comprensión**
Pedir a los estudiantes que expliquen con sus propias palabras la relación "intención en lenguaje natural → comprensión y ejecución por IA → producción del experimento con EvoX", y que expliquen por qué el investigador aún debe revisar si se cumplen las restricciones, si el frente de Pareto es razonable y si las rutas son seguras y viables. Después de confirmar que los estudiantes pueden distinguir las responsabilidades de ejecución de la IA de las responsabilidades de juicio del humano, pasar al contenido práctico posterior.
### Práctica de tarea de navegación del robot de almacén
*Página 8*
> **Objetivo de la página:** Comprender cómo invocar rápidamente EvoX a través de la IA para resolver un problema concreto de navegación con evitación de obstáculos.
> **Orden de explicación**
>
> Los estantes, pasillos, obstáculos, punto de inicio y punto final ya están determinados, y se necesita encontrar una ruta sin colisiones y lo más corta posible.
>
> 2. Señalar que la longitud de la ruta y la seguridad de evitación de obstáculos normalmente no son consistentes, por lo que es un problema típico de optimización multiobjetivo, no una ruta más corta de objetivo único.
>
> 3. Explicar que la IA actúa como "traductor de tareas", transformando la descripción en lenguaje natural en una invocación ejecutable de EvoX, reduciendo la codificación manual y la configuración de parámetros.
>
> 4. EvoX NSGA-II completa en paralelo en GPU la evaluación de la población y la búsqueda, retiene múltiples soluciones de compromiso y forma una familia de rutas que va de "corta pero arriesgada" a "larga pero segura".
>
> Visualizar el mapa de rutas candidatas y la curva de tendencia de convergencia, para observar la viabilidad y el progreso de la búsqueda.
**Puntos clave de enseñanza**
- Diseño fijo del almacén, entorno de obstáculos, punto de inicio y punto final del robot. Puntos clave de la ruta, puntos de control de curva, radio de giro, perfil de velocidad, etc. Minimizar la longitud de la ruta
- Minimizar el riesgo de colisión o maximizar la viabilidad sin colisiones. La ruta debe permanecer dentro del pasillo, no puede atravesar estantes u obstáculos, y debe cumplir las restricciones cinemáticas del robot. Transformar automáticamente la descripción en lenguaje natural en una invocación ejecutable de EvoX, reduciendo el costo de configuración
- No reemplaza al algoritmo de optimización mismo. Evaluar en paralelo una gran cantidad de rutas candidatas, acelerando la iteración de NSGA-II
- No cambia el hecho de que el multiobjetivo tiene soluciones de compromiso. Visualizar el mapa de rutas para observar la viabilidad de las rutas, la diversidad y la ruta recomendada sin colisiones
- La curva de tendencia de convergencia para juzgar si se ha entrado en una meseta. Primero definir objetivos y restricciones, luego ajustar parámetros
- La viabilidad tiene prioridad sobre la longitud de la ruta
- Usar la tendencia de convergencia para decidir si continuar iterando o detenerse.
**Tratamiento de ejercicios**
Elementos de entrada de la tarea -> diseño fijo del almacén, entorno de obstáculos, punto de inicio y punto final. Retroalimentación: la entrada de la tarea define el entorno, las restricciones y las condiciones de inicio y fin.
Dos objetivos que maneja NSGA-II -> longitud de ruta y seguridad de evitación de obstáculos. Retroalimentación: una ruta más corta puede acercarse más a los obstáculos, y el requisito de seguridad puede alargar la ruta.
Valor principal de la IA -> transformar automáticamente la descripción de la tarea en una invocación ejecutable de EvoX. Retroalimentación: la IA es la capa de traducción de tareas y generación de invocaciones, que reduce el costo de configuración.
Ventaja de la GPU -> evaluar en paralelo una gran cantidad de rutas candidatas, acelerando la iteración de NSGA-II. Retroalimentación: la GPU acelera la evaluación y la búsqueda, no cambia la esencia del compromiso multiobjetivo.
Mapa de rutas visualizado y tendencia de convergencia -> observar respectivamente la viabilidad de las rutas, la diversidad y la ruta recomendada sin colisiones; si el proceso de optimización converge. Retroalimentación: el mapa de rutas muestra la calidad espacial de las soluciones, la tendencia de convergencia muestra el progreso de la búsqueda en la dimensión temporal.
Definir variables de decisión, dos objetivos de optimización y condiciones de restricción; explicar la división del trabajo entre IA, EvoX NSGA-II y GPU, y explicar cómo la tendencia de convergencia auxilia la decisión. Puntos clave de la respuesta: la IA analiza la descripción de la tarea como una invocación de EvoX; NSGA-II evalúa en paralelo en GPU, y la clasificación no dominada y el hacinamiento mantienen soluciones de compromiso; se producen rutas visualizadas y curvas de convergencia; si la curva se estabiliza, el beneficio es limitado, y si aún desciende, se pueden aumentar las iteraciones o el tamaño de población.
**Verificación de comprensión**
Pedir aleatoriamente a un estudiante que resuma con sus propias palabras los puntos clave de esta página, y el instructor complementa las palabras clave omitidas según la respuesta.
> **Indicación de transición**
>
> Después de confirmar que los estudiantes pueden expresar la relación central de esta página, pasar a la siguiente página con ejemplos, aplicaciones o resumen.
### Resultados experimentales y análisis de visualización
*Página 9*
> **Objetivo de la página:** Aprender a interpretar la tendencia de convergencia durante el proceso de optimización y los datos completos de resultados.
> **Objetivo de la página**
>
> Aprender a interpretar la tendencia de convergencia durante el proceso de optimización y los datos completos de resultados, comprendiendo que "la tendencia del proceso + el resultado final" deben corroborarse mutuamente, y no se puede concluir basándose solo en el mejor resultado de una única ejecución.
> **Orden de explicación**
>
> 1. Primero leer la curva de convergencia, para juzgar si el proceso de búsqueda avanza.
>
> 2. Luego observar la ruta final y la tabla de métricas bajo el diseño fijo del almacén, para juzgar si la solución es utilizable.
>
> 3. Usar datos experimentales completos para sustentar conclusiones reproducibles.
>
> 4. Mediante ejercicios y casos, manejar errores de juicio comunes.
**Puntos clave de enseñanza**
- Dos tipos de evidencia son indispensables. La curva responde "¿se está moviendo la búsqueda?", la ruta y las métricas responden "¿se puede usar el resultado?". Solo cuando la tendencia de convergencia indica que la búsqueda avanza, y la visualización de rutas y la tabla de métricas indican que la solución es utilizable, y ambas condiciones se cumplen simultáneamente, se puede concluir. Si falta cualquiera de las dos mitades, es solo una conjetura. Mejora continua, descenso estable en las fases inicial e intermedia o ascenso estable del indicador compuesto
- Oscilación, fluctuación hacia arriba y hacia abajo sin tendencia a largo plazo, puede provenir de ruido de evaluación, conflicto de restricciones o diversidad excesiva
- Estancamiento, un intervalo casi horizontal pero que aún puede mejorar después
- Convergencia prematura, se aplana completamente muy pronto y no se recupera, generalmente por pérdida de diversidad de la población o compresión prematura del espacio de soluciones. Cuando la curva muestra "¿estancamiento tardío/prematuro?" en la fase final, se debe distinguir combinando con los registros, y no escribir directamente "ha convergido". La comparación de rutas bajo el diseño fijo del almacén debe superponer la ruta óptima y las rutas de comparación sobre el mismo mapa fijo del almacén, verificar si la ruta es realmente alcanzable, si la evitación de obstáculos es razonable, y si el último tramo cerca del punto final es estable. El diseño fijo es una restricción clave, que permite atribuir las diferencias de ruta entre distintas ejecuciones o distintos parámetros a la optimización misma, y no a cambios en el mapa. La tabla de métricas puede dar una comparación intuitiva: longitud de ruta 128.4 frente a 156.9, número total de giros 6 frente a 9, costo compuesto 1.00 frente a 1.21, reflejando la ventaja de la ruta óptima en múltiples métricas. Configuración de ejecución y semilla aleatoria, registro de iteraciones, valores numéricos de cada objetivo por generación, ruta final y resultados de evaluación. Si la curva deja de mejorar notablemente en la fase final, se debe juzgar con el registro completo si es convergencia prematura, saturación de evaluación, o si ya se acerca a una solución utilizable
- Si es necesario, re-ejecutar o hacer verificación cruzada. Una curva que se aplana suavemente y temprano no equivale automáticamente a haber encontrado la solución óptima, ni automáticamente a que el algoritmo haya fallado
- Una ruta que parece bonita tampoco equivale a una búsqueda estable. El mejor resultado de una única ejecución puede ser una mejora real, o el producto de fluctuaciones aleatorias o saturación de evaluación; la tendencia del proceso y el resultado final deben corroborarse mutuamente.
**Cobertura de palabras clave**
- Tendencia de convergencia, verificación de rutas, diseño fijo del almacén, reproducibilidad, convergencia prematura, saturación de evaluación, métrica de hipervolumen, longitud de ruta, número total de giros, costo compuesto.
> **Pistas de ejercicios**
>
> - Cinco preguntas de opción múltiple giran en torno a los juicios centrales de esta página. La pregunta 1 pregunta sobre la relación entre la curva de convergencia y la visualización de la ruta final, y la dirección correcta es "la curva refleja si el proceso de búsqueda avanza, la ruta y la tabla de métricas reflejan si la solución final es utilizable, y ambas deben juzgarse en conjunto". La pregunta 2 pregunta cómo proceder cuando el valor objetivo se mantiene horizontal durante mucho tiempo después de la generación 200, y la dirección correcta es "juzgar con el registro completo si es convergencia prematura, saturación de evaluación, o si ya se acerca a una solución utilizable, y si es necesario ajustar la estrategia y re-ejecutar". La pregunta 3 pregunta qué se debe guardar y verificar para una conclusión reproducible, y la dirección correcta es "configuración de ejecución, semilla aleatoria, registro de iteraciones, valores de cada objetivo, ruta final y resultados de evaluación". La pregunta 4 pregunta el propósito del diseño fijo del almacén, y la dirección correcta es "permitir que las diferencias de ruta entre distintas ejecuciones o distintos algoritmos se atribuyan a la optimización misma, y no a cambios en el entorno". La pregunta 5 pregunta la interpretación rigurosa de "muy suave y que deja de cambiar muy temprano", y la dirección correcta es "verificar si hay saturación de evaluación o pérdida prematura de diversidad de la población, y validar mediante re-ejecución y verificación cruzada de métricas". Retroalimentación de respuestas: cuando es correcta, explicar que el juicio puede conectar con los conceptos de esta página y dar la base
> - cuando es incorrecta, volver a la explicación de esta página, encontrar la evidencia clave o el ejemplo y luego juzgar. En "reproducción de navegación multiobjetivo bajo diseño fijo del almacén", si después de la generación 180 la curva se aplana y se obtiene una buena ruta candidata, se deben recopilar y verificar la configuración de ejecución y la semilla aleatoria, el registro de iteraciones, los valores de cada objetivo por generación, la ruta final y los resultados de evaluación bajo el diseño fijo, la tabla de métricas clave, y se recomienda re-ejecutar o hacer verificación cruzada. No se puede usar solo el mejor resultado de una única ejecución, porque el óptimo puntual puede provenir de fluctuaciones aleatorias o saturación de evaluación, no puede explicar si la búsqueda realmente avanza, ni puede ser reproducido por otros. Si tras re-ejecutar la forma de la curva es similar pero la ruta final es diferente, se deben comparar las distribuciones de métricas en lugar de los valores puntuales, verificar si la semilla y la configuración son consistentes, revisar la convergencia prematura o la saturación de evaluación, y si es necesario aumentar las generaciones de iteración, ajustar la estrategia de mantenimiento de diversidad o corregir la función de evaluación, y presentar en el informe rutas típicas y resúmenes estadísticos.
**Verificación de comprensión**
Pedir aleatoriamente a un estudiante que resuma con sus propias palabras la relación de "la curva mira la tendencia, la ruta mira la implementación" y "la tendencia del proceso y el resultado final son indispensables", y el profesor complementa las palabras clave omitidas según la respuesta. Se puede pedir a los estudiantes que den un ejemplo cercano a su experiencia para explicar por qué mirar solo la curva o solo la ruta puede llevar a un juicio erróneo.
> **Indicación de transición**
>
> Después de confirmar que los estudiantes pueden expresar que la curva de convergencia y la visualización de rutas deben juzgarse en conjunto, pasar a la siguiente página con ejemplos, aplicaciones o resumen.
### Cuanto más fácil es usar la herramienta, más clara es la responsabilidad humana
*Página 10*
> **Objetivo de la página:** Reconocer el cambio en el rol y la responsabilidad del investigador humano tras la popularización de las herramientas de automatización.
> **Objetivo de la página**
>
> Comprender que tras la popularización de las herramientas de automatización, la responsabilidad del investigador no se aligera, sino que asciende de la "implementación" a la "definición y arbitraje". Esta página debe hacer que los estudiantes recuerden una frase: cuanto más fácil es usar la herramienta, más clara es la responsabilidad humana.
**Puntos clave de enseñanza**
- La IA y EvoX reducen mucho el costo de ejecución de "idea→código→experimento"; generar rápidamente implementaciones candidatas, ajustar parámetros por lotes y dibujar curvas se ha vuelto fácil. Pero la disminución del costo de ejecución no equivale a la desaparición del costo de juicio. El modelo no puede responder por el investigador tres preguntas previas: ¿vale la pena investigar este problema? ¿Son precisos los objetivos? ¿Es justa la comparación? Que funcione, que compile, que pase las pruebas, que las métricas mejoren, son solo señales candidatas, no equivalen a que la conclusión científica sea válida. A la izquierda está la capa de ejecución de IA/herramientas, encargada de generar código candidato, experimentos por lotes y ajuste de parámetros, dibujo y visualización automáticos, y hacer que las implementaciones de bajo valor se eliminen rápidamente
- a la derecha está la capa de responsabilidad humana, encargada de formular preguntas clave, definir objetivos y criterios de evaluación, garantizar comparaciones justas, verificar si las conclusiones son válidas, y el juicio de valor y el gusto. En el medio está la puerta de "juicio no externalizable", los criterios de aceptación no son negociables, y las modificaciones candidatas deben pasar por el arbitraje humano. La puerta de aceptación de Genesis es precisamente la ingenierización de este límite: las modificaciones candidatas deben pasar compilación, pruebas, verificación de comportamiento y aceptación de nivel superior para entrar en la historia del proyecto. En los experimentos multiobjetivo con EvoX, el Agente puede generar rápidamente soluciones candidatas, ajustar parámetros y dibujar, pero el investigador aún debe revisar: ¿la función objetivo representa la necesidad real? ¿La diversidad de candidatos está siendo ocultada por las métricas? ¿Los modos de fallo están siendo mostrados selectivamente? En este momento, el valor de la herramienta es hacer que las implementaciones de bajo valor se eliminen más rápido, y que el juicio de alto valor se convierta antes en el cuello de botella. La indicación de Turing también apunta a esto: hay muchas cosas por hacer adelante, Code is cheap. Taste matters. La capacidad central es formular preguntas clave y controlar las conclusiones de manera reproducible
- el gusto del investigador determina en qué valor científico se transforma finalmente la conveniencia técnica.
**Cobertura de palabras clave**
- Costo de ejecución, costo de juicio, juicio no externalizable, validez científica, puerta de aceptación, señales candidatas, comparación justa, juicio de valor y gusto. Base documental: esta página gira en torno a "elevación de la responsabilidad: de la implementación a la definición y el arbitraje" y "la validez del resultado tiene prioridad sobre el éxito de la ejecución". Pistas de material: se puede usar un diagrama de comparación izquierda-derecha para destacar la división entre la capa de ejecución de IA/herramientas y la capa de responsabilidad humana, enfatizando en el centro el "juicio no externalizable".
**Tratamiento de ejercicios**
La pregunta 1 debe elegir "pasar compilación, pruebas, verificación de comportamiento y aceptación de nivel superior"; el punto de retroalimentación es: por muy rápidos y bonitos que sean los gráficos, solo son señales candidatas, lo clave es la puerta de aceptación. La pregunta 2 debe elegir "la selección del problema, la definición de objetivos y los criterios de evaluación aún deben ser asumidos por humanos"; el punto de retroalimentación es: las herramientas aceleran la ejecución, no cancelan el juicio. La pregunta 3 debe elegir "si vale la pena investigar el problema, si los objetivos son precisos, si la comparación es justa"; el punto de retroalimentación es: estas tres son condiciones previas de la validez científica. La pregunta 4 debe priorizar la revisión de "si la función objetivo representa la necesidad real, si la diversidad de candidatos está siendo ocultada por las métricas, si los modos de fallo están siendo mostrados selectivamente"; el punto de retroalimentación es: que las métricas mejoren no equivale a que la conclusión sea válida.
La pregunta 5 debe elegir "tras la reducción del costo de implementación, el gusto y el juicio del investigador determinan en qué valor científico se transforma la conveniencia técnica"; el punto de retroalimentación es: Code is cheap se refiere a la reducción del costo de implementación, Taste matters se refiere a que el juicio y el gusto son más importantes.
En el proyecto multi-Agente Genesis, el Agente puede proponer parches candidatos, ejecutar pruebas y resumir métricas, pero aprobar su entrada en la historia del proyecto, establecer criterios de aceptación y explicar conclusiones debe ser responsabilidad humana. Los juicios no externalizables incluyen: si mejorar la estabilidad es una necesidad real, cómo se define la estabilidad, si la línea base representa escenarios reales, y si las líneas base, variables y modos de fallo se tratan de manera consistente. Si se usa solo "mejora de métricas de referencia" como criterio de aceptación, el riesgo puede provenir de sesgo en la función objetivo, sobreajuste a la referencia, exhibición selectiva de casos exitosos, ocultamiento de modos de fallo o comparaciones injustas.
La dirección de mejora es añadir a la puerta de aceptación la reproducción de líneas base, el control de variables, experimentos de ablación, informes de modos de fallo, compensaciones multiobjetivo y verificación de límites de extrapolación, y exigir que el humano confirme si la función objetivo representa la necesidad real y si la comparación es justa.
Primero preguntar si vale la pena, luego cómo implementarlo; tratar los criterios de aceptación como responsabilidad propia; el gusto determina el destino de la conveniencia técnica. Verificación de comprensión: pedir a los estudiantes que digan en una frase cuál es el juicio no externalizable más importante de esta página, y que expliquen cómo verificarlo. Indicación de transición: después de confirmar que los estudiantes pueden distinguir "señales candidatas" de "conclusiones científicas" y expresar el límite entre la capa de ejecución y la capa de responsabilidad, pasar a la siguiente página con aplicaciones o resumen.
### Núcleo de la investigación: la capacidad de formular preguntas clave
*Página 11*
> **Objetivo de la página:** Dominar la capacidad central de formular preguntas, más importante que escribir código en la era de la programación automatizada.
> **Objetivo de la página**
>
> Esta página debe hacer que los estudiantes comprendan que en la investigación AI Native, la programación automatizada y los grandes modelos ya han reducido mucho el costo de "implementar respuestas", por lo que el centro de gravedad de la investigación asciende de "¿se puede hacer?" a "¿vale la pena hacerlo y hacia dónde hacerlo?". La capacidad central del investigador es formular preguntas clave y defender la dirección, los criterios de compromiso y el significado científico.
**Puntos clave de enseñanza**
- 1. El cambio en la estructura de costos es el punto de partida lógico de esta página. La generación de código, la búsqueda de soluciones y la ejecución de experimentos pueden delegarse a la IA
- cuando las respuestas se vuelven baratas, lo escaso se convierte en "formular las preguntas correctas". La IA se encarga de expandir el espacio de respuestas y las rutas de ejecución, el humano de la definición del problema y el control de la dirección, y la responsabilidad asciende en consecuencia. 2. Usando el mapa mental de la página, descomponer la capacidad de formular preguntas clave en seis tipos de elementos y explicarlos uno por uno: objetivos y conflictos — ¿cuál es la cantidad que realmente se quiere mejorar, cómo se compensan los múltiples objetivos y cuál tiene prioridad?
- restricciones y límites — ¿qué condiciones no son negociables y qué tan grande es el espacio de soluciones?
- evaluación y verificación — ¿son observables las métricas, cuál es el protocolo de verificación y el presupuesto de evaluación?
- candidatos/espacio de soluciones — ¿qué tipo de diversidad y robustez se necesita?
- criterios de fallo — ¿qué resultados deben juzgarse como fallo?
- división humano-máquina y gusto — la IA expande las respuestas, el humano controla la dirección. Se puede sugerir a los estudiantes que recuerden estos seis tipos como una lista de autoverificación. 3. La esencia de las preguntas clave no es indagar en detalles de implementación, sino transformar la intuición vaga en una estructura de investigación verificable, evolucionable y divisible. La calidad de las preguntas determina la calidad del espacio de soluciones: cuanto más clara es la definición del problema, más probable es que la búsqueda y la evolución caigan en regiones significativas, y más probable es que los productos sean explicables y reutilizables
- cuanto más vaga es la definición, el modelo solo puede tantear aleatoriamente en un espacio demasiado grande, y los resultados a menudo parecen viables pero no pueden sedimentarse. 4. División humano-máquina y el gusto central del investigador. La IA expande el espacio de respuestas y las rutas de ejecución, el humano controla la dirección, los criterios de compromiso y el significado científico. Tomando como ejemplo prácticas de evolución continua a nivel de sistema como Genesis: las modificaciones candidatas deben pasar compilación, pruebas y aceptación de nivel superior para entrar en la versión aceptada del proyecto, convirtiéndose en la base histórica del trabajo posterior
- si en la etapa de formulación de preguntas no se definen claramente el protocolo de evaluación y los criterios de fallo, la puerta de aceptación no tendrá base para juzgar, y los productos de la IA solo podrán quedarse como productos de código desechables, sin poder acumularse a través de contextos y ciclos de tareas. El gusto central son tres juicios: qué vale la pena preguntar, qué evidencia es aceptable, qué solución aunque viable no vale la pena hacer. Reescribirlo como "¿cuál es el conflicto real? ¿Cómo cuantificar objetivos y restricciones? ¿Cuál es el presupuesto de evaluación y los criterios de verificación? ¿Qué diversidad y robustez se necesitan? ¿Qué resultados deben juzgarse como fallo?" Así la IA puede implementar respuestas eficientemente, y el humano tiene base para aceptar. Las cinco preguntas de opción múltiple corresponden respectivamente a los cinco juicios de esta página — por qué asciende el núcleo de la investigación, la esencia de las preguntas clave, los elementos que debe aclarar una pregunta clave, la relación entre la calidad de las preguntas y el espacio de soluciones, y los tres juicios del gusto central. Al tratarlas no es necesario leerlas una por una; se puede pedir primero a los estudiantes que respondan, y luego corregir con retroalimentaciones como "lo que se reduce es el costo de implementación, no el costo de juicio" y "vago no significa libre". La pregunta de caso requiere que los estudiantes reescriban "hacer optimización con EvoX" como una tarjeta de problema que cubra objetivos y conflictos, restricciones y límites, evaluación y verificación, y criterios de fallo, y que expliquen cómo la calidad de las preguntas determina si el experimento puede sedimentarse como un producto de proyecto sosteniblemente evolutivo. Puntos de referencia: Genesis trata el código enviado como modificación candidata, y solo entra en la versión aceptada tras pasar compilación, pruebas y aceptación de nivel superior
- sin métricas observables, protocolo de verificación y criterios de fallo, la aceptación no tiene base
- la IA se encarga de generar candidatos, buscar y ejecutar pruebas, el humano de delimitar objetivos, restricciones duras, presupuesto de evaluación y criterios de fallo, y tomar la decisión de aceptación. Pedir aleatoriamente a un estudiante que repita con sus propias palabras las seis autoverificaciones, y que dé una demanda vaga de su propia investigación, intentando reescribirla en el momento. Después de confirmar que los estudiantes pueden expresar las dos relaciones de "que funcione no significa que valga la pena invertir" y "la calidad de las preguntas determina la calidad del espacio de soluciones", pasar a la siguiente página.
### División humano-máquina: la IA implementa respuestas, el humano controla la dirección
*Página 12*
> **Objetivo de la página:** Aclarar la relación de división y colaboración entre la IA y el investigador en el proceso de exploración científica.
**Puntos clave de enseñanza**
- Antes de cada experimento, preguntarse tres cosas: ¿quién eligió este problema? ¿Quién definió los criterios de evaluación? ¿Quién acepta las conclusiones? Si las tres respuestas apuntan a "yo", la división es saludable; si todas apuntan al modelo, el control de la dirección ya se ha perdido.
- Una vez que los criterios de evaluación pueden ser reescritos por flujos automatizados, la optimización se desvía silenciosamente hacia "la métrica más fácil de mejorar". Establecer la función objetivo y las restricciones como solo lectura es la primera puerta para prevenir la deriva.
- La IA expande el ancho de banda, el humano defiende el significado — lo que se entrega no son más números, sino conclusiones sostenibles.
### Objetivo de la página
Aclarar la relación de división y colaboración entre la IA y el investigador, definir el límite entre la capa de ejecución de la IA y la capa de control humana, y comprender por qué "la IA expande el ancho de banda de exploración, el humano defiende el significado científico".
### Orden de explicación
Delegar la implementación y la exploración a la IA, reservar la dirección y el juicio al investigador.
Bucle cerrado de colaboración humano-máquina. La capa de ejecución de la IA incluye implementación de respuestas, ejecución por lotes de experimentos, búsqueda de soluciones candidatas y retroalimentación de resultados; la capa de control humana incluye definición del problema, selección de dirección, juicio de evidencia y aceptación del significado científico. Ambos lados se acoplan mediante "resultados hacia arriba, estándares hacia abajo": la IA empuja respuestas candidatas y retroalimentación experimental al investigador, y el investigador devuelve a la IA objetivos, restricciones y criterios de aceptación.
Implementar respuestas rápidamente, ejecutar experimentos por lotes, buscar soluciones candidatas y retroalimentar. Una vez que el problema y los criterios de evaluación están claros, la IA puede dar en muy poco tiempo soluciones ejecutables y verificables, haciendo que el ensayo y error pase de recurso escaso a operación rutinaria.
Formular preguntas clave, establecer objetivos, restricciones y criterios de evaluación, juzgar si la evidencia es confiable, y completar la aceptación del significado científico. Se debe poder distinguir "resultados que funcionan" de "resultados confiables", e identificar sobreajuste, fuga de datos y falsificación de métricas.
Si falta cualquiera de los dos lados, el sistema falla. Solo con IA, se obtendrán grandes cantidades de resultados sin sentido; solo con humanos, el ancho de banda de exploración es limitado. Tomando como ejemplo la exploración evolutiva multiobjetivo, la IA puede generar y ejecutar automáticamente una gran cantidad de soluciones candidatas, y el investigador decide si los objetivos de optimización, las restricciones y las métricas de evaluación reflejan el problema real, y filtra las direcciones científicamente confiables que vale la pena seguir explorando.
Delegar también los criterios de evaluación a la IA para que los decida automáticamente. Así el sistema optimizará eficientemente un objetivo que no refleja el problema científico real, produciendo grandes cantidades de resultados "aparentemente razonables" pero sin sentido. Toda decisión que cambie "qué se considera bueno" debe permanecer del lado humano.
¿Quién eligió este problema? ¿Quién definió los criterios de evaluación? ¿Quién acepta las conclusiones? Si las tres respuestas apuntan a "yo", la división es saludable; si todas apuntan al modelo, el control de la dirección ya se ha perdido.
La IA expande el ancho de banda, el humano defiende el significado — lo que se entrega no son más números, sino conclusiones sostenibles.
### Puntos clave de enseñanza
Implementación de respuestas, ejecución por lotes de experimentos, búsqueda de soluciones candidatas, retroalimentación de resultados; el núcleo es reducir el costo de implementación a casi cero.
Definición del problema, selección de dirección, juicio de evidencia, aceptación del significado científico; el núcleo es mantener el costo de juicio en manos propias.
La IA expande el ancho de banda de exploración, el humano controla la dirección y los criterios de aceptación.
Una vez que los criterios de evaluación pueden ser reescritos por flujos automatizados, la optimización se desvía silenciosamente hacia "la métrica más fácil de mejorar". Establecer la función objetivo y las restricciones como solo lectura es la primera puerta para prevenir la deriva.
No se trata de producir más resultados numéricos, sino de que los resultados tengan verdadero significado científico; solo entonces la cantidad tiene valor.
### Cobertura de palabras clave
Capa de ejecución de IA, capa de control humana, bucle cerrado de colaboración humano-máquina, ancho de banda de exploración, deriva de criterios de evaluación, función objetivo de solo lectura, aceptación del significado científico, tres preguntas de autoverificación.
### Tratamiento de ejercicios
La respuesta correcta es "implementar respuestas rápidamente, ejecutar experimentos por lotes y buscar soluciones candidatas". La IA asume la implementación y la exploración; decidir el valor del problema, juzgar la confiabilidad de la evidencia y aceptar el significado científico pertenecen a la capa de control humana.
La respuesta correcta es "porque solo cuando los resultados tienen verdadero significado científico, la cantidad tiene valor". La cantidad proviene del ancho de banda de exploración de la IA, el valor proviene del juicio humano sobre el significado científico.
La respuesta correcta es "si los objetivos de optimización, las restricciones y las métricas de evaluación reflejan el problema real". La generación de candidatos y la ejecución por lotes pertenecen a la capa de ejecución de la IA; el investigador debe controlar la capa de "qué se considera bueno".
La respuesta correcta es "permitir que el investigador concentre su atención en el juicio de dirección y los criterios de aceptación". La IA expande la amplitud, el humano aporta la dirección; ambos son complementarios, no sustitutos.
La respuesta correcta es "el sistema optimizará eficientemente un objetivo que no refleja el problema científico real, produciendo grandes cantidades de resultados aparentemente razonables pero sin sentido". Delegar los criterios de evaluación al sistema equivale a dejar que el evaluado defina su propio examen; toda decisión que cambie los criterios de evaluación debe conservar la revisión humana.
### Tratamiento del caso
1. La capa de ejecución de la IA incluye la generación de formulaciones candidatas, la ejecución de simulaciones por lotes, la recuperación de métricas de rendimiento y la actualización de la población; esto pertenece a la implementación y la exploración. La capa de control humana incluye el sistema de materiales a buscar, los objetivos de rendimiento y las restricciones de proceso, si las métricas reflejan el significado físico real, y si los candidatos finales vale la pena seguir invirtiendo en experimentos; esto pertenece a la dirección y el juicio. La base de la división es: toda decisión que cambie "qué se considera bueno" debe permanecer del lado humano; todo trabajo que ejecute estándares ya definidos a mayor escala puede delegarse a la IA.
2. Si se deja que la IA ajuste automáticamente los pesos de las métricas de rendimiento mediante meta-optimización, el riesgo principal es la deriva de los criterios de evaluación: una vez que el sistema optimizado también controla el poder de evaluarse a sí mismo, se inclinará hacia "la métrica más fácil de mejorar", y las formulaciones de alta puntuación producidas pueden ser físicamente irrealizables o sin valor práctico, y además suelen parecer muy razonables a simple vista, difíciles de identificar de inmediato. El diseño de protección incluye: declarar la función objetivo y las restricciones como controladas y de solo lectura; la meta-optimización solo permite ajustar una pequeña cantidad de hiperparámetros dentro de límites especificados por humanos y con cotas superior e inferior; establecer una puerta de aceptación independiente del objetivo de optimización, como experimentos reales de síntesis y caracterización; todo cambio de pesos debe ser revisado explícitamente por el investigador y dejar registro, garantizando que las decisiones de dirección sean rastreables.
### Actividad en clase
Pedir a los estudiantes que usen un ejemplo cercano a su experiencia de aprendizaje o investigación para repetir la división de "la IA implementa respuestas, el humano controla la dirección", y que expliquen la relación entre este ejemplo y las tres preguntas de autoverificación.
### Verificación de comprensión
Capa de ejecución de IA, capa de control humana, bucle cerrado de colaboración humano-máquina, deriva de métricas, tres preguntas de autoverificación. Complementar las palabras clave omitidas según la respuesta.
### Indicación de transición
Después de confirmar que los estudiantes pueden expresar la relación central de "la IA expande el ancho de banda de exploración, el humano controla la dirección y los criterios de aceptación", pasar a la siguiente página con ejemplos, aplicaciones o resumen.
### Principio central: Code is cheap. Taste matters
*Página 13*
> **Objetivo de la página:** Experimentar la filosofía de Turing y el objetivo final de EvoX de construir infraestructura abierta.
> **Objetivo de la página**
>
> Comprender el principio central "Code is cheap. Taste matters", y experimentar la filosofía de Turing y el objetivo final de EvoX de construir infraestructura abierta.
**Puntos clave de enseñanza**
- 1. Code is cheap es una descripción objetiva del estado actual de la ingeniería. Cuando el costo marginal de la generación e implementación de código se reduce casi a cero por los grandes modelos y las bases tensorizadas, el código ya no es una barrera, ni una unidad de medida de la contribución científica. "Que funcione" degenera de resultado a premisa, de logro exhibible a boleto de entrada para seguir trabajando. 2. Taste matters es una reubicación de la responsabilidad humana tras la división humano-máquina. Cuando "la IA implementa respuestas, el humano controla la dirección" se convierte en la división predeterminada, lo verdaderamente escaso del lado humano es la capacidad de formular preguntas clave, establecer criterios de evaluación y juzgar la dirección en medio de conflictos multiobjetivo. 3. Esta capacidad se manifiesta en cuatro niveles: selección del problema — qué problema hacer determina el techo más que con qué método hacerlo; cuando la dirección es errónea, cuanto más rápida la implementación, más desperdicio
- diseño de la función objetivo y los criterios de evaluación — una vez que las métricas se eligen mal, el modelo solo convergerá eficientemente en la dirección equivocada
- criterios de compromiso multiobjetivo — las preferencias entre rendimiento, reproducibilidad, mantenibilidad y costo de implementación deben declararse explícitamente, no decidirse improvisadamente
- interpretación y atribución de resultados — distinguir "funcionó por casualidad" de "realmente se entiende", y juzgar de qué cambios provienen realmente los beneficios. 4. El gusto debe ser verificable. El gusto no es una afirmación estética, ni puede resolverse por antigüedad o votación. Debe ser falsable mediante "entrar en el entorno real — recibir retroalimentación real": escribir el juicio como hipótesis verificable, y revisarlo con los fracasos y éxitos en escenarios reales. De lo contrario, la discusión se reduce a una disputa de preferencias. 5. El significado de la infraestructura es dar un punto de apoyo al gusto. El objetivo final de EvoX es precisamente construir infraestructura abierta capaz de entrar en entornos reales y recibir retroalimentación real. Una base abierta, desacoplada y combinable reduce el costo de implementación lo suficiente como para que las buenas ideas entren a bajo costo en escenarios reales, sean filtradas, sedimentadas y heredadas — y el juicio tenga así un vehículo que puede pulirse repetidamente. Code cheap no significa que la ingeniería pueda omitirse. La puerta de aceptación, la reproducibilidad, la mantenibilidad y el bucle cerrado de retroalimentación siguen constituyendo umbrales reales. El gusto se manifiesta precisamente en el juicio de compromiso sobre estos umbrales: qué retroalimentación merece ser creída, qué métricas deben mantenerse firmes, qué intentos fallidos deben rechazarse en lugar de fusionarse. El valor de mecanismos al estilo Genesis también está aquí — las modificaciones candidatas solo pueden convertirse en base histórica heredable por ejecutores posteriores tras pasar compilación, pruebas, verificación de comportamiento y aceptación de nivel superior. Solo podemos ver una distancia muy corta hacia adelante, pero podemos ver que allí hay una gran cantidad de cosas por hacer. En lugar de discutir la forma concreta del fin de la inteligencia, es mejor construir primero infraestructura abierta capaz de entrar continuamente en escenarios reales y recibir retroalimentación real, para que cada ronda de exploración pueda ser verificada y heredada. La página usa un gráfico de tendencia para mostrar la disminución continua del costo de implementación y el aumento continuo del valor del juicio, cuyo cruce forma un punto de inflexión, que significa que el juicio se convierte en la variable clave. Debajo del gráfico se enumeran las palabras clave de la visión de EvoX: abierto, combinable, retroalimentación real, evolución continua.
**Tratamiento de ejercicios**
Esta página incluye cinco preguntas de opción múltiple, que verifican respectivamente la comprensión del significado ingenieril de Code is cheap, la dirección del desplazamiento de la escasez, la falsabilidad del gusto, los cuatro umbrales de ingeniería y el propósito de la infraestructura de EvoX. Después de responder, comparar con la retroalimentación, distinguiendo especialmente entre "métricas del lado de la implementación" y "capacidades del lado del juicio": el número de líneas de código, la precisión de autocompletado, la popularidad del framework y la frecuencia de commits no pueden sustituir el juicio sobre "qué debe ser aceptado". La pregunta de caso requiere que el equipo enumere los eslabones en los que debe invertir prioritariamente y diseñe un proceso de aceptación de modificaciones candidatas que verifique el gusto;
las direcciones de referencia incluyen selección del problema y definición de objetivos, diseño de la función objetivo y los criterios de evaluación, puerta de aceptación y criterios de compromiso multiobjetivo, interpretación y atribución de resultados, y el bucle cerrado de "modificación candidata—prueba aislada—puntuación de evaluación—aceptación de nivel superior—herencia histórica—retroalimentación".
**Verificación de comprensión**
Pedir aleatoriamente a un estudiante que resuma con sus propias palabras los puntos clave de esta página, y el instructor complementa las palabras clave omitidas según la respuesta, como "que funcione es solo el boleto de entrada", "el gusto debe ser falsable", "los cuatro umbrales de ingeniería".
> **Indicación de transición**
>
> Esta página continúa la división de "la IA implementa respuestas, el humano controla la dirección" de la página anterior, y presenta el principio central que sustenta esta división; la siguiente página pasa a la práctica de guiar a la IA mediante diálogo para completar tareas de EvoX.
### Actividad en clase: guiar a la IA mediante diálogo para completar tareas de EvoX
*Página 14*
> **Objetivo de la página:** Verificar mediante práctica manual el flujo básico de tareas de optimización en un entorno AI Native.
**Actividad en clase**
Guiar a la IA mediante diálogo para completar tareas de EvoX
> **Objetivo de la página**
>
> Completar el bucle cerrado mínimo de "indicación → generación → ejecución → aceptación" en un entorno real de EvoX. Lo importante no es solo obtener un fragmento de código legible, sino verificar la forma de trabajo AI Native: el humano da la dirección, la IA da la implementación, el humano hace la aceptación.
> **Orden de explicación**
>
> Primero explicar la tarea de la actividad, luego desglosar cómo construir la indicación, después explicar cómo aceptar los resultados de ejecución, y finalmente manejar resultados no ideales añadiendo restricciones, volviendo a la división humano-máquina.
**Puntos clave de enseñanza**
- Usar una indicación conversacional para impulsar a la IA a generar y ejecutar una tarea básica de optimización con EvoX, y luego revisar la salida como un ingeniero. Problema de optimización y función objetivo (por ejemplo, minimización de la función Rastrigin), espacio de búsqueda y dimensiones (por ejemplo, 10 dimensiones y rango de valores), algoritmo u operador (por ejemplo, algoritmo DE, operadores de cruce y mutación), tamaño de población y generaciones de iteración (por ejemplo, población 128, 200 generaciones), plataforma de cómputo (CPU o GPU tensorizada), salida esperada (mejor valor, curva de convergencia, registro de ejecución). Demasiado gruesa activará la configuración predeterminada, difícil de juzgar si cumple la intención
- demasiado detallada degenera en codificación manual. La práctica adecuada es aclarar las restricciones y el criterio de aceptación, y dejar los detalles de implementación a la IA. Por ejemplo, especificar el problema, el algoritmo, el tamaño de población y el número de iteraciones, pero sin necesidad de prescribir cómo invocar interfaces concretas. Si realmente se ejecuta, y no solo se da código, se puede ver en los registros de terminal y el tiempo de ejecución
- si la curva de convergencia es monotónicamente decreciente y sin oscilaciones anómalas
- si el mejor valor es coherente con el orden de magnitud conocido del problema, por ejemplo, el óptimo global de la función Rastrigin es 0
- si la semilla aleatoria y la configuración son reproducibles; con semilla fija, las ejecuciones repetidas deben dar resultados iguales o similares. Cuando los resultados no alcanzan lo esperado, priorizar añadir restricciones por diálogo, por ejemplo "fijar seed=42, re-ejecutar y dar la media y varianza de tres repeticiones", y observar si la IA puede corregir iterativamente en lugar de reescribir. El humano se encarga de la definición del problema, el criterio de las métricas y la determinación de resultados
- la IA se encarga de la selección de interfaces, la organización del código y la ejecución de depuración. Solo se hace la verificación del flujo de tareas básicas, sin desarrollar temas posteriores como la evolución de dos capas de MetaDE, las compensaciones multiobjetivo o el multi-Agente Genesis. Ejemplo de indicación de referencia: "Usa EvoX para resolver el mínimo de la función Rastrigin (10 dimensiones), con algoritmo DE, población 128, 200 generaciones, backend tensorizado en GPU, seed=42 fijo
- ejecuta directamente y devuelve la mejor aptitud, el gráfico de la curva de convergencia y el registro de ejecución." Si realmente se ejecuta, si la forma de la curva de convergencia es razonable, si el mejor valor se acerca a 0, si los resultados de ejecuciones repetidas son consistentes.
> **Pistas de ejercicios**
>
> - No es necesario especificar el número concreto de líneas de código de la implementación del algoritmo
> - La evidencia clave para verificar la ejecución real es el registro de iteraciones en terminal y la curva de convergencia
> - Cuando los resultados son malos, lo más efectivo es añadir restricciones, por ejemplo fijar la semilla aleatoria y repetir la ejecución
> - El humano se encarga principalmente de definir el problema, el criterio de las métricas y la determinación de resultados
> - La granularidad de la indicación debe aclarar restricciones y criterio de aceptación, dejando los detalles de implementación a la IA. Si los estudiantes responden mal, se les puede guiar a volver a "elementos de la indicación", "lista de verificación de ejecución" y "división humano-máquina" para encontrar la base. Función Ackley de 20 dimensiones, CMA-ES, población 64, 500 iteraciones, CPU, seed=123 fijo; si la curva oscila violentamente al principio y el mejor valor es mucho mayor que 0, las posibles causas incluyen parámetros de paso demasiado grandes, diversidad de población insuficiente, desajuste entre parámetros del algoritmo y dimensión del problema, fluctuaciones de exploración inicial causadas por la semilla aleatoria, etc. Las restricciones añadidas pueden fijar la semilla y repetir tres veces, calcular media y varianza
> - requerir la salida del cambio del mejor valor por generación
> - ajustar el paso o el tamaño de población y re-ejecutar. En la aceptación, además del mejor valor, se debe verificar si realmente se ejecutó, la forma de la curva de convergencia, el orden de magnitud del mejor valor, la reproducibilidad y la razonabilidad del tiempo de ejecución. Se puede pedir a los estudiantes que se dividan en grupos por roles: uno encargado de construir la indicación, otro de observar el registro de ejecución y la curva de convergencia, y otro de dar la conclusión de aceptación según la lista de verificación
> - registrar un resultado fallido o no ideal, e intentar mejorarlo añadiendo restricciones.
**Verificación de comprensión**
Pedir aleatoriamente a un estudiante que resuma con sus propias palabras los puntos clave de esta página, y el instructor complementa los elementos de la indicación, las cuatro preguntas de aceptación y el principio de iterar en lugar de reescribir.
> **Indicación de transición**
>
> Después de confirmar que los estudiantes pueden expresar la relación central de "el humano da la dirección, la IA da la implementación, el humano hace la aceptación", pasar a la siguiente página con ejemplos, aplicaciones o resumen.
### Resumen del curso: flujo de trabajo AI nativo y gusto científico
*Página 15*
> **Objetivo de la página:** Resumir el flujo de trabajo AI nativo de EvoX y el pensamiento crítico en la colaboración humano-máquina.
> **Objetivo de la página**
>
> Esta página, como cierre de todo el curso, converge el flujo de trabajo AI nativo de EvoX y el gusto científico irremplazable del investigador en una misma conclusión: cuando las herramientas reducen el costo de "implementar respuestas" a un nivel extremadamente bajo, "definir qué vale la pena hacer y juzgar qué resultados son confiables" se convierte en la divisoria del valor científico.
> **Orden de explicación**
>
> A la izquierda está el flujo de trabajo AI nativo, que parte del diálogo en lenguaje natural y completa la configuración del entorno, la construcción de problemas y restricciones, el impulso de la ejecución evolutiva y la exploración por lotes, el análisis visual de resultados y la revisión; a la derecha está el gusto científico humano, encargado de definir el problema, establecer objetivos y restricciones, hacer compensaciones multiobjetivo, juzgar la confiabilidad de los resultados y la dirección de evolución.
>
> La IA implementa respuestas, el humano controla la dirección; en una frase: Code is cheap. Taste matters.
>
> El flujo de trabajo comprime el costo de ruta de la idea al primer experimento ejecutable; la responsabilidad asciende con la conveniencia; el gusto científico tiene puntos de apoyo identificables; el pensamiento crítico tiene cuatro preguntas estructuradas; la evolución continua a nivel de proyecto y de sistema aún requiere que el humano establezca criterios de aceptación y dirección de evolución.
>
> Lo escaso no es el código, sino el juicio; la destreza en el flujo de trabajo determina qué tan rápido se puede correr, el gusto científico y el pensamiento crítico determinan si la dirección es correcta.
**Puntos clave de enseñanza**
- Tomar el diálogo en lenguaje natural como entrada para impulsar el experimento de cadena completa de EvoX. Lo que reduce es el costo de ruta de la "idea" al "primer experimento ejecutable", no el experimento mismo, ni reemplaza la definición del problema y el juicio de resultados. El esqueleto del script, las interfaces de parámetros y el código de dibujo pueden tomar forma más rápido, y el investigador obtiene así una mayor frecuencia de iteración experimental. Cuanto más fácil es usar la herramienta, más clara es la responsabilidad humana. La automatización transfiere la carga de ejecución, no la responsabilidad de juicio. Cuando la IA produce soluciones candidatas en minutos, "si la compensación multiobjetivo es razonable", "si la mejora de métricas es confiable", "hacia dónde explorar a continuación" aún deben ser respondidas por el investigador. La conveniencia aumenta el rendimiento de ensayo y error, y amplifica igualmente la velocidad de propagación de decisiones erróneas. Definición del problema, decide qué investigar y qué abandonar
- establecimiento de objetivos y restricciones, traduce la intención vaga en funciones objetivo optimizables y restricciones duras
- compensación multiobjetivo, da preferencias defendibles entre velocidad de convergencia, diversidad, robustez y costo
- juicio de confiabilidad de resultados, distingue "salió" de "la conclusión se sostiene"
- establecimiento de la dirección de evolución, decide dónde explorar en la siguiente ronda, en lugar de aceptar pasivamente el óptimo actual. Estos no son problemas de cálculo, sino problemas de valor y juicio. ¿Se sostienen las hipótesis? La IA puede haber completado silenciosamente premisas no declaradas
- ¿Se malinterpretan las métricas? La mejora puede provenir de fuga de datos, cambios en el criterio de evaluación o sobreajuste
- ¿Se pueden reproducir los resultados? La semilla aleatoria, la programación paralela y las versiones de dependencias afectan la reproducibilidad
- ¿Se verifican los límites y modos de fallo? Si siguen siendo válidos bajo restricciones extremas, datos dispersos o alta dimensionalidad. La IA se encarga de la implementación y la exploración por lotes, el humano de la dirección y el juicio de valor. Sin importar el grado de automatización, los criterios de aceptación y la dirección de evolución aún deben ser establecidos por humanos
- si esta capacidad de juicio falta a largo plazo, la brecha en el gusto se amplificará con el tiempo hasta convertirse en deuda técnica difícil de pagar. La IA implementa respuestas, el humano controla la dirección. Antes de delegar cada tarea a la IA, pensar claramente cuál es el criterio de aceptación.
**Cobertura de palabras clave**
- Flujo de trabajo AI nativo, gusto científico, pensamiento crítico, división humano-máquina, carga de ejecución, responsabilidad de juicio, definición del problema, objetivos y restricciones, compensación multiobjetivo, confiabilidad de resultados, dirección de evolución, deuda técnica, Code is cheap. Taste matters.
> **Pistas de ejercicios**
>
> - Los ejercicios de esta página giran en torno a la compresión de costos, la transferencia de responsabilidad, los puntos de apoyo del gusto científico, la verificación crítica y los riesgos de la evolución continua. Al tratarlos, primero pedir a los estudiantes que juzguen "qué es reemplazado por la automatización y qué no lo es", y luego volver al marco de dos pasos de "primero que funcione, luego verificar".
**Tratamiento de ejercicios**
La herramienta comprime el costo de implementación de la idea al primer experimento ejecutable, pero no cambia la dificultad de la definición del problema ni del juicio de resultados. Al retroalimentar, recordar distinguir "carga de ejecución" de "responsabilidad de juicio".
La velocidad de producción aumenta, haciendo que conclusiones no verificadas se propaguen más fácilmente como resultados ya confirmados. Al retroalimentar, enfatizar que la conveniencia aumenta el rendimiento de ensayo y error, y amplifica en la misma proporción la velocidad de propagación de decisiones erróneas.
Definición del problema, establecimiento de objetivos y restricciones, compensación multiobjetivo, juicio de confiabilidad de resultados, establecimiento de la dirección de evolución. Al retroalimentar, explicar que estos eslabones son problemas de valor y juicio, no problemas de cálculo.
Suposiciones implícitas que la IA completó silenciosamente sin declararlas, y si el criterio de evaluación fue modificado. Al retroalimentar, señalar que el foco de la verificación crítica son las suposiciones, el criterio de las métricas, la reproducibilidad y las condiciones de frontera, no la forma de presentación.
La brecha en el gusto se amplifica continuamente con el tiempo, acumulándose como deuda técnica difícil de pagar. Al retroalimentar, reiterar que la automatización solo puede garantizar "que funcione", no "que la dirección sea correcta".
Frente a las soluciones candidatas y la clasificación recomendada por la IA, primero verificar si los objetivos y restricciones cumplen las demandas reales del negocio, luego examinar el criterio de las métricas y la línea base, revisar la distribución y robustez de las soluciones en el frente de compromiso, hacer pruebas de límites y modos de fallo, y fijar semillas aleatorias, versiones de dependencias y configuración experimental para garantizar la reproducibilidad. Si se decide completamente la solución principal según la clasificación recomendada por la IA y se avanza automáticamente en la dirección, el riesgo es externalizar el juicio de valor de la compensación multiobjetivo, la dirección errónea es heredada repetidamente por iteraciones posteriores, y "que funcione" se confunde con "dirección correcta". Al redefinir la división, dejar que la IA se encargue de la implementación y la exploración por lotes, y que el humano aclare los pesos de los objetivos y las restricciones duras, establezca los criterios de aceptación, conserve el derecho de revisión y veto, y designe hipótesis y métodos de verificación para la siguiente ronda de exploración.
**Actividad en clase**
Pedir a los estudiantes que repitan con sus propias palabras las "cuatro preguntas de autoverificación", y que den un ejemplo cercano a su propia experiencia de aprendizaje o investigación para explicar cómo, si se omite la verificación, se confunde "salió" con "se sostiene".
**Verificación de comprensión**
Pedir aleatoriamente a un estudiante que resuma los puntos clave de esta página, y que responda "qué determina la destreza en el flujo de trabajo y qué determinan el gusto científico y el pensamiento crítico". El instructor complementa las relaciones omitidas según la respuesta: la primera determina la velocidad, los segundos determinan la dirección y el valor.
> **Indicación de transición**
>
> Después de confirmar que los estudiantes pueden distinguir "que funcione" de "que se sostenga", e "implementar respuestas" de "controlar la dirección", pasar a la siguiente página con ejemplos, aplicaciones o resumen.
### Apéndice y entrada a la comunidad de código abierto
*Página 16*
> **Objetivo de la página:** Obtener los canales oficiales de comunicación de EvoX y recursos de aprendizaje continuo.
> **Objetivo de la página**
>
> Esta página, como apéndice del curso, reúne las entradas oficiales de la comunidad del sistema de evolución inteligente EvoX y la práctica de investigación AI Native, y explica los canales para el aprendizaje continuo, las preguntas y la participación en la exploración de frontera después de clase.
**Puntos clave de enseñanza**
- Primero distinguir dos entradas oficiales. La cuenta oficial de WeChat es "演化机器智能" (Inteligencia de Máquinas Evolutivas), utilizada para publicar actualizaciones del curso, artículos técnicos, notificaciones de actividades e interpretaciones de frontera, adecuada para seguir sistemáticamente la dirección de la evolución inteligente. El grupo oficial de QQ tiene el número 297969717, utilizado para preguntas en tiempo real, discusión e intercambio entre pares, facilitando obtener retroalimentación sobre problemas concretos. Ambos apuntan a "participar continuamente en la exploración de frontera de la evolución inteligente", no reemplazan el aprendizaje en clase, sino que forman el ciclo de "aprender—practicar—intercambiar—volver a aprender". Después de unirse, primero revisar los anuncios fijados y los mensajes históricos, comprender las normas y los recursos existentes, y luego participar en la discusión según la dirección de investigación. Al preguntar, proporcionar contexto claro, preguntas concretas y métodos ya intentados
- participar activamente en las discusiones de otros también profundiza la comprensión. Revisar periódicamente el contenido de frontera y convertir los recursos de la comunidad en capacidad de investigación. Los ejercicios de esta página giran en torno a tres hechos y dos actitudes. El nombre de la cuenta oficial es "演化机器智能"
- el número del grupo de QQ es 297969717
- el propósito de las entradas de la comunidad es proporcionar canales de aprendizaje continuo, preguntas y exploración de frontera después de clase
- los recursos posteriores al curso deben obtenerse a través de las entradas oficiales: seguir la cuenta oficial y unirse al grupo de QQ
- el uso de la comunidad debe ser preguntar activamente, compartir y participar en discusiones, no solo usarla antes de los exámenes, unirse a grupos no oficiales o permanecer en silencio. El estudio de caso puede guiar a los estudiantes a escribir los dos canales oficiales y dar al menos dos sugerencias de aprendizaje continuo, como seguir las actualizaciones de la cuenta oficial, preguntar e intercambiar en el grupo, seguir las novedades de frontera, participar en proyectos de código abierto o actividades en línea, aplicar lo aprendido en el curso a la investigación real y compartir experiencias.
**Verificación de comprensión**
Pedir a los estudiantes que expliquen con sus propias palabras para qué sirve cada una de las dos entradas oficiales, y que repitan la práctica correcta tras unirse a la comunidad. Si los estudiantes solo recuerdan los nombres pero no pueden explicar sus usos, se les puede pedir que revisen la página y comparen ambas entradas.
> **Indicación de transición**
>
> Después de confirmar que los estudiantes pueden expresar la relación entre las entradas oficiales y el ciclo de aprendizaje continuo, pasar a la siguiente página.
--- FIN DEL TEXTO FUENTE ---