OpenAI تكشف كواليس عمل فرق FDE: نحو 90% من الشيفرة المخصصة انتقلت إلى مهارات Codex

نشرت OpenAI تحليلًا لطريقة عمل مهندسيها من فئة forward deployed engineers (FDE). تشكّل الفريق في مطلع 2025 لمعالجة مشكلة محددة: النموذج قادر نظريًا على الكثير، لكن الناس لا يستطيعون بعد الاعتماد عليه في سير العمل. هذه هي «deployment gap». وهذه نتائج أربعة مشاريع: من 3–6 أشهر للوصول إلى الإنتاج في أشباه الموصلات، و+50% في الإنتاجية لدى محاسبي الضرائب، وارتفاع أداء نموذج صوتي من 60% إلى 90%+ في evals الرئيسية، ونحو 90% من الشيفرة المخصصة جرى التخلي عنها بعد صدور Codex.

يقول شعار الفريق: ابدأ بالنتيجة، وافعل كل ما يلزم لتتحقق، ثم وسّع النطاق لاحقًا. ويلاحظ إيغور أكيموف، صاحب قناة AI Product، أن الموردين يتحدثون بصوت واحد عن نماذج فائقة الذكاء، بينما تقلّ عمليات التبني في القطاعات العمودية. وبتقديره، فإن من يحرق التوكنات حاليًا في الغالب هم الشركات الناشئة على حساب غيرها. ويعمل مهندسو FDE تحديدًا حيث يجب سد هذه الفجوة يدويًا.

الرقائق والضرائب والاتصالات: أربع حالات بالأرقام

• هندسة أشباه الموصلات، منتصف 2025. عمل نحو 15 مهندس FDE على أكثر من 10 حالات استخدام: توليد الاختبارات، وتحديد أسباب الأعطال، ومساعد للهندسة المعمارية. يستهلك التحقق في هذا القطاع نحو 70% من جهد المشروع. وانضم بعض المهندسين إلى OpenAI قبل أيام قليلة من البدء ولم يكونوا يفقهون في الرقائق. جلسوا مع مهندسي العميل، ودرسوا المجال، وبنوا المقاييس معًا. خلال 3–6 أشهر وصلت جميع حالات الاستخدام إلى الإنتاج. النتيجة: توفير نحو 48% من الوقت في توليد الاختبارات، وزيادة وسيطة في الأداء بنسبة 22% عند تحسين النوى، وتحولت أسابيع من تصحيح الأخطاء إلى ساعات.
• الانتقال إلى Codex. عندما نضج Codex، نُقلت كل حالات الاستخدام إلى بنية ربط مشتركة يتوسطها Codex. تحولت التطبيقات المخصصة إلى إضافات (plugins) ومهارات (skills)، وجرى التخلي عن واجهات CLI والواجهات الخاصة. وسقط في كل مشروع نحو 90% من الشيفرة المخصصة. استغرق التنفيذ الأول في إحدى الحالات شهرين، أما التوسع إلى فريق ثانٍ فاستغرق يومًا واحدًا.
• الذكاء الاصطناعي الضريبي لشركات المحاسبة التابعة لـ Thrive Holdings. عولج في التجربة التجريبية 7 000 إقرار ضريبي، وارتفعت الإنتاجية بنحو 50%. وكانت الإقرارات المتعلقة بصفقات العقارات الأصعب: 6 أسابيع من العمل الهندسي والمراجعة على يد ممارسين للوصول إلى 90% في precision وrecall.
• الصوت لقطاع الاتصالات. يشكّل الصوت نحو 90% من طلبات الدعم. وسجّل النموذج نحو 60% في evals الرئيسية، وهذا غير كافٍ للإنتاج. جرى إشراك فريق Research: خلال 6 أشهر رُفعت النتيجة إلى 80%، ثم إلى 90%+. ويعمل هذا النموذج الصوتي الآن لدى عملاء آخرين أيضًا.

الشيفرة المخصصة تعيش نصف عام

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

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

والاستنتاج مباشر بالنسبة لاقتصاديات التوكنات. فما دامت طبقة المنطق المكتوب يدويًا تنمو حول النموذج، تنمو معها تكاليف الصيانة، ويزداد خطر أن تقدّم المنصة الشيء نفسه جاهزًا بعد نصف عام. وقد اعتمد الفريق ذلك مبدأً عمليًا: معيار نجاح مهندس FDE أن يجعل نفسه غير ضروري كل شهرين تقريبًا. وعندما صار Codex قادرًا على بناء ما كان المهندسون يبنونه على مدى أشهر دفعة واحدة، حصل سؤال «ماذا نفعل» على جواب بسيط: ابحث عن مهمة أكثر تعقيدًا.

ما الذي يجب أن يأخذه المُدمج

هناك ثلاثة أصول طويلة الأمد: معرفة المجال، ومجموعات البيانات والمقاييس التي بُنيت مع خبراء العميل، وفهم المواضع التي لا يقدر فيها النموذج على الإنجاز. وتؤكد حالة الضرائب ذلك: فنسبة 90% في precision وrecall على صفقات العقارات لم تحققها الميزات، بل ستة أسابيع من المراجعة على يد ممارسين. وتُظهر حالة الصوت الأمر نفسه من زاوية أخرى: فالانتقال من 60% إلى 90%+ تطلّب إشراك Research. ومن هنا تنبثق خطوات عملية لمدير المنتج والمُدمج:

• البدء بـ evals ومقاييس متفق عليها مع خبراء العميل، لا بالواجهة؛
• بناء الحل على لبنات المنصة الأساسية (المهارات والإضافات)، لا على واجهات CLI مكتوبة يدويًا؛
• الإبقاء على وكيل واحد مع مهارات ما دامت الأنظمة متعددة الوكلاء لم تثبت ضرورتها على المقاييس؛
• احتساب أن طبقة الربط ستحتاج إلى إعادة كتابة كل بضعة أشهر.

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