Auditar un fallo de orquestación

2069. Identidad de la lección

Módulo

5.3 — Orquestación de IA

Lección

3 — Auditar un fallo de orquestación

Tipo académico

Laboratorio de depuración

Tipo de esquema

Práctica

Orden

3 del módulo

Tiempo estimado

35–45 minutos

2070. Objetivo de aprendizaje

Después de esta lección, podrás rastrear una suposición incorrecta a través de una secuencia de agentes, identificar dónde la retroalimentación no logró corregirla y rediseñar la orquestación con comprobaciones explícitas de evidencia y un punto de control recuperable del estado del proyecto previo a cualquier edición.

2071. Por qué importa

Una cadena de agentes puede producir un resultado pulido mientras conserva la misma premisa incorrecta desde el primer paso. Añadir agentes no aumenta automáticamente la fiabilidad. En el desarrollo de juegos, una interpretación inicial equivocada sobre una mecánica, una interfaz o una restricción puede convertirse en arquitectura, implementación y evidencia de prueba que parecen coherentes entre sí. Auditar la cadena permite localizar la primera suposición no respaldada, en lugar de corregir únicamente el resultado final.

2072. Conocimientos previos

Debes haber completado 5.3 L2 — Construir una secuencia de cambios con intervención humana. Debes poder definir una tarea acotada, especificar condiciones de detención, exigir evidencia en los puntos de control y distinguir entre el cambio propuesto por un agente y la aprobación humana. También necesitas aplicar la práctica del curso de separar intención, restricciones, observaciones y resultados de verificación.

2073. Concepto central

La propagación de errores ocurre cuando un agente posterior trata una afirmación anterior como un hecho sin comprobarla por separado. Un bucle de retroalimentación solo es útil si puede observar el fallo relevante y devolver esa evidencia a la decisión que lo originó. Si cada agente posterior recibe únicamente la conclusión del agente anterior, la cadena puede aumentar la confianza sin aumentar la corrección.

Por eso, una auditoría de orquestación formula dos preguntas en cada transferencia:

1. ¿Qué afirmación se está transmitiendo?
2. ¿Qué evidencia podría refutarla o hacer que se revise?

La primera afirmación no respaldada es el objetivo principal de la auditoría. Una propuesta derivada de esa afirmación sigue siendo solo una propuesta: no constituye un estado recuperable del proyecto ni demuestra que la implementación funcione. Si más adelante se autoriza la implementación, crea y verifica antes de editar un punto de control con nombre que conserve el estado previo del proyecto y pueda restaurarse. Después, registra por separado los archivos realmente modificados, los resultados de validación y la decisión de revisión como evidencia posterior a la implementación. Los resultados incorrectos posteriores pueden ser consecuencias, no fallos independientes.

2074. Modelo mental

Utiliza la auditoría Afirmación → Evidencia → Decisión → Retroalimentación.

Aplica la tabla a la primera afirmación no respaldada. Después, rastrea cómo la heredó cada decisión posterior y señala qué evidencia podría haber detenido la cadena o hecho que se revisara esa afirmación.

2075. Ejemplo concreto

Imagina una cadena de cuatro pasos para diagnosticar un problema de interacción del jugador:

1. Agente A — Intérprete de requisitos: Concluye que la interacción debe activarse cuando el jugador entra en un volumen de detección.
2. Agente B — Planificador de implementación: Diseña una solución basada en ese volumen.
3. Agente C — Asistente de código: Produce un cambio que detecta la entrada en el volumen.
4. Agente D — Validador: Informa que el código está completo porque existen la función y el evento esperados.

La eficiencia aparente oculta una comprobación ausente. El requisito original podría describir una interacción basada en una acción deliberada del jugador, no en la proximidad pasiva. El Agente B nunca verifica la interpretación, el Agente C implementa la regla equivocada y el Agente D valida la estructura en lugar del comportamiento del jugador. Hay varias salidas, pero todas dependen de la misma afirmación no comprobada.

Un diseño más sólido introduce un límite después de la interpretación:

• El Agente A declara su interpretación y enumera los términos ambiguos.
• La persona confirma si la interacción depende de la proximidad o de una acción.
• El Agente B propone una implementación después de esa decisión.
• El Agente C identifica el comportamiento modificado y su superficie de prueba.
• El Agente D reproduce el comportamiento e informa de la evidencia, no solo de la presencia del código.

El rediseño no exige un agente en cada paso. Coloca la revisión humana y la evidencia de comportamiento donde pueden invalidar la suposición de mayor impacto.

2076. Flujo de trabajo nativo de IA

Usa la IA como auditora y como fuente de objeciones, no como autoridad final sobre la cadena.

1. Entrega al modelo un registro acotado de la orquestación que incluya la entrada, la salida, la decisión y la evidencia disponible de cada agente.
2. Pídele que extraiga cada afirmación factual y la clasifique como observada, inferida, solicitada o no verificada.
3. Pídele que identifique la primera afirmación no verificada que influyó en una decisión posterior.
4. Solicita dos comprobaciones que podrían refutarla. Descarta las comprobaciones que solo inspeccionen texto o código cuando la afirmación discutida se refiera al comportamiento del jugador.
5. Pide una secuencia revisada con una condición de detención, un paso que produzca evidencia, una decisión humana explícita y un punto de control de implementación recuperable.
6. Compara la propuesta del modelo con el registro. Conserva únicamente los controles que respondan al recorrido real del fallo; no añadas agentes solo para alargar la cadena.

Si la cadena se relaciona con un proyecto real, no permitas que el modelo edite el proyecto durante esta auditoría. Primero conserva el registro, identifica el límite del fallo y acuerda la secuencia revisada. Antes de cualquier implementación posterior, crea un punto de control identificado y recuperable del estado del proyecto previo a la implementación, y comprueba que pueda restaurarse antes de editar. Mantén el paquete de cambio acotado como una propuesta sin aplicar hasta que una persona lo apruebe; no confundas esa propuesta con el punto de control. Después de implementar, exige evidencia independiente asociada a ese pase: el registro real de archivos modificados, los hallazgos de la revisión y los resultados de las pruebas de comportamiento. Cualquier cambio posterior debe seguir la secuencia con intervención humana de la lección anterior y detenerse si el punto de control no puede restaurarse o si la evidencia no puede asociarse con el cambio aprobado.

2077. Error común

El error común es tratar una redacción diferente como una verificación independiente. Tres agentes pueden describir la misma suposición con palabras distintas y seguir dependiendo del mismo contexto heredado. La coincidencia entre salidas no es evidencia de corrección a menos que al menos un paso observe el artefacto relevante o reproduzca de manera independiente el comportamiento relevante.

2078. Práctica guiada

Audita el siguiente registro de orquestación. Supón que el resultado previsto es: el jugador puede abrir la puerta asegurada solo después de presentar el objeto de acceso requerido, y el estado de denegación sigue siendo claro cuando no posee el objeto.

• Agente 1 — Resumidor de tarea: «La puerta debe abrirse cuando el jugador se acerque al panel de seguridad».
• Agente 2 — Planificador: «Usa detección de proximidad cerca del panel y llama a la acción de abrir la puerta cuando el jugador entre en el área».
• Agente 3 — Implementador: Informa que añadió el evento de proximidad y la llamada para abrir la puerta.
• Agente 4 — Revisor: Comprueba que el evento está conectado y declara que el cambio está listo.
• Prueba de juego observada: La puerta se abre sin el objeto de acceso. El mensaje de denegación nunca aparece.

Completa estos pasos:

1. Escribe la primera afirmación no respaldada del registro.
2. Identifica la evidencia que usó cada agente y la evidencia que faltaba.
3. Señala la primera transferencia donde una condición de detención debería haber interrumpido la cadena.
4. Indica si el fallo es principalmente de interpretación, de implementación, de validación o una combinación. Justifica la elección.
5. Rediseña la secuencia en un máximo de seis pasos. Incluye una decisión humana, una comprobación de comportamiento, una condición de detención y un punto de control de implementación recuperable. Define un punto de control identificado del estado del proyecto previo a la implementación, créalo y comprueba su restauración antes de editar. Indica también la aprobación exacta que debe dar una persona para que comience la implementación. Mantén el paquete de cambio acotado como una propuesta separada y sin aplicar hasta recibir esa aprobación.
6. Asocia el pase de implementación resultante con el alcance aprobado, el registro real de archivos modificados, los hallazgos de la revisión y los resultados de las pruebas de comportamiento tanto para el caso permitido como para el denegado. Define la ruta de fallo: restaura primero el punto de control previo a la implementación; vuelve al límite de interpretación si se entendió mal la regla del objeto de acceso, al límite de planificación si el alcance o el diseño aprobados eran inadecuados, o al límite de implementación si el plan era correcto pero su ejecución falló. No permitas que otro agente continúe a partir de evidencia fallida.

Una respuesta sólida no culpará únicamente al Agente 3. Mostrará cómo la interpretación inicial omitió el requisito del objeto de acceso, cómo la revisión final comprobó las conexiones pero no el comportamiento previsto y cómo restaurar el punto de control evita que un pase de implementación fallido se convierta en una entrada aceptada para el paso siguiente.

Evalúa tu artefacto de auditoría con esta lista:

• Rastreo de afirmaciones: Cita o parafrasea la primera afirmación no respaldada y la vincula con las decisiones posteriores.
• Clasificación de evidencia: Distingue la información observada, inferida, solicitada y no verificada.
• Ubicación del control: Sitúa una condición de detención antes de que la interpretación no respaldada impulse la implementación.
• Recuperación: Identifica un punto de control previo a la implementación, confirma que se prueba su restauración antes de editar y define la acción de restauración.
• Autoridad: Identifica a la persona que aprueba la propuesta y decide si el flujo continúa.
• Verificación de comportamiento: Registra tanto el caso permitido como el denegado y dirige cada tipo de evidencia fallida al límite anterior que corresponda.

2079. Validación / evidencia

2080. Ideas clave

• Una cadena más larga puede amplificar un error cuando los pasos posteriores heredan afirmaciones no comprobadas.
• Suele ser más útil auditar la primera afirmación no respaldada que la última salida incorrecta.
• La retroalimentación debe producir evidencia capaz de cuestionar la decisión que se está revisando.
• Un punto de control de implementación recuperable limita el coste de una decisión equivocada y define cuándo la cadena debe volver a un límite anterior.
• La revisión humana debe situarse en los límites de ambigüedad de alto impacto, no automáticamente en cada paso.
• Una orquestación eficiente reduce la propagación no verificada; no maximiza el número de agentes.

2081. Siguiente lección

Este módulo ha terminado. A continuación, continúa con 5.4 — Gestión del contexto, donde administrarás la información que recibe, conserva y utiliza un sistema de IA durante una tarea de desarrollo más extensa.

2082. Comprobación