Aprende cómo los modelos causales de Judea Pearl ayudan a equipos a explicar el comportamiento de la IA, depurar fallos y tomar decisiones de producto más claras, yendo más allá de las correlaciones.
Un equipo nota algo “obvio” en su dashboard: los usuarios que reciben más notificaciones vuelven con más frecuencia. Así que aumentan el volumen de notificaciones. Una semana después, la retención baja y suben las quejas por churn. ¿Qué pasó?
El patrón original era real, pero engañoso. Los usuarios más comprometidos naturalmente generan más notificaciones (porque usan el producto más) y también vuelven más. Las notificaciones no causaban la retención; el compromiso causaba ambos. El equipo actuó sobre una correlación y, sin querer, creó una peor experiencia.
El pensamiento causal es el hábito de preguntar: ¿qué causa qué, y cómo lo sabemos? En vez de quedarse en “estas dos cosas se mueven juntas”, intentas separar:
No se trata de desconfiar de los datos: se trata de ser específico con la pregunta. “¿Las notificaciones se correlacionan con la retención?” es diferente de “¿Enviar más notificaciones aumentará la retención?” La segunda pregunta es causal.
Este artículo se centra en tres áreas prácticas donde el reconocimiento de patrones suele fallar:
Esto no es un recorrido matemático pesado sobre inferencia causal. No necesitarás aprender la notación de do-calculus para obtener valor aquí. El objetivo es un conjunto de modelos mentales y un flujo de trabajo que tu equipo pueda usar para:
Si alguna vez lanzaste un cambio que “se veía bien en los datos” pero no funcionó en la realidad, el pensamiento causal es el eslabón que falta.
Judea Pearl es un científico de la computación y filósofo de la ciencia cuyo trabajo reformuló cómo muchos equipos piensan sobre datos, IA y toma de decisiones. Antes de su revolución causal, gran parte del “aprender de datos” en computación se centraba en asociaciones estadísticas: encuentra patrones, ajusta modelos, predice qué ocurrirá después. Ese enfoque es poderoso, pero a menudo falla cuando planteas una pregunta de producto o ingeniería que contiene la palabra porque.
El cambio central de Pearl fue tratar la causalidad como un concepto de primera clase, no como una intuición vaga encima de las correlaciones. En vez de preguntar solo “cuando X es alto, ¿Y también lo es?”, el pensamiento causal pregunta: “si cambiamos X, ¿cambiará Y?” Esa diferencia suena pequeña, pero separa la predicción de la toma de decisiones.
La asociación responde “qué tiende a ocurrir junto”. La causalidad apunta a responder “qué pasaría si intervinieras”. Esto importa en computación porque muchas decisiones reales son intervenciones: lanzar una función, cambiar rankings, añadir un guardián, alterar un conjunto de entrenamiento o ajustar una política.
Pearl hizo la causalidad más práctica al enmarcarla como una elección de modelo más suposiciones explícitas. No “descubres” causalidad automáticamente a partir de datos en general; propones una historia causal (a menudo basada en conocimiento del dominio) y luego usas datos para probarla, estimarla y refinarla.
Estas herramientas dieron a los equipos un lenguaje compartido para pasar del reconocimiento de patrones a responder preguntas causales con claridad y disciplina.
Correlación significa que dos cosas se mueven juntas: cuando una sube, la otra tiende a subir (o bajar). Es extremadamente útil—especialmente en equipos con muchos datos—porque ayuda con la predicción y la detección.
Si las ventas de helado aumentan cuando sube la temperatura, una señal correlacionada (temperatura) puede mejorar el pronóstico. En trabajo de producto e IA, las correlaciones potencian modelos de ranking (“muestra más de lo que usuarios similares clicaron”), detección de anomalías (“esta métrica suele seguir a aquella”) y diagnósticos rápidos (“los errores suben cuando la latencia sube”).
El problema empieza cuando tratamos la correlación como respuesta a una pregunta distinta: ¿qué pasa si cambiamos algo a propósito? Eso es causalidad.
Una relación correlacionada puede estar impulsada por un tercer factor que afecta a ambas variables. Cambiar X no necesariamente cambia Y, porque X podría no ser la razón por la que Y se movió en primer lugar.
Imagina que trazas gasto semanal en marketing contra ventas semanales y ves una fuerte correlación positiva. Es tentador concluir “más gasto causa más ventas”.
Pero supongamos que ambos suben durante las fiestas. La estación (un confusor) impulsa mayor demanda y también desencadena presupuestos más grandes. Si aumentas gasto en una semana no festiva, las ventas pueden no subir mucho—porque la demanda subyacente no está ahí.
Estás en territorio causal cuando te escuchas preguntar:
Cuando el verbo es cambiar, lanzar, eliminar o reducir, la correlación es una pista inicial, no la regla de decisión.
Un diagrama causal—a menudo dibujado como un DAG (grafo acíclico dirigido)—es una manera simple de hacer visibles las suposiciones de un equipo. En vez de discutir en términos vagos (“probablemente sea el modelo” o “quizá la UI”), pones la historia en el papel.
El objetivo no es la verdad perfecta; es un borrador compartido de “cómo creemos que funciona el sistema” que todos puedan criticar.
Supongamos que evalúas si un nuevo tutorial de onboarding (T) aumenta la activación (A).
Un reflejo común en analítica es “controlar por todas las variables disponibles”. En términos de DAG, eso puede significar ajustar accidentalmente por:
Con un DAG, ajustas variables por una razón: típicamente para bloquear caminos de confusión—no porque existan.
Empieza con una pizarra y tres pasos:
Incluso un DAG aproximado alinea producto, datos e ingeniería sobre la misma pregunta causal antes de correr números.
Un gran giro en el pensamiento causal de Judea Pearl es separar observar algo de cambiarlo.
Si observas que los usuarios que activan notificaciones retienen mejor, aprendiste un patrón. Pero aún no sabes si las notificaciones causan retención, o si los usuarios comprometidos simplemente son más propensos a activar notificaciones.
Una intervención es diferente: significa que fijas activamente una variable a un valor y preguntas qué ocurre después. En términos de producto, eso no es “los usuarios eligieron X”, es “lanzamos X”.
Pearl suele etiquetar esta diferencia como:
La idea de “do” es básicamente una nota mental de que estás rompiendo las razones habituales por las que una variable toma un valor. Cuando intervienes, las notificaciones no están activadas porque los usuarios comprometidos optaron; están activadas porque tú forzaste la configuración (o la impulsaste). Ese es el punto: las intervenciones ayudan a aislar causa y efecto.
La mayoría del trabajo real de producto tiene forma de intervención:
Estas acciones buscan cambiar resultados, no solo describirlos. El pensamiento causal mantiene la pregunta honesta: “Si hacemos esto, ¿qué cambiará?”
No puedes interpretar una intervención (ni diseñar un buen experimento) sin suposiciones sobre qué afecta qué—tu diagrama causal, aunque sea informal.
Por ejemplo, si la estacionalidad influye tanto en gasto de marketing como en registros, entonces “hacer” un cambio de gasto sin tener en cuenta la estacionalidad puede todavía engañarte. Las intervenciones son poderosas, pero solo responden preguntas causales cuando la historia causal subyacente es al menos aproximadamente correcta.
Un contrafactual es un tipo específico de “¿qué pasaría si?”: para este caso exacto, ¿qué habría ocurrido si hubiéramos tomado otra acción (o si una entrada hubiera sido distinta)? No es “¿qué pasa en promedio?”—es “¿este resultado habría cambiado para esta persona, este ticket, esta transacción?”
Los contrafactuales aparecen cuando alguien pide un camino a un resultado diferente:
Estas preguntas son de nivel usuario. También son lo suficientemente concretas para guiar cambios de producto, políticas y explicaciones.
Imagina un modelo de préstamos que rechaza una solicitud. Una explicación basada en correlaciones podría decir: “Ahorros bajos se correlacionan con rechazo.” Un contrafactual pregunta:
Si los ahorros del solicitante fueran $3,000 más altos (todo lo demás igual), ¿el modelo lo aprobaría?
Si la respuesta es “sí”, has aprendido algo accionable: un cambio plausible que invierte la decisión. Si la respuesta es “no”, evitas dar un consejo engañoso como “aumenta tus ahorros” cuando el verdadero bloqueo es la relación deuda-ingreso o historial laboral inestable.
Los contrafactuales dependen de un modelo causal—una historia sobre cómo las variables se influyen—no solo de un conjunto de datos. Debes decidir qué puede cambiar razonablemente, qué cambiaría como consecuencia y qué debe permanecer fijo. Sin esa estructura causal, los contrafactuales pueden convertirse en escenarios imposibles (“aumentar ahorros sin cambiar ingresos o gastos”) y producir recomendaciones inútiles o injustas.
Cuando un modelo ML falla en producción, la causa raíz rara vez es “el algoritmo empeoró”. Más a menudo, algo en el sistema cambió: qué datos se recolectan, cómo se producen las etiquetas o qué hacen los usuarios. El pensamiento causal te ayuda a dejar de adivinar y empezar a aislar qué cambio causó la degradación.
Algunos culpables recurrentes aparecen en muchos equipos:
Estos pueden parecer “bien” en dashboards agregados porque la correlación puede mantenerse alta aunque la razón por la que el modelo acierta haya cambiado.
Un diagrama causal simple (DAG) convierte la depuración en un mapa. Te obliga a preguntar: ¿esta feature es causa de la etiqueta, consecuencia de ella, o consecuencia de cómo medimos la etiqueta?
Por ejemplo, si Política de etiquetado → Ingeniería de features → Entradas del modelo, puede que hayas construido un pipeline donde el modelo predice la política en lugar del fenómeno subyacente. Un DAG hace visible esa vía para que puedas bloquearla (quitar la feature, cambiar la instrumentación o redefinir la etiqueta).
En vez de solo inspeccionar predicciones, prueba intervenciones controladas:
Muchas herramientas de “explicabilidad” responden una pregunta estrecha: ¿por qué el modelo dio esta puntuación? A menudo lo hacen destacando inputs influyentes (importancia de features, mapas de saliencia, valores SHAP). Eso puede ser útil, pero no es lo mismo que explicar el sistema donde el modelo reside.
Una explicación de predicción es local y descriptiva: “Este préstamo fue denegado principalmente porque el ingreso fue bajo y la utilización fue alta”.
Una explicación del sistema es causal y operativa: “Si aumentamos ingreso verificado (o reducimos utilización) de una forma que refleje una intervención real, ¿cambiaría la decisión y mejorarían los resultados downstream?”
La primera te ayuda a interpretar el comportamiento del modelo. La segunda te ayuda a decidir qué hacer.
El pensamiento causal vincula las explicaciones con intervenciones. En vez de preguntar qué variables se correlacionan con la puntuación, preguntas qué variables son palancas válidas y qué efectos producen al cambiarse.
Un modelo causal te obliga a ser explícito sobre:
Esto importa porque una “feature importante” puede ser un proxy: útil para predecir, peligrosa para actuar.
Las explicaciones post‑hoc pueden parecer persuasivas mientras se mantienen puramente correlacionales. Si “número de tickets de soporte” predice fuertemente churn, un plot de importancia puede tentar a un equipo a “reducir tickets” haciendo más difícil el acceso al soporte. Esa intervención podría aumentar churn, porque los tickets eran síntoma de problemas de producto—no la causa.
Las explicaciones basadas en correlación también son frágiles ante cambios de distribución: cuando el comportamiento de los usuarios cambia, las mismas features destacadas pueden dejar de significar lo mismo.
Las explicaciones causales son especialmente valiosas cuando las decisiones tienen consecuencias y rendición de cuentas:
Cuando necesitas actuar, no solo interpretar, la explicación necesita una columna vertebral causal.
El A/B testing es inferencia causal en su forma más simple y práctica. Cuando asignas usuarios aleatoriamente a la variante A o B, estás realizando una intervención: no estás observando solo lo que la gente eligió, estás fijando lo que ven. En términos de Pearl, la aleatorización hace real “do(variant = B)”—así, las diferencias en resultados pueden atribuirse con credibilidad al cambio, no a quién lo recibió.
La asignación aleatoria rompe muchos vínculos ocultos entre rasgos de usuario y exposición. Usuarios power, nuevos usuarios, hora del día, tipo de dispositivo—estos factores siguen existiendo, pero (en promedio) están balanceados entre grupos. Ese balance es lo que convierte una brecha métrica en una afirmación causal.
Incluso los mejores equipos no siempre pueden correr tests aleatorios limpios:
En estos casos, puedes seguir pensando causalmente—solo que debes ser explícito sobre suposiciones e incertidumbre.
Opciones comunes incluyen diferencia-en-diferencias (comparar cambios a lo largo del tiempo entre grupos), discontinuidad en regresión (usar una regla de corte como “solo usuarios con puntuación > X”), variables instrumentales (un empujón natural que cambia la exposición sin afectar directamente el resultado) y matching/weighting para hacer los grupos más comparables. Cada método cambia la aleatorización por suposiciones; un diagrama causal puede ayudarte a enunciar esas suposiciones claramente.
Antes de lanzar un test (o un estudio observacional), escribe: la métrica primaria, guardarraíles, población objetivo, duración y regla de decisión. La pre‑registración no eliminará el sesgo, pero reduce el cherry-picking de métricas y hace las afirmaciones causales más confiables—y más fáciles de debatir en equipo.
La mayoría de los debates de producto suenan así: “La métrica X subió después de que lanzamos Y—entonces Y funcionó.” El pensamiento causal lo afina a una pregunta clara: “¿El cambio Y causó que X se moviera, y cuánto?” Ese giro convierte dashboards de prueba en puntos de partida.
Cambio de precio: en vez de “¿Ingresos subieron tras el aumento de precio?”, pregunta:
Ajuste de onboarding: en vez de “Los nuevos usuarios completan más el onboarding ahora”, pregunta:
Cambio en ranking de recomendaciones: en vez de “CTR mejoró”, pregunta:
Los dashboards a menudo mezclan “quién recibió el cambio” con “quién lo habría hecho bien de todos modos”. Un ejemplo clásico: lanzas un nuevo flujo de onboarding, pero primero se muestra a usuarios con la versión de app más reciente. Si las versiones nuevas las adoptan usuarios más comprometidos, tu gráfica puede mostrar un aumento que es en parte (o mayormente) adopción de versión, no onboarding.
Otros confusores frecuentes en analítica de producto:
Una sección útil en el PRD puede titularse literalmente “Preguntas causales” e incluir:
Si usas un bucle de desarrollo rápido (especialmente con desarrollo asistido por LLM), esta sección es aún más importante: evita que “podemos lanzarlo rápido” se convierta en “lo lanzamos sin saber qué causó”. Los equipos que construyen en Koder.ai con frecuencia incorporan estas preguntas causales desde la planificación, implementan variantes con feature flags rápidamente y usan snapshots/rollback para mantener la experimentación segura cuando los resultados (o efectos secundarios) sorprenden.
PMs definen la decisión y criterios de éxito. Datos traducen eso en estimaciones causales medibles y chequeos de plausibilidad. Ingeniería asegura que el cambio sea controlable (feature flags, logging de exposición limpio). Soporte aporta señales cualitativas—los cambios de precio a menudo “funcionan” mientras aumentan silenciosamente cancelaciones o tickets. Cuando todos acuerdan la pregunta causal, lanzar se convierte en aprender—no solo en lanzar.
El pensamiento causal no necesita un despliegue de doctorado. Trátalo como un hábito de equipo: escribe tu historia causal, ponla a prueba, y deja que los datos (y experimentos cuando sea posible) confirmen o corrijan.
Para avanzar, reúne cuatro insumos desde el inicio:
En la práctica, la velocidad importa: cuanto más rápido conviertas una pregunta causal en un cambio controlado, menos tiempo gastarás discutiendo patrones ambiguos. Por eso algunos equipos adoptan plataformas como Koder.ai para pasar de “hipótesis + plan” a una implementación instrumentada (web, backend o móvil) en días en vez de semanas—manteniendo rigor con despliegues por etapas y rollback.
Si quieres un repaso sobre experimentos, ve a /blog/ab-testing-basics. Para trampas comunes en métricas de producto que imitan “efectos”, consulta /blog/metrics-that-mislead.
El pensamiento causal es un cambio de “¿qué tiende a moverse junto?” a “¿qué cambiaría si actuáramos?” Ese cambio—popularizado en computación y estadística por Judea Pearl—ayuda a los equipos a evitar historias sonoras que no resisten intervenciones reales.
La correlación es una pista, no una respuesta.
Los diagramas causales (DAGs) hacen las suposiciones visibles y discutibles.
Las intervenciones (“hacer/do”) son distintas de las observaciones (“ver/see”).
Los contrafactuales ayudan a explicar casos individuales: “¿qué pasaría si esto fuera distinto?”
El buen trabajo causal documenta incertidumbre y explicaciones alternativas.
La causalidad requiere cuidado: confusores ocultos, errores de medición y efectos de selección pueden invertir conclusiones. El antídoto es la transparencia—escribe las suposiciones, muestra qué datos usaste y señala qué refutaría tu afirmación.
Si quieres profundizar, explora artículos relacionados en /blog y compara enfoques causales con otros métodos de analítica y “explicabilidad” para ver dónde ayuda cada uno y dónde puede engañar.
La correlación te ayuda a predecir o detectar (por ejemplo: “cuando X sube, Y suele subir también”). La causalidad responde a una pregunta de decisión: “Si cambiamos X a propósito, ¿cambiará Y?”
Usa correlación para pronósticos y monitoreo; usa pensamiento causal cuando estés a punto de lanzar un cambio, fijar una política o asignar presupuesto.
Porque la correlación puede estar impulsada por confusión. En el ejemplo de notificaciones, los usuarios muy comprometidos tanto generan/reciben más notificaciones como vuelven con más frecuencia.
Si aumentas las notificaciones para todo el mundo, estás cambiando la experiencia (una intervención) sin cambiar el compromiso subyacente: la retención puede no mejorar y, en algunos casos, empeorar.
Un DAG (grafo acíclico dirigido) es un diagrama simple donde:
Es útil porque hace explícitas las suposiciones y ayuda a los equipos a ponerse de acuerdo sobre qué controlar, qué no controlar y qué experimento realmente respondería la pregunta.
Un error común es “controlar por todo”, lo que puede ajustar accidentalmente por mediadores o colisionadores y sesgar el resultado.
“Ver” es observar lo que ocurrió naturalmente (los usuarios optaron por algo, una puntuación fue alta). “Hacer” es fijar activamente una variable (lanzar una función, forzar un valor por defecto).
La idea clave: una intervención rompe las razones habituales por las que una variable toma un valor, y por eso puede revelar causalidad más fiablemente que la observación sola.
Un contrafactual pregunta: para este caso específico, ¿qué habría pasado si hubiéramos hecho otra cosa?
Es útil para:
Requiere un modelo causal para no proponer cambios imposibles.
Concéntrate en qué cambió aguas arriba y qué podría estar explotando el modelo:
Una mentalidad causal te impulsa a probar intervenciones dirigidas (ablaciones, perturbaciones) en lugar de perseguir movimientos métricos coincidentes.
No necesariamente. La importancia de una característica explica qué influyó en la predicción, no qué deberíamos cambiar.
Una variable “muy importante” puede ser un proxy o un síntoma (por ejemplo, tickets de soporte predicen churn). Intervenir sobre el proxy (“reducir tickets dificultando el acceso al soporte”) puede empeorar la retención. Las explicaciones causales vinculan la importancia con palancas válidas y los efectos esperados bajo intervención.
Los tests A/B aleatorizan y, por tanto, son ideales cuando se puede: rompen muchos vínculos ocultos entre rasgos de usuarios y la exposición.
Si no puedes aleatorizar (tráfico pequeño, efectos a largo plazo, interferencia, límites éticos u operativos), considera alternativas cuasi-experimentales: diferencia-en-diferencias, discontinuidad en regresión, variables instrumentales o matching/weighting—siempre explicitando las suposiciones.
Añade una sección corta que obligue a la claridad antes del análisis:
Esto mantiene al equipo alineado en una pregunta causal en lugar de contar historias post-hoc a partir del dashboard.
