À l'intérieur de l'agent de données interne d'OpenAI

Les données alimentent la manière dont les systèmes apprennent, les produits évoluent et 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 simplifier les opérations à mesure qu'OpenAI se développe, nous avons conçu notre propre agent de données IA sur mesure, développé en interne, qui explore et raisonne sur notre propre plateforme.

Notre agent est un outil interne personnalisé (non destiné à une offre externe), conçu spécifiquement pour les données, les autorisations et les flux de travail d’OpenAI. Nous montrons comment nous l’avons conçu et l’utilisons pour mettre en lumière 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 l’exécuter (Codex, notre modèle phare GPT‑5, l’ API Evals⁠(s'ouvre dans une nouvelle fenêtre) et l’API Embeddings⁠(s'ouvre dans une nouvelle fenêtre)) sont les mêmes outils que nous mettons à la disposition des développeurs partout dans le monde.

Notre agent de données permet aux employés de passer d’une question à une information en quelques minutes, pas en quelques jours. Cela facilite l'extraction de données et la réalisation d'analyses nuancées dans toutes les fonctions, et pas seulement par notre équipe chargée des données. Aujourd’hui, les équipes d’ingénierie, de science des données, de stratégie de mise sur le marché, de finance et de recherche chez OpenAI s’appuient sur l’agent pour répondre à des questions de données à fort impact. Par exemple, cela peut vous 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 tableaux, alimentées par Codex, avec le contexte du produit et de l’organisation. Son système de mémoire en apprentissage continu signifie qu'il s'améliore également à chaque interaction.

Dans cet article, nous allons expliquer pourquoi nous avions besoin d’un agent de données IA sur mesure, ce qui rend son contexte de données enrichi en code et son apprentissage autonome si utiles, ainsi que 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 équipes d’ingénierie, de produit et de recherche, couvrant plus de 600 pétaoctets de données réparties sur 70 000 ensembles de données. À cette taille, trouver le bon tableau peut être l'une des étapes les plus longues de l'analyse.

Comme l’a exprimé un utilisateur interne :

« Nous avons de nombreux tableaux qui se ressemblent, et je passe énormément de temps à essayer de comprendre leurs différences et lequel utiliser. Certains incluent les utilisateurs déconnectés, d'autres non. Certains ont des champs qui se chevauchent ; il est difficile de savoir ce qui est quoi. »

Même avec les bons tableaux sélectionnés, il peut être difficile d’obtenir des résultats corrects. Les analystes doivent analyser les données des tableaux et les relations entre eux pour garantir 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 propagation des filtres et les valeurs nulles non gérées, peuvent invalider les résultats sans avertissement. À l’échelle d’OpenAI, les analystes ne devraient pas avoir à perdre du temps à déboguer la sémantique SQL ou la performance 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.

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

Notre agent est alimenté par GPT‑5.2 et est conçu pour raisonner sur 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, à l’intérieur des IDE, dans la CLI Codex via MCP⁠(s'ouvre dans une nouvelle fenêtre), et directement dans l’application interne ChatGPT d’OpenAI via un connecteur MCP⁠(s'ouvre dans une nouvelle fenêtre).

Les utilisateurs peuvent poser des questions complexes et ouvertes qui nécessiteraient généralement plusieurs étapes d’exploration manuelle. Prenez cet exemple d’invite, qui utilise un jeu de données de test : « Pour les trajets de taxi à NYC, quelles paires de codes postaux entre le point de prise en charge et le point de dépose sont les moins fiables, avec le plus grand écart entre les temps de trajet typiques et les pires cas, et quand cette variabilité se produit-elle? »

L’agent gère l’analyse de bout en bout, de la compréhension de la question à l’exploration des données, l’exécution de requêtes et la synthèse des résultats.

L’un des superpouvoirs de l’agent est sa capacité à raisonner à travers 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 examine ce qui a mal tourné, ajuste son approche et réessaie. Tout au long de ce processus, il conserve l'intégralité du contexte et transmet les apprentissages d'une étape à l'autre. Ce processus en boucle fermée et autoapprenant transfère l’itération de l’utilisateur à l’agent lui-même, permettant d’obtenir des résultats plus rapides et des analyses de qualité supérieure de manière constante par rapport aux flux de travail manuels.

L’agent couvre l’ensemble du flux de travail analytique : découverte de données, exécution de SQL, publication de carnets et rapports. Il comprend les connaissances internes de l’entreprise, peut effectuer des recherches sur le Web pour obtenir des informations externes et s’améliore au fil du temps grâce à l’utilisation et à la mémoire acquises.

Des réponses de haute qualité dépendent d’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 conçu autour de plusieurs couches de contexte qui l’ancrent dans les données et le savoir institutionnel d’OpenAI.

• Ancrage des 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 SQL et utilise la lignée des tableaux (par exemple, les relations de tableaux en amont et en aval) pour fournir un contexte sur la manière dont différents tableaux sont reliés.
• Inférence de requête : L’intégration des requêtes historiques aide l’agent à comprendre comment écrire ses propres requêtes et quelles tableaux sont généralement assemblés.

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

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

• En établissant une définition au niveau du code d'un tableau, l'agent développe une compréhension plus approfondie de ce que les données contiennent réellement. 
  • Les nuances concernant ce qui est stocké dans le tableau et la manière dont cela est dérivé d’un événement analytique apportent des informations supplémentaires. Par exemple, cela peut fournir du contexte sur le caractère unique des valeurs, la fréquence de mise à jour des données du tableau, la portée des données (p. ex., si le tableau exclut certains champs, il présente ce niveau de granularité), etc.
• Cela offre un contexte d'utilisation enrichi en illustrant comment le tableau est exploité au-delà de SQL dans Spark, Python et d'autres systèmes de données.
• Cela signifie que l’agent peut distinguer entre des tableaux qui se ressemblent mais diffèrent de manière cruciale. Par exemple, il peut indiquer si un tableau inclut uniquement le trafic de première partie de ChatGPT. Ce contexte est également actualisé automatiquement, ce qui lui permet de rester à jour sans entretien manuel.

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

• Lorsque l’agent reçoit des corrections ou découvre des nuances sur certaines questions de données, il peut enregistrer ces apprentissages pour la prochaine fois, ce qui lui permet de s’améliorer constamment avec ses utilisateurs. 
  • Par conséquent, les réponses futures partent d'une base de référence plus précise plutôt que de rencontrer à répétition les mêmes problèmes.
  • L’objectif de la mémoire est de conserver et de réutiliser des corrections, des filtres et des contraintes non évidentes qui sont essentielles à l’exactitude des données, mais difficiles à déduire des autres couches seules. 
  • Par exemple, dans un cas, l’agent ne savait pas comment filtrer un certain test analytique (cela reposait sur une correspondance avec une chaîne précise définie dans un portail d'expérimentation). La mémoire était d'une importance cruciale ici pour garantir qu'elle puisse filtrer correctement, plutôt que d'essayer de faire une correspondance de chaînes de manière approximative.
• Lorsque vous donnez une correction à l’agent ou lorsqu’il trouve un apprentissage dans votre conversation, il vous invite à sauvegarder 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 classées au niveau global et personnel, et les outils de l'agent facilitent leur modification.

• Lorsqu'il n'existe aucun contexte préalable pour un tableau ou lorsque les informations existantes sont obsolètes, l'agent peut envoyer des requêtes en direct à l'entrepôt de données afin d'inspecter et de consulter directement le tableau. 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 dialoguer avec d’autres systèmes de la plateforme de données (service de métadonnées, Airflow, Spark) au besoin 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⁠(s'ouvre 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⁠(s'ouvre 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⁠(s'ouvre 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.