کسی لینگویج ماڈل سے پوچھیں کہ لفظ “strawberry” میں کتنے حروف ہیں۔ امکان ہے کہ وہ غلط جواب دے گا۔ وہ دس کہہ سکتا ہے۔ وہ گیارہ کا اندازہ لگا سکتا ہے۔ وہ مکمل اعتماد کے ساتھ جواب دے گا، لیکن پھر بھی غلط ہوگا۔ اسی ماڈل سے کسی قرض پر مرکب سود (compound interest) کا حساب لگانے، یا دو بڑے اعداد کو جمع کرنے، یا دو تاریخوں کے درمیان کاروباری دنوں (business days) کو گننے کے لیے کہیں، تو اکثر آپ کو ایک معقول نظر آنے والا جواب ملے گا جس کے ہندسے تھوڑے سے، لیکن خطرناک حد تک غلط ہوں گے۔
ایسا اس لیے ہوتا ہے کیونکہ بڑے لینگویج ماڈلز اعداد و شمار کے بارے میں اس طرح سوچتے نہیں ہیں جیسے انسان سوچتے ہیں۔ وہ ٹوکنز (tokens) کی پیش گوئی کرتے ہیں۔ ایک ٹوکن ایک پورا لفظ، لفظ کا حصہ، یا ایک ہندسہ ہو سکتا ہے۔ جب ماڈل “strawberry” دیکھتا ہے، تو وہ اسے ایک قطار میں لگے ہوئے آٹھ الگ الگ حروف کے طور پر نہیں دیکھتا۔ وہ اسے چند ٹکڑوں (chunks) کے طور پر دیکھتا ہے۔ اسے حروف گننا نہیں سکھایا گیا، بلکہ صرف یہ پیش گوئی کرنا سکھایا گیا ہے کہ متن کا اگلا ٹکڑا کون سا ہوگا۔ یہی حد ریاضی پر بھی لاگو ہوتی ہے۔ ماڈل کے پاس کوئی اندرونی کیلکولیٹر نہیں ہوتا۔ اس میں carry logic کی کمی ہوتی ہے۔ اسے مقام کی قیمت (place value) کی کوئی حقیقی سمجھ نہیں ہوتی۔ جب یہ 148 کو 279 سے ضرب دیتا ہے، تو یہ ضرب نہیں کر رہا ہوتا۔ بلکہ یہ اپنی تربیت کے دوران دیکھے گئے اسی طرح کے جملوں کے ساتھ پیٹرن میچنگ کر رہا ہوتا ہے، اور اندازہ لگا رہا ہوتا ہے کہ ہندسوں کا کون سا سلسلہ آگے آنا چاہیے۔ چھوٹے مجموعوں کے لیے پیٹرن اتنا مضبوط ہوتا ہے کہ کام چل جاتا ہے۔ لیکن جس میں اصل درستگی کی ضرورت ہو، وہاں اندازہ آخر کار غلط ہو جاتا ہے۔
دو کام، ایک بوٹ
عام پرومپٹنگ طریقے ایک ہی سسٹم سے ایک ہی وقت میں دو بہت مختلف کام کرنے کو کہتے ہیں۔ پہلا، مسئلے کی منطق (logic) کو سمجھنا۔ دوسرا، درست ریاضی کا عمل کرنا۔ ماڈل پہلے کام میں واقعی متاثر کن ہے۔ یہ ایک لفظی مسئلہ پڑھ سکتا ہے، متغیرات (variables) نکال سکتا ہے، تعلقات کا نقشہ بنا سکتا ہے، اور حل کا راستہ ترتیب دے سکتا ہے۔ لیکن پھر اسے خود اپنا کیلکولیٹر بننا پڑتا ہے۔ یہیں سے زنجیر ٹوٹ جاتی ہے۔ تیسرے مرحلے میں ایک بھی ہندسہ غلط ہو جائے تو اس کے بعد کے تمام مراحل متاثر ہو جاتے ہیں۔ منطق خود مکمل طور پر درست ہو سکتی ہے، پھر بھی حتمی جواب غلط ہوتا ہے کیونکہ ماڈل نے غلط جمع کیا ہوتا ہے۔
Program-Aided Language Models، یا PAL، کام کو تقسیم کر کے اس کا حل نکالتے ہیں۔ ماڈل سے جواب مانگنے کے بجائے، آپ اس سے ایک پروگرام مانگتے ہیں۔
یہاں یہ عمل درحقیقت کام کرتا ہے۔ آپ مسئلہ پیش کرتے ہیں۔ ماڈل منطق سمجھتا ہے، متغیرات (variables) کی تعریف کرتا ہے، اور الگورتھم کی ساخت تیار کرتا ہے۔ پھر، خود نتیجہ نکالنے کے بجائے، یہ ایک مختصر اسکرپٹ لکھتا ہے، جو عام طور پر Python میں ہوتا ہے۔ وہ اسکرپٹ ایک حقیقی code interpreter کے حوالے کر دیا جاتا ہے۔ انٹرپریٹر منطق کو چلاتا ہے اور بالکل درست، یقینی نتیجہ واپس کرتا ہے۔ ماڈل ریاضی کی وضاحت کرتا ہے۔ Python ریاضی کرتا ہے۔
عملی طور پر قابلِ عمل استدلال
PAL کو قابلِ عمل استدلال (executable reasoning) کے طور پر سمجھیں۔ اگر کوئی اسکرپٹ کسی مسئلے کو حل کر سکتا ہے، تو ماڈل کو اسکرپٹ لکھنے دیں۔
ایک ٹھوس مثال پر غور کریں۔ آپ کو ₹50,000 کی فکسڈ ڈپازٹ پر سالانہ 8.5 فیصد شرح سود کے ساتھ، سہ ماہی بنیادوں پر مرکب (compounded quarterly) ہونے والی رقم کا حساب لگانا ہے، جو سات سال کے لیے ہو۔ اگر آپ براہ راست کسی لینگویج ماڈل سے پوچھیں گے، تو ہو سکتا ہے کہ وہ ایک فارمولا لکھے، قیمتیں درج کرے، اور سوچ کے سلسلے (chain of thought) میں نتیجہ نکالے۔ لیکن اگر آپ غور سے دیکھیں، تو آپ کو معلوم ہو سکتا ہے کہ اس نے سہ ماہی کمپاؤنڈنگ کے لیے شرح کو غلط طریقے سے تقسیم کر کے غلطی کی ہے، یا کسی درمیانی مرحلے کو راؤنڈ (round) کر کے غلطی کو آگے بڑھا دیا ہے۔ جواب معقول لگتا ہے لیکن سینکڑوں روپے کا فرق ہوتا ہے۔
PAL کے ساتھ، تعامل بدل جاتا ہے۔ آپ ماڈل کو Python کوڈ تیار کرنے کی ہدایت دیتے ہیں جو principal = 50000, rate = 0.085, time = 7, اور n = 4 کی تعریف کرے، اور پھر amount = principal * (1 + rate/n) ** (n * time) کا حساب لگائے۔ ماڈل کوڈ فراہم کرتا ہے۔ ایک Python runtime اسے چلاتا ہے۔ آپ کو ہر بار آخری اعشاریہ تک بالکل درست رقم ملتی ہے۔ ضرب میں کوئی اندازہ نہیں ہوتا، کوئی فرضی باقی (remainder) نہیں ہوتا، اور کوئی پر اعتماد راؤنڈنگ کی غلطی نہیں ہوتی۔
یہی پیٹرن تاریخ کے حساب کتاب پر بھی لاگو ہوتا ہے۔ کسی ماڈل سے پوچھیں کہ آج سے ٹھیک 120 کاروباری دن (business days) بعد کون سی تاریخ آتی ہے، ہفتہ وار تعطیلات کو چھوڑ کر۔ صرف متن پر مبنی ماڈل آگے گنتی کرتے ہوئے کسی ہفتہ یا اتوار پر پھسل سکتا ہے۔ PAL کا طریقہ کار ماڈل کو datetime اور calendar کی منطق استعمال کرتے ہوئے ایک اسکرپٹ لکھنے کا کہتا ہے، اور پھر انٹرپریٹر کو بالکل درست طریقے سے عمل کرنے دیتا ہے۔ ڈیٹا کے استعمال (data manipulation) کا طریقہ بھی ایسا ہی ہے۔ اگر آپ کو کسی الجھے ہوئے CSV کو پارس کرنا ہو، یا کسی پیچیدہ JSON کو فلٹر کرنا ہو، یا کوئی فوری شماریاتی تبدیلی (statistical transform) کرنی ہو، تو ماڈل کو منطق کا خاکہ تیار کرنا چاہیے جبکہ انٹرپریٹر عمل درآمد سنبھالے۔
یہ حقیقت میں کیوں اہم ہے
نثر (prose) میں جوابات سے قابلِ عمل کوڈ کی طرف منتقلی تین عملی فوائد فراہم کرتی ہے۔
حتمیت۔ ایک لینگویج ماڈل سے اگر دو بار ایک ہی سوال پوچھا جائے تو وہ اپنے الفاظ بدل سکتا ہے یا کوئی ہندسہ تبدیل کر سکتا ہے۔ ایک انٹرپریٹر ہر بار ایک ہی ان پٹ کے لیے ایک ہی آؤٹ پٹ فراہم کرتا ہے۔ یہ استحکام اکاؤنٹنگ، لاجسٹکس، شیڈولنگ، اور کسی بھی انجینئرنگ کیلکولیشن میں انتہائی اہمیت رکھتا ہے جہاں تسلسل (consistency) کوئی اختیاری چیز نہیں ہے۔
تصدیق پذیری۔ جب کوئی ماڈل آپ کو استدلال کے تین پیراگراف فراہم کرتا ہے، تو آپ کو ایک غلط ہندسے کی تلاش کے لیے ہر جملہ پڑھنا پڑتا ہے۔ جب وہ آپ کو دس لائنوں کا اسکرپٹ دیتا ہے، تو آپ کوڈ کا جائزہ لے سکتے ہیں۔ آپ انٹرپریٹر کے چلنے سے پہلے ہی اس بات کی تصدیق کر سکتے ہیں کہ کمپاؤنڈ انٹرسٹ (compound-interest) کا فارمولا درست ہے۔ آپ ویری ایبل کے ناموں کا معائنہ کر سکتے ہیں، 'off-by-one' غلطیوں کو پکڑ سکتے ہیں، اور یہاں تک کہ حل کا ورژن کنٹرول (version-control) بھی کر سکتے ہیں۔ چھپی ہوئی غلطیوں کا امکان نمایاں طور پر کم ہو جاتا ہے۔
قابل اعتمادیت۔ ماڈل اپنے مقررہ دائرہ کار میں رہتا ہے۔ یہ وہی کرتا ہے جس کے لیے اسے بنایا گیا ہے: ساخت، مفہوم (semantics)، اور مسئلے کی تقسیم (problem decomposition) کے بارے میں استدلال کرنا۔ مشین وہی کرتی ہے جس کے لیے اسے بنایا گیا ہے: درست طریقے سے حساب کتاب کرنا۔ ذمہ داریوں کی یہی تقسیم (separation of concerns) وہ طریقہ ہے جس سے قابل اعتماد سافٹ ویئر کا ڈھانچہ تیار کیا جاتا ہے۔ کمپوزیشن (Composition)، مونو لیتھک ڈیزائن (monolithic design) سے بہتر ہے۔
اسے غیر قابل اعتماد کوڈ کے طور پر چلائیں
ایک احتیاطی تدبیر ضروری ہے۔ تیار کردہ کوڈ کو غیر قابل اعتماد ان پٹ تصور کیا جانا چاہیے۔ ماڈل ایک ایسا اسکرپٹ لکھ سکتا ہے جس میں انفینٹ لوپ (infinite loop)، کوئی غیر ضروری نیٹ ورک ریکویسٹ، یا فائل سسٹم کا ایسا آپریشن ہو جس کا آپ نے مطالبہ نہیں کیا تھا۔ ان پروگراموں کو ہمیشہ ایک الگ سینڈ باکس (sandbox) کے اندر چلائیں۔ محدود اختیارات والے کنٹینرز، بغیر نیٹ ورک رسائی کے سرور لیس فنکشنز، یا محدود سی پی یو (CPU) وقت اور بغیر مستقل اسٹوریج والے سخت کنٹرول شدہ ماحول کا استعمال کریں۔ یہاں سیکیورٹی کوئی ضمنی بات نہیں ہے۔ یہ سسٹم ڈیزائن کا حصہ ہے۔
جہاں PAL بہترین کام کرتا ہے، اور جہاں یہ رک جاتا ہے
PAL ریاضی، تاریخوں، اور منظم ڈیٹا کے استعمال (structured data manipulation) کے لیے بہترین کام کرتا ہے۔ یہ ان میکانیکی غلطیوں کو ختم کر دیتا ہے جو صرف ٹیکسٹ پر مبنی استدلال میں پیدا ہوتی ہیں۔
تاہم، یہ ناقص منطق (bad logic) کو درست نہیں کرتا۔ اگر ماڈل غلط فارمولا منتخب کرتا ہے،