Régression de capacités
Améliorer le comportement visé peut dégrader des compétences sans rapport, la calibration ou le comportement de sûreté.
Contrôle : Conservez une suite de régression figée sur le modèle de base et comparez-y chaque candidat.
Guide du fine-tuning
Risques et questions ouvertes du fine-tuning
Le fine-tuning est une expérience, pas une amélioration garantie. La vraie question est de savoir si un candidat améliore une charge de travail définie sans régressions, fuites, coûts ou risques opérationnels inacceptables.
Risques à traiter avant la mise en production
Mémorisation et fuite de données personnelles
Des enregistrements sensibles, dupliqués ou identifiables de façon unique peuvent être appris puis reproduits.
Contrôle : Minimisez et dédupliquez les données, documentez la provenance, recherchez secrets et données personnelles, et menez des tests d’extraction.
Empoisonnement et déclencheurs cachés
Des exemples non fiables ou mal revus peuvent enseigner un comportement indésirable ou des portes dérobées.
Contrôle : Restreignez les accès en écriture, conservez la traçabilité, examinez les anomalies et testez des entrées ressemblant à des déclencheurs avant la promotion.
Fuite d’évaluation
Un modèle peut sembler meilleur lorsque les exemples d’entraînement recoupent les cas de test ou qu’une métrique se substitue à l’objectif produit.
Contrôle : Dédupliquez entre les découpages, gardez un jeu de test scellé et combinez métriques de tâche, revue humaine et revue de sûreté.
Dérive de distribution
Les gains hors ligne peuvent ne pas résister aux entrées réelles, à des règles qui changent ou à un autre template de service.
Contrôle : Testez un trafic proche de la production, surveillez les segments et les abstentions, et définissez des seuils de retour arrière.
Dépendance opérationnelle
Un fournisseur ou un framework peut ne pas exporter les adaptateurs, l’état de l’optimiseur ou un checkpoint déployable.
Contrôle : Confirmez la propriété des artefacts, les formats d’export, la conservation, la suppression, la région et le support du retour arrière avant d’entraîner.
Critère de qualité
- • Cas réservés spécifiques à la tâche
- • Régressions des capacités de base
- • Revue humaine avec une grille écrite
- • Intervalles de confiance ou runs répétés quand c’est possible
Critère de sûreté
- • Cas de détournement et d’injection de prompt
- • Tentatives d’extraction de données sensibles
- • Segments de biais et de sorties nuisibles
- • Régressions de politique et de refus
Critère d’exploitation
- • Données, code, poids et réglages versionnés
- • Déploiement canary et retour arrière
- • Limites de latence, de débit et de coût
- • Responsable, alertes, procédure d’incident et plan de retrait
Questions auxquelles le benchmark doit répondre
- 1. Quelle erreur visible par l’utilisateur l’entraînement doit-il réduire ?
- 2. Quelle référence en prompt seul, en recherche documentaire ou en appel d’outils doit-il dépasser ?
- 3. Quels segments d’utilisateurs et cas rares sont représentés dans le jeu de test ?
- 4. Quel budget de régression est acceptable en dehors de la tâche visée ?
- 5. Quelle métrique ou quelle décision de relecteur bloque le déploiement ?
- 6. Le résultat peut-il être reproduit à partir d’entrées versionnées et d’un environnement propre ?
Références principales
Ces sources proposent des méthodes et des preuves ; aucune n’établit un résultat universel en production.