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

پروڈکشن میں ٹیکسٹ بینچ مارکس کیوں ناکام ہو جاتے ہیں

معیاری بینچ مارکس پر زیادہ اسکور سکون کا ایک گمراہ کن ذریعہ بن گئے ہیں۔ ایک ایجنٹ جو شستہ نثر لکھتا ہے وہ پھر بھی آپریشنل خطرہ ہو سکتا ہے۔ جب آپ کا سسٹم اپائنٹمنٹس بک کرتا ہے، ڈیٹا بیس ریکارڈز میں ترمیم کرتا ہے، یا سپورٹ ٹکٹس فائل کرتا ہے، تو تیار کردہ ٹیکسٹ ورک فلو کی صرف ظاہری سطح ہوتی ہے۔ اس کے نیچے، ایجنٹ اس بارے میں ٹھوس فیصلے کر رہا ہوتا ہے کہ کس اینڈ پوائنٹ (endpoint) کو ہٹ کرنا ہے، کیا پے لوڈ (payload) بھیجنا ہے، اور کب رکنا ہے۔ یہ ریڈنگ کمپری ہینشن (reading-comprehension) لیڈر بورڈ پر ٹاپ کر سکتا ہے جبکہ وسائل کی ڈبل بکنگ کر کے، غلط رو (row) کو تبدیل کر کے، یا لاگ فائل میں حساس اسٹیٹ (state) لیک کر کے آپ کا نقصان کر سکتا ہے۔ آپ کو کام کے میکانزم کی تصدیق کرنے کی ضرورت ہے، نہ کہ صرف آؤٹ پٹ کی چمک دمک کی۔ اگر ایک ایجنٹ آف لائن QA ٹیسٹ میں اچھا اسکور کر سکتا ہے اور پھر بھی لوپنگ یا کسی ٹول کے غلط استعمال کے ذریعے آپ کے ورک فلو میں ناکام ہو جاتا ہے، تو آپ کا ایویلیوایشن غلط اشاروں کو دیکھ رہا ہے۔

پانچ انحصار (dependencies) کا نقشہ بنانا

Van Data Team کی ٹیم ہر ایویلیوایشن کا آغاز پانچ مخصوص کنٹرول پوائنٹس کا نقشہ بنا کر کرتی ہے۔ یہ سوال کو مکمل طور پر بدل دیتا ہے۔ آپ یہ پوچھنا بند کر دیتے ہیں کہ آیا ایک ماڈل دوسرے سے زیادہ ذہین ہے یا نہیں۔ آپ یہ پوچھنا شروع کرتے ہیں کہ کیا ایجنٹ آپ کی حقیقی حدود کے تحت پروڈکشن ٹاسک کو مکمل کر سکتا ہے۔

کاروباری نتائج (Business outcomes)۔ ڈالر اور کسٹمر پر اثر کے لحاظ سے یہ طے کریں کہ "مکمل" کا کیا مطلب ہے۔ کوئی ٹاسک اس لیے مکمل نہیں ہوتا کیونکہ ایجنٹ نے ایک خلاصہ جاری کر دیا ہے۔ یہ تب مکمل ہوتا ہے جب انوینٹری کا ریکارڈ درست ہو، اپائنٹمنٹ کی تصدیق ہو جائے، اور کسٹمر کو ایک درست ٹریکنگ نمبر موصول ہو جائے۔

تبدیل ہونے والی حالت (Mutable state)۔ بالکل جان لیں کہ ایجنٹ کو کیا تبدیل کرنے کی اجازت ہے۔ کون سے ٹیبلز، کون سی اسٹیٹس، کون سے اکاؤنٹ فلیگز؟ اگر ایجنٹ ریفنڈ جاری کر سکتا ہے، کاموں کو دوبارہ شیڈول کر سکتا ہے، یا بلنگ ایڈریس اپ ڈیٹ کر سکتا ہے، تو آپ کو اس کے چھونے والے ہر فیلڈ کا انوینٹری لسٹ بنانا ہوگا۔

ٹول کی اجازتیں (Tool permissions)۔ اس بارے میں واضح رہیں کہ کون سے API اینڈ پوائنٹس اور فنکشنز اسکوپ میں ہیں۔ سرچ ٹول، رائٹ ٹول، اور نوٹیفیکیشن ٹول تک رسائی رکھنے والا ایجنٹ انہیں مکس کر دے گا اگر حدود غیر واضح ہوں۔ ہر اجازت کو ایک مخصوص آپریشنل ضرورت کے ساتھ جوڑیں۔

ناکامی سے بحالی (Failure recovery)۔ فیصلہ کریں کہ جب کیلنڈر API ٹائم آؤٹ ہو جائے، 500 ایرر دے، یا غلط فارمیٹ والا JSON واپس کرے تو کیا ہوگا۔ ایجنٹ کو گھبرانا نہیں چاہیے، کامیابی کا جھوٹا پیغام (hallucinate) نہیں دینا چاہیے، یا ہمیشہ کے لیے دوبارہ کوشش (retry) نہیں کرنی چاہیے۔ اسے ایک واضح فال بیک (fallback) راستے کی ضرورت ہے۔

انسانی نظر ثانی کے گیٹس (Human review gates)۔ ان لمحات کی نشاندہی کریں جہاں ایجنٹ کے آگے بڑھنے سے پہلے کسی انسان کا منظوری دینا ضروری ہو۔ یہ آٹومیشن میں کمزوری کی علامت نہیں ہے۔ یہ زیادہ اثر والے تبدیلیوں کے لیے ایک سیفٹی والو ہے اور آپ کے ربرکس (rubrics) کے لیے گراؤنڈ ٹروتھ لیبلز کا ذریعہ ہے۔

ایک حقیقی ایویلیوایشن پلان کیسا ہوتا ہے

ایک بار جب انحصار کا نقشہ بن جائے، تو آپ کو ایک ایسے ایویلیوایشن پلان کی ضرورت ہوتی ہے جو پروڈکشن کی پیچیدگیوں کے مطابق ہو۔ سلائیڈ ڈیک میٹرکس یہاں آپ کے کام نہیں آئیں گے۔

حقیقی پروڈکشن کی ناکامیوں سے ٹیسٹ سیٹس بنائیں، نہ کہ مصنوعی سوالات کے بینکوں سے۔ اگر آپ کا ایجنٹ گزشتہ منگل کو دو ملتے جلتے SKUs میں الجھ کر ناکام ہوا تھا، تو وہی الجھن ایک مستقل ٹیسٹ کیس ہونی چاہیے۔ آپ کا ایویلیوایشن سویٹ (evaluation suite) ہر اس واقعے کے ساتھ بڑھنا چاہیے جو آپ کو کچھ نیا سکھاتا ہے۔

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

ٹول کالز اور ری ٹرائیز کے لیے ٹریس سپیکس (trace specs) متعین کریں۔ آپ کو اس بات کی نگرانی (observability) کی ضرورت ہے کہ ایجنٹ نے کیا منصوبہ بنایا، اس نے اصل میں کیا کال کیا، اس نے کتنی بار ری ٹرائی کیا، اور کیا ری ٹرائی کی حکمت عملی مناسب تھی۔ ٹول لیول کی تفصیل کے بغیر ٹریس محض ایک خوبصورت کہانی ہے۔

اس بات کے لیے پالیسیاں بنائیں کہ انسان کو کب الرٹ کرنا ہے۔ ایجنٹ کو اپنی حدود کا علم ہونا چاہیے۔ اگر کوئی درخواست ڈالر کی حد سے تجاوز کرتی ہے، کسی VIP اکاؤنٹ کا حوالہ دیتی ہے، یا ایسی حالت کا سامنا کرتی ہے جو اس نے پہلے کبھی نہیں دیکھی، تو اسے اندازہ لگانے کے بجائے معاملہ آگے (escalate) بڑھانا چاہیے۔

خراب ماڈل اپ گریڈز کو روکنے کے لیے ریلیز گیٹس (release gates) لگائیں۔ ایک نیا ماڈل صرف اس صورت میں اپ گریڈ کہلائے گا اگر وہ آپ کے مخصوص نتائج کو بہتر بنائے۔ اگر یہ ٹول آرگومنٹ کے بارے میں زیادہ غلط معلومات (hallucinate) دیتا ہے، لیٹنسی (latency) بڑھاتا ہے، یا نئے حفاظتی خطرات پیدا کرتا ہے، تو اسے جاری نہیں کیا جانا چاہیے۔ یہ گیٹ پروڈکشن کو مستحکم رکھتا ہے، چاہے بیس ماڈل فراہم کرنے والا کوئی نیا ورژن ہی کیوں نہ جاری کر دے۔

رن ٹائم گریڈنگ (Runtime Grading): ایجنٹ کے کام کرنے کا مشاہدہ کرنا

Anthropic صنعت کو آف لائن ٹیسٹوں سے آگے بڑھ کر رن ٹائم گریڈنگ (runtime grading) کی طرف مائل کر رہا ہے۔ کسی ٹرانسکرپٹ کا حقیقت کے بعد فیصلہ کرنے کے بجائے، رن ٹائم گریڈنگ سسٹم کو اس وقت ایجنٹ کے کام کا جائزہ لینے کی اجازت دیتی ہے جب ٹاسک ابھی عمل میں ہو۔ اس سے غلطیوں کو مستقل مسائل بننے سے پہلے پکڑنے کا موقع ملتا ہے۔

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

ایک مخصوص خامی (blind spot) سے ہوشیار رہیں۔ اگر وہی ماڈل کام بھی کرتا ہے اور اسی کام کی جانچ بھی کرتا ہے، تو ہو سکتا ہے کہ وہ وہی غلطیاں نظر انداز کر دے۔ وہ منطق جس نے غلطی پیدا کی، ریویو کے دوران آسانی سے اس غلطی کا جواز پیش کر سکتی ہے۔ زیادہ اثر والے کاموں کے لیے، انسانی جائزے (human review) کو عمل کا حصہ رکھیں۔ لوگوں کو گریڈر کے اپنے فیصلے کی تصدیق کرنے دیں، خاص طور پر جب معاملہ رقم یا صارف کے اعتماد کا ہو۔

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

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

ایک مہنگی غلطی سے آغاز کریں

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

اگر آپ ماہرین کی کمیونٹی کے ساتھ ایجنٹ ایویلیوایشن اور رن ٹائم گریڈنگ کے بارے میں مزید جاننا چاہتے ہیں، تو آپ GyaanSetu لرننگ کمیونٹی کو https://t.me/GyaanSetuAi پر تلاش کر سکتے ہیں۔