Fenêtre de contexte vs RAG vs fine-tuning : que choisir

Trois façons d'apprendre à un LLM à travailler avec vos données et tâches - tout mettre dans la fenêtre de contexte, brancher du RAG (retrieval-augmented generation) ou fine-tuner le modèle. Chaque approche a son coût, sa vitesse de mise à jour des connaissances et son plafond de précision. Voici comment elles fonctionnent, leurs différences et comment choisir une stratégie pour chatbot, assistant support ou copilot interne sans dépenser inutilement.

Trois approches pour un même problème

L'objectif est le même : le modèle doit répondre sur votre produit, documentation, politiques ou domaine - pas seulement le pre-training. Options :

Approche	Idée	Où vivent les connaissances
Fenêtre de contexte	Tout le texte utile dans le prompt	À chaque requête
RAG	Chercher des fragments pertinents + générer	Dans l'index / base de connaissances
Fine-tuning	Réentraîner les poids du modèle	Dans les poids du modèle

Souvent on ne choisit pas « ou » mais une combinaison : RAG pour les faits, fine-tuning pour le style et le format, long contexte pour peu de documents dans une requête.

Fenêtre de contexte : tout dans le prompt

La fenêtre de contexte est la quantité de texte (en tokens) que le modèle « voit » dans une requête : system prompt, historique du chat, fichiers joints et instructions.

Fonctionnement

Vous mettez dans le prompt :

• instructions système (« réponds comme juriste de l'entreprise X »);
• documents pertinents en entier ou en gros blocs;
• exemples few-shot (« voici un bon modèle de réponse »).

Les modèles actuels (GPT-5.6, Claude Fable 5, Gemini 3.5 Flash) supportent 1-2M tokens de contexte - des centaines de pages. Pour beaucoup de scénarios, cela suffit sans infrastructure dédiée.

Avantages

• Infrastructure minimale - pas d'index vectoriel ni pipeline d'embeddings.
• Mise à jour instantanée - changez le texte du prompt, les connaissances sont à jour.
• Transparence - vous savez exactement ce que le modèle « voit » dans cette requête.
• Few-shot sans entraînement - les exemples dans le prompt fixent le format de réponse.

Inconvénients

• Coût qui augmente avec la longueur - tarifs long-context souvent x1,5-x2 sur la base.
• Plafond de volume - même 2M tokens ne contiennent pas toute une base enterprise.
• Qualité au milieu - le modèle peut « perdre » des détails au centre d'un très long contexte (lost-in-the-middle).
• Latence - plus de tokens en input = premier token plus lent.

Quand choisir le contexte

• Petit corpus stable : 5-50 documents, un produit, une FAQ.
• Prototype ou MVP - valider une hypothèse en un jour sans stack RAG.
• Tâches nécessitant le texte complet en une requête : comparer deux contrats, code review d'une PR entière.
• Besoin de contrôle total sur le contenu du prompt (audit, compliance).

RAG : recherche + génération

RAG (Retrieval-Augmented Generation) - avant de répondre, le système cherche des fragments pertinents dans votre base (recherche vectorielle, BM25, hybride), les insère dans le prompt et le modèle génère une réponse appuyée sur ce qui a été trouvé.

Fonctionnement

Pipeline typique :

1. Ingestion - documents découpés en chunks (300-1000 tokens), création d'embeddings.
2. Index - base vectorielle (Pinecone, Qdrant, pgvector, Chroma) + index keyword optionnel.
3. Query - question utilisateur -> embedding -> top-k chunks.
4. Generation - chunks + question -> LLM -> réponse (idéalement avec citations sources).

Mise à jour des connaissances : réindexer les documents modifiés - sans réentraîner le modèle.

Avantages

• Échelle - millions de pages si indexation et chunking sont bien faits.
• Fraîcheur - nouveau document dans l'index en minutes, pas en semaines.
• Moins d'hallucinations - le modèle s'appuie sur les fragments fournis ; les citations renforcent la confiance.
• Économie d'input - seuls les chunks pertinents entrent dans le prompt, pas toute la base.

Inconvénients

• Complexité - chunking, embeddings, reranking, évaluation, monitoring du drift.
• Qualité du retrieval = qualité de réponse - mauvaise recherche donne de mauvaises réponses avec un modèle « parfait ».
• Latence - deux étapes (recherche + génération) plus rerank.
• Doublons et contradictions - différentes versions de documents dans l'index perturbent le système.

Quand choisir RAG

• Base large ou changeant souvent : docs, wiki, tickets, Confluence, archive PDF.
• Besoin de liens vers les sources dans les réponses (support, legal, médical avec réserves).
• Beaucoup d'utilisateurs et de requêtes - moins cher de tirer 5 chunks que 500 pages en contexte.
• Données ne doivent pas être intégrées aux poids (confidentialité, isolation tenant).

Fine-tuning : connaissances dans les poids

Fine-tuning - entraînement supplémentaire du modèle de base sur vos données : paires instruction/réponse, dialogues, texte métier. Les poids se décalent pour que le modèle connaisse mieux style, terminologie et tâches typiques sans long prompt.

Variantes :

• Full fine-tuning - tous les paramètres (coûteux, rarement nécessaire).
• LoRA / QLoRA - adaptateurs sur base gelée (standard pour modèles custom).
• DPO / RLHF - alignement sur préférences (ton, sécurité, format).

Fonctionnement

1. Construire un dataset : Q&A, dialogues support, exemples de code, réponses JSON.
2. Entraîner adaptateur ou modèle complet sur GPU (heures à jours).
3. Déployer endpoint fine-tuned ou poids merged.
4. À l'inference - system prompt court, le modèle « connaît » déjà les patterns.

Le fine-tuning ne remplace pas les faits actuels : prix, versions API, actualités produit ne sont pas « mémorisés » de façon fiable sans RAG ou contexte frais.

Avantages

• Style et format - ton unifié, schema JSON, modèles de réponse.
• Moins de tokens dans le prompt - pas d'instructions longues ni dizaines d'exemples few-shot.
• Latence et coût par requête - prompt plus court pour la même tâche.
• Terminologie spécialisée - médecine, droit, jargon interne.

Inconvénients

• Coûteux et lent - données, GPU, itérations, eval ; compétences ML requises.
• Obsolescence - nouveau produit = nouveau cycle d'entraînement ou hybride avec RAG.
• Risque d'overfitting - le modèle « apprend par cœur » le training set et généralise mal.
• Plus faible sur faits rares - fine-tuning moins bon que RAG pour « trouve le paragraphe 4.2 dans policy v3 ».

Quand choisir fine-tuning

• Tâche stable avec format répétitif : classification, extraction, résumés templatisés.
• Besoin d'un prompt court et faible latence sur des millions de requêtes.
• Grand volume de dialogues étiquetés de qualité (milliers+ d'exemples).
• On-prem ou air-gapped - un modèle local sans API externe par chunk.

Comparaison par critères clés

Critère	Contexte	RAG	Fine-tuning
Volume de connaissances	Jusqu'à la limite de fenêtre	Pratiquement illimité	Limité par le training set
Fraîcheur	Instantanée (nouveau prompt)	Rapide (reindex)	Lente (retrain)
Coût de démarrage	Faible	Moyen	Élevé
Coût par requête	Augmente avec la longueur	Recherche + contexte court	Prompt faible
Hallucinations	Risque moyen	Plus faible avec bon retrieval	Moyen, erreurs « confiantes »
Citations sources	Manuel dans le prompt	Naturel	Difficile
Infrastructure	API modèle	BD vectorielle, pipeline	GPU, MLOps
Compliance / audit	Contrôle total du prompt	Logs de retrieval	Boîte noire des poids

Matrice de décision pratique

Commencez par le contexte si :

• peu de documents tiennent dans 100-200K tokens;
• vous avez besoin d'un POC en un sprint;
• chaque requête est unique et exige « le fichier entier » (diff, contrat).

Ajoutez RAG si :

• la base a grandi ou se met à jour chaque semaine;
• les utilisateurs posent des questions sur des faits précis dans des milliers de pages;
• vous voulez des citations et un taux d'hallucination plus bas.

Ajoutez fine-tuning si :

• le format de réponse est strict et identique sur 95% des requêtes;
• RAG fonctionne mais le prompt gonfle avec instructions et exemples;
• vous avez dataset et budget pour des itérations d'eval.

Stack production typique 2026 :

Modèle fine-tuned (style + routing)
    + RAG (faits depuis la base de connaissances)
    + Contexte modéré (system prompt, N derniers messages, 1-2 docs complets si besoin)

Erreurs fréquentes

• « On met tout dans 1M de contexte » - cher, lent ; qualité de retrieval souvent meilleure pour le même budget.
• Fine-tune au lieu de RAG pour FAQ - le modèle « mémorise » des prix obsolètes ; RAG ou contexte est plus simple.
• RAG sans eval - sans métriques (recall@k, faithfulness, revue humaine) le système se dégrade silencieusement.
• Chunks trop petits - le sens du paragraphe se perd ; trop grands - bruit dans le prompt.
• Ignorer le reranking - top-5 de recherche vectorielle sans cross-encoder souvent pire qu'hybride BM25 + rerank.

Conclusion

Fenêtre de contexte - démarrage rapide et contrôle total pour petits volumes. RAG - standard pour bases scalables avec faits frais et citations. Fine-tuning - investissement dans comportement et format stables, pas une encyclopédie de faits.

Pour la plupart des assistants corporate, RAG + system prompt court est optimal ; le fine-tuning s'ajoute quand des gains mesurables en qualité ou coût par requête justifient l'entraînement. Long contexte s'utilise ponctuellement - pour tâches nécessitant un document entier en un shot, pas comme remplacement de la recherche dans toute l'organisation.

Questions fréquentes

Peut-on remplacer RAG par une très longue fenêtre de contexte ?

Théoriquement - pour petits corpus. En pratique - rarement rentable : coût et latence augmentent linéairement avec la longueur du prompt, et les modèles exploitent moins bien l'information au milieu d'un long contexte. RAG ne tire que le pertinent et scale sur de grands archives. Exception - tâches « lire le fichier entier » : code review, comparer deux versions de contrat, analyser un PDF de 200 pages.

Faut-il du fine-tuning pour un chatbot corporate ?

Pas nécessairement au départ. La plupart des copilots internes et bots support se contentent de RAG + bon system prompt. Le fine-tuning a du sens avec des milliers de dialogues de référence, un format unifié (JSON, tickets, champs CRM) ou des économies critiques de tokens par requête. Mesurez d'abord la baseline avec RAG - le fine-tuning sans métriques ne rentabilise souvent pas.

Qu'est-ce qui coûte moins cher : RAG ou fine-tuning ?

RAG moins cher au départ : BD vectorielle, API embeddings, pas de cluster GPU. Fine-tuning plus cher au lancement (données, entraînement, deploy) mais peut baisser le coût par requête s'il supprime longues instructions et few-shot de chaque prompt à fort trafic. Comparez le TCO sur 6-12 mois : infra RAG + refresh embeddings vs coût de retrain et inference du modèle fine-tuned.

À quelle fréquence mettre à jour les connaissances pour chaque approche ?

Contexte - à chaque requête (prompt actuel) ou au déploiement d'une nouvelle version de template. RAG - à mesure que les documents changent : reindex incrémental de minutes à heures ; rebuild complet selon planning ou changement de modèle d'embedding. Fine-tuning - quand le comportement ou le domaine change : semaines à mois entre releases ; les faits (prix, releases) passent toujours par RAG ou tool calls.

Peut-on combiner les trois approches ?

Oui, et les meilleurs systèmes en production le font. Modèle fine-tuned fixe style et routing (« faut-il chercher dans la base ? »). RAG apporte des fragments frais. Le contexte contient règles système, historique du chat et parfois un document complet pour tâches « lire entièrement ». Clé : rôles clairs - faits depuis RAG, comportement depuis fine-tuning, contraintes et few-shot depuis le prompt - sans dupliquer le même texte dans toutes les couches.