6 habilidades técnicas que te convertirán en un científico de datos senior

Sea honesto. Escribir código en 2025 será mucho más fácil que hace diez o incluso cinco años.

Pasamos de Fortran a C y luego a Python, y cada paso redujo el esfuerzo necesario para que algo funcionara. Ahora herramientas como Cursor y GitHub Copilot pueden escribir texto estándar, refactorizar funciones y mejorar los procesos de codificación a partir de unas pocas líneas de lenguaje natural.

Al mismo tiempo, más personas que nunca se están involucrando en la inteligencia artificial, la ciencia de datos y el aprendizaje automático. Los gerentes de producto, analistas, biólogos, economistas, lo que sea, están aprendiendo a codificar, comprender cómo funcionan los modelos de IA e interpretar datos de manera eficiente.

Todo esto para decir esto:

No me malinterpretes. La diferencia sigue siendo técnica. Todavía depende de la comprensión de los datos, las estadísticas y los modelos. Pero ya no se trata de ser la persona que puede invertir un árbol binario en una pizarra o resolver un algoritmo en O(n).

A lo largo de mi carrera, he trabajado con destacados científicos de datos en diferentes campos. Con el tiempo, comencé a notar un patrón en la forma en que los profesionales de datos de alto nivel abordaban los problemas, y no se trataba de los modelos específicos que adoptaban o sus habilidades de codificación: se trataba del flujo de trabajo estructurado y organizado que adoptaban para convertir un producto inexistente en una solución sólida basada en datos.

En este artículo, describiré este flujo de trabajo de seis etapas que utilizan los científicos de datos sénior al desarrollar un producto o función de DS. Científico de datos sénior:

Mapee el ecosistema antes de tocar el código Piense en los productos DS como operadores Diseñe el sistema de extremo a extremo con “lápiz y papel” Comience de manera simple, luego gane el derecho a agregar complejidad Interrogue métricas y resultados Ajuste los resultados a las audiencias y seleccione las herramientas adecuadas para mostrar su trabajo

A lo largo del artículo iré ampliando cada uno de estos puntos. Mi objetivo es que, al final de este artículo, puedas aplicar estas seis etapas por tu cuenta para que puedas pensar como un científico de datos senior en tu trabajo diario.

¡Empecemos!

Mapeando el ecosistema

Lo entiendo, los profesionales de datos como nosotros nos enamoramos del “núcleo de ciencia de datos” de un producto. Disfrutamos ajustando modelos, probando diferentes funciones de pérdida, jugando con la cantidad de capas o probando nuevos trucos de aumento de datos. Después de todo, así es como fuimos entrenados la mayoría de nosotros. En la universidad, la atención se centra en la técnica, no en el entorno donde vivirá esa técnica.

Sin embargo, los científicos de datos sénior saben que en los productos reales, el modelo es sólo una pieza de un sistema más grande. A su alrededor hay todo un ecosistema donde es necesario integrar el producto. Si ignora este contexto, puede crear fácilmente algo inteligente que en realidad no importa.

Comprender este ecosistema comienza con preguntas como:

¿Qué problema exacto estamos mejorando y cómo se resuelve hoy? ¿Quién utilizará este modelo y cómo cambiará su trabajo diario? ¿Cómo se ve “mejor” en la práctica desde una perspectiva empresarial (menos tickets, más ingresos, menos revisión manual)?

En pocas palabras, antes de realizar cualquier codificación o diseño de sistema, es fundamental comprender qué aporta el producto.

Su respuesta, a partir de este paso, será la siguiente:

[My data product] tiene como objetivo mejorar la característica [A] para producto [X] en el sistema [Y]. El producto de ciencia de datos mejorará [Z]. esperas ganar [Q]mejorar [R]y disminuir [T].

Piense en los productos DS como operadores

Bien, ahora que tenemos una comprensión clara del ecosistema, podemos empezar a pensar en el producto de datos.

Este es un ejercicio de cambiar de silla con el usuario real. Si somos usuarios de este producto, ¿cómo es nuestra experiencia con el producto?

Para responder a nuestra pregunta, necesitamos responder preguntas como:

¿Cuál es una buena métrica de satisfacción (es decir, éxito/fracaso) del producto? ¿Cuál es el caso óptimo, el caso no óptimo y el peor de los casos? ¿Cuánto tiempo está bien esperar? ¿Son un par de minutos, diez segundos o tiempo real? ¿Cuál es el presupuesto para este producto? ¿Cuánto está bien gastar en esto? ¿Qué sucede cuando el sistema falla? ¿Recurrimos a una decisión basada en reglas, pedimos más información al usuario o simplemente mostramos “sin resultado”? ¿Cuál es el valor predeterminado más seguro?

Como podrá observar, nos estamos adentrando en el ámbito del diseño de sistemas, pero aún no hemos llegado allí. Esta es más bien la fase preliminar donde determinamos todas las restricciones, límites y funcionalidad del sistema.

Diseñe el sistema de principio a fin con “lápiz y papel”

Bien, ahora tenemos:

Una comprensión completa del ecosistema donde se ubicará nuestro producto. Una comprensión completa del rendimiento y las limitaciones del producto DS requerido.

Entonces tenemos todo lo que necesitamos para comenzar la fase de Diseño del sistema*.

En pocas palabras, utilizamos todo lo que hemos descubierto anteriormente para determinar:

La entrada y la salida La estructura de aprendizaje automático que podemos usar Cómo se construirán los datos de entrenamiento y prueba Las métricas que usaremos para entrenar y evaluar el modelo.

Las herramientas que puede utilizar para realizar una lluvia de ideas sobre esta parte son Figma y Excalidraw. Como referencia, esta imagen representa una parte del diseño del sistema (la parte del modelo/parte 2 de la lista anterior) usando Excalidraw.

Aquí es donde emergen las verdaderas habilidades de un científico de datos senior. Toda la información que ha acumulado hasta ahora debe converger en su sistema. ¿Tienes un presupuesto pequeño? Probablemente entrenar una estructura DL de parámetros 70B no sea una buena idea. ¿Necesitas baja latencia? El procesamiento por lotes no es una opción. ¿Necesita una aplicación de PNL compleja donde el contexto importa y tiene un conjunto de datos limitado? Quizás los LLM puedan ser una opción.

Tenga en cuenta que esto todavía es sólo “lápiz y papel”: todavía no se ha escrito ningún código. Sin embargo, en este punto, tenemos una comprensión clara de lo que necesitamos construir y cómo. AHORA, y sólo ahora, podemos empezar a codificar.

*El diseño de sistemas es un tema enorme en sí mismo y tratarlo en menos de 10 minutos es básicamente imposible. Si quieres ampliar esto, un curso que recomiendo mucho es este de ByteByteGo.

Empiece de forma sencilla y luego gane el derecho a añadir complejidad

Cuando un científico de datos senior trabaja en el modelado, los modelos de aprendizaje automático más sofisticados, potentes y sofisticados suelen ser los últimos que prueba.

El flujo de trabajo habitual sigue estos pasos:

Intente realizar el problema manualmente: ¿qué haría si usted (no la máquina) hiciera la tarea? Diseñe las características: según lo que sabe del punto anterior (1), ¿cuáles son las características que consideraría? ¿Puedes crear algunas características para realizar tu tarea de manera eficiente?

Comience simple: pruebe un modelo de aprendizaje automático tradicional razonablemente simple*, por ejemplo, un bosque aleatorio/regresión logística para clasificación o una regresión lineal/polinomial para tareas de regresión. Si no es lo suficientemente preciso, vaya ascendiendo.

Cuando digo “construye tu camino hacia arriba”, esto es lo que quiero decir:

En pocas palabras: sólo aumentamos la complejidad cuando es necesario. Recuerde: no intentamos impresionar a nadie con la última tecnología, intentamos crear un producto sólido y funcional basado en datos.

Cuando digo “razonablemente simple” me refiero a que, para ciertos problemas complejos, es posible que algunos algoritmos de aprendizaje automático muy básicos ya estén fuera de escena. Por ejemplo, si tiene que crear una aplicación de PNL compleja, probablemente nunca usará la regresión logística y es seguro comenzar desde una arquitectura más compleja de Hugging Face (por ejemplo, BERT).

Interrogar métricas y resultados

Una de las diferencias clave entre una figura senior y un profesional más joven es la forma en que ven el resultado del modelo.

Por lo general, los científicos de datos senior dedican mucho tiempo a revisar manualmente el resultado. Esto se debe a que la evaluación manual es una de las primeras cosas que hacen los gerentes de proceso (las personas con las que los científicos de datos senior compartirán su trabajo) cuando quieren comprender el rendimiento del modelo. Por esta razón, es importante que el resultado del modelo parezca “convincente” desde el punto de vista de la evaluación manual. Además, al revisar cientos o miles de casos manualmente, puede detectar los casos en los que falla su algoritmo. Esto le dará un punto de partida para mejorar su modelo si es necesario.

Por supuesto, eso es sólo el comienzo. El siguiente paso importante es elegir las métricas más oportunas para hacer una evaluación cuantitativa. Por ejemplo, ¿queremos que nuestro modelo represente adecuadamente todas las clases/opciones del conjunto de datos? Entonces, recordar es muy importante. ¿Queremos que nuestro modelo sea extremadamente preciso cuando realiza una clasificación, incluso a costa de sacrificar parte de la cobertura de datos? Entonces, estamos priorizando la precisión. ¿Queremos ambos? Las puntuaciones AUC/F1 son nuestra mejor apuesta.

En pocas palabras: los mejores científicos de datos saben exactamente qué métricas utilizar y por qué. Esas métricas serán las que se comunicarán internamente y/o a los clientes. No solo eso, esas métricas serán el punto de referencia para la próxima iteración: si alguien quiere mejorar su modelo (para la misma tarea), tiene que mejorar esa métrica.

Adapte los resultados a las audiencias y seleccione las herramientas adecuadas para mostrar su trabajo.

Recapitulemos dónde estamos:

Hemos mapeado nuestro producto DS en el ecosistema y definido nuestras limitaciones. Hemos construido el diseño de nuestro sistema y desarrollado el modelo de aprendizaje automático. Lo hemos evaluado y es lo suficientemente preciso.

Ahora finalmente ha llegado el momento de presentar nuestro trabajo. Esto es crucial: la calidad de su trabajo es tan alta como su capacidad para comunicarlo. Lo primero que tenemos que entender es:

¿A quién le mostramos esto?

Si le mostramos esto a un científico de datos del personal para la evaluación del modelo, o se lo mostramos a un ingeniero de software para que pueda implementar nuestro modelo en producción, o a un gerente de producto que deberá informar el trabajo a roles de decisión más altos, necesitaremos diferentes tipos de entregas.

Esta es la regla general:

Se proporcionará una descripción general del modelo de muy alto nivel y los resultados de las métricas a los gerentes de producto. Se mostrará una explicación más detallada de los detalles del modelo y las métricas al personal científico de datos. Se entregarán detalles muy prácticos, a través de scripts de código y cuadernos, a los superhéroes que pondrán este código en producción: los ingenieros de software.

Conclusiones

En 2025, escribir código no es lo que distingue a los científicos de datos senior de los junior. Los científicos de datos senior no son “mejores” porque conocen la documentación de tensorflow que tienen en la cabeza. Son mejores porque tienen un flujo de trabajo específico que adoptan cuando crean un producto basado en datos.

En este artículo, explicamos el flujo de trabajo estándar del científico de datos senior a través de un proceso de seis capas:

Una capa de comunicación para ajustar la entrega a la audiencia (historia de PM, rigor de DS, artefactos listos para ingenieros) Una forma de mapear el ecosistema antes de tocar el código (problema, línea de base, usuarios, definición de “mejor”) Un marco para pensar en características de DS como operadores (latencia, presupuesto, confiabilidad, modos de falla, configuración predeterminada más segura) Un proceso de diseño de sistema liviano de lápiz y papel (entradas/salidas, fuentes de datos, bucle de entrenamiento, bucle de evaluación, integración) Un flujo de trabajo de modelado que comienza simple y agrega complejidad solo cuando es necesario Un método práctico para interrogar resultados y métricas (primero revisión manual, luego la métrica correcta para el objetivo del producto) Una capa de comunicación para ajustar la entrega a la audiencia (historia de PM, rigor de DS, artefactos listos para ingenieros)

Antes de salir

Gracias de nuevo por tu tiempo. Significa mucho ❤️

Mi nombre es Piero Paialunga y soy este chico:

Soy originario de Italia, tengo un doctorado. de la Universidad de Cincinnati y trabaja como científico de datos en The Trade Desk en la ciudad de Nueva York. Escribo sobre IA, aprendizaje automático y la evolución del papel de los científicos de datos tanto aquí en TDS como en LinkedIn. Si te gustó el artículo y quieres saber más sobre el aprendizaje automático y seguir mis estudios, puedes:

R. Sígueme en Linkedin, donde publico todas mis historias.
B. Sígueme en GitHub, donde podrás ver todo mi código.
C. Si tiene preguntas, puede enviarme un correo electrónico a [email protected]