ایک درمیانے درجے کے انشورنس بروکر کے ساتھ کام کا یہ تیسرا دن ہے، اور ‘کلیمز آپریشنز’ (claims ops) کے سربراہ ایک ایسے چیٹ ٹول کا مطالبہ کر رہے ہیں جو کلیم ایڈجسٹ کرنے والوں (adjusters) کو تیزی سے جواب دے سکے۔ وہ چاہتے ہیں کہ یہ ٹول پالیسی کے تازہ ترین اصولوں کا حوالہ دے، استثنیٰ (exceptions) کی وضاحت کرے، اور متعلقہ ہینڈ بک میں عین اس صفحے کی نشاندہی کرے جہاں معلومات موجود ہیں۔ اسی میٹنگ میں، قانونی شعبہ ایک اور شرط کا اضافہ کرتا ہے: یہ ٹول کلائنٹ کے معاہدے کا مواد اس وقت تک ہرگز نہ دکھائے جب تک کہ ایڈجسٹر کو اس اکاؤنٹ پر تعینات نہ کیا گیا ہو۔
یہیں پر ‘فارورڈ ڈیپلائڈ ورک’ (FDE) میں کسٹمر کے لیے مخصوص RAG (Retrieval-Augmented Generation) کا کردار سامنے آتا ہے۔ کسٹمر کے لیے مخصوص RAG ایک ایسا نظام ہے جس میں AI سسٹم پہلے متعلقہ کسٹمر کے اپنے ذرائع سے حقائق اخذ کرتا ہے اور پھر ان حقائق کی بنیاد پر جواب تیار کرتا ہے۔ یہ ‘کسٹمر کے لیے مخصوص’ اس لیے ہے کیونکہ ذرائع وقت کے ساتھ تبدیل ہوتے رہتے ہیں اور یہ کسٹمر ہی ہے—نہ کہ ہم—جو یہ طے کرتا ہے کہ کون سا جواب قابلِ قبول ہے۔
عملی طور پر، ہم کوئی عام چیٹ بوٹ فراہم نہیں کر رہے، بلکہ جوابات کا ایک ایسا نظام (workflow) فراہم کر رہے ہیں جو حقیقی دستاویزات، حقیقی اجازتوں اور حقیقی کاروباری نتائج سے منسلک ہے۔ بروکر کے لیے، “درست” جواب کا مطلب ہے کہ جواب ہینڈ بک کے موجودہ ورژن سے مطابقت رکھتا ہو، اس کا حوالہ دیتا ہو، اور اکاؤنٹ کی سطح پر رسائی کے اصولوں کا احترام کرتا ہو—یہاں تک کہ جب سوال مبہم ہو۔
FDE کا بنیادی اصول یہ ہے کہ RAG کو محض ایک فیچر (خصوصیت) کے طور پر نہیں بلکہ ایک مکمل ‘اینڈ ٹو اینڈ’ (end-to-end) نظام کے طور پر دیکھا جائے۔ اگر ہم صرف ماڈل پرامپٹس (prompts) پر توجہ مرکوز کریں گے، تو ہم ان پہلوؤں کو نظر انداز کر دیں گے جو اسے پروڈکشن کے ماحول میں محفوظ اور قابلِ اعتماد بناتے ہیں۔ اس سبق کا بقیہ حصہ اسی بروکر کیس پر مرکوز رہے گا، کیونکہ آپ کا ہر فیصلہ بالآخر اس چیز سے جڑا ہوگا جو ایڈجسٹر کو اس وقت نظر آتی ہے جب اسے جواب کی ضرورت ہوتی ہے۔
RAG میں پروڈکشن کی ناکامیاں شاذ و نادر ہی ڈرامائی نوعیت کی ہوتی ہیں۔ یہ عام طور پر خاموشی سے، بظاہر درست لگنے والے انداز میں اور مہنگی ثابت ہونے والی صورت میں رونما ہوتی ہیں۔ ایڈجسٹر کو ایسا جواب ملتا ہے جو درست معلوم ہوتا ہے، وہ اس پر عمل کرتا ہے، اور بعد میں کسی کو پتہ چلتا ہے کہ کلیم (دعویٰ) غلط اصول کے تحت نمٹایا گیا تھا۔
اس صورتحال پر غور کریں۔ بروکر پیر کے روز “پانی سے ہونے والے نقصانات کے استثنیٰ” (Water Damage Exceptions) سے متعلق ایک نیا بلیٹن اپ لوڈ کرتا ہے۔ بدھ تک، چیٹ ٹول اب بھی پچھلے مہینے کی ہینڈ بک کا استعمال کرتے ہوئے جواب دے رہا ہوتا ہے کیونکہ ‘کونٹینٹ پائپ لائن’ نے نئی فائل کو دوبارہ شامل (ingest) نہیں کیا ہوتا۔ کوئی ایرر (خرابی) ظاہر نہیں ہوتا، اور سسٹم شاید کسی حقیقی صفحہ نمبر کا حوالہ بھی دے دے؛ بس فرق یہ ہوتا ہے کہ وہ موجودہ پالیسی سیٹ کے لحاظ سے غلط صفحہ نمبر ہوتا ہے۔
ایک اور عام خرابی رسائی کی حدود (access boundaries) سے متعلق ہوتی ہے۔ اگر ‘ریٹریول’ (معلومات تلاش کرنے) کا مرحلہ کسی دستاویز تک رسائی حاصل کر سکتا ہے، تو AI سسٹم اس کا خلاصہ پیش کر سکتا ہے—حالانکہ حتمی صارف (end user) کو اس تک رسائی نہیں ہونی چاہیے۔ یہی وجہ ہے کہ RAG میں اجازتیں (permissions) محض UI کی کوئی معمولی تفصیل نہیں ہوتیں۔ یہ ’ریٹریول ڈیزائن‘ (معلومات کی بازیافت کے نظام) کا حصہ ہیں، اور ماڈل کو کوئی بھی متن (text) سونپے جانے سے پہلے ان کا نفاذ لازمی ہے۔
’خاموش کوتاہیاں‘ (silent misses) ایک اور سنگین مسئلہ ہیں۔ مثال کے طور پر، “اگر نقصان 2 ہزار سے کم ہو تو کیا ہم معائنے سے استثنیٰ دے سکتے ہیں؟” جیسے سوال کے لیے شاید کسی مخصوص استثنائی شق کی ضرورت ہو۔ اگر بازیافت کا نظام اسے تلاش کرنے میں ناکام رہتا ہے، تب بھی ماڈل اکثر مددگار ثابت ہونے کی کوشش میں کسی عام سے اصول کے ذریعے اس خلا کو پُر کر دیتا ہے۔ پیمائش کے بغیر، آپ کو اس انحراف (drift) کا تب تک علم نہیں ہو سکے گا جب تک کہ کاروباری سطح پر شکایت نہ آ جائے۔
ان ناکامیوں اور کاروباری اثرات کے درمیان تعلق کے اہم پہلوؤں کا جائزہ لیں۔
تبدیلی (drift) کو تسلیم کریں، معیار کو ثابت کریں اگر آپ وقت کے ساتھ ساتھ معیار کی نگرانی نہیں کر رہے ہیں، تو معیار پہلے ہی تبدیل ہو رہا ہے اور آپ اسے ابھی دیکھ نہیں پا رہے۔
ناکامی کے یہ انداز (failure modes) اصل FDE سوال کو جنم دیتے ہیں۔ ہمیں کیا اور کس ترتیب سے طے کرنے کی ضرورت ہے تاکہ یہ نظام درست رہے جب کہ دستاویزات، صارفین اور قواعد تبدیل ہوتے رہیں؟
صارف کے لیے مخصوص RAG کا کام فیصلوں کی ایک ایسی زنجیر ہے جس میں ہر کڑی (link) اس بات کو بدل دیتی ہے کہ اگلی کڑی محفوظ طریقے سے کیا کر سکتی ہے۔ اگر ہم براہِ راست ایمبیڈنگز (embeddings) یا چنک سائز (chunk sizes) کی طرف بڑھ جائیں، تو بعد میں ہمیں نظام کو دوبارہ لکھنا پڑ سکتا ہے جب کوئی ایسا کاروباری اصول سامنے آئے جسے شروع ہی سے ایک اہم ضرورت (first-class requirement) ہونا چاہیے تھا۔
ایسی ضروریات سے آغاز کریں جو جانچنے کے لیے کافی حد تک مخصوص ہوں۔ بروکر کے معاملے میں، ہم قبولیت کے معیارات (acceptance criteria) لکھتے ہیں جیسے “ہینڈ بک کے عین اسی حصے کا حوالہ دینا لازمی ہے” اور “جب صارف کے پاس رسائی نہ ہو تو انکار کرنا لازمی ہے۔” یہ مبہم اہداف نہیں ہیں۔ یہ ‘پاس یا فیل’ کی جانچ پڑتال ہیں جنہیں ہم تشخیص کے ایک مجموعے میں تبدیل کر سکتے ہیں۔
اگلا مرحلہ ڈیٹا کا ہے۔ ہم ان ذرائع کی نشاندہی کرتے ہیں جو معلومات کی بازیافت (retrieval) کا ذریعہ بنیں گے اور یہ کہ وہ کیسے تبدیل ہوتے ہیں۔ جیسے SharePoint میں ہینڈ بکس، ای میل سے بلیٹنز، اور CRM ایکسپورٹ میں اکاؤنٹ کے معاہدے۔ ہم یہ بھی طے کرتے ہیں کہ کسے کیا دیکھنے کی اجازت ہے، کیونکہ اجازت کا یہ ماڈل انڈیکسنگ اور استفسار کے وقت فلٹرنگ (query-time filtering) کی تشکیل کرے گا۔
پھر بازیافت (retrieval) کے ڈیزائن کا مرحلہ آتا ہے۔ بازیافت سے مراد یہ ہے کہ نظام کس طرح دستاویز کے ٹکڑوں (snippets) کا انتخاب کرتا ہے تاکہ انہیں ماڈل کو دکھایا جا سکے۔ اہم فیصلہ یہ ہے کہ آیا ہم استفسار کے وقت اجازتوں کی بنیاد پر فلٹر کر سکتے ہیں، یا معلومات کے غیر مجاز اخراج (leakage) سے بچنے کے لیے ہمیں ہر حصے (segment) کے لیے الگ الگ انڈیکس کی ضرورت ہے۔ بروکر کے معاملے میں، اکاؤنٹ کے معاہدے اکثر آپ کو سخت فلٹرنگ کی طرف لے جاتے ہیں، کیونکہ ایک بھی غلطی سنگین واقعہ ثابت ہو سکتی ہے۔
‘گراؤنڈنگ’ (Grounding) وہ عمل ہے جس کے ذریعے ہم ماڈل کو بازیافت شدہ متن سے منسلک رکھتے ہیں۔ گراؤنڈنگ میں عام طور پر ایسے اصول شامل ہوتے ہیں جیسے “صرف فراہم کردہ سیاق و سباق (context) سے جواب دیں” اور “حوالہ جات شامل کریں۔” اس میں یہ بھی شامل ہے کہ جب سیاق و سباق موجود نہ ہو تو نظام کو کیا کرنا چاہیے، مثلاً وضاحت طلب کرنے والا سوال پوچھنا یا یہ جواب دینا کہ “مجھے موجودہ پالیسی دستاویزات میں یہ نہیں مل رہا۔”
تشخیص (Evaluation) وہ مرحلہ ہے جہاں ہم قابلِ اعتماد ہونے کو قابلِ پیمائش بناتے ہیں۔ تشخیص، متوقع رویوں کے ساتھ ٹیسٹ سوالات کا ایک ایسا مجموعہ ہے جسے دہرایا جا سکتا ہے اور جسے تبدیلیوں سے پہلے اور بعد میں چلایا جاتا ہے۔ اس بروکر کے لیے، ہمیں حوالہ جات کی درستگی، محدود دستاویزات کے معاملے میں انکار کی درستگی، اور زیادہ خطرے والے کلیم (claim) کے منظرناموں کا احاطہ کرنے کی فکر ہوتی ہے۔
تعیناتی (Deployment) کے فیصلے اس سب کو ایک فعال نظام (operating system) میں بدل دیتے ہیں۔ ہم فیصلہ کرتے ہیں کہ ڈیٹا کا اندراج (ingestion) کیسے ہوگا، انڈیکس کتنی بار تازہ (refresh) ہوں گے، ہم درخواستوں کو محفوظ طریقے سے کیسے ریکارڈ (log) کریں گے، اور ہم اپ ڈیٹس کو کیسے جاری کریں گے۔ اس کے بعد ‘اِٹریریشن’ (دہرائی اور بہتری کا عمل) حفاظتی حدود (guardrails) کے ساتھ ایک چکر کی صورت اختیار کر لیتا ہے۔ جب ایڈجسٹرز (adjusters) کسی غلطی یا کمی کی اطلاع دیتے ہیں، تو ہم فیصلہ کرتے ہیں کہ آیا یہ ڈیٹا کی کمی تھی، بازیافت کا مسئلہ تھا، یا ہدایات میں کوئی خامی تھی، اور پھر ہم متعلقہ سطح (layer) کو درست کرتے ہیں۔
مراحل کو انتخابات کے ایک باہم مربوط نظام کے طور پر دیکھیں۔