Herramientas y tech stack del Data Scientist: la guía honesta de 2026

Déjeme describirle el stack que la mayoría de los equipos de ciencia de datos realmente tiene, incluso los que tienen empresas con ARR de ocho cifras detrás.

Un notebook de Jupyter en la laptop de alguien. Un CSV en S3 con un nombre como clientes_FINAL_v3_usar_esto.csv. Un model.pkl que alguien le envió a un ingeniero de backend por Slack hace tres trimestres. Un dashboard de Looker en el que nadie confía porque los joins siguen cambiando silenciosamente. Una página de Confluence titulada "Arquitectura de ML" que fue editada por última vez el día antes de que renunciara el anterior director de datos.

Si este es su stack, no está atrasado. La mayoría de los equipos está aquí. La pregunta honesta no es si su configuración es vergonzosa. Es si se queda aquí o si hace el trabajo aburrido para salir.

Esta guía es para el Data Scientist IC (no para el VP, no para el equipo de plataforma) que necesita construir un stack desde cero o auditar el desastre con cinta adhesiva que heredó. Recorreremos las 6 capas principales, nombraremos los valores predeterminados de código abierto, nombraremos las alternativas de pago y diremos claramente cuándo cada una vale la pena. Si desea contratar correctamente para este rol, la plantilla de JD de Data Scientist es la pieza complementaria.

Por qué esto importa ahora

Los modelos en notebooks no generan dinero. La brecha entre "entrené un modelo con AUC 0.87" y "el negocio usa esta predicción todos los días para tomar una decisión" es aproximadamente un 80% de herramientas y un 20% de ciencia. A nadie le gusta escuchar eso, especialmente al DS que pasó tres años en un doctorado en estadística, pero es verdad.

El Data Scientist que puede montar el stack completo desde el almacén hasta el monitoreo es el que es promovido, consigue headcount, obtiene presupuesto y deja de ser tratado como un centro de costos que ejecuta SQL. El que no puede es el que sigue entregando notebooks y se pregunta por qué el próximo recorte tiene su nombre.

No tiene que amar MLOps. Sí tiene que estar al tanto de él.

Los Core 6: lo que todo stack de ML realmente necesita

Seis capas. Precios reales. Cuándo vale la pena cada una.

Repasemos cada una, porque la tabla es el resumen, no el argumento.

Capa de almacén / datos

Snowflake, BigQuery o Databricks SQL. Elija el que su equipo de ingeniería de datos ya paga. Si no hay equipo de ingeniería de datos y está eligiendo desde cero, BigQuery es el más barato para empezar (pago por consulta a $6.25/TB escaneado, sin costo de almacén inactivo) y Snowflake es el más fácil de compartir con analistas no técnicos.

El error que veo semanalmente: un equipo de DS intentando "ahorrar dinero" entrenando modelos directamente desde Parquet en S3 sin capa de almacén, cada trabajo re-lee 200 GB y reescribe esquemas en Pandas. Eso no es ahorrar dinero. Eso es quemar horas de DS, que cuestan diez veces más que los créditos del almacén que evitó. Compre el almacén. Use dbt para transformar dentro de él. Entrene con tablas curadas.

Notebook / IDE

Jupyter es gratuito, local y funciona bien para trabajo individual. Para equipos de tres o más, los notebooks colaborativos (Hex a $40-$80/usuario/mes, Deepnote algo más barato) justifican su costo porque ponen SQL, Python y un artefacto publicable en un solo lienzo. Las partes interesadas pueden leer un documento de Hex; no pueden leer su analysis_v7_final.ipynb.

Los Databricks Notebooks se incluyen con el cómputo de Databricks. Si ya paga por el cómputo, los notebooks están bien. Si no, está pagando el precio de la plataforma Databricks por lo que es esencialmente un Jupyter alojado, y esa matemática no funciona.

Opción infravalorada: VS Code más la extensión de Jupyter. Gratuito, rápido, tiene git real, depurador y extensiones. La mayoría de los Data Scientists senior que respeto lo usan para trabajo serio y reservan los notebooks alojados para exploración y compartir con partes interesadas.

Seguimiento de experimentos

Esta es la capa donde la mayoría de los equipos tiene tres herramientas porque nadie decidió. Elija una.

MLflow es open-source y puede alojarse en una VM pequeña por alrededor de $50/mes. La UI de seguimiento es funcional. El registro de modelos es operativo. Pasará quizás un día de ingeniería configurándolo y unas pocas horas por trimestre manteniéndolo.

Weights & Biases tiene la UI más bonita de la categoría, la más fácil de compartir con partes interesadas y vale la pena pagar (entre $20 y $100 por usuario al mes según el nivel) si ejecuta más de veinte experimentos por semana o si su equipo realmente usa las herramientas de comparación. Si dos personas ejecutan tres experimentos por trimestre, MLflow es suficiente y W&B es excesivo.

Neptune.ai es la alternativa más barata a W&B con la mayoría de las mismas funciones. Vale la pena revisarlo si el precio de W&B le asusta.

Sea lo que sea que elija, elimine los demás. El peor stack de seguimiento de experimentos es el que Alice usa W&B, Bob usa MLflow y el nuevo contratado abre TensorBoard porque eso era lo que tenía en su trabajo anterior.

Almacén de características

Feast es open-source y gratuito en dólares. No es gratuito en horas. Tiene que alojar Redis (u otro almacén en línea), configurar el registro, escribir los trabajos de materialización y mantener todo en funcionamiento. Para un equipo de dos personas con tres modelos en producción, Feast es infraestructura teórica y un proyecto dbt bien organizado hace el mismo trabajo con una décima parte del mantenimiento.

Tecton es la opción empresarial de pago. El precio de entrada es de seis cifras. Solo se justifica si tiene 50+ modelos en producción con reutilización real de características entre equipos. Un equipo de dos personas comprando Tecton es la señal más clara posible de mala asignación de capital en este campo.

Databricks Feature Store se incluye si ya está en Databricks. Úselo si es así. No cambie de plataforma para obtenerlo.

Opinión honesta: la mayoría de los equipos con menos de diez modelos en producción todavía no necesitan un almacén de características. Necesitan pipelines de características limpios en dbt y una convención de nomenclatura. Posponga la capa del almacén de características hasta que el dolor de duplicar características en cinco trabajos de entrenamiento sea más alto que el dolor de montar Feast.

Servicio del modelo

La capa de servicio es donde la mayoría de los stacks están sobre-ingeniados. Cuatro opciones reales:

SageMaker es nativo de AWS, complejo y cuesta alrededor de $0.05 a $2 por hora por endpoint según la instancia. Es la respuesta correcta si ya usa AWS intensamente y tiene un ingeniero de plataforma para gestionar endpoints. Es la respuesta incorrecta si es un equipo de dos DS y solo quiere un modelo detrás de un endpoint HTTP.

Vertex AI es el equivalente de GCP. Precio similar, complejidad similar, advertencias similares.

Modal es GPU serverless. Paga por segundo de cómputo. Es excelente para inferencia variable (recomendaciones en un sitio de bajo tráfico, trabajos de puntuación por lotes, cualquier cosa donde de otro modo pagaría por un endpoint inactivo). La experiencia del desarrollador es la mejor de la categoría. Es mi recomendación predeterminada para configuraciones individuales y de equipos pequeños.

BentoML es un framework open-source. Escribe su lógica de inferencia, BentoML la empaqueta y despliega el paquete en Kubernetes (o Modal, o Lambda, o donde sea). Combínelo con Modal y tendrá un stack de GPU serverless a precios de startup.

La combinación de Modal más BentoML es lo que construiría hoy si estuviera empezando un equipo de DS desde cero sin equipo de plataforma. SageMaker es lo que confirma cuando tiene un equipo de plataforma y un contrato de adquisición que ya incluye créditos de AWS.

Monitoreo y detección de deriva

Si tiene modelos en producción y sin monitoreo, no tiene modelos en producción. Tiene bombas de tiempo puntuadas por AUC.

Evidently es open-source, ejecutable como librería de Python o como servicio independiente. Es el punto de partida correcto. Puede integrarlo en un notebook y tener informes básicos de deriva funcionando en una tarde.

WhyLabs tiene un nivel gratuito que escala. Buena opción si quiere un dashboard alojado sin el presupuesto para Arize.

Arize es la opción seria de pago, $1k-$10k/mes para volumen de producción. Vale la pena pagar una vez que tenga más de cinco modelos en producción o cualquier requisito regulatorio (servicios financieros, atención médica, cualquier cosa con auditores).

Empiece con Evidently gratuito. Actualice cuando el número de modelos en producción o la presión de cumplimiento lo justifique. No compre Arize antes de tener un modelo que necesite monitoreo.

La pregunta de la fuente única de verdad (donde la mayoría de los stacks de DS se pudren)

Basura entra, basura sale. Ya lo sabe. Lo que quizás no ha internalizado es de dónde viene la mayoría de la basura de etiquetas: el sistema de registro operativo. El CRM. La herramienta de tickets. La configuración de análisis del producto que tres PMs diferentes configuraron de tres maneras distintas en dos reorganizaciones.

Si su etiqueta "el cliente abandonó" viene de un CRM donde el representante de ventas A marca un deal "Cerrado Perdido - Sin Decisión", el representante B marca la misma situación "Perdido - Competidor" y el representante C simplemente borra el deal, ningún nivel de seguimiento en MLflow lo salva. Su modelo de abandono está aprendiendo los hábitos inconsistentes de higiene de datos de sus representantes, no el comportamiento del cliente.

Un sistema de registro operativo limpio importa más que un almacén de características elegante. No es glamoroso. No le consigue una charla en una conferencia. Pero el Data Scientist que pasa una semana corrigiendo las definiciones de etapa del pipeline y forzando la validación de campos obligatorios en el CRM entrega mejores modelos durante los próximos dos años que el que cambia de almacén de características tres veces.

Rework CRM a $12/usuario/mes le brinda etapas de pipeline estructuradas, campos personalizados con validación, un registro de eventos que puede transmitir a su almacén de datos y una fuente única de verdad para el ciclo de vida del cliente del que dependen sus modelos de abandono y conversión. Cualquiera que sea el CRM que use, el principio aplica: la calidad de los datos upstream decide la calidad del modelo downstream. Corríjala antes de ajustar otro hiperparámetro.

Construir vs. comprar: el árbol de decisión real

Aquí está la matriz. Encuentre su fila, construya en consecuencia. No se salte niveles.

No se salte niveles. Los dos errores de stack más comunes que veo, en orden:

1. El equipo de dos personas que compró Tecton porque alguien vio una charla en una conferencia.
2. El equipo de ocho personas que todavía ejecuta todo desde la laptop de un fundador porque "aún no necesitamos MLOps".

Ambos son malos. El primero es sobre-inversión sin retorno. El segundo es sub-inversión que sangra productividad y credibilidad cada semana.

La auditoría de 30 días del stack

Concreto, semana a semana. Ejecútelo si heredó un desastre o si lo construyó usted mismo.

Días 1-3: inventario de lo que está realmente desplegado

No lo que está en la diapositiva de arquitectura. Lo que está realmente corriendo. Abra cada cron, cada Airflow DAG, cada endpoint de SageMaker, cada notebook en un horario. Haga una hoja de cálculo. Columnas: herramienta, responsable, costo mensual, porcentaje del equipo que la usa, fecha de último uso, matar-conservar-actualizar.

Encontrará al menos tres cosas que no sabía que existían.

Días 4-7: encuentre cada modelo en producción

Por cada modelo: quién es su responsable, con qué datos entrena, cuándo fue reentrenado por última vez, cuál es su métrica de rendimiento actual y si alguien notaría si dejara de correr.

Si nadie lo notaría, mátelo. Si nadie es el responsable, ese es ahora su problema para asignar.

Días 8-14: añada monitoreo al modelo peor monitoreado

Elija el modelo con mayor impacto en el negocio y peor monitoreo. Agréguele Evidently esta semana. No tiene que ser bonito. Un informe semanal de deriva enviado por correo a un canal es suficiente para empezar.

Días 15-21: consolide el seguimiento de experimentos

Elija una herramienta. Migre los experimentos activos. Dígale al equipo que deje de usar las demás. Archive el resto. Esto será políticamente más difícil de lo que suena porque la persona que configuró la herramienta que está eliminando se lo tomará de forma personal. Hágalo de todas formas.

Días 22-30: documente el stack en un solo README

Un único README en el repositorio del equipo. Diagrama de arquitectura (cajas y flechas, no una obra maestra de Visio). El propósito, el responsable y el acceso de cada herramienta. El procedimiento de guardia para cada modelo en producción. La próxima contratación de DS debería poder leer esto en una hora y saber qué está heredando.

Después de 30 días, puede responder en una oración: cada modelo en producción, quién es su responsable, cuándo fue reentrenado por última vez, cómo se ve su deriva actual y qué herramienta cortaría mañana. Si no puede responder eso, la auditoría no está terminada.

Errores comunes

Los más frecuentes, aproximadamente en el orden en que los veo:

• Comprar herramientas antes de tener modelos en producción. "Necesitamos un almacén de características." ¿De verdad? ¿Tiene características? ¿Tiene un modelo que las usa? No compre infraestructura para un futuro que aún no ha construido.
• Alojar MLflow sin presupuestar tiempo de mantenimiento. Es gratuito en dólares. No es gratuito en horas. Alguien tiene que mantener la VM parchada, la base de datos respaldada y la autenticación funcionando. Si ese alguien es usted y también tiene que entregar modelos, la matemática puede favorecer la opción gestionada.
• Dejar que cada DS elija su propia herramienta. "Usamos lo que usaban en su trabajo anterior" es como termina con tres rastreadores de experimentos, dos almacenes de características y un documento de incorporación de 40 páginas.
• Construir una "plataforma" antes de tener tres modelos que la justifiquen. La trampa del equipo de plataforma de uno. No generalice hasta que tenga cosas específicas de las que generalizar.
• Ignorar el CRM y la capa de datos operativos porque "no es ML". Es la capa que decide si sus etiquetas son reales. Es la base del ML, no el vecino del ML.

Plantillas que vale la pena construir

Cuatro artefactos para mantener en el repositorio de su equipo:

1. Hoja de cálculo de auditoría del stack. Herramienta, costo mensual, responsable, porcentaje del equipo que la usa, fecha de último uso, decisión de matar-conservar-actualizar.
2. Inventario de "lo que está realmente en producción". Modelo, responsable, fuente de datos de entrenamiento, último reentrenamiento, estado del monitoreo, impacto en el negocio, procedimiento de guardia.
3. Matriz de decisión construir vs. comprar. La tabla de este artículo, personalizada para el stack específico de su equipo.
4. Estructura de repositorio del stack mínimo viable. Un ejemplo funcional de MLflow más BentoML más Evidently conectados, para que la próxima contratación de DS pueda clonarlo y entregar un modelo en su primera semana.

La conclusión

La parte más difícil de un stack de ML no es el ML. Es la capa upstream aburrida (etiquetas limpias, eventos limpios, una fuente de verdad) y la capa downstream aburrida (monitoreo que realmente consulta). La parte media (qué modelo, qué almacén de características, qué framework de servicio) recibe más atención y importa menos.

Las herramientas importan. La disciplina del stack importa más. El DS que ejecuta la auditoría de 30 días, elimina dos herramientas redundantes y escribe el README es más valioso que el que hace benchmarks de cinco librerías de gradient boosting.

Si está contratando para este rol, la plantilla de JD de Data Scientist establece las responsabilidades y el nivel. Si ya está en el rol y su stack parece el párrafo de apertura de esta guía, empiece la auditoría el lunes.

Más información

• Un día en la vida de un Data Scientist
• Sus primeros 30/60/90 días como nuevo Data Scientist
• Mover modelos a producción sin romperlos
• Métricas de DS: modelos desplegados, impacto en el negocio, degradación
• Plantilla de JD de Data Scientist