Унутар OpenAI-јевог интерног агента за податке

Подаци покрећу начин на који системи уче, производи се развијају и компаније доносе одлуке. Али брзо, тачно и у правом контексту доћи до одговора често је теже него што би требало да буде. Да бисмо то олакшали како OpenAI расте, направили смо сопственог прилагођеног интерног AI агента за податке који истражује и резонује над нашом платформом.

Наш агент је прилагођен интерни алат намењен само за унутрашњу употребу (није спољна понуда), направљен посебно око OpenAI-јевих података, дозвола и токова рада. Показујемо како смо га направили и користимо да бисмо приказали примере стварних, значајних начина на које AI може да подржи свакодневни рад у нашим тимовима. OpenAI алати које смо користили да га направимо и покрећемо (Codex, наш најпознатији модел GPT‑5, Evals API⁠(отвара се у новом прозору) и Embeddings API⁠(отвара се у новом прозору)) исти су алати које стављамо на располагање програмерима свуда.

Наш агент за податке омогућава запосленима да од питања до увида стигну за неколико минута, а не дана. То снижава праг за извлачење података и нијансиране анализе у свим функцијама, не само у нашем тиму за податке. Данас се тимови из инжењеринга, науке о подацима, припреме за излазак на тржиште, финансија и истраживања у OpenAI-ју ослањају на агента да одговори на важна питања о подацима. На пример, може да помогне да се одговори како проценити лансирања и разумети здравље пословања, све кроз интуитиван формат природног језика. Агент комбинује знање о табелама које покреће Codex са производним и организационим контекстом. Његов систем Меморије који непрекидно учи значи да се побољшава са сваким наредним кораком.

У овом тексту ћемо објаснити зашто нам је био потребан прилагођени AI агент за податке, шта његов контекст података обогаћен кодом и самостално учење чини толико корисним и које смо лекције успут научили.

OpenAI-јева платформа података служи за више од 3,5 хиљ. интерних корисника који раде у инжењерингу, производима и истраживању, обухватајући више од 600 петабајта података у 70 хиљ. скупова података. На тој скали, само проналажење праве табеле може бити један од најзахтевнијих делова анализе.

Како је један интерни корисник рекао:

„Имамо много табела које су прилично сличне, и трошим огромно време покушавајући да схватим по чему се разликују и коју да користим. Неке укључују одјављене кориснике, неке не. Неке имају поља која се преклапају; тешко је разазнати шта је шта.“

Чак и када су изабране исправне табеле, добијање тачних резултата може бити изазовно. Аналитичари морају да резонују о подацима у табелама и односима између табела како би осигурали да се трансформације и филтери правилно примењују. Уобичајени начини отказа — many-to-many спајања, грешке при протискивању филтера и необрађене null вредности — могу неприметно да учине резултате неважећим. На OpenAI-јевој скали, аналитичари не би требало да троше време на отклањање проблема са SQL семантиком или перформансама упита: њихов фокус треба да буде на дефинисању метрика, провери претпоставки и доношењу одлука заснованих на подацима.

Хајде да прођемо кроз то шта је наш агент, како прикупља контекст и како наставља сам да се побољшава.

Наш агент покреће GPT‑5.2 и осмишљен је да резонује над OpenAI-јевом платформом података. Доступан је свуда где запослени већ раде: као Slack агент, преко веб интерфејса, унутар IDE-ова, у Codex CLI-ју преко MCP-а⁠(отвара се у новом прозору) и директно у OpenAI-јевој интерној ChatGPT апликацији преко MCP конектора⁠(отвара се у новом прозору).

Корисници могу да постављају сложена, отворена питања која би обично захтевала више кругова ручног истраживања. Узмимо овај пример инструкције, који користи тест скуп података: „За вожње NYC таксија, који парови ZIP кодова од места преузимања до одредишта су најнепоузданији, са највећим јазом између типичног и најгорег времена путовања, и када долази до те варијабилности?“

Агент обавља анализу од почетка до краја, од разумевања питања до истраживања података, покретања упита и синтезе налаза.

Једна од супермоћи агента је начин на који резонује кроз проблеме. Уместо да прати фиксну скрипту, агент процењује сопствени напредак. Ако међурезултат делује погрешно (нпр. ако има нула редова због нетачног спајања или филтера), агент истражује шта је пошло наопако, прилагођава приступ и покушава поново. Током тог процеса задржава пун контекст и преноси научено између корака. Овај затворени процес самосталног учења пребацује итерацију са корисника на самог агента, омогућавајући брже резултате и доследно квалитетније анализе од ручних токова рада.

Агент покрива цео аналитички ток рада: откривање података, покретање SQL-а и објављивање свески и извештаја. Разуме интерно знање компаније, може да претражује веб ради спољних информација и временом се побољшава кроз научену употребу и Меморију.

Квалитетни одговори зависе од богатог, тачног контекста. Без контекста, чак и снажни модели могу да дају погрешне резултате, као што су драстично погрешне процене броја корисника или погрешно тумачење интерне терминологије.

Да бисмо избегли ове начине отказа, агент је изграђен око више слојева контекста који га утемељују у OpenAI-јевим подацима и институционалном знању.

• Утемељење у метаподацима: Агент се ослања на метаподатке шеме (називе колона и типове података) да би усмеравао писање SQL-а и користи линију порекла табела (нпр. односе узводних и низводних табела) да пружи контекст о томе како су различите табеле повезане.
• Закључивање из упита: Уношење историјских упита помаже агенту да разуме како да пише сопствене упите и које се табеле обично спајају.

• Курирани описи табела и колона које дају стручњаци за домен, хватајући намеру, семантику, пословно значење и позната ограничења која се не могу лако извести из шема или претходних упита.

Сами метаподаци нису довољни. Да бисте заиста разликовали табеле, потребно је да разумете како су настале и одакле потичу.

• Извођењем дефиниције табеле на нивоу кода, агент гради дубље разумевање онога што подаци заиста садрже. 
  • Нијансе о томе шта је ускладиштено у табели и како је изведено из аналитичког догађаја пружају додатне информације. На пример, могу да дају контекст о јединствености вредности, колико често се подаци у табели ажурирају, о обухвату података (нпр. ако табела искључује одређена поља, има овај ниво грануларности) итд.
• То пружа обогаћен контекст употребе показујући како се табела користи изван SQL-а у Spark-у, Python-у и другим системима података.
• То значи да агент може да разликује табеле које изгледају слично, али се критично разликују. На пример, може да утврди да ли табела укључује само first-party ChatGPT саобраћај. Овај контекст се такође аутоматски освежава, па остаје ажуран без ручног одржавања.

• Агент може да приступи Slack-у, Google Docs-у и Notion-у, који бележе критичан контекст компаније као што су лансирања, инциденти поузданости, интерни кодни називи и алати, као и канонске дефиниције и логика израчунавања кључних метрика.
• Ови документи се уносе, претварају у embeddings и чувају са метаподацима и дозволама. Сервис за проналажење управља контролом приступа и кеширањем у време извршавања, омогућавајући агенту да ову информацију ефикасно и безбедно прибави.

• Када агент добије исправке или открије нијансе у вези са одређеним питањима о подацима, може да сачува та сазнања за следећи пут, што му омогућава да се непрестано побољшава са својим корисницима. 
  • Као резултат тога, будући одговори почињу са тачније полазне основе уместо да се изнова сударају са истим проблемима.
  • Циљ Меморије је да задржи и поново употреби неочигледне исправке, филтере и ограничења који су кључни за исправност података, али их је тешко извести само из других слојева. 
  • На пример, у једном случају агент није знао како да филтрира одређени аналитички експеримент (ослањао се на поклапање са одређеним стрингом дефинисаним у капији експеримента). Меморија је овде била пресудно важна да би могао исправно да филтрира, уместо да нејасно покушава да упари стрингове.
• Када агенту дате исправку или када пронађе нешто што треба научити из вашег разговора, тражиће од вас да сачувате ту меморију за следећи пут. 
  • Корисници такође могу ручно да креирају и уређују меморије.
  • Меморије су обухваћене на глобалном и личном нивоу, а алати агента омогућавају лако уређивање.

• Када за неку табелу не постоји претходни контекст или када су постојеће информације застареле, агент може да изда live упите складишту података како би директно прегледао и испитао табелу. То му омогућава да потврди шеме, разуме податке у реалном времену и у складу с тим одговори.
• Агент такође по потреби може да разговара са другим системима Data Platform-а (сервис метаподатака, Airflow, Spark) да би добио шири контекст података који постоји изван складишта.

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⁠(отвара се у новом прозору) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(отвара се у новом прозору) (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⁠(отвара се у новом прозору) 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.