Beyond Reproducible Research: Building a Formal Representation of a Data Analysis

Este artículo propone e implementa una representación formal de los análisis de datos que, al externalizar su construcción lógica, permite evaluar la razonabilidad del análisis y la sensibilidad de sus supuestos sin necesidad de los datos originales ni de ejecutar el código.

Lo esencial

Imagina que la investigación científica es como un restaurante de alta cocina.

Hasta ahora, el estándar para que un chef (un científico) comparta su receta con el mundo era simplemente entregarle al cliente la lista de ingredientes (los datos) y la lista de pasos exactos que siguió (el código de programación). Esto se llama "investigación reproducible". Si el cliente sigue los pasos con los mismos ingredientes, debería obtener el mismo plato.

El problema:
A veces, el cliente sigue la receta, pero el plato sale mal. ¿Por qué? Porque la receta no explica por qué el chef tomó ciertas decisiones.

• ¿Por qué usó sal en lugar de azúcar?
• ¿Asumió que el tomate estaba maduro?
• ¿Ignoró que el horno estaba defectuoso?

El código dice qué se hizo, pero no explica el razonamiento, las suposiciones o las expectativas del chef. Si el plato sale mal, el cliente tiene que volver a cocinarlo todo para descubrir el error, lo cual es lento y costoso.

La Propuesta: El "Plano Arquitectónico" de la Análisis

Roger Peng propone algo nuevo: en lugar de solo dar la receta, el chef debe entregar un plano arquitectónico lógico de su pensamiento.

Imagina que cada afirmación que hace el científico (ej. "El promedio de esta muestra es 4.6") no es solo un número, sino un edificio. Para que ese edificio sea sólido, debe tener cimientos y vigas de soporte.

En este nuevo sistema:

1. La afirmación es el edificio: "El promedio es 4.6".
2. Las premisas son los cimientos: "No hay datos faltantes", "No hay valores extremos raros", "La distribución es simétrica".

El código no solo calcula el número; verifica que los cimientos estén bien antes de permitir que el edificio se construya.

Analogías Clave para Entenderlo

1. El "Guardián de la Puerta" (Validación Automática)

En el código tradicional, si pides un promedio y hay un dato que dice "999" por error, el programa simplemente lo suma y te da un promedio falso. Es como si un guardia de seguridad dejara pasar a un intruso disfrazado.

En el sistema de Peng, cada afirmación tiene un guardián (una clase de validación).

• Si el guardia ve un "999" o un dato faltante, bloquea la puerta.
• El programa se detiene y grita: "¡Espera! No puedes afirmar que el promedio es 4.6 porque hay un dato raro aquí".
• Ventaja: Sabes que la afirmación es cierta antes de ver el resultado final, solo por saber que el guardia no bloqueó la puerta.

2. El Árbol Genealógico de la Verdad

Imagina que quieres probar que "Juan es un buen padre".

• Enfoque antiguo: Muestras una foto de Juan con su hijo. (Esto es el código: muestra lo que pasó).
• Enfoque nuevo: Construyes un árbol genealógico de pruebas.
  • Para que Juan sea un buen padre, debe ser responsable.
  • Para ser responsable, debe pagar la escuela.
  • Para pagar la escuela, debe tener un trabajo estable.
  • Para tener un trabajo, debe tener un diploma.

El sistema de Peng crea este árbol. Si puedes verificar que tiene el diploma, el trabajo, paga la escuela y es responsable, entonces lógicamente debe ser un buen padre. No necesitas ver la foto del hijo para saber que la lógica es sólida.

3. El "Mapa de Riesgos" (Árboles de Fallo)

El artículo menciona algo fascinante: estos árboles de lógica son como los mapas de seguridad de los aviones.

• En un avión, los ingenieros dibujan un árbol de lo que podría salir mal (fallo del motor, fallo del freno) para prevenirlo.
• Peng dibuja un árbol de lo que debe estar bien para que la conclusión sea cierta.
• Si el árbol muestra que "no hay valores extremos" y "la mediana es cercana al promedio", entonces la conclusión es segura. Si falta una rama, la conclusión es débil.

¿Por qué es esto importante para ti?

Imagina que lees un artículo médico que dice: "Este nuevo medicamento cura el dolor de cabeza".

• Hoy (Reproducible): Te dan el código y los datos. Tienes que descargarlos, ejecutarlos en tu computadora y esperar horas para ver si el código funciona. Si funciona, confías en el resultado.
• Mañana (Representación Formal): Te dan el "plano lógico". Puedes ver el árbol de argumentos:
  • Afirmación: El medicamento funciona.
  • Premisa 1: Los pacientes no tenían migrañas previas (verificado).
  • Premisa 2: No hubo efectos secundarios raros (verificado).
  • Premisa 3: La distribución de datos no estaba sesgada (verificado).

El beneficio mágico:
Puedes evaluar la calidad del argumento sin necesidad de tener los datos. Puedes ver el plano y decir: "Ah, veo que no verificaron si los pacientes tenían migrañas previas. ¡El edificio tiene un cimiento roto! No importa si el código funciona, la conclusión no es segura".

En Resumen

Roger Peng nos dice: "Dejemos de solo mostrar el resultado de la carrera (el código). Empecemos a mostrar el mapa del entrenamiento y la lógica del atleta (el razonamiento)."

Este sistema convierte la ciencia de datos en una estructura de lógica transparente, donde cada afirmación debe demostrar sus cimientos. No es solo una herramienta para repetir experimentos, es una herramienta para entender por qué un experimento es válido, incluso si nunca ejecutamos el código.

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo "Beyond Reproducible Research: Building a Formal Representation of a Data Analysis" de Roger D. Peng, presentado en español.

1. El Problema: Limitaciones de la Reproducibilidad Tradicional

El artículo identifica una brecha crítica en la práctica actual de la investigación estadística y de datos. Aunque el movimiento de "investigación reproducible" (compartir código y datos) ha sido fundamental, presenta limitaciones inherentes:

• Código como Programa vs. Código como Argumento: El código se escribe típicamente de manera imperativa (una secuencia de comandos para ejecutar acciones). Esto permite reproducir resultados, pero oculta el razonamiento lógico del analista, sus premisas, expectativas y suposiciones sobre los datos.
• Falta de Validación Estática: La simple ejecución exitosa de un programa no garantiza que el análisis sea correcto o que las afirmaciones sobre los datos sean verdaderas. Un programa puede ejecutarse sin errores y producir un resultado "sensible" que, sin embargo, se base en premisas falsas o datos mal interpretados.
• Dependencia de la Ejecución: Para verificar la validez de una afirmación en un análisis reproducible tradicional, un tercero debe volver a ejecutar el código sobre los datos. Esto es costoso en recursos, requiere acceso a los datos (a veces sensibles) y no permite evaluar la lógica del análisis sin los datos mismos.
• Ausencia de Prueba Formal: Las afirmaciones de análisis de datos (ej. "la media es 4.6") se asumen verdaderas sin una prueba formal explícita en el código, a diferencia de las afirmaciones matemáticas que se sustentan en demostraciones lógicas.

2. Metodología: Representación Formal Estática mediante Clases

El autor propone un cambio de paradigma: tratar el análisis de datos no como un programa para ejecutar, sino como una construcción lógica de afirmaciones que deben ser validadas. La metodología se basa en los siguientes pilares:

• Afirmaciones como Definiciones de Clases:

  • Se propone modelar las afirmaciones de análisis de datos como definiciones de clases en un lenguaje de programación (se utiliza R con el sistema de clases S4).
  • Una afirmación (ej. "La primera columna no tiene valores faltantes") se convierte en una clase. La creación exitosa de un objeto de esa clase constituye la "prueba" de que la afirmación es verdadera.
  • Cada clase incluye un método de validity (validez) que verifica explícitamente si los datos cumplen con la afirmación. Si la validación falla, el objeto no se crea y se lanza un error.

• Premisas como Extensiones de Clases:

  • Para apoyar una afirmación principal, se definen premisas (otras afirmaciones de análisis) que la sustentan.
  • Estas premisas se implementan como clases que se extienden de la clase principal o se incluyen como "slots" (compartimentos) dentro de ella.
  • Esto crea una jerarquía lógica: una afirmación final solo es válida si todas sus premisas (y las premisas de esas premisas) son válidas.

• Dos Fases de Construcción:

  1. Especificación: Definir la afirmación de análisis deseada como una clase.
  2. Vinculación: Conectar la afirmación con premisas de soporte (ya sea de forma directa o indirecta, descartando hipótesis alternativas).

• Análisis Estático:

  • Al tener las expectativas y definiciones explícitas en el código (en las definiciones de las clases), es posible realizar un análisis estático.
  • Se pueden inferir propiedades del resultado (ej. "si el código se ejecutó sin error, el resultado no puede ser NA") sin necesidad de ejecutar el código sobre los datos reales.

3. Contribuciones Clave

1. Externalización del Razonamiento: El sistema obliga al analista a hacer explícitas sus suposiciones y expectativas en el código, separando la lógica de la mera ejecución.
2. Evaluación sin Datos: Permite evaluar la calidad y la lógica de un análisis sin necesidad de tener acceso a los datos brutos, solo revisando la estructura de las clases y sus métodos de validez.
3. Visualización de la Estructura Lógica: La jerarquía de clases se puede visualizar como un árbol (similar a un árbol de fallas en ingeniería de sistemas), donde los nodos hijos representan premisas que deben ser verdaderas (lógica AND) para que el nodo padre (la conclusión) sea válido.
4. Detección de Errores Silenciosos: El enfoque ayuda a identificar errores comunes (como uniones de datos incorrectas debido a variaciones en nombres de columnas) antes de que se produzcan, al definir explícitamente qué debe parecer el resultado correcto (número de filas, columnas, ausencia de NA).
5. Análisis de Sensibilidad: Facilita la simulación de datos con características inesperadas (valores atípicos, sesgos) para probar si las premisas definidas son lo suficientemente robustas para "atrapar" estas anomalías.

4. Resultados y Ejemplos Demostrativos

El autor ilustra la metodología con varios ejemplos en R:

• Cálculo de la Media: Se demuestra cómo definir una clase para afirmar que "la media es 4.6". En lugar de solo calcularla, se construyen premisas que descartan que la media sea NA (no hay valores faltantes), Inf (no hay valores infinitos) o que la distribución esté sesgada (mediana cercana a 4.6, sin outliers).
• Unión de Data Frames (Join): Se muestra cómo definir una clase merged_dataset que valida que la unión tenga exactamente 3 filas y 4 columnas. Esto previene errores silenciosos donde una unión falla por diferencias en nombres (ej. "US" vs "USA") produciendo resultados incorrectos sin lanzar advertencias.
• Regresión Lineal Simple: Se aplica el marco a un modelo de regresión. La afirmación principal es el coeficiente de pendiente (1.79). Las premisas incluyen: ausencia de no linealidad (verificado mediante razón de verosimilitud), ausencia de outliers significativos y validación visual de gráficos de residuos (donde el analista debe confirmar manualmente que los gráficos son aceptables).

En todos los casos, el código resultante es más verboso que un script tradicional, pero contiene una semántica rica que describe el "por qué" y el "cómo" del análisis, no solo el "qué".

5. Significado e Impacto

El artículo propone un avance conceptual más allá de la simple reproducibilidad:

• De la Ejecución a la Verificación: Cambia el foco de "¿puedo ejecutar este código?" a "¿puedo verificar lógicamente este argumento?".
• Puente entre Estadística e Ingeniería de Software: Introduce conceptos de "Proposiciones como Tipos" (Propositions as Types) y pruebas formales en el análisis de datos, tratando las afirmaciones estadísticas como tipos de datos verificables.
• Mejora de la Calidad: Aunque el sistema no mejora automáticamente la calidad del análisis, proporciona una herramienta poderosa para que los analistas y revisores examinen la solidez del razonamiento, las suposiciones y la estructura lógica antes de confiar en los resultados.
• Adaptabilidad: Reconoce que la implementación actual (clases S4 en R) es demasiado verbosa para el uso diario, pero sugiere que el diseño de sistemas más eficientes para capturar esta lógica formal es un área de trabajo futura crucial para elevar el estándar de la ciencia de datos.

En resumen, Peng argumenta que para mejorar la confianza en los análisis de datos, debemos pasar de compartir solo el "cómo" (código) a compartir explícitamente el "por qué" (lógica y premisas) mediante representaciones formales que permitan la verificación estática y la evaluación crítica independiente.