Inde i OpenAIs interne dataagent

Data driver den måde, hvorpå systemer lærer, produkter udvikler sig, og hvordan virksomheder træffer beslutninger. At få svar hurtigt, korrekt og med den rigtige kontekst er dog ofte sværere, end det burde være. For at gøre dette nemmere i takt med at OpenAI skalerer, har vi bygget vores egen skræddersyede interne AI-dataagent, der udforsker og ræsonnerer på vores egen platform.

Vores agent er et brugerdefineret internt værktøj (og ikke et eksternt tilbud), der er bygget specifikt omkring OpenAIs data, tilladelser og arbejdsgange. Vi viser, hvordan vi har bygget det, og hvordan vi bruger det, til at afdække eksempler på de virkelige og effektive måder, hvorpå AI kan understøtte det daglige arbejde på tværs af vores teams. De OpenAI-værktøjer, vi brugte til at bygge og køre det (Codex, vores GPT‑5‑flagskibsmodel, Evals API⁠(åbner i et nyt vindue) og Embeddings API⁠(åbner i et nyt vindue)), er de samme værktøjer, som vi stiller til rådighed for udviklere overalt.

Vores dataagent lader medarbejdere gå fra spørgsmål til indsigt på få minutter i stedet for dage. Dette gør det lettere for alle at trække data og udføre nuanceret analyse på tværs af alle funktioner, og ikke kun af vores datateam. I dag bruger OpenAI's teams indenfor ingeniørvidenskab, datalogi, markedsføring, finans og forskning agenten til at besvare dataspørgsmål med stor betydning. For eksempel kan det hjælpe med at besvare spørgsmål om, hvordan man evaluerer lanceringer og forstår virksomhedens sundhed, alt sammen gennem det intuitive format af naturligt sprog. Agenten kombinerer Codex-drevet viden på tabelniveau med produkt- og organisationskontekst. Dets kontinuerligt lærende hukommelsessystem betyder, at det også forbedres for hver tur.

I dette indlæg vil vi gennemgå, hvorfor vi havde brug for en skræddersyet AI-dataagent, hvad der gør dens kodeberigede datakontekst og selvlæringsfunktion så nyttig, og hvilke erfaringer vi har lært undervejs.

OpenAIs dataplatform betjener mere end 3,500 interne brugere, der arbejder indenfor ingeniørvidenskab, produktion og forskning, og spænder over 600 petabyte data på tværs af 70.000 datasæt. I den størrelse kan en af de mest tidskrævende dele af at lave en analyse være at finde den rette tabel.

Som en intern bruger udtrykte det:

[[indryk]]“Vi har mange tabeller, der er ret ens, og jeg bruger masser af tid på at finde ud af, hvordan de er forskellige, og hvilke jeg skal bruge. Nogle inkluderer brugere, der er logget ud, og andre gør det ikke. "Nogle har overlappende felter. Det er svært at sige, hvad der er hvad.”

Selv når de korrekte tabeller er valgt, kan det være svært at producere korrekte resultater. Analytikere skal ræsonnere over tabeldata og tabelrelationer for at sikre, at transformationer og filtre anvendes korrekt. Almindelige fejltilstande – mange-til-mange-joins, filter-pushdown-fejl og ikke-håndterede null-værdier – kan ubemærket gøre resultater ugyldige. På OpenAI’s skala bør analytikere ikke bruge tid på at fejlfinde SQL-semantik eller forespørgselsydeevne. Deres fokus bør være rettet mod at definere målepunkter, validere antagelser og træffe datadrevne beslutninger.

Lad os gennemgå, hvad vores agent er, hvordan den udvælger kontekst, og hvordan den løbende forbedrer sig selv.

Vores agent er drevet af GPT‑5.2 og er designet til at ræsonnere over OpenAI’s dataplatform. Den er tilgængelig, der hvor medarbejdere allerede arbejder, f.eks. som en Slack-agent, via en webgrænseflade, inde i IDE'er, i Codex CLI via MCP⁠(åbner i et nyt vindue) og direkte i OpenAI's interne ChatGPT‑app gennem en MCP-connector⁠(åbner i et nyt vindue).

Brugere kan stille komplekse, åbne spørgsmål, der typisk ville kræve flere runder af manuel udforskning. Tag dette eksempel på en prompt, der bruger et testdatasæt: “For NYC-taxiture, hvilke afhentning-til-afleveringer ZIP-par er de mest upålidelige, med den største forskel mellem typiske og værst tænkelige turetider, og hvornår opstår den variabilitet?”

Agenten håndterer analysen fra start til slut, lige fra at forstå spørgsmålet til at udforske dataene, køre forespørgsler og sammenfatte resultater.

En af agentens superkræfter er, hvordan den løser problemer gennem ræsonnering. I stedet for at følge et fast manuskript vurderer agenten sine egne fremskridt. Hvis et mellemresultat ser forkert ud (f.eks. hvis det har nul rækker på grund af en forkert join eller et forkert filter), undersøger agenten, hvad der gik galt, justerer sin tilgang og prøver igen. Gennem hele denne proces bevarer agenten den fulde kontekst og fører læringen videre mellem trinene. Denne lukkede, selvlærende proces flytter iterationen fra brugeren til selve agenten, hvilket muliggør hurtigere resultater og konsekvent højere kvalitet af analyser end manuelle arbejdsgange.

Agenten dækker hele analysearbejdsgangen fra at finde data, køre SQL og udgive notebooks og rapporter. Den forstår intern virksomhedsviden, kan søge på nettet efter ekstern information og forbedres over tid gennem indlært brug og hukommelse.

Svar af høj kvalitet afhænger af en fyldig og præcis kontekst. Uden kontekst kan selv stærke modeller give forkerte resultater, såsom at fejlvurdere brugerantal betydeligt eller misfortolke intern terminologi.

For at undgå disse fejltilstande er agenten bygget op omkring flere lag af kontekst, der forankrer den i OpenAI’s data og institutionelle viden.

• Grundlag for metadata: Agenten er afhængig af skemadata (kolonnenavne og datatyper) til at informere SQL-skrivning og bruger tabelafstamning (f.eks. upstream- og downstream-tabelrelationer) til at give kontekst om, hvordan forskellige tabeller relaterer til hinanden.
• Forespørgselsinferens: Indlæsning af historiske forespørgsler hjælper agenten med at forstå, hvordan den kan skrive sine egne forespørgsler, og hvilke tabeller der typisk sammenføjes.

• Udvalgte beskrivelser af tabeller og kolonner leveret af domæneeksperter, der forstår intention, semantik, forretningsmæssig betydning og kendte forbehold, som er svære at udlede af skemaer eller tidligere forespørgsler.

Metadata alene er ikke nok. For virkelig at kunne skelne tabeller fra hinanden, er det vigtigt at forstå, hvordan de blev oprettet, og hvor de stammer fra.

• Ved at udlede en definition af en tabel på kodeniveau opbygger agenten en dybere forståelse af, hvad dataene rent faktisk indeholder. 
  • Der opnås ekstra information ved at se på variationer af, hvad der gemmes i tabellen, og hvordan det udledes fra en analysebegivenhed. For eksempel kan det give kontekst om værdiers unikke karakter, hvor ofte tabeldataene opdateres, dataenes omfang (f.eks. hvis tabellen ekskluderer bestemte felter, har den dette detaljeringsniveau) osv.
• Dette giver en forbedret brugskontekst ved at vise, hvordan tabellen anvendes ud over SQL i Spark, Python og andre datasystemer.
• Det betyder, at agenten kan skelne mellem tabeller, der ser ens ud, men adskiller sig på væsentlige måder. For eksempel kan den afgøre, om en tabel kun indeholder førsteparts ChatGPT‑trafik. Denne kontekst opdateres også automatisk, så den forbliver opdateret uden manuel vedligeholdelse.

• Agenten kan få adgang til Slack, Google Docs og Notion, som indfanger kritisk virksomhedskontekst såsom lanceringer, pålidelighedshændelser, interne kodenavne og værktøjer samt de kanoniske definitioner og beregningslogikken for nøglemålepunkter.
• Disse dokumenter optages, indlejres og gemmes sammen med metadata og tilladelser. En hentningstjeneste håndterer adgangskontrol og caching under kørsel, hvilket gør det muligt for agenten at hente disse oplysninger effektivt og sikkert.

• Når agenten får rettelser eller opdager variationer vedrørende visse dataspørgsmål, kan den gemme disse erfaringer til næste gang, så den konstant kan forbedre sig sammen med sine brugere. 
  • Derfor begynder fremtidige svar fra et mere præcist udgangspunkt frem for gentagne gange at støde på de samme problemer.
  • Målet med hukommelse er at bevare og genbruge ikke-åbenlyse rettelser, filtre og begrænsninger, der er kritiske for datakorrekthed, men som er vanskelige at udlede alene fra de andre lag. 
  • For eksempel vidste agenten i ét tilfælde ikke, hvordan man filtrerede efter et bestemt analyseeksperiment (den var afhængig af matchning mod en specifik streng defineret i en eksperimentgate). Hukommelse var afgørende her for at sikre, at agenten kunne filtrere korrekt, i stedet for at forsøge at lave uklar strengmatchning.
• Når du giver agenten en rettelse, eller når den finder en læring fra din samtale, vil den bede dig om at gemme den viden til næste gang. 
  • En sådan hukommelse kan også oprettes og redigeres manuelt af brugere.
  • Hukommelser er defineret på globalt og personligt niveau, og agentens værktøjer gør det nemt at redigere dem.

• Når der ikke findes nogen tidligere kontekst for en tabel, eller når eksisterende oplysninger er forældede, kan agenten sende live-forespørgsler til datalageret for at inspicere og forespørge tabellen direkte. Dette gør det muligt at validere skemaer, forstå dataene i realtid og reagere i overensstemmelse hermed.
• Agenten kan også kommunikere med andre dataplatformsystemer (metadatatjeneste, Airflow, Spark), hvis det er nødvendigt, for at få en bredere datakontekst, der findes uden for lageret.

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⁠(åbner i et nyt vindue) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(åbner i et nyt vindue) (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⁠(åbner i et nyt vindue) 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.