Modèle

Comment ça marche

Un modèle, c’est le résultat d’un entraînement : une architecture et des milliards de paramètres ajustés sur des données. Une fois entraîné, il ne change plus. On l’utilise en lui envoyant un texte, il renvoie un texte. C’est tout ce que fait un modèle. Tout le reste, l’interface de chat, les consignes de comportement, la recherche web, l’accès à vos documents, la mémoire, est ajouté par l’application qui l’entoure.

Cette distinction compte dans trois situations. Quand on compare des outils : est-ce le modèle qui est meilleur, ou l’application ? Quand on choisit où vont les données : le modèle ne stocke rien, c’est l’application et son fournisseur qui décident. Et quand un outil change de comportement du jour au lendemain : souvent, le modèle a été remplacé sous l’application, sans que l’interface bouge. Les fournisseurs proposent leurs modèles en familles, par taille et par coût, et on peut en changer par un simple réglage.

Un exemple concret

1. Situation : un outil interne de rédaction de comptes rendus, construit sur un grand modèle, utilisé par 30 personnes depuis un an.
2. Le test : trois modèles candidats (le modèle actuel, sa version plus récente, et le modèle moyen de la même famille) sur 40 comptes rendus réels, notés à l’aveugle par cinq utilisateurs.
3. Résultats : la version récente est jugée meilleure sur 12 cas, équivalente sur 26, moins bonne sur 2 (elle ajoute des commentaires non demandés). Le modèle moyen est équivalent sur 34 cas, pour un coût divisé par cinq.
4. Décision : le modèle moyen par défaut, le grand modèle récent pour les comptes rendus de plus de dix pages, une consigne ajoutée pour interdire les commentaires. Et un test identique prévu à chaque nouvelle version.

L’application n’a pas changé. Deux lignes de réglage, et la facture a été divisée par quatre.

Ce que ça change pour une équipe

• Le modèle devient un réglage. On le choisit par tâche, on le change quand un meilleur arrive, on revient si ça déçoit.
• On sait quoi évaluer. Un outil décevant : est-ce le modèle, la consigne, les données fournies ? La question se pose dans cet ordre, et se teste.
• Les coûts se pilotent. Les tailles d’une même famille vont de un à vingt en prix. Le bon modèle pour la tâche est le premier levier.
• Les données se protègent au bon endroit. Ce n’est pas le modèle qui garde vos données : c’est le fournisseur de l’application. Les garanties se demandent là.

Les limites et les erreurs fréquentes

• Juger sur les classements. Les tests publics mesurent des tâches générales. Votre tâche est particulière. Le seul test qui compte est le vôtre.
• Basculer sans tester. Un nouveau modèle change le ton, le format, parfois le refus de certaines demandes. En production, on teste d’abord.
• Prendre le plus gros par défaut. Pour la plupart des tâches, le modèle moyen fait aussi bien, pour une fraction du prix.
• Confondre modèle et fournisseur. Un même modèle ouvert peut être servi par plusieurs hébergeurs, avec des conditions différentes sur les données. Le modèle ne dit rien de ce qu’on fait de vos données.