Échecs des API d'IA en production

Les messages d'erreur racontent rarement toute l'histoire quand votre fonctionnalité d'IA tombe en panne à 2 heures du matin. J'ai géré des intégrations OpenAI et Anthropic pendant un an. J'ai appris à regrouper les échecs selon ce qu'ils signifient pour le débogage.

Gestion des limites de débit (Rate Limits)

Les erreurs 429 d'OpenAI ont des causes différentes. Vous devez vérifier le code d'erreur pour savoir comment réagir.

  • Les limites de requêtes par minute (RPM) se rétablissent en quelques secondes.
  • Les limites de jetons par minute (TPM) se rétablissent en 60 secondes.
  • L'épuisement du quota mensuel reste bloqué jusqu'à ce que vous ajoutiez des crédits ou que le cycle de facturation soit réinitialisé.

N'utilisez pas de backoff exponentiel pour les problèmes de quota. Cela vous fera perdre votre temps.

Les erreurs 529 d'Anthropic signifient que le fournisseur est surchargé. Traitez cela comme une erreur 503. Le problème vient de leur côté. Réduisez la cadence et alertez votre équipe.

Gestion des erreurs 400

Ces échecs sont généralement de votre faute. Surveillez ces trois schémas :

  • Incohérences de version de modèle. Vous avez mis à jour un nom à un endroit, mais pas dans votre gestionnaire de tentatives (retry handler).
  • Dépassement de la fenêtre de contexte. L'historique de la conversation est devenu trop volumineux. Cela arrive souvent à cause d'une mauvaise logique de troncature.
  • Échecs de validation de schéma. Votre structure JSON contient des types non pris en charge ou des références récursives.

Pour corriger cela, enregistrez (log) l'intégralité de la charge utile (payload) de la requête pour les erreurs 400. Masquez d'abord les données utilisateur. Le corps de la réponse vous indique exactement quel champ a échoué.

Gestion des délais d'attente (Timeouts)

Les timeouts sont difficiles à suivre car le fournisseur ne voit rien d'anormal.

  • Connect timeout. La poignée de main (handshake) a échoué. Cela se produit lors de baisses de régime (brownouts) du fournisseur ou de problèmes DNS. Vérifiez votre réseau sortant.
  • Read timeout. Le modèle a commencé mais n'a pas terminé. Votre application doit gérer les sorties de streaming partielles.
  • Gateway timeout (504). Votre proxy a expiré en premier. La requête est peut-être encore en cours chez le fournisseur. Utilisez la déduplication avant de réessayer.

Pour déboguer, séparez votre connect timeout de votre read timeout. Enregistrez le time-to-first-token pour identifier l'origine de la latence.

Gestion des problèmes de fournisseur

  • Une erreur 500 se résout souvent avec une seule tentative après deux secondes.
  • Une erreur 503 signifie que le service est dégradé. Si la page de statut du fournisseur indique un incident, utilisez un circuit breaker.
  • Enregistrez toujours quelle version de modèle a échoué. Les différents modèles ont des niveaux de fiabilité différents.

Arrêtez de passer sans cesse des logs à Slack. Vérifiez d'abord la page de statut du fournisseur. Cela vous évitera 20 minutes de panique.

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

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi