L’exploitation d’un système reposant sur un grand modèle de langage ne s’arrête pas au fait de le rendre disponible ou d’améliorer sa précision initiale. Le système peut rester entièrement disponible tout en approuvant silencieusement de mauvaises décisions, en consommant rapidement le budget ou en basculant, pendant les pannes, vers un modèle dont la qualité n’a pas été testée. C’est pourquoi la cinquième partie de la série Running LLM systems in production se concentre sur l’exploitabilité au quotidien, en tant que couche qui rend le système observable, contrôlable, arrêtable et capable de récupérer.
Surveillez la décision, pas seulement le service
Les métriques de service traditionnelles, telles que le taux de requêtes, les erreurs, le temps de réponse et la consommation du processeur, ne révèlent pas si l’agent prend de bonnes décisions. La source propose d’ajouter une couche de surveillance propre aux décisions, comprenant le volume des décisions, le taux d’exécution automatisée, la distribution de la confiance composée, le temps de chaque nœud, les cas de blocage des contrôles de sécurité, la consommation de jetons et les coûts, le taux d’intervention humaine et les résultats d’évaluations cachées sur des échantillons du trafic de production.
La source définit quatre familles de signaux : décision, sécurité, coûts et performances, et qualité. S’il est impossible de tout mesurer, la priorité doit être accordée au taux d’exécution automatisée, aux blocages des contrôles de sécurité, au coût total des modèles et au taux de dépassement des décisions du système par les humains.
Elle recommande également de répartir les journaux en trois couches : des données opérationnelles à haut volume, des métadonnées de décision dans les limites de confiance, et des données brutes ou structurées soumises au chiffrement et à un contrôle strict. Chaque décision doit porter un identifiant stable, decision_id, qui relie les métriques, les journaux, les traces et le journal d’audit, afin de pouvoir examiner une décision donnée de son début à sa fin.
Rendez les coûts mesurables et plafonnables
Les appels aux modèles ne devraient pas être répartis dans différentes parties de la base de code, car cela rend les coûts difficiles à attribuer et à contrôler. La source propose plutôt une passerelle unique par laquelle passent tous les appels, chargée de calculer les jetons et les coûts par locataire, capacité et modèle, tout en appliquant les limites de débit et de budget.
Les outils de réduction des coûts sont appliqués dans l’ordre suivant : ne pas appeler le modèle lorsqu’une règle déterministe suffit, regrouper les éléments dans un seul appel, mettre temporairement en cache les résultats déterministes, choisir un modèle plus petit pour les tâches simples, puis réduire le contexte et les instructions inutiles. Il faut également calculer les jetons estimés avant l’appel, plutôt que de compter chaque requête comme une seule unité, et définir un plafond global pour la plateforme ainsi que des limites pour les tentatives répétées et les boucles d’outils illimitées.
Routage, repli et mécanisme d’arrêt
En pratique, il n’existe pas un modèle unique adapté à toutes les tâches. Les tâches à faible risque et à fort volume peuvent être orientées vers un modèle plus petit, tandis que les cas ambigus ou sensibles peuvent être confiés à un modèle plus puissant. Une famille différente peut être utilisée pour le modèle de jugement, afin que les modèles ne partagent pas les mêmes points faibles. Chaque modèle présent dans le chemin de routage ou de repli doit être évalué, car le passage à un modèle de remplacement peut modifier la qualité.
Lorsqu’un fournisseur est en panne, il faut utiliser une chaîne de repli définie avec un délai d’attente global unique, un disjoncteur qui empêche d’appeler un fournisseur connu pour être défaillant, ainsi que des clés d’idempotence pour éviter de traiter la décision deux fois si le délai d’attente de l’appel expire alors que celui-ci a en réalité abouti. Lorsque l’alternative n’est pas acceptable, la décision doit être transférée à un humain plutôt que de dissimuler la dégradation.
Concernant le mécanisme d’arrêt, la source propose qu’il fonctionne comme un état opérationnel partagé pouvant être général ou propre à un locataire ou à une capacité. Les états comprennent : le fonctionnement normal, HUMAN_ONLY pour arrêter l’exécution automatisée tout en conservant les suggestions destinées aux humains, et HALTED pour arrêter entièrement la prise de décision. Si le mécanisme d’arrêt est inaccessible, le comportement sûr consiste à passer en mode de revue humaine, et non à poursuivre le fonctionnement normal.
L’architecture qui empêche le chaos
La source relie l’exploitabilité à une architecture à six directions qui sépare la logique métier des modules des fournisseurs de modèles au moyen d’une interface et de passerelles d’adaptation. Il devient ainsi possible de changer de fournisseur sans réécrire la logique métier et de tester le domaine avec un modèle fictif, sans réseau ni coût.
L’architecture de base comprend des services d’agents sans état, une passerelle de modèles, un stockage d’audit en ajout uniquement, une mémoire partagée pour les limites et le mécanisme d’arrêt, un coffre-fort de secrets et un stockage objet pour les entrées et les données sensibles. La source insiste également sur une identité indépendante pour chaque service, le principe du moindre privilège et la vérification de la concordance entre l’identité du locataire et la requête à chaque saut, en particulier lors de l’utilisation de délégations d’autorisation à courte durée pour les tâches différées.
Pourquoi cette actualité est-elle importante ?
La valeur pratique ne réside pas dans l’ajout d’un nouveau composant, mais dans le regroupement des points de contrôle critiques au sein d’un même point d’accès : la passerelle qui rend possible le changement de modèle est aussi celle qui mesure les coûts, applique les limites, gère le routage et le repli, et active l’arrêt. La réussite de cette approche reste toutefois conditionnée par le test réel de scénarios de défaillance, tels que la panne d’un fournisseur de modèles, l’activation du mécanisme d’arrêt, une charge soudaine et le redémarrage d’un nœud pendant une décision en cours d’exécution. Sans ces tests, les mécanismes de récupération restent des hypothèses non vérifiées.