Bonnes pratiques en production
Les points à maîtriser avant qu’une intégration ne traite du trafic réel.
Fiabilité
- Réessayez pour les codes appropriés.
429,500,502,503,529avec un délai exponentiel et une variation aléatoire. Ne réessayez jamais aveuglément400,401,402ou403. - Définissez des délais d’expiration. Une génération longue peut légitimement prendre plusieurs minutes ; une connexion bloquée ne doit pas bloquer aussi votre processus de traitement. Un plafond de 120 s est raisonnable pour les appels sans streaming.
- Limitez les appels simultanés avec un sémaphore plutôt que de tout lancer puis de réessayer les requêtes rejetées.
- Prévoyez un modèle de secours. Si votre modèle principal est surchargé, passer à un modèle plus petit vaut mieux que renvoyer une erreur.
Coût
- Définissez
max_tokensà chaque appel. Il s’agit d’un plafond de dépenses, pas d’une suggestion. - Orientez les requêtes selon la tâche — consultez Maîtrise des coûts.
- Activez la mise en cache des prompts pour des préfixes stables.
- Consignez
usagepour chaque requête, avec une étiquette de tâche afin de pouvoir attribuer les dépenses par la suite.
Sécurité
- Les clés doivent être stockées dans des variables d’environnement ou un gestionnaire de secrets — jamais dans le dépôt, jamais dans un bundle client.
- Une clé par service, pour une révocation ciblée.
- Ne construisez jamais de prompts en concaténant des entrées utilisateur non fiables avec des instructions ; conservez le contenu utilisateur dans un message
useret les instructions danssystem. - Traitez les sorties du modèle comme non fiables. Ne leur appliquez pas
evalet n’exécutez pas le SQL généré avec un rôle disposant de droits d’écriture.
Observabilité
- Consignez le modèle, la latence,
usage,stop_reasonet votre propre type de tâche pour chaque appel. - Déclenchez une alerte sur le taux de
stop_reason: max_tokens— une hausse signifie que les réponses sont tronquées. - Suivez le coût par type de tâche, pas seulement le total. Les totaux masquent la charge de travail dont le coût a augmenté.
L’alerte la plus utile porte sur la troncature, pas sur les erreurs. Une réponse tronquée renvoie HTTP 200 et semble correcte pour votre système de supervision, alors qu’elle est incorrecte pour l’utilisateur.