Errores comunes del Data Scientist (y cómo dejar de repetirlos)

He visto repetirse el mismo patrón en tres equipos distintos. Un nuevo Data Scientist se incorpora, entrega un primer modelo limpio en seis meses y recibe el reconocimiento obligatorio en el all-hands. Luego, alrededor del mes nueve o doce, las ruedas dejan de girar. La promoción no llega. El PM guarda silencio. Una reorganización los ubica en un equipo "menos estratégico" y pasan el año siguiente preguntándose qué ocurrió.

Casi siempre es uno de siete errores. A veces dos o tres a la vez.

Esto no es una lista de "los mejores errores que hay que evitar". Es una lista de las cosas específicas que destruyen las carreras de DS entre los meses 6 y 18, cuando se agota la benevolencia de los primeros meses y las partes interesadas empiezan a esperar impacto real en el negocio. Cada error viene con un síntoma que puede detectar en usted mismo, un número real que hace concreto el costo, y una solución que puede ejecutar esta semana.

Por qué esto importa ahora

El primer año, tiene un pase libre. La gente es paciente. Espera la curva de aprendizaje. Puede entregar un notebook y llamarlo un entregable.

En los años dos y tres, eso desaparece. Se lo juzga por resultados de negocio entregados: modelos corriendo en producción, decisiones cambiadas, dólares ahorrados o generados. La brecha entre el Data Scientist que llega a Senior en 2-3 años y el que se estanca en IC2 rara vez es de IQ o destreza estadística. Casi todos en este nivel tienen el nivel técnico base. La brecha está en si evitaron esta lista.

Si lleva 6-18 meses en el rol y algo no encaja pero no puede nombrarlo, empiece aquí.

Error 1: empezar con el modelo, no con el problema

Síntoma. Abrió un notebook y empezó a extraer datos antes de escribir cuál decisión debía informar el modelo. Quizás ya eligió XGBoost. Quizás está pensando en si probar un transformer. El hilo de Slack con la parte interesada tiene tres mensajes.

El costo. Gartner y VentureBeat han publicado el mismo número deprimente durante años: el 60-70% de los proyectos de ML nunca llegan a producción. El trabajo técnico generalmente no es lo que los mata. La mayoría muere porque nadie enmarcó la decisión de negocio que el modelo debía informar, de modo que cuando el modelo está "listo", no hay lugar donde conectarlo. El dashboard que nadie abre. La puntuación en la que nadie actúa. Seis meses de su vida.

La solución. Antes de abrir un notebook, escriba un brief del problema de una página. No un ensayo de Confluence. Una página.

Qué decisión se está tomando y por quién
Cuál es el baseline actual (motor de reglas, intuición, el promedio del último trimestre)
Cómo se ve "mejor" en dólares o en un KPI de negocio
Quién actúa sobre el resultado del modelo y a través de qué superficie (dashboard, alerta, llamada API, correo electrónico)
Cuál es el costo de equivocarse, en ambas direcciones

Si no puede responder las cinco, aún no tiene un proyecto. Tiene una feria de ciencias. Vuelva a la parte interesada y tenga la conversación.

Error 2: construir en un notebook y tirarlo por encima de la pared

Síntoma. Su documento de entrega es un notebook de Jupyter con rutas hardcodeadas y una celda que dice df = pd.read_csv('/Users/sunombre/Downloads/data_v3_FINAL.csv'). El equipo de ingeniería cotiza 6-8 semanas para "productionizarlo". La mitad de su esfuerzo se va en reescribir su código para que realmente pueda ejecutarse en un horario.

El costo. La encuesta State of Data Science de Anaconda ha ubicado alrededor del 38% del tiempo de DS en preparación de datos y fricción de despliegue durante años. Las reescrituras de notebook a producción son el mayor bloque de esa fricción. Cada vez que ingeniería tiene que traducir su notebook a código de producción, agrega semanas al cronograma y hace que el equipo de ingeniería esté menos entusiasmado de trabajar con usted el trimestre siguiente.

La solución. Desde la semana uno de un proyecto, escriba código como si un compañero fuera a ejecutarlo mañana en una máquina diferente. Esto no es DevOps. Es higiene básica.

Extraiga la lógica de limpieza y características en módulos .py importables. El notebook los llama. No los redefine.
Fije las dependencias en un requirements.txt o pyproject.toml. No "lo que estaba en mi laptop en marzo."
Parametrice rutas y fechas. No /Users/sunombre/. No 2024-Q3 hardcodeado.
Use un archivo de configuración o variables de entorno para cualquier cosa que cambie entre desarrollo y producción.
Ejecute su propio código en un entorno limpio antes de entregarlo. Si falla para usted en una instalación limpia, fallará para ingeniería.

No necesita Kubernetes. Necesita código que alguien más pueda ejecutar sin agendar una videollamada.

Error 3: omitir el monitoreo en producción

Síntoma. El modelo se entregó. Pasó al siguiente proyecto. Tres meses después, los tickets de soporte se disparan. El equipo de customer success está gritando. Pasa dos días investigando y descubre que el modelo ha estado derivando silenciosamente desde la semana cuatro.

El costo. Estudios del sector ubican consistentemente la degradación del rendimiento de los modelos en un 20-40% en los primeros 6-12 meses para los modelos de negocio típicos sin reentrenamiento. El comportamiento del cliente cambia. Las fuentes de datos upstream cambian de esquema sin avisarle. Una nueva función del producto cambia la distribución de entrada. Sin monitoreo, se entera por las personas que se vieron afectadas: sus clientes y su parte interesada.

La solución. Entregue un dashboard de monitoreo la misma semana que entregue el modelo. No "después del próximo sprint". La misma semana.

Rastree el Population Stability Index (PSI) en sus 5-10 características principales. Alerta cuando PSI > 0.2.
Rastree la distribución de predicciones día a día. Un cambio repentino en la media o la forma es un indicador adelantado.
Rastree el KPI de negocio al que está vinculado el modelo (tasa de conversión, tasa de abandono, tasa de detección de fraude). Si el KPI deriva, necesita saberlo antes que el VP.
Establezca una cadencia de reentrenamiento. Trimestral es el mínimo para la mayoría de los modelos de negocio, mensual para cualquier cosa en un dominio de rápido movimiento.
Ponga su nombre y contacto en el dashboard. Hágase responsable.

Un modelo sin monitoreo es un pasivo, no un activo. Trátelo como tal.

Error 4: sobre-ingeniería de características

Síntoma. Su pipeline final tiene 200 características y una cadena de preprocesamiento de 12 pasos. El AUC pasó de 0.81 a 0.83. Está orgulloso. Su parte interesada no nota la diferencia.

El costo. Esas 180 características adicionales duplicaron el tiempo de entrenamiento, triplicaron la superficie de fallo en producción (cada característica es un posible nulo, ruptura de esquema o incidente upstream), y el lift que "ganó" está dentro de la banda de ruido de su conjunto de prueba. Ahora es responsable de mantener un pipeline frágil por un incremento del 2% en AUC que nadie solicitó.

La solución. Empiece lean. Agregue solo cuando la matemática lo justifique.

Abra con 10-20 características. Las que un experto del dominio nombraría en una reunión.
Agregue una característica solo cuando SHAP o la importancia por permutación demuestre que aporta más del 1% de lift en un conjunto separado.
Agregue una característica solo cuando a la parte interesada le importe ese 1%. Si el 1% del abandono son $50K, bien. Si son $500, descártela.
Cada característica que agrega es una promesa de mantenimiento. Si no puede comprometerse a mantenerla, no la agregue.
Ante la duda, ablate. Descarte las características de menor importancia y vea si algo realmente se rompe.

El nivel de Data Scientist Senior no es "mayor AUC". Es "mayor impacto en el negocio por unidad de complejidad del pipeline".

Error 5: reportar AUC sin una métrica de negocio

Síntoma. Su diapositiva de presentación dice "AUC 0.87, F1 0.74, log loss 0.21". Su parte interesada asiente con educación. Olvida que el proyecto existe en la siguiente revisión trimestral.

El costo. Cero dólares directos, pero el proyecto deja de financiarse porque nadie puede explicárselo al VP. Construyó algo que funciona y nadie sabe que funciona. Seis meses después, cuando el presupuesto se ajusta, el proyecto del que "no podíamos articular realmente el valor" es el primero en ser recortado.

La solución. Todo informe de modelo lidera con la métrica de negocio. Siempre.

Abra con los dólares o el KPI: "$2.1M en abandono evitado a este umbral", "14% de lift en precisión sobre el motor de reglas", "23% de reducción en contracargos por fraude".
Muestre la curva de compensación en términos de negocio. "Al umbral 0.4, detectamos el 80% del fraude y marcamos el 3% de las transacciones legítimas. Al umbral 0.6, detectamos el 60% y marcamos el 0.5%. Aquí está el costo de cada uno."
Vincule la métrica a un número que la parte interesada ya tenga en mente. Si viven por ARR, enmarque en ARR. Si viven por NPS, enmarque en NPS.
AUC, F1 y log loss van en el apéndice. Son para usted y su revisor de DS, no para el VP.
Cierre con la decisión que habilita el modelo, no con el modelo en sí.

Un informe de modelo que no lidera con valor de negocio es una actualización de estado, no un resultado.

Error 6: ignorar la calidad de los datos en el origen

Síntoma. Su notebook tiene 400 líneas de código de limpieza porque "los datos están desordenados". Lo ha explicado en los últimos tres standups. Está empezando a verse como la persona que sabe dónde están enterrados los cadáveres en la tabla de eventos de clientes.

El costo. El viejo número de IBM situó los costos de datos deficientes en $3.1 billones al año en toda la economía de EE. UU. A nivel de empresa, las encuestas muestran consistentemente que los equipos de DS gastan del 40% al 60% de su tiempo en limpieza. Ese es su tiempo. Su salario. Y cada regla de limpieza que escribe en su notebook es una regla que silenciosamente se pudrirá la próxima vez que cambie el esquema upstream, porque nadie más sabe que existe.

La solución. Trate cada regla de limpieza como un reporte de bug que le debe al equipo de ingeniería de datos.

Registre el bug. Una vez. Con una reproducción clara y el impacto ("esto afecta tres modelos en producción").
Deje de corregirlo en su notebook. Corrígalo upstream, en el pipeline de origen, donde todos los consumidores downstream se benefician.
Impulse contratos de datos en las tablas de las que depende. Esquema, nulabilidad, SLA de frescura, responsable.
Convierta la calidad de los datos en una métrica compartida. Si su equipo e ingeniería de datos tienen "frescura de datos" o "tasa de ruptura de esquema" en un dashboard, las correcciones ocurren más rápido.
Cuando ingeniería rechace ("no es prioridad este trimestre"), venga con el costo en dólares: horas de DS desperdiciadas, modelos degradados, decisiones bloqueadas.

La corrección en el notebook es un impuesto que paga para siempre. La corrección upstream es una inversión de una sola vez. Páguela una vez.

Error 7: decir "el modelo está bien, los datos están mal" sin corregir los datos

Síntoma. Ha usado alguna versión de esta oración en 3 o más standups: "El modelo funciona. Los datos de entrenamiento simplemente son malos." Lo dijo de nuevo en la revisión de la semana pasada. La parte interesada guardó silencio.

El costo. Usted, específicamente. En unos seis meses, las partes interesadas se dirigen a un DS que "realmente entrega". No lo invitan al próximo proyecto estratégico. No tiene la conversación de promoción. El modelo que "está bien" es el modelo en el que nadie confía en producción, lo que significa que no está bien.

La solución. Hágase responsable del pipeline completo. Punto.

El modelo es su responsabilidad, y el modelo incluye los datos que lo alimentan. No hay una línea limpia donde "su trabajo" termina y "el trabajo de ingeniería de datos" comienza cuando el resultado está roto.
Si los datos están mal, escale. No en Slack en voz pasiva. En un correo electrónico con un nombre y una fecha límite.
Escriba la especificación de cómo se ve "correcto". Rangos numéricos, frescura, esquema. No lo deje a la interpretación.
Participe en la revisión de ingeniería cuando se está alcanzando la corrección. Asegúrese de que estén resolviendo el problema correcto.
No lo suelte hasta que esté corregido en producción y verificado en su dashboard de monitoreo.

"No es mi problema" es una oración que termina carreras en esta etapa. El modelo no está bien si no funciona en producción. Hacer que funcione en producción es su trabajo.

El patrón detrás de los siete errores

Relea los siete errores. Todos son el mismo error.

Tratar la ciencia de datos como un trabajo de modelado en lugar de un trabajo de resultados de negocio.

El error 1 es "me enfoqué en el modelo, no en la decisión." El error 2 es "me enfoqué en el modelo, no en la entrega." El error 3 es "me enfoqué en el modelo, no en lo que pasa después del lanzamiento." El cuatro es "el modelo, no el costo de mantenimiento." El cinco es "el modelo, no los dólares." El seis es "el modelo, no los datos que lo alimentan." El siete es "el modelo, no el sistema a su alrededor."

El nivel de Data Scientist Senior es "entrega impacto de negocio medible." El nivel de IC2 para siempre es "produce modelos precisos que nadie usa." Observe a cualquier DS que haya llegado a Senior en 2-3 años en su equipo. Luego observe a uno que ha sido IC2 durante cuatro años. La brecha casi nunca es la matemática. Está en si trataron el modelo como el entregable, o como un componente de un sistema que realmente tiene que funcionar para el negocio.

Auditoría personal

Aplique esto a sus últimos 2-3 proyectos. Sea honesto. El objetivo no es sentirse mal, es saber dónde está.

Por cada proyecto, pregunte:

¿Escribí un brief del problema de una página antes de abrir un notebook?
¿Mi entrega a ingeniería fue código limpio en módulos importables, no un notebook con rutas hardcodeadas?
¿Entregué monitoreo la misma semana que entregué el modelo?
¿Mantuve las características lean, agregando solo cuando SHAP lo justificó Y a la parte interesada le importó?
¿Mi presentación lideró con la métrica de negocio, con AUC en el apéndice?
¿Registré los problemas de calidad de datos upstream, o solo los limpié en mi notebook?
Cuando los datos estaban mal, ¿me responsabilicé de la corrección de extremo a extremo?

Cuente los "no".

0-1 no's: Está en el camino correcto. Siga haciendo lo que está haciendo.
2-3 no's: Corrija el rumbo ahora. Elija el de mayor apalancamiento y corríjalo en su próximo proyecto.
4+ no's: Tenga una conversación real con su manager esta semana. Está a una reorganización de un equipo menos estratégico y probablemente ya lo siente.

Cómo se ve "lo bueno"

El DS que llega a Senior en 2-3 años no es más inteligente que usted. Simplemente ha internalizado una definición diferente del trabajo.

Comienza cada proyecto con un brief del problema, no con un notebook. Escribe código desde la semana uno como si ingeniería lo fuera a ejecutar el lunes. Entrega el monitoreo la misma semana que el modelo y lo revisa semanalmente. Mantiene las características lean y abla sin piedad. Lidera las presentaciones con dólares, no con AUC. Registra los problemas de calidad de datos upstream y los sigue hasta el final. Cuando los datos están mal, se responsabiliza de la corrección hasta que esté desplegada.

Esa persona entrega menos notebooks y más sistemas entregados, monitoreados y con impacto en el negocio. Las partes interesadas la incorporan al próximo proyecto estratégico antes de que termine el actual. El expediente de promoción se escribe solo, porque cada proyecto tiene una historia clara de "entregué X, impulsó Y en valor de negocio, aquí está el dashboard".

Puede ser esa persona. La mayor parte de la brecha son hábitos, no capacidad intelectual.

Playbooks del Data Scientist