Wewnętrzny agent danych OpenAI od środka

Dane wpływają na sposób uczenia się systemów, ewolucję produktów i podejmowanie decyzji przez firmy. Jednak uzyskanie szybkich, poprawnych odpowiedzi w odpowiednim kontekście jest często trudniejsze, niż powinno. Aby ułatwić to zadanie w miarę rozwoju działalności OpenAI, stworzyliśmy własnego, dostosowanego do naszych potrzeb wewnętrznego agenta danych AI, który bada i analizuje naszą platformę.

Nasz agent jest niestandardowym narzędziem przeznaczonym wyłącznie do użytku wewnętrznego (nie jest to oferta zewnętrzna), stworzonym specjalnie z myślą o danych, uprawnieniach i przepływach pracy OpenAI. Przedstawiamy, w jaki sposób stworzyliśmy to narzędzie, a także jak je wykorzystujemy, aby zaprezentować przykłady rzeczywistych, znaczących sposobów, w jakie sztuczna inteligencja może wspierać codzienną pracę naszych zespołów. Narzędzia OpenAI, których użyliśmy do jego stworzenia i uruchomienia (Codex, nasz model podstawowy GPT‑5, Evals API⁠(otwiera nowe okno) oraz Embeddings API⁠(otwiera nowe okno)) to te same narzędzia, które udostępniamy programistom na całym świecie.

Nasz agent danych pozwala pracownikom skrócić czas potrzebny na uzyskanie odpowiedzi na pytanie z kilku dni do kilku minut. Zmniejsza to bariery w pozyskiwaniu danych i przeprowadzaniu szczegółowych analiz we wszystkich funkcjach, nie tylko przez nasz zespół ds. danych. Obecnie zespoły z działów inżynierii, nauki o danych, strategii prowadzenia na rynek, finansów i badań w OpenAI korzystają z agenta, aby uzyskać odpowiedzi na ważne pytania dotyczące danych. Na przykład może pomóc odpowiedzieć na pytanie, jak oceniać wprowadzenia produktów na rynek i zrozumieć kondycję firmy, a wszystko to dzięki intuicyjnemu formatowi w języku naturalnym. Agent łączy wiedzę na poziomie tabel opartą na modelu Codex z kontekstem produktowym i organizacyjnym. Jego system pamięci oparty na ciągłym uczeniu się oznacza, że z każdą turą staje się coraz lepszy.

W tym wpisie wyjaśnimy, dlaczego potrzebowaliśmy niestandardowego agenta danych AI, co sprawia, że jego wzbogacony kodem kontekst danych i zdolność do samodzielnej nauki są tak przydatne, a także podzielimy się wnioskami, jakie wyciągnęliśmy podczas pracy nad tym projektem.

Platforma danych OpenAI obsługuje ponad 3,5 tys. użytkowników wewnętrznych pracujących w działach inżynierii, produktów i badań, obejmując ponad 600 petabajtów danych w 70 tys. zestawach danych. Przy takiej skali znalezienie odpowiedniej tabeli może być jednym z najbardziej czasochłonnych elementów analizy.

Jeden z użytkowników wewnętrznych ujął to w następujący sposób:

„Mamy wiele dość zbliżonych do siebie tabel i spędzam mnóstwo czasu, próbując zrozumieć, czym się różnią i której z nich użyć. Niektóre uwzględniają użytkowników, którzy się wylogowali, inne nie. Niektóre z nich mają pokrywające się obszary działania. Trudno jest rozróżnić, która jest która”.

Nawet po wybraniu właściwych tabel uzyskanie prawidłowych wyników może okazać się wyzwaniem. Analitycy muszą analizować dane tabelaryczne i relacje między tabelami, aby zapewnić prawidłowe stosowanie transformacji i filtrów. Typowe przyczyny awarii – połączenia wiele-do-wielu, błędy przesyłania filtrów i nieobsługiwane wartości null – mogą w dyskretny sposób podważać wyniki. Przy skali działalności OpenAI analitycy nie powinni tracić czasu na debugowanie semantyki SQL lub wydajności zapytań – powinni skupić się na definiowaniu wskaźników, weryfikowaniu założeń i podejmowaniu decyzji opartych na danych.

Przyjrzyjmy się, czym jest nasz agent, w jaki sposób selekcjonuje kontekst, a także w jaki sposób samoczynnie się doskonali.

Nasz agent bazuje na modelu GPT‑5.2 i został zaprojektowany do analizy danych na platformie OpenAI. Jest dostępny wszędzie tam, gdzie pracują już pracownicy: jako agent Slack, poprzez interfejs internetowy, w środowiskach IDE, w Codex CLI poprzez MCP⁠(otwiera nowe okno) oraz bezpośrednio w wewnętrznej aplikacji ChatGPT firmy OpenAI poprzez łącznik MCP⁠(otwiera nowe okno).

Użytkownicy mogą zadawać złożone pytania otwarte, które zazwyczaj wymagałyby wielu tur ręcznej eksploracji. Weźmy na przykład poniższe pytanie, które wykorzystuje zestaw danych testowych: „W przypadku przejazdów taksówką w Nowym Jorku, które pary kodów pocztowych miejsc odbioru i wysiadania są najbardziej niepewne, charakteryzują się największą różnicą między typowym a najgorszym czasem przejazdu i kiedy występuje ta zmienność?”

Agent zajmuje się analizą od początku do końca, od zrozumienia pytania po analizę danych, przeprowadzanie zapytań i syntezę wyników.

Jedną z nadzwyczajnych cech agenta jest sposób, w jaki analizuje problemy. Zamiast postępować zgodnie z ustalonym scenariuszem agent ocenia własne postępy. Jeśli wynik pośredni wydaje się nieprawidłowy (np. zawiera zero wierszy z powodu nieprawidłowego połączenia lub filtrowania), agent bada, co poszło nie tak, dostosowuje swoje podejście i próbuje ponownie. W trakcie całego procesu zachowuje pełny kontekst i przenosi zdobytą wiedzę między poszczególnymi etapami. Ten proces samodzielnej nauki o zamkniętej pętli przesuwa iterację z użytkownika na samego agenta, umożliwiając uzyskanie szybszych wyników i konsekwentnie wyższej jakości analiz niż w przypadku ręcznych przepływów pracy.

Agent obejmuje cały proces analityczny: wyszukiwanie danych, uruchamianie SQL oraz publikowanie notatników i raportów. Posiada wiedzę wewnętrzną firmy, potrafi wyszukiwać informacje zewnętrzne w Internecie i z czasem doskonali się dzięki nauczonemu wykorzystaniu i pamięci.

Wysokiej jakości odpowiedzi zależą od bogatego i dokładnego kontekstu. Bez kontekstu nawet zaawansowane modele mogą generować błędne wyniki, takie jak znaczne zaniżanie liczby użytkowników lub błędna interpretacja wewnętrznej terminologii.

Aby uniknąć tych rodzajów błędów, agent został zbudowany w oparciu o wiele warstw kontekstu, które opierają się na danych i wiedzy instytucjonalnej OpenAI.

• Ugruntowanie metadanych: agent bazuje się na metadanych schematu (nazwach kolumn i typach danych) w celu informowania o pisaniu kodu SQL i wykorzystuje pochodzenie tabeli (np. relacje między tabelami upstream i downstream), aby zapewnić kontekst dotyczący powiązań między różnymi tabelami.
• Wnioskowanie z zapytań: pozyskiwanie danych z historycznych zapytań pomaga agentowi zrozumieć, jak tworzyć własne zapytania oraz które tabele są zazwyczaj ze sobą łączone.

• Wyselekcjonowane opisy tabel i kolumn dostarczone przez ekspertów z danej dziedziny, uwzględniające intencje, semantykę, znaczenie biznesowe oraz znane zastrzeżenia, których nie da się łatwo wywnioskować ze schematów lub poprzednich zapytań.

Same metadane już nie wystarczają. Aby faktycznie odróżnić tabele, należy zrozumieć, w jaki sposób zostały one utworzone i skąd pochodzą.

• Wyprowadzając definicję tabeli na poziomie kodu, agent buduje głębsze zrozumienie tego, co faktycznie zawierają dane. 
  • Niuanse dotyczące zawartości tabeli i sposobu jej uzyskania na podstawie zdarzenia analitycznego dostarczają dodatkowych informacji. Na przykład może to dostarczyć informacji na temat unikatowości wartości, częstotliwości aktualizacji danych w tabeli, zakresu danych (np. jeśli tabela nie zawiera niektórych pól, ma taki poziom szczegółowości) itp.
• Zapewnia to lepszy kontekst użytkowania, pokazując, w jaki sposób tabela jest wykorzystywana poza SQL w Spark, Python i innych systemach danych.
• Oznacza to, że agent może rozróżniać tabele, które wyglądają podobnie, ale różnią się pod względem istotnych cech. Na przykład może stwierdzić, czy tabela zawiera wyłącznie ruch pochodzący bezpośrednio od ChatGPT. Kontekst ten jest również automatycznie odświeżany, dzięki czemu pozostaje aktualny bez konieczności ręcznej konserwacji.

• Agent ma dostęp do platform Slack, Dokumenty Google i Notion, które rejestrują kluczowe informacje dotyczące firmy, takie jak premiery produktów, incydenty związane z niezawodnością, wewnętrzne nazwy kodowe i narzędzia oraz oficjalne definicje i logika obliczeniowa kluczowych wskaźników.
• Dokumenty te są pozyskiwane, osadzane i przechowywane wraz z metadanymi i uprawnieniami. Usługa pobierania danych obsługuje kontrolę dostępu i buforowanie w czasie wykonywania, umożliwiając agentowi wydajne i bezpieczne pobieranie tych informacji.

• Gdy agent otrzymuje poprawki lub odkrywa niuanse dotyczące pewnych pytań związanych z danymi, może zapisać te informacje na przyszłość, co pozwala mu stale doskonalić się wraz z użytkownikami. 
  • W rezultacie przyszłe odpowiedzi będą opierać się na dokładniejszej podstawie zamiast powtarzać te same problemy.
  • Celem pamięci jest zachowanie i ponowne wykorzystanie nieoczywistych poprawek, filtrów i ograniczeń, które mają kluczowe znaczenie dla poprawności danych, ale są trudne do wywnioskowania wyłącznie na podstawie innych warstw. 
  • Na przykład w jednym przypadku agent nie wiedział, jak filtrować dane dla konkretnego eksperymentu analitycznego (opierał się na dopasowaniu do określonego ciągu znaków zdefiniowanego w bramce eksperymentu). Pamięć miała tu kluczowe znaczenie dla zapewnienia prawidłowego filtrowania, aby uniknąć nieprecyzyjnego dopasowywania ciągów znaków.
• Kiedy wprowadzisz poprawkę lub agent wykryje coś, czego nauczył się z Twojej rozmowy, wyświetli się komunikat dotyczący zapisania tej informacji na przyszłość. 
  • Użytkownicy mogą również ręcznie tworzyć i edytować wspomnienia.
  • Wspomnienia mają zasięg globalny i osobisty, a narzędzia agenta ułatwiają ich edytowanie.

• W przypadku braku wcześniejszego kontekstu dla tabeli lub gdy istniejące informacje są nieaktualne, agent może wysyłać zapytania na żywo do magazynu danych w celu bezpośredniego sprawdzenia i przeszukania tabeli. Umożliwia to weryfikację schematów, zrozumienie danych w czasie rzeczywistym oraz odpowiednią reakcję.
• Agent może również komunikować się z innymi systemami platformy danych (usługa metadanych, Airflow, Spark) w razie potrzeby, aby uzyskać szerszy kontekst danych istniejący poza magazynem.

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⁠(otwiera nowe okno) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(otwiera nowe okno) (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⁠(otwiera nowe okno) 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.