Quand les petits LLM valent mieux qu'un essaim : comment un découpage en sections a multiplié un modèle faible par 4

Pourquoi les petits modèles sont utiles, mais pas en essaim

L'ingénieur thermicien, chef de service dans un bureau d'études avec 14 ans d'expérience, a passé son printemps à tenter de faire émerger un essaim de modèles locaux faibles. L'expérience s'appelait Mycélium — inspirée des travaux sur les structures dissipatives et les populations de modèles capables de se répartir des rôles et de négocier un langage commun. Mais l'essaim n'a pas décollé : sur 200 tâches de MBPP, il n'a résolu que 29 % des cas, contre 52 % pour un simple best-of-N, où les modèles se contentent de proposer plusieurs tentatives. Mais en chemin, il a découvert qu'une idée venue du bureau d'études supporte une charge colossale.

Toutes les expériences ont tourné sur une GTX 1660 SUPER de 6 Go de mémoire. L'auteur a dû se contenter de modèles vraiment petits : qwen2.5-coder-1.5b, qwen3-1.7b, llama-3.2-1b, internvl3-2b, gemma-3-1b et smollm2-1.7b. Les contraintes de mémoire imposaient de garder plusieurs modèles en charge simultanément et de les faire tourner sur des milliers d'appels. Le code de toutes les expériences a été écrit par des agents IA, l'auteur fixant les tâches et contestant les chiffres.

Une structure de bureau d'études plutôt qu'un essaim

L'idée vient de l'histoire d'Albert Kahn, architecte américain qui a conçu des usines pour Ford. Entre 1929 et 1932, son cabinet a conçu environ 500 usines pour l'URSS, dont celle de tracteurs de Stalingrad. On dit que les instituts de conception soviétiques sont nés de son bureau moscovite. L'auteur vit chaque jour dans cette organisation.

L'ingénieur en chef du projet (GIP) divise l'objet en sections : thermique, électricité, génie civil, automatismes — chaque service gère la sienne. Une section terminée est vérifiée en interne (contrôle intra-disciplinaire). Puis les sections sont confrontées entre elles aux points de contact (contrôle interdisciplinaire) — l'un a une pompe, les constructeurs lui doivent une fondation, et les deux doivent correspondre.

Les points litigieux remontent au spécialiste principal. À la fin, un contrôle normatif vérifie la présentation, et ce n'est qu'après que les dossiers partent chez le client. Personne ne garde la centrale entière en tête — elle n'y rentre pas.

Un petit modèle auquel on donne 18 enregistrements et qu'on charge de trouver les bons se trouve dans la même situation.

Ce qui a été testé

Sur 40 tâches de test, les modèles devaient retrouver toutes les transactions correspondant à la fois à une catégorie ET à une région données, dans un jeu de 18 enregistrements. Le nombre de bonnes réponses variait de 2 à 5, avec des pièges à proximité — des enregistrements ayant la bonne catégorie mais la mauvaise région, et inversement, à raison de 2 à 4 chacun. Le modèle devait fournir UNIQUEMENT la liste des identifiants correspondants, séparés par des virgules, sans explication, et désigner exactement le bon ensemble — ni trop, ni trop peu.

Modèles utilisés au format GGUF : qwen2.5-coder-1.5b-instruct (Q4_0), llama-3.2-1b-instruct (Q4_0), qwen3-1.7b (Q4_0), internvl3-2b (Q4_K_M), gemma-3-1b-it (Q5_K_S), smollm2-1.7b-instruct (Q4_K_M). Les réponses sur la liste complète provenaient d'expériences antérieures stockées sur disque, afin d'éliminer la variabilité de génération. Au total, 720 appels, 614 secondes sur la GTX 1660 SUPER.

Résultats : le découpage en sections

Sans découpage, on observait déjà une mauvaise répartition selon la position : le premier enregistrement était retrouvé dans 61 % des cas, le dernier dans seulement 21 %. L'auteur a d'abord pensé que vers la fin de la liste, le modèle répondait simplement plus souvent non, mais en vérifiant, il s'est trompé. Vers la fin, le modèle devient légèrement plus avare (0,21 contre 0,50 au début), mais distingue beaucoup moins bien les lignes similaires. Il trouve moins de bonnes réponses (0,30 contre 0,50), et le taux de fausses détections parmi les cas non pertinents augmente (0,16 contre 0,14).

Les 18 enregistrements ont ensuite été découpés par script en 3 blocs de 6 consécutifs — l'ordre interne de chaque bloc étant conservé. Chacun des six modèles lisait chaque bloc séparément. Si un modèle citait un identifiant absent de son bloc, c'était considéré comme une invention, et le code rejetait cette réponse (seulement 5 inventions détectées sur l'ensemble de l'exécution). Le vote pour un enregistrement n'était comptabilisé que depuis le bloc où il se trouvait réellement.

Résultats en correspondance exacte (le modèle a désigné exactement le bon ensemble) :

| Modèle | Sans découpage | Avec blocs de 6 | Gain | |--------|-----------|-----------------|----------| | qwen2.5-coder-1.5b | 17,5 % | 70 % | +52,5 points | | llama-3.2-1b | 40 % | 72,5 % | +32,5 points | | internvl3-2b | 57,5 % | 82,5 % | +25 points | | qwen3-1.7b | 72,5 % | 85 % | +12,5 points | | gemma-3-1b | 0 % | 5 % | +5 points | | smollm2-1.7b | 0 % | 0 % | 0 point |

Plus le modèle est faible, plus le gain est important. L'écart entre début et fin de liste s'est réduit de 20 points à 2 points. Sur la liste complète, le rappel en fin de liste était de 0,30 ; avec le découpage, il est passé à 0,57.

Le mythe de l'émergence

L'objectif principal était de rechercher l'émergence — un cas où la réponse agrégée serait correcte alors qu'aucun modèle seul n'aurait réussi. Avec la formulation initiale, erronée, cela donnait 34 tâches sur 40. L'auteur a presque sorti le champagne, avant de regarder ce qu'il comparait réellement avec quoi. D'un côté, tout le pipeline : blocs, vérification, vote, agrégation. De l'autre, un modèle isolé auquel on avait donné les 18 enregistrements d'un coup. Les conditions étant différentes, cette comparaison ne signifiait rien.

En comparant équitablement (en faisant passer le meilleur modèle, qwen3-1.7b, par le même pipeline avec blocs), il obtient 0,850. Les six modèles réunis obtiennent 0,900. Un oracle « au moins un des six a réussi » donne 0,975. L'émergence stricte s'est révélée nulle : la réponse agrégée n'a jamais dépassé ce qu'au moins un des modèles savait déjà faire seul. L'essaim n'a ajouté que 5 points au meilleur modèle isolé.

Un seul élément sur sept a fonctionné

Seul le découpage en sections a supporté la charge. Ce qu'a apporté chaque élément : le GIP qui divise l'objet en sections (découpage des 18 enregistrements en 3 blocs de 6) — presque tout : écart de 0,20 à 0,02, correspondance exacte de 0,75 à 0,90. Les exécutants (6 modèles, un par bloc) — +0,05 au-dessus du meilleur modèle isolé.

Le contrôle intra-disciplinaire (un identifiant hors de son bloc est rejeté) — 5 inventions détectées. Le contrôle interdisciplinaire (vérification aux points de contact entre blocs) — les blocs étant indépendants, rien à vérifier. Le contrôle normatif (vérification du format) — aucune erreur constatée.

Le spécialiste principal (question ciblée sur une ligne) — inutile. Les révisions (nouveau cycle en cas de réponse incertaine) — inutiles.

Conclusion pratique : découpez les petits modèles en morceaux lorsque vous leur soumettez un paquet de documents ou une longue liste. Dans cette expérience, l'optimum était de 6 enregistrements par bloc — les six premières positions étaient les mieux retrouvées. Le découpage par jetons est quasiment gratuit : trois morceaux d'un tiers chacun donnent le même volume, plus trois en-têtes de prompt. Trois fois plus d'appels, mais plus courts. L'essaim de six modèles par-dessus coûte six fois plus cher pour seulement 5 points de gain. L'auteur n'approuve pas cet échange, mais l'outil — le découpage en sections — fonctionne.