Comparer les LLM sans se perdre dans le bruit
Quand quelqu’un demande ce que sont les LLM et comment ils fonctionnent, la réponse rapide est souvent « des modèles de langage qui prédisent le mot suivant ». C’est exact, mais insuffisant pour décider lequel utiliser. La différence pratique entre un modèle et un autre ne réside pas dans cette définition, mais dans la façon dont ils gèrent le contexte, combien ils coûtent par million de tokens, avec quelle précision ils suivent de longues instructions et jusqu’où s’étend leur fenêtre d’attention avant d’oublier ce qui a été dit au début de la conversation.
Cet article ne répète pas l’explication de manuel. Il se concentre sur ce qui change lorsqu’on compare les familles les plus utilisées — GPT, Claude, Gemini, Llama et Mistral — et sur les critères qui discriminent réellement dans un usage professionnel : raisonnement sur des documents volumineux, génération de code, coût opérationnel et contrôle sur les données.
Comment fonctionne un LLM à l’intérieur (le strict nécessaire pour comparer)
Un LLM est un réseau de neurones entraîné avec une architecture transformer. Il traite le texte en le divisant en tokens (fragments de mot) et calcule des probabilités sur le token suivant. Ce mécanisme, répété, produit des réponses cohérentes. Ce qui est pertinent pour une comparaison, c’est qu’il existe deux phases bien distinctes :
- Pré-entraînement : le modèle absorbe des motifs issus d’énormes corpus de texte. C’est là que se définissent ses connaissances générales et sa capacité de raisonnement de base.
- Alignement (fine-tuning et RLHF) : on l’ajuste pour suivre des instructions, refuser les requêtes nuisibles et adopter un ton précis. C’est là que se définissent son « caractère » et son obéissance.
Deux modèles de même taille peuvent se comporter de manière radicalement différente selon la façon dont cette seconde phase a été réalisée. C’est pourquoi comparer les « paramètres » sans regarder l’alignement conduit à des conclusions erronées.
Le contexte n’est pas qu’un nombre
Les fiches techniques annoncent des fenêtres de contexte de 128 000, 200 000 voire un million de tokens. En pratique, la qualité de récupération à l’intérieur de cette fenêtre se dégrade. Un schéma qui se répète lorsqu’on teste des modèles avec de longs contrats : l’information située au milieu du document est moins bien récupérée que celle du début ou de la fin. C’est le fameux effet « perdu au milieu », documenté dans des études du secteur sur l’évaluation du contexte long.
Conséquence pratique : si vous allez analyser un rapport de 300 pages, il ne suffit pas que le modèle accepte le document. Il convient de le découper, de l’indexer et de faire de la récupération sémantique (RAG) plutôt que de compter sur le fait que le modèle lira tout avec la même attention.
Comparatif des familles les plus utilisées
GPT (OpenAI)
C’est la référence par son écosystème : API mature, outils, fonctions et une communauté énorme. Il excelle dans la génération de code et dans le suivi d’instructions structurées (sorties JSON, appels de fonctions). Son point faible historique a été la verbosité et une certaine tendance à complaire à l’utilisateur même lorsque la prémisse est erronée. Pour les tâches d’extraction de données avec un format strict, c’est généralement l’option la plus prévisible.
Claude (Anthropic)
Il s’est positionné fortement sur la rédaction longue et l’analyse de documents volumineux. Il produit souvent des textes avec moins de formules creuses et accepte mieux les corrections nuancées. Dans les tâches de révision éditoriale ou de synthèse de contrats, de nombreuses équipes le préfèrent pour son ton. Limite réelle : dans certains flux de code très spécifiques, il est en dessous de GPT, et son intégration avec des outils externes est arrivée plus tard.
Gemini (Google)
Son avantage est l’intégration avec l’écosystème Google : recherche, Workspace, Android. La fenêtre de contexte étendue et l’accès à des informations actualisées via la recherche le rendent utile pour les tâches nécessitant des données récentes. La nuance : la variabilité entre versions (Flash, Pro, Ultra) est élevée, et choisir le mauvais modèle pour une tâche peut faire exploser le coût sans améliorer le résultat.
Llama (Meta)
C’est la famille ouverte de référence. Elle permet une exécution locale ou sur ses propres serveurs, ce qui répond à des exigences de confidentialité que les modèles dans le cloud ne couvrent pas. Contrepartie : elle nécessite une infrastructure (GPU), de la maintenance et des connaissances techniques. Pour une PME sans équipe de ML, l’économie de licence est absorbée par le coût opérationnel.
Mistral
Des modèles efficients, bons en rapport qualité/taille, avec des options ouvertes et commerciales. Ils conviennent bien lorsqu’on a besoin d’un modèle léger pour la classification, l’extraction ou le service client avec une faible latence. Ce n’est pas la meilleure option pour un raisonnement complexe en plusieurs étapes.
Tableau de décision rapide
| Besoin | Option raisonnable | Pourquoi |
|---|---|---|
| Générer du code et automatiser avec des API | GPT | Écosystème et sorties structurées fiables |
| Analyser de longs documents et rédiger | Claude | Ton soigné et bonne gestion d’un contexte étendu |
| Données actualisées et intégration Google | Gemini | Recherche intégrée et connexion avec Workspace |
| Confidentialité et exécution locale | Llama | Modèle ouvert, contrôle total de la donnée |
| Faible latence et coût maîtrisé | Mistral | Petits modèles efficients |
Un cas réel qui change la décision
Une équipe juridique a essayé de téléverser un contrat cadre de 180 pages dans un modèle avec une fenêtre de 200 000 tokens. La surprise : le modèle citait correctement les clauses du début et de la fin, mais omettait une clause de pénalité située vers la page 90. Ce n’était pas un défaut de capacité, mais d’attention distribuée. La solution n’a pas été de changer de modèle, mais de découper par sections, d’indexer avec des embeddings et d’interroger sur une clause précise. C’est le type de limitation qui n’apparaît pas dans les comparatifs de benchmarks et que l’on ne découvre qu’en l’utilisant avec de vrais documents.
Ce qu’aucun LLM ne fait bien (encore)
Il convient de le dire clairement : aucun modèle actuel ne garantit la véracité. Ils peuvent inventer des références, des chiffres ou des citations avec une assurance totale. Ils n’ont pas non plus conscience de leurs limites : si vous leur posez une question sur une donnée qu’ils ne connaissent pas, ils ont tendance à combler le vide. Et ils ne raisonnent pas de manière symbolique stricte : pour des calculs financiers ou de la logique formelle, un tableur ou un moteur de règles reste plus fiable.
De plus, le coût par token peut sembler faible jusqu’à ce qu’on passe à l’échelle. Un flux qui traite des milliers de documents par jour peut transformer une facture mensuelle modeste en un montant significatif si l’on utilise le plus grand modèle pour des tâches qu’un petit modèle résoudrait tout aussi bien.
Comment choisir sans se tromper
- Définissez la tâche : classifier, rédiger, extraire, raisonner. Chacune a un modèle qui se démarque.
- Mesurez avec vos données : les benchmarks publics orientent, mais ne remplacent pas un test avec cent exemples réels de votre domaine.
- Calculez le coût total : pas seulement le prix par token, mais aussi la latence, les nouvelles tentatives et la supervision humaine.
- Vérifiez la confidentialité : si la donnée ne peut pas sortir de votre infrastructure, la décision se réduit aux modèles ouverts.
- Préparez la substitution : utiliser une couche d’abstraction (comme des bibliothèques de type LangChain ou des clients unifiés) évite de rester lié à un fournisseur.
Le comparatif utile n’est pas « quel est le meilleur modèle », mais « quel est le meilleur pour cette tâche, avec ce budget et ces contraintes ». Cette question change tous les quelques mois, et c’est pourquoi il convient de construire le flux de manière à pouvoir changer de moteur sans tout refaire.