LLMs آپ کے کوڈ تک نہیں پہنچتے – وہ آپ کو ایک درخواست دیتے ہیں، اور آپ فنکشن چلاتے ہیں۔ یہ سادہ سی حقیقت اس غلط فہمی کو ختم کر دیتی ہے کہ "ماڈل جادوئی طور پر میرے Python روٹین کو کال کرتا ہے" اور ڈویلپرز کو ڈیبگنگ اور سیکیورٹی کے بارے میں دوبارہ سوچنے پر مجبور کرتی ہے۔
ڈسپچ لوپ (dispatch loop)، مرحلہ وار
جب ایک لینگویج ماڈل (LLM) کو کسی ٹول کی ضرورت ہوتی ہے، تو وہ ایک طے شدہ ترتیب (deterministic sequence) پر عمل کرتا ہے:
- Planning (منصوبہ بندی) – ماڈل فیصلہ کرتا ہے کہ ایک ایکشن کی ضرورت ہے (مثلاً، "ادائیگی واپس کرنا")۔
- Generating a request (درخواست تیار کرنا) – یہ ایک منظم متن (structured text)—عام طور پر JSON—آؤٹ پٹ کے طور پر دیتا ہے جس میں ٹول کا نام اور اس کے آرگومنٹ (arguments) درج ہوتے ہیں۔
- Parsing (تجزیہ کرنا) – آپ کی ایپ یا کوئی سپورٹنگ فریم ورک اس متن کو پڑھتا ہے۔
- Matching (موازنہ کرنا) – فریم ورک ان اصل فنکشنز کی رجسٹری میں نام تلاش کرتا ہے جو آپ نے فراہم کیے ہوتے ہیں۔
- Validating (تصدیق کرنا) – یہ چیک کرتا ہے کہ آیا آرگومنٹ فنکشن کے اسکیما (schema) سے مطابقت رکھتے ہیں اور کیا کال کرنے والا مجاز (authorized) ہے۔
- Executing (عمل درآمد) – میچ ہونے والا فنکشن آپ کے ماحول (environment) میں چلتا ہے اور کام انجام دیتا ہے۔
- Returning (واپسی) – نتیجہ پیک کیا جاتا ہے اور مزید استدلال (reasoning) کے لیے ماڈل کو واپس بھیج دیا جاتا ہے۔
LLM کو ایک منصوبہ ساز (planner)، فریم ورک کو ایک ڈسپچر (dispatcher)، اور فنکشن کو اس ورکر کے طور پر سمجھیں جو اصل میں ڈیٹا یا رقم منتقل کرتا ہے۔
"جادو" کی غلط فہمی کیوں برقرار ہے
زیادہ تر ڈویلپرز ماڈل کے آؤٹ پٹ کی ایک ایسی لائن دیکھتے ہیں جو فنکشن کال کی طرح نظر آتی ہے اور فرض کر لیتے ہیں کہ ماڈل نے خود ہی آپریشن انجام دے دیا ہے۔ فراہم کنندگان (providers) کی دستاویزات میں استعمال ہونے والی اصطلاح "tool calling" ایسا محسوس کراتی ہے جیسے ماڈل براہ راست کوڈ کو کال کر رہا ہو۔
حقیقت میں، ماڈل صرف ایسا متن تیار کرتا ہے جو ایک کال کی وضاحت کرتا ہے۔ اصل بھاری کام آپ کا پروسیس کرتا ہے—تلاش کرنا (lookup)، ٹائپ چیکنگ، اجازتوں کا نفاذ (permission enforcement)، اور ایرر ہینڈلنگ۔
فریم ورکس جو پیچیدہ عمل کو چھپا دیتے ہیں
PydanticAI اور LangChain جیسی لائبریریاں اس لوپ کو اس طرح سادہ (abstract) بنا دیتی ہیں کہ آپ بزنس لاجک پر توجہ مرکوز کر سکیں۔ وہ خودکار طور پر یہ کام کرتی ہیں:
- Validate arguments (آرگومنٹ کی تصدیق) ایک اسکیما (مثلاً، Pydantic ماڈل) کے خلاف کرتے ہیں۔
- Enforce permissions (اجازتوں کا نفاذ) کرتے ہیں، تاکہ اس بات کو یقینی بنایا جا سکے کہ صارف ٹول کو ٹرگر کرنے کا مجاز ہے۔
- Retry on failure (ناکامی پر دوبارہ کوشش) کرتے ہیں، جب کوئی ٹول ایرر واپس کرتا ہے تو ماڈل کے پاس دوبارہ لوپ کرتے ہیں۔
- Guard against runaway loops (بے قابو لوپس سے بچاؤ) کرتے ہیں، مسلسل ٹول کالز کی حد مقرر کرتے ہیں۔
- Maintain conversation state (گفتگو کی حالت برقرار رکھنا) کرتے ہیں، ٹول کے نتائج کو مکالمے میں شامل کرتے ہیں۔
ان مددگاروں کے باوجود، پیٹرن وہی رہتا ہے: ماڈل کبھی بھی کوڈ ایگزیکیوٹ نہیں کرتا۔
فراہم کنندگان کی طرف سے نیٹیو (native) ٹول کالنگ سپورٹ
کچھ فراہم کنندگان ایک "نیٹیو" ٹول کالنگ انٹرفیس فراہم کرتے ہیں جو ٹول کی تعریفوں اور درخواست کے فارمیٹس کو معیاری بناتا ہے۔ یہ انٹیگریشن کو آسان بناتا ہے لیکن ڈسپچ کے مرحلے کو ختم نہیں کرتا۔ آپ کو اب بھی وہ کوڈ لکھنا (یا امپورٹ کرنا) پڑتا ہے جو اصل میں مطلوبہ آپریشن چلاتا ہے۔
جب آپ مسئلے کا نام بدل دیتے ہیں تو ڈیبگنگ آسان ہو جاتی ہے
"الجھا ہوا ایجنٹ" (confused agent) کہنے کے بجائے، یہ کہیں کہ مسئلہ یہ ہے کہ "ماڈل کے جواب میں کوئی ٹول کال شامل نہیں تھی"۔ یہ فرق اہمیت رکھتا ہے:
- No tool call – ماڈل نے براہ راست جواب دیا یا صحیح فارمیٹ میں درخواست تیار کرنے میں ناکام رہا۔
- Malformed request – JSON کی ساخت (syntax) غلط ہے یا ضروری فیلڈز موجود نہیں ہیں، اس لیے ڈسپچر اسے مسترد کر دیتا ہے۔
- Validation failure – آرگومنٹ اسکیما سے مطابقت نہیں رکھتے، جس کی وجہ سے ایگزیکیوشن سے پہلے ہی ایرر آ جاتا ہے۔
ناکامیوں کی درجہ بندی کرنے سے آپ لوپ کے ہر مرحلے کو لاگ (log) کر سکتے ہیں اور یہ درست طور پر نشاندہی کر سکتے ہیں کہ چیزیں کہاں سے غلط ہوئیں۔
قابل اعتماد پائپ لائن کے لیے عملی مشورے
- ماڈل کے آؤٹ پٹ کو غیر قابل اعتماد ان پٹ سمجھیں۔ کسی بھی سائیڈ ایفیکٹ والے کوڈ کو کال کرنے سے پہلے ہر درخواست کو طے شدہ ویلیڈیشن (deterministic validation) سے گزاریں۔
- خام درخواست (raw request) اور ویلیڈیشن کے ہر مرحلے کے نتیجے کو لاگ کریں۔ یہ کچھ غلط ہونے کی صورت میں دوبارہ ٹریس کرنے کے لیے ایک ریکارڈ فراہم کرتا ہے۔
- مسلسل ٹول کالز پر واضح حد مقرر کریں؛ ایک بے قابو لوپ وسائل ختم کر سکتا ہے یا ریٹ لمٹس (rate limits) کو متاثر کر سکتا ہے۔
- ہر فنکشن کو try/except بلاک میں رکھیں جو ایک منظم ایرر آبجیکٹ واپس کرے جسے ماڈل سمجھ سکے، تاکہ دوبارہ کوشش یا بہتر متبادل (graceful fallback) کا راستہ مل سکے۔
- اجازتوں کی جانچ کو بزنس لاجک سے الگ رکھیں۔ فنکشن چلنے سے پہلے کال کرنے والے کے حقوق کی تصدیق کریں، خاص طور پر "delete user" جیسے حساس اقدامات کے لیے۔
- اسکیما پر مبنی تعریفیں استعمال کریں (مثلاً، Pydantic ماڈلز) تاکہ فریم ورک خودکار طور پر وہ JSON اسکیما تیار کر سکے جس پر ماڈل کو عمل کرنا ہوتا ہے۔
آگے کیا دیکھنا ہے
جیسے جیسے فراہم کنندگان نیٹیو ٹول کالنگ APIs کو بہتر بنا رہے ہیں، درخواست کے فارمیٹس کے حوالے سے سخت معاہدوں اور بہتر ایرر کوڈز کی توقع رکھیں۔ یہ تبدیلیاں ویلیڈیشن کو آسان بنائیں گی اور ڈویلپرز کو زیادہ سخت سیکیورٹی کے حفاظتی اقدامات (security fences) بنانے میں مدد دیں گی۔ لائبریری اپ ڈیٹس پر نظر رکھیں—بہت سی لائبریریاں نئے فراہم کنندگان کے فیچرز کے لیے بلٹ ان سپورٹ شامل کر رہی ہیں۔
خلاصہ
LLM ایک پیچیدہ ٹیکسٹ جنریٹر ہے، نہ کہ ایک ایگزیکیوٹر۔ آپ کا کوڈ ہی وہ واحد اتھارٹی ہے جو اقدامات انجام دیتا ہے، اور وہ ڈسپैچر (dispatcher) جو آپ بناتے ہیں (یا امپورٹ کرتے ہیں) وہ ایک گیٹ کیپر ہے جو ان اقدامات کی تصدیق، اجازت اور انہیں چلا کر دیکھتا ہے۔ ورک فلو کو نئے انداز میں ترتیب دینے سے "جادو" کا وہم ختم ہو جاتا ہے، ڈی بگنگ (debugging) بہتر ہوتی ہے، اور وہ سیکیورٹی ڈسپلن نافذ ہوتا ہے جس کی ہر پروڈکشن سسٹم کو ضرورت ہوتی ہے۔