Log Probability Tracking of LLM APIs

Cette étude propose une méthode de surveillance continue et peu coûteuse des API de modèles de langage en utilisant les probabilités logarithmiques (logprobs) pour détecter des modifications infimes, surpassant ainsi les techniques existantes en sensibilité et en efficacité.

L'essentiel

🕵️‍♂️ Le Détective des Modèles : Comment savoir si un LLM a changé sans le savoir ?

Imaginez que vous commandez un café dans une chaîne de magasins. Vous vous attendez à ce que votre "Latte" ait toujours le même goût, la même température et la même mousse, peu importe le jour ou le magasin. Si demain, le café a un goût bizarre ou est moins chaud, vous vous demanderez : "Qu'est-ce qui a changé ?"

C'est exactement le problème avec les Intelligences Artificielles (LLM) que nous utilisons via des sites web ou des applications. Les fournisseurs (comme OpenAI, Google, etc.) disent : "Ne vous inquiétez pas, notre modèle est stable." Mais en réalité, ils peuvent modifier le modèle en coulisses pour le rendre plus rapide, moins cher, ou même à cause d'une erreur. Et nous, les utilisateurs, n'avons aucun moyen de vérifier si notre "Latte" est toujours le même.

Les méthodes actuelles pour vérifier cela sont comme essayer de goûter le café en commandant 100 tasses à chaque fois et en les comparant une par une. C'est trop long, trop cher et trop compliqué à faire tous les jours.

💡 La Révolution : Écouter le "Souffle" du modèle

Dans ce papier, les chercheurs (Timothée Chauvin et son équipe) ont trouvé une astuce géniale. Au lieu de regarder le mot final que l'IA produit (le café), ils écoutent le "souffle" ou l'hésitation de l'IA juste avant de choisir ce mot.

En langage technique, cela s'appelle les "log-probabilités".

• L'analogie : Imaginez que l'IA est un chef cuisinier qui doit choisir un ingrédient. Avant de dire "Je prends le sel", il hésite un instant. Il pense : "Le sel, c'est 90% probable. Le poivre, c'est 5%. La cannelle, c'est 0,1%."
• Les méthodes anciennes regardent seulement le mot final : "Ah, il a mis du sel."
• La nouvelle méthode (appelée LT ou Log Probability Tracking) écoute les pourcentages d'hésitation : "Tiens, aujourd'hui, il hésite beaucoup plus entre le sel et le poivre qu'hier. Quelque chose a changé dans sa recette."

🚀 Comment ça marche ? (La méthode du "X")

L'équipe a découvert qu'ils n'ont pas besoin de poser de questions complexes.

1. Ils envoient un message ultra-court, juste une lettre : "x".
2. Ils demandent à l'IA de répondre par un seul mot.
3. Ils regardent les chiffres d'hésitation (les log-probabilités) de ce mot.

C'est comme si vous demandiez au chef cuisinier : "Donne-moi juste un grain de sel." Et vous analysez la façon dont il le saisit. Si sa main tremble différemment aujourd'hui par rapport à hier, vous savez qu'il a changé de recette, même si le grain de sel semble identique.

Le résultat ?

• Sensibilité extrême : Ils peuvent détecter un changement aussi minuscule qu'une seule étape d'apprentissage (un "fine-tuning"). C'est comme détecter qu'un cuisinier a ajouté une pincée de sel en plus, alors que les autres méthodes ne le remarquent qu'après avoir ajouté une cuillère entière.
• Coût dérisoire : C'est 1 000 fois moins cher que les méthodes actuelles. Au lieu de commander 100 cafés, vous n'en commandez qu'un seul, et vous écoutez le bruit de la machine à café.

🛠️ Le "TinyChange" : Le laboratoire de test

Pour prouver que leur méthode fonctionne, les chercheurs ont créé un nouveau jeu appelé TinyChange.
Imaginez que vous prenez un gâteau (le modèle original) et que vous créez 58 versions légèrement modifiées :

• Parfois, vous enlevez un peu de farine (suppression de poids).
• Parfois, vous ajoutez un peu de bruit (du sel dans le sucre).
• Parfois, vous faites juste une étape de cuisson de plus.

Ils ont testé leur détective sur ces gâteaux. Résultat ? Le détective a réussi à repérer les changements les plus infimes, là où les autres détectives (les anciennes méthodes) étaient aveugles.

🌍 Dans la vraie vie : Ce qu'ils ont trouvé

Les chercheurs ont utilisé leur méthode pour surveiller 189 services d'IA différents pendant 4 mois.

• Ils ont envoyé des milliers de petits messages "x" chaque heure.
• Ils ont découvert 37 changements cachés.
• Souvent, ces changements concernaient des modèles que l'on croyait stables (des modèles "open source").

C'est comme si vous découvriez que votre chaîne de café préférée changeait secrètement sa recette chaque semaine, et que personne ne le savait sauf vous.

⚠️ Les limites (Le petit bémol)

Pour que cette méthode fonctionne, le fournisseur d'IA doit accepter de vous donner les "chiffres d'hésitation" (les log-probabilités).

• Certains fournisseurs pourraient dire : "Non, on ne vous donne que le mot final."
• Ou pire, ils pourraient essayer de tricher en donnant une réponse "faussement stable" uniquement quand ils voient votre petit message "x". Mais c'est difficile à faire sans casser le service pour les autres utilisateurs.

🎯 En résumé

Ce papier nous dit : "Arrêtez de payer cher pour vérifier les IA. Écoutez simplement leur hésitation."

C'est une arme puissante pour :

1. Les chercheurs : Pour s'assurer que leurs expériences sont reproductibles.
2. Les développeurs : Pour éviter que leurs applications ne cassent à cause d'un changement caché.
3. La sécurité : Pour repérer si quelqu'un a injecté un virus ou un "backdoor" dans le modèle.

C'est une petite révolution : un outil simple, pas cher et très sensible pour garder un œil sur la boîte noire des intelligences artificielles.

Résumé technique

1. Problématique et Contexte

L'utilisation de modèles de langage (LLM) via des API repose sur une attente fondamentale : la cohérence du modèle servi au fil du temps. Cette stabilité est cruciale pour la fiabilité des applications en aval et la reproductibilité de la recherche. Cependant, les fournisseurs d'API modifient fréquemment leurs infrastructures (matériel, logiciels d'inférence) ou leurs modèles (fine-tuning, quantification, mises à jour de sécurité, voire injections de backdoors malveillantes) sans toujours le signaler explicitement.

Le problème majeur identifié est l'absence de méthodes de surveillance pratiques et économiques. Les techniques d'audit existantes nécessitent un traitement massif de tokens de sortie et des benchmarks étendus, ce qui les rend trop coûteuses pour une surveillance continue. Par conséquent, les mises à jour de modèles restent largement non surveillées, créant un risque pour la sécurité et la reproductibilité.

2. Méthodologie : Le Suivi des Log-Probabilités (Logprob Tracking - LT)

Les auteurs proposent une méthode novatrice appelée Logprob Tracking (LT) qui exploite les log-probabilités (logprobs) des tokens générés plutôt que les tokens eux-mêmes.

Principes de base

• Source d'information : Contrairement aux tokens (discrétisés), les logprobs fournissent une information continue et dense sur la distribution de probabilité du modèle avant l'échantillonnage. De nombreuses API (environ 23 % sur OpenRouter) permettent de récupérer les logprobs des $k$ meilleurs tokens.
• Défi de la non-déterminisme : En pratique, les logprobs ne sont pas déterministes à cause du sampling par température et des variations d'infrastructure (chargement GPU, batchs dynamiques). Ils fluctuent autour d'une moyenne.
• Approche statistique : Pour contourner cette non-déterminisme, les auteurs traitent chaque logprob retourné comme un échantillon d'une distribution sous-jacente. Ils utilisent un test d'hypothèse par permutation (permutation test) pour comparer deux distributions.

Algorithme de détection

1. Entrée : Un prompt unique (même un seul caractère, ex: "x") est envoyé à deux API (ou à la même API à deux moments différents).
2. Échantillonnage : On demande la génération d'un seul token de sortie et on récupère les logprobs des $k$ meilleurs tokens pour $N$ itérations.
3. Statistique de test : On calcule la distance absolue moyenne entre les logprobs moyens de chaque token pour les deux distributions.
4. Décision : Un test de permutation est appliqué pour obtenir une valeur $p$. Si $p < \alpha$, on rejette l'hypothèse nulle (les distributions sont identiques) et on conclut à un changement de modèle.

3. Contributions Clés

1. Méthode Logprob Tracking (LT) : Démonstration qu'un prompt d'un seul token et les logprobs d'un seul token de réponse suffisent à détecter des changements avec une sensibilité supérieure aux méthodes existantes, à un coût dérisoire.
2. Benchmark TinyChange : Introduction d'un nouveau benchmark conçu pour évaluer la sensibilité des méthodes de détection face à des modifications de modèles minimes et réalistes. Il génère 58 variantes de modèles (de 0,5B à 8B paramètres) via :
   • Fine-tuning (1 à 512 étapes).
   • Fine-tuning LoRA.
   • Élagage (pruning) de poids (de $2^{-10}$ à 100%).
   • Ajout de bruit gaussien aux paramètres.
3. Évaluation Comparative : Une comparaison exhaustive contre deux méthodes de l'état de l'art (MET et MMLU-ALG), démontrant la supériorité de LT en termes de sensibilité et de coût.

4. Résultats Expérimentaux

Les expériences ont été menées sur 5 modèles open-weight et 189 endpoints d'API réels.

• Sensibilité extrême : La méthode LT est capable de détecter des changements aussi infimes qu'une seule étape de fine-tuning.
  • Pour l'élagage de poids, LT détecte des changements à un niveau de difficulté de $2^{-10}$, là où les méthodes de référence (MET, MMLU-ALG) échouent jusqu'à $2^{-1}$ ou $2^{-4}$.
  • LT est 2 à 3 ordres de grandeur plus sensible que les méthodes existantes.
• Coût réduit :
  • LT nécessite seulement 28 tokens d'entrée et 20 tokens de sortie par test.
  • Comparé aux méthodes existantes (nécessitant des milliers de tokens), LT est 1 000 fois moins cher.
  • Le coût estimé pour une surveillance horaire annuelle est de 0,14 $ contre 146 $à 332$ pour les autres méthodes.
• Robustesse du prompt : La longueur du prompt a un impact négligeable sur la performance. Un prompt d'un seul token ("x") est presque aussi efficace que des prompts longs, ce qui maximise l'efficacité des coûts.
• Déploiement réel : Sur 4 mois de surveillance de 189 endpoints, 37 changements suspects ont été détectés, affectant majoritairement des modèles open-weight, prouvant que les changements non documentés sont omniprésents.

5. Signification et Impact

Ce travail remet en question la fiabilité actuelle des API de LLM en démontrant que :

1. La transparence est possible à bas coût : Il est techniquement et économiquement viable de surveiller continuellement les API pour détecter des dérives de modèles.
2. Les changements subtils sont détectables : Même des modifications infimes (un pas de fine-tuning) laissent des traces statistiques dans les logprobs, rendant les modèles "noir" moins opaques qu'on ne le pensait.
3. Nouvelles normes de surveillance : LT propose une première ligne de défense légère pour les développeurs, chercheurs et régulateurs. Elle peut être intégrée dans des pipelines d'audit pour déclencher des investigations plus approfondies uniquement lorsque des changements sont détectés.

En conclusion, le papier établit que l'exploitation des log-probabilités, couplée à des tests statistiques simples, permet de transformer la surveillance des LLM d'une tâche coûteuse et rare en une pratique continue, abordable et hautement sensible.