CodeVetter નું v1 benchmark 27 સિન્થેટિક કેસોને AI-સંચાલિત કોડ-રિવ્યુ પાઇપલાઇન દ્વારા ચલાવે છે અને ટૂલ દ્વારા પ્લાન્ટ કરેલા બગ્સ પકડાય છે કે નહીં તે રેકોર્ડ કરે છે. ત્યારબાદ તે દરેક કેસ માટે પાસ અથવા ફેઇલની ગણતરી કરે છે.
આ benchmark શા માટે મહત્વનું છે
આ ટેસ્ટ એક મર્યાદિત પ્રશ્ન પૂછે છે: શું આપેલ રિવ્યુઅર આ નિશ્ચિત સ્નિપેટ્સના સેટમાં benchmark ડિઝાઇનરોએ એમ્બેડ કરેલી ચોક્કસ ખામીઓને ઓળખી શકે છે? ડેવલપર્સ આ પરિણામનો ઉપયોગ ઇશ્યુ કવરેજ (issue coverage) ના ઝડપી ચેક તરીકે કરી શકે છે. કારણ કે રિપોઝિટરીમાં ટાસ્ક પેકેજ અને સ્કોરિંગ સ્ક્રિપ્ટ ઉપલબ્ધ છે, તેથી કોઈપણ વ્યક્તિ ટેસ્ટ ફરીથી ચલાવી શકે છે અને સમાન આંકડા મેળવી શકે છે.
આ benchmark શું સાબિત કરતું નથી
27-કેસનું સિન્થેટિક સ્યુટ એ ટીમ દ્વારા દરરોજ હેન્ડલ કરવામાં આવતા હજારો pull requests નું સ્થાન લઈ શકે તેમ નથી. આ benchmark નીચેની બાબતો વિશે કંઈ જ કહેતું નથી:
- વાસ્તવિક દુનિયાની વિવિધતા (Real-world diversity) – તે માત્ર થોડી ભાષાઓ અને બગ કેટેગરીની મર્યાદિત શ્રેણીને આવરી લે છે.
- પરફોર્મન્સ (Performance) – તે સમય અથવા કમ્પ્યુટ-કોસ્ટના માપદંડો પૂરા પાડતું નથી.
- કોડ બેઝમાં વિશ્વસનીયતા (Reliability across code bases) – લાઈવ-રિપો ટેસ્ટિંગ વગર આપણે જાણી શકતા નથી કે ટૂલ પ્રોડક્શનમાં સૂક્ષ્મ ખામીઓ ચૂકી જશે કે ખોટા પોઝિટિવ્સ (false positives) જનરેટ કરશે.
પ્રકાશિત પરિણામોને ઇન્ફ્રાસ્ટ્રક્ચર ફાઇલો અને ભવિષ્યના "વ્યાપક, વાસ્તવિક ડેટા" ના વચનો સાથે મિશ્રિત કરવાથી એક માર્કેટિંગ નેરેટિવ ઊભું થાય છે કે આ સિંગલ સ્કોર પ્રોડક્શન-રેડી ક્ષમતા દર્શાવે છે, જે ડેટા દ્વારા સમર્થિત નથી.
આ benchmark વ્યાપક ટેસ્ટિંગ ઇકોસિસ્ટમમાં કેવી રીતે ફિટ થાય છે
CodeVetter જેવા રેકગ્નિશન-સ્ટાઇલ (Recognition-style) benchmarks એ ટૂલ કેટલા વિસ્તારને હેન્ડલ કરી શકે છે તેનું મેપિંગ કરે છે. તેઓ SWE-bench જેવા ફંક્શનલ benchmarks ને પૂરક છે, જે તપાસે છે કે AI-જનરેટેડ પેચ ખરેખર હાલના કોડ બેઝમાં વાસ્તવિક સમસ્યાનું નિરાકરણ લાવે છે કે નહીં. સાથે મળીને તેઓ એક સંપૂર્ણ ચિત્ર આપે છે: કવરેજ વિરુદ્ધ અસરકારકતા (coverage versus effectiveness).
એક સારા એજન્ટ benchmark માં આખું સ્ટેક (full stack) ખુલ્લું હોવું જોઈએ:
- ડેટાસેટ (The dataset) – રો ઇનપુટ્સ અને અપેક્ષિત આઉટપુટ્સ.
- દરેક કેસ માટે ડોક્યુમેન્ટેશન (Per-case documentation) – દરેક ટેસ્ટ માટે એક પેજ જે બગ, સાચું ફિક્સ અને ટૂલનો પ્રતિસાદ દર્શાવે છે.
- રિવ્યુઅર આઉટપુટ્સ (Reviewer outputs) – AI દ્વારા આપવામાં આવેલા ચોક્કસ કોમેન્ટ્સ અથવા સૂચનો.
- સ્કોરિંગ પદ્ધતિ (Scoring methodology) – મેચ કેવી રીતે નક્કી કરવામાં આવે છે, જેમાં પાર્શિયલ ક્રેડિટ માટેની સહિષ્ણુતાનો પણ સમાવેશ થાય છે.
- રીપ્રોડ્યુસિબિલિટી સૂચનાઓ (Reproducibility instructions) – વર્ઝન પિન, હાર્ડવેર વિગતો અને ટેસ્ટ ફરીથી ચલાવવા માટેની સ્ક્રિપ્ટ્સ.
જ્યારે આ તમામ ભાગો પારદર્શક હોય ત્યારે જ આપણે સિંગલ એગ્રીગેટ સ્કોર પર વિશ્વાસ કરી શકીએ છીએ.
benchmark દ્વારા સૂચવવામાં આવેલી મર્યાદાઓ
- સિન્થેટિક કેસો, જે લાઈવ રિપોઝિટરીઝમાંથી લેવામાં આવ્યા નથી.
- મર્યાદિત ભાષા અને બગ-ટાઇપની પસંદગી.
- સમય અથવા ખર્ચનો ડેટા નથી, તેથી કાર્યક્ષમતા અજ્ઞાત છે.
- ચોકસાઈના અવરોધો (Precision constraints) જે બોર્ડરલાઇન નિષ્ફળતાઓને છુપાવી શકે છે.
આગળ શું જોવું
CodeVetter માટે—અને AI રિવ્યુઅર્સનો ઉપયોગ કરનાર કોઈપણ વ્યક્તિ માટે—આગળનું પગલું મોટા અને વધુ વૈવિધ્યસભર કોર્પોરા (corpora) પર વારંવાર પુરાવા આપવાનું છે. તેનો અર્થ એ છે કે વાસ્તવિક pull-request સ્ટ્રીમ્સ પર પરિણામો પ્રકાશિત કરવા, લેટન્સી (latency) અને કમ્પ્યુટ વપરાશનો રિપોર્ટ આપવો અને નિષ્ફળતાના પ્રકારોને કેટેગરી મુજબ વિભાજિત કરવા. જ્યાં સુધી આવો ડેટા ન મળે ત્યાં સુધી, 27-કેસ સ્કોરને પ્રારંભિક સૂચક તરીકે ગણો, તૈયાર હોવાની ખાતરી તરીકે નહીં.
મુખ્ય વાત (Takeaway): એવું benchmark જે તમને માત્ર એટલું જ જણાવે છે કે ટૂલ થોડા પૂર્વ-લખાયેલા બગ્સ શોધી શકે છે કે નહીં, તે સેનિટી-ચેકિંગ (sanity-checking) માટે ઉપયોગી છે, પરંતુ તે એ પ્રમાણિત કરતું નથી કે ટૂલ પ્રોડક્શન કોડ રિવ્યુની વધુ જટિલ અને ખર્ચ-સંવેદનશીલ વાસ્તવિકતામાં ટકી શકશે.