Vnútri interného dátového agenta OpenAI

Údaje poháňajú proces učenia sa systémov, vývoja produktov a rozhodovania spoločností. Ale získať odpovede rýchlo, správne a v správnom kontexte je často ťažšie, než by malo byť. Aby to bolo jednoduchšie, keď OpenAI škáluje, vytvorili sme nášho vlastného prispôsobeného interného dátového agenta s umelou inteligenciou, ktorý skúma našu vlastnú platformu a uvažuje v rámci nej.

Náš agent je vlastný interný nástroj (nie externá ponuka), vytvorený špeciálne pre údaje, povolenia a pracovné postupy OpenAI. Ukazujeme, ako sme ho vytvorili a používame, aby sme pomohli poukázať na príklady skutočných a efektívnych spôsobov, akými môže umelá inteligencia podporovať každodennú prácu v našich tímoch. Nástroje OpenAI, ktoré sme použili na jeho vytvorenie a spustenie (Codex, náš vlajkový model GPT‑5, Evals API⁠(otvorí sa v novom okne) a Embeddings API⁠(otvorí sa v novom okne)), sú tie isté nástroje, ktoré sprístupňujeme vývojárom na celom svete.

Náš dátový agent umožňuje zamestnancom prejsť od otázky k poznatkom za pár minút, nie za dni. Toto znižuje latku pre získavanie údajov a detailnú analýzu naprieč všetkými funkciami, nielen naším dátovým tímom. V súčasnosti sa tímy v OpenAI z oblasti inžinierstva, dátovej vedy, marketingu, financií a výskumu spoliehajú na agenta, aby zodpovedal otázky týkajúce sa údajov s vysokým dopadom. Napríklad môže pomôcť odpovedať na otázky, ako hodnotiť uvedenie produktov na trh a pochopiť zdravie firmy, a to všetko prostredníctvom intuitívneho formátu prirodzeného jazyka. Agent kombinuje znalosti na úrovni tabuliek z Codexu s kontextom produktu a organizácie. Jeho neustále sa učiaci pamäťový systém znamená, že sa zlepšuje s každým krokom.

V tomto príspevku si rozoberieme, prečo sme potrebovali dátového agenta s umelou inteligenciou na mieru, čo robí jeho dátový kontext obohatený kódom a samoučenie tak užitočnými a aké ponaučenia sme sa počas tejto cesty naučili.

Dátová platforma OpenAI slúži viac ako 3 500 interným používateľom pracujúcim v oblasti inžinierstva, produktov a výskumu a pokrýva viac ako 600 petabajtov údajov v 70 000 súboroch údajov. Pri takejto veľkosti môže byť už len samotné nájdenie správnej tabuľky jednou z časovo najnáročnejších častí analýzy.

Ako to vyjadril jeden z interných používateľov:

[[odsadenie]]„Máme veľa tabuliek, ktoré sú si dosť podobné, a trávim veľa času snahou zistiť, v čom sa líšia a ktoré použiť. Niektoré zahŕňajú odhlásených používateľov, iné nie. Niektoré majú prekrývajúce sa polia. Je ťažké rozoznať, čo je čo."

Aj pri správnom výbere tabuliek môže byť dosiahnutie správnych výsledkov náročné. Analytici musia uvažovať o tabuľkových údajoch a vzťahoch medzi tabuľkami, aby sa zabezpečilo, že transformácie a filtre sa použijú správne. Bežné režimy zlyhania – spojenia typu „mnohé k mnohým“, chyby pri filtrovaní a nespracované hodnoty null – môžu ticho zneplatniť výsledky. V rozsahu OpenAI by analytici nemali musieť tráviť čas ladením sémantiky SQL alebo výkonu dopytov: mali by sa zamerať na definovanie metrík, overovanie predpokladov a prijímanie rozhodnutí na základe údajov.

Poďme si pozrieť, čo je náš agent, ako spravuje kontext a ako sa neustále zlepšuje.

Náš agent je poháňaný technológiou GPT‑5.2 a je navrhnutý tak, aby pracoval s dátovou platformou OpenAI. Je k dispozícii všade, kde už zamestnanci pracujú: ako Slack agent, prostredníctvom webového rozhrania, v rámci IDE, v Codex CLI cez MCP⁠(otvorí sa v novom okne) a priamo v internej aplikácii ChatGPT od OpenAI prostredníctvom MCP konektora⁠(otvorí sa v novom okne).

Používatelia môžu klásť zložité, otvorené otázky, ktoré by si zvyčajne vyžadovali viacero kôl manuálneho skúmania. Vezmime si tento príkaz, ktorý používa testovaciu sadu údajov:„Ktoré páry PSČ od miesta vyzdvihnutia po miesto vysadenia sú najnespoľahlivejšie, s najväčším rozdielom medzi typickým a najhorším prípadom času cestovania a kedy k tejto variabilite dochádza?“

Agent spracováva analýzu od začiatku do konca, od pochopenia otázky až po skúmanie údajov, spúšťanie dotazov a syntézu zistení.

Jednou zo superschopností agenta je spôsob, akým uvažuje pri riešení problémov. Namiesto dodržiavania pevne stanoveného scenára agent hodnotí svoj vlastný pokrok. Ak priebežný výsledok vyzerá nesprávne (napr. ak má nulové riadky kvôli nesprávnemu spojeniu alebo filtru), agent preskúma, čo sa pokazilo, upraví svoj prístup a skúsi to znova. Počas celého tohto procesu si zachováva plný kontext a prenáša poznatky medzi jednotlivými krokmi. Tento uzavretý proces samoučenia presúva iteráciu od používateľa k samotnému agentovi, čo umožňuje rýchlejšie výsledky a konzistentne kvalitnejšie analýzy ako pri manuálnych pracovných postupoch.

Agent pokrýva kompletný analytický pracovný postup: vyhľadávanie údajov, spúšťanie SQL a publikovanie poznámkových blokov a zostáv. Rozumie interným firemným znalostiam, dokáže vyhľadávať externé informácie na webe a časom sa zlepšuje prostredníctvom naučeného používania a pamäte.

Kvalitné odpovede závisia od bohatého a presného kontextu. Bez kontextu môžu aj silné modely priniesť nesprávne výsledky, ako napríklad výrazne nesprávny odhad počtu používateľov alebo nesprávnu interpretáciu internej terminológie.

Aby sa týmto poruchám predišlo, agent je postavený na viacerých vrstvách kontextu, ktoré ho zakotvujú v údajoch a inštitucionálnych znalostiach OpenAI.

• Základy metaúdajov: Agent sa pri písaní SQL spolieha na metaúdaje schémy (názvy stĺpcov a typy údajov) a používa pôvod tabuliek (napr. vzťahy medzi tabuľkami nadradeného a následného pôvodu) na poskytnutie kontextu o tom, ako rôzne tabuľky súvisia.
• Inferencia dopytov: Prijímanie historických dopytov pomáha agentovi pochopiť, ako písať vlastné dopyty a ktoré tabuľky sú zvyčajne spojené.

• Vytvorené opisy tabuliek a stĺpcov, ktoré poskytli odborníci na danú oblasť, zachytávajúce zámer, sémantiku, obchodný význam a známe upozornenia, ktoré sa nedajú ľahko odvodiť zo schém alebo predchádzajúcich dopytov.

Samotné metaúdaje nestačia. Aby ste skutočne rozlíšili tabuľky, musíte pochopiť, ako boli vytvorené a odkiaľ pochádzajú.

• Odvodením definície tabuľky na úrovni kódu si agent vytvorí hlbšie pochopenie toho, čo údaje skutočne obsahujú. 
  • Nuansy o tom, čo je uložené v tabuľke a ako je to odvodené z analytickej udalosti, poskytujú ďalšie informácie. Môže napríklad poskytnúť kontext o jedinečnosti hodnôt, o frekvencii aktualizácie údajov v tabuľke, o rozsahu údajov (napr. ak tabuľka neobsahuje určité polia, má túto úroveň podrobnosti) atď.
• Toto poskytuje rozšírený kontext používania tým, že ukazuje, ako sa tabuľka používa nad rámec SQL v Spark, Python a iných dátových systémoch.
• To znamená, že agent dokáže rozlíšiť medzi tabuľkami, ktoré vyzerajú podobne, ale sa líšia v kritických ohľadoch. Napríklad môže určiť, či tabuľka obsahuje iba prenos prvej strany pre ChatGPT. Tento kontext sa automaticky obnovuje, takže zostáva aktuálny bez potreby manuálnej údržby.

• Agent má prístup k službám Slack, Google Docs a Notion, ktoré zachytávajú kritický kontext spoločnosti, ako sú uvedenia na trh, incidenty spoľahlivosti, interné kódové názvy a nástroje a kanonické definície a výpočtovú logiku pre kľúčové metriky.
• Tieto dokumenty sa spracovávajú, vkladajú a ukladajú s metaúdajmi a povoleniami. Služba načítania zabezpečuje riadenie prístupu a ukladanie do vyrovnávacej pamäte v runtime, čo umožňuje agentovi efektívne a bezpečne tieto informácie získať.

• Keď agent dostane opravy alebo zistí nuansy týkajúce sa určitých otázok v oblasti údajov, dokáže si tieto poznatky uložiť nabudúce, čo mu umožňuje neustále sa zlepšovať spolu so svojimi používateľmi. 
  • Výsledkom je, že budúce odpovede vychádzajú z presnejšieho východiskového bodu, a nie z opakovaného stretávania sa s rovnakými problémami.
  • Cieľom pamäte je uchovať a opätovne použiť nezrejmé korekcie, filtre a obmedzenia, ktoré sú kritické pre správnosť údajov, ale ťažko sa odvodzujú len z ostatných vrstiev. 
  • Napríklad v jednom prípade agent nevedel, ako filtrovať konkrétny analytický experiment (spoliehal sa na porovnávanie s konkrétnym reťazcom definovaným v bráne experimentu). Pamäť tu bola mimoriadne dôležitá, aby sa zabezpečilo správne filtrovanie, namiesto nejasného pokusu o zhodu reťazcov.
• Keď agenta opravíte alebo keď z vašej konverzácie zistí nejaký poznatok, príkazom vás vyzve, aby ste si túto pamäť uložili do budúcna. 
  • Pamäte môžu používatelia manuálne vytvárať a upravovať.
  • Pamäte sú definované na globálnej aj osobnej úrovni a nástroje agenta umožňujú ich jednoduchú úpravu.

• Keď pre tabuľku neexistuje žiadny predchádzajúci kontext alebo keď sú existujúce informácie zastarané, agent môže vydávať živé dopyty do dátového skladu na priamu kontrolu a preverenie tabuľky. To mu umožňuje overovať schémy, porozumieť údajom v reálnom čase a podľa toho reagovať.
• Agent je tiež schopný podľa potreby komunikovať s inými systémami dátovej platformy (služba pre metaúdaje, Airflow, Spark), aby získal širší dátový kontext, ktorý existuje mimo dátového skladu.

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⁠(otvorí sa v novom okne) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(otvorí sa v novom okne) (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⁠(otvorí sa v novom okne) 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.