CodeVetter चा v1 बेंचमार्क २७ कृत्रिम (synthetic) केसेस एका AI-चालित कोड-रिव्ह्यू पाइपलाइनमधून चालवतो आणि टूलने पेरलेले बग्स (bugs) शोधले की नाही याची नोंद करतो. त्यानंतर तो प्रत्येक केससाठी पास किंवा फेलची गणना करतो.
हा बेंचमार्क का महत्त्वाचा आहे
ही चाचणी एक मर्यादित प्रश्न विचारते: एखादा रिव्ह्यूअर, बेंचमार्क डिझाइनर्सनी कोड स्निपेट्सच्या या निश्चित संचामध्ये जे नेमके दोष (defects) समाविष्ट केले आहेत, ते ओळखू शकतो का? डेव्हलपर्स या निकालाचा वापर इश्यू कव्हरेजच्या (issue coverage) जलद तपासणीसाठी करू शकतात. रिपॉझिटरीमध्ये टास्क पॅकेजेस आणि स्कोअरिंग स्क्रिप्ट उपलब्ध असल्याने, कोणीही ही चाचणी पुन्हा चालवून तेच आकडे मिळवू शकतो.
हा बेंचमार्क काय सिद्ध करत नाही
२७ केसेसचा कृत्रिम संच (synthetic suite) हा एखादी टीम दररोज हाताळत असलेल्या हजारो 'पुल रिक्वेस्ट'चा (pull requests) पर्याय असू शकत नाही. हा बेंचमार्क खालील गोष्टींबद्दल काहीही सांगत नाही:
- वास्तविक जगातील विविधता (Real-world diversity) – यामध्ये केवळ काही भाषा आणि मर्यादित बग श्रेणींचा समावेश आहे.
- कार्यक्षमता (Performance) – यामध्ये वेळेचे किंवा संगणकीय खर्चाचे (compute-cost) मोजमाप दिले जात नाही.
- कोड बेसमधील विश्वासार्हता (Reliability across code bases) – लाईव्ह-रिपो (live-repo) टेस्टिंगशिवाय, टूल सूक्ष्म दोष चुकवेल की प्रोडक्शनमध्ये 'फॉल्स पॉझिटिव्ह' (false positives) निर्माण करेल, हे आपल्याला कळू शकत नाही.
प्रकाशित निकाल, इन्फ्रास्ट्रक्चर फाइल्स आणि भविष्यातील "व्यापक, वास्तववादी डेटा" देण्याचे आश्वासन यांचा एकत्रित वापर केल्यामुळे असा मार्केटिंगचा दावा तयार होतो की, हा एकच स्कोअर प्रोडक्शन-रेडी क्षमतेचे प्रतिनिधित्व करतो, परंतु डेटा याला पाठिंबा देत नाही.
हा बेंचमार्क व्यापक टेस्टिंग इकोसिस्टममध्ये कसा बसतो
CodeVetter सारखे 'रेकग्निशन-स्टाईल' (recognition-style) बेंचमार्क, टूल किती क्षेत्रावर काम करू शकते याचे मोजमाप करतात. ते SWE-bench सारख्या 'फंक्शनल' बेंचमार्कना पूरक ठरतात, जे AI-निर्मित पॅच (patch) अस्तित्वात असलेल्या कोड बेसमधील वास्तविक समस्या खरोखर सोडवतो की नाही हे तपासतात. एकत्रितपणे ते एक पूर्ण चित्र देतात: कव्हरेज विरुद्ध परिणामकारकता (coverage versus effectiveness).
एका चांगल्या एजंट बेंचमार्कमध्ये संपूर्ण स्टॅक (full stack) स्पष्ट असणे आवश्यक आहे:
- डेटासेट (The dataset) – रॉ इनपुट्स आणि अपेक्षित आउटपुट्स.
- प्रत्येक केससाठी दस्तऐवजीकरण (Per-case documentation) – प्रत्येक चाचणीसाठी एक स्वतंत्र पान, ज्यामध्ये बग, योग्य फिक्स आणि टूलचा प्रतिसाद दर्शवलेला असेल.
- रिव्ह्यूअर आउटपुट्स (Reviewer outputs) – AI ने दिलेले नेमके कमेंट्स किंवा सूचना.
- स्कोअरिंग पद्धत (Scoring methodology) – मॅचेसचे मूल्यमापन कसे केले जाते, ज्यामध्ये अंशतः क्रेडिटसाठी (partial credit) दिलेल्या सवलतीचाही समावेश आहे.
- पुनरुत्पादनासाठी सूचना (Reproducibility instructions) – व्हर्जन पिन्स, हार्डवेअर तपशील आणि चाचणी पुन्हा चालवण्यासाठी आवश्यक स्क्रिप्ट्स.
जेव्हा हे सर्व घटक पारदर्शक असतील, तेव्हाच आपण एका एकत्रित स्कोअरवर विश्वास ठेवू शकतो.
बेंचमार्कने स्वतः नमूद केलेली मर्यादा
- लाईव्ह रिपॉझिटरीजमधून न घेतलेले कृत्रिम (synthetic) केसेस.
- मर्यादित भाषा आणि बग-प्रकार निवड.
- वेळेचा किंवा खर्चाचा डेटा नाही, त्यामुळे कार्यक्षमता अज्ञात आहे.
- अचूकतेचे (precision) निर्बंध जे सीमावर्ती अपयश (borderline failures) लपवू शकतात.
पुढे काय पाहावे
CodeVetter साठी—आणि AI रिव्ह्यूअर्स वापरणाऱ्या कोणासाठीही—पुढील पाऊल म्हणजे मोठ्या आणि अधिक वैविध्यपूर्ण कॉर्पोरा (corpora) वर वारंवार पुरावे सादर करणे. याचा अर्थ वास्तविक 'पुल-रिक्वेस्ट' स्ट्रीमवर निकाल प्रकाशित करणे, लॅटन्सी (latency) आणि संगणकीय वापर (compute consumption) रिपोर्ट करणे आणि अपयशाचे प्रकार श्रेणीनुसार विभागणे असा आहे. जोपर्यंत असा डेटा समोर येत नाही, तोपर्यंत २७ केसेसच्या स्कोअरकडे केवळ एक सुरुवातीचा निर्देशक म्हणून पहा, तो तयारतेची (readiness) खात्री नाही.
थोडक्यात सांगायचे तर (Takeaway): असा बेंचमार्क जो केवळ टूल काही मोजके आधीच लिहिलेले बग्स शोधू शकते की नाही हे सांगतो, तो 'सॅनिटी-चेकिंग'साठी (sanity-checking) उपयुक्त आहे, परंतु टूल प्रोडक्शन कोड रिव्ह्यूच्या अधिक गुंतागुंतीच्या आणि खर्च-संवेदनशील वास्तवात टिकून राहील याचे ते प्रमाणपत्र देत नाही.