Поглед отвътре на собствения агент за данни на OpenAI

Данните задвижват начина, по който системите се учат, продуктите се развиват и компаниите правят избори. Но получаването на отговори бързо, правилно и с подходящия контекст често е по-трудно, отколкото би трябвало. За да улесним това, докато OpenAI се разраства, създадохме собствен персонализиран вътрешен ИИ агент за данни, който изследва и разсъждава върху нашата собствена платформа.

Нашият агент е персонализиран инструмент само за вътрешна употреба (не е външно използване), създаден специално около данните, разрешенията и работните процеси на OpenAI. Показваме как го създадохме и го използваме, за да изведем на преден план примери за реалните, значими начини, по които ИИ може да подпомага ежедневната работа в нашите екипи. Инструментите на OpenAI, които използвахме, за да го изградим и стартираме (Codex, нашият водещ модел GPT‑5, Evals API⁠(отваря се в нов прозорец) и Embeddings API⁠(отваря се в нов прозорец)), са същите инструменти, които предоставяме на разработчиците навсякъде по света.

Нашият агент позволява на служителите да преминат от въпрос към анализ за минути, а не за дни. Това понижава прага за извличане на данни и детайлен анализ във всички функции, а не само от нашия екип по данни. Днес екипи от Инженеринг, Наука за данни, Пускане на пазара, Финанси и Изследвания в OpenAI разчитат на агента, за да отговаря на въпроси с данни с голямо въздействие. Например той може да помогне да се отговори на въпроса как да се оценят пусканията на продукти и да се разбере състоянието на бизнеса, всичко това чрез интуитивния формат на естествения език. Агентът комбинира знания на ниво таблица, задвижвани от Codex, с контекста на продукта и организацията. Непрекъснато обучаващата се система за памет означава, че тя се подобрява с всяко следващо запитване.

В тази публикация ще обясним защо ни беше необходим персонализиран ИИ агент за данни, какво прави неговия обогатен с код контекст на данните и самообучението му толкова полезни, и какви уроци научихме по пътя.

Платформата за данни на OpenAI обслужва повече от 3,5 хил. вътрешни потребители , работещи в областите на инженеринга, продуктите и изследванията, и обхваща над 600 петабайта данни в 70 хил. набора от данни. При такъв размер самото намиране на правилната таблица може да бъде една от най-времеемките части от извършването на анализ.

Както се изрази един вътрешен потребител:

„Имаме много таблици, които са доста сходни и аз прекарвам много време в опити да разбера по какво се различават и кои да използвам. Някои от тях включват излезли от системата потребители, а други - не. Някои от тях имат припокриващи се полета и е трудно да се определи коя за какво е.“

Дори когато са избрани правилните таблици, получаването на коректни резултати може да бъде предизвикателство. Анализаторите трябва да разсъждават върху данните в таблиците и връзките между тях, за да гарантират, че трансформациите и филтрите се прилагат правилно. Често срещани режими на грешка — обединения „много към много“, грешки при прилагане на филтри и необработени нули — могат да доведат до невалидност на резултатите. В мащаба на OpenAI анализаторите не трябва да губят време в отстраняване на грешки в семантиката на SQL или производителността на заявките: фокусът им трябва да бъде върху дефинирането на показатели, валидирането на предположения и вземането на решения, базирани на данни.

Нека разгледаме какво представлява нашият агент, как подбира контекста и как продължава да се самоусъвършенства.

Нашият агент се захранва от GPT‑5.2 и е проектиран да разсъждава върху платформата за данни на OpenAI. Наличен е навсякъде, където служителите вече работят: като агент в Slack, чрез уеб интерфейс, в интегрирани среди за разработка (IDE), в Codex CLI чрез MCP⁠(отваря се в нов прозорец) и директно във вътрешното приложение ChatGPT на OpenAI чрез MCP конектор⁠(отваря се в нов прозорец).

Потребителите могат да задават сложни, отворени въпроси, които обикновено биха изисквали няколко кръга на ръчно проучване. Вземете този пример за подкана, който използва набор от тестови данни: „За пътуванията с такси в Ню Йорк кои двойки пощенски кодове за вземане и оставяне са най-ненадеждни, с най-голямата разлика между типичните и най-лошите времена за пътуване и кога се проявява тази променливост?“

Агентът извършва анализа от край до край, от разбирането на въпроса до проучването на данните, изпълнението на заявки и обобщаването на резултати.

Една от суперсилите на агента е способността му да разсъждава върху проблемите. Вместо да следва фиксиран сценарий, агентът оценява собствения си напредък. Ако междинен резултат изглежда неправилен (например, ако има нула реда поради неправилно обединение или филтър), агентът проверява какво се е объркало, коригира подхода си и опитва отново. През целия този процес се запазва пълният контекст и наученото се пренася напред между отделните стъпки. Този затворен цикъл, самообучаващ се процес прехвърля итерацията от потребителя към самия агент, като позволява по-бързи резултати и последователно по-висококачествени анализи в сравнение с ръчните работни процеси.

Агентът обхваща целия аналитичен работен процес: откриване на данни, изпълнение на SQL и публикуване на бележници и отчети. Той разбира вътрешните знания на компанията, може да търси външна информация в интернет и се усъвършенства с времето чрез натрупания опит и памет.

Високото качество на отговорите зависи от богатия и точен контекст. Без контекст дори мощни модели могат да дадат неправилни резултати, като например значително да подценят броя на потребителите или да тълкуват неправилно вътрешната терминология.

За да се избегнат тези грешки, агентът е изграден на базата на няколко слоя контекст, които го свързват с данните и институционалните знания на OpenAI.

• Основаване на метаданни: Агентът разчита на метаданни за схемата (имена на колони и типове данни), за да насочва писането на SQL, и използва произхода на таблиците (напр. връзки между таблиците нагоре и надолу по веригата), за да предостави контекст за това как различните таблици са свързани.
• Изводи от заявки: Приемането на минали заявки помага на агента да разбере как да съставя свои собствени заявки и кои таблици обикновено се обединяват.

• Подбрани описания на таблици и колони, предоставени от експерти в съответната област, които улавят намерението, семантиката, значението за бизнеса и известни предупреждения, които не могат лесно да бъдат изведени от схеми или предишни заявки.

Само метаданните не са достатъчни. За да различите наистина таблиците, трябва да разберете как са създадени и откъде произхождат.

• Чрез извеждане на дефиниция на таблица на ниво код, агентът изгражда по-задълбочено разбиране за това какво всъщност съдържат данните. 
  • Нюансите относно това какво се съхранява в таблицата и как се извлича от дадено аналитично събитие предоставят допълнителна информация. Например може да предостави контекст относно уникалността на стойностите, честотата на актуализиране на данните в таблицата, обхвата на данните (напр., ако таблицата изключва определени полета, тя има това ниво на детайлност) и т.н.
• Това предоставя разширен контекст на използване, като показва как таблицата се използва не само в SQL, но и в Spark, Python и други системи за данни.
• Това означава, че агентът може да различава таблици, които изглеждат подобни, но се различават по съществени начини. Например може да определи дали дадена таблица включва само трафик от първа страна на ChatGPT. Този контекст също се обновява автоматично, така че остава актуален без необходимост от ръчна поддръжка.

• Агентът може да има достъп до Slack, Google Docs и Notion, които събират важен контекст за компанията, като пускания на пазара, инциденти с надеждността, вътрешни кодови имена и инструменти, както и каноничните дефиниции и изчислителната логика за ключови показатели.
• Тези документи се приемат, вграждат и съхраняват с метаданни и права за достъп. Услуга за извличане управлява контрола на достъпа и кеширането по време на изпълнение, като позволява на агента ефективно и безопасно да извлича тази информация.

• Когато агентът получи корекции или открие нюанси в определени въпроси, свързани с данни, той може да запази тези знания за следващия път, което му позволява постоянно да се усъвършенства заедно с потребителите. 
  • В резултат на това бъдещите отговори ще започнат от по-точна изходна точка, а не от многократни сблъсъци с едни и същи проблеми.
  • Целта на паметта е да запазва и използва повторно неочевидни корекции, филтри и ограничения, които са критични за коректността на данните, но е трудно да се изведат само от другите слоеве. 
  • Например в един случай агентът не знаеше как да филтрира за конкретен аналитичен експеримент (разчиташе на съпоставяне с конкретен низ, дефиниран в експериментален гейт). Паметта беше от решаващо значение тук, за да се гарантира, че може да филтрира правилно, вместо да се опитва неясно да съпоставя низове.
• Когато дадете на агента корекция или когато той открие нещо научено от разговора Ви, той ще Ви подкани да запазите тази информация за следващия път. 
  • Спомените могат също да бъдат създавани и редактирани ръчно от потребителите.
  • Спомените са обхванати на глобално и лично ниво, а инструментите на агента улесняват тяхното редактиране.

• Когато няма предишен контекст за таблица или когато съществуващата информация е остаряла, агентът може да изпраща заявки в реално време към хранилището за данни, за да проверява и директно да направи заявки към таблицата. Това позволява да се валидират схеми, да се разбират данните в реално време и да се реагира съответно.
• Агентът също така може да комуникира с други системи на Платформата за данни (metadata service, 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.