Quand fine-tuner — arbre de décision senior 2026

TL;DR Fine-tuning n'est presque jamais le premier réflexe en 2026. Ordre canonique : (1) prompt engineering correct, (2) few-shot dans le contexte, (3) RAG si data privée / changeante, (4) agentic workflow si tâche complexe, (5) fine-tune en dernier, et uniquement quand tu as un signal clair : style/format strict, narrow domain, réduction tokens, réduction latence, ou exigence souveraineté. Coût FT bas (50-500€ entraînement Mistral Small via API), mais coût caché énorme = pipeline data + eval + maintenance. Ne FT que si tu as ≥ 1000 exemples curated et un eval set qui prouve la régression d'un Sonnet vanilla.

---

🧠 Mental model

                ┌──────────────────────────────────┐
                │   Tu as une tâche LLM à livrer   │
                └────────────────┬─────────────────┘
                                 │
                ┌────────────────▼─────────────────┐
                │ 1. Prompt engineering sérieux ?  │
                │   - rôle, instructions, format   │
                │   - chain-of-thought / structure │
                └────────────────┬─────────────────┘
                                 │ Pas assez bon
                ┌────────────────▼─────────────────┐
                │ 2. Few-shot 3-10 exemples ?      │
                │   - dans le system prompt        │
                │   - exemples diversifiés         │
                └────────────────┬─────────────────┘
                                 │ Toujours pas
                ┌────────────────▼─────────────────┐
                │ 3. Data privée ou changeante ?   │
                │   → RAG (chunks + retrieval)     │
                │   → tool use / search            │
                └────────────────┬─────────────────┘
                                 │ Couvert mais lent ou cher
                ┌────────────────▼─────────────────┐
                │ 4. Tâche multi-step / decision ? │
                │   → Agentic (planner+tools)      │
                └────────────────┬─────────────────┘
                                 │ Toujours pas le compte
                ┌────────────────▼─────────────────┐
                │ 5. Fine-tuning justifié ?        │
                │   - style/format strict          │
                │   - jargon de niche              │
                │   - latency / cost / souverain   │
                └──────────────────────────────────┘

Analogie senior : prompt engineering = brief client, few-shot = exemples joints au brief, RAG = base documentaire que le freelance consulte, agentic = sous-traitants spécialisés, fine-tuning = former un nouveau collaborateur. Tu ne formes pas un junior pour rédiger UN mail. Tu le formes quand tu as 6 mois de travail récurrent à lui donner.

Règle de pouce : si tu hésites entre RAG et fine-tune, c'est RAG. Tu ne perds rien à reporter le FT de 3 mois, tu perds beaucoup à FT trop tôt sur un dataset mal curated.

---

🛠️ Code minimal — eval avant FT

Un eval de baseline n'est pas un script jetable : c'est l'artefact n°1 du projet FT, et un staff engineer l'écrit avec les mêmes exigences prod que le reste (async pour le débit, retries typés, prompt caching sur le préfixe stable, logging de l'usage pour le coût). Si tu mesures ton baseline à la main, séquentiellement, sur 8 exemples, tu te mens à toi-même.

# eval_before_ft.py
# Avant de fine-tuner, mesure ce que tu as déjà.
# Si ton baseline n'est pas mesuré, ton FT ne sert à rien.
import asyncio
import logging
from statistics import mean

from anthropic import (
    AsyncAnthropic,
    APITimeoutError,
    RateLimitError,
    OverloadedError,
)

logger = logging.getLogger("ft_eval")

# AsyncAnthropic + max_retries : le SDK gère le backoff exponentiel sur 429/5xx.
# timeout par appel pour ne pas bloquer tout le batch sur un appel pendu.
client = AsyncAnthropic(max_retries=4, timeout=60.0)

# Dataset eval — 50-200 exemples curated (input → expected_output).
# C'EST l'artefact qui décide go/no-go FT. Versionne-le, ne le bidouille pas.
EVAL_SET = [
    {"input": "...", "expected": "..."},
    # ...
]

# Le style guide / few-shot / instructions sont STABLES sur tout le batch :
# on les met en tête de system et on cache le préfixe (lecture ~0.1x du prix input).
def build_system(prompt_prefix: str) -> list[dict]:
    return [{
        "type": "text",
        "text": prompt_prefix,
        "cache_control": {"type": "ephemeral"},  # cache le préfixe stable
    }]

def _text(resp) -> str:
    return "".join(b.text for b in resp.content if b.type == "text")

async def _score_one(model: str, system: list[dict], ex: dict, sem: asyncio.Semaphore) -> float:
    async with sem:  # borne la concurrence pour rester sous les rate limits
        try:
            resp = await client.messages.create(
                model=model,
                max_tokens=1024,
                system=system,
                messages=[{"role": "user", "content": ex["input"]}],
            )
        except (RateLimitError, OverloadedError, APITimeoutError) as e:
            logger.warning("appel échoué (%s) — exemple ignoré", type(e).__name__)
            return float("nan")
        # logging usage = visibilité coût ; cache_read_input_tokens > 0 prouve le cache hit
        u = resp.usage
        logger.info("in=%d out=%d cache_read=%d", u.input_tokens, u.output_tokens,
                    getattr(u, "cache_read_input_tokens", 0))
        return judge(_text(resp), ex["expected"])  # 0..1, ton LLM-as-judge calibré

async def baseline_score(model: str, prompt_prefix: str, concurrency: int = 8) -> float:
    sem = asyncio.Semaphore(concurrency)
    system = build_system(prompt_prefix)
    scores = await asyncio.gather(*(_score_one(model, system, ex, sem) for ex in EVAL_SET))
    valid = [s for s in scores if s == s]  # filtre les NaN (appels échoués)
    return mean(valid) if valid else float("nan")

async def main() -> None:
    # Compare AVANT de FT — même base model, on fait varier le contexte
    print("Sonnet vanilla:",    await baseline_score("claude-sonnet-4-6", PROMPT))
    print("Sonnet + few-shot:", await baseline_score("claude-sonnet-4-6", PROMPT_FEWSHOT))
    print("Sonnet + RAG:",      await baseline_score("claude-sonnet-4-6", PROMPT_RAG))
    # Et le plafond haut de gamme, à effort élevé, avant de conclure :
    print("Opus 4.8 + RAG:",    await baseline_score("claude-opus-4-8", PROMPT_RAG))
    # Seulement si écart vs le meilleur base model > seuil métier
    # ET non comblable par contexte => envisage FT.

asyncio.run(main())

Pourquoi ces choix sont « senior » et pas cosmétiques : (1) asyncio.gather + sémaphore = ton eval de 200 exemples tourne en ~30s au lieu de 10min, ce qui change la fréquence à laquelle tu itères ; (2) le prompt caching sur le style guide stable divise le coût d'un eval répété (tu vas le relancer 50 fois) ; (3) les exceptions typées (RateLimitError, OverloadedError) te disent pourquoi un appel a échoué au lieu de planter le batch ; (4) resp.usage loggé = tu peux chiffrer exactement le coût/run et le mettre dans ton ADR.

---

🎬 Cas d'usage concrets

1. Cabinet d'avocats Paris — rédaction de conclusions

Cabinet de 50 collaborateurs (droit social, prudhommes). Avant : Claude Sonnet + prompt 4K tokens (style guide cabinet + 3 exemples) = 95% acceptable, 2000-3000 tokens output. Frustration : style "trop ChatGPT", relecture systématique de l'associé.

Décision : fine-tuner Mistral Small sur 1200 conclusions historiques anonymisées. Résultat : style maison reconnu par les avocats, prompt réduit à 800 tokens, latence -40%. Mais 4 mois de pipeline data (anonymisation + curation + RGPD). ROI : break-even à 6 mois, ROI 18 mois ≈ 220k€ de temps gagné.

2. ETI agroalimentaire — screening CV

DRH veut classifier 15 000 CV/an entre 12 catégories de postes (logistique, qualité, R&D, commercial...). Sonnet 4.6 vanilla = 91% accuracy, 400 tokens/CV à 3$/1M input = 18€/an. Le problème ? Latence 2s/CV × 15K = 8h batch.

Décision : pas de FT. La latence n'est pas critique (batch nocturne), et 9% d'erreur ne justifie pas l'effort. On reste sur Sonnet + prompt caching. Économie de 3 semaines de travail FT pour un ROI marginal.

3. E-commerce mode FR — classifier intent helpdesk

50 000 tickets/mois, 18 intents (retour, livraison, taille, paiement...). Sonnet 4.6 = 94%, mais 0.003€/ticket × 50K = 150€/mois juste pour le routing. Latence aussi (réponse temps réel).

Décision : fine-tune Haiku 4.5 (ou distill vers Mistral 7B). Inference 10x moins chère, latence < 300ms, accuracy 95%. ROI : économie 1500€/an, mais surtout UX du chat amélioré → conversion +0.4%, soit ~80k€ de revenu additionnel. Là le FT est justifié.

Note pricing Anthropic 2026 (référence pour tes calculs ROI) : Haiku 4.5 = 1$/5$ par M tok (in/out), Sonnet 4.6 = 3$/15$, Opus 4.8 = 5$/25$ (à 1M de contexte). Le ratio coût Opus/Haiku ≈ 5x en input, 5x en output : sur un classifieur à fort volume, descendre de Opus à Haiku avant même de FT divise déjà la facture par 5. C'est souvent le premier levier, pas le FT.

---

🛠️ Exemple end-to-end — décision FT vs RAG pour cabinet d'avocats

Contexte client : cabinet d'avocats parisien spécialisé en droit du travail, 50 collaborateurs (12 associés, 28 collaborateurs, 10 paralégaux). Objectif : assistant IA pour rédaction de conclusions, notes de synthèse, et courriers clients.

Étape 1 — Baseline et mesure

Dataset d'éval : 60 exemples (20 conclusions, 20 notes, 20 courriers), notation par 2 associés sur 5 critères (justesse juridique, style maison, références jurisprudence, structure, ton).

Modèle                            | Score /5 | Coût/doc | Latence
----------------------------------|----------|----------|--------
Sonnet 4.6 vanilla                |   3.2    |  0.08€   |  4s
Sonnet 4.6 + prompt 4K (style)    |   3.8    |  0.11€   |  5s
Sonnet 4.6 + few-shot 8 ex        |   4.0    |  0.14€   |  6s
Sonnet 4.6 + RAG jurisprudence    |   4.2    |  0.16€   |  7s
Sonnet 4.6 + RAG + few-shot       |   4.3    |  0.18€   |  8s
Opus 4.8 vanilla                  |   4.0    |  0.40€   |  9s

Plafond observé avec Sonnet = 4.3/5. L'associé senior exige 4.6/5 minimum pour "publish-ready sans relecture".

Étape 2 — Analyse de l'écart

Les 0.3 manquants viennent de :

• Style maison (formules "Au regard de...", "Il convient de rappeler que...", structure visa/moyens spécifique au cabinet).
• Calibration ton : ni trop académique, ni trop commercial, équilibre propre au cabinet.
• Préférence sources : le cabinet cite préférentiellement certains arrêts (Cass. soc.) et évite d'autres.

C'est exactement le profil "narrow domain language + style strict" où FT brille.

Étape 3 — Calcul ROI FT vs alternatives

Volume : 50 collaborateurs × 3 docs IA/jour × 220 jours = 33 000 docs/an.

Option A — Status quo (Sonnet + RAG + few-shot)
  Score : 4.3/5 (insuffisant)
  Coût API : 33K × 0.18€ = 5 940€/an
  Coût relecture associé : 15 min/doc × 33K × 250€/h = 2 062 500€/an équivalent
  → INACCEPTABLE

Option B — Opus 4.8 + RAG
  Score : 4.4/5 (encore insuffisant)
  Coût API : 33K × 0.45€ = 14 850€/an
  Coût relecture : encore élevé
  → KO

Option C — Fine-tune Mistral Small sur 1200 conclusions anonymisées
  Investissement initial :
    - Curation/anonymisation : 25j × 600€ = 15 000€
    - Training + eval (3 itérations) : 8j × 1200€ = 9 600€
    - Setup vLLM Scaleway H100 : 5j × 1200€ = 6 000€
    - Total CAPEX : 30 600€
  Coûts récurrents :
    - GPU Scaleway H100 (1x) : 24K€/an
    - Maintenance/re-training : 8j × 1200€ = 9 600€/an
  Score attendu : 4.65/5 (validé sur eval pilote 200 docs)
  Coût/doc : 0.04€ (4x moins cher)
  Latence : 1.8s (3x plus rapide)
  Gain relecture : 12 min/doc → 3 min/doc = 9 min × 33K × 250€/h = 1 237 500€
  → ROI = 1 237 500 - 30 600 - 33 600 = 1 173 300€/an
  → Payback : 1.5 mois

Étape 4 — ADR signed-off

# ADR-007 — Fine-tuning Mistral Small pour assistant rédaction

Date : 2026-04-15
Statut : Accepted
Décideurs : Associé Managing, RSSI, AI Lead (freelance)

## Contexte
Plafond de qualité atteint avec Sonnet + RAG (4.3/5).
Exigence métier : 4.6/5 minimum pour autonomie du collaborateur.

## Décision
Fine-tune Mistral Small (24B) en LoRA r=64 sur 1200 conclusions
anonymisées du cabinet (2019-2025), déployé en vLLM sur Scaleway H100
HDS-friendly (option DPA Scaleway).

## Conséquences
+ Qualité 4.65/5 attendue (validé pilote)
+ Coût/doc /4, latence /3
+ Données restent en France (souveraineté, RGPD strict)
- CAPEX 30k€, OPEX 33k€/an
- Dépendance à 1 GPU H100 (mitigation : 2e GPU en hot standby)
- Re-training annuel à prévoir (drift jurisprudentiel)

## Rejetée
- RAG-only : plafond qualité insuffisant
- Opus 4.8 + RAG : coût × 7 sans atteindre 4.6
- FT GPT-4o-mini : data hors UE (RGPD KO pour cabinet)
- Llama 3.3 self-host : licence ambigüe sur usage commercial entreprise

Étape 5 — Garde-fous

1. Eval continu : 100 docs/mois jugés par associé rotatif, alerte si score < 4.4.
2. Fallback : si vLLM down, route automatique vers Sonnet (qualité dégradée acceptée).
3. Re-training trigger : drift > 0.2 sur score eval ou nouvelle convention collective majeure.
4. Audit RGPD : dataset training stocké chiffré, droit à l'oubli implémenté (re-train si demande).

---

🎯 Patterns courants

• Few-shot d'abord, FT après : si 8 exemples bien choisis ne suffisent pas, mesure l'écart précisément avant de FT.
• Eval set avant tout : sans 50+ exemples notés, tu navigues à vue. Le eval set est l'artefact n°1.
• Mesurer le plafond du base model : tester Sonnet 4.6, Opus 4.8, et Mistral Large avant de conclure que FT est nécessaire. Et surtout tester avec effort élevé (output_config.effort: "high" / "xhigh" sur Opus 4.8) — un FT qui « bat » un Opus à bas effort ne prouve rien, tu compares ton modèle entraîné à une version bridée du base model.
• FT = compression : tu compresses un prompt long (style guide, exemples) dans les poids. Tu ne fais pas apprendre du nouveau savoir factuel (ça c'est RAG).
• Iterate dataset, not hyperparams : 90% des gains FT viennent de la qualité des données, pas du tuning de rank LoRA.
• Hold-out blind eval : 20% des données jamais vues par le training, jugées par humain qui ne connaît pas l'origine (FT vs base).

---

🔄 Versions & écosystème 2026

• Anthropic : Claude Haiku 4.5 fine-tuning via AWS Bedrock disponible (GA Q4 2025). Sonnet FT en preview entreprise.
• OpenAI : GPT-4o-mini FT mature, GPT-4.1-nano FT optimisé pour latence. Distillation API native (depuis Dev Day 2024).
• Mistral : mistralai/Mistral-Small-Instruct-2502 et Mistral Large 2 FT via plateforme Mistral (FR, RGPD-friendly). Mistral propose aussi FT on-prem en partenariat avec Scaleway et OVH.
• Llama 4 (Meta, mars 2026) : Maverick 17B et Scout 109B MoE, FT recipes officiels via torchtune.
• Qwen 3 : excellent ratio perf/taille, FT-friendly, licence Apache.
• Outils : Unsloth (FT 2x faster en mémoire), Axolotl (production-grade), torchtune (Meta officiel), Hugging Face PEFT (lib de base).
• OpenPipe / Together AI : plateformes managed FT spécialisées open-source.

---

⚠️ Pitfalls

1. FT sans eval set : tu vas overfitter et tu ne le sauras pas. Toujours hold-out 20%.
2. Croire que FT = apprendre des faits : non, FT apprend du style/format/distribution. Les faits → RAG.
3. Trop peu de données (< 500 exemples) : préfère le few-shot, le FT va overfitter.
4. Données non curated : 200 exemples nickel valent mieux que 5000 sales. La curation est 70% du job.
5. FT sur output ChatGPT : verbosité ChatGPTienne contagieuse, et risque légal (ToS OpenAI interdit FT compétiteur — sauf via distillation API).
6. Pas de baseline : si tu n'as pas mesuré Sonnet vanilla, ton "FT améliore de 12%" ne veut rien dire.
7. Re-FT à chaque changement métier : tu vas créer une dette infrastructure énorme. Préfère RAG pour la partie volatile.
8. Oublier le coût d'inference : un FT Mistral Small self-host coûte plus cher en GPU qu'en API si volume < 100K req/mois.
9. RGPD oubliée : si data contient PII, le FT model les "mémorise" potentiellement. Anonymisation OBLIGATOIRE.
10. Pas de plan de rollback : si le FT régresse en prod, il faut pouvoir router vers le base model en 1 commande.

---

💰 Pricing / ROI client

Coût d'un projet FT typique (cabinet d'avocats 50 personnes, exemple ci-dessus) :

Poste	Coût
Audit + design (5j)	6 000€
Curation données + RGPD (25j)	15 000€
Training + eval itératif (8j)	9 600€
Déploiement vLLM (5j)	6 000€
Documentation + handover (3j)	3 600€
Total mission FT	40 200€

Mission équivalente RAG-only : 18-25k€ (pas de pipeline data lourd).

Posture senior : facture la décision elle-même. Un audit "FT vs RAG" sur 5 jours à 1200€/j = 6000€ qui économise potentiellement 40k€ de FT inutile. C'est ta mission la plus rentable.

Modèle de facturation FT :

• Forfait audit + ADR : 6-10k€
• Forfait pipeline data + training : 25-40k€
• Run rate maintenance : 1500€/mois ou 12k€/an

---

🧪 Testing / Eval

Pyramide d'eval FT :

        ┌──────────────────┐
        │  Eval humain     │  20-50 exemples, jugés par expert métier
        │  (gold standard) │  pondération forte
        └────────┬─────────┘
                 │
        ┌────────▼─────────┐
        │  LLM-as-judge    │  200-500 exemples
        │  (Claude Opus)   │  rubric strict, calibré sur humain
        └────────┬─────────┘
                 │
        ┌────────▼─────────┐
        │  Metrics auto    │  1000+ exemples
        │  BLEU/ROUGE/exact│  monitoring continu prod
        └──────────────────┘

Checklist eval FT :

• [ ] Train/val/test split (70/15/15), test NEVER touché pendant itérations
• [ ] Blind eval (juge ne sait pas quel modèle a produit la réponse)
• [ ] Rubric écrite avant de mesurer (sinon biais confirmation)
• [ ] Au moins 2 modèles base comparés (Sonnet, Mistral Large)
• [ ] Métriques au-delà de l'accuracy : style, format, refus, hallucination
• [ ] Régression test : 30 exemples "trap" qui doivent toujours marcher
• [ ] Adversarial : 10 prompts qui essaient de casser le format

---

🔁 Quand utiliser / éviter

Utilise FT quand :

• Tu as mesuré un plafond clair des modèles base + RAG.
• Tu as ≥ 1000 exemples curated et un eval set solide.
• Le style/format strict est central (rédactionnel, classification niche).
• Tu cherches à réduire coût/latence sur volume élevé (> 100K req/mois).
• Souveraineté/RGPD impose modèle on-prem.
• Tu as 3 mois et 30k€+ de budget.

Évite FT quand :

• Tu n'as pas testé prompt + few-shot + RAG sérieusement.
• Tu as < 500 exemples ou data sale.
• La tâche évolue chaque mois (FT figé, RAG plus adapté).
• Tu cherches à enseigner des faits (use RAG, not FT).
• Tu n'as pas d'eval humain prévu.
• Le volume est faible (< 10K req/mois) : économie d'inference marginale.

---

🎤 En entretien

Questions que ce sujet attire au niveau senior/staff, avec la réponse en une ligne.

« Un client veut fine-tuner pour que le modèle connaisse sa doc produit interne. Tu en penses quoi ? »

C'est un anti-pattern classique : le FT apprend du style/distribution, pas des faits — la doc produit change et tu re-FT à chaque release ; la bonne réponse est RAG (retrieval sur la doc), éventuellement FT par-dessus seulement si le style de réponse est aussi un enjeu.

« Ton FT améliore l'accuracy de 12% sur ton eval. Tu déploies ? »

Pas sans interroger le chiffre : sur quel split (le test est-il resté blind ?), vs quel base model à effort élevé, avec quel intervalle de confiance vu la taille du set, et est-ce que les 12% tiennent sur les cas adversariaux/trap — un gain moyen peut cacher une régression sur 5% de cas critiques.

« Quand le FT bat-il vraiment RAG + prompt engineering, en 2026 ? »

Quand la valeur est dans la forme à très haut volume : style rédactionnel strict compressé dans les poids (prompt 4K → 800 tokens), classification de niche à >100K req/mois où tu distilles vers un Haiku/7B pour diviser coût+latence, ou souveraineté/RGPD qui impose un modèle on-prem — sinon RAG gagne sur le time-to-value et la maintenance.

« Comment tu chiffres le ROI d'un projet FT face à un dirigeant ? »

Je facture la décision avant le FT : le coût caché n'est pas le training (50–500€) mais le pipeline data + eval + maintenance + GPU d'inférence ; le ROI réel se joue sur le temps humain économisé (relecture) × volume, comparé au CAPEX curation + OPEX GPU, avec un payback explicite — et souvent la conclusion est « ne FT pas ».

---

🏋️ Exercices

Exercices progressifs et exigeants. L'objectif n'est pas « change une constante » : c'est de te mettre dans la posture de quelqu'un qui doit défendre un chiffre et casser sa propre solution.

Exercice 1 — Construire l'eval set qui décide go/no-go

Objectif : produire un eval set de 60 exemples (train/val/test 70/15/15) avec une rubric écrite avant de mesurer, pour une tâche de classification d'intent helpdesk (18 intents). Indice/Solution : écris la rubric en premier (critères indépendants et gradables : intent exact, gestion du multi-intent, refus propre sur hors-scope). Sépare le test set physiquement et ne l'ouvre jamais pendant l'itération. Ajoute 10 cas « trap » (tickets ambigus, fautes, langue mixte FR/EN) qui doivent toujours marcher. Mesure d'abord Haiku 4.5 et Sonnet 4.6 vanilla + few-shot — tu n'as souvent pas besoin d'aller plus loin.

Exercice 2 — Adapter le code d'eval en async + cache + juge calibré

Objectif : partir du eval_before_ft.py ci-dessus et le rendre réellement prod : LLM-as-judge avec client.messages.parse() (schéma Pydantic, score + justification), prompt caching vérifié, coût/run loggé. Indice/Solution : définis un class Verdict(BaseModel): score: float; reasoning: str et passe-le à messages.parse(output_config={"format": ...}) au lieu de parser du texte à la main — sur Opus 4.8/Sonnet 4.6 les structured outputs natifs remplacent le XML/JSON prompté. Assert que usage.cache_read_input_tokens > 0 à partir du 2ᵉ appel (sinon un invalidant silencieux — datetime.now() dans le system, JSON non trié — casse ton cache). Calibre le juge sur 20 exemples notés humain avant de lui faire confiance sur 500.

Exercice 3 — Défendre (ou démolir) le ROI du cabinet d'avocats

Objectif : reprendre l'ADR-007 et refaire le calcul ROI en attaquant chaque hypothèse — le gain de relecture de 1.2M€/an est-il défendable ? Indice/Solution : le chiffre fragile est « 9 min × 33K docs × 250€/h ». Challenge : tous les docs passent-ils vraiment 12→3 min ? Le 4.65/5 attendu est validé sur 200 docs pilote, pas en prod. Refais le calcul avec une hypothèse pessimiste (gain 4 min, pas 9 ; score réel 4.5, pas 4.65 → relecture pas éliminée) et un OPEX GPU qui double (2ᵉ H100 hot standby). Si le payback passe de 1.5 mois à 14 mois, la décision change — un staff engineer présente les deux scénarios.

Exercice 4 — Casser un FT en production, puis le réparer

Objectif : tu déploies un FT Mistral Small qui passe ton eval à 4.65/5, mais en prod la qualité s'effondre après 3 semaines. Diagnostique et corrige. Indice/Solution : causes probables, dans l'ordre — (a) overfit sur ton eval (le test set a fuité dans le train via curation), (b) distribution shift (nouvelle convention collective → ton train de 2019-2025 ne couvre pas les nouveaux cas), (c) eval pas représentatif (tes 60 exemples sont trop propres vs la réalité). Mets en place : eval continu (100 docs/mois jugés humain, alerte si < 4.4), trigger de re-training sur drift > 0.2, et un fallback en 1 commande vers Sonnet 4.6 quand le score chute. Le vrai test senior : tu dois pouvoir router vers le base model sans redéploiement.

Exercice 5 — Prouver que tu n'aurais pas dû fine-tuner

Objectif : sur un cas réel où ton équipe a fine-tuné, démontre a posteriori qu'un Opus 4.8 à effort: "high" + prompt caching + RAG aurait atteint le même résultat à coût total (TCO 18 mois) inférieur. Indice/Solution : reconstruis le TCO complet des deux côtés. Côté FT : CAPEX curation + training + setup vLLM, OPEX GPU/an, maintenance/re-train, dette infra. Côté Opus+RAG : coût API (avec cache hit > 80% sur le système stable, donc ~0.1x sur le préfixe), zéro GPU, zéro pipeline data. Le FT ne gagne que si (volume × delta coût/req × 18 mois) > (CAPEX + OPEX_GPU + maintenance) — calcule le break-even volume exact, et vérifie si ton volume réel le dépasse. Souvent en dessous de ~100K req/mois, FT perd.

Exercice 6 (bonus, staff) — Designer le système de décision réutilisable

Objectif : transformer l'arbre de décision de ce fichier en un outil que ton équipe applique sans toi — un scoring qui sort « prompt / few-shot / RAG / agentic / FT » à partir de 8 inputs. Indice/Solution : modélise chaque branche comme un gate avec seuil : data privée/changeante (→ RAG), style strict + volume > seuil (→ FT), tâche multi-step (→ agentic), nb exemples curated < 500 (→ bloque FT). Pondère par le coût d'erreur et le time-to-value. Le piège à éviter : un score qui pousse vers FT parce que c'est « plus impressionnant » — ton système doit avoir un biais explicite contre le FT (règle de pouce du fichier : « si tu hésites entre RAG et FT, c'est RAG »).

---

🔗 Liens

• Anthropic prompt engineering guide — toujours lire avant d'envisager FT
• OpenAI fine-tuning best practices — applicable à tous les providers
• Mistral fine-tuning docs (FR-friendly)
• Eugene Yan — "Don't fine-tune, distill or RAG" (article référence)
• Hamel Husain — "Your AI product needs evals" (eval pyramid)
• Fichier voisin : 02-lora-peft.md (comment FT techniquement)
• Fichier voisin : 03-distillation.md (alternative FT)
• Fichier amont : 02-rag-production/ (alternative principale au FT)