Les modèles locaux fine-tunés sont la couche suivante

Mes deux derniers articles portaient d'abord sur les systèmes, puis sur la stack technique qui les soutient.

Le premier point était simple : l'IA devient réellement utile lorsqu'elle est intégrée dans un système.

Le second était que, dans mon cas, ce système repose sur deux couches principales :

• un harness pour l'exécution
• un Knowledge OS pour le contexte structuré

Je continue à penser que ces deux couches sont la base.

Mais elles ne sont pas l'état final.

Si l'on veut que ces systèmes deviennent plus complets, plus isolés, et plus facilement déployables dans différents environnements, alors la couche suivante me paraît claire :

Pas un seul grand modèle pour tout faire.

Pas un seul immense prompt censé tenir tout le système ensemble.

Je parle de modèles plus petits, assignés à des tâches plus étroites, entraînés pour des rôles précis, attachés à de vraies contraintes matérielles, et intégrés au système d'exécution comme des composants fiables.

Pourquoi le prompting seul finit par atteindre une limite

Le prompting est puissant. C'est le moyen le plus rapide d'explorer, de prototyper et d'obtenir une première utilité.

Mais il a ses limites.

Quand trop de comportement vit dans les prompts, le système devient coûteux à maintenir et difficile à stabiliser. Les instructions s'allongent. Les cas limites s'accumulent. Le modèle doit encore inférer trop de choses à chaque exécution.

Cela reste acceptable au début.

Cela l'est beaucoup moins quand l'objectif devient une exécution répétable.

Si le même type de raisonnement, de formatage, de routage, de classification, d'extraction ou de prise de décision revient encore et encore, je ne veux pas payer le coût complet du prompt à chaque fois. Je veux qu'une partie de ce comportement se rapproche du modèle lui-même.

C'est là que le fine-tuning commence à compter.

Le fine-tuning comme compression de comportement

On parle souvent du fine-tuning comme si l'enjeu principal était de rendre un modèle plus intelligent.

Ce n'est pas l'angle qui m'intéresse le plus.

L'angle le plus pratique est plutôt celui-ci :

le fine-tuning est une manière de compresser un comportement répété dans le modèle afin que le système dépende de moins de scaffolding de prompt à l'exécution.

Au lieu d'expliquer la même tâche étroite encore et encore, on entraîne le modèle pour que ce comportement devienne plus naturel pour lui.

Cela réduit :

• la longueur des prompts
• l'overhead d'orchestration
• la latence dans les workflows étroits
• la variabilité sur les tâches répétées

Et dans beaucoup de cas, cela améliore davantage la fiabilité qu'une simple accumulation d'instructions dans le prompt.

Pourquoi les petits modèles comptent

Je ne pense pas que le futur des systèmes IA opérationnels soit un unique modèle frontier qui fait tout.

La vision la plus sérieuse ressemble davantage à une architecture distribuée :

• des modèles frontier pour le raisonnement large et la synthèse difficile
• des systèmes structurés pour la mémoire, le retrieval et le gating
• des modèles plus petits, fine-tunés, pour les tâches étroites et répétées

Cette dernière catégorie compte énormément.

Un petit modèle bien borné peut être extrêmement utile si son rôle est clairement défini. Il n'a pas besoin d'être universellement brillant. Il doit être fiable dans une responsabilité limitée.

Par exemple :

• un modèle spécialisé pour la classification
• un modèle spécialisé pour l'extraction de données structurées
• un modèle spécialisé pour l'application du style
• un modèle spécialisé pour le routage d'outils
• un modèle spécialisé pour une validation métier précise

C'est une voie bien plus sérieuse vers la fiabilité que de demander à un modèle général d'improviser toutes les couches de la stack.

Le raisonnement doit rester central

Cela ne signifie pas que je veux remplacer le raisonnement par une automatisation fragile.

Au contraire.

Je pense que le raisonnement devient plus précieux lorsque le reste du système est plus propre.

Le harness continue de gérer les décisions, le gating, l'itération, l'escalade et le flux d'exécution.

Le Knowledge OS continue de gérer la mémoire, le contexte, la structure et le retrieval.

Mais désormais, des modèles spécialisés peuvent prendre en charge des tâches plus étroites à l'intérieur de cette boucle plus large.

Cela signifie que le système de plus haut niveau peut réserver le raisonnement aux endroits où il est réellement nécessaire, au lieu de gaspiller une intelligence générale coûteuse sur des tâches à faible entropie qui auraient déjà dû être stabilisées.

Le déplacement n'est donc pas du raisonnement vers l'entraînement.

Il va d'un prompting généralisé vers du raisonnement là où c'est nécessaire, et de l'entraînement là où la répétition existe déjà.

La fiabilité vient de l'alignement avec le vrai travail

Quand on entend le mot alignement, on saute souvent immédiatement vers des discussions abstraites de safety.

Ce n'est pas le sens que je vise ici.

Je parle d'alignement opérationnel.

Le modèle se comporte-t-il d'une manière qui correspond réellement à la tâche, au domaine, aux règles et à l'environnement matériel dans lequel il tourne ?

Pour des systèmes de production, cela compte plus que des démos élégantes.

Un modèle local étroit, entraîné sur les bons exemples, évalué sur les bons modes d'échec, et contraint par le bon harness, peut avoir bien plus de valeur qu'un plus grand modèle seulement orienté par des prompts.

La fiabilité n'a rien de magique. C'est un alignement conçu entre :

• la tâche
• les données d'entraînement
• la boucle d'évaluation
• l'environnement d'exécution

L'auto-amélioration a besoin d'un système, pas d'un mythe

Oui, je pense que l'auto-amélioration est la porte suivante.

Mais je ne parle pas d'un fantasme flou où un modèle se réécrit lui-même indéfiniment dans le noir.

Je parle d'un processus structuré dans lequel le système apprend de l'exécution :

• ce qui a échoué
• ce qui s'est répété
• ce qui a demandé trop de prompting
• quels schémas sont devenus assez stables pour être encodés

À partir de là, on peut décider ce qui doit rester dans les prompts, ce qui doit devenir une règle, ce qui doit devenir de la donnée d'entraînement, et ce qui doit être confié à un plus petit modèle spécialisé.

C'est une version bien plus solide de l'auto-amélioration.

Le système ne devient pas meilleur parce qu'il "réfléchit" au sens abstrait.

Il devient meilleur parce que l'exécution produit des preuves, et que ces preuves sont transformées en meilleurs modèles, meilleurs routages et meilleures contraintes.

Le hardware fait partie du design

Une autre raison pour laquelle je m'intéresse aux petits modèles locaux est simple : le hardware est réel.

Si un système doit être déployable dans différents environnements, alors le compute, la mémoire, la latence, la confidentialité et le coût sont des sujets d'architecture, pas des détails.

Un système IA complet devrait pouvoir affecter la bonne tâche à la bonne couche :

• certaines tâches méritent le raisonnement de grands modèles
• certaines tâches doivent rester locales pour la vitesse ou la confidentialité
• certaines tâches doivent tourner sur de petits modèles spécialisés parce que c'est l'option la plus efficace

C'est l'une des principales raisons pour lesquelles je vois les modèles locaux fine-tunés comme une partie d'une architecture sérieuse, et non comme une simple astuce d'optimisation.

Ils rendent le système plus portable, plus contrôlable et, dans bien des cas, plus viable économiquement.

À quoi commence à ressembler la stack complète

À haut niveau, l'architecture devient plus facile à décrire :

Cela ressemble beaucoup plus à un système complet que "un modèle plus un prompt".

Cela ressemble aussi beaucoup plus à quelque chose qui peut être isolé, déployé et adapté à différents systèmes et différentes contraintes matérielles.

Dernière idée

Si le harness aide le système à faire, et le Knowledge OS aide le système à savoir, alors les modèles locaux fine-tunés aident le système à stabiliser.

Ils réduisent la dépendance au prompt.

Ils transforment des comportements répétés en capacités réutilisables.

Ils créent un meilleur pont entre l'exécution, le raisonnement, le hardware et l'alignement.

Pour moi, c'est la prochaine étape sérieuse.

Pas plus de prompting.

Mais plus de spécialisation, plus d'entraînement, et un meilleur design système autour des endroits où le raisonnement doit vraiment intervenir.