Az OpenAI belső adatügynökében

Az adatok határozzák meg, hogyan tanulnak a rendszerek, hogyan fejlődnek a termékek, és hogyan döntenek a vállalatok. De gyakran nehezebb gyorsan, helyesen és a megfelelő kontextusban választ kapni, mint amilyennek lennie kellene. Az OpenAI méretezésének megkönnyítése érdekében létrehoztunk egy saját, egyedi, házon belüli AI adatügynököt, amely feltérképezi és elemzi a platformunkat.

Az ügynökünk egy egyedi, kizárólag belső használatra szánt eszköz (nem külső ajánlat), amelyet kifejezetten az OpenAI adatai, jogosultságai és munkafolyamatai köré fejlesztettünk ki. Bemutatjuk, hogyan építettük fel és használjuk, hogy példákat mutassunk be arra, hogyan támogathatja az AI a csapataink mindennapi munkáját valós és jelentős módon. Az OpenAI eszközök, amelyeket a felépítéséhez és futtatásához használtunk (Codex, a GPT‑5 zászlóshajó modellünk, az Evals API⁠(új ablakban nyílik meg) és az Embeddings API⁠(új ablakban nyílik meg)) ugyanazok az eszközök, amelyeket világszerte elérhetővé teszünk a fejlesztők számára.

Adatügynökünk lehetővé teszi a munkavállalóknak, hogy percek alatt, ne napok alatt jussanak el a kérdéstől a felismerésig. Ez megkönnyíti az adatok lekérését és a részletes elemzéseket minden funkcióban, nem csak az adatkezelő csapatunk számára. Ma az OpenAI mérnöki, adattudományi, piaci bevezetés, pénzügyi és kutatási csapatai az ügynökre támaszkodnak, hogy megválaszolják a nagy hatású adatokat érintő kérdéseket. Például segíthet megválaszolni, hogyan lehet értékelni a bevezetések sikerességét és megérteni az üzleti egészséget, mindezt a természetes nyelv intuitív formátumán keresztül. Az ügynök a Codex által támogatott táblázatszintű tudást a termék- és szervezeti kontextussal ötvözi. A folyamatosan tanuló memóriarendszer azt jelenti, hogy minden egyes fordulattal javul.

Ebben a bejegyzésben bemutatjuk, miért volt szükségünk egy egyedi AI adatügynökre, mi teszi a kóddal gazdagított adatkontextusát és az önálló tanulását olyan hasznossá, és milyen tanulságokat vontunk le az út során.

Az OpenAI adatplatformja több mint 3,5 ezer mérnöki, termék- és kutatási területeken dolgozó belső felhasználót szolgál ki, és több mint 600 petabájt adatot kezelnek 70 ezer adatkészletben. Ekkora méretnél a megfelelő táblázat megtalálása önmagában is az elemzés egyik legidőigényesebb része lehet.

Ahogy egy belső felhasználó mondta:

„Sok hasonló táblázatunk van, és rengeteg időt töltök azzal, hogy kitaláljam, miben különböznek, és melyiket használjam. Egyesek tartalmazzák a kijelentkezett felhasználókat, mások nem. Néhány mező átfedésben van; nehéz megmondani, mi micsoda.

Még a megfelelő táblázatok kiválasztása esetén is nehéz lehet a helyes eredmények elérése. Az elemzőknek a táblázatadatokkal és a táblázatok közötti kapcsolatokról kell gondolkodniuk azért, hogy az átalakítások és a szűrők helyesen legyenek alkalmazva. Gyakori hibamódok—sok-sok kapcsolat, szűrő-leküldési hibák és kezeletlen nullák—észrevétlenül érvényteleníthetik az eredményeket. Az OpenAI méretén az elemzőknek nem kellene időt pazarolniuk az SQL szemantika vagy a lekérdezések teljesítményének hibakeresésére: a figyelmüknek a metrikák meghatározására, a feltételezések érvényesítésére és az adatalapú döntések meghozatalára kellene összpontosulnia.

Nézzük meg, mi az ügynökünk, hogyan alakítja a kontextust, és hogyan fejlődik folyamatosan.

Ügynökünket a GPT‑5.2 működteti, és úgy van kialakítva, hogy az OpenAI adatplatformján végezzen következtetéseket. Mindenhol elérhető, ahol a munkavállalók már dolgoznak: Slack ügynökként, webes felületen keresztül, IDE-kben, a Codex CLI-ben MCP-n keresztül⁠(új ablakban nyílik meg), valamint közvetlenül az OpenAI belső ChatGPT alkalmazásában egy MCP csatlakozón keresztül⁠(új ablakban nyílik meg).

A felhasználók olyan komplex, nyitott kérdéseket is feltehetnek, amelyek általában több körös manuális kutatást igényelnének. Például ez az utasítást, amely egy tesztadatkészletet használ: „Az NYC taxik esetében mely felvételi és lerakási irányítószám-párok a legmegbízhatatlanabbak, a tipikus és a legrosszabb eseti utazási idők közötti legnagyobb különbséggel, és mikor jelentkezik ez a változás?”

Az ügynök teljes körűen kezeli az elemzést, a kérdés megértésétől az adatok feltárásán át a lekérdezések futtatásáig és a megállapítások szintetizálásáig.

Az ügynök egyik szuperképessége, hogy a problémák megoldása során logikusan érvel. Ahelyett, hogy egy rögzített forgatókönyvet követne, az ügynök saját haladását értékeli. Ha egy köztes eredmény hibásnak tűnik (pl. ha egy helytelen összekapcsolás vagy szűrő miatt nulla sora van), az ügynök megvizsgálja, mi csúszott el, módosítja a megközelítését, és újra próbálkozik. A folyamat során végig megőrzi a teljes kontextust, és a tanulságokat lépésről lépésre továbbviszi. Ez a zárt hurkú, öntanuló folyamat az iterációt a felhasználótól az ügynökre helyezi át, lehetővé téve a gyorsabb eredményeket és a manuális munkafolyamatoknál következetesen jobb minőségű elemzéseket.

Az ügynök lefedi a teljes elemzési munkafolyamatot: az adatok felfedezését, az SQL futtatását, valamint a jegyzetfüzetek és jelentések publikálását. Érti a belső vállalati tudást, képes külső információk keresni az interneten, és idővel fejlődik a tanult használat és a memória révén.

A magas színvonalú válaszok gazdag és pontos kontextustól függenek. Kontextus nélkül még az erős modellek is hibás eredményeket adhatnak, például jelentősen mellébecsülhetik a felhasználók számát vagy félreértelmezhetik a belső terminológiát.

Ezen hibamódok elkerülése érdekében az ügynököt több kontextusréteg köré építettük, amelyek az OpenAI adataiban és intézményi tudásában gyökereznek.

• Metadata grounding: Az ügynök a séma metaadataira (oszlopnevek és adattípusok) támaszkodik az SQL írásához, és a táblák származási vonalát (pl. upstream és downstream táblakapcsolatok) használja annak érdekében, hogy kontextust adjon a különböző táblázatok közötti kapcsolatokhoz.
• Lekérdezés-következtetés: A korábbi lekérdezések betöltése segíti az ügynököt abban, hogy megértse, hogyan írja meg a saját lekérdezéseit, és mely táblázatokat szokás jellemzően összekapcsolni.

• Szakértők általi leírások a táblákról és oszlopokról, amelyek rögzítik a szándékot, a szemantikát, az üzleti jelentést és az ismert korlátozásokat, amelyeket nem könnyű kikövetkeztetni a sémákból vagy a korábbi lekérdezésekből.

A metaadatok önmagukban nem elegendőek. Ahhoz, hogy igazán meg tudd különböztetni a táblázatokat, meg kell értened, hogyan készültek, és honnan erednek.

• Egy táblázat kódszintű definíciójának levezetésével az ügynök mélyebb megértést szerez arról, hogy az adatok valójában mit tartalmaznak. 
  • Az, hogy milyen árnyalatok vannak abban, mi kerül tárolásra a táblázatban, és hogyan származik egy elemzési eseményből, további információt nyújt. Például kontextust adhat az értékek egyediségéről, arról, hogy milyen gyakran frissülnek a táblázat adatai, az adatok hatóköréről (pl. ha a táblázat kizár bizonyos mezőket, akkor ilyen részletezettségi szinttel rendelkezik), stb.
• Ez kibővített használati kontextust biztosít azáltal, hogy bemutatja, hogyan használják a táblát az SQL-en túl a Sparkban, a Pythonban és más adatrendszerekben.
• Ez azt jelenti, hogy az ügynök képes megkülönböztetni azokat a táblázatokat, amelyek hasonlónak tűnnek, de lényeges szempontokban különböznek. Például meg tudja mondani, hogy egy táblázat csak első féltől származó ChatGPT forgalmat tartalmaz-e. Ez a kontextus is automatikusan frissül, így naprakész marad manuális karbantartás nélkül.

• Az ügynök hozzáférhet a Slackhez, a Google Docs-hoz és a Notionhöz, amelyek rögzítik a kritikus vállalati kontextust, például a bevezetéseket, a megbízhatósági incidenseket, a belső kódneveket és eszközöket, valamint a kulcsfontosságú metrikák kanonikus definícióit és számítási logikáját.
• Ezeket a dokumentumokat beolvassák, beágyazzák, és metaadatokkal és engedélyekkel együtt tárolják. Egy lekérési szolgáltatás futásidőben kezeli a hozzáférés-vezérlést és a gyorsítótárazást, lehetővé téve az ügynök számára a hatékony és biztonságos hozzáférést ezekhez az információkhoz.

• Amikor az ügynök javításokat kap, vagy árnyalatokat fedez fel bizonyos adatjellegű kérdésekkel kapcsolatban, képes ezeket a tanulságokat a következő alkalomra elmenteni, így folyamatosan fejlődik a felhasználóival együtt. 
  • Ennek eredményeként a jövőbeli válaszok egy pontosabb kiindulási alapból indulnak, ahelyett hogy ismételten ugyanazokkal a problémákkal találkoznának.
  • A memória célja az, hogy megőrizze és újra felhasználja azokat a nem nyilvánvaló korrekciókat, szűrőket és kikötéseket, amelyek kritikusak az adatok helyessége szempontjából, de amelyeket önmagukban nehéz kikövetkeztetni a többi rétegből. 
  • Például egy esetben az ügynök nem tudta, hogyan szűrjön egy adott elemzési kísérletre (ez egy kísérleti kapuban meghatározott konkrét karakterlánccal való egyezésen alapult). A memória itt kulcsfontosságú volt annak biztosítására, hogy helyesen tudjon szűrni, ahelyett hogy homályosan próbálna karakterlánc-egyezést végezni.
• Amikor javítást adsz az ügynöknek, vagy amikor tanulságot von le a beszélgetésetekből, az ügynök utasítást ad, hogy mentsd el ezt a memóriát a következő alkalomra. 
  • A memóriákat a felhasználók manuálisan is létrehozhatják és szerkeszthetik.
  • A memóriák globális és személyes szinten vannak meghatározva, és az ügynök eszközei megkönnyítik a szerkesztésüket.

• Amikor egy táblához nincs korábbi kontextus, vagy a meglévő információ elavult, az ügynök élő lekérdezéseket indíthat az adattárházba, hogy közvetlenül megvizsgálja és lekérdezze a táblázatot. Ez lehetővé teszi a sémák érvényesítését, az adatok valós idejű megértését, és a megfelelő válaszadást.
• Az ügynök szükség esetén képes kommunikálni más adatplatform-rendszerekkel (metaadat-szolgáltatás, Airflow, Spark), hogy szélesebb adatkontextust szerezzen, amely az adattárházon kívül található.

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⁠(új ablakban nyílik meg) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(új ablakban nyílik meg) (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⁠(új ablakban nyílik meg) 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.