CodeVetter کا v1 بینچ مارک 27 مصنوعی کیسز (synthetic cases) کو ایک AI سے چلنے والے کوڈ ریویو پائپ لائن کے ذریعے گزارتا ہے اور یہ ریکارڈ کرتا ہے کہ آیا ٹول نے پہلے سے موجود بگ (bugs) کو پہچانا یا نہیں۔ پھر یہ ہر کیس کے لیے پاس یا فیل کا حساب لگاتا ہے۔
یہ بینچ مارک کیوں اہم ہے
یہ ٹیسٹ ایک محدود سوال پوچھتا ہے: کیا کوئی دیا گیا ریویوور ان مخصوص نقائص کو پہچان سکتا ہے جو بینچ مارک ڈیزائنرز نے کوڈ کے ان مخصوص ٹکڑوں (snippets) میں شامل کیے ہیں؟ ڈویلپرز اس نتیجے کو ایشو کوریج (issue coverage) کے فوری معائنے کے طور پر استعمال کر سکتے ہیں۔ چونکہ ریپوزٹری میں ٹاسک پیکیجز اور اسکورنگ اسکرپٹ شامل ہیں، اس لیے کوئی بھی اس ٹیسٹ کو دوبارہ چلا کر وہی اعداد و شمار حاصل کر سکتا ہے۔
یہ بینچ مارک کیا ثابت نہیں کرتا
27 کیسز کا مصنوعی مجموعہ ان ہزاروں پل ریکویسٹس (pull requests) کا متبادل نہیں ہے جنہیں ایک ٹیم روزانہ ہینڈل کرتی ہے۔ یہ بینچ مارک ان چیزوں کے بارے میں کچھ نہیں بتاتا:
- حقیقی دنیا کا تنوع (Real-world diversity) – یہ صرف چند زبانوں اور بگ کی محدود اقسام کا احاطہ کرتا ہے۔
- کارکردگی (Performance) – یہ وقت یا کمپیوٹیشن لاگت (compute-cost) کی پیمائش فراہم نہیں کرتا۔
- مختلف کوڈ بیسز پر بھروسہ مندی (Reliability across code bases) – لائیو ریپوزٹری ٹیسٹنگ کے بغیر ہم یہ نہیں جان سکتے کہ آیا ٹول پروڈکشن میں باریک نقائص کو نظر انداز کر دے گا یا غلط مثبت (false positives) نتائج دے گا۔
شائع شدہ نتائج کو انفراسٹرکچر فائلوں اور مستقبل کے "وسیع اور حقیقت پسندانہ ڈیٹا" کے وعدوں کے ساتھ ملانے سے ایک ایسا مارکیٹنگ بیانیہ تخلیق ہوتا ہے جس سے یہ تاثر ملتا ہے کہ یہ واحد اسکور پروڈکشن کے لیے تیار صلاحیت کی نمائندگی کرتا ہے، جبکہ ڈیٹا اس کی حمایت نہیں کرتا۔
یہ بینچ مارک وسیع تر ٹیسٹنگ ایکو سسٹم میں کیسے فٹ بیٹھتا ہے
پہچان کے انداز کے بینچ مارکس، جیسے کہ CodeVetter کے، اس سطح کا تعین کرتے ہیں جسے ایک ٹول ہینڈل کر سکتا ہے۔ یہ SWE-bench جیسے فنکشنل بینچ مارکس کے ساتھ مل کر کام کرتے ہیں، جو یہ چیک کرتے ہیں کہ آیا AI کے ذریعے تیار کردہ پیچ (patch) واقعی موجودہ کوڈ بیس میں کسی حقیقی مسئلے کو حل کرتا ہے۔ یہ مل کر ایک مکمل تصویر پیش کرتے ہیں: کوریج بمقابلہ تاثیر (effectiveness)۔
ایک اچھے ایجنٹ بینچ مارک کو مکمل اسٹیک (full stack) کو ظاہر کرنا چاہیے:
- ڈیٹاسٹ (The dataset) – خام ان پٹس اور متوقع آؤٹ پٹس۔
- فی کیس دستاویزات (Per-case documentation) – ہر ٹیسٹ کے لیے ایک صفحہ جو بگ، درست اصلاح (fix)، اور ٹول کے جواب کو ظاہر کرے۔
- ریویوور کے آؤٹ پٹس (Reviewer outputs) – وہ درست تبصرے یا تجاویز جو AI نے فراہم کیں۔
- اسکورنگ طریقہ کار (Scoring methodology) – میچز کا فیصلہ کیسے کیا جاتا ہے، بشمول جزوی کریڈٹ (partial credit) کی گنجائش۔
- دوبارہ پیدا کرنے کی ہدایات (Reproducibility instructions) – ورژن پن، ہارڈ ویئر کی تفصیلات، اور ٹیسٹ کو دوبارہ چلانے کے اسکرپٹس۔
جب یہ تمام حصے شفاف ہوں گے، تب ہی ہم کسی ایک مجموعی اسکور پر بھروسہ کر سکتے ہیں۔
وہ حدود جو بینچ مارک خود فہرست میں دیتا ہے
- مصنوعی کیسز، جو لائیو ریپوزٹریز سے نہیں لیے گئے۔
- زبانوں اور بگ کی اقسام کا محدود انتخاب۔
- وقت یا لاگت کا ڈیٹا موجود نہیں، اس لیے کارکردگی (efficiency) کا علم نہیں۔
- درستگی (precision) کی ایسی حدود جو ممکنہ طور پر بارڈر لائن ناکامیوں کو چھپا سکتی ہیں۔
آگے کیا دیکھنا ہے
CodeVetter کے لیے—اور AI ریویوورز استعمال کرنے والے کسی بھی شخص کے لیے—اگلا قدم بڑے اور زیادہ متنوع ڈیٹا سیٹس (corpora) پر بار بار ثبوت فراہم کرنا ہے۔ اس کا مطلب ہے کہ حقیقی پل ریکویسٹ اسٹریمز پر نتائج شائع کرنا، لیٹنسی (latency) اور کمپیوٹ کے استعمال کی رپورٹنگ کرنا، اور ناکامی کے طریقوں کو کیٹیگری کے لحاظ سے تقسیم کرنا۔ جب تک ایسا ڈیٹا سامنے نہیں آتا، 27 کیسز کے اسکور کو محض ایک ابتدائی اشارے کے طور پر لیں، نہ کہ تیاری کی ضمانت کے طور پر۔
حاصلِ کلام (Takeaway): ایک ایسا بینچ مارک جو آپ کو صرف یہ بتاتا ہے کہ آیا کوئی ٹول پہلے سے لکھے گئے چند بگ کو پہچان سکتا ہے، وہ بنیادی جانچ (sanity-checking) کے لیے تو مفید ہے، لیکن یہ اس بات کی تصدیق نہیں کرتا کہ ٹول پروڈکشن کوڈ ریویو کی پیچیدہ اور لاگت کے حساس حقیقت میں کامیاب رہے گا۔