കാര്യക്ഷമതയുടെ മിഥ്യ: AI-യുടെ അവസാന ഘട്ടം (Last Mile) എന്തിനാണ് ഇത്ര വലിയ വില നൽകുന്നത്?

AI കോഡിംഗിലെ 80/20 നിയമത്തെക്കുറിച്ച് നിങ്ങൾ വായിക്കുകയും അത് ശരിയാണെന്ന് സമ്മതിക്കുകയും ചെയ്യുന്നു.

AI നിങ്ങളുടെ കോഡിന്റെ ആദ്യത്തെ 80% സെക്കൻഡുകൾക്കുള്ളിൽ എഴുതിത്തരുന്നു. അത് പുരോഗതിയായി തോന്നാം. അത് വേഗതയായി അനുഭവപ്പെടാം.

ഇതൊരു കെണിയാണ്.

ജോലിയുടെ അവസാനത്തെ 20% പൂർത്തിയാക്കാൻ നിങ്ങളുടെ സമയത്തിന്റെ 80% ആവശ്യമായി വരുന്നു. ഇവിടെയാണ് പ്രോജക്റ്റുകൾ പരാജയപ്പെടുന്നത്. ഇവിടെയാണ് ഡെവലപ്പർമാർ തളർന്നുപോകുന്നത്.

AI പ്രവർത്തിക്കുന്നത് പ്രോബബിലിറ്റി (probability) അടിസ്ഥാനമാക്കിയാണ്. അടുത്തതായി വരാൻ സാധ്യതയുള്ള വാക്കോ കോഡ് വരിയോ അത് പ്രവചിക്കുന്നു. അതിന് ലോജിക് (logic) മനസ്സിലാകില്ല. നിങ്ങളുടെ സിസ്റ്റം ആർക്കിടെക്ചർ (system architecture) അതിന് അറിയില്ല. തികഞ്ഞ സാഹചര്യങ്ങളിൽ മാത്രം പ്രവർത്തിക്കുന്ന ഒരു "ഹാപ്പി പാത്ത്" (happy path) മാത്രമാണ് അത് നിർമ്മിക്കുന്നത്.

ആ ഹാപ്പി പാത്തിൽ നിന്ന് പുറത്തുവരുമ്പോൾ, നിങ്ങൾ പ്രതിസന്ധികളെ നേരിടേണ്ടി വരും.

ഇതിനെ ഞാൻ 'വെരിഫിക്കേഷൻ ഡെറ്റ്' (Verification Debt) എന്ന് വിളിക്കുന്നു.

ടെക്നിക്കൽ ഡെറ്റ് (Technical debt) ഉണ്ടാകുന്നത് പെട്ടെന്നുള്ള പരിഹാരങ്ങളിൽ നിന്നാണ്. എന്നാൽ വെരിഫിക്കേഷൻ ഡെറ്റ് ഉണ്ടാകുന്നത് കാര്യങ്ങൾ കൃത്യമായി മനസ്സിലാക്കാത്തതുകൊണ്ടാണ്.

നിങ്ങൾ സ്വന്തമായി കോഡ് എഴുതുമ്പോൾ, നിങ്ങളുടെ മനസ്സിൽ ഒരു മാപ്പ് രൂപപ്പെടുന്നു. ഓരോ വരിയും എന്തിനാണ് ഉപയോഗിച്ചിരിക്കുന്നത് എന്ന് നിങ്ങൾക്ക് അറിയാം. എന്നാൽ AI കോഡ് എഴുതുമ്പോൾ, നിങ്ങൾ നിർമ്മിക്കാത്ത ഒരു ഉൽപ്പന്നമാണ് നിങ്ങൾക്ക് ലഭിക്കുന്നത്. അതിന്റെ ലോജിക് നിങ്ങളുടെ നിയന്ത്രണത്തിലല്ല, ഫലം മാത്രമാണ് നിങ്ങളുടെ കൈവശം.

കോഡ് നിങ്ങൾക്ക് മനസ്സിലാകുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് അത് ഡീബഗ് (debug) ചെയ്യാൻ കഴിയില്ല. AI ഒരു സെക്കൻഡിൽ ചെയ്ത ഒരു തെറ്റ് തിരുത്താൻ നിങ്ങൾ മണിക്കൂറുകൾ ചെലവഴിക്കേണ്ടി വരും.

കോഡ് വേഗത്തിൽ തയ്യാറാകുന്നത് ജോലി പൂർത്തിയായെന്ന ഒരു മിഥ്യാധാരണ ഉണ്ടാക്കുന്നു. നിങ്ങൾ ഏകദേശം തീരാറായി എന്ന് നിങ്ങൾ കരുതും. എന്നാൽ പിന്നീട് എഡ്ജ് കേസുകൾ (edge cases) വരുന്നു. ഇന്റഗ്രേഷൻ (integration) പരാജയപ്പെടുന്നു. സെക്യൂരിറ്റി പിഴവുകൾ (security flaws) പ്രത്യക്ഷപ്പെടുന്നു.

അവസാനത്തെ 20% എന്നത് വെറും "ഫിനിഷിംഗ് ടച്ചുകൾ" മാത്രമല്ല. അത് ഗുണനിലവാരത്തിന്റെ കാതലാണ്. ടെസ്റ്റിംഗ്, ഡീബഗ്ഗിംഗ്, എഡ്ജ് കേസ് കൈകാര്യം ചെയ്യൽ എന്നിവയെല്ലാം ഇതിൽ ഉൾപ്പെടുന്നു.

ഇത് എങ്ങനെ പരിഹരിക്കാം?

AI നൽകുന്ന ഔട്ട്പുട്ടിനെ ഒരു ഫൈനൽ പ്രോഡക്റ്റ് ആയി കാണുന്നത് നിർത്തുക. അതിനെ വിശ്വസിക്കാൻ കൊള്ളാത്ത ഡാറ്റയായി (untrusted data) കാണുക.

  • ആദ്യം ടെസ്റ്റുകൾ എഴുതുക. ടെസ്റ്റുകൾ തയ്യാറാക്കുന്നതിന് മുമ്പ് ഒരിക്കലും ലോജിക് നിർമ്മിക്കരുത്. AI ഉത്തരം നൽകുന്നതിന് മുമ്പ് പരാജയം എങ്ങനെയായിരിക്കണം എന്ന് നിർവചിക്കുക.
  • ഭാഗങ്ങളായി പരിശോധിക്കുക (Validate in segments). പിഴവുകൾ കണ്ടെത്താൻ മുഴുവൻ സിസ്റ്റവും ഇന്റഗ്രേറ്റ് ചെയ്യുന്നത് വരെ കാത്തുനിൽക്കരുത്. ഓരോ ചെറിയ ബ്ലോക്കും പ്രത്യേകം പരിശോധിക്കുക.
  • പാച്ച് ചെയ്യുന്നതിന് പകരം ഒഴിവാക്കുക. ഒരു AI ഫംഗ്ഷൻ ടെസ്റ്റിൽ പരാജയപ്പെട്ടാൽ, അത് വരിവരിയായി തിരുത്താൻ ശ്രമിക്കരുത്. അത് ഡിലീറ്റ് ചെയ്ത ശേഷം മറ്റൊരു പ്രോംപ്റ്റ് (prompt) ഉപയോഗിച്ച് ശ്രമിക്കുക. AI തെറ്റുകൾ പാച്ച് ചെയ്യുന്നത് (patching) പലപ്പോഴും കൂടുതൽ തെറ്റുകൾക്ക് കാരണമാകും.

80/20 നിയമം ഒരു മുന്നറിയിപ്പാണ്. AI നിങ്ങളുടെ വേഗത വർദ്ധിപ്പിക്കുന്നു, എന്നാൽ അത് പരിശോധിക്കേണ്ട നിങ്ങളുടെ ഉത്തരവാദിത്തവും വർദ്ധിപ്പിക്കുന്നു.

AI-യുടെ തെറ്റുകൾ തിരുത്താൻ മാത്രം നിങ്ങൾ സമയം ചെലവഴിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് കാര്യക്ഷമത ലഭിച്ചിട്ടില്ല. നിങ്ങൾ ഒരു തരം ജോലിക്ക് പകരം മറ്റൊരു തരം ജോലി മാത്രമാണ് സ്വീകരിച്ചിട്ടുള്ളത്.

കോഡ് ശരിക്കും പ്രവർത്തിക്കുന്നുണ്ടെന്ന് നിങ്ങൾ തെളിയിക്കുന്നത് ഈ അവസാന ഘട്ടത്തിലാണ്. കാണാൻ മനോഹരമായ ഒരു കള്ളത്തിൽ നിങ്ങൾ വീണില്ലെന്ന് തെളിയിക്കുന്നതും ഇവിടെയാണ്.

Source: https://dev.to/amrree/the-illusion-of-efficiency-why-ais-last-mile-costs-everything-a7g

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