𝗬𝗼𝘂𝗿 𝗔𝗜 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿 𝗜𝘀 𝗮 𝗦𝗶𝗻𝗴𝗹𝗲 𝗣𝗼𝗶𝗻𝘁 𝗼𝗳 𝗙𝗮𝗶𝗹𝘂𝗿𝗲
കഴിഞ്ഞ വെള്ളിയാഴ്ച, യു.എസ്. കൊമേഴ്സ് ഡിപ്പാർട്ട്മെന്റ് Anthropic-ന് ഒരു കത്തയച്ചു. അന്നേ ദിവസം വൈകുന്നേരത്തോടെ Fable 5-ഉം Mythos 5-ഉം അപ്രത്യക്ഷമായി.
അവ നിർത്തലാക്കിയതോ (deprecated) പ്രവർത്തന പരിധി കുറച്ചതോ (throttled) ആയിരുന്നില്ല. അവ വെറുതെ അപ്രത്യക്ഷമായിപ്പോയി.
API കോളുകൾ 404 എററുകൾ കാണിച്ചു. ലൈവ് സെഷനുകൾ സംഭാഷണത്തിനിടയിൽ പരാജയപ്പെട്ടു. ആ മോഡലുകളെ ആശ്രയിച്ചു പ്രവർത്തിച്ചിരുന്ന ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിക്കാതെയായി. ലോഞ്ചിന് മൂന്ന് ദിവസത്തിന് ശേഷമാണ് ഇത് സംഭവിച്ചത്. മുൻകൂട്ടി മുന്നറിയിപ്പുകളോ മാറ്റത്തിനുള്ള സമയമോ (migration window) ഉണ്ടായിരുന്നില്ല.
ആ മോഡലുകൾ പുതിയതായിരുന്നു എന്നതുകൊണ്ട് നമ്മൾ ഭാഗ്യവാന്മാരായിരുന്നു. ആരും അവയെ അത്രത്തോളം ആശ്രയിച്ചിരുന്നില്ല. ആറ് മാസമായി നിങ്ങൾ ദിവസവും ഉപയോഗിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു മോഡലിന് ഇത്തരമൊരു സംഭവം സംഭവിക്കുന്നത് സങ്കൽപ്പിക്കുക.
ഒരു സർക്കാർ കത്ത് കൊണ്ട് നിങ്ങളുടെ പ്രധാന ഡാറ്റാബേസ് നിർത്തലാക്കാൻ കഴിയുമെങ്കിൽ, ഒരു ഫെയിലോവർ (failover) ഇല്ലാതെ നിങ്ങൾ അത് പ്രവർത്തിപ്പിക്കുമോ? ഇല്ല. എന്നിട്ടും, മിക്ക ടീമുകളും AI-യുടെ കാര്യത്തിൽ ഇത് ചെയ്യുന്നുണ്ട്.
പല ടീമുകളും AI-യെ വൈദ്യുതി പോലെയാണ് കാണുന്നത്. സ്വിച്ച് ഇട്ടാൽ വെളിച്ചം കിട്ടുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്നു. അതിന്റെ സ്രോതസ്സിനെക്കുറിച്ചോ വൈദ്യുതി നിലച്ചാൽ എന്ത് സംഭവിക്കുമെന്നോ നിങ്ങൾ ചിന്തിക്കുന്നില്ല. നിങ്ങൾ ഒരു മോഡൽ തിരഞ്ഞെടുക്കുന്നു, ഒരു എൻഡ്പോയിന്റ് (endpoint) ഹാർഡ്കോഡ് ചെയ്യുന്നു, എന്നിട്ട് അത് പുറത്തിറക്കുന്നു.
ഇതൊരു എൻജിനീയറിങ് അല്ല. ഇത് പ്രതീക്ഷകളിൽ മാത്രം അധിഷ്ഠിതമായ ഒരു ആർക്കിടെക്ചർ ആണ്.
താഴെ പറയുന്ന കാരണങ്ങളാൽ മോഡലുകൾ അപ്രത്യക്ഷമായേക്കാം:
- നിയന്ത്രണപരമായ കാരണങ്ങൾ (Regulatory reasons)
- നയപരമായ മാറ്റങ്ങൾ (Policy changes)
- ഭൗമരാഷ്ട്രീയ പ്രശ്നങ്ങൾ (Geopolitical issues)
Anthropic-ന്റെ സാഹചര്യം ഒരു ബഗ്ഗോ ഇൻഫ്രാസ്ട്രക്ചർ പരാജയമോ ആയിരുന്നില്ല. അതൊരു റെഗുലേറ്ററി കിൽ സ്വിച്ച് (regulatory kill switch) ആയിരുന്നു.
നിങ്ങളുടെ മോഡൽ ലെയറിൽ നിങ്ങൾ പ്രതിരോധശേഷി (resilience) കെട്ടിപ്പടുക്കണം. ഈ രീതികൾ ഉപയോഗിക്കുക:
- നിങ്ങളുടെ മോഡൽ കോളുകൾ അബ്സ്ട്രാക്റ്റ് (Abstract) ചെയ്യുക. ഏത് പ്രൊവൈഡറാണ് മറുപടി നൽകുന്നതെന്ന് നിങ്ങളുടെ ആപ്പിനെ ബാധിക്കാത്ത രീതിയിൽ ഒരു ഇന്റർഫേസ് ഉപയോഗിക്കുക.
- ഒന്നിലധികം പ്രൊവൈഡർമാരെ ഉപയോഗിക്കുക. ഒരു പ്രൊവൈഡറെ മാറ്റുന്നത് ഒരു കോൺഫിഗറേഷൻ മാറ്റം മാത്രമായിരിക്കണം, അല്ലാതെ മുഴുവൻ കോഡും വീണ്ടും എഴുതേണ്ടി വരരുത്.
- ഓപ്പൺ-വെയിറ്റ് (open-weight) മോഡലുകൾ ഉപയോഗിക്കുക. നിങ്ങൾ തന്നെ മോഡൽ പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, ആർക്കും അത് റിമോട്ട് ആയി ഓഫ് ചെയ്യാൻ കഴിയില്ല. വൈദ്യുതി നിലയ്ക്കുമ്പോൾ ജനറേറ്റർ പ്രവർത്തിക്കുന്നത് പോലെ ഈ മോഡലുകൾ സഹായിക്കും.
- ഗ്രേസ്ഫുൾ ഡിഗ്രഡേഷൻ (graceful degradation) നടപ്പിലാക്കുക. ഒരു ആപ്ലിക്കേഷൻ പൂർണ്ണമായും തകരാറിലാകുന്നതിനേക്കാൾ നല്ലത് ഒരു ചെറിയതോ പഴയതോ ആയ മോഡൽ ഉപയോഗിക്കുന്നതാണ്.
നിങ്ങളുടെ എറർ റേറ്റുകൾ (error rates) നിരീക്ഷിക്കുക. അവ പെട്ടെന്ന് വർദ്ധിക്കുകയാണെങ്കിൽ, ഉടൻ തന്നെ ട്രാഫിക് നിങ്ങളുടെ ഫാള்பാക്കിലേക്ക് (fallback) തിരിച്ചുവിടുക.
നിങ്ങളുടെ AI-യെ മറ്റ് പ്രധാന പ്രൊഡക്ഷൻ ഡിപെൻഡൻസികളെപ്പോലെ കാണുക. പരാജയങ്ങൾ മുൻകൂട്ടി കണ്ട് അതിനനുസരിച്ച് രൂപകൽപ്പന ചെയ്യുക.
നിങ്ങളുടെ പ്രൊവൈഡർ പരാജയപ്പെട്ടേക്കാം എന്ന് നിങ്ങളുടെ ആർക്കിടെക്ചർ കണക്കിലെടുക്കുന്നുണ്ടോ? ഇല്ലെങ്കിൽ, നിങ്ങൾ അപകടത്തിലാണ്.
നിങ്ങളുടെ സ്റ്റാക്കിൽ മൾട്ടി-പ്രൊവൈഡർ ഫാള்பാക്ക് (multi-provider fallback) ഉൾപ്പെടുത്തിയിട്ടുണ്ടോ? കമന്റുകളിൽ അറിയിക്കുക.
Source: https://dev.to/aws/your-ai-provider-is-a-single-point-of-failure-26i2
Optional learning community: https://t.me/GyaanSetuAi