LLM en production, partie 2 — RAG, fine-tuning, ou juste un prompt ?
Il y a trois manières honnêtes de rendre un LLM utile avec vos données. La plupart des équipes choisissent la mauvaise parce que le choix est cadré par les vendeurs d'outils, pas par les arbitrages d'ingénierie. Voici l'arbre de décision réel.
Les trois approches en un paragraphe chacune
Prompt seul
Vous passez tout ce que le modèle doit savoir dans le prompt lui-même. Quelques exemples few-shot, des instructions, du contexte. Pas de récupération externe, pas d'entraînement de modèle.
Idéal pour : des connaissances stables qui tiennent dans le contexte, des cas d'usage à faible volume, des prototypes, tout ce où la « connaissance » est en réalité du conditionnement de comportement.
RAG (Retrieval-Augmented Generation)
Vous gardez vos données dans une vector store (ou un index full-text, ou les deux). À chaque requête, vous récupérez les fragments pertinents et les injectez dans le prompt avant que le modèle réponde.
Idéal pour : des bases de connaissances larges et évolutives ; des besoins de citation/auditabilité ; des situations où le coût du réentraînement dépasse celui de la récupération.
Fine-tuning
Vous prenez un modèle de base et entraînez une fine couche dessus avec des exemples d'entrée → sortie pour votre domaine. Le modèle apprend les patterns plutôt que de les lire à l'inférence.
Idéal pour : des formats de sortie constants, du jargon domaine-spécifique, de la réplication de ton, des situations où vous avez ≥1000 paires d'exemples de haute qualité.
L'arbre de décision réel
Connaissance stable + petite ? → Prompt seul.
Connaissance large ou évolutive ? → RAG.
Le problème est le FORMAT ou le TON (pas la connaissance) ? → Fine-tune.
Aucun ? → Combinez. RAG + formatter fine-tuné, c'est la stack de prod la plus courante.
La réalité des coûts
| Coût initial | Par requête | Coût de mise à jour | |
|---|---|---|---|
| Prompt seul | $0 | Élevé (prompts longs = plus de tokens) | Éditer le prompt |
| RAG | Vector store + pipeline de chunking | Modéré (la récupération coûte peu, mais le contexte reste gros) | Réindexer à chaque changement |
| Fine-tune | Run d'entraînement à $500–$10k | Plus faible par requête (prompts plus courts) | Nouveau run à chaque mise à jour significative |
Pour la plupart des produits, RAG gagne sur le coût total de possession parce que les connaissances évoluent plus vite que les fine-tunes ne peuvent suivre.
Ce que les équipes font mal
La plus grande erreur : fine-tuner quand le vrai problème est une mauvaise récupération. Vous pouvez fine-tuner un modèle pour mémoriser 200 faits sur votre produit, mais vous ne pouvez pas le fine-tuner pour connaître la politique que votre équipe a publiée hier. Si vos données changent plus vite que votre cadence d'entraînement, vous voulez du RAG, pas un fine-tune.
La deuxième plus grande erreur : livrer du RAG vanille sans réfléchir à la taille des chunks, au nombre de récupérations, ou au rerank. Chunking par défaut + top-3 retrieval, c'est presque jamais la bonne configuration. Passez une semaine à régler ça et la qualité de votre RAG grimpe plus que le passage à un autre modèle ne le ferait.
Ce qu'on a couvert, ce qui suit
Cet article est volontairement opinionné. Les arbitrages sont réels et le coût de choisir mal est élevé. Pour un traitement plus exhaustif, les cookbooks d'Anthropic et OpenAI ont de bons exemples — mais ni l'un ni l'autre ne vous dira quand ne pas utiliser leur outil.
Prochainement dans la série production : comment on fait tourner les évaluations rapidement, pourquoi ROC/précision/recall mentent sur la qualité des LLM, et les trois techniques d'éval auxquelles on fait confiance.
