Problème de localisation des défauts après réduction des coûts dans le routage multimodèle

La première fois que j’ai senti que quelque chose n’allait pas en ligne, c’était une plainte difficile à expliquer : le même utilisateur a posé la même question trois fois en 5 minutes. La première fois, il a bien réagi, la deuxième fois, il a commencé à dire des bêtises et la troisième fois, tout est revenu à la normale.

Il n’y a aucune anomalie dans les journaux, la latence est stable et l’utilisation des jetons n’a pas augmenté. Le seul changement visible est que nous venons d’activer le « routage multimodèle » et d’utiliser des modèles moins chers pour couvrir une partie du trafic.

A cette époque, l’intuition de l’équipe était très cohérente : le modèle est une distribution de probabilité, et les fluctuations sont normales. En outre, le routage n’est qu’une couche de la passerelle, alors quels gros problèmes peuvent survenir ?

Au cours des deux semaines suivantes, nous avons subi cette sentence à plusieurs reprises.

Jugement fondamental

Le principal coût du routage multimodèle est de changer le comportement de la même requête de « reproductible » à « distribution de probabilité ».

À l’ère du modèle unique, quelle que soit la difficulté d’un problème en ligne, tant que vous obtenez l’entrée, l’invite, le contexte et le numéro de version, vous pouvez très probablement le reproduire dans un certain environnement, puis suivre la chaîne d’appels pour identifier la cause première.

Une fois le routage impliqué, le problème deviendra :

-Quel modèle, quelle version et quel ensemble de paramètres ai-je utilisé cette fois-ci ?

• Pourquoi l’itinéraire a-t-il été choisi de cette manière et quelles caractéristiques le seuil a-t-il atteint ?
• Avez-vous emprunté des chemins différents deux fois au cours d’une même séance ?
• Lorsqu’un échec survient, est-il possible de relancer la « décision prise à ce moment-là » ?

S’il n’existe pas de journaux traçables ni de mécanismes de restauration, les erreurs en ligne passeront de « modèle inexact » à « cause première introuvable ».

Comment les choses deviennent de plus en plus difficiles étape par étape

Au début, nous n’avons adopté que la stratégie la plus simple : utiliser des petits modèles autant que possible, et passer aux grands modèles uniquement lorsqu’ils “semblent compliqués”.

Ce que l’on appelle « l’apparence complexe » sont certaines fonctionnalités bon marché : la longueur d’entrée, la présence ou non de blocs de code, l’existence de plusieurs cycles de dialogue et la confiance d’un petit classificateur.

La première vague de problèmes après la mise en ligne a été l’échec des méthodes de dépannage.

La même invite ne peut pas être reproduite par les collègues de test dans l’environnement en niveaux de gris et ne peut pas être reproduite localement par les développeurs. En fin de compte, seuls les utilisateurs en ligne peuvent le déclencher de manière stable.

Nous avons déjà soupçonné qu’il s’agissait d’un bug lié à l’épissage du contexte, à la mise en cache ou à un post-traitement. Ce n’est que lorsque nous avons capturé l’intégralité des données d’une demande que nous avons découvert qu’un petit modèle était utilisé en ligne cette fois-ci, et que le grand modèle était utilisé par défaut lorsque nous le reproduisions.

Il s’agit d’un “changement de chemin”.

Les changements de chemin font passer le dépannage de « entrées récurrentes » à « décisions récurrentes ». Les décisions ne peuvent pas être rejouées à ce moment-là.

Malentendu 1 : considérer le routage comme une pure optimisation des coûts

Ce que vous voyez dans le tableau des coûts est :

• 30% du trafic va aux petits modèles
• Le coût moyen par appel a diminué de 18 %

Mais ce que vous ne pouvez pas voir dans le tableau des défauts est :

• Chaque problème de qualité prendra 1 à 2 jours supplémentaires pour déterminer s’il est causé par le routage.
• La reproduction en ligne nécessite un « contexte décisionnel » plus complet
• Le rollback n’est plus un “modèle de rollback”, mais une “stratégie de rollback + seuil de rollback + logique d’extraction des fonctionnalités de rollback”

Lorsque vous traitez le routage comme un changement léger comme « changer de fournisseur », vous devrez certainement payer des intérêts plus tard dans le dépannage.

Malentendu 2 : Interpréter l’instabilité comme « LLM est intrinsèquement aléatoire »

La plupart des problèmes causés par le caractère aléatoire d’un seul modèle consistent à “échantillonner plusieurs fois la même entrée avec des sorties différentes”.

Le problème causé par le caractère aléatoire du routage est que « la même entrée va vers des systèmes différents ».

Les deux ressemblent à des fluctuations, mais sont diagnostiqués de manière complètement différente.

Le premier ajuste souvent la température, les invites du système et ajoute des contraintes ; ce dernier doit d’abord répondre : ont-ils fait fausse route cette fois-ci ?

Sans acheminer les journaux de décision, l’équipe prendra une très mauvaise habitude : attribuer toutes les anomalies à « l’instabilité du modèle », de sorte que la stratégie devient de plus en plus agressive et la qualité devient de plus en plus comme un dé.

Trois types de traçabilité qu’il faut vraiment compléter

Pour faire du routage un système « dépannable », au moins trois types d’enregistrements doivent être complétés, et ils doivent pouvoir être regroupés dans une seule dimension de demande.

1) Journal de décision de routage (journal de décision)

Enregistrez non seulement « quel modèle a été sélectionné », mais enregistrez également :

• Ensemble de candidats (quels modèles disponibles sont disponibles à ce moment-là)
• Notation ou jugement de seuil pour chaque candidat
• Valeurs des fonctionnalités utilisées (longueur d’entrée, nombre de tours multiples, sortie du classificateur, etc.)
• Numéro de version de la politique (très critique)

Ce n’est qu’ainsi que nous pourrons répondre « Pourquoi ai-je choisi cette fois ? »

2) Demander un instantané (rejouer un instantané)

Au moins les éléments suivants doivent être disponibles en cas de panne :

• Entrée utilisateur brute
• L’invite réellement envoyée au modèle (y compris les mots d’invite du système, le contexte épissé et les résultats de l’outil)
• Configuration des clés (température, top_p, max_tokens, stop et son propre commutateur de post-traitement)

Sans instantanés, les récurrences ne sont que des suppositions.

3) Annulation du routage (primitive d’annulation)

La restauration doit être suffisamment « grossière » et peut être exécutée en un seul clic :

• Forcer tous les joueurs à suivre un certain modèle stable
• Ou corriger une certaine version de stratégie

Ne vous attendez pas à modifier temporairement le seuil en cas d’accident. Ce qu’il faut en cas d’accident, c’est la certitude.

Cas d’échec : “seuil adaptatif” apparemment intelligent

Nous avons ensuite essayé une approche plus « intelligente » : ajuster dynamiquement le seuil en fonction de la qualité du signal des 10 dernières minutes pour permettre au petit modèle d’avaler plus de trafic.

Le résultat est une auto-oscillation très typique :

• Les petits modèles avalent davantage et la qualité du signal se dégrade
• Le seuil est relevé, les gros modèles avalent davantage, et la qualité du signal devient meilleure.
• Le seuil est abaissé, et les petits modèles en avalent davantage

Extérieurement, cela ressemble à « des bons et des mauvais moments », mais en interne, la stratégie vacille.

S’il n’existe pas de numéro de version de politique ni de journal de décision pour ce type de problème, il est fondamentalement impossible de l’expliquer clairement, et encore moins de le résoudre.

Limites applicables

Le routage multimodèle n’est pas impossible, mais il est plus adapté aux équipes qui répondent aux prérequis suivants :

• Est-il acceptable de payer des frais supplémentaires de stockage et de conformité à la confidentialité pour la traçabilité ?
• Disposez de mesures de qualité et d’avertissements clairs, au lieu de vous fier aux plaintes des utilisateurs
• La stratégie peut-elle être maintenue sous la forme d’un « système en ligne » avec des versions, des niveaux de gris et des restaurations ?

Si l’observabilité actuelle est encore limitée au “volume des demandes, délai, code d’erreur”, alors ne vous précipitez pas pour effectuer un routage complexe. L’argent économisé peut être perdu pendant le temps de dépannage.

Résumé

La chose la plus sous-estimée à propos du routage multimodèle est qu’il modifie les objets de dépannage.

Ce qui était autrefois reproduit était une contribution, mais maintenant ce qui doit être reproduit, c’est une prise de décision. Sans journaux de décision, instantanés de requêtes et primitives de restauration, les échecs en ligne deviendront « aléatoires » et ne pourront être ni expliqués ni réparés.

Les comptes de réduction des coûts sont faciles à calculer, tandis que les comptes récurrents sont les plus difficiles à calculer, mais ils apparaîtront certainement dans le bilan des accidents à la fin.