- 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
1 commentaires
Réactions sur Hacker News
La fiabilité et l’explicabilité sont le plus gros problème
Cela fait 10 ans que nous développons l’analyse en langage naturel chez Veezoo, et une approche simple de type Text-to-SQL ne passe pas à l’échelle
Quand un CFO demande le chiffre d’affaires, un nombre juste à 99 % ne veut rien dire, et le CFO ne peut pas non plus valider lui-même le SQL
C’est pourquoi nous avons mis en place une couche d’abstraction appelée Knowledge Graph, où l’IA convertit le langage naturel en langage de requête sémantique, puis le compile de manière déterministe en SQL
À l’inverse, cette requête sémantique peut être reconvertie en explication en langage naturel afin que l’utilisateur puisse facilement vérifier si le résultat correspond bien à son intention
La logique métier réside dans le Knowledge Graph, et le compilateur garantit que toutes les requêtes la respectent à 100 %
L’architecture en détail est décrite dans la documentation Veezoo Architecture
Je me demande comment vous gérez l’explosion de cardinalité, et comment vous traitez les requêtes multi-étapes qui dépendent des résultats des requêtes précédentes
Il faut pouvoir retracer quelle requête a été utilisée à quelle date et comment elle a été validée
(Bien sûr, les prompts doivent eux aussi être versionnés)
J’ai été surpris que le premier exemple soit totalement illogique
Si cela a passé une relecture humaine, j’imagine que c’était probablement rédigé par une IA, ce qui soulève des questions sur la fiabilité du système
Lien vers l’image en question
Sur desktop, le prompt est correct,
tandis que sur mobile, le prompt est erroné
Pour avoir utilisé plusieurs systèmes de BI, je pense que ce type d’agent IA est un cas d’usage parfait
La BI produit déjà des erreurs à plusieurs niveaux — soit la requête elle-même est fausse, soit l’interprétation des données est erronée
Quand ces deux problèmes se combinent, on est déjà dans un « monde imaginaire », donc autant laisser l’IA prendre en charge l’étape 1
J’espérais qu’OpenAI aurait résolu le problème de fiabilité, mais malheureusement ce n’est pas le cas
Étape 0 : les données sont mal stockées
Étape -1 : le modèle est mal compris dès le départ
Étape -2 : le processus métier est erroné dès l’origine
C’est pour cela que je parle d’une « source unique de mensonge » plutôt que d’une « source unique de vérité »
Le plus difficile, c’est de faire passer la confiance à l’échelle
Nous construisons quelque chose de similaire, et même avec une excellente boucle agentique, il faut au final des métriques de référence validées par des humains (canonical metrics)
Sinon, des utilisateurs non techniques prennent des décisions risquées à partir d’un SQL impossible à vérifier
Notre approche est la suivante
Avec le temps, la plupart des requêtes finissent par utiliser des métriques standardisées, et l’agent devient non plus un simple générateur de SQL, mais un routeur intelligent intention → métrique validée
Le système d’évaluation Golden SQL de la section « avancer vite sans casser la confiance » reflète la même intuition
J’ai résumé cela dans ce billet de blog
S’il existe plusieurs chemins pour arriver à une réponse, on obtient des résultats différents
Les LLM inventent souvent des métriques dénuées de sens comme « xyz_index », et les utilisateurs les prennent telles quelles parce qu’elles ont l’air plausibles
À mon avis, le véritable impact de l’IA sur l’emploi des développeurs sera la qualité des données et de la documentation
L’efficacité avec laquelle une entreprise peut exploiter l’IA dépend de la qualité d’organisation de ses données
Les données publiques sont déjà épuisées, et la prochaine ressource, ce sont les documents internes, les dépôts de code et les data lakes
Les entreprises qui ont de bonnes fondations dans ce domaine pourront créer et maintenir de nouveaux services avec l’IA plus vite et à moindre coût
À l’inverse, dans les entreprises où la documentation et la gestion du code sont chaotiques, l’IA ne fonctionnera pas correctement
Elles finiront par perdre des parts de marché au profit de leurs concurrents
C’est pourquoi, lors de mes prochaines recherches d’emploi, je compte toujours demander quel est leur niveau de gestion de la documentation, des données et des dépôts
Chez Amplitude, ils ont construit un système similaire appelé Moda
Il y a quelques mois, Wade a montré à Claire Vo une vidéo de démo, et c’était vraiment excellent
Je l’utilise tous les jours pour poser toutes sortes de questions
Nous proposons nous aussi une fonctionnalité similaire sur Definite.app en 5 minutes
Pas besoin de Spark ni de Snowflake
Nous fournissons data lake, pipelines, couche sémantique et agent de données dans une seule application
En réalité, construire l’infrastructure de données est bien plus difficile que l’agent lui-même
Si un agent sait seulement écrire du SQL, il reste très limité, mais nous avons changé la donne en lui permettant de gérer l’infrastructure elle-même
Très bon contenu
En revanche, il semble manquer la partie sur la manière dont le résultat a été calculé
Pour un usage interne chez OpenAI, supposer que l’utilisateur puisse lire le SQL est acceptable, mais pour des utilisateurs non techniques, c’est un vrai défi de conception
Dès qu’on travaille avec des systèmes de données, on comprend vite que le « comment la réponse a été obtenue » est presque aussi important que la réponse elle-même
Personnellement, je trouve l’In-House Data Agent de Kimi plus intéressant
Les problèmes de données ne sont pas des problèmes techniques, mais des problèmes d’organisation
D’après mon expérience, la cause des problèmes de données n’est pas un « mauvais choix technologique », mais les décisions de gouvernance et de propriété
Au final, tout ramène à la loi de Conway