Petits modèles locaux : trois usages efficaces

Les petits modèles de langage ne sont pas des oracles, mais ils excellent quand la connaissance vient de l’extérieur. Une règle simple aide à choisir : si la tâche exige des faits issus des poids, viser un grand modèle distant ; si elle fournit son propre matériau, un modèle local peut convenir. Trois cas d’usage s’imposent alors — latence, volume, données confinées — à condition de contourner raisonnement étendu, rappel et contexte efficace.

Choisir local ou distant : la règle qui tranche

Les besoins de conformité, de coût et de latence décrivent trois familles d’usages distinctes. Leur point commun est que la connaissance reste en dehors du modèle : un schéma apporte la structure, un jeu d’étiquettes borne les réponses, l’écran fournit le texte de référence. Chacun de ces éléments se vérifie contre la sortie, et le modèle n’est sollicité que pour exécuter la tâche avec ce qui lui est remis. Cette règle de sélection guide le choix de l’outil. Si une tâche réclame au modèle des faits issus de ses propres poids, un petit modèle local n’est pas le bon candidat et un grand modèle distant convient mieux, même s’il demeure incertain. À l’inverse, lorsque la tâche apporte son propre matériau, un petit modèle exécuté sur le matériel de l’entreprise peut faire l’affaire.

Latence : des micro-tâches lues à l’écran, en continu

La latence constitue un enjeu à part entière. Un modèle qui répond en quelques centaines de millisecondes depuis la mémoire locale ne se résume pas à une version accélérée d’un service qui met deux secondes sur un réseau : c’est un autre type d’outil, que l’on accepte d’invoquer très souvent. Les tâches adaptées sont courtes, répétées des dizaines de fois par heure, et si élémentaires qu’une capacité supplémentaire ne change rien de perceptible. L’entrée est brève et déjà visible, l’utilisateur lit la sortie au fil de l’eau et les erreurs apparaissent aussitôt, sans dépendance au rappel. C’est précisément le terrain où un petit modèle fonctionne le mieux et où le temps de réponse pèse sur le coût perçu. Les écueils surviennent en nourrissant le modèle avec un fichier entier plutôt qu’une sélection — un champ, une ligne, un paragraphe — ce qui réactive les limites de contexte. Un résumé qui ignore totalement le milieu d’un document peut passer inaperçu. À l’inverse, les tâches dont la sortie est affichée au premier plan se prêtent bien à ce format local.

Volume : un tri en deux niveaux et des escalades ciblées

Lorsque l’arithmétique domine, le coût par élément d’un modèle de pointe peut être insignifiant pour quarante documents mais devenir prohibitif à quatre cent mille. Les tâches de classification et d’étiquetage en masse — classer des tickets de support par sujet, ranger des archives par type, aiguiller le courrier entrant — sont formées d’atomes décisionnels simples : choisir une étiquette dans une courte liste. Si elles traînent, c’est rarement par difficulté intrinsèque, mais par incapacité à justifier le coût à grande échelle. L’inférence locale rebat ce calcul, avec une limite claire : un petit modèle trie très bien les cas faciles et juge mal les cas difficiles. La configuration efficace est alors à deux niveaux : le modèle local traite la grande majorité et les cas incertains montent vers un modèle plus grand lorsque c’est autorisé, ou vers une personne. Ce chemin d’escalade fait partie de la conception : un système qui traite l’essentiel du volume à moindre coût et n’escalade qu’au besoin accomplit sa mission. L’erreur serait de confier toute la file au petit modèle en lui accordant une confiance inconditionnelle.

Données confinées : structurer sous contrainte de schéma

Dès lors que des informations ne peuvent pas quitter l’organisation — secrets opérationnels, données critiques, notes cliniques, dossiers RH sous enquête, documents clients sous privilège ou réglementation — la comparaison de capacité n’a plus cours : le meilleur modèle n’est de toute façon pas une option, et l’alternative réelle est un petit modèle ou rien. La tâche la plus robuste dans ce périmètre est la structuration de documents : convertir du texte non structuré en enregistrements interrogeables (tableau, feuille de calcul, lignes de base). Il s’agit de lire un rapport et d’émettre des champs, pour une sortie réduite à une ligne plutôt qu’à un essai. La clé est de déplacer la difficulté hors du modèle avec un décodage contraint par schéma : à chaque étape, les tokens qui violeraient le schéma sont masqués, ce qui force des sorties qui se décodent ; une sortie mal formée devient mécaniquement impossible. Le modèle se concentre alors sur la lecture et l’affectation des segments aux champs, une compétence qu’un petit modèle maîtrise bien. La complexité du schéma reste l’ennemi : un schéma plat de douze champs de chaîne est simple à respecter, mais la conformité se dégrade avec l’imbrication d’objets et de clés, un écueil qui affecte disproportionnellement les petits modèles. En pratique, il vaut mieux aplatir et faire plusieurs passes : une première pour extraire, une seconde pour explorer l’imbrication, puis ajuster le nombre de passages à la profondeur visée. Lorsque le calcul est local, ces passages supplémentaires ne pénalisent guère.

Ce que les SLM font mal : raisonnement, rappel, contexte

Trois limites structurent le périmètre d’un petit modèle. D’abord le raisonnement étendu : l’écart avec les modèles de pointe est net en mathématiques et en génération de code complexes, et il a peu de chances de se combler côté petit modèle. Un système qui décroche à l’étape sept d’un plan en douze étapes ne sera pas corrigé par un prompt plus habile. Ensuite, il faut rappeler que la connaissance paramétrique demeure arrêtée à la date de coupure, ne bénéficie pas de mises à jour sélectives et sa qualité varie selon les domaines. Un petit modèle, disposant d’un stock de connaissances de départ plus limité, tend à produire davantage d’hallucinations lorsque les données d’entraînement sont peu nombreuses, notamment pour des API spécialisées, des réglementations propres à certaines régions ou toute information ayant évolué au cours de l’année écoulée. Enfin, le contexte efficace : il est en général bien inférieur à la fenêtre affichée, avec des pertes de fiabilité possibles dès quarante pour cent, parfois de manière abrupte. Les informations au milieu d’une longue entrée sont les plus défavorisées et la précision chute entre environ trente et soixante-dix pour cent du texte, tandis que le début et la fin résistent mieux. Cette dynamique, contre-intuitive, trompe facilement l’utilisateur.

Capacité perçue, contraintes matérielles et « huit milliards »

Trois circonstances motivent l’exécution locale : des données qui ne peuvent pas sortir, un volume déjà financé, ou une latence qui fait le produit. Sur un matériel non spécialisé que l’on possède déjà, le plafond pratique se situe autour de huit milliards de paramètres ou moins ; dans ce cadre, des modèles prêts à l’emploi et compétents traitent correctement les tâches décrites sans fine-tuning. Les discussions portant sur la « quantité de savoir » détenue par un petit modèle détournent l’attention du point principal : l’idée répandue selon laquelle il « manque de connaissances » prête à confusion. Aucun modèle disponible sur le marché ne peut être considéré comme une source factuelle fiable, et la capacité générale mesurée ne permet pas d’anticiper ce niveau de fiabilité, ces deux aspects n’étant pas liés. Il est exact qu’un petit modèle possède un volume de connaissances inférieur à celui d’un grand, mais ce facteur s’avère peu pertinent pour orienter un choix d’utilisation précis.