Flujo de trabajo reproducible

1 · Definición

Un análisis es reproducible cuando otra persona, con los mismos datos y la documentación del trabajo, obtiene exactamente los mismos resultados.

2 · Por qué importa

Porque el “otro” sos vos. Dentro de seis meses, cuando el jurado pida rehacer un análisis con un caso más, nadie se va a acordar de qué se hizo. La reproducibilidad no es un gesto hacia la comunidad científica: es una forma de no perder el trabajo propio.

Porque los datos cambian. El INDEC corrige una serie, aparecen tres cuestionarios más, se detecta un error de carga. Si el análisis es un script, se vuelve a correr; si es una cadena de clics, se rehace a mano.

Porque es lo que permite revisar. Un resultado que no se puede verificar no se puede defender.

3 · Los cuatro requisitos

1 · La base cruda no se modifica. Es el principio del que se desprende todo lo demás. Los datos originales son de solo lectura; todas las transformaciones viven en código.

2 · Todo paso está en un script. Importar, limpiar, recodificar, analizar, graficar. Si un paso se hizo a mano, se rompió la cadena.

3 · Las rutas son relativas. read.csv("datos/base.csv") funciona en cualquier computadora; read.csv("C:/Users/jorge/...") solo en la tuya.

4 · El entorno está declarado. Qué versión del programa, qué paquetes. Es lo que más se omite y lo que explica que un script deje de funcionar dos años después.

Cómo se ve el problema de las versiones

No es que el script “deje de funcionar”. Eso sería lo bueno: un error se ve. Lo que pasa de verdad es peor.

LinearRegression de scikit-learn tiene un parámetro tol que decide cuándo descartar una dirección por ser numéricamente chica. Su historia:

Versión	Qué pasó
Hasta la 1.6	el parámetro no existía
1.7	se agrega tol, con valor por defecto $10^{-6}$
1.9	pasa a aplicarse también a datos densos

4 · Los tres niveles

Nivel	Qué significa	Cómo se logra
Repetible	Vos podés rehacerlo	Scripts en vez de clics
Reproducible	Otro llega al mismo resultado con tus datos	+ datos, documentación y rutas relativas
Replicable	Otro llega a la misma conclusión con datos nuevos	+ método documentado con todo detalle

El primero es el mínimo exigible en cualquier trabajo. El segundo es el estándar de una tesis seria. El tercero depende del fenómeno, no solo del método.

5 · Los enemigos

• Copiar y pegar entre programas. Cada copia es un paso que no queda registrado.
• Editar la planilla a mano. El cambio existe y nadie sabe cuál fue.
• Nombres como analisis_final_v3_ESTE_SI.xlsx. Señal inequívoca de que no hay control de versiones.
• Rutas absolutas.
• Resultados que se guardan pero no se regeneran. Si un gráfico se hizo una vez y se pegó, nadie puede saber si corresponde a la versión actual de los datos.
• Notebooks ejecutados fuera de orden. Un Jupyter donde las celdas se corrieron salteadas puede mostrar resultados que no se reproducen al correrlo de arriba abajo.

6 · El mínimo viable

Para una tesis no hace falta control de versiones ni contenedores. Alcanza con esto:

tesis/
├── datos/
│   ├── crudos/          ← no se toca nunca
│   └── procesados/      ← se regenera
├── scripts/
│   ├── 01-importar.R
│   ├── 02-limpiar.R
│   ├── 03-descriptivos.R
│   └── 04-graficos.R
├── salidas/             ← se regenera
└── README.txt           ← qué es cada cosa, en qué orden se corre

Y una regla: borrar datos/procesados/ y salidas/, correr los scripts en orden, y verificar que todo se reconstruya. Si funciona, el trabajo es reproducible. Si no, ahí está la parte que falta.

La prueba no es una figura retórica

Vale la pena hacerla de verdad y mirar el resultado, porque tiene una versión exigente: no alcanza con que los archivos se regeneren, tienen que salir idénticos. Corrida sobre el conjunto de scripts que produce los datos de este sitio:

Scripts corridos de cero	19
Terminaron sin error	19
Archivos de salida regenerados	18
Idénticos byte por byte	18

En la línea de comandos, la prueba entera son tres órdenes:

sha256sum salidas/* > antes.txt     # las huellas de lo que hay
rm -rf datos/procesados salidas     # borrar todo lo derivado
Rscript scripts/01-importar.R && Rscript scripts/02-limpiar.R  # y demás
sha256sum -c antes.txt              # ¿salió lo mismo?

7 · Errores frecuentes

• Confundir reproducible con prolijo. Un trabajo puede estar impecable y no ser reproducible.
• Dejar la documentación para el final. Se escribe mientras se hace, o no se escribe.
• No declarar las versiones de los paquetes. Y no por los scripts que se rompen —esos avisan— sino por los que siguen corriendo y dan otros números: LinearRegression de scikit-learn devuelve coeficientes distintos antes y después de la versión 1.9, en silencio.
• Dar por hecha la reproducibilidad sin hacer la prueba. Regenerar no alcanza: los archivos tienen que salir idénticos.
• Guardar resultados intermedios como si fueran datos. Todo lo que se puede regenerar se regenera.
• Creer que hace falta saber mucho. Cuatro scripts numerados y un README ya ponen el trabajo por encima de la mayoría.

8 · En el software

# R — declarar el entorno al final del script
sessionInfo()

# O, mejor, congelar las versiones del proyecto
renv::init()      # una vez
renv::snapshot()  # cada vez que se agrega un paquete

# Python
pip freeze > requirements.txt

@misc{estadistica_ar_flujo_de_trabajo_reproducible,
  author       = {Montivero, Jorge Luis},
  title        = {{Flujo de trabajo reproducible}},
  year         = {2026},
  howpublished = {\url{https://estadistica.ar/conceptos/flujo-de-trabajo-reproducible}},
  note         = {estadistica.ar. Consultado el \today},
  urldate      = {2026-09-27}
}