رحلة داخل وكيل الذكاء الاصطناعي الداخلي لدى OpenAI

تعد البيانات المحرك الأساسي لتعلم الأنظمة، وتطور المنتجات، وكيفية اتخاذ الشركات لقراراتها. ومع ذلك، فإن الحصول على إجابات سريعة ودقيقة وضمن السياق الصحيح غالبًا ما يكون أصعب مما ينبغي. ولتسهيل هذه العملية مع توسّع نطاق OpenAI، قمنا ببناء وكيل بيانات مدعوم بالذكاء الاصطناعي خاص بنا ومطور داخليًا، يعمل على استكشاف منصتنا وتحليلها بمنطقية.

هذا الوكيل هو أداة داخلية حصرية (وليست متاحة للجمهور) صُممت لتتوافق تمامًا مع بنية البيانات والأذونات الخاصة بـ OpenAI. هدفنا من مشاركة قصة بنائه واستخداماته هو تسليط الضوء على الإمكانات الملموسة للذكاء الاصطناعي في تعزيز الإنتاجية اليومية. والجدير بالذكر أننا اعتمدنا في تطويره على تقنياتنا الأساسية المتاحة للجميع، بما في ذلك Codex، ونموذجنا الرائد GPT‑5، وواجهة Evals API⁠(يفتح في نافذة جديدة)، وواجهة Embeddings API⁠(يفتح في نافذة جديدة)، وهي ذاتها الأدوات التي يمكن لأي مطور استخدامها اليوم.

بفضل وكيل البيانات لدينا، أصبح بإمكان موظفينا الانتقال من السؤال إلى المعلومة المفيدة في دقائق بدلًا من أيام؛ لقد كسر هذا الوكيل الحواجز أمام تحليل البيانات المعقدة، ليصبح متاحًا للجميع دون الاقتصار على فريق البيانات فقط. وتعتمد عليه حاليًا فرق متنوعة، مثل فرق الهندسة وعلوم البيانات واستراتيجيات السوق والتمويل والأبحاث في OpenAI، للحصول على إجابات عن أسئلة البيانات الاستراتيجية؛ فعلى سبيل المثال، يمكنه المساعدة في تقييم عمليات الإطلاق وفهم الوضع العام للأعمال، وكل ذلك بمجرد طرح الأسئلة بلغة عادية. يتميز الوكيل بدمج تقنيات Codex مع فهم عميق للسياق التنظيمي وسياق المنتجات، بالإضافة إلى نظام ذاكرة يجعله يتعلم ويتحسن باستمرار مع كل استخدام.

سنوضح في هذا المقال لماذا احتجنا إلى وكيل بيانات ذكاء اصطناعي مصمم داخليًا، وسر فاعلية ميزاته في الربط بين البيانات والأكواد والتعلم الذاتي، وسنشارككم أهم الخبرات التي اكتسبناها أثناء تطويره.

بأكثر من 70 ألف مجموعة بيانات وحجم إجمالي يتخطى 600 بيتابايت، تدعم منصة بيانات OpenAI ما يزيد عن 3500 موظف في قطاعات الهندسة والبحث والتطوير. وفي ظل هذا النطاق الواسع، يمثل البحث عن جدول بيانات محدد عائقًا زمنيًا كبيرًا أمام المحللين والمهندسين.

على حد تعبير أحد موظفينا:

"لدينا كم هائل من الجداول المتشابهة إلى حد كبير، وأبذل جهدًا مضاعفًا لاكتشاف الاختلافات بينها وتحديد ما يجب استخدامه. بعض الجداول تشمل المستخدمين الذين سجلوا خروجهم والبعض الآخر يستثنيهم، وهناك تداخل في البيانات يجعل من الصعب معرفة طبيعة كل جدول بدقة."

لا يضمن اختيار الجداول المناسبة الحصول على نتائج دقيقة دائمًا، فالمحلل يحتاج لفهم عميق للعلاقات بين بيانات الجداول لضمان دقة عناصر التصفية والتحويلات التي يتم تطبيقها. كما أن هناك ثغرات تقنية متكررة قد تؤدي إلى نتائج غير صالحة دون سابق إنذار، مثل علاقات الربط المعقدة أو أخطاء ترحيل عناصر التصفية أو إهمال القيم الصفرية. وفي بيئة ضخمة مثل OpenAI، من المفترض ألا يهدر المحللون طاقتهم في إصلاح أكواد SQL أو تحسين سرعة البحث، بل يجب استثمار وقتهم في صياغة مقاييس الأداء واختبار الفرضيات ودعم اتخاذ قرارات مبنية على البيانات.

سنتعرف الآن على هوية الوكيل، وكيفية انتقائه للمعلومات السياقية، ووسائل تعلمه الذاتي المستمر.

يعمل الوكيل بواسطة نموذج GPT‑5.2، وهو مصمم للتحليل والاستنتاج عبر منصة بيانات OpenAI. الوكيل متاح في جميع بيئات عمل الموظفين الحالية: كوكيل في تطبيق Slack، ومن خلال واجهة ويب، وداخل بيئات التطوير المتكاملة، وفي واجهة Codex CLI عبر MCP⁠(يفتح في نافذة جديدة)، ومباشرةً داخل تطبيق ChatGPT الداخلي لشركة OpenAI من خلال موصل MCP⁠(يفتح في نافذة جديدة).

يتيح النظام للموظفين طرح تساؤلات متشعبة تتطلب في الحالات العادية أوقاتًا من الاستكشاف اليدوي. إليك مثالاً من واقع البيانات التجريبية: "في رحلات تاكسي مدينة نيويورك، أي المسارات (من منطقة إلى أخرى) تُعد الأكثر تقلبًا وغير مضمونة من حيث الوقت، حيث تظهر أكبر فجوة بين الوقت الطبيعي وأسوأ سيناريو للرحلة، وفي أي أوقات يتكرر هذا التباين؟"

يتولى الوكيل إدارة دورة التحليل كاملة، حيث يبدأ باستيعاب الاستفسار والبحث في البيانات، ثم تنفيذ الأوامر البرمجية، وينتهي بصياغة الاستنتاجات النهائية.

يتميز وكيلنا بقدرة استثنائية على التفكير المنطقي وحل المشكلات؛ فهو لا يتبع سيناريو ثابتًا، بل يراقب أداءه باستمرار. فإذا واجه نتيجة غير منطقية، كالحصول على جدول فارغ بسبب خطأ في البرمجة، فإنه يحقق في السبب ويصحح مساره تلقائيًا، ثم يحاول مرة أخرى. الميزة هنا هي قدرة النظام على التعلم التراكمي والحفاظ على سياق المشكلة طوال الوقت. هذا النظام الذي يعتمد على التعلم الذاتي ضمن "حلقة مغلقة"، يجعل عملية التجربة والخطأ تتم داخل الوكيل لا من قِبل المستخدم، مما يوفر الوقت ويقدم تحليلات تتفوق في دقتها على أساليب العمل اليدوية.

يتولى الوكيل إدارة سير عمل التحليلات الشامل: من استكشاف البيانات وتنفيذ أكواد SQL إلى إصدار التقارير والملفات التحليلية. إنه يتميز بفهمه العميق لسياق العمل الداخلي، وقدرته على إجراء بحث خارجي عبر الإنترنت، فضلاً عن قدرته على التحسن المستمر بفضل نظام الذاكرة وتعلمه من أنماط الاستخدام.

إن جودة الإجابات مرهونة بدقة وشمولية المعلومات السياقية. ففي غياب السياق، قد تقع أقوى النماذج في فخ النتائج المضللة، كإعطاء تقديرات خاطئة جدًا لعدد المستخدمين، أو فهم المصطلحات الخاصة بالعمل بشكل غير صحيح.

ولتفادي ثغرات الأداء هذه، يرتكز بناء الوكيل على طبقات سياقية متعددة تضمن استناده إلى قواعد بيانات OpenAI ومعرفتها المؤسسية.

• الاستناد على البيانات الوصفية: يستند الوكيل إلى وصف هيكل البيانات (الأسماء والأنواع) لإتقان صياغة استعلامات SQL، كما يستفيد من تتبع مسار الجداول (مثل، مثل علاقات الجداول السابقة واللاحقة) لفهم الارتباطات بينها، مما يساعده على إدراك كيفية تدفق البيانات من جدول إلى آخر.
• الاستدلال من الاستعلامات: من خلال تحليل الاستعلامات السابقة، يتعلم الوكيل صياغة أوامر SQL بشكل صحيح، ويكتشف أنماط الربط الشائعة بين الجداول المختلفةً.

• الأوصاف المنسّقة للجداول والأعمدة التي يقدمها خبراء متخصصين، توضح الغرض من البيانات ومعناها في سياق العمل، بالإضافة إلى ملاحظات وتحذيرات قد لا تظهر بوضوح عند الاكتفاء بتحليل مخططات البيانات أو سجل الاستعلامات السابقة.

ولا يكفي الاعتماد على البيانات الوصفية فقط؛ فالتفريق الدقيق بين الجداول يتطلب استيعاب سياق بنائها ومعرفة جذورها (أين نشأت).

• عبر اشتقاق تعريفات الجداول من واقع الأكواد البرمجية، يتمكن الوكيل من تكوين رؤية أكثر عمقًا للمحتوى الحقيقي للبيانات. 
  • إن فهم الفروقات الدقيقة لما يحتويه الجدول وكيفية توليده من واقع سجلات الأحداث يمنحنا رؤية أشمل. إذ يمكنه توضيح مدى تكرار القيم، ودورية تحديث البيانات، ونطاق التغطية (كأن نعرف أن الجدول يفتقر لحقول محددة مما يحدد مستوى دقته)، وغيرها من التفاصيل.
• يمنحنا هذا رؤية أشمل لسياق الاستخدام، حيث يوضح كيفية التعامل مع الجدول في بيئات برمجية متنوعة مثل Spark وPython، وغيرها من أنظمة البيانات التي لا تقتصر على SQL.
• بفضل هذه الميزة، يستطيع الوكيل التفريق بين جداول البيانات التي تبدو متشابهة ولكنها تختلف في جوانب جوهرية؛ كأن يحدد بدقة ما إذا كان الجدول يقتصر على حركة بيانات 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.