Agente de datos que piensa como científico en DABStep | Keryc
NVIDIA KGMON (NeMo Agent Toolkit) Data Explorer alcanzó el primer puesto en el benchmark DABStep usando una estrategia que separa aprendizaje pesado de inferencia rápida. ¿La clave? Construir herramientas reutilizables durante una fase de aprendizaje y luego ejecutar respuestas con un agente pequeño y ágil que orquesta esas herramientas.
Qué problema resuelve
Los agentes que dependen de búsqueda en texto fallan cuando la información está en tablas y requiere razonamiento en varios pasos. Preguntas complejas sobre datos tabulares no se arreglan con un snippet de web. ¿Te ha pasado que un modelo responde bien a una cosa, pero se pierde al cruzar dos archivos CSV y reglas de dominio? Este proyecto se diseñó para eso: preguntas multi-paso, herramientas stateful y validación estricta.
Arquitectura en tres fases
La idea central es dividir responsabilidades: gastar cómputo una vez para producir herramientas robustas, y luego usar esas herramientas muchas veces de forma eficiente.
Fase de Learning (aprendizaje): se usa un modelo pesado (por ejemplo Opus 4.5/4.6) en un loop multi-paso con un conjunto completo de herramientas (intérprete Python stateful, bash, detector de estructura de archivos, retriever). El agente resuelve varios casos representativos, valida contra ground truth y sintetiza soluciones en una biblioteca reutilizable helper.py y ejemplos few-shot.
Fase de Inference (inferencia): aquí entra un modelo pequeño/rápido (por ejemplo Haiku 4.5) en un loop simple. El contexto se poda agresivamente: el agente recibe solo las firmas de las funciones y un prompt optimizado, y llama a helper.py mediante un intérprete Python mínimo. Resultado: latencia y tokens al mínimo.
Fase de Offline Reflection (revisión offline): un modelo pesado (Opus o Sonnet 4.6) actúa como revisor no supervisado. Ejecuta dos técnicas clave: reflection (auditoría de código y uso de helper.py) y group-consistency (comparar soluciones para grupos de preguntas similares). Las correcciones se retroalimentan offline para afinar el prompt y las funciones sin ralentizar la inferencia en producción.
Dos loops de agente según caso de uso
Exploratory EDA: ReAct agent + herramientas de manipulación de notebooks. El agente crea, ejecuta celdas y genera visualizaciones; un handler envía las gráficas a un Vision-Language Model para describirlas y proponer mejoras, devolviendo texto enriquecido al agente.
Tabular QA orientado a reglas: Tool Calling Agent que orquesta un intérprete Python stateful, un retriever y un detector de estructura. Este enfoque es ideal para tareas que exigen pasos deterministas y validación rígida.
Insight técnico: por qué funciona
La gran idea es reconocer que muchas preguntas complejas comparten operaciones base. En vez de rehacer scripts por tarea, el agente construye funciones generalizables. Ejemplo real: calcular una tarifa de transacción y listar IDs de tarifas comparten los mismos pasos iniciales. El Learning phase prueba versiones de funciones contra múltiples tareas; cuando una versión falla en otro caso, el agente refina la función hasta generalizar.
Mover las comprobaciones costosas offline permite que la inferencia sea 30 veces más rápida sin perder rigor. El sistema mantiene calidad gracias a la reflexión offline y a la inyección de patrones aprendidos en el prompt del agente ligero.
Resultados y comparativa
Sistema
Easy
Hard
Time/Task
Code Length
NVIDIA KGMON (NeMo Agent Toolkit) Data Explorer + haiku 4.5
87.5
89.95
20s
1870
claude code + opus 4.5
90.2
66.93
10min
5011
DataPilot from AntGroup
86.11
87.57
unknown
unknown
DS-STAR from Google AI
87.5
45.24
unknown
unknown
Puntos clave:
Dominio en tareas "Hard": 89.95 frente a 66.93 del baseline que resuelve todo desde cero.
30x speedup en tiempo por tarea (20 segundos vs 10 minutos) gracias a la biblioteca helper.py y al modelo ligero en inferencia.
Código mucho más compacto en la salida final, lo que reduce el review humano y los errores formales por formato.
Cómo replicarlo o aplicarlo en tus proyectos (guía técnica breve)
Reúne un dev split representativo para la fase de aprendizaje. Asegúrate de tener ground truth y ejemplos que expongan variaciones operativas.
Ejecuta un agente pesado con acceso a un intérprete Python stateful y herramientas de inspección de archivos. Resuelve lotes de tareas y guarda scripts por tarea.
Automatiza la síntesis: prueba variaciones de funciones contra múltiples tareas y valida. Extrae las funciones que generalizan bien en helper.py.
Diseña un prompt conciso que incluya firmas de funciones, few-shot examples y reglas de formato de salida. Usa un modelo más pequeño para inferencia y un intérprete más limitado.
Corre revisiones offline periódicas con un modelo pesado para reflection y group-consistency. Alimenta las mejoras resultantes al prompt y a helper.py.
Consejos prácticos: prioriza pruebas unitarias automáticas para las funciones de helper.py; alarga el ciclo de aprendizaje cuando la distribución de tareas es muy heterogénea; usa el VLM para convertir gráficos en texto cuando debas explicar visualizaciones a usuarios no técnicos.
Impacto y limitaciones
Este enfoque muestra que con diseño arquitectural puedes hacer que modelos pequeños resuelvan problemas difíciles de razonamiento tabular, manteniendo velocidad y economía de tokens. La técnica es especialmente útil en sectores con datos tabulares sensibles o especializados, donde la web ayuda poco.
Limitaciones a considerar: el costo inicial de la fase de Learning puede ser alto; la calidad final depende de la representatividad del dev split; y hay dependencia de que las reglas de negocio no cambien radicalmente entre learning e inference.
La propuesta no es mágica: es ingeniería de agentes y capitalización de la generalización de código. Si tú trabajas con bases de datos financieras, logs de transacciones o catálogos complejos, esta arquitectura puede acelerar notablemente tus pipelines de análisis.
