Fine-tuning vs RAG : Quand utiliser quoi

Le débat autour du fine-tuning vs RAG est souvent pollué par les biais des éditeurs de logiciels et une mauvaise compréhension des compromis. Si vous construisez des applications LLM en production, vous ne pouvez pas vous permettre de vous tromper sur cette décision d'architecture. Choisir la mauvaise voie conduit à des cycles GPU gaspillés, des données obsolètes et des systèmes sujets aux hallucinations.

Cet article balaie le bruit théorique. Nous examinerons précisément l'espace du problème, analyserons l'architecture de la génération augmentée par récupération (RAG) et celle du fine-tuning (affinage) de modèle, puis nous vous fournirons un cadre décisionnel clair pour savoir quand utiliser l'une ou l'autre de ces approches.

Le problème

Les grands modèles de langage (LLM) sont figés dans le temps. Un modèle entraîné en 2024 ne sait rien de la base de code propriétaire que votre équipe a écrite hier, pas plus qu'il ne comprend les dernières modifications apportées à l'API il y a une heure. Lorsque vous demandez à un modèle de fondation de raisonner sur des documents internes ou des données d'entreprise privées, soit il hallucinera avec assurance, soit il refusera de répondre.

Vous disposez de données spécifiques à votre domaine. Vous avez besoin que le LLM les utilise. C'est là le problème fondamental.

Pourquoi c'est difficile

Combler le fossé entre les poids statiques d'un LLM et des données privées et dynamiques introduit d'importants défis d'ingénierie. Vous ne pouvez pas simplement injecter un PDF de 50 Mo dans la fenêtre de contexte d'un prompt - même avec des modèles prenant en charge des fenêtres de plus d'un million de tokens, les contextes longs souffrent du phénomène du « perdu au milieu » (lost in the middle), d'une latence massive et de coûts de tokens exorbitants.

Si vous décidez de mettre à jour les poids du modèle, vous entrez dans le domaine complexe de l'entraînement distribué, de la curation de jeux de données et de l'oubli catastrophique. Les pipelines d'entraînement se cassent, les formats de données nécessitent une standardisation rigoureuse, et évaluer si un modèle affiné s'est réellement amélioré exige des frameworks d'évaluation manuelle coûteux.

Architecture : RAG vs Fine-Tuning

Génération augmentée par récupération (RAG)

Le RAG laisse les poids du LLM inchangés. À la place, il modifie le prompt de manière dynamique au moment de l'inférence. Vous convertissez vos données propriétaires en vecteurs de haute dimension, les stockez dans une base de données vectorielle et effectuez des recherches par similitude sémantique lorsqu'une requête arrive. Les documents récupérés sont ensuite injectés dans le contexte du prompt.

Le RAG est un problème de récupération de données déguisé en problème d'IA. L'architecture ressemble généralement à ceci :

1. Pipeline d'ingestion des données (extraction de texte à partir de PDF, Confluence, etc.)
2. Stratégie de découpage (division du texte en blocs de 512 à 1024 tokens)
3. Modèle d'embedding (ex. text-embedding-3-small)
4. Magasin de vecteurs (vector store) (ex. Pinecone, Qdrant, pgvector)
5. Modèle de génération (ex. GPT-4, Claude 3 Opus)

Fine-Tuning (Affinage)

Le fine-tuning modifie de manière permanente les poids du réseau de neurones. Vous prenez un modèle pré-entraîné (comme Llama-3-8B) et l'entraînez davantage sur un jeu de données préparé composé de paires de prompts-complétions. Cela intègre les connaissances ou le comportement directement dans les paramètres du modèle.

Architecture pour le Fine-Tuning (spécifiquement LoRA/QLoRA) :

1. Préparation du jeu de données (format JSONL d'instructions et de réponses)
2. Sélection du modèle de base
3. Adaptateurs de fine-tuning efficaces en paramètres (PEFT)
4. Cluster d'entraînement distribué
5. Boucles d'évaluation
6. Serveur d'inférence avec adaptateurs fusionnés

Fine-tuning vs RAG : Notre analyse tranchée

Utilisez le RAG lorsque le modèle a besoin de connaître des faits. Utilisez le fine-tuning lorsque le modèle a besoin d'apprendre un format, un ton ou un comportement.

N'affinez pas un modèle pour lui faire mémoriser la politique RH de votre entreprise. Il oubliera des détails, hallucinera sur des chiffres et nécessitera un réentraînement complet à chaque modification de la politique. Utilisez le RAG pour cela.

N'utilisez pas le RAG pour apprendre à un modèle à produire des schémas JSON complexes, spécifiques et propriétaires, ou à écrire du code dans un DSL interne hautement personnalisé. La fenêtre de contexte débordera d'exemples few-shot (few-shot examples), et la latence tuera votre application. Utilisez le fine-tuning pour cela.

Implémentation

Construire le pipeline RAG

Pour le RAG, nous utiliserons Python 3.11, LlamaIndex 0.10.x et Qdrant.

# requirements.txt
# llama-index==0.10.15
# llama-index-vector-stores-qdrant==0.1.2
# qdrant-client==1.7.3

import qdrant_client
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext
from llama_index.vector_stores.qdrant import QdrantVectorStore

# 1. Initialiser le Vector Store
client = qdrant_client.QdrantClient(location=":memory:")
vector_store = QdrantVectorStore(client=client, collection_name="internal_docs")
storage_context = StorageContext.from_defaults(vector_store=vector_store)

# 2. Charger les documents
documents = SimpleDirectoryReader("./data").load_data()

# 3. Construire l'index
index = VectorStoreIndex.from_documents(
    documents,
    storage_context=storage_context,
)

# 4. Requête
query_engine = index.as_query_engine()
response = query_engine.query("What is the new API rate limit?")
print(response)

Construire le pipeline de Fine-Tuning

Pour le fine-tuning, nous utilisons Unsloth 2024.4 pour un entraînement 2x plus rapide et une utilisation réduite de la VRAM.

# requirements.txt
# unsloth[cu121-ampere] @ git+https://github.com/unslothai/unsloth.git
# trl==0.8.1

from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments
from datasets import load_dataset

# 1. Charger le modèle de base et les adaptateurs LoRA
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/llama-3-8b-bnb-4bit",
    max_seq_length = 2048,
    load_in_4bit = True,
)

model = FastLanguageModel.get_peft_model(
    model,
    r = 16,
    target_modules = ["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_alpha = 16,
    lora_dropout = 0, 
    bias = "none",
    use_gradient_checkpointing = "unsloth",
)

# 2. Préparer le jeu de données
dataset = load_dataset("json", data_files="internal_dsl_dataset.jsonl", split="train")

def format_prompts(examples):
    instructions = examples["instruction"]
    outputs      = examples["output"]
    texts = []
    for instruction, output in zip(instructions, outputs):
        text = f"Instruction: {instruction}\nOutput: {output}<|end_of_text|>"
        texts.append(text)
    return { "text" : texts }

dataset = dataset.map(format_prompts, batched = True)

# 3. Entraînement
trainer = SFTTrainer(
    model = model,
    tokenizer = tokenizer,
    train_dataset = dataset,
    dataset_text_field = "text",
    max_seq_length = 2048,
    args = TrainingArguments(
        per_device_train_batch_size = 2,
        gradient_accumulation_steps = 4,
        max_steps = 60,
        learning_rate = 2e-4,
        fp16 = not torch.cuda.is_bf16_supported(),
        bf16 = torch.cuda.is_bf16_supported(),
        logging_steps = 1,
        output_dir = "outputs",
    ),
)

trainer.train()

Pièges à éviter

Pièges du RAG

1. Découpage aveugle : Couper le texte indistinctement tous les 512 tokens coupe les phrases au milieu et détruit le sens sémantique. Vous devez utiliser le découpage sémantique (semantic chunking) ou le découpage récursif par caractères (recursive character splitting).
2. Ignorer les métadonnées : La recherche par similitude vectorielle est fondamentalement aveugle au contexte temporel ou logique. Si vous cherchez « revenus du Q3 », l'embedding peut récupérer un document de 2021 parce qu'il lui ressemble mathématiquement. Filtrez toujours par métadonnées (date, auteur, catégorie) avant d'effectuer la recherche vectorielle.
3. Perdu au milieu (Lost in the Middle) : Injecter 20 documents récupérés dans la fenêtre de contexte conduit souvent le LLM à ignorer les documents du milieu. Réordonnez (re-rank) vos documents récupérés (à l'aide d'outils comme Cohere Rerank) pour placer les éléments les plus pertinents au tout début et à la toute fin de la fenêtre de contexte.

Pièges du Fine-Tuning

1. Données de mauvaise qualité : Le fine-tuning amplifie la qualité de votre jeu de données. Si vos données d'entraînement contiennent des erreurs de formatage, des hallucinations ou des contradictions, votre modèle affiné produira de manière systématique ces mêmes erreurs.
2. Surapprentissage (Overfitting) : Entraîner le modèle sur trop d'époques avec un petit jeu de données détruira ses capacités de raisonnement général. Il apprendra à réciter les données d'entraînement mot pour mot, mais échouera lamentablement face à de nouvelles requêtes.
3. Oubli catastrophique : À mesure que le modèle se spécialise sur votre tâche, il oublie inévitablement d'autres compétences. Un modèle fortement affiné pour écrire des requêtes SQL peut soudainement devenir très mauvais pour écrire du Python ou résumer du texte.

Résultat

Cessez de traiter le fine-tuning et le RAG comme des solutions exclusives. Ils résolvent des problèmes différents.

Le RAG apporte le contexte externe. Le fine-tuning façonne le comportement interne.

Si votre application doit raisonner sur des bases de connaissances privées et changeantes, construisez un pipeline RAG robuste. Si votre application exige que le modèle produise systématiquement des structures complexes, adopte un ton de marque spécifique ou s'exécute efficacement sur des modèles open source plus petits et moins coûteux, vous devez l'affiner.

Les architectures d'entreprise les plus avancées combinent les deux. Elles affinent un petit modèle peu coûteux (comme Llama 3 8B) pour qu'il comprenne parfaitement leur schéma de sortie JSON et les intentions de l'utilisateur, puis elles connectent ce modèle affiné à un pipeline RAG d'envergure pour récupérer les faits réels nécessaires à l'alimentation de ce schéma.

Faites votre choix d'architecture en fonction de la vitesse d'évolution de vos données et de vos exigences de sortie, et non en suivant la dernière tendance sur les réseaux sociaux. Construisez de manière pragmatique, évaluez sans relâche et maîtrisez les mécanismes internes de vos technologies.