کمپنیاں AI ‘فارورڈ ڈیپلائڈ انجینئر’ (FDE) کی خدمات اس وقت حاصل کرتی ہیں جب انہیں کسی ایسے شخص کی ضرورت ہو جو گاہک کے کسی پیچیدہ یا الجھے ہوئے مسئلے کو لے کر اسے تیزی سے ایک فعال پروڈکٹ فیچر (product behavior) میں تبدیل کر سکے—اور یہ سب اعتماد، سیکیورٹی یا ڈیڈ لائنز (timelines) پر سمجھوتہ کیے بغیر ممکن بنائے۔ فارورڈ ڈیپلائڈ انجینئر (FDE) سے مراد وہ انجینئر ہے جو گاہکوں کے ساتھ براہِ راست کام کرتے ہوئے ان کے ماحول (environment) میں حل (solutions) فراہم کرتا ہے، اور پھر اپنے تجربات اور سیکھی ہوئی باتیں واپس پروڈکٹ ٹیم تک پہنچاتا ہے۔
اس صورتحال پر غور کریں۔ آپ AI FDE کے کردار کے لیے انٹرویو دے رہے ہیں اور انٹرویو لینے والا بار بار ایک مخصوص پروجیکٹ یا معاملے کا ذکر کر رہا ہے: ایک سپورٹ ٹیم جو اندرونی دستاویزات (internal docs) کی بنیاد پر پالیسی سے متعلق سوالات کے جواب دینے کے لیے AI اسسٹنٹ استعمال کرنے کی کوشش کر رہی ہے۔ یہاں اصل اور پوشیدہ امتحان یہ نہیں ہے کہ آیا آپ کسی ماڈل کی کوئی خاص تکنیک یا ‘ٹرک’ جانتے ہیں۔ بلکہ اصل امتحان یہ ہے کہ کیا آپ 30ویں دن بھی یہ کام کر سکتے ہیں جب ڈیٹا بے ترتیب ہو، سیکیورٹی ٹیم پریشان ہو، اور اسٹیک ہولڈر (stakeholder) چاہتا ہو کہ اگلے ہی ہفتے کوئی چیز فعال (live) ہو جائے۔
زیادہ تر معاملات میں، 90 دنوں کے اندر “کامیابی” کا مطلب چند ٹھوس اور حقیقی نتائج کا حصول ہوتا ہے۔ مثلاً، گاہک کے سسٹم (stack) میں پہلی کامیاب انٹیگریشن، معیار کا ایک قابلِ پیمائش معیار (measurable quality bar)، اور اس بات کا واضح منصوبہ کہ آگے کیا چیز فراہم (ship) کرنی ہے اور کس چیز کے لیے مزید پروڈکٹ ڈیولپمنٹ کی ضرورت ہے۔ انٹرویو کا مقصد یہ اندازہ لگانا ہوتا ہے کہ کیا آپ غیر حقیقی وعدے کیے بغیر اس مقام تک پہنچ سکتے ہیں۔
آئیے اس ‘صلاحیتوں کے نقشے’ (capability map) کا جائزہ لیں جو اکثر کمپنیوں کے پیشِ نظر ہوتا ہے۔
بھرتی کرنے کی بنیادی وجہ خطرات (risks) کو کم کرنا ہے۔ AI پروجیکٹ خاموشی سے ناکام ہو سکتا ہے، مثلاً ایسے غلط جوابات جو پراعتماد انداز میں دیے جائیں، یا کوئی ایسا انٹیگریشن (integration) جو ڈیمو میں تو کامیاب ہو جائے لیکن پروڈکشن میں ناکام ہو جائے۔ AI FDE سے توقع کی جاتی ہے کہ وہ ان خطرات کی جلد نشاندہی کرے اور انہیں ایسے فیصلوں میں تبدیل کرے جن پر گاہک (customer) رضامندی ظاہر کر سکے۔
سپورٹ اسسٹنٹ کی مثال میں، گاہک کی پہلی درخواست یہ ہوتی ہے کہ “ہماری دستاویزات (docs) استعمال کریں اور انسانوں کی طرح سوالات کے جواب دیں۔” آپ کا کام اسے ایسی چیز میں تبدیل کرنا ہے جسے عملی طور پر بنایا جا سکے، مثلاً “منظور شدہ ذرائع سے حاصل کردہ اقتباسات (snippets) کا استعمال کرتے ہوئے جواب دیں، ان کا حوالہ دیں، اور جب پالیسی واضح نہ ہو تو جواب دینے سے انکار کر دیں۔” Retrieval-augmented generation (RAG) میں دستاویزات کے مجموعے پر سرچ کا عمل استعمال کر کے متعلقہ متن (text) تلاش کیا جاتا ہے، اور پھر وہ متن ماڈل کو فراہم کیا جاتا ہے تاکہ جوابات تلاش کی گئی معلومات پر مبنی ہوں۔
90 دنوں میں کامیابی کا انحصار مواصلاتی عادات پر بھی ہوتا ہے۔ آپ گاہک کے ساتھ قریبی رابطہ رکھتے ہیں، مفروضوں (assumptions) کو تحریری شکل دیتے ہیں، اور سادہ زبان میں مختلف آپشنز کے درمیان موازنہ (tradeoffs) واضح کرتے ہیں۔ جب ماڈل غلطی کرتا ہے، تو آپ اسے محض ایک ‘احساس’ یا ‘اندازے’ کا مسئلہ سمجھنے کے بجائے، بنیادی وجہ (root cause) والے ایک واقعے (incident) کے طور پر دیکھتے ہیں۔
ڈیمو نہیں، نتائج فراہم کریں بھرتی کا عمل ایسے لوگوں کی تلاش میں رہتا ہے جو غیر یقینی صورتحال کو ایک واضح منصوبے (scoped plan) میں اور پھر گاہک کے ماحول میں چلنے والی کسی عملی چیز میں تبدیل کر سکیں۔
AI FDE کے انٹرویو کے زیادہ تر مراحل میں ان چیزوں کا امتزاج ہوتا ہے: “کیا آپ تعمیر کر سکتے ہیں؟”، “کیا آپ منطقی استدلال کر سکتے ہیں؟”، اور “کیا آپ دباؤ کے عالم میں لوگوں کے ساتھ کام کر سکتے ہیں؟” سپورٹ اسسٹنٹ کا وہی منظرنامہ ہر مرحلے میں سامنے آ سکتا ہے، بس مختلف زاویے سے۔
‘فریم ورکنگ’ (framing) یا ابتدائی مرحلے میں، آپ کی ‘ڈسکوری’ (discovery) یا معلومات کی تلاش کی صلاحیت کو پرکھا جاتا ہے۔ Discovery سے مراد بات چیت اور حقائق جاننے کا وہ ابتدائی عمل ہے جو ایک غیر واضح درخواست کو واضح تقاضوں اور حدود (constraints) میں بدل دیتا ہے۔ ایک مضبوط جواب کچھ یوں ہو سکتا ہے: “اسے کون استعمال کرے گا، درست جواب کسے سمجھا جائے گا، کون سا ڈیٹا استعمال کرنے کی اجازت ہے، اور جب ماڈل کو یقین نہ ہو تو کیا ہوگا؟”
سسٹم ڈیزائن کے مرحلے میں، آپ کی ‘آرکیٹیکچر’ (ڈھانچے) کے انتخاب اور ناکامی کے ممکنہ طریقوں (failure modes) کے بارے میں سمجھ بوجھ کو پرکھا جاتا ہے۔ اسسٹنٹ کے معاملے میں، اس کا مطلب یہ طے کرنا ہے کہ RAG کہاں چلے گا، ایمبیڈنگز (embeddings) کو کیسے محفوظ کیا جائے گا، رسائی کے کنٹرول (access control) کو کیسے سنبھالا جائے گا، اور کن چیزوں کا ریکارڈ (log) رکھا جائے گا۔ Single sign-on (SSO) کا مطلب ایک مرکزی شناختی نظام کے ذریعے لاگ ان ہونا ہے تاکہ ایک ہی لاگ ان کئی ایپس میں کام کر سکے؛ انٹرویو لینے والے اکثر یہ دیکھتے ہیں کہ آیا آپ نے اس بات پر توجہ دی ہے کہ دستاویز تک رسائی صارف کی شناخت سے مطابقت رکھتی ہو۔
کوڈنگ کے مرحلے میں، عام طور پر وقت کے دباؤ کے تحت انٹیگریشن (مختلف حصوں کو جوڑنے) کی صلاحیت اور درستگی کا امتحان لیا جاتا ہے۔ آپ کو ‘ریٹریول کال’ (retrieval call)، ‘پرامپٹ ٹیمپلیٹ’ (prompt template)، ‘رسپانس اسکیمہ’ (response schema)، یا ‘ایویلیوایشن ہارنس’ (evaluation harness) جیسے اجزاء تیار کرنے پڑ سکتے ہیں۔ اس میں ایک عام غلطی (یا جال) ایسا کوڈ لکھنا ہے جو صرف مثالی حالات (happy path) میں تو کام کرے لیکن ٹائم آؤٹس (timeouts)، دوبارہ کوششوں (retries) اور غلط ان پٹس (bad inputs) کو نظر انداز کر دے۔
کیس اسٹڈی میں، وہ ان تمام پہلوؤں کو یکجا کر کے آپ کی فیصلہ سازی کی صلاحیت کو پرکھتے ہیں۔ Proof of Concept (POC) سے مراد ایک چھوٹا سا تجربہ ہے جس کا مقصد یہ ثابت کرنا ہے کہ کوئی چیز کام کرتی ہے، نہ کہ اسے باقاعدہ پروڈکشن (production) میں لانچ کرنا۔ انٹرویو لینے والے آپ سے اس بارے میں تفصیل طلب کریں گے کہ آپ POC میں کیا کام کریں گے اور کسے مؤخر (defer) کریں گے، نیز یہ کہ آپ کسی سادہ پیمانے (metric) کے ذریعے اس کی افادیت یا قدر (value) کو کیسے ثابت کریں گے۔
کردار اور اسٹیک ہولڈرز (stakeholders) سے متعلقہ حالات میں، آپ کا امتحان اس بات پر ہوتا ہے کہ آیا آپ اپنے دائرہ کار اور حدود (boundaries) پر قائم رہ سکتے ہیں یا نہیں۔ آپ کو ایسے حالات کا سامنا کرنا پڑ سکتا ہے جیسے: “سیلز (Sales) ٹیم نے دو ہفتوں میں اس کی تکمیل کا وعدہ کیا تھا،” یا “سیکیورٹی ٹیم کا کہنا ہے کہ کوئی ڈیٹا VPC سے باہر نہیں جا سکتا۔” ایسی صورت میں آپ کا ردعمل الزام تراشی پر مبنی نہیں، بلکہ متبادل آپشنز اور ان کے ممکنہ نتائج (consequences) پر مشتمل ہونا چاہیے۔
ملاحظہ کریں کہ ایک عام عمل (loop) کس طرح مختلف مراحل (rounds) اور شواہد (evidence) کے لحاظ سے تقسیم ہوتا ہے۔