OpenAI ettevõttesisese agendi sees

Andmed annavad jõu sellele, kuidas süsteemid õpivad, tooted arenevad ja kuidas ettevõtted otsuseid teevad. Aga sageli on vastuseid kiiresti, õigesti ja õiges kontekstis saada raskem, kui see peaks olema. Et muuta see OpenAI skaleerumisel lihtsamaks, lõime omaenda eritellimusel loodud ettevõttesisese AI agendi, mis uurib meie enda platvormi ja arutleb selle üle.

Meie agent on kohandatud ainult sisekasutuseks mõeldud tööriist (mitte väline pakkumine) olema, see on loodud spetsiaalselt OpenAI andmete, õiguste ja töövoogude jaoks. Me näitame, kuidas me selle ehitasime ja kuidas seda kasutame, et aidata esile tuua näiteid tõelistest ja mõjukatest viisidest, kuidas tehisintellekt saab toetada igapäevast tööd meie meeskondades. OpenAI tööriistad, mida kasutasime selle loomiseks ja käitamiseks (Codex, meie GPT‑5 lipulaeva mudel, Evals API⁠(avaneb uues aknas) ja Embeddings API⁠(avaneb uues aknas)), on samad tööriistad, mida teeme kättesaadavaks arendajatele kõikjal mujal.

Meie andmeagent laseb töötajatel minna küsimusest teadmisteni minutitega, mitte päevadega. See alandab lävendit andmete hankimisele ja nüansirikkale analüüsile kõigis funktsioonides, mitte ainult meie andmetiimi poolt. Täna toetuvad OpenAI inseneri-, andmeteaduse, go-to-market-, finants- ja uurimismeeskonnad agendile, et vastata suure mõjuga andmeküsimustele. Näiteks võib see aidata vastata, kuidas hinnata lansseerimisi ja mõista ettevõtte tervist, seda kõike loomuliku keele intuitiivse vormingu kaudu. Agent ühendab Codexi toel saadud tabelitaseme teadmised toote- ja organisatsioonilise kontekstiga. Selle pidevalt õppiv mälusüsteem tähendab, et see täiustub iga kasutuskorraga.

Selles postituses selgitame, miks me vajasime eritellimusel loodud tehisintellekti agenti, mis teeb selle koodiga rikastatud andmekonteksti ja iseõppimise nii kasulikuks, ning milliseid õppetunde me teel õppisime.

OpenAI andmeplatvorm teenindab enam kui 3500 sisekasutajat , kes töötavad inseneritöö, toote ja teadustöö valdkondades, sellega on hõlmatud üle 600 petabaidi andmeid 70 000 andmekogumis. Sellise suuruse korral võib ainuüksi õige tabeli leidmine olla üks analüüsi tegemise ajamahukamaid osi.

Nagu üks sisekasutaja ütles:

“Meil on palju tabeleid, mis on üsna sarnased, ja ma kulutan tohutult aega, et aru saada, mille poolest need erinevad ja millist kasutada. Mõned hõlmavad väljalogitud kasutajaid, mõned ei hõlma. Mõnel on kattuvad valdkonnad; on raske aru saada, mis on mis."

Isegi kui õiged tabelid on valitud, võib õigete tulemuste saamine olla keeruline. Analüütikud peavad tabeliandmete ja tabelisuhete üle mõtlema, et tagada teisenduste ja filtrite korrektne rakendamine. Levinud tõrkemustrid—mitu-mitmega vahelised ühendused, filtri allasurumise vead ja käsitlemata nullid—võivad tulemused märkamatult kehtetuks muuta. OpenAI mastaabis ei peaks analüütikud kulutama aega SQL-semantika või päringute jõudluse silumisele: nende fookus peaks olema mõõdikute määratlemisel, eelduste valideerimisel ja andmepõhiste otsuste tegemisel.

Vaatame, mis meie agent endast kujutab, kuidas see konteksti kureerib ja kuidas see end pidevalt täiustab.

Meie agenti käitab GPT‑5.2 ja see on loodud OpenAI andmeplatvormi üle arutlemiseks. See on saadaval kõikjal, kus töötajad juba töötavad: Slacki agendina, veebiliidese kaudu, IDE-de sees, Codex CLI-s MCP kaudu⁠(avaneb uues aknas) ja otse OpenAI sisemises ChatGPT rakenduses MCP-ühendaja kaudu⁠(avaneb uues aknas).

Kasutajad saavad esitada keerulisi, avatud küsimusi, mis tavaliselt nõuaksid mitut vooru käsitsi uurimist. Võtame näiteks selle näidisviiba, mis kasutab testandmekogumit: “NYC taksosõitude puhul, millised pealevõtu ja mahapaneku ZIP-paarid on kõige ebausaldusväärsemad, suurima lõhega tüüpilise ja halvima stsenaariumi sõiduaja vahel, ja millal see varieeruvus esineb?”

Agent teostab analüüsi algusest lõpuni, alates küsimuse mõistmisest kuni andmete uurimise, päringute käivitamise ja leidude sünteesimiseni.

Üks agendi supervõimetest on see, kuidas ta probleemide üle arutleb. Selle asemel, et järgida kindlat stsenaariumi, hindab agent oma edusamme. Kui vahetulemus näib vale (nt kui sellel on ebaõige liitmise või filtri tõttu null rida), uurib agent, mis läks valesti, kohandab oma lähenemist ja proovib uuesti. Kogu selle protsessi vältel säilitab see täieliku konteksti ja kannab õpitut sammude vahel edasi. See suletud ahelaga, iseõppiv protsess viib iteratsiooni kasutajalt agendile endale, võimaldades kiiremaid tulemusi ja järjepidevalt kvaliteetsemaid analüüse kui käsitsi töövood.

Agent katab kogu analüütika töövoo: andmete avastamine, SQL-i käivitamine ning märkmike ja aruannete avaldamine. See mõistab ettevõtte siseteadmisi, oskab veebist otsida välist teavet ning areneb edasi aja jooksul õpitud kasutuse ja mälu kaudu.

Kvaliteetsed vastused sõltuvad rikkalikust ja täpsest kontekstist. Ilma kontekstita võivad isegi tugevad mudelid anda valesid tulemusi, näiteks kasutajate arvu oluliselt valesti hinnata või sisemist terminoloogiat valesti tõlgendada.

Nende tõrkemustrite vältimiseks on agent üles ehitatud mitmele kontekstikihile, mis seovad selle OpenAI andmete ja institutsionaalsete teadmistega.

• Metaandmete maandamine: agent tugineb skeemi metaandmetele (veergude nimed ja andmetüübid), et suunata SQL-i kirjutamist, ning kasutab tabelite põlvnemist (nt ülesvoolu ja allavoolu tabelite seosed), et anda konteksti selle kohta, kuidas erinevad tabelid on omavahel seotud.
• Päringu järeldamine: Ajalooliste päringute saamine aitab agendil mõista, kuidas oma päringuid kirjutada ja milliseid tabeleid tavaliselt omavahel liidetakse.

• Kureeritud kirjeldused tabelite ja veergude kohta, mille on koostanud valdkonna eksperdid, hõlmates kavatsust, semantikat, ärilist tähendust ja teadaolevaid kitsaskohti, mida ei ole lihtne skeemidest või varasematest päringutest järeldada.

Ainuüksi metaandmetest ei piisa. Selleks, et tõeliselt tabeleid eristada, pead mõistma, kuidas need loodi ja kust need pärinevad.

• Tuletades tabeli kooditasemel definitsiooni, saavutab agent sügavama arusaamise selle kohta, mida andmed tegelikult sisaldavad. 
  • Nüansid selle kohta, mida tabelisse salvestatakse ja kuidas see analüütikasündmusest tuletatakse, annavad lisateavet. Näiteks võib see anda konteksti väärtuste unikaalsuse kohta, kui sageli tabeliandmeid uuendatakse, andmete käsitlusala kohta (nt kui tabel jätab teatud väljad välja, siis on sellel selline detailsuse aste), jne.
• See pakub täiustatud kasutuskonteksti, näidates, kuidas tabelit kasutatakse lisaks SQL-ile ka Sparkis, Pythonis ja teistes andmesüsteemides.
• See tähendab, et agent suudab eristada tabeleid, mis näevad sarnased välja, kuid erinevad olulistes aspektides. Näiteks saab see öelda, kas tabel sisaldab ainult esimese osapoole ChatGPT liiklust. See kontekst värskendatakse ka automaatselt, nii püsib see ajakohasena ilma käsitsi hooldamiseta.

• Agent pääseb juurde Slackile, Google Docsile ja Notionile, mis talletavad kriitilise ettevõtte konteksti, nagu lansseerimised, töökindluse intsidendid, sisemised koodnimed ja tööriistad ning võtmemõõdikute kanoonilised definitsioonid ja arvutusloogika.
• Need dokumendid võetakse vastu, manustatakse ja salvestatakse koos metaandmete ja õigustega. Andmete hankimise teenus haldab käitusajal juurdepääsukontrolli ja vahemällu salvestamist, võimaldades agendil seda teavet tõhusalt ja turvaliselt hankida.

• Kui agent saab parandusi või avastab teatud andmeküsimuste kohta nüansse, suudab ta need õppetunnid järgmiseks korraks salvestada, see võimaldab tal koos kasutajatega pidevalt paremaks muutuda. 
  • Selle tulemusena saavad tulevased vastused alguse täpsemalt lähtealuselt, selle asemel, et korduvalt samade probleemidega kokku puutuda.
  • Mälu eesmärk on säilitada ja taaskasutada mitteilmseid parandusi, filtreid ja piiranguid, mis on andmete korrektsuse jaoks kriitilised, kuid mida on keeruline üksnes teistest kihtidest järeldada. 
  • Näiteks ühel juhul ei teadnud agent, kuidas konkreetse analüütikaeksperimendi jaoks filtreerida (see tugines vastendamisele konkreetse sõnega, mis oli määratletud eksperimendi väravas). Mälu oli siin ülioluline, et tagada korrektne filtreerimine, selle asemel et ähmaselt proovida sõnesid sobitada.
• Kui annad agendile paranduse või kui see leiab sinu vestlusest õppetunni, annab see sulle juhise mälu järgmiseks korraks salvestada. 
  • Mälestusi saavad kasutajad ka käsitsi luua ja muuta.
  • Mälestused on määratletud globaalsel ja isiklikul tasandil ning agendi tööriistad teevad lihtsaks nende muutmise.

• Kui tabeli jaoks ei ole varasemat konteksti või kui olemasolev teave on vananenud, saab agent esitada andmelaole reaalajas päringuid, et tabelit otse uurida ja päringuid esitada. See võimaldab tal skeeme valideerida, andmeid reaalajas mõista ja sellele vastavalt reageerida.
• Agent on vastavalt vajadusele õimeline suhtlema ka teiste Data Platformi süsteemidega (metaandmete teenus, Airflow, Spark), et saada laiemat andmekonteksti, mis väljaspool andmeladu asub.

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