Ce qui se règle, et ce qui ne se règle pas

Ces poids ont été écrits deux fois. Une première pour savoir continuer du texte ; une seconde, après coup, pour installer un comportement — obéir, s’arrêter, se servir d’un outil. Toute cette Étape tient dans la suite de cette phrase : qui a écrit ces poids, et qui peut encore écrire dessus.

Parce que deux des cinq leviers dont vous disposez n’écrivent rien du tout : ils changent ce que le modèle lit, pas ce qu’il est. Confondre les deux est l’erreur la plus coûteuse de toute cette Section — c’est un trimestre d’affinage pour un problème que trois documents dans le contexte auraient réglé en une après-midi.

---

Pourquoi le modèle brut ne savait pas obéir ?

Parce qu’obéir ne se déduit pas de « continuer du texte ». À la sortie du pré-entraînement, il existe une machine à continuer du texte, et rien d’autre. Elle n’obéit pas : une consigne est du texte comme un autre, qu’elle continue au lieu de l’exécuter. Elle ne s’arrête pas. Elle ne sait pas qu’un résultat d’outil attend une suite.

Tout ce que vous prenez pour un assistant a été ajouté après, par une seconde série d’entraînements sur les mêmes poids — le post-entraînement.

Le premier geste est le fine-tuning supervisé. On montre au modèle des milliers de paires — une demande, la réponse qu’on voulait — et les poids se déplacent vers cette forme. Ce qui est installé est un comportement : suivre une consigne, tenir un format, refuser, s’arrêter.

D’où la première chose à savoir de ce levier, et elle décide de tout ce que vous en attendrez : il fige un comportement dans les poids, il n’y ajoute pas de connaissance fraîche. J’aime bien dire qu’un affinage apprend un accent, pas un vocabulaire.

Affiner un modèle sur trois mille tickets de votre équipe lui apprend donc vos tournures, votre découpage, votre façon de finir une réponse — pas le contenu de ces tickets. Ce n’est jamais la réponse à « le modèle ignore notre API ». C’est même le pire cas de figure : il continuera de l’inventer, avec un style désormais très proche du vôtre, donc nettement plus difficile à prendre en défaut.

Le second geste est celui dont dépend tout le travail en agent, et son nom dit ce qu’il fait : le post-entraînement agentique. Mener une consigne en plusieurs temps, appeler un outil, lire ce que l’outil a renvoyé, corriger, recommencer. Rien de tout cela ne se déduit de « continuer du texte » : ça s’installe, ou ça ne s’installe pas. C’est ce qui sépare deux modèles de taille comparable dès qu’on les met dans une boucle — et on y revient à la fin de cette Étape, parce que ça ne se lit sur aucune fiche technique.

Pourquoi le modèle vous donne toujours raison ?

Parce que c’est exactement ce qu’on a optimisé. Après le fine-tuning vient une passe d’un autre genre : l’apprentissage par préférences. On produit deux réponses à la même demande, on demande à des humains laquelle ils préfèrent, et les poids se déplacent vers celle qui gagne. Répété à très grande échelle, c’est ce qui sépare un modèle qu’on a envie d’utiliser d’un modèle qu’on ne supporte pas.

Maintenant, regardez bien ce qui a été mesuré. Personne n’a coché « cette réponse est vraie ». On a coché « je préfère celle-ci ». Deux étiquettes différentes, et c’est la seconde qui a écrit dans les poids. Or entre une réponse qui vous contredit et une réponse qui vous donne raison, à qualité de rédaction égale, la seconde est préférée. Pas par complaisance des évaluateurs : par construction du jugement humain.

La sycophantie n’est donc ni un défaut de politesse ni une bavure : c’est le produit direct de ce qu’on a optimisé. Le modèle n’a pas appris à bien répondre et, accessoirement, à vous flatter. Il a appris à produire la réponse préférée, et votre accord fait partie de ce qui plaît.

Ce qui condamne d’avance un remède, et c’est là que la conséquence se prend : ajouter « sois franc », « sois critique », « ne me ménage pas » à votre prompt ne change pas l’objectif qui a écrit les poids. La consigne arrive dans le contexte, du même côté que votre cadrage, et elle est traitée par un modèle entraîné à vous satisfaire — y compris, s’il le faut, en vous servant une critique de pure forme.

Ce qui déplace le résultat n’est pas la formule, c’est le dispositif de vérification : qui tranche, et sur quoi. Ce dispositif appartient à Limites et hallucinations, qui clôt cette Section. Ce qu’il faut emporter d’ici est plus court : quand le modèle vous donne raison, il fait exactement ce pour quoi il a été réglé, et aucune consigne de votre côté ne le lui fera oublier.

Quel levier quand le modèle ne fait pas ce que vous voulez ?

Celui qui vise le bon objet. Il y a cinq gestes possibles, et chacun change une chose différente : ce que le modèle lit, ce qu’il va chercher, ses poids, ou le modèle lui-même.

On présente d’habitude cette échelle classée par puissance croissante, et ce classement induit en erreur. C’est l’objet qui se décide, pas la technique — il n’existe aucun sens dans lequel monter d’un barreau compenserait le fait d’avoir visé le mauvais objet.

• Le contexte. Vous fournissez dans la requête ce qui manque : la version, le fichier, la convention. Rien n’est écrit nulle part, l’effet dure le temps de l’appel. C’est le barreau du bas, et il traite la majorité des cas — le contexte et prompting pour développeurs sont deux Étapes entières là-dessus.
• La récupération de documents, qu’on appelle le RAG. Un dispositif va chercher, avant l’appel, les passages pertinents dans vos sources, et les colle dans le contexte. Il change le contexte, pas les poids : ce n’est pas un barreau de plus que le précédent, c’est le même, automatisé et passé à l’échelle.
• L’affinage à la marge, dont LoRA est la forme courante. Plutôt que de réécrire tous les poids, on apprend un petit correctif qui vient s’ajouter par-dessus, pour un coût de calcul sans commune mesure avec un entraînement. Les poids bougent, mais peu, et sur une seule dimension : un style, un format, un vocabulaire de domaine.
• Le fine-tuning supervisé complet. Le geste du fournisseur, refait chez vous, en plus lourd. Même nature et même limite que le précédent.
• Un autre modèle. Le dernier barreau, et il n’a rien d’un aveu d’échec — la section suivante dit quand il est la bonne réponse.

La question qui trie ces cinq gestes tient en deux mots, et elle se pose avant d’ouvrir la moindre documentation : ce qui manque au modèle, est-ce de l’information ou du comportement ?

De l’information — votre API, votre schéma de données, la version de la bibliothèque, la décision prise en réunion mardi ? Les deux barreaux du bas, et eux seuls. C’est le point sur lequel il ne faut pas se tromper : la récupération de documents est le seul geste de toute l’échelle qui traite « le modèle ne connaît pas notre projet ». Et parce qu’elle passe par le contexte, ce qu’elle apporte a trois propriétés qu’aucun affinage ne donnera jamais : c’est daté — vous savez de quand est le document —, révocable — vous le retirez de l’index et l’effet disparaît au prochain appel — et vérifiable — vous pouvez relire la source dont la réponse est sortie.

Du comportement — un format que votre outillage sait lire, un ton, une façon de découper une réponse, une convention de nommage ? Les deux barreaux d’affinage, et ils ne feront rien d’autre. Un modèle affiné garde exactement les lacunes qu’il avait, avec vos tournures par-dessus.

LE CRAFTOMANCER

« On va fine-tuner un modèle sur notre code » est la phrase la plus chère de la réunion. Avant de la laisser passer, demandez ce que l’affinage est censé apprendre au modèle. Si la réponse est un fait — une convention, une API interne, une décision d’architecture prise l’an dernier — la plainte est un manque d’information, et le bon barreau est deux crans plus bas.

Quel barreau pour quelle plainte ?

Le même tri, en tableau, rangé par ce que vous constatez plutôt que par les techniques disponibles. La colonne de droite est celle qui fait le travail : un barreau bien choisi ne répare qu’une chose, et savoir laquelle il ne répare pas vous évite de lui prêter le reste.

Une ligne de ce tableau répond « aucun barreau », et c’est la plus utile qu’il porte : elle existe pour que la sycophantie ne devienne pas un projet d’affinage. La dernière, elle, ouvre le seul cas où changer de modèle est une décision et non une fuite.

Comment choisir entre deux modèles ?

Pas sur le nombre de paramètres, en tout cas. Ce proxy a longtemps servi de mesure grossière mais utilisable — plus gros, plus capable. Il est mort, et il faut savoir de quoi il est mort pour ne pas le remplacer par un autre aussi mauvais.

La taille annoncée d’un modèle n’est plus la quantité de modèle qui tourne sur votre requête. Beaucoup de modèles récents n’activent qu’une partie de leurs poids à chaque token — ce sont leurs paramètres activés, et c’est ce nombre-là, pas le total de la fiche, qui dit combien de calcul votre requête déclenche. Deux modèles annoncés à la même taille peuvent donc ne pas faire le même travail par token, ne pas coûter la même chose et ne pas se valoir. Vous héritez ici d’un critère dont vous n’avez pas la clé : ce que « paramètres activés » recouvre, et pourquoi le total annoncé ne s’y réduit plus est déroulé dans le Guide.

Quatre choses à comparer, donc, au lieu d’une :

• Les paramètres activés — ce qui tourne réellement à chaque token, et non ce qui est annoncé.
• Le post-entraînement — ce qui a été installé sur ces poids. Pour de l’agentique, c’est le facteur qui décide, et il n’apparaît sur aucune fiche : il se mesure en faisant tenir une tâche longue à outils, pas en lisant un score de connaissances.
• Le contexte réellement exploitable — la fenêtre annoncée est une capacité, pas une performance ; tokens, fenêtres et attention dit pourquoi les deux ne se confondent pas.
• Le moteur qui sert les réponses — le même modèle, servi ailleurs, ne rend ni la même latence ni le même prix. C’est le sujet du coût et de la latence.

Un seul de ces quatre axes est public. C’est pour cette raison que le seul protocole de choix qui tienne est de faire tourner les deux modèles l’un après l’autre sur une tâche à vous, avec vos outils — et non de comparer deux pages de spécifications.

En pratique

• Avant de choisir un levier, dites à voix haute ce qui manque : de l’information ou du comportement. Ce seul tri élimine le plus gros des mauvais choix.
• Un affinage n’apprend jamais un fait. Si la plainte contient un nom d’API, un numéro de version ou un chemin de fichier, c’est un problème de contexte.
• À doute égal, prenez le révocable. Ce qu’une récupération de documents apporte se retire d’un index ; ce qu’un affinage installe se retire en recommençant l’affinage.
• Quand le modèle vous donne raison, ne réécrivez pas la consigne : changez qui tranche.
• Pour choisir un modèle d’agent, faites-lui tenir une de vos tâches longues, avec vos outils. Le nombre de paramètres ne vous dira rien, et la fenêtre annoncée non plus.

Que veut dire paramètres activés ?

Cette Étape vous laisse avec des critères de choix dont elle ne donne pas les mécanismes — délibérément : ils ne changent aucun de vos gestes. « Le modèle de bout en bout » les porte, et deux de ses sections reprennent exactement d’ici :

• Combien de modèle tourne vraiment — pourquoi le total annoncé et ce qui tourne par token ont cessé d’être le même nombre, et ce que la précision des poids ajoute à l’écart.
• Ce qu’on peut encore écrire dessus — les internes des deux passes de post-entraînement et des deux barreaux d’affinage : ce qui bouge dans les poids, et de combien.

Vérifiez votre modèle

Quatre questions pour voir si le modèle mental tient. Cliquez une réponse : le verdict s’affiche.

RUN · VII 0 / 4

jack in — choisissez votre réponse

L’agent ignore une API interne à votre entreprise. Le geste qui traite le problème…

▶ la lui fournir : dans la requête, ou par une récupération de documents ▶ affiner un modèle sur le code de l’entreprise ▶ passer à un modèle plus gros

Vous affinez un modèle sur trois mille tickets de votre équipe. Il en ressort…

▶ avec vos tournures, et exactement les mêmes lacunes ▶ en connaissant les sujets traités dans ces tickets ▶ plus fiable sur votre domaine, donc moins à vérifier

L’agent valide votre hypothèse à chaque fois. La cause…

▶ on a optimisé la réponse préférée, et une réponse qui vous donne raison est préférée ▶ le modèle a été rendu poli au point de ne plus oser contredire ▶ il manque une consigne de franchise dans votre prompt

Deux modèles annoncent le même nombre de paramètres. Ce qui prédit lequel tiendra une tâche longue à outils…

▶ ce qui a été installé au post-entraînement, et ce qui tourne réellement à chaque token ▶ le plus récent des deux ▶ celui qui annonce la plus grande fenêtre de contexte