Žvilgsnis į „OpenAI“ vidinį duomenų agentą

Duomenys lemia, kaip sistemos mokosi, produktai tobulėja ir kaip įmonės priima sprendimus. Tačiau gauti atsakymus greitai, teisingai ir turint tinkamą kontekstą dažnai yra sunkiau, nei turėtų būti. Siekdami tai palengvinti plečiantis „OpenAI“, sukūrėme savo specializuotą vidinį DI duomenų agentą, kuris tyrinėja ir analizuoja mūsų pačių platformą.

Mūsų agentas yra specializuotas, tik vidaus naudojimui skirtas įrankis (ne išorinis pasiūlymas), sukurtas specialiai pagal „OpenAI“ duomenis, leidimus ir darbo eigas. Rodome, kaip jį sukūrėme ir naudojame, kad pateiktume realių, reikšmingų pavyzdžių, kaip DI gali padėti atlikti kasdienį darbą visose mūsų komandose. „OpenAI“ įrankiai, kuriuos naudojome jam sukurti ir valdyti (Codex, mūsų GPT‑5 pavyzdinis modelis, Evals API⁠(atsidaro naujame lange) ir Embeddings API⁠(atsidaro naujame lange)), yra tie patys įrankiai, kuriuos teikiame kūrėjams visame pasaulyje.

Mūsų duomenų agentas leidžia darbuotojams gauti įžvalgas iš klausimų per kelias minutes, o ne dienas. Tai sumažina kliūtis traukiant duomenis ir atliekant niuansuotą analizę visose funkcijose, ne tik mūsų duomenų komandoje. Šiandien Inžinerijos, Duomenų mokslo, Patekimo į rinką strategijos, Finansų ir Tyrimų komandos „OpenAI“ viduje pasitelkia agentą atsakydamos į didelio poveikio duomenų klausimus. Pavyzdžiui, jis gali padėti atsakyti, kaip įvertinti pristatymus ir suprasti verslo būklę, visa tai atliekant intuityviu natūraliosios kalbos formatu. Agentas sujungia „Codex“ paremtas lentelių lygmens žinias su produkto ir organizaciniu kontekstu. Jo nuolat besimokanti atminties sistema reiškia, kad jis taip pat tobulėja su kiekvienu veiksmu.

Šiame įraše išskaidysime, kodėl mums reikėjo specializuoto DI duomenų agento, kuo naudingas jo kodu praturtintas duomenų kontekstas bei savarankiškas mokymasis, ir ko išmokome šiame procese.

„OpenAI“ duomenų platforma aptarnauja daugiau nei 3,5 tūkst. vidinių naudotojų, dirbančių Inžinerijos, Produktų ir Tyrimų srityse, apimdama daugiau nei 600 petabaitų duomenų 70-yje tūkst. duomenų rinkinių. Esant tokiam mastui, tiesiog rasti tinkamą lentelę gali būti viena daugiausiai laiko reikalaujančių analizės dalių.

Kaip pasakė vienas įmonės naudotojas:

„Turime daugybę lentelių, kurios yra gana panašios; aš praleidžiu marias laiko bandydamas išsiaiškinti, kuo jos skiriasi ir kurią naudoti. Vienose yra neprisijungę naudotojai, kitose – ne. Kai kurios turi persidengiančių laukų; sunku pasakyti, kas yra kas.“

Net pasirinkus tinkamas lenteles, gauti teisingus rezultatus gali būti sudėtinga. Analitikai turi protauti apie lentelių duomenis ir lentelių ryšius, kad užtikrintų tinkamą transformacijų ir filtrų taikymą. Dažni nesėkmės būdai – jungimai „daug su daug“, filtrų nuleidimo (pushdown) klaidos ir neapdorotos „null“ reikšmės – gali tyliai paversti rezultatus neteisingais. „OpenAI“ mastu analitikai neturėtų gaišti laiko derindami SQL semantiką ar užklausų našumą: jie turėtų telkti dėmesį į rodiklių apibrėžimą, prielaidų tikrinimą ir duomenimis pagrįstų sprendimų priėmimą.

Apžvelkime, kas yra mūsų agentas, kaip jis kuruoja kontekstą ir kaip jis nuolat savarankiškai tobulėja.

Mūsų agentas veikia GPT‑5.2 pagrindu ir yra sukurtas protauti „OpenAI“ duomenų platformoje. Jis pasiekiamas visur, kur darbuotojai jau dirba: kaip „Slack“ agentas, per žiniatinklio sąsają, IDE aplinkose, „Codex“ CLI per MCP⁠(atsidaro naujame lange) ir tiesiogiai „OpenAI“ vidinėje „ChatGPT“ programoje per MCP jungtį⁠(atsidaro naujame lange).

Naudotojai gali užduoti sudėtingus, atvirus klausimus, kuriems paprastai prireiktų kelių rankinio tyrimo etapų. Paimkime šią pavyzdinę užklausą, kurioje naudojamas bandomasis duomenų rinkinys: „For NYC taxi trips, which pickup-to-dropoff ZIP pairs are the most unreliable, with the largest gap between typical and worst-case travel times, and when does that variability occur?“ (Kalbant apie Niujorko taksi keliones, kurios įlaipinimo ir išlaipinimo ZIP kodų poros yra pačios nepatikimiausios, t. y. turinčios didžiausią atotrūkį tarp įprastos ir blogiausio atvejo kelionės trukmės, ir kada šis kintamumas pasireiškia?)

Agentas atlieka analizę nuo pradžios iki galo: nuo klausimo supratimo iki duomenų tyrinėjimo, užklausų vykdymo ir išvadų susisteminimo.

Viena iš agento supergalių yra tai, kaip jis protauja spręsdamas problemas. Užuot sekęs fiksuotu scenarijumi, agentas įvertina savo pažangą. Jei tarpinis rezultatas atrodo neteisingas (pvz., jame yra nulis eilučių dėl netinkamo sujungimo ar filtro), agentas tiria, kas nutiko, pakoreguoja savo metodą ir bando dar kartą. Per visą šį procesą jis išlaiko visą kontekstą ir perkelia išmoktus dalykus į kitus žingsnius. Šis uždarojo ciklo, savarankiško mokymosi procesas leidžia agentui pačiam atlikti iteracijas vietoje naudotojo – taip greičiau gaunami rezultatai ir užtikrinamos nuosekliai kokybiškesnės analizės nei rankinės darbo eigos.

Agentas apima visą analizaės darbo eigą: duomenų atradimą, SQL vykdymą ir užrašinių bei ataskaitų publikavimą. Jis supranta vidines įmonės žinias, gali ieškoti išorinės informacijos internete ir laikui bėgant tobulėja dėl išmokto naudojimo ir atminties.

Aukštos kokybės atsakymai priklauso nuo turtingo, tikslaus konteksto. Be konteksto net stiprūs modeliai gali pateikti klaidingus rezultatus, pavyzdžiui, visiškai neteisingai įvertinti naudotojų skaičių arba klaidingai interpretuoti vidinę terminiją.

Kad būtų išvengta šių nesėkmės būdų, agentas sukurtas remiantis keliais konteksto sluoksniais, kurie jį pagrindžia „OpenAI“ duomenimis ir institucinėmis žiniomis.

• Pagrindimas metaduomenimis: agentas remiasi schemos metaduomenimis (stulpelių pavadinimais ir duomenų tipais) rašydamas SQL ir naudoja lentelių kilmę (pvz., pirmesnių ir tolesnių grandžių lentelių ryšius), kad suteiktų kontekstą apie tai, kaip skirtingos lentelės yra susijusios.
• Užklausų modelio vykdymas: istorinių užklausų įkėlimas padeda agentui suprasti, kaip rašyti savo užklausas ir kurios lentelės paprastai jungiamos kartu.

• Kuruojami lentelių ir stulpelių aprašymai, kuriuos pateikia srities ekspertai, apimantys ketinimą, semantiką, verslo prasmę ir žinomas išlygas, kurios nėra lengvai numanomos iš schemų ar ankstesnių užklausų.a

Vien metaduomenų nepakanka. Norint iš tikrųjų atskirti lenteles, reikia suprasti, kaip jos buvo sukurtos ir iš kur jos atsirado.

• Išvesdamas kodo lygmens lentelės apibrėžimą, agentas geriau supranta, kas iš tikrųjų yra duomenyse.
  • Niuansai apie tai, kas saugoma lentelėje ir kaip ji išvedama iš analizės įvykio, suteikia papildomos informacijos. Pavyzdžiui, tai gali suteikti konteksto apie reikšmių unikalumą, kaip dažnai atnaujinami lentelės duomenys, duomenų apimtį (pvz., jei lentelėje nėra tam tikrų laukų, ji pasižymi tokiu detalumu) ir t. t.
• Tai suteikia patobulintą naudojimo kontekstą parodant, kaip lentelė naudojama ne tik SQL, bet ir „Spark“, „Python“ bei kitose duomenų sistemose.
• Tai reiškia, kad agentas gali atskirti lenteles, kurios atrodo panašios, bet skiriasi kritiniais aspektais. Pavyzdžiui, jis gali pasakyti, ar lentelė apima tik tiesioginį „ChatGPT“ srautą. Šis kontekstas taip pat atnaujinamas automatiškai, todėl jis išlieka naujas be rankinės priežiūros.

• Agentas gali pasiekti „Slack“, „Google Docs“ ir „Notion“, kuriuose fiksuojamas svarbus įmonės kontekstas, pavyzdžiui, pristatymai, patikimumo incidentai, vidiniai kodiniai pavadinimai ir įrankiai bei pagrindinių rodiklių kanoninės apibrėžtys ir skaičiavimo logika.
• Šie dokumentai įkeliami, paverčiami vektoriniais duomenimis ir saugomi su metaduomenimis bei leidimais. Gavimo paslauga valdo prieigos kontrolę ir kaupimą talpykloje vykdymo metu, leisdama agentui efektyviai ir saugiai gauti šią informaciją.

• Kai agentui pateikiami taisymai arba jis aptinka niuansų apie tam tikrus duomenų klausimus, jis gali įrašyti šiuos išmoktus dalykus kitam kartui, taip nuolat tobulėdamas kartu su naudotojais. 
  • Dėl to būsimi atsakymai pradedami nuo tikslesnio atskaitos taško, užuot pakartotinai susidūrus su tomis pačiomis problemomis.
  • Atminties tikslas – išsaugoti ir pakartotinai naudoti neakivaizdžius taisymus, filtrus ir apribojimus, kurie yra labai svarbūs duomenų teisingumui, bet sunkiai nustatomi vien iš kitų sluoksnių.
  • Pavyzdžiui, vienu atveju agentas nežinojo, kaip filtruoti tam tikrą analizės eksperimentą (jis rėmėsi atitikties tikrinimu pagal konkrečią eilutę, apibrėžtą eksperimento vartuose). Atmintis šiuo atveju buvo labai svarbi siekiant užtikrinti tinkamą filtravimą, užuot netiksliai bandžius derinti eilutes.
• Kai agentui pateikiate taisymą arba kai jis pokalbio metu kažką išmoksta, jis pasiūlys išsaugoti šią atmintį kitam kartui. 
  • Atmintis taip pat gali rankiniu būdu sukurti ir redaguoti naudotojai.
  • Atminčių apimtis nustatoma visuotiniu ir asmeniniu lygmeniu, o agento įrankiai leidžia lengvai jas redaguoti.

• Kai nėra ankstesnio konteksto apie lentelę arba kai turima informacija yra pasenusi, agentas gali pateikti tiesiogines užklausas duomenų saugyklai, kad tiesiogiai patikrintų lentelę ir atliktų užklausą. Tai leidžia realiuoju laiku patvirtinti schemas, suprasti duomenis ir atitinkamai reaguoti.
• Agentas taip pat gali susisiekti su kitomis Duomenų platformos sistemomis (metaduomenų paslauga, „Airflow“, „Spark“), kai reikia gauti platesnį duomenų kontekstą, esantį už saugyklos ribų.

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