CodeVetter-ന്റെ v1 ബെഞ്ച്മാർക്ക് 27 സിന്തറ്റിക് കേസുകളെ (synthetic cases) ഒരു AI അധിഷ്ഠിത കോഡ്-റിവ്യൂ പൈപ്പ്ലൈനിലൂടെ കടത്തിവിട്ട്, ടൂൾ ആസൂത്രിതമായി ഉൾപ്പെടുത്തിയ ബഗുകൾ (bugs) കണ്ടെത്തുന്നുണ്ടോ എന്ന് രേഖപ്പെടുത്തുന്നു. തുടർന്ന് ഓരോ കേസിലും വിജയിച്ചോ (pass) പരാജയപ്പെട്ടോ (fail) എന്ന് കണക്കാക്കുന്നു.
ഈ ബെഞ്ച്മാർക്ക് പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്
ഈ പരിശോധന ഒരു പരിമിതമായ ചോദ്യമാണ് ചോദിക്കുന്നത്: ബെഞ്ച്മാർക്ക് ഡിസൈനർമാർ ഈ നിശ്ചിത സ്നിപ്പറ്റുകളിൽ (snippets) ഉൾപ്പെടുത്തിയ കൃത്യമായ പിഴവുകൾ ഒരു റിവ്യൂവർക്ക് തിരിച്ചറിയാൻ കഴിയുമോ? ഡെവലപ്പർമാർക്ക് ഇഷ്യൂ കവറേജ് (issue coverage) വേഗത്തിൽ പരിശോധിക്കാൻ ഈ ഫലം ഉപയോഗിക്കാം. ടാസ്ക് പാക്കേജുകളും സ്കോറിംഗ് സ്ക്രിപ്റ്റും റെപ്പോസിറ്ററിയിൽ ലഭ്യമായതിനാൽ, ആർക്കും ഈ ടെസ്റ്റ് വീണ്ടും നടത്തി ഒരേ ഫലങ്ങൾ തന്നെ ലഭിക്കും.
ഈ ബെഞ്ച്മാർക്ക് എന്തിനെയല്ല തെളിയിക്കുന്നത്
ഒരു ടീം ദിവസേന കൈകാര്യം ചെയ്യുന്ന ആയിരക്കണക്കിന് പുൾ റിക്വസ്റ്റുകൾക്ക് (pull requests) പകരമാവില്ല ഈ 27 കേസുകളുള്ള സിന്തറ്റിക് സ്യൂട്ട്. ഈ ബെഞ്ച്മാർക്ക് താഴെ പറയുന്ന കാര്യങ്ങളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല:
- യഥാർത്ഥ ലോകത്തിലെ വൈവിധ്യം (Real-world diversity) – ഇത് ഏതാനും ഭാഷകളെയും പരിമിതമായ ബഗ് വിഭാഗങ്ങളെയും മാത്രമേ ഉൾക്കൊള്ളുന്നുള്ളൂ.
- പ്രകടനം (Performance) – ഇത് സമയമോ കമ്പ്യൂട്ട് ചിലവോ (compute-cost) അളക്കുന്നതിനുള്ള വിവരങ്ങൾ നൽകുന്നില്ല.
- കോഡ് ബേസുകളിലെ വിശ്വാസ്യത (Reliability across code bases) – ലൈവ്-റെപ്പോ ടെസ്റ്റിംഗ് ഇല്ലാതെ, പ്രൊഡക്ഷനിൽ ടൂൾ സൂക്ഷ്മമായ പിഴവുകൾ കാണാതെ പോകുമോ അതോ തെറ്റായ പോസിറ്റീവുകൾ (false positives) നൽകുമോ എന്ന് നമുക്ക് അറിയാൻ കഴിയില്ല.
പ്രസിദ്ധീകരിച്ച ഫലങ്ങളെ ഇൻഫ്രാസ്ട്രക്ചർ ഫയലുകളുമായും ഭാവിയിലെ "വിപുലവും യാഥാർത്ഥ്യബോധമുള്ളതുമായ ഡാറ്റ" എന്ന വാഗ്ദാനങ്ങളുമായും കൂട്ടിച്ചേർക്കുന്നത്, ഈ ഒറ്റ സ്കോർ പ്രൊഡക്ഷൻ റെഡി കപ്പാബിലിറ്റിയെ (production-ready capability) പ്രതിനിധീകരിക്കുന്നു എന്നൊരു മാർക്കറ്റിംഗ് കഥ സൃഷ്ടിക്കുന്നു; എന്നാൽ ഡാറ്റ അത് പിന്തുണയ്ക്കുന്നില്ല.
വിശാലമായ ടെസ്റ്റിംഗ് ഇക്കോസിസ്റ്റത്തിൽ ഈ ബെഞ്ച്മാർക്ക് എങ്ങനെ ഉൾപ്പെടുന്നു
CodeVetter-ന്റേത് പോലുള്ള റെക്കഗ്നിഷൻ സ്റ്റൈൽ (Recognition-style) ബെഞ്ച്മാർക്കുകൾ ഒരു ടൂളിന് കൈകാര്യം ചെയ്യാൻ കഴിയുന്ന പരിധി നിശ്ചയിക്കുന്നു. നിലവിലുള്ള ഒരു കോഡ് ബേസിലെ യഥാർത്ഥ പ്രശ്നം ഒരു AI നിർമ്മിച്ച പാച്ച് (patch) പരിഹരിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്ന SWE-bench പോലുള്ള ഫങ്ഷണൽ ബെഞ്ച്മാർക്കുകളെ ഇവ പൂരകമായി സഹായിക്കുന്നു. ഇവ രണ്ടും ചേരുമ്പോൾ കവറേജ് വേഴ്സസ് ഇഫക്റ്റീവ്നെസ് (coverage versus effectiveness) എന്ന കാര്യത്തിൽ കൂടുതൽ വ്യക്തമായ ചിത്രം നൽകുന്നു.
ഒരു നല്ല ഏജന്റ് ബെഞ്ച്മാർക്ക് അതിന്റെ മുഴുവൻ ഘടനയും (full stack) വെളിപ്പെടുത്തണം:
- ഡാറ്റാസെറ്റ് (The dataset) – റോ ഇൻപുട്ടുകളും (raw inputs) പ്രതീക്ഷിക്കുന്ന ഔട്ട്പുട്ടുകളും.
- ഓരോ കേസിലേക്കുമുള്ള ഡോക്യുമെന്റേഷൻ (Per-case documentation) – ഓരോ ടെസ്റ്റിലും ബഗ്, ശരിയായ പരിഹാരം, ടൂളിന്റെ പ്രതികരണം എന്നിവ കാണിക്കുന്ന ഒരു പേജ്.
- റിവ്യൂവർ ഔട്ട്പുട്ടുകൾ (Reviewer outputs) – AI നൽകിയ കൃത്യമായ കമന്റുകളോ നിർദ്ദേശങ്ങളോ.
- സ്കോറിംഗ് രീതി (Scoring methodology) – ഭാഗികമായ ക്രെഡിറ്റിനുള്ള ഇളവുകൾ ഉൾപ്പെടെ, ഫലങ്ങൾ എങ്ങനെ വിലയിരുത്തുന്നു എന്നത്.
- റീപ്രൊഡ്യൂസിബിലിറ്റി നിർദ്ദേശങ്ങൾ (Reproducibility instructions) – വേർഷൻ പിൻ (version pins), ഹാർഡ്വെയർ വിവരങ്ങൾ, ടെസ്റ്റ് വീണ്ടും നടത്തുന്നതിനുള്ള സ്ക്രിപ്റ്റുകൾ എന്നിവ.
ഈ ഘടകങ്ങളെല്ലാം സുതാര്യമാകുമ്പോൾ മാത്രമേ നമുക്ക് ഒരു അഗ്രഗേറ്റ് സ്കോറിനെ (aggregate score) വിശ്വസിക്കാൻ കഴിയൂ.
ബെഞ്ച്മാർക്ക് തന്നെ സൂചിപ്പിക്കുന്ന പരിമിതികൾ
- ലൈവ് റെപ്പോസിറ്ററികളിൽ നിന്ന് എടുക്കാത്ത സിന്തറ്റിക് കേസുകൾ.
- പരിമിതമായ ഭാഷാ തിരഞ്ഞെടുപ്പും ബഗ് തരങ്ങളും.
- സമയമോ ചിലവോ സംബന്ധിച്ച വിവരങ്ങളില്ലാത്തതിനാൽ കാര്യക്ഷമത അറിയാൻ കഴിയില്ല.
- അതിർവരമ്പുകളിലുള്ള പരാജയങ്ങളെ മറച്ചുവെച്ചേക്കാവുന്ന പ്രിസിഷൻ നിയന്ത്രണങ്ങൾ (precision constraints).
ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
CodeVetter-നും AI റിവ്യൂവർ ഉപയോഗിക്കുന്ന മറ്റെല്ലാവർക്കും അടുത്ത ഘട്ടം, കൂടുതൽ വലുതും വൈവിധ്യമാർന്നതുമായ കോർപ്പസുകളിൽ (corpora) നിന്നുള്ള ആവർത്തിച്ചുള്ള തെളിവുകൾ നൽകുക എന്നതാണ്. അതായത്, യഥാർത്ഥ പുൾ റിക്വസ്റ്റ് സ്ട്രീമുകളിൽ ഫലങ്ങൾ പ്രസിദ്ധീകരിക്കുക, ലേറ്റൻസിയും (latency) കമ്പ്യൂട്ട് ഉപയോഗവും റിപ്പോർട്ട് ചെയ്യുക, പരാജയങ്ങൾ ഓരോ വിഭാഗമായി തിരിച്ച് വിശകലനം ചെയ്യുക എന്നിവയാണത്. അത്തരം വിവരങ്ങൾ ലഭ്യമാകുന്നതുവരെ, ഈ 27 കേസുകളിലെ സ്കോറിനെ ഒരു പ്രാഥമിക സൂചകമായി മാത്രം കാണുക, പ്രൊഡക്ഷന് തയ്യാറാണെന്ന ഉറപ്പായി കരുതരുത്.
ചുരുക്കത്തിൽ (Takeaway): കുറച്ച് മുൻകൂട്ടി എഴുതിയ ബഗുകൾ കണ്ടെത്താൻ ഒരു ടൂളിന് കഴിയുമോ എന്ന് മാത്രം പറയുന്ന ഒരു ബെഞ്ച്മാർക്ക്, അടിസ്ഥാനപരമായ പരിശോധനകൾക്ക് (sanity-checking) ഉപകരിക്കുമെങ്കിലും, പ്രൊഡക്ഷൻ കോഡ് റിവ്യൂവിലെ സങ്കീർണ്ണവും ചിലവ് കൂടിയതുമായ സാഹചര്യങ്ങളെ അതിജീവിക്കാൻ ആ ടൂളിന് കഴിയുമെന്ന് അത് ഉറപ്പുനൽകുന്നില്ല.