Plongée dans l’agent de données interne d’OpenAI

• OpenAI a développé en interne un agent de données IA sur mesure afin d’analyser efficacement plus de 3 500 utilisateurs internes et 600 PB de données
• À partir de simples questions en langage naturel, il automatise un workflow d’analyse de bout en bout allant de l’exploration des tables à l’exécution de SQL, jusqu’à la publication de notebooks et de rapports
• Il garantit la précision en combinant 6 couches de contexte (usage des tables, annotations humaines, analyse de code basée sur Codex, connaissance organisationnelle, mémoire, contexte d’exécution)
• Il fonctionne selon une structure de boucle fermée auto-apprenante : si un résultat intermédiaire est erroné, il en recherche lui-même la cause et ajuste son approche
• Grâce à un système d’évaluation structuré fondé sur l’API Evals, il détecte précocement les régressions de qualité tout en conservant la fiabilité via l’héritage du modèle existant de sécurité et d’autorisations

---

Pourquoi un agent de données sur mesure est nécessaire

• La plateforme de données d’OpenAI compte plus de 3 500 utilisateurs internes, 600 pétaoctets de données et plus de 70 000 jeux de données ; trouver la bonne table est en soi la tâche la plus chronophage de l’analyse
• De nombreuses tables se ressemblent, ce qui rend difficile l’identification des différences entre elles, par exemple l’inclusion ou non des utilisateurs déconnectés ou des doublons de champs
• Même en sélectionnant la bonne table, des jointures many-to-many, des erreurs de filter pushdown ou une mauvaise gestion des valeurs nulles peuvent invalider les résultats
• Les analystes doivent se concentrer non pas sur le débogage SQL, mais sur la définition des métriques, la vérification des hypothèses et la prise de décision fondée sur les données

Comment l’agent fonctionne

• Fonctionne sur la base de GPT-5.2
• Accessible depuis les environnements que les employés utilisent déjà, comme l’agent Slack, l’interface web, l’IDE, Codex CLI (intégration MCP) et l’application ChatGPT interne
• Peut traiter des questions complexes et ouvertes
  • compréhension de la question
  • exploration des données
  • exécution de SQL
  • jusqu’à l’analyse et au résumé des résultats, avec une exécution de bout en bout
  • Exemple : analyser, dans le jeu de données des taxis de NYC, la combinaison de paires de codes ZIP pickup-dropoff présentant la plus forte variabilité des temps de trajet
• Au lieu de suivre un script figé, il évalue lui-même sa progression et, si un résultat intermédiaire est erroné (par exemple 0 ligne à cause d’une mauvaise jointure ou d’un filtre incorrect), il en examine la cause, corrige son approche et réessaie
• Il couvre l’ensemble du workflow analytique : découverte des données, exécution de SQL, publication de notebooks et de rapports, consultation des connaissances internes, recherche web et apprentissage fondé sur la mémoire

Architecture des couches de contexte

• Layer 1: usage des tables (Table Usage)

  • Ancrage dans les métadonnées : utilisation des métadonnées de schéma (noms de colonnes, types de données) pour écrire du SQL, et compréhension des relations entre tables via la lignage des tables (relations amont/aval)
  • Inférence à partir des requêtes : collecte des requêtes passées afin que l’agent apprenne sa propre manière d’écrire des requêtes ainsi que les combinaisons de tables généralement jointes

• Layer 2: annotations humaines (Human Annotations)

  • Des experts métier rédigent des descriptions curées des tables et colonnes, capturant des informations difficiles à déduire du schéma ou des requêtes passées : intention, sémantique, contexte métier, points d’attention connus
  • Comme les métadonnées seules ne suffisent pas à distinguer les tables, une compréhension de leur mode de production et de leur origine est indispensable

• Layer 3: analyse de code basée sur Codex (Codex Enrichment)

  • Elle extrait la définition au niveau du code des tables afin de comprendre en profondeur le contenu réel des données
    • Elle fournit des nuances liées aux événements analytiques, comme l’unicité des valeurs, la fréquence de mise à jour des données, ou encore leur périmètre (exclusion de certains champs, niveau de granularité)
  • Elle permet aussi de comprendre le contexte d’usage dans divers systèmes de données, au-delà du SQL, comme Spark ou Python
  • Elle permet de distinguer des tables apparemment similaires mais fondamentalement différentes (par exemple, savoir si une table ne contient que le trafic ChatGPT 1st-party)
  • Ce contexte est mis à jour automatiquement, sans maintenance manuelle

• Layer 4: connaissance organisationnelle (Institutional Knowledge)

  • L’agent collecte, depuis Slack, Google Docs, Notion, etc., le contexte propre à l’entreprise : lancements, incidents, noms de code internes, définitions normalisées et logique de calcul des métriques clés
  • Il exploite un service de recherche qui collecte les documents, les vectorise, les stocke avec leurs métadonnées et autorisations, puis gère à l’exécution le contrôle d’accès et le caching

• Layer 5: mémoire (Memory)

  • Lorsque l’agent reçoit des corrections ou découvre des subtilités dans des questions de données, il les enregistre pour repartir la fois suivante d’une base de référence plus précise
  • L’objectif de la mémoire est de préserver et réutiliser des corrections, filtres et contraintes non évidents qu’il est difficile de déduire à partir des autres couches
    • Exemple : lors du filtrage d’une expérience d’analyse spécifique, il fallait faire correspondre une chaîne précise définie dans la gate de l’expérience ; sans mémoire, l’agent commettait l’erreur d’essayer un matching de chaînes flou
  • Lorsqu’il détecte une correction ou un apprentissage, l’agent encourage l’enregistrement en mémoire, et l’utilisateur peut aussi créer et modifier manuellement ces mémoires
  • La portée de la mémoire est distinguée entre niveau global et niveau individuel

• Layer 6: contexte d’exécution (Runtime Context)

  • Lorsqu’il n’existe pas de contexte préalable sur une table ou que l’information est obsolète, l’agent lance des requêtes live dans le data warehouse afin de valider le schéma et de comprendre les données en temps réel
  • Il communique aussi avec d’autres systèmes de la Data Platform, comme les services de métadonnées, Airflow ou Spark, afin d’obtenir un contexte de données hors du warehouse

• Pipeline offline quotidien et RAG

  • OpenAI exploite un pipeline offline quotidien qui agrège l’usage des tables, les annotations humaines et les enrichissements basés sur Codex dans une représentation normalisée unique
  • Le contexte enrichi est ensuite converti en embeddings via l’API OpenAI Embeddings, stocké, puis seuls les contextes pertinents sont récupérés à la requête via RAG (Retrieval-Augmented Generation)
  • Cela permet de maintenir une compréhension des tables rapide et scalable sur des dizaines de milliers de tables, tout en gardant une latence d’exécution prévisible et faible

Une conception pensée pour raisonner et collaborer comme un coéquipier

• L’agent prend en charge une exploration itérative conversationnelle plutôt qu’une réponse one-shot, en conservant l’intégralité du contexte entre les tours pour éviter d’avoir à tout réexpliquer lors d’une question de suivi ou d’un changement de direction
• Si l’agent part dans la mauvaise direction, l’utilisateur peut intervenir en cours d’analyse pour le rediriger
• Si l’instruction est ambiguë, il pose de manière proactive des questions de clarification et, en l’absence de réponse, applique des valeurs par défaut raisonnables (par exemple les 7 ou 30 derniers jours) pour avancer
• Après avoir observé que certaines analyses sont exécutées de façon répétée, OpenAI empaquette ces analyses récurrentes sous forme de workflows réutilisables (instruction set)
  • Exemples : rapports business hebdomadaires, validation de tables
  • Le contexte et les bonnes pratiques sont encodés une seule fois pour garantir des résultats cohérents entre utilisateurs

Un cadre d’évaluation pour progresser vite sans perdre la confiance

• Comme l’agent évolue en permanence, une dérive de qualité peut facilement apparaître, et sans évaluation systématique les régressions peuvent passer inaperçues
• OpenAI construit, sur la base de l’API OpenAI Evals, un ensemble curé de paires question-réponse, avec pour chaque question une requête SQL « golden » rédigée manuellement
• Les questions en langage naturel sont envoyées à un endpoint de génération de requêtes, le SQL généré est exécuté, puis comparé aux résultats du SQL attendu
• Il ne s’agit pas d’un simple matching de chaînes : le SQL et les données de résultat sont tous deux comparés puis transmis au grader Evals afin de produire un score final et une explication reflétant la précision et les variations tolérées
• Cette évaluation joue le rôle de tests unitaires exécutés en continu pendant le développement, ainsi que de canari en production pour détecter tôt les régressions

Sécurité de l’agent

• L’agent se connecte directement au modèle existant de sécurité et de contrôle d’accès d’OpenAI, en héritant et appliquant les mêmes autorisations et garde-fous au niveau de la couche d’interface
• Tous les accès fonctionnent en mode pass-through : l’utilisateur ne peut interroger que les tables auxquelles il a déjà accès ; sinon, l’agent l’en informe ou bascule vers un jeu de données alternatif
• Pour assurer la transparence, il rend visible son raisonnement : il résume ses hypothèses et les étapes d’exécution avec la réponse, et fournit un lien direct vers les résultats bruts de la requête exécutée afin que l’utilisateur puisse vérifier chaque étape de l’analyse

Enseignements tirés de la construction

• Lesson 1: less is more

  • Au départ, l’ensemble complet des outils avait été exposé à l’agent, mais cela a provoqué une confusion liée au chevauchement des fonctionnalités
  • Des fonctions redondantes utiles pour un appel manuel par un humain créaient de l’ambiguïté pour l’agent ; en limitant et en consolidant certains appels d’outils, OpenAI a amélioré la fiabilité

• Lesson 2: guider l’objectif, pas le chemin (Guide the Goal, Not the Path)

  • Un prompting très directif a au contraire dégradé les résultats
  • Comme les détails varient selon les questions, des instructions rigides peuvent entraîner l’agent sur une mauvaise trajectoire ; fournir un guidage de haut niveau et laisser GPT-5 choisir le chemin d’exécution via son raisonnement donne de meilleurs résultats

• Lesson 3: le sens réside dans le code (Meaning Lives in Code)

  • Le schéma et l’historique des requêtes n’expliquent que la forme d’une table et sa manière d’être utilisée ; le véritable sens se trouve dans le code qui produit la table
  • La logique des pipelines capture des hypothèses, des garanties de fraîcheur et l’intention métier, des éléments qui n’apparaissent ni dans le SQL ni dans les métadonnées
  • En explorant la base de code avec Codex pour comprendre comment les jeux de données sont réellement construits, OpenAI peut répondre avec précision à « ce que contient réellement la table » et « quand elle peut être utilisée », ce qui serait impossible avec les seuls signaux du warehouse

Suite

• OpenAI continue de travailler sur une meilleure gestion des questions ambiguës, une amélioration de la fiabilité et de la précision via une validation plus robuste, ainsi qu’un approfondissement de l’intégration des workflows
• L’objectif est une intégration naturelle dans les modes de travail existants, plutôt qu’un outil séparé
• À mesure que les technologies sous-jacentes de raisonnement, de validation et d’auto-correction de l’agent progressent, le système continuera d’évoluer,
  avec pour mission de fournir de manière fluide une analyse de données rapide et fiable à l’échelle de tout l’écosystème de données d’OpenAI