Prezentarea agentului de date intern al OpenAI

Datele influențează modul în care sistemele învață, produsele evoluează și modul în care companiile iau decizii. Dar obținerea de răspunsuri rapide, corecte și cu contextul potrivit este adesea mai dificilă decât ar trebui să fie. Pentru a face acest lucru mai ușor pe măsură ce OpenAI se extinde, am construit propriul nostru agent de date cu IA personalizat, intern care explorează și dezvoltă un raționament asupra propriei noastre platforme.

Agentul nostru este un instrument intern personalizat (nu o ofertă externă), construit special în jurul datelor, permisiunilor și fluxurilor de lucru OpenAI. Arătăm cum l-am creat și folosit pentru a scoate la iveală exemple de modalități reale și eficiente în care inteligența artificială poate sprijini munca zilnică a echipelor noastre. Instrumentele OpenAI pe care le-am folosit pentru a-l crea și rula (Codex, modelul nostru de vârf GPT‑5, API-ul Evals⁠(se deschide într-o fereastră nouă) și API-ul Embeddings⁠(se deschide într-o fereastră nouă)) sunt aceleași instrumente pe care le punem la dispoziția dezvoltatorilor de pretutindeni.

Agentul nostru de date le permite angajaților să treacă de la întrebare la informație în doar câteva minute, nu în zile. Acest lucru reduce barierele în calea extragerii datelor și a unei analize nuanțate în toate departamentele, nu doar pentru echipa noastră de date. Astăzi, echipele de inginerie, știință a datelor, lansare pe piață, finanțe și cercetare de la OpenAI utilizează agentul pentru a răspunde la întrebări cu impact ridicat privind datele. De exemplu, poate ajuta la evaluarea lansărilor și la înțelegerea stării afacerii, totul prin intermediul formatului intuitiv al limbajului natural. Agentul combină cunoștințele la nivel de tabel bazate pe Codex cu contextul produsului și al organizației. Sistemul său de memorie care se învață continuu înseamnă că se îmbunătățește cu fiecare interacțiune.

În această postare, vom analiza de ce aveam nevoie de un agent de date cu IA personalizat, ce face ca contextul său de date îmbogățit cu cod și auto-învățarea să fie atât de utile și lecțiile pe care le-am învățat pe parcurs.

Platforma de date OpenAI deservește peste 3,5 mii de utilizatori interni care lucrează în inginerie, produs și cercetare, acoperind peste 600 petabyți de date din 70.000 de seturi de date. La o asemenea dimensiune, simpla găsire a tabelului potrivit poate fi unul dintre cele mai laborioase aspecte ale analizei.

După cum a spus un utilizator intern:

„Avem o mulțime de tabele destul de similare și petrec mult timp încercând să-mi dau seama prin ce diferă și pe care să le folosesc. Unele includ utilizatori deconectați, altele nu. Unele au câmpuri care se suprapun; e greu de spus ce reprezintă fiecare.”

Chiar și cu tabelele selectate corect, obținerea unor rezultate corecte poate fi dificilă. Analiștii trebuie să analizeze datele din tabel și relațiile dintre tabele pentru a se asigura că transformările și filtrele sunt aplicate corect. Modurile comune de eșec — îmbinări many-to-many, erori de filtrare pushdown și valori nule neprelucrate — pot invalida rezultatele în mod silențios. La scara OpenAI, analiștii nu ar trebui să fie nevoiți să investească timp în depanarea semanticii SQL sau a performanței interogărilor: accentul lor ar trebui să fie pus pe definirea indicatorilor, validarea presupunerilor și luarea deciziilor bazate pe date.

Să vedem ce este agentul nostru, cum gestionează contextul și cum se autoperfecționează în mod constant.

Agentul nostru este susținut de GPT‑5.2 și este conceput să funcționeze pe platforma de date OpenAI. Este disponibil oriunde lucrează deja angajații: ca agent Slack, printr-o interfață web, în IDE-uri, în Codex CLI prin MCP⁠(se deschide într-o fereastră nouă) și direct în aplicația ChatGPT internă a OpenAI printr-un conector MCP⁠(se deschide într-o fereastră nouă).

Utilizatorii pot pune întrebări complexe, deschise, care ar necesita de obicei mai multe rânduri de explorare manuală. Iată un exemplu de solicitare care folosește un set de date de testare: „Pentru cursele de taxi din NYC, care perechi de coduri poștale de la preluare la destinație sunt cele mai nefiabile, cu cel mai mare decalaj între timpii de călătorie tipici și cei din cel mai defavorabil caz, și când apare această variabilitate?”

Agentul gestionează analiza complet, de la înțelegerea întrebării până la explorarea datelor, rularea interogărilor și sintetizarea constatărilor.

Una dintre superputerile agentului este modul în care dezvoltă raționamente pentru rezolvarea problemelor. În loc să urmeze un scenariu fix, agentul își evaluează propriul progres. Dacă un rezultat intermediar pare greșit (de exemplu, dacă are zero rânduri din cauza unei îmbinări sau a unui filtru incorect), agentul investighează ce a mers prost, își ajustează abordarea și încearcă din nou. Pe parcursul acestui proces, păstrează contextul complet și transferă învățămintele între pași. Acest proces de auto-învățare, cu buclă închisă, mută iterația de la utilizator la agentul în sine, permițând rezultate mai rapide și analize de o calitate constant superioară față de fluxurile de lucru manuale.

Agentul acoperă întregul flux de lucru analitic: descoperirea datelor, rularea SQL și publicarea blocnotesurilor și rapoartelor. Înțelege cunoștințele interne ale companiei, poate căuta informații externe pe web și se îmbunătățește în timp prin utilizarea învățată și prin memorie.

Răspunsurile de înaltă calitate depind de un context bogat și precis. Fără context, chiar și modelele performante pot produce rezultate greșite, cum ar fi estimarea extrem de greșită a numărului de utilizatori sau interpretarea greșită a terminologiei interne.

Pentru a evita aceste moduri de eșec, agentul este creat pe baza mai multor straturi de context care îl fundamentează pe datele și cunoștințele instituționale ale OpenAI.

• Fundamentarea pe metadate: Agentul se bazează pe metadatele schemei (numele coloanelor și tipurile de date) pentru a influența scrierea SQL și utilizează descendența tabelului (de exemplu, relațiile dintre tabelele din amonte și din aval) pentru a oferi contextul relației dintre diferite tabele.
• Inferența interogărilor: Ingerarea interogărilor istorice ajută agentul să înțeleagă cum să-și scrie propriile interogări și ce tabele sunt de obicei îmbinate.

• Descrieri atent selecționate ale tabelelor și coloanelor, furnizate de experți în domeniu, care surprind intenția, semantica, semnificația comercială și avertismentele cunoscute care nu pot fi deduse ușor din scheme sau interogări anterioare.

Doar metadatele nu sunt suficiente. Ca să distingi cu adevărat tabelele, trebuie să înțelegi cum au fost create și de unde provin.

• Prin derivarea unei definiții la nivel de cod a unui tabel, agentul își construiește o înțelegere mai profundă a ceea ce conțin efectiv datele. 
  • Nuanțele legate de conținutul tabelului și modul în care este derivat dintr-un eveniment analitic oferă informații suplimentare. De exemplu, poate oferi context privind unicitatea valorilor, frecvența actualizării datelor din tabel, domeniul de aplicare al datelor (de exemplu, dacă tabelul exclude anumite câmpuri, are acest nivel de granularitate) etc.
• Aceasta oferă un context de utilizare îmbunătățit, arătând modul în care tabelul este utilizat dincolo de SQL în Spark, Python și alte sisteme de date.
• Aceasta înseamnă că agentul poate deosebi tabele care arată similar, dar diferă în moduri esențiale. De exemplu, poate spune dacă un tabel include doar trafic ChatGPT de primă parte. Acest context este actualizat automat, astfel încât rămâne actualizat fără întreținere manuală.

• Agentul poate accesa Slack, Google Docs și Notion, care cuprind informații esențiale despre companie, cum ar fi lansări, incidente legate de fiabilitate, nume de cod și instrumente interne, precum și definițiile oficiale și logica de calcul pentru indicatorii cheie.
• Aceste documente sunt preluate, încorporate și stocate cu metadate și permisiuni. Un serviciu de recuperare gestionează controlul accesului și cache-ul în timpul execuției, permițându-i agentului să preia aceste informații eficient și în siguranță.

• Când agentul primește corecții sau descoperă nuanțe despre anumite întrebări legate de date, poate salva aceste învățăminte pentru data viitoare, permițându-i să se îmbunătățească constant împreună cu utilizatorii săi. 
  • Ca urmare, răspunsurile viitoare pornesc de la o bază mai precisă, în loc să întâlnească în mod repetat aceleași probleme.
  • Scopul memoriei este de a reține și reutiliza corecții, filtre și constrângeri care nu sunt evidente, dar care sunt esențiale pentru corectitudinea datelor, însă dificil de dedus exclusiv din celelalte straturi. 
  • De exemplu, într-un caz, agentul nu știa cum să filtreze pentru un anumit experiment de analiză (se baza pe potrivirea cu un șir specific definit într-o etapă a experimentului). Memoria a fost extrem de importantă aici pentru a se asigura că poate filtra corect, în loc să încerce vag să potrivească șiruri.
• Când îi oferi agentului o corecție sau când găsește o informație utilă în conversația ta, îți va solicita să salvezi acea amintire pentru data viitoare. 
  • Amintirile pot fi, de asemenea, create și editate manual de către utilizatori.
  • Amintirile sunt gestionate la nivel global și personal, iar instrumentele agentului facilitează editarea lor.

• Când nu există un context anterior pentru un tabel sau când informațiile existente sunt învechite, agentul poate lansa interogări live către depozitul de date pentru a inspecta și interoga tabelul direct. Acest lucru îi permite să valideze schemele, să înțeleagă datele în timp real și să răspundă corespunzător.
• Agentul poate, de asemenea, să comunice cu alte sisteme ale platformei de date (serviciu de metadate, Airflow, Spark), după cum este necesar, pentru a obține un context de date mai amplu care există în afara depozitului.

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⁠(se deschide într-o fereastră nouă) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(se deschide într-o fereastră nouă) (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⁠(se deschide într-o fereastră nouă) 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.