OpenAI میں فارورڈ ڈیپلائڈ انجینئر کا کردار

جب Codex آیا، تو ٹیم میں کسی نے مجھ سے پوچھا، ”جب Codex ایک ہی کوشش میں وہ کام کر سکے جن کے لیے ہم گزشتہ چند ماہ سے نظام بنا رہے تھے، تو ہم کیا کریں گے؟“

یہ سوال OpenAI میں فارورڈ ڈیپلائڈ انجینئر کے کردار کی اصل بات تک پہنچتا ہے. ہم کلائنٹس کے ساتھ مل کر ان کے مشکل ترین مسائل سمجھتے ہیں اور ایسے حل بناتے ہیں جن پر وہ بھروسا کر سکیں. ہم جو سیکھتے ہیں، وہ ہماری مصنوعات کی تشکیل میں مدد دیتا ہے اور تحقیقی ٹیم کو حل کرنے کے لیے ٹھوس مسائل فراہم کرتا ہے.

یہی پیش رفت ہے. اگر ہر دو ایک ماہ میں ہم اپنے کام میں اپنی ضرورت ختم کر دیں، تو اس کا مطلب ہے کہ ہماری فارورڈ ڈیپلائڈ انجینئر ٹیم اپنا کام کر رہی ہے.

میں نے 2025 کے اوائل میں یہ ٹیم اس فرق کو ختم کرنے کے لیے بنائی جسے ہم ”تعیناتی کا خلا“ کہتے ہیں: یعنی ماڈل بظاہر جو کچھ کر سکتے ہیں اور لوگ اپنے کام میں بھروسے کے ساتھ جو کچھ استعمال کر سکتے ہیں، ان کے درمیان فاصلہ.

ماڈل کی صلاحیتیں، انہیں استعمال میں لانے کے لیے درکار نظاموں اور طریقۂ کار سے زیادہ تیزی سے آگے بڑھی ہیں. کبھی اس کمی کو پورا کرنے کے لیے ایک مصنوعات درکار ہوتی ہے. کبھی ماڈل معیاری جانچ میں اچھا کام کرتا ہے، لیکن حقیقی زندگی کے بدلتے عوامل اور پابندیوں کے ساتھ وہ کام نہیں کر پاتا.

ہم کلائنٹس کے مشکل ترین مسائل پر توجہ دیتے ہیں. جہاں ہمارے ماڈل آج یہ کام کر سکتے ہیں، وہاں ہم مصنوعات کی ٹیم اور کلائنٹ کے ساتھ مل کر حل کو بار بار استعمال کے قابل بناتے ہیں. جہاں وہ کم پڑتے ہیں، وہاں ہم کلائنٹس اور تحقیقی ٹیم کے ساتھ مل کر کمی واضح کرتے ہیں اور بہتری لاتے ہیں. ہمارا مقصد ہے کہ ہر منصوبہ اگلے کلائنٹ کو آغاز کے لیے بہتر بنیاد دے. اگر ہم بنیادی معیار اتنا بلند کر دیں کہ اگلی بار اسی نوعیت کا مسئلہ حل کرنے کے لیے کلائنٹس کو فارورڈ ڈیپلائڈ انجینئروں کی ضرورت نہ ہو، تو ہم نے اپنا کام بخوبی کیا ہے.

لیکن اکثر مسائل کی حدود واضح نہیں ہوتیں، درست نتیجے کی کوئی مسلمہ کسوٹی نہیں ہوتی، اور کوئی طے شدہ طریقہ بھی موجود نہیں ہوتا. ہر شخص کچھ ایسا بنانا چاہتا ہے جو پہلے کبھی موجود نہ رہا ہو. مگر وہاں تک پہنچنے کے لیے جو کچھ کرنا پڑتا ہے، اس پر کم لوگ آمادہ ہوتے ہیں.

باصلاحیت فارورڈ ڈیپلائڈ انجینئر تلاش کرنے اور ”قابلِ قبول“ معیار کو مسلسل بلند کرنے کے لیے مسلسل تجربات کرنا اور انہیں عملی جامہ پہنانا ضروری رہا ہے.

فارورڈ ڈیپلائڈ انجینئر ٹیم کی ہر نشست کے آغاز میں، میں ایک سلائیڈ دکھاتا ہوں جس پر ایک بنیادی اصول ہوتا ہے: ”مطلوبہ نتیجے سے آغاز کریں، کامیابی کے لیے جو ضروری ہو وہ کریں، پھر اسے بڑے پیمانے پر لے جائیں“.

ایک متاثر کن نمائشی نمونہ خاصی مقبولیت حاصل کر سکتا ہے، اس سے پہلے کہ کوئی پوچھے کہ آیا یہ حقیقی دنیا میں بھی کام کرتا ہے.

ہمارا کام کلائنٹ کا مسئلہ ایسے معیار پر حل کرنا ہے جس کی عملی استعمال میں ہم ذمہ داری لے سکیں.

ہمارے فارورڈ ڈیپلائڈ انجینئروں کے لیے پہلے دن ہی صنعت سے واقف ہونا ضروری نہیں، مگر اسے سمجھنا ان کی ذمہ داری ہے.

کوڈنگ معاونین کی بدولت سافٹ ویئر تیزی سے بننے لگا ہے، اس لیے کلائنٹ کے کاروبار کو سمجھنا اور بھی اہم ہو گیا ہے. ہم اپنی ٹیموں میں وسیع عمومی مہارت رکھنے والوں اور مخصوص شعبوں کے ماہرین، دونوں کو شامل کرتے ہیں.

درست فیصلے کرنے کے لیے کافی علم اور موجودہ صورت حال سے متعلق مفروضوں پر سوال اٹھانے کے لیے کافی تجسس ضروری ہے.

مثلاً، حیاتیاتی علوم میں ہمارے فارورڈ ڈیپلائڈ انجینئروں کا سائنسی پس منظر انہیں ان محققین کا اعتماد حاصل کرنے میں مدد دیتا ہے جو ادویہ کی دریافت کے قبل از طبی آزمائش مرحلے میں کام کرتے ہیں، جیسے اہداف کی توثیق اور ترجیح بندی، جینی اظہار کا تجزیہ اور کیمیائی ترکیب کے راستوں کی ازسرنو تشکیل. یہ مہارت انہیں اس بارے میں باخبر رائے دینے کے قابل بناتی ہے کہ کام کے ان سلسلوں کو کیسے بہتر کیا جا سکتا ہے.

ہم دکھا چکے تھے کہ کام کے یہ سلسلے فائدہ پہنچا سکتے ہیں، لیکن ہر ایک کو دوسری ٹیم تک پہنچانے کے لیے اب بھی بہت زیادہ مخصوص انضمام درکار تھا. اگلا چیلنج یہ تھا کہ ان نتائج کو برقرار رکھتے ہوئے سافٹ ویئر کی تعیناتی اور دیکھ بھال کو آسان بنایا جائے.

تب تک Codex کی صلاحیت بڑھ چکی تھی. ایک فارورڈ ڈیپلائڈ انجینئر نے اسے بنیاد بنا کر اپنی ایپلی کیشن دوبارہ بنانے کا تجربہ کیا، پھر ٹیم کے ساتھ مل کر استعمال کے ان معاملات کو ایک مشترکہ ہارنیس پر منتقل کیا جس کے مرکز میں Codex تھا.

مخصوص ایپلی کیشنیں Codex کے مشترکہ بنیادی اجزا پر بنے پلگ اِنز اور مہارتوں میں بدل گئیں. Codex صارف رابطہ بھی بن گیا، جس سے ہم وہ الگ ٹرمینل صارف رابطے اور کمانڈ لائن رابطے ہٹا سکے جو ہم نے استعمال کے مختلف معاملات کے لیے لکھے تھے.

ہم ہر منصوبے سے تقریباً 90% مخصوص کوڈ ہٹا سکے، اور اس سے کام کے ان سلسلوں کو بنانے، برقرار رکھنے اور پھیلانے کا ہمارا طریقہ بدل گیا:

• ہم Codex میں مرکزی سطح پر ہونے والی بہتریوں سے فائدہ اٹھا سکتے تھے، جس سے استعمال کے ہر معاملے میں اجزا کو آپس میں جوڑنے کے لیے کم کوڈ درکار رہ گیا

• اہم افعال کو مہارتوں اور پلگ اِنز کی صورت میں یکجا کیا گیا، جس سے انہیں آپس میں بانٹنا اور مصنوعی ذہانت کے مرکزِ مہارت کے ذریعے مرکزی طور پر ان کا انتظام کرنا آسان ہو گیا. اس کا مطلب تھا کہ ایک ٹیم سے دوسری تک حل پہنچانا اتنا آسان ہو سکتا تھا کہ نئے کنیکٹر یا ایم سی پی سرور لگائے جائیں، نئی جانچیں بنائی جائیں، جن کے لیے بھی ہمارے پاس ایک مہارت موجود تھی، اور کام شروع کر دیا جائے.

• اگست 2026 کی ایک مثال میں، ابتدائی تعیناتی میں دو ماہ لگے. اسی حل کو دوسری ٹیم تک پہنچانے میں ایک دن لگا. جیسے جیسے ہم دائرہ بڑھاتے گئے، اگلی ٹیموں کو شامل کرنے میں کم وقت لگنے لگا. یہ سلسلہ جاری رہا: اگست 2026 کے ایک معاملے میں، ابتدائی تعیناتی کے دو ماہ کے مقابلے میں دوسری ٹیم کے لیے صرف ایک دن لگا.

یہ اپنے کام میں اپنی ضرورت ختم کر دینے کی ایک صورت ہے. نظام کو عملی استعمال تک پہنچانے کے لیے کیے گئے کام نے واضح کر دیا تھا کہ کیا چیز اہم ہے. بنیادی مصنوعات میں بہتری کے ساتھ، ہم اپنے مخصوص نفاذ کا بڑا حصہ بدل سکے، اور اس سے ملنے والا فائدہ بھی برقرار رہا.

اسی لیے ترتیب اہم ہے. LLM ہمیں تیزی سے بنانے دیتے ہیں. اس رفتار سے فائدہ اٹھا کر صارفین کو کوئی کارآمد چیز دیں، جانیں کہ عملی استعمال میں کیا مؤثر رہتا ہے، اور پھر جو کامیاب ہو اسے بڑے پیمانے پر پھیلائیں.

یہی اصول ہر اشتراکی منصوبے پر لاگو ہوتا ہے.

کبھی بہتر مصنوعات ہمیں اپنے بنائے ہوئے نظام کو سادہ بنانے دیتی ہے، لیکن کبھی خود ماڈل ہی ابھی وہ کام نہیں کر سکتا.

اگر ہم صرف وہی بنائیں جو آج کے ماڈل پہلے ہی ممکن بناتے ہیں، تو ہمیں ذہانت کی صلاحیت میں ان کمیوں کا پتہ نہیں چلے گا جنہیں تحقیقی ٹیم کو آگے دور کرنا ہے. اسی لیے ہمارے بہت سے اہم منصوبے انہی حدود سے شروع ہوتے ہیں، اور کلائنٹ، فارورڈ ڈیپلائڈ انجینئر اور تحقیقی ٹیم مل کر ان سے آگے بڑھنے کا عزم کرتے ہیں.

ہر حصے کی اہمیت تھی. کلائنٹ نے ایسے مسئلے پر کام کرنے کا عزم کیا جسے ماڈل ابھی حل نہیں کر سکتا تھا. فارورڈ ڈیپلائڈ انجینئر نے کلائنٹ کے ساتھ قریبی رابطہ رکھا، تاکہ مسئلے کی واضح صورت متعین کر سکے، پلیٹ فارم بنا سکے اور شروع سے آخر تک منصوبے کو آگے بڑھائے. تحقیقی ٹیم نے بنیادی ماڈل کی صلاحیتوں کو بہتر بنایا.

یہ اپنی ضرورت ختم کر دینے کی دوسری صورت ہے: آج کے ماڈل جس مسئلے کو حل نہیں کر سکتے، اسے ایسی صلاحیت میں بدلنے میں مدد دینا جو مستقبل کے ماڈل فراہم کر سکیں. ہمارے کام کا فائدہ ان گھنٹوں سے کہیں آگے جاتا ہے جو ہم کسی ایک کلائنٹ کے ساتھ گزارتے ہیں.

میں نے OpenAI میں اس لیے شمولیت اختیار کی تھی کہ مصنوعی ذہانت کو لوگوں کے روزمرہ کام میں مفید بنانے میں مدد دوں. آج بھی یہی مقصد ٹیم کی رہنمائی کرتا ہے. میں اکثر ٹیم سے کہتا ہوں کہ LLM کی تیاری میں زیادہ تر معاملات پر اوکام کا اصول لاگو ہوتا ہے: سب سے سادہ حل ہی بہترین ہوتا ہے. ہم ایک ایسی کمپنی میں ہیں جس کی پہچان اس کی جدید ترین تحقیق ہے، اور ایک ایسی صنعت میں جہاں مبالغہ آرائی عام ہے. ہم ایسی چیزیں بنانا چاہتے ہیں جو بھروسے کے ساتھ کام کریں اور عملی میدان میں کام کرنے والے لوگ ان پر انحصار کر سکیں.

مقصد یہ ہے کہ ہر منصوبہ اگلے کام کو بہتر بنائے: ایسی مصنوعات جس کی تعیناتی آسان ہو، ایسا ماڈل جو زیادہ مشکل کام سنبھال سکے، یا اگلے کلائنٹ کے لیے کم مخصوص کام کی ضرورت.

اگر آپ کوئی مشکل مسئلہ حل کرنا چاہتے ہیں، تو ہمیں آپ کے ساتھ کام کرکے خوشی ہوگی. اگر آپ ان مسائل کو حل کرنے میں مدد دینا چاہتے ہیں، تو ہم چاہیں گے کہ آپ ہمارے ساتھ شامل ہوں.

تو جب Codex وہ کام سنبھال سکتا ہو جس کا نظام بنانے میں ہم نے مہینے لگائے، تو ہم کیا کریں؟

کوئی زیادہ مشکل مسئلہ تلاش کریں.