RAG vs fine-tuning: comment choisir pour une PME

RAG vs fine-tuning: deux leviers, deux jobs

RAG apporte des faits au moment de la question. Fine-tuning modifie (ou adapte) le comportement du modèle via des exemples dans les poids ou un adaptateur. Tu ne choisis pas « la tech la plus hype ». Tu choisis le levier qui corrige ton échec mesuré.

Échec typique « le modèle ne connaît pas notre catalogue » → d'abord RAG (ou simple search). Échec « le modèle connaît les faits mais sort le mauvais format / ton » → fine-tuning ou prompts/skills robustes peuvent gagner.

Beaucoup d'équipes fine-tunent pour masquer un corpus mal rangé. Ça coûte cher et ça se périme au prochain prix ou procédure.

Grille de décision en 6 questions

1) Les faits changent-ils chaque semaine ? Oui → RAG (ou base à jour), pas un retrain mensuel. 2) As-tu les droits et la qualité des données d'exemples pour un fine-tune ? Non → RAG + prompts. 3) Le risque est-il juridique / client ? → retrieval + citations + HITL d'abord.

4) Le besoin est-il style, langue métier, format de ticket ? → skills/prompt, éventuellement fine-tune léger. 5) Budget ops: peux-tu servir un modèle custom ? Non → API + RAG. 6) As-tu un jeu d'eval ? Sans eval, aucun des deux n'est « validé ».

Score mental: si 3 réponses ou plus poussent vers documents et fraîcheur, commence par RAG. Si le corpus est déjà impeccable et l'échec est purement comportemental, regarde fine-tune.

Coûts cachés des deux options

RAG: ingest, storage vecteurs, re-index, eval retrieval, ACL, citations. Coût récurrent souvent sous-estimé côté data engineering.

Fine-tuning: collecte et labellisation, runs d'entraînement, eval de régression (le modèle « oublie » des cas), serving d'un modèle distinct, versioning des adapters, risque de fuite de données d'entraînement.

Compare sur 90 jours: euros + jours-homme + incidents. Un fine-tune « gratuit » offert par un vendor reste payant en eval et en maintenance.

Patterns qui marchent ensemble

RAG pour les faits + system prompt / skills pour le process. Fine-tune (ou adapter) seulement sur le format de sortie une fois le retrieval stable. Agents: tools déterministes pour le calcul, RAG pour la doc, HITL pour l'envoi.

Évite le double système non gouverné: un fine-tune opaque + un RAG non évalué. Un seul pipeline mesurable bat deux bricolages.

Local / open weights: fine-tune local possible mais lourd; RAG sur corpus interne reste souvent le premier levier (voir ia-locale et actu open weights).

Pièges classiques

Fine-tuner sur des FAQ non à jour. Mesurer le succès au « vibe demo ». Ignorer les ACL. Croire que le fine-tune supprime le besoin de citations. Changer de modèle et de corpus le même jour sans baseline.

Contre-mesure: baseline figée, une variable à la fois, journal d'expériences, owner data + owner modèle.

Décision en une page (template)

Contexte · échec mesuré · option A RAG · option B fine-tune · option C prompt/skills only · coût 90 jours · risque · eval · go / no-go · date de revue.

Si le go est RAG, enchaîne sur le guide RAG LLM. Si fine-tune, impose eval de non-régression et plan de retrain. Si les deux, séquence: RAG d'abord.

Si vous voulez arbitrer RAG vs fine-tuning sur un cas réel, on peut cadrer en 20-40 minutes.