El informe para el comité, y el cierre de la carrera

## Viernes, 9:00. La historia en una figura y una página

El comité de Growth se reúne a mediodía. No van a ver tu notebook, ni tu AUC, ni la validación cruzada: van a ver una figura y van a oír una recomendación en euros. Todo el trabajo de la semana —definir el target, separar la población, entrenar los dos modelos, cruzar las listas, hacer la cuenta— se condensa hoy en algo que una persona de negocio entiende en treinta segundos. Esa condensación no es un adorno: es la última milla del trabajo, la que decide si el proyecto cambia algo o se queda en una carpeta.

La figura que lo cuenta todo tiene dos paneles: a quién marca cada lista (la ingenua, alta y casi toda no accionable; la reformulada, baja y accionable entera) y el retorno de cada campaña (la ingenua en negativo, la reformulada en positivo). Con esos dos paneles no hace falta explicar qué es un AUC: se ve que la lista grande cuesta más y retiene menos. Y el mensaje de una línea que acompaña la figura es el del caso: «la lista que pedíamos habría costado 6.810 euros y perdido 4.578; la reformulada cuesta 1.730 y gana 4.498, marcando a una cuarta parte de la gente».

## La conversación con Nerea

Nerea entra a la reunión queriendo su lista grande. Es el momento delicado del caso: le trajiste una reformulación de lo que ella pidió, y hay que defenderla sin que suene a que ignoraste su encargo. La clave no es decirle que su pregunta estaba mal; es enseñarle que respondiste a lo que de verdad quería. Nerea no quería «una lista de 681 personas»: quería retener clientes gastando bien el presupuesto. Y eso es exactamente lo que le llevas, solo que la lista que lo consigue es más pequeña de lo que esperaba. Cuando lo ve en euros, no hay discusión: nadie en un comité aprueba la opción que pierde 4.578 euros frente a la que gana 4.498.

## El entregable: el repositorio y el README

Lo que ha quedado de la semana es un repositorio completo: cinco scripts numerados que van de explorar los datos crudos a sacar las figuras del informe, la carpeta sql con las consultas que definen el target y la población, los datos, el requirements.txt y el README. Ese README es el entregable intelectual, no un trámite: cuenta qué hace el proyecto, cómo se corre, y —lo importante— el hallazgo honesto. No «entrené un modelo con 0,73 de AUC», sino «la pregunta que me trajeron estaba mal planteada; responderla tal cual habría costado dinero; reformularla en tres pasos cambió una campaña ruinosa en una rentable».

1retencion-marea/
2├── README.md            ← el hallazgo honesto, lo escribes hoy
3├── requirements.txt     ← pandas, numpy, scikit-learn, matplotlib, duckdb
4├── datos/               ← clientes.csv, actividad_mensual.csv, tabla_modelado.csv
5├── sql/                 ← definición del target y de la población accionable
6└── src/
7    ├── 01_explorar.py   ← los cuatro estados, el cero que no es nulo
8    ├── 02_target.py     ← el target de dos formas, la población accionable
9    ├── 03_modelar.py    ← un modelo por encuadre, el AUC engañoso, las listas
10    ├── 04_evaluar.py    ← la cuenta de dinero y la sensibilidad
11    └── 05_informe.py    ← las figuras del comité

## Ocho casos, y la pieza que lo gobierna todo

Este era el último encargo de tu rodaje, y no es casualidad que el cierre sea este. En los siete anteriores aprendiste el oficio técnico: desconfiar de una columna que lo sabe todo, mirar la forma de los datos, medir donde duele con una clase rara, no filtrar el futuro al partir, escalar bien, cazar el que memoriza, poner el umbral por su coste. Todo eso es necesario, y lo dominas. Pero este caso te ha enseñado la pieza que gobierna a todas las demás: ninguna de esas habilidades sirve de nada si estás respondiendo a la pregunta equivocada. Puedes partir perfecto, calibrar perfecto, elegir el umbral perfecto, y aun así entregar algo inútil, porque el fallo estaba antes de todo eso, en la pregunta.

Por eso Darío repite que el error más caro no es entrenar mal un modelo, es entrenar perfectamente el modelo que responde a la pregunta equivocada: eso no lo caza ninguna validación cruzada, porque la validación cruzada da por buena la pregunta. La única defensa es la que has practicado esta semana: antes del primer fit(), parar y preguntarte qué significa de verdad lo que te piden, sobre quién tiene sentido actuar, y qué decisión se va a tomar con tu respuesta. El trabajo más importante del data scientist ocurre antes del primer fit(). Con eso cierras ocho casos. Ya no eres el que abría el primer notebook con las manos sudando: eres quien hace la pregunta que nadie más en la sala hace.