Fine-tuning, RAG ou prompt engineering : quelle approche pour votre cas d'usage IA ?

L’une des questions les plus fréquentes dans les projets IA enterprise : “Pour que le modèle connaisse nos données internes et réponde dans notre style, faut-il le fine-tuner, faire du RAG, ou améliorer nos prompts ?” La réponse n’est pas la même selon vos contraintes de temps, de budget, de données et d’exigences de performance. Voici le framework de décision que nous utilisons chez BetterPeople.

---

Les trois approches : définitions claires

Prompt Engineering

Ce que c’est : modifier et optimiser le texte d’instruction envoyé au modèle pour obtenir de meilleures réponses, sans modifier le modèle lui-même.

Exemples :

• Ajouter des exemples (few-shot) dans le prompt
• Structurer l’instruction avec des étapes claires (chain-of-thought)
• Définir un persona (“Tu es un expert comptable…”)
• Ajouter des contraintes de format (“Réponds en JSON avec les champs suivants…”)

Analogie : c’est comme former un consultant externe en lui donnant des instructions détaillées et des exemples de votre façon de travailler — sans le recruter à plein temps.

---

RAG (Retrieval-Augmented Generation)

Ce que c’est : augmenter le prompt du modèle avec des documents ou informations pertinentes, récupérés dynamiquement depuis une base de données ou un index.

Comment ça fonctionne :

1. L’utilisateur pose une question
2. Le système cherche les passages les plus pertinents dans votre base documentaire (via embeddings vectoriels)
3. Ces passages sont injectés dans le prompt avec la question
4. Le modèle génère une réponse basée sur ces passages ET ses connaissances générales

Exemples :

• Chatbot qui répond sur la base de votre documentation interne
• Assistant juridique nourri de vos contrats et procédures
• Support client qui connaît votre catalogue produit et vos FAQ

---

Fine-tuning

Ce que c’est : ré-entraîner un modèle pré-existant sur vos données spécifiques, en ajustant ses poids pour qu’il se comporte différemment.

Comment ça fonctionne :

1. Vous préparez un dataset d’exemples input-output (ex: 1000 paires question-réponse)
2. Le modèle de base est entraîné sur ce dataset pendant quelques heures/jours
3. Le modèle résultant a “mémorisé” les patterns de votre dataset
4. Vous déployez ce nouveau modèle

Exemples :

• Modèle qui écrit exactement dans le style éditorial de votre marque
• Classificateur de tickets support spécialisé dans vos catégories internes
• Extracteur d’entités adapté à votre nomenclature métier

---

La matrice de décision

Critère	Prompt Engineering	RAG	Fine-tuning
Temps de mise en place	Heures	Jours-semaines	Semaines-mois
Coût	Très faible	Moyen	Élevé
Données nécessaires	Aucune	Documents (non labellisés)	Exemples labellisés (500-50 000+)
Connaissance de données récentes	❌	✅	❌ (gelé à l’entraînement)
Personnalisation du style/comportement	Partielle	Faible	✅ Excellent
Latence	Standard	+50-200ms	Standard
Maintenabilité	Très facile	Moyenne	Complexe
Explicabilité	✅	✅	❌

---

Quand choisir le prompt engineering

Le bon choix si…

• Vous débutez et cherchez à valider un cas d’usage rapidement
• Vos besoins de personnalisation sont modérés
• Vous n’avez pas de données d’entraînement de qualité
• Votre cas d’usage ne nécessite pas de connaissances spécifiques à votre entreprise

Techniques avancées souvent sous-utilisées

Chain-of-thought (CoT) : demandez explicitement au modèle de raisonner étape par étape avant de répondre. Améliore significativement les performances sur les tâches analytiques.

Avant d'analyser ce contrat, liste les étapes de ton analyse :
1. Identifier les parties prenantes
2. Résumer les obligations de chaque partie
...
Ensuite, effectue chaque étape.

Few-shot examples : fournissez 3 à 5 exemples de la transformation attendue. C’est le moyen le plus rapide d’aligner le format de sortie sur vos attentes.

Structured outputs : si vous avez besoin d’un JSON structuré, définissez le schéma explicitement. GPT-4o, Claude 3.5 et Mistral Large supportent le “JSON mode” qui garantit un output structuré.

Persona system prompt : un bon system prompt de 200-500 mots définissant le rôle, le style, les contraintes et les exemples peut transformer radicalement la qualité des réponses.

---

Quand choisir le RAG

Le bon choix si…

• Vous avez un corpus documentaire interne que le modèle doit connaître
• Vos données changent fréquemment (mise à jour sans ré-entraînement)
• La traçabilité est importante (savoir quelle source a été utilisée)
• Vous devez répondre avec précision sur des informations spécifiques à votre entreprise

Architecture RAG de base

1. Ingestion (une fois)
   Documents → Découpage en chunks → Embeddings → Vector DB

2. Inférence (chaque requête)
   Question → Embedding → Recherche vectorielle → Top-k chunks
   System prompt + Chunks + Question → LLM → Réponse

Outils recommandés pour RAG

Vector databases :

• Chroma : open source, idéal pour débuter et les petits volumes
• Qdrant : open source, très performant, auto-hébergeable
• Pinecone : SaaS, scalable, simple à démarrer
• pgvector : extension PostgreSQL, si vous avez déjà PostgreSQL

Frameworks d’orchestration :

• LangChain : le plus populaire, grande communauté, parfois verbeux
• LlamaIndex : optimisé pour les use cases documentaires, plus simple
• Haystack : alternative européenne (deepset, Berlin), focus enterprise

Les pièges courants du RAG

Chunking mal calibré : des chunks trop petits perdent le contexte ; trop grands, la précision de la recherche souffre. Le sweet spot est généralement 200-400 tokens avec 10-20 % de chevauchement.

Absence de métadonnées : ne pas stocker l’auteur, la date, la source avec chaque chunk rend impossible le filtrage par date ou par département.

Embeddings pas adaptés : les embeddings OpenAI (text-embedding-3) sont excellents en anglais mais moins performants en français. Pour du RAG en français, envisagez camembert-base (Inria) ou multilingual-e5-large.

Pas de re-ranking : la recherche vectorielle seule est imprécise. Ajouter un re-ranker (ex: Cohere Rerank) après la recherche initiale améliore significativement la qualité.

---

Quand choisir le fine-tuning

Le bon choix si…

• Vous avez besoin d’une personnalisation de style très précise que les prompts ne suffisent pas à capturer
• Vous avez un cas d’usage très spécialisé avec un vocabulaire ou une structure propres à votre domaine
• Vous faites des milliers d’appels par jour et souhaitez réduire la longueur des prompts (= coût)
• Vous avez les données labellisées nécessaires (minimum 500-1000 exemples de qualité)

Ce que le fine-tuning ne résout PAS

❌ Problème de connaissances factuelles : si votre problème est que le modèle ne connaît pas vos produits ou procédures internes, le fine-tuning n’est pas la solution — c’est le RAG.

❌ Raisonnement complexe : le fine-tuning sur des données limitées peut dégrader les capacités de raisonnement général du modèle.

❌ Données récentes : le fine-tuning “gèle” les connaissances à la date de l’entraînement. Pour des données changeantes, c’est une mauvaise approche.

Coût réel du fine-tuning

GPT-4o fine-tuning (OpenAI) :

• Entraînement : ~25 $/M tokens d’entraînement
• Inférence : prix multiplié par 2-3x vs le modèle de base

Open source (Llama 3, Mistral) via cloud :

• Coût GPU : ~2-5 $/heure sur AWS A100 ou H100
• Pour 10 000 exemples, comptez 5-20 heures = 10-100 $ selon la taille du modèle

Maintenance : tout changement dans vos besoins nécessite un nouvel entraînement. Le coût réel inclut cette dette de maintenance.

---

Architecture combinée : le meilleur des trois mondes

En production, les meilleurs systèmes combinent souvent les trois approches :

[System prompt + persona]     → Prompt Engineering
         +
[Documents récupérés dynamiquement] → RAG
         +
[Modèle fine-tuné sur le style]     → Fine-tuning
         ↓
    Réponse optimale

Exemple : un assistant commercial qui :

1. A un system prompt définissant son persona et ses règles (prompt engineering)
2. Récupère les fiches produit et prix en temps réel (RAG)
3. Est fine-tuné sur 2000 emails commerciaux validés de votre équipe (fine-tuning pour le style)

---

Framework de décision rapide

Question 1 : Le modèle a-t-il besoin de connaissances spécifiques à votre entreprise ?

• Non → Prompt engineering suffit probablement
• Oui → Question 2

Question 2 : Ces connaissances changent-elles régulièrement ?

• Oui → RAG
• Non → Question 3

Question 3 : Avez-vous besoin d’un style ou comportement très précis impossible à capturer en quelques exemples dans le prompt ?

• Oui + vous avez 500+ exemples labellisés → Fine-tuning
• Non → RAG + prompt engineering

---

Conclusion

Il n’y a pas de réponse universelle. Le prompt engineering est presque toujours le point de départ — il est rapide, réversible, et souvent suffisant. Le RAG est la solution de choix dès que vous avez un corpus documentaire. Le fine-tuning est une option avancée pour des cas précis, avec des ressources et des données adéquates.

BetterPeople aide les équipes à concevoir leur architecture IA dès la première itération, en évitant les erreurs courantes qui coûtent cher à corriger. Planifiez un atelier de conception.