Les LLM démontés : pre-training, fine-tuning, RAG

SÉRIE — LES COUCHES DE L'IA · 04 / 06 — LLM

ChatGPT, Claude, Gemini — même fenêtre de chat, même fluidité apparente, même promesse de répondre à n'importe quoi. Avant d'ouvrir le capot, un repère utile pour la suite de la série : un LLM n'est pas une catégorie autonome, c'est un cas industriel particulier de Deep Learning — précisément, un Transformer (architecture DL décrite dans l'article précédent) entraîné à très grande échelle sur du texte. Toute IA dite « générative » — GPT, Claude, Gemini, mais aussi DALL-E, Whisper, Suno — relève structurellement du Deep Learning, donc du Machine Learning. Le terme « LLM » désigne donc moins une couche distincte qu'une spécialisation industrielle du Deep Learning : un Transformer textuel à très grande échelle. Pourtant, sous cette interface uniforme, ces systèmes sont le produit de trois opérations profondément distinctes. La première, le pre-training, ressemble à une scolarité généraliste de dix ans condensée en quelques semaines : le modèle lit des centaines de milliards de mots et apprend à prédire le suivant, encore et encore. La deuxième, le fine-tuning, est une spécialisation : on apprend au modèle à répondre, à nuancer, à refuser ce qui est dangereux. La troisième, le RAG, est l'accès en temps réel à une bibliothèque externe : plutôt que tout mémoriser pendant l'entraînement, le modèle consulte des documents frais au moment de répondre. Ces trois couches ne s'excluent pas — elles se superposent. C'est cette architecture en trois temps que cet article démonte, pièce par pièce.

Pre-training : apprendre depuis le web

Le pré-entraînement est l'opération la plus coûteuse et la plus simple à décrire. Un Transformer — décrit dans l'article précédent de cette série — est exposé à un corpus de plusieurs dizaines de trillions de tokens, et entraîné à une seule tâche : prédire le mot suivant. Répétée à l'échelle, cette opération produit la connaissance générale du modèle.

Le corpus est la matière première. FineWeb, publié par Hugging Face en 2024, regroupe 18,5 trillions de tokens issus de Common Crawl, dédupliqués et nettoyés — la référence ouverte des modèles open. RedPajama, The Pile et Dolma complètent l'écosystème. Les laboratoires propriétaires — OpenAI, Anthropic, Google DeepMind — ne publient pas la composition exacte de leurs corpus, qui mêlent données web, code, livres numérisés et données synthétiques.

Avant d'entrer dans le modèle, le texte est découpé en tokens — des unités sub-lexicales qui représentent en moyenne quatre caractères en anglais. Deux algorithmes dominent. Le Byte-Pair Encoding (BPE), itératif, fusionne les paires de bytes les plus fréquentes ; il alimente GPT-3, GPT-4 et LLaMA. SentencePiece, language-agnostic, traite le texte brut comme une séquence de bytes sans pré-tokenisation par espace ; il équipe T5 et Gemma. La facturation des API se fait précisément à ce niveau de granularité.

La grande correction Chinchilla

Pendant trois ans, la doxa du pré-entraînement a tenu en une formule : plus de paramètres, mieux le modèle apprend. C'est ce que défendait Kaplan et al. en janvier 2020 dans « Scaling Laws for Neural Language Models », qui établissait des lois de puissance sur sept ordres de magnitude reliant performance, taille et compute. Recommandation pratique : prioriser les paramètres sur les données. GPT-3, Gopher, Megatron-Turing 530B ont été conçus dans cette logique.

En mars 2022, DeepMind publie « Training Compute-Optimal Large Language Models » et inverse la perspective. En entraînant plus de quatre cents modèles de 70 millions à 16 milliards de paramètres sur des corpus de 5 à 500 milliards de tokens, l'équipe démontre que paramètres et données doivent croître proportionnellement — autour de vingt tokens par paramètre. Le modèle vedette, Chinchilla 70B, surpasse Gopher 280B, GPT-3 175B et Megatron-Turing 530B avec le même budget compute. Les grands modèles de 2021-2022 n'étaient pas trop petits — ils étaient sous-entraînés en données.

Chinchilla 70B surpasse GPT-3 175B avec le même budget compute — ce n'est pas une question de taille, c'est une question de données.

La correction a redessiné l'industrie. LLaMA 2 7B, Mistral 7B et leurs successeurs ont été entraînés sur deux trillions de tokens et plus, bien au-delà de l'optimal Kaplan, suivant la règle Chinchilla. Les modèles plus petits mais mieux nourris sont devenus la norme.

Le coût qui ne baisse pas

Pré-entraîner un modèle frontière ne se fait pas dans un cluster du dimanche. Selon Sam Altman, le coût d'entraînement de GPT-4 dépasse les cent millions de dollars. Une étude de Cottier et al. publiée en mai 2024 estime à environ 191 millions de dollars le coût compute de Gemini Ultra. Dario Amodei, fondateur d'Anthropic, projette publiquement des runs à un milliard de dollars d'ici fin 2026 et jusqu'à dix milliards à l'horizon 2027-2028. Ces chiffres restent des estimations — OpenAI et Anthropic ne publient pas leurs coûts réels, et les paramètres de GPT-4 n'ont jamais été divulgués.

Fine-tuning : aligner le modèle

Un modèle pré-entraîné, brut, n'est pas un assistant. C'est un compléteur de texte statistique : confronté à « Comment fabriquer une bombe artisanale », il poursuit la séquence la plus plausible selon ce qu'il a vu sur le web. La transformation en assistant utile, honnête et inoffensif passe par une seconde phase d'entraînement — l'alignement, qui empile plusieurs techniques.

La première étape est le SFT (Supervised Fine-Tuning) : sur un dataset de démonstrations humaines (instruction → réponse idéale), on continue l'entraînement supervisé. Le modèle apprend le format question-réponse et le style attendu. Limites : produire un dataset SFT de qualité coûte cher en annotation, et le modèle peut mémoriser des formules sans aligner ses valeurs en profondeur.

La deuxième étape, popularisée par OpenAI, est le RLHF (Reinforcement Learning from Human Feedback). Décrit dans l'article InstructGPT (Ouyang et al., mars 2022), il enchaîne trois phases : SFT initial ; entraînement d'un reward model à partir de paires de réponses ranquées par des annotateurs ; optimisation du LLM par PPO pour maximiser la récompense, avec une contrainte KL pour ne pas trop s'éloigner du modèle SFT. Résultat devenu canonique : un modèle InstructGPT de 1,3 milliard de paramètres est préféré par les humains à GPT-3 175 milliards non aligné — cent fois plus petit, et préféré.

InstructGPT 1,3B est préféré à GPT-3 175B non aligné — la taille ne fait pas tout, l'alignement fait la différence.

RLHF reste lourd à opérer : PPO est instable, le reward model est un objet supplémentaire à maintenir, et le pipeline exige une infrastructure de RL non triviale. En mai 2023, Rafailov et al. publient « Direct Preference Optimization » — DPO — et montrent par une reformulation mathématique que le LLM est lui-même implicitement un reward model. Le pipeline simplifié tient en deux étapes : constituer un dataset de paires (prompt, réponse préférée, réponse rejetée), puis entraîner directement le LLM avec une perte de classification binaire. Plus de reward model séparé, plus de RL. Depuis fin 2023, DPO est devenu le standard de facto pour aligner les modèles open-source — Mistral, LLaMA 3 et leurs descendants l'emploient.

Anthropic a emprunté un chemin parallèle. En décembre 2022, Bai et al. publient « Constitutional AI: Harmlessness from AI Feedback », qui remplace les annotations humaines de harmlessness par un LLM guidé par une constitution textuelle — une liste de principes explicites (« ne pas aider à produire des armes », « respecter l'autonomie de l'utilisateur »). Cette technique, appelée RLAIF (Reinforcement Learning from AI Feedback), produit un modèle qui explique ses objections plutôt que de refuser sans justification. Claude 1 et Claude 2 ont été alignés selon cette méthode.

Aligner un modèle frontière reste inaccessible à la plupart des équipes. Pour adapter un LLM existant à un domaine — vocabulaire juridique, style propriétaire, code interne — la solution s'appelle LoRA (Low-Rank Adaptation). Plutôt que de mettre à jour des milliards de paramètres, LoRA n'en entraîne que 0,2 à 0,3 % via deux matrices de rang faible. QLoRA, publié en 2023, ajoute la quantification 4-bit du modèle de base et permet de fine-tuner des modèles de plusieurs milliards de paramètres sur un GPU grand public de 24 Go. Ces techniques adaptent style et vocabulaire ; elles ne servent pas à injecter des faits récents — c'est ce que le RAG résout.

RAG : la mémoire externe

Fine-tuner un modèle pour qu'il connaisse les nouveautés produit de la semaine dernière n'a aucun sens. Le coût est élevé, la mise à jour lente, et le résultat — des connaissances cuites dans les poids — est intraçable : impossible de citer la source d'une réponse, impossible de retirer un document propriétaire après coup, impossible de garantir qu'une donnée confidentielle ne sera pas régurgitée. Le RAG (Retrieval-Augmented Generation), formalisé par Lewis et al. en mai 2020 chez Meta AI, résout ces limites simultanément. Plutôt que mémoriser, le modèle consulte : à l'arrivée d'une question, le système la convertit en vecteur, retrouve les documents pertinents dans une base externe, les injecte dans le prompt comme contexte, et laisse le LLM générer la réponse en s'appuyant dessus. Les sources sont citables, le corpus se met à jour sans re-training, et les données propriétaires restent isolées du modèle.

Pipeline RAG canonique : ingestion (une fois) puis requête (à chaque interaction) — le reranker, souvent omis dans les démos, est l'étape qui fait la plus grande différence en production.

Le pipeline canonique se déroule en deux phases. L'ingestion, exécutée une fois puis répétée à chaque mise à jour, transforme les sources brutes — PDF, HTML, bases relationnelles, API — en chunks, calcule un vecteur d'embedding pour chacun, puis indexe ces vecteurs dans une base spécialisée. La requête, exécutée à chaque interaction, convertit la question en vecteur avec le même modèle d'embedding, retrouve les chunks les plus proches par similarité cosinus, applique un reranker pour réordonner par pertinence réelle, puis construit le prompt final remis au LLM.

Trois choix d'architecture déterminent la qualité du résultat. Le premier est le modèle d'embedding, qui transforme le texte en vecteur. Voyage-3.5-lite offre en 2026 le meilleur rapport qualité-prix avec un score MTEB autour de 66 et un coût inférieur à deux centimes par million de tokens. BGE-M3 (BAAI) est l'option open-source de référence — dense, sparse et multi-vector dans un seul modèle, gratuit en self-hosting. Cohere embed-v4 traite texte et image dans le même espace vectoriel. La technique Matryoshka Representation Learning, standard depuis 2025, permet de réduire les dimensions sans re-entraîner.

Le deuxième choix est la base vectorielle. Trois archétypes structurent les décisions opérationnelles.

Outil	Forces	Idéal pour
pgvector	Extension PostgreSQL, ACID natif, SQL standard, aucun composant supplémentaire	Applications déjà sur Postgres, PME, projets jusqu'à dizaines de millions de vecteurs
Qdrant	DB dédiée Rust, filtrage complexe, scaling horizontal, performances très élevées	Production fort trafic avec filtres metadata avancés
Chroma	Setup en trois lignes Python, expérience développeur excellente	Prototypage local, PoC rapide — pas pour la production sérieuse

Pinecone et Weaviate complètent l'écosystème. pgvector est utilisé en production à grande échelle par Supabase, Neon et Instacart, et reste le choix par défaut quand un Postgres existe déjà dans la stack.

Le troisième choix — souvent le plus négligé — est le reranker. Le retrieval par similarité cosinus est rapide mais grossier : il retrouve des candidats proches du vecteur de la question, sans évaluer leur pertinence réelle pour la formulation exacte. Un cross-encoder dédié — Cohere Rerank, BGE-Reranker — prend les vingt à cinquante chunks candidats et les réordonne par score de pertinence. Coût compute supérieur, gain de précision considérable. C'est l'étape qui fait la plus grande différence en production, et celle que les démonstrations omettent presque toujours.

RAG avancé en 2026

Le pipeline naïf — embed, top-k cosinus, prompt — atteint vite ses limites. Les noms propres mal orthographiés sont ratés, les questions globales (« quels sont les thèmes dominants dans ces mille documents ? ») sont impossibles, et les requêtes complexes nécessitent plusieurs tours de recherche. Trois évolutions majeures ont émergé depuis 2024.

L'hybrid search combine BM25 — algorithme lexical historique — et la recherche dense par embedding, fusionnés via Reciprocal Rank Fusion. Effet immédiat : les acronymes, noms de produits et termes techniques exacts sont retrouvés correctement, ce que le vector search pur rate systématiquement.

Le GraphRAG, publié en open source par Microsoft Research mi-2024, ajoute un knowledge graph extrait du corpus à la couche vectorielle. Le système identifie entités et relations, les structure, puis combine retrieval graph et retrieval vectoriel selon la question. Cette approche permet les questions globales sur de très grands corpus — précisément celles que la recherche par similarité ne sait pas traiter.

L'Agentic RAG, enfin, transforme le pipeline fixe en agent décisionnel. Un LLM orchestrateur décide dynamiquement : faut-il reformuler la question ? Combien de tours de retrieval lancer ? Quels outils invoquer en parallèle ? Cette logique, implémentée dans LlamaIndex et LangChain, fait le pont avec les agents — sujet du prochain article.

Tendances 2026

Trois évolutions structurent le paysage des LLM en 2026 et ne peuvent pas être ignorées dans un choix d'architecture.

La première est le contexte long. Claude Opus 4.6 supporte un million de tokens, inclus pour Max, Team et Enterprise. GPT-5.5, lancé le 23 avril 2026, accepte un million de tokens en API et 400 000 dans Codex. Gemini 2.5 Pro propose un million de tokens en multimodal natif. Llama 4 Scout, open source, annonce dix millions de tokens¹. Cette inflation ne rend pas le RAG obsolète : à un million de tokens, on ne charge pas un corpus de dix millions de documents, et la performance sur les tâches « needle in a haystack » varie selon les modèles. Long contexte et RAG sont complémentaires, pas concurrents.

La deuxième est le test-time compute — allouer plus de calcul à l'inférence plutôt qu'uniquement à l'entraînement. OpenAI o1 (septembre 2024) a inauguré une chaîne de pensée interne avant la réponse finale. o3 (début 2025) a atteint un niveau expert sur les benchmarks scientifiques. Claude 3.7 Sonnet a généralisé l'extended thinking visible. GPT-5.5 déploie en avril 2026 du compute parallèle sur les questions difficiles. Nuance importante : selon une étude OpenReview 2025, le test-time compute améliore le raisonnement logique, mathématique et scientifique, mais reste inefficace sur les tâches knowledge-intensive — celles qui dépendent d'informations factuelles précises. Pour ces dernières, le RAG reste la solution adaptée.

La troisième est le prompt caching d'Anthropic. Une lecture en cache coûte 0,1 fois le prix input normal — 90 % d'économie. L'écriture coûte 1,25 fois (TTL 5 minutes) ou 2 fois (TTL 1 heure). La latence chute jusqu'à 85 %. En production RAG, le cas d'usage canonique consiste à cacher le system prompt et les portions statiques du contexte. Disponible sur API Anthropic, AWS Bedrock et Vertex AI, cette mécanique change l'économie unitaire des assistants à fort volume.

Quand fine-tune, quand RAG, quand long contexte

Une question revient dans toute discussion d'architecture LLM : fine-tuner, RAG, long contexte, test-time compute ? Voici la grille de décision rapide.

Situation	Approche recommandée
Données récentes, mises à jour fréquentes	RAG
Adapter le style ou le vocabulaire métier	Fine-tuning (DPO + QLoRA)
Questions complexes sur corpus volumineux	GraphRAG ou Agentic RAG
Document unique long (rapport, contrat)	Long contexte (1M tokens)
Raisonnement logique, mathématiques, planification	Test-time compute (o-series, extended thinking)
Étape la plus sous-estimée d'un RAG	Reranking

Un LLM, même augmenté de RAG et de test-time compute, sait répondre. Il ne sait pas agir — réserver un vol, exécuter du code, modifier un fichier, enchaîner cinquante étapes pour résoudre un problème ouvert. Pour cela, on l'enveloppe dans une architecture qui combine outils externes, mémoire et boucle planification — exécution — observation. Ces ingrédients ne sont pas neufs : la planification automatique (STRIPS, PDDL), les agents BDI et la recherche opérationnelle les manipulent depuis les années 1970-90. Ce que les LLM apportent, c'est un moteur cognitif central capable de raisonner en langage naturel, qui débloque des tâches jusque-là hors d'atteinte. C'est l'objet de l'article suivant.

¹ Llama 4 Scout : fenêtre de contexte 10M tokens annoncée par Meta sur ai.meta.com (vérification mai 2026). ↩

Une question, un projet IA ?

Vous explorez une architecture, évaluez un modèle ou planifiez un déploiement — échangeons sur votre contexte.

Prendre contact →