Small Language Models : quand un petit modèle est le meilleur choix pour un assureur

Ce qu’il faut retenir

• Un small language model n’est pas défini par un plafond universel de paramètres. Il est « petit » relativement à une tâche, une famille de modèles et une enveloppe de calcul.
• Le bon objectif n’est pas de choisir le modèle le plus compact, mais le plus compact qui respecte les seuils d’erreur du cas d’usage, sur l’infrastructure réellement visée.
• Paramètres, taille du fichier, mémoire au pic, temps avant le premier token, débit et coût par dossier sont des mesures différentes. Aucune ne remplace les autres.
• Une exécution locale peut réduire certains flux vers un prestataire ; elle ne rend pas le service sûr par nature. Journaux, sauvegardes, mises à jour, comptes d’administration et données de test restent dans le périmètre.
• Distillation et quantification peuvent rendre un modèle plus exploitable. Leur effet sur les erreurs rares doit être testé sur l’artefact exact qui sera déployé.
• Le routage est un contrat observable : le SLM traite les cas admissibles, s’abstient lorsque les contrôles échouent et passe la main à une voie plus robuste ou à une personne.

Définir « petit » sans compter trop vite

Le terme SLM désigne couramment un modèle de langage plus compact que les grands modèles pris comme références à une date donnée. Cette définition est relative. Un modèle peut être petit dans un catalogue de modèles génératifs et trop lourd pour le serveur d’agence, le terminal ou le temps de réponse attendu. À l’inverse, un modèle plus volumineux peut rester le plus petit candidat qui réussit une tâche multilingue exigeante.

Le rapport technique Phi-3 emploie par exemple l’étiquette « small language model » pour un modèle de 3,8 milliards de paramètres. Ce chiffre illustre un usage du vocabulaire, pas une frontière normative. Il ne dit rien, à lui seul, sur les performances d’un modèle en assurance.

Le nombre de paramètres ne mesure pas directement la compétence. L’architecture, les données, le budget d’entraînement, la longueur d’entrée, la méthode d’alignement et la préparation de la requête modifient le résultat. Les travaux de Hoffmann et al. sur l’allocation du calcul d’entraînement étudient précisément l’interaction entre taille du modèle et quantité de données dans leur cadre expérimental. Ils ne fournissent ni règle universelle de dimensionnement ni résultat applicable tel quel aux dossiers d’assurance.

Paramètres, poids et mémoire ne sont pas synonymes

Une estimation élémentaire du stockage des poids vaut nombre de paramètres × bits par poids ÷ 8. Elle aide à contrôler un ordre de grandeur, mais elle n’est pas la mémoire nécessaire au service. Le processus charge aussi des métadonnées, des tampons du moteur, des activations et un cache de clés-valeurs qui varie avec le contexte, le lot et la concurrence. Le système d’exploitation, le pilote et le serveur d’inférence ajoutent leur propre réserve.

La question utile devient donc : « quel est le pic mémoire de cet artefact, avec notre longueur d’entrée et notre concurrence, sur ce matériel ? ». Une fiche annonçant seulement le nombre de paramètres ne permet pas de répondre.

Décrire la capacité attendue avant de comparer les modèles

Un SLM n’est jamais « assez bon » en général. Il peut être fiable pour classer une demande dans une taxonomie stable et insuffisant pour rapprocher des clauses, suivre une consigne longue ou produire un texte libre. Le cahier de test doit décomposer la capacité attendue en dimensions observables.

Dimension	Question de conception	Épreuve utile	Signal d’inadéquation
Périmètre	Les intentions et sorties sont-elles finies et stables ?	Cas courants, limites et demandes hors périmètre	Le modèle force une classe quand il devrait s’abstenir
Langue	Quelles langues, fautes et formulations sont réellement reçues ?	Corpus par langue, registre et qualité de saisie	Un score global masque un segment dégradé
Contexte	Quelle quantité d’information est indispensable à la décision ?	Messages courts, fils longs et documents tronqués	Le résultat change lorsque la condition décisive s’éloigne
Sortie	Une étiquette ou un JSON borné suffit-il ?	Validation de schéma et valeurs autorisées	Champs inventés, absents ou mal typés
Raisonnement	Faut-il combiner plusieurs pièces ou appeler un outil ?	Cas mono-indice et cas à preuves multiples	Réponse plausible sans trace des éléments utilisés
Robustesse	Quels pièges, ambiguïtés ou contenus hostiles sont plausibles ?	Négations, instructions contradictoires et bruit	Échec silencieux ou contournement des contraintes

Cette décomposition évite le faux raccourci « tâche simple = petit modèle ». Une tâche de classification peut devenir difficile lorsque les classes se chevauchent, que les conséquences d’une confusion sont fortes ou que les demandes arrivent dans plusieurs langues. Une génération plus longue peut au contraire être acceptable si elle reste un brouillon relu et n’active aucune décision.

Réduire l’espace de sortie lorsque le métier le permet

Un modèle compact bénéficie d’un contrat précis : taxonomie versionnée, schéma JSON fermé, exemples négatifs, consigne d’abstention et validation déterministe. Cette réduction n’ajoute pas magiquement une compétence. Elle rend toutefois les écarts plus visibles et empêche certaines sorties d’atteindre le système aval.

La validation de forme ne certifie pas le fond. Un JSON parfaitement conforme peut contenir la mauvaise intention. Il faut donc conserver deux mesures : validité technique et exactitude métier. L’article sur l’articulation entre déterministe, probabiliste et génératif montre comment placer ces contrôles autour d’un composant non déterministe.

Trouver la frontière tâche-modèle

La sélection d’un modèle est un problème sous contraintes. On cherche le candidat le moins exigeant qui franchit les seuils de qualité, de sûreté et de délai, pas le plus petit fichier disponible. Si aucun candidat compact ne passe, il faut élargir le modèle, réduire le périmètre ou maintenir une prise en charge humaine.

Étape	Décision	Preuve conservée
1. Cadrer	Fixer entrées, sorties, exclusions et conséquence de chaque erreur	Contrat de tâche et matrice des risques
2. Geler	Constituer un jeu de comparaison identique pour tous les candidats	Version des cas, annotations et consignes
3. Éliminer	Écarter tout candidat sous un seuil bloquant	Résultats par erreur critique et segment
4. Mesurer	Tester les survivants dans l’enveloppe matérielle cible	Latence, mémoire, débit et coût normalisés
5. Arbitrer	Choisir un point de la frontière qualité-ressources	Décision, alternatives et hypothèses

Pour rendre la comparaison honnête, utilisez la même consigne fonctionnelle et le même schéma de sortie. Une adaptation propre à un modèle peut être autorisée, mais elle doit être tracée et son coût de maintenance compté. Ne faites pas gagner un candidat grâce à vingt exemples manuellement optimisés si l’autre reçoit une instruction générique.

Le modèle plus grand sert de candidat, pas de vérité terrain. Les références restent les annotations validées, les règles métier et, si nécessaire, la décision humaine. Les frontier models en assurance peuvent élargir certaines capacités ; leur échelle n’en fait ni des arbitres juridiques ni des producteurs automatiques de bonnes réponses.

Mesurer coût, latence et mémoire sur la charge cible

Un benchmark de modèle réalisé hors du service peut inverser le classement réel. La longueur des entrées, le nombre de tokens produits, la concurrence, le traitement en lots, le démarrage à froid et le moteur d’inférence ont tous un effet. Il faut donc publier un protocole et non un seul chiffre de tokens par seconde.

Séparer attente initiale, génération et débit

• Temps avant le premier token : utile pour une interface interactive et sensible à la préparation du contexte.
• Temps total : mesure le délai jusqu’à la sortie complète et dépend de sa longueur.
• Débit : renseigne le volume traité par unité de temps, mais peut améliorer au prix d’une attente individuelle plus forte.
• Percentiles : p50, p95 et p99 révèlent une queue de latence qu’une moyenne efface.
• Stabilité : erreurs de mémoire, redémarrages et dégradation sous concurrence font partie du résultat.

Mesurez des profils courts, médians et longs issus de la distribution visée. Répétez à froid et à chaud, à une requête puis à la concurrence nominale et au pic. Les essais doivent tourner sur le même matériel, avec le même serveur, la même précision et les mêmes limites. L’analyse des coûts et de la latence pendant un pic de sinistres complète cette approche à l’échelle de la capacité.

Calculer un coût de service, pas seulement d’inférence

Pour un service hébergé, comptez l’usage facturé, la mise en cache éventuelle, le trafic, la rétention et l’effort d’intégration. Pour une exécution interne, comptez matériel ou location, taux d’utilisation, énergie si elle est suivie, exploitation, supervision, mises à jour, astreinte et capacité de secours. Divisez ensuite par une unité métier stable : dossier admissible, message classé ou sortie validée.

Un SLM sous-utilisé sur une machine réservée peut coûter davantage par dossier qu’un service partagé. Un modèle distant bon marché peut, à l’inverse, devenir inacceptable si ses conditions de données ou sa latence ne conviennent pas. Le dossier acheter ou construire une IA pour l’assurance aide à intégrer ces coûts non visibles dans la comparaison.

Traiter résidence, sécurité et données comme trois sujets liés

Installer un modèle dans une infrastructure maîtrisée peut éviter que le contenu des requêtes transite vers un service externe. Ce choix ne suffit pas à démontrer la résidence complète des données. Les images de conteneur, journaux, traces, tableaux de bord, sauvegardes, systèmes de support, registres de modèles et mécanismes de mise à jour créent d’autres flux.

La résidence décrit où les données sont traitées et conservées. La confidentialité dépend aussi de qui peut les lire. La sécurité couvre en plus identités, vulnérabilités, intégrité des artefacts, segmentation, supervision et reprise. Enfin, la conformité dépend du contexte juridique et contractuel ; elle ne découle pas du lieu d’hébergement seul.

Le principe de zero trust exposé par le NIST SP 800-207 ne confère pas de confiance implicite à un acteur ou un composant du seul fait de sa localisation réseau. Appliqué ici, il invite à authentifier, autoriser et journaliser les accès au service de modèle comme ceux de tout autre service sensible.

Cartographier les flux avant le choix d’hébergement

1. Inventorier la requête, le contexte ajouté, la sortie et les métadonnées techniques.
2. Tracer chaque stockage et chaque transfert, y compris observabilité, sauvegarde et support.
3. Qualifier les identités qui accèdent aux données et celles qui administrent la plateforme.
4. Définir minimisation, pseudonymisation, durée de conservation et procédure d’effacement.
5. Vérifier la provenance, l’intégrité et la mise à jour de l’artefact de modèle.
6. Tester le mode dégradé sans recopier de données sensibles dans des journaux de diagnostic.

Le profil NIST AI 600-1 pour l’IA générative propose des considérations de gestion des risques tout au long du cycle de vie. Le texte officiel du RGPD pose notamment des exigences de minimisation, de protection dès la conception et de sécurité du traitement. Ces références structurent les questions ; elles ne constituent pas, dans cet article, un avis de conformité pour un déploiement particulier.

Distillation et quantification : deux leviers différents

La distillation agit pendant l’apprentissage du modèle élève. Le travail fondateur de Hinton, Vinyals et Dean décrit le transfert d’un modèle ou d’un ensemble vers un modèle plus simple au moyen de cibles plus informatives que les seules étiquettes dures. DistilBERT fournit un exemple de distillation appliquée à un modèle de représentation linguistique. Ces résultats démontrent des techniques dans leurs cadres ; ils ne promettent aucune conservation uniforme des capacités d’un grand modèle génératif.

Un élève peut reproduire des comportements indésirables du professeur ou échouer sur des cas peu représentés. S’il est adapté avec des sorties synthétiques, il faut documenter leur origine, leurs filtres, leurs droits d’usage et le protocole de validation humaine. La comparaison doit porter sur professeur, élève et baseline simple, sur le même jeu gelé.

La quantification réduit la précision numérique de tout ou partie des poids, et parfois d’autres tenseurs selon la méthode. Elle peut diminuer l’empreinte et rendre un déploiement possible sur un matériel donné. AWQ est une méthode de quantification weight-only à faible nombre de bits étudiée pour des modèles de langage. Ses résultats ne permettent pas de conclure que toute quantification accélère toute charge.

Recetter l’artefact exact, pas le nom du modèle

Transformation	Peut modifier	À comparer	Prudence
Distillation	Architecture et comportement appris	Erreurs par classe, abstention, robustesse et dérive	L’élève ne reçoit pas une copie littérale de toutes les capacités
Quantification	Représentation numérique et parfois exécution	Mémoire au pic, qualité, latence et stabilité	Le gain dépend des noyaux, du matériel et de la charge
Adaptation métier	Distribution des réponses et respect du format	Généralisation hors exemples et régressions	Un petit jeu surappris peut donner une illusion de maîtrise

Conservez un identifiant cryptographique ou, au minimum, une version non ambiguë de l’artefact, la configuration de quantification, le moteur et le jeu de calibration. Une mise à jour apparemment mineure recrée un candidat et déclenche les tests bloquants.

Recette comparative : orienter une demande d’assurance

Le scénario suivant est pédagogique. Il ne décrit ni un client, ni un service en production, ni un niveau de performance constaté. Il sert à montrer comment comparer un SLM et un modèle plus grand sans leur demander une décision d’indemnisation.

La tâche consiste à lire le premier message d’un assuré et à produire un objet JSON avec une intention parmi declaration_sinistre, suivi_sinistre, document_manquant, question_echeance, resiliation ou hors_perimetre. Deux champs optionnels peuvent reprendre une référence explicitement écrite et la langue détectée. Le système n’interprète pas une garantie, ne propose pas de montant et n’envoie aucune réponse au client.

Construire le jeu de comparaison

1. Rédiger ou sélectionner des messages autorisés, puis retirer ou remplacer toute donnée personnelle non nécessaire.
2. Faire annoter chaque cas selon une consigne versionnée, avec double lecture pour les ambiguïtés et une issue « hors périmètre ».
3. Réserver le test final avant les ajustements ; éviter que ses formulations apparaissent dans les exemples de consigne ou d’adaptation.
4. Inclure des contrastes difficiles : « je veux déclarer » contre « où en est ma déclaration », document demandé contre pièce déjà envoyée, échéance de paiement contre échéance contractuelle.
5. Créer des segments rares mais importants : déclaration contenant une demande secondaire, négation, message multilingue, pièce évoquée sans contexte et instruction hostile insérée dans le texte.

Chaque candidat reçoit le même contrat de sortie, les mêmes exemples autorisés et les mêmes limites de génération. Les températures et mécanismes de décodage sont consignés. Plusieurs répétitions sont utiles si la configuration laisse subsister de la variabilité.

Mesurer la bonne erreur au bon niveau

Mesure	Ce qu’elle révèle	Découpe obligatoire
F1 macro par intention	Évite que les classes fréquentes absorbent le score	Intention, langue et longueur
Rappel « déclaration de sinistre »	Détecte les déclarations que le routeur manquerait	Demande principale et demande mêlée
Taux de routage critique erroné	Compte les confusions définies comme bloquantes	Type de conséquence
Exactitude des champs repris	Vérifie qu’une référence n’est pas créée ou altérée	Champ présent, absent et ambigu
Sortie invalide	Compte schémas cassés et valeurs inconnues	Modèle, artefact et moteur
Couverture après abstention	Montre la part vraiment traitée par le SLM	Seuil et motif de refus
Latence et mémoire au pic	Vérifie la faisabilité opérationnelle	Profil d’entrée et concurrence

L’exactitude brute peut être publiée en complément, jamais seule. Si 70 % des messages portent sur le suivi, un modèle qui privilégie cette classe peut sembler bon tout en perdant les déclarations. Le choix doit aussi comparer une baseline déterministe — règles sur un formulaire ou choix explicite — car un modèle n’est pas nécessaire lorsque l’entrée peut être structurée à la source.

Fixer des seuils par type d’erreur avant de voir les scores

Un seuil unique donne le même poids à des erreurs qui n’ont pas la même conséquence. Avant l’essai, attribuez à chaque confusion une classe de décision : bloquante, tolérable sous contrôle ou informative. Définissez ensuite un maximum, un minimum ou un intervalle et la taille d’échantillon nécessaire à l’interprétation.

Erreur pédagogique	Conséquence possible	Politique de passage	Réponse du système
Déclaration classée comme question générale	Retard de prise en charge	Seuil bloquant dédié	Fallback immédiat ou file prioritaire
Référence absente inventée	Mauvais rapprochement de dossier	Aucune valeur non ancrée dans l’entrée	Rejeter le champ et demander vérification
Sortie hors schéma	Échec d’intégration	Contrôle déterministe systématique	Une nouvelle tentative bornée, puis fallback
Question d’échéance envoyée en revue	Surcoût sans préjudice client direct	Budget de faux positifs	Accepter jusqu’au plafond opérationnel
Cas ambigu traité automatiquement	Confiance excessive	Mesure d’abstention et d’escalade	Demande de précision ou revue humaine

Le taux d’erreur observé sur un petit lot reste incertain. Conservez effectifs et intervalles, surtout lorsqu’un événement critique est rare. « Zéro erreur vue » ne signifie pas « risque nul ». Si le seuil ne peut pas être démontré avec assez de cas, la décision prudente est de limiter la couverture ou de maintenir la revue.

Évaluer le couple qualité-couverture

Une politique d’abstention augmente souvent la qualité des cas traités au prix d’une couverture plus faible. Tracez une courbe : pour chaque règle d’acceptation, combien de messages sont automatisés et combien d’erreurs de chaque classe subsistent ? Le score de confiance produit par le modèle n’est pas automatiquement calibré. Il doit être comparé à la fréquence réelle des erreurs, par segment et par version.

Un modèle plus grand doit passer exactement les mêmes seuils. Il peut réduire certaines confusions et en introduire d’autres, notamment produire une sortie plus convaincante lorsqu’il manque une preuve. La taille ne remplace jamais l’abstention.

Construire un routage explicable et un fallback fini

Le routeur décide avant ou après un premier passage, à partir de signaux que l’équipe peut auditer. Les travaux RouteLLM étudient des routeurs appris entre modèles plus faible et plus fort à partir de données de préférence. Ils démontrent une approche de recherche sur leurs évaluations, pas une économie garantie ni une sûreté démontrée pour l’assurance.

1. Admission : langue autorisée, taille compatible, canal connu, données permises et service disponible.
2. SLM : production de la classe et des champs dans le schéma fermé.
3. Contrôles : validation JSON, valeurs autorisées, référence présente dans l’entrée et règles critiques.
4. Acceptation : résultat transmis seulement si tous les critères du segment sont franchis.
5. Fallback : modèle plus capable si son usage est autorisé, ou file humaine ; les mêmes contrôles s’appliquent.
6. Clôture : aucun nouvel essai après le budget fixé ; journalisation du motif et issue explicite.

Préférer des signaux contrôlables

La longueur, la langue, le canal, la présence des champs minimaux, le type de document, l’échec du schéma et les règles de sécurité sont observables. Une probabilité calibrée sur un jeu indépendant peut compléter ces signaux. Une auto-évaluation textuelle du modèle — « je suis sûr » — ne suffit pas.

Le modèle de fallback n’est pas obligé d’être distant ni plus grand dans tous les cas. Une règle peut envoyer une déclaration vers un formulaire sécurisé, une demande ambiguë vers une personne et seulement une formulation complexe vers un modèle plus capable. La conception détaillée du routeur de modèles pour l’assurance aide à formaliser ces chemins, tandis que l’article sur la fenêtre de contexte d’un dossier rappelle qu’ajouter plus de texte ne corrige pas automatiquement une mauvaise sélection d’information.

Empêcher les boucles et les coûts invisibles

• Limiter le nombre de tentatives et interdire le retour indéfini entre deux modèles.
• Attribuer un identifiant de corrélation sans placer le message complet dans tous les journaux.
• Conserver le motif de route, la version des modèles, les contrôles exécutés et l’issue.
• Appliquer un budget par demande et un coupe-circuit en cas de surcharge.
• Tester la voie humaine, les files d’attente et le rattrapage après incident.

Le coût du système se calcule avec le taux de passage vers chaque voie. Un SLM très bon marché qui escalade presque tout peut augmenter la latence totale. À l’inverse, une couverture modeste mais stable sur un flux abondant et bien borné peut suffire à justifier son exploitation.

Constituer le dossier de décision et organiser la réversibilité

Une décision solide tient dans un dossier reproductible : contrat de tâche, versions des données, artefacts, résultats par segment, mesures d’infrastructure, cartographie des flux, matrice d’erreurs, règles de routage et responsables. Le document indique aussi pourquoi les candidats écartés ne conviennent pas.

Checklist avant un pilote limité

• La tâche, les exclusions et la sortie sont définies sans vocabulaire marketing.
• Le jeu final n’a pas servi à régler les exemples, les seuils ou l’adaptation.
• Chaque erreur critique dispose d’une mesure, d’un seuil et d’une action.
• La baseline déterministe, le SLM et le candidat plus grand ont été comparés.
• L’artefact exact, y compris sa quantification, a passé la recette.
• Les mesures p95/p99, mémoire au pic et concurrence proviennent du matériel cible.
• Les flux de données, accès, journaux, sauvegardes et mises à jour sont cartographiés.
• L’abstention, le fallback, le coupe-circuit et la prise en charge humaine sont testés.
• La dérive des entrées et les erreurs par segment seront suivies après le pilote.
• Le retour à la version précédente est documenté et réalisable.

Le pilote commence sur un périmètre réversible et sans décision irrévocable. Une nouvelle langue, une taxonomie modifiée, un moteur différent, une quantification nouvelle ou une dérive des messages déclenchent au moins la partie concernée de la recette. Les erreurs collectées ne doivent pas être réinjectées dans un entraînement sans vérification de leurs droits, de leur qualité et de leurs données personnelles.

La bonne question finale n’est donc pas « pouvons-nous remplacer le grand modèle ? ». Elle est : « sur quelle fraction explicitement bornée du flux cet artefact respecte-t-il nos seuils, avec quel coût complet, quelles données et quelle voie de secours ? ». Un SLM devient le meilleur choix lorsque cette réponse est documentée et reste vraie sous la charge réelle.

Sources et références primaires

• Phi-3 Technical Report — exemple documenté de l’emploi du terme SLM ; aucune performance transposée à l’assurance.
• Training Compute-Optimal Large Language Models — relation étudiée entre paramètres, données et calcul dans le cadre des auteurs.
• Distilling the Knowledge in a Neural Network et DistilBERT — mécanisme et exemple de distillation.
• AWQ — méthode primaire de quantification weight-only.
• NIST AI 600-1 et NIST SP 800-207 — gestion des risques de l’IA générative et architecture zero trust.
• Règlement général sur la protection des données — texte juridique officiel ; aucune conclusion de conformité individuelle n’est formulée ici.
• RouteLLM — recherche primaire sur le routage entre modèles ; résultats limités au protocole publié.