AI انٹرویو سوال نمبر 2: بڑی زبان کے ماڈل (LLM) کے ٹول کالز کی وشوسنییتا کو کیسے یقینی بنایا جائے

بڑی زبان کے ماڈل (LLM) کو ٹول کالز میں قابل اعتماد اور کنٹرول شدہ طریقے سے کام کرنے کے لیے صرف پرامپٹس پر انحصار کرنا کافی نہیں ہے۔ اس کے لیے ایک کثیر سطحی پابندیوں کا فریم ورک درکار ہے۔

مثال کے طور پر موسم کی معلومات حاصل کرنے کے معاملے میں، ماڈل ٹول کالز میں تین عام "غلط" رویے دکھاتا ہے:
1. ٹول کو کال کیے بغیر براہ راست جواب گھڑنا۔
2. ٹول کو کال کرتے وقت غلط فارمیٹ کے پیرامیٹرز دینا (مثلاً ٹول "پرسوں" کو سپورٹ نہیں کرتا، لیکن پیرامیٹر date="پرسوں" بھیجنا)۔
3. اپنی مرضی سے پیرامیٹر فارمیٹ تبدیل کرنا (مثلاً "پرسوں" کو مخصوص تاریخ میں تبدیل کرنا)، حالانکہ ٹول کو اس کی ضرورت نہیں۔

مسئلے کی جڑ یہ ہے کہ ماڈل کی آؤٹ پٹ بنیادی طور پر احتمالی ہوتی ہے، اور پرامپٹس صرف احتمال کی تقسیم پر "نرم پابندیاں" لگاتے ہیں، نہ کہ کوئی لازمی طریقہ کار جو ماڈل کو سختی سے پابند کرے۔ پیچیدہ حالات میں یہ "نرم پابندیاں" آسانی سے ناکام ہو جاتی ہیں۔

اس مسئلے کو حل کرنے کے لیے ایک کثیر سطحی انجینئرنگ حل درکار ہے:

1. پہلی سطح: پرامپٹس کو بہتر بنانا (نرم پابندیاں)

   • یہ پابندیوں کے نظام کا نقطہ آغاز ہے، لیکن یقینی طور پر اختتام نہیں۔
   • پرامپٹ کو "آپریشنل معاہدہ" سمجھیں، جس میں ٹول کے استعمال، ہر پیرامیٹر کی قسم، حدود، اور غلط اقدار کی مثالیں واضح طور پر بیان کی جائیں۔
   • Few-shot مثالیں شامل کریں، جو "درست ان پٹ → درست کال" کی مثالیں دکھا کر سیاق و سباق کی تعلیم کے ذریعے ماڈل کے رویے کو مستحکم کریں۔

2. دوسری سطح: JSON Schema متعارف کروانا (سخت پابندیاں)

   • یہ "سمجھانے" سے "حد بندی کرنے" کی طرف اہم قدم ہے۔
   • قدرتی زبان میں پیرامیٹر کی وضاحت کی بجائے مشین کے ذریعے پڑھے اور تصدیق کیے جانے والے ساختی تعریف (JSON Schema) کا استعمال کریں۔ اس سے فیلڈ کی قسم، لازمی ہونے کی شرط، قابل قبول اقدار کی حد کو سختی سے بیان کیا جا سکتا ہے، اور additionalProperties: false سیٹ کر کے ماڈل کو کسی بھی غیر متعینہ فیلڈ کو آؤٹ پٹ کرنے سے روکا جا سکتا ہے۔
   • مرکزی API پلیٹ فارمز ماڈل کے ڈی کوڈنگ مرحلے میں ہی اس طرح کی ساختی آؤٹ پٹ پابندیوں کو سپورٹ کرتے ہیں، جس سے فارمیٹ کی خلاف ورزیوں کو پیدا ہونے سے روکا جاتا ہے۔

3. تیسری سطح: تصدیق-مرمت-دوبارہ کوشش کا بند لوپ قائم کرنا (عمل درآمد کا بیک اپ)

   • Schema ہونے کے باوجود، ماڈل کی آؤٹ پٹ ملنے کے بعد نحوی اور Schema کی تصدیق ضروری ہے۔
   • تصدیق ناکام ہونے پر، خودکار صفائی اور دوبارہ کوشش کا طریقہ کار (محدود تعداد میں) ڈیزائن کریں، جس میں غلطی کی معلومات ماڈل کو واپس بھیجی جائیں تاکہ وہ آؤٹ پٹ درست کرے۔ دوبارہ کوشش کی حد سے تجاوز کرنے پر، ڈاؤن گریڈ یا انسانی مداخلت کا منصوبہ ہونا چاہیے۔

4. آرکیٹیکچرل سطح: ذمہ داریوں کی علیحدگی

   • فیصلہ اور عمل درآمد کو الگ کریں، جس سے تین سطحی ڈھانچہ بنے:
     • ماڈل کی سطح: صرف فیصلہ کرنے کی ذمہ دار (یہ طے کرنا کہ کون سا ٹول کال کرنا ہے اور کون سے پیرامیٹرز تیار کرنے ہیں)۔
     • فریم ورک کی سطح: عمل درآمد کے فریم ورک کی ذمہ دار، جس میں Schema کی تصدیق، ٹول کال کرنا، دوبارہ کوشش کا انتظام، اور نتائج کو یکجا کرنا شامل ہے۔ اس سے یہ یقینی ہوتا ہے کہ ماڈل کی غلطیاں براہ راست ٹول کی حفاظت کو متاثر نہیں کرتیں، اور ٹول میں تبدیلی کے لیے پرامپٹس میں بار بار ترمیم کی ضرورت نہیں ہوتی۔
     • ٹول کی سطح: مخصوص کاروباری صلاحیتوں کا نفاذ۔
   • LangChain، LlamaIndex جیسے فریم ورک اسی طرح کا کام کر رہے ہیں۔

موجودہ حل کی حدود: یہ پیرامیٹر فارمیٹ کے مسائل کو اچھی طرح حل کرتا ہے، لیکن پیرامیٹر کے معنوں (مثلاً "شنگھائی" اور "ہو" کی برابری) کی تصدیق کا احاطہ ابھی بھی ناکافی ہے۔ یہ مستقبل میں ایک انجینئرنگ چیلنج ہوگا۔

بنیادی نتیجہ: LLM کو قابل اعتماد طریقے سے ٹول کال کرنے کے قابل بنانا بنیادی طور پر ایک سافٹ ویئر انجینئرنگ کا مسئلہ ہے، جس کے لیے نرم پابندیوں، سخت پابندیوں، عمل درآمد کے بیک اپ، اور آرکیٹیکچرل ڈیزائن پر مشتمل ایک منظم انجینئرنگ حل درکار ہے، نہ کہ صرف پرامپٹس کو بہتر بنانے پر انحصار۔