23 La IA como revisora adversaria
Este capítulo forma parte de un libro en desarrollo activo y todavía no ha pasado por la revisión del autor. El contenido puede cambiar a medida que avanza la revisión.
La decisión de investigación. Cuando alguien que revisa te entrega una lista de fallas en tu propio análisis, tú decides cuáles fallas son reales, y lo decides corriendo la única verificación de datos que confirma o refuta cada una, nunca haciéndole caso a quien sonó más seguro. La confianza no es evidencia, y un panel de revisores seguros no son tres piezas de evidencia.
23.1 Por qué importa esta decisión
La decisión sobre la mesa: cuáles de las fallas que nombra una revisión son reales, resuelto por una verificación que corres tú y no por lo segura que sonó la revisión.
Imagina la revisión de una propuesta para llevar un cambio de tienda a toda la cadena. Una gerente de operaciones es quien firma para que tu cambio llegue a cada tienda, y quien responde por él cuando las filas de las cajas cuentan otra historia. Ejemplo: la gerenta que aprobó tu nueva distribución de autopago es quien atiende los reclamos cuando las filas se amontonan el primer sábado con movimiento. Su preocupación es directa.
“No me digas que los números mejoraron. Dime qué verificación corriste que lo habría detectado si no hubieran mejorado. Confío en la verificación, no en el gráfico.”
Una medición segura, una crítica fluida de una IA y una tabla de aspecto limpio pueden estar equivocadas todas de la misma manera convincente. La gerenta está pidiendo lo que suena menos impresionante y más importa: la verificación con la que te comprometiste antes de mirar, y la alerta que efectivamente verificaste contra los datos.
23.2 El concepto
Una revisión adversaria es una lectura cuyo trabajo es atacar tu resultado y encontrar dónde se rompe, no elogiarlo. Ejemplo: un par que intenta mostrar que la mejora que mediste fue suerte y no un cambio real. Quien revisa puede ser una colega, una sola IA o un panel de modelos, y cada uno falla a su manera.
Defiendes un resultado intentando romperlo primero. Una verificación de robustez vuelve a correr el mismo hallazgo bajo una decisión distinta pero igual de defendible y mira si la respuesta se sostiene. Ejemplo: mediste la mejora durante una franja horaria, así que también la mides en otras dos franjas realistas. Una prueba de placebo corre tu procedimiento exacto donde el efecto no puede existir y confirma que vuelve cerca de cero. Ejemplo: comparas dos tramos de la distribución vieja entre sí, y cualquier “mejora” entre ellos es tu medición mintiendo.
El hábito que mantiene honesto un ataque es el orden. La búsqueda de especificaciones consiste en probar muchas versiones de un análisis y reportar solo la que dio la respuesta que querías, sin revelar la búsqueda. Su nombre cotidiano es p-hacking. Ejemplo: mides diez horas distintas y muestras solo la hora en la que tu cambio gana. La cura es un conjunto de verificaciones prelistadas, la lista completa que vas a correr, comprometida antes de ver ningún resultado. Ejemplo: escribes tres franjas horarias y un placebo, después corres las cuatro y reportas todos los números, incluidos los que no te ayudaron.
Una falla más se gana un nombre porque las IA revisoras la cometen todo el tiempo. El error correlacionado es que dos revisiones se equivoquen de la misma manera, de modo que su acuerdo es un eco y no una confirmación. Ejemplo: dos modelos de IA comparten un punto ciego y ambos señalan el mismo no-problema con igual confianza.
23.2.1 Una revisora agéntica sigue sin tener voto
Ahora puedes apuntar una herramienta a todo tu análisis y dejar que corra su propio bucle: leer tu código, volver a correrlo, hurgar en variantes y volver con una lista ordenada de problemas. Eso es una mejora genuina frente a un solo prompt, y va a encontrar errores reales que se te pasaron. No cambia nada sobre quién arbitra. Cada punto de esa lista sigue siendo una propuesta, y cada uno sigue necesitando el mismo trato: nombra la verificación, corre la verificación, lee tu propia salida. La lista es más larga y está mejor organizada que antes, lo que la vuelve más tentadora de aceptar completa, así que aguanta con más fuerza. Una revisión propone una falla, y los datos deciden si es real. La confianza, humana o de máquina, no te dice nada sobre si la falla existe.
23.3 Un ejemplo resuelto
Tu tienda instaló una nueva distribución de autopago, y tus datos dicen que la clientela pasó más rápido por la fila. Antes de defender eso, lo atacas. Primero, un término. El tiempo de espera p95 es la espera por debajo de la cual quedan 95 de cada 100 personas, un resumen más justo que el promedio porque captura las esperas largas de las que la gente de verdad se queja. Ejemplo: un p95 de 210 segundos significa que solo el 5 por ciento más lento esperó más que eso. Tu titular es una caída del p95 de 210 segundos a 140.
Le entregas el resultado a tres revisiones adversarias, y cada una nombra una falla fatal distinta. La primera dice que la victoria la impulsa una única mañana inusualmente tranquila. La segunda dice que elegiste a dedo la única mezcla de clientela donde la distribución ayuda. La tercera dice que comparaste una semana con personal completo contra una con poco personal, así que mediste el personal, no la distribución. Las tres están seguras, y las tres no coinciden.
No le crees a la voz más fuerte. Conviertes cada falla en una verificación. Dejar uno fuera elimina la mañana tranquila y recalcula el p95: apenas se mueve, así que la primera falla queda refutada. Tu rejilla prelistada de especificaciones vuelve a correr la caída en tres mezclas de clientela, y se sostiene en las tres, así que la segunda también queda refutada. El placebo compara dos tramos de la distribución vieja entre sí. Una mejora entre dos tramos idénticos le daría la razón a la tercera revisión, pero vuelve cerca de cero, así que la maquinaria está limpia.
Las dos alertas más ruidosas se disolvieron apenas una verificación las tocó. La falla que sobrevive es una que ninguna medición adicional puede quitar y que ninguna de las tres levantó: esto corrió en una tienda, entre semana, no en toda la cadena. Así que la afirmación honesta viene acotada. Mediste una mejora del p95 para estas tres mezclas de clientela en esta tienda, no una garantía para cada local que opera tu empresa.
23.4 El laboratorio en Colab
Este capítulo tiene su propio cuaderno de acompañamiento: ábrelo en Colab con la insignia de arriba. El cuaderno reúne los prompts y el código del capítulo y termina con el espacio de trabajo Ahora te toca a ti, para que completes el paso del capítulo en tu proyecto sin salir de Colab. El laboratorio de aula completo detrás de este capítulo es el cuaderno del curso nb10, Comparte la investigación y ataca el análisis (abrir en Colab), parte del curso de acompañamiento presentado en el apéndice Para docentes. Vuelves a correr una estimación sobre una rejilla prelistada de ocho especificaciones, ves cómo la búsqueda de especificaciones fabrica un resultado significativo a partir de puro ruido, corres un placebo y una verificación de influencia dejando uno fuera, y después entregas tu análisis a una persona, a una IA y a un panel de modelos de IA, y arbitras contra los datos cada alerta que levanten.
23.5 Prompts de IA recomendados
Comprométete primero con tu propia lectura del resultado, y después deja que una revisión lo ataque. Cada prompt de abajo entrega una tarea que puedes verificar, con una nota de verificación que nombra la falla contra la que te protege.
Haz red team (revisión adversaria) al resultado (tú corres la verificación que nombre).
Act as a hostile operations reviewer, not a cheerleader. Here is a one-paragraph
summary of my wait-time study and its headline claim: [paste your summary]. Name the
single most serious flaw you can find, and state the exact measurement I could run
that would confirm or refute it. Do not rewrite my study and do not list more than
one flaw.Después de ejecutarlo, verifica (contrarresta el acuerdo complaciente): si califica tu montaje de “sólido” u ofrece solo elogios suaves, insiste y pide el peor problema suponiendo que el resultado es falso. Una falla es real solo cuando corres la medición que nombró y tus propios números la confirman.
Lista las especificaciones que dejé fuera (tú auditas la lista).
Here is my pre-listed robustness grid for one wait-time result: I vary the customer
mix, the time of day, and whether the store was fully staffed. Name up to three
additional, equally defensible specifications I did NOT list that could move the
result, and for each say which direction you expect it to push.Después de ejecutarlo, verifica (contrarresta la ilusión de exhaustividad): una rejilla larga y ordenada puede aun así omitir el único ajuste que rompe la afirmación. Agrega y vuelve a correr las sugerencias que de verdad puedas operacionalizar, y descarta el resto.
Colapsa las alertas del panel (tú te quedas con el veredicto).
Three reviewers each named one "most serious flaw" in my analysis: [A], [B], [C].
For each, give the single data check that would confirm or refute it, in one line.
Then tell me which two of the three are most likely the same underlying concern in
different words, and which one is genuinely separate.Después de ejecutarlo, verifica (contrarresta los errores correlacionados): tres revisiones que repiten un mismo punto ciego pueden sentirse como tres confirmaciones. Corre cada verificación contra tu propia salida antes de creerle a ninguna alerta, y trata el acuerdo unánime como una candidata a verificar, nunca como la verificación misma.
Estas siguen siendo tuyas, por fluida que suene la revisión. Qué verificaciones de robustez te comprometes a correr antes de mirar, porque una verificación elegida después de ver el resultado no es una verificación, es una búsqueda. Qué fallas señaladas confirman de verdad tus datos, decidido por la medición y no por la confianza. Si una falla es un problema de límite de la afirmación que ninguna medición adicional puede arreglar y que solo una afirmación más estrecha puede responder. Y el único resultado acotado que vas a defender, con su incertidumbre enunciada. Una revisión propone; tú verificas, y la evidencia decide.
23.6 Un caso de falla de la IA
Pegas tu resumen de tiempos de espera en una IA revisora, y responde con total certeza: tu mejora es un artefacto de una única mañana inusualmente tranquila, elimina esa mañana y desaparece. La afirmación es específica, mecanicista y enunciada sin matices. Se lee exactamente como alguien que ha visto este error cien veces.
Así es como lo detectas. No actúas sobre el veredicto. Corres por tu cuenta el dejar uno fuera, eliminando la mañana tranquila y recalculando el p95. La mejora apenas se mueve. La falla segura estaba fabricada, un mecanismo con sonido real atornillado a un problema que tus datos no tienen. Créele a la certeza y tiras a la basura un resultado genuino por una corazonada. Apuntar la verificación a tus propios números fue lo único que lo resolvió.
23.7 Ahora te toca a ti
Tu proyecto tiene una estimación, un rango alrededor y una prueba negativa detrás. Este paso entrega todo el conjunto a una revisión cuyo único trabajo es romperlo, y te deja a ti la decisión de qué se rompió.
- Escribe un resumen de un párrafo de tu diseño, tu afirmación principal y las verificaciones que ya corriste. Una revisión que no sabe qué hiciste va a inventar fallas que descartaste la semana pasada.
- Encarga la revisión: pide la falla más grave, una sola, y la medición exacta que la confirmaría o la refutaría. Hazlo al menos dos veces, con encuadres distintos o herramientas distintas, y trata dos respuestas que coinciden como una candidata a verificar, no como dos confirmaciones.
- Toma los tres puntos más difíciles que recibiste. Para cada uno, escribe en una sola línea la verificación de datos que lo resolvería.
- Corre las tres verificaciones contra tus propios datos. Marca cada alerta como confirmada o refutada por tu propia salida, nunca por lo segura que sonó la revisión. Guarda la alerta equivocada más confiada que atrapaste; te dice algo sobre la herramienta que vas a volver a usar mañana.
- Encuentra la falla que ninguna verificación puede arreglar, la que es un problema de límite y no de medición, y estrecha tu afirmación hasta que la afirmación sea verdadera.
- Registra la revisión y cada alerta arbitrada en tu AI Research Ledger (registro de investigación con IA), y verifica al menos una salida con un método nombrado de la Guía de Verificación. El razonamiento con pares va bien aquí: pasa tu afirmación estrechada por una persona y mira si sobrevive a su primera pregunta. Una IA revisora puede hacer la comprobación contigo; la decisión de aceptar o rechazar es tuya.