મેં એક જ AI પ્રોવાઈડર પર નિર્ભર રહેવાનું કેમ બંધ કર્યું
મેં એક કોમ્યુનિટી ફોરમ માટે રિયલ-ટાઇમ ચેટબોટ બનાવ્યો હતો. મને લાગ્યું કે માત્ર એક API નો ઉપયોગ કરવો પૂરતો હશે. પણ હું ખોટો હતો.
ત્રણ અઠવાડિયા પછી, પીક અવર્સ દરમિયાન મને 5xx એરર આવી. મારો ચેટબોટ બંધ થઈ ગયો. વપરાશકર્તાઓ હતાશ થઈ ગયા. મને સમજાયું કે પ્રોડક્શન એપ્સ માટે હું માત્ર એક જ પ્રોવાઈડર પર વિશ્વાસ કરી શકતો નથી.
મેં GPT-4 નો ઉપયોગ કર્યો હતો. જ્યાં સુધી સમસ્યા ન આવી ત્યાં સુધી તે સારું કામ કરતું હતું. મને રેટ લિમિટ્સ, ટાઈમઆઉટ્સ અને સંપૂર્ણ આઉટેજનો સામનો કરવો પડ્યો. ઉચ્ચ ટાયર્સ (higher tiers) માટે ચૂકવણી કરવી એ સમસ્યાને ઉકેલવાને બદલે માત્ર તેના લક્ષણોને સુધારવા જેવું લાગતું હતું.
મેં અન્ય પ્રોવાઈડર્સ અજમાવ્યા, પરંતુ તે બધાના ફોર્મેટ અને ઓથ (auth) પદ્ધતિઓ અલગ-અલગ હતી. મારો કોડ switch-case સ્ટેટમેન્ટ્સનું એક જટિલ માળખું બની ગયો. મને એક એવી સિસ્ટમની જરૂર હતી જે:
- પ્રોવાઈડર વચ્ચેના તફાવતોને છુપાવી શકે.
- નિષ્ફળતાના કિસ્સામાં બેકઅપ પ્રોવાઈડર પર સ્વિચ કરી શકે.
- રિસ્પોન્સ કેશ (cache) કરી શકે.
- વેન્ડર લોક-ઇન (vendor lock-in) થી બચી શકે.
મેં થર્ડ-પાર્ટી લાઇબ્રેરીઓ ટાળી કારણ કે તે ખૂબ જ જટિલ હતી અને સરળતાથી બગડી જતી હતી. તેના બદલે, મેં એક સાદો રાઉટર (router) બનાવ્યો.
સૌ પ્રથમ, મેં તમામ પ્રોવાઈડર્સ માટે એક કોમન ઇન્ટરફેસ (common interface) વ્યાખ્યાયિત કર્યો. દરેક પ્રોવાઈડર એક generate મેથડ અને એક હેલ્થ ચેક (health check) અમલમાં મૂકે છે.
ત્યારબાદ, મેં એક router ક્લાસ બનાવ્યો. તે ચોક્કસ ક્રમમાં પ્રોવાઈડર્સને અજમાવે છે. તે exponential backoff અને એક સાદા કેશ (cache) નો ઉપયોગ કરે છે. જો પ્રથમ પ્રોવાઈડર નિષ્ફળ જાય, તો સિસ્ટમ થોડી રાહ જુએ છે અને પછી બીજા પ્રોવાઈડરને અજમાવે છે.
આ સિસ્ટમે ત્રણ અલગ-અલગ આઉટેજ દરમિયાન મારા વીકેન્ડ્સ બચાવ્યા. જ્યારે કોઈ મુખ્ય પ્રોવાઈડર ડાઉન જાય છે, ત્યારે પણ તે મારી એપને ચાલુ રાખે છે.
જો તમે આ બનાવો છો, તો આ મુદ્દાઓ ધ્યાનમાં રાખો:
- પ્રોડક્શનમાં લોકલ ડિક્શનરીને બદલે કેશિંગ માટે Redis નો ઉપયોગ કરો.
- હેલ્થ ચેક સફળતાની ખાતરી આપતા નથી. પ્રોવાઈડર ચેકમાં પાસ થઈ શકે છે પરંતુ વાસ્તવિક રિક્વેસ્ટમાં નિષ્ફળ જઈ શકે છે.
- રેટ લિમિટ્સને યોગ્ય રીતે હેન્ડલ કરવા માટે Retry-After હેડર્સ પાર્સ કરો.
- ખર્ચને ટ્રેક કરવા માટે ટોકન વપરાશ માટે લોગિંગ (logging) ઉમેરો.
- ઉચ્ચ પ્રદર્શન માટે
asyncioનો ઉપયોગ કરો.
જો તમારો પ્રોજેક્ટ નાનો હોય, તો ઓવર-એન્જિનિયરિંગ (over-engineer) કરશો નહીં. જો તમારે સ્ટ્રીમિંગની જરૂર હોય, તો આ પેટર્ન લેટન્સી (latency) વધારે છે. તમારા સ્કેલ મુજબ યોગ્ય સાધન પસંદ કરો.
તમે પ્રોવાઈડરની વિશ્વસનીયતા કેવી રીતે હેન્ડલ કરો છો? શું તમે એક જ પ્રોવાઈડર સાથે જોડાયેલા રહો છો અથવા ફોલબેક લેયર (fallback layer) બનાવો છો?
Optional learning community: https://t.me/GyaanSetuAi