5.3
Bloque 5 · Proyecto Integrador · Semanas 53–54

Evaluación e iteración

Los metrics tradicionales (A/B testing) no funcionan en sistemas complejos porque el sistema cambia en respuesta a tu medida. Aprende a evaluar sistemas híbridos adaptables y a iterar sin que el acto de medición destruya lo que intentas optimizar.

Sesión A — Medir lo que importa en sistemas complejos

La medición en sistemas complejos es paradójica: cuanto más importantes son los aspectos que quieres medir (confianza, equidad, estabilidad emergente), más difíciles son de cuantificar. Y cuanto más fáciles de medir (clicks, recomendaciones aceptadas), menos importancia tienen realmente.

La Ley de Goodhart (1975) reza: "Cuando una medida se convierte en un objetivo, deja de ser una buena medida." Ejemplo: si optimizas una recomendador por "tasa de clicks", el sistema aprenderá a generar contenido sensacionalista. Hiciste click, pero te arrepentiste. Goodhart ocurre en sistemas complejos porque el acto de optimizar una métrica cambia el comportamiento del sistema.

Cinco categorías de métricas en sistemas híbridos:

1. Output metrics: Lo que el sistema produce directamente. Ej: precisión, recall, latencia. Son fáciles de medir pero pueden engañar. Optimizar solo output sin ver impacto global es peligroso.

2. System health indicators: Cómo está el sistema en su conjunto. Ej: tasa de override humano (si sube, la IA está fallando o perdiendo confianza), variedad de decisiones (si cae, el sistema está colapsando a un único patrón), feedback delay (si sube, el loop se vuelve inestable).

3. Emergence detection: Propiedades que emergen del acoplamiento humano-IA. Ej: usuarios se polarizan (el recomendador amplificó sus sesgos), aparece un arbitraje imprevisto (alguien explota una brecha sistema), surge liderazgo emergente (una facción domina las decisiones).

4. Feedback loop integrity: ¿El feedback que retorna es válido? Ej: usuarios que dan feedback negativo falso (para manipular el sistema), ruido ambiental que corrompe medidas.

5. Human satisfaction & autonomy: Cómo se sienten los humanos operando el sistema. Ej: cognitive load, sense of agency (¿sienten que tienen control?), trust trajectory (¿va creciendo o decayendo?).

Sesión B — Práctica

Sesión B — Ciclo de evaluación iterativa

Practica un ciclo PDCA (Plan-Do-Check-Act) en un sistema híbrido simulado. Tienes 5 rondas. Cada ronda: elige qué medir, propón una intervención, observa cómo el sistema responde (incluyendo consecuencias imprevistas), y aprende.

Instrucciones: Abajo verás un dashboard con múltiples métricas (Accuracy, Fairness, Human Satisfaction, System Stability, Adaptation Rate). Tu objetivo es mejorar el sistema sin que se degrade ninguna métrica crítica.

Cada ronda tienes 3 acciones disponibles:

  • "Aumentar automatización": Reduce intervención humana. Accuracy sube, Human Satisfaction baja.
  • "Mejorar transparencia": Explica más decisiones. Fairness sube, Accuracy baja ligeramente (más overhead).
  • "Reentrenar modelo": Usa nuevos datos. Puede mejorar Accuracy pero destabilizar si hay feedback malo.
  • Autores

Trampa: Cada intervención tiene una consecuencia secundaria que aparece 1-2 rondas después. Ej: aumentar automatización baja Human Satisfaction, que lleva a override humano más frecuente, que destabiliza el sistema. ¿Puedes predecir y evitar esto?

Victoria: Completar 5 rondas sin que ninguna métrica crítica caiga por debajo del 40%.

Sesión C — Evaluación

Sesión C — Evaluación de dominio

Dominaste este concepto si:

Quiz de evaluación

Responde correctamente 3 de 4 preguntas (75% mínimo).

Contexto histórico

Ley de Goodhart y el fracaso de métricas (1975–2008)

Charles Goodhart fue economista del Banco de Inglaterra. En 1975, observó un patrón: cada vez que el banco intentaba usar una métrica económica como objetivo, la métrica se volvía inútil. Ejemplo histórico: cuando optimizaban por dinero en circulación (M3, agregado monetario), los bancos comerciales comenzaban a crear instrumentos financieros que aumentaban M3 sin reflejar la economía real. La métrica ya no medía lo que pretendía.

Goodhart formuló su ley: "Cuando una medida se convierte en un objetivo, deja de ser una buena medida." Es decir, tan pronto como estructura incentivos alrededor de una métrica, los actores la juegan. La métrica se vuelve Goodharted.

La crisis de replicación (2011–presente)

En 2011, Daryl Bem publicó un paper en una revista top que "demostraba" la precognición en humanos mediante p-values < 0.05. El paper era un fraude metodológico: Bem había hacked las pruebas estadísticas optimizando por "p-value bajo". Esto detonó la "crisis de replicación": miles de papers publicados no podían ser reproducidos porque los autores habían optimizado por "publicable" (p < 0.05), no por verdad.

Andrew Gelman, estadístico de Columbia, mostró que en campos donde hay muchos grados de libertad (qué variable medir, cómo codificar datos, qué test estadístico usar), es trivial hackear un resultado: simplemente prueba todos los análisis posibles, quédate con el que da p < 0.05, y publica. Eso es "p-hacking" o "HARKing" (Hypothesizing After Results are Known).

La lección: en sistemas complejos con muchas variables, la probabilidad de Goodhart es alta. Si optimizas una métrica, la optimizarás a costa de otras. Y si no tienes metrices de "system health" para detectarlo, no te darás cuenta hasta que el sistema colapsa.

Deming y el PDCA (1950s)

W. Edwards Deming, estadístico americano, fue a Japón después de WWII a enseñar control de calidad. Deming enfatizó que mejoría continua requiere un ciclo: Plan (qué cambiar) → Do (implementa en pequeño) → Check (mide resultado) → Act (implementa en grande o pivotea). Este ciclo, ahora conocido como PDCA o ciclo Deming, se convirtió en el fundamento del movimiento de calidad japonés (kaizen).

Lo importante de Deming: no esperes hasta el final para medir. Itera rápido, mide temprano, ajusta. Eso minimiza el riesgo de Goodhart porque detectas problemas en pequeño.

Agile y ciclos de feedback cortos (2000s)

El manifiesto Agile (2001) codificó muchas ideas de Deming: ciclos cortos (1-2 semanas), feedback constante de usuarios, ajuste continuo. En lugar de planificar 6 meses y esperar, haces sprints cortos y mides feedback cada 2 semanas. Eso reduce la probabilidad de Goodhart porque detectas que estás optimizando la métrica equivocada antes de invertir mucho.

Campbell's Law (1976) — "A System Optimizing for a Metric Loses Sight of the Actual Goal"

Donald Campbell, psicólogo social, formuló una ley análoga a Goodhart en 1976: "La más precisa de todas las medidas cuantitativas tiende, cuando se usa para propósitos de evaluación administrativa, a distorsionarse y corromper los procesos que intenta monitorear."

Ejemplo: si evalúas profesores por "tasa de aprobados", los profesores enseñarán a pasar el examen, no a aprender. Si evalúas doctores por "tiempo promedio por paciente", los doctores verán pacientes rápidamente y harán diagnósticos superficiales. La métrica corrompe el sistema.

Aplicación a sistemas híbridos IA-humano (2020s)

Grupos de investigación como AI Now Institute, Partnership on AI, y universidades como Stanford, MIT, y Oxford han estudiado cómo Goodhart afecta sistemas de IA. Un ejemplo famoso: Amazon construyó un recomendador de hiring que optimizaba por "candidatos contratados, luego permanencia en el trabajo." El sistema aprendió a recomendar hombres porque había menos mujeres en roles técnicos, creando un ciclo: menos mujeres recomendadas → menos mujeres contratadas → menos datos de mujeres en el sistema → IA recomienda menos mujeres. Amazon optimizó la métrica equivocada sin darse cuenta hasta que fue demasiado tarde.

La solución moderna: multi-métrica evaluation. No optimices una cosa. Mantén un dashboard con múltiples métricas (accuracy, fairness, diversity, human satisfaction) y busca soluciones que mejoren la mayoría sin degradar la minoría. Eso se llama "Pareto optimization" en economía.

Teoría profunda

Formalización de Goodhart (Manheim & Garrabrant, 2018)

Dos investigadores de MIRI (Machine Intelligence Research Institute) formalizaron Goodhart matemáticamente. Hay tres tipos:

1. Regressional Goodhart: La métrica y el objetivo están correlacionados, pero no causalmente. Optimizar la métrica rompe la correlación. Ejemplo: "tasa de llamadas al servicio técnico" correlaciona con "insatisfacción del cliente." Pero si optimizas por "menos llamadas," la gente simplemente deja de llamar (y se va a competidor). Ya no hay correlación.

2. Causal Goodhart: Hay causalidad, pero al optimizar, cambias el sistema de tal modo que la causalidad desaparece. Ejemplo: "horas de sueño" causa "mejor desempeño cognitivo." Pero si forcedly obliges a empleados a dormir exactas 8 horas (ej: les prohibes trabajar de noche), cambias su motivación, así que el desempeño se degrada.

3. Adversarial Goodhart: Actores racional optimize la métrica de forma deshonesta. Ejemplo: "dinero recaudado por ONGs" no mide "impacto social." ONGs pueden recaudar mucho dinero prometiendo resultados imposibles, o usando celebridades, sin realmente resolver problemas.

En sistemas de IA, los tres tipos ocurren. Regressional Goodhart es el más común: optimizas Accuracy sin medir fairness, y descubres que es injusto. Causal Goodhart ocurre cuando cambias incentivos: si das bonus por "acciones ejecutadas por IA," los humanos dejan de verificar, y el sistema diverge. Adversarial Goodhart ocurre cuando hay stakeholders: sindicatos pueden falsificar feedback para que no se automate su trabajo.

Multi-objetivo Pareto-optimal

Si tienes múltiples objetivos (o₁, o₂, ..., oₙ) que se contradicen, una solución es Pareto-óptima si no existe otra solución que mejore en todos. Ejemplo:

A no domina B en todos. B es mejor en Fairness pero peor en Accuracy. Ambas son Pareto-óptimas; la elección depende de tus prioridades.

Para sistemas híbridos, construye el "Pareto frontier": el conjunto de soluciones donde no puedes mejorar una métrica sin degradar otra. Luego, negotia con stakeholders: ¿prefieres 95% accuracy con 70% fairness, o 90% accuracy con 90% fairness? Esa es la pregunta real, no "cómo optimizar accuracy."

Diferencia-en-diferencias (DiD) y sus limitaciones en sistemas adaptativos

El estándar de oro del causal inference en economía es diferencia-en-diferencias: tienes grupo control y grupo tratamiento, antes y después del tratamiento. Efecto causal = (T_after - T_before) - (C_after - C_before).

Pero en sistemas adaptativos, DiD falla:

Alternativa: Bayesian Updating

En lugar de asumir un efecto causal fijo, modela tu confianza en parámetros del sistema como distribución probabilística. Antes de intervención: prior. Observas datos post-intervención: actualizas a posterior. Repite cada ronda. Esto permite capturar incertidumbre y actualizar conforme aprendes, sin asumir que el efecto es constante.

Matemáticamente: P(parámetro | datos observados) ∝ P(datos | parámetro) × P(parámetro).

System Health Indicators como forma de Goodhart defense

Define indicadores que NO puedes optimizar directamente pero que detectan problemas:

Estos no son objetivos (no los maximizas ni minimizas), son alarmas. Si un indicador cruza threshold, pausa la optimización y investiga.

Cómo estudiar este material

Textos clave:

1. Goodhart, C. A. E. (1975). "Monetary Relationships: A View from the Bank of England". Paper económico, 15 páginas. No necesitas entender toda la economía; enfócate en la sección "Goodhart's Law" donde explica por qué las métricas se corrompen cuando se convierten en objetivos.

2. Campbell, D. T. (1976). "Assessing the Impact of Planned Social Change". Paper en sociología. Campbell observó que cuando instituiciones educativas o de salud son evaluadas por una métrica, la métrica se distorsiona. Busca especialmente su ejemplo de "teaching to the test."

3. Deming, W. E. (1986). "Out of the Crisis". Libro sobre calidad y mejora continua. Lee el Capítulo sobre "PDCA Cycle" y "Variation." La idea: mejoría requiere ciclos cortos de medición y ajuste, no planes fijos.

4. Manheim, D. & Garrabrant, S. (2018). "Categorizing Variants of Goodhart's Law". Paper técnico de MIRI, 12 páginas. Formaliza los tres tipos de Goodhart (Regressional, Causal, Adversarial). Lee la sección de ejemplos.

5. Gelman, A., Carlin, J. B., et al. (2013). "Bayesian Data Analysis" (3rd ed.), Cap. 6 sobre "Model Checking and Improvement". O más corto: Gelman (2013) "P-hacking and the problem of multiple comparisons." Busca este último online; es 5 páginas. Explica por qué optimizar métricas lleva a falsos positivos.

6. Riedl, C., et al. (2023). "Potential of AI for Collective Intelligence". Section sobre "Evaluation Methodology for Hybrid Systems." Enfócate en las limitaciones de A/B testing en sistemas adaptativos.

Cómo estudiar:

Paso 1 (30 min): Lee resumen de Goodhart (busca en Google "Goodhart's Law explained"; hay buenos resúmenes). Comprende: métrica ≠ objetivo.

Paso 2 (45 min): Lee Campbell (1976) sección "Assessing Impact." Toma nota de 5 ejemplos donde optimizar métrica rompió el sistema. Ejemplos: maestros que enseñan solo el examen, hospitales que optimizan por "tiempo de espera" y bajan calidad médica, etc.

Paso 3 (1 hora): Lee Manheim & Garrabrant. Enfócate en los 3 tipos: Regressional (métrica correlaciona pero no causa), Causal (causa existe pero cambia cuando optimizas), Adversarial (actores la juegan). Para cada tipo, piensa: ¿cómo afecta mi sistema de IA?

Paso 4 (1 hora): Lee Deming sobre PDCA y "Variation." Comprende: en sistema complejo, variación es normal. Lo importante es detectarla rápidamente (ciclos cortos) antes de divergir.

Paso 5 (30 min): Lee Gelman sobre p-hacking. Entiende: si tienes 20 hipótesis, 1 tendrá p < 0.05 por azar. En sistemas complejos con muchas variables, mismo problema: puedo reportar la métrica que pasó (Goodharting), no la métrica verdaderamente importante.

Conexión práctica: Para cada paper, pregúntate: "Si fuera responsable de evaluar mi sistema híbrido IA-humano, ¿cómo evitaría este error?" Ej: Goodhart → monitoreo multi-métrica. Deming → ciclos PDCA cortos. Gelman → registro pre-especificado de métricas antes de medir.

ISLR conexión: ISLR Cap. 5 sobre "Resampling Methods" (cross-validation). Eso es una forma de defender contra overfitting (una forma de Goodhart: optimizas train error a costa de test error). Pero necesitas ir más allá: system health indicators.

Ejercicio expandido

Escenario A: Detectar y evitar Goodhart en tasa de adoption de IA

Una empresa implementa un sistema de recomendación para reducir tiempo de decisión (métrica: "tiempo promedio de decisión"). Mides la métrica y ves que bajó 40% (victoria). Pero después de 3 meses, la calidad de decisiones se degrada. ¿Qué pasó?

Análisis: Probablemente los usuarios están tomando decisiones rápidas sin leer la recomendación completamente (Goodhart). Optimizaron tiempo a costa de calidad. Qué debiste medir:

Entrega: Lista de 5-6 métricas que deberías haber medido simultáneamente. Para cada una, explica por qué ayuda a detectar Goodhart.

Escenario B: PDCA en vivo — Iteración con feedback de usuarios

Eres responsable de un sistema de clasificación de crédito (híbrido: IA + oficial de crédito). Ciclo inicial:

Una semana después: oficiales de crédito reportan que el modelo está rechazando más solicitantes (tasa de aprobación bajó). Investigas y encuentras que el nuevo modelo aprendió a usar "ubicación geográfica" como proxy para raza (Goodhart + sesgo). Accuracy subió pero fairness se degradó, y encima el modelo es más rechazador.

Rediseña el ciclo PDCA para detectar esto:

Entrega: PDCA plan revisado con pasos de "Check" expandidos (qué 4-5 métricas medir), y criterios de "stop/go" para avanzar a "Act".

Escenario C: Diseña un "System Health Dashboard" con alarmas tempranas

Construye un dashboard para monitorear un sistema híbrido humano-IA. Incluye:

Para cada indicador, define:

Ejemplo parcial:

Tasa de Override Humano
Porcentaje de recomendaciones IA donde el humano ignora y elige diferente.
Baseline: 15% | Amarillo: >25% | Rojo: >40%
Acción si se dispara: Investigar si IA está dando malas recomendaciones o si cambió preferencia del usuario.

Entrega: Tabla de dashboard con 8-10 indicadores, baseline, thresholds y acciones. Bonus: diagrama mostrando cómo los indicadores se relacionan (ej: si override sube, eventualmente accuracy baja 1 semana después si no investigas).

Evaluación: Los mejores dashboards son aquellos donde los indicadores detectan problemas tempranamente y la lógica de acciones es clara (no reactiva, es proactiva).