Fine-Tuning vs Prompt Engineering vs RAG : Choisissez le bon outil

Vous avez un problème qu’un LLM doit résoudre. Vous êtes maintenant face à trois options : affiner un modèle (fine-tuning), concevoir une meilleure requête (prompt engineering) ou construire un pipeline de génération augmenté par récupération (RAG). Chacune coûte différents montants en temps et en argent. Chacune échoue de différentes manières. Choisir mal vous fera perdre des semaines.

La Tension Principale : Comportement vs Connaissance vs Les Deux

Avant de choisir, comprenez ce que chaque approche modifie réellement.

L’ingénierie de requête (Prompt engineering) modifie la façon dont un modèle raisonne sur une seule demande. Vous ne modifiez pas les poids du modèle. Vous modifiez l’entrée.

Le RAG modifie le contexte que le modèle voit. Vous récupérez des documents ou des données pertinents, vous les injectez dans la requête, et laissez le modèle travailler à partir de ces informations fondées au lieu de se fier aux données d’entraînement d’il y a 6 mois.

Le Fine-tuning modifie le modèle lui-même. Vous réentraînez les poids sur des exemples spécifiques à la tâche jusqu’à ce que le modèle internalise les schémas qui vous intéressent. C’est la seule approche qui fait réellement mémoriser quelque chose de nouveau au modèle.

Ce ne sont pas des concurrents. Ce sont des couches. Et la plupart des systèmes de production en utilisent deux, voire les trois.

Quand l’Ingénierie de Requête Gagne (C’est Souvent Suffisant)

Commencez par là. Sérieusement. L’ingénierie de requête est gratuite si vous payez déjà pour l’accès API.

Elle fonctionne lorsque :

• Le modèle sait déjà comment résoudre le problème — il a juste besoin d’instructions plus claires
• Les échecs sont dus à un raisonnement incohérent, pas à un manque de connaissances
• Votre tâche implique un raisonnement sur des informations sur lesquelles le modèle a été entraîné

Exemple : Vous avez besoin que Claude Sonnet 4 extrait des données structurées d’e-mails clients. Une requête brute échoue 15 % du temps car le modèle saute des champs ou hallucine des valeurs.

Mauvaise requête :

Extrais les données client de cet e-mail :

{email_text}

Requête améliorée :

Extrais les données client de cet e-mail. Retourne uniquement du JSON valide. Si un champ est absent de l'e-mail, utilise null. N'invente pas de valeurs.

Champs requis : nom, email, téléphone, entreprise, catégorie du problème

E-mail :
{email_text}

JSON :

La deuxième version réduit le taux d’erreur à 3 % dans la plupart des cas. Pas de réentraînement. Pas de bases de données vectorielles. Juste de la spécificité sur le format, les contraintes et ce qu’il faut faire lorsque l’information est absente.

Coût : 30 minutes d’itération.

Quand le RAG Corrige Ce Que le Prompting Ne Peut Pas

Le RAG ne sert pas pour les problèmes de raisonnement. Il sert pour les problèmes de connaissance.

Utilisez le RAG lorsque :

• Le modèle n’a pas les informations dont il a besoin (elles sont dans vos documents, votre base de données, votre historique Slack, publiées après la date limite d’entraînement du modèle)
• Vous avez besoin que le modèle cite ses sources ou fasse référence à des documents spécifiques
• Votre base de connaissances change plus rapidement que les mises à jour du modèle (documentation produit trimestrielle, prix en direct, politiques spécifiques aux clients)

Scénario réel : Une équipe de support a besoin d’un LLM pour répondre aux questions sur votre produit SaaS. Votre produit a été mis à jour trois fois depuis les données d’entraînement de GPT-4o. Le modèle hallucine des fonctionnalités qui n’existent pas et en oublie de nouvelles.

L’ingénierie de requête n’aidera pas — le modèle ne le sait littéralement pas. Le fine-tuning est excessif pour quelque chose qui change chaque mois. Le RAG est la solution : intégrez vos derniers documents, récupérez les sections pertinentes, injectez-les dans la requête.

Exemple de configuration RAG en Python :

from anthropic import Anthropic
import json

client = Anthropic()

# Vos documents comme base de connaissances simple
KNOWLEDGE_BASE = {
    "pricing": "Standard : 99 $/mois. Pro : 299 $/mois. Entreprise : personnalisé",
    "onboarding": "Les nouveaux utilisateurs bénéficient d'un essai de 30 jours pour toutes les fonctionnalités",
    "api_limit": "10 000 appels API par mois en plan Standard"
}

def retrieve_context(query):
    """Correspondance simple par mots-clés. Utilisez la recherche par embedding en production."""
    relevant = []
    for key, value in KNOWLEDGE_BASE.items():
        if any(word in query.lower() for word in key.split()):
            relevant.append(value)
    return "\n".join(relevant) if relevant else "Aucun document pertinent trouvé"

def answer_with_rag(user_question):
    context = retrieve_context(user_question)
    
    message = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=500,
        messages=[
            {
                "role": "user",
                "content": f"Réponds en te basant sur ces informations:\n{context}\n\nQuestion : {user_question}"
            }
        ]
    )
    return message.content[0].text

# Testons
print(answer_with_rag("Quel est le coût du plan Standard ?"))

Voilà le RAG en 30 lignes. En production, vous utiliseriez une récupération basée sur les embeddings (embeddings OpenAI, Cohere ou Sentence Transformers) et un magasin vectoriel (Pinecone, Weaviate, Chroma). Le principe reste le même : récupérer + injecter + répondre.

Coût : infrastructure pour les embeddings et la récupération, maintenance continue à mesure que les documents changent.

Quand le Fine-Tuning Vaut Vraiment le Coup

Le fine-tuning est l’approche la plus coûteuse. Utilisez-la uniquement lorsque les deux premières échouent.

Affinez lorsque :

• Vous avez plus de 100 exemples d’entraînement pour la tâche exacte (généralement nécessaire pour une réelle amélioration)
• Le modèle doit internaliser des schémas ou un style, pas seulement accéder à des informations
• Vous exécutez l’inférence à grande échelle et les coûts des tokens sont plus importants que le coût de l’entraînement

Exemple réel : Vous gérez des tickets de support client. Vous avez besoin que le modèle adopte le ton spécifique de votre équipe, son schéma de catégorisation et sa structure de réponse. L’ingénierie de requête gère la structure. Le RAG gère les connaissances manquantes. Mais le modèle sonne toujours mal — trop formel, ou il manque vos nuances de catégorisation spécifiques.

Affinez sur 200 conversations de support réelles (tickets + réponses idéales du modèle). Après le fine-tuning sur Llama 3 8B ou Mistral 7B (inférence locale), le modèle internalise votre style exact et vos schémas de catégorisation.

Coût : 5 à 50 $ pour le fine-tuning API (OpenAI, Anthropic). Des heures de préparation de données. Des jours d’itération pour voir si cela a aidé.

Le risque : Le fine-tuning peut dégrader les performances générales. Testez sur un ensemble de validation avant de déployer en production.

Arbre de Décision : Que Essayer en Premier

Commencez par le haut. Descendez uniquement si l’étape précédente échoue.

1. Le modèle connaît-il déjà la réponse ? Oui → Essayez l’ingénierie de requête. Non → Passez à 2.
2. L’information est-elle sous votre contrôle (documents, base de données, API) ? Oui → Construisez un RAG. Non → Passez à 3.
3. Avez-vous plus de 100 exemples étiquetés de la tâche exacte ? Oui → Fine-tunez. Non → Restez avec le RAG + un meilleur prompting.

La plupart des systèmes réels n’ont pas besoin de fine-tuning. Ils ont besoin de meilleures requêtes et d’une meilleure récupération. Le fine-tuning est un dernier recours, pas une première impulsion.

Votre Prochaine Étape : Auditez Votre Configuration Actuelle

Choisissez une tâche LLM avec laquelle vous êtes actuellement insatisfait. Mesurez le taux d’échec actuel. Ensuite, exécutez cette séquence :

1. Passez 2 heures à itérer sur la requête (spécifiez le format de sortie, les contraintes, les exemples). Mesurez le nouveau taux d’échec.
2. Si c’est toujours supérieur à l’acceptable, prenez 5 documents pertinents de votre base de connaissances et testez l’injection RAG. Mesurez à nouveau.
3. Seulement si les deux échouent, envisagez le fine-tuning — et seulement si vous avez les données d’entraînement.

Cela ne coûte presque rien et clarifie quelle approche résout réellement votre problème. La plupart des équipes sautent complètement l’étape 1 et passent directement à l’étape 3. C’est coûteux et généralement erroné.