OpenAI iekšējā datu aģenta iekšpusē

Dati veicina to, kā sistēmas mācās, produkti attīstās un kā uzņēmumi pieņem lēmumus. Bet atbildes iegūt ātri, pareizi un ar pareizo kontekstu bieži vien ir grūtāk, nekā tam vajadzētu būt. Lai atvieglotu OpenAI mērogošanu, mēs izveidojām pašu pielāgotu iekšējo MI datu aģentu, kas izpēta un analizē mūsu platformu.

Mūsu aģents ir pielāgots rīks tikai iekšējai lietošanai (nevis ārējs piedāvājums), kas izveidots tieši, balstoties uz OpenAI datiem, atļaujām un darbplūsmām. Mēs parādām, kā mēs to izveidojām un izmantojam, lai palīdzētu izcelt piemērus par reāliem, ietekmīgiem veidiem, kā mākslīgais intelekts var atbalstīt ikdienas darbu mūsu komandās. OpenAI rīki, kurus izmantojām, lai to izveidotu un darbinātu (Codex, mūsu GPT‑5 pamatmodelis, Evals API⁠(atveras jaunā logā) un Embeddings API⁠(atveras jaunā logā)), ir tie paši rīki, kurus padarām pieejamus izstrādātājiem visā pasaulē.

Mūsu datu aģents ļauj darbiniekiem no jautājuma nonākt līdz ieskatam minūtēs, nevis dienās. Tas pazemina slieksni datu iegūšanai un niansētai analīzei visās funkcijās, ne tikai mūsu datu komandai. Šodien OpenAI inženierijas, datu zinātnes, tirgū palaišanas, finanšu un pētniecības komandas paļaujas uz aģentu, lai atbildētu uz nozīmīgiem datu jautājumiem. Piemēram, tas var palīdzēt atbildēt uz jautājumu, kā novērtēt produktu palaišanu un izprast uzņēmējdarbības veselību, un tas viss — izmantojot intuitīvu dabiskās valodas formātu. Aģents apvieno Codex nodrošinātas tabulu līmeņa zināšanas ar produkta un organizācijas kontekstu. Tās nepārtraukti mācīties spējīgā atmiņas sistēma nozīmē, ka tā uzlabojas arī ar katru reizi.

Šajā ierakstā mēs izskaidrosim, kāpēc mums bija nepieciešams pielāgots MI datu aģents, kas padara tā kodu bagātināto datu kontekstu un pašmācīšanos tik noderīgu, un kādas mācības mēs guvām šajā ceļā.

OpenAI datu platforma apkalpo vairāk nekā 3,5 tūkstošus iekšējo lietotāju , kas strādā inženierijas, produktu un pētniecības jomās, aptverot vairāk nekā 600 petabaitu datu visā 70 tūkstošos datu kopu. Šādā apjomā atrast īsto tabulu var būt viena no laikietilpīgākajām analīzes daļām.

Kā teica viens no iekšējiem lietotājiem:

“Mums ir daudz tabulu, kas ir diezgan līdzīgas, un es pavadu daudz laika, mēģinot saprast, ar ko tās atšķiras un kuru izmantot. Dažās ir iekļauti nepieteikušies lietotāji, dažās nav iekļauti. Dažās lauki pārklājas; ir grūti saprast, kas ir kas.

Pat ar pareizi atlasītām tabulām pareizu rezultātu iegūšana var būt sarežģīta. Analītiķiem ir jāspēj analizēt tabulu datus un to savstarpējās attiecības, lai nodrošinātu, ka transformācijas un filtri tiek piemēroti pareizi. Bieži sastopamie kļūdu režīmi - savienošana no daudziem uz daudziem, filtra izspiešanas kļūdas un neapstrādāti nulles punkti - var nemanāmi padarīt rezultātus nederīgus. OpenAI mērogā analītiķiem nevajadzētu tērēt laiku SQL semantikas vai vaicājumu veiktspējas atkļūdošanai; viņu uzmanībai jābūt vērstai uz metriku definēšanu, pieņēmumu validēšanu un uz datiem balstītu lēmumu pieņemšanu.

Apskatīsim, kas ir mūsu aģents, kā tas veido kontekstu un kā tas turpina sevi uzlabot.

Mūsu aģentu nodrošina GPT‑5.2, un tas ir izstrādāts, lai veiktu loģisku analīzi OpenAI datu platformā. Tas ir pieejams visur, kur darbinieki jau strādā: kā Slack aģents, izmantojot tīmekļa saskarni, IDE vidē, Codex CLI, izmantojot MCP⁠(atveras jaunā logā), un tieši OpenAI iekšējā ChatGPT lietotnē, izmantojot MCP savienotāju⁠(atveras jaunā logā).

Lietotāji var uzdot sarežģītus, atvērtus jautājumus, kuru risināšanai parasti būtu nepieciešamas vairākas manuālas izpētes kārtas. Ņem šo uzvednes piemēru, kurā tiek izmantota testa datu kopa: “Ņujorkas taksometru braucieniem, kuri paņemšanas–izkāpšanas pasta indeksa pāri ir visneuzticamākie, ar vislielāko atšķirību starp tipisko un sliktākā gadījuma brauciena laiku, un kad rodas šī mainība?”

Aģents veic analīzi no sākuma līdz beigām, sākot no jautājuma izpratnes līdz datu izpētei, pieprasījumu izpildei un atklājumu sintezēšanai.

Viena no aģenta superspējām ir spēja loģiski risināt problēmas. Tā vietā, lai sekotu noteiktam scenārijam, aģents pats izvērtē savu progresu. Ja starprezultāts izskatās nepareizs (piemēram, ja tam ir nulle rindu nepareiza savienojuma vai filtra dēļ), aģents izmeklē, kas nogāja greizi, pielāgo savu pieeju un mēģina vēlreiz. Visā šī procesa laikā tas saglabā pilnu kontekstu un pārnes apgūtās mācības starp soļiem. Šis slēgtā cikla, pašmācošais process pārvieto iterāciju no lietotāja uz pašu aģentu, ļaujot sasniegt ātrākus rezultātus un konsekventi augstākas kvalitātes analīzes nekā manuālās darbplūsmas.

Aģents aptver pilnu analītikas darbplūsmu: datu atklāšanu, SQL izpildi, kā arī piezīmju grāmatiņu un atskaišu publicēšanu. Tas saprot uzņēmuma iekšējās zināšanas, var veikt tīmekļa meklēšanu ārējās informācijas iegūšanai un laika gaitā uzlabojas, izmantojot apgūto pieredzi un atmiņu.

Augstas kvalitātes atbildes ir atkarīgas no bagātīga un precīza konteksta. Bez konteksta pat spēcīgi modeļi var radīt nepareizus rezultātus, piemēram, būtiski kļūdaini novērtēt lietotāju skaitu vai nepareizi interpretēt iekšējo terminoloģiju.

Lai izvairītos no šiem atteices režīmiem, aģents ir veidots no vairākiem konteksta slāņiem, kas to balsta OpenAI datu un institucionālajās zināšanās.

• Metadatu piesaiste: aģents izmanto shēmas metadatus (kolonnu nosaukumus un datu tipus), lai rakstītu SQL, un izmanto tabulu ciltskoku (piemēram, augšupējo un lejupējo tabulu attiecības), lai sniegtu kontekstu par to, kā dažādas tabulas ir saistītas.
• Vaicājumu secināšana: vēsturisko vaicājumu apstrāde palīdz aģentam saprast, kā veidot savus vaicājumus un kuras tabulas parasti tiek apvienotas.

• Kurēti apraksti par tabulām un kolonnām, ko sniedz jomas eksperti, atspoguļojot nodomu, semantiku, biznesa nozīmi un zināmos brīdinājumus, kurus nav viegli secināt no shēmām vai iepriekšējiem vaicājumiem.

Ar metadatiem vien nepietiek. Lai patiešām atšķirtu tabulas, tev ir jāsaprot, kā tās tika izveidotas un no kurienes tās nāk.

• Izveidojot tabulas koda līmeņa definīciju, aģents iegūst dziļāku izpratni par to, ko dati patiesībā satur. 
  • Nianses par to, kas tiek glabāts tabulā un kā tas tiek atvasināts no analītikas notikuma, sniedz papildu informāciju. Piemēram, tas var sniegt kontekstu par vērtību unikalitāti, cik bieži tabulas dati tiek atjaunināti, datu tvērumu (piemēram, ja tabulā ir izslēgti noteikti lauki, tai ir šāds detalizācijas līmenis) u. c.
• Tas nodrošina uzlabotu lietošanas kontekstu, parādot, kā tabula tiek izmantota ne tikai SQL, bet arī Spark, Python un citās datu sistēmās.
• Tas nozīmē, ka aģents spēj atšķirt tabulas, kas izskatās līdzīgas, bet būtiski atšķiras. Piemēram, tas var noteikt, vai tabulā ir iekļauta tikai pirmās puses ChatGPT datplūsma. Šis konteksts tiek automātiski atjaunināts, tāpēc tas vienmēr ir aktuāls bez nepieciešamības pēc manuālas uzturēšanas.

• Aģents var piekļūt Slack, Google Docs un Notion, kas apkopo kritiski svarīgu uzņēmuma kontekstu, piemēram, palaišanas, uzticamības incidentus, iekšējos koda nosaukumus un rīkus, kā arī kanoniskās definīcijas un aprēķinu loģiku galvenajiem rādītājiem.
• Šie dokumenti tiek importēti, iegulti un glabāti ar metadatiem un atļaujām. Izgūšanas pakalpojums izpildlaikā nodrošina piekļuves kontroli un kešatmiņu, ļaujot aģentam efektīvi un droši iegūt šo informāciju.

• Kad aģentam tiek sniegti labojumi vai tas atklāj nianses par noteiktiem datu jautājumiem, tas spēj saglabāt šīs atziņas nākamajai reizei, ļaujot tam pastāvīgi uzlaboties kopā ar lietotājiem. 
  • Tā rezultātā nākotnes atbildes sākas no precīzāka pamata, nevis atkārtoti saskaras ar tām pašām problēmām.
  • Atmiņas mērķis ir saglabāt un atkārtoti izmantot neuzkrītošus labojumus, filtrus un ierobežojumus, kas ir būtiski datu pareizībai, bet kurus ir grūti secināt tikai no citiem slāņiem. 
  • Piemēram, vienā gadījumā aģents nezināja, kā filtrēt konkrētu analītikas eksperimentu (tas balstījās uz atbilstības pārbaudi, salīdzinot ar konkrētu virkni, kas definēta eksperimenta vārtos). Atmiņa šeit bija ļoti svarīga, lai nodrošinātu pareizu filtrēšanu, nevis neskaidru virkņu atbilstības meklēšanu.
• Sniedzot aģentam labojumu vai tam atrodot atziņu no tavas sarunas, tas parāda uzvedni, lai tu saglabātu šo atmiņu nākamajai reizei. 
  • Atmiņas var arī manuāli izveidot un rediģēt lietotāji paši.
  • Atmiņas ir noteiktas globālā un personīgā līmenī, un aģenta rīki ļauj tās viegli rediģēt.

• Ja tabulai nav iepriekšēja konteksta vai esošā informācija ir novecojusi, aģents var veikt tiešos vaicājumus datu noliktavā, lai tiešā veidā pārbaudītu tabulu un uzdotu tai vaicājumus. Tas ļauj validēt shēmas, izprast datus reāllaikā un attiecīgi reaģēt.
• Aģents var arī sazināties ar citām Data Platform sistēmām (metadatu pakalpojumu, Airflow, Spark), kad tas ir nepieciešams, lai iegūtu plašāku datu kontekstu, kas atrodas ārpus noliktavas.

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