Внутренний агент данных OpenAI

Данные определяют, как обучаются системы, как развиваются продукты и как компании принимают решения. Но получать ответы быстро, правильно и в нужном контексте часто сложнее, чем должно быть. Чтобы упростить процесс по мере масштабирования OpenAI, мы разработали собственного уникального внутреннего ИИ-агента по работе с данными, который исследует и анализирует нашу собственную платформу.

Наш агент — это настраиваемый инструмент для внутреннего использования (не внешнее предложение), созданный специально на основе данных, разрешений и рабочих процессов OpenAI. Мы показываем, как мы создали и используем его, чтобы выявить примеры реальных и значимых способов, которыми ИИ может поддерживать повседневную работу в наших командах. Инструменты OpenAI, которые мы использовали для его создания и запуска (Codex, наша флагманская модель GPT‑5, Evals API⁠(открывается в новом окне) и Embeddings API⁠(открывается в новом окне)), — это те же инструменты, которые мы предоставляем разработчикам по всему миру.

Наш агент данных позволяет сотрудникам переходить от вопроса к инсайту не за дни, а за считанные минуты. Это снижает порог для извлечения данных и проведения детального анализа во всех функциях, а не только нашей командой аналитиков данных. Сегодня команды из отделов Engineering, Data Science, Go-To-Market, Finance и Research в OpenAI полагаются на агента, чтобы получать ответы на значимые вопросы по данным. Например, он может помочь ответить на вопрос, как оценивать запуски и понимать состояние бизнеса — всё это через интуитивно понятный формат естественного языка. Агент объединяет знания на уровне таблиц на базе Codex с контекстом продукта и организации. Его система памяти с непрерывным обучением означает, что она также постоянно улучшается.

В этом посте мы разберем, для чего нам понадобился отдельный ИИ-агент данных, что делает его контекст данных, обогащенный кодом, и самообучение такими полезными, а также какие уроки мы извлекли на этом пути.

Платформа данных OpenAI обслуживает более 3,5 тыс. внутренних пользователей , работающих в командах Engineering, Product и Research, и охватывает более 600 петабайт данных в 70 тыс. наборов данных. При таком размере нахождение нужной таблицы может быть одной из самых трудоёмких частей анализа.

Как выразился один из внутренних пользователей:

«У нас много довольно похожих таблиц, и я трачу уйму времени, пытаясь понять, чем они отличаются и какую из них использовать. Некоторые включают неавторизованных пользователей, некоторые — нет. У некоторых поля пересекаются... трудно определить, что к чему.»

Даже при выборе правильных таблиц получение правильных результатов может быть сложной задачей. Аналитики должны анализировать данные таблиц и их взаимосвязи, чтобы гарантировать правильное применение преобразований и фильтров. Распространенные режимы отказа — соединения «многие-ко-многим», ошибки фильтрации и необработанные значения null — могут незаметно сделать результаты недействительными. В масштабе OpenAI аналитики не должны тратить время на отладку семантики SQL или производительности запросов: их внимание должно быть сосредоточено на определении метрик, проверке гипотез и принятии решений на основе данных.

Давайте разберёмся, что из себя представляет наш агент, как он формирует контекст и как он продолжает самосовершенствоваться.

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

Пользователи могут задавать сложные, открытые вопросы, которые обычно требуют нескольких этапов ручного исследования. Возьмем этот пример промпта, в котором используется тестовый набор данных: «Для поездок на такси в Нью-Йорке, какие пары ZIP-кодов „место посадки — место высадки“ являются самыми ненадёжными, с наибольшим разрывом между типичным и наихудшим временем в пути, и когда возникает эта вариативность?»

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

Одна из суперспособностей агента — это его умение рассуждать при решении задач. Вместо того чтобы следовать фиксированному сценарию, агент оценивает свой прогресс. Если промежуточный результат выглядит неверным (например, если в нем ноль строк из-за некорректного соединения или фильтра), агент выясняет, что пошло не так, корректирует свой подход и пробует снова. На протяжении всего этого процесса сохраняется полный контекст, и наработки переносятся между шагами. Этот замкнутый, самообучающийся процесс переносит итерации от пользователя к самому агенту, что позволяет получать более быстрые результаты и стабильно более качественный анализ по сравнению с ручными рабочими процессами.

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

Высококачественные ответы зависят от полноты и точности контекста. Без контекста даже мощные модели могут давать неверные результаты — например, сильно ошибаться в оценке количества пользователей или неправильно интерпретировать внутреннюю терминологию.

Чтобы избежать таких сбоев, агент построен вокруг нескольких уровней контекста, которые связывают его с данными OpenAI и институциональными знаниями.

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

• Кураторские описания таблиц и столбцов, предоставленные экспертами в данной области, отражающие намерение, семантику, деловое значение и известные оговорки, которые трудно вывести из схем или предыдущих запросов.

Одних только метаданных недостаточно. Чтобы действительно различать таблицы, необходимо понимать, как они были созданы и откуда они происходят.

• Путем вывода определения таблицы на уровне кода агент формирует более глубокое понимание того, что на самом деле содержат данные. 
  • Нюансы того, что хранится в таблице и как это извлекается из аналитического события, предоставляют дополнительную информацию. Например, это может дать контекст об уникальности значений, о том, как часто обновляются данные таблицы, об охвате данных (например, если таблица исключает определённые поля, она имеет такой уровень детализации), и т. д.
• Это обеспечивает расширенный контекст использования, показывая, как таблица используется не только в SQL, но и в Spark, Python и других системах данных.
• Это означает, что агент может различать таблицы, которые выглядят похоже, но отличаются в критически важных аспектах. Например, он может определить, включает ли таблица только трафик первого уровня ChatGPT. Этот контекст также обновляется автоматически, поэтому он остается актуальным без необходимости ручного обслуживания.

• Агент может получить доступ к Slack, Google Docs и Notion, которые фиксируют критически важный контекст компании, такой как запуски, инциденты надежности, внутренние кодовые имена и инструменты, а также канонические определения и вычислительную логику для ключевых метрик.
• Эти документы загружаются, встраиваются и хранятся с метаданными и разрешениями. Служба извлечения управляет контролем доступа и кэшированием во время выполнения, что позволяет агенту эффективно и безопасно извлекать эту информацию.

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

• Когда для таблицы отсутствует предварительный контекст или имеющаяся информация устарела, агент может выполнять живые запросы к хранилищу данных, чтобы напрямую просматривать и запрашивать таблицу. Это позволяет проверять схемы, понимать данные в реальном времени и реагировать соответствующим образом.
• Агент также может при необходимости взаимодействовать с другими системами 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.