Passer à la navigation
Avancé

Mise en cascade des LLM

Découvrez comment Agents Platform garantit des réponses LLM fiables grâce à un mécanisme de repli en cascade.

Vue d’ensemble

Agents Platform utilise un mécanisme de mise en cascade des LLM pour renforcer la fiabilité et la résilience de ses capacités de génération de texte. Ce système tente automatiquement d’utiliser des grands modèles de langage (LLM) de secours en cas d’échec du LLM principal configuré, afin de garantir une expérience utilisateur plus fluide et cohérente.

Les échecs peuvent inclure des erreurs d’API, des délais d’expiration ou des réponses vides du fournisseur de LLM. La logique en cascade gère ces situations de manière fluide.

Fonctionnement

Le processus de mise en cascade suit une séquence définie :

  1. Tentative avec le LLM préféré : le système tente d’abord de générer une réponse à l’aide du LLM sélectionné dans la configuration de l’agent.

  2. Séquence de LLM de secours : si le LLM préféré échoue, le système bascule automatiquement vers une séquence prédéfinie de LLM de secours. Cette séquence est sélectionnée selon les performances, la vitesse et la fiabilité des modèles. La séquence par défaut actuelle, susceptible d’être modifiée, est la suivante :

    1. Gemini 3.5 Flash
    2. GPT-4o
    3. Gemini 3.5 Flash-Lite
    4. Claude Sonnet 4.6

  3. Conformité HIPAA : si l’agent fonctionne dans un mode exigeant une confidentialité stricte des données, conformité HIPAA ou zéro rétention des données, la liste de secours est filtrée pour n’inclure que les modèles conformes de la séquence ci-dessus.

  4. Nouvelles tentatives : le système relance le processus de génération plusieurs fois, au moins 3 tentatives, sur la séquence de LLM disponibles, préféré et secours. Si un LLM de secours échoue également, le système passe au suivant dans la séquence. S’il n’y a plus de LLM de secours uniques dans la limite de tentatives, il peut réessayer des modèles de secours ayant précédemment échoué.

  5. Initialisation à la demande : les connexions aux LLM de secours ne sont initialisées qu’en cas de besoin, afin d’optimiser l’utilisation des ressources.

La liste précise et l’ordre des LLM de secours sont gérés en interne par ElevenLabs et optimisés pour les performances et la disponibilité. La séquence ci-dessus représente la valeur par défaut actuelle, mais elle peut être mise à jour sans préavis.

LLM personnalisés

Lorsque vous configurez un LLM personnalisé comme modèle principal, la logique de cascade standard vers les modèles hébergés par ElevenLabs est ignorée par défaut. Le système tente d’utiliser votre LLM personnalisé et, en cas d’échec, réessaie la requête plusieurs fois avec le même LLM personnalisé, selon le nombre minimal standard de tentatives, avant de considérer la requête comme ayant échoué.

Ce paramètre par défaut maintient tout le trafic sur votre propre endpoint, mais une défaillance prolongée de votre LLM personnalisé met fin à la conversation. Pour maintenir les conversations lorsque votre LLM personnalisé est indisponible, configurez une cascade de secours personnalisée vers d’autres modèles.

Configurer une cascade de secours personnalisée

Une cascade de secours personnalisée fonctionne de la même manière lorsqu’un LLM personnalisé est principal que pour tout autre modèle. Définissez la préférence de LLM de secours de l’agent sur override et fournissez un tableau order répertoriant, dans l’ordre, les modèles hébergés par ElevenLabs vers lesquels effectuer le repli. Consultez le champ backup_llm_config des endpoints Create agent et Update agent pour connaître la structure exacte.

Vous pouvez aussi le configurer dans le Dashboard ElevenLabs, sous Configuration des LLM de secours, en sélectionnant Personnalisée puis en organisant les modèles de repli. Consultez Modèles pour connaître les options disponibles.

La cascade suit le même comportement de nouvelles tentatives et de délais d’expiration décrit ci-dessus : chaque modèle de l’ordre est essayé à son tour, et le système effectue au moins 3 tentatives sur la séquence, principal et secours, avant de considérer la requête comme ayant échoué. Définissez cascade_timeout_seconds (2 à 15 secondes, 4 par défaut) pour contrôler le temps d’attente du système sur un modèle avant de passer au suivant.

Un LLM personnalisé peut uniquement être utilisé comme modèle principal ; il ne peut pas être répertorié dans order pour les modèles de secours. Les entrées de secours doivent être des modèles hébergés par ElevenLabs.

Lorsque votre LLM personnalisé est le modèle principal et que backup_llm_config est défini sur default ou disabled, le système ne bascule pas vers des modèles hébergés par ElevenLabs. Une défaillance prolongée de votre LLM personnalisé met fin à la conversation sans solution de secours. Utilisez override pour activer le repli. Définissez disabled uniquement si vous ne souhaitez intentionnellement aucun repli, ce qui est fortement déconseillé en production.

Pour un agent utilisant un modèle Realtime, l’agent bascule vers un LLM de secours si le modèle Realtime ne répond pas à temps. Le modèle Realtime définit la durée d’attente de l’agent.

Avantages

  • Fiabilité accrue : réduit l’impact de problèmes temporaires chez un fournisseur de LLM spécifique.
  • Disponibilité renforcée : augmente les chances de générer une réponse avec succès, même lors de pannes partielles de LLM.
  • Fonctionnement transparent : le mécanisme de repli est automatique et transparent pour l’utilisateur final.

Configuration

La mise en cascade des LLM est un processus automatique en arrière-plan. Par défaut, il vous suffit de sélectionner votre LLM préféré dans les paramètres de l’agent, et le système gère le reste.

Pour personnaliser le comportement de repli, y compris lors de l’utilisation d’un LLM personnalisé comme modèle principal, définissez la Configuration des LLM de secours de l’agent sur Par défaut, Personnalisée ou Désactivée. Consultez LLM personnalisés ci-dessus.