6.8 اے آئی کی جانچ اور ٹیسٹنگ

جائزہ اور محرکات

عام سافٹ ویئر کی ٹیسٹنگ ایک تسلی بخش مفروضے پر ٹکی ہے: ایک ہی ان پٹ دیں تو پروگرام ایک ہی آؤٹ پٹ لوٹاتا ہے، اور آپ بالکل assert کر سکتے ہیں کہ آؤٹ پٹ کیا ہونا چاہیے۔ مصنوعی ذہانت اس مفروضے کو توڑتی ہے۔ ماڈل ایک ہی سوال کا دو مختلف طریقوں سے جواب دے سکتا ہے، دونوں قابل قبول۔ اسے پاس یا فیل کی بجائے غلط سے شاندار تک کے سلسلے پر درجہ دیا جا سکتا ہے۔ اور اکثر کوئی ایک درست جواب نہیں ہوتا جس کے مقابل assert کیا جائے۔ اس لیے تخمینے کا نظم و ضبط، یعنی ایک آؤٹ پٹ کو ایک متوقع قدر سے جانچنے کی بجائے بہت سے نمائندہ معاملات میں ناپنا کہ ماڈل کتنا اچھا برتاؤ کرتا ہے، کسی بھی قابل اعتماد AI نظام کی ریڑھ بن جاتا ہے۔ جب ٹیمیں ایسے AI فیچر بھیجتی ہیں جو انہیں شرمندہ کریں تو بنیادی وجہ تقریباً ہمیشہ یہ ہوتی ہے کہ ریلیز سے پہلے معیار ناپنے کا ان کے پاس کوئی سنجیدہ طریقہ نہ تھا۔

بڑی ٹیموں کے لیے تخمینہ وہ چیز ہے جو تبدیلی کو محفوظ بناتی ہے۔ آپ ماڈلز بدلیں گے، prompts دوبارہ لکھیں گے، retrieval ٹیون کریں گے، اور ٹولز جوڑیں گے، اور ان میں سے ہر تبدیلی خاموشی سے وہ برتاؤ بگاڑ سکتی ہے جسے آپ ٹھوس سمجھتے تھے۔ معیار ناپنے کے دہرائے جانے والے طریقے کے بغیر ہر تبدیلی جوا ہے اور ہر regression صارف دریافت کرتا ہے۔ یہ باب تعمیر کے ابواب کا پیمائش کا ساتھی ہے: جنریٹو AI اور LLM ایپلیکیشنز (باب 6.3)، AI ایجنٹس اور ایجنٹی نظام (باب 6.7)، اور مشین لرننگ انجینئرنگ اور MLOps (باب 6.2)۔ یہ آپ کی عمومی ٹیسٹنگ کی حکمت عملی (باب 2.4) کو امکانی دنیا تک بڑھاتا ہے۔

انٹرپرائز اور سرکاری ترتیبیں داؤ مزید بڑھاتی ہیں۔ درجنوں AI فیچر چلانے والے انٹرپرائز کو مشترک تخمینے کا پلیٹ فارم چاہیے تاکہ ہر ٹیم صفر سے درجہ بندی دوبارہ ایجاد نہ کرے۔ سرکاری ایجنسی کو دستاویزی اور قابل آڈٹ تخمینہ چاہیے، کیونکہ “ہم نے ٹیسٹ کیا” کو “یہ شہادت، ڈیٹا سیٹ، میٹرک، اور منظوری ہے” بننا ہے۔ تخمینہ وہ جگہ ہے جہاں ذمہ دار اور قابل اعتماد AI (باب 6.5) قدر کا بیان ہونا چھوڑ کر ایسی چیز بنتی ہے جو آپ ضابطہ ساز کو دکھا سکیں۔

بنیادی اصول

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

سفارشات

تخمینے سے چلنے والی ڈیولپمنٹ اپنائیں

prompt ٹیون کرنے یا ماڈل چننے سے پہلے تخمینہ لکھیں۔ یہ test-driven development کی عکاسی کرتا ہے: آپ قابل پیمائش اصطلاحات میں متعین کرتے ہیں کہ “اچھا” کا کیا مطلب ہے، پھر اس کی طرف بناتے ہیں۔ یہاں تخمینے کا مطلب ان پٹس کا ڈیٹا سیٹ ہے جو اسکورنگ کے طریقے سے جڑا ہو جو ہر آؤٹ پٹ کے لیے عدد یا درجہ لوٹائے۔ چھوٹا شروع کریں۔ حقیقی صارف کے ارادے کی عکاسی کرنے والے بیس احتیاط سے چنے معاملات ہزار بے ترتیب معاملات سے بہتر ہیں۔ جیسے جیسے سیکھیں کہ نظام کہاں ناکام ہوتا ہے سیٹ بڑھائیں، ہر پروڈکشن ناکامی مستقل معاملے کے طور پر واپس جوڑیں تاکہ وہی غلطی بغیر نوٹس لوٹ نہ سکے۔

تخمینے سے چلنے والی ڈیولپمنٹ ٹیم کا برتاؤ بدلتی ہے۔ جب اچھے کی تعریف لکھی اور قابل عمل ہو تو بحثیں کہ کوئی تبدیلی مددگار تھی یا نہیں ذوق کی بجائے قابل جانچ بن جاتی ہیں۔ تخمینے کے سیٹ کو ورژن کنٹرول میں ریویو شدہ آرٹیفیکٹ بنائیں، ان prompts اور کوڈ کے ٹھیک ساتھ جنہیں وہ ناپتا ہے۔

Offline اور online تخمینہ الگ کریں، اور دونوں استعمال کریں

Offline تخمینہ مقررہ ڈیٹا سیٹ کو کنٹرول شدہ ترتیب میں آپ کے نظام سے گزارتا ہے، تیز، سستا، اور دہرائے جانے کے قابل، تاکہ کچھ بھیجنے سے پہلے آپ ورژنز کا موازنہ کر سکیں۔ Online تخمینہ زندہ نظام کو حقیقی صارفین کے ساتھ کام کی تکمیل، escalation کی شرح، thumbs-up اور thumbs-down کے جواب، اور نیچے کے کاروباری نتائج جیسی میٹرکس سے ناپتا ہے۔ Offline بتاتا ہے کہ تبدیلی کے محفوظ ہونے کا امکان ہے؛ online بتاتا ہے کہ واقعی کام ہوا۔ آپ کو دونوں چاہئیں، کیونکہ offline سیٹ حقیقت کو کبھی پوری طرح نہیں پکڑتے اور online اشارے آپ کا واحد حفاظتی جال ہونے کے لیے بہت دیر سے آتے ہیں۔

دونوں کو چکر میں جوڑیں۔ جب online میٹرکس گریں یا صارفین برے جواب کو نشان زد کریں تو وہ معاملہ پکڑیں، لیبل کریں، اور offline سیٹ میں شامل کریں۔ تجربات کو اسی کنٹرول شدہ موازنے سے گزاریں جو آپ کسی بھی پروڈکٹ کی تبدیلی کے لیے استعمال کرتے ہیں، جو پروڈکٹ تجزیات اور تجربات (باب 7.4) کا علاقہ ہے۔ A/B ٹیسٹ جو دکھائے کہ نیا ماڈل کام میں کامیابی بڑھاتا ہے کسی بھی offline اسکور سے زیادہ قیمتی ہے، پھر بھی offline اسکور ہی تھا جس نے آپ کو ٹیسٹ چلانے کی ہمت دی۔

نمائندہ تخمینے کے سیٹ بنائیں اور آلودگی سے بچاؤ کریں

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

پھر اس ڈیٹا کو آلودگی سے بچائیں۔ ٹیسٹ سیٹ کی آلودگی تب ہوتی ہے جب آپ کے تخمینے کی مثالیں ماڈل کے تربیتی ڈیٹا یا خود prompt میں رس جائیں، اس لیے ماڈل اچھی کارکردگی دکھاتا ہے کیونکہ اس نے عملاً جوابات دیکھ لیے ہیں۔ یہی وجہ ہے کہ ماڈل عوامی benchmark پر شاندار اسکور کر کے آپ کے حقیقی ٹریفک پر لڑکھڑا سکتا ہے۔ اپنے تخمینے کے ڈیٹا کا حصہ نجی رکھیں اور اسے کبھی ایسے تیسرے فریق کو نہ بھیجیں جس پر آپ بھروسہ نہ کر سکیں۔ سیٹس وقت کے ساتھ تازہ کریں۔ اس باریک لیک سے ہوشیار رہیں جہاں ڈویلپرز تخمینے کے سیٹ کے مقابل prompts ہاتھ سے ٹیون کرتے ہیں یہاں تک کہ اسکور بے معنی ہو، حقیقی بہتری کی بجائے ٹیسٹ پر overfitting کی ایک شکل۔ تازہ holdout سیٹ رکھیں جسے آپ کبھی کبھار ہی دیکھیں۔

کام کے مطابق میٹرکس چنیں

اپنی پیمائش کو آؤٹ پٹ کی شکل سے ملائیں۔ درجہ بندی اور نکالنے کے لیے، جہاں درست لیبل ہے، کلاسیکی میٹرکس لاگو ہوتی ہیں: precision اور recall (جن اشیاء کو آپ نے نشان زد کیا ان میں سے کتنی درست تھیں، اور درست اشیاء میں سے آپ نے کتنی پائیں)، انہیں متوازن کرنے والا F-score، اور exact-match کی درستگی۔ ہر اس چیز کے لیے جہاں پراعتماد امکان اہم ہے، calibration ناپیں، یعنی کیا بتایا ہوا 80 فیصد اعتماد تقریباً 80 فیصد وقت درست ہے، کیونکہ اچھی طرح کیلیبریٹ ماڈل جو جانتا ہے کہ کب غیر یقینی ہے حد سے زیادہ پراعتماد ماڈل سے کہیں محفوظ ہے۔

جنریٹو آؤٹ پٹس مشکل ہیں۔ حوالے پر مبنی میٹرکس جیسے BLEU اور ROUGE، جو اصل میں مشینی ترجمے اور خلاصہ نگاری کے لیے بنیں، بنائے متن کا حوالہ متن سے موازنہ الفاظ اور فقروں کا اوور لیپ گن کر کرتی ہیں۔ وہ سستی اور دہرائی جانے والی ہیں، اور معیار کی کمزور proxies ہیں: وہ سطحی اوور لیپ کو انعام اور حوالے سے مختلف الفاظ میں لکھے درست جواب کو سزا دیتی ہیں۔ انہیں موٹے regression کے اشاروں کے طور پر استعمال کریں، اچھے کی اپنی تعریف کے طور پر نہیں۔ کھلے کاموں کے لیے rubric پر مبنی اسکورنگ بہتر کام کرتی ہے: واضح معیار متعین کریں (کیا یہ بنیاد شدہ، مکمل، محفوظ، اور درست فارمیٹ میں ہے) اور ہر ایک کو اسکور کریں۔ Rubrics موضوعی معیار کو پڑھنے اور ریویو کے قابل بناتے ہیں۔

LLM-as-a-judge استعمال کریں، مگر اسے انسانوں کے مقابل کیلیبریٹ کریں

جنریٹو آؤٹ پٹ کو ہاتھ سے درجہ دینا پیمانہ نہیں پاتا، اس لیے ٹیمیں بڑھتی طور پر مضبوط بڑے زبان کے ماڈل کو خودکار جج کے طور پر استعمال کرتی ہیں، اسے ان پٹ، آؤٹ پٹ، اور rubric کے ساتھ prompt کر کے اور اسکور کرنے کو کہہ کر۔ یہ LLM-as-a-judge کا طریقہ تیز اور حیران کن حد تک قابل ہے، اور حقیقی تعصبات ساتھ رکھتا ہے جنہیں آپ کو منظم کرنا ہے۔ جج لمبے جوابات کو ترجیح دیتے ہیں، جوڑی کے موازنے میں پہلا دکھایا اختیار پسند کرتے ہیں (مقام کا تعصب)، اپنے لکھنے کے انداز کو انعام دیتے ہیں، اور رواں مگر غلط استدلال سے متاثر ہو سکتے ہیں۔ بغیر جانچ کے متعصب جج آپ کو پراعتماد، درست، غلط اعداد دیتا ہے۔

جج کو انسانی لیبلز کے مقابل کیلیبریٹ کریں۔ لوگوں سے نمونے کی درجہ بندی کرائیں، پھر جانچیں کہ ماڈل جج ان سے کتنا متفق ہے، اور جج کے prompt کو ٹیون کرتے رہیں جب تک اتفاق بھروسے کے لیے کافی بلند نہ ہو۔ معلوم تعصبات دانستہ گھٹائیں: اختیارات کی ترتیب بے ترتیب کریں، لمبائی کو قابو کریں، اور خالی عدد کی بجائے وجوہات کے ساتھ rubric سے لنگر انداز اسکور مانگیں۔ جج کو ایسا ناپنے کا آلہ سمجھیں جسے وقتاً فوقتاً دوبارہ کیلیبریشن چاہیے، مقررہ oracle نہیں۔ جج بناتے ہوئے دستیاب سب سے قابل ماڈل پر ڈیفالٹ کریں، کیونکہ کمزور جج کمزور پیمانہ ہے۔

زمینی سچائی کے لیے انسانوں کو لوپ میں رکھیں

انسانی تخمینہ وہ لنگر رہتا ہے جس کے مقابل ہر خودکار میٹرک ناپی جاتی ہے، اس لیے اسے اچھی طرح کرنے میں سرمایہ لگائیں۔ واضح annotation کی ہدایات لکھیں، اپنے annotators کو تربیت دیں، اور inter-annotator اتفاق ناپیں، وہ حد جس تک آزاد ریویو کرنے والے ایک ہی معاملے کو ایک ہی درجہ دیتے ہیں۔ کم اتفاق کا عموماً مطلب ہے کہ آپ کا rubric مبہم ہے، یہ نہیں کہ آپ کے ریویو کرنے والے لاپرواہ ہیں، اس لیے rubric ٹھیک کریں۔ زیادہ داؤ کے شعبوں کے لیے ماہر لوگ استعمال کریں، ہجوم کے کارکن نہیں جن کے پاس قانونی یا طبی جواب پرکھنے کا سیاق نہیں۔

حفاظت اور مخالفانہ مضبوطی کے لیے red-team کریں

معیاری تخمینے کے سیٹ ناپتے ہیں کہ نظام معقول ان پٹس پر درست کام کرتا ہے یا نہیں۔ Red teaming، اپنے ہی نظام پر دانستہ حملہ کر کے یہ ڈھونڈنا کہ وہ کہاں غلط برتاؤ کرتا ہے، ناپتی ہے کہ دباؤ میں کیا ہوتا ہے۔ prompt injection، jailbreaks، غیر محفوظ مواد، رازداری کے لیک، اور متعصب آؤٹ پٹس کی جانچ کریں۔ اسے دہرانے کے قابل سویٹ بنائیں، ایک بار کی مشق نہیں: ہر کامیاب حملے کو مستقل regression معاملے میں بدلیں تاکہ ٹھیک کی ہوئی کمزوری ٹھیک رہے۔ یہ کام براہ راست ذمہ دار اور قابل اعتماد AI (باب 6.5) سے جڑتا ہے، اور ضابطے کے پابند ترتیبوں میں یہ اکثر وہ شہادت ہے جو حفاظت کے ریویو کو مطمئن کرتی ہے۔

ایجنٹس کو سرے سے سرے تک کام کی کامیابی پر پرکھیں

وہ ایجنٹس جو کئی قدموں میں منصوبہ بناتے اور عمل کرتے ہیں انہیں ایک وقت میں ایک آؤٹ پٹ سے نہیں پرکھا جا سکتا۔ جو اہم ہے وہ یہ کہ پورا کام کامیاب ہوا: کیا ایجنٹ نے میٹنگ بک کی، ٹکٹ حل کیا، یا ورک فلو درست اور محفوظ طور پر مکمل کیا۔ sandbox شدہ ماحول میں کام کی سطح کے تخمینے بنائیں جہاں ایجنٹ حقیقت پسندانہ مگر محفوظ fixtures کے مقابل عمل کر سکے، اور آخری نتائج جمع trajectory اسکور کریں، یعنی وہاں تک پہنچنے میں اس کے لیے گئے قدموں اور ٹول کالز کا سلسلہ۔ خطرناک یا فضول راستے سے پہنچا درست جواب پھر بھی مسئلہ ہے۔ یہ AI ایجنٹس اور ایجنٹی نظام (باب 6.7) کے لیے ضروری ہے، جہاں ایک غلط عمل کے حقیقی نتائج ہو سکتے ہیں۔

تخمینوں کو CI میں جوڑیں اور پروڈکشن کی نگرانی کریں

تخمینے کو خودکار بنائیں۔ ہر prompt، ماڈل، یا retrieval کی تبدیلی پر اپنا offline سویٹ continuous integration (CI) میں چلائیں، اور merges کو اس پر یوں دروازہ دار کریں جیسے آپ unit ٹیسٹوں پر کرتے ہیں، وہ عمل جو آپ کی وسیع تر ٹیسٹنگ کی حکمت عملی (باب 2.4) میں جڑا ہے۔ چونکہ اسکور شور والے ہیں، کامل رن مانگنے کی بجائے حدوں اور رجحانات پر دروازہ لگائیں، اور بلڈ ناکام کریں جب کوئی اہم میٹرک اپنے فرش سے نیچے گرے یا طے شدہ حاشیے سے زیادہ regress ہو۔ پھر پروڈکشن میں دیکھتے رہیں: معیار کے اشارے، آؤٹ پٹ کی تقسیم، اور ان پٹ drift کی نگرانی کریں تاکہ آپ وہ سست زوال پکڑیں جو offline ٹیسٹ چوک جاتے ہیں، جو مشین لرننگ انجینئرنگ اور MLOps (باب 6.2) کے مشاہدے کے عمل سے جڑتا ہے۔ لانچ پر درست ماڈل اس دنیا کے بدلنے سے بگڑ سکتا ہے جسے وہ بیان کرتا ہے۔

سمجھوتے: فوائد اور نقصانات

تخمینے کا طریقہ	فوائد	نقصانات	بہترین جب
انسانی تخمینہ	اعلیٰ ترین وفاداری، باریکی پکڑتا ہے	سست، مہنگا، پیمانہ پانا مشکل	زمینی سچائی، زیادہ داؤ، ججوں کی کیلیبریشن
LLM-as-a-judge	تیز، سستا، بڑے سیٹس تک پیمانہ	متعصب، کیلیبریشن چاہیے	جنریٹو آؤٹ پٹ پر بار بار offline رنز
حوالے پر مبنی میٹرکس (BLEU، ROUGE)	سستی، قطعی، دہرائی جانے والی	حقیقی معیار کی کمزور proxy	موٹے regression کے اشارے، آخری فیصلے نہیں
کلاسیکی میٹرکس (precision، recall، F-score)	معروضی، اچھی طرح سمجھی گئی	صرف درست لیبل والے کاموں کو موزوں	درجہ بندی، نکالنا، retrieval
عوامی benchmarks	ماڈلز میں قابل موازنہ، کوئی ترتیب نہیں	آلودگی، آپ کے کام سے ناقص موزونیت	ابتدائی ماڈل کی چھانٹی، ریلیز کے دروازے نہیں
Online تخمینہ (A/B، جواب)	حقیقی صارفین اور نتائج کی عکاسی	سست، نمائش کے بعد آتا ہے	تصدیق کہ تبدیلی نے واقعی مدد کی

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

اپنی ٹیم کے ساتھ بحث کے سوالات

1. “کافی اچھا” کا ہمارا معیار کیا ہے، اور اسے متعین کرنے والے تخمینے کے سیٹ کا مالک کون ہے؟ ہر AI فیچر کا مضمر معیار کی حد ہے، اور جب وہ مضمر رہتی ہے تو ہر انجینئر اپنی اندازے سے طے کرتا ہے اور تنازعات کمرے کے سب سے سینئر شخص کے حق میں طے ہوتے ہیں۔ معیار کو فی طبقہ ہدف کے اسکور کے ساتھ قابل عمل تخمینے کے سیٹ کے طور پر لکھنا ان تنازعات کو قابل پیمائش سوالوں میں بدلتا ہے۔ کامیابی کی اپنی موجودہ تعریف، اس کے پیچھے کا ڈیٹا، اور اس کی ملکیت کا ایماندار بیان لائیں، کیونکہ مالک کے بغیر تخمینے کا سیٹ کسی بھی بے توجہ کوڈ جتنی تیزی سے سڑتا ہے۔ طے کریں کہ آیا معیار خطرے کے درجے سے مختلف ہو، کیونکہ عوام کی طرف قانونی جواب کو اندرونی brainstorming معاون سے اونچا معیار پار کرنا چاہیے۔ جواب کو بتانا چاہیے کہ کیا کوئی آج AI کی تبدیلی بغیر پیمائش کے اپنے اور صارفین کے درمیان کھڑے ہوئے بھیج سکتا ہے۔

2. ہمیں کیسے پتا کہ ہمارے تخمینے کے اعداد آلودہ یا overfit ہونے کی بجائے دیانت دار ہیں؟ اسکور تبھی مفید ہے جب وہ حقیقی دنیا کے معیار کی پیش گوئی کرے، اور اس کے رکنے کے بہت سے طریقے ہیں: benchmark کا ڈیٹا تربیت میں رسنا، ڈویلپرز کا ٹیسٹ سیٹ کے مقابل prompts ٹیون کرنا یہاں تک کہ عدد بے معنی ہو، یا golden ڈیٹا سیٹ جو کبھی توثیق نہ ہوئے جوابات پر بنا ہو۔ شہادت لائیں کہ آپ کا تخمینے کا ڈیٹا کہاں سے آیا، اس کا کتنا حصہ نجی رکھا گیا، اور کتنی بار تازہ ہوتا ہے۔ بحث کریں کہ آیا آپ تازہ holdout رکھتے ہیں جسے شاذ دیکھتے ہیں، تاکہ آپ کے پاس کم از کم ایک عدد ہو جس کے مقابل کسی نے بہتری نہیں کی۔ اگر آپ وضاحت نہیں کر سکتے کہ آپ کے اسکور ایسے ڈیٹا پر کیوں برقرار رہیں گے جسے ماڈل نے کبھی متاثر نہیں کیا تو آپ اپنا ہی عکس ناپ رہے ہیں۔

3. انسان لوپ میں کہاں رہتے ہیں، اور ہم اپنے خودکار ججوں کو ان کے مقابل کیلیبریٹ کیسے رکھتے ہیں؟ LLM-as-a-judge اور حوالے کی میٹرکس آپ کو پیمانے پر درجہ بندی کرنے دیتی ہیں، اور وہ انسانی فیصلے سے ان طریقوں سے بھٹکتی ہیں جو جانچے بغیر نظر نہیں آتے۔ خودکار درجہ بندی اور انسانی ریویو کے درمیان اتفاق کی اپنی موجودہ شرح، آپ نے اسے آخری بار کب ناپا، اور آپ نے کون سے تعصبات (لمبائی، مقام، انداز) کے لیے ٹیسٹ کیا لائیں۔ طے کریں کون سے فیصلوں کو لاگت سے قطع نظر انسانی گریڈر چاہیے، عموماً سب سے زیادہ داؤ والے اور وہ جو خودکار جج کو دوبارہ کیلیبریٹ کرنے میں استعمال ہوں۔ annotation کے معیار پر بھی بات کریں، کیونکہ غیر مستقل انسانی لیبلز کے مقابل کیلیبریٹ شدہ جج وہ عدم مستقل مزاجی وراثت میں پاتا ہے۔ جواب کو دوبارہ کیلیبریشن کا شیڈول دینا چاہیے، ایک بار کی برکت نہیں۔

4. آج کون سی AI تبدیلیاں تخمینے پر دروازہ دار ہیں، اور کون سی اب بھی کسی کے اعتماد کی بنا پر صارفین تک پہنچتی ہیں؟ وہ دروازہ جو کچھ تبدیلیوں پر چلے اور دوسروں پر نہیں آپ کو حفاظت کا فریب دیتا ہے جبکہ حقیقی regressions بغیر دروازے کے راستے سے پھسل جاتے ہیں: خاموش prompt کی ترمیم، retrieval کی ٹیوننگ، ماڈل ورژن کی تبدیلی جسے کسی نے تبدیلی نہ سمجھا۔ بڑی ٹیم کے لیے خطرہ prompt کو چھو سکنے والے لوگوں کی تعداد کے ساتھ بڑھتا ہے، کیونکہ ہر بغیر دروازے کا راستہ ایسی regression بھیجنے کا طریقہ ہے جو کسی ڈیٹا سیٹ نے کبھی نہیں دیکھی۔ تبدیلی کی اقسام کی فہرست لائیں جو اس وقت continuous integration میں offline سویٹ ٹرگر کرتی ہیں، جو نہیں کرتیں، اور بغیر دروازے کی تبدیلی سے متعلق حالیہ واقعات۔ طے کریں دروازہ کون سی حد اور رجحان نافذ کرتا ہے، کیونکہ شور والا اسکور کامل رن مانگنے کی بجائے فرش اور regression کا حاشیہ مانگتا ہے۔ انٹرپرائز اور سرکاری ترتیبوں میں دروازے کو ریلیز کے ریکارڈ سے خود جوڑیں، تاکہ ثبوت کہ تبدیلی ناپی گئی آڈٹ کے نشان کا حصہ ہو، اسکرین شاٹ نہیں جو کسی نے ایک بار لیا۔

5. ہم تخمینے پر کتنا خرچ کر رہے ہیں، اور کیا وہ خرچ ہر فیچر کے خطرے سے ملتا ہے؟ تخمینہ مفت نہیں: annotation کی محنت، ہر رن پر خودکار جج جو compute جلاتے ہیں، اور golden datasets کو نمائندہ رکھنے کا مستقل کام سب حقیقی پیسہ لیتے ہیں، اور وہ ٹیم جو ان لاگتوں کا کبھی نام نہ لے اکثر یا زیادہ داؤ کے فیچر پر کم سرمایہ لگاتی ہے یا ردی فیچر پر سونے کا ملمع چڑھاتی ہے۔ متصادم کشش وفاداری اور بجٹ کے درمیان ہے، کیونکہ سب سے قابل بھروسہ طریقہ، ماہر انسانی ریویو، سب سے کم قابل پیمائش بھی ہے، اس لیے آپ اسے ہر جگہ برداشت نہیں کر سکتے اور طے کرنا ہوگا کہ وہ اپنی قیمت کہاں کماتا ہے۔ فی تخمینے کے رن موجودہ لاگت، فی فیچر annotation کے گھنٹے، اور ہر نظام کے لیے ایماندار خطرے کا درجہ لائیں تاکہ کمرہ دیکھ سکے کہ پیسہ کہاں جاتا ہے بمقابلہ خطرہ کہاں رہتا ہے۔ انٹرپرائز کے لیے یہ مشترک تخمینے کے پلیٹ فارم کی سب سے مضبوط دلیل ہے جو بہت سی ٹیموں میں annotation اور compute کو بٹاتا ہے؛ سرکاری ایجنسی کے لیے خطرے کا درجہ براہ راست اس شہادت کی گہرائی سے ملنا چاہیے جو نگرانی کا ادارہ بعد میں مانگے گا۔

6. جب بہتر ماڈل آئے تو ہم کتنی جلد ثابت کر سکتے ہیں کہ وہ مدد کرتا ہے، اور بدلنے کی اجازت کس کو ہے؟ تخمینے کے سویٹ کی قدر سب سے تیزی سے اس دن محسوس ہوتی ہے جب مضبوط ماڈل آئے، کیونکہ وہ ٹیم جو اپنے golden datasets اور red-team سویٹ نئے ماڈل کے مقابل ایک دوپہر میں چلا سکے وہ بہتریاں اپنا سکتی ہے جو ہاتھ سے درجہ بندی کرنے والی ٹیم مہینوں چوک جائے گی۔ کھنچاؤ رفتار اور احتیاط کے درمیان ہے: آپ چاہتے ہیں کہ جس دن بہتر ماڈل آئے آپ آگے بڑھیں، اور آپ تبدیلی کو جوابات کا وہ زمرہ خاموشی سے بگاڑنے نہیں دے سکتے جسے آپ کا اوسط اسکور چھپاتا ہے۔ نئے فراہم کنندہ کے مقابل مکمل offline موازنہ چلانے میں اس وقت کتنا وقت لگتا ہے، آیا آپ کے تخمینے کے سیٹ ماڈلز میں قابل منتقلی ہیں، اور وہ طبقات جہاں regression سب سے زیادہ اہم ہوگی لائیں۔ ضابطے کے پابند اور عوامی ترتیبوں میں نام لیں کہ ماڈل کی تبدیلی منظور کرنے کا اختیار کس کے پاس ہے اور وہ کون سی دستاویزی شہادت مانگتے ہیں، کیونکہ شہری کے فیصلے کے پیچھے ماڈل کی غیر دستاویزی تبدیلی ٹھیک وہ تبدیلی ہے جس کا جواز آڈیٹر آپ سے مانگے گا۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ سب سے چھوٹا دیانت دار تخمینہ بنائیں جو آپ بنا سکتے ہیں اور اسے پروڈکٹ کے ساتھ بڑھنے دیں۔ بیس سے چالیس حقیقی معاملات کی اسپریڈ شیٹ، ہر ایک جانچے متوقع جواب کے ساتھ، ہر merge سے پہلے اسکرپٹ سے چلائی گئی، آپ کے مخصوص شعبے کے لیے کسی بھی عوامی benchmark سے بہتر ہے اور تقریباً کچھ لاگت نہیں لیتی۔ مشترک پلیٹ فارم اور LLM-as-a-judge اس وقت تک چھوڑ دیں جب تک ہاتھ سے درجہ بندی واقعی تکلیف نہ دے، لیکن پہلے دن سے صارف کی رپورٹ کی گئی ہر ناکامی سیٹ میں واپس جوڑیں، کیونکہ یہی ردعمل وہی شرمندگی دو بار ہونے سے روکتا ہے۔

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

بڑا ادارہ۔ انعام مشترک تخمینے کا پلیٹ فارم ہے تاکہ درجن ٹیمیں درجہ بندی دوبارہ ایجاد نہ کریں: golden datasets کے لیے عام ذخیرہ، continuous integration میں دروازہ دار offline سویٹس، اپنے کیلیبریشن اسکورز کے ساتھ رجسٹر شدہ LLM-judge prompts، اور فی فیچر online میٹرکس۔ اس کے اوپر نظم و نسق خطرے کے درجوں کے ساتھ لگائیں جو مطلوبہ معیار اور ریلیز سے پہلے منظوری طے کریں، تاکہ زیادہ داؤ کا فیچر اندرونی معاون سے اونچا دروازہ پار کرے۔ پلیٹ فارم ٹیموں میں annotation اور compute بٹاتا ہے، جو ہر گروہ کو فی البدیہہ کرنے دینے کی بجائے بنانے کی سب سے مضبوط وجہ ہے۔

حکومت۔ تخمینہ قابل آڈٹ ہونا چاہیے، محض کیا جانا نہیں، اس لیے ہر ریلیز کے لیے جوابدہی کی شہادت کے طور پر ڈیٹا سیٹ ورژن، میٹرکس، ریویو کرنے والے کا نام، اور منظوری محفوظ کریں۔ red-team سویٹ کو ثابت کرنا چاہیے کہ نظام اپنے ذرائع میں غائب پالیسی ایجاد کرنے یا قانون بتانے سے انکار کرتا ہے، اور خریداری کو فروخت کنندگان سے مطالبہ کرنا چاہیے کہ وہ افشا کریں کہ انہوں نے ماڈل کا تخمینہ کیسے کیا اور آپ کے تخمینے کے ڈیٹا کی منتقلی کی ضمانت دیں۔ جب نگرانی کا ادارہ پوچھے کہ آپ کو کیسے پتا کہ ٹول محفوظ ہے تو جواب تاریخ شدہ ریکارڈ ہونا چاہیے، یقین دہانی نہیں۔

مثالیں

اسٹارٹ اپ۔ AI معاہدے کے ریویو کا معاون بنانے والی چار افراد کی کمپنی نے چالیس حقیقی شقوں کی اسپریڈ شیٹ سے آغاز کیا، ہر ایک کو ان کے اندرونی وکیل نے اس خطرے سے لیبل کیا جسے اسے نشان زد کرنا چاہیے۔ ہر prompt کی تبدیلی merge سے پہلے اسکرپٹ میں اس سیٹ کے مقابل چلتی، اور اسکور pull request میں چھپتا۔ جب صارفین نے چھوٹی شق کی نشاندہی کی تو وہ سیدھی شیٹ میں گئی، اس لیے سیٹ پروڈکٹ کے ساتھ بڑھا۔ حجم بڑھنے پر انہوں نے وضاحت کے معیار کو درجہ دینے کو LLM-as-a-judge جوڑا، مگر صرف نمونے پر جانچنے کے بعد کہ وہ وکیل سے متفق ہے۔ سستا، نجی، اور دیانت دار ان کے مخصوص شعبے کے لیے کسی بھی عوامی benchmark سے بہتر رہا۔

بڑا ادارہ۔ بڑے بینک نے معاونت، تلاش، اور اندرونی ٹولنگ میں درجن AI فیچر چلائے، اور ہر ٹیم مختلف طرح درجہ بندی کرتی رہی تھی۔ انہوں نے مشترک تخمینے کا پلیٹ فارم بنایا: golden datasets رکھنے، CI میں offline سویٹس چلانے، کیلیبریشن اسکورز کے ساتھ LLM-judge prompts رجسٹر کرنے، اور فی فیچر online میٹرکس ٹریک کرنے کی مشترک جگہ۔ نظم و نسق اس کے اوپر بیٹھا، خطرے کے درجوں کے ساتھ جو مطلوبہ معیار اور ریلیز سے پہلے منظوری طے کرتے۔ نیا fraud-explanation فیچر اس وقت تک نہیں بھیجا جا سکتا تھا جب تک اس کے تخمینے کے سیٹ کا ریویو نہ ہو، red-team سویٹ پاس نہ ہو، اور جوابدہ مالک نتائج پر دستخط نہ کرے۔ پلیٹ فارم دوبارہ استعمال کرنے کا مطلب تھا کہ ٹیمیں اپنے شعبے پر بحث کرتیں، ناپنے کے طریقے پر نہیں۔

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

کاروباری جواز: محرکات، ROI اور TCO

تخمینہ ہر دوسری AI سرمایہ کاری کو محفوظ اور تیز بنا کر اپنی ادائیگی خود کرتا ہے۔ اس کی سرمایہ کاری پر واپسی (ROI) کم پروڈکشن واقعات، تیز تکرار کے طور پر ظاہر ہوتی ہے کیونکہ ٹیمیں اعتماد سے prompts اور ماڈلز بدل سکتی ہیں، اور بہتر ماڈلز آتے ہی اپنانے کی صلاحیت کے طور پر کیونکہ آپ ثابت کر سکتے ہیں کہ آیا وہ مدد کرتے ہیں۔ اس کی قدر لگانے کا واضح ترین طریقہ اس کی غیر موجودگی کی لاگت ہے: ایک عوامی hallucination، متعصب آؤٹ پٹ، یا ڈیٹا لیک اصلاح، کھوئے اعتماد، اور ضابطے کی نمائش میں تخمینے کے انفراسٹرکچر کے برسوں سے کہیں زیادہ لاگت دے سکتا ہے۔ یہ CI میں مفت regression ڈھونڈنے اور اخبار میں ڈھونڈنے کا فرق ہے۔

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

ضد نمونے اور خامیاں

• اندازے پر بھیجنا۔ ڈیٹا سیٹ اور دہرائے جانے والے اسکور کے بغیر چند prompts ہاتھ سے آزما کر AI کی تبدیلیوں کو پرکھنا۔
• Benchmark کا تھیٹر۔ مضبوط عوامی benchmark اسکور پر بھروسہ کہ نظام آپ کے کام کو موزوں ہے، آلودگی اور تقسیم کی بے میلی نظر انداز کرتے ہوئے۔
• تخمینے کے سیٹ پر overfitting۔ اسی مقررہ سیٹ کے مقابل prompts ٹیون کرنا یہاں تک کہ عدد بلند اور بے معنی ہو، بغیر تازہ holdout کے۔
• غیر کیلیبریٹ ججز۔ LLM-as-a-judge تعینات کرنا اور انسانی گریڈرز سے اتفاق جانچے بغیر اس کے اسکور پر بھروسہ کرنا۔
• میٹرک کی پرستش۔ BLEU یا ROUGE کو معیار سمجھ کر بہتر بنانا، اور ایسے بدتر جوابات بھیجنا جو حوالے کے متن سے اتفاقاً اوور لیپ کرتے ہیں۔
• ایک بار کی red teaming۔ نظام پر لانچ سے پہلے ایک بار حملہ کرنا اور نتائج کو مستقل regression ٹیسٹوں میں کبھی نہ بدلنا۔
• صرف offline اعتماد۔ یہ ماننا کہ اچھا offline اسکور فیچر کے کام کرنے کا مطلب ہے، حقیقی نتائج کی online پیمائش کے بغیر۔
• یتیم تخمینے کے سیٹس۔ ڈیٹا سیٹس جن کا کوئی مالک نہیں، جو پروڈکشن کی ناکامیاں کبھی جذب نہیں کرتے اور آہستہ حقیقت کی عکاسی چھوڑ دیتے ہیں۔

پختگی کا ماڈل

• سطح 1، آغاز: AI کی تبدیلیاں چند مثالوں پر ہاتھ سے پرکھی جاتی ہیں، ردعملی طور پر، جب کسی کو اتفاق سے فکر ہو۔ کوئی ڈیٹا سیٹ، دہرایا جانے والا اسکور، یا دروازہ نہیں۔ regressions صارفین پاتے ہیں، اور کوئی نہیں بتا سکتا کہ نظام پچھلے مہینے سے بہتر ہے یا بدتر۔
• سطح 2، ترقی: کچھ ٹیمیں چھوٹے golden datasets رکھتی ہیں اور بڑی تبدیلیوں سے پہلے انہیں ہاتھ سے چلاتی ہیں، اور کچھ کلاسیکی یا حوالے پر مبنی اسکور موجود ہیں۔ اہم فیچرز کے لیے انسانی ریویو ہوتا ہے، مگر ٹیموں میں درجہ بندی غیر مستقل ہے، تخمینہ خودکار یا دروازہ دار نہیں، اور ہر گروہ مختلف طرح کرتا ہے۔
• سطح 3، معیار بندی: Offline سویٹس continuous integration میں ہر prompt، ماڈل، یا retrieval کی تبدیلی پر چلتے اور merges کو دروازہ دار کرتے ہیں، ادارے میں ایک دستاویزی عمل کی پیروی کرتے ہوئے۔ LLM-as-a-judge انسانی لیبلز کے مقابل کیلیبریٹ ہے، red teaming دہرایا جانے والا سویٹ ہے، اور ڈیٹا سیٹس ملکیت میں، ورژن شدہ، اور پروڈکشن کی ناکامیوں سے کھلائے جاتے ہیں، آلودگی سے فعال بچاؤ کے ساتھ۔
• سطح 4، انتظام: تخمینہ بنیادی خطوط کے مقابل ڈیٹا سے ناپا اور کنٹرول کیا جاتا ہے۔ جج-انسان کے اتفاق کی شرحیں، red-team کی پاس کی شرحیں، فی طبقہ اسکور، online کام کی کامیابی، اور drift وقت کے ساتھ ٹریک ہوتے ہیں، اور merges ایک کامل رن کی بجائے حدوں اور regression کے حاشیوں پر دروازہ دار ہوتے ہیں۔ Annotation کی لاگت اور فی رن compute فی فیچر بجٹ ہوتے ہیں، دوبارہ کیلیبریشن شیڈول پر ہوتی ہے، اور ہر نتیجہ جوابدہ مالک اور منظوری رکھتا ہے۔
• سطح 5، ہم آہنگی: مشترک تخمینے کا پلیٹ فارم پورے ادارے کی خدمت کرتا ہے، اور offline اور online تخمینہ کاروباری نتائج سے بندھا مسلسل چکر بناتے ہیں۔ نئے ماڈل آتے ہی قابل منتقلی تخمینے کے سیٹس کے مقابل ثابت ہوتے ہیں، پورٹ فولیو استعمال اور خطرے کے بدلنے پر ڈھلتا ہے، تخمینے کی شہادت ضابطہ سازوں اور نگرانی کے لیے قابل آڈٹ ہے، اور ایک ٹیم کی ناکامیوں کے اسباق ہر ٹیم کے ڈیٹا سیٹس میں بہتے ہیں۔

بحث کے لیے خیالات

1. آپ کیسے طے کرتے ہیں کہ offline اسکور online تجربے کا جواز بننے کے لیے کب کافی مضبوط ہے، اور کب نہیں؟
2. آپ کے خطرے کے پروفائل کے لیے انسانی تخمینے اور خودکار درجہ بندی کا درست تناسب کیا ہے، اور آپ کو اسے کتنی بار دیکھنا چاہیے؟
3. جب عوامی benchmark اور آپ کا نجی تخمینے کا سیٹ اس پر متفق نہ ہوں کہ کون سا ماڈل بہتر ہے تو آپ کس پر بھروسہ کرتے ہیں اور کیوں؟
4. جب صارف کا برتاؤ بدلے تو آپ تخمینے کے سیٹ کو نمائندہ کیسے رکھتے ہیں، اسے اتنا پھولنے دیے بغیر کہ CI میں چلنا سست ہو جائے؟
5. آپ کے شعبے کے red-team سویٹ میں کیا ہونا چاہیے، اور حملے ڈیزائن کرنے کا اہل کون ہے؟
6. آپ ہر قدم کی درجہ بندی کی لاگت میں ڈوبے بغیر ایجنٹ کی صرف آخری جواب نہیں بلکہ trajectory کا تخمینہ کیسے کرتے ہیں؟

اہم نکات

• AI کا تخمینہ سافٹ ویئر کی ٹیسٹنگ سے مختلف ہے کیونکہ آؤٹ پٹس غیر متعین ہیں اور شاذ ایک درست جواب ہوتا ہے، اس لیے آپ قطعی قدریں assert کرنے کی بجائے نمائندہ معاملات میں معیار ناپتے ہیں۔
• تخمینے سے چلنے والی ڈیولپمنٹ پر عمل کریں: پہلے قابل پیمائش معیار متعین کریں، پھر اس کی طرف بنائیں، اور ہر پروڈکشن کی ناکامی سیٹ میں واپس جوڑیں۔
• طریقوں کو رفتار اور وفاداری سے تہہ دار کریں: مسلسل تکرار کے لیے سستی خودکار درجہ بندی، لنگر کے طور پر انسانی فیصلہ، اور انہیں ہم آہنگ رکھنے کو کیلیبریشن۔
• آلودگی اور overfitting سے بچیں، ورنہ آپ کے اعداد آپ کی خوشامد کریں گے جبکہ حقیقی نظام صارفین کو مایوس کرتا ہے۔
• offline تخمینے کو CI میں دروازے کے طور پر جوڑیں اور پروڈکشن میں معیار اور drift ناپتے رہیں، کیونکہ لانچ پر اچھا ماڈل بگڑ سکتا ہے۔

حوالہ جات اور مزید مطالعہ

• Chip Huyen, AI Engineering: Building Applications with Foundation Models.
• Lianmin Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
• Kishore Papineni et al., BLEU: A Method for Automatic Evaluation of Machine Translation.
• Chin-Yew Lin, ROUGE: A Package for Automatic Evaluation of Summaries.
• Percy Liang et al., Holistic Evaluation of Language Models (HELM).
• Deep Ganguli et al., Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviours, and Lessons Learned.
• OWASP Foundation, OWASP Top 10 for Large Language Model Applications.
• National Institute of Standards and Technology, AI Risk Management Framework.