CodeVetter-ன் v1 benchmark, 27 செயற்கையான (synthetic) நிகழ்வுகளை ஒரு AI-ஆல் இயக்கப்படும் code-review pipeline மூலம் இயக்கி, அதில் திட்டமிட்டு வைக்கப்பட்ட பிழைகளை (planted bugs) கருவி கண்டறிகிறதா என்பதைப் பதிவு செய்கிறது. பின்னர் ஒவ்வொரு நிகழ்விற்கும் வெற்றி அல்லது தோல்வியைக் கணக்கிடுகிறது.

இந்த benchmark ஏன் முக்கியமானது

இந்தச் சோதனை ஒரு குறுகிய கேள்வியைக் கேட்கிறது: benchmark வடிவமைப்பாளர்கள் இந்த குறிப்பிட்ட தொகுப்பில் (snippets) மறைத்து வைத்திருக்கும் துல்லியமான குறைபாடுகளை ஒரு குறிப்பிட்ட reviewer அடையாளம் காண முடியுமா? டெவலப்பர்கள் இந்த முடிவை issue coverage-ஐ விரைவாகச் சரிபார்க்கப் பயன்படுத்தலாம். இந்த repository-யில் task packages மற்றும் scoring script ஆகியவை இருப்பதால், எவரும் இந்தச் சோதனையை மீண்டும் இயக்கி அதே முடிவுகளைப் பெற முடியும்.

இந்த benchmark எதை நிரூபிப்பதில்லை

27 நிகழ்வுகளைக் கொண்ட ஒரு செயற்கையான தொகுப்பு (synthetic suite), ஒரு குழு தினமும் கையாளும் ஆயிரக்கணக்கான pull requests-களுக்கு மாற்றாகாது. இந்த benchmark பின்வருவனவற்றைப் பற்றி எதுவும் கூறவில்லை:

  • நிஜ உலகப் பன்முகத்தன்மை (Real-world diversity) – இது சில மொழிகளையும், வரையறுக்கப்பட்ட பிழை வகைகளையும் மட்டுமே உள்ளடக்கியது.
  • செயல்திறன் (Performance) – இது நேர அளவு (timing) அல்லது கணினிச் செலவு (compute-cost) அளவீடுகளை வழங்கவில்லை.
  • Code bases முழுவதிலும் உள்ள நம்பகத்தன்மை (Reliability across code bases) – நேரடித் களச் சோதனை (live-repo testing) இல்லாமல், இந்த கருவி நுணுக்கமான குறைபாடுகளைத் தவறவிடுமா அல்லது production சூழலில் தவறான முடிவுகளை (false positives) வழங்குமா என்பதை நாம் அறிய முடியாது.

வெளியிடப்பட்ட முடிவுகளை, infrastructure கோப்புகளுடனும், எதிர்கால “விரிவான, யதார்த்தமான தரவு” (broad, realistic data) குறித்த வாக்குறுதிகளுடனும் இணைப்பது, அந்த ஒற்றை மதிப்பெண் மட்டுமே production-ready திறனைக் குறிக்கிறது என்ற ஒரு சந்தைப்படுத்தல் கதையை (marketing narrative) உருவாக்குகிறது; ஆனால் தரவுகள் அதை ஆதரிக்கவில்லை.

இந்த benchmark பரந்த சோதனைச் சூழலில் (testing ecosystem) எவ்வாறு பொருந்துகிறது

CodeVetter-ஐப் போன்ற அடையாளம் காணும் பாணி (Recognition-style) benchmarks, ஒரு கருவி கையாளக்கூடிய பரப்பளவைக் காட்டுகின்றன. இவை SWE-bench போன்ற functional benchmarks-களுக்குத் துணையாக அமைகின்றன; SWE-bench என்பது ஒரு AI-ஆல் உருவாக்கப்பட்ட patch, ஏற்கனவே உள்ள code base-இல் உள்ள ஒரு உண்மையான சிக்கலைத் தீர்க்கிறதா என்பதைச் சரிபார்க்கிறது. இவை இரண்டும் இணைந்து ஒரு முழுமையான சித்திரத்தைத் தருகின்றன: coverage மற்றும் effectiveness ஆகியவற்றிற்கு இடையிலான ஒப்பீடு.

ஒரு சிறந்த agent benchmark முழுமையான கட்டமைப்பையும் (full stack) வெளிப்படுத்த வேண்டும்:

  1. The dataset – மூல உள்ளீடுகள் (raw inputs) மற்றும் எதிர்பார்க்கப்படும் வெளியீடுகள் (expected outputs).
  2. Per-case documentation – ஒவ்வொரு சோதனைக்கும் பிழை, சரியான தீர்வு மற்றும் கருவியின் பதில் ஆகியவற்றைத் காட்டும் ஒரு பக்கம்.
  3. Reviewer outputs – AI உருவாக்கிய துல்லியமான கருத்துக்கள் அல்லது பரிந்துரைகள்.
  4. Scoring methodology – பொருத்தங்கள் எவ்வாறு தீர்மானிக்கப்படுகின்றன, இதில் பகுதி மதிப்பெண்களுக்கான (partial credit) சகிப்புத்தன்மையும் அடங்கும்.
  5. Reproducibility instructions – பதிப்பு விவரங்கள் (version pins), வன்பொருள் விவரங்கள் மற்றும் சோதனையை மீண்டும் இயக்கத் தேவையான ஸ்கிரிப்ட்கள்.

இந்த அனைத்து அம்சங்களும் வெளிப்படையாக இருக்கும்போது மட்டுமே, ஒரு ஒட்டுமொத்த மதிப்பெண்ணை (aggregate score) நாம் நம்ப முடியும்.

benchmark பட்டியலிடும் வரம்புகள்

  • நேரடித் களச் சேமிப்பகங்களிலிருந்து (live repositories) எடுக்கப்படாத செயற்கையான நிகழ்வுகள்.
  • குறுகிய மொழி மற்றும் பிழை வகைத் தெரிவு.
  • நேர அல்லது செலவுத் தரவுகள் இல்லை, எனவே செயல்திறன் (efficiency) அறியப்படவில்லை.
  • எல்லைக் கோட்டுப் பிழைகளை (borderline failures) மறைக்கக்கூடிய துல்லியக் கட்டுப்பாடுகள் (precision constraints).

அடுத்து கவனிக்க வேண்டியவை

CodeVetter-க்கும், AI reviewers-களைப் பயன்படுத்துபவர்களுக்கும் அடுத்த கட்டம், பெரிய மற்றும் மாறுபட்ட தரவுத் தொகுப்புகளில் (corpora) மீண்டும் மீண்டும் நிரூபிக்கப்படுவதாகும். அதாவது, உண்மையான pull-request ஓட்டைகளில் முடிவுகளை வெளியிடுவது, latency மற்றும் கணினிப் பயன்பாட்டைக் (compute consumption) குறிப்பிடுவது மற்றும் தோல்வி முறைகளை (failure modes) வகை வாரியாகப் பிரித்துக் காட்டுவது ஆகியவற்றைக் குறிக்கிறது. இத்தகைய தரவுகள் கிடைக்கும் வரை, இந்த 27 நிகழ்வுகளின் மதிப்பெண்ணை ஒரு ஆரம்பக் குறிகாட்டியாகவே (early indicator) கருதுங்கள், அது தயார்நிலையின் உத்தரவாதம் அல்ல.

சுருக்கம் (Takeaway): ஒரு கருவி சில முன் எழுதப்பட்ட பிழைகளைக் கண்டறிய முடியுமா என்பதை மட்டுமே சொல்லும் ஒரு benchmark, அடிப்படைச் சரிபார்ப்பிற்கு (sanity-checking) பயனுள்ளதாக இருக்கும், ஆனால் அது production code review-இன் சிக்கலான மற்றும் செலவு சார்ந்த யதார்த்தத்தைச் சமாளிக்கும் என்று சான்றளிக்காது.