OpenAI:n sisäinen data-agentti

Data ohjaa sitä, miten järjestelmät oppivat, tuotteet kehittyvät ja miten yritykset tekevät päätöksiä. Mutta vastausten saaminen nopeasti, oikein ja oikeassa asiayhteydessä on usein vaikeampaa kuin pitäisi. Jotta OpenAI:n skaalautuminen olisi helpompaa, rakensimme oman räätälöidyn sisäisen tekoälydata-agentin, joka tutkii ja tekee johtopäätöksiä omalla alustallamme.

Agenttimme on räätälöity, sisäiseen käyttöön tarkoitettu työkalu (ei ulkoinen tarjonta), joka on suunniteltu erityisesti OpenAI:n datan, käyttöoikeuksien ja työnkulkujen ympärille. Näytämme, kuinka rakensimme sen ja käytämme sitä, jotta voimme tuoda esiin esimerkkejä todellisista, merkittävistä tavoista, joilla tekoäly voi tukea päivittäistä työtä tiimeissämme. OpenAI-työkalut, joita käytimme sen rakentamiseen ja ajamiseen (Codex, GPT‑5‑lippulaivamallimme, Evals API⁠(avautuu uudessa ikkunassa) ja Embeddings API⁠(avautuu uudessa ikkunassa)), ovat samat työkalut, jotka tarjoamme kehittäjille kaikkialla.

Data-agenttimme avulla työntekijät voivat siirtyä kysymyksestä oivallukseen muutamassa minuutissa, ei päivissä. Tämä madaltaa kynnystä tietojen hakemiseen ja yksityiskohtaiseen analyysiin kaikissa toiminnoissa, ei vain datatiimissämme. Tänään OpenAI:n suunnittelu-, datatiede-, markkinoille saattaminen-, rahoitus- ja tutkimustiimit tukeutuvat agenttiin saadakseen vastauksia merkittäviin datakysymyksiin. Se voi esimerkiksi auttaa vastaamaan kysymykseen, miten arvioida julkaisuja ja ymmärtää liiketoiminnan tilaa, kaikki luonnollisen kielen intuitiivisessa muodossa. Agentti yhdistää Codexin tukeman taulukkotason tiedon tuote- ja organisaatiokontekstiin. Jatkuvasti oppiva muistijärjestelmä tarkoittaa, että se paranee jokaisen käyttökerran myötä.

Tässä julkaisussa käsittelemme, miksi tarvitsimme räätälöidyn tekoälydata-agentin, mikä tekee sen koodilla rikastetusta datakontekstista ja itseoppimisesta niin hyödyllistä, ja mitä opimme matkan varrella.

OpenAI:n data-alusta palvelee yli 3 500 sisäistä käyttäjää , jotka työskentelevät suunnittelun, tuotekehityksen ja tutkimuksen parissa, kattaen yli 600 petatavua dataa 70 000 tietokokonaisuudessa. Tuon kokoluokan taulukon löytäminen voi olla yksi analyysin tekemisen aikaa vievimmistä osista.

Kuten eräs sisäinen käyttäjä totesi:

"Meillä on paljon taulukoita, jotka ovat melko samankaltaisia, ja käytän paljon aikaa selvittääkseni, miten ne eroavat toisistaan ja mitä niistä pitäisi käyttää. Joihinkin sisältyy uloskirjautuneita käyttäjiä, joihinkin ei. Joissakin on päällekkäisiä kenttiä; on vaikea sanoa, mitä mikäkin on."

Vaikka oikeat taulukot on valittu, oikeiden tulosten tuottaminen voi silti olla haastavaa. Analyytikkojen on ymmärrettävä taulukkodatan ja taulukoiden väliset suhteet varmistaakseen, että muunnoksia ja suodattimia sovelletaan oikein. Yleiset vikatilat—monenväliset liitokset, suodattimen työntövirheet ja käsittelemättömät nolla-arvot—voivat huomaamatta mitätöidä tulokset. OpenAI:n mittakaavassa analyytikoiden ei pitäisi joutua käyttämään aikaa SQL-semanttiikan tai kyselyjen suorituskyvyn virheenkorjaukseen; heidän tulisi keskittyä metriikan määrittelyyn, oletusten validointiin ja tietoon perustuvien päätösten tekemiseen.

Käydään läpi, mitä agenttimme on, miten se kuratoi kontekstia ja miten se parantaa itseään jatkuvasti.

Agenttimme toimii GPT‑5.2:lla ja on suunniteltu tekemään päättelyä OpenAI:n data-alustalla. Se on saatavilla siellä, missä työntekijät jo työskentelevät: Slack-agenttina, verkkokäyttöliittymän kautta, IDE-ohjelmissa, Codex CLI:ssä MCP:n kautta⁠(avautuu uudessa ikkunassa) ja suoraan OpenAI:n sisäisessä ChatGPT‑sovelluksessa MCP-liittimen kautta⁠(avautuu uudessa ikkunassa).

Käyttäjät voivat esittää monimutkaisia, avoimia kysymyksiä, jotka yleensä vaatisivat useita manuaalisia tutkimuskierroksia. Esimerkiksi tämä kehote, joka käyttää testiaineistoa: "Mitkä New Yorkin taksien nouto- ja jättöpaikan ZIP-parit ovat epäluotettavimpia, eli joissa tyypillisten ja pahimman tapauksen matka-aikojen välinen ero on suurin, ja milloin tuo vaihtelu tapahtuu?"

Agentti hoitaa analyysin alusta loppuun, kysymyksen ymmärtämisestä datan tutkimiseen, kyselyiden suorittamiseen ja tulosten yhdistämiseen.

Yksi agentin supervoimista on sen kyky ratkaista ongelmia päättelyn avulla. Kiinteän käsikirjoituksen noudattamisen sijaan agentti arvioi omaa edistymistään. Jos välitulos vaikuttaa virheelliseltä (esim. jos siinä on nolla riviä virheellisen liitoksen tai suodattimen vuoksi), agentti tutkii, mikä meni vikaan, mukauttaa lähestymistapaansa ja yrittää uudelleen. Koko prosessin ajan se säilyttää täyden kontekstin ja vie oppimansa mukanaan vaiheesta toiseen. Tämä suljettu, itseoppiva prosessi siirtää iteroinnin käyttäjältä agentille, mikä mahdollistaa nopeammat tulokset ja johdonmukaisesti laadukkaammat analyysit manuaalisiin työnkulkuihin verrattuna.

Agentti kattaa koko analytiikan työnkulun: datan löytämisen, SQL:n suorittamisen sekä muistikirjojen ja raporttien julkaiseminen. Se ymmärtää yrityksen sisäistä tietoa, voi hakea ulkoista tietoa verkosta ja paranee ajan myötä opitun käytön ja muistin avulla.

Korkealaatuiset vastaukset riippuvat runsaasta ja tarkasta kontekstista. Ilman kontekstia vahvatkin mallit voivat tuottaa vääriä tuloksia, kuten arvioida käyttäjämääriä huomattavasti väärin tai tulkita sisäistä terminologiaa väärin.

Näiden vikatilanteiden välttämiseksi agentti on rakennettu useiden kontekstikerrosten varaan, jotka yhdistävät sen OpenAI:n dataan ja institutionaaliseen tietämykseen.

• Metadatan ankkurointi: Agentti hyödyntää skeeman metatietoja (kuten sarakkeiden nimiä ja tietotyyppejä) SQL-kirjoittamisessa ja käyttää taulukkojen perimätietoa (esim. taulukoiden aiemmat ja myöhemmät suhteet) antaakseen kontekstia siitä, miten eri taulukot liittyvät toisiinsa.
• Kyselyn päättely: Historiallisten kyselyiden käsittely auttaa agenttia ymmärtämään, miten se voi laatia omia kyselyitään ja mitkä taulukot yleensä yhdistetään toisiinsa.

• Kuratoidut kuvaukset taulukoista ja sarakkeista, jotka alan asiantuntijat ovat laatineet. Ne kuvaavat tarkoitusta, semantiikkaa, liiketoiminnallista merkitystä ja tunnettuja varoituksia, joita ei ole helppo päätellä skeemasta tai aiemmista kyselyistä.

Pelkkä metatieto ei riitä. Jotta voit todella erottaa taulukot toisistaan, sinun täytyy ymmärtää, miten ne on luotu ja mistä ne ovat peräisin.

• Taulukon kooditason määritelmän avulla agentti kehittää syvemmän ymmärryksen siitä, mitä data todella sisältää. 
  • Vivahteet siitä, mitä taulukkoon tallennetaan ja miten se johdetaan analytiikkatapahtumasta, antavat lisätietoa. Se voi esimerkiksi antaa tietoa arvojen ainutlaatuisuudesta, siitä, kuinka usein taulukon tietoja päivitetään, tietojen laajuudesta (esim. jos taulukko ei sisällä tiettyjä kenttiä, sillä on tämä tarkkuustaso) jne.
• Tämä tarjoaa parannetun käyttökontekstin osoittamalla, miten taulukkoa hyödynnetään SQL:n lisäksi Sparkissa, Pythonissa ja muissa tietojärjestelmissä.
• Tämä tarkoittaa, että agentti voi erottaa taulukot, jotka näyttävät samanlaisilta mutta eroavat toisistaan olennaisilta osin. Se voi esimerkiksi selvittää, sisältääkö taulukko vain ensimmäisen osapuolen ChatGPT‑liikennettä. Tämä konteksti päivittyy myös automaattisesti, joten se pysyy ajan tasalla ilman manuaalista ylläpitoa.

• Agentti voi käyttää Slackia, Google Docsia ja Notionia, jotka tallentavat kriittistä yrityskontekstia, kuten julkaisuja, luotettavuushäiriöitä, sisäisiä koodinimiä ja työkaluja sekä keskeisten mittareiden kanonisia määritelmiä ja laskentalogiikkaa.
• Nämä asiakirjat syötetään, upotetaan ja tallennetaan metatietoineen ja käyttöoikeuksineen kanssa. Hakupalvelu hallitsee käyttöoikeuksia ja välimuistia ajonaikaisesti, jolloin agentti voi hakea nämä tiedot tehokkaasti ja turvallisesti.

• Kun agentti saa korjauksia tai havaitsee vivahteita tietyistä dataan liittyvistä kysymyksistä, se pystyy tallentamaan nämä opit seuraavaa kertaa varten, minkä ansiosta se voi kehittyä jatkuvasti käyttäjiensä kanssa. 
  • Näin ollen tulevat vastaukset alkavat tarkemmasta lähtökohdasta sen sijaan, että samoihin ongelmiin törmättäisiin toistuvasti.
  • Muistin tavoitteena on säilyttää ja hyödyntää uudelleen ei-ilmeisiä korjauksia, suodattimia ja rajoitteita, jotka ovat kriittisiä tietojen oikeellisuuden kannalta, mutta joita on vaikea päätellä pelkästään muista kerroksista. 
  • Esimerkiksi eräässä tapauksessa agentti ei tiennyt, miten suodattaa tiettyä analytiikkakoetta varten (se perustui tietyn merkkijonon vastaavuuteen, joka oli määritelty kokeen portissa). Muisti oli tässä ratkaisevan tärkeä, jotta se pystyi suodattamaan oikein sen sijaan, että olisi epämääräisesti yrittänyt tehdä merkkijonojen vastaavuushakua.
• Kun annat agentille korjauksen tai kun se löytää keskustelustasi opittavan asian, se antaa sinulle kehotteen tallentaa se muistiin seuraavaa kertaa varten. 
  • Käyttäjät voivat myös luoda ja muokata muisteja manuaalisesti.
  • Muistit on rajattu globaalille ja henkilökohtaiselle tasolle, ja agentin työkalut tekevät niiden muokkaamisesta helppoa.

• Kun taulukoille ei ole aiempaa kontekstia tai kun olemassa olevat tiedot ovat vanhentuneita, agentti voi tehdä reaaliaikaisia kyselyjä tietovarastoon tarkastellakseen ja kysyäkseen taulukkoa suoraan. Näin se voi validoida skeemoja, ymmärtää tietoja reaaliajassa ja reagoida sen mukaisesti.
• Agentti voi myös tarvittaessa keskustella muiden Data Platform -järjestelmien (metatietopalvelu, Airflow, Spark) kanssa saadakseen laajemman datakontekstin, joka on olemassa tietovaraston ulkopuolella.

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⁠(avautuu uudessa ikkunassa) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(avautuu uudessa ikkunassa) (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⁠(avautuu uudessa ikkunassa) 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.