# 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 6｜Tema: Evolución Continua a Nivel de Sistema: Genesis y la Sedimentación del Mundo del Software](#lecture-lesson-1)
---
## Lección 6｜Tema: Evolución Continua a Nivel de Sistema: Genesis y la Sedimentación del Mundo del Software
### Evolución Continua a Nivel de Sistema: Genesis y la Sedimentación del Mundo del Software
*Página 1*
> **Objetivo de la página:** Aprender cómo Genesis, mediante la colaboración multi-Agente y mecanismos de verificación estrictos, permite que el código del proyecto se acumule y evolucione continuamente a lo largo de su ciclo de vida.
> **Objetivo de la página**
>
> Cómo un proyecto no solo completa una codificación, sino que permite que el código se acumule y evolucione continuamente a lo largo de todo su ciclo de vida. Hay dos hilos conductores principales: primero, el patrón de ingeniería constituido por la colaboración multi-Agente y la descomposición recursiva de tareas; segundo, el mecanismo mediante el cual la compilación, las pruebas y la aceptación sedimentan las modificaciones efectivas en la historia del proyecto.
**Puntos clave de la enseñanza**
- 1. Primero señalar el significado de "evolución continua". El software no es un producto que se fija una vez escrito, sino una entidad que se modifica, complementa y refactoriza constantemente a lo largo del tiempo. La posición de Genesis es precisamente proporcionar una forma organizativa ejecutable para esta evolución a largo plazo, en lugar de ser una técnica de generación de código de una sola vez. 2. La colaboración multi-Agente resuelve "quién se divide el trabajo". Frente a un proyecto real, la escala de la tarea a menudo excede la capacidad de procesamiento de una sola vez, por lo que se necesita división de roles y flujos de colaboración que hagan que las responsabilidades de cada eslabón sean claras y rastreables. 3. La descomposición recursiva de tareas resuelve "cómo empezar". Se descompone un objetivo mayor capa por capa en tareas pequeñas ejecutables, hasta que cada subtarea sea lo suficientemente concreta como para ser completada y verificada de forma independiente. Esto reduce la dificultad de cada paso y permite evaluar el resultado de cada uno por separado. 4. La verificación estricta resuelve "con qué fundamento cuenta como válido". La compilación exitosa, la prueba exitosa y la aceptación exitosa son tres barreras que se estrechan capa por capa. Solo las modificaciones que superan estas barreras tienen derecho a ser escritas en la historia del proyecto.
- Las modificaciones que no pasan se descartan o se rehacen. La colaboración y la descomposición producen una gran cantidad de modificaciones candidatas, la verificación se encarga de filtrarlas, y los resultados filtrados se sedimentan en la historia del proyecto, que a su vez se convierte en el punto de partida de la siguiente ronda de evolución. Este es el circuito completo de la "evolución continua a nivel de sistema".
**Verificación de comprensión**
Se pide a los estudiantes que expresen con sus propias palabras la relación de orden entre "descomposición—verificación—sedimentación", y que respondan: si una modificación pasa la compilación pero no pasa las pruebas, ¿en qué estado se encuentra dentro del mecanismo descrito en esta página? El docente confirma con esto si el estudiante realmente comprendió el papel de las barreras de verificación, en lugar de solo memorizar términos.
> **Sugerencia de transición**
>
> Esta página establece el marco general; el contenido posterior entrará en métodos y ejemplos más concretos. Tras confirmar que los estudiantes pueden recitar este circuito, continuar profundizando en los eslabones específicos.
### Límites de Capacidad de los Grandes Modelos y la Necesidad de la Evolución a Nivel de Sistema
*Página 2*
> **Objetivo de la página:** Comprender los límites de capacidad actuales de los grandes modelos en el desarrollo de sistemas complejos y la necesidad de construir sistemas de desarrollo continuo.
> **Objetivo de la página**
>
> Comprender los límites de capacidad de los grandes modelos en el desarrollo de sistemas complejos, y por qué es necesario integrar componentes inteligentes en un circuito de sistema que pueda evolucionar continuamente a lo largo de su ciclo de vida.
> **Orden de explicación**
>
> Los grandes modelos son componentes inteligentes poderosos, pero no son sistemas capaces de autosostenerse. Ya poseen capacidades utilizables en comprensión, generación, razonamiento y llamada de herramientas, y pueden actuar como proponentes de hipótesis y productores de código de alta calidad; pero carecen del estado, los objetivos y los mecanismos de retroalimentación necesarios para evolucionar continuamente a lo largo del ciclo de vida.
>
> Comprensión, generación, razonamiento, llamada de herramientas, y finalmente se obtiene una instantánea estática; al terminar la sesión el estado se reinicia a cero. A la derecha, el gran modelo se integra como un pequeño módulo en el circuito de evolución a nivel de sistema: propuesta, evaluación, selección, sedimentación. El gran modelo se encarga de proponer; el modelo proxy se usa para reducir el costo de evaluación; la etapa de selección maneja el equilibrio multiobjetivo; la sedimentación forma la memoria entre sesiones; la inteligencia de enjambre mantiene la diversidad de candidatos y regresa a la siguiente ronda de propuestas.
>
> Límite de estado — la ventana de contexto es finita, carece de memoria persistente entre sesiones, y los proyectos de largo ciclo no pueden autosostenerse; límite de objetivos — los problemas reales a menudo involucran conflictos multiobjetivo y equilibrio de preferencias, y el modelo difícilmente puede dar criterios de compromiso defendibles de forma autónoma; límite de retroalimentación — carece de mecanismos ejecutables de evaluación, selección y eliminación, y los esquemas generados no pueden ser verificados objetivamente ni retenidos iterativamente.
>
> La mejora de la capacidad del modelo no equivale a la mejora de la capacidad del sistema. La capacidad es una instantánea, el entorno es un proceso. Solo integrando el gran modelo en el circuito evolutivo de "generación—evaluación—selección—sedimentación", manteniendo la diversidad con inteligencia de enjambre, comprimiendo el costo de evaluación con modelos proxy, y reteniendo experiencia efectiva con selección y sedimentación, la inteligencia puede mantener su adaptabilidad en entornos dinámicos. Este es también el punto de anclaje de EvoX.
**Puntos clave de la enseñanza**
- Los grandes modelos poseen poderosas capacidades de comprensión y generación, pero no pueden evolucionar sistemas de forma independiente. Los sistemas complejos del mundo real requieren capacidades de evolución continua a lo largo del ciclo de vida; las instantáneas estáticas no bastan para responder a los cambios del entorno. Los componentes inteligentes necesitan mecanismos evolutivos para adaptarse a entornos dinámicos; los mecanismos clave incluyen el circuito evolutivo, la inteligencia de enjambre y los modelos proxy. Límite de estado, límite de objetivos, límite de retroalimentación.
**Tratamiento de ejercicios**
Para las preguntas de conceptos centrales debe elegirse "comprender los límites de capacidad actuales de los grandes modelos en el desarrollo de sistemas complejos y la necesidad de construir sistemas de desarrollo continuo".
Para el resto de las preguntas de verdadero/falso debe priorizarse la opción "poder explicar con evidencia o ejemplos"; decidir solo por intuición, saltarse la memorización de materiales, o cambiar todos los factores a la vez para comparar, no cumple con los requisitos de esta página.
Si la respuesta es correcta, se puede elogiar que logra conectar con los conceptos de esta página y explicar sus fundamentos; si es incorrecta, se sugiere volver a la explicación para encontrar la evidencia o ejemplo clave, repasando especialmente los tres tipos de límites y el circuito "propuesta—evaluación—selección—sedimentación".
Primero explicar que la idea central es "los grandes modelos poseen poderosas capacidades de comprensión y generación pero no pueden evolucionar sistemas de forma independiente", y luego dar ejemplos de por qué los sistemas complejos necesitan capacidades de evolución continua a lo largo del ciclo de vida.
**Verificación de comprensión**
Se pide a los estudiantes que expliquen con sus propias palabras "por qué la mejora de la capacidad del modelo no equivale a la mejora de la capacidad del sistema", y que señalen al menos dos de los tres tipos de límites: estado, objetivos y retroalimentación. Si el estudiante puede explicar claramente la relación entre la capacidad monolítica y la evolución en circuito cerrado, se puede pasar a la siguiente página; si no, volver al diagrama comparativo y reorganizar las dos rutas, izquierda y derecha.
> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar la relación central "el gran modelo es un componente, el circuito evolutivo es el sistema", continuar con el contenido posterior sobre evolución continua a nivel de sistema, Genesis y la sedimentación del mundo del software.
### Expansión de los Límites de Evolución: de los Parámetros Numéricos a los Sistemas de Programa
*Página 3*
> **Objetivo de la página:** Dominar cómo los grandes modelos expanden los objetos de evolución desde parámetros numéricos tradicionales hasta programas, estructuras de modelo y estados de sistema.
> **Objetivo de la página**
>
> Dominar cómo los grandes modelos expanden los objetos de evolución desde parámetros numéricos tradicionales hasta programas, estructuras de modelo y estados de sistema, y comprender las condiciones impulsoras de esta expansión de límites y los cambios en la evaluación.
> **Orden de explicación**
>
> Los objetos suelen ser vectores de parámetros numéricos de baja dimensión y predefinidos, como hiperparámetros, pesos, variables continuas; el espacio de búsqueda está limitado por estructuras y modos de codificación preestablecidos manualmente.
>
> Tras la expansión de la escala computacional y la base de ingeniería, la búsqueda de objetos de alta dimensión, discretos y estructurados pasa de ser inviable a ser tratable, y los límites de búsqueda se expanden en sincronía con la potencia de cómputo y la cadena de herramientas.
>
> Con capacidades de comprensión de código, razonamiento contextual y generación de candidatos, se pueden construir, modificar y evaluar directamente objetos a nivel de programa, reduciendo la dependencia de operadores de codificación y mutación diseñados manualmente.
>
> Si los métodos de generación de candidatos siguen siendo fijados manualmente, el sistema solo repetirá la rutina establecida; incorporar el propio método de generación de candidatos como objeto de evolución, por ejemplo las estrategias de mutación y la configuración de parámetros de la evolución diferencial, es precisamente la manifestación de la expansión de límites.
>
> De abajo hacia arriba: parámetros numéricos → estructura de modelo → mecanismo algorítmico → estado de programa e ingeniería de software; hacia arriba, la dimensionalidad del espacio de búsqueda y la complejidad semántica aumentan progresivamente; a la derecha está el soporte de capacidad del gran modelo; arriba están las restricciones de verificación ejecutable y costo de ingeniería.
>
> Cuanto más alto el nivel, más fuertes las restricciones semánticas y más larga la cadena de evaluación; los candidatos deben ser ejecutables y verificables; la evaluación de aptitud pasa de ser una función escalar a un juicio conjunto de resultados de ejecución y restricciones de ingeniería.
>
> Esto no reemplaza la optimización de parámetros, sino que incorpora la optimización de parámetros en un ciclo mayor de evolución de programas y sistemas, formando un espectro continuo desde el ajuste local de parámetros hasta la mejora a nivel de sistema.
**Puntos clave de la enseñanza**
- La expansión de la escala computacional trae límites de búsqueda más amplios. Los grandes modelos pueden comprender código y contexto y construir candidatos complejos. Los objetos de evolución se expanden desde parámetros numéricos hasta programas y estados de ingeniería de software, pasando por estructuras de modelo y mecanismos algorítmicos. Primero, la expansión de la potencia de cómputo y la base de ingeniería; segundo, los grandes modelos poseen capacidades de comprensión de código, razonamiento contextual y generación de candidatos.
**Cobertura de palabras clave**
- Parámetros numéricos, estructura de modelo, mecanismo algorítmico, estado de programa e ingeniería de software, límites de búsqueda, comprensión de código, razonamiento contextual, construcción de candidatos, verificación ejecutable, costo de ingeniería, evaluación de aptitud, espectro continuo. Tratamiento de ejercicios y retroalimentación: Los grandes modelos expanden los objetos de evolución desde parámetros numéricos tradicionales hasta programas, estructuras de modelo y estados de sistema. Si la respuesta se desvía, se sugiere volver primero a la oración conceptual e intentar de nuevo. Los grandes modelos pueden comprender código y contexto de ejecución, y a partir de ello construir y modificar candidatos complejos a nivel de programa.
- Las opciones incorrectas suelen limitar los grandes modelos a parámetros numéricos codificados manualmente. La dirección correcta de los ejercicios 3, 4 y 5 no es memorizar, decidir por intuición ni cambiar todos los factores a la vez, sino poder explicar las conclusiones relevantes con evidencia o ejemplos. La retroalimentación puede enfatizar: solo se considera verdadero dominio si se puede conectar con los conceptos de esta página y explicar sus fundamentos. El equipo primero ajusta solo hiperparámetros numéricos como la tasa de aprendizaje, el tamaño de lote y el número de capas de red.
- Posteriormente se pide al gran modelo que lea los scripts de entrenamiento y los registros de ejecución, reescriba directamente la implementación del optimizador, la tubería de datos y el flujo de control del algoritmo, y luego entregue los candidatos a la ejecución en tiempo de ejecución, retornando métricas para la siguiente ronda de evolución a nivel de programa. Se puede preguntar: ¿Cuál es la idea central? ¿Cuáles son las dos condiciones que impulsan la expansión? Puntos clave de la respuesta: la evolución tradicional tiene como objeto vectores de parámetros numéricos de baja dimensión, y el espacio de búsqueda está limitado por presets manuales.
- La expansión de la potencia de cómputo y la base de ingeniería hace tratable la búsqueda de alta dimensión, discreta y estructurada.
- Los grandes modelos pueden construir y reescribir objetos a nivel de programa, por lo que los objetos de evolución se expanden capa por capa hacia estructuras de modelo, mecanismos algorítmicos y estados de programa o ingeniería de software. Luego preguntar: ¿Cómo participan los grandes modelos en la construcción y evaluación de candidatos a nivel de programa? Puntos clave de la respuesta: leer scripts y contexto de ejecución, reescribir optimizadores o flujos de control para generar candidatos ejecutables.
- La ejecución en tiempo de ejecución verifica si puede ejecutarse, y luego se compara con restricciones de ingeniería como recursos y presupuesto de tiempo; las métricas retornadas impulsan la siguiente ronda de evolución.
**Verificación de comprensión**
Se pide a los estudiantes que reciten con sus propias palabras la cadena de expansión jerárquica, y que completen la capacidad del gran modelo a la derecha y las restricciones de verificación y costo arriba. Se puede preguntar adicionalmente: "¿Por qué cuanto más alto el nivel, la evaluación de aptitud se parece más a un juicio conjunto de resultados de ejecución y restricciones de ingeniería?" Confirmar que los estudiantes pueden mencionar razones como ejecutabilidad, verificabilidad y alargamiento de la cadena de evaluación.
> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden distinguir la relación entre la optimización de parámetros y la evolución a nivel de programa o sistema, continuar con la siguiente página sobre colaboración multi-agente y sedimentación por verificación.
### Desafíos Complejos del Mundo Real: Equilibrio Multiobjetivo y Mantenimiento de la Diversidad
*Página 4*
> **Objetivo de la página:** Comprender la importancia de los objetivos complejos mutuamente condicionados en los problemas del mundo real y de retener soluciones candidatas diversificadas.
**Puntos clave de la enseñanza**
- Bajo múltiples objetivos no existe un orden total natural. Al ver un conjunto de candidatos, primero preguntar "¿bajo qué preferencia se comparan?", y luego hablar de ventajas y desventajas; de lo contrario, es fácil confundir las preferencias personales con conclusiones objetivas.
- Retener solo el óptimo actual provoca convergencia prematura de la población y colapso de modos. Se pueden usar mecanismos como la distancia de hacinamiento, nichos y archivo externo para que los candidatos se distribuyan en diferentes regiones del frente, cubriendo más intervalos de equilibrio.
- El algoritmo se encarga de generar opciones disponibles con diferencias; los expertos de dominio se encargan de completar la evaluación y el compromiso según preferencias y restricciones. No confundir "generar candidatos" con "decidir por las personas".
Objetivo de la página
Comprender la esencia de los objetivos mutuamente condicionados en los problemas del mundo real, y explicar por qué el sistema debe retener un conjunto de soluciones candidatas con diferencias, en lugar de converger a una única "respuesta óptima".
Orden de explicación
Los problemas reales rara vez tienen una solución óptima única. Múltiples objetivos se condicionan mutuamente; la mejora de un indicador generalmente tiene como costo el deterioro de otros. Por lo tanto, el sistema debe retener un conjunto de soluciones candidatas no dominadas con diferencias, haciendo visibles explícitamente las relaciones de equilibrio y manteniendo la decisión en el juicio humano.
Los puntos grises representan soluciones posibles; los puntos de color representan candidatos mutuamente no dominados, que en conjunto constituyen el frente. En la figura, A se inclina por la resistencia, B es equilibrado, C se inclina por la eficiencia, D tiene resistencia extremadamente baja. El frente de Pareto solo puede aproximarse, no eliminarse.
3. Desarrollar cuatro comprensiones clave. Primero, el conflicto de objetivos es estructural, no un problema de ajuste de parámetros: entre objetivos como la relación sustentación-arrastre, la resistencia estructural, el costo y la fabricabilidad no existe un óptimo simultáneo. Segundo, bajo múltiples objetivos no hay orden total: dos soluciones cualesquiera pueden ser mutuamente no dominadas, y "el mejor" debe definirse con una dirección de preferencia adjunta; al ver un conjunto de candidatos, primero preguntar "¿bajo qué preferencia se comparan?", y luego hablar de ventajas y desventajas. Tercero, la retroalimentación dispersa es la norma: la evaluación de ingeniería real depende de simulaciones o mediciones de alto costo, con poca retroalimentación, mucho ruido y gradientes no disponibles; la búsqueda de ascenso de punto único difícilmente avanza eficazmente; los algoritmos evolutivos, al mantener una población, exploran múltiples direcciones simultáneamente con pocas evaluaciones.
Perseguir solo el óptimo actual provoca convergencia prematura de la población y colapso de modos, perdiendo finalmente todo el intervalo de equilibrio no explorado; se pueden usar mecanismos como la distancia de hacinamiento, nichos y archivo externo para que los candidatos se distribuyan en diferentes regiones del frente.
El algoritmo se encarga de "generar un conjunto de opciones disponibles con diferencias"; los expertos de dominio se encargan de "completar la evaluación y el compromiso según preferencias y restricciones". El conjunto de soluciones candidatas no decide por las personas, sino que pone sobre la mesa opciones comparables.
En el diseño de perfiles alares supercríticos, la eficiencia aerodinámica, las características de divergencia de resistencia, la resistencia estructural y el costo de fabricación se condicionan mutuamente. El valor de EvoX no radica en dar un único "perfil alar óptimo", sino en producir una familia de perfiles alares candidatos que cubren diferentes intervalos de equilibrio, para que los ingenieros elijan según condiciones de vuelo específicas y restricciones de proceso.
Puntos clave de la enseñanza
Definir "el mejor" con direcciones de preferencia; mantener activamente la diversidad; distinguir entre generación y compromiso. Bajo múltiples objetivos no hay orden total natural; retener solo el óptimo actual provoca el colapso de la población; el algoritmo genera candidatos con diferencias, y los expertos completan el juicio final según preferencias y restricciones. Las dos pequeñas figuras a la derecha de la imagen ya muestran intuitivamente la diferencia entre convergencia de punto único y distribución diversa: la primera colapsa en un grupo, la segunda se despliega en un frente.
Tratamiento de ejercicios
La ausencia de orden total significa que la dirección de preferencia debe participar en la definición; la retroalimentación dispersa dificulta el avance de la búsqueda de punto único porque la evaluación es costosa, ruidosa y el gradiente no está disponible; el valor de dispersar candidatos es dejar el poder de elección y el conocimiento de dominio a los expertos; perseguir solo el óptimo actual provoca convergencia prematura y colapso de modos; en el diseño de perfiles alares supercríticos, la posición de EvoX es producir una familia de perfiles alares candidatos que cubren diferentes intervalos de equilibrio. Al retroalimentar, si el estudiante elige mal, se le puede guiar de vuelta a las tres palabras clave: "dirección de preferencia", "retroalimentación dispersa" y "la diversidad es un activo".
Guía de estudio de caso
En el escenario de taxis aéreos urbanos, se pueden identificar conflictos entre alcance y carga útil, entre ruido y eficiencia aerodinámica, y entre redundancia de seguridad y costo de fabricación. Estos objetivos se condicionan mutuamente, por lo que no existe un diseño único simultáneamente óptimo, solo un frente de Pareto mutuamente no dominado. EvoX puede tomar el alcance, la carga útil, el ruido, la redundancia de seguridad y el costo como múltiples objetivos, ejecutar la búsqueda de población y producir soluciones candidatas mutuamente no dominadas distribuidas en diferentes regiones del frente; los expertos de dominio luego realizan simulaciones de alta fidelidad o mediciones reales sobre las soluciones candidatas según el escenario operativo, las restricciones regulatorias y las condiciones de proceso, completando la evaluación y el compromiso final según la dirección de preferencia.
Verificación de comprensión
Se pide a los estudiantes que den con sus propias palabras un ejemplo cotidiano multiobjetivo, como el equilibrio entre rendimiento, precio, peso y autonomía al comprar un portátil, y que respondan "¿bajo qué preferencia se comparan?". Si el estudiante puede explicar que el mismo conjunto de candidatos bajo diferentes preferencias producirá elecciones razonables diferentes, significa que comprendió el núcleo de esta página.
Sugerencia de transición
Tras confirmar que los estudiantes pueden distinguir "generar candidatos" de "decidir por las personas", continuar con la siguiente página sobre mejora del método de cálculo o mejora del método. Esta página responde "por qué se necesita el equilibrio multiobjetivo y candidatos diversos"; el contenido posterior responderá respectivamente "cómo calcular más rápido" y "cómo mejorar el método mismo".
### Computación Tensorizada y Soporte de Exploración Paralela con Arquitectura Unificada
*Página 5*
> **Objetivo de la página:** Comprender cómo EvoX utiliza la computación tensorial por lotes para soportar una exploración evolutiva paralela de alta intensidad.
> **Objetivo de la página**
>
> Comprender cómo EvoX utiliza la computación tensorial por lotes para soportar una exploración evolutiva paralela de alta intensidad, y captar las dos líneas principales que se sustentan mutuamente: el grafo computacional tensorizado y la arquitectura unificada abierta y desacoplada.
>
> Orden de explicación sugerido:
>
> Cuando la población se expande de decenas a miles o decenas de miles, el problema central de la computación evolutiva ya no es "si se puede encontrar una buena solución", sino "si se pueden evaluar suficientes candidatos en tiempo limitado". La diversidad depende del rendimiento; mantener la diversidad es esencialmente una cuestión de potencia de cómputo.
>
> La computación tensorizada se encarga de "correr rápido"; la arquitectura unificada se encarga de "poder cambiar".
>
> El bucle CPU serial tradicional ejecuta "evaluación—registro—actualización" por individuo, lo que genera tres tipos de costos: alto costo de programación, fragmentación de operadores y baja utilización de GPU; el enfoque tensorizado organiza el mantenimiento de la población, la evaluación por lotes y la actualización de estado como operaciones tensoriales por lotes, permitiendo el cálculo paralelo de candidatos de la misma generación o incluso de múltiples generaciones. Por ejemplo, con N soluciones candidatas, el serial es un bucle uno por uno; el tensorizado organiza la población como un tensor, completando de una vez la evaluación por lotes y la actualización de estado en paralelo, reduciendo así el costo de programación y aumentando la ocupación de GPU.
>
> Reescribir solo el bucle no es suficiente; si el algoritmo, el problema y la lógica de programación están acoplados, cambiar de algoritmo o de tarea requiere reescribir. La arquitectura unificada desacopla el algoritmo, el problema, el flujo de trabajo y la programación del Runtime, y junto con la programación de cómputo heterogéneo gestiona CPU/GPU a nivel de tareas por lotes, permitiendo que el mismo mecanismo paralelo se reutilice en escenarios de evolución de métodos como MetaDE y AutoPSO.
>
> A la izquierda está el bucle CPU serial tradicional, serial individuo por individuo, con baja ocupación de GPU; a la derecha está la computación tensorial por lotes en GPU, tensor de población → evaluación por lotes → actualización de estado paralela; en la base está la base unificada abierta y desacoplada, que incluye algoritmo, problema, flujo de trabajo y programación del Runtime.
**Puntos clave de la enseñanza**
- EvoX no solo resuelve problemas, sino que también incorpora como objeto de evolución el método mismo que produce soluciones candidatas. En MetaDE, el algoritmo externo evoluciona la configuración y estrategia del algoritmo interno; AutoPSO y EvoGO combinan aún más componentes y utilizan retroalimentación histórica para aprender formas de generación de candidatos, pasando de "cambiar parámetros" a "cambiar la estructura del algoritmo". Este tipo de evolución de doble capa interna y externa exige naturalmente que una gran cantidad de tareas internas sean evaluadas por lotes y actualizadas en estado. Lo que cambia es la forma de organización del cálculo, convirtiendo toda la ruta "población—evaluación—actualización" en operaciones tensoriales por lotes, en lugar de reemplazar un operador o cambiar el modo de codificación. Si el perfilado de rendimiento muestra "demasiados operadores pequeños, baja ocupación de GPU, alta proporción de programación de CPU", generalmente indica que el sistema todavía está en un bucle serial individuo por individuo, lo cual es una señal de entrada para introducir el grafo computacional tensorizado. Hacer solo tensorización obliga a reescribir al cambiar de algoritmo o tarea.
- Hacer solo arquitectura unificada, sin paralelismo por lotes, sigue sin ser rápido.
**Tratamiento de ejercicios**
El cambio central de la tensorización es reescribir el mantenimiento de la población, la evaluación por lotes y la actualización de estado como operaciones tensoriales por lotes; los principales costos del bucle CPU serial tradicional son alto costo de programación, fragmentación de operadores y baja utilización de GPU; la arquitectura unificada abierta y desacoplada sirve para que el mecanismo paralelo sea reutilizable en diferentes algoritmos y tareas; con N soluciones candidatas de la misma generación, el beneficio clave es completar de una vez la evaluación por lotes y la actualización de estado paralela; la base aportada por GPU y grandes modelos eleva la computación por lotes de optimización local a capacidad fundamental para la exploración evolutiva a nivel de sistema. La retroalimentación de respuestas debe guiar a los estudiantes de vuelta a las dos palabras clave "paralelismo por lotes" y "reutilización desacoplada", evitando elegir distractores como "comprimir la población", "evaluación aproximada" o "flujo de trabajo fijo".
El ejercicio de caso requiere migrar la evolución diferencial de serial en una sola máquina a una base paralela por lotes. Puntos clave de la pregunta 1: el serial individuo por individuo genera alto costo de programación, fragmentación de operadores y baja utilización de GPU; la tensorización lo mitiga organizando la población como un tensor, fusionando la evaluación por lotes y la actualización de estado, manteniendo inalterada la semántica de mutación, cruce y selección. Puntos clave de la pregunta 2: la arquitectura unificada se descompone y desacopla en capa de algoritmo, capa de problema, capa de flujo de trabajo y capa de programación del Runtime;
la capa de algoritmo solo describe la semántica de generación y actualización de candidatos, la capa de problema encapsula la interfaz de evaluación por lotes, la capa de flujo de trabajo orquesta las tareas internas y externas, y la capa de programación del Runtime se encarga de la programación de cómputo heterogéneo y la gestión a nivel de tareas por lotes, permitiendo que la misma base se reutilice en escenarios de evolución de métodos como MetaDE y AutoPSO.
**Verificación de comprensión**
Se puede pedir a los estudiantes que expliquen con sus propias palabras "qué resuelve el grafo computacional tensorizado y qué resuelve la arquitectura unificada", y que den ejemplos de por qué ambos deben coordinarse.
> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden distinguir "correr rápido" de "poder cambiar", continuar con la siguiente página sobre casos específicos o mecanismos de ingeniería de la evolución continua a nivel de sistema.
### La Evolución del Propio Algoritmo: de Resolver Respuestas a Mejorar Métodos
*Página 6*
> **Objetivo de la página:** Comprender el principio básico de incorporar el método de generación de candidatos como objeto de optimización para lograr la auto-evolución del algoritmo.
**Puntos clave de la enseñanza**
- La capa interna busca respuestas, la capa externa cambia métodos. Ver "estrategias, parámetros, operadores, componentes puestos en la búsqueda" es evolución de métodos; ver "solo cambian las soluciones candidatas, las reglas de generación nunca cambian" es un algoritmo evolutivo tradicional.
- La señal de preferencia primero entra en la evaluación de respuestas, luego pasa por agregación entre tareas y verificación de estabilidad, y solo entonces se permite entrar en la selección de métodos. Saltarse este paso hace que la capa externa persiga un resultado agradable pero no reproducible.
- ¿Qué tan grande es el espacio de métodos? ¿Cuántas veces hay que ejecutar la tarea interna en cada ronda? ¿Con qué conjunto de tareas independiente se verifica que la mejora externa realmente generaliza? Si estas tres cuentas no están claras, la búsqueda de doble capa fácilmente degenera en un ajuste aleatorio de parámetros más caro.
Objetivo de la página
Los algoritmos evolutivos tradicionales buscan bajo un mecanismo de generación fijo, y lo optimizado siempre son las soluciones candidatas; la evolución de métodos incorpora también como objeto de búsqueda el método mismo que produce soluciones candidatas, completando la evolución de "resolver respuestas" a "mejorar métodos".
Orden de explicación
1. Primero comparar la diferencia entre los algoritmos evolutivos tradicionales y la evolución de métodos, señalando que "el objeto optimizado" se ha desplazado.
2. Introducir la definición de evolución de métodos, y explicar que EvoX avanza por esta ruta, incorporando como objeto de evolución el método mismo de generación de candidatos.
La capa interna busca respuestas, la capa externa cambia métodos.
4. Ubicar en qué capa debe colocarse la optimización de preferencias, enfatizando que los dos tipos de objetivos no deben confundirse.
5. Dar MetaDE, AutoPSO y EvoGO como formas típicas.
6. Cerrar con beneficios y costos, y tratar ejercicios y casos.
Puntos clave de la enseñanza
Reglas como selección, cruce y mutación sobre "cómo producir respuestas" están preescritas por humanos, y la búsqueda solo se mueve en el espacio de respuestas. Tras abrirse la escala de cómputo, el mecanismo de generación fijo se convierte en el techo.
El algoritmo no solo produce mejores respuestas, sino que mediante la búsqueda externa mejora continuamente las estrategias, parámetros y componentes que producen respuestas. EvoX es un trabajo en esta ruta, por ejemplo incorporando como objeto de evolución las estrategias de mutación y la configuración de parámetros de la evolución diferencial.
La capa interna resuelve problemas específicos con el método actual, produciendo soluciones candidatas; la capa externa, basándose en retroalimentación como la calidad de la solución, señales de preferencia, estabilidad o costo, compara, selecciona y actualiza el método a usar en la siguiente ronda. El objeto elevado al espacio de búsqueda no es una solución, sino el mecanismo mismo de generación de candidatos, por lo que se convierte en un objeto evaluable, seleccionable y actualizable.
La capa superior es "el método que evoluciona para producir soluciones candidatas", e incluye estrategias/parámetros/componentes de operadores, búsqueda evolutiva externa, y método de generación mejorado; la capa inferior es "resolver problemas específicos", e incluye el método actual, las soluciones candidatas y la evaluación de la calidad de la solución. Los dos circuitos representan respectivamente el retorno de los resultados externos a la capa interna, y la retroalimentación de calidad de solución/preferencia/costo que impulsa ambas capas. Al escribir en la pizarra, se pueden dibujar primero las dos capas superior e inferior, y luego marcar con flechas "actualizar el método de generación" y "señal de retroalimentación".
Puede participar en la retroalimentación de la capa superior, pero debe separar "evaluar la respuesta actual" de "mejorar el método que genera respuestas". Leer directamente "esta solución es más agradable" como "esta estrategia es mejor" es usar la preferencia de respuestas para disfrazar la calidad del método; la capa externa será arrastrada por el ruido de un solo resultado. La señal de preferencia primero entra en la evaluación de respuestas, luego pasa por agregación entre tareas y verificación de estabilidad, y solo entonces se permite entrar en la selección de métodos.
MetaDE hace que la capa externa evolucione las estrategias de mutación y los parámetros de la evolución diferencial, y la capa interna resuelve la tarea como de costumbre; AutoPSO y EvoGO combinan aún más componentes de enjambre de partículas y utilizan retroalimentación histórica para aprender formas de generación de candidatos, logrando el salto de "cambiar parámetros" a "cambiar la estructura del algoritmo".
El beneficio es llevar el diseño del algoritmo de un ajuste manual de una sola vez a una auto-adaptación sostenible. Hay tres costos: expansión del espacio de búsqueda, ya que el espacio de métodos es mucho mayor que el espacio de soluciones; aumento del costo de evaluación, ya que cada conjunto de métodos candidatos debe ejecutar tareas internas, generalmente dependiendo de la evaluación paralela por lotes en GPU para diluirlo; aumento de la complejidad de verificación, ya que si la mejora externa realmente generaliza requiere un diseño de verificación independiente.
Pistas de ejercicios y guía de respuestas
1. Comparado con los algoritmos evolutivos tradicionales, ¿cuál es la diferencia más esencial de la evolución de métodos en "el objeto optimizado"? La dirección correcta es: poner también en el objeto de búsqueda las estrategias, parámetros y componentes de operadores sobre "cómo producir respuestas". Si el estudiante elige "población más grande" o "eliminar la evaluación de aptitud", se le sugiere volver al desplazamiento del objeto de optimización: lo optimizado ya no es solo la respuesta, sino el mecanismo que produce respuestas.
Calidad de la solución, señales de preferencia, estabilidad o costo, retroalimentación proveniente del desempeño de las tareas internas. Si el estudiante elige erróneamente "ruido aleatorio" o "especificado manualmente por el ingeniero", se le guía a preguntar: ¿con qué fundamento juzga la capa externa que una estrategia es mejor que otra? Ese "con qué fundamento" es la señal de retroalimentación.
Dejar que la señal de preferencia participe en la retroalimentación de la capa superior, pero tratar "evaluar la respuesta actual" e "mejorar el método de generación" como dos tipos de objetivos por separado. Si el estudiante toma la preferencia de respuestas directamente como calidad del método, recordarle: la preferencia debe pasar por agregación entre tareas y verificación de estabilidad para ascender de "preferencia de respuestas" a "criterio de método".
Expansión del espacio de métodos, cada conjunto de métodos paga el costo de evaluación interna, y la dificultad de verificación aumenta. Se puede resumir como triple presión: espacio, cómputo y verificación; la evolución de métodos eleva una capa el objeto de búsqueda, y el costo también sube.
5. ¿Cuál es precisa sobre MetaDE y AutoPSO? La dirección correcta es: MetaDE usa la capa externa para evolucionar las estrategias de mutación y los parámetros de la evolución diferencial, y la capa interna sigue encargándose de la solución de candidatos para tareas específicas. AutoPSO y EvoGO avanzan aún más hacia la combinación de componentes y la mejora a nivel estructural, en la dirección de pasar de cambiar parámetros a cambiar estructura.
Tratamiento del caso
El escenario es un equipo que optimiza el diseño de chips en un clúster de GPU; ya tienen un solucionador de evolución diferencial, pero las estrategias de mutación y los parámetros dependen de la experiencia manual, con fluctuaciones de rendimiento evidentes; planean introducir una optimización de doble capa tipo MetaDE y usar preferencias del usuario para guiar la búsqueda.
La entrada de la capa interna es el método actual (estrategias de mutación y configuración de parámetros) y una instancia concreta del problema de diseño, y la salida son los diseños candidatos y su calidad de solución. La entrada de la capa externa son las estadísticas agregadas del desempeño de las tareas internas, y la salida es la estrategia y configuración de parámetros actualizadas. La señal de retroalimentación debe agregarse entre tareas y entre ejecuciones repetidas, por ejemplo promedio multi-tarea, cuantiles o indicadores de estabilidad, y no puede tomarse de una sola ejecución. La razón es que la calidad de una sola solución depende en gran medida de la instancia concreta y la aleatoriedad; mide "si esta respuesta es buena", no "si este método es bueno"; usar directamente el resultado de una sola ejecución para impulsar la capa externa hace que la capa externa sea dominada por las diferencias entre instancias y el ruido.
La capa interna puede usar una función de evaluación ponderada por preferencias para filtrar diseños candidatos; la capa externa primero debe transformarlo en un criterio de comparación estable entre tareas, por ejemplo la puntuación ponderada de longitud de cable e indicadores de congestión y su varianza, y luego usarlo para elegir la configuración del método, evitando tomar una preferencia de respuesta puntual directamente como calidad del método.
La expansión del espacio de búsqueda puede controlarse con agrupación de parámetros, búsqueda jerárquica y de grueso a fino; el aumento del costo de evaluación puede reducirse con evaluación paralela por lotes en GPU, evaluación proxy con pocas muestras y mecanismos de parada temprana; el aumento de la complejidad de verificación requiere retener conjuntos de tareas de verificación independientes y ejecuciones repetidas, comprobando si la mejora externa realmente generaliza.
Verificación de comprensión y transición
La capa interna busca respuestas, la capa externa cambia métodos. Ver "estrategias, parámetros, operadores, componentes puestos en la búsqueda" es evolución de métodos; ver "solo cambian las soluciones candidatas, las reglas de generación nunca cambian" es un algoritmo evolutivo tradicional. Tras confirmar que los estudiantes pueden explicar "el objeto optimizado ha cambiado" y "la preferencia no puede disfrazar directamente la calidad del método", continuar con los ejemplos, aplicaciones o resumen de la siguiente página.
### MetaDE y AutoPSO: Arquitectura de Doble Capa para la Evolución de Métodos
*Página 7*
> **Objetivo de la página:** Dominar cómo MetaDE y AutoPSO logran la evolución automática de variantes de algoritmos y parámetros mediante optimización de doble capa interna y externa.
> **Objetivo de la página**
>
> Comprender cómo MetaDE y AutoPSO logran la evolución automática de configuraciones y estructuras de algoritmos mediante arquitecturas de optimización de doble capa interna y externa, y dominar su estructura de costos y equilibrio de ingeniería.
> **Orden de explicación**
>
> El algoritmo ya no solo busca soluciones, sino que también mejora "cómo se buscan las soluciones".
>
> 2. Mostrar la abstracción general de la arquitectura de doble capa interna y externa, enfatizando que la capa externa busca el espacio de algoritmos, la capa interna resuelve la tarea objetivo, y el desempeño interno se retorna como señal de aptitud, formando un circuito cerrado.
>
> 3. Explicar por separado las dos rutas de implementación de MetaDE y AutoPSO, señalando que la primera gestiona la capa de configuración y la segunda la capa de estructura/componentes.
>
> 4. Analizar el efecto multiplicador del costo de la optimización de doble capa, introduciendo compromisos de ingeniería como asignación de presupuesto, evaluación aproximada, parada temprana y paralelización.
>
> Pasar del diseño manual de un solo algoritmo al diseño de un espacio de algoritmos evolucionable y un mecanismo de evaluación.
**Puntos clave de la enseñanza**
- La evolución de métodos (Meta-Evolution) toma como objeto de optimización el "método que produce candidatos". La capa externa busca configuraciones de algoritmos, combinaciones de componentes o estrategias, no soluciones de tareas. La capa externa se encarga de buscar el espacio de algoritmos (hiperparámetros, estrategias, combinaciones de componentes y otras "definiciones del algoritmo").
- La capa interna usa el algoritmo candidato para resolver realmente la tarea objetivo, obteniendo un desempeño medible.
- El desempeño interno se agrega como aptitud y se retorna a la capa externa; la capa externa elimina configuraciones de baja calidad, retiene y muta configuraciones de alta calidad, formando un circuito de mejora continua. Se retiene la evolución diferencial como solucionador interno, y se entrega la configuración propia de DE a la búsqueda externa: estrategias de mutación, tasa de cruce, factor de escala, etc., se ajustan adaptativamente según el problema y la etapa de optimización. Responde a "cómo debe configurarse este conjunto de configuraciones en la etapa actual de la tarea", perteneciendo a la evolución de métodos a nivel de configuración. Se consideran los parámetros centrales y los mecanismos de aprendizaje de PSO como componentes combinables: peso de inercia, factores de aprendizaje y diferentes combinaciones de mecanismos de aprendizaje individual y grupal, buscados y combinados automáticamente por la capa externa para producir variantes de PSO adaptadas a diferentes problemas. Transforma "elegir algoritmo" en "buscar estructura de algoritmo", logrando el salto de la adaptación de parámetros a la autogeneración de mecanismos. MetaDE se inclina por el ajuste automático de configuración y capa de hiperparámetros; AutoPSO se inclina por la combinación automática de estructura y capa de componentes; juntos cubren el rango de evolución desde la adaptación de parámetros hasta la autogeneración de mecanismos. El costo clave de la optimización de doble capa radica en el efecto multiplicador: cada evaluación externa de un algoritmo candidato a menudo requiere múltiples ejecuciones internas (evaluación repetida por aleatoriedad, verificación conjunta multi-tarea, etc.), y el presupuesto computacional se amplifica significativamente. El cálculo real es aproximadamente igual a "número de algoritmos candidatos externos × número de ejecuciones internas por candidato". Asignación de presupuesto, evaluación aproximada, parada temprana, paralelización. La ejecución eficiente depende de tensorización paralela, programación del Runtime y composibilidad de algoritmos.
- La paralelización puede aliviar el tiempo de reloj, pero no reduce el cómputo total. Lo que el investigador entrega ya no es un algoritmo fijo, sino un espacio de búsqueda y reglas de retroalimentación que permiten que el algoritmo se mejore continuamente a sí mismo.
**Verificación de comprensión**
Se puede preguntar secuencialmente y dar los puntos clave de las respuestas:
1. ¿Cuál es el objeto directo de la búsqueda de la capa externa?
La configuración, estructura y combinación de componentes del propio algoritmo. La esencia de la evolución de métodos es tomar el propio algoritmo como objeto optimizado; la capa externa busca configuraciones y estructuras en el espacio de algoritmos, en lugar de buscar directamente soluciones de tareas. Distinguir las dos capas: la que busca directamente soluciones es la capa interna; la capa externa busca "qué algoritmo usar y cómo configurarlo".
2. ¿Qué grupo de objetos evoluciona principalmente la capa externa en MetaDE?
Las estrategias de mutación, la tasa de cruce y el factor de escala de la evolución diferencial. MetaDE permite que la configuración de DE se ajuste adaptativamente según el problema y la etapa, perteneciendo a la evolución de métodos a nivel de configuración/hiperparámetros, y no a la estructura de otros algoritmos.
3. ¿Qué descripción es más precisa sobre la división del trabajo entre AutoPSO y MetaDE?
AutoPSO se enfoca en la combinación automática de parámetros y mecanismos de aprendizaje, convirtiendo "elegir algoritmo" en "buscar estructura de algoritmo"; MetaDE se enfoca en la evolución a nivel de configuración. Ambos son complementarios: MetaDE cubre la capa de configuración e hiperparámetros, AutoPSO cubre la capa de estructura y componentes, y juntos constituyen el rango de evolución desde la adaptación de parámetros hasta la autogeneración de mecanismos, y ambos deben pasar por evaluación interna.
4. ¿Qué es correcto sobre la estructura de costos de la optimización de doble capa?
Cada evaluación externa de un algoritmo candidato a menudo requiere múltiples ejecuciones internas, y el presupuesto se amplifica significativamente, requiriendo asignación de presupuesto, evaluación aproximada o parada temprana. El costo principal de la arquitectura de doble capa es el efecto multiplicador; la paralelización solo puede aliviar, no eliminar, el costo total.
5. Tras adoptar la arquitectura de doble capa de evolución de métodos, ¿cuál es el cambio cognitivo del rol del investigador?
Pasar del diseño manual de un solo algoritmo al diseño del espacio y mecanismo de evaluación por el cual el algoritmo puede ser evolucionado. Lo que se entrega ya no es un algoritmo fijo, sino "un espacio de algoritmos evolucionable + reglas de evaluación de aptitud"; la búsqueda externa y la solución interna forman así un circuito de mejora continua. Aunque ya no se fija manualmente un solo algoritmo, el trabajo central se convierte en diseñar el espacio de búsqueda y el mecanismo de evaluación, y la responsabilidad es incluso mayor.
**Tratamiento de ejercicios**
El caso "construir un servicio de evolución de doble capa para tareas en cambio continuo" puede usarse después de explicar la arquitectura y los costos, pidiendo a los estudiantes que respondan primero individualmente y luego discutan en grupo.
Explicar qué se encargan respectivamente la capa interna y la externa, y cómo fluyen las señales.
La capa externa busca algoritmos candidatos en el espacio de algoritmos: puede evolucionar las estrategias de mutación, la tasa de cruce y el factor de escala de DE (ruta MetaDE), o combinar automáticamente componentes como el peso de inercia, los factores de aprendizaje y los mecanismos de aprendizaje de PSO (ruta AutoPSO). La capa interna ejecuta y evalúa cada algoritmo candidato en la tarea objetivo del día, produciendo un desempeño comparable; el desempeño interno se agrega como aptitud y se retorna a la capa externa, que a partir de ello elimina candidatos de baja calidad, retiene y muta configuraciones de alta calidad, iterando continuamente, formando el circuito "la capa externa busca el espacio de algoritmos, la capa interna resuelve la tarea objetivo, el desempeño retroalimenta la mejora".
Frente a la presión de presupuesto de que "una evaluación externa requiere múltiples ejecuciones internas", dar al menos dos medidas de compromiso y explicar el costo o riesgo.
① Asignación de presupuesto — establecer cuotas de cómputo separadas para la capa externa e interna y limitar las repeticiones internas, con el costo de mayor varianza de evaluación y posible mala elección; ② Evaluación aproximada — estimar la aptitud con subconjuntos de datos o ejecuciones cortas, con el costo de señal ruidosa y posible subestimación del mejor candidato; ③ Parada temprana — terminar anticipadamente las ejecuciones internas de candidatos claramente de baja calidad, con el costo de eliminar prematuramente configuraciones de maduración lenta que rinden bien después; ④ Tensorización paralela y programación del Runtime — ejecutar internamente en lote y concurrentemente, lo que alivia significativamente el tiempo de reloj, pero no reduce el cómputo total y está limitado por la memoria de video y el costo de programación. La respuesta debe explicar la correspondencia entre cada medida y su costo o riesgo, y reflejar la estimación multiplicativa "escala de búsqueda externa × número de ejecuciones internas por vez".
Lenguaje de retroalimentación:
Correcto. Esta respuesta puede conectar con los conceptos de esta página y explicar sus fundamentos.
Por favor, vuelve a la explicación de esta página, encuentra la evidencia o el ejemplo clave y luego juzga.
Presta atención a distinguir las "capas": la que busca directamente soluciones es la capa interna; la capa externa busca "qué algoritmo usar y cómo configurarlo"; el objeto de MetaDE es la configuración de la propia evolución diferencial, no la estructura de otros algoritmos; el costo principal de la arquitectura de doble capa es el efecto multiplicador; la paralelización solo puede aliviar, no eliminar, el costo total; aunque ya no se fija manualmente un solo algoritmo, el trabajo central del investigador se convierte en diseñar el espacio de búsqueda y el mecanismo de evaluación, y la responsabilidad es incluso mayor.
> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden distinguir con sus propias palabras "evolución de la capa de configuración" y "evolución de la capa de estructura/componentes", y pueden expresar el circuito de señales interna y externa y el efecto multiplicador del presupuesto, continuar con los ejemplos, aplicaciones o resumen de la siguiente página.
### Caso Práctico Multiobjetivo: Diseño de Perfiles Alares Supercríticos
*Página 8*
> **Objetivo de la página:** Aprender cómo utilizar EvoX para manejar restricciones de ingeniería complejas y generar soluciones de equilibrio diversificadas en el diseño de perfiles alares.
> **Objetivo de la página**
>
> Comprender por qué el diseño de perfiles alares supercríticos es un problema multiobjetivo, y dominar cómo utilizar EvoX para generar soluciones de equilibrio diversificadas bajo estrictas restricciones de ingeniería.
> **Orden de explicación**
>
> El diseño de perfiles alares supercríticos es una práctica multiobjetivo de EvoX en ingeniería real. Los parámetros de forma del perfil alar, como la curvatura, el espesor y el borde de salida, están acoplados entre sí; cambiar la forma afecta simultáneamente múltiples indicadores aerodinámicos.
>
> Mejorar un indicador a menudo tiene como costo otro indicador, por lo que no puede tratarse como una optimización de objetivo único; se requiere equilibrio multiobjetivo.
>
> Requisitos como sustentación, ángulo de ataque y espesor delimitan el dominio de diseño factible; la búsqueda debe desarrollarse bajo el cumplimiento de restricciones para garantizar que las soluciones candidatas sean utilizables en ingeniería.
>
> EvoX genera un conjunto diversificado de soluciones candidatas que equilibran los distintos indicadores, en lugar de una única solución óptima; el conjunto de candidatos permite a los expertos de dominio comparar diferentes beneficios y costos y tomar decisiones.
>
> Este caso transforma un problema complejo real en un proceso explorable y evaluable, buscando soluciones de equilibrio interpretables entre restricciones y conflictos de objetivos.
**Puntos clave de la enseñanza**
- Los cambios de forma del perfil alar supercrítico afectan múltiples indicadores aerodinámicos; los objetivos a menudo entran en conflicto, requiriendo equilibrio multiobjetivo. El diseño debe cumplir múltiples restricciones estrictas como sustentación, ángulo de ataque y espesor; la búsqueda debe desarrollarse dentro del dominio de diseño factible. Generar soluciones candidatas diversificadas ayuda a los expertos a evaluar diferentes beneficios y costos y tomar decisiones. Primero explorar continuamente en el espacio de parámetros del perfil alar (curvatura, espesor, borde de salida), luego aproximarse al frente de equilibrio multiobjetivo (indicador A e indicador B), y finalmente formar el conjunto de soluciones candidatas. Perfil alar supercrítico, equilibrio multiobjetivo, dominio de diseño factible, conjunto de soluciones candidatas, EvoX.
> **Pistas de ejercicios**
>
> - La raíz del problema multiobjetivo, el papel de las restricciones, la salida práctica de EvoX, el significado de los candidatos diversificados, el valor del método. La comprensión correcta debe centrarse en: los parámetros de forma afectan simultáneamente múltiples indicadores, causando conflictos de objetivos.
> - Las restricciones delimitan el dominio de diseño factible.
> - La salida es un conjunto diversificado de soluciones candidatas.
> - Diferentes candidatos representan diferentes beneficios y costos.
> - El valor del método radica en transformar problemas complejos reales en procesos explorables y evaluables.
**Tratamiento de ejercicios**
Si el estudiante elige erróneamente "solo optimizar la sustentación" o "buscar la única solución óptima", se le sugiere volver al acoplamiento de parámetros de forma y al conflicto de objetivos.
Si el estudiante elige erróneamente "las restricciones pueden relajarse libremente" o "no tienen relación con la usabilidad en ingeniería", recordarle que las restricciones definen el dominio de diseño factible y no pueden relajarse libremente.
Si el estudiante elige erróneamente "perfil alar óptimo único" o "forma aleatoria", recordarle que la salida debe ser un conjunto diversificado de soluciones candidatas que equilibran los distintos indicadores.
Correcto, esta respuesta puede conectar con los conceptos de esta página y explicar sus fundamentos.
Por favor, vuelve a la explicación de esta página, encuentra la evidencia o el ejemplo clave y luego juzga.
**Actividad en clase**
Como los cambios de parámetros de forma afectan simultáneamente múltiples indicadores aerodinámicos, mejorar uno a menudo tiene como costo otro, requiriendo equilibrio multiobjetivo; las restricciones delimitan el dominio de diseño factible y garantizan que las soluciones candidatas sean utilizables en ingeniería.
**Verificación de comprensión**
Cómo EvoX, en el diseño de perfiles alares supercríticos, genera un conjunto diversificado de soluciones candidatas bajo estrictas restricciones, para que los expertos evalúen beneficios y costos. El docente complementa las palabras clave omitidas según la respuesta: conflicto de objetivos, dominio de diseño factible, conjunto de soluciones candidatas, equilibrio multiobjetivo.
> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden distinguir la optimización de objetivo único del equilibrio multiobjetivo, y pueden explicar el uso del conjunto de soluciones candidatas, continuar con los ejemplos, aplicaciones o resumen de la siguiente página.
### Desafíos a lo Largo del Ciclo de Vida: Agotamiento del Contexto y Persistencia a Nivel de Proyecto
*Página 9*
> **Objetivo de la página:** Comprender la contradicción entre las limitaciones de contexto de los grandes modelos y los proyectos de ingeniería reales que duran meses o años.
**Puntos clave de la enseñanza**
- El contexto de una sola sesión es un banco de trabajo; el repositorio del proyecto es la memoria a largo plazo. No dejar el estado de la población, las configuraciones fallidas y las razones de las decisiones solo en la ventana de sesión; antes de cerrar la sesión deben escribirse en artefactos a nivel de proyecto, y la siguiente sesión debe leerlos primero antes de continuar.
- La persistencia heredable requiere que los artefactos sean versionables, recuperables e interpretables: código, pruebas, registros de experimentos, registros de decisiones, métricas de evaluación y conclusiones de aceptación deben poder responder por qué se eligió así, qué ya falló y qué conflictos siguen abiertos.
- El Agente de capa superior descompone objetivos; el Agente de capa inferior implementa y prueba. Antes de terminar cada sesión se establece un punto de control: actualizar el registro de decisiones y las métricas de evaluación; al iniciar una nueva sesión, primero heredar el punto de control y luego decidir acciones locales, trascendiendo así múltiples ciclos de vida finitos.
> **Objetivo de la página**
>
> Comprender la contradicción entre las limitaciones de contexto de los Agentes de grandes modelos y los proyectos de ingeniería reales que duran meses o incluso años, y establecer la necesidad de la persistencia a nivel de proyecto. Juicio central: la ventana de contexto de una sola sesión C_máx es un recurso finito, y el ciclo de vida del proyecto T_proyecto puede durar meses o incluso años, por lo que T_proyecto ≫ C_máx. La verdadera dificultad no es la insuficiencia de la capacidad de razonamiento de una sola vez, sino que la experiencia no puede trascender el ciclo de vida del Agente.
>
> Orden de explicación
>
> El contexto de un solo Agente solo puede contener el objetivo actual, las observaciones locales y el razonamiento reciente; al cerrar la sesión el estado se borra, y las conclusiones temporales y la experiencia dejan de estar disponibles. Sin persistencia, las sesiones posteriores solo pueden repetir la exploración.
>
> Persistencia a nivel de proyecto. Externalizar las configuraciones fallidas, el proceso de equilibrio, las soluciones candidatas y las conclusiones de aceptación en artefactos a nivel de proyecto que existen continuamente, incluyendo código, pruebas, registros de experimentos, registros de decisiones, métricas de evaluación y conclusiones de aceptación. Los Agentes posteriores no necesitan empezar de cero, sino leer la experiencia previa y juzgar qué direcciones ya fueron verificadas, qué conflictos siguen sin resolverse y qué indicadores ya cumplieron.
>
> El objeto de evolución ya no es solo un parámetro numérico puntual o una solución candidata, sino un mundo del software que existe continuamente, es versionable y heredable. Los nuevos artefactos producidos en cada sesión cambian el estado de este mundo, y la siguiente sesión continúa evolucionando sobre el mundo actualizado, de modo que el proceso de optimización se convierte en evolución continua a nivel de proyecto.
>
> Múltiples Agentes con ciclos de vida finitos pueden trabajar en colaboración: el ejecutor de capa superior comprende el objetivo y descompone tareas, el ejecutor de capa inferior completa la implementación y prueba locales, y si es necesario continúa la descomposición recursiva. Antes de cerrar se escriben los estados clave; al iniciar un nuevo Agente, primero lee la memoria del proyecto y luego decide acciones locales.
>
> Los proyectos de largo ciclo a menudo tienen conflictos de objetivos, por ejemplo rendimiento, costo y robustez difíciles de optimizar simultáneamente; la retroalimentación también puede ser dispersa, con un experimento que tarda horas o incluso días. Los registros de decisiones y las métricas de evaluación persistentes pueden transformar la retroalimentación dispersa en experiencia heredable, evitando que los Agentes posteriores tropiecen repetidamente con la misma piedra.
>
> Puntos clave de la enseñanza
>
> El contexto de una sola sesión es un banco de trabajo; el repositorio del proyecto es la memoria a largo plazo. No dejar el estado de la población, las configuraciones fallidas y las razones de las decisiones solo en la ventana de sesión; antes de cerrar la sesión deben escribirse en artefactos a nivel de proyecto, y la siguiente sesión debe leerlos primero antes de continuar.
>
> La persistencia no es acumulación de registros. La persistencia heredable requiere que los artefactos sean versionables, recuperables e interpretables: código, pruebas, registros de experimentos, registros de decisiones, métricas de evaluación y conclusiones de aceptación deben poder responder por qué se eligió así, qué ya falló y qué conflictos siguen abiertos.
>
> Antes de terminar cada sesión se actualiza el registro de decisiones y las métricas de evaluación; al iniciar una nueva sesión se hereda primero el punto de control y luego se deciden las acciones locales, trascendiendo así múltiples ciclos de vida finitos.
>
> Evolución continua a nivel de proyecto, es decir, migrar el proceso de generar candidatos, evaluar candidatos, registrar equilibrios y conclusiones de aceptación desde el contexto de un solo Agente hacia artefactos persistentes a nivel de proyecto, haciendo que el proyecto itere continuamente a lo largo de múltiples ciclos de vida de Agentes.
>
> Pistas de ejercicios
>
> Debe elegirse "la ventana de contexto es finita, y al cerrar la sesión el estado y la experiencia no son confiables". Al retroalimentar, enfatizar: el límite duro está en la longitud finita y el borrado del estado al cerrar la sesión, no en la escala de parámetros, el grado de paralelismo o la función objetivo.
>
> Debe elegirse "código, pruebas, registros de experimentos, registros de decisiones, métricas de evaluación y conclusiones de aceptación". Al retroalimentar, explicar que estos artefactos constituyen conjuntamente la memoria del proyecto.
>
> Debe elegirse "expandirse de parámetros numéricos/soluciones candidatas puntuales a un mundo del software que existe continuamente, es versionable y heredable". Al retroalimentar, distinguir el cambio de paradigma de entrenamiento del cambio de límites del objeto de evolución.
>
> Debe elegirse "la capa superior comprende el objetivo y descompone tareas, la capa inferior completa la implementación y prueba locales, y si es necesario descompone recursivamente". Al retroalimentar, enfatizar que la continuidad a través del ciclo de vida está garantizada por la persistencia a nivel de proyecto.
>
> Debe elegirse "al cerrar cada sesión se pierden el estado de la población, las configuraciones fallidas y las razones de las decisiones, y los Agentes posteriores repiten la exploración". Al retroalimentar, explicar que la falta de persistencia no resuelve automáticamente los conflictos de objetivos ni amplía el contexto.
>
> Si es correcto, se puede elogiar "puede conectar con los conceptos de esta página y explicar sus fundamentos"; si es incorrecto, pedir al estudiante que vuelva a la explicación de esta página, encuentre la evidencia o el ejemplo clave y luego juzgue.
>
> Tratamiento de ejercicios
>
> El objetivo incluye eficiencia aerodinámica, resistencia estructural y costo de fabricación, los tres en conflicto; la retroalimentación de simulación es dispersa; el equipo espera que múltiples Agentes de ciclo de vida corto colaboren continuamente. La primera pregunta requiere explicar por qué la memoria del proyecto no puede colocarse solo en el contexto de una sola sesión, y enumerar al menos tres tipos de artefactos que deben persistirse. Puntos clave de la respuesta: la ventana de contexto de una sola sesión es finita y el estado se borra al cerrar la sesión, mientras que el proyecto abarca meses, T_proyecto ≫ C_máx; depender solo del contexto de una sola sesión pierde el estado de la población, los resultados de simulación, las configuraciones fallidas, los conflictos de indicadores y las razones de las decisiones; la persistencia debe incluir al menos scripts de código y entrenamiento de modelos proxy, registros de pruebas y métricas de evaluación, registros de experimentos y configuraciones fallidas, registros de decisiones y razones de equilibrio, soluciones candidatas y conclusiones de aceptación.
>
> Al iniciar la sesión, primero leer el registro de decisiones, las métricas de evaluación, los registros de experimentos y las soluciones candidatas, restaurando el estado de la población y los conflictos no resueltos; durante la sesión, escribir nuevos modelos proxy, resultados de simulación, evaluaciones de candidatos y análisis de equilibrio; antes de cerrar, actualizar el registro de decisiones, registrando las configuraciones fallidas de esta ronda, los conflictos de indicadores, las razones de descarte y las sugerencias para el siguiente paso, y enviarlo versionado; las sesiones posteriores heredan las configuraciones fallidas y las razones de las decisiones leyendo estos artefactos, evitando la exploración repetida.
**Verificación de comprensión**
Se pide a los estudiantes que resuman con sus propias palabras "por qué la memoria del proyecto no puede guardarse solo en el contexto de un solo Agente", y que mencionen al menos tres tipos de objetos de persistencia a nivel de proyecto. Sugerencia de transición: tras confirmar que los estudiantes pueden expresar la relación central de esta página — T_proyecto ≫ C_máx, la persistencia a nivel de proyecto externaliza la experiencia en un mundo del software heredable — continuar con los ejemplos, aplicaciones o resumen de la siguiente página.
### La Arquitectura Genesis y el Paradigma de Sedimentación del Mundo del Software
*Página 10*
> **Objetivo de la página:** Dominar cómo Genesis permite que el código del proyecto se acumule y evolucione continuamente a lo largo del ciclo de vida.
> **Objetivo de la página**
>
> Ayudar a los estudiantes a comprender cómo Genesis reancla la inteligencia desde el proceso de sesión volátil hacia un mundo del software acumulable, permitiendo que el código del proyecto y los resultados de ingeniería se acumulen, evolucionen y hereden continuamente a través de una sola ventana de contexto y un solo ciclo de vida.
> **Orden de explicación**
>
> Primero plantear el criterio "la sesión es volátil, el repositorio es la memoria a largo plazo", y luego desarrollar sucesivamente la diferencia esencial del paradigma de sedimentación, la división del trabajo de las cuatro categorías de activos sedimentables, la premisa de la estabilidad de interfaces, el circuito de sedimentación y el guardián de la aceptación, la herencia entre ciclos de vida, y finalmente señalar en una frase el límite de la división del trabajo entre EvoX y Genesis.
**Puntos clave de la enseñanza**
- 1. Para juzgar si un trabajo tiene valor de sedimentación, basta con una pregunta: ¿la siguiente persona puede reproducirlo sin venir a preguntar nada? Si no puede, aún no se ha convertido en un activo. Los flujos de trabajo conversacionales se evaporan al terminar el contexto, y la producción se queda en "esta sesión".
- El mundo del software, que tiene como medio el repositorio, las versiones y los artefactos, posee naturalmente acumulatividad. Genesis formaliza precisamente este medio como la capa de memoria a largo plazo del sistema evolutivo; lo que recuerda no son las conversaciones, sino los resultados de ingeniería verificados. El código gestiona "puede ejecutarse", el método gestiona "cómo elegir", el estado gestiona "dónde está", la evidencia gestiona "con qué fundamento creer". El código porta la capacidad ejecutable y es el proceso de solución que puede ejecutarse y reproducirse directamente.
- El método porta las decisiones de algoritmo y estrategia, por ejemplo la selección de configuración y el modo de combinación de componentes de la evolución de doble capa.
- El estado porta el contexto del proyecto y la memoria de ejecución, registrando el progreso actual, las restricciones y los límites conocidos.
- La evidencia porta los registros de experimentos y las conclusiones de aceptación, respondiendo por qué el resultado es confiable. Si falta uno de los cuatro, la sedimentación es irreproducible o no heredable: solo con código pero sin evidencia, la conclusión no puede ser creída.
- Solo con método pero sin estado, el heredero no sabe desde dónde continuar. Por lo tanto, las cuatro categorías de activos deben solidificarse en conjunto, y no dispersarse por separado. 3. La premisa de la sedimentación es la estabilidad de las interfaces. Solo cuando los límites de módulo y los contratos son relativamente estables, la nueva producción es un activo.
- De lo contrario, cada cambio arrastra la implementación circundante, y la sedimentación se convierte rápidamente en deuda de mantenimiento. Esto es condición mutua con el diseño de base abierta y desacoplada de Genesis: la interfaz estable permite que la sedimentación se herede de forma segura, y el desacoplamiento permite que la herencia no requiera reescribir la historia. Antes de sedimentar, primero solidificar el contrato suele ser más valioso que escribir varios documentos más. Exploración → producción → estricta aceptación → solidificación como activo → la siguiente ronda de evolución hereda directamente. La aceptación es el guardián de la sedimentación: la producción no verificada no entra en la capa de activos, evitando solidificar ruido, fenómenos accidentales y conclusiones erróneas como "experiencia" del proyecto. Sin guardián, el repositorio se vuelve cada vez más largo y menos confiable. 5. La clave de la herencia entre ciclos de vida es el desacoplamiento de los activos respecto de las instancias de ejecución concretas, de modo que nuevas sesiones, nuevos Agentes y nuevas tareas puedan restaurar el conocimiento a nivel de proyecto "leyendo el repositorio", sin depender de reproducir el historial de conversaciones. El costo de herencia baja de "volver a contar todo el proyecto" a "hacer checkout y cargar", y el conocimiento del proyecto ya no está limitado por la capacidad de una ventana de contexto. Genesis se encarga de "qué sedimentar, en qué forma sedimentarlo, cómo heredarlo".
- La colaboración multi-Agente y la descomposición recursiva de tareas se encargan de "cómo producir la producción".
- El mecanismo de aceptación y herencia histórica se encarga de "cómo se determina que la producción es confiable". Los tres superpuestos constituyen la capacidad completa de evolución continua a nivel de proyecto: si falta cualquier eslabón, el proyecto solo puede repetirse en el mismo lugar.
**Cobertura de palabras clave**
- Genesis, evolución continua a nivel de proyecto, arquitectura del sistema EvoX, código/método/estado/evidencia, guardián de la aceptación, herencia entre ciclos de vida. Esta página organiza el contenido con el "diagrama esquemático de la arquitectura de tres capas de Genesis y el circuito de sedimentación"; a la izquierda, de arriba hacia abajo, están la capa de activos (código·método·estado·evidencia), el mecanismo de sedimentación (versionado·puerta de aceptación·recuperación y herencia) y el EvoX Runtime (tensorización paralela·cómputo heterogéneo·módulos de algoritmo).
- A la derecha, el diagrama circular presenta el circuito de exploración, producción, aceptación, solidificación, reutilización y re-evolución, y anota "los activos se engrosan a medida que el ciclo de vida aumenta". La página también incluye tres avisos: no tomar la sesión como memoria, las cuatro categorías de activos son indispensables, y si las interfaces no son estables la sedimentación se convierte en deuda. Al explicar se puede usar este diagrama para guiar a los estudiantes a recitar el circuito siguiendo las flechas, y luego señalar que la aceptación está después de la producción y antes de la solidificación.
> **Pistas de ejercicios**
>
> - La página incluye cinco preguntas de opción múltiple y un caso. La pregunta 1 apunta al mundo del software acumulable (repositorio, versiones y artefactos). Si el estudiante elige erróneamente la ventana de contexto, se le sugiere volver al punto de partida "al cerrar la sesión no queda nada".
> - La pregunta 2 evalúa la correspondencia de responsabilidades de las cuatro categorías de activos; la opción correcta es que el código porta la capacidad ejecutable.
> - La pregunta 3 evalúa el límite entre activos y deuda de mantenimiento; la opción correcta es "los límites de módulo y los contratos son relativamente estables", enfatizando que la clave no está en cuánto se produce ni en cuán nuevas son las herramientas.
> - La pregunta 4 evalúa el guardián en el circuito; la opción correcta es la estricta aceptación.
> - La pregunta 5 evalúa la herencia entre ciclos de vida; la opción correcta es "los activos se desacoplan de las instancias de ejecución, y las nuevas sesiones pueden restaurar el conocimiento del proyecto leyendo el repositorio". Si acierta, elogiar que puede conectar con los conceptos de esta página y explicar sus fundamentos; si falla, pedirle que vuelva a la explicación, encuentre la evidencia o el ejemplo clave y luego juzgue. Tras terminar la exploración multiobjetivo de perfiles alares supercríticos, el equipo conserva la configuración de doble capa MetaDE ejecutable y los scripts de entrenamiento del modelo proxy, la definición de métricas de evaluación, el estado intermedio que cubre el intervalo de parámetros del perfil alar y las restricciones de condiciones geométricas, y las conclusiones de aceptación de esta ronda. La primera pregunta requiere organizar los activos en las cuatro categorías de código, método, estado y evidencia, y explicar el papel guardián de la aceptación — solo la producción que pasa la estricta aceptación puede entrar en la capa de activos; las cuatro categorías de activos deben solidificarse en conjunto, y si falta una, son irreproducibles o no heredables. La segunda pregunta requiere comparar "reproducir el historial de conversaciones" con "leer el repositorio": lo primero depende de la ventana de contexto, el costo crece linealmente con el proyecto, y una vez truncada la conversación el conocimiento se pierde.
> - Lo segundo reduce el costo de herencia a hacer checkout y cargar; los resultados son versionables, reproducibles y auditables, y el costo de prueba y error repetido de esta ronda se sedimenta así como punto de partida de reutilización de la siguiente ronda.
**Actividad en clase**
Se pide a los estudiantes que reciten el contenido de esta página con un ejemplo cercano a su propia experiencia, y que expliquen la relación entre ese ejemplo y el criterio "¿la siguiente persona puede reproducirlo sin venir a preguntarte?".
**Verificación de comprensión**
Se pide aleatoriamente a un estudiante que resuma con sus propias palabras los puntos clave de esta página; el docente complementa las palabras clave omitidas según la respuesta, confirmando especialmente que el estudiante puede expresar simultáneamente "la división del trabajo de las cuatro categorías de activos" y "la aceptación es el guardián de la sedimentación".
> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar la relación central de esta página — la sedimentación ocurre sobre contratos estables, es supervisada por la aceptación, y finalmente se hereda leyendo el repositorio — continuar con la aplicación o el resumen de la siguiente página.
### Patrón de Ingeniería de Colaboración Multi-Agente y Descomposición Recursiva de Tareas
*Página 11*
> **Objetivo de la página:** Comprender cómo múltiples Agentes con ciclos de vida finitos colaboran para completar el desarrollo y la descomposición de tareas de proyectos complejos.
**Puntos clave de la enseñanza**
- Al descomponer tareas, preguntar primero "¿qué cosa verificable debe entregar esta capa?", en lugar de pensar primero "¿a qué Agente se le entrega?". Una vez definidos claramente los entregables (conjuntos de datos, interfaces, puntos de control, informes de evaluación), los límites de responsabilidad y la división jerárquica emergen naturalmente.
- El punto de parada de la descomposición recursiva no es "descomponer hasta lo mínimo", sino "descomponer hasta que sea ejecutable, verificable y pueda completarse en circuito cerrado dentro de un contexto de un solo Agente". Descomponer demasiado superficial excede la capacidad de la capa inferior; descomponer demasiado profundo trae costos adicionales de coordinación y traspaso.
- La superposición de responsabilidades hace que múltiples Agentes implementen repetidamente lo mismo y produzcan resultados mutuamente conflictivos. Solidificar los límites con definiciones de interfaz y criterios de aceptación claros, y acordar qué contenido puede decidir la capa inferior por sí misma y qué debe reportarse a la tarea padre para arbitraje.
Objetivo de la página
Cuando la capacidad de contexto y la capacidad de procesamiento de un solo ejecutor no bastan para soportar todo el objetivo de ingeniería, cómo degradar un problema grande en un conjunto de problemas pequeños entregables, y hacer que los resultados de colaboración de cada capa sean verificables y recuperables.
Orden de explicación
Primero plantear el tema con "degradar un problema grande en un conjunto de problemas pequeños entregables", luego desarrollar la estructura de tres capas, después explicar los motivos y las condiciones de terminación de la descomposición recursiva, y finalmente aterrizar en la relación de traspaso bidireccional del árbol de tareas y las tres sugerencias de ingeniería. Al explicar se puede acompañar con el diagrama señalando los nodos capa por capa hacia abajo, ayudando a los estudiantes a corresponder la división abstracta del trabajo con el árbol de tareas concreto.
Puntos clave de la enseñanza
1. Estructura de tres capas y sus responsabilidades respectivas. El ejecutor de capa superior se orienta al objetivo global, responde "qué hay que hacer", y produce subtareas delegables, condiciones de restricción y criterios de aceptación; el ejecutor de capa media recibe subtareas que aún son demasiado grandes y continúa la descomposición recursiva, convergiendo objetivos grandes y sueltos en una jerarquía de tareas estable; el ejecutor de capa inferior completa la implementación y prueba locales dentro del límite de responsabilidad, produciendo resultados verificables y entregándolos hacia arriba, formando un circuito local cerrado. En el diagrama, el Agente de capa superior divide los módulos de tarea A, B, C; el módulo B, por seguir siendo demasiado pesado, se descompone en subtareas B1, B2; los cuatro nodos hoja finalmente caen en la implementación y prueba locales de los Agentes de capa inferior.
La capa superior se sitúa en el nodo raíz; lo que produce son tareas delegables y criterios de aceptación, no la realización personal de la implementación.
2. Por qué es necesaria la descomposición recursiva. La ventana de contexto del ejecutor, las herramientas invocables y la escala de tareas procesables de una sola vez son finitas. Si un solo ejecutor mantiene a largo plazo todo el contexto del proyecto completo, el costo aumenta con la escala, y además es fácil que aparezcan deriva de objetivos, contaminación de estado y dilución de información clave. La descomposición recursiva dispersa esta presión entre las capas: cada ejecutor solo necesita comprender el objetivo y las restricciones de su propia capa; el objetivo complejo se degrada capa por capa en unidades de trabajo ejecutables y entregables, y la consistencia global se garantiza mediante la jerarquía de tareas.
Árbol de tareas y traspaso bidireccional. Las tareas padre e hijo constituyen un árbol de tareas recursivo. Hacia abajo fluye la delegación de tareas — objetivo, restricciones de límite y criterios de aceptación; hacia arriba fluye la recuperación de resultados — productos, evidencia de verificación y problemas aún no resueltos. Que la colaboración se establezca realmente depende de tres cosas: si la jerarquía de tareas es clara, si los límites de responsabilidad son mutuamente excluyentes, y si los productos de traspaso (definiciones de interfaz, conjuntos de datos, casos de prueba, puntos de control) están claramente acordados. Si falta cualquiera de ellas, múltiples ejecutores degeneran en trabajo repetido y resultados mutuamente conflictivos.
La profundidad de la descomposición, la granularidad de la delegación y la estrategia de recuperación de resultados también pueden evaluarse y ajustarse continuamente. Cuando retroalimentaciones como el retrabajo repetido de una subtarea afectan a su vez cómo se descompone la próxima vez, este flujo de colaboración entra en un ciclo de automejora.
5. Sugerencias de ingeniería. La condición de parada de la descomposición recursiva no es "descomponer hasta lo mínimo", sino "descomponer hasta que sea ejecutable, verificable y pueda completarse en circuito cerrado dentro de un contexto de un solo ejecutor". Descomponer demasiado superficial excede la capacidad de procesamiento de la capa inferior; descomponer demasiado profundo trae gran costo de coordinación y pérdida por traspaso. Se puede definir primero el entregable y luego decidir quién lo hace; los límites poco claros suelen ser el mayor costo de la colaboración.
Tratamiento de ejercicios
Esta página incluye un conjunto de preguntas de juicio conceptual; se sugiere pedir a los estudiantes que indiquen sus fundamentos después de responder, en lugar de solo decir la opción.
La respuesta correcta es "comprender el objetivo global y descomponerlo en subtareas delegables y criterios de aceptación". Si el estudiante elige mal, se le sugiere volver a la posición del nodo raíz — lo que produce son tareas y criterios de aceptación, no el código en sí.
La respuesta correcta es "cuando la subtarea sigue siendo demasiado compleja y excede el alcance de procesamiento de una sola vez". Enfatizar que la recursión no es una acción incondicional; la condición de activación es que la subtarea siga siendo demasiado grande y no pueda completarse y verificarse en un solo procesamiento.
¿Qué pasaría si solo hubiera envío de tareas? ¿Y si solo hubiera recuperación de resultados? Con esto explicar que la colaboración debe ser bidireccional.
La respuesta correcta es "dispersar la presión de contexto y procesamiento entre las capas, reduciendo la carga de contexto de un solo punto y el riesgo de deriva de objetivos". La palabra clave es "dispersar", no "garantizar el éxito de una sola vez".
La respuesta correcta es "hacer que los nodos hoja retengan unidades de trabajo ejecutables y entregables, y definir claramente las interfaces y la producción de pruebas". Se puede repasar de paso: límites difusos o eliminación de jerarquías conducen a implementación repetida y conflictos de resultados.
Actividad en clase
El estudio de caso "entrega colaborativa del sistema de control de calidad de servicio al cliente inteligente" es adecuado como actividad grupal. Primero pedir a los estudiantes que dibujen el árbol de tareas recursivo: el nodo raíz se encarga de la comprensión del objetivo global y produce las tres subtareas A, B, C y sus criterios de aceptación; el módulo B es descompuesto por la capa media en B1, B2, definiendo la interfaz entre ambos; los nodos hoja son las cuatro categorías de unidades de trabajo A, B1, B2, C. Luego pedir a cada grupo que enumere los productos de traspaso en las dos direcciones, descendente y ascendente, por ejemplo especificación de interfaz de datos y conjunto de datos de diálogo limpio, diccionario de características y normas de etiquetado, punto de control del modelo e informe de verificación, métricas de evaluación y configuración de despliegue, y que expliquen por qué los nodos hoja ya cumplen la condición de parada.
Ante la pregunta adicional de que B1 encuentra un conflicto entre "normas de etiquetado" y "métricas de evaluación", se puede guiar a los estudiantes a resumir los principios de tratamiento: el conflicto se eleva para arbitraje, no se modifican por cuenta propia los criterios de aceptación; las interfaces y estándares mantienen una única fuente, gestionada de manera unificada por la capa superior; antes del arbitraje se mantiene el circuito local cerrado verificable; el resultado del arbitraje actualiza inversamente el árbol de tareas y las entradas de las subtareas relacionadas; se registra todo el proceso de conflicto, fundamento del arbitraje y criterio final para su trazabilidad.
Verificación de comprensión
De qué se encarga la capa superior, bajo qué condiciones continúa la recursión, qué información transmiten las dos direcciones, ascendente y descendente. Si se pueden expresar simultáneamente la condición de parada y "primero definir el entregable y luego la división del trabajo", se considera que esta página se domina adecuadamente.
Sugerencia de transición
Tras confirmar que los estudiantes pueden distinguir "descomponer tareas" de "implementar personalmente", y pueden explicar claramente el traspaso bidireccional del árbol de tareas, continuar con la siguiente página sobre el mecanismo de verificación y sedimentación, para conectar el patrón de división del trabajo de esta página con los eslabones posteriores de compilación, prueba y aceptación.
### Mecanismo Estricto de Aceptación y Herencia Histórica
*Página 12*
> **Objetivo de la página:** Dominar cómo sedimentar las modificaciones efectivas en la historia del proyecto mediante compilación, pruebas y puertas de aceptación.
> **Orden de explicación**
>
> Primero señalar en una frase "al ver cualquier sistema de 'generación automática y mejora automática', preguntar primero tres cosas: ¿cuál es la identidad por defecto del producto del Agente (¿candidato?), qué verificaciones debe pasar para ser adoptado (¿aceptación?), y después de ser adoptado, base de quién se convierte (¿línea base?). Si se separan estas tres cosas, la lógica general del mecanismo no se desordena", y luego, combinando con los ejemplos, diagramas o palabras clave de la página, explicar por qué es importante.
**Puntos clave de la enseñanza**
- ¿Cuál es la identidad por defecto del producto del Agente (¿candidato?), qué verificaciones debe pasar para ser adoptado (¿aceptación?), y después de ser adoptado, base de quién se convierte (¿línea base?). Si se separan estas tres cosas, la lógica general del mecanismo no se desordena.
- Compilación → pruebas → verificación de comportamiento → aceptación de capa superior, es un camino cuesta abajo de "costo de bajo a alto": cuanto más barato, más adelante; cuanto más caro, más atrás. Recordar "primero filtrar lo barato, luego revisar lo costoso" evita desperdiciar la revisión de capa superior en una gran cantidad de candidatos basura.
- Pasar la aceptación no equivale a ser realmente mejor. Cuando la cobertura de pruebas es insuficiente o falta la verificación de comportamiento, la puerta deja pasar modificaciones dañinas. Cultivar dos hábitos: completar casos de regresión y definiciones de tolerancia para comportamientos clave.
- Mantener en todo momento métricas observables y muestreo manual, como última línea de defensa cuando el estándar es incompleto.
Mecanismo estricto de aceptación y herencia histórica
11
AI999
Genesis y la sedimentación del mundo del software
Las modificaciones generadas automáticamente por el Agente, ¿con qué fundamento pueden escribirse en la rama principal del proyecto? El mecanismo estricto de aceptación y herencia histórica desacopla completamente la generación de la adopción — cualquier código enviado por el Agente es solo una modificación candidata (candidate patch), y debe pasar primero un conjunto de puertas de verificación para tener derecho a ser reconocido como parte de la historia del proyecto.
Modificación candidata → cuatro capas de puertas de aceptación → rama principal / rechazo por bifurcación. Cola de modificaciones candidatas: envío del Agente · no confiable por defecto. Candidato A pendiente de verificación. Candidato B pendiente de verificación. Candidato C pendiente de verificación. Candidato D pendiente de verificación. ① Puerta de compilación: sintaxis e interfaces construibles · costo más bajo, eliminación más rápida. ② Puerta de pruebas: pruebas unitarias/de integración en verde · cubre contratos existentes. ③ Puerta de verificación de comportamiento: consistencia semántica · tolerancia numérica y equivalencia. ④ Aceptación de capa superior: rendimiento · aceleración · mantenibilidad. Rechazo · área de archivo de fallos · retener como muestras negativas y material de diagnóstico · almacenar aislado, sin contaminar la rama principal · el rechazo mismo es filtrado de ruido · evitar repetir la exploración de la misma vía muerta. Historial de versiones de la rama principal (acumulación monótona). Línea base v3 · heredable, trazable. Línea base v2. Línea base v1. Retroalimentación de herencia histórica: la línea base ya aceptada se convierte en el punto de partida de ejecución de los Agentes posteriores. Principio de candidatura por defecto: la salida del Agente se considera por defecto una entrada no confiable: está estrictamente aislada de las versiones ya aceptadas en permisos, almacenamiento y referencias; no puede leer ni escribir directamente la rama principal, ni puede ser tomada por otros módulos como dependencia estable.
El único propósito de este principio es erradicar "generación es igual a ingreso al repositorio". Solo después de pasar todas las puertas, la modificación candidata obtiene el mismo estatus que la rama principal. Filtrado progresivo de cuatro capas: costo creciente, fallar lo antes posible. Compilación: construible a nivel de sintaxis e interfaces. Costo más bajo, eliminación más rápida; primero dejar fuera las modificaciones obviamente inviables. Pruebas: pruebas unitarias y de integración aprobadas, cubriendo contratos existentes. Verificación de comportamiento: consistencia semántica y de comportamiento, incluyendo tolerancia numérica, equivalencia y comparación de regresión, específicamente para prevenir "pruebas aprobadas pero comportamiento desviado". Aceptación de capa superior: juicio final orientado a objetivos de tarea y restricciones de ingeniería, incluyendo juicios de rendimiento, aceleración y mantenibilidad.
Las puertas se ordenan de bajo a alto costo, de modo que la gran mayoría de las modificaciones inválidas se truncan en etapas baratas, dejando la costosa revisión de capa superior para unos pocos candidatos de alta calidad — esta es precisamente la economía de "fallar lo antes posible". El valor del rechazo y la herencia histórica: los intentos no exitosos no entran en la rama principal, pero pueden conservarse como archivo de fallos/muestras negativas, para diagnóstico, deduplicación y prevención de exploración repetida — el rechazo mismo es un filtrado de ruido. Y las modificaciones que pasan la aceptación se convierten en nuevas versiones de línea base; los ejecutores posteriores continúan evolucionando sobre esta base, formando una cadena evolutiva de acumulación monótona, en lugar de empezar de cero cada ronda. Como regla de fusión y contrato de calidad de la colaboración multi-Agente y la descomposición recursiva de tareas, la puerta de aceptación define "quién puede escribir en la historia", determinando así si el resultado de la colaboración converge o aumenta su entropía.
En escenarios de restricciones de corrección fuerte como la refactorización de compiladores y la actualización de software científico, este mecanismo demuestra una confiabilidad extremadamente alta y trae una aceleración de ejecución considerable. Límites de fallo: la completitud del propio criterio de aceptación se convierte en el nuevo cuello de botella: cuando la cobertura de pruebas es insuficiente o falta la verificación de comportamiento, la puerta deja pasar modificaciones "que pasan la aceptación pero son realmente dañinas". Por lo tanto, se necesita respaldar con métricas observables y muestreo manual, y reforzar continuamente los casos de regresión y las definiciones de tolerancia.
En el mecanismo de aceptación estricta, ¿cuál es la posición por defecto del código enviado por el Agente?
Un producto terminado cuya disponibilidad es determinada por el propio remitente.
Una versión formal que puede fusionarse directamente en la rama principal.
Una modificación candidata pendiente de verificación, estrictamente aislada de las versiones ya aceptadas en permisos, almacenamiento y referencias.
Un subproducto solo para registro en logs, que no participa en ningún flujo.
La candidatura por defecto considera la salida del Agente como entrada no confiable, estrictamente aislada de la rama principal, evitando institucionalmente "generación es igual a ingreso al repositorio".
La salida no verificada no debería tener el mismo estatus que las versiones ya aceptadas.
Correcto. Esta respuesta puede conectar con los conceptos de esta página y explicar sus fundamentos.
Por favor, vuelve a la explicación de esta página, encuentra la evidencia o el ejemplo clave y luego juzga.
¿En qué orden se disponen las cuatro capas de puertas de aceptación y cuál es la intención de su diseño?
De costo alto a bajo, priorizando invertir recursos en la revisión de capa superior más costosa.
Ordenadas por momento de envío de candidatos, primero en llegar primero en verificarse.
En orden aleatorio, para aumentar la diversidad de verificación.
Compilación → pruebas → verificación de comportamiento → aceptación de capa superior, haciendo que la gran mayoría de las modificaciones inválidas se trunquen en etapas baratas.
Las puertas baratas se encargan de la eliminación masiva, las costosas solo enfrentan unos pocos candidatos de alta calidad.
Pensar qué capa es la más costosa y cuál la más rápida. El orden de las puertas debe hacer que la revisión costosa se encuentre con la menor cantidad posible de candidatos basura.
¿Qué tipo de problema previene principalmente la verificación de comportamiento (tercera capa de puerta)?
Que se escriban muy pocos casos de prueba unitaria.
"Pruebas aprobadas pero comportamiento desviado", es decir, que la implementación nueva y la antigua sean inconsistentes en semántica o salida numérica.
Errores de sintaxis en el código que impiden la compilación.
Que el historial de versiones de la rama principal ocupe demasiado almacenamiento.
La verificación de comportamiento usa tolerancia numérica, equivalencia y comparación de regresión para comparar la consistencia semántica, interceptando desviaciones de comportamiento que las pruebas no cubren.
La capa de compilación gestiona "si puede construirse", la capa de pruebas gestiona "si se cumplen los contratos", y la verificación de comportamiento se enfoca en desviaciones semánticas más ocultas.
Las modificaciones candidatas rechazadas por las puertas, ¿cómo debe entenderse su valor?
Deben eliminarse por completo, para no ocupar almacenamiento e interferir con juicios posteriores.
Deben escribirse directamente en la rama principal, conservadas como contraste negativo.
Pueden conservarse como archivo de fallos/muestras negativas, para diagnóstico, deduplicación y prevención de exploración repetida.
Deben reenviarse repetidamente sin modificación hasta pasar automáticamente.
Los intentos fallidos se aíslan de la línea principal, pero aún pueden usarse como muestras negativas — el rechazo mismo es un filtrado de ruido.
La diferencia clave está en si se les permite contaminar la rama principal y si pueden transformarse en información de diagnóstico reutilizable.
¿Cuál de las siguientes situaciones es más probable que haga que la puerta de aceptación deje pasar modificaciones "que pasan la aceptación pero son realmente dañinas"?
Cobertura de pruebas insuficiente o falta de verificación de comportamiento, haciendo que el propio criterio de aceptación sea incompleto.
La aceptación de capa superior evalúa simultáneamente rendimiento, aceleración y mantenibilidad.
En la cola de modificaciones candidatas hay simultáneamente envíos de diferentes Agentes.
El archivo de fallos se conserva a largo plazo para diagnóstico.
La puerta solo puede detener los problemas que puede detectar; cuando el criterio de aceptación es incompleto, se necesita respaldar con métricas observables y muestreo manual.
El riesgo a menudo no viene del remitente, sino del punto ciego de cobertura del propio criterio de aceptación.
Aceptación de un parche de reescritura del núcleo del compilador
Lee el escenario y responde las siguientes dos preguntas.
Un equipo refactoriza el núcleo de un compilador con colaboración multi-Agente. El Agente X envía una versión del parche de reescritura del núcleo, afirmando que puede aumentar la velocidad de ejecución de cierto benchmark en aproximadamente 1.4 veces. El sistema procesa el parche según el "mecanismo estricto de aceptación y herencia histórica": el parche primero entra en la cola de modificaciones candidatas, y luego recibe sucesivamente compilación, pruebas, verificación de comportamiento y aceptación de capa superior; si pasa, se escribe de vuelta en la rama principal y se convierte en el punto de partida de la siguiente generación de Agentes; si no pasa, entra en el área aislada de archivo de fallos.
1. Explica en orden qué verificaciones debe pasar sucesivamente el parche, y por qué la aceptación de capa superior se coloca al final.
Compilación → pruebas → verificación de comportamiento → aceptación de capa superior. La compilación verifica si puede construirse a nivel de sintaxis e interfaces, con el costo más bajo y la eliminación más rápida; las pruebas verifican si las pruebas unitarias/de integración están todas en verde, cubriendo los contratos existentes; la verificación de comportamiento compara la consistencia semántica de la implementación nueva y antigua, incluyendo tolerancia numérica, equivalencia y comparación de regresión; la aceptación de capa superior realiza el juicio final orientado a objetivos de tarea y restricciones de ingeniería, juzgando rendimiento, aceleración y mantenibilidad. La aceptación de capa superior se coloca al final porque es la más costosa y requiere intervención manual o de revisión de alto nivel; solo después de que las primeras barreras truncan la gran mayoría de candidatos inválidos, este recurso costoso puede concentrarse en unos pocos candidatos de alta calidad, logrando "costo creciente, fallar lo antes posible".
En algunas entradas, las salidas numéricas de la implementación nueva y antigua exceden la tolerancia acordada. ¿Cómo debe manejarlo el sistema en este caso? ¿Sigue teniendo valor? ¿Qué pasaría si se eliminara la verificación de comportamiento?
El parche no debe escribirse en la rama principal; debe ser rechazado y transferido al área aislada de archivo de fallos; dado que pasó las etapas de compilación y pruebas, precisamente indica que pertenece al tipo peligroso de "pruebas aprobadas pero comportamiento desviado". Sigue teniendo valor: puede conservarse como muestra negativa, para diagnosticar el origen de las diferencias, evitar que los Agentes posteriores repitan la misma vía muerta, y sugerir al equipo complementar casos de regresión o revisar la definición de tolerancia. Si se eliminara la verificación de comportamiento, este tipo de parche entraría directamente en la aceptación de capa superior o incluso se escribiría de vuelta en la rama principal con las pruebas en verde, introduciendo desviaciones de comportamiento en la línea base histórica; este es precisamente el límite de fallo de este mecanismo — la puerta solo puede detener los problemas que puede detectar, por lo que se necesita respaldar con métricas observables y muestreo manual.
Candidato, aceptación, línea base
¿Cuál es la identidad por defecto del producto del Agente (¿candidato?), qué verificaciones debe pasar para ser adoptado (¿aceptación?), y después de ser adoptado, base de quién se convierte (¿línea base?). Si se separan estas tres cosas, la lógica general del mecanismo no se desordena.
Recordar el orden de las puertas como un camino cuesta abajo
Compilación → pruebas → verificación de comportamiento → aceptación de capa superior, es un camino cuesta abajo de "costo de bajo a alto": cuanto más barato, más adelante; cuanto más caro, más atrás. Recordar "primero filtrar lo barato, luego revisar lo costoso" evita desperdiciar la revisión de capa superior en una gran cantidad de candidatos basura.
La puerta solo puede detener los problemas que puede medir
Pasar la aceptación no equivale a ser realmente mejor. Cuando la cobertura de pruebas es insuficiente o falta la verificación de comportamiento, la puerta deja pasar modificaciones dañinas. Cultivar dos hábitos: completar casos de regresión y definiciones de tolerancia para comportamientos clave; mantener en todo momento métricas observables y muestreo manual, como última línea de defensa cuando el estándar es incompleto.
step-1
Dominar cómo sedimentar las modificaciones efectivas en la historia del proyecto mediante compilación, pruebas y puertas de aceptación.
lesson_6
lesson_6_slide_11
Del borrador de EvoClass
> **Objetivo de la página**
>
> Dominar el mecanismo de sedimentar las modificaciones efectivas en la historia del proyecto mediante compilación, pruebas y aceptación.
**Puntos clave de la enseñanza**
- Mecanismo estricto de aceptación y herencia histórica.
- El código enviado por el Agente es solo una modificación candidata; debe pasar compilación, pruebas, verificación de comportamiento y aceptación de capa superior para entrar en la versión de proyecto aceptada. Los intentos fallidos pueden rechazarse, y los resultados que pasan la verificación se convierten en la base histórica de los ejecutores posteriores. En la refactorización de compiladores y la actualización de software científico, este mecanismo muestra una confiabilidad extremadamente alta y una aceleración de ejecución considerable.
**Puntos clave de la enseñanza**
- Mecanismo estricto de aceptación y herencia histórica.
- El código enviado por el Agente es solo una modificación candidata; debe pasar compilación, pruebas, verificación de comportamiento y aceptación de capa superior para entrar en la versión de proyecto aceptada. Los intentos fallidos pueden rechazarse, y los resultados que pasan la verificación se convierten en la base histórica de los ejecutores posteriores. En la refactorización de compiladores y la actualización de software científico, este mecanismo muestra una confiabilidad extremadamente alta y una aceleración de ejecución considerable. Mecanismo estricto de aceptación y herencia histórica.
- El código enviado por el Agente es solo una modificación candidata; debe pasar compilación, pruebas, verificación de comportamiento y aceptación de capa superior para entrar en la versión de proyecto aceptada. lesson_id_distribution 86818163433546df25555ab4cb1c2d59fc1effedc37a25c4e84b74b7d294e704
**Base de materiales**
Del borrador de EvoClass
> **Pistas de material**
>
> - Dominar el mecanismo de sedimentar las modificaciones efectivas en la historia del proyecto mediante compilación, pruebas y aceptación.
> - Mecanismo estricto de aceptación y herencia histórica.
> - El código enviado por el Agente es solo una modificación candidata; debe pasar compilación, pruebas, verificación de comportamiento y aceptación de capa superior para entrar en la versión de proyecto aceptada. Los intentos fallidos pueden rechazarse, y los resultados que pasan la verificación se convierten en la base histórica de los ejecutores posteriores. En la refactorización de compiladores y la actualización de software científico, este mecanismo muestra una confiabilidad extremadamente alta y una aceleración de ejecución considerable.
> - El código enviado por el Agente es solo una modificación candidata; debe pasar compilación, pruebas, verificación de comportamiento y aceptación de capa superior para entrar en la versión de proyecto aceptada.
**Actividad en clase**
Se pide recitar el contenido de esta página con un ejemplo cercano a la experiencia de los estudiantes, y pedirles que expliquen la relación entre este ejemplo y "al ver cualquier sistema de 'generación automática y mejora automática', preguntar primero tres cosas: ¿cuál es la identidad por defecto del producto del Agente (¿candidato?), qué verificaciones debe pasar para ser adoptado (¿aceptación?), y después de ser adoptado, base de quién se convierte (¿línea base?). Si se separan estas tres cosas, la lógica general del mecanismo no se desordena".
> **Objetivos correspondientes**
>
> - Comprender el patrón de ingeniería de colaboración multi-Agente y descomposición recursiva de tareas.
> - Dominar el mecanismo de sedimentar las modificaciones efectivas en la historia del proyecto mediante compilación, pruebas y aceptación.
**Verificación de comprensión**
Se pide aleatoriamente a un estudiante que resuma con sus propias palabras los puntos clave de esta página; el docente complementa las palabras clave omitidas según la respuesta.
> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden expresar la relación central de esta página, continuar con los ejemplos, aplicaciones o resumen de la siguiente página.
### Actividad en Clase: Simulación de Colaboración Multi-Agente y Puerta de Aceptación Automatizada
*Página 13*
> **Objetivo de la página:** Profundizar la comprensión del desarrollo colaborativo multi-Agente y el mecanismo de aceptación automatizada mediante un ejercicio de simulación.
> **Objetivo de la página**
>
> Mediante un ejercicio de simulación en clase, comprender la división de tareas en el desarrollo colaborativo multi-Agente, la convergencia de modificaciones candidatas, y cómo la puerta de aceptación automatizada intercepta modificaciones no calificadas; el punto clave es recorrer el circuito de ingeniería "desarrollo colaborativo—aceptación automática—herencia histórica", no hacer que los Agentes discutan entre sí hasta obtener la respuesta correcta.
> **Orden de explicación**
>
> Dividir los grupos de clase en Agente de planificación/descomposición, Agente de implementación, Agente de generación de pruebas y Agente de revisión/coordinación. Una misma tarea puede producir múltiples modificaciones candidatas, que luego son arbitradas de manera unificada por la puerta de aceptación.
>
> Descomposición de tareas, implementación paralela, aceptación automática, herencia histórica. La descomposición de tareas debe dividir el objetivo en subtareas verificables independientemente, por ejemplo "verificación de interfaz — reparación de algoritmo — pruebas de regresión"; en la etapa de implementación paralela, múltiples Agentes de implementación envían parches candidatos, y el Agente de pruebas genera casos límite; en la etapa de aceptación automática se ejecutan pruebas automatizadas, verificación estática y verificación de contratos, y la puerta juzga según criterios ejecutables; en la etapa de herencia histórica, las modificaciones aprobadas se fusionan en la línea base histórica, y las rechazadas conservan las razones de fallo y la información de reproducción para reintentos.
>
> A la izquierda está la descomposición recursiva de tareas, en el medio las modificaciones candidatas multi-Agente, a la derecha las pruebas automatizadas y la puerta de aceptación. Tras converger, los candidatos entran en la puerta; si pasan, se fusionan en la línea base histórica; si se rechazan, se devuelven con retroalimentación reproducible, y la retroalimentación fluye de vuelta a las etapas de implementación y pruebas.
>
> Los criterios deben ser ejecutables, no pueden quedarse en "parece correcto". El enfoque está en interceptar modificaciones que no cumplen los acuerdos de interfaz, introducen regresiones, no cubren condiciones límite o violan restricciones de calidad. Una retroalimentación utilizable debe incluir al menos el caso de fallo, el log, los pasos de reproducción, el comportamiento esperado y las restricciones relacionadas.
>
> Las modificaciones aprobadas entran en la línea base, y los Agentes posteriores no necesitan empezar de cero; las modificaciones rechazadas se convierten en negativos recuperables, evitando repetir errores. Al evaluar, hay que prestar atención a si las reglas de aceptación son reproducibles, si la retroalimentación es accionable, y a los diferentes riesgos de intercepción errónea y omisión de intercepción.
>
> Si falta la puerta de aceptación o los estándares son vagos, la colaboración multi-Agente no necesariamente es más eficiente; por el contrario, puede volverse caótica por falta de arbitraje unificado; el valor de la puerta automatizada radica en reemplazar la aprobación subjetiva con evidencia reproducible.
**Puntos clave de la enseñanza**
- Antes de la aceptación, escribir primero pruebas ejecutables, aserciones de contrato y casos límite.
- Una regla que no puede reproducirse no puede interceptar de forma estable. Los candidatos rechazados deben incluir el log de fallo, el comando de reproducción, el comportamiento esperado y las restricciones relacionadas, para que el siguiente Agente pueda localizar y revisar directamente. Una granularidad de descomposición demasiado fina eleva el costo de fusión y aceptación; demasiado gruesa hace que las modificaciones candidatas se superpongan entre sí.
- Priorizar la descomposición en subtareas que puedan probarse y aceptarse por separado.
> **Pistas de material**
>
> - Descomposición recursiva de tareas, modificaciones candidatas multi-Agente, pruebas automatizadas y puerta de aceptación. En la figura también se señalan "convergencia de candidatos", "retorno de retroalimentación", "lo aprobado entra en la línea base, lo rechazado retorna retroalimentación reproducible", adecuado para explicar el circuito señalando la figura. Se puede pedir a los estudiantes que, en torno al caso "el servicio de pago se cae al recibir números negativos o cadenas demasiado largas", diseñen un conjunto de reglas ejecutables para la puerta de aceptación, cubriendo al menos interfaz, regresión, límites y restricciones de calidad. Dirección de referencia: la capa de interfaz requiere que el campo de monto rechace números negativos y cadenas demasiado largas, devuelva un código de error unificado y haga aserciones de contrato.
> - La capa de regresión requiere que los casos existentes de pago exitoso, reembolso y conciliación pasen todos y no haya nuevos fallos.
> - La capa de límites incluye casos de 0, números negativos, monto máximo permitido, cadenas demasiado largas, cadenas vacías y caracteres especiales, afirmando que no se cae y que el error es explicable.
> - Las restricciones de calidad incluyen verificación estática aprobada, cobertura de rutas clave no inferior al umbral acordado, y sin alertas de alto riesgo. Todas las reglas deben expresarse como pruebas o scripts ejecutables, y poder reproducirse en integración continua.
> **Pistas de ejercicios**
>
> - La intercepción errónea desperdicia el trabajo de candidatos correctos y reduce la eficiencia de colaboración, y puede inducir al equipo a relajar los estándares.
> - La omisión de intercepción hace que los defectos entren en la línea base histórica, y los Agentes posteriores continúan trabajando sobre una línea base errónea, amplificando el riesgo de regresión. Las formas de reducirlo incluyen conservar la evidencia de fallo, revisar por muestreo los resultados de intercepción, sedimentar los nuevos casos de fallo como conjunto de regresión, y controlar el riesgo con una combinación de casos límite, verificación de contratos y verificación en gris.
**Verificación de comprensión**
Se pide aleatoriamente a un estudiante que resuma con sus propias palabras los puntos clave de esta página, para ver si puede expresar los tres puntos clave: "estándares ejecutables", "retroalimentación accionable" y "descomponer según límites verificables independientemente". Si puede dar ejemplos combinando con el caso del servicio de pago, se considera dominado; si solo responde "hacer que los Agentes discutan automáticamente", se le sugiere volver a los estándares de la puerta de aceptación y al flujo del circuito.
> **Sugerencia de transición**
>
> Tras confirmar que los estudiantes pueden explicar claramente la relación entre la colaboración multi-Agente, la aceptación automática y la herencia histórica, continuar con las aplicaciones, ejemplos o resumen de la siguiente página.
### Modo de Trabajo AI Native y Entradas de Acceso Convenientes
*Página 14*
> **Objetivo de la página:** Comprender cómo iniciar rápidamente experimentos con EvoX a través de entradas y configuraciones simples en herramientas de IA.
**Puntos clave de la enseñanza**
- Recordar esta línea de división del trabajo: la entrada AI Native se encarga de la instalación, la configuración básica y la verificación del entorno; tú te encargas de la definición del problema, la elección de dirección y los criterios de evaluación. Invertir el tiempo ahorrado en lo segundo hace que los beneficios realmente recaigan en la investigación; de lo contrario, solo se traslada la espera de la etapa de configuración a la etapa de retrabajo.
- El valor de una instrucción de una frase es permitirte entrar rápidamente en el experimento, no saltarte la verificación. Tras completar la instalación, confirmar activamente la versión, las dependencias y la visibilidad de la GPU; tomar el estado reportado por la herramienta como pista, no como conclusión, para que los experimentos posteriores tengan un punto de referencia confiable.
- Antes de reproducir en otra máquina, verificar punto por punto: si la lista de dependencias y versiones es consistente, si el modelo de GPU y el número de dispositivos disponibles son iguales, si la semilla aleatoria y los hiperparámetros clave están fijados. Tras pasar los tres puntos, ampliar la escala del experimento, evitando que el costo de diagnóstico posterior sea mucho mayor que el costo de configuración previo.
Objetivo de la página**
Qué cambia realmente el modo de trabajo AI Native, y dónde están sus límites. Después de aprender, se deben poder explicar tres puntos: la entrada de interacción pasa de consultar manualmente documentación, instalar dependencias, configurar el entorno y escribir scaffolding, a iniciar experimentos con una frase en una herramienta de IA; la instalación, la configuración básica y la verificación del entorno son asumidas por la herramienta, que reporta el estado; la definición del problema, la elección de dirección y los criterios de evaluación siguen siendo responsabilidad del investigador.
Puntos clave de la enseñanza**
1. La migración de la entrada es la característica definitoria. La ruta tradicional es "consultar documentación → instalar dependencias → configurar el entorno → escribir scaffolding → recién entonces hacer el primer experimento"; cada eslabón puede fallar, y cada cambio requiere restablecer el contexto. La ruta AI Native es "instrucción de una frase → la herramienta asume la instalación y configuración → verificación del entorno aprobada → entrar en el experimento". Lo que cambia es la forma en que la persona empieza a trabajar, no el objeto optimizado en sí.
2. La naturaleza de la fricción se transfiere, no desaparece. La verdadera carga a menudo no viene de cuán difícil es una operación individual, sino del cambio frecuente de contexto: el investigador debería estar enfocado en el modelado del problema, el diseño experimental y la interpretación de resultados, pero es interrumpido constantemente por conflictos de versiones, dependencias faltantes y rutas de entorno. La entrada conveniente transfiere toda la cadena de ingeniería, devolviendo la atención a la investigación misma.
Completar la instalación y configuración básica de EvoX dentro de una instrucción de una sola frase. Por ejemplo, ingresar "instala EvoX y completa la configuración básica", y la herramienta lo ejecuta y retroalimenta el resultado; el investigador entra inmediatamente en el experimento. Notar que esto es solo el punto de partida, no el final — el "configuración completada" reportado por la herramienta es un estado que debe verificarse, no una conclusión que pueda tomarse directamente.
4. Cuanto más corta la ruta, menor la distancia de la idea al experimento ejecutable; la idea puede verificarse el mismo día, y las hipótesis fallidas pueden descartarse rápidamente. Es especialmente evidente para temas de evolución de métodos que requieren construir repetidamente estructuras experimentales internas y externas: el tiempo puede dedicarse al diseño de estrategias, los criterios de evaluación y la atribución de resultados, en lugar de reparar el entorno repetidamente.
La entrada conveniente reduce el costo de inicio y configuración, pero no reemplaza el juicio del investigador sobre el valor del problema, la dirección de investigación y las métricas de evaluación. Leer "ahorrar tiempo" como "ahorrar juicio" es la desviación más común de esta página. El tiempo ahorrado solo rinde beneficios reales en la investigación si se invierte en la etapa de juicio; de lo contrario, solo se traslada la espera de la etapa de configuración a la etapa de retrabajo.
Pistas de material**
La fila superior gris son los cuatro pasos de la ruta tradicional, con la anotación "fricción concentrada" debajo; la fila media azul son los cuatro pasos de la ruta AI Native, entre ellos "instrucción de una frase" resaltada, con la anotación "fricción transferida" debajo; el bloque naranja de abajo es "límites de posicionamiento". Al explicar se puede preguntar directamente: ¿qué segmento se quitó en la figura, y qué segmento se quedó? Guiar a los estudiantes a descubrir — lo transferido es la instalación, la configuración básica y la verificación del entorno; lo conservado son el problema, la dirección y los criterios de evaluación.
Tratamiento de ejercicios**
Las cinco preguntas de opción múltiple adjuntas se sugieren tratar de forma concentrada después de la explicación, dando una frase de fundamento para cada pregunta, facilitando la autoevaluación de los estudiantes.
El juicio correcto es "la entrada de interacción por defecto pasa de consultar manualmente documentación, configurar el entorno y escribir scaffolding, a iniciar experimentos directamente con instrucciones simples en herramientas de IA". Si se elige estrategia de búsqueda, migración a la nube o reemplazo de estructura de red, indica que se confunde "cambio de entrada" con "cambio de algoritmo", y hay que volver a esta página para enfatizar: este punto describe cómo la persona empieza a trabajar.
El juicio correcto es "la herramienta completa la instalación, la configuración básica y la verificación del entorno dentro de una instrucción de una sola frase y reporta el estado, y el investigador entra en el experimento a partir de ello". Si se cree que la herramienta garantiza que ya no hay que verificar la versión y la visibilidad de la GPU, o que determina automáticamente las preguntas de investigación y las métricas de evaluación, indica que se amplió indebidamente el alcance — solo cubre el segmento de la cadena de ingeniería de instalación y configuración básica.
El juicio correcto es "reduce el costo de inicio y configuración, pero no reemplaza el juicio del investigador sobre la definición del problema, la dirección de investigación y los criterios de evaluación". Leer "ahorrar tiempo" como "ahorrar juicio", o creer que solo tiene valor para principiantes, requiere volver a la conclusión de límites para reposicionarse.
El juicio correcto es "el valor proviene de la transferencia de la fricción de ingeniería y el acortamiento del ciclo de iteración; la condición de validez es que el investigador aún pueda verificar los resultados de configuración y la reproducibilidad del experimento". Aquí hay que señalar la distinción entre "reducir operaciones manuales" y "reducir juicio manual".
La pregunta 5 es una proyección de consecuencias de no verificar; el juicio correcto es "el entorno no es reproducible, las diferencias entre experimentos son difíciles de localizar, y la estabilidad de los resultados no puede garantizarse". Al retroalimentar, señalar: el problema no está en el límite superior de capacidad de la herramienta, sino en la ausencia de la etapa de verificación; una configuración no verificada deja peligros ocultos para la reproducción posterior y la localización de fallos.
Actividad en clase**
La discusión del caso puede desarrollarse con "recorrer en tres días un experimento de evolución de métodos con EvoX". La primera pregunta requiere explicar qué costo se redujo y qué responsabilidad se conservó: lo reducido es el costo de fricción de ingeniería; lo conservado es la decisión de modelado del problema y la dirección, la determinación de los criterios de evaluación, y la verificación de la configuración. La segunda pregunta se enfoca en la reproducción en múltiples máquinas; se puede guiar a los estudiantes a dar al menos dos prácticas verificables: guardar la lista de versiones y dependencias realmente instaladas por la herramienta y compararla punto por punto entre máquinas; verificar el modelo de GPU, la memoria de video y el número de dispositivos visibles de cada máquina, fijando el número de dispositivo si es necesario; fijar la semilla aleatoria y el tamaño de lote y otras configuraciones clave, primero reejecutar la tarea de referencia bajo la misma configuración, confirmando que el resultado cae dentro del rango de fluctuación esperado, y luego ampliar la escala del experimento.
Verificación de comprensión**
"Si toda la instalación se entrega a la herramienta, ¿qué es lo que más necesitas confirmar manualmente al día siguiente?" Poder mencionar la verificación de versión, dependencias y visibilidad de la GPU se considera dominio.
Sugerencia de transición**
Tras confirmar que los estudiantes pueden expresar la línea de división "la herramienta se encarga de la preparación de ingeniería, el investigador del juicio de investigación", continuar con los ejemplos, aplicaciones o resumen de la siguiente página.
### El Gusto Central del Investigador: División del Trabajo Hombre-Máquina y Pensamiento Crítico
*Página 15*
> **Objetivo de la página:** Comprender el gusto científico insustituible y el juicio crítico del investigador en el proceso de evolución asistida por IA.
> **Objetivo de la página**
>
> Comprender el gusto científico insustituible y el juicio crítico del investigador en el proceso de evolución asistida por IA. La pregunta central es: cuando la IA reduce drásticamente el costo de "implementar respuestas", ¿hacia dónde se desplaza el valor de la investigación científica?
**Puntos clave de la enseñanza**
- La IA / EvoX puede completar rápidamente la implementación de código, la ejecución por lotes de experimentos, la generación de candidatos, la búsqueda de parámetros y el registro de retroalimentación; el costo de ingeniería ya no es el cuello de botella central. El investigador decide qué problema vale la pena investigar, qué resultado tiene significado, qué evidencia basta para sostener una conclusión. La IA expande la implementación y el espacio de búsqueda.
- El investigador controla la definición del problema, los conflictos de objetivos, los límites de restricciones y los criterios de aceptación. Tratar la salida de la IA como hipótesis pendiente de verificación, comprobando si la hipótesis se sostiene, si la evidencia es suficiente, si se consideran las condiciones límite, si se ignoran los resultados negativos, evitando ser engañado por respuestas fluidas pero no verificadas. Bajo exploración abierta y retroalimentación dispersa, la elección de dirección no puede externalizarse a la IA.
- El juicio final y la responsabilidad científica siguen siendo del investigador. A la izquierda está la IA / EvoX, correspondiente a generar candidatos, ejecutar experimentos, buscar espacio, registrar retroalimentación.
- A la derecha está el investigador, correspondiente a plantear preguntas, evaluar evidencia, sopesar compromisos, reflexionar sobre la dirección.
- En el medio está "Code is cheap. Taste matters". Abajo, "circuito de retroalimentación: punto de control crítico" señala que este no es un flujo unidireccional, sino un ciclo en el que la producción de la IA retroalimenta a la persona, y la persona redefine el problema y los estándares. En tareas de optimización multiobjetivo con EvoX, la IA genera rápidamente una gran cantidad de soluciones candidatas y código experimental. El investigador necesita juzgar: ¿la función objetivo refleja las necesidades reales? ¿La línea base es justa? ¿Las métricas omiten restricciones clave? Si solo se mira el puntaje, se puede elegir una solución que parece óptima pero no cumple las necesidades reales. Aquí se manifiesta "Code is cheap. Taste matters" en que: la IA se encarga de la implementación rápida y la búsqueda, el investigador examina la definición del problema y los criterios de evidencia, juzgando qué resultados tienen realmente significado.
**Tratamiento de ejercicios**
El gusto científico insustituible y el juicio crítico del investigador, y la división del trabajo en que la IA se encarga de la implementación y la persona del juicio. Las opciones incorrectas típicamente se caracterizan por saltarse conceptos, saltarse la memorización de materiales, concluir solo por intuición, o cambiar todos los factores a la vez para comparar resultados. La respuesta del caso en clase debe aterrizar en: tratar la salida de la IA como hipótesis pendiente de verificación, examinando la función objetivo, la línea base y las métricas; y al mismo tiempo dejar claro que la elección de dirección y la responsabilidad científica no pueden externalizarse.
**Verificación de comprensión**
Se pide a los estudiantes que distingan con sus propias palabras "costo de implementación" y "valor de juicio", y que den cada uno un ejemplo de un eslabón que puede entregarse a la IA y uno que debe ser responsabilidad del investigador. Si pueden explicar claramente la relación entre ambos, continuar con la siguiente página.
### Resumen del Curso: Construir la Infraestructura del Mundo del Software en Evolución Continua
*Página 16*
> **Objetivo de la página:** Resumir el contenido central de todo el curso, clarificando la visión de construir una infraestructura inteligente abierta, evolutiva y de sedimentación continua.
**Puntos clave de la enseñanza**
- Las soluciones candidatas, los métodos que producen candidatos (como las configuraciones interna y externa de MetaDE) y los activos a nivel de proyecto son tres niveles diferentes. Antes de diseñar o responder, aclarar primero "¿qué nivel estoy optimizando ahora?", lo que evita confundir la evolución de métodos con la evolución continua a nivel de proyecto.
- Solo los productos que pasan la estricta aceptación pueden entrar en la biblioteca de experiencia y ser heredados. Una vez que los resultados no aceptados son heredados por tareas posteriores, los errores se amplifican continuamente a lo largo de la cadena de herencia, y es muy difícil localizar la fuente.
- Al inicio de cada nueva tarea, preguntarse: ¿qué productos y entradas de experiencia ya verificados de la ronda anterior reutilicé directamente en esta ronda? Si la respuesta es vacía, significa que el flujo actual sigue siendo una tarea única, y no una infraestructura en evolución continua.
Objetivo de la página
Elevar la "evolución inteligente" de una búsqueda única y una optimización única a una infraestructura de software orientada al mundo real. El punto clave no es introducir un nuevo algoritmo, sino hacer que los estudiantes vean cómo el sistema trasciende una sola tarea y un solo Agente, manteniéndose abierto, confiable y continuamente conectado a problemas reales mediante el circuito "tarea—exploración—aceptación—herencia—re-evolución".
Puntos clave de la enseñanza
1. Actualización del objeto de evolución. Genesis expande el objeto de evolución desde la solución candidata de una sola tarea hacia la evolución continua a nivel de proyecto que atraviesa Agentes y ciclos de tareas. Al terminar una ejecución ya no se borra el estado; el fin de la tarea se convierte en el punto de partida de la siguiente ronda.
2. Paradigma de sedimentación de ingeniería. La aceptación estricta, la herencia histórica y la sedimentación de experiencia son tres elementos indispensables: la aceptación es la puerta, que decide qué tiene derecho a quedarse; la herencia es el canal, que decide si el sedimento puede realmente invocarse en la siguiente ronda; la sedimentación de experiencia permite que el sistema acumule estabilidad entre múltiples tareas. Escribir solo documentos e informes semanales no es sedimentación de ingeniería; los activos que pueden ejecutarse, heredarse y reutilizarse sí lo son.
3. Posicionamiento de EvoX. EvoX se sitúa en la base, proporcionando la base de cómputo, la ejecución paralela y la programación evolutiva, soportando hacia arriba la construcción de sistemas abiertos, componibles y de acumulación sostenible; no es un módulo que reemplaza las decisiones del Agente, ni un componente de visualización de resultados.
4. Visión final. El mundo del software no es un producto cerrado entregado de una vez, sino una infraestructura inteligente que evoluciona continuamente, se sedimenta continuamente y se conecta continuamente a problemas reales. Las palabras clave son evolución continua, sedimentación continua, conexión continua.
Pistas de material
Productos de aceptación (resultados por etapas que pasan la estricta aceptación), biblioteca de experiencia (estrategias reutilizables y lecciones de fallo estructuradas), herencia histórica (punto de partida directo de la siguiente ronda de tareas). El diagrama de capas a la izquierda se lee de abajo hacia arriba: EvoX Runtime, luego evolución continua a nivel de proyecto, luego colaboración multi-Agente, y finalmente conexión con problemas del mundo real, formando un circuito de evolución continua.
Formas organizativas implementables
Múltiples Agentes se encargan respectivamente de la búsqueda bibliográfica, la implementación de código y la reproducción de experimentos; cada exploración se escribe en el registro de experimentos; los resultados por etapas deben confirmarse conjuntamente con verificación humana y automática para entrar en la biblioteca compartida; la siguiente ronda de tareas parte directamente de los resultados confirmados. Así, el proyecto no es una colección de documentos "terminado y archivado", sino una línea de producción de tarea a exploración, acept