SWE-bench Verified ഇനിമുതല് അത്യാധുനിക കോഡിംഗ് കഴിവുകൾ അളക്കാത്തതിന്റെ കാരണം എന്താണ്
SWE-bench Verified-ൽ മലിനീകരണം വർദ്ധിച്ചുവരുന്നു. ഞങ്ങൾ SWE-bench Pro ശുപാർശ ചെയ്യുന്നു.
2024 ഓഗസ്റ്റിൽ ഞങ്ങൾ ആദ്യമായി SWE-bench Verified പ്രസിദ്ധീകരിച്ചതിനുശേഷം, സ്വയംഭരണ സോഫ്റ്റ്വെയർ എഞ്ചിനീയറിംഗ് ടാസ്കുകളിലെ മോഡലുകളുടെ പുരോഗതി അളക്കാൻ വ്യവസായത്തില് ഇത് വ്യാപകമായി ഉപയോഗിച്ചു. അതിന്റെ റിലീസിന് ശേഷം, SWE-ബെഞ്ച് സ്ഥിരീകരിച്ചത് കഴിവിലെ പുരോഗതിക്ക് ശക്തമായ ഒരു സൂചന നൽകി, കൂടാതെ അത്യാധുനിക മോഡൽ റിലീസുകളിൽ റിപ്പോർട്ട് ചെയ്യുന്ന ഒരു സ്റ്റാൻഡേർഡ് മെട്രിക്കായി മാറി. ഈ ശേഷികളുടെ പുരോഗതി ട്രാക്ക് ചെയ്യുന്നതും പ്രവചിക്കുന്നതും OpenAIയുടെ പ്രിപെയർഡ്നസ് ഫ്രെയിംവർക്ക് എന്നതിന്റെ ഒരു പ്രധാന ഭാഗമാണ്. Verified ബെഞ്ച്മാർക്ക് ആദ്യമായി രൂപീകരിക്കുമ്പോൾ,SWE-ബെഞ്ച് ഡാറ്റാസെറ്റ്(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)-ല് ചില ടാസ്കുകൾ നിർവഹിക്കുന്നത് അസാധ്യമാക്കുന്ന വിധത്തില് യഥാർത്ഥ മൂല്യനിർണയ സംവിധാനത്തില് ഉണ്ടായിരുന്ന പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ ഞങ്ങൾ ശ്രമിച്ചു.
ആദ്യത്തെ വലിയ മുന്നേറ്റങ്ങൾക്ക് ശേഷം, SWE-ബെഞ്ച് സ്ഥിരീകരിച്ചതിലെ അത്യാധുനിക പുരോഗതി മന്ദഗതിയിലായി, കഴിഞ്ഞ 6 മാസങ്ങളിൽ 74.9% മുതൽ 80.9% വരെ മെച്ചപ്പെട്ടു(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു). ഇത് ഈ ചോദ്യം ഉയർത്തുന്നു: ശേഷിക്കുന്ന പരാജയങ്ങൾ മോഡൽ പരിമിതികളെയോ അല്ലെങ്കിൽ ഡാറ്റാസെറ്റിന്റെ തന്നെ ഗുണങ്ങളെയോ പ്രതിഫലിപ്പിക്കുന്നുണ്ടോ?
ഒരു പുതിയ വിശകലനത്തിൽ, സ്ഥിരീകരിച്ച സെറ്റിൽ രണ്ട് പ്രധാന പ്രശ്നങ്ങൾ ഞങ്ങൾ കണ്ടെത്തി; അവ ഇന്നത്തെ പ്രകടന നിലകളിൽ അത്യാധുനിക ലോഞ്ചുകൾക്കായുള്ള സ്വയംഭരണ സോഫ്റ്റ്വെയർ എഞ്ചിനീയറിംഗ് ശേഷികളിലെ പുരോഗതി അളക്കുന്നതിന് ഈ ബെഞ്ച്മാർക്ക് ഇനി അനുയോജ്യമല്ലെന്ന് സൂചിപ്പിക്കുന്നു:
- പരിശോധനകൾ ശരിയായ പരിഹാരങ്ങൾ നിരസിക്കുന്നു: മോഡലുകൾ പലപ്പോഴും പരിഹരിക്കാൻ പരാജയപ്പെട്ട ഡാറ്റാസെറ്റിന്റെ 27.6% ഒരു ചെറിയ സെറ്റ് ഞങ്ങൾ ഓഡിറ്റ് ചെയ്തു, കൂടാതെ, SWE-bench Verified ന്റെ പ്രാരംഭ സൃഷ്ടിയിൽ ഇതിനെ മെച്ചപ്പെടുത്താൻ ഞങ്ങൾ പരമാവധി ശ്രമിച്ചിട്ടും, ഓഡിറ്റ് ചെയ്ത പ്രശ്നങ്ങളിൽ കുറഞ്ഞത് 59.4% എങ്കിലും പ്രവർത്തനപരമായി ശരിയായ സമർപ്പണങ്ങളെ നിരസിക്കുന്ന പിഴവുള്ള ടെസ്റ്റ് കേസുകൾ ഉണ്ടെന്ന് കണ്ടെത്തി.
- പരിഹാരങ്ങളിലെ പരിശീലനം: വലിയ അത്യാധുനിക മോഡലുകൾക്ക് അവരുടെ പരിശീലനത്തിൽ നിന്ന് വിവരങ്ങൾ പഠിക്കാൻ കഴിയുന്നതിനാൽ, അവയെ വിലയിരുത്തുന്ന പ്രശ്നങ്ങളുടെയും പരിഹാരങ്ങളുടെയും അടിസ്ഥാനത്തിൽ ഒരിക്കലും പരിശീലിപ്പിക്കപ്പെടാതിരിക്കുക എന്നത് പ്രധാനമാണ്. ഇത് പരീക്ഷയ്ക്ക് മുമ്പ് വരാനിരിക്കുന്ന ഒരു പരീക്ഷയ്ക്കായി പ്രശ്നങ്ങളും പരിഹാരങ്ങളും വിദ്യാർത്ഥികളുമായി പങ്കിടുന്നതിന് സമാനമാണ് - അവർ ഉത്തരം മനഃപാഠമാക്കണമെന്നില്ല, പക്ഷേ മുമ്പ് ഉത്തരങ്ങൾ കണ്ടിട്ടുള്ള വിദ്യാർത്ഥികൾ, കാണാത്തവരെക്കാൾ തീർച്ചയായും മികച്ച പ്രകടനം കാഴ്ചവെക്കും. SWE-bench പ്രശ്നങ്ങൾ പല മോഡൽ പ്രൊവൈഡർമാരും പരിശീലന ആവശ്യങ്ങൾക്ക് ഉപയോഗിക്കുന്ന ഓപ്പൺ-സോഴ്സ് റിപ്പോസിറ്ററികളിൽ നിന്നാണ് ശേഖരിക്കുന്നത്. ഞങ്ങളുടെ വിശകലനത്തിൽ, ഞങ്ങൾ പരീക്ഷിച്ച എല്ലാ അത്യാധുനിക മോഡലുകൾക്കും ഗ്രൗണ്ട്-ട്രൂത്ത് റഫറൻസായി ഉപയോഗിച്ചിരുന്ന യഥാർത്ഥ മനുഷ്യൻ എഴുതിയ ബഗ് ഫിക്സ് (ഗോൾഡ് പാച്ച് എന്നറിയപ്പെടുന്നത്) അല്ലെങ്കിൽ ചില ടാസ്കുകൾക്കായി പ്രശ്നത്തിന്റെ പ്രസ്താവനയിലെ അതെ വാക്കുകള് തന്നെ പുനഃസൃഷ്ടിക്കാൻ കഴിഞ്ഞതായി കണ്ടെത്തി; ഇത് പരിശീലനത്തിനിടെ അവയെല്ലാം കുറഞ്ഞത് ചില പ്രശ്നങ്ങളും പരിഹാരങ്ങളും എങ്കിലും കണ്ടിട്ടുണ്ടെന്ന് സൂചിപ്പിക്കുന്നു.
പരിശീലന സമയത്ത് തന്നെ ഇത്തരം പ്രശ്നങ്ങളില് പരിചയമുള്ള മോഡലുകൾക്ക് വിജയിക്കാൻ കൂടുതൽ സാധ്യതയുണ്ടെന്നതിന് ഞങ്ങൾ തെളിവുകള് കണ്ടെത്തി, കാരണം മതിയായ രീതിയിൽ നിർവചിക്കപ്പെടാത്ത ടെസ്റ്റുകൾ പാസ്സാകാന് ആവശ്യമായ അധിക വിവരങ്ങൾ അവയ്ക്ക് ലഭിച്ചിട്ടുണ്ട്.
SWE-bench Verified-ലുള്ള മെച്ചപ്പെടുത്തലുകൾ ഇനിമുതല് പരീക്ഷിക്കപ്പെടുന്ന മോഡലുകളുടെ യഥാർത്ഥ ലോക സോഫ്റ്റ്വെയർ വികസനത്തിന്റെ കഴിവുകളില് ഉണ്ടാകുന്ന അർത്ഥവത്തായ മെച്ചപ്പെടുത്തലുകളെ പ്രതിഫലിപ്പിക്കില്ല എന്നാണ് ഇതിനര്ത്ഥം. പകരം, പരിശീലന സമയത്ത് ബെഞ്ച്മാർക്കിനോട് മോഡൽ എത്രത്തോളം എക്സ്പോസ് ചെയ്യപ്പെട്ടിരുന്നു എന്നതിനെ അവ കൂടുതൽ കൂടുതൽ പ്രതിഫലിപ്പിക്കുന്നു. ഇതാണ് ഞങ്ങൾ SWE-bench Verified സ്കോറുകൾ റിപ്പോർട്ട് ചെയ്യുന്നത് നിർത്തിയതിന്റെ കാരണം, മറ്റ് മോഡൽ ഡെവലപ്പർമാരും ഇത് പിന്തുടരണം എന്ന് ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു.
കോഡിംഗ് കഴിവുകൾ കൂടുതൽ നന്നായി ട്രാക്ക് ചെയ്യുന്നതിനായി ഞങ്ങൾ പുതിയ, ഇത്തരം മലിനീകരണമില്ലാത്ത, വിലയിരുത്തലുകൾ നിർമ്മിക്കുകയാണ്. കൂടാതെ വിശാലമായ ഗവേഷണ സമൂഹം ശ്രദ്ധ കേന്ദ്രീകരിക്കേണ്ട ഒരു പ്രധാന മേഖലയാണിതെന്ന് ഞങ്ങൾ കരുതുകയും ചെയ്യുന്നു. അവ ലഭിക്കുന്നതുവരെ, SWE-bench Pro-യുടെ ഫലങ്ങൾ റിപ്പോർട്ട് ചെയ്യാൻ OpenAI ശുപാർശ ചെയ്യുന്നു.
അസൽ SWE-bench(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) മൂല്യനിർണ്ണയം 2023-ൽ പുറത്തിറക്കി. ഓരോ പ്രശ്നവും 12 ഓപ്പൺ-സോഴ്സ് Python റിപ്പോസിറ്ററികളിൽ ഒന്നിലെ പരിഹരിച്ച GitHub issue-ൽ നിന്ന് എടുത്തതും അതിനനുസരിച്ച pull request (PR) നോടൊപ്പം ജോഡിപ്പിച്ചതുമാണ്. മോഡൽ-ജനറേറ്റ് ചെയ്ത കോഡ് മാറ്റം ശരിയാണോ എന്ന് നിർണ്ണയിക്കാൻ, ഓരോ പ്രശ്നത്തിനും രണ്ട് സെറ്റ് പരീക്ഷണങ്ങൾ ഉണ്ട്:
- മാറ്റങ്ങളൊന്നും വരുത്താത്ത കോഡ്ബേസിൽ പരാജയപ്പെടുകയും, പ്രശ്നം ശരിയായി പരിഹരിച്ചാൽ പാസ് ചെയ്യുകയും ചെയ്യുന്ന ടെസ്റ്റുകൾ
- ബന്ധമില്ലാത്ത പ്രവർത്തനക്ഷമത കേടുകൂടാതെ നിലനിൽക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ, പരിഹാരത്തിന് മുമ്പും ശേഷവും വിജയിക്കുന്ന പുനരാവർത്തന സ്വഭാവമുള്ള ടെസ്റ്റുകൾ.
മോഡൽ, ടെസ്റ്റുകൾ കാണുന്നില്ല. യഥാർത്ഥത്തില് ഇഷ്യൂ ചെയ്ത ടെക്സ്റ്റും ഫിക്സിന് മുമ്പുള്ള റിപ്പോസിറ്ററിയുടെ നിലയും മാത്രം നൽകിയാൽ ഇത് ഒരു കോഡ് വ്യത്യസം സൃഷ്ടിക്കണം. കോഡ് മാറ്റം പ്രയോഗിച്ചതിന് ശേഷം മാത്രം എല്ലാ ടെസ്റ്റുകളും പാസ്സായാൽ മാത്രമേ അത് ഒരു പ്രോബ്ലം പാസ്സാകുന്നുള്ളൂ.
മോഡലുകളുടെ കഴിവ് കുറച്ചു കാണിക്കുന്നതിലേക്ക് നയിച്ചേക്കാവുന്ന നിരവധി പ്രശ്നങ്ങൾ ആ മൂല്യനിർണ്ണയത്തിൽ ഞങ്ങൾ കണ്ടെത്തി.
- ചില യൂണിറ്റ് ടെസ്റ്റുകൾ ആവശ്യത്തില് അധികം വ്യക്തമാക്കപെട്ടതോ ടാസ്കുമായി പൊരുത്തക്കേടുള്ളതോ ആയത് കൊണ്ട് ശരിയായ പരിഹാരങ്ങൾ തള്ളിക്കളയപ്പെടാൻ സാധ്യതയുണ്ടായിരുന്നു.
- പല ടാസ്ക് പ്രസ്താവനകൾ വ്യക്തമായി നിർവചിക്കപ്പെട്ടിരുന്നില്ല, അതിനാൽ ഒന്നിലധികം സാധുവായ വ്യാഖ്യാനങ്ങൾ ഉണ്ടാകാം - എന്നാൽ പരിശോധനകൾ ഒരു പ്രത്യേക വ്യാഖ്യാനം മാത്രം ഉൾക്കൊണ്ടിരുന്നു.
- പരിസ്ഥിതിയുടെ ക്രമീകരണത്തെ ആശ്രയിച്ച് (ഉദാഹരണത്തിന് Linux vs Windows, അല്ലെങ്കിൽ python പതിപ്പ്), ചില ടെസ്റ്റുകൾ തെറ്റായി പരാജയപ്പെടാൻ സാധ്യതയുണ്ട്
ഈ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനായി ഞങ്ങൾ 2024-ൽ SWE-ബെഞ്ച് സ്ഥിരീകരിച്ചത് സൃഷ്ടിച്ചു. 1,699 SWE-ബെഞ്ച് പ്രശ്നങ്ങൾ അവലോകനം ചെയ്യാനും ഈ പ്രശ്നങ്ങൾ ഉണ്ടായിരുന്ന പ്രശ്നങ്ങൾ ഒഴിവാക്കാനായി ഞങ്ങൾ വിദഗ്ധ സോഫ്റ്റ്വെയർ എഞ്ചിനീയർമാരുമായി ചേർന്ന് പ്രവർത്തിച്ചു. ഓരോ പ്രശ്നവും മൂന്ന് വിദഗ്ധർ സ്വതന്ത്രമായി അവലോകനം ചെയ്തു. ഈ അവലോകന പ്രക്രിയയുടെ ഫലമായി SWE-ബെഞ്ച് സ്ഥിരീകരിച്ചത്, 500 പ്രശ്നങ്ങളുടെ ഒരു ക്യൂറേറ്റ് ചെയ്ത സമാഹാരം ഉണ്ടായി.
SWE-bench Verified പ്രാരംഭ പതിപ്പിനെക്കാൾ വലിയ മെച്ചപ്പെടുത്തലാണെങ്കിലും, ശേഷിക്കുന്ന പ്രശ്നങ്ങൾ ഇപ്പോഴും നിലനിൽക്കുന്നു. ഞങ്ങൾ OpenAI o3 64 സ്വതന്ത്ര റൺസുകളിലുടനീളം സ്ഥിരമായി പരിഹരിക്കാനാകാതിരുന്ന 138 SWE-ബെഞ്ച് സ്ഥിരീകരിച്ച പ്രശ്നങ്ങളുടെ ഒരു ഓഡിറ്റ് നടത്തി. ഓരോ കേസും കുറഞ്ഞത് ആറു പരിചയസമ്പന്നരായ സോഫ്റ്റ്വെയർ എഞ്ചിനീയർമാർ സ്വതന്ത്രമായി അവലോകനം ചെയ്തു. ഒരു വിദഗ്ധൻ ഒരു പ്രശ്നം ഫ്ലാഗ് ചെയ്യുന്നു എങ്കില്, അത് മറ്റൊരു ടീം വീണ്ടും സ്ഥിരീകരിച്ചു.
138 പ്രശ്നങ്ങളിൽ 59.4% എണ്ണത്തിലും ടെസ്റ്റ് ഡിസൈനിലും/അല്ലെങ്കിൽ പ്രശ്ന വിവരണത്തിലും ഗൗരവമായ പ്രശ്നങ്ങൾ അടങ്ങിയിരുന്നുവെന്ന് ഞങ്ങൾ കണ്ടെത്തി, അതിനാൽ ഏറ്റവും കഴിവുള്ള മോഡലിനോ അല്ലെങ്കില് ഒരു മനുഷ്യനോ പോലും അവ പരിഹരിക്കുന്നത് അത്യന്തം ബുദ്ധിമുട്ടായതോ അസാധ്യമോ ആയിരുന്നു.
- ഓഡിറ്റ് ചെയ്ത ടാസ്കുകളിൽ 35.5% കർശനമായ ടെസ്റ്റ് കേസുകൾ ഉണ്ട്, അവ നിർദ്ദിഷ്ട ഇംപ്ലിമെന്റേഷൻ വിശദാംശങ്ങൾ നിർബന്ധിതമാക്കുന്നു, അതിനാൽ പ്രവർത്തനപരമായി ശരിയായ പല സമർപ്പണങ്ങളും അസാധുവാകുന്നു. ഇവയെ ഞങ്ങൾ ഇടുങ്ങിയ ടെസ്റ്റ് കേസുകൾഎന്ന് വിളിക്കുന്നു.
- ഓഡിറ്റ് ചെയ്ത ടാസ്കുകളിൽ 18.8% ന്, പ്രശ്ന വിവരണത്തിൽ വ്യക്തമാക്കിയിട്ടില്ലാത്ത അധിക പ്രവർത്തനക്ഷമത പരിശോധിക്കുന്ന ടെസ്റ്റുകൾ ഉണ്ട്; ഇവയെ ഞങ്ങൾ വൈഡ് ടെസ്റ്റ് കേസുകൾഎന്ന് വിളിക്കുന്നു.
- ബാക്കിയുള്ള 5.1% ടാസ്കുകൾക്ക് ഈ ടാക്സോണമിയുമായി നന്നായി ഗ്രൂപ്പ് ചെയ്യപ്പെടാത്ത വിവിധതരം പ്രശ്നങ്ങൾ ഉണ്ടായിരുന്നു.
ആദ്യ പരാജയ മോഡിന്റെ ഒരു ഉദാഹരണ ചിത്രീകരണം pylint-dev__pylint-4551(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ആണ്, ഇവിടെ മൊത്തത്തിലുള്ള പരിഹാരത്തിന്റെ ഭാഗമായി PR ഒരു പുതിയ ഫംഗ്ഷൻ `get_annotation` അവതരിപ്പിക്കുന്നു. ഈ ഫംഗ്ഷൻ നാമം പ്രശ്ന വിവരണത്തിൽ പരാമർശിച്ചിട്ടില്ല, പക്ഷേ ടെസ്റ്റുകൾ അത് നേരിട്ട് ഇമ്പോർട്ട് ചെയ്യുന്നു. ചില മോഡലുകൾക്ക് അത്തരമൊരു ഫംഗ്ഷൻ സൃഷ്ടിക്കാൻ സ്വാഭാവികമായി തോന്നിയേക്കാമെങ്കിലും, പ്രശ്നം ശരിയായി പരിഹരിക്കാൻ ഈ പ്രത്യേക പേരുള്ള ഒരു ഫംഗ്ഷൻ തന്നെ നടപ്പിലാക്കണം എന്ന് നിര്ബന്ധമില്ല. ഇമ്പോർട്ട് എററുകള് കാരണം പല സാധുവായ പരിഹാരങ്ങളും ടെസ്റ്റ് കേസുകൾ പാസ്സാകുന്നില്ല.
പ്രശ്ന വിവരണം
PR ടെസ്റ്റ് സ്നിപ്പെറ്റ്
PR ടെസ്റ്റ് പരാജയങ്ങൾ (വായനാസൗകര്യത്തിനായി ചുരുക്കിയിരിക്കുന്നു)
വളരെ വൈഡ് ടെസ്റ്റ് കേസുകള്ക്ക് ഒരു ഉദാഹരണം ആണ് sympy__sympy-18199(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു). ഈ ടാസ്ക് `nthroot_mod` ഫംഗ്ഷനുമായി ബന്ധപ്പെട്ട മൂന്ന് വ്യത്യസ്ത പ്രശ്നങ്ങൾ പരിഹരിച്ച ഒരു PR-ൽ നിന്നാണ് എടുത്തത്, പ്രത്യേകിച്ച് #17373(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), #17377(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), #18212(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു). എന്നിരുന്നാലും, SWE-ബെഞ്ച് സ്ഥിരീകരിച്ചത് ടാസ്കിന്റെ വിവരണം അവസാന പ്രശ്നമായ #18212(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) മാത്രമേ ഉൾക്കൊള്ളുന്നുള്ളൂ. ഇത് ഒരു പൊരുത്തക്കേട് ഉണ്ടാക്കുന്നു: PR ടെസ്റ്റുകൾ മൂന്നു പ്രശ്നങ്ങളെയും ഉൾക്കൊള്ളുമ്പോൾ, വിവരണം ഒന്നിനെ മാത്രമാണ് വിശദീകരിക്കുന്നത്. ഞങ്ങളുടെ റൺസിൽ, മോഡലുകൾ പലപ്പോഴും വിവരിച്ച പരിഹാരം ശരിയായി നടപ്പിലാക്കുകയും തുടർന്ന് മറ്റ് രണ്ട് പ്രശ്നങ്ങൾക്കായുള്ള നടപ്പിലാക്കൽ ഉൾക്കൊള്ളുന്ന ടെസ്റ്റുകളിൽ പരാജയപ്പെടുകയും ചെയ്യുന്നു.
(GitHub PR-ൽ നിന്നുള്ള) യഥാർത്ഥ PR വിവരണം
#18212-നുള്ള പ്രശ്ന വിവരണം
SWE-bench Verified ടാസ്കിനുള്ള പ്രശ്ന വിവരണം (#18212-ൽ നിന്ന് മാത്രം എടുത്തത്):
SWE-bench Verified ഉം റിപ്പോസിറ്ററികൾ (കോഡ് ബേസുകളും റിലീസ് നോട്ടുകളും) രണ്ടും ഓപ്പൺ-സോഴ്സും വ്യാപകമായി ഉപയോഗിക്കപ്പെടുകയും ചർച്ച ചെയ്യപ്പെടുകയും ചെയ്യുന്നത് ആയതുകൊണ്ട്, മോഡൽ ഡെവലപ്പർമാർക്ക് മലിനീകരണം ഒഴിവാക്കുന്നത് ബുദ്ധിമുട്ടാണ്.
ഞങ്ങളുടെ സ്വന്തം മോഡലുകളിൽ ആദ്യം മലിനീകരണത്തിന്റെ അടയാളങ്ങൾ കണ്ടു. ഉദാഹരണത്തിന്, GPT‑5.2 ഞങ്ങൾ പരിഹരിക്കാൻ ഏതാണ്ട് അസാധ്യമായതെന്ന് കണക്കാക്കിയ 31 ടാസ്കുകൾ പരിഹരിച്ചു. django__django-14725(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ൽ ടെസ്റ്റുകൾക്ക് പ്രശ്ന പ്രസ്താവനയിൽ വ്യക്തമായി ആവശ്യപ്പെട്ടിട്ടില്ലാത്ത ഒരു പുതിയ പാരാമീറ്റർ `edit_only` ആവശ്യമാണ്. പ്രശ്നം പരിഹരിക്കുമ്പോൾ, GPT‑5.2 തന്റെ ചെയിൻ-ഓഫ്-തോട്ട് കാണിക്കുന്നത് കോഡ്ബേസിലെ മാറ്റങ്ങളെ വിശദമായി രേഖപ്പെടുത്തുന്ന റിലീസ് നോട്ടുകളിലെ വിവരങ്ങൾ ഇതിൽ അടങ്ങിയിരിക്കുന്നുവെന്നും. അതോടൊപ്പം, edit_only പരാമീറ്റർ Django 4.1 പതിപ്പിൽ അവതരിപ്പിച്ചതാണെന്ന് ഇത് കൃത്യമായി തിരിച്ചറിയുന്നു എന്നുമാണ്.
GPT‑5.2 CoT
ഗണ്യമായ മലിനീകരണം എത്രത്തോളം വ്യാപകമാണെന്ന് വിലയിരുത്താൻ, ഞങ്ങൾ ഒരു സ്വയം പ്രവർത്തിക്കുന്ന റെഡ് ടീമിംഗ് സജ്ജീകരണം സൃഷ്ടിച്ചു. ഓരോ SWE-ബെഞ്ച് സ്ഥിരീകരിച്ചു ചോദ്യത്തിനും, GPT‑5.2‑Chat നെ പ്രോബുചെയ്യാൻ GPT‑5 നെ ഞങ്ങൾ ചുമതലപ്പെടുത്തി, Claude Opus 4.5യും Gemini 3 Flash Previewയും അനാവശ്യ സ്വാധീനം പരിശോധിക്കുന്നതിനായി വിലയിരുത്തി. റീസണിംഗ് മോഡലുകൾ ഒഴിവാക്കുന്നതിനായി ഈ മോഡലുകൾ തിരഞ്ഞെടുക്കപ്പെട്ടു, എന്നാൽ അവയുടെ ശേഷിയില് ഗണ്യമായ വ്യത്യാസം ഉണ്ടാകാൻ സാധ്യതയുണ്ടെന്ന് ഞങ്ങൾ അംഗീകരിക്കുന്നു.
മലിനീകരണം പരിശോധിക്കുന്നതിനായി, GPT‑5 ന് ലഭിച്ചത്: SWE-ബെഞ്ച് സ്ഥിരീകരിച്ചു ടാസ്കിന്റെ ID, വിവരണം, ഗോൾഡ് പാച്ച്, PR ടെസ്റ്റുകൾ എന്നിവയാണ്. 15-ലധികം ടേണുകളിലായി, സിസ്റ്റം/ഡെവലപ്പർ പ്രോംപ്റ്റ്, ഉപയോക്തൃ പ്രോംപ്റ്റ്, അസിസ്റ്റന്റ് പ്രീഫിൽ എന്നിവയും വ്യത്യസ്ത എലിസിറ്റേഷൻ തന്ത്രങ്ങളും മാറ്റാൻ ഞങ്ങൾ GPT‑5‑നെ അനുവദിച്ചു. ഓരോ ടേണിന് ശേഷവും, ഒരു ജഡ്ജ് മോഡൽ എത്രമാത്രം പുതിയ ടാസ്ക്-നിർദ്ദിഷ്ട വിവരങ്ങൾ പ്രത്യക്ഷപ്പെട്ടു എന്ന് ലേബൽ ചെയ്തു, കൂടാതെ ഓരോ പ്രതികരണവും “ഒട്ടുമില്ല” മുതൽ “ശക്തമായി” വരെ മലിനീകരണ തീവ്രതയ്ക്കായി ലേബൽ ചെയ്തു. മുൻ ടേണുകളെ അടിസ്ഥാനമാക്കി ടാസ്ക്-നിർദ്ദിഷ്ട വിശദാംശങ്ങൾ ആവർത്തിച്ച് വീണ്ടെടുക്കുന്നതിനായി GPT‑5‑ന് അതിന്റെ തന്ത്രം പൊരുത്തപ്പെടുത്താൻ അനുവദിച്ചു. ശക്തമായ മലിനീകരണത്തിന്റെ ഓരോ ഉദാഹരണത്തിനും, GPT‑5 ലക്ഷ്യ മോഡലിലേക്ക് അത്യധികം വിവരങ്ങൾ ചോർന്നുപോകുന്നില്ലെന്ന് മറ്റൊരു ജഡ്ജിനൊപ്പം ഞങ്ങൾ സ്ഥിരീകരിച്ചു. അവസാനം, ഈ പോസ്റ്റിലെ ട്രാൻസ്ക്രിപ്റ്റുകൾ രൂപപ്പെടുത്തുന്ന “ശക്തമായ” ഉദാഹരണങ്ങൾ പിന്നീട് മനുഷ്യര് തന്നെ അവലോകനം ചെയ്തു.
വ്യത്യസ്ത മോഡൽ പ്രൊവൈഡർമാർക്കിടയിൽ ശക്തമായ മലിനീകരണത്തിന്റെ ഉദാഹരണങ്ങൾ താഴെ കൊടുക്കുന്നു.
ടാസ്ക് വിവരണത്തിൽ നിന്നുള്ള ഒരു ചെറിയ ഭാഗം നൽകിയാൽ, GPT‑5.2 കൃത്യമായ ഗോൾഡ് പാച്ച് പുറത്തുവിടുന്നു. പ്രത്യേകിച്ച്, അതിന് കൃത്യമായ ക്ലാസ്, മെതഡ് പേര് എന്നിവയും, അവതരിപ്പിച്ചിരിക്കുന്ന പുതിയ early return നിബന്ധന ആയ `യുസര് നെയിമോ പാസ്സ്വേര്ഡോ ഇല്ലെങ്കില്' എന്നതും അറിയാം.
അനാവശ്യ സ്വാധീനം വെളിപ്പെടുത്തൽ
ഗോൾഡ് പാച്ച്
PR അവതരിപ്പിച്ച കൃത്യമായ 4-ലൈൻ ഫംഗ്ഷണൽ മാറ്റം, അത് സ്പർശിച്ച പ്രത്യേക ഫയല് നെയിമും മെത്തേഡും സഹിതം, ഓർമ്മപ്പെടുത്താൻ മാത്രമല്ല, Opus-ന് diff-ന്റെ ഭാഗമായിരുന്ന inline comment-ും വാക്യം പ്രതി ഉദ്ധരിക്കുകയും ചെയ്യുന്നു.
അനാവശ്യ സ്വാധീനം വെളിപ്പെടുത്തൽ
ഗോൾഡ് പാച്ച്
ജെമിനി 3 Flash, ID ഒഴികെ ടാസ്കിനെക്കുറിച്ച് കൂടുതൽ വിവരങ്ങൾ ഒന്നും നൽകാത്തപ്പോൾ, ടാസ്ക് വിവരണത്തിലും ഗോൾഡ് പാച്ചിലും നിന്നുള്ള വാക്കുതോതിലുള്ള വിശദാംശങ്ങൾ ഔട്ട്പുട്ട് ചെയ്യാൻ കഴിയും. ഇതിൽ ഉപയോക്തൃനാമം സാധൂകരിക്കുന്നതിനുള്ള പുതിയ regex ഫോർമുലയും മാറ്റത്തിനുള്ള കൃത്യമായ വരി നമ്പറുകളും ഉൾപ്പെടുന്നു.
അനാവശ്യ സ്വാധീനം വെളിപ്പെടുത്തൽ
ഗോൾഡ് പാച്ച്
SWE-bench Verified എന്നതിന്റെ ഈ ഓഡിറ്റിൽ നിന്ന്, മൂല്യനിർണ്ണയ രൂപകൽപ്പനയ്ക്കായി രണ്ട് വിപുലമായ പാഠങ്ങൾ നമുക്ക് കാണാം. ആദ്യം, പൊതുവായി ലഭ്യമായ വസ്തുക്കളിൽ നിന്ന് ലഭിച്ച ബെഞ്ച്മാർക്കുകൾക്ക് മലിനീകരണ അപകടസാധ്യതയുണ്ട്, കാരണം പരിശീലന-ഡാറ്റ എക്സ്പോഷർ നിശ്ശബ്ദമായി സ്കോറുകൾ ഉയർത്തിക്കാട്ടാൻ കഴിയും. പൊതുവായി ക്രോൾ ചെയ്ത ഡാറ്റ ബെഞ്ച്മാർക്ക് നിർമ്മാണത്തിൽ ഉപയോഗിക്കുന്നുവെങ്കിൽ, മോഡൽ ഡെവലപ്പർമാർ മലിനീകരണം കണ്ടെത്തുന്നതിനായി അധിക ടെസ്റ്റുകൾ നടത്തണം. ബെഞ്ച്മാർക്കുകൾ, അവയുടെ പരിഹാരങ്ങൾ പോലും, പൊതുവായി പോസ്റ്റ് ചെയ്താൽ പരിശീലന ഡാറ്റയിൽ ഉൾപ്പെടാൻ സാധ്യതയുണ്ട്. ഡാറ്റാസെറ്റുകൾ പോസ്റ്റ് ചെയ്യുന്നത് എങ്ങനെ എന്നതിലും അധിക ശ്രദ്ധ ആവശ്യമുണ്ട് (i.e. പാസ്വേഡ് സംരക്ഷിതം) കൂടാതെ പരിശീലന ഡാറ്റ തരംതിരിക്കൽ (i.e. കാനറി സ്ട്രിംഗുകൾ കർശനമായി പാലിക്കൽ).
രണ്ടാമതായി, ഓട്ടോമേറ്റഡ് സ്കോറിംഗ് ശരിയായി നേടുന്നത് സങ്കീർണ്ണമാണ്; പൂർണ്ണമായ ടെസ്റ്റ് കേസുകൾ ശരിയായ പ്രവർത്തനക്ഷമത പൂർണ്ണമായി തന്നെ സ്ഥിരീകരിക്കണം, പ്രത്യേകിച്ചും പ്രാധാന്യമില്ലാത്ത നടപ്പിലാക്കൽ വിശദാംശങ്ങളോട് ജാഗ്രത പാലിക്കുകയും, കൂടാതെ ഷോർട്ട്കട്ട് പരിഹാരങ്ങളോട് പ്രതിരോധശേഷിയുള്ളതായിരിക്കുകയും വേണം. ഈ പ്രശ്നങ്ങൾ പാരമ്പര്യമായി സങ്കീർണ്ണവും പരിഹരിക്കാൻ ബുദ്ധിമുട്ടുള്ളതുമാണ്. ഈ പ്രശ്നങ്ങൾ കണ്ടെത്താൻ ഒന്നിലധികം വിപുലമായ മനുഷ്യ ലേബലിംഗ് കാമ്പെയ്നുകൾ ആവശ്യമായി വന്നു.
ഈ കണ്ടെത്തലുകൾ ഞങ്ങളുടെ അടുത്തിടെയുള്ള വിലയിരുത്തൽ ശ്രമങ്ങളിൽ ഞങ്ങൾ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. ഞങ്ങൾ കഴിഞ്ഞ മാസങ്ങളിൽ SWE-Bench Pro-യുടെ പൊതു വിഭജനത്തിൽ നിന്നുള്ള ഫലങ്ങൾ റിപ്പോർട്ട് ചെയ്യാൻ തീരുമാനിച്ചു. മറ്റ് മോഡൽ ഡെവലപ്പർമാരും അത് പിന്തുടരണമെന്ന് ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു. SWE-bench Pro പെര്ഫെക്റ്റ് അല്ല, പക്ഷേ അനുഭവത്തിന്റെ അടിസ്ഥാനത്തില് പരിശോധിച്ചാല് മലിനീകരണ പ്രശ്നങ്ങൾ അതിനെ കുറച്ചുമാത്രം ബാധിക്കുന്നതായി തോന്നുന്നു. ഞങ്ങളുടെ മലിനീകരണ പൈപ്പ്ലൈൻ ചില മലിനീകരണ കേസുകൾ കണ്ടെത്തി, പക്ഷേ ഈ കേസുകൾ SWE-bench Verified-നെക്കാൾ വളരെ അപൂർവവും കുറച്ച്മാത്രം ഗുരുതരവുമായിരുന്നു, കൂടാതെ ഒരു മോഡലിനും പൂർണ്ണമായ verbatim gold patch നിർമ്മിക്കാൻ കഴിഞ്ഞില്ല.
സ്വകാര്യമായി രചിച്ച യഥാർത്ഥ ബെഞ്ച്മാർക്കുകളിൽ ഞങ്ങൾ തുടർന്നും നിക്ഷേപിക്കും, അതുപോലെ ചെയ്യാൻ വ്യവസായത്തിലും അക്കാദമിയയിലും നിന്ന് സഹായം അഭ്യർത്ഥിക്കുകയും ചെയ്യും. GDPVal-ൽ, ടാസ്കുകൾ ഡൊമെയ്ൻ വിദഗ്ധർ സ്വകാര്യമായി രചിക്കുന്നതിനാൽ എക്സ്പോഷർ റിസ്ക് കുറയുന്നു, കൂടാതെ പരിഹാരങ്ങൾ പരിശീലനം നേടിയ റിവ്യൂവർമാർ സമഗ്രമായി മൂല്യനിർണ്ണയം ചെയ്യുന്നു. ഈ സമീപനം വിഭവ-തീവ്രമാണ്, എന്നാൽ യഥാർത്ഥ ശേഷി മെച്ചപ്പെടുത്തലുകൾ അളക്കാൻ ഇത് കൂടുതൽ കൂടുതൽ ആവശ്യമായി വരുന്നു.


