Dins de l’agent de dades intern d’OpenAI

Les dades impulsen com aprenen els sistemes, com evolucionen els productes i com les empreses prenen decisions. Però obtenir respostes ràpidament, correctament i amb el context adequat sovint és més difícil del que hauria de ser. Per facilitar-ho a mesura que OpenAI escala, vam construir el nostre propi agent de dades d’IA intern i a mida que explora i raona sobre la nostra pròpia plataforma.

El nostre agent és una eina interna personalitzada només per a ús intern (no una oferta externa), construïda específicament al voltant de les dades, els permisos i els fluxos de treball d’OpenAI. Mostrem com l’hem construït i com l’utilitzem per ajudar a fer aflorar exemples de les maneres reals i impactants en què la IA pot donar suport al treball quotidià dels nostres equips. Les eines d’OpenAI que vam utilitzar per construir-lo i executar-lo (Codex, el nostre model insígnia GPT‑5, l’API Evals⁠(s'obre en una finestra nova) i l’API Embeddings⁠(s'obre en una finestra nova)) són les mateixes eines que posem a disposició dels desenvolupadors de tot arreu.

El nostre agent de dades permet als empleats passar de la pregunta a la informació en minuts, no en dies. Això rebaixa la barrera per obtenir dades i anàlisis matisades a totes les funcions, no només per part del nostre equip de dades. Avui dia, equips d’Enginyeria, Data Science, Go-To-Market, Finances i Recerca a OpenAI es recolzen en l’agent per respondre preguntes de dades d’alt impacte. Per exemple, pot ajudar a respondre com avaluar llançaments i entendre la salut del negoci, tot a través del format intuïtiu del llenguatge natural. L’agent combina coneixement a nivell de taula impulsat per Codex amb context de producte i organitzatiu. El seu sistema de Memòria, que aprèn contínuament, significa que també millora amb cada torn.

En aquesta entrada, desglossarem per què necessitàvem un agent de dades d’IA a mida, què fa tan útils el seu context de dades enriquit amb codi i el seu autoaprenentatge, i les lliçons que vam aprendre pel camí.

La plataforma de dades d’OpenAI dona servei a més de 3,5 mil usuaris interns que treballen a Enginyeria, Producte i Recerca, i abasta més de 600 petabytes de dades en 70 mil conjunts de dades. Amb aquesta escala, simplement trobar la taula correcta pot ser una de les parts que més temps consumeix de fer una anàlisi.

Tal com va dir un usuari intern:

«Tenim moltes taules que s’assemblen força, i dedico moltíssim temps a intentar esbrinar en què es diferencien i quina he d’utilitzar. Algunes inclouen usuaris amb la sessió tancada i d’altres no. Algunes tenen camps solapats; és difícil saber què és cada cosa.»

Fins i tot amb les taules correctes seleccionades, produir resultats correctes pot ser complicat. Els analistes han de raonar sobre les dades de les taules i les relacions entre taules per assegurar-se que les transformacions i els filtres s’apliquen correctament. Els modes de fallada habituals —joins molts a molts, errors de propagació de filtres i valors nuls no gestionats— poden invalidar silenciosament els resultats. A l’escala d’OpenAI, els analistes no haurien d’haver de dedicar temps a depurar la semàntica SQL o el rendiment de les consultes: s’haurien de centrar a definir mètriques, validar supòsits i prendre decisions basades en dades.

Vegem pas a pas què és el nostre agent, com selecciona el context i com continua millorant per si mateix.

El nostre agent funciona amb GPT‑5.2 i està dissenyat per raonar sobre la plataforma de dades d’OpenAI. Està disponible allà on els empleats ja treballen: com a agent de Slack, a través d’una interfície web, dins dels IDE, al Codex CLI via MCP⁠(s'obre en una finestra nova) i directament a l’aplicació interna ChatGPT d’OpenAI a través d’un connector MCP⁠(s'obre en una finestra nova).

Els usuaris poden fer preguntes complexes i obertes que normalment requeririen diverses rondes d’exploració manual. Prenem aquest exemple d’indicació, que fa servir un conjunt de dades de prova: «Per als trajectes de taxi de NYC, quins parells de codis postals de recollida a deixada són els menys fiables, amb la bretxa més gran entre els temps de viatge habituals i els del pitjor cas, i quan es produeix aquesta variabilitat?»

L’agent gestiona l’anàlisi de cap a cap, des de la comprensió de la pregunta fins a l’exploració de les dades, l’execució de consultes i la síntesi de les conclusions.

Una de les superpotències de l’agent és com raona sobre els problemes. En lloc de seguir un guió fix, l’agent avalua el seu propi progrés. Si un resultat intermedi sembla incorrecte (p. ex., si té zero files a causa d’un join o filtre incorrecte), l’agent investiga què ha anat malament, ajusta el seu enfocament i ho torna a intentar. Durant tot aquest procés, conserva el context complet i trasllada els aprenentatges d’un pas a l’altre. Aquest procés tancat i d’autoaprenentatge desplaça la iteració de l’usuari cap al mateix agent, cosa que permet resultats més ràpids i anàlisis de més qualitat de manera consistent que els fluxos de treball manuals.

L’agent cobreix tot el flux de treball analític: descobrir dades, executar SQL i publicar llibretes i informes. Entén el coneixement intern de l’empresa, pot fer cerques web d’informació externa i millora amb el temps a través de l’ús après i la Memòria.

Les respostes d’alta qualitat depenen d’un context ric i precís. Sense context, fins i tot models potents poden produir resultats erronis, com ara sobreestimar enormement els recomptes d’usuaris o interpretar malament la terminologia interna.

Per evitar aquests modes de fallada, l’agent està construït al voltant de múltiples capes de context que l’ancoren en les dades i el coneixement institucional d’OpenAI.

• Ancoratge de metadades: L’agent es basa en metadades d’esquema (noms de columnes i tipus de dades) per informar l’escriptura de SQL i utilitza el llinatge de taules (p. ex., relacions entre taules aigües amunt i aigües avall) per proporcionar context sobre com es relacionen diferents taules.
• Inferència de consultes: La ingestió de consultes històriques ajuda l’agent a entendre com escriure les seves pròpies consultes i quines taules s’uneixen habitualment.

• Descripcions seleccionades de taules i columnes proporcionades per experts del domini, que capturen la intenció, la semàntica, el significat empresarial i les advertències conegudes que no es poden inferir fàcilment a partir dels esquemes o de consultes anteriors.

Les metadades per si soles no són suficients. Per distingir realment les taules, cal entendre com es van crear i d’on provenen.

• En derivar una definició d’una taula a nivell de codi, l’agent construeix una comprensió més profunda del que realment contenen les dades. 
  • Els matisos sobre què s’emmagatzema a la taula i com es deriva d’un esdeveniment d’analítica proporcionen informació addicional. Per exemple, pot donar context sobre la unicitat dels valors, la freqüència amb què s’actualitzen les dades de la taula, l’abast de les dades (p. ex., si la taula exclou determinats camps, aquest és el seu nivell de granularitat), etc.
• Això proporciona un context d’ús millorat en mostrar com s’utilitza la taula més enllà de l’SQL en Spark, Python i altres sistemes de dades.
• Això vol dir que l’agent pot distingir entre taules que semblen similars però que difereixen en aspectes crítics. Per exemple, pot saber si una taula només inclou trànsit de ChatGPT de primera part. Aquest context també s’actualitza automàticament, de manera que es manté al dia sense manteniment manual.

• L’agent pot accedir a Slack, Google Docs i Notion, que capturen context crític de l’empresa com ara llançaments, incidents de fiabilitat, noms en clau i eines internes, i les definicions canòniques i la lògica de càlcul de mètriques clau.
• Aquests documents s’ingereixen, es converteixen en embeddings i s’emmagatzemen amb metadades i permisos. Un servei de recuperació gestiona el control d’accés i la memòria cau en temps d’execució, cosa que permet a l’agent incorporar aquesta informació de manera eficient i segura.

• Quan es donen correccions a l’agent o descobreix matisos sobre determinades preguntes de dades, és capaç de desar aquests aprenentatges per a la pròxima vegada, cosa que li permet millorar constantment amb els seus usuaris. 
  • Com a resultat, les respostes futures comencen des d’una base més precisa en lloc de topar repetidament amb els mateixos problemes.
  • L’objectiu de la Memòria és retenir i reutilitzar correccions, filtres i restriccions no evidents que són crucials per a la correcció de les dades però difícils d’inferir només a partir de les altres capes. 
  • Per exemple, en un cas, l’agent no sabia com filtrar un experiment analític concret (es basava en la coincidència amb una cadena específica definida en una porta d’experiment). La Memòria va ser crucial aquí per assegurar que pogués filtrar correctament, en lloc d’intentar fer una coincidència difusa de cadenes.
• Quan dones una correcció a l’agent o quan troba un aprenentatge a la teva conversa, et demanarà que desis aquesta Memòria per a la pròxima vegada. 
  • Les memòries també poden ser creades i editades manualment pels usuaris.
  • Les memòries tenen abast global i personal, i les eines de l’agent fan que sigui fàcil editar-les.

• Quan no existeix context previ per a una taula o quan la informació existent està desactualitzada, l’agent pot emetre consultes en viu al magatzem de dades per inspeccionar i consultar la taula directament. Això li permet validar esquemes, entendre les dades en temps real i respondre en conseqüència.
• L’agent també pot parlar amb altres sistemes de Data Platform (servei de metadades, Airflow, Spark) segons calgui per obtenir un context de dades més ampli que existeix fora del magatzem.

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'obre en una finestra nova) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(s'obre en una finestra nova) (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'obre en una finestra nova) 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.