ایک کامیابی بھروسے کی ضمانت نہیں: آپریشنز سونپنے سے پہلے AI ایجنٹ کی جانچ کیسے کریں

سیدھا جواب: ایک کامیاب ڈیمو کسی AI ایجنٹ کی قابلِ اعتمادی کے بارے میں کچھ ثابت نہیں کرتا، کیونکہ درست سوال یہ نہیں کہ اس نے کام ایک بار مکمل کیا یا نہیں، بلکہ یہ ہے کہ کیا وہ اسے ہر بار درست طریقے سے مکمل کرتا ہے۔ Microsoft کی 20 اگست 2026 کو شائع ہونے والی ایک تحقیق میں، جب ہر کام ایک بار چلایا گیا تو سب سے طاقتور ماڈل نے 65.36% اسکور کیا، لیکن صرف 25.25% کاموں میں وہ تمام بیس کوششیں پاس کر سکا۔ یہی فرق اس ایجنٹ کے درمیان فاصلہ ہے جو میٹنگ میں آپ کو متاثر کرتا ہے اور اس ایجنٹ کے درمیان جسے آپ گاہکوں کا ڈیٹا اعتماد سے سونپ سکتے ہیں۔

Microsoft نے دراصل کیا بنایا

اس ٹول کا نام Thinkingbox ہے، جو GitHub پر MIT لائسنس کے تحت جاری کیا گیا ایک اوپن سورس ٹیسٹنگ ماحول ہے۔ خیال سادہ اور ذہین ہے: ٹولز کو براہِ راست ایجنٹ سے جوڑنے کے بجائے آپ انہیں MCP سے ہم آہنگ سرورز کے طور پر متعین کرتے ہیں، ایجنٹ کو اس کے اپنے بیکنگ ڈیٹا بیس والے ایک الگ تھلگ سیشن میں چلاتے ہیں، اور عمل درآمد کا مکمل ریکارڈ محفوظ کرتے ہیں۔

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

اس ماحول کے اوپر ٹیم نے Thinkingbox-bench نامی ایک بینچ مارک بنایا جس میں پانچ شعبوں میں پالیسی کی پابند 507 ورک فلوز شامل ہیں: ریٹیل اور ای کامرس، سفر اور مہمان نوازی، آٹو انشورنس، ایک نیو بینک میں اندرونی IT سپورٹ، اور ایک کنسلٹنگ فرم میں IT اور HR سپورٹ۔ ہر کام کو بارہ ماڈلز پر بیس بار چلایا گیا، جن میں ملکیتی اور اوپن ویٹ دونوں طرح کے ماڈلز شامل تھے۔

یہ عدد کاروبار کے مالک کے لیے کیوں اہم ہے

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

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

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

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

کسی بھی ایجنٹ کو اپنانے سے پہلے کیا کریں

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

Origami میں ہم اسے کیسے سنبھالتے ہیں

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

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

ماخذ

• تحقیقی مقالہ: One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows — arXiv (20 اگست 2026 کو شائع ہوا)
• اوپن سورس ریپوزیٹری: GitHub پر microsoft/thinkingbox