Lorsqu’on met en place une intelligence artificielle locale capable d’interroger ses propres documents, une question revient presque systématiquement : quel modèle faut-il utiliser ?
La tentation est alors assez naturelle : choisir le modèle comportant le plus grand nombre de paramètres possible. Un modèle de 14, 26 ou 30 milliards de paramètres devrait logiquement être meilleur qu’un modèle de 3, 4 ou 8 milliards.
En pratique, notamment dans le cadre d’un système RAG (Retrieval-Augmented Generation), les choses sont beaucoup moins simples.
Au sein du laboratoire IA Open Source, nous testons notamment différentes variantes des familles Ministral 3 de Mistral AI et Gemma 4 de Google DeepMind. Ces essais mettent surtout en évidence une règle importante : il n’existe pas un modèle idéal pour tous les usages RAG.
Le bon modèle est celui qui correspond au type de documents, aux questions posées, au niveau de raisonnement demandé et au matériel disponible.
Avant le modèle, il faut comprendre ce que fait réellement un RAG
Un système RAG ne demande normalement pas au modèle de connaître lui-même la réponse à une question.
Prenons une entreprise qui souhaite interroger plusieurs centaines de documents internes : procédures, manuels techniques, comptes rendus, fiches produits ou documentation commerciale.
Lorsqu’un utilisateur pose une question, le système recherche d’abord dans ces documents les passages qui semblent les plus pertinents. Ceux-ci sont ensuite transmis au modèle avec la question.
Le travail du modèle consiste alors essentiellement à comprendre les informations récupérées, les mettre en relation et construire une réponse.
C’est une différence fondamentale par rapport à une utilisation classique d’un chatbot.
Dans un RAG, la qualité finale dépend donc de plusieurs éléments :
Documents → découpage → recherche → passages sélectionnés → modèle IA → réponse
Un modèle extrêmement puissant ne peut pas compenser systématiquement une mauvaise recherche documentaire. Si les mauvais passages lui sont transmis, il pourra produire une excellente réponse… à partir des mauvaises informations.
Un modèle RAG n’a donc pas nécessairement besoin d’être gigantesque
Prenons la famille Ministral 3.
Mistral propose notamment des modèles 3B, 8B et 14B, spécialement destinés à des usages locaux ou « edge ». Ils disposent d’une fenêtre de contexte pouvant atteindre 256 000 tokens et existent dans différentes variantes, notamment instruct et reasoning.
Sur le papier, on pourrait donc être tenté de considérer simplement :
14B > 8B > 3B
Pour un usage RAG, cette façon de raisonner est beaucoup trop simpliste.
Imaginons un ensemble de fiches techniques relativement courtes.
Question :
Quelle est la durée de garantie du produit X ?
Si le système retrouve un passage indiquant clairement que « le produit X bénéficie d’une garantie de cinq ans », un modèle de taille modeste peut parfaitement produire la bonne réponse.
Donner cette même tâche à un modèle beaucoup plus lourd n’apportera pas nécessairement quelque chose de perceptible.
Cela reviendrait un peu à utiliser un serveur 64 cœurs pour additionner deux cellules dans un tableur : cela fonctionne très bien, mais ce n’est probablement pas l’utilisation la plus rationnelle du matériel.
Là où les différences commencent réellement à apparaître
Changeons maintenant légèrement la question.
Au lieu de demander :
Quelle est la durée de garantie du produit X ?
demandons :
Compare les conditions de garantie des produits X, Y et Z, en tenant compte des exclusions prévues dans les conditions générales et indique leurs principales différences.
Cette fois, plusieurs passages provenant éventuellement de plusieurs documents doivent être compris simultanément.
Le modèle doit identifier quelles informations correspondent à quel produit, rapprocher plusieurs éléments, éviter les confusions puis synthétiser la réponse.
La capacité de raisonnement du modèle devient alors beaucoup plus importante.
Et si nous demandons :
À partir de nos procédures internes, de notre règlement et des trois derniers rapports d’incident, quelles modifications de procédure pourraient réduire le risque observé ?
nous franchissons encore un niveau.
Le RAG ne se limite plus à retrouver une information. Le modèle doit analyser plusieurs sources et construire une réponse à partir d’informations dispersées.
Dans ce type de situation, un modèle plus puissant peut prendre l’avantage.
La taille du modèle n’est cependant qu’un indicateur
C’est probablement l’un des enseignements les plus importants lorsque l’on compare des modèles d’IA locaux.
Le nombre de paramètres donne une indication sur la taille du modèle, mais il ne permet pas à lui seul de prédire ses performances sur une tâche précise.
Deux modèles possédant un nombre de paramètres comparable peuvent se comporter très différemment.
L’architecture utilisée, les données d’entraînement, la qualité du post-entraînement, les capacités de raisonnement, le respect des instructions, la gestion du contexte ou encore les performances dans une langue particulière jouent également un rôle considérable.
Gemma 4 illustre particulièrement bien cette évolution. Google présente justement cette génération comme cherchant à obtenir davantage de capacités par paramètre plutôt que de simplement augmenter la taille des modèles. La famille comporte plusieurs architectures et tailles, depuis des modèles destinés aux appareils relativement modestes jusqu’à des modèles beaucoup plus lourds pour les tâches de raisonnement avancées.
Autrement dit :
deux fois plus de paramètres ne signifie absolument pas deux fois plus efficace en RAG.
Et un modèle plus petit d’une génération récente peut parfois se révéler beaucoup plus intéressant qu’un modèle plus ancien et nettement plus lourd.
Ministral 3 et Gemma 4 : deux familles particulièrement intéressantes pour le RAG local
C’est précisément pour cette raison que nous avons choisi d’intégrer différentes tailles de Ministral 3 et Gemma 4 dans nos essais.
La famille Ministral 3 est particulièrement intéressante dans une démarche d’IA locale. Mistral propose des modèles denses de 3B, 8B et 14B et les destine explicitement aux environnements locaux et edge. Les modèles disposent également de capacités multilingues, multimodales et d’une importante fenêtre de contexte.
De son côté, Gemma 4 adopte différentes approches architecturales et propose aussi bien des modèles très compacts que des modèles nettement plus importants. Google met notamment en avant les capacités de raisonnement, les longues fenêtres de contexte et l’exécution locale comme éléments centraux de cette génération.
Cela nous permet surtout de poser une question beaucoup plus intéressante que :
Quel est le modèle le plus puissant ?
La vraie question devient :
Quel est le plus petit modèle capable d’accomplir correctement cette tâche ?
Et dans une infrastructure locale, cette différence est loin d’être anecdotique.
Pourquoi chercher le plus petit modèle suffisamment performant ?
Parce qu’un modèle plus petit présente plusieurs avantages très concrets.
Il consomme généralement moins de mémoire vive et de VRAM, démarre plus rapidement, produit ses réponses plus vite et permet d’utiliser du matériel beaucoup plus accessible.
Un modèle 8B suffisamment performant pour un RAG documentaire représente donc souvent une meilleure solution qu’un modèle 30B donnant une réponse légèrement meilleure mais nécessitant une machine beaucoup plus coûteuse.
Cela devient encore plus important dans une PME, une association, une maison médicale ou une petite administration souhaitant conserver ses données sur sa propre infrastructure.
Le but n’est pas de construire la machine capable d’exécuter le plus gros modèle possible.
Le but est de disposer d’une solution fiable, suffisamment rapide et économiquement raisonnable.
Le type de questions est déterminant
Une bonne manière de choisir un modèle consiste donc à analyser les questions qui seront réellement posées.
Pour de la recherche factuelle simple, un petit modèle peut déjà être extrêmement efficace pour ce type de question :
Quelle est l’adresse du fournisseur ?
Quelle température maximale est autorisée ?
Quel délai est prévu dans cette procédure ?
Le modèle doit essentiellement identifier et reformuler correctement une information déjà présente dans le contexte.
Pour de la synthèse documentaire, la tâche devient plus complexe :
Résume les principales différences entre ces trois procédures.
Fais la synthèse des décisions prises dans les cinq derniers comptes rendus.
Un modèle intermédiaire peut alors apporter davantage de régularité.
Enfin, pour de la recherche nécessitant du raisonnement, par exemple :
Quels éléments communs apparaissent dans les différents incidents ?
Y a-t-il des contradictions entre ces documents ?
Compare ces différentes recommandations et explique leurs conséquences.
des modèles plus puissants deviennent beaucoup plus intéressants.
On pourrait donc résumer très grossièrement la logique ainsi :
Recherche simple → petit modèle possible
Synthèse de plusieurs sources → modèle intermédiaire
Analyse, comparaison et raisonnement → modèle plus performant
Mais il ne s’agit pas d’une règle absolue. C’est justement pour cette raison que les essais pratiques sont indispensables.
Une énorme fenêtre de contexte ne résout pas tout non plus
Les générations récentes de modèles acceptent désormais des contextes très importants. Ministral 3 peut par exemple atteindre 256 000 tokens, tandis que différents modèles Gemma 4 disposent de fenêtres de 128 000 ou 256 000 tokens.
Cela pourrait donner envie de transmettre des dizaines ou centaines de pages au modèle à chaque question.
Mais en RAG, pouvoir utiliser énormément de contexte ne signifie pas qu’il soit souhaitable de le faire.
Si la réponse se trouve dans trois paragraphes, transmettre cinquante pages ajoute surtout du « bruit ».
Un bon système RAG doit justement retrouver les quelques informations pertinentes avant de les envoyer au modèle.
La qualité de la recherche est donc souvent aussi importante que la capacité du modèle lui-même.
Et la quantification vient encore compliquer la comparaison
Lorsqu’on utilise une IA locale, on rencontre rapidement des versions Q8, Q6, Q5, Q4 ou encore IQ3.
La quantification permet de réduire fortement l’espace mémoire nécessaire pour charger un modèle.
Elle rend ainsi possible l’exécution de modèles relativement importants sur du matériel grand public.
Mais cela signifie également que comparer uniquement « un modèle 8B » à « un modèle 14B » ne suffit plus.
Un excellent modèle 8B utilisé avec une quantification relativement conservatrice peut être préférable, pour certaines tâches, à un modèle beaucoup plus lourd fortement compressé pour parvenir à le faire entrer dans la mémoire disponible. Le choix devient donc un compromis entre : qualité, mémoire nécessaire et vitesse d’exécution.
Le modèle n’est qu’une pièce du système RAG
C’est peut-être le point le plus important à retenir. Lorsqu’un RAG fonctionne mal, changer immédiatement de modèle n’est pas toujours la bonne solution.
Le problème peut provenir de la façon dont les documents ont été découpés, du modèle d’embedding utilisé pour la recherche, du nombre de passages récupérés, d’un éventuel système de reranking ou simplement des instructions données au modèle.
Un petit modèle recevant trois passages extrêmement pertinents peut produire une meilleure réponse qu’un énorme modèle auquel on transmet quinze extraits dont la moitié n’a pratiquement aucun rapport avec la question.
La performance d’un RAG doit donc être considérée comme celle d’un ensemble.
Il faut tester avec ses propres documents
Les benchmarks publics sont utiles pour comparer globalement les capacités des modèles.
Mais ils ne répondront jamais complètement à une question comme :
Quel modèle dois-je utiliser pour interroger les documents de mon entreprise ?
Pour le savoir, il faut construire un jeu de questions représentatif de l’utilisation réelle.
Quelques questions simples dont la réponse se trouve explicitement dans un document.
Quelques questions nécessitant plusieurs documents.
Quelques questions volontairement ambiguës.
Quelques questions dont la réponse n’existe pas dans les documents, afin de vérifier que le modèle accepte de dire qu’il ne dispose pas de l’information.
Et quelques questions nécessitant une véritable mise en relation de plusieurs sources.
On peut ensuite poser exactement les mêmes questions à Ministral 3 3B, 8B, 14B ou aux différentes variantes de Gemma 4 et comparer les résultats.
C’est justement l’approche que nous privilégions dans notre laboratoire : confronter les modèles à des documents et des usages concrets plutôt que de nous limiter aux benchmarks théoriques.
Le meilleur modèle est celui dont la puissance est réellement utile
La démocratisation des modèles locaux entraîne parfois une étrange course à la taille.
8 milliards de paramètres.
14 milliards.
30 milliards.
70 milliards…
Techniquement, réussir à exécuter des modèles toujours plus imposants sur du matériel personnel est passionnant.
Mais dans un projet réel, ce n’est pas forcément l’objectif.
Si un modèle compact répond correctement à 98 % des questions d’un système documentaire, remplacer celui-ci par un modèle nécessitant deux ou trois fois plus de ressources pour gagner marginalement en qualité n’a probablement que peu d’intérêt.
À l’inverse, si les documents sont complexes et que les utilisateurs attendent des analyses croisant de nombreuses informations, économiser quelques gigaoctets de VRAM en utilisant un modèle trop limité peut détériorer fortement l’expérience.
La bonne démarche consiste donc à dimensionner le modèle par rapport au problème, et non à dimensionner le problème par rapport au modèle que l’on souhaite absolument utiliser.
C’est précisément ce que permettent aujourd’hui des familles comme Ministral 3 et Gemma 4 : disposer de plusieurs niveaux de puissance afin d’adapter l’intelligence artificielle au matériel et surtout… à l’usage.
À retenir
Dans un système RAG, le plus gros modèle n’est pas automatiquement le meilleur modèle.
La qualité de la recherche documentaire, la nature des questions, le niveau de raisonnement nécessaire, la langue, la quantification, la vitesse attendue et le matériel disponible sont tout aussi importants.
La bonne question n’est donc plus :
« Quel est le modèle IA local le plus puissant que ma machine puisse faire tourner ? »
mais plutôt :
« Quel est le modèle le plus efficace dont j’ai réellement besoin pour mes documents et mon usage ? »
Et cette question ne se résout pas uniquement avec une fiche technique.
Elle se résout par les tests.