(no hace mucho tiempo) cuando ser un científico de datos significaba vivir en un cuaderno, ajustando hiperparámetros como si tu vida dependiera de ello, y en muchos casos, todo el proyecto, de hecho, dependía de ello.
¿Recuerdas esas búsquedas nocturnas en la red? ¿O construir tuberías de ingeniería que pareciera más arte que ciencia? ¿Y la satisfacción de obtener una precisión adicional del 0,7% de un modelo XGBoost?
En 2019, ¡ese era el trabajo de un científico de datos! Lo cual tenía sentido. Si querías un modelo sólido, tenías que construirlo tú mismo o trabajar duro para hacerlo bien. El valor real provino de qué tan bien se podían ajustar, optimizar y comprender los datos.
Ahora, lo “de última generación” está a solo una llamada de API. ¿Necesita un modelo de lenguaje superior? Hecho. ¿Necesita incrustaciones o razonamiento multimodal? También hecho. Las partes más difíciles del modelado ahora se manejan mediante puntos finales escalables, mucho más allá de lo que la mayoría de los equipos podrían construir por sí mismos.
La pregunta ahora es, si el modelo ya está ahí, ¿a dónde fue el trabajo?
El valor ya no está sólo en el modelo. Está en cómo todas las partes se conectan, comunican y adaptan. Ese cambio está remodelando por completo el papel de un científico de datos.
¿Cómo, preguntas? De esto se trata este artículo.
¿Qué cambió?
1. Omitir el método .fit()
Si observa el código de un proyecto de IA moderno, notará rápidamente que no hay mucho modelado real.
Es posible que vea una convocatoria para un LLM o un modelo de integración, pero ese rara vez es el principal desafío. El verdadero trabajo consiste en la ingesta de datos, el enrutamiento, el contexto de ensamblaje, el almacenamiento en caché, el monitoreo y el manejo de reintentos.
En otras palabras, usar .fit() es ahora una de las partes menos interesantes del código.
2. Adaptación a los nuevos componentes
Hoy en día, en lugar de centrarnos en los componentes internos del modelo, ensamblamos sistemas a partir de componentes prefabricados. Una pila de modelado típica ahora incluye:
Bases de datos vectoriales (p. ej., Pinecone, Milvus) Ingeniería rápida. Capas de memoria.
Además de funciones/llamadas de agentes. Cuando miramos el panorama general, vemos que este no es un modelo tradicional. Es el diseño del sistema. Una cosa importante a señalar aquí es que ninguno de estos componentes es particularmente útil por sí solo. Su poder proviene de cómo se organizan juntos.
3. Juntando todo
En este momento, la mayor parte del código de ciencia de datos trata de conectar las piezas. No se trata de álgebra lineal, optimización o incluso estadística.
Se trata de escribir código que mueva datos entre componentes, formatee entradas, analice salidas, registre interacciones y administre el estado en sistemas distribuidos.
Si mide su código, verá que solo del 10 al 20 por ciento se gasta usando un modelo (llamadas API, inferencia), mientras que del 80 al 90 por ciento se gasta en orquestación: manejo del flujo de datos, integración e infraestructura.
El cambio de científico de datos a arquitecto de IA
El mayor cambio de mentalidad actual es que ya no se trata simplemente de optimizar una función. Ahora está diseñando un sistema completo, pensando en la latencia, el costo, la confiabilidad y cómo las personas interactúan con él.
En lugar de preguntar “¿Cómo puedo mejorar el rendimiento del modelo?” Ahora nos preguntamos: “¿Cómo funciona todo este sistema en situaciones del mundo real?”
Sé lo que estás pensando: ¡este es un desafío completamente diferente! Fue incómodo para muchas personas, incluyéndome a mí, cuando ocurrió este cambio por primera vez.
Para mantenernos al día con la pila actual, necesitamos algo más que estadísticas y aprendizaje automático. Tenemos que sentirnos cómodos con las API (como FastAPI o Flask) para servir y enrutar, la contenedorización (como Docker) para la implementación, la programación asíncrona (usando Asyncio) para manejar múltiples solicitudes, la infraestructura de la nube para escalar y monitorear, y los conceptos básicos de ingeniería de datos para canalizaciones y almacenamiento.
Si cree que esto se parece mucho a la ingeniería de backend, tiene razón.
Este cambio ha desdibujado la línea entre científico de datos e ingeniero. Las personas a las que les va bien son aquellas que pueden trabajar cómodamente en ambas áreas.
Lo viejo versus lo nuevo
La pregunta clave ahora es: ¿cómo se ve este cambio en el código?
Proyecto Legacy (2019): Análisis de sentimiento
Muchos de nosotros hemos trabajado en proyectos como este. El proceso es sencillo:
Recopile un conjunto de datos etiquetados. Realizar ingeniería de características (TF-IDF, n-gramas). Clasificador de trenes (regresión logística, XGBoost). Ajuste los hiperparámetros. Implementar modelo.
El éxito aquí depende de la calidad de su conjunto de datos y su modelo.
Proyecto moderno (2026): Agente autónomo de comentarios de clientes
El proceso es diferente ahora. Para construir un sistema hoy, necesita:
Ingerir mensajes de clientes en tiempo real. Almacene incrustaciones en una base de datos vectorial. Recuperar el contexto histórico relevante. Construya indicaciones dinámicamente. Dirigirse a LLM con acceso a herramientas (p. ej., actualizaciones de CRM, sistemas de emisión de tickets) Mantener memoria conversacional. Supervisar la calidad y seguridad de los resultados.
¿Puedes detectar lo que falta? Aquí tienes una pista: no hay ningún circuito de entrenamiento.
Este ejemplo es simple a propósito, pero observe en qué nos centramos ahora. La recuperación es parte del sistema; el modelo es de una sola pieza y el valor proviene de cómo todo se conecta y funciona en conjunto.
Cómo empezar a pensar como un arquitecto de IA
Ahora que sabemos qué ha cambiado, hablemos de lo que realmente debería hacer de manera diferente. ¿Cómo puedes avanzar con este cambio en lugar de quedarte atrás?
La respuesta corta: empezar a construir sistemas, no sólo modelos.
La respuesta más larga: concéntrese en desarrollar estas habilidades:
1. Cree componentes integrales, no solo
En lugar de pensar “entrené un modelo”, apunte a “construí un sistema que recibe información, la procesa y devuelve un valor”. Ahora se trata del panorama general, no sólo de una tarea.
2. Aprenda el backend suficiente para ser peligroso
No es necesario que se convierta en ingeniero de backend a tiempo completo, pero debe saber lo suficiente para construir su sistema. Concentrarse en:
Poner en marcha una API simple (FastAPI es suficiente) Manejar solicitudes de forma asincrónica Registro y manejo de errores Implementación básica (Docker + una plataforma en la nube)
3. Siéntete cómodo con la ambigüedad
Los sistemas de IA modernos no son deterministas como los modelos tradicionales. Esto hace que sea más difícil trabajar con ellos, porque ahora no sólo estás depurando código; más bien, estás depurando el comportamiento.
Eso significa repetir las indicaciones, diseñar mecanismos alternativos y evaluar los resultados cualitativamente, no solo cuantitativamente.
4. Mida lo que realmente importa
La precisión ya no es siempre la métrica principal. Ahora, la latencia, el costo por solicitud, la satisfacción del usuario y la tasa de finalización de tareas son más importantes.
Un sistema que tiene una precisión del 95 % pero que no se puede utilizar en producción es peor que uno que tiene una precisión y confiabilidad del 85 %.
El pensamiento final
En nuestro campo, siempre existe la tentación de perseguir lo que parezca más “técnico”, el modelo más nuevo, el punto de referencia más importante, la arquitectura más llamativa.
¡Pero la parte más valiosa de este trabajo siempre ha sido y será siempre el lado humano! Que es entender el problema. Saber qué estamos tratando de resolver importa más que los datos o el modelo que utilizamos.
Hacer preguntas como: “¿Cuál es la necesidad aquí? ¿Qué le importa al usuario? ¿Qué significa realmente ‘bueno’ en contexto?” hace una gran diferencia en lo que construyes.
No puedes subcontratar ni ocultar esa parte detrás de una API. Y definitivamente no puedes automatizarlo.
Así que no se limite a fabricar el motor de un automóvil. Trate de ser la persona que comprenda hacia dónde debe ir el automóvil y luego construya el sistema para llevarlo allí.