പ്രൊഡക്ഷൻ AI API പരാജയങ്ങൾ

നിങ്ങളുടെ AI ഫീച്ചർ പുലർച്ചെ 2 മണിക്ക് തകരാറിലാകുമ്പോൾ, എറർ മെസ്സേജുകൾ (Error messages) പലപ്പോഴും പൂർണ്ണമായ വിവരങ്ങൾ നൽകണമെന്നില്ല. ഒരു വർഷമായി ഞാൻ OpenAI, Anthropic സംയോജനങ്ങൾ (integrations) കൈകാര്യം ചെയ്യുന്നു. ഡീബഗ്ഗിംഗിന് (debugging) എളുപ്പമാകുന്ന രീതിയിൽ പരാജയങ്ങളെ തരംതിരിക്കാൻ ഞാൻ പഠിച്ചു.

റേറ്റ് ലിമിറ്റുകൾ (Rate Limits) കൈകാര്യം ചെയ്യൽ

OpenAI 429 എററുകൾക്ക് വ്യത്യസ്ത കാരണങ്ങളുണ്ടാകാം. എങ്ങനെ പ്രതികരിക്കണമെന്ന് അറിയാൻ നിങ്ങൾ എറർ കോഡ് പരിശോധിക്കണം.

  • മിനിറ്റിലെ റിക്വസ്റ്റുകൾ (Requests-per-minute - RPM) പരിധി സെക്കൻഡുകൾക്കുള്ളിൽ മാറിക്കിട്ടും.
  • മിനിറ്റിലെ ടോക്കണുകൾ (Tokens-per-minute - TPM) പരിധി 60 സെക്കൻഡുകൾക്കുള്ളിൽ മാറിക്കിട്ടും.
  • പ്രതിമാസ ക്വാട്ട (Monthly quota) തീർന്നുപോയാൽ, നിങ്ങൾ ക്രെഡിറ്റുകൾ ചേർക്കുന്നത് വരെയോ അല്ലെങ്കിൽ ബില്ലിംഗ് സൈക്കിൾ പുതുക്കുന്നത് വരെയോ ഈ പ്രശ്നം തുടരും.

ക്വാട്ട പ്രശ്നങ്ങൾക്ക് exponential backoff ഉപയോഗിക്കരുത്. അത് നിങ്ങളുടെ സമയം വെറുതെ കളയും.

Anthropic 529 എററുകൾ എന്നാൽ പ്രൊവൈഡർ (provider) അമിതഭാരം അനുഭവിക്കുന്നു എന്നാണ് അർത്ഥം. ഇതിനെ ഒരു 503 എറർ പോലെ കണക്കാക്കുക. പ്രശ്നം അവരുടെ ഭാഗത്താണ്. അല്പനേരം കാത്തിരിക്കുകയും നിങ്ങളുടെ ടീമിനെ അറിയിക്കുകയും ചെയ്യുക.

400 എററുകൾ കൈകാര്യം ചെയ്യൽ

ഈ പരാജയങ്ങൾ സാധാരണയായി നിങ്ങളുടെ ഭാഗത്തുനിന്നുണ്ടാകുന്നതാണ്. ഈ മൂന്ന് രീതികൾ ശ്രദ്ധിക്കുക:

  • മോഡൽ വേർഷൻ വ്യത്യാസങ്ങൾ (Model version mismatches). നിങ്ങൾ ഒരു സ്ഥലത്ത് പേര് അപ്ഡേറ്റ് ചെയ്തെങ്കിലും റീട്രൈ ഹാൻഡ്‌ലറിൽ (retry handler) അത് ചെയ്തിട്ടുണ്ടാകില്ല.
  • കോൺടെക്സ്റ്റ് വിൻഡോ ഓവർഫ്ലോ (Context window overflow). സംഭാഷണ ചരിത്രം (conversation history) വളരെ വലുതായിപ്പോകുന്നു. മോശം ട്രങ്കേഷൻ ലോജിക് (truncation logic) കാരണമാണ് ഇത് പലപ്പോഴും സംഭവിക്കുന്നത്.
  • സ്കീമ വാലിഡേഷൻ പരാജയങ്ങൾ (Schema validation failures). നിങ്ങളുടെ JSON സ്ട്രക്ചറിൽ സപ്പോർട്ട് ചെയ്യാത്ത ടൈപ്പുകളോ റിക്കഴ്‌സീവ് റെഫറൻസുകളോ (recursive references) ഉണ്ടാകാം.

ഇവ പരിഹരിക്കുന്നതിന്, 400 എററുകൾക്കായി ഫുൾ റിക്വസ്റ്റ് പേലോഡ് (full request payload) ലോഗ് ചെയ്യുക. ആദ്യം ഉപയോക്താവിന്റെ വിവരങ്ങൾ നീക്കം ചെയ്യുക (Redact). ഏത് ഫീൽഡിലാണ് പരാജയപ്പെട്ടതെന്ന് റെസ്‌പോൺസ് ബോഡി (response body) കൃത്യമായി പറയും.

ടൈമൗട്ടുകൾ (Timeouts) കൈകാര്യം ചെയ്യൽ

പ്രൊവൈഡർക്ക് കാര്യമായ പ്രശ്നമൊന്നും കാണാത്തതിനാൽ ടൈമൗട്ടുകൾ ട്രാക്ക് ചെയ്യുന്നത് പ്രയാസകരമാണ്.

  • കണക്ട് ടൈമൗട്ട് (Connect timeout). ഹാൻഡ്‌ഷേക്ക് (handshake) പരാജയപ്പെട്ടു. പ്രൊവൈഡർ ബ്രൗൺഔട്ട് (brownout) സമയത്തോ അല്ലെങ്കിൽ DNS പ്രശ്നങ്ങൾ ഉള്ളപ്പോഴോ ആണ് ഇത് സംഭവിക്കുന്നത്. നിങ്ങളുടെ ഔട്ട്‌ബൗണ്ട് നെറ്റ്‌വർക്ക് പരിശോധിക്കുക.
  • റീഡ് ടൈമൗട്ട് (Read timeout). മോഡൽ പ്രവർത്തനം ആരംഭിച്ചെങ്കിലും പൂർത്തിയാക്കിയില്ല. നിങ്ങളുടെ ആപ്പ് ഭാഗികമായ സ്ട്രീമിംഗ് ഔട്ട്‌പുട്ടുകൾ (partial streaming outputs) കൈകാര്യം ചെയ്യണം.
  • ഗേറ്റ്‌വേ ടൈമൗട്ട് (Gateway timeout - 504). നിങ്ങളുടെ പ്രോക്സി ആദ്യം ടൈമൗട്ട് ആയി. പ്രൊവൈഡറിൽ റിക്വസ്റ്റ് ഇപ്പോഴും പ്രവർത്തിച്ചുകൊണ്ടിരിക്കാം. റീട്രൈ ചെയ്യുന്നതിന് മുമ്പ് ഡ്യൂപ്ലിക്കേഷൻ ഒഴിവാക്കാനുള്ള സംവിധാനം (deduplication) ഉപയോഗിക്കുക.

ഡീബഗ്ഗിംഗിനായി, കണക്ട് ടൈമൗട്ടിനെയും റീഡ് ടൈമൗട്ടിനെയും വേർതിരിക്കുക. ലേറ്റൻസി (latency) എവിടെയാണെന്ന് കണ്ടെത്താൻ time-to-first-token ലോഗ് ചെയ്യുക.

പ്രൊവൈഡർ പ്രശ്നങ്ങൾ കൈകാര്യം ചെയ്യൽ

  • ഒരു 500 എറർ പലപ്പോഴും രണ്ട് സെക്കൻഡിന് ശേഷമുള്ള ഒരു റീട്രൈയിലൂടെ പരിഹരിക്കപ്പെടും.
  • ഒരു 503 എറർ എന്നാൽ സർവീസ് തകരാറിലാണെന്നാണ് അർത്ഥം. പ്രൊവൈഡർ സ്റ്റാറ്റസ് പേജിൽ എന്തെങ്കിലും പ്രശ്നം കാണിക്കുന്നുണ്ടെങ്കിൽ, ഒരു സർക്യൂട്ട് ബ്രേക്കർ (circuit breaker) ഉപയോഗിക്കുക.
  • ഏത് മോഡൽ വേർഷനാണ് പരാജയപ്പെട്ടതെന്ന് എപ്പോഴും രേഖപ്പെടുത്തുക. വ്യത്യസ്ത മോഡലുകൾക്ക് വ്യത്യസ്ത വിശ്വാസ്യത നിലവാരമാണുള്ളത് (reliability levels).

ലോഗുകളിൽ നിന്ന് നേരിട്ട് സ്ലാക്കിലേക്ക് (Slack) ചാടിപ്പോകുന്നത് നിർത്തുക. ആദ്യം പ്രൊവൈഡർ സ്റ്റാറ്റസ് പേജ് പരിശോധിക്കുക. ഇത് നിങ്ങളുടെ 20 മിനിറ്റ് പരിഭ്രാന്തി ഒഴിവാക്കും.

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

ഓപ്ഷണൽ ലേണിംഗ് കമ്മ്യൂണിറ്റി: https://t.me/GyaanSetuAi