𝗪𝗵𝘆 𝗜 𝗦𝘁𝗼𝗽𝗽𝗲𝗱 𝗥𝗲𝗹𝘆𝗶𝗻𝗴 𝗼𝗻 𝗮 𝗦𝗶𝗻𝗴𝗹𝗲 𝗔𝗜 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿
ഒരു കമ്മ്യൂണിറ്റി ഫോറത്തിനായി ഞാൻ ഒരു റിയൽ-ടൈം ചാറ്റ്ബോട്ട് നിർമ്മിച്ചു. ഒരു API മാത്രം ഉപയോഗിച്ചാൽ മതിയാകുമെന്ന് ഞാൻ കരുതി. പക്ഷേ ഞാൻ തെറ്റിപ്പോയി.
മൂന്ന് ആഴ്ചകൾക്ക് ശേഷം, തിരക്കുള്ള സമയങ്ങളിൽ എനിക്ക് ഒരു 5xx error നേരിടേണ്ടി വന്നു. എന്റെ ചാറ്റ്ബോട്ട് പ്രവർത്തനരഹിതമായി. ഉപയോക്താക്കൾ നിരാശരായി. പ്രൊഡക്ഷൻ ആപ്പുകൾക്കായി ഒരു പ്രൊവൈഡറെ മാത്രം വിശ്വസിക്കാൻ കഴിയില്ലെന്ന് ഞാൻ തിരിച്ചറിഞ്ഞു.
ഞാൻ GPT-4 ആണ് ഉപയോഗിച്ചത്. അത് നന്നായി പ്രവർത്തിച്ചിരുന്നു, എന്നാൽ പെട്ടെന്ന് പ്രശ്നങ്ങൾ തുടങ്ങി. റേറ്റ് ലിമിറ്റുകൾ (rate limits), ടൈമൗട്ടുകൾ (timeouts), പൂർണ്ണമായ തകരാറുകൾ (outages) എന്നിവ എനിക്ക് നേരിടേണ്ടി വന്നു. ഉയർന്ന ടയറുകൾക്കായി പണം നൽകുന്നത് പ്രശ്നത്തിന് പരിഹാരം കാണുന്നതിന് പകരം അതിന്റെ ലക്ഷണങ്ങളെ മാത്രം ചികിത്സിക്കുന്നത് പോലെ തോന്നി.
ഞാൻ മറ്റ് പ്രൊവൈഡർമാരെ പരീക്ഷിച്ചു, പക്ഷേ അവയ്ക്കെല്ലാം വ്യത്യസ്തമായ ഫോർമാറ്റുകളും ഓതന്റിക്കേഷൻ (auth) രീതികളുമാണ് ഉണ്ടായിരുന്നത്. എന്റെ കോഡ് switch-case സ്റ്റേറ്റ്മെന്റുകളുടെ ഒരു വലിയ കുഴപ്പമായി മാറി. എനിക്ക് താഴെ പറയുന്ന കാര്യങ്ങൾ ചെയ്യാൻ കഴിയുന്ന ഒരു സിസ്റ്റം ആവശ്യമായിരുന്നു:
- പ്രൊവൈഡർമാരിലെ വ്യത്യാസങ്ങൾ മറച്ചുവെക്കാൻ.
- പരാജയപ്പെടുമ്പോൾ ഒരു ബാക്കപ്പ് പ്രൊവൈഡറിലേക്ക് മാറാൻ.
- മറുപടികൾ കാഷെ (cache) ചെയ്യാൻ.
- വെണ്ടർ ലോക്ക്-ഇൻ (vendor lock-in) ഒഴിവാക്കാൻ.
തേർഡ് പാർട്ടി ലൈബ്രറികൾ വളരെ സങ്കീർണ്ണവും എളുപ്പത്തിൽ തകരാറിലാകുന്നതുമായതിനാൽ ഞാൻ അവ ഒഴിവാക്കി. പകരം, ഞാൻ ഒരു ലളിതമായ റൂട്ടർ (router) നിർമ്മിച്ചു.
ആദ്യം, എല്ലാ പ്രൊവൈഡർമാർക്കും വേണ്ടി ഞാൻ ഒരു കോമൺ ഇന്റർഫേസ് (common interface) നിർവചിച്ചു. ഓരോ പ്രൊവൈഡറും ഒരു generate മെത്തേഡും ഒരു ഹെൽത്ത് ചെക്കും (health check) നടപ്പിലാക്കുന്നു.
അടുത്തതായി, ഞാൻ ഒരു റൂട്ടർ ക്ലാസ് (router class) നിർമ്മിച്ചു. ഇത് ഒരു പ്രത്യേക ക്രമത്തിൽ പ്രൊവൈഡർമാരെ പരീക്ഷിക്കുന്നു. ഇത് exponential backoff-ഉം ഒരു ലളിതമായ കാഷെയും ഉപയോഗിക്കുന്നു. ആദ്യത്തെ പ്രൊവൈഡർ പരാജയപ്പെട്ടാൽ, സിസ്റ്റം കാത്തുനിൽക്കുകയും അടുത്തതിനെ പരീക്ഷിക്കുകയും ചെയ്യുന്നു.
മൂന്ന് വ്യത്യസ്ത തകരാറുകൾ ഉണ്ടായ സമയങ്ങളിൽ ഈ സിസ്റ്റം എന്റെ വാരാന്ത്യങ്ങൾ രക്ഷിച്ചു. ഒരു പ്രധാന പ്രൊവൈഡർ പ്രവർത്തനരഹിതമായാലും ഇത് എന്റെ ആപ്പ് പ്രവർത്തിപ്പിക്കാൻ സഹായിക്കുന്നു.
നിങ്ങൾ ഇത് നിർമ്മിക്കുകയാണെങ്കിൽ, ഈ കാര്യങ്ങൾ ശ്രദ്ധിക്കുക:
- പ്രൊഡക്ഷനിൽ ലോക്കൽ ഡിക്ഷണറിക്ക് പകരം കാഷെ ചെയ്യാൻ Redis ഉപയോഗിക്കുക.
- ഹെൽത്ത് ചെക്കുകൾ വിജയം ഉറപ്പുനൽകുന്നില്ല. ഒരു പ്രൊവൈഡർ ചെക്ക് പാസാകുകയും എന്നാൽ യഥാർത്ഥ റിക്വസ്റ്റുകളിൽ പരാജയപ്പെടുകയും ചെയ്തേക്കാം.
- റേറ്റ് ലിമിറ്റുകൾ ശരിയായി കൈകാര്യം ചെയ്യാൻ Retry-After ഹെഡറുകൾ പാഴ്സ് (parse) ചെയ്യുക.
- ചിലവുകൾ ട്രാക്ക് ചെയ്യാൻ ടോക്കൺ ഉപയോഗത്തിനായുള്ള ലോഗിംഗ് (logging) ചേർക്കുക.
- ഉയർന്ന പ്രകടനം ലഭിക്കാൻ asyncio ഉപയോഗിക്കുക.
നിങ്ങളുടെ പ്രോജക്റ്റ് ചെറുതാണെങ്കിൽ, അനാവശ്യമായി സങ്കീർണ്ണമാക്കരുത് (over-engineer). നിങ്ങൾക്ക് സ്ട്രീമിംഗ് (streaming) ആവശ്യമുണ്ടെങ്കിൽ, ഈ രീതി ലേറ്റൻസി (latency) വർദ്ധിപ്പിക്കും. നിങ്ങളുടെ ആവശ്യാനുസരണം ശരിയായ ടൂൾ തിരഞ്ഞെടുക്കുക.
പ്രൊവൈഡർമാരുടെ വിശ്വാസ്യത നിങ്ങൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു? നിങ്ങൾ ഒരു പ്രൊവൈഡറിൽ മാത്രം ഒതുങ്ങിക്കൂടുകയാണോ അതോ ഒരു ഫോളബാക്ക് ലെയർ (fallback layer) നിർമ്മിക്കുകയാണോ?
Optional learning community: https://t.me/GyaanSetuAi