Unutar OpenAI-jevog internog agenta za podatke

Podaci pokreću način na koji sistemi uče, proizvodi se razvijaju i kako kompanije donose odluke. Ali brzo, tačno i u pravom kontekstu dobiti odgovore često je teže nego što bi trebalo biti. Kako bismo ovo olakšali dok OpenAI raste, izgradili smo našeg vlastitog prilagođenog internog AI agenta za podatke koji istražuje i rezonuje nad našom platformom.

Naš agent je prilagođeni alat samo za internu upotrebu (nije vanjska ponuda), izgrađen posebno oko podataka, dozvola i tokova rada OpenAI-a. Pokazujemo kako smo ga izgradili i koristimo ga da bismo istakli primjere stvarnih i značajnih načina na koje AI može podržati svakodnevni rad u našim timovima. Alati OpenAI koje smo koristili za izgradnju i pokretanje (Codex, naš glavni model GPT‑5, Evals API⁠(otvara se u novom prozoru) i Embeddings API⁠(otvara se u novom prozoru)) su isti alati koje nudimo programerima širom svijeta.

Naš data agent omogućava zaposlenicima da od pitanja dođu do uvida za nekoliko minuta, a ne za nekoliko dana. Ovo snižava prag za prikupljanje podataka i detaljnu analizu u svim funkcijama, a ne samo od strane našeg tima za podatke. Danas se timovi u OpenAI-ju iz oblasti inženjeringa, nauke o podacima, strategije izlaska na tržište, finansija i istraživanja oslanjaju na agenta da odgovori na pitanja o podacima s velikim uticajem. Na primjer, može pomoći odgovoriti na pitanje kako procijeniti lansiranja i razumjeti zdravlje poslovanja, sve kroz intuitivan format prirodnog jezika. Agent kombinuje znanje na nivou tabele koje pokreće Codex s kontekstom proizvoda i organizacije. Njegov sistem memorije koji kontinuirano uči znači da se također poboljšava sa svakim okretom.

U ovom postu ćemo razložiti zašto nam je bio potreban prilagođeni UI agent za podatke, šta njegov kodom obogaćen kontekst podataka i samoučenje čini toliko korisnim, te lekcije koje smo naučili putem.

OpenAI-jeva platforma za podatke opslužuje više od 3.500 internih korisnika koji rade u oblastima inženjeringa, proizvoda i istraživanja, obuhvatajući preko 600 petabajta podataka kroz 70.000 skupova podataka. Pri toj veličini, samo pronalaženje prave tabele može biti jedan od najzahtjevnijih i vremenski najintenzivnijih dijelova analize.

Kako je jedan interni korisnik rekao:

„Imamo mnogo tabela koje su prilično slične, i provodim mnogo vremena pokušavajući shvatiti po čemu se razlikuju i koju da koristim. Neki uključuju odjavljene korisnike, a neki ne. Neka polja se preklapaju; teško je razaznati šta je šta.

Čak i kada su odabrane ispravne tabele, postizanje tačnih rezultata može biti izazovno. Analitičari moraju razmišljati o podacima u tabelama i njihovim međusobnim odnosima kako bi osigurali da se transformacije i filteri ispravno primjenjuju. Uobičajeni načini otkaza—spajanja mnogi-na-mnoge, greške potiskivanja filtera i neobrađene null vrijednosti—mogu tiho učiniti rezultate nevažećim. Na nivou obima OpenAI-a, analitičari ne bi trebali trošiti vrijeme na otklanjanje grešaka u SQL semantici ili performansama upita: njihov fokus treba biti na definisanju metrika, validaciji pretpostavki i donošenju odluka temeljenih na podacima.

Hajde da prođemo kroz to šta je naš agent, kako upravlja kontekstom i kako se stalno samousavršava.

Naš agent pokreće GPT‑5.2 i dizajniran je da analizira OpenAI-jevu platformu podataka. Dostupan je gdje god zaposlenici već rade: kao Slack agent, putem web sučelja, unutar IDE-ova, u Codex CLI putem MCP-a⁠(otvara se u novom prozoru), i direktno u OpenAI-jevoj internoj aplikaciji ChatGPT putem MCP konektora⁠(otvara se u novom prozoru).

Korisnici mogu postavljati složena, otvorena pitanja koja bi obično zahtijevala više krugova ručnog istraživanja. Uzmite ovaj primjer upita, koji koristi testni skup podataka: „Za NYC taxi vožnje, koji parovi ZIP kodova od preuzimanja do odredišta su najnepouzdaniji, s najvećim razmakom između tipičnih i najgorih mogućih vremena putovanja, i kada se ta varijabilnost javlja?”

Agent obavlja analizu od početka do kraja, od razumijevanja pitanja do istraživanja podataka, pokretanja upita i sintetiziranja nalaza.

Jedna od supermoći agenta je način na koji razmišlja kroz probleme. Umjesto da slijedi fiksni skript, agent procjenjuje svoj napredak. Ako međurezultat izgleda pogrešno (npr., ako ima nula redova zbog netačnog spajanja ili filtriranja), agent istražuje šta je pošlo po zlu, prilagođava svoj pristup i pokušava ponovo. Kroz cijeli proces, zadržava puni kontekst i prenosi naučene lekcije između koraka. Ovaj zatvoreni krug, samoučeći proces prebacuje iteraciju s korisnika na samog agenta, omogućavajući brže rezultate i dosljedno kvalitetnije analize nego ručni tokovi rada.

Agent pokriva cijeli analitički radni tok: otkrivanje podataka, pokretanje SQL-a i objavljivanje bilježnica i izvještaja. Razumije interno znanje kompanije, može pretraživati web za vanjske informacije, i s vremenom se poboljšava kroz naučenu upotrebu i pamćenje.

Visokokvalitetni odgovori zavise od bogatog, tačnog konteksta. Bez konteksta, čak i snažni modeli mogu proizvesti pogrešne rezultate, kao što su drastično pogrešno procjenjivanje broja korisnika ili pogrešno tumačenje unutrašnje terminologije.

Da bi se izbjegli ovi načini otkaza, agent je izgrađen oko više slojeva konteksta koji ga utemeljuju u podacima i institucionalnom znanju OpenAI-ja.

• Utemeljenje metapodataka: Agent se oslanja na metapodatke šeme (nazive kolona i tipove podataka) kako bi informisao pisanje SQL-a i koristi porijeklo tabela (npr. uzvodne i nizvodne odnose tabela) da pruži kontekst o tome kako su različite tabele povezane.
• Zaključivanje upita: Unošenje historijskih upita pomaže agentu da razumije kako pisati vlastite upite i koje se tabele obično spajaju.

• Kurirani opisi tabela i kolona koje pružaju stručnjaci iz domena, bilježeći namjeru, semantiku, poslovno značenje i poznate napomene koje se ne mogu lako zaključiti iz šema ili prethodnih upita.

Sami metapodaci nisu dovoljni. Da biste zaista razlikovali tabele, trebate razumjeti kako su nastale i odakle potiču.

• Izvođenjem definicije tabele na nivou koda, agent stiče dublje razumijevanje stvarnog sadržaja podataka. 
  • Nijanse o tome šta se pohranjuje u tabeli i kako se izvodi iz analitičkog događaja pružaju dodatne informacije. Na primjer, može pružiti kontekst o jedinstvenosti vrijednosti, koliko često se podaci u tabeli ažuriraju, opsegu podataka (npr. ako tabela isključuje određena polja, ima ovaj nivo detaljnosti), itd.
• Ovo pruža poboljšani kontekst upotrebe pokazujući kako se tabela koristi ne samo u SQL-u, već i u Sparku, Pythonu i drugim podatkovnim sistemima.
• To znači da agent može razlikovati između tabela koje izgledaju slično, ali se razlikuju na ključne načine. Na primjer, može reći da li tabela uključuje samo saobraćaj ChatGPT‑a iz prve ruke. Ovaj kontekst se automatski osvježava, tako da ostaje ažuriran bez potrebe za ručnim održavanjem.

• Agent može pristupiti Slacku, Google Docsu i Notionu, koji bilježe ključni kontekst kompanije kao što su lansiranja, incidenti pouzdanosti, interni kodni nazivi i alati, te kanonske definicije i logika izračunavanja za ključne metrike.
• Ovi dokumenti se unose, ugrađuju i pohranjuju sa metapodacima i dozvolama. Servis za preuzimanje upravlja kontrolom pristupa i keširanjem u izvršnom okruženju, omogućujući agentu da efikasno i sigurno povuče ove informacije.

• Kada agent primi ispravke ili otkrije nijanse u vezi s određenim pitanjima o podacima, može sačuvati ta saznanja za sljedeći put, što mu omogućava da se stalno poboljšava zajedno sa korisnicima. 
  • Kao rezultat, budući odgovori počinju sa preciznijom osnovom umjesto da se stalno suočavaju s istim problemima.
  • Cilj memorije je zadržati i ponovo koristiti nevidljive ispravke, filtere i ograničenja koja su ključna za tačnost podataka, ali ih je teško zaključiti samo iz drugih slojeva. 
  • Na primjer, u jednom slučaju, agent nije znao kako filtrirati za određeni analitički eksperiment (oslanjao se na podudaranje s određenim nizom definisanim u eksperimentalnom prolazu). Memorija je ovdje bila od presudne važnosti kako bi se osiguralo da može pravilno filtrirati, umjesto da nejasno pokušava upariti nizove.
• Kada agentu date ispravku ili kada iz vašeg razgovora nauči nešto novo, upit će vas da sačuvate tu memoriju za sljedeći put. 
  • Uspomene, takođe, mogu biti ručno kreirane i uređivane od strane korisnika.
  • Sjećanja su definirana na globalnom i osobnom nivou, a alati agenta omogućavaju jednostavno njihovo uređivanje.

• Kada ne postoji prethodni kontekst za tabelu ili kada su postojeće informacije zastarjele, agent može izdati upite uživo prema skladištu podataka kako bi direktno pregledao i upitao tabelu. Ovo mu omogućava da validira šeme, razumije podatke u stvarnom vremenu i odgovara u skladu s tim.
• Agent je, takođe, u mogućnosti komunicirati sa drugim sistemima Data Platforme (metadata service, Airflow, Spark) po potrebi kako bi dobio širi kontekst podataka koji postoji izvan skladišta.

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⁠(otvara se u novom prozoru) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(otvara se u novom prozoru) (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⁠(otvara se u novom prozoru) 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.