69 AI-എഴുതിയ ടെസ്റ്റുകൾ ഒരു Python മോഡ്യൂൾ വിജയിപ്പിച്ചെങ്കിലും, ഒരു ലക്ഷ്യബോധത്തോടെയുള്ള (targeted) ടെസ്റ്റ് ജനറേഷൻ രീതി ഉപയോഗിച്ചപ്പോൾ ഉൾപ്പെടുത്തിയ 53 പിഴവുകളിൽ (faults) 44 എണ്ണവും കണ്ടെത്താൻ സാധിച്ചതായി ഒരു പരീക്ഷണം കാണിച്ചു. നിലവിലെ ലാർജ് ലാംഗ്വേജ് മോഡലുകളുടെ (LLM) ടെസ്റ്റ് എഴുതുന്ന രീതിയിലുള്ള ഒരു അടിസ്ഥാനപരമായ പോരായ്മയാണ് ഈ വാരാന്ത്യ പരീക്ഷണത്തിലൂടെ തെളിയിക്കപ്പെട്ടത്: ഒരു ടെസ്റ്റ് അറിയപ്പെടുന്ന ഒരു പിഴവ് കണ്ടെത്തുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്ന ഒരു ഫീഡ്‌ബാക്ക് ലൂപ്പ് ഇല്ലാതെ, നിർമ്മിക്കപ്പെട്ട ടെസ്റ്റുകൾ പിഴവുകൾ ഇല്ലാത്തവയായി തോന്നാമെങ്കിലും അവ കണ്ടെത്തേണ്ട ബഗുകളെ തന്നെ അവ പാതിവഴിയിൽ വിട്ടുപോകുന്നു.

ഈ പരീക്ഷണം പ്രധാനമാകുന്നത് എന്തുകൊണ്ട്

ഡെവലപ്പർമാർ യൂണിറ്റ് ടെസ്റ്റുകൾ തയ്യാറാക്കാൻ LLM-കളെ ആശ്രയിക്കുന്ന സാഹചര്യത്തിൽ, കോഡും അതിന്റെ കവറേജും (coverage) തമ്മിലുള്ള അകലം കുറയ്ക്കാൻ ഓട്ടോമേറ്റഡ് ടെസ്റ്റ് ജനറേഷൻ സഹായിക്കും. മിക്ക പൊതുവായ ബെഞ്ച്മാർക്കുകളും വിജയത്തെ അളക്കുന്നത് 'ലൈൻ കവറേജ്' (line coverage) അടിസ്ഥാനമാക്കിയാണ്—അതായത് ടെസ്റ്റ് റൺ ചെയ്യുമ്പോൾ കോഡിലെ ഓരോ വരിയും പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് നോക്കുന്നു. എന്നാൽ ഈ അളവ് തെറ്റിദ്ധരിപ്പിക്കാൻ സാധ്യതയുണ്ട്: ഒരു വരി പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും ആ ടെസ്റ്റ് ശരിയായ പെരുമാറ്റം ഉറപ്പാക്കുന്നുണ്ടോ (asserting correct behavior) എന്ന് പരിശോധിക്കണമെന്നില്ല. സോഴ്സ് കോഡിൽ മനഃപൂർവ്വം മാറ്റങ്ങൾ വരുത്തിക്കൊണ്ട് (ഉദാഹരണത്തിന് ഒരു താരതമ്യം മാറ്റുകയോ ഒരു സ്റ്റേറ്റ്‌മെന്റ് നീക്കം ചെയ്യുകയോ ചെയ്യുന്നത് വഴി) നിലവിലുള്ള ടെസ്റ്റുകൾ ആ മാറ്റം കണ്ടെത്തുന്നുണ്ടോ എന്ന് നോക്കുന്ന 'മ്യൂട്ടേഷൻ ടെസ്റ്റിംഗ്' (Mutation testing) ഈ പോരായ്മ പരിഹരിക്കുന്നു. ഒരു മ്യൂട്ടേറ്റ് ചെയ്ത പതിപ്പ് (mutated version) വിജയിക്കുകയാണെങ്കിൽ, ടെസ്റ്റ് സ്യൂട്ട് ഒരു യഥാർത്ഥ പിഴവ് കണ്ടെത്താൻ പരാജയപ്പെട്ടു എന്നാണ് അർത്ഥം.

ടെസ്റ്റുകൾ നിർമ്മിക്കാൻ ഒരു LLM-നെ പ്രോംപ്റ്റ് ചെയ്യുന്ന മൂന്ന് രീതികളെ പരീക്ഷണം താരതമ്യം ചെയ്തു:

  • Bulk prompting – "കൂടുതൽ ടെസ്റ്റുകൾ നൽകുക" എന്ന ഒറ്റ നിർദ്ദേശത്തിലൂടെ 69 ടെസ്റ്റുകൾ നിർമ്മിക്കപ്പെട്ടു. ഇവയെല്ലാം മാറ്റം വരുത്താത്ത കോഡിൽ വിജയിച്ചുവെങ്കിലും, 53 മ്യൂട്ടേഷനുകളിൽ 9 എണ്ണം മാത്രമേ കണ്ടെത്താൻ കഴിഞ്ഞുള്ളൂ.
  • One-test-per-call, untargeted – പിഴവുകളെക്കുറിച്ച് യാതൊരു നിർദ്ദേശവും നൽകാതെ ഓരോ തവണയും ഒരു ടെസ്റ്റ് വീതം നിർമ്മിക്കാൻ മോഡലിനോട് ആവശ്യപ്പെട്ടു; ഇത് വെറും 2 മ്യൂട്ടേഷനുകൾ മാത്രമേ കണ്ടെത്തിയിട്ടുള്ളൂ.
  • Targeted prompting with a mutation-testing gate – ഓരോ തവണയും കണ്ടെത്താൻ കഴിയാത്ത മ്യൂട്ടേഷനുകൾ മോഡലിന് കാണിച്ചുകൊടുക്കുകയും, മ്യൂട്ടേറ്റ് ചെയ്ത കോഡിൽ പരാജയപ്പെടുകയും എന്നാൽ യഥാർത്ഥ കോഡിൽ വിജയിക്കുകയും ചെയ്യുന്ന ഒരു ടെസ്റ്റ് എഴുതാൻ ആവശ്യപ്പെടുകയും ചെയ്തു. ഈ രീതിയിലൂടെ 44 ടെസ്റ്റുകൾ പിഴവുകൾ കണ്ടെത്താൻ സഹായിച്ചു.

44 versus 9 അല്ലെങ്കിൽ 2 എന്ന ഈ വലിയ വ്യത്യാസം കാണിക്കുന്നത്, പിഴവുകളെ കേന്ദ്രീകരിച്ചുള്ള ഒരു ഫീഡ്‌ബാക്ക് ലൂപ്പ് (feedback loop) ഉപയോഗിക്കുന്നത് AI നിർമ്മിക്കുന്ന ടെസ്റ്റുകളുടെ പിഴവുകൾ കണ്ടെത്തുന്ന ശേഷി ഗണ്യമായി വർദ്ധിപ്പിക്കുമെന്നാണ്.

മ്യൂട്ടേഷൻ-ടെസ്റ്റിംഗ് ഗേറ്റ് എങ്ങനെ പ്രവർത്തിക്കുന്നു

  1. മ്യൂട്ടേഷനുകൾ ഉൾപ്പെടുത്തുക (Inject mutations) – ഹാർനസ് (harness) യഥാർത്ഥ സോഴ്സ് കോഡിൽ ചെറിയ മാറ്റങ്ങൾ വരുത്തുന്നു (ഉദാഹരണത്തിന്, ഒരു കണ്ടിഷണൽ റിവേഴ്സ് ചെയ്യുകയോ ഒരു വരി നീക്കം ചെയ്യുകയോ ചെയ്യുക). ഓരോ മ്യൂട്ടേഷനും ഒരു സാധ്യമായ ബഗ്ഗായി കണക്കാക്കുന്നു.
  2. നിലവിലുള്ള ടെസ്റ്റ് സ്യൂട്ട് പ്രവർത്തിപ്പിക്കുക – ടെസ്റ്റ് സ്യൂട്ട് ഇപ്പോഴും വിജയിക്കുകയാണെങ്കിൽ, മ്യൂട്ടേഷൻ കണ്ടെത്താൻ കഴിഞ്ഞ
  • അളവുകോലുകൾ പ്രധാനമാണ് – ലൈൻ കവറേജിൽ (line coverage) മാത്രം വിശ്വസിക്കുന്നത് തെറ്റായ സുരക്ഷിതബോധം നൽകിയേക്കാം. മ്യൂട്ടേഷൻ ടെസ്റ്റിംഗ് (Mutation testing) കൂടുതൽ പെരുമാറ്റാധിഷ്ഠിതമായ (behavior-centric) ഒരു അളവ് നൽകുന്നു, ഇത് ഇവാലുവേഷൻ ലൂപ്പിൽ (evaluation loop) ഉൾപ്പെടുത്തുന്നത് തുടക്കത്തിൽ തന്നെ പോരായ്മകൾ (blind spots) കണ്ടെത്താൻ സഹായിക്കും.
  • ഫീഡ്‌ബാക്ക് ലൂപ്പുകൾ ഔട്ട്‌പുട്ട് മെച്ചപ്പെടുത്തുന്നു – ഗേറ്റിൽ നിന്നുള്ള വലിയ മുന്നേറ്റം സൂചിപ്പിക്കുന്നത്, വൺ-ഷോട്ട് ജനറേഷനേക്കാൾ (one-shot generation) ആവർത്തനപരമായതും തിരുത്തലുകൾ വരുത്തുന്നതുമായ പ്രോംപ്റ്റുകളിൽ (iterative, corrective prompts) നിന്നാണ് LLM-കൾക്ക് കൂടുതൽ ഗുണം ലഭിക്കുന്നത് എന്നാണ്.
  • ടൂളിംഗ് സുതാര്യത അത്യാവശ്യമാണ് – മെഷർമെന്റ് ഹാർനെസ്സിൽ (measurement harness) തന്നെ 11 ബഗുകൾ എഴുത്തുകാരൻ കണ്ടെത്തി, ഇത് തുടക്കത്തിൽ റിപ്പോർട്ട് ചെയ്ത വിജയശതമാനത്തെ അമിതമായി കാണിച്ചിരുന്നു. ഫലങ്ങൾക്കൊപ്പം ഹാർനെസ്സ് കൂടി പ്രസിദ്ധീകരിക്കുന്നത് കമ്മ്യൂണിറ്റിക്ക് ഇവാലുവേഷൻ പൈപ്പ്‌ലൈൻ (evaluation pipeline) പരിശോധിക്കാനും മെച്ചപ്പെടുത്താനും അവസരം നൽകുന്നു.

ഇനി ശ്രദ്ധിക്കേണ്ടവ

  • ഹൈബ്രിഡ് പൈപ്പ്‌ലൈനുകൾ – വ്യാപ്തിക്കായി (breadth) ബൾക്ക് ടെസ്റ്റ് ജനറേഷനും, ആഴത്തിനായി (depth) ലക്ഷ്യമിട്ടുള്ള മ്യൂട്ടേഷൻ അധിഷ്ഠിത പരിഷ്കരണവും (mutation-driven refinement) സംയോജിപ്പിക്കുന്നത് കോഡ് കവർ ചെയ്യുന്നതോടൊപ്പം പെരുമാറ്റം പരിശോധിക്കുന്നതുമായ ഒരു സന്തുലിതമായ സ്യൂട്ട് (balanced suite) നൽകിയേക്കാം.
  • ഓട്ടോമേറ്റഡ് ഹാർനെസ്സ് വെരിഫിക്കേഷൻ – കൂടുതൽ ഗവേഷകർ മ്യൂട്ടേഷൻ ടെസ്റ്റിംഗിനെ ഒരു ബെഞ്ച്മാർക്കായി സ്വീകരിക്കുമ്പോൾ, ഒളിഞ്ഞിരിക്കുന്ന അളവ് തെറ്റുകൾ (measurement errors) ഒഴിവാക്കാൻ അവയുടെ മ്യൂട്ടേഷൻ സെറ്റുകളും എക്സിക്യൂഷൻ പൈപ്പ്‌ലൈനുകളും സ്വയം പരിശോധിക്കുന്ന ടൂളുകൾ നിർണ്ണായകമാകും.
  • ജനറലൈസേഷൻ പഠനങ്ങൾ – ഗേറ്റ് വഴി നിർമ്മിച്ച ടെസ്റ്റുകൾ കാണാത്ത ബഗുകളിലോ പ്രൊഡക്ഷൻ എൻവയോൺമെന്റുകളിലോ (production environments) പ്രയോഗിക്കുമ്പോൾ ഫലപ്രദമാണോ എന്ന് ഭാവിയിലെ പഠനങ്ങൾ പരിശോധിക്കണം, ഇത് പരിധിതമായ ഉപയോഗം (narrowness) എന്ന ആശങ്ക പരിഹരിക്കാൻ സഹായിക്കും.

സംഗ്രഹം

ലളിതമായ ഒരു മ്യൂട്ടേഷൻ-ടെസ്റ്റിംഗ് ഫീഡ്‌ബാക്ക് ലൂപ്പ്, പാസ്സാകുന്ന എന്നാൽ ഉപയോഗശൂന്യമായ ടെസ്റ്റുകൾ എഴുതുന്ന ഒരു LLM-നെ യഥാർത്ഥത്തിൽ പിഴവുകൾ കണ്ടെത്തുന്ന ഒരു ടൂളായി മാറ്റാൻ കഴിയും. ഇത്തരമൊരു ഗേറ്റ് ഇല്ലെങ്കിൽ, AI നിർമ്മിക്കുന്ന ടെസ്റ്റുകൾ വെറും കവറേജ് മാത്രമായി മാറാനും, അവ കണ്ടെത്തേണ്ട ബഗുകളെ തന്നെ നഷ്ടപ്പെടുത്താനും സാധ്യതയുണ്ടെന്ന് പരീക്ഷണം കാണിക്കുന്നു. ഡെവലപ്പർമാർക്കും ഗവേഷകർക്കും ഒരുപോലെ, ടെസ്റ്റ് ജനറേഷനെ പെരുമാറ്റാധിഷ്ഠിത പരിശോധനയുമായി (behavior-focused validation) കൂട്ടിയിണക്കുന്നത് ഇനി ഒരു ഓപ്ഷനല്ല—ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് കോഡ്‌ബേസിന് (codebase) യഥാർത്ഥ സുരക്ഷ നൽകുന്നുണ്ടെന്ന് ഉറപ്പാക്കാനുള്ള ഏക മാർഗ്ഗമാണത്.