Aula de cursos

Objetivo. Evaluar una IA por la resistencia de sus resultados a pruebas, no por la calidad de su presentación.

Una demostración no es una validación

La IA puede generar una tabla, un gráfico o una pequeña aplicación. Ninguno demuestra automáticamente que el método sea correcto. La primera pregunta no es «¿funciona el botón?», sino «¿qué representa el cálculo y qué realidad omite?». En un simulador de cafetería, reducir el tiempo de caja y observar un aumento de «capacidad total» puede ser correcto bajo un modelo de estaciones en serie con determinada dotación; no es universal. Si la barra sigue saturada, la fila podría simplemente trasladarse a otro lugar.

Seis controles para un artefacto generado

1. Variables: ¿están definidas con unidades y periodos?
2. Alcance: ¿representa pedidos, clientes, productos o etapas? No son lo mismo.
3. Supuestos: ¿se consideran simultaneidad, personal y llegada de demanda?
4. Pruebas límite: ¿qué sucede con cero clientes, una avalancha de pedidos o una estación fuera de servicio?
5. Equidad: ¿se analiza el promedio, pero también la espera máxima o del percentil 90?
6. Reproducibilidad: ¿puedes contrastar el cálculo con un ejemplo manual y obtener el mismo resultado?

Experimento de colas con datos ficticios

Construye seis pedidos que llegan al mismo instante: uno requiere nueve minutos y los otros cinco, dos minutos cada uno. Compara dos reglas: orden de llegada con el pedido largo primero y priorizar pedidos cortos. Con una sola estación y sin interrupciones, una regla puede reducir la espera promedio a costa de aumentar la espera del pedido largo. No elijas «ganador» antes de definir el objetivo. Repite el análisis cambiando el orden de llegada: verás que parte del resultado depende del escenario.

La cuestión dialéctica es concreta: si el objetivo se define solo por promedio, ¿qué dimensión de la experiencia del cliente queda excluida y podría terminar desmintiendo la idea de «mejor servicio»? El concepto de éxito debe volverse más completo; no basta añadir un eslogan sobre calidad.

Prueba patrón, con resultado conocido: si los seis pedidos anteriores llegan al mismo instante y hay un único servidor, la regla que atiende primero el pedido de nueve minutos produce esperas de 0, 9, 11, 13, 15 y 17 minutos (promedio: 65/6 ≈ 10,83). Si los cinco pedidos cortos van primero, las esperas son 0, 2, 4, 6, 8 y 10 minutos (promedio: 5), pero el pedido largo pasa de esperar cero a esperar diez minutos. El resultado ilustra una tensión entre promedio y trato a un segmento, no demuestra qué política conviene a una cafetería real. Para percentiles en muestras pequeñas, declara el método de cálculo.

Instrucción para auditar código generado

No mejores el diseño gráfico todavía. Explica el modelo matemático y las reglas del código, separadas de su interfaz. Enséñame un caso pequeño calculable a mano, los resultados esperados y tres pruebas de borde. Verifica promedio y percentil 90 de espera, variaciones en llegadas y efectos sobre distintos tipos de pedidos. Señala explícitamente lo que este prototipo no puede predecir sobre una cafetería real.

Entrega y evaluación

Presenta: (1) hipótesis del modelo; (2) un caso de prueba reproducible; (3) un fallo o limitación descubierta; (4) la modificación necesaria; y (5) un criterio de despliegue o descarte. Si el prototipo no tiene fallos detectados, indica qué pruebas realizaste y qué incertidumbre queda en pie. Principio: un prototipo generado en segundos puede ahorrar trabajo de programación, pero no elimina el trabajo de validar que represente la situación que importa.