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-ի միջոցով⁠(բացվում է նոր պատուհանում), և անմիջապես OpenAI-ի ներքին ChatGPT հավելվածում՝ MCP միակցիչի միջոցով⁠(բացվում է նոր պատուհանում)։

Օգտատերերը կարող են տալ բարդ, բաց հարցեր, որոնք սովորաբար կպահանջեն ձեռքով ուսումնասիրության մի քանի փուլեր։ Վերցրեք այս օրինակ հարցումը, որը օգտագործում է թեստային տվյալների հավաքածու. «NYC տաքսու ուղևորությունների համար, ո՞ր վերցման-մինչև-իջեցման ZIP զույգերն են ամենաանվստահելի՝ սովորական և վատագույն դեպքի ճանապարհորդության ժամանակների միջև ամենամեծ տարբերությամբ, և ե՞րբ է այդ փոփոխականությունը տեղի ունենում»

Ագենտը իրականացնում է վերլուծությունը ամբողջությամբ՝ սկզբից մինչև վերջ, սկսած հարցը հասկանալուց մինչև տվյալների ուսումնասիրումը, հարցումների կատարումը և արդյունքների սինթեզը։

Ագենտի գերհզորություններից մեկն այն է, թե ինչպես է այն լուծում խնդիրները։ Ֆիքսված սցենարին հետևելու փոխարեն, ագենտը գնահատում է իր առաջընթացը։ Եթե միջանկյալ արդյունքը սխալ է թվում (օրինակ՝ եթե այն ունի զրո տող՝ սխալ միացման կամ ֆիլտրի պատճառով), ապա ագենտը ուսումնասիրում է, թե ինչն է սխալ գնացել, ճշգրտում է իր մոտեցումը և կրկին փորձում է։ Այս գործընթացի ընթացքում այն պահպանում է ամբողջական համատեքստը և քայլերի միջև փոխանցում է ձեռք բերված գիտելիքները՝ ապահովելով շարունակականություն։ Այս փակ ցիկլով, ինքնուսուցման գործընթացը իտերացիան օգտատիրոջից տեղափոխում է հենց ագենտի մեջ՝ հնարավորություն տալով ավելի արագ արդյունքների և ձեռքով աշխատանքային հոսքերից հետևողականորեն ավելի բարձրորակ վերլուծությունների։

Ագենտը ընդգրկում է վերլուծական աշխատանքային գործընթացի ամբողջական հոսքը՝ տվյալների հայտնաբերում, SQL-ի գործարկում և նոթբուքերի ու հաշվետվությունների հրապարակում։ Այն ըմբռնում է ընկերության ներքին գիտելիքները, կարող է արտաքին տեղեկատվության համար վեբ որոնում կատարել և ժամանակի ընթացքում բարելավվում է՝ սովորած օգտագործման և հիշողության շնորհիվ։

Բարձրորակ պատասխանները կախված են հարուստ և ճշգրիտ համատեքստից։ Առանց համատեքստի, նույնիսկ հզոր մոդելները կարող են սխալ արդյունքներ տալ, օրինակ՝ զգալիորեն սխալ գնահատել օգտատերերի քանակը կամ սխալ մեկնաբանել ներքին տերմինաբանությունը։

Այս խափանման ռեժիմներից խուսափելու համար ագենտը կառուցված է համատեքստի բազմաթիվ շերտերի շուրջ, որոնք այն հիմնավորում են OpenAI-ի տվյալների և ինստիտուցիոնալ գիտելիքների վրա։

• Մետատվյալների հիմնավորումÉ Ագենտը հիմնվում է սխեմայի մետատվյալների վրա (սյունակների անուններ և տվյալների տեսակներ)՝ SQL գրելու համար և օգտագործում է աղյուսակների ծագումնաբանությունը (օրինակ՝ վերին և ստորին հոսքի աղյուսակների հարաբերությունները)՝ համատեքստ տրամադրելու համար, թե ինչպես են տարբեր աղյուսակները փոխկապակցված։
• Հարցման եզրակացություն: Պատմական հարցումների ներմուծումը օգնում է ագենտին հասկանալ, թե ինչպես կազմել իր սեփական հարցումները և որոնք են այն աղյուսակները, որոնք սովորաբար միացվում են։

• Խնամքով ընտրված նկարագրություններ աղյուսակների և սյունակների, որոնք տրամադրվում են ոլորտային փորձագետների կողմից՝ արտացոլելով մտադրությունը, սեմանտիկան, բիզնեսային նշանակությունը և հայտնի զգուշացումները, որոնք հեշտ չէ ենթադրել սխեմաներից կամ նախորդ հարցումներից։

Մետատվյալները միայնակ բավարար չեն։ Աղյուսակները տարբերակելու համար անհրաժեշտ է հասկանալ, թե ինչպես են դրանք ստեղծվել և որտեղից են ծագում։

• Աղյուսակի կոդային մակարդակի սահմանումից ածանցելով՝ ագենտը ձևավորում է ավելի խորը ըմբռնում այն մասին, թե տվյալները իրականում ինչ են պարունակում։ 
  • Աղյուսակում պահվող տվյալների և դրանց ստացման եղանակի նրբերանգները վերլուծական իրադարձությունից լրացուցիչ տեղեկություն են տալիս։ Օրինակ՝ այն կարող է համատեքստ տրամադրել արժեքների եզակիության, թե որքան հաճախ են աղյուսակի տվյալները թարմացվում, տվյալների շրջանակի վերաբերյալ (օրինակ՝ եթե աղյուսակը բացառում է որոշ դաշտեր, այն ունի մանրամասնության այս մակարդակը) և այլն։
• Սա ապահովում է օգտագործման ընդլայնված համատեքստ՝ ցույց տալով, թե ինչպես է աղյուսակը կիրառվում SQL-ից դուրս՝ Spark-ում, Python-ում և այլ տվյալների համակարգերում։
• Սա նշանակում է, որ ագենտը կարող է տարբերակել աղյուսակները, որոնք արտաքինից նման են, բայց կարևոր առումներով տարբերվում են։ Օրինակ՝ այն կարող է պարզել՝ արդյոք աղյուսակը ներառում է միայն առաջին կողմի ChatGPT‑ի տրաֆիկը։ Այս համատեքստը նույնպես ավտոմատ կերպով թարմացվում է, ուստի այն մնում է արդիական՝ առանց ձեռքով սպասարկման։

• Ագենտը կարող է մուտք գործել Slack, Google Docs և Notion, որոնք ամրագրում են ընկերության կարևոր համատեքստը, ինչպիսիք են թողարկումները, հուսալիության միջադեպերը, ներքին կոդային անվանումներն ու գործիքները, ինչպես նաև հիմնական չափորոշիչների կանոնական սահմանումները և հաշվարկման տրամաբանությունը։
• Այս փաստաթղթերը ներմուծվում են, ներդրվում և պահվում մետատվյալներով և թույլտվություններով։ Տեղեկատվության ստացման ծառայությունը գործարկման ժամանակ կառավարում է մուտքի վերահսկողությունն ու քեշավորումը՝ հնարավորություն տալով ագենտին արդյունավետ և անվտանգ կերպով ներգրավել այս տվյալները։

• Երբ ագենտին տրվում են ուղղումներ կամ նա բացահայտում է որոշ տվյալների հարցերի նրբերանգներ, նա կարողանում է պահպանել այս սովորածը հաջորդ անգամի համար՝ թույլ տալով, որ նա մշտապես բարելավվի իր օգտատերերի հետ։ 
  • Արդյունքում, ապագա պատասխանները սկսվում են ավելի ճշգրիտ հիմքից՝ նույն խնդիրներին կրկին բախվելու փոխարեն։
  • Հիշողության նպատակը ոչ ակնհայտ ուղղումները, ֆիլտրերը և սահմանափակումները պահպանելն ու վերօգտագործելն է, որոնք կարևոր են տվյալների ճշգրտության համար, սակայն դժվար է դրանք եզրակացնել միայն մյուս շերտերից։ 
  • Օրինակ՝ մեկ դեպքում ագենտը չգիտեր, թե ինչպես ֆիլտրել որոշակի վերլուծական փորձարկման համար (այն հիմնվում էր փորձարկման դարպասում սահմանված կոնկրետ տողի հետ համընկնումը գտնելու վրա)։ Հիշողությունը այստեղ չափազանց կարևոր էր՝ ապահովելու համար, որ այն կարողանա ճիշտ զտել՝ առանց մշուշոտ կերպով տողային համընկնումներ փնտրելու։
• Երբ դուք ուղղում եք տալիս ագենտին կամ երբ այն ձեր խոսակցությունից ինչ-որ բան է սովորում, այն կհուշի ձեզ պահպանել այդ հիշողությունը հաջորդ անգամի համար։ 
  • Հիշողությունները կարող են նաև օգտատերերի կողմից ձեռքով ստեղծվել և խմբագրվել։
  • Հիշողությունները սահմանվում են համաշխարհային և անձնական մակարդակներում, և ագենտի գործիքակազմը հեշտացնում է դրանց խմբագրումը։

• Երբ աղյուսակի համար նախնական համատեքստ չկա կամ առկա տեղեկատվությունը հնացած է, ագենտը կարող է ուղարկել կենդանի հարցումներ տվյալների պահեստարան՝ անմիջապես ստուգելու և հարցումներ կատարելու համար։ Սա թույլ է տալիս վավերացնել սխեմաները, իրական ժամանակում հասկանալ տվյալները և համապատասխանաբար արձագանքել։
• Գործակալը նաև կարող է կապ հաստատել այլ տվյալների հարթակի համակարգերի հետ (մետատվյալների ծառայություն, 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.