قابلِ اعتماد تیسرے فریق کی evaluations کے لیے ایک مشترک رہنما

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

پہلے، بہت سی evaluations ماڈلز کو chatbots کی طرح سمجھتی تھیں: evaluation ماڈل کو ایسے پرومپٹ دیتی تھی جیسے کوئی صارف سوال پوچھ رہا ہو، ماڈل جواب دیتا تھا، اور evaluator آؤٹ پٹ کا فیصلہ کرتا تھا. آج کے فرنٹیئر ماڈلز اس سے کہیں زیادہ کر سکتے ہیں: وہ tools استعمال کر سکتے ہیں، کئی مراحل میں معلومات کا حساب رکھ سکتے ہیں، اور ایک بڑے workflow کے اندر عمل کر سکتے ہیں. اس کا مطلب ہے کہ کارکردگی صرف ماڈل پر نہیں بلکہ اس environment پر بھی منحصر ہے جس میں کام انجام پاتا ہے، اور اس setup پر بھی جو اس کے اعمال کو ممکن بناتا ہے. یہ گرد و پیش کا setup، جسے ہم “harness” کہتے ہیں، نظام کی کارکردگی کے اہم پہلو بدل سکتا ہے، جن میں tools کا استعمال، معلومات کا حساب رکھنا، یا غلطیوں سے سنبھلنا شامل ہے.

اس سے یہ بدل جاتا ہے کہ evaluations کیسے کی جانی چاہییں، اور evaluation reports میں قارئین کو کن چیزوں پر نظر رکھنی چاہیے. ہماری نظر میں، سب سے مفید reports خود نتیجے کے علاوہ دو چیزیں واضح طور پر بیان کرتی ہیں: اول، وہ بتاتی ہیں کہ evaluation setup کس دعوے کو جانچنے کے لیے بنایا گیا تھا، اور دوم، وہ دستیاب شواہد شیئر کرتی ہیں کہ evaluation کا نتیجہ معتبر ہے.

evaluations میں آزمائے جانے والے دعوے عموماً تین زمروں میں آتے ہیں¹:

• Capability elicitation: کیا کوئی ماڈل معقول طور پر زیرِ جانچ صلاحیت پیدا کر سکتا ہے؟ 
• Safeguard performance: زیرِ جانچ رویے یا حملے کے مقابلے میں آزمودہ safeguards کتنے مضبوط ہیں؟
• Comparison: یکساں حالات میں مختلف ماڈلز کی کارکردگی کیسی ہے؟

evaluation reports کو یہ بھی بتانا چاہیے کہ evaluators نے ان اثرات کی جانچ کیسے کی جو کسی نتیجے کی درستی کو متاثر کر سکتے ہیں. ان میں شامل ہیں:

• Reward hacking: کام یا scorer میں موجود شارٹ کٹس سے فائدہ اٹھانا، تاکہ نظام اس رویے کا مظاہرہ کیے بغیر کریڈٹ لے لے جسے evaluation ناپنے کے لیے بنائی گئی ہے.
• Refusals: ایسے انکار کرنا جو زیرِ جانچ رویے کو دھندلا دیں.
• Contamination: اس لیے حد سے زیادہ بہتر کارکردگی دکھانا کہ evaluation کے کام، جوابات، یا ان کے قریبی متبادل تربیتی ڈیٹا میں موجود تھے یا evaluation کے دوران، مثلاً browsing کے ذریعے، دریافت کیے جا سکتے تھے.
• Broken problems: اس لیے کم کارکردگی دکھانا کہ کام ہی غیر معتبر ہوں. وجوہ میں غیر منصفانہ scoring شامل ہو سکتی ہے (مثلاً درست جواب کے لیے غیر مذکور implementation details درکار ہوں) اور ناقابلِ حل environments (مثلاً اہم files غائب ہوں یا tools ناقابلِ اعتماد ہوں).
• Sandbagging: جب وہ جانچ سے آگاہی دکھائیں تو جان بوجھ کر کم کارکردگی دکھانا.

ہم نے دیکھا ہے کہ harness کا کردار خاص طور پر ان نظاموں کے لیے اہم ہے جو طویل trajectories پر عمل کرتے ہیں. جب ماڈلز tools استعمال کر سکتے ہوں، state برقرار رکھ سکتے ہوں، اور کئی مراحل میں غلطیوں سے سنبھل سکتے ہوں، تو harness مشاہدہ شدہ کارکردگی کی سطح بدل سکتا ہے، بلکہ یہ بھی طے کر سکتا ہے کہ زیرِ جانچ صلاحیت evaluation میں سرے سے ظاہر ہوتی ہے یا نہیں. مثلاً، ایسا harness جو state محفوظ رکھے اور ناکام اعمال کو دوبارہ آزمائے، ماڈل کو ایسا کثیر مرحلہ کام مکمل کرنے دے سکتا ہے جسے یہی ماڈل ایک سادہ harness میں کبھی مکمل نہ کرے.

نیچے دی گئی جدول میں، ہم ان تین قسم کے دعووں کو الگ کرتے ہیں جو evaluators کرنا چاہ سکتے ہیں، اور وہ harness بھی جس کی ہر قسم کے دعوے کو، ہمارے خیال میں، ضرورت ہوتی ہے.

صلاحیت سے متعلق دعوے اتنے ہی مضبوط ہوتے ہیں جتنی ان کے پیچھے elicitation مضبوط ہو: evaluators کو ایسا harness چننا چاہیے جو کام اور اس صلاحیت دونوں سے بہترین مطابقت رکھتا ہو جسے evaluation ناپنے کی کوشش کر رہی ہے. یکساں حالات میں نظاموں کا موازنہ کرنے کے لیے standardized harness درست ہو سکتا ہے، لیکن اگر وہ مخصوص harness خصوصیات چھوڑ دے جو ماڈل کو کام انجام دینے میں مدد دیتی ہیں تو یہ صلاحیت کو کم ظاہر کر سکتا ہے. مثال کے طور پر، OpenAI کی cyber ranges پر GPT‑5.5 کی کارکردگی دکھاتی ہے کہ harness کا انتخاب ان کاموں میں ناپی گئی صلاحیت کو نمایاں طور پر بدل سکتا ہے جن میں طویل، کثیر مرحلہ tool use درکار ہو: جب harness تعامل کے طویل ہونے پر کام سے متعلق سیاق محفوظ رکھنے کے لیے compaction⁠ استعمال کرتا ہے تو ماڈل بہتر کارکردگی دکھاتا ہے. یہ ظاہر کرتا ہے کہ بعض ماڈلز کے لیے ایسا harness جو compaction کو چھوڑ دے، کارکردگی کو کم ظاہر کرے گا.

دیگر شائع شدہ evaluations² بھی دکھاتی ہیں کہ harness اور بجٹ کے انتخاب evaluation کے نتائج بدل دیتے ہیں. ٹیسٹ کے وقت compute میں اضافہ اس صلاحیت کو نمایاں طور پر بدل سکتا ہے جسے evaluation ظاہر کرتی ہے، خاص طور پر ان شعبوں میں جہاں کامیابی کی تصدیق آسان ہو، جیسے بہت سے cyber tasks. UK AISI کی cyber range evaluation⁠(نئی ونڈو میں کھلتا ہے) میں، بجٹ کو 10M سے 100M tokens تک بڑھانے سے کارکردگی میں 59% تک بہتری آئی، اور آزمودہ سب سے زیادہ بجٹ پر بھی کارکردگی بڑھ رہی تھی. اس کی تفصیل evaluation کو زیادہ قابلِ فہم بناتی ہے: یہ قارئین کو دکھاتی ہے کہ نتیجہ آزمودہ elicitation setup پر کیسے منحصر ہے. جب اضافی بجٹ کے ساتھ کارکردگی اب بھی بہتر ہو رہی ہو، تو اسکور کو اسی harness اور بجٹ کے تحت کارکردگی کے طور پر بیان کیا جانا چاہیے، نہ کہ ناپی گئی صلاحیت کی آخری حد کے طور پر. صلاحیت اکثر وسائل پر منحصر ہوتی ہے، نہ کہ ایسی مقررہ مقدار جو ایک بار میں صاف طور پر ہمیشہ کے لیے ناپی جا سکے. جہاں بار بار کوششوں میں کامیابی ناپی جا سکتی ہو، reports کو صرف مقررہ token بجٹ پر کامیابی کی شرح نہیں بلکہ ہر کامیاب حل کی متوقع لاگت پر بھی غور کرنا چاہیے. اس سے شدت کو سمجھنا آسان ہو سکتا ہے: کم کامیابی کی شرح بھی عملی طور پر اہم ہو سکتی ہے اگر بار بار کوششوں کی لاگت متعلقہ threat model کے اندر ہو. صلاحیت سے متعلق دعووں کے لیے، قابلِ اجتناب کم elicitation ایک پیمائشی ناکامی ہے: اگر harness یا بجٹ نظام کو وہ رویہ دکھانے سے روکے جو وہ ورنہ پیدا کر سکتا تھا، تو اسکور دعویٰ کردہ صلاحیت کو نہیں ناپتا. جہاں evaluators نے elicitation کو ممکن حد تک آگے بڑھایا ہو اور کارکردگی پھر بھی بہتر ہو رہی ہو، reports کو یہ بات واضح طور پر کہنی چاہیے اور یہ بھی واضح کرنا چاہیے کہ نتیجہ صرف lower-bound اندازہ ہے.

Safeguard testing اس بات کو کم ظاہر کر سکتی ہے کہ کوئی حملہ کامیاب ہو سکتا ہے یا کتنا شدید ہو سکتا ہے، اگر حملہ آوروں کو دستیاب وسائل، بشمول custom harnesses، کو مدنظر نہ رکھا جائے. UK AISI کی GPT‑5.5 cyber evaluation میں، ان کی expert red teaming نے ایک universal jailbreak دریافت کیا جس نے OpenAI کی فراہم کردہ malicious queries میں، بشمول multi-turn agentic settings، خلافِ ضابطہ cyber مواد ظاہر کروایا. انہوں نے ماڈل کی حملہ آور کارکردگی مضبوط کرنے کے لیے Codex استعمال کر کے ایک custom harness بنایا: اس نے تعامل میں safeguard-bypass کا ایک دوبارہ استعمال ہونے والا pattern شامل کیا، اس pattern کو turns اور blocks میں محفوظ رکھا، اور اسے OpenAI کی فراہم کردہ malicious cyber queries پر لاگو کیا. Safeguard testing کو adversary سے مطابقت رکھنی چاہیے. اگر دعویٰ expert misuse کے مقابلے میں مضبوطی سے متعلق ہو، تو ٹیسٹ کو متعین بجٹ کے تحت سب سے مضبوط قابلِ اعتبار end-to-end attack strategy کی جانچ کرنی چاہیے، بشمول وہ harness جو اس strategy کو محفوظ رکھنے اور دوبارہ استعمال کرنے کے لیے درکار ہو. ورنہ، نتائج miscalibration کا خطرہ رکھتے ہیں: وہ صرف سادہ prompting کے مقابلے میں مزاحمت کے ایک تنگ دعوے کی تائید کر سکتے ہیں، یہ بھی چھوٹ سکتا ہے کہ elicitation طریقہ عملی بننے کے بعد حملہ کتنا شدید اور کتنا کامیاب ہو سکتا ہے، اور اگر بہت زیادہ بجٹ دے دیا جائے تو مسئلے کے امکان یا شدت کو بڑھا چڑھا کر بھی دکھا سکتے ہیں.⁠(نئی ونڈو میں کھلتا ہے)

standardized harness comparisons کے لیے بھی وقت اور جگہ ہے، لیکن evaluators کو واضح ہونا چاہیے کہ harnesses کے یکساں مجموعے کا استعمال کیوں مناسب ہے اور یہ کس دعوے کی تائید کر سکتا ہے. METR کی time-horizon evaluation⁠(نئی ونڈو میں کھلتا ہے) ایک وسیع تر، مناسب طور پر مقرر evaluation setup کی مثال ہے: اسے ان نظاموں میں قابلِ موازنہ نتائج پیدا کرنے کے لیے ڈیزائن کیا گیا ہے جن کی یہ جانچ کرتی ہے. METR ایک مشترک outcome متعین کرتا ہے، یعنی انسانی کام کی وہ معمول کی مدت جس پر پیش گوئی کی جاتی ہے کہ ایک AI ایجنٹ دی گئی reliability سطح پر کامیاب ہوگا. یہ ایک مشترک task suite، scoring method، fitting method، اور reusable scaffolds کے ایک چھوٹے مجموعے جیسے Triframe and ReAct⁠(نئی ونڈو میں کھلتا ہے) کو ان اندازوں کے ہر batch میں لاگو کرتا ہے جو ساتھ رپورٹ کیے جاتے ہیں. جب METR نے task suite کو وسعت دی اور evaluation infrastructure کو Vivaria نامی framework سے Inspect نامی framework میں منتقل کیا، تو اس نے اس تبدیلی کی رپورٹ دی (Time Horizon 1.1 update⁠(نئی ونڈو میں کھلتا ہے)) اور نئے evaluation setup کے تحت ماڈلز کی دوبارہ جانچ کی. standardized evaluation setup، بشمول یکساں harness set، کی یہی قدر ہے: یہ قارئین کو اعتماد دے سکتا ہے کہ اسکورز میں فرق واقعی موازنہ کیے جانے والے نظاموں کے فرق کو ظاہر کرتا ہے، نہ کہ پیمائش کے setup میں تبدیلی کو.

ہم تجویز کرتے ہیں کہ تیسرے فریق کی evaluation reports یہ بتائیں کہ ان کا evaluation setup کس قسم کے دعوے کی تائید کے لیے بنایا گیا ہے؛ یہ بیان کریں کہ جو چیز آزمائی گئی وہ اس وسیع تر دعوے کی کتنی نمائندگی کرتی ہے؛ ان harness choices کو بیان کریں جنہوں نے نتیجے کو شکل دی؛ یہ تفصیل دیں کہ evaluations کے درمیان وہ choices کب بدلتی ہیں؛ اور ایسے معاون شواہد شامل کریں جو دکھائیں کہ نتیجہ کیسے پیدا ہوا اور وہ دعوے پر کتنی اچھی طرح عمومی اطلاق رکھتا ہے.

جوں جوں ماڈلز زیادہ باصلاحیت ہوتے جاتے ہیں، evaluation scores کو غلط سمجھنا آسان ہوتا جاتا ہے. حقیقی صلاحیتوں کے مقابلے میں، اگر ماڈل یہ پہچان لے کہ اس کی جانچ ہو رہی ہے اور حکمتِ عملی کے تحت کم کارکردگی دکھائے، تو evaluation scores مصنوعی طور پر کم ہو سکتے ہیں. اگر ماڈل کام، prompt، scorer، یا harness میں موجود کسی شارٹ کٹ سے فائدہ اٹھائے تو یہ بڑھ بھی سکتے ہیں. یہ contamination سے بھی بگڑ سکتے ہیں (جہاں ماڈل پہلے سے جواب جانتا ہو یا کام حل کیے بغیر اسے ڈھونڈ سکتا ہو) یا “broken” مسائل سے جو مبہم، غلط اسکور شدہ، ناقابلِ حل، یا غیر ارادی شارٹ کٹس کے لیے حساس ہوں. اس لیے evaluation reports کو سرخی والے scores کے ساتھ ان خطرات پر گفتگو بھی شامل کرنی چاہیے، تاکہ قارئین اندازہ لگا سکیں کہ آیا scores مطلوبہ رویے کی عکاسی کرتے ہیں.

Harnesses، budgets، tools، scoring rules، monitors، اور review procedures سب اس بات کو متاثر کرتے ہیں کہ آیا کوئی ایجنٹ مطلوبہ کام حل کر رہا ہے، اس سے بچ رہا ہے، اسے یاد سے دہرا رہا ہے، یا اس کے گرد کوئی راستہ نکال رہا ہے. ایک قابلِ اعتماد report ان جانچوں کو نمایاں بناتی ہے: evaluators کو ہر بار assessment چلنے پر ان رویوں کے لیے نمونوں کا جائزہ لینا چاہیے.

Reward hacking

Reward hacking کا مطلب یہ ہے کہ evaluation میں بلند scores ایسے طریقوں سے حاصل کیے جائیں جو مطلوبہ صلاحیت کی عکاسی نہ کرتے ہوں. یہاں تشویش یہ ہے کہ نظام کام، scorer، prompt، یا harness سے فائدہ اٹھا کر کریڈٹ لے لے، بجائے اس کام کے جو evaluation ناپنے کے لیے بنائی گئی تھی. GPT 5.4 کی METR evaluation⁠(نئی ونڈو میں کھلتا ہے) دکھاتی ہے کہ یہ کیوں اہم ہے: اگرچہ پہلے جائزے میں ماڈل ایسے کاموں پر اس شرح سے کامیاب ہوا جو تقریباً 13 گھنٹے کے time horizon کے طور پر درج ہوتی، انسانی جائزے نے دکھایا کہ ان میں سے کچھ کامیابیاں reward hacking سے آئی تھیں، اور صرف reward hacking سے پاک مثالوں کو شمار کرنے کے لیے نتائج میں ترمیم کرنے سے اندازہ تقریباً 6 گھنٹے رہ گیا. evaluators کو ایسی ترامیم کی ضرورت کا اندازہ لگانا چاہیے اور جب ان کی ضرورت ہو تو انہیں واضح طور پر رپورٹ کرنا چاہیے: صلاحیت کا اندازہ اس وقت کہیں زیادہ مفید ہوتا ہے جب قارئین دیکھ سکیں کہ کون سی ظاہری کامیابیاں خارج کی گئیں، کیوں خارج کی گئیں، اور نتیجہ اس فیصلے پر کتنا منحصر ہے.

Refusals

Safeguards کی وجہ سے ماڈلز capability evaluations میں کم کارکردگی بھی دکھا سکتے ہیں. کوئی ماڈل evaluation tasks مکمل کرنے کے بجائے انکار کرنے کی وجہ سے اپنی اصل صلاحیت سے کم evaluation performance دکھا سکتا ہے. اس لیے reports کو یہ بتانا چاہیے کہ آیا refusals evaluation results کا حصہ تھیں، اور اگر ہاں، تو ان کی وجہ سے کتنے samples متاثر ہوئے.

Contamination

Contamination سب سے زیادہ عوامی یا دوبارہ استعمال ہونے والے benchmarks⁠ کے لیے اہم ہے. اگر tasks، answers، یا ان کے قریبی متبادل تربیتی ڈیٹا میں موجود ہوں یا browsing والا ایجنٹ انہیں تلاش کر سکے، تو کارکردگی ماڈل کی کارکردگی کے بجائے یادداشت یا retrieval کی عکاسی کر سکتی ہے. جہاں ممکن ہو evaluators کو نجی یا نئے بنائے گئے tasks کو ترجیح دینی چاہیے اور یہ جانچنا چاہیے کہ ماڈلز حل کرنے سے پہلے task-specific details دہرا تو نہیں رہے.

Broken problems

Broken problems میں ایسی صورتیں شامل ہیں جیسے کوئی مسئلہ جو غلطی سے حل ہی نہ ہو سکے. Broken problems اتنے عام⁠(نئی ونڈو میں کھلتا ہے) ہیں کہ انہیں درستی کے ایک معیاری خطرے کے طور پر لیا جانا چاہیے. ان میں غلط ground truth، مبہم prompts، غائب files، غیر مستحکم services، غیر منصفانہ scoring معیار، اور ایسے environments شامل ہیں جو hidden answer files یا ground-truth patch پر مشتمل repository history جیسے شارٹ کٹس ظاہر کرتے ہیں.

Sandbagging

کسی ماڈل یا نظام کی طرف سے Sandbagging کا مطلب ہے حکمتِ عملی کے تحت کم کارکردگی دکھانا جب مضبوط کارکردگی کسی مقصد سے ٹکراتی ہو. Apollo کی GPT‑5.5 evaluation⁠(نئی ونڈو میں کھلتا ہے) نے اس کی جانچ ایک ایسا سیاق بنا کر کی جس میں ماڈل سمجھتا تھا کہ بلند evaluation scores unlearning کو متحرک کر سکتی ہیں یا deployment روک سکتی ہیں. GPT‑5.5 نے پھر بھی درست جواب دیا، جس سے حکمتِ عملی کے تحت کم کارکردگی کے رویے کے کم شواہد ملے³. لیکن reasoning traces کے ان کے جائزے نے اہم سیاق شامل کیا: Apollo نے sandbagging-condition samples کے 52% میں alignment-evaluation awareness کی درمیانی یا اس سے زیادہ علامات پائیں، جبکہ counterfactuals میں یہ 0% تھیں. یہ شواہد نتیجے کی تشریح کو پیچیدہ بناتے ہیں، لیکن آخرکار قارئین کو زیادہ اشارہ دیتے ہیں: قارئین تسلی بخش رویہ جاتی نتیجہ بھی دیکھ سکتے ہیں اور اسے حد سے زیادہ معنی دینے میں احتیاط کی وجہ بھی.

مضبوط دعووں کے لیے درست harness بھی درکار ہے تاکہ رویہ ظاہر ہو، اور validity checks بھی تاکہ دکھایا جا سکے کہ نتیجہ درست ہے. یہ ہمارا مؤقف کہ harnesses اور validity checks evaluation result کا حصہ ہیں، اس بات کو شکل دیتا ہے کہ ہم عملی طور پر تیسرے فریق کی evaluations کی حمایت کیسے کرتے ہیں: 

• ہم evaluators کے ساتھ مخصوص maximum-elicitation رہنمائی شیئر کر رہے ہیں.
• ہم capability evaluators سے کہہ رہے ہیں کہ OpenAI ماڈلز کے لیے Codex کو ایک مشترک کم از کم معیار کے طور پر استعمال کریں: tests کو کم از کم اسی agentic interface کے ذریعے ایک baseline چلانا چاہیے جس پر صارفین کے انحصار کا امکان ہے، نہ کہ صرف ایک محدود ماڈل interface کے ذریعے.
• ہم reasoning traces اور دیگر درمیانی artifacts بھی وہاں دستیاب کر رہے ہیں جہاں deception، sandbagging، یا evaluation awareness کا اندازہ لگانے کے لیے ان کی ضرورت ہو. METR اور Apollo نے GPT‑5 کے بعد سے OpenAI evaluations میں اس رسائی کا استعمال کیا ہے. 
• آخر میں، ہم اس تحقیق کو ترجیح دے رہے ہیں کہ زیادہ گہرائی سے سمجھا جا سکے کہ harness choices کب اور کیسے نتائج کو نمایاں طور پر بدلتی ہیں، سیاق کے انتظام اور tool access سے لے کر retry behavior، scoring، اور resource budgets تک.

ان سفارشات کا مقصد صرف انفرادی evaluation reports کو بہتر بنانا نہیں، بلکہ فرنٹیئر AI evaluation اور reporting کے لیے ابھرتے ہوئے قومی ⁠(نئی ونڈو میں کھلتا ہے)اور بین الاقوامی ⁠(نئی ونڈو میں کھلتا ہے)معیارات کو بھی معلومات فراہم کرنا ہے. آگے چل کر، تیسرے فریق کے evaluation standards کو اتنی تفصیل درکار ہونی چاہیے کہ فیصلہ ساز سمجھ سکیں کہ مخصوص evaluations کن دعووں کی تائید کرتی ہیں، کون سا نظام آزمایا گیا، نتیجہ کیسے ظاہر کروایا گیا، اور evaluators نے اس کی درستی کیسے جانچی. ایسے فرنٹیئر نظاموں کے لیے جنہیں ان کاموں پر آزمایا جا رہا ہو جہاں agentic صلاحیتیں اہم ہوں، تفصیلات میں یہ شامل ہونا چاہیے (کسی بھی سکیورٹی یا رازداری کے خدشات کے تابع):

• دعویٰ: آیا evaluation نظاموں کا موازنہ کرتی ہے، صلاحیت کی بالائی حد کا اندازہ لگاتی ہے، یا safeguards کی جانچ کرتی ہے.
• Evaluation content: کاموں یا task distribution کے بارے میں اتنی تفصیل کہ قارئین سمجھ سکیں evaluation دراصل کن مہارتوں، رویوں، یا failure modes کی جانچ کر رہی ہے.
• آزمودہ نظام: ماڈل، reasoning setting، tool access، harness، اور safeguards.
• بجٹ: turns، tokens، attempts/retries، wall-clock time، inference cost، اور جہاں لاگو ہو ہر کامیاب حل کی متوقع لاگت.
• Elicitation methods: نتیجہ ظاہر کروانے کے لیے استعمال ہونے والے harness choices، اور یہ کہ جو چیز آزمائی گئی وہ کیے جانے والے وسیع تر دعوے کی کتنی نمائندگی کرتی ہے.
• Validity checks: assessors نے reward hacking، evaluation awareness، contamination، refusals، sandbagging اور دیگر ایسے رویوں کو کیسے تلاش کیا جو نتیجے کو کمزور کر سکتے تھے، بشمول یہ کہ تصدیق شدہ مثالوں نے scoring یا تشریح کو کیسے متاثر کیا.

وہ standards جو harness choices یا validity checks کو چھوڑ دیتے ہیں، کسی نظام کی صلاحیت کو کم ظاہر کر سکتے ہیں یا کسی حفاظتی دعوے پر اعتماد کو بڑھا چڑھا کر پیش کر سکتے ہیں. مضبوط harnesses اور elicitation methods بنانا اب بھی تحقیق کا ایک کھلا میدان ہے اور مزید تحقیق اور سرمایہ کاری کا مرکز ہونا چاہیے.