La revancha del científico de datos

• Con la aparición de las API de LLM, los científicos de datos y los MLE quedaron fuera de la ruta principal para lanzar productos de IA, pero la esencia del trabajo real —diseño de experimentos, medición de métricas y depuración de sistemas probabilísticos— no desapareció
• Tanto el caso de Codex de OpenAI como el proyecto auto-research de Karpathy muestran que el núcleo es un harness compuesto por pruebas, métricas y una pila de observabilidad, y una parte importante de ese harness es ciencia de datos
• En la práctica están apareciendo repetidamente 5 trampas de evaluación (eval) —métricas genéricas, modelos juez no verificados, mal diseño experimental, datos y etiquetas deficientes, y automatización excesiva— que deterioran la calidad de los sistemas de IA
• La causa común de cada trampa es la falta de fundamentos de ciencia de datos, y la solución sigue siendo la metodología de siempre: análisis exploratorio de datos, evaluación de modelos, diseño experimental, recolección de datos y ML en producción
• "Ver los datos directamente" es la actividad con mayor ROI y, aun así, la que más se omite; el rol del científico de datos sigue siendo central incluso en la era de los LLM

---

El renacimiento del científico de datos

• Alguna vez, al científico de datos se le llamó “el trabajo más sexy del siglo XXI” y recibía salarios altos
  • Requería habilidades complejas como modelado predictivo, medición causal y exploración de patrones en datos
  • Más tarde, el trabajo de modelado predictivo se separó como Machine Learning Engineer (MLE)
• Con la llegada de los LLM (modelos de lenguaje grandes), surgió un cambio en el que, al desplegar IA en las empresas, los científicos de datos o los MLE dejaron de ser una ruta obligatoria
  • A través de las API de foundation models, los equipos pueden integrar IA de forma independiente
• Sin embargo, entrenar modelos no es todo lo que hace un científico de datos, y el diseño de experimentos, la depuración y el diseño de métricas siguen siendo tareas clave
  • Estas tareas no desaparecen solo por llamar a una API de LLM
• La charla “The Revenge of the Data Scientist” de PyAI Conf aborda esto con casos concretos y enfatiza que el rol de la ciencia de datos sigue siendo importante

La esencia del harness es ciencia de datos

• El concepto de Harness Engineering de OpenAI describe una estructura en la que un agente desarrolla código de forma autónoma dentro de un entorno rodeado de pruebas y especificaciones
  • El harness incluye una pila de observabilidad como logs, métricas y trazas, lo que permite que el agente detecte comportamientos anómalos por sí mismo
• El proyecto auto-research de Andrej Karpathy también muestra el mismo patrón de optimización iterativa basado en la métrica de pérdida de validación (validation loss)
• “Llamar a un LLM por API” no elimina el trabajo de diseño experimental, depuración ni diseño de métricas; una parte importante del harness es ciencia de datos
  • Antes se dedicaba mucho tiempo a inspeccionar datos, verificar la consistencia de etiquetas y diseñar métricas
  • Ahora existe una tendencia a depender de la “intuición” del modelo o a usar tal cual bibliotecas open source de métricas
• En particular, en áreas como RAG (Retrieval-Augmented Generation) y Evals (evaluaciones) hay muchos malentendidos por falta de comprensión de los datos
• Aparecen afirmaciones como “RAG is dead, evals are dead”, pero incluso los equipos que dicen eso terminan construyendo sistemas que dependen de esos conceptos
• Entre ingenieros sin background en datos se nota especialmente la tendencia a evitar retrieval y evals por temor a no entenderlos
• “Llamar a un LLM por API” no elimina el trabajo de diseño experimental, depuración ni diseño de métricas; una parte importante del harness es ciencia de datos

5 trampas de eval

• Trampa 1: métricas genéricas (Generic Metrics)

  • Métricas genéricas como helpfulness score, coherence score o hallucination score son demasiado amplias para diagnosticar fallas reales de una aplicación
  • Un científico de datos no adoptaría una métrica de inmediato; primero exploraría directamente los datos y las trazas para entender "qué es exactamente lo que se está rompiendo"
  • "Ver los datos" significa leer las trazas directamente, crear visores de trazas personalizados y clasificar fallas mediante análisis de errores (error analysis)
  • Métricas genéricas de similitud como ROUGE o BLEU casi no encajan con salidas de LLM, y se necesitan métricas específicas de la aplicación como "Calendar Scheduling Failure" o "Failure to Escalate To Human"
  • Ver los datos es la actividad con mayor ROI y la que más se omite

• Trampa 2: jueces no verificados (Unverified Judges)

  • La mayoría de los equipos que usan un LLM como juez no tienen una respuesta clara a "¿cómo confiamos en el juez?"
  • Un científico de datos trata al juez como un clasificador (classifier), obtiene etiquetas humanas y mide su confiabilidad separando en train/dev/test
    • Los ejemplos few-shot se toman del conjunto de entrenamiento, el prompt del juez se mejora con el dev set y el test set se conserva para verificar overfitting
  • Al reportar resultados, en vez de usar solo accuracy, se deben usar precision y recall — incluso si el modo de falla es solo del 5%, accuracy puede ocultar el rendimiento real
  • La validación de clasificadores se ha vuelto una habilidad perdida en la IA moderna

• Trampa 3: mal diseño experimental (Bad Experimental Design)

  • Construcción del test set: la mayoría de los equipos le pide al LLM “genera 50 consultas de prueba”, pero este método crea datos genéricos no representativos
    • Un científico de datos primero examinaría datos reales de producción, identificaría las dimensiones importantes y luego generaría ejemplos sintéticos alineados con esas dimensiones
    • Los datos sintéticos deben generarse a partir de logs o trazas reales, e inyectar edge cases
  • Diseño de métricas: meter toda la rúbrica en una sola llamada a un LLM y usar por defecto una escala de Likert de 1 a 5 oculta la ambigüedad y posterga decisiones difíciles sobre el desempeño del sistema
    • Debe reemplazarse por juicios binarios (pass/fail) sobre criterios de alcance acotado

• Trampa 4: datos y etiquetas deficientes (Bad Data and Labels)

  • Como etiquetar no luce glamoroso, suele delegarse al equipo de desarrollo o externalizarse, pero un científico de datos exige que el etiquetado lo hagan directamente expertos del dominio
  • Además de la calidad de las etiquetas, hay una razón más profunda: el concepto de "criteria drift" validado por trabajos como los de Shreya Shankar — los usuarios necesitan criterios para evaluar resultados, pero terminan definiendo esos criterios durante el propio proceso de evaluación. Es decir, no saben lo que quieren hasta ver la salida del LLM
  • Hay que poner a los expertos del dominio y a los PM frente a los datos crudos, no frente a puntajes resumidos

• Trampa 5: automatizar demasiado (Automating Too Much)

  • Los LLM pueden ayudar a escribir código de plumbing, generar boilerplate y conectar evaluaciones
  • Pero el trabajo de ver los datos directamente no se puede automatizar — porque no sabes lo que quieres hasta ver las salidas
  • Otras trampas adicionales mencionadas: mal uso de puntajes de similitud, hacerle al juez preguntas ambiguas como “¿es útil?”, hacer que los anotadores lean JSON crudo, reportar puntajes sin calibrar ni intervalos de confianza, data drift, overfitting, muestreo incorrecto y dashboards difíciles de entender

Relación con los fundamentos de ciencia de datos

• Las 5 trampas tienen la misma causa raíz: la ausencia de fundamentos de ciencia de datos
• Correspondencia entre cada trampa y la metodología clásica:
  • Leer trazas y clasificar fallas → análisis exploratorio de datos (EDA)
  • Verificar jueces LLM con etiquetas humanas → evaluación de modelos (Model Evaluation)
  • Construir test sets representativos basados en datos de producción → diseño experimental (Experimental Design)
  • Etiquetado por expertos del dominio → recolección de datos (Data Collection)
  • Monitorear el funcionamiento del producto en producción → ML en producción (Production ML)
• Cambiaron los nombres, pero el trabajo en sí es el mismo
• Python sigue siendo el mejor conjunto de herramientas para explorar y manipular datos
• Se publicó una herramienta open source para analizar pipelines de eval y diagnosticar qué está mal mediante el plugin open source evals-skills

[GN⁺]

Comentarios de Hacker News

• Son buenas prácticas al construir soluciones de GenAI, pero no creo que este cambio garantice la sostenibilidad del rol de científico de datos.
  Antes, los científicos de datos destacaban por su capacidad de construir modelos directamente y generar valor de negocio.
  Pero ahora ese papel lo están ocupando los proveedores de LLM y los ingenieros que llaman APIs. Ajustar el comportamiento de un LLM es una especie de magia negra, pero no requiere necesariamente conocimientos matemáticos.
  Lo que queda ahora es evaluación y monitoreo, y eso no parece ser un “valor central” desde la perspectiva del negocio. En organizaciones que quieren desplegar prototipos rápido, incluso se percibe como un obstáculo.
  Al final, se termina en la situación de tener que convencer a otros de que “los científicos de datos deben ser los guardianes de la construcción con LLM”, y dudo qué tan convincente resulte ese argumento.

  • Yo sentí algo parecido. Para usar LLM ya existentes, no hace falta necesariamente un científico de datos. Incluso un ingeniero con afinidad por la IA, como yo, pudo aprenderlo rápido.
    Aun así, creo que fuera de los LLM sigue habiendo muchas áreas donde todavía se necesitan modelos de ML personalizados. Por ejemplo, el ranking de búsqueda de AirBnB o el algoritmo de matching de Uber no se pueden reemplazar con LLM.
    En resumen, el mercado sí se redujo, pero no desapareció por completo.
  • Es difícil convencer al liderazgo, y de hecho muchos DS tampoco quieren hacer este tipo de trabajo de evaluación.
    Pero este proceso obliga a definir con claridad “qué se está tratando de resolver”. A veces la respuesta puede ser “no vale la pena construir este producto”.
    Pero casi nadie quiere escuchar ese tipo de cosas.
  • No veo por qué el trabajo de evaluación tenga que ser necesariamente territorio de los científicos de datos.
    Los ingenieros de IA con formación en SWE muchas veces encajan mejor. Porque para ellos resulta natural pensar “evaluación = pruebas automatizadas”.
    De hecho, en muchos proyectos de agentes el rol del DS prácticamente está desapareciendo.
  • Parece que el rigor estadístico que aportaban los científicos de datos casi se ha perdido en las soluciones basadas en LLM.

• Es un consejo que les doy seguido a los científicos de datos.

  1. Piensen en los datos de contexto como datos de entrenamiento — el LLM aprende a partir del contexto que se le da.
  2. Piensen en los datos de evaluación como datos de prueba — hay que recolectarlos de los logs de ejecución del agente y etiquetarlos manualmente.
     Si se va a usar un LLM como juez, ese modelo también necesita aprendizaje en contexto a partir de buenos datos de ejemplo.
     Todo esto está resumido en mi libro.
  • Totalmente de acuerdo. “Evaluations = Tests”.
    Pero cuando un modelo tiene que evaluar la salida de otro modelo, termina convirtiéndose en una estructura meta, así que en algún punto igual hay que fijar una “respuesta correcta” real.

• Yo vengo de un trasfondo en ciencia de datos/ingeniería.
  Usar IA se parece a explorar un espacio de soluciones. Es el proceso de encontrar un óptimo entre miles de millones de combinaciones de parámetros.
  Con prompts se reduce el espacio de búsqueda, y con heurísticas basadas en significado se intenta encontrar una mejor solución.
  A menudo uno queda atrapado en un óptimo local o termina yéndose en una dirección completamente equivocada. Por eso reinicio la base de código cada semana, simplificando o agregando funciones. Así es como se pueden encontrar mejores soluciones.

• Creo que casos como pg_textsearch, mencionado recientemente, son buenos ejemplos de este estilo de desarrollo.
  Cuando hay casos de prueba y benchmarks claros, la probabilidad de éxito es alta.
  Pero en el desarrollo greenfield, definir los casos de prueba es tan difícil como escribir el código, o incluso más difícil.
  Además, los LLM a menudo tienden a quedarse atrapados en un mínimo local. Una vez que la estructura del código se endurece, casi no intentan grandes refactorizaciones. Es un fenómeno parecido al overfitting.

• Se decía que la clave de los experimentos con IA era verificar qué tanto generaliza el modelo a datos nuevos, pero en la práctica falta el proceso de confirmar claramente “qué son los datos”.
  Porque muchas veces los datos que la gente cree tener no son los datos reales.

• A mí me da mucho más insight observar directamente el comportamiento del agente que construir workflows complejos de LLM-como-juez.

• Ayer probé aplicar el enfoque de autoresearch de Karpathy a un problema de ML.
  Después de varios experimentos, me sorprendieron los resultados que mostró el modelo. Si Kaggle siguiera tan activo como antes, parecería que la IA habría ganado la mayoría de los problemas.
  Pero el trabajo real de ciencia de datos está lleno de gente que ni siquiera conoce bien las herramientas básicas. Darles IA no hará que de repente se vuelvan buenos.
  Al final, los expertos seguirán sacando trabajo adelante usando juniors, y los no expertos seguirán perdidos entre resultados mediocres.

  • Si fueran problemas tipo Kaggle, parece que la IA podría hacerlo bastante bien.
    Pero el trabajo real de DS consiste sobre todo en lidiar con datos incompletos y objetivos ambiguos.
    Un buen DS tiene que saber decir “esto no se puede hacer”. En cambio, un LLM siempre responde algo como “¡sí, gran idea!”.

• Al final, el desarrollo con IA también es un loop parecido: “definir qué es un buen resultado, medir la distancia con respecto a eso, e iterar para mejorar”.
  Solo que quienes llevan mucho tiempo pensando así están muy por delante de los prompt engineers.

[raykim]

No sé si la gente de DS ya dejó comentarios por aquí. Parece que todos lo están viendo desde la perspectiva de desarrollador...