Een kijkje in OpenAI's interne data-agent

Data vormt de basis voor hoe systemen leren, producten evolueren en hoe bedrijven keuzes maken. Maar snel, correct en met de juiste context antwoorden krijgen, is vaak moeilijker dan het zou moeten zijn. Om dit makkelijker te maken terwijl OpenAI opschaalt, hebben we onze eigen op maat gemaakte interne AI-data-agent gebouwd die ons eigen platform verkent en erover redeneert.

Onze agent is een op maat gemaakte interne tool (geen extern aanbod), specifiek gebouwd rondom de data, rechten en workflows van OpenAI. We laten zien hoe we deze hebben gebouwd en gebruiken, om voorbeelden te geven van de echte, impactvolle manieren waarop AI het dagelijkse werk binnen onze teams kan ondersteunen. De OpenAI-tools die we gebruikten om hem te bouwen en te draaien (Codex, ons GPT‑5 vlaggenschipmodel, de Evals API⁠(opent in een nieuw venster) en de Embeddings API⁠(opent in een nieuw venster)) zijn dezelfde tools die we beschikbaar stellen aan ontwikkelaars overal ter wereld.

Met onze data-agent gaan medewerkers van vraag naar inzicht in minuten, niet dagen. Dit verlaagt de drempel voor het ophalen van data en genuanceerde analyses voor alle functies, niet alleen voor ons datateam. Tegenwoordig vertrouwen teams binnen Engineering, Data Science, Go-To-Market, Finance en Research bij OpenAI op de agent om impactvolle datavragen te beantwoorden. Hij kan bijvoorbeeld helpen bij het evalueren van lanceringen en het begrijpen van de gezondheid van het bedrijf, allemaal via het intuïtieve format van natuurlijke taal. De agent combineert kennis op tabelniveau, aangedreven door Codex, met product- en organisatiecontext. Dankzij het continu lerende geheugen wordt hij bovendien met elke interactie beter.

In deze post leggen we uit waarom we een op maat gemaakte AI-data-agent nodig hadden, wat zijn met code verrijkte data-context en zelflerend vermogen zo nuttig maakt, en welke lessen we onderweg hebben geleerd.

OpenAI's dataplatform bedient meer dan 3,5k interne gebruikers binnen Engineering, Product en Research, met meer dan 600 petabytes aan data verspreid over 70k datasets. Op die schaal kan alleen al het vinden van de juiste tabel een van de meest tijdrovende onderdelen van een analyse zijn.

Zoals een interne gebruiker het verwoordde:

[[indent]"We hebben veel tabellen die behoorlijk op elkaar lijken, en ik ben enorm veel tijd kwijt om uit te zoeken hoe ze verschillen en welke ik moet gebruiken. Sommige bevatten uitgelogde gebruikers, andere niet. Sommige hebben overlappende velden. Het is moeilijk te zeggen wat wat is."

Zelfs als de juiste tabellen zijn geselecteerd, kan het produceren van correcte resultaten een uitdaging zijn. Analisten moeten nadenken over tabeldata en relaties tussen tabellen om ervoor te zorgen dat transformaties en filters correct worden toegepast. Veelvoorkomende foutoorzaken (many-to-many joins, filter pushdown-fouten en niet-afgehandelde null-waarde) kunnen resultaten ongemerkt ongeldig maken. Op de schaal van OpenAI zouden analisten geen tijd moeten verliezen aan het debuggen van SQL-semantiek of query-prestaties: hun focus moet liggen op het definiëren van meetwaarden, het valideren van aannames en het nemen van datagedreven beslissingen.

Laten we bekijken wat onze agent precies is, hoe hij context samenstelt en hoe hij zichzelf blijft verbeteren.

Onze agent wordt aangedreven door GPT‑5.2 en is ontworpen om te redeneren over het dataplatform van OpenAI. Hij is beschikbaar waar medewerkers al werken: als een Slack-agent, via een webinterface, in IDE's, in de Codex CLI via MCP⁠(opent in een nieuw venster) en rechtstreeks in OpenAI's interne ChatGPT‑app via een MCP-connector⁠(opent in een nieuw venster).

Gebruikers kunnen complexe, open vragen stellen die normaal gesproken meerdere rondes van handmatige verkenning zouden vereisen. Neem deze voorbeeldprompt, die een testdataset gebruikt: "Voor NYC-taxiritten, welke ophaal-naar-afzet postcode-paren zijn het meest onbetrouwbaar, met het grootste gat tussen typische en worst-case reistijden, en wanneer treedt die variabiliteit op?"

De agent handelt de analyse van begin tot eind af, van het begrijpen van de vraag tot het verkennen van de data, het uitvoeren van query's en het synthetiseren van bevindingen.

Een van de superkrachten van de agent is hoe hij door problemen heen redeneert. In plaats van een vast script te volgen, evalueert de agent zijn eigen voortgang. Als een tussenresultaat er verkeerd uitziet (bijv. als het nul rijen heeft door een onjuiste join of filter), onderzoekt de agent wat er misging, past hij zijn aanpak aan en probeert hij het opnieuw. Gedurende dit proces behoudt hij de volledige context en neemt hij leerpunten mee naar volgende stappen. Dit gesloten, zelflerende proces verplaatst de iteratie van de gebruiker naar de agent zelf, wat zorgt voor snellere resultaten en analyses van consistent hogere kwaliteit dan bij handmatige workflows.

De agent dekt de volledige analytics-workflow: data ontdekken, SQL draaien en notebooks en rapporten publiceren. Hij begrijpt interne bedrijfskennis, kan op het web zoeken naar externe informatie en verbetert in de loop der tijd door geleerd gebruik en geheugen.

Hoogwaardige antwoorden zijn afhankelijk van rijke en nauwkeurige context. Zonder context kunnen zelfs sterke modellen verkeerde resultaten produceren, zoals het enorm verkeerd inschatten van gebruikersaantallen of het verkeerd interpreteren van interne terminologie.

Om deze fouten te voorkomen, is de agent gebouwd rond meerdere lagen context die hem verankeren in de data en institutionele kennis van OpenAI.

• Metadata-verankering: De agent vertrouwt op schema-metadata (kolomnamen en datatypes) voor het schrijven van SQL en gebruikt tabel-lineage (bijv. upstream en downstream tabelrelaties) om context te bieden over hoe verschillende tabellen zich tot elkaar verhouden.
• Query-inferentie: Het inladen van historische query's helpt de agent begrijpen hoe hij zijn eigen query's moet schrijven en welke tabellen doorgaans worden samengevoegd.

• Gecontroleerde beschrijvingen van tabellen en kolommen, aangeleverd door domeinexperts, die intentie, semantiek, zakelijke betekenis en bekende valkuilen vastleggen die niet eenvoudig af te leiden zijn uit schema's of eerdere query's.

Metadata alleen is niet genoeg. Om tabellen echt van elkaar te onderscheiden, moet je begrijpen hoe ze zijn gemaakt en waar ze vandaan komen.

• Door een definitie op codeniveau van een tabel af te leiden, bouwt de agent een dieper begrip op van wat de data daadwerkelijk bevat. 
  • Nuances over wat er in de tabel is opgeslagen en hoe dit is afgeleid van een analytics-event, leveren extra informatie op Het kan bijvoorbeeld context geven over het unieke karakter van waarden, hoe vaak de tabeldata wordt bijgewerkt, de scope van de data (bijv. als de tabel bepaalde velden uitsluit, of dit granulariteitsniveau heeft), enz.
• Dit biedt verbeterde gebruikscontext door te laten zien hoe de tabel buiten SQL wordt gebruikt in Spark, Python en andere datasystemen.
• Dit betekent dat de agent onderscheid kan maken tussen tabellen die op elkaar lijken, maar op cruciale punten verschillen. Hij kan bijvoorbeeld zien of een tabel alleen first-party ChatGPT‑verkeer bevat. Deze context wordt ook automatisch vernieuwd, zodat deze up-to-date blijft zonder handmatig onderhoud.

• De agent heeft toegang tot Slack, Google Docs en Notion, waarin kritieke bedrijfscontext wordt vastgelegd, zoals lanceringen, betrouwbaarheidsincidenten, interne codenamen en tools, en de canonieke definities en berekeningslogica voor belangrijke statistieken.
• Deze documenten worden ingelezen, omgezet in embeddings en opgeslagen met metadata en rechten. Een retrieval-service regelt toegangsbeheer en caching tijdens runtime, waardoor de agent deze informatie efficiënt en veilig kan ophalen.

• Wanneer de agent correcties krijgt of nuances ontdekt over bepaalde datavragen, kan hij deze leerpunten opslaan voor de volgende keer, waardoor hij constant verbetert samen met zijn gebruikers. 
  • Hierdoor beginnen toekomstige antwoorden vanuit een nauwkeurigere basis in plaats van steeds tegen dezelfde problemen aan te lopen.
  • Het doel van het geheugen is het onthouden en hergebruiken van niet-voor de hand liggende correcties, filters en beperkingen die cruciaal zijn voor de correctheid van data, maar moeilijk af te leiden zijn uit alleen de andere lagen. 
  • Bijvoorbeeld: in één geval wist de agent niet hoe hij moest filteren voor een specifiek analytics-experiment (hij vertrouwde op het matchen van een specifieke string gedefinieerd in een experiment-gate). Geheugen was hier cruciaal om ervoor te zorgen dat hij correct kon filteren, in plaats van een onnauwkeurige string-match te proberen.
• Wanneer je de agent een correctie geeft of wanneer hij een leerpunt uit je gesprek haalt, zal hij je vragen om die herinnering op te slaan voor de volgende keer. 
  • Herinneringen kunnen ook handmatig door gebruikers worden aangemaakt en bewerkt.
  • Herinneringen hebben een bereik op globaal of persoonlijk niveau, en de tools van de agent maken het makkelijk om ze te bewerken.

• Wanneer er geen eerdere context bestaat voor een tabel of wanneer bestaande informatie verouderd is, kan de agent live query's uitvoeren op het datawarehouse om de tabel direct te inspecteren en te bevragen. Hierdoor kan hij schema's valideren, de data in realtime begrijpen en dienovereenkomstig reageren.
• De agent kan indien nodig ook communiceren met andere Data Platform-systemen (metadata-service, Airflow, Spark) om bredere datacontext te verkrijgen die buiten het warehouse bestaat.

De Evals zijn gebouwd op gecureerde sets van vraag-antwoordparen. Elke vraag richt zich op een belangrijke statistiek of analytisch patroon dat we absoluut goed willen hebben, gekoppeld aan een handgeschreven "gouden" SQL-query die het verwachte resultaat oplevert. Voor elke evaluatie sturen we de vraag in natuurlijke taal naar het query-generatie-endpoint, voeren we de gegenereerde SQL uit en vergelijken we de output met het resultaat van de verwachte SQL.

Evaluatie is niet afhankelijk van naïeve string-matching. Gegenereerde SQL kan syntactisch verschillen en toch correct zijn, en resultatensets kunnen extra kolommen bevatten die het antwoord niet wezenlijk beïnvloeden. Om hiermee rekening te houden, vergelijken we zowel de SQL als de resulterende data, en voeden we deze signalen aan OpenAI's Evals-grader. De grader genereert een eindscore met een toelichting, waarbij rekening wordt gehouden met zowel correctheid als acceptabele variatie.

Deze evals zijn als unit tests die continu draaien tijdens de ontwikkeling om regressies te identificeren als kanaries in productie. Hierdoor kunnen we problemen vroegtijdig opsporen en vol vertrouwen itereren terwijl de capaciteiten van de agent uitbreiden.

Onze agent sluit direct aan op het bestaande beveiligings- en toegangscontrolemodel van OpenAI. Hij fungeert puur als een interfacelaag en erft en handhaaft dezelfde rechten en vangrails die gelden voor de data van OpenAI. 

Alle toegang van de agent is strikt pass-through, wat betekent dat gebruikers alleen tabellen kunnen bevragen waartoe ze al toegang hebben. Wanneer toegang ontbreekt, signaleert hij dit of valt hij terug op alternatieve datasets die de gebruiker wel mag gebruiken.

Tot slot is hij gebouwd voor transparantie. Zoals elk systeem kan hij fouten maken. Hij toont zijn redeneerproces door aannames en uitvoeringsstappen samen te vatten bij elk antwoord. Wanneer query's worden uitgevoerd, linkt hij direct naar de onderliggende resultaten, zodat gebruikers de ruwe data kunnen inspecteren en elke stap van de analyse kunnen verifiëren.

Het vanaf de grond opbouwen van onze agent bracht praktische lessen aan het licht over hoe agents zich gedragen, waar ze moeite mee hebben en wat hen daadwerkelijk betrouwbaar maakt op schaal.

In het begin stelden we onze volledige toolset open voor de agent en liepen we al snel tegen problemen aan met overlappende functionaliteit. Hoewel deze redundantie nuttig kan zijn voor specifieke maatwerkgevallen en duidelijker is voor een mens bij handmatig gebruik, is het verwarrend voor agents. Om dubbelzinnigheid te verminderen en de betrouwbaarheid te verbeteren, hebben we bepaalde tool-aanroepen beperkt en samengevoegd.

We ontdekten ook dat zeer voorschrijvende prompts de resultaten verslechterden. Hoewel veel vragen een algemene analytische vorm delen, variëren de details genoeg dat rigide instructies de agent vaak het verkeerde pad op stuurden. Door over te stappen op sturing op hoger niveau en te vertrouwen op de redenering van GPT‑5 om het juiste uitvoeringspad te kiezen, werd de agent robuuster en produceerde hij betere resultaten.

Schema's en query-geschiedenis beschrijven de vorm en het gebruik van een tabel, maar de ware betekenis leeft in de code die deze produceert. Pijplijn-logica legt aannames, versheidsgaranties en zakelijke intenties vast die nooit naar voren komen in SQL of metadata. Door de codebase te crawlen met Codex, begrijpt onze agent hoe datasets daadwerkelijk zijn opgebouwd en kan hij beter redeneren over wat elke tabel eigenlijk bevat. Hij kan vragen als "wat zit hierin" en "wanneer kan ik dit gebruiken" veel nauwkeuriger beantwoorden dan op basis van alleen warehouse-signalen. 

We werken er voortdurend aan om onze agent te verbeteren door zijn vermogen om met dubbelzinnige vragen om te gaan te vergroten, zijn betrouwbaarheid en nauwkeurigheid te verbeteren met sterkere validaties, en hem dieper te integreren in workflows. We geloven dat hij op natuurlijke wijze moet samenvloeien met hoe mensen al werken, in plaats van te functioneren als een losstaande tool.

Terwijl onze tooling zal blijven profiteren van onderliggende verbeteringen in het redeneren, valideren en zelfcorrigeren van de agent, blijft de missie van ons team hetzelfde: naadloos snelle, betrouwbare data-analyse leveren binnen het data-ecosysteem van OpenAI.