നിങ്ങൾ പ്രൊഡക്ഷനിലേക്ക് എത്തിക്കുന്ന ഓരോ വരി കോഡും ഒരു അൽഗോരിതത്തെ എങ്ങനെ പെരുമാറണമെന്ന് പഠിപ്പിക്കുന്നു. ആ പെരുമാറ്റം പുറത്തേക്ക് വ്യാപിക്കുന്നു. അത് ആരുടെ ലോൺ അംഗീകരിക്കണം, ഏത് മെഡിക്കൽ സ്കാനിന് മുൻഗണന നൽകണം, ഉപയോക്താവിന്റെ ഫീഡിൽ എന്ത് ഉള്ളടക്കം നിറയ്ക്കണം എന്നിവ തീരുമാനിക്കുന്നു. ഒരു ഡെവലപ്പർ എന്ന നിലയിൽ, നിങ്ങൾ വെറും ഫീച്ചറുകൾ കൂട്ടിച്ചേർക്കുകയല്ല ചെയ്യുന്നത്. ഈ സംവിധാനങ്ങൾ മനുഷ്യജീവിതവുമായി എങ്ങനെ ഇടപഴകുന്നു എന്ന് നിങ്ങൾ രൂപപ്പെടുത്തുകയാണ്.
ആ ഉത്തരവാദിത്തം കേവലം പ്രവർത്തനക്ഷമമായ സോഫ്റ്റ്വെയർ വിതരണം ചെയ്യുന്നതിനേക്കാൾ ആഴത്തിലുള്ളതാണ്. സാങ്കേതികവിദ്യ നിർമ്മിക്കുന്നത് മാത്രം പോരാ. അത് ഉത്തരവാദിത്തത്തോടെ നിർമ്മിക്കണം. എത്തിക്കൽ അൽഗോരിതങ്ങൾ ബെഞ്ച്മാർക്കുകളിൽ മികച്ച പ്രകടനം കാഴ്ചവെക്കുന്നതിനേക്കാൾ ഉപരിയായി പ്രവർത്തിക്കുന്നു. അവ സജീവമായി ദോഷങ്ങൾ തടയുകയും കാലക്രമേണ അവ ഉപയോഗിക്കുന്ന ആളുകളിൽ നിന്ന് വിശ്വാസം നേടിയെടുക്കുകയും ചെയ്യുന്നു. ആ വിശ്വാസം വളരെ ദുർബലമാണ്. ഒരു ട്രെയിനിംഗ് പൈപ്പ്ലൈനിലെ അശ്രദ്ധമായ തിരഞ്ഞെടുപ്പോ അല്ലെങ്കിൽ അവ്യക്തമായ ഒരു പ്രൈവസി സെറ്റിംഗോ അതിനെ തകർക്കാം. നിങ്ങളുടെ കോഡ് സമൂഹത്തെ രൂപപ്പെടുത്തുന്നു. നിങ്ങളുടെ തിരഞ്ഞെടുപ്പുകൾക്ക് മൂല്യമുണ്ടായിരിക്കണം.
നിങ്ങൾ നിർമ്മിക്കുന്നതിന്റെ ഭാരം
ഡെവലപ്പർമാർ AI-യുടെ ഭാവി നിർമ്മിക്കുന്നു. ഈ സംവിധാനങ്ങൾ എങ്ങനെ പെരുമാറണമെന്ന് നിങ്ങൾ തീരുമാനിക്കുന്നു. ഡീബഗ്ഗിംഗ് മോഡിൽ മുഴുകിയിരിക്കുമ്പോഴോ, loss curves-ഉം latency metrics-ഉം നോക്കിക്കൊണ്ടിരിക്കുമ്പോഴോ ആ ശക്തി മറന്നുപോകാൻ എളുപ്പമാണ്. എന്നാൽ നിങ്ങൾ ട്രെയിൻ ചെയ്യുന്ന മോഡലുകൾ ഇൻഫ്രാസ്ട്രക്ചർ ആയി മാറുന്നു. അവ നിയമന തീരുമാനങ്ങൾ, ക്രെഡിറ്റ് സ്കോറിംഗ്, ക്രിമിനൽ റിസ്ക് വിലയിരുത്തലുകൾ, വിദ്യാഭ്യാസപരമായ സ്ഥാനപ്പെടുത്തലുകൾ എന്നിവയെ സ്വാധീനിക്കുന്നു.
ഇതിനെ സ്ട്രക്ചറൽ എഞ്ചിനീയറിംഗുമായി താരതമ്യം ചെയ്യാം. ഒരു പാലം നിർമ്മിക്കുന്നയാൾക്ക് സാധനങ്ങൾ ലഭ്യമായിരുന്നുവെന്നും കണക്കുകൾ ശരിയായിരുന്നുവെന്നും മാത്രം പറഞ്ഞാൽ പോരാ. യഥാർത്ഥ സാഹചര്യങ്ങളിലെ സമ്മർദ്ദത്തിൽ ആ രൂപകൽപ്പന നിലനിൽക്കുമോ എന്നും അതിലൂടെ നടന്നുപോകുന്ന ആളുകൾ സുരക്ഷിതരാണോ എന്നും അവർ ചോദിക്കണം. ഇതേ മാനദണ്ഡം ഇവിടെയും ബാധകമാണ്. നിയന്ത്രിതമായ പരീക്ഷണങ്ങളിൽ കൃത്യമായി പ്രവർത്തിക്കുന്ന ഒരു അൽഗോരിതം യഥാർത്ഥ മനുഷ്യജീവിതവുമായി സമ്പർക്കത്തിൽ വരുമ്പോൾ വലിയ നാശനഷ്ടങ്ങൾ ഉണ്ടാക്കിയേക്കാം. ആ നാശനഷ്ടങ്ങൾ തടയുന്നത് ജോലിയുടെ ഭാഗമാണ്. അത് പിന്നീട് ചിന്തിക്കേണ്ട ഒന്നല്ല. അത് ഒരു ലീഗൽ ടീമിന്റെ പ്രശ്നവുമല്ല. മറിച്ച്, ആ തൊഴിലിന്റെ അടിസ്ഥാനപരമായ ഭാഗമാണ്.
ഡാറ്റാ പ്രൈവസിയും സുരക്ഷയും
നിങ്ങൾ മോഡലിന് നൽകുന്ന ഡാറ്റയിൽ നിന്ന് തുടങ്ങുക. ഡാറ്റാ പ്രൈവസിയും സുരക്ഷയും എന്നത് ഉൽപ്പന്നം വിതരണം ചെയ്ത ശേഷം പൂർത്തിയാക്കേണ്ട വെറും കംപ്ലയൻസ് ചെക്ക്ബോക്സുകളല്ല. അവ തുടക്കത്തിൽ തന്നെ നിങ്ങൾ എടുക്കേണ്ട ആർക്കിടെക്ചറൽ തീരുമാനങ്ങളാണ്.
ഡാറ്റ ശേഖരണ വേളയിൽ കഠിനമായ ചോദ്യങ്ങൾ ചോദിക്കുക. മോഡൽ മെച്ചപ്പെടുത്താൻ യഥാർത്ഥ ഉപയോക്താക്കളുടെ സംഭാഷണങ്ങൾ സൂക്ഷിക്കേണ്ടതുണ്ടോ, അതോ ഐഡന്റിഫയറുകൾ നീക്കം ചെയ്ത് അഗ്രഗേറ്റഡ് പാറ്റേണുകൾ (aggregated patterns) ഉപയോഗിക്കാമോ? സെൻസിറ്റീവ് ആയ ഇൻപുട്ടുകൾ നിങ്ങൾ എത്ര കാലം സൂക്ഷിക്കുന്നു? ഡിലീഷൻ റിക്വസ്റ്റുകൾ (deletion requests) പാലിക്കാനുള്ള ഒരു മാർഗ്ഗം നിങ്ങൾ നിർമ്മിച്ചിട്ടുണ്ടോ, അതോ ആരും നിരീക്ഷിക്കാത്ത ഒരു ബക്കറ്റിൽ ഡാറ്റ ഇരിക്കുകയാണോ?
AI സംവിധാനങ്ങളുടെ സുരക്ഷയ്ക്ക് അതിന്റേതായ പ്രത്യേക റിസ്ക്കുകളുണ്ട്. Prompt injection attacks മോഡലിനെ അതിന്റെ സുരക്ഷാ സംവിധാനങ്ങൾ അവഗണിക്കാൻ പ്രേരിപ്പിച്ചേക്കാം. ട്രെയിനിംഗ് സമയത്ത് മോഡൽ overfit ആണെങ്കിൽ training data extraction attacks വഴി സ്വകാര്യ വിവരങ്ങൾ പുറത്തുകൊണ്ടുവരാൻ സാധിക്കും. ഒരു ശത്രുവിനെപ്പോലെ ചിന്തിക്കാൻ നിങ്ങൾ ശീലിക്കണം. ഡാറ്റാ റെസ്റ്റ് (at rest) ആയും ട്രാൻസിറ്റിലും (in transit) എൻക്രിപ്റ്റ് ചെയ്യുക. ട്രെയിനിംഗ് ഡാറ്റാസെറ്റുകളിലേക്കുള്ള പ്രവേശനം നിയന്ത്രിക്കുക. പ്രൊഡക്ഷൻ മോഡലുകൾ ആരാണ് ക്വറി ചെയ്യുന്നത് എന്ന് ഓഡിറ്റ് ചെയ്യുകയും അവർ ചോദിക്കുന്നത് ലോഗ് ചെയ്യുകയും ചെയ്യുക. ഇവ സാധാരണ ജോലികളാണ്, എന്നാൽ ഉപയോക്താവിന്റെ വിശ്വാസവും ഡാറ്റാ ബ്രീച്ചിനെക്കുറിച്ചുള്ള വാർത്തകളും തമ്മിലുള്ള അതിർവരമ്പാണ് ഇവ.
ട്രെയിനിംഗ് സെറ്റുകളിലെ ബയാസ് പ്രതിരോധം
നിങ്ങൾ കാണിച്ചുകൊടുക്കുന്ന പാറ്റേണുകളാണ് മോഡലുകൾ പഠിക്കുന്നത്. ട്രെയിനിംഗ് ഡാറ്റ ചരിത്രപരമായ അസമത്വങ്ങളെ പ്രതിഫലിപ്പിക്കുന്നുണ്ടെങ്കിൽ, ആ അസമത്വത്തെ ഭയാനകമായ വേഗതയിലും വ്യാപ്തിയിലും മോഡൽ ഓട്ടോമേറ്റ് ചെയ്യും. ആദ്യത്തെ ഡാറ്റാ ശേഖരണം മുതൽ അവസാന വിന്യാസം (deployment) വരെ ട്രെയിനിംഗ് സെറ്റുകളിലെ ബയാസ് പ്രതിരോധത്തിന് ജാഗ്രത ആവശ്യമാണ്.
ഇതിനർത്ഥം മൊത്തത്തിലുള്ള കൃത്യത (aggregate accuracy) മാത്രം നോക്കിയാൽ പോരാ എന്നാണ്. ഒരു മെഡിക്കൽ ഡയഗ്നോസ്റ്റിക് മോഡൽ മൊത്തത്തിൽ നല്ല സ്കോർ നേടുന്നുണ്ടാകാം, എന്നാൽ കറുത്ത നിറമുള്ള ചർമ്മത്തിന്റെ ചിത്രങ്ങളിൽ അത് നിരന്തരം പരാജയപ്പെട്ടേക്കാം. ട്രെയിനിംഗ് ഡാറ്റ പതിറ്റാണ്ടുകളായുള്ള ഏകതാനമായ പ്രൊമോഷൻ ചരിത്രങ്ങളിൽ നിന്നാണെങ്കിൽ ഒരു ഹയറിംഗ് ടൂൾ പഴയ പക്ഷപാതങ്ങൾ ആവർത്തിച്ചേക്കാം. ഡെമോഗ്രാഫിക് റെപ്രസന്റേഷൻ നിങ്ങൾ ഓഡിറ്റ് ചെയ്യണം. മുഴുവൻ ജനസംഖ്യയെയും മാത്രമല്ല, വിവിധ ഉപവിഭാഗങ്ങളിലെ (subgroups) എറർ റേറ്റുകളും നിങ്ങൾ പരിശോധിക്കണം. സബ്ജക്റ്റീവ് ലേബലുകൾ ഒരു കാഴ്ചപ്പാടിൽ നിന്ന് മാത്രം വരാതിരിക്കാൻ വൈവിധ്യമാർന്ന അനോട്ടേഷൻ ടീമുകളെ ഉൾപ്പെടുത്തുക.
ബയാസ് പ്രതിരോധം എന്നത് കോൺടെക്സ്റ്റിനെ (context) കുറിച്ചുള്ളത് കൂടിയാണ്. വടക്കേ അമേരിക്കൻ സ്രോതസ്സുകളിൽ നിന്നുള്ള ഇംഗ്ലീഷ് ടെക്സ്റ്റിൽ ട്രെയിൻ ചെയ്ത ഒരു മോഡലിന് മുംബൈയിലെയോ लागോസിലെയോ ശൈലികൾ കൈകാര്യം ചെയ്യാൻ ബുദ്ധിമുട്ടായിരിക്കും. അത് ആർക്കിടെക്ചറിലെ പോരായ്മയല്ല, മറിച്ച് ഡാറ്റാസെറ്റിലെ പോരായ്മയാണ്. സ്രോതസ്സുകൾ വിപുലീകരിച്ചും, കുറഞ്ഞ പ്രാതിനിധ്യമുള്ള ഡാറ്റയ്ക്ക് കൂടുതൽ പ്രാധാന്യം നൽകിയും (weighting underrepresented data), റിലീസ് ചെയ്യുന്നതിന് മുമ്പ് adversarial tests നടത്തിയും ഇത് പരിഹരിക്കാം. ഫെയർനെസ്സിനെ (fairness) നിങ്ങൾ ട്രാക്ക് ചെയ്യുകയും പരിഹരിക്കുകയും ചെയ്യേണ്ട ഒരു ബഗ്ഗായി കാണുക.
തീരുമാനങ്ങൾ എടുക്കുന്നതിലെ സുതാര്യത
തങ്ങൾ സംസാരിക്കുന്നത് ഒരു മെഷീനോടാണെന്ന് അറിയാൻ ആളുകൾക്ക് അവകാശമുണ്ട്, കൂടാതെ ആ മെഷീൻ അവരെക്കുറിച്ച് ഒരു തീരുമാനമെടുക്കുമ്പോൾ അതിന്റെ വിശദീകരണം നൽകാനും അവർക്ക് അവകാശമുണ്ട്. തീരുമാനങ്ങൾ എടുക്കുന്നതിലെ സുതാര്യത എന്നാൽ, ഉള്ളിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് ഉപയോക്താക്കളെ അറിയിക്കാനുള്ള മതിയായ ബഹുമാനം അവർക്ക് നൽകുക എന്നാണ് അർത്ഥമാക്കുന്നത്.
ഡെവലപ്പർമാരെ സംബന്ധിച്ചിടത്തോളം, ഇത് പ്രായോഗികമായ ഉൽപ്പന്ന തിരഞ്ഞെടുപ്പുകളായി മാറുന്നു. ഒരു AI വായ്പ നിരസിക്കുകയാണെങ്കിൽ, അപേക്ഷകൻ ആ നിരസിക്കലിന് പിന്നിലെ പ്രധാന കാരണങ്ങൾ കാണണം, അല്ലാതെ ഒരു പൊതുവായ നിരസിക്കൽ സന്ദേശമല്ല. ഒരു കണ്ടന്റ് മോഡറേഷൻ സിസ്റ്റം ഒരു പോസ്റ്റ് നീക്കം ചെയ്യുകയാണെങ്കിൽ, ഏത് നിയമമാണ് ലംഘിക്കപ്പെട്ടതെന്ന് ഉപയോക്താവിന് മനസ്സിലാകണം. ഉപയോഗിക്കേണ്ട രീതികൾ (intended use cases), അറിയപ്പെടുന്ന പരിമിതികൾ (known limitations), വിവിധ വിഭാഗങ്ങളിലെ പ്രകടനം (performance across different populations) എന്നിവ വ്യക്തമാക്കുന്ന മോഡൽ കാർഡുകൾ പ്രസിദ്ധീകരിക്കുക. ഉയർന്ന പ്രാധാന്യമുള്ള തീരുമാനങ്ങൾ എങ്ങനെ എത്തിയെന്ന് ഓഡിറ്റർമാർക്ക് പരിശോധിക്കാൻ കഴിയുന്ന രീതിയിൽ ലോഗിംഗ് സംവിധാനം നിർമ്മിക്കുക.
സുതാര്യത എന്നത് വെറും പ്രോബബിലിറ്റി വെയ്റ്റുകൾ (probability weights) സ്ക്രീനിൽ പ്രദർശിപ്പിക്കലല്ല. സത്യസന്ധമായി ആശയവിനിമയം നടത്തുന്ന ഇന്റർഫേസുകൾ രൂപകൽപ്പന ചെയ്യുന്നതിനെക്കുറിച്ചാണ് അത്. ഒരു മറുപടി AI നിർമ്മിതമാണോ എന്ന് ഉപയോക്താക്കൾ ഊഹിക്കേണ്ടി വരരുത്. സിസ്റ്റത്തിന് എന്തെങ്കിലും തെറ്റ് സംഭവിക്കുമ്പോൾ അവർക്ക് ഒരു 'ബ്ലാക്ക് ബോക്സിനോട്' (black box) പോരാടേണ്ടി വരരുത്.
മോഡൽ ഔട്ട്പുട്ടുകൾക്കുള്ള ഉത്തരവാദിത്തം
ചോദ്യം ചെയ്യാൻ കഴിയാത്ത ഒരു മോഡലിനെ വിശ്വസിക്കാൻ കഴിയില്ല. മോഡൽ ഔട്ട്പുട്ടുകൾക്കുള്ള ഉത്തരവാദിത്തം എന്നാൽ സിസ്റ്റം പരാജയപ്പെടുമ്പോൾ എവിടെയോ ഒരാൾക്ക് അതിന്റെ ഉത്തരവാദിത്തം ഏറ്റെടുക്കാൻ കഴിയണം എന്നാണ് അർത്ഥമാക്കുന്നത്.
നിർണ്ണായകമായ തീരുമാനങ്ങളിൽ മനുഷ്യന്റെ മേൽനോട്ടം (human oversight) ഉറപ്പാക്കുക. ഒരു അൽഗോരിതം ഒരു ഇടപാടിനെ തട്ടിപ്പ് (fraudulent) എന്ന് അടയാളപ്പെടുത്തിയേക്കാം, എന്നാൽ അത്തരം നടപടികൾ നടപ്പിലാക്കുന്നതിന് മുമ്പ് ഒരു വ്യക്തി അത് പരിശോധിക്കണം. ഒരു AI നിയമപരമായ ഭാഷ തയ്യാറാക്കിയേക്കാം, എന്നാൽ ഒരു യോഗ്യതയുള്ള പ്രൊഫഷണൽ അത് അംഗീകരിക്കണം. ഉപയോക്താക്കൾക്ക് തെറ്റുകൾ റിപ്പോർട്ട് ചെയ്യാനും തിരുത്തൽ നിരക്കുകൾ (correction rates) അളക്കാനും കഴിയുന്ന രീതിയിൽ ഫീഡ്ബാക്ക് ലൂപ്പുകൾ നിർമ്മിക്കുക. എപ്പോഴാണോ അതിനായി വ്യക്തമായ എസ്കലേഷൻ പാതകൾ സ്ഥാപിക്കുക