کوئی جادوئی جملہ نہیں ہے۔ کوئی پوشیدہ کمانڈ کسی بڑے لینگویج ماڈل کو غیب دان (oracle) نہیں بنا سکتی، اور نہ ہی کوئی خفیہ پری فکس (prefix) کلاڈ (Claude) کو اچانک آپ کے کاروبار کو آپ سے بہتر سمجھنے میں مدد دے گا۔ پرامپٹ انجینئرنگ کسی کوڈ کو توڑنے کا نام نہیں ہے۔ یہ ایک انتہائی قابل ساتھی کے ساتھ واضح طور پر بات چیت کرنے کا نظم و ضبط ہے جس نے انٹرنیٹ کے وسیع حصوں کو پڑھا ہے لیکن وہ آپ سے کبھی ملا نہیں، آپ کا دفتر نہیں دیکھا، یا آپ کی پروڈکٹ کی پیشکش نہیں سنی۔ کلاڈ کے ساتھ ایک نئے ذہین ملازم کی طرح پیش آئیں جو اپنے پہلے دن پر ہے۔ وہ مدد کرنے کے لیے پرجوش ہے، لیکن اگر آپ مبہم ہدایات دیں گے، تو آپ کو مبہم نتائج ہی ملیں گے۔ یہی اصول یہاں بھی لاگو ہوتا ہے جیسا کہ کسی بھی دفتر میں ہوتا ہے: کچرا اندر، کچرا باہر (garbage in, garbage out)۔
کلاڈ کے ساتھ ایک نئے ملازم کی طرح پیش آئیں
تصور کریں کہ آپ ایک باصلاحیت ٹھیکیدار کو کام پر رکھ رہے ہیں۔ آپ پہلے ہی دن جا کر کبھی یہ نہیں کہیں گے کہ "ویب سائٹ ٹھیک کر دو،" اور پھر وہاں سے چلے جائیں گے۔ وہ ہدایت بے کار ہے۔ کون سا صفحہ؟ کیا خراب ہے؟ سامعین کون ہیں؟ کامیابی کیسی نظر آتی ہے؟ اس کے باوجود لوگ روزانہ AI کے لیے "ویب سائٹ ٹھیک کر دو" کے برابر الفاظ ٹائپ کرتے ہیں اور حیران ہوتے ہیں کہ نتیجہ کیوں درست نہیں آیا۔
اس مفروضے سے آغاز کریں کہ کلاڈ کو آپ کی مخصوص صورتحال کے بارے میں کوئی معلومات نہیں ہیں۔ وہ گرامر، کوڈنگ کے پیٹرنز اور تاریخ جانتا ہے، لیکن وہ آپ کی کمپنی کا لہجہ، آپ کے صارفین کے مسائل، یا آپ کی قانونی پابندیوں سے واقف نہیں ہے جب تک کہ آپ انہیں واضح طور پر بیان نہ کر دیں۔ اچھا پرامپٹنگ دراصل اچھی مینجمنٹ ہے۔ آپ حدود مقرر کر رہے ہیں، سامعین کی تعریف کر رہے ہیں، اور مطلوبہ کام (deliverable) کو واضح کر رہے ہیں۔ اگر آپ یہ اچھے طریقے سے کریں گے، تو ماڈل کا موجودہ علم اچانک مفید ہو جائے گا۔
ایک مضبوط پرامپٹ کے پانچ حصے
ہر پیشہ ورانہ پرامپٹ میں پانچ الگ الگ عناصر ہونے چاہئیں۔ آپ کو ہر ایک کے لیے مضمون لکھنے کی ضرورت نہیں ہے، لیکن "انٹر" دبانے سے پہلے آپ کو ان تمام کا ذکر کرنا چاہیے۔
Role (کردار)
ماڈل کو بتائیں کہ وہ کون ہے۔ یہ الفاظ کے چناؤ، نقطہ نظر اور ترجیحات کو تشکیل دیتا ہے۔ "آپ ایک ٹیکنیکل ایڈیٹر ہیں" کام کر سکتا ہے، لیکن "آپ ایک ٹیکنیکل ایڈیٹر ہیں جو ان fintech ڈویلپرز کے لیے API ڈاکومنٹیشن کو آسان بناتے ہیں جو blockchain کے لیے نئے ہیں" کہیں زیادہ بہتر کام کرتا ہے۔ کردار جتنا مخصوص ہوگا، نتیجہ اتنا ہی بہتر ہوگا۔
Context (سیاق و سباق)
منظر نامے کی وضاحت کریں۔ اسے کون پڑھ رہا ہے؟ مقصد کیا ہے؟ ہسپتال کے منتظمین کے لیے سائبر سیکیورٹی کے بارے میں ایک بلاگ پوسٹ کا لہجہ ان نوجوان گیمرز کے لیے لکھی گئی پوسٹ سے بالکل مختلف ہونا چاہیے۔ سیاق و سباق میں خطرات (stakes) بھی شامل ہیں۔ کیا آپ صرف آئیڈیاز سوچ رہے ہیں، یا یہ وہ حتمی مسودہ ہے جو منظرِ عام پر آئے گا؟
Task (کام)
درست افعال (verbs) استعمال کریں۔ "بہتر کریں"، "اضافہ کریں" یا "بہتر بنائیں" جیسے مبہم الفاظ سے پرہیز کریں۔ ان کا کوئی مطلب نہیں ہے۔ اس کے بجائے لکھیں: "اس ٹرانسکرپٹ کا تین بلٹ پوائنٹس میں خلاصہ کریں، جن میں سے ہر ایک 20 الفاظ سے کم ہو۔" یا: "اس فنکشن کو async/await استعمال کرنے کے لیے ریفیکٹر (refactor) کریں اور ٹائم آؤٹ کے لیے ایرر ہینڈلنگ شامل کریں۔" کام آپ کا حکم ہے، اس لیے اسے ایک خواہش کے بجائے ایک حکم بنائیں۔
Format (فارمیٹ)
کلاڈ کے لکھنا شروع کرنے سے پہلے جواب کی شکل متعین کریں۔ کیا آپ کو نمبروں والی فہرست چاہیے، markdown ٹیبل، درست JSON، سبجیکٹ لائن کے ساتھ ای میل، یا کوئی قانونی دستاویز؟ اگر آپ کو مخصوص کالموں کے ساتھ موازنہ کرنے والا ٹیبل چاہیے، تو ان کے نام لیں۔ اگر آپ چاہتے ہیں کہ آؤٹ پٹ کمنٹس کے ساتھ ایک کوڈ بلاک میں ہو، تو ایسا ہی کہیں۔ فارمیٹنگ کی ہدایات آپ کو اس وقت عبارتوں کے ڈھیر سے بچاتی ہیں جب آپ کو منظم ڈیٹا کی ضرورت ہو۔
Constraints (حدود و قیود)
ان چیزوں کی فہرست بنائیں جن سے بچنا ہے۔ اس میں لہجہ، لمبائی، ممنوعہ الفاظ اور ممنوعہ موضوعات شامل ہیں۔ مثال کے طور پر: "جواب کو 150 الفاظ سے کم رکھیں۔ بات چیت والا لہجہ استعمال کریں۔ لفظ 'synergy' استعمال نہ کریں۔ ایسے حل تجویز کرنے سے گریز کریں جن کے لیے 500 ڈالر سے زیادہ کا بجٹ درکار ہو۔" حدود دراصل حفاظتی رکاوٹیں (guardrails) ہیں۔ ماڈل ان پر اچھی طرح عمل کرتا ہے، لیکن صرف تب جب آپ انہیں واضح طور پر بیان کریں۔
بہتر نتائج کے لیے چار تکنیکیں
جب آپ بنیادی باتیں سیکھ لیں، تو آپ چند جدید طریقوں سے اپنے انداز کو مزید بہتر بنا سکتے ہیں۔ ان میں سے کسی کے لیے بھی خصوصی تربیت کی ضرورت نہیں ہے۔ یہ محض آپ کی سوچ کو اس طرح ترتیب دینے کے طریقے ہیں تاکہ ماڈل اس پر عمل کر سکے۔
پیچیدہ کام کو مراحل میں تقسیم کریں
ایک ہی بار میں سب کچھ نہ مانگیں۔ اگر آپ کو مارکیٹنگ مہم چاہیے، تو سامعین کے تجزیے سے شروع کریں۔ اس کے نتیجے کا جائزہ لیں، پھر پیغام (messaging) کے بارے میں پوچھیں۔ پھر چینل کے انتخاب کے بارے میں پوچھیں۔ یہ مرحلہ وار طریقہ آپ کو شروع میں ہی غلطیوں کو پکڑنے میں مدد دیتا ہے۔ یہ ماڈل کو ایک ہی بار میں دس مختلف ضروریات کو متوازن کرنے کی کوشش میں الجھنے سے بھی بچاتا ہے۔ کوڈنگ کے کاموں کے لیے، پہلے architecture کے بارے میں پوچھیں، پھر اس کے implementation کے بارے میں، اور پھر tests کے بارے میں۔ ہر مرحلہ پچھلے مرحلے پر مبنی ہوتا ہے، اور آپ کنٹرول میں رہتے ہیں۔
استدلال کا مطالبہ کریں
Chain-of-thought prompting کا سادہ مطلب یہ ہے کہ کلاڈ (Claude) سے حتمی جواب دینے سے پہلے اپنا کام دکھانے کا کہا جائے۔ "اپنے استدلال پر مرحلہ وار غور کریں، پھر اپنا نتیجہ دیں" جیسے جملے منطقی مسائل، ریاضی، اور کوڈنگ ڈیبگنگ کے لیے حیرت انگیز طور پر کارآمد ثابت ہوتے ہیں۔ جب آپ دیکھ سکتے ہیں کہ ماڈل کس طرح ایک جواب تک پہنچا، تو آپ اس لمحے کو درست طور پر پہچان سکتے ہیں جب اس نے کسی ضرورت کو غلط سمجھا یا ڈیٹا سیٹ سے غلط ویلیو لی۔ یہ ایک 'بلیک باکس' کو ایسی چیز میں بدل دیتا ہے جس کا آپ آڈٹ کر سکتے ہیں۔
معلومات کو الگ کرنے کے لیے XML ٹیگز کا استعمال کریں
جب کسی پرومپٹ میں متن کے بڑے بلاکس شامل ہوں، تو ماڈل اصل مواد کو ہدایات کے ساتھ خلط ملط کر سکتا ہے۔ مختلف حصوں کو <context>، <task>، یا <example> جیسے ٹیگز میں لپیٹ دیں۔ مثال کے طور پر:
یہ ڈھانچہ ایک دستاویز میں ہیڈنگز کی طرح کام کرتا ہے۔ یہ ماڈل کو غلطی سے آپ کے پس منظر کی معلومات کو کام کا حصہ سمجھنے سے روکتا ہے، اور یہ طویل پرومپٹس کو بعد میں ایڈٹ کرنا آسان بناتا ہے۔
صرف بتائیں نہیں، دکھائیں
Few-shot prompting کا مطلب ہے کہ آپ جس اسٹائل یا فارمیٹ کو چاہتے ہیں اس کی دو سے چار مثالیں دیں۔ ماڈلز پیٹرن میچنگ انجن ہیں۔ وہ اکثر گہری تفصیلات کے بجائے مثالوں سے تیزی سے سیکھتے ہیں۔ اگر آپ میٹنگ کے نوٹس کو ایکشن آئٹمز میں تبدیل کرنا چاہتے ہیں، تو خام نوٹس کی دو مثالیں دیں اور اس کے بعد وہ درست ساخت شدہ آؤٹ پٹ دیں جس کی آپ توقع کرتے ہیں۔ کلاڈ نئے ان پٹ پر حیرت انگیز درستگی کے ساتھ اس پیٹرن سے میل کھا لے گا۔ دس جملوں میں فارمیٹ بیان کرنا عام طور پر تین صاف ستھری مثالیں دکھانے کے مقابلے میں کم مؤثر ہوتا ہے۔
استعمال کے لیے تیار ٹیمپلیٹ
اگر آپ ایک خالی پرومپٹ باکس کو دیکھ کر پریشان ہیں، تو اس خاکے پر عمل کریں۔ ہر بریکٹ کو بھریں، چاہے جواب مختصر ہی کیوں نہ ہو۔
Role: [مخصوص کردار اور متعلقہ مہارت درج کریں] Context: [پس منظر، سامعین، اور مقصد درج کریں] Task: [کسی مضبوط فعل کا استعمال کرتے ہوئے درست عمل درج کریں] Format: [مطلوبہ ساخت درج کریں: فہرست، ٹیبل، مضمون، JSON، وغیرہ] Constraints: [لہجہ، لمبائی، ممنوعہ الفاظ، یا جن موضوعات سے بچنا ہے وہ درج کریں]
یہاں اس کا مکمل نمونہ دیا گیا ہے:
Role: آپ ایک B2B پے رول اسٹارٹ اپ میں پروڈکٹ مارکیٹنگ مینیجر ہیں۔ Context: ہم ایک ایسا فیچر لانچ کر رہے ہیں جو درمیانے درجے کی کمپنیوں کے لیے ریاستی ٹیکس فائلنگ کو خودکار بناتا ہے۔ سامعین وہ ایچ آر ڈائریکٹرز ہیں جو تعمیل (compliance) کی کاغذی کارروائیوں میں دبے ہوئے ہیں۔ مقصد انہیں ڈیمو بک کرنے پر آمادہ کرنا ہے۔ Task: 120 الفاظ پر مشتمل ایک ای میل لکھیں جو دستی فائلنگ کی مشکل سے شروع ہو اور 15 منٹ کی کال شیڈول کرنے کی نرم درخواست پر ختم ہو۔ Format: سبجیکٹ لائن، دو مختصر پیراگراف، اور کال ٹو ایکشن بٹن کا لیبل۔ Constraints: "synergy" یا "bandwidth" جیسی اصطلاحات استعمال نہ کریں۔ لہجہ پیشہ ورانہ لیکن دوستانہ ہو۔ کوئی فجائی نشان (exclamation mark) استعمال نہ کریں۔
یہ پرومپٹ کلاڈ کو وہ سب کچھ فراہم کرتا ہے جس کی اسے ضرورت ہے۔ نتیجہ شاید مکمل طور پر پرفیکٹ نہ ہو، لیکن یہ اتنا قریب ہوگا کہ آپ کو اسے شروع سے لکھنے کے بجائے صرف ایڈٹ کرنا پڑے گا۔
اصل نچوڑ
آپ کو ہر ایک درخواست کے لیے پانچ حصوں کا شاہکار بنانے کی ضرورت نہیں ہے۔ "دالوں کی اچھی ترکیب کیا ہے؟" پوچھنے کے لیے کسی کردار یا XML ٹیگز کی ضرورت نہیں ہوتی۔ لیکن جب آؤٹ پٹ اہم ہو، جب کام پیچیدہ ہو، یا جب آپ کو لگاتار تین بار غلط جوابات مل چکے ہوں، تو اس چیک لسٹ پر عمل کریں۔ زیادہ تر ناکام پرومپٹس اس لیے ناکام ہوتے ہیں کیونکہ انسان ابھی تک صرف سوچ رہا ہوتا ہے۔ یہ فیصلہ کرنے کے لیے تیس سیکنڈ لیں کہ آپ اصل میں کیا چاہتے ہیں، یہ کس کے لیے ہے، اور یہ کیسا نظر آنا چاہیے۔ یہ سوچ پہلے ہی سوچ لیں، اور آپ جواب کو درست کرنے میں بہت کم وقت صرف کریں گے۔ واضح ہدایات سے واضح نتائج ملتے ہیں۔ باقی سب محض شور ہے۔