OpenAI-ის შიდა მონაცემთა აგენტის შიგნით

მონაცემები განსაზღვრავს, როგორ სწავლობენ სისტემები, როგორ ვითარდება პროდუქტები და როგორ იღებენ კომპანიები გადაწყვეტილებებს. მაგრამ პასუხების სწრაფად, სწორად და შესაბამისი კონტექსტით მიღება ხშირად იმაზე რთულია, ვიდრე უნდა იყოს. ამის გასამარტივებლად, OpenAI-ის ზრდასთან ერთად, ჩვენ შევქმენით ჩვენივე უნიკალური შიდა AI მონაცემთა აგენტი, რომელიც იკვლევს და მსჯელობს ჩვენსავე პლატფორმაზე.

ჩვენი აგენტი არის შიდა, მორგებული ინსტრუმენტი მხოლოდ შიდა გამოყენებისთვის (არა გარე შეთავაზება), რომელიც სპეციალურად OpenAI-ის მონაცემებზე, ნებართვებსა და სამუშაო ნაკადებზეა აგებული. ჩვენ ვაჩვენებთ, როგორ ავაშენეთ და ვიყენებთ მას, რათა წარმოვაჩინოთ რეალური, მნიშვნელოვანი გზები, რომლითაც AI-ს შეუძლია მხარი დაუჭიროს ყოველდღიურ სამუშაოს ჩვენს გუნდებში. OpenAI-ის ინსტრუმენტები, რომლებიც მის ასაგებად და გასაშვებად გამოვიყენეთ (Codex, ჩვენი GPT‑5 ფლაგმანური მოდელი, Evals API⁠(იხსნება ახალ ფანჯარაში) და Embeddings API⁠(იხსნება ახალ ფანჯარაში)) არის იგივე ინსტრუმენტები, რომლებსაც ჩვენ დეველოპერებს ყველგან ვთავაზობთ.

ჩვენი მონაცემთა აგენტი თანამშრომლებს საშუალებას აძლევს კითხვიდან ხედვამდე წუთებში მივიდნენ და არა დღეებში. ეს ამცირებს ბარიერს მონაცემების მოპოვებისა და დახვეწილი ანალიზისთვის ყველა ფუნქციაში და არა მხოლოდ ჩვენი მონაცემთა გუნდისთვის. დღეს OpenAI-ში ინჟინერიის, მონაცემთა მეცნიერების, ბაზარზე გატანის, ფინანსებისა და კვლევის გუნდები აგენტს ეყრდნობიან, რათა უპასუხონ მაღალი გავლენის მქონე მონაცემთა კითხვებს. მაგალითად, ის შეიძლება დაეხმაროს გაშვებების შეფასებასა და ბიზნესის მდგომარეობის გაგებაში, ეს ყველაფერი ბუნებრივი ენის ინტუიციური ფორმატის საშუალებით. აგენტი აერთიანებს Codex-ით გაძლიერებულ ცხრილის დონეზე ცოდნას პროდუქტისა და ორგანიზაციული კონტექსტით. მისი უწყვეტად მსწავლელი მეხსიერების სისტემა ნიშნავს, რომ ის ყოველ ჯერზე უმჯობესდება.

ამ პოსტში განვიხილავთ, რატომ გვჭირდებოდა უნიკალური AI მონაცემთა აგენტი, რა ხდის მისი კოდით გამდიდრებული მონაცემთა კონტექსტსა და თვითსწავლებას ასე სასარგებლოს და რა გაკვეთილები ვისწავლეთ გზად.

OpenAI-ის მონაცემთა პლატფორმა ემსახურება 3.5k-ზე მეტ შიდა მომხმარებელს , რომლებიც მუშაობენ ინჟინერიის, პროდუქტისა და კვლევის მიმართულებებში, და მოიცავს 600 პეტაბაიტზე მეტ მონაცემს 70k მონაცემთა ნაკრებში. ამ მასშტაბზე უბრალოდ სწორი ცხრილის პოვნა შეიძლება ანალიზის ერთ-ერთი ყველაზე შრომატევადი ნაწილი იყოს.

როგორც ერთ-ერთმა შიდა მომხმარებელმა თქვა:

„ჩვენ გვაქვს ბევრი ცხრილი, რომლებიც საკმაოდ ჰგავს ერთმანეთს, და უამრავ დროს ვხარჯავ იმის გარკვევაში, რით განსხვავდებიან და რომელი უნდა გამოვიყენო. ზოგი logged-out მომხმარებლებს მოიცავს, ზოგი — არა. ზოგს გადაფარული ველები აქვს; ძნელია გაიგო, რა რა არის.“

თუნდაც სწორი ცხრილები იყოს არჩეული, სწორი შედეგების მიღება მაინც შეიძლება რთული იყოს. ანალიტიკოსებს უწევთ მსჯელობა ცხრილის მონაცემებსა და ცხრილებს შორის ურთიერთობებზე, რათა დარწმუნდნენ, რომ გარდაქმნები და ფილტრები სწორად გამოიყენეს. გავრცელებული შეცდომები — many-to-many შეერთებები, filter pushdown შეცდომები და დაუმუშავებელი null-ები — შეიძლება ჩუმად გააბათილოს შედეგები. OpenAI-ის მასშტაბზე ანალიტიკოსებს დრო არ უნდა დაეკარგოთ SQL-ის სემანტიკის ან მოთხოვნის წარმადობის გამართვაში: მათი ფოკუსი უნდა იყოს მეტრიკების განსაზღვრაზე, ვარაუდების შემოწმებასა და მონაცემებზე დაფუძნებული გადაწყვეტილებების მიღებაზე.

მოდით განვიხილოთ, რა არის ჩვენი აგენტი, როგორ კრებს ის კონტექსტს და როგორ აგრძელებს თვითგაუმჯობესებას.

ჩვენი აგენტი მუშაობს GPT‑5.2-ზე და შექმნილია OpenAI-ის მონაცემთა პლატფორმაზე მსჯელობისთვის. ის ხელმისაწვდომია ყველგან, სადაც თანამშრომლები უკვე მუშაობენ: როგორც Slack აგენტი, ვებინტერფეისის საშუალებით, IDE-ებში, Codex CLI via MCP⁠(იხსნება ახალ ფანჯარაში)-ში და პირდაპირ OpenAI-ის შიდა ChatGPT აპში MCP connector-ის მეშვეობით⁠(იხსნება ახალ ფანჯარაში).

მომხმარებლებს შეუძლიათ დასვან რთული, ღია ტიპის კითხვები, რომლებიც ჩვეულებრივ ხელით კვლევის მრავალ რაუნდს მოითხოვდა. აი ეს მაგალითი მოთხოვნა, რომელიც სატესტო მონაცემთა ნაკრებს იყენებს: „NYC taxi-ის მგზავრობებისთვის, pickup-to-dropoff ZIP წყვილებიდან რომლებია ყველაზე არასაიმედო, ტიპურ და უარეს შემთხვევის მგზავრობის დროს შორის ყველაზე დიდი სხვაობით, და როდის ჩნდება ეს ცვალებადობა?“

აგენტი ანალიზს თავიდან ბოლომდე მართავს — კითხვის გაგებიდან დაწყებული, მონაცემების კვლევით, მოთხოვნების გაშვებით და მიგნებების შეჯამებით დასრულებული.

აგენტის ერთ-ერთი სუპერძალა ისაა, თუ როგორ მსჯელობს პრობლემებზე. ფიქსირებული სკრიპტის მიყოლის ნაცვლად, აგენტი საკუთარ პროგრესს აფასებს. თუ შუალედური შედეგი არასწორად გამოიყურება (მაგ., თუ არასწორი join-ის ან filter-ის გამო მას ნულოვანი სტრიქონები აქვს), აგენტი იკვლევს, რა მოხდა არასწორად, ასწორებს მიდგომას და თავიდან ცდის. ამ მთელი პროცესის განმავლობაში ის სრულ კონტექსტს ინარჩუნებს და ნასწავლს ნაბიჯებს შორის გადააქვს. ეს დახურული ციკლის, თვითმსწავლელი პროცესი იტერაციას მომხმარებლიდან თავად აგენტში გადააქვს, რაც იძლევა უფრო სწრაფ შედეგებს და მუდმივად უფრო მაღალი ხარისხის ანალიზს, ვიდრე ხელით სამუშაო ნაკადები.

აგენტი ფარავს ანალიტიკის სრულ სამუშაო პროცესს: მონაცემების აღმოჩენას, SQL-ის გაშვებას და ნოუთბუქებისა და ანგარიშების გამოქვეყნებას. მას ესმის კომპანიის შიდა ცოდნა, შეუძლია ვებძიება გარე ინფორმაციისთვის და დროთა განმავლობაში უმჯობესდება ნასწავლი გამოყენებისა და მეხსიერების მეშვეობით.

მაღალი ხარისხის პასუხები დამოკიდებულია მდიდარ, ზუსტ კონტექსტზე. კონტექსტის გარეშე, ძლიერმა მოდელებმაც კი შეიძლება არასწორი შედეგები შექმნან, მაგალითად, მნიშვნელოვნად არასწორად შეაფასონ მომხმარებელთა რაოდენობა ან არასწორად გაიგონ შიდა ტერმინოლოგია.

ამ ტიპის ჩავარდნების თავიდან ასაცილებლად, აგენტი აგებულია კონტექსტის მრავალ ფენაზე, რომლებიც მას OpenAI-ის მონაცემებსა და ინსტიტუციურ ცოდნასთან აკავშირებს.

• მეტამონაცემებით დაკავშირება: აგენტი ეყრდნობა სქემის მეტამონაცემებს (სვეტების სახელები და მონაცემთა ტიპები) SQL-ის წერისთვის და იყენებს ცხრილის lineage-ს (მაგ., upstream და downstream ცხრილების ურთიერთობები), რათა კონტექსტი მისცეს, თუ როგორ უკავშირდება სხვადასხვა ცხრილი ერთმანეთს.
• მოთხოვნის ინფერენცია: ისტორიული მოთხოვნების მიღება ეხმარება აგენტს გაიგოს, როგორ დაწეროს საკუთარი მოთხოვნები და რომელი ცხრილებია ჩვეულებრივ ერთმანეთთან შეერთებული.

• დომენის ექსპერტების მიერ მოწოდებული ცხრილებისა და სვეტების კურირებული აღწერები, რომლებიც ასახავს განზრახვას, სემანტიკას, ბიზნესის მნიშვნელობას და ცნობილ შენიშვნებს, რომელთა გამოტანა სქემებიდან ან წარსული მოთხოვნებიდან მარტივად შეუძლებელია.

მხოლოდ მეტამონაცემები საკმარისი არ არის. ცხრილების რეალურად გასარჩევად, უნდა გესმოდეთ, როგორ შეიქმნა ისინი და საიდან მოდის.

• ცხრილის კოდის დონეზე განსაზღვრების გამოყვანით, აგენტი უფრო ღრმა გაგებას ქმნის იმის შესახებ, თუ რას შეიცავს მონაცემები რეალურად.
  • იმის ნიუანსები, თუ რა ინახება ცხრილში და როგორ გამოიყვანება ის ანალიტიკური მოვლენიდან, დამატებით ინფორმაციას იძლევა. მაგალითად, ამას შეუძლია კონტექსტი მისცეს მნიშვნელობების უნიკალურობას, რამდენად ხშირად ახლდება ცხრილის მონაცემები, მონაცემების მოცულობას (მაგ., თუ ცხრილი გარკვეულ ველებს გამორიცხავს, მას ასეთი დეტალურობის დონე აქვს) და ა.შ.
• ეს იძლევა გამოყენების გაუმჯობესებულ კონტექსტს იმით, რომ აჩვენებს, როგორ გამოიყენება ცხრილი SQL-ის მიღმაც Spark-ში, Python-ში და სხვა მონაცემთა სისტემებში.
• ეს ნიშნავს, რომ აგენტს შეუძლია განასხვაოს ცხრილები, რომლებიც ჰგავს ერთმანეთს, მაგრამ კრიტიკულად განსხვავდება. მაგალითად, მას შეუძლია განსაზღვროს, შეიცავს თუ არა ცხრილი მხოლოდ პირველი მხარის ChatGPT ტრაფიკს. ეს კონტექსტიც ავტომატურად ახლდება, ამიტომ ხელით მოვლის გარეშე აქტუალური რჩება.

• აგენტს შეუძლია Slack-ზე, Google Docs-სა და Notion-ზე წვდომა, სადაც ფიქსირდება კომპანიის კრიტიკული კონტექსტი, როგორიცაა გაშვებები, საიმედოობის ინციდენტები, შიდა კოდური სახელები და ინსტრუმენტები, ასევე ძირითადი მეტრიკების კანონიერი განსაზღვრებები და გამოთვლის ლოგიკა.
• ეს დოკუმენტები იტვირთება, embedding-ებად გარდაიქმნება და ინახება მეტამონაცემებთან და ნებართვებთან ერთად. retrieval სერვისი გაშვების დროს მართავს წვდომის კონტროლსა და ქეშირებას, რაც აგენტს ამ ინფორმაციის ეფექტიანად და უსაფრთხოდ მოზიდვის საშუალებას აძლევს.

• როდესაც აგენტს აწვდიან შესწორებებს ან თავად აღმოაჩენს კონკრეტული მონაცემთა კითხვების ნიუანსებს, მას შეუძლია ეს ნასწავლი მომავლისთვის შეინახოს, რაც შესაძლებლობას აძლევს, მუდმივად გაუმჯობესდეს თავის მომხმარებლებთან ერთად.
  • ამის შედეგად, მომავალი პასუხები უფრო ზუსტი საწყისი მდგომარეობიდან იწყება, ნაცვლად იმისა, რომ იგივე პრობლემებს ისევ და ისევ წააწყდეს.
  • მეხსიერების მიზანია შეინარჩუნოს და ხელახლა გამოიყენოს არააშკარა შესწორებები, ფილტრები და შეზღუდვები, რომლებიც კრიტიკულია მონაცემთა სისწორისთვის, მაგრამ სხვა ფენებიდან გამოტანა რთულია.
  • მაგალითად, ერთ შემთხვევაში აგენტმა არ იცოდა, როგორ გაეფილტრა კონკრეტული ანალიტიკური ექსპერიმენტი (ის ეყრდნობოდა ექსპერიმენტის gate-ში განსაზღვრულ კონკრეტულ სტრიქონთან დამთხვევას). აქ მეხსიერებას გადამწყვეტი მნიშვნელობა ჰქონდა, რათა მას სწორი ფილტრაცია შეესრულებინა და არა ბუნდოვნად ეცადა სტრიქონის დამთხვევა.
• როდესაც აგენტს შესწორებას აძლევთ ან ის თქვენს საუბარში რაიმე ახალს პოულობს, ის შემოგთავაზებთ, რომ ეს მეხსიერებაში შეინახოთ მომავლისთვის.
  • მეხსიერებების შექმნა და რედაქტირებაც მომხმარებლებს ხელით შეუძლიათ.
  • მეხსიერებები გლობალურ და პერსონალურ დონეზეა განსაზღვრული, ხოლო აგენტის ინსტრუმენტები მათ რედაქტირებას ამარტივებს.

• როდესაც ცხრილისთვის წინასწარი კონტექსტი არ არსებობს ან არსებული ინფორმაცია მოძველებულია, აგენტს შეუძლია პირდაპირ მონაცემთა საწყობში გაუშვას ცოცხალი მოთხოვნები, რათა ცხრილი პირდაპირ დაათვალიეროს და გამოკითხოს. ეს მას საშუალებას აძლევს, რეალურ დროში გადაამოწმოს სქემები, გაიგოს მონაცემები და შესაბამისად უპასუხოს.
• აგენტს ასევე შეუძლია საჭიროების მიხედვით დაუკავშირდეს სხვა 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.