Un vistazo al agente de datos interno de OpenAI

 (openai.com)
13 puntos por GN⁺ 2026-02-13 | 1 comentarios | Compartir por WhatsApp
  • OpenAI construyó internamente un agente de datos de IA personalizado para analizar de forma eficiente más de 3,500 usuarios internos y 600 PB de datos
  • Con solo preguntas en lenguaje natural, automatiza un flujo de análisis de extremo a extremo que va desde explorar tablas y ejecutar SQL hasta publicar notebooks y reportes
  • Garantiza la precisión al combinar 6 capas de contexto (uso de tablas, anotaciones humanas, análisis de código basado en Codex, conocimiento institucional, memoria y contexto de ejecución)
  • Opera con una estructura de bucle cerrado de autoaprendizaje que investiga por sí misma la causa cuando un resultado intermedio es incorrecto y corrige su enfoque
  • Con un sistema de evaluación estructurado basado en la Evals API, detecta temprano regresiones de calidad y mantiene la confiabilidad heredando el modelo existente de seguridad y permisos

Por qué se necesita un agente de datos personalizado

  • La plataforma de datos de OpenAI cuenta con más de 3,500 usuarios internos, 600 petabytes de datos y más de 70,000 datasets, por lo que encontrar la tabla correcta es en sí una de las tareas que más tiempo consumen dentro del análisis
  • Hay muchas tablas parecidas, lo que dificulta identificar las diferencias entre tablas, como si incluyen o no a usuarios desconectados o si hay duplicación de campos
  • Incluso al elegir la tabla correcta, un join many-to-many, errores de filter pushdown o valores null sin manejar pueden invalidar el resultado
  • Los analistas deberían enfocarse en definir métricas, validar hipótesis y tomar decisiones basadas en datos, no en depurar SQL

Cómo funciona el agente

  • Funciona sobre la base de GPT-5.2
  • Se puede acceder desde entornos que el personal ya usa, como el agente de Slack, la interfaz web, el IDE, Codex CLI (con integración MCP) y la app interna de ChatGPT
  • Puede manejar preguntas complejas y abiertas
    • Entiende la pregunta
    • Explora los datos
    • Ejecuta SQL
    • Analiza y resume resultados en un proceso de extremo a extremo
    • Ejemplo: analizar en el dataset de taxis de NYC la combinación de pares de ZIP de origen-destino con mayor variabilidad en tiempo de viaje
  • No sigue scripts fijos, sino que evalúa su propio progreso y, si un resultado intermedio sale mal (por ejemplo, 0 filas debido a un join o filtro incorrecto), investiga la causa, ajusta el enfoque y vuelve a intentar
  • Cubre todo el flujo de trabajo analítico: descubrimiento de datos, ejecución de SQL, publicación de notebooks y reportes, consulta de conocimiento interno, búsqueda web y aprendizaje basado en memoria

Estructura de capas de contexto

  • Capa 1: Uso de tablas (Table Usage)

    • Base en metadatos: utiliza metadatos del esquema (nombres de columnas, tipos de datos) para redactar SQL, y usa el linaje de tablas (relaciones entre tablas padre e hija) para entender cómo se conectan entre sí
    • Inferencia de consultas: recopila consultas pasadas para que el agente aprenda cómo redacta sus propias consultas y qué combinaciones de tablas suelen unirse

  • Capa 2: Anotaciones humanas (Human Annotations)

    • Expertos de dominio escriben descripciones curadas sobre tablas y columnas, capturando intención, semántica, contexto de negocio y advertencias conocidas que son difíciles de inferir a partir del esquema o de consultas anteriores
    • Como solo con metadatos es difícil distinguir tablas, es esencial entender cómo fueron generadas y de dónde provienen

  • Capa 3: Análisis de código basado en Codex (Codex Enrichment)

    • Obtiene la definición a nivel de código de las tablas para comprender en profundidad el contenido real de los datos
      • Aporta matices basados en eventos analíticos, como unicidad de valores, frecuencia de actualización de datos y alcance de los datos (si excluyen ciertos campos, nivel de granularidad, etc.)
    • Permite entender el contexto de uso en distintos sistemas de datos, además de SQL, como Spark y Python
    • Hace posible distinguir tablas que parecen similares pero son esencialmente diferentes (por ejemplo, si una tabla contiene solo tráfico de ChatGPT de 1st-party)
    • Este contexto se actualiza automáticamente, sin necesidad de mantenimiento manual

  • Capa 4: Conocimiento institucional (Institutional Knowledge)

    • Reúne contexto de la empresa desde Slack, Google Docs, Notion y otros sistemas, incluyendo lanzamientos, incidentes, nombres en clave internos y las definiciones formales y lógica de cálculo de métricas clave
    • Opera un servicio de búsqueda que recopila documentos, los convierte en embeddings y los guarda junto con metadatos y permisos, manejando en tiempo de ejecución control de acceso y caché

  • Capa 5: Memoria (Memory)

    • Cuando el agente recibe correcciones o detecta matices en una pregunta sobre datos, los guarda para empezar desde una línea base más precisa en análisis futuros
    • El objetivo de la memoria es conservar y reutilizar correcciones, filtros y restricciones no obvias que son difíciles de inferir desde otras capas
      • Ejemplo: al filtrar un experimento analítico específico, se necesitaba una coincidencia exacta de cierta cadena definida en el gate del experimento, pero sin memoria el agente cometía el error de intentar fuzzy string matching
    • Cuando hay correcciones o descubrimientos de aprendizaje, el agente impulsa el guardado en memoria, y el usuario también puede crearla o editarla manualmente
    • La memoria se divide en alcance global y personal

  • Capa 6: Contexto de ejecución (Runtime Context)

    • Si no hay contexto previo sobre una tabla o la información está desactualizada, emite consultas en vivo al data warehouse para validar el esquema y entender los datos en tiempo real
    • También se comunica con otros sistemas de la plataforma de datos como el servicio de metadatos, Airflow y Spark para obtener contexto fuera del warehouse

  • Pipeline diario offline y RAG

    • Opera un pipeline diario offline que agrega en una sola representación normalizada el uso de tablas, las anotaciones humanas y el enriquecimiento basado en Codex
    • Convierte el contexto enriquecido en embeddings con la OpenAI Embeddings API y luego lo almacena; al consultar, recupera solo el contexto relevante mediante RAG (Retrieval-Augmented Generation)
    • Esto mantiene la comprensión de tablas rápida y escalable en decenas de miles de tablas, y conserva una latencia de ejecución predecible y baja

Diseñado para pensar y colaborar como un compañero de equipo

  • No se limita a respuestas de una sola vez, sino que admite exploración iterativa conversacional, manteniendo el contexto completo entre turnos para que no haya que volver a explicar todo desde cero en preguntas de seguimiento o cambios de dirección
  • Si el agente va en una dirección equivocada, el usuario puede intervenir a mitad del análisis y redirigirlo
  • Si la instrucción no es clara, hace preguntas de aclaración de forma proactiva y, si no hay respuesta, avanza aplicando valores razonables por defecto (por ejemplo, los últimos 7 o 30 días)
  • Tras observar patrones donde el mismo análisis se repite una y otra vez, empaqueta esos análisis repetitivos como workflows reutilizables (instruction set)
    • Algunos ejemplos son reportes semanales del negocio y validación de tablas
    • Al codificar una vez el contexto y las mejores prácticas, garantiza resultados consistentes entre usuarios

Un sistema de evaluación para mejorar rápido sin perder la confianza

  • Como es un agente en constante evolución, puede producirse fácilmente deriva de calidad, y sin una evaluación sistemática las regresiones pueden avanzar sin ser detectadas
  • Basándose en la OpenAI Evals API, construyen un conjunto curado de pares pregunta-respuesta y asignan a cada pregunta una consulta SQL "golden" escrita manualmente
  • Envían la pregunta en lenguaje natural al endpoint de generación de consultas, ejecutan el SQL generado y luego comparan con el resultado esperado del SQL de referencia
  • No se trata de una simple coincidencia de cadenas: comparan tanto el SQL como los datos resultantes, y los envían al grader de Evals para producir una puntuación final y su explicación, reflejando exactitud y variaciones tolerables
  • Esta evaluación actúa como prueba unitaria que se ejecuta continuamente durante el desarrollo y como canary en producción para detectar regresiones temprano

Seguridad del agente

  • Se conecta directamente al modelo existente de seguridad y control de acceso de OpenAI, heredando y aplicando las mismas autorizaciones y guardrails en la capa de interfaz
  • Todo acceso es de tipo pass-through, por lo que el usuario solo puede consultar tablas para las que ya tiene permisos; si no los tiene, se le informa o se recurre a un dataset alternativo como fallback
  • Para mantener la transparencia, muestra el proceso de razonamiento: resume junto con la respuesta los supuestos y pasos ejecutados, y enlaza directamente a los resultados originales de las consultas ejecutadas para que el usuario pueda verificar cada paso del análisis

Lecciones aprendidas durante la construcción

  • Lección 1: Menos es más (Less is More)

    • Al inicio expusieron al agente el conjunto completo de herramientas, pero esto generó confusión por superposición de funciones
    • Funciones redundantes que son útiles cuando un humano las invoca manualmente generan ambigüedad para el agente, así que restringir y unificar ciertas llamadas de herramienta mejoró la confiabilidad

  • Lección 2: Guiar el objetivo, no el camino (Guide the Goal, Not the Path)

    • Un prompting demasiado directivo en realidad empeoraba los resultados
    • Como cada pregunta cambia en sus detalles, las instrucciones rígidas pueden llevar al agente por una ruta equivocada; ofrecer guía de alto nivel y delegar en el razonamiento de GPT-5 la elección del camino de ejecución dio mejores resultados

  • Lección 3: El significado está en el código (Meaning Lives in Code)

    • El esquema y el historial de consultas solo describen la forma y el modo de uso de una tabla; el verdadero significado está en el código que la genera
    • La lógica del pipeline captura supuestos, garantías de frescura e intención de negocio, y eso no se refleja en el SQL ni en los metadatos
    • Al rastrear el codebase con Codex para entender cómo se construyen realmente los datasets, pueden responder con precisión cosas como "qué contiene" y "cuándo puede usarse", algo imposible de obtener solo con señales del warehouse

Hacia dónde va esto

  • Siguen impulsando mejoras en el manejo de preguntas ambiguas, más confiabilidad y precisión mediante una validación más robusta, y una integración más profunda de workflows
  • Buscan que no sea una herramienta aparte, sino algo que se integre naturalmente en la forma en que la gente ya trabaja
  • A medida que mejoran las tecnologías base de razonamiento, validación y autocorrección del agente, este seguirá evolucionando, y
    la misión del equipo es ofrecer análisis de datos rápidos y confiables de forma fluida en todo el ecosistema de datos de OpenAI

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-13
Comentarios en Hacker News

  • La confiabilidad y la explicabilidad son el mayor problema
    Llevamos 10 años desarrollando analítica en lenguaje natural en Veezoo, y un enfoque simple de Text-to-SQL no escala bien
    Si el CFO pregunta por los ingresos, una cifra correcta solo al 99% no sirve, y además el CFO no puede validar el SQL por su cuenta
    Por eso usamos una capa de abstracción llamada Knowledge Graph, donde la IA convierte el lenguaje natural en un lenguaje de consulta semántico y luego lo compila de forma determinista a SQL
    A la vez, esa consulta semántica se vuelve a convertir en una explicación en lenguaje natural para que el usuario pueda verificar fácilmente si el resultado coincide con su intención
    La lógica de negocio vive en el Knowledge Graph, y el compilador garantiza que todas las consultas la sigan al 100%
    La estructura en detalle está resumida en la documentación de arquitectura de Veezoo

    • Gracias por compartir el enlace. El resumen de la arquitectura fue muy revelador
      Me pregunto cómo manejan la explosión de cardinalidad y cómo resuelven solicitudes de múltiples consultas que dependen de resultados de consultas anteriores
    • Aun así, ¿el SQL generado no necesita control de versiones y pruebas unitarias?
      Debería poder rastrearse qué consulta se usó en qué fecha y cómo se validó
      (Por supuesto, los prompts también deberían entrar en control de versiones)

  • Me sorprendió que el primer ejemplo fuera totalmente ilógico
    Si esto pasó una revisión humana, probablemente fue porque lo escribió una IA, y en ese caso la confiabilidad del sistema queda en duda
    Enlace a la imagen del problema

  • Por mi experiencia usando varios sistemas de BI, creo que este tipo de agente de IA es un caso de uso perfecto
    La BI ya trae errores en varias capas por naturaleza: la consulta puede estar mal, o puede estar mal la manera de interpretar los datos
    Si juntas ambas cosas, ya estás en un “mundo imaginario”, así que mejor que la IA se encargue de la etapa 1
    Esperaba que OpenAI hubiera resuelto el problema de confiabilidad, pero lamentablemente no fue así

    • Hay algo que no hay que olvidar
      Etapa 0: los datos se almacenaron mal
      Etapa -1: se entendió mal el modelado desde el principio
      Etapa -2: el proceso de negocio ya estaba mal desde el arranque
      Por eso yo le digo “fuente única de falsedad” en lugar de “fuente única de verdad”

  • Lo más difícil es escalar la confianza
    Nosotros también estamos construyendo algo parecido, pero por muy bueno que sea el loop del agente, al final hacen falta métricas estándar curadas por humanos (canonical metrics)
    Si no, los usuarios no técnicos terminan tomando decisiones riesgosas basadas en SQL imposible de verificar
    Nuestro enfoque es:

    1. Controlamos directamente el pipeline de datos y usamos solo fuentes de datos con esquemas consistentes entre clientes
    2. Si existe una métrica validada, usamos esa; solo recurrimos a SQL cuando no la hay, y registramos esa diferencia para revisión humana
      Con el tiempo, la mayoría de las consultas terminan usando métricas estándar, y el agente deja de ser un simple generador de SQL para convertirse en un router inteligente de intención → métrica validada
      El sistema de evaluación de SQL dorado en la sección “Moverse rápido sin romper la confianza” recoge la misma idea
      Lo explicamos en este post del blog
    • Sí, hace falta una capa semántica clara
      Si hay varios caminos para llegar a una respuesta, vas a obtener resultados distintos
      Los LLM a menudo inventan métricas sin sentido, como xyz_index, y los usuarios se las creen porque suenan plausibles

  • Creo que el impacto real de la IA en los empleos de desarrollo estará en la calidad de los datos y la documentación
    Qué tan bien organizados estén los datos de una empresa va a determinar qué tan eficiente será su uso de IA
    Los datos públicos ya se agotaron, y el siguiente recurso son los documentos internos, los repositorios de código y los data lakes
    Las empresas que tengan bien resuelta esa base podrán crear y mantener nuevos servicios con IA de forma rápida y barata
    En cambio, donde la documentación y la gestión del código sean un desastre, la IA simplemente no funcionará bien
    Al final terminarán perdiendo mercado frente a la competencia
    Por eso, cuando busque trabajo en el futuro, pienso preguntar sí o sí por el nivel de gestión de documentación, datos y repositorios

    • Me da curiosidad qué aspectos concretos miras en documentación, datos y repositorios para distinguir una buena arquitectura de una mala

  • En Amplitude construyeron un sistema parecido llamado Moda
    Hace unos meses Wade le mostró a Claire Vo este video demo, y estaba realmente muy bien
    Yo lo uso todos los días para hacerle distintas preguntas

  • Nosotros también ofrecemos algo parecido en Definite.app en 5 minutos
    No hace falta Spark ni Snowflake
    Ofrecemos data lake, pipeline, capa semántica y agente de datos en una sola app
    De hecho, más que el agente en sí, lo realmente difícil es construir la infraestructura de datos
    Si el agente solo puede escribir SQL, sus límites son grandes, pero nosotros permitimos gestionar la infraestructura misma, y ahí está el verdadero punto de inflexión

  • Está muy bueno
    Pero me parece que falta la parte de explicar cómo se calculó el resultado
    Para uso interno de OpenAI, asumir que el usuario puede leer SQL está bien, pero para usuarios no técnicos eso es un desafío grande de diseño
    En cuanto trabajas con sistemas de datos, te das cuenta rápido de que importa tanto la “respuesta” como “cómo se llegó a esa respuesta”

  • Personalmente, me parece más interesante el In-House Data Agent de Kimi

  • Los problemas de datos no son problemas técnicos, sino problemas organizacionales

    • Totalmente de acuerdo
      En mi experiencia, el origen de los problemas de datos no está en “elegir mal la tecnología”, sino en las decisiones de gobernanza y ownership
      Al final, todo termina reduciéndose a la ley de Conway