10 Declarar y diagnosticar un diseño de investigación
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. Si el diseño que escribiste es lo bastante fuerte para correrlo, decidido antes de recoger un solo dato: lo simulas, lees con qué frecuencia aterriza en la verdad y nombras el único cambio que más lo mejora. Después lo corres, lo arreglas o reduces lo que prometiste.
10.1 Por qué importa esta decisión
La decisión sobre la mesa: si este diseño es lo bastante fuerte para correrlo, juzgado antes de gastar nada en recoger datos.
Imagina a la metodóloga de tu comité leyendo tu plan. Hace una sola pregunta: «¿Con qué frecuencia atraparía este diseño exacto el efecto real si lo corrieras mil veces?» Si tu respuesta es «nunca lo comprobé», ahí se detiene. Un diseño puede leerse hermoso, con una pregunta afilada y una comparación limpia, y aun así volver con «aquí no hay nada» nueve de cada diez veces, o aterrizar con seguridad en el número equivocado todas las veces. Este capítulo te deja descubrirlo barato, en simulación, para que los meses que habrías gastado recogiendo datos condenados se vayan a un diseño que sí puede responder tu pregunta.
10.2 El concepto
En el capítulo 9 construiste las cuatro partes de un diseño. Este capítulo las pone a prueba con un ciclo de tres pasos que este libro toma de RDSS (Research Design in the Social Sciences: Declare, Diagnose, Redesign).
Declarar significa escribir tus cuatro partes del diseño como algo que una computadora pueda correr: un modelo que genera datos falsos, una indagación que se puede calcular sobre esos datos falsos, un plan de muestreo y de asignación de condiciones, y una regla para convertir datos en una estimación. Ejemplo: código que inventa 40 personas compradoras, lanza una moneda para darle a cada una la nueva pantalla de pago y resta los promedios de los dos grupos.
Diagnosticar significa correr ese diseño declarado muchas veces sobre mundos simulados frescos y observar cómo se comporta su estimación. Ejemplo: corre el estudio de la moneda 2.000 veces y recoge las 2.000 estimaciones. Tres números empiezan la historia de ese montón, y cada uno responde a una preocupación distinta.
El sesgo es el promedio de tus errores a lo largo de las corridas, contando la dirección: cada estimación menos la verdad, promediado. Un diseño es insesgado cuando sus estimaciones se centran en la respuesta verdadera. Ejemplo: la verdad es 2, y cinco corridas devuelven 0, 1, 2, 3 y 4. Los errores son -2, -1, 0, +1, +2, que promedian cero, así que el sesgo es cero aunque una sola corrida haya caído en 2. La dirección es lo que separa al sesgo de la simple distancia: errores que se cancelan dicen que el diseño apunta bien, mientras que errores que se inclinan todos hacia un lado dicen que está torcido.
La varianza es cuánto se bambolea la estimación de una corrida a la siguiente. Ejemplo: estimaciones que oscilan entre -5 y +9 alrededor de un valor verdadero de 2 tienen varianza alta. Recoger más datos del mismo tipo, con el mismo diseño, normalmente achica ese bamboleo. Es el único problema que el tamaño resuelve con confianza.
La potencia es con qué frecuencia el diseño detecta un efecto real, y no significa nada hasta que digas cómo decidirías. Una prueba estadística es la regla que usas para decidir si tus datos chocan lo suficiente con “ningún efecto” como para llamar real al resultado. Ejemplo: en el estudio del pago en línea, una regla de diferencia de medias: declara un efecto cuando la brecha entre los dos grupos supera cerca de dos veces su bamboleo típico entre corridas. El umbral de la prueba es qué tan exigente es esa regla, y se lee a lo largo de repeticiones imaginadas: en el ajuste usual de 5 por ciento, un diseño cuyo efecto verdadero es CERO todavía gritaría “efecto” en unas 5 corridas de cada 100. El umbral es una propiedad de la regla a lo largo de muchas corridas, nunca la probabilidad de que tu hallazgo particular sea falso. Ejemplo: un diseño que pasa esa regla en 8 de 100 corridas, cuando el efecto verdadero es 2, tiene 8% de potencia, lo que es casi inútil. La potencia se mueve con todo lo que está en la declaración: la prueba, el umbral, el efecto que plantaste, el tamaño de la muestra y cómo hace ruido el mundo. Reporta la tarjeta completa junto al número.
Esos tres no agotan el montón, y los diagnósticos más completos agregan otros. Dos valen la pena por su nombre. La raíz del error cuadrático medio es el tamaño típico de un error, con los errores grandes pesando de más. Ejemplo: en el ejemplo de cinco corridas de arriba, la distancia promedio simple es 1,2, pero la raíz del error cuadrático medio es cerca de 1,4, porque los dos errores de 2 puntos cuentan más que su parte. La cobertura es con qué frecuencia el rango que reportas alrededor de tu estimación de verdad contiene la verdad. Ejemplo: si reportas un rango hecho para acertar 95 de cada 100 veces, la cobertura revisa si de verdad acierta. Un diseño puede ser insesgado y aun así fallar feo cada vez, y exactamente por eso un solo número nunca es el diagnóstico completo. Un capítulo más adelante construye esos rangos como corresponde; aquí basta con saber que un diagnóstico puede preguntar por ellos.
Rediseñar significa cambiar exactamente una parte en respuesta al diagnóstico y volver a diagnosticar. La potencia baja por varianza alta pide más datos. Una inclinación incrustada en el diseño, como quién termina en qué grupo, pide un diseño distinto: más datos vuelven una estimación torcida más estable, no más verdadera.
10.3 Un ejemplo resuelto
Trabajas con un supermercado en línea que quiere saber si un botón de recompra con un toque, que reconstruye el último carrito de una persona con una sola pulsación, hace que la gente pase por el pago más rápido. Tu resultado son los segundos hasta completar la compra. Tu efecto verdadero, en el mundo que simulas, es que el botón recorta 8 segundos.
Lo declaras: construye personas compradoras cuyos tiempos de pago de base varíen mucho, porque algunas navegan y otras corren; lanza una moneda para asignar el botón; resta los promedios de los dos grupos. Diagnosticas un piloto de 12 personas por versión. El resultado da que pensar. El sesgo es cercano a cero, así que el diseño apunta bien, pero la dispersión es enorme porque los tiempos individuales varían muchísimo, y la potencia vuelve por debajo del 10%. El diseño es honesto e inútil a la vez. Apunta en promedio a la ganancia de 8 segundos y casi nunca se acerca lo bastante en una corrida individual como para demostrarla.
Ahora rediseña. El problema es la varianza, así que subes la muestra a 400 por versión y vuelves a diagnosticar. La potencia salta por encima del 90% y la dispersión se colapsa hacia la verdad. Eso es varianza curada con tamaño. Pero corre un diseño más como advertencia: quita el lanzamiento de la moneda y deja que la gente elija usar el botón nuevo por su cuenta. Quienes lo eligen son las personas frecuentes y practicadas, que de todos modos pagan más rápido, así que el botón se lleva el crédito por una velocidad que aportó la costumbre. Este diseño confundido es igual de preciso con 400 por versión, y sin embargo se centra en una ganancia de 14 segundos en lugar de 8, y ninguna cantidad extra de datos lo mueve. Esa brecha nombra la última idea. Un diseño aleatorizado puede identificar el efecto del botón, es decir, atribuirle la diferencia de tiempo al botón y descartar otras causas, mientras que el confundido solo muestra una asociación, donde ambas cosas se mueven juntas pero una causa común podría explicarlo.
10.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 nb04 — The anatomy of a research design: MIDA + declare → diagnose → redesign (la anatomía de un diseño de investigación: MIDA + declarar → diagnosticar → rediseñar) (abrir en Colab), parte del curso de acompañamiento presentado en el apéndice Para docentes. Allí declararás el diseño de mentoría del cuaderno en unas pocas líneas de Python, lo correrás miles de veces para leer con tus propios ojos su sesgo, su varianza y su potencia, y verás cómo un rediseño rescata un estudio justo pero sin potencia mientras su gemelo confundido sigue equivocado con cualquier tamaño de muestra.
10.5 Prompts de IA recomendados
Comprométete primero con tu propia expectativa y solo después delega. Cada prompt de abajo te deja un borrador que igual tienes que revisar. La simulación es donde el bucle de IA (el ciclo prompt → respuesta → interrogación → refinamiento → nueva ejecución) se vuelve más rápido y más peligroso a la vez: los asistentes de código modernos escriben el script, lo corren, leen el error y lo parchan sin esperarte, y convergerán encantados en código que corre limpio mientras declara un diseño distinto del tuyo. Deja que la herramienta se quede con el tecleo. Quédate tú con la propiedad del efecto verdadero que plantas y de los números que lees.
Act as a simulation assistant. Here is my declared design in words:
[model, inquiry, data strategy, answer strategy]. Write the smallest Python
that builds a world where I set the true effect, runs the design many times,
and reports bias, variance, and power. List every assumption your code makes
about my design that I did not state.Después de ejecutarlo, verifica (contrarresta el método plausible pero equivocado): vuelve a correrlo con el efecto verdadero puesto en cero y confirma que «detecta» un efecto solo con la frecuencia que permite tu umbral de significancia. Una simulación que se dispara con un efecto cero está declarando un diseño distinto del tuyo.
Here is my diagnosed design and its numbers: [bias, variance, power]. List the
threats to any conclusion from one run as a table: threat, whether it is a
bias / variance / power problem, and the single redesign that reduces it most.Después de ejecutarlo, verifica (contrarresta la ilusión de exhaustividad): contrasta la tabla con tu propio diagnóstico impreso. El problema letal que tus números ya demostraron tiene que ser la primera fila; una lista ordenada de seis amenazas que nunca lo nombra se perdió el punto.
Argue against my claim that this design is strong enough to run. As a hostile
methodologist, name the one diagnosand I am most likely fooling myself about,
and the observation that would expose it.Después de ejecutarlo, verifica (contrarresta el acuerdo complaciente): si elogia el diseño sin una sola objeción, descarta la respuesta y vuelve a diagnosticar por tu cuenta.
Tres decisiones siguen siendo tuyas. Qué mundo supone tu pregunta, el modelo que declaras, es una afirmación sobre la realidad que ninguna herramienta puede hacer por ti. Qué única cantidad nombras como tu indagación decide qué significa siquiera el «éxito». Y la decisión honesta de correr o no un diseño que tu propio diagnóstico dice que es demasiado débil es un juicio que firmas con tu nombre. Una IA puede proponer amenazas y redactar código de simulación, pero no puede decidir que tu estudio sin potencia vale meses de tu vida de todos modos.
10.6 Un caso de falla de la IA
Pegas tu diseño observacional confundido y preguntas: «Mi estimación es ruidosa. ¿Qué debería hacer?». La herramienta responde con seguridad: «Recoge más observaciones para ajustar tu estimación». Eso suena obviamente correcto y es exactamente lo equivocado en tu caso. Tu problema es sesgo por autoselección, no varianza, y más datos solo convierten una estimación sesgada en un número equivocado más preciso. Lo atrapas como enseña este capítulo: corre el diseño confundido en simulación con una muestra grande y observa cómo las estimaciones se agrupan apretadas alrededor de 14 segundos cuando la verdad es 8. La dispersión se achicó; el error no. Esa es la falla del plausible-but-wrong-method (método plausible pero equivocado), y tu propio diagnóstico la desenmascara.
10.7 Ahora te toca a ti
Tienes cuatro partes de un diseño sobre el papel. Este paso pregunta si sobrevivirían al contacto con el mundo, mientras una mala respuesta todavía es gratis.
- Declara tu diseño como algo que se pueda correr. Si sabes programarlo, escribe el script más pequeño que construya un mundo donde tú fijas el efecto verdadero, saque tu muestra, aplique tu estrategia de respuesta e imprima una estimación. Si todavía no sabes programarlo, decláralo en palabras lo bastante precisas como para que alguien más pueda: enuncia el efecto verdadero que estás suponiendo, el número de unidades y la aritmética exacta.
- Diagnostícalo. Córrelo unos miles de veces y lee tres números: sesgo (¿se centran las estimaciones en la verdad que plantaste?), varianza (¿qué tan ancha es la dispersión?) y potencia (¿con qué frecuencia pasa el umbral que declaraste?). Anota la prueba y el umbral que usaste, o el número de potencia no significa nada. Si la simulación queda fuera de tu alcance, registra cada número como “no estimado” y razona en palabras sobre la dirección: hacia qué lado esperas la inclinación, y qué ensancharía la dispersión. Etiqueta ese razonamiento como razonamiento. Un número que no computaste no es un diagnóstico.
- Nombra el peor de los tres y di de qué tipo de problema se trata. El bamboleo ancho y la potencia baja suelen ceder ante una muestra más grande, aunque no solo ante ella: una medición más afilada, grupos mejor equilibrados y un contraste de tratamiento más fuerte también compran potencia. Una inclinación en quién termina dónde es un problema de diseño, y una muestra más grande la vuelve más precisa en lugar de menos equivocada.
- Rediseña una vez. Cambia exactamente una cosa, la que señala tu diagnóstico, y vuelve a diagnosticar. Registra ambos diagnósticos lado a lado para que la mejora se vea.
- Toma la decisión honesta en una oración: correrlo tal como quedó rediseñado, rediseñar otra vez, o reducir la afirmación a lo que este diseño de verdad puede entregar. Los tres son resultados respetables. Fingir que nunca lo comprobaste, no.
- Registra ambos diagnósticos en tu AI Research Ledger (registro de investigación con IA) y verifica el número clave con un método nombrado de la Guía de Verificación; la simulación es el método para una afirmación sobre cómo se comporta un procedimiento, y un diagrama causal es la segunda comprobación si tu indagación usa la palabra causa. Una IA revisora puede correr el diagnóstico contigo; la decisión de correr, arreglar o reducir es tuya.