Découvrir l’agent de données interne d’OpenAI

Les données déterminent la façon dont les systèmes apprennent, dont les produits évoluent et dont les entreprises prennent des décisions. Mais obtenir des réponses rapidement, correctement et dans le bon contexte est souvent plus difficile que cela ne devrait l’être. Pour faciliter cette tâche au fur et à mesure qu’OpenAI se développe, nous avons conçu notre propre agent de données IA interne sur mesure qui explore et raisonne sur notre propre plateforme.

Notre agent est un outil interne personnalisé (et non une offre externe), conçu spécifiquement pour les données, les autorisations et les workflows d’OpenAI. Nous montrons comment nous l’avons conçu et l’utilisons pour mettre en évidence des exemples concrets et marquants de la manière dont l’IA peut soutenir le travail quotidien de nos équipes. Les outils OpenAI que nous avons utilisés pour le créer et le faire fonctionner (Codex, notre modèle phare GPT‑5, l’API Evals⁠(ouverture dans une nouvelle fenêtre) et l’API Embeddings⁠(ouverture dans une nouvelle fenêtre)) sont les mêmes outils que ceux que nous mettons à la disposition des développeurs partout dans le monde.

Notre agent de données permet aux employés de passer de la question à la réponse en quelques minutes, et non en plusieurs jours. Cela facilite l’extraction de données et l’analyse nuancée pour toutes les fonctions, et pas seulement pour notre équipe de données. Aujourd’hui, les équipes d’OpenAI dans les domaines de l’ingénierie, de la science des données, de la stratégie de mise sur le marché, des finances et de la recherche s’appuient sur l’agent pour répondre à des questions de données à fort impact. Par exemple, cela peut aider à évaluer les lancements et à comprendre la santé de l’entreprise, le tout grâce au format intuitif du langage naturel. L’agent associe des connaissances au niveau des tables, propulsées par Codex, avec le contexte du produit et de l’organisation. Son système de mémoire à apprentissage continu signifie qu’il s'améliore également à chaque interaction.

Dans cet article, nous allons détailler pourquoi nous avions besoin d’un agent de données IA sur mesure, ce qui rend son contexte de données enrichi par le code et son auto-apprentissage si utiles, et les leçons que nous avons apprises en cours de route.

La plateforme de données d’OpenAI dessert plus de 3 500 utilisateurs internes travaillant dans les domaines de l’ingénierie, des produits et de la recherche, couvrant plus de 600 pétaoctets de données réparties sur 70 000 ensembles de données. À cette échelle, le simple fait de trouver la bonne table peut être l’une des parties les plus fastidieuses de l’analyse.

Comme l’a exprimé un utilisateur interne :

« Nous avons beaucoup de tables assez similaires, et je passe énormément de temps à essayer de comprendre en quoi elles sont différentes et laquelle utiliser. Certaines incluent les utilisateurs déconnectés, d’autres non. Certaines ont des champs qui se chevauchent ; il est difficile de faire la part des choses. »

Même avec les bonnes tables sélectionnées, il peut être difficile d’obtenir des résultats corrects. Les analystes doivent raisonner sur les données des tables et les relations entre les tables afin de s’assurer que les transformations et les filtres sont appliqués correctement. Les modes de défaillance courants, tels que les jointures plusieurs-à-plusieurs, les erreurs de filtrage et les valeurs nulles non gérées, peuvent invalider silencieusement les résultats. À l’échelle d’OpenAI, les analystes ne devraient pas avoir à perdre du temps à déboguer la sémantique SQL ou les performances des requêtes ; ils devraient se concentrer sur la définition des indicateurs, la validation des hypothèses et la prise de décisions fondées sur les données.

Voyons ce qu’est notre agent, comment il organise le contexte et comment il continue de s’auto-améliorer.

Notre agent est propulsé par GPT‑5.2. Il est conçu pour analyser la plateforme de données d’OpenAI. Il est disponible partout où les employés travaillent déjà : en tant qu’agent Slack, via une interface Web, dans les IDE, dans la CLI Codex via MCP⁠(ouverture dans une nouvelle fenêtre), et directement dans l’application interne ChatGPT d’OpenAI via un connecteur MCP⁠(ouverture dans une nouvelle fenêtre).

Les utilisateurs peuvent poser des questions complexes et ouvertes nécessitant généralement plusieurs cycles d’exploration manuelle. Voyez cet exemple de prompt, qui utilise un jeu de données de test  :« Pour les trajets en taxi à New York, quelles paires de codes postaux entre le lieu de prise en charge et le lieu de dépose sont les moins fiables, avec l’écart le plus important entre les temps de trajet typiques et les pires scénarios, et quand cette variabilité se produit-elle ? »

L’agent prend en charge l’analyse de bout en bout, depuis la compréhension de la question jusqu’à l’exploration des données, en passant par l’exécution de requêtes et la synthèse des résultats.

L'un des superpouvoirs de l’agent est sa capacité à raisonner pour résoudre les problèmes. Plutôt que de suivre un script fixe, l’agent évalue ses propres progrès. Si un résultat intermédiaire semble incorrect (par exemple, s’il comporte zéro ligne en raison d’une jointure ou d’un filtre incorrect), l’agent recherche ce qui n’a pas fonctionné, ajuste son approche et réessaie. Tout au long de ce processus, il conserve l’intégralité du contexte et applique les enseignements d’une étape à l’autre. Ce processus d’auto-apprentissage en boucle fermée transfère l’itération de l’utilisateur vers l’agent lui-même, ce qui permet d’obtenir des résultats plus rapides et des analyses de meilleure qualité qu’avec les workflows manuels.

L’agent couvre l’ensemble du workflow analytique : découverte des données, exécution de requêtes SQL et publication de carnets de notes et de rapports. Il comprend les connaissances internes de l’entreprise, peut rechercher des informations externes sur le Web et s’améliore au fil du temps grâce à l’apprentissage et à la mémoire.

Pour obtenir des réponses qualité il est nécessaire d’avoir un contexte riche et précis. Sans contexte, même des modèles performants peuvent produire des résultats erronés, comme surestimer considérablement le nombre d’utilisateurs ou mal interpréter la terminologie interne.

Pour éviter ces modes de défaillance, l’agent est construit autour de plusieurs couches de contexte qui l’ancrent dans les données et les connaissances institutionnelles d’OpenAI.

• Ancrage sur les métadonnées : L’agent s’appuie sur les métadonnées du schéma (noms de colonnes et types de données) pour orienter la rédaction de requêtes SQL et utilise la lignée des tables (par exemple, les relations entre les tables en amont et en aval) pour fournir un contexte sur la façon dont les différentes tables sont reliées.
• Déduction tirée des requêtes : L’ingestion de requêtes passées aide l’agent à comprendre comment rédiger ses propres requêtes et quelles tables sont généralement jointes entre elles.

• Descriptions organisées des tables et des colonnes fournies par des experts du domaine, capturant l’intention, la sémantique, la signification commercial et les mises en garde connues qui ne sont pas facilement déductibles des schémas ou des requêtes antérieures.

Les métadonnées seules ne suffisent pas. Pour vraiment distinguer les tables, vous devez comprendre comment elles ont été créées et d’où elles proviennent.

• En établissant une définition au niveau du code d’une table, l’agent développe une compréhension plus approfondie de ce que les données contiennent réellement. 
  • Des précisions sur ce qui est stocké dans la table et sur la manière dont cela est dérivé d’un événement analytique fournissent des informations supplémentaires. Par exemple, cela peut fournir un contexte sur le caractère unique des valeurs, la fréquence de mise à jour des données de la table, la portée des données (par ex., si la table exclut certains champs, présente ce niveau de granularité), etc.
• Cela permet d’améliorer le contexte d’utilisation en montrant comment la table est utilisée au-delà de SQL dans Spark, Python et d’autres systèmes de données.
• Cela signifie que l’agent peut faire la distinction entre des tables qui se ressemblent, mais qui présentent des différences importantes. Par exemple, cela peut indiquer si une table inclut uniquement du trafic ChatGPT de première partie. Ce contexte est également actualisé automatiquement, de sorte qu’il reste à jour sans nécessiter de maintenance manuelle.

• L’agent peut accéder à Slack, Google Docs et Notion, ce qui lui permet de saisir le contexte critique de l’entreprise, comme les lancements, les incidents de fiabilité, les noms de code et les outils internes, ainsi que les définitions canoniques et la logique de calcul pour les indicateurs clés.
• Ces documents sont ingérés, intégrés et stockés avec les métadonnées et les autorisations. Un service de récupération gère le contrôle d’accès et la mise en cache à l’exécution, permettant ainsi à l’agent de récupérer ces informations de manière efficace et sécurisée.

• Lorsque l’agent reçoit des corrections ou découvre des nuances sur certaines questions, il peut enregistrer ces apprentissages pour la prochaine fois, ce qui lui permet de s’améliorer continuellement grâce à ses utilisateurs. 
  • Par conséquent, les réponses futures partent d’une base plus précise au lieu de rencontrer les mêmes problèmes à plusieurs reprises.
  • L’objectif de la mémoire est de conserver et de réutiliser des corrections, des filtres et des contraintes non évidents, qui sont essentiels à l’exactitude des données mais difficiles à déduire des autres couches seules. 
  • Par exemple, dans un scénario, l’agent ne savait pas comment filtrer une expérience analytique particulière (cette dernière reposait sur une correspondance avec une chaîne spécifique définie dans un seuil d’expérimentation). La mémoire était essentielle ici pour s’assurer que l’agent puisse filtrer correctement, plutôt que d’essayer de faire une correspondance de chaînes de manière floue.
• Lorsque vous donnez une correction à l’agent ou lorsqu'il tire un enseignement de votre conversation, il vous incitera à enregistrer cette mémoire pour la prochaine fois. 
  • Les mémoires peuvent également être créées et modifiées manuellement par les utilisateurs.
  • Les mémoires sont définies au niveau global et personnel, et les outils de l’agent permettent de les modifier facilement.

• Lorsqu’aucun contexte préalable n’existe pour une table ou que les informations existantes sont obsolètes, l’agent peut exécuter des requêtes en direct vers l’entrepôt de données afin d’inspecter et d’interroger la table directement. Cela lui permet de valider des schémas, de comprendre les données en temps réel et de réagir en conséquence.
• L’agent est également capable de communiquer avec d’autres systèmes de la plateforme de données (service de métadonnées, Airflow, Spark) si nécessaire pour obtenir un contexte de données plus large qui existe en dehors de l’entrepôt.

We run a daily offline pipeline that aggregates table usage, human annotations, and Codex-derived enrichment into a single, normalized representation. This enriched context is then converted into embeddings using the OpenAI embeddings API⁠(ouverture dans une nouvelle fenêtre) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(ouverture dans une nouvelle fenêtre) (RAG) instead of scanning raw metadata or logs. This makes table understanding fast and scalable, even across tens of thousands of tables, while keeping runtime latency predictable and low. Runtime queries are issued to our data warehouse live as needed.

Together, these layers ensure the agent’s reasoning is grounded in OpenAI’s data, code, and institutional knowledge, dramatically reducing errors and improving answer quality.

One-shot answers work when the problem is clear, but most questions aren’t. More often, arriving at the correct result requires back-and-forth refinement and some course correction.

The agent is built to behave like a teammate you can reason with. It’s a conversational, always-on and handles both quick answers and iterative exploration.

It carries over complete context across turns, so users can ask follow-up questions, adjust their intent, or change direction without restating everything. If the agent starts heading down the wrong path, users can interrupt mid-analysis and redirect it, just like working with a human collaborator who listens instead of plowing ahead.

When instructions are unclear or incomplete, the agent proactively asks clarifying questions. If no response is provided, it applies sensible defaults to make progress. For example, if a user asks about business growth with no date range specified, it may assume the last seven or 30 days. These priors allow it to stay responsive and non-blocking while still converging on the right outcome.

The result is an agent that works well both when you know exactly what you want (e.g., “Tell me about this table”) and just as strong when you’re exploring (e.g., “I’m seeing a dip here, can we break this down by customer type and timeframe?”). 

After rollout, we observed that users frequently ran the same analyses for routine repetitive work. To expedite this, the agent's workflows package recurring analyses into reusable instruction sets. Examples include workflows for weekly business reports and table validations. By encoding context and best practices once, workflows streamline repeat analyses and ensure consistent results across users.

Building an always-on, evolving agent means quality can drift just as easily as it can improve. Without a tight feedback loop, regressions are inevitable and invisible. The only way to scale capability without breaking trust is through systematic evaluation.

In this section, we’ll discuss how we leverage OpenAI’s Evals API⁠(ouverture dans une nouvelle fenêtre) to measure and protect the agent’s response quality.

Its Evals are built on curated sets of question-answer pairs. Each question targets an important metric or analytical pattern we care deeply about getting right, paired with a manually authored “golden” SQL query that produces the expected result. For each eval, we send the natural language question to its query-generation endpoint, execute the generated SQL, and compare the output against the result of the expected SQL.

Evaluation doesn’t rely on naive string matching. Generated SQL can differ syntactically while still being correct, and result sets may include extra columns that don’t materially affect the answer. To account for this, we compare both the SQL and the resulting data, and feed these signals into OpenAI’s Evals grader. The grader produces a final score along with an explanation, capturing both correctness and acceptable variation.

These evals are like unit tests that run continuously during development to identify regressions as canaries in production; this allows us to catch issues early and confidently iterate as the agent's capabilities expand.

Our agent plugs directly into OpenAI’s existing security and access-control model. It operates purely as an interface layer, inheriting and enforcing the same permissions and guardrails that govern OpenAI’s data. 

All of the agent’s access is strictly pass-through, meaning users can only query tables they already have permission to access. When access is missing, it flags this or falls back to alternative datasets the user is authorized to use.

Finally, it's built for transparency. Like any system, it can make mistakes. It exposes its reasoning process by summarizing assumptions and execution steps alongside each answer. When queries are executed, it links directly to the underlying results, allowing users to inspect raw data and verify every step of the analysis.

Building our agent from scratch surfaced practical lessons about how agents behave, where they struggle, and what actually makes them reliable at scale.

Early on, we exposed our full tool set to the agent, and quickly ran into problems with overlapping functionality. While this redundancy can be helpful for specific custom cases and is more obvious to a human when manually invoking, it’s confusing to agents. To reduce ambiguity and improve reliability, we restricted and consolidated certain tool calls.

We also discovered that highly prescriptive prompting degraded results. While many questions share a general analytical shape, the details vary enough that rigid instructions often pushed the agent down incorrect paths. By shifting to higher-level guidance and relying on GPT‑5’s reasoning to choose the appropriate execution path, the agent became more robust and produced better results.

Schemas and query history describe a table’s shape and usage, but its true meaning lives in the code that produces it. Pipeline logic captures assumptions, freshness guarantees, and business intent that never surface in SQL or metadata. By crawling the codebase with Codex, our agent understands how datasets are actually constructed and is able to better reason about what each table actually contains. It can answer “what’s in here” and “when can I use it” far more accurately than from warehouse signals alone. 

We’re constantly working to improve our agent by increasing its ability to handle ambiguous questions, improving its reliability and accuracy with stronger validations, and integrating it more deeply into workflows. We believe it should blend naturally into how people already work, instead of functioning like a separate tool.

While our tooling will keep benefiting from underlying improvements in agent reasoning, validation, and self-correction, our team’s mission remains the same: seamlessly deliver fast, trustworthy data analysis across OpenAI’s data ecosystem.