ਪ੍ਰੋਡਕਸ਼ਨ AI API ਅਸਫਲਤਾਵਾਂ

ਜਦੋਂ ਤੁਹਾਡਾ AI ਫੀਚਰ ਰਾਤ ਦੇ 2 ਵਜੇ ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਗਲਤੀ ਦੇ ਸੁਨੇਹੇ (error messages) ਸ਼ਾਇਦ ਪੂਰੀ ਗੱਲ ਨਹੀਂ ਦੱਸਦੇ। ਮੈਂ ਇੱਕ ਸਾਲ ਤੱਕ OpenAI ਅਤੇ Anthropic ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਚਲਾਇਆ ਹੈ। ਮੈਂ ਸਿੱਖਿਆ ਹੈ ਕਿ ਡੀਬੱਗਿੰਗ ਲਈ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਅਰਥਾਂ ਅਨੁਸਾਰ ਕਿਵੇਂ ਵੰਡਣਾ ਹੈ।

ਰੇਟ ਲਿਮਿਟਸ (Rate Limits) ਨੂੰ ਸੰਭਾਲਣਾ

OpenAI 429 ਗਲਤੀਆਂ ਦੇ ਵੱਖ-ਵੱਖ ਕਾਰਨ ਹੁੰਦੇ ਹਨ। ਇਹ ਜਾਣਨ ਲਈ ਕਿ ਕਿਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣੀ ਹੈ, ਤੁਹਾਨੂੰ ਗਲਤੀ ਕੋਡ (error code) ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

  • Requests-per-minute (RPM) ਲਿਮਿਟਾਂ ਸਕਿੰਟਾਂ ਵਿੱਚ ਠੀਕ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
  • Tokens-per-minute (TPM) ਲਿਮਿਟਾਂ 60 ਸਕਿੰਟਾਂ ਵਿੱਚ ਠੀਕ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
  • ਮਾਸਿਕ ਕੋਟਾ (Monthly quota) ਖਤਮ ਹੋਣ ਦੀ ਸਥਿਤੀ ਉਦੋਂ ਤੱਕ ਖਰਾਬ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕ੍ਰੈਡਿਟ ਨਹੀਂ ਜੋੜਦੇ ਜਾਂ ਬਿਲਿੰਗ ਚੱਕਰ (billing cycle) ਰੀਸੈੱਟ ਨਹੀਂ ਹੁੰਦਾ।

ਕੋਟਾ ਸਮੱਸਿਆਵਾਂ ਲਈ exponential backoff ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। ਇਹ ਤੁਹਾਡਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰੇਗਾ।

Anthropic 529 ਗਲਤੀਆਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪ੍ਰੋਵਾਈਡਰ 'ਤੇ ਲੋਡ ਜ਼ਿਆਦਾ ਹੈ। ਇਸਨੂੰ 503 ਗਲਤੀ ਵਾਂਗ ਹੀ ਸਮਝੋ। ਸਮੱਸਿਆ ਉਹਨਾਂ ਦੇ ਪਾਸੇ ਹੈ। ਥੋੜ੍ਹੀ ਦੇਰ ਰੁਕੋ ਅਤੇ ਆਪਣੀ ਟੀਮ ਨੂੰ ਸੂਚਿਤ ਕਰੋ।

400 ਗਲਤੀਆਂ (Errors) ਨੂੰ ਸੰਭਾਲਣਾ

ਇਹ ਅਸਫਲਤਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੀ ਗਲਤੀ ਹੁੰਦੀਆਂ ਹਨ। ਇਹਨਾਂ ਤਿੰਨ ਪੈਟਰਨਾਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ:

  • ਮਾਡਲ ਵਰਜ਼ਨ ਦਾ ਮੇਲ ਨਾ ਖਾਣਾ (Model version mismatches)। ਤੁਸੀਂ ਇੱਕ ਜਗ੍ਹਾ ਨਾਮ ਅਪਡੇਟ ਕੀਤਾ ਸੀ ਪਰ ਆਪਣੇ ਰੀਟ੍ਰਾਈ ਹੈਂਡਲਰ (retry handler) ਵਿੱਚ ਨਹੀਂ।
  • ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਓਵਰਫਲੋ (Context window overflow)। ਗੱਲਬਾਤ ਦਾ ਇਤਿਹਾਸ ਬਹੁਤ ਵੱਡਾ ਹੋ ਗਿਆ। ਇਹ ਅਕਸਰ ਗਲਤ ਟਰੰਕੇਸ਼ਨ ਲੌਜਿਕ (truncation logic) ਕਾਰਨ ਹੁੰਦਾ ਹੈ।
  • ਸਕੀਮਾ ਵੈਲੀਡੇਸ਼ਨ ਅਸਫਲਤਾਵਾਂ (Schema validation failures)। ਤੁਹਾਡੇ JSON ਢਾਂਚੇ ਵਿੱਚ ਅਸਮਰਥਿਤ ਕਿਸਮਾਂ (unsupported types) ਜਾਂ ਰਿਕਰਸੀਵ ਰੈਫਰੈਂਸ ਹਨ।

ਇਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, 400 ਗਲਤੀਆਂ ਲਈ ਪੂਰੇ ਰਿਕਵੈਸਟ ਪੇਲੋਡ (request payload) ਨੂੰ ਲੌਗ ਕਰੋ। ਪਹਿਲਾਂ ਯੂਜ਼ਰ ਡੇਟਾ ਨੂੰ ਰੈਡੈਕਟ (redact) ਕਰੋ। ਰਿਸਪਾਂਸ ਬਾਡੀ ਤੁਹਾਨੂੰ ਦੱਸੇਗੀ ਕਿ ਕਿਹੜਾ ਫੀਲਡ ਫੇਲ ਹੋਇਆ ਹੈ।

ਟਾਈਮਆਊਟ (Timeouts) ਨੂੰ ਸੰਭਾਲਣਾ

ਟਾਈਮਆਊਟ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰੋਵਾਈਡਰ ਨੂੰ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦਾ।

  • ਕਨੈਕਟ ਟਾਈਮਆਊਟ (Connect timeout)। ਹੈਂਡਸ਼ੇਕ ਫੇਲ ਹੋ ਗਿਆ। ਇਹ ਪ੍ਰੋਵਾਈਡਰ ਦੇ ਬ੍ਰਾਊਨਆਊਟਸ (brownouts) ਜਾਂ DNS ਸਮੱਸਿਆਵਾਂ ਦੌਰਾਨ ਹੁੰਦਾ ਹੈ। ਆਪਣੇ ਆਊਟਬਾਊਂਡ ਨੈੱਟਵਰਕ ਦੀ ਜਾਂਚ ਕਰੋ।
  • ਰੀਡ ਟਾਈਮਆਊਟ (Read timeout)। ਮਾਡਲ ਸ਼ੁਰੂ ਹੋਇਆ ਪਰ ਖਤਮ ਨਹੀਂ ਹੋਇਆ। ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਅਧੂਰੇ ਸਟ੍ਰੀਮਿੰਗ ਆਉਟਪੁੱਟਸ (partial streaming outputs) ਨੂੰ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ।
  • ਗੇਟਵੇ ਟਾਈਮਆਊਟ (504)। ਤੁਹਾਡਾ ਪ੍ਰੌਕਸੀ ਪਹਿਲਾਂ ਟਾਈਮਆਊਟ ਹੋ ਗਿਆ। ਰਿਕਵੈਸਟ ਸ਼ਾਇਦ ਅਜੇ ਵੀ ਪ੍ਰੋਵਾਈਡਰ ਕੋਲ ਚੱਲ ਰਹੀ ਹੋਵੇ। ਰੀਟ੍ਰਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡਿਡੂਪਲੀਕੇਸ਼ਨ (deduplication) ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਡੀਬੱਗ ਕਰਨ ਲਈ, ਆਪਣੇ ਕਨੈਕਟ ਟਾਈਮਆਊਟ ਨੂੰ ਆਪਣੇ ਰੀਡ ਟਾਈਮਆਊਟ ਤੋਂ ਵੱਖ ਕਰੋ। ਲੇਟੈਂਸੀ (latency) ਕਿੱਥੇ ਹੈ ਇਹ ਲੱਭਣ ਲਈ time-to-first-token ਨੂੰ ਲੌਗ ਕਰੋ।

ਪ੍ਰੋਵਾਈਡਰ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸੰਭਾਲਣਾ

  • 500 ਗਲਤੀ ਅਕਸਰ ਦੋ ਸਕਿੰਟਾਂ ਬਾਅਦ ਇੱਕ ਰੀਟ੍ਰਾਈ ਨਾਲ ਹੱਲ ਹੋ ਜਾਂਦੀ ਹੈ।
  • 503 ਗਲਤੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸੇਵਾ ਘਟ ਗਈ ਹੈ (degraded)। ਜੇਕਰ ਪ੍ਰੋਵਾਈਡਰ ਸਟੇਟਸ ਪੇਜ ਕਿਸੇ ਘਟਨਾ (incident) ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਤਾਂ ਸਰਕਟ ਬ੍ਰੇਕਰ (circuit breaker) ਦੀ ਵਰਤੋਂ ਕਰੋ।
  • ਹਮੇਸ਼ਾ ਰਿਕਾਰਡ ਕਰੋ ਕਿ ਕਿਹੜਾ ਮਾਡਲ ਵਰਜ਼ਨ ਫੇਲ ਹੋਇਆ। ਵੱਖ-ਵੱਖ ਮਾਡਲਾਂ ਦੇ ਭਰੋਸੇਯੋਗਤਾ ਪੱਧਰ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ।

ਲੌਗਸ ਤੋਂ ਸਿੱਧਾ 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