Combien d’exemples faut-il vraiment pour ajuster un petit modèle sur une tâche de classification ? Chez Les Ateliers du Partage, association qui reçoit chaque semaine plusieurs dizaines d’emails de bénévoles, de donateurs et de bénéficiaires, la réponse tenait en un chiffre modeste : cent vingt exemples annotés à la main ont suffi pour un premier ajustement exploitable, loin des dizaines de milliers d’exemples souvent évoqués pour du fine-tuning classique.
Le besoin de départ était simple : chaque email reçu sur l’adresse générique de contact devait être classé dans l’une de cinq catégories (don, bénévolat, demande d’aide, presse, autre) avant sa conversion automatique en ticket HubSpot, pour que chaque service concerné retrouve directement dans sa file les messages qui le concernent. Un prompt générique donnait des résultats corrects mais coûteux à chaque appel, avec un taux d’erreur qui augmentait légèrement à mesure que de nouveaux types d’emails, non anticipés dans le prompt, arrivaient.
Pourquoi un fine-tuning léger plutôt qu’un prompt plus long
Un prompt de classification, pour rester fiable, tend à s’allonger au fil du temps : chaque cas particulier rencontré appelle une nouvelle règle ajoutée au texte, jusqu’à obtenir un prompt de plusieurs centaines de mots qu’il faut relire et maintenir. Le fine-tuning léger d’un modèle de petite taille inverse cette logique : au lieu d’expliquer les règles, on montre des exemples, et le modèle en déduit la logique de classification lui-même.
Cette approche convient particulièrement bien à une tâche répétitive et bien délimitée comme celle-ci, avec un nombre restreint de catégories stables dans le temps. Elle serait en revanche mal adaptée à une tâche qui évolue rapidement, où chaque nouvelle catégorie exigerait un nouveau cycle d’entraînement complet.
Étape 1 : constituer le jeu d’exemples
Les cent vingt exemples ont été extraits des emails déjà archivés des six derniers mois, classés manuellement par un salarié de l’association qui connaissait bien les catégories attendues. L’attention a porté sur la diversité des formulations plutôt que sur leur seul volume : des emails courts et des emails longs, des messages bien structurés et d’autres écrits dans l’urgence, avec des fautes d’orthographe conservées telles quelles pour refléter la réalité des messages reçus.
{"messages": [
{"role": "user", "content": "Bonjour, je souhaite faire un don ponctuel, comment procéder ?"},
{"role": "assistant", "content": "don"}
]}
{"messages": [
{"role": "user", "content": "j aimerais donner un peu de mon temps le we"},
{"role": "assistant", "content": "benevolat"}
]}Étape 2 : lancer l’ajustement
- Exporter le jeu d’exemples au format attendu par la plateforme de fine-tuning, un fichier JSONL avec une paire question-réponse par ligne.
- Lancer un premier entraînement avec les paramètres par défaut, sans ajustement fin des hyperparamètres à ce stade.
- Tester le modèle obtenu sur un jeu de validation distinct, composé de trente emails jamais vus pendant l’entraînement.
- Mesurer le taux de bonne classification et identifier les catégories les plus souvent confondues.
Étape 3 : corriger les confusions récurrentes
Le premier modèle confondait régulièrement « demande d’aide » et « bénévolat » sur les emails de personnes proposant à la fois leur aide et évoquant leur propre situation difficile, un cas de figure sous-représenté dans le jeu d’entraînement initial. Une vingtaine d’exemples supplémentaires, ciblés spécifiquement sur cette ambiguïté, ont suffi à faire nettement baisser le taux de confusion lors d’un second cycle d’entraînement.
Étape 4 : brancher la sortie vers HubSpot
La catégorie prédite par le modèle ajusté alimente une propriété personnalisée du ticket HubSpot créé à partir de chaque email entrant, via l’API de création de tickets. Le modèle ne fait que classer ; c’est un workflow HubSpot existant, non modifié pour ce projet, qui se charge ensuite de router le ticket vers la bonne équipe selon la valeur de cette propriété.
Un petit modèle bien ajusté sur cent exemples pertinents bat souvent un grand modèle interrogé avec un prompt générique : la qualité des exemples compte plus que la taille du modèle sur ce type de tâche bornée.
En résumé
Le fine-tuning léger n’a rien d’une opération réservée aux grandes équipes disposant de volumes massifs de données : sur une tâche de classification simple et stable, cent vingt exemples soigneusement choisis ont suffi à obtenir un modèle plus fiable et moins coûteux qu’un prompt générique appelé à chaque email. La configuration du CRM lui-même, elle, n’a pas eu besoin d’être retouchée pour accueillir ce nouveau champ de classification.
