Budgets de délai et dégradation progressive

Un budget de délai d’attente est la durée totale maximale allouée à l’exécution d’une demande à travers toutes les étapes de votre chaîne de traitement. Au lieu de définir un délai d’attente arbitraire pour chaque appel d’API, vous définissez le budget de bout en bout de l’opération destinée à l’utilisateur, puis vous le répartissez entre les étapes de récupération, de génération par le LLM et de post-traitement. Vous vous assurez ainsi de toujours répondre dans un délai acceptable, même si certaines étapes sont lentes.

Une chaîne de traitement de discussion RAG classique comporte trois étapes : la récupération, la génération par le LLM et la mise en forme de la réponse. Attribuez une durée à chacune selon sa durée habituelle et le niveau de latence que les utilisateurs sont prêts à accepter. La marge restante constitue votre réserve de dégradation : si une étape utilise toute la durée qui lui est attribuée, vous commencez à simplifier les étapes suivantes pour rester dans le budget global.

Utilisez un BudgetTracker qui enregistre l’heure de début et vérifie le budget restant à chaque transition entre les étapes. Avant de commencer une étape, vérifiez qu’il reste suffisamment de budget. Les étapes suivantes peuvent ainsi s’adapter : une étape de récupération qui consomme 1200ms sur son budget de 1500ms ne laisse que 300ms de marge, ce qui devrait déclencher une invite LLM plus simple ou l’omission de l’étape de reclassement.

La dégradation progressive consiste à fournir une réponse de qualité moindre, mais toujours utile, lorsque la chaîne de traitement complète ne peut pas s’achever dans le budget imparti, plutôt que de renvoyer une erreur. Exemples : renvoyer une réponse mise en cache, ignorer le reclassement, tronquer la fenêtre de contexte, utiliser un modèle plus rapide mais moins précis ou renvoyer un message de repli pré-écrit. L’objectif est toujours de donner quelque chose à l’utilisateur plutôt que rien.

À chaque point de décision de la chaîne de traitement, vérifiez le budget restant et choisissez le niveau de qualité approprié. Le code ci-dessous choisit la profondeur de récupération et le modèle en fonction du budget restant. Ainsi, dans des conditions normales, les utilisateurs bénéficient de la meilleure qualité, tandis que pendant les périodes de forte latence, ils obtiennent tout de même une réponse utile plutôt qu’une erreur de délai d’attente.

Définissez toujours des délais d’attente explicites pour chaque appel d’API externe. Le SDK Python OpenAI accepte un paramètre timeout exprimé en secondes. Définissez-le à une valeur légèrement inférieure au budget restant afin de disposer du temps nécessaire pour gérer l’exception et éventuellement appliquer une dégradation progressive avant l’échéance globale de la réponse. Ne vous fiez jamais au délai d’attente par défaut du SDK : il peut être trop long pour les demandes destinées aux utilisateurs.

Avec la diffusion en continu, vous pouvez renvoyer des réponses partielles générées avant l’expiration du budget. Lorsqu’un délai d’attente survient au milieu de la diffusion, cessez de lire de nouveaux jetons, ajoutez des points de suspension ou une brève invite de continuation, puis fermez le flux. L’utilisateur voit une réponse qui s’interrompt proprement plutôt qu’une erreur vide. Cela n’est possible qu’avec la diffusion en continu : les appels sans diffusion sont entièrement réussis ou entièrement échoués.

Un cache sémantique constitue une excellente couche de dégradation, car sa latence est presque nulle. Avant d’appeler le LLM, interrogez votre cache sémantique pour rechercher des questions précédentes similaires. Si une correspondance du cache présentant une forte similarité (supérieure à 0.92 selon la similarité cosinus) est trouvée, renvoyez immédiatement la réponse mise en cache. Cela accélère les réponses tout en fournissant un repli instantané lorsque le LLM est lent ou indisponible.

Chaque fois que votre chaîne de traitement passe à un niveau de qualité inférieur, consignez-le comme un événement structuré. Incluez le niveau de dégradation atteint, le budget restant à chaque étape et la latence finale. L’analyse de ces journaux vous indique à quelle fréquence chaque niveau de dégradation est déclenché. Elle vous aide ainsi à ajuster les budgets, à repérer les étapes systématiquement en dépassement de budget et à justifier les investissements dans l’infrastructure.

Lorsque vous fournissez une réponse dégradée, indiquez à l’utilisateur que sa qualité peut être inférieure à la normale. Dans une interface de discussion, affichez un indicateur discret tel que « Mode de réponse rapide — certains détails peuvent être limités. » Pour une API d’extraction, ajoutez un champ degraded: true dans la réponse JSON afin que les consommateurs en aval puissent traiter différemment les résultats dégradés. La transparence préserve la confiance des utilisateurs, même pendant les interruptions de service.

Les répartitions initiales du budget sont des estimations. Après une semaine d’utilisation en production, analysez la répartition du temps consacré à chaque étape à l’aide de vos données de traçage. Si la récupération prend systématiquement 800ms au lieu des 1500ms prévus, réattribuez cette marge à l’étape LLM afin d’autoriser davantage de jetons de sortie ou une fenêtre de contexte plus large. L’ajustement du budget est une activité d’exploitation continue, et non une configuration ponctuelle.

Dans cette leçon, vous avez appris que les budgets de délai d’attente répartissent le temps entre les étapes de la chaîne de traitement afin que vous répondiez toujours dans un délai acceptable, que les échelles de dégradation fournissent des réponses progressivement moins qualitatives plutôt que des erreurs lorsque le temps est épuisé, et que la consignation des événements de dégradation vous aide à repérer et à corriger les goulots d’étranglement persistants. Nous allons maintenant étudier le modèle du LLM en tant qu’évaluateur pour l’évaluation automatisée de la qualité.