سپورٹ ایجنٹ نے ٹو فیکٹر آتھنٹیکیشن (two-factor authentication) ری سیٹ کرنے کی صارف کی درخواست کا جواب ایسے اقدامات کے ساتھ دیا جو حقیقت میں موجود ہی نہیں تھے۔ جواب پر اعتماد معلوم ہو رہا تھا، HTTP درخواست نے 200 OK واپس کیا، لیٹنسی (latency) معمول کے مطابق تھی اور مانیٹرنگ کا ہر چارٹ سبز (green) نظر آ رہا تھا۔
ایک AI سے چلنے والے سپورٹ ایجنٹ نے غلط جواب (hallucination) دیا کیونکہ وہ اندرونی چیک جو اس غلطی کو پکڑ سکتے تھے، کبھی چلے ہی نہیں۔ انجینئرز جس ڈیش بورڈ پر بھروسہ کرتے ہیں اس نے مکمل طور پر درست آپریشن رپورٹ کیا، جبکہ ایجنٹ خاموشی سے ایک فرضی حل تیار کر رہا تھا۔
روایتی ڈیش بورڈز AI hallucinations کو کیوں نہیں پکڑ پاتے
زیادہ تر observability stacks ایک AI ایجنٹ کے ساتھ کسی بھی دوسرے مائیکرو سروس (microservice) کی طرح سلوک کرتے ہیں: ایک ان باؤنڈ (inbound) درخواست اور ایک آؤٹ باؤنڈ (outbound) جواب۔ وہ HTTP اسٹیٹس، رسپانس ٹائم اور ایرر کاؤنٹ کو لاگ (log) کرتے ہیں۔ وہ درخواست کے اندرونی چھپے ہوئے مراحل کو لاگ نہیں کرتے – جیسے کہ بیرونی دستاویزات کا حصول (retrieval)، لارج لینگویج ماڈلز (LLMs) کو کالز، معاون ٹولز کا استعمال، اور کوئی بھی گارڈ ریل (guard-rail) لاجک جو آؤٹ پٹ کی تصدیق کرتی ہو۔
جب ریٹریول (retrieval) کا مرحلہ خالی نتیجہ واپس کرتا ہے، تو ماڈل اکثر اسے کسی معقول لگنے والے متن سے "پُر" کر دیتا ہے۔ مانیٹرنگ سسٹم کے نقطہ نظر سے کال کامیاب رہی، کیونکہ کچھ بھی کریش نہیں ہوا اور اسٹیٹس کوڈ 200 ہی رہا۔ اس طرح hallucination نظر نہیں آتی، اور واحد علامت صارف تک پہنچنے والا غلط جواب ہوتا ہے۔
ایک بلیک باکس کو قابلِ مطالعہ ٹری (tree) میں تبدیل کرنا
قابلِ اعتماد ڈی بگنگ (debugging) کا پہلا قدم یہ ہے کہ ایجنٹ کو ایک واحد (monolithic) کال سمجھنا بند کیا جائے اور ہر اندرونی آپریشن کو ٹریس ٹیبل (trace table) میں ایک الگ رو (row) کے طور پر دکھایا جائے۔ ایک عام عمل درج ذیل حصوں میں تقسیم ہوتا ہے:
- ایجنٹ کی اعلیٰ سطح کی کال (invocation)
- ریٹریول کا مرحلہ جو متعلقہ دستاویزات نکالتا ہے
- ہر لینگویج ماڈل انفرنس (inference) جو حاصل شدہ ڈیٹا پر کارروائی کرتا ہے
- ہر ٹول کال (مثلاً ڈیٹا بیس لک اپ، API درخواست)
- گارڈ ریل چیک جو حقائق یا پالیسی کی تعمیل کو یقینی بناتے ہیں
ہر رو (row) ٹائم اسٹیمپ، کامیابی کا نشان (success flag)، اور اس مرحلے سے گزرنے والے پی لوڈ (payload) کو ریکارڈ کرتی ہے۔ اس ڈھانچے کے ساتھ، عمل ایک درخت (tree) کی شکل اختیار کر لیتا ہے جس کا حتمی آؤٹ پٹ سے اندازہ لگانے کے بجائے لائن بہ لائن معائنہ کیا جا سکتا ہے۔
وہ بگ (bug) جو نظر انداز ہو گیا
غلط سپورٹ انٹرایکشن میں ٹریس کچھ اس طرح تھا:
- Retrieval چلا لیکن کوئی دستاویزات واپس نہیں لایا۔
- اگلا مرحلہ پھر بھی جاری رہا، اور ماڈل کو ایک خالی سیاق و سباق (context) فراہم کر دیا۔
- ماڈل نے ایک ایسا جواب تیار کیا جس نے مفقود معلومات کو فرضی اقدامات سے پُر کر دیا۔
- سسٹم نے 200 واپس کیا کیونکہ پائپ لائن میں کوئی استثنیٰ (exception) پیش نہیں آیا تھا۔
یہ hallucination خود لینگویج ماڈل کی خرابی نہیں تھی؛ بلکہ یہ ریٹریول اور جنریشن کے مراحل کے درمیان ایک گارڈ ریل (guard-rail) کی کمی تھی۔ ایجنٹ نے جواب تب بھی دیا جب اس کے پاس اپنے جواب کی بنیاد رکھنے کے لیے کچھ بھی موجود نہیں تھا۔
سادہ گارڈ ریلز جو hallucinations کو روکتی ہیں
دو ٹھوس تبدیلیوں نے اس مسئلے کو ختم کر دیا:
- خالی ریٹریول پر عمل روک دیں – اگر ڈاکومنٹ اسٹور کچھ بھی واپس نہیں کرتا، تو ایجنٹ کو جنریشن کے عمل کی طرف بڑھنے کے بجائے یہ جواب دینا چاہیے کہ "مجھے وہ معلومات نہیں مل سکیں جن کی آپ کو ضرورت ہے"۔
- گراؤنڈنگ چیک (Grounding check) – ماڈل کے جواب تیار کرنے کے بعد، اس بات کی تصدیق کریں کہ ہر حقیقت پر مبنی دعویٰ حاصل شدہ مواد میں موجود ہے۔ اگر چیک ناکام ہو جائے، تو جواب کو مسترد کر دیں اور "جواب نہیں دے سکتا" والے جواب پر منتقل ہو جائیں۔
تیز تر ڈی بگنگ کے لیے ایک عملی ورک فلو
- ہر اندرونی کال کو ٹریس کریں – ایجنٹ کو اس طرح تیار کریں کہ ہر ریٹریول، ماڈل انفرنس اور ٹول کا استعمال ایک مستقل لاگ (persistent log) میں ایک نئی رو لکھے۔
- ناکام رن کو محفوظ رکھیں – صارف کی جانب سے غلط بتائی گئی کسی بھی بات کا مکمل ٹریس محفوظ کریں۔ اسٹوریج بچانے کے لیے انہیں حذف کرنا اس ڈیٹا کو چھپا دیتا ہے جو ریگریشنز (regressions) تلاش کرنے کے لیے ضروری ہوتا ہے۔
- رن کو ورژن کی معلومات کے ساتھ ٹیگ کریں – ہر ٹریس رو میں ریلیز آئیڈنٹیفائر اور کسی بھی فیچر فلیگ (feature-flag) کی حالت شامل کریں۔ اس سے آپ ایک نئے بگ کو حالیہ کوڈ کی تبدیلی کے ساتھ جوڑ سکتے ہیں۔
- صرف رفتار نہیں، بلکہ معیار کو بھی پرکھیں – ایسے میٹرکس (metrics) شامل کریں جو یہ پیمائش کریں کہ جواب ہدایات پر کتنا صحیح عمل کرتا ہے اور حاصل شدہ مواد پر کتنا مبنی ہے۔ اگر جوابات غلط ہوں تو زیادہ تھرو پٹ (throughput) کا کوئی فائدہ نہیں۔
- روزانہ ناکامیوں کا جائزہ لیں – محفوظ شدہ ناکامیوں کا مختصر اور باقاعدہ جائزہ اکثر پیٹرن (مثلاً ایک خاص قسم کی کوئری کا مسلسل خالی ریٹریول دینا) کو بہت سے صارفین کو متاثر کرنے سے پہلے ہی ظاہر کر دیتا ہے۔
"سبز" (green) کو "تصدیق شدہ" (verified) میں تبدیل کر کے، ٹیمیں hallucination کو جلد پکڑ سکتی ہیں اور صارف کے تجربے کو قابلِ اعتماد رکھ سکتی ہیں۔
اندرونی ناکامیوں کو نظر انداز کرنے کی قیمت
جب ڈیش بورڈز صرف HTTP لیئر پر کامیابی رپورٹ کرتے ہیں، تو ادارے ایسے ایجنٹس تعینات کر دیتے ہیں جو قابلِ اعتماد نظر آتے ہیں لیکن باقاعدگی سے غلط رہنمائی فراہم کرتے ہیں۔
آگے کیا دیکھنا ہے
جب تک یہ چیزیں عام نہیں ہو جاتیں، سب سے محفوظ طریقہ یہ ہے کہ ہر اندرونی آپریشن کو قابلِ مشاہدہ (observable) سمجھا جائے اور ثبوت کی عدم موجودگی میں فوری طور پر عمل روک دیا جائے (fail fast)۔
حاصلِ کلام: ایک سبز ڈیش بورڈ آپ کو یہ بتاتا ہے کہ سسٹم کا بنیادی ڈھانچہ (plumbing) کام کر رہا ہے؛ یہ اس بات کی ضمانت نہیں دیتا کہ جواب درست ہے۔ ہر ریٹریول (retrieval)، ماڈل کال (model call) اور گارڈ ریل چیک (guard-rail check) کا سراغ لگا کر، آپ پوشیدہ ہالوسینیشنز (hallucinations) کو ایسی واضح ناکامیوں میں تبدیل کر دیتے ہیں جنہیں صارف تک پہنچنے سے پہلے ٹھیک کیا جا سکتا ہے۔