OpenAI-дің ішкі деректер агентінің ішкі жұмысы

Деректер жүйелердің қалай үйренетінін, өнімдердің қалай дамитынын және компаниялардың қалай шешім қабылдайтынын айқындайды. Бірақ жауапты жылдам, дұрыс және тиісті контекстпен алу көбіне қажеттіден қиынырақ. OpenAI ауқымданған сайын мұны жеңілдету үшін біз өзімізге арналған арнайы ішкі AI деректер агентін құрдық, ол өз платформамызды зерттеп, оның үстінен ой қорытады.

Біздің агент — арнайы тек ішкі қолдануға арналған құрал (сыртқы ұсыныс емес), OpenAI деректері, рұқсаттары және workflow-лары айналасында арнайы құрылған. Біз оны қалай құрып, қолданатынымызды көрсетіп отырмыз, себебі бұл AI-дың командамыздың күнделікті жұмысын нақты әрі әсерлі түрде қалай қолдай алатынына мысал береді. Оны құруға және іске қосуға пайдаланған OpenAI құралдары (Codex, біздің GPT‑5 негізгі моделіміз, Evals API⁠(жаңа терезеде ашылады) және Embeddings API⁠(жаңа терезеде ашылады)) — біз бүкіл әлемдегі әзірлеушілерге ұсынатын сол құралдардың өзі.

Біздің деректер агентіміз қызметкерлерге сұрақтан инсайтқа күндер емес, минуттар ішінде жетуге мүмкіндік береді. Бұл тек деректер командамызға емес, барлық функцияларға деректер мен нәзік талдауды алу шегін төмендетеді. Бүгінде OpenAI-дегі Инженерия, Data Science, Go-To-Market, Қаржы және Зерттеу командалары әсері жоғары деректер сұрақтарына жауап беру үшін агентке сүйенеді. Мысалы, ол табиғи тілдің интуитивті форматы арқылы іске қосуды бағалауға және бизнестің жай-күйін түсінуге көмектесе алады. Агент Codex-ке негізделген кесте деңгейіндегі білімді өнімдік және ұйымдық контекстпен біріктіреді. Оның үздіксіз үйренетін жад жүйесі әр turn сайын жақсара түсетінін білдіреді.

Бұл жазбада біз неге арнайы AI деректер агенті қажет болғанын, оның кодпен байытылған деректер контексті мен өзін-өзі үйретуінің неліктен соншалық пайдалы екенін және жолай қандай сабақ алғанымызды тарқатамыз.

OpenAI-дің деректер платформасы Инженерия, Өнім және Зерттеу бағыттарында жұмыс істейтін 3.5k-тан астам ішкі пайдаланушыға қызмет көрсетеді және 70k деректер жиынындағы 600 петабайттан астам деректерді қамтиды. Мұндай көлемде талдау жасаудың ең көп уақыт алатын бөліктерінің бірі — дұрыс кестені табудың өзі.

Ішкі пайдаланушылардың бірі айтқандай:

«Бізде бір-біріне едәуір ұқсас кестелер көп, мен олардың айырмасын және қайсысын қолдану керегін түсінуге көп уақытымды жұмсаймын. Кейбіріне жүйеге кірмеген пайдаланушылар кіреді, кейбіріне кірмейді. Кейбірінде қабаттасатын өрістер бар; ненің не екенін түсіну қиын».

Дұрыс кестелер таңдалғанның өзінде де, дұрыс нәтиже шығару қиын болуы мүмкін. Трансформациялар мен сүзгілердің дұрыс қолданылуын қамтамасыз ету үшін аналитиктер кесте деректері мен кестелер арасындағы байланыстар туралы ой қорытуы керек. Көптен-көп joins, filter pushdown қателері және өңделмеген null мәндер сияқты жиі кездесетін сәтсіздік түрлері нәтижелерді үнсіз жарамсыз ете алады. OpenAI ауқымында аналитиктер уақытын SQL семантикасын не сұрау өнімділігін жөндеуге емес, метрикаларды анықтауға, болжамдарды тексеруге және деректерге негізделген шешімдер қабылдауға жұмсауы керек.

Енді агентіміздің не екенін, оның контексті қалай іріктейтінін және өзін қалай үздіксіз жетілдіретінін бірге қарап шығайық.

Біздің агент GPT‑5.2 арқылы жұмыс істейді және OpenAI-дің деректер платформасы үстінен ой қорытуға арналған. Ол қызметкерлер онсыз да жұмыс істейтін жердің бәрінде қолжетімді: Slack агенті ретінде, веб-интерфейс арқылы, IDE ішінде, MCP арқылы Codex CLI-де⁠(жаңа терезеде ашылады) және тікелей MCP connector арқылы OpenAI-дің ішкі ChatGPT қолданбасында⁠(жаңа терезеде ашылады).

Пайдаланушылар әдетте қолмен бірнеше айналым зерттеуді қажет ететін күрделі, ашық сұрақтар қоя алады. Сынақ деректер жиынын пайдаланатын мына көмексөзді алайық: «NYC taxi сапарлары үшін әдеттегі және ең нашар жол жүру уақыты арасындағы алшақтық ең үлкен, ең сенімсіз pickup-to-dropoff ZIP жұптары қайсы және бұл құбылмалылық қашан болады?»

Агент талдауды басынан аяғына дейін атқарады: сұрақты түсінуден бастап, деректерді зерттеуге, сұрауларды іске қосуға және тұжырымдарды синтездеуге дейін.

Агенттің суперқабілеттерінің бірі — мәселелерді қалай ой қорытып шешетіні. Белгіленген сценарийге ермей, агент өзінің ілгерілеуін өзі бағалайды. Егер аралық нәтиже қате көрінсе (мысалы, қате join не filter салдарынан жолдар саны нөл болса), агент не дұрыс болмағанын тексеріп, тәсілін түзетіп, қайтадан байқап көреді. Осы процестің барысында ол толық контексті сақтап, learned нәрселерді қадамдар арасында алып жүреді. Бұл тұйық циклді, өзін-өзі үйрететін процесс итерацияны пайдаланушыдан агенттің өзіне ауыстырады, соның арқасында қолмен жасалатын workflow-ларға қарағанда жылдамырақ нәтижелер мен тұрақты түрде жоғары сапалы талдаулар береді.

Агент толық аналитика workflow-ын қамтиды: деректерді табу, SQL орындау және ноутбуктер мен есептерді жариялау. Ол компания ішіндегі білімді түсінеді, сыртқы ақпарат үшін вебтен іздей алады және learned usage пен жад арқылы уақыт өте жақсарады.

Жоғары сапалы жауаптар бай әрі дәл контекске тәуелді. Контекст болмаса, тіпті күшті модельдер де пайдаланушы санын қатты қате бағалау не ішкі терминологияны дұрыс түсінбеу сияқты қате нәтижелер бере алады.

Мұндай сәтсіздіктерді болдырмау үшін агент оны OpenAI деректері мен институционалдық біліміне негіздейтін бірнеше контекст қабатының айналасында құрылған.

• Metadata арқылы негіздеу: Агент SQL жазуға көмектесу үшін schema metadata-сына (баған атаулары мен деректер түрлері) сүйенеді және әртүрлі кестелердің қалай байланысатынына контекст беру үшін table lineage-ті (мысалы, upstream және downstream кесте қатынастары) қолданады.
• Сұраудан қорытынды шығару: Тарихи сұрауларды ingest ету агентке өз сұрауларын қалай жазу керегін және қандай кестелердің әдетте бірге join жасалатынын түсінуге көмектеседі.

• Схемалардан немесе өткен сұраулардан оңай шығарылмайтын ниетті, семантиканы, бизнес мағынаны және белгілі caveat-тарды қамтитын домен сарапшылары берген кестелер мен бағандардың мұқият дайындалған сипаттамалары.

Жалғыз metadata жеткіліксіз. Кестелерді шын мәнінде ажырату үшін олардың қалай жасалғанын және қайдан шыққанын түсіну керек.

• Кестенің код деңгейіндегі анықтамасын шығару арқылы агент деректердің шын мәнінде нені қамтитынын тереңірек түсінеді.
  • Кестеде нақты не сақталатыны және оның analytics event-тен қалай туындайтыны туралы нюанстар қосымша ақпарат береді. Мысалы, бұл мәндердің бірегейлігі, кесте деректерінің қаншалық жиі жаңартылатыны, деректер ауқымы туралы (мысалы, кесте кейбір өрістерді қамтымаса, түйіршіктілігі осындай болады) және т.б. контекст бере алады.
• Бұл кестенің SQL-ден тыс Spark, Python және басқа деректер жүйелерінде қалай қолданылатынын көрсету арқылы қолданылу контекстін кеңейтеді.
• Бұл агентке сырттай ұқсас көрінгенімен, маңызды айырмашылықтары бар кестелерді ажыратуға мүмкіндік береді. Мысалы, ол кестеде тек бірінші тарапқа тиесілі ChatGPT трафигі бар-жоғын ажырата алады. Бұл контекст автоматты түрде де жаңартылып отырады, сондықтан қолмен сүйемелдеусіз өзекті күйінде қалады.

• Агент Slack, Google Docs және Notion-ға қол жеткізе алады; олар іске қосудар, сенімділік инциденттері, ішкі код атаулары мен құралдар және негізгі метрикалардың канондық анықтамалары мен есептеу логикасы сияқты маңызды компаниялық контексті қамтиды.
• Бұл құжаттар ingest етіледі, embedding-терге айналдырылады және metadata мен рұқсаттармен бірге сақталады. Retrieval service орындалу кезінде рұқсатты басқару мен кэштеуді атқарады, соның арқасында агент бұл ақпаратты тиімді әрі қауіпсіз түрде тарта алады.

• Агентке түзетулер берілгенде немесе ол белгілі бір деректер сұрақтары туралы нюанстарды тапқанда, ол бұл learned нәрселерді келесі жолы үшін сақтай алады, осылайша пайдаланушыларымен бірге үнемі жақсарып отырады.
  • Нәтижесінде, болашақ жауаптар сол қателерге қайта-қайта тап болудың орнына, анағұрлым дәл бастапқы негізден басталады.
  • Жадтың мақсаты — деректердің дұрыстығы үшін маңызды, бірақ басқа қабаттардан ғана шығару қиын болатын айқын емес түзетулерді, сүзгілерді және шектеулерді сақтау және қайта пайдалану.
  • Мысалы, бір жағдайда агент белгілі бір аналитикалық экспериментке қалай filter қою керегін білмеді (ол experiment gate ішінде анықталған нақты жолға сәйкестендіруге сүйенді). Мұнда жад аса маңызды болды, себебі ол жолдарды жуықтап сәйкестендіруге тырысудың орнына, дұрыс filter қоя алуын қамтамасыз етті.
• Сіз агентке түзету бергенде немесе ол әңгімеңізден learned нәрсе тапқанда, оны келесі жолы үшін жадқа сақтауды ұсынады.
  • Жад жазбаларын пайдаланушылар қолмен де жасап, өңдей алады.
  • Жадтар жаһандық және жеке деңгейде scope етіледі, ал агенттің құралдары оларды өңдеуді жеңілдетеді.

• Кесте үшін алдын ала контекст болмағанда немесе бар ақпарат ескіргенде, агент кестені тікелей тексеру және сұрау үшін деректер қоймасына тікелей сұраулар жібере алады. Бұл оған схемаларды тексеруге, деректерді нақты уақытта түсінуге және соған сәйкес жауап беруге мүмкіндік береді.
• Агент қоймадан тыс бар кеңірек деректер контекстін алу үшін қажетіне қарай басқа Data Platform жүйелерімен де (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.