درون عامل داده داخلی OpenAI

داده‌ها نحوه یادگیری سیستم‌ها، تکامل محصولات و تصمیم‌گیری شرکت‌ها را قدرت می‌بخشند. اما دریافت پاسخ‌ها به‌سرعت، به‌درستی، و با زمینه‌ی مناسب اغلب دشوارتر از آن است که باید باشد. برای آسان‌تر کردن این کار با گسترش OpenAI، ما عامل داده AI سفارشی داخلی خودمان را ساختیم که پلتفرم خودمان را کاوش کرده و درباره آن استدلال می‌کند.

عامل ما یک ابزار سفارشی داخلی است (نه یک محصول خارجی)، که به‌طور خاص بر اساس داده‌ها، مجوزها و جریان‌های کاری OpenAI طراحی شده است. ما نشان می‌دهیم که چگونه آن را ساخته‌ایم و از آن استفاده می‌کنیم تا نمونه‌هایی از روش‌های واقعی و مؤثری برجسته شود که AI می‌تواند از کارهای روزمره در تیم‌های ما پشتیبانی کند. ابزارهای OpenAI که برای ساخت و اجرای آن استفاده کردیم (Codex، الگو پرچمی GPT‑5 ما، Evals API⁠(در یک پنجره جدید باز می‌شود) و Embeddings API⁠(در یک پنجره جدید باز می‌شود)) همان ابزارهایی هستند که در اختیار توسعه‌دهندگان در همه‌جا قرار می‌دهیم.

عامل داده‌ای ما به کارمندان اجازه می‌دهد در عرض چند دقیقه، نه چند روز، از سوال به بینش برسند. این کار آستانه لازم برای استخراج داده‌ها و تحلیل‌های دقیق در تمام بخش‌ها را پایین می‌آورد، نه فقط توسط تیم داده ما. امروز، تیم‌های مهندسی، علوم داده، Go-To-Market، امور مالی و تحقیقات در OpenAI به عامل تکیه می‌کنند تا به پرسشسؤالات داده‌محور با تأثیر بالا پاسخ دهند. برای مثال، می‌تواند به شما کمک کند تا به این پرسش پاسخ دهید که چگونه عرضه‌ها را ارزیابی کنید و سلامت کسب‌وکار را درک کنید، همه از طریق قالب شهودی زبان طبیعی. عامل، دانش سطح جدول مبتنی بر Codex را با زمینه محصول و سازمانی ترکیب می‌کند. سیستم حافظه‌ای که به طور مداوم یاد می‌گیرد، به این معناست که با هر بار استفاده نیز بهبود می‌یابد.

در این پست، توضیح خواهیم داد چرا به یک عامل دادهٔ AI سفارشی نیاز داشتیم، چه چیزی زمینهٔ دادهٔ غنی‌شده با کد و خودیادگیری آن را تا این حد مفید می‌کند، و درس‌هایی که در طول مسیر آموختیم.

پلتفرم داده OpenAI به بیش از ۳,۵۰۰ کاربر داخلی که در حوزه‌های مهندسی، محصول و پژوهش فعالیت می‌کنند، خدمات ارائه می‌دهد و بیش از ۶۰۰ پتابایت داده را در ۷۰,۰۰۰ مجموعه‌داده پوشش می‌دهد. در آن اندازه، صرفاً پیدا کردن جدول مناسب می‌تواند یکی از زمان‌برترین بخش‌های انجام تحلیل باشد.

همان‌طور که یکی از کاربران داخلی اظهار داشت:

«ما تعداد زیادی جدول داریم که تا حد زیادی شبیه به هم هستند و من زمان زیادی صرف می‌کنم تا بفهمم چه تفاوت‌هایی دارند و کدام یک را باید استفاده کنم. برخی شامل کاربران خارج‌شده از حساب می‌شوند، برخی نمی‌شوند. برخی کادرها هم‌پوشانی دارند؛ تشخیص آن‌ها از هم دشوار است.»

حتی با انتخاب جدول‌های صحیح، تولید نتایج صحیح می‌تواند چالش‌برانگیز باشد. تحلیلگران باید درباره داده‌های جدول و روابط جدول استدلال کنند تا اطمینان حاصل شود که تبدیل‌ها و فیلترها به‌درستی اعمال می‌شوند. حالت‌های رایج خرابی—اتصال‌های چندبه‌چند، خطاهای پایین‌دستی فیلتر، و مقادیر تهیِ رسیدگی‌نشده—می‌توانند بی‌سروصدا نتایج را نامعتبر کنند. در مقیاس OpenAI، تحلیل‌گران نباید مجبور باشند زمان خود را صرف اشکال‌زدایی معناشناسی SQL یا عملکرد کوئری کنند: تمرکز آن‌ها باید بر تعریف معیارها، اعتبارسنجی فرضیات، و اتخاذ تصمیمات مبتنی بر داده باشد.

بیایید بررسی کنیم که عامل ما چیست، چگونه زمینه را تنظیم می‌کند و چگونه به بهبود مستمر خود ادامه می‌دهد.

عامل ما توسط GPT‑5.2 توانمند شده و برای استدلال بر روی پلتفرم داده‌های OpenAI طراحی شده است. این در هر جایی که کارکنان از قبل کار می‌کنند در دسترس است: به‌عنوان یک عامل در Slack، از طریق یک رابط وب، داخل IDEها، در Codex CLI از طریق MCP⁠(در یک پنجره جدید باز می‌شود)، و مستقیماً در اپ داخلی ChatGPT در OpenAI از طریق یک کانکتور MCP⁠(در یک پنجره جدید باز می‌شود).

کاربران می‌توانند پرسش‌های پیچیده و باز بپرسند که معمولاً به چندین دور بررسی دستی نیاز دارد. این دستور نمونه را در نظر بگیرید که از یک مجموعه‌داده‌ی آزمایشی استفاده می‌کند: «در سفرهای تاکسی نیویوک، کدام جفت کد پستی مبدا تا مقصد بیشترین اختلاف بین زمان معمول و بدترین حالت سفر را دارند و این نوسان چه زمانی رخ می‌دهد؟»

عامل تحلیل را به‌صورت جامع انجام می‌دهد، از درک پرسش تا بررسی داده‌ها، اجرای کوئری‌ها و ترکیب یافته‌ها.

یکی از توانایی‌های ویژه عامل، شیوه‌ استدلال آن در حل مسائل است. به‌جای پیروی از یک اسکریپت ثابت، عامل پیشرفت خود را ارزیابی می‌کند. اگر یک نتیجه میانی نادرست به نظر برسد (مثلاً اگر به دلیل یک پیوند یا فیلتر نادرست، صفر ردیف داشته باشد)، عامل بررسی می‌کند چه چیزی اشتباه شده است، رویکرد خود را تنظیم می‌کند و دوباره تلاش می‌کند. در طول این فرایند، زمینه را به‌طور کامل حفظ می‌کند و آموخته‌ها را بین مراحل منتقل می‌کند. این فرایند حلقه‌بسته و خودیادگیر تکرار را از کاربر به خودِ عامل منتقل می‌کند و نتایج سریع‌تر و تحلیل‌هایی با کیفیت به‌طور مداوم بالاتر از گردش‌های کاری دستی را ممکن می‌سازد.

عامل کل گردش کار تحلیل را پوشش می‌دهد: کشف داده‌ها، اجرای 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.