വെരിഫിക്കേഷൻ ചിലവാണ് യഥാർത്ഥ AI കോഡിംഗ് ചിലവ്

കോഡിംഗിനായി ഒരു AI മോഡൽ തിരഞ്ഞെടുക്കുമ്പോൾ ഞാൻ ഒരു ചോദ്യം ചോദിക്കാറുണ്ടായിരുന്നു.

ഈ ടാസ്കിന് ഏത് മോഡലാണ് കൂടുതൽ കരുത്തുള്ളത്?

ആ ചോദ്യം ശരിയാണ്. പക്ഷേ ഇപ്പോൾ അത് എന്റെ ആദ്യത്തെ ചോദ്യമല്ല.

ഇതിലും നല്ല ചോദ്യം ഇതാണ്: എനിക്ക് എത്ര വേഗത്തിൽ ഔട്ട്പുട്ട് വെരിഫൈ (പരിശോധിക്കാൻ) കഴിയും?

ഈ ചിന്താഗതി കുറഞ്ഞ ചിലവുള്ള മോഡലുകൾ നിങ്ങൾ ഉപയോഗിക്കുന്ന രീതി മാറ്റും. അവയെ വലിയ മോഡലുകളുടെ ദുർബലമായ പതിപ്പുകളായി കാണരുത്. പകരം, വേഗത്തിൽ പരിശോധിച്ചു തീർക്കാൻ കഴിയുന്ന ജോലികൾ ചെയ്യുന്ന തൊഴിലാളികളായി അവയെ കാണുക.

ചില ജോലികൾ പരിശോധിക്കാൻ ചിലവ് കുറവാണ്, കാരണം നിങ്ങൾക്ക് ഫലങ്ങൾ ഉടൻ തന്നെ കാണാൻ കഴിയും.

• README ക്ലീനപ്പ് • Usage ഉദാഹരണങ്ങൾ • കോഡ് കമന്റുകൾ • Changelog കുറിപ്പുകൾ • ചെറിയ ഫോർമാറ്റിംഗ് സ്ക്രിപ്റ്റുകൾ • Issue ടെംപ്ലേറ്റുകൾ

ഒരു മോഡൽ മോശം README പാരഗ്രാഫ് എഴുതിയാൽ, നിങ്ങൾക്ക് അത് കാണാൻ കഴിയും. ആ മോശം ഭാഗം നിങ്ങൾ നീക്കം ചെയ്യും. ആ തെറ്റ് അലോസരപ്പെടുത്തുന്നതാകാം, പക്ഷേ അതിന് വലിയ ചിലവൊന്നുമില്ല. കുറഞ്ഞ ചിലവുള്ള മോഡലുകൾ ഉപയോഗിക്കാനുള്ള ഏറ്റവും നല്ല മാർഗ്ഗമാണിത്.

അടുത്ത വിഭാഗം ടെസ്റ്റ് ചെയ്യാൻ കഴിയുന്ന ജോലികളാണ് (testable work).

പ്രതീക്ഷിക്കുന്ന രീതിയും (expected behavior) ഒരു ടെസ്റ്റ് സ്യൂട്ടും നിങ്ങൾക്ക് നിർവചിക്കാൻ കഴിയുമെങ്കിൽ, ആദ്യ ഡ്രാഫ്റ്റിനായി കുറഞ്ഞ ചിലവുള്ള ഒരു മോഡൽ ഉപയോഗിക്കുക. നിങ്ങൾ മോഡലിന് വ്യക്തമായ അതിർവരമ്പുകൾ നൽകണം.

ഇങ്ങനെ പറയരുത്: Add tests for this helper.

പകരം ഇങ്ങനെ പറയുക: Add tests for empty input, null input, duplicate values, invalid config, default config, and normal input. Do not change runtime code.

ഇത് ഒരു വെരിഫിക്കേഷൻ ഫ്രെയിമിനുള്ളിൽ ജോലി ചെയ്യാൻ മോഡലിനെ നിർബന്ധിക്കുന്നു.

ചില ജോലികളിൽ ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾ ഉണ്ടാവില്ല, പക്ഷേ വ്യക്തമായ മാനുവൽ പരിശോധനകൾ സാധ്യമാണ്.

• CLI ഔട്ട്പുട്ട് ഫോർമാറ്റിംഗ് • Config ഉദാഹരണങ്ങൾ • Migration dry run കുറിപ്പുകൾ • ചെറിയ ഡാറ്റാ കൺവേർഷൻ സ്ക്രിപ്റ്റുകൾ

ഇവയ്ക്കായി, താഴെ പറയുന്നവ ഉൾപ്പെടുത്താൻ മോഡലിനോട് ആവശ്യപ്പെടുക:

  • കോഡ് എങ്ങനെ റൺ ചെയ്യാം
  • ഏത് ഇൻപുട്ട് ഉപയോഗിക്കണം
  • എന്ത് ഔട്ട്പുട്ട് പ്രതീക്ഷിക്കണം
  • ഏതൊക്കെ edge cases പരിശോധിക്കണം

തന്റെ ജോലി എങ്ങനെ വെരിഫൈ ചെയ്യാം എന്ന് ഒരു മോഡലിന് വിശദീകരിക്കാൻ കഴിയില്ലെങ്കിൽ, ആ കോഡിനെ വിശ്വസിക്കരുത്.

ചെറിയ റീഫാക്ടറുകൾ (refactors) അപകടകരമാണ്. ഒരു diff ചെറുതും വൃത്തിയുള്ളതുമായി തോന്നാം. എന്നാൽ ഒരു ഹിഡൻ പാത്തിൽ (hidden path), ഒരു ഡിഫോൾട്ട് വാല്യൂവിൽ, അല്ലെങ്കിൽ ഒരു പെർമിഷൻ ചെക്കിൽ പെരുമാറ്റം മാറാൻ സാധ്യതയുണ്ട്.

താഴെ പറയുന്നവ ഉൾപ്പെടുന്ന ജോലികളിൽ കൂടുതൽ ശ്രദ്ധ നൽകുക:

  • Fallbacks
  • Defaults
  • Routing
  • Permissions
  • Billing
  • Rate limits
  • Migrations
  • Backwards compatibility

സാധാരണ കോഡ് റിവ്യൂവിൽ ഇത്തരം തെറ്റുകൾ കണ്ടെത്താൻ പ്രയാസമാണ്. അവയ്ക്ക് ആഴത്തിലുള്ള അറിവ് (deep context) ആവശ്യമാണ്.

വെരിഫിക്കേഷൻ ചിലവ് അനുസരിച്ച് നിങ്ങളുടെ ജോലികളെ തരംതിരിക്കുക:

  • കുറഞ്ഞ വെരിഫിക്കേഷൻ ചിലവ്: ഒരു ഡ്രാഫ്റ്റ് തയ്യാറാക്കാൻ കുറഞ്ഞ ചിലവുള്ള മോഡൽ ഉപയോഗിക്കുക.
  • ഇടത്തരം വെരിഫിക്കേഷൻ ചിലവ്: കുറഞ്ഞ ചിലവുള്ള മോഡൽ ഉപയോഗിക്കുക, തുടർന്ന് മനുഷ്യർ തിരുത്തുക.
  • ഉയർന്ന വെരിഫിക്കേഷൻ ചിലവ്: ടെസ്റ്റുകളും മനുഷ്യരുടെ റിവ്യൂവും ഉപയോഗിച്ച് ഒരു ശക്തമായ മോഡൽ ഉപയോഗിക്കുക.

ജോലിയുടെ വലുപ്പമല്ല പ്രധാനം. പരിശോധിക്കാൻ പ്രയാസമാണെങ്കിൽ ഒരു ചെറിയ ജോലിയും ചിലവേറിയതാകും.

AI കോഡിംഗിലെ ചിലവേറിയ ഭാഗം കോഡ് നിർമ്മിക്കുന്നതല്ല (generation). മറിച്ച് അതിലുള്ള വിശ്വാസ്യതയാണ് (trust).

Source: https://dev.to/zephyrelabs369/verification-cost-is-the-real-ai-coding-cost-1354

Optional learning community: https://t.me/GyaanSetuAi