Modèle

Ce qu'un modèle contient

Un modèle de langage se résume rarement à un fichier unique. Il comprend une architecture, c'est-à-dire la façon dont les couches sont agencées, des paramètres appris, un vocabulaire de tokens et des fichiers de configuration qui décrivent le format des entrées. Le poids de l'ensemble atteint plusieurs gigaoctets, parfois davantage. Ces éléments sont figés après l'entraînement : le modèle ne modifie plus ses paramètres quand il répond, il les utilise tels quels. Ces fichiers suffisent à recréer le comportement du modèle, pas à retrouver la façon dont il a été obtenu.

Cette distinction entre apprendre et utiliser structure tout le reste du vocabulaire. L'entraînement produit le modèle, l'inférence le fait servir. Un même modèle peut être exécuté par plusieurs moteurs, sur un serveur ou sur un poste de travail, avec des performances différentes. Comprendre cette séparation évite deux confusions fréquentes : croire qu'un modèle apprend de vos échanges, et croire que la qualité dépend uniquement du nom de l'éditeur. Un modèle téléchargé aujourd'hui se comportera de la même façon dans un an, à moteur identique.

Modèle, données, application

Un modèle n'est pas une application. Il produit du texte, du code ou une image à partir d'une consigne, mais il ne sait pas déclencher une action, consulter un fichier ou vérifier un fait par lui-même. Une application utile combine un modèle, des données métier, des garde-fous et une interface. C'est l'assemblage qui rend le service fiable, pas le modèle seul. Un modèle excellent mal intégré déçoit, un modèle moyen bien encadré rend service.

La valeur d'un modèle se mesure donc rarement à l'unité. Deux modèles de qualité voisine donneront des résultats très différents selon la façon dont ils sont alimentés en contexte, dont leurs sorties sont validées et dont les erreurs sont rattrapées. Dans un projet, le temps passé sur les données et les contrôles dépasse souvent celui consacré au choix du modèle. Ce déséquilibre est normal et mérite d'être budgété dès le départ. C'est pourquoi un budget de projet doit prévoir cette phase d'ingénierie, souvent sous-estimée.

Choisir un modèle

Le choix se fait sur quelques critères concrets : la tâche visée, la langue, la taille de contexte nécessaire, le coût par usage et les contraintes d'hébergement. Un modèle ouvert téléchargeable convient quand les données ne doivent pas sortir ; un modèle accessible par API convient quand la charge est irrégulière et que l'équipe ne veut pas exploiter de serveur. Les deux options peuvent cohabiter dans un même système, par exemple pour les pics d'activité. Un modèle fermé peut être remplacé du jour au lendemain, ce qui plaide pour une couche d'abstraction.

Les classements publics donnent une indication, pas une décision. Ils agrègent des épreuves qui ne ressemblent souvent pas à votre travail réel et ne disent rien de votre coût. Un jeu de test interne, construit avec une centaine de cas issus de votre activité et de réponses de référence, tranche mieux. Ce dispositif reste utile dans le temps, car il permet de comparer chaque nouvelle version avant de l'adopter en production. Il vaut mieux le constituer tôt, avant d'avoir pris l'habitude d'un fournisseur unique.