عند صدور Codex، سألني أحد أفراد الفريق: “ماذا سنفعل عندما يتمكن Codex من إنجاز حالات الاستخدام التي بنيناها في الأشهر القليلة الماضية بمحاولة واحدة؟”
هذا السؤال يمسّ جوهر ما تعنيه FDE في OpenAI. نحن نعمل جنبًا إلى جنب مع العملاء لفهم أصعب مشكلاتهم وبناء حلول يمكنهم الاعتماد عليها. وما نتعلمه يساعد في تشكيل منتجاتنا ويمنح فريق Research مشكلات ملموسة لحلها.
هذا تقدم. إذا جعلنا أنفسنا متجاوزة كل بضعة أشهر، ففريق FDE لدينا يقوم بعمله على أكمل وجه.
أسستُ الفريق في أوائل 2025 لسدّ ما نسميه “فجوة النشر”: المسافة بين ما تبدو عليه قدرات النماذج وما يمكن للناس استخدامه بشكل موثوق للقيام بأعمالهم.
تحركت قدرات النماذج أسرع من الأنظمة والعمليات اللازمة لتوظيفها. أحيانًا تكون القطعة المفقودة منتجًا. وأحيانًا يُظهر النموذج أداءً جيدًا في اختبار معياري لكنه لا يستطيع أداء العمل مع متغيرات وقيود الحياة الواقعية.
نركز على أصعب مشكلات العملاء. حيث تستطيع نماذجنا أداء العمل اليوم، نعمل مع فريق Product والعميل لجعل الحل قابلًا للتكرار، وحيث تقصر عن ذلك، نعمل مع العملاء وفريق Research لتحديد الفجوة وإجراء التحسينات. هدفنا هو أن يترك كل تعاونًا نقطة انطلاق أفضل للعميل التالي—إذا رفعنا الحد الأدنى إلى درجة لا يحتاج معها عملاؤنا إلى FDEs لحل هذا النوع من المشكلات في المرة القادمة، فقد أدّينا عملنا جيدًا.
كان التحدي الذي واجه John Deere، وهي شركة زراعية عمرها 200 عام، هو كيفية توسيع نطاق تقديم النصائح المخصصة للمزارعين.
أحد الأمثلة على ذلك هو See & Spray، تقنية مكافحة الأعشاب الضارة الدقيقة، التي تستخدم الكاميرات وتعلم الآلة لتحديد الأعشاب الضارة ورشّها بدلاً من معالجة الحقول بأكملها، مما يقلل استخدام المواد الكيميائية بنسبة تصل إلى 70%.
لكن تحقيق تلك الفوائد يعتمد على معرفة المزارعين بكيفية إعداد التقنية، وتخطيط موسمهم، وتعديل ممارساتهم مع تغير الظروف.
نشرت John Deere واجهات برمجة التطبيقات (APIs) الخاصة بـ OpenAI للمساعدة في جعل هذا الدعم مخصصًا وقابلًا للتوسع.
يمكن للذكاء الاصطناعي الإجابة عن أسئلة المزارعين بلغتهم الطبيعية، وتقديم إرشادات إعداد وتوصيات مخصصة، وتحديد الحالات التي قد لا تقدم فيها المعدات إمكاناتها الكاملة، ومساعدة المزارعين على فهم القيمة التي يحصلون عليها من التقنية.
وتتجاوز الفرصة أي تفاعل منفرد: لتقديم إرشادات ذات صلة على طول رحلة العميل، مما يساعد المزارعين على الاستخدام الأفضل لمعداتهم مع تحسين الكفاءة والاستدامة.
هذا هو نوع التحديات التي يسعى OpenAI FDEs إلى حلها: مساعدة المؤسسات على الانتقال من قدرات الذكاء الاصطناعي إلى أنظمة تقدم قيمة عملية في بيئات واقعية معقدة.
لكن المشكلات غالبًا ما تكون مفتوحة تمامًا، وقد لا توجد حقيقة مرجعية راسخة، ولا يوجد دليل إرشادي جاهز. الجميع يريد بناء شيء لم يكن موجودًا من قبل. لكن عددًا أقل من الناس يريد القيام بما يلزم للوصول إلى ذلك.
إيجاد مواهب FDEs مع رفع معيار “الجودة الكافية” تطلب تجريبًا وتطبيقًا مستمرين.
ابدأ بالنتيجة
في بداية كل اجتماع لفريق FDE، أعرض شريحة تحمل قيمة أساسية واحدة: “ابدأ بالنتيجة، افعل ما يلزم للنجاح، ثم تتبع ذلك بالتوسع”.
يمكن للعرض التوضيحي المذهل أن يقطع شوطًا طويلًا قبل أن يسأل أحد عما إذا كان يعمل في العالم الواقعي.
مهمتنا هي حل مشكلة العميل بمعيار نستطيع الوقوف خلفه في بيئة الإنتاج.
في منتصف 2025، كان لدينا حوالي 15 FDE يعملون مع عميل كبير في صناعة أشباه الموصلات على أكثر من 10 حالات استخدام. كان الطموح هو جعل عملية التحقق لديهم ذات طبيعة مدعومة بالذكاء الاصطناعي، وتشمل:
إنشاء الاختبارات الموجهة
تحليل الأسباب الجذرية وتصحيح الأخطاء
مساعد معماري
يمثل التحقق حوالي 70% من جهد المشروع في هذه الصناعة. كانت الفرصة هائلة، وكانت هناك أماكن كثيرة ممكنة للبدء منها.
كان بعض مهندسي نشر الحلول (FDEs) قد انضموا إلى OpenAI قبل أيام قليلة فقط ولم يكونوا قد عملوا قط في مجال أشباه الموصلات. فاندمجوا مع فريق التحقق لدى العميل، ودرسوا تصميم الرقائق في وقت فراغهم، وبنوا تقييمات مع المهندسين لاختبار ما إذا كان الذكاء الاصطناعي قادرًا على توليد اختبارات مفيدة وتشخيص أعطال الرقائق بشكل صحيح.
إلى جانب ذلك التعلم، بنّينا أدوات تشغيل مخصصة لحالات الاستخدام الفردية. خلال أول 3-6 أشهر، وصلت جميعها إلى الإنتاج وتبنّى المبكر من المستخدمين. وكانت المكافأة هي رؤية المقاييس:
توفير ~48% من الوقت من خلال توليد الاختبارات الموجّهة بالذكاء الاصطناعي.
تحسن في الأداء بنسبة 22% كوسيط من خلال تحسين النوى (kernel optimisation).
أسابيع من تصحيح الأخطاء انضغطت إلى ساعات
وعندما عرضنا كل ذلك، سأل كبير مسؤولي الأجهزة: «هل كنتم مصممي رقائق قبل قدومكم إلى هنا؟»
لا يحتاج مهندسو النشر الميداني لدينا إلى معرفة القطاع في اليوم الأول، لكن من مسؤوليتهم تعلّمه.
مع جعل مساعدي البرمجة بناء البرمجيات أسرع، يصبح فهم أعمال العميل أكثر أهمية. نبني فرقًا تضم مزيجًا من العموميين وخبراء المجالات.
تحتاج إلى معرفة كافية لاتخاذ أحكام سليمة، وإلى فضول كافٍ للتشكيك في افتراضات الوضع الراهن.
على سبيل المثال، في علوم الحياة، تساعد الخلفيات العلمية لمهندسي النشر الميداني لدينا على كسب ثقة الباحثين العاملين في مهام اكتشاف الأدوية قبل السريرية مثل التحقق من الأهداف وترتيب أولوياتها، وتحليل التعبير الجيني، وإعادة بناء مسارات التخليق الكيميائي. وتتيح لهم هذه الخبرة تقديم أحكام مستنيرة حول كيفية تحسين تلك المسارات العملية.
اجعل النجاح قابلًا للتكرار
لقد أثبتّا أن هذه المسارات العملية يمكنها تقديم قيمة، لكن كل واحد منها كان لا يزال يتطلب تكاملًا مخصصًا كبيرًا للغاية بحيث لا يمكن توسيعه لفريق آخر. وكان التحدي التالي هو الحفاظ على تلك النتائج مع جعل البرمجيات أسهل في النشر والصيانة.
بحلول ذلك الوقت، كانت Codex قد نمت في قدراتها. اختبر أحد مهندسي النشر الميداني إعادة بناء تطبيقه حولها، ثم عمل مع الفريق على نقل حالات الاستخدام إلى منصة مشتركة تقوم Codex على جوهرها.
أصبحت التطبيقات المخصصة إضافات ومهارات مبنية على العناصر الأساسية المشتركة لـ Codex. وأصبحت Codex أيضًا الواجهة، مما سمح لنا بإشراة واجهات المستخدم الطرفية وأدوات سطر الأوامر CLIs المنفصلة التي كتبّاها لحالات استخدام فردية.
تمكّنا من إزالة نحو 90% من الشيفرة المخصصة من كل مشروع، وقد غيّر ذلك طريقة بنائنا لهذه المسارات العملية وصيانتها وتوسيع نطاقها:
تمكّنا من الاستفادة من التحسينات المركزية على Codex، مما قلل من حجم شيفرة الربط المطلوبة لكل حالة استخدام فردية
جُمعت الوظائف الرئيسية في مهارات وإضافات، مما جعل مشاركتها أسهل والتحكم فيها مركزيًا من قبل مركز التميز للذكاء الاصطناعي. هذا يعني أن التوسع من فريق إلى فريق آخر قد يكون بسيطًا كتبديل موصلات/خوادم MCP جديدة، وبناء تقييمات جديدة (كانت لدينا مهارة لذلك أيضًا) والانطلاق في العمل.
في أحد الأمثلة في أغسطس 2026، استغرق النشر الأولي شهرين. أما توسيع الحل ليشمل فريقًا ثانيًا فاستغرق يومًا واحدًا. وانضمت الفرق التالية بسرعة أكبر كلما توسعنا—وهذا ما استمر، حيث استغرقت حالة استخدام في أغسطس 2026 يومًا واحدًا (1) للفريق الثاني بعد أن استغرق النشر الأولي شهرين (2).
تلك هي إحدى صور جعل أنفسنا غير ضروريين. لقد رسّخ العمل الذي قمنا به للوصول إلى الإنتاج ما يهم. ومع تحسّن المنتج الأساسي، تمكّنا من استبدال جزء كبير من تنفيذنا المخصص مع الإبقاء على القيمة التي كان يقدمها.
لهذا السبب فإن الترتيب مهم. تتيح لنا النماذج اللغوية الكبيرة البناء بسرعة. استخدم تلك السرعة لتضع شيئًا ذا قيمة بين يدي المستخدمين، وتعلّم ما يصمد في الممارسة العملية، ثم وسّع نطاق ما ينجح.
ينطبق المبدأ نفسه على جميع المشاريع.
حضور OpenAI، منتجنا لوكلاء الصوت والدردشة للمؤسسات، نشأ من عمليات نشر حقيقية لدى العملاء. بدأ العمل مع Swarm(يفتح في نافذة جديدة) وتطوّر عبر واجهة برمجة تطبيقات الوكلاء Agents API، واليوم يعالج أحد العملاء الآن أكثر من نصف مكالماته بالذكاء الاصطناعي.
أدخلا تلك عمليات النشر إلى الإنتاج علّمنا أي المشاكل تحتاج إلى حل مخصص وأي العناصر الأساسية يمكن للفرق الأخرى استخدامها. أدخلنا تلك العناصر الأساسية إلى Presence، مما سهّل على المطورين أتمتة المسارات العملية الخاضعة للتنظيم دون إعادة بناء البنية التحتية الأساسية. وساعد كل عملية نشر في تشكيل المنتج ومنح العميل التالي نقطة انطلاق أفضل.
مع Thrive Holdings، عمل مهندسو النشر الميداني والباحثون في OpenAI جنبًا إلى جنب مع المهندسين والمحاسبين لبناء Tax AI لشركات المحاسبة التابعة لـ Crete. خلال مرحلته التجريبية، عالج Tax AI عدد 7,000 من الإقرارات الضريبية وزاد الإنتاجية بنحو 50%.
كانت واحدة من أصعب التحديات هي أتمتة الإقرارات الضريبية للعقارات المؤجرة، والتي تطلقت ستة أسابيع من العمل الهندسي ومراجعة الممارسين للوصول إلى دقة واسترجاع بنسبة 90%. وأنشأ هذا العمل أنماطًا قابلة لإعادة الاستخدام سهّلت توسيع Tax AI إلى جداول ضريبية معقدة أخرى.
تطبّق الفرق الآن النهج نفسه على مسك الدفاتر والتدقيق ودعم تكنولوجيا المعلومات—مما يبني أنظمة تتحسّن من خلال ملاحظات الممارسين والاستخدام في العالم الحقيقي.
سدّ فجوات الذكاء عند ظهورها
أحيانًا يتيح لنا منتج أفضل تبسيط ما بنيناه، لكن أحيانًا لا يستطيع النموذج نفسه بعد القيام بالمهمة.
إذا اكتفينا ببناء ما تجعله نماذج اليوم ممكنًا بالفعل، فلن نكشف عن فجوات الذكاء التي يحتاج قسم Research إلى سدّها لاحقًا. لذلك تبدأ الكثير من تعاملاتنا المهمة عند تلك الحدود مع العميل، بالتزام كل من FDE وقسم Research بالعمل على تجاوزها معًا.
كان قد سبق لنا تطوير منصة خدمة عملاء مع شركة اتصالات كبرى، وأرادوا توسيعها لتشمل الصوت.
شكّلت المكالمات الصوتية نحو 90% من حجم خدمة العملاء لديهم. وكانت هذه الحالات أكثر تكلفة في الاحتواء من المحادثات النصية، وجلبت مجموعة من التحديات التقنية الجديدة في رفع مستوى التعامل مع اللهجات والنبرة وزمن الاستجابة والدقة إلى مستوى الإنتاج. إن إنجاز ذلك بشكل صحيح كان سيُحدث فرقًا جوهريًا في أعمالهم.
أثناء مرحلة تحديد النطاق، حقق نموذجنا نحو 60% في التقييمات الأساسية التي استخدمناها لتقييم ما إذا كان قادرًا على أداء المهمة في بيئة الإنتاج. كنا قد بلغنا حدود قدراته. كان لا بد من تحسين استدعاء الدوال واتباع التعليمات في سيناريوهات خدمة العملاء.
شرحنا ذلك للعميل وأدخلنا فريق Research في العمل. عمل فريق FDE مع العميل لبناء المنصة وتحديد ما ينبغي على النموذج القيام به. ويعمل فريق Research على سد الفجوات في القدرات، حيث مكّنتنا نماذج اللقطات المتعاقبة من اختبار التقدم مقابل متطلبات العميل.
على مدى ستة أشهر، ارتفع الأداء في التقييمات الرئيسية من حوالي 60% إلى 80% ثم إلى أكثر من 90%، وصولاً إلى المستويات اللازمة للإنتاج.
نموذج الصوت الناتج يدعم الآن نشر ذلك العميل، وعمليات نشر مخصصة أخرى لخدمة العملاء، وعمليات النشر المُدارة من خلال Presence. ساعدت مشكلة وُاجهت في عمل أحد العملاء في تحديد تحسينات يمكن أن تخدم الكثيرين الآخرين.
كان لكل جزء أهميته. التزم العميل بالعمل على مشكلة لم يكن النموذج قادراً على حلها بعد. وبقي فريق FDE قريباً بما يكفي لصياغة تلك المشكلة وبناء المنصة وقيادة المشاركة من البداية إلى النهاية. وحسّن فريق Research القدرات الأساسية للنموذج.
هذا هو الإصدار الآخر من جعل أنفسنا غير ضروريين: المساعدة في تحويل مشكلة لا تستطيع نماذج اليوم حلها إلى قدرة تستطيع نماذج المستقبل تقديمها. ومردود عملنا يمتد إلى ما هو أبعد من الساعات التي نقضيها مع أي عميل واحد.
اذهب وابحث عن المشكلة الأصعب
انضممت إلى OpenAI للمساعدة في جعل الذكاء الاصطناعي مفيداً في عمل الناس اليومي. وهذا ما لا يزال يوجه الفريق. أقول غالباً للفريق إنه في معظم الحالات في تطوير نماذج LLM، ينطبق شفر أوكام—أي أن أبسط الحلول هو الأفضل. في شركة تُعرَّف بأبحاثها الرائدة وفي صناعة تتسم بالمبالغة، نريد أن نبني أشياء تعمل بشكل موثوق يمكن للناس في الميدان الاعتماد عليها.
الهدف هو أن تُحسّن كل مشاركة ما يأتي بعد ذلك: منتج يسهل نشره، أو نموذج قادر على التعامل مع مهمة أصعب، أو عمل مخصص أقل للعميل التالي.
إذا كانت لديك مشكلة صعبة تريد حلها، فسنكون سعداء بالعمل معك. وإذا أردت المساعدة في حل تلك المشكلات، فسنكون سعداء بانضمامك إلينا.
فماذا نفعل إذا كان Codex قادراً على إنجاز العمل الذي أمضينا شهوراً في بنائه؟
اذهب وابحث عن المشكلة الأصعب.