પ્રોડક્શન AI API નિષ્ફળતાઓ

જ્યારે તમારી AI સુવિધા રાત્રે 2 વાગ્યે બગડે છે, ત્યારે એરર મેસેજ (error messages) ભાગ્યે જ આખી વાત કહે છે. મેં એક વર્ષ સુધી OpenAI અને Anthropic ઇન્ટિગ્રેશન ચલાવ્યા છે. મેં શીખ્યું છે કે ડિબગિંગ માટે નિષ્ફળતાઓને તેના અર્થ મુજબ કેવી રીતે જૂથબદ્ધ કરવી.

રેટ લિમિટ્સ (Rate Limits) હેન્ડલ કરવી

OpenAI 429 એરર્સના કારણો અલગ-અલગ હોય છે. કેવી રીતે પ્રતિક્રિયા આપવી તે જાણવા માટે તમારે એરર કોડ તપાસવો જ જોઈએ.

  • Requests-per-minute (RPM) લિમિટ્સ સેકન્ડોમાં સુધરી જાય છે.
  • Tokens-per-minute (TPM) લિમિટ્સ 60 સેકન્ડમાં સુધરી જાય છે.
  • માસિક ક્વોટા (Monthly quota) ખતમ થઈ જવાથી સમસ્યા ત્યાં સુધી રહે છે જ્યાં સુધી તમે ક્રેડિટ ઉમેરો નહીં અથવા બિલિંગ સાયકલ રિસેટ ન થાય.

ક્વોટાની સમસ્યાઓ માટે exponential backoff નો ઉપયોગ કરશો નહીં. તે તમારો સમય બગાડશે.

Anthropic 529 એરર્સનો અર્થ છે કે પ્રોવાઈડર પર લોડ વધી ગયો છે. આને 503 એરરની જેમ ગણો. સમસ્યા તેમના પક્ષે છે. થોડી રાહ જુઓ અને તમારી ટીમને જાણ કરો.

400 એરર્સ (Errors) હેન્ડલ કરવી

આ નિષ્ફળતાઓ સામાન્ય રીતે તમારી ભૂલ હોય છે. આ ત્રણ પેટર્ન પર ધ્યાન આપો:

  • મોડેલ વર્ઝન મિસમેચ (Model version mismatches). તમે એક જગ્યાએ નામ અપડેટ કર્યું પણ તમારા રીટ્રાય હેન્ડલરમાં (retry handler) નહીં.
  • કોન્ટેક્સ્ટ વિન્ડો ઓવરફ્લો (Context window overflow). વાતચીતનો ઇતિહાસ ખૂબ મોટો થઈ ગયો. આ ઘણીવાર ખરાબ ટ્રંકેશન લોજિક (truncation logic) ને કારણે થાય છે.
  • સ્કીમા વેલિડેશન નિષ્ફળતા (Schema validation failures). તમારા JSON સ્ટ્રક્ચરમાં અસપોર્ટેડ પ્રકારો અથવા રિકર્સિવ રેફરન્સ છે.

આને ઠીક કરવા માટે, 400 એરર્સ માટે સંપૂર્ણ રિક્વેસ્ટ પેલોડ (request payload) લોગ કરો. પહેલા યુઝર ડેટાને રિડેક્ટ (redact) કરો. રિસ્પોન્સ બોડી તમને બરાબર જણાવશે કે કયું ફિલ્ડ નિષ્ફળ ગયું છે.

ટાઈમઆઉટ્સ (Timeouts) હેન્ડલ કરવા

ટાઈમઆઉટ્સને ટ્રેક કરવા મુશ્કેલ છે કારણ કે પ્રોવાઈડરને કંઈપણ ખોટું દેખાતું નથી.

  • કનેક્ટ ટાઈમઆઉટ (Connect timeout). હેન્ડશેક નિષ્ફળ ગયું. આ પ્રોવાઈડર બ્રાઉનઆઉટ અથવા DNS સમસ્યાઓ દરમિયાન થાય છે. તમારું આઉટબાઉન્ડ નેટવર્ક તપાસો.
  • રીડ ટાઈમઆઉટ (Read timeout). મોડેલે શરૂઆત કરી પણ પૂર્ણ ન કર્યું. તમારા એપ દ્વારા પાર્શિયલ સ્ટ્રીમિંગ આઉટપુટ્સ (partial streaming outputs) હેન્ડલ કરવા જોઈએ.
  • ગેટવે ટાઈમઆઉટ (504). તમારો પ્રોક્સી પહેલા ટાઈમઆઉટ થઈ ગયો. રિક્વેસ્ટ કદાચ હજુ પણ પ્રોવાઈડર પર ચાલી રહી હોઈ શકે છે. રીટ્રાય કરતા પહેલા deduplication નો ઉપયોગ કરો.

ડિબગ કરવા માટે, તમારા કનેક્ટ ટાઈમઆઉટને તમારા રીડ ટાઈમઆઉટથી અલગ કરો. લેટન્સી (latency) ક્યાં છે તે શોધવા માટે time-to-first-token લોગ કરો.

પ્રોવાઈડરની સમસ્યાઓ હેન્ડલ કરવી

  • 500 એરર ઘણીવાર બે સેકન્ડ પછી એક રીટ્રાય સાથે ઉકેલાઈ જાય છે.
  • 503 એરરનો અર્થ છે કે સર્વિસમાં ખામી છે. જો પ્રોવાઈડર સ્ટેટસ પેજ કોઈ ઇન્સિડન્ટ બતાવે છે, તો સર્કિટ બ્રેકર (circuit breaker) નો ઉપયોગ કરો.
  • હંમેશા રેકોર્ડ કરો કે કયું મોડેલ વર્ઝન નિષ્ફળ ગયું હતું. અલગ-અલગ મોડેલ્સના વિશ્વસનીયતા સ્તર (reliability levels) અલગ હોય છે.

લોગ્સથી સીધા Slack પર જવાનું બંધ કરો. પહેલા પ્રોવાઈડર સ્ટેટસ પેજ તપાસો. તે તમને 20 મિનિટના ગભરાટથી બચાવશે.

Source: https://dev.to/void_stitch/production-ai-api-failures-by-category-what-429s-529s-and-timeouts-are-actually-telling-you-5bo1

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