لانچ سے دو دن قبل، ایک رسک ٹیم (خطرات کا جائزہ لینے والی ٹیم) کے سپرد صحت کی دیکھ بھال (healthcare) کے ممبر سپورٹ چیٹ بوٹ کا نیا نظام کیا جاتا ہے۔ آخری لمحات میں کیے گئے ایک ٹیسٹ کے دوران، بوٹ ایک ممبر کو نسخے والی دوا (prescription drug) کے استعمال کے لیے مرحلہ وار ہدایات دیتا ہے، حالانکہ پروڈکٹ کی ضرورت یہ ہے کہ اسے طبی مشورہ دینے سے انکار کرنا چاہیے اور ممبر کو نرس لائن (طبی رہنمائی کے لیے مخصوص ہیلپ لائن) کی طرف بھیجنا چاہیے۔ رسک ریٹنگ (خطرے کی سطح کا تعین) کے لیے درکار بنیادی سوال کا جواب کسی کے پاس نہیں ہوتا: یعنی نظام میں وہ کون سا مقام تھا جہاں اس رویے کو روکا جا سکتا تھا، اس کی نشاندہی کی جا سکتی تھی، یا اسے قابو میں لایا جا سکتا تھا۔
اس سبق کا بقیہ حصہ نقصان دہ نتائج کے لیے خطرے کا ایک ماڈل تشکیل دیتا ہے؛ اس عمل میں واقعے کے پورے سلسلے (incident chain) کا شروع سے آخر تک جائزہ لیا جاتا ہے اور پھر اس سلسلے کو ٹھوس کنٹرول پوائنٹس (قابو پانے کے مقامات) میں تبدیل کیا جاتا ہے جن کی پیمائش اور نگرانی کی جا سکتی ہے۔
اس کورس میں، تھریٹ ماڈل (خطرے کا ماڈل) اس بات کی ایک منظم وضاحت ہے کہ آپ کی LLM ایپلی کیشن میں کوئی مخصوص نقصان کیسے واقع ہو سکتا ہے، اس میں کون سے اجزاء شامل ہوتے ہیں، کن شرائط کا پورا ہونا ضروری ہے، اور اس راستے کی تصدیق یا تردید کے لیے آپ کون سے شواہد اکٹھے کر سکتے ہیں۔ نقصان دہ نتائج کے معاملے میں، اس کا مطلب یہ ہے کہ ہم آؤٹ پٹ کو ‘ناکام حالت’ (failure state) کے طور پر لیتے ہیں اور پرامپٹ (prompt)، بازیافت (retrieval)، تخلیق (generation)، اعتدال پسندی/جانچ (moderation)، اور ترسیل (delivery) کے مراحل سے ہوتے ہوئے پیچھے کی طرف جاتے ہیں، یہاں تک کہ ہمیں اس سلسلے میں ایسے مقامات مل جائیں جہاں مداخلت یا کنٹرول ممکن ہو۔
فرضی — واقعے کی تفصیل کا اقتباس:
ایک ممبر چیٹ بوٹ سے پوچھتا ہے کہ کیا وہ دوا کی خوراک دوگنی کر سکتا ہے تاکہ اس دن کی کمی پوری ہو سکے جس دن دوا نہیں لی جا سکی تھی۔ چیٹ بوٹ دواؤں سے متعلق عام سوالات (FAQ) اور کمیونٹی فورم کا ایک اقتباس تلاش کرتا ہے جس میں خوراک کے بارے میں غیر رسمی گفتگو شامل ہوتی ہے۔ ماڈل مشروط خوراک کی رہنمائی اور ایک انتباہ کے ساتھ جواب دیتا ہے، اور یوزر انٹرفیس (UI) اسے بغیر کسی اضافی رکاوٹ یا جانچ کے (بغیر کسی اضافی ‘گیٹ’ کے) ظاہر کر دیتا ہے۔ نہ تو انکار کا کوئی پیغام جاری ہوتا ہے اور نہ ہی انسانی سطح پر اس کا جائزہ لیا جاتا ہے۔
اہم قدم یہ ہے کہ جو کچھ غلط ہوا اسے نظام کے قابلِ مشاہدہ واقعات میں الگ الگ کیا جائے۔ صارف کی درخواست موصول ہوئی، بازیافت (retrieval) کے عمل نے قابلِ قبول اور غیر محفوظ سیاق و سباق (context) کا ملا جلا مواد فراہم کیا، ماڈل نے ہدایات تیار کیں، اعتدال پسندی/جانچ (moderation) کے مرحلے نے اسے نہ تو روکا اور نہ ہی کسی اور طرف بھیجا، اور ترسیل کے چینل نے اسے عام معلوماتی مواد کے طور پر پیش کر دیا۔ ہمیں خطرے کے ماڈل کی ضرورت اس لیے ہے کیونکہ ہر مرحلے (hop) کی ٹیلی میٹری (ڈیٹا کی نگرانی) اور کنٹرول کی حدود مختلف ہوتی ہیں۔
ہم نظام کے خاکے (system diagram) میں اس سلسلے کو ٹھوس شکل دے سکتے ہیں۔ جب آپ اس کا جائزہ لیں، تو اس بات پر توجہ مرکوز کریں کہ کس جزو نے ایک پوشیدہ خطرے کو حقیقت میں فراہم کیے گئے جواب میں تبدیل کیا۔ اب آرکیٹیکچر (نظام کی ساخت) پر ناکامی کے مقامات کی نشاندہی کریں:
کنٹرول پوائنٹ (Control point) درخواست سے جواب تک کے راستے میں وہ مقام ہے جہاں آپ ان پٹ، پالیسی اور نفاذی اقدام کا استعمال کرتے ہوئے سیکیورٹی یا حفاظت سے متعلق فیصلہ لاگو کر سکتے ہیں۔ نقصان دہ آؤٹ پٹ (نتائج) کے معاملے میں، کنٹرول پوائنٹس کو ‘جنریشن سے پہلے’ (pre-generation)، ‘جنریشن کے دوران’ (during-generation) اور ‘جنریشن کے بعد’ (post-generation) کے گروپس میں تقسیم کرنا مفید رہتا ہے، کیونکہ ہر گروپ مختلف ضمانتیں اور ‘فالس پازیٹو’ (غلط شناخت) کی مختلف لاگتیں پیش کرتا ہے۔
جنریشن سے پہلے کے کنٹرولز اس بات کا تعین کرتے ہیں کہ ماڈل کیا دیکھتا ہے۔ ان میں صارف کے ان پٹ کی فلٹرنگ، معلومات کی بازیافت (retrieval) کی حدود، اور پرامپٹ ٹیمپلیٹس شامل ہیں۔ یہ نقصان دہ نتائج کے امکان کو کم کر سکتے ہیں لیکن حفاظت کی ضمانت نہیں دے سکتے، کیونکہ بظاہر محفوظ ان پٹ سے غیر محفوظ نتائج (completions) حاصل ہو سکتے ہیں، اور معلومات کی بازیافت کے دوران ایسا متن بھی سامنے آ سکتا ہے جو سیاق و سباق کے لحاظ سے خطرناک ہو۔
جنریشن کے دوران کام کرنے والے کنٹرولز اس بات کا تعین کرتے ہیں کہ ماڈل کو کیا تیار کرنے کی اجازت ہے۔ یہاں آپ سسٹم کی ہدایات، ایجنٹس کے لیے ٹول پالیسیاں، اور ماڈل کی سطح پر موجود حفاظتی خصوصیات (جہاں دستیاب ہوں) کا استعمال کرتے ہیں۔ یہ ماڈل کے رویے کو محدود کر سکتے ہیں، لیکن پھر بھی اس بات کا انحصار اس پر ہوتا ہے کہ آیا ماڈل مخالفانہ یا مبہم ان پٹ کے باوجود ہدایات پر عمل کرتا ہے یا نہیں؛ نیز، منظم جانچ (testing) کے بغیر ان کی تصدیق کرنا مشکل ہوتا ہے۔
جنریشن کے بعد کے کنٹرولز یہ فیصلہ کرتے ہیں کہ کیا چیز صارف تک پہنچائی جائے اور کسے کس راستے پر بھیجا جائے۔ اس میں آؤٹ پٹ کو جانچنے والے کلاسیفائرز (moderation classifiers)، زیادہ خطرے والے موضوعات کے لیے ‘اجازت’ اور ‘ممانعت’ کی فہرستیں، اور انسانی جائزے کی قطاریں (queues) شامل ہیں۔ اکثر یہی وہ مقام ہوتا ہے جہاں آپ اس بات کی ضمانت دے سکتے ہیں کہ ممنوعہ متن صارف تک نہیں پہنچے گا، لیکن ان کی وجہ سے تاخیر (latency) ہو سکتی ہے، صارف کا تجربہ غیر مستقل ہو سکتا ہے، اور جب ثبوت درکار ہوں تو یہ ثابت کرنے کے لیے کہ انہوں نے درست کام کیا، باقاعدہ لاگنگ (logging) کی ضرورت پڑتی ہے۔
ضمانتوں کے لیے نفاذ ضروری ہےپالیسی کا بیان بذاتِ خود کوئی کنٹرول نہیں ہے۔ کنٹرول پوائنٹ کا وجود تبھی ہوتا ہے جب کوئی ایسا فیصلہ موجود ہو جسے نافذ کیا جا سکے اور ساتھ ہی ایک ایسا ‘آڈٹ ٹریل’ (audit trail) ہو جس کا جائزہ لیا جا سکے۔
ایک عام غلط فہمی یہ ہے کہ نقصان دہ نتائج کا خطرہ صرف ماڈل کے معیار کا مسئلہ ہے۔ عملی طور پر، ماڈل ایک تقسیم شدہ نظام (distributed system) کا صرف ایک جزو ہوتا ہے۔ وہی بنیادی ماڈل نرس لائن ٹرائیج (triage) کے ورک فلو میں—جہاں جنریشن کے بعد سخت روٹنگ ہوتی ہے—قابلِ قبول ہو سکتا ہے، لیکن ‘سیلف سروس چیٹ UI’ میں—جہاں کوئی فلٹرنگ یا گیٹنگ نہیں ہوتی—ناقابلِ قبول ہو سکتا ہے، کیونکہ ترسیل کا راستہ (delivery path) اثرات اور شناخت کی صلاحیت کو تبدیل کر دیتا ہے۔
کنٹرول پوائنٹس کو فعال بنانے کے لیے، ہم ان کے ساتھ ثبوت منسلک کرتے ہیں۔ ہر پوائنٹ کے لیے، ہمیں یہ بتانے کے قابل ہونا چاہیے کہ کون سا سگنل لاگ کیا جاتا ہے، اسے کہاں محفوظ کیا جاتا ہے، اور اس کا جائزہ کیسے لیا جاتا ہے۔ آئیے مداخلت کے ان پوائنٹس اور ان لاگز کا جائزہ لیں جن کی توقع کی جاتی ہے: