Aller au contenu
Ressources/Guide technique
Analyse technique approfondie

Guide des compétences IA et du fine-tuning

Un guide complet pour enseigner de nouvelles compétences aux modèles d'IA : fine-tuning supervisé (SFT), LoRA/QLoRA, RLHF, DPO, GRPO, distillation de modèles, fusion de modèles et évaluation. Du concept à la production — avec du code fonctionnel à chaque étape.

11 sections
45 min de lecture
Code prêt pour la production
Mars 2026

Le paysage du fine-tuning

Le pré-entraînement donne au modèle une connaissance large du monde, mais une seule compétence : prédire le token suivant. Le modèle a vu Wikipédia, du code, des livres et le web — mais il ne sait pas être utile, suivre des instructions ou refuser des requêtes dangereuses. Le fine-tuning est le processus qui enseigne ces comportements après le pré-entraînement.

L'industrie a convergé vers une échelle d'entraînement standard que suivent tous les grands modèles de pointe (GPT-4o, Claude Opus 4.6, Llama 4, Gemini 2.5). Chaque étape s'appuie sur la précédente — vous ne pouvez pas sauter le SFT pour passer directement au RLHF.

L'échelle d'entraînement

graph LR
  A[Raw Text Corpus] -->|Pretraining cross-entropy| B[Base Model]
  B -->|Supervised Fine-Tuning| C[Instruction-Following Model]
  C -->|RLHF / DPO / GRPO| D[Aligned Model]
  D -->|Evaluation & Red-teaming| E[Production Model]

Pré-entraînement

Prédiction auto-supervisée du token suivant sur d'immenses corpus. Encode la connaissance du monde.

SFT

Fine-tuning supervisé sur des paires instruction-réponse. Apprend au modèle à être utile.

Alignement sur les préférences

RLHF, DPO ou GRPO sur des données de préférences humaines. Rend les sorties sûres et préférées.

Évaluation

Benchmarks automatisés + red-teaming. Détecter les régressions avant la mise en production.

Fine-tuning vs ingénierie de prompts
L'ingénierie de prompts rend les comportements conditionnels (ils n'apparaissent que lorsque le prompt le demande). Le fine-tuning les rend par défaut — le modèle les manifeste de manière constante sans qu'on le lui dise. À grande échelle, cette différence de fiabilité est significative.

Fine-tuning supervisé (SFT)

Le SFT entraîne le modèle à prédire les tokens de l'assistant à partir d'un contexte de conversation. Le détail clé est le loss masking : la perte d'entropie croisée est calculée uniquement sur les tokens de l'assistant, pas sur le prompt système ni sur les tours de l'utilisateur. Cela empêche le modèle d'« apprendre » le côté utilisateur de la conversation.

Formats de données

Trois formats dominent le paysage du SFT. ChatML est devenu le plus largement adopté grâce à ses tokens spéciaux sans ambiguïté.

text (ChatML format)
<|im_start|>system
You are a helpful AI assistant specialized in European AI regulation.
<|im_end|>
<|im_start|>user
What are the key obligations under the EU AI Act for high-risk systems?
<|im_end|>
<|im_start|>assistant
High-risk AI systems under the EU AI Act (in force August 2024) must comply with...
<|im_end|>

Hyperparamètres clés

ParamètreValeur typiqueNotes
Learning rate2e-5Plus faible qu'au pré-entraînement ; décroissance en cosinus
Epochs2–3Plus d'époques → surapprentissage sur les petits jeux de données
Batch size (effective)64–128Utiliser l'accumulation de gradient pour une faible mémoire GPU
Warmup ratio0.110 % des étapes pour le warmup du LR
Max sequence length2048–8192Faire correspondre à votre fenêtre de contexte d'inférence

SFT avec le SFTTrainer de trl

python
from transformers import AutoModelForCausalLM, AutoTokenizer
from trl import SFTConfig, SFTTrainer
from datasets import load_dataset
import torch

model_name = "meta-llama/Llama-4-Scout-17B-16E-Instruct"  # 2026: Llama 4 Scout replaces Llama 3.1 8B
model = AutoModelForCausalLM.from_pretrained(
    model_name, torch_dtype=torch.bfloat16, device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained(model_name)

dataset = load_dataset("HuggingFaceH4/ultrachat_200k", split="train_sft")

sft_config = SFTConfig(
    output_dir="./sft-llama-4-scout",
    num_train_epochs=3,
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    learning_rate=2e-5,
    lr_scheduler_type="cosine",
    warmup_ratio=0.1,
    logging_steps=10,
    save_strategy="epoch",
    bf16=True,
)

trainer = SFTTrainer(
    model=model,
    args=sft_config,
    train_dataset=dataset,
    processing_class=tokenizer,
)
trainer.train()
trainer.save_model()
La qualité des données prime sur la quantité
1 000 paires instruction-réponse de haute qualité et diversifiées surpassent systématiquement 100 000 exemples bruités. Les meilleurs jeux de données d'instruction-tuning (Alpaca 52K, WizardLM 196K, OpenHermes 1M, UltraChat 200K) réussissent grâce à la curation, pas à la taille brute.

Fine-tuning efficace en paramètres : LoRA

Le fine-tuning complet modifie l'ensemble des ~7 milliards de paramètres d'un modèle 7B. En bfloat16, cela représente 14 Go rien que pour le stockage des paramètres, sans compter les gradients et les états de l'optimiseur. LoRA (Low-Rank Adaptation, Hu et al. 2021) exploite une observation empirique clé : les variations de poids pendant le fine-tuning sont de faible rang.

Au lieu d'apprendre une mise à jour de poids complète ΔW ∈ ℝ^(d×k), LoRA apprend deux petites matrices : A ∈ ℝ^(d×r) et B ∈ ℝ^(r×k) où r ≪ min(d, k). À l'inférence, l'adaptateur est réintégré : W′ = W + αAB/r. Une fois fusionné, le surcoût d'inférence est nul.

r = 4
Adaptation minimale (ton, style)
~21M (0.3%)
r = 8
Par défaut — qualité équilibrée
~42M (0.6%)
r = 16
Plus de capacité, tâches de domaine
~83M (1.0%)
r = 64
Qualité proche du fine-tuning complet
~335M (4.1%)
Ratio alpha/rang
Gardez lora_alpha = 2 × r comme point de départ (p. ex. r=16, alpha=32). Cela contrôle le taux d'apprentissage effectif de l'adaptateur. Alpha plus élevé = adaptation plus forte ; trop élevé = instabilité.

LoRA avec PEFT

python
from peft import LoraConfig, TaskType, get_peft_model

config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,
    lora_alpha=32,
    lora_dropout=0.05,
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],
    bias="none",
)

model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: 83,886,080 || all params: 8,030,261,248 || trainable%: 1.044

# After training, merge adapter back into the base weights
merged = model.merge_and_unload()
merged.save_pretrained("./my-lora-merged")

Comparaison LoRA vs fine-tuning complet

MéthodeParamètres entraînablesRAM GPU (8B)QualitéVitesse d'entraînement
Full Fine-Tuning7B (100%)~80 GBOptimaleLa plus lente
LoRA r=4~21M (0.3%)~16 GBBonneRapide
LoRA r=16~83M (1.0%)~18 GBTrès bonneRapide
LoRA r=64~335M (4.1%)~24 GBProche du FT completModérée
DoRA : LoRA à décomposition de poids
DoRA (Liu et al. 2024) décompose les mises à jour de poids en composantes de magnitude et de direction, en appliquant des taux d'apprentissage distincts à chacune. Il obtient systématiquement des scores de benchmark supérieurs de 1 à 2 % à ceux du LoRA standard, sans surcoût d'inférence. Disponible dans PEFT via use_dora=True dans LoraConfig.

QLoRA : fine-tuning en 4 bits

Même avec LoRA, le modèle de base chargé en bfloat16 nécessite 16 Go pour un modèle 8B — au-delà des budgets GPU grand public. QLoRA (Dettmers et al. 2023) résout cela en quantifiant le modèle de base gelé en NormalFloat 4 bits (NF4) et en entraînant les adaptateurs LoRA en précision bfloat16.

Quantification NF4

NormalFloat4 est théoriquement optimal du point de vue de l'information pour des poids de réseau de neurones distribués normalement. Moins d'erreur qu'int4 ou fp4.

Optimiseurs paginés

Les états de l'optimiseur sont automatiquement paginés vers la RAM CPU lorsque la mémoire GPU se remplit, évitant les plantages OOM pendant l'entraînement.

Double quantification

Quantifie les constantes de quantification elles-mêmes, économisant environ 0,5 bit supplémentaire par paramètre.

Exigences matérielles

ModèleVRAM FP16VRAM QLoRAGPU minimal
Llama 4 Scout (17B)34 GB10 GBRTX 4090 24GB
Llama 4 Maverick (70B-class)140 GB40 GB2× A100 40GB
Llama 4 Behemoth (frontier)800+ GB~200 GB8× H100 80GB

QLoRA avec bitsandbytes

python
from transformers import AutoModelForCausalLM, BitsAndBytesConfig
import torch

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-4-Maverick-17B-128E-Instruct",  # 2026: Llama 4 Maverick replaces Llama 3.1 70B
    quantization_config=bnb_config,
    device_map="auto",
)
# Now apply LoRA to the 4-bit model — same LoraConfig + get_peft_model as before
Unsloth pour les charges sur un seul GPU
Unsloth fournit des kernels CUDA personnalisés pour QLoRA qui atteignent un entraînement 2× plus rapide et 50 % de VRAM en moins par rapport au QLoRA bitsandbytes standard. Il prend en charge les familles Llama 4, Llama 3, Mistral, Qwen et Gemma et constitue le choix de référence pour le fine-tuning sur un seul GPU.

Alignement : RLHF

Le Reinforcement Learning from Human Feedback (RLHF) a été la percée qui a transformé GPT-3 en InstructGPT puis en GPT-4o. Il aligne le comportement du modèle sur les préférences humaines — pas seulement le suivi d'instructions, mais le fait de rendre les sorties véritablement préférées, sûres et utiles.

Le pipeline en trois étapes

Stage 1

Échauffement SFT

Affiner le modèle de base sur un ensemble curé de démonstrations de suivi d'instructions de haute qualité. Cela crée la politique de départ que le RLHF améliorera.

Stage 2

Entraînement du modèle de récompense

Entraîner un classifieur sur des préférences humaines par paires : étant données deux complétions (y_w, y_l) au même prompt, laquelle est la meilleure ? Perte : log σ(r(x, y_w) − r(x, y_l)).

Stage 3

Optimisation PPO

Utiliser la Proximal Policy Optimization pour maximiser le score du modèle de récompense tout en restant proche de la politique SFT (la pénalité de divergence KL empêche le reward hacking).

Schéma du pipeline RLHF

graph LR
  A[Base Model] -->|SFT on demos| B[SFT Model]
  B -->|Sample completions| C[Completion Pairs]
  C -->|Human labelers rank| D[Preference Dataset]
  D -->|Train| E[Reward Model]
  B -->|Initialize policy| F[Policy Model]
  F -->|Rollout + PPO| G[RL Optimization]
  E -->|Score rollouts| G
  G -->|Converged| H[RLHF Model]
Complexité du PPO
Le RLHF avec PPO requiert quatre modèles simultanément : la politique, la politique de référence (modèle SFT gelé), le modèle de récompense et le modèle de valeur. Cela rend le RLHF gourmand en mémoire et notoirement difficile à stabiliser. Le reward hacking (la politique trouve des moyens d'obtenir un score élevé sans être réellement bonne) est un défi persistant. C'est pourquoi le DPO est devenu largement préféré.

Alignement : DPO et GRPO

Le DPO (Direct Preference Optimization) (Rafailov et al. 2023) élimine entièrement le modèle de récompense. Il a montré mathématiquement que la politique RLHF optimale peut être exprimée directement comme une fonction des données de préférences, réduisant un pipeline en trois étapes à une seule étape de fine-tuning.

La perte DPO optimise directement la politique sur des paires de préférences (prompt, chosen, rejected) en utilisant le modèle SFT comme référence gelée. Pas de PPO, pas de modèle de récompense, pas de collecte distincte de données d'entraînement pour le RM.

DPO avec le DPOTrainer de trl

python
from trl import DPOConfig, DPOTrainer
from datasets import load_dataset

# Dataset needs: prompt, chosen, rejected columns
dataset = load_dataset("HuggingFaceH4/ultrafeedback_binarized", split="train_prefs")

dpo_config = DPOConfig(
    output_dir="./dpo-output",
    num_train_epochs=3,
    per_device_train_batch_size=2,
    gradient_accumulation_steps=8,
    learning_rate=5e-7,   # much smaller than SFT lr
    beta=0.1,             # KL penalty coefficient
    bf16=True,
)

trainer = DPOTrainer(
    model=sft_model,          # your SFT fine-tuned model
    ref_model=sft_ref_model,  # frozen reference
    args=dpo_config,
    train_dataset=dataset,
    processing_class=tokenizer,
)
trainer.train()

GRPO : l'approche de DeepSeek

La Group Relative Policy Optimization (GRPO) (utilisée dans DeepSeek-R1) élimine le modèle de référence. Pour chaque prompt, elle échantillonne plusieurs sorties et utilise la récompense moyenne du groupe comme référence pour l'estimation de l'avantage. C'est moins coûteux que le PPO (pas de modèle de valeur) et mieux adapté aux tâches de raisonnement où l'on peut vérifier la justesse de manière programmatique.

Avantage clé du GRPO :
Aucun modèle de référence requis + récompenses relatives au groupe = entraînement efficace pour les tâches vérifiables (mathématiques, code, sortie structurée).

Comparaison des méthodes d'alignement

MéthodeCalculStabilitéBesoins en donnéesNotes
RLHF (PPO)Très élevéFaibleClassements humains4 modèles en mémoire ; risque de reward hacking
DPOFaibleÉlevéePaires de préférencesPas de modèle de récompense ; pipeline plus simple
GRPOMoyenMoyenneÉchantillons de rolloutPas de modèle de référence ; adapté au raisonnement
SimPOFaibleÉlevéePaires de préférencesPas de modèle de référence ; récompense en log-prob moyen

Distillation de modèles

La distillation de connaissances entraîne un petit modèle « élève » à imiter un grand modèle « enseignant ». L'idée clé est que l'enseignant fournit des distributions de probabilité douces sur le vocabulaire (logits) plutôt que des étiquettes one-hot. Ces cibles douces encodent bien plus d'information — elles révèlent quels tokens sont sémantiquement proches de la bonne réponse, offrant à l'élève un signal d'entraînement plus riche.

La perte combinée : L = α × L_CE(étiquettes dures) + (1 − α) × L_KL(logits de l'élève ‖ logits de l'enseignant). La mise à l'échelle par température T > 1 adoucit la distribution de l'enseignant, répartissant la masse de probabilité sur davantage de tokens et rendant les étiquettes douces encore plus informatives.

Pipeline de distillation

graph TB
  A["Large Teacher (70B)"] -->|"Generate on training data"| B[Soft Logits]
  C[Input Prompt] --> A
  C --> D["Small Student (7B)"]
  B -->|KL Loss| D
  E[Ground Truth] -->|CE Loss| D
  D -->|Both losses| F[Distilled Student]

Distillation de réponses

L'élève imite les sorties de l'enseignant — générer les complétions de l'enseignant, entraîner l'élève à les reproduire. Utilisée par DeepSeek-R1-Distill pour transférer les traces de raisonnement.

Distillation de caractéristiques

Faire correspondre les représentations intermédiaires (états cachés, motifs d'attention) entre les couches de l'enseignant et de l'élève. Transfère la connaissance structurelle, pas seulement les sorties de surface.

Décodage spéculatif

Un petit modèle de brouillon propose des séquences de tokens ; le grand modèle les vérifie en parallèle. Atteint une accélération d'inférence de 2 à 4× sans perte de qualité.

Distillation on-policy

L'élève génère les tokens ; l'enseignant les note. Évite le biais d'exposition (décalage de distribution entre entraînement et test) courant dans la distillation hors ligne.

Exemples réels de distillation
  • Phi-3 / Phi-4 (Microsoft) : distillés depuis GPT-4 sur des données synthétiques curées
  • Gemma 2 (Google) : distillé depuis Gemini Ultra ; le 9B rivalise avec des modèles bien plus grands
  • DeepSeek-R1-Distill : traces de raisonnement de R1 distillées dans des modèles Qwen2.5 7B / 14B

Fusion de modèles

La fusion de modèles combine plusieurs checkpoints affinés en un seul modèle sans aucun entraînement supplémentaire. C'est peu coûteux, rapide et étonnamment efficace pour combiner des compétences spécialisées — code, mathématiques, suivi d'instructions — en un seul modèle déployable. Les modèles fusionnés apparaissent fréquemment en tête du HuggingFace Open LLM Leaderboard.

SLERPInterpolation linéaire sphérique

Interpolation douce entre deux checkpoints de modèle dans l'espace des poids. Traite les poids comme des points sur une hypersphère. Idéale pour mélanger deux modèles étroitement liés.

Task ArithmeticAjout/soustraction de deltas de fine-tuning

Calculer ΔW = W_FT − W_base pour chaque modèle affiné, puis additionner les deltas. Permet de composer des capacités ou de soustraire des comportements indésirables.

TIES-MergingTrim, Elect Signs, Merge

Résout les conflits entre modèles : élaguer les paramètres de faible magnitude, élire le signe dominant pour chaque poids, puis fusionner. Gère proprement 3 modèles ou plus.

DAREDrop and Rescale

Supprime aléatoirement des deltas de poids de fine-tuning (avec une probabilité p) et redimensionne les survivants pour préserver la norme. Réduit les interférences entre modèles.

Configuration MergeKit (TIES)

yaml
# mergekit config.yaml
models:
  - model: meta-llama/Llama-4-Scout-17B-16E
    parameters:
      weight: 0.4
  - model: ./llama-4-scout-code-finetuned
    parameters:
      weight: 0.3
  - model: ./llama-4-scout-math-finetuned
    parameters:
      weight: 0.3
merge_method: ties
base_model: meta-llama/Llama-4-Scout-17B-16E
parameters:
  density: 0.7
  normalize: true
bash
mergekit-yaml config.yaml ./merged-model --cuda
Frankenmerge (empilement de couches)
Une technique plus radicale : empiler différentes couches de différents checkpoints de modèle — p. ex. les couches 0–16 du modèle A, les couches 17–32 du modèle B. Ne nécessite aucun entraînement et peut produire des capacités surprenantes, mais demande de l'expérimentation pour trouver de bonnes combinaisons de couches. MergeKit le prend en charge via la méthode de fusion passthrough.

Préparation des données

La qualité des données est le facteur le plus déterminant de la réussite du fine-tuning — plus important que l'architecture du modèle, la durée d'entraînement ou le choix de l'optimiseur. Un jeu de données mal curé garantit de mauvais résultats, quoi qu'il en soit par ailleurs.

Rédigé par des humainsLa plus élevée
Le plus coûteux

Exemples rédigés par des experts ; meilleur rapport signal/bruit. Utilisé pour les comportements critiques.

Généré par GPT-4 / ClaudeÉlevée
Modéré

Génération synthétique avec des modèles de pointe. Idéal pour amorcer la couverture d'un domaine à grande échelle.

Evol-Instruct / MagpieBonne
Faible

Faire évoluer des instructions de départ vers des variantes plus difficiles et plus diversifiées. Utilisé dans WizardLM et OpenHermes.

Filtré depuis InternetVariable
Le moins cher

Nécessite un filtrage qualité agressif : déduplication, filtre de longueur, filtre de perplexité, filtre de sécurité.

Format de données ShareGPT

json
{
  "conversations": [
    {"from": "system", "value": "You are an expert in EU AI regulation."},
    {"from": "human", "value": "Explain the risk categories in the EU AI Act."},
    {"from": "gpt", "value": "The EU AI Act categorizes AI systems into four risk levels..."}
  ]
}

Génération de données synthétiques à grande échelle

python
from openai import OpenAI  # or use Mistral/Llama locally

client = OpenAI()

def generate_training_example(topic: str, difficulty: str) -> dict:
    prompt = (
        f"Generate a challenging {difficulty}-level question about {topic} "
        "and a comprehensive expert answer."
    )
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.8,
    )
    content = response.choices[0].message.content
    # Parse and structure output (question/answer split)...
    return {"instruction": topic, "response": content}

Répartition recommandée de la diversité des instructions

Questions-réponses
30%
Rédaction et résumé
20%
Génération de code et débogage
20%
Analyse et raisonnement
15%
Autres (traduction, extraction, etc.)
15%
Contamination des données
La contamination du jeu de test est le problème d'évaluation n°1 du fine-tuning. Si l'un de vos benchmarks d'évaluation (MT-Bench, HumanEval, MMLU) apparaît dans vos données d'entraînement, vos scores seront gonflés et dénués de sens. Effectuez toujours des vérifications de chevauchement par n-grammes entre votre jeu d'entraînement et vos benchmarks d'évaluation avant l'entraînement.

Évaluation et itération

La boucle de fine-tuning est : entraîner → évaluer sur un jeu de validation → diagnostiquer les modes d'échec → améliorer les données → réentraîner. Une bonne évaluation est ce qui transforme les tâtonnements en amélioration systématique.

MT-Bench

Qualité générale

Benchmark multi-tours de 80 questions réparties sur 8 catégories (rédaction, mathématiques, code, etc.). GPT-4 note chaque réponse de 1 à 10.

AlpacaEval

Suivi d'instructions

Taux de victoire de votre modèle face à un modèle de référence (GPT-4o) tel que jugé par GPT-4o. Évaluation automatisée rapide de la qualité du suivi d'instructions.

IFEval

Conformité de format

Précision du suivi d'instructions sur des contraintes vérifiables (p. ex. « répondre en moins de 100 mots »). Variantes de notation stricte et souple.

HumanEval / MBPP

Génération de code

Benchmarks de génération de code. Métrique Pass@k : fraction de problèmes résolus en k tentatives. Cas de test exécutables comme vérité terrain.

Le motif LLM-as-Judge

python
import json
from openai import OpenAI

client = OpenAI()

def evaluate_response(question: str, answer: str, judge_model: str = "gpt-4o") -> dict:
    prompt = f"""Rate the following AI assistant response on a scale of 1-10.

Question: {question}
Answer: {answer}

Evaluate: helpfulness (1-10), factuality (1-10), safety (1-10).
Return JSON: {{"helpfulness": N, "factuality": N, "safety": N, "rationale": "..."}}"""

    response = client.chat.completions.create(
        model=judge_model,
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"},
    )
    return json.loads(response.choices[0].message.content)
Pièges courants de l'évaluation
  • Biais de longueur : les juges LLM ont tendance à préférer les réponses plus longues, quelle que soit la qualité. Calibrez votre juge.
  • Flagornerie : les modèles notent plus haut leurs propres sorties. Utilisez un modèle différent comme juge, ou une validation humaine.
  • Contamination : des données de benchmark dans le jeu d'entraînement gonflent les scores. Vérifiez toujours le chevauchement.
  • Pièges du critère unique : optimiser un critère en dégrade souvent d'autres. Suivez un tableau de bord équilibré.

Modèle de suivi d'expériences

RunModèle de baseMéthodeJeu de donnéesMT-BenchAlpacaEval Win%Notes
v1Llama-4-ScoutSFTUltraChat 200K7.470%Référence
v2Llama-4-ScoutSFT+DPO+ UltraFeedback8.076%+DPO a amélioré la sécurité
v3Llama-4-ScoutSFT+DPO (r=16)+ UltraFeedback8.177%LoRA r=16 vs FT complet

Quand faire du fine-tuning vs RAG vs ingénierie de prompts

Le fine-tuning est puissant mais n'est pas toujours le bon outil. La décision dépend de ce que vous essayez de changer : connaissance, comportement, format ou préférences. Un mauvais choix coûte des semaines d'ingénierie et de calcul.

ScénarioMeilleure approchePourquoi
Ancrer les réponses dans les documents de l'entrepriseRAGLa connaissance peut changer ; le FT ne se met pas à jour facilement
Vouloir un ton/style cohérentSFTLe ton est un format, pas une connaissance
Usage d'une terminologie spécifique à un domaineSFT + peu de donnéesModifier le comportement par défaut à moindre coût
Gérer des formats de sortie spécifiquesSFTLe respect d'un schéma est une compétence apprise
Réduire les sorties nuisiblesDPO / RLHFL'alignement sur les préférences cible directement cela
Avoir besoin de capacités de raisonnementGRPO ou distiller depuis R1Les schémas de raisonnement sont entraînables
Ajouter de nouvelles connaissances factuellesRAG (pas FT)Le FT mémorise, ne peut pas citer ses sources
Réduire les coûts d'API à grande échelleAffiner un petit modèleÉgaler la qualité d'un grand modèle sur une tâche étroite
Prototype / expérience rapideIngénierie de prompts d'abordCoût d'entraînement nul ; valider le concept d'abord

L'escalier LLM

Commencez tout en bas. Ne montez que lorsque le niveau actuel est véritablement insuffisant — chaque marche ajoute du coût, de la complexité et de la latence.

1
Ingénierie de prompts
Gratuit, instantané, coût d'entraînement nul
2
Exemples few-shot
Ajouter des exemples dans le contexte
3
RAG
Ancrer les réponses dans des documents récupérés
4
SFT
Enseigner le format, le style, la connaissance de domaine
5
DPO / RLHF
Aligner sur les préférences et la sécurité
6
Distillation
Compresser en un petit modèle spécialisé

Faire du fine-tuning quand

  • Ton/format cohérent à grande échelle
  • Le jargon de domaine doit être par défaut
  • Schéma de sortie spécifique requis
  • Réduire les coûts d'API sur une tâche étroite
  • Alignement sur les préférences/la sécurité nécessaire

Utiliser le RAG quand

  • La connaissance change fréquemment
  • Les réponses nécessitent des citations/sources
  • Base de connaissances privée/propriétaire
  • Grand corpus de documents (>1M tokens)
  • Besoin de mettre à jour sans réentraîner

Éviter le fine-tuning quand

  • Ajouter de nouvelles connaissances factuelles (utiliser le RAG)
  • Stade de prototype rapide ou de PoC
  • Jeu de données très petit (<100 exemples)
  • Aucun budget GPU disponible
  • Le prompting atteint déjà l'objectif
Prêt à faire du fine-tuning ?

Construisez votre modèle d'IA sur mesure

Que vous ayez besoin d'un assistant spécialisé dans un domaine, de modèles alignés sur les préférences ou de déploiements de production distillés — notre équipe en a construit et livré. Parlons de votre cas d'usage.

Plus de guides
Guide des compétences IA et du fine-tuning : SFT, LoRA, RLHF, DPO et distillation de modèles | Hyperion Consulting