Innan innanhúss gagnafulltrúi OpenAI

Gögn knýja hvernig kerfi læra, vörur þróast og hvernig fyrirtæki taka ákvarðanir. En að fá svör fljótt, rétt og í réttu samhengi er oft erfiðara en það ætti að vera. Til að auðvelda þetta þegar OpenAI stækkar, smíðuðum við okkar eigin sérsniðna gervigreindarfulltrúa innan fyrirtækisins sem rannsakar og rökstyður á okkar eigin verkvangi.

Fulltrúi okkar er sérsniðið innanhússverkfæri (ekki ytra framboð), smíðað sérstaklega í kringum gögn, heimildir og vinnuflæði OpenAI. Við erum að sýna hvernig við byggðum það og notum það til að draga fram dæmi um raunverulegar og áhrifamiklar leiðir sem gervigreind getur stutt daglegt starf í teymum okkar. OpenAI-verkfærin sem við notuðum til að byggja og keyra það (Codex, GPT‑5 flaggskipslíkani okkar, Evals API⁠(opnast í nýjum glugga) og Embeddings API⁠(opnast í nýjum glugga)) eru sömu verkfærin sem við gerum aðgengileg forriturum alls staðar.

Gagnafulltrúi okkar gerir starfsmönnum kleift að fara frá spurningu til innsýnar á nokkrum mínútum, ekki dögum. Þetta auðveldar gagnaöflun og ítarlega greiningu yfir allar deildir, ekki bara hjá gagnateyminu okkar. Í dag treysta teymi í verkfræði, gagnavísindum, fara-á-markað, fjármálum og rannsóknum hjá OpenAI á fulltrúann til að svara gagnaspurningum með miklum áhrifum. Til dæmis getur það hjálpað við að svara hvernig á að meta útgáfur og skilja ástand fyrirtækisins, allt í gegnum innsæi náttúrulegs máls. Fulltrúinn sameinar Codex-knúna þekkingu á töflustigi við vöru- og skipulagslegt samhengi. Stöðugt lærandi minniskerfi þess þýðir að það bætir sig einnig með hverri umferð.

Í þessari færslu munum við útskýra hvers vegna við þurftum sérsniðinn gervigreindargagnafulltrúa, hvað gerir kóðaauðgað gagnasamhengi hans og sjálfsnám svo gagnlegt, og hvaða lærdóma við öðluðumst í leiðinni.

Gagnaverkvangur OpenAI þjónar meira en 3.500 innri notendum sem starfa á sviðum verkfræði, vöruþróunar og rannsókna og nær yfir meira en 600 petabæti af gögnum í 70.000 gagnasöfnum. Í þeirri stærð getur það eitt og sér að finna réttu töfluna verið einn af tímafrekustu þáttunum við að framkvæma greiningu.

Eins og einn innri notandi orðaði það:

„Við erum með margar töflur sem eru nokkuð líkar, og ég eyði miklum tíma í að reyna að átta mig á því hvernig þær eru ólíkar og hverja á að nota. Sumar innihalda útskráða notendur, aðrar ekki. Sumt hefur skörun á sviðum; það er erfitt að átta sig á hvað er hvað.“

Jafnvel þegar réttar töflur eru valdar getur verið erfitt að fá réttar niðurstöður. Greinendur þurfa að íhuga töflugögn og tengsl milli taflna til að tryggja að umbreytingar og síur séu rétt notaðar. Algengar bilunarleiðir—margföld tengsl, villur við síuþrýsting og ómeðhöndluð núllgildi—geta hljóðlega gert niðurstöður ógildar. Á þeim mælikvarða sem OpenAI starfar á ættu greiningaraðilar ekki að þurfa að eyða tíma í að kemba SQL-semantík eða afköst fyrirspurna: áherslan þeirra ætti að vera á að skilgreina mælikvarða, sannreyna forsendur og taka gagnadrifnar ákvarðanir.

Förum yfir hvað fulltrúi okkar er, hvernig hann mótar samhengi og hvernig hann heldur áfram að bæta sig.

Fulltrúi okkar er knúinn af GPT‑5.2 og er hannaður til að vinna með OpenAI-gagnaverkvanginum. Hann er í boði hvar sem starfsmenn vinna nú þegar: sem Slack-fulltrúi, í gegnum vefviðmót, inni í IDE-kerfum, í Codex CLI í gegnum MCP⁠(opnast í nýjum glugga), og beint í innra ChatGPT‑forriti OpenAI í gegnum MCP-tengil⁠(opnast í nýjum glugga).

Notendur geta spurt flókinna, opinna spurninga sem venjulega myndu krefjast margra umferða af handvirkri könnun. Taktu þetta dæmi um kvaðningu sem notar prófunargagnasett: „Fyrir NYC leigubílaferðir, hvaða pör af póstnúmerum fyrir sótt til skilað eru óáreiðanlegust, með stærsta bilið milli dæmigerðs og versta tilfellis ferðatíma, og hvenær á sér stað þessi breytileiki?“

Fulltrúinn sér um greininguna frá upphafi til enda, frá því að skilja spurninguna til að kanna gögnin, keyra fyrirspurnir og samþætta niðurstöður.

Einn af ofurkröftum fulltrúans er hvernig hann leysir vandamál með rökum. Frekar en að fylgja föstu handriti metur fulltrúinn eigin framvindu. Ef bráðabirgðaniðurstaða lítur rangt út (t.d. ef hún hefur núll raðir vegna rangrar tengingar eða síu), rannsakar fulltrúinn hvað fór úrskeiðis, aðlagar nálgun sína og reynir aftur. Í gegnum þetta ferli heldur hann fullu samhengi og flytur lærdóminn áfram milli skrefa. Þetta lokaða, sjálflærandi ferli færir endurtekningar frá notandanum yfir í fulltrúann sjálfan, sem gerir kleift að ná hraðari niðurstöðum og stöðugt hágæða greiningum en handvirk verkflæði.

Fulltrúinn nær yfir allt greiningarvinnuflæðið: að uppgötva gögn, keyra SQL og birta glósubækur og skýrslur. Hann skilur innri þekkingu fyrirtækja, getur leitað á vefnum að utanaðkomandi upplýsingum og batnar með tímanum með reynslu og minni.

Hágæða svör reiða sig á ríkulegt, nákvæmt samhengi. Án samhengis geta jafnvel sterk líkön skilað röngum niðurstöðum, svo sem með því að vanmeta notendafjölda verulega eða misskilja innri hugtök.

Til að forðast þessar bilunarleiðir er fulltrúinn byggður á mörgum lögum af samhengi sem tengja hann við gögn OpenAI og stofnanalega þekkingu.

• Grunnur lýsigagna: Fulltrúinn treystir á skema lýsigagna (dálkaheiti og gagnagerðir) til að leiðbeina við SQL-skrif og notar töfluuppruna (t.d. tengsl milli uppstreymis- og niðurstreymistaflna) til að veita samhengi um hvernig mismunandi töflur tengjast.
• Ályktun fyrirspurna: Inntaka sögulegra fyrirspurna hjálpar fulltrúanum að skilja hvernig á að búa til eigin fyrirspurnir og hvaða töflur eru venjulega tengdar saman.

• Valdar lýsingar á töflum og dálkum sem sérfræðingar á sviðinu veita, sem fanga ásetning, merkingu, viðskiptalegt samhengi og þekkta fyrirvara sem ekki er auðvelt að álykta út frá skemum eða fyrri fyrirspurnum.

Lýsigögn ein og sér eru ekki nægjanleg. Til að greina töflur í sundur þarftu að skilja hvernig þær voru búnar til og hvaðan þær koma.

• Með því að draga fram skilgreiningu á töflu á kóðastigi, öðlast fulltrúinn dýpri skilning á því hvað gögnin í raun innihalda. 
  • Blæbrigði um hvað er geymt í töflunni og hvernig það er dregið af greiningarviðburði veita viðbótarupplýsingar. Til dæmis getur það veitt samhengi um sérstöðu gilda, hversu oft töflugögnin eru uppfærð, umfang gagnanna (t.d., ef taflan útilokar ákveðna reiti, þá hefur hún þetta nákvæmnisstig), o.s.frv.
• Þetta veitir aukið notkunarsamhengi með því að sýna hvernig taflan er notuð umfram SQL í Spark, Python og öðrum gagnakerfum.
• Þetta þýðir að fulltrúinn getur greint á milli taflna sem líta svipað út en eru ólíkar á mikilvægum atriðum. Til dæmis getur það sagt til um hvort tafla innihaldi eingöngu umferð frá fyrsta aðila ChatGPT. Þetta samhengi er einnig uppfært sjálfkrafa, svo það haldist nýtt án handvirks viðhalds.

• Fulltrúinn getur fengið aðgang að Slack, Google Docs og Notion, sem fanga mikilvægt samhengi fyrirtækisins, svo sem útgáfur, áreiðanleikaatvik, innri kóðanöfn og verkfæri, og staðlaðar skilgreiningar og útreikningsrökfræði fyrir lykilmælikvarða.
• Þessi skjöl eru tekin inn, felld inn og geymd með lýsigögnum og aðgangsheimildum. Endurheimtuþjónusta sér um aðgangsstýringu og skyndiminni á keyrslutíma, sem gerir fulltrúanum kleift að sækja þessar upplýsingar á skilvirkan og öruggan hátt.

• Þegar fulltrúinn fær leiðréttingar eða uppgötvar blæbrigði varðandi ákveðnar gagnaspurningar, getur hann vistað þennan lærdóm til næstu skipta, sem gerir honum kleift að bæta sig stöðugt með notendum sínum. 
  • Þess vegna byrja framtíðarsvör á nákvæmari grunnlínu í stað þess að rekast ítrekað á sömu vandamál.
  • Markmið minnisins er að varðveita og endurnýta óaugljósar leiðréttingar, síur og skorður sem eru nauðsynlegar fyrir réttleika gagna en erfitt er að álykta út frá öðrum lögum einum. 
  • Til dæmis, í einu tilviki vissi fulltrúinn ekki hvernig ætti að sía fyrir tiltekna greiningartilraun (það byggði á samsvörun við ákveðinn streng sem var skilgreindur í tilraunahliði). Minni skipti sköpum hér til að tryggja að það gæti síað rétt, í stað þess að reyna óskýrt að passa saman strengi.
• Þegar þú leiðréttir fulltrúann eða þegar hann lærir eitthvað af samtali ykkar mann hann biðja þig um að vista það minni fyrir næsta skipti. 
  • Notendur geta einnig búið til og breytt minni handvirkt.
  • Minni eru afmarkað á altæku sniði og persónulegu stigi, og verkfæri fulltrúa auðvelda breytingar á þeim.

• Þegar ekkert fyrra samhengi er til fyrir töflu eða þegar fyrirliggjandi upplýsingar eru úreltar getur fulltrúinn sent beinar fyrirspurnir til gagnageymslunnar til að skoða og spyrja töfluna beint. Þetta gerir því kleift að sannreyna skemu, skilja gögnin í rauntíma og bregðast við í samræmi við það.
• Fulltrúinn getur einnig átt samskipti við önnur kerfi Data Platform (metadata service, Airflow, Spark) eftir þörfum til að fá víðara gagnasamhengi sem er til staðar utan gagnageymslunnar.

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⁠(opnast í nýjum glugga) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(opnast í nýjum glugga) (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⁠(opnast í nýjum glugga) 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.