Distillation d’un modèle IA : le petit élève peut aussi copier son professeur

La distillation des connaissances entraîne un modèle « élève », généralement plus petit, à imiter les sorties d’un modèle « enseignant » plus puissant. Elle peut réduire les ressources nécessaires à l’inférence, mais elle ne transfère pas automatiquement les paramètres du professeur ni l’ensemble de ses capacités.

Le même mécanisme peut donc servir deux finalités : compresser un système avec l’autorisation de son propriétaire, ou reproduire une partie de sa valeur fonctionnelle en collectant méthodiquement les réponses de son API. Le risque dépend moins du mot « distillation » que des droits accordés, de la manière d’obtenir les sorties et des capacités laissées à celui qui interroge le service.

Ce que l’élève copie réellement

Dans la forme la plus simple, l’enseignant traite un ensemble d’entrées et produit des réponses, des probabilités ou d’autres signaux d’apprentissage. L’élève reçoit des entrées comparables, puis ses poids sont ajustés afin de rapprocher ses résultats de ceux du professeur. Le guide AI Insights du gouvernement britannique présente ce transfert de comportement vers un modèle plus petit et distingue notamment les méthodes fondées sur les réponses, les représentations intermédiaires et les étapes de raisonnement.

Prenons un exemple conditionnel qui servira de fil conducteur : une entreprise possède un assistant chargé de classer les demandes reçues par son support. Elle soumet des cas représentatifs au grand modèle, conserve ses classifications, puis entraîne un modèle compact à reconnaître les mêmes catégories. L’élève peut apprendre à distinguer une panne, une demande de remboursement et une question commerciale sans devenir une réplique complète de l’enseignant.

Sa couverture reste celle des exemples et des signaux qu’il a rencontrés. Un élève performant sur un périmètre stable peut échouer lorsque changent la langue, le domaine ou la forme des requêtes ; il peut aussi reproduire des erreurs et des biais présents dans les sorties utilisées pour l’entraînement.

Pourquoi la compression est utile sans être gratuite

Le bénéfice apparaît après l’entraînement : les demandes courantes peuvent être confiées au modèle compact plutôt qu’au professeur plus exigeant en calcul. Dans notre exemple, le grand modèle peut rester réservé aux dossiers ambigus, tandis que l’élève traite un périmètre étroit sur une infrastructure plus modeste. Le gain réel doit toutefois être mesuré sur la tâche et le matériel visés, pas déduit de la seule différence de taille.

Cette organisation suppose une procédure de repli lorsque la demande sort du périmètre appris. Elle exige aussi de sélectionner les données, d’entraîner le modèle, de valider ses résultats et de le réévaluer lorsque les règles du support évoluent. La distillation réduit potentiellement le coût de chaque inférence ; elle ne supprime ni le coût initial ni la maintenance.

Compression autorisée, données publiques et extraction par API

La compression autorisée est le cas le plus net : l’organisation contrôle l’enseignant ou dispose d’un contrat et de licences permettant l’usage de ses sorties pour entraîner l’élève. Le corpus, la finalité et les critères de validation peuvent alors être définis dans le cadre du projet.

L’apprentissage sur des réponses publiques est plus ambigu. La visibilité d’un texte ne suffit pas à déterminer si sa réutilisation est permise : il faut considérer les conditions du service, les licences, la provenance des données, les obligations de confidentialité et le droit applicable. « Accessible » ne signifie donc pas automatiquement « réutilisable sans restriction ».

L’extraction organisée commence lorsqu’un acteur construit méthodiquement un corpus à partir d’une interface qu’il ne contrôle pas : il couvre les fonctions du service, repère les zones mal reproduites et adapte ses requêtes. Les travaux publiés à USENIX Security sur l’extraction de modèles ont montré, pour plusieurs classes de modèles et services étudiés, qu’un accès en boîte noire à une API de prédiction pouvait suffire à dupliquer étroitement sa fonctionnalité sans révéler ses paramètres ni ses données d’entraînement.

Il n’existe pas de seuil universel séparant un client intensif d’une tentative d’extraction. L’autorisation, la finalité, l’automatisation, la couverture systématique des capacités, le contournement des limites et la réutilisation des réponses forment ensemble un faisceau d’indices. Un grand volume peut correspondre à un usage légitime, tandis qu’une collecte plus petite mais soigneusement ciblée peut être plus informative.

Les trois budgets qui changent l’évaluation du risque

Compter uniquement les appels à l’API décrit mal la menace. L’étude de Lena Libon et ses coauteurs propose d’expliciter trois dimensions — budget de requêtes, budget de données et profil d’interface — et montre que le jugement porté sur une défense peut changer selon les capacités attribuées à l’attaquant.

• Le budget de requêtes couvre tous les appels disponibles, y compris les tentatives répétées sur une même entrée.
• Le budget de données correspond aux exemples distincts que l’acteur peut réunir ou produire ; leur diversité peut compter davantage qu’un volume de doublons.
• Le profil d’interface décrit ce que l’API accepte et révèle : types d’entrées, réponses multiples, probabilités, paramètres disponibles et traitements appliqués par le fournisseur.

Dans notre exemple, un plafond quotidien par compte réduit le budget visible sans nécessairement couvrir plusieurs comptes, la sélection stratégique des demandes ou le retraitement local des réponses. Une évaluation crédible doit donc annoncer son modèle de menace et éprouver plusieurs profils, au lieu de transformer un résultat obtenu sous des hypothèses étroites en garantie générale.

Ce que les défenses peuvent — et ne peuvent pas — faire

Une première couche combine authentification, quotas, plafonds de dépenses et limitation du débit. L’analyse peut agréger les signaux par compte, organisation, moyen de paiement et comportement afin de repérer une collecte répartie. La cadence seule ne suffit pas : la répétition, la diversité des sujets et l’exploration méthodique des limites du service apportent un contexte plus utile.

Une deuxième couche consiste à n’exposer que les fonctions nécessaires. Retirer des probabilités détaillées, limiter certains paramètres ou réserver des interfaces riches à des clients vérifiés réduit l’information disponible, sans rendre l’extraction impossible : des étiquettes ou des réponses textuelles peuvent encore devenir des cibles d’entraînement.

Les défenses par perturbation modifient les sorties pour gêner l’apprentissage d’un imitateur tout en cherchant à préserver l’utilité pour le client légitime. Leur compromis est fragile : une modification forte peut dégrader le service normal, alors qu’un attaquant peut parfois répéter les appels, filtrer les résultats ou les retraiter. Leur efficacité n’a donc de sens qu’en précisant les trois budgets retenus.

Enfin, les contrôles techniques gagnent à être associés à des conditions contractuelles explicites, à une journalisation proportionnée et à une procédure de traitement des abus. Aucun signal isolé ne prouve une extraction et aucune mesure ne garantit qu’un comportement observable ne sera jamais imité. L’objectif réaliste est de rendre la collecte plus coûteuse, moins informative et plus détectable sans neutraliser l’usage normal de l’API.

À lire aussi:

• Automatiser une campagne créateur peut aussi automatiser ses angles morts
• Céder ses droits à une marque : « monde entier » peut durer toute une vie
• Claude filigrane désormais ses textes : le copier-coller laisse une trace