RAG ou fine-tuning : choisir pour l’adaptation au domaine

Deux voies dominent l’adaptation des modèles au contexte métier : RAG et fine-tuning. Elles ne résolvent pas les mêmes problèmes. D’un côté, la récupération met à jour les connaissances et garantit la traçabilité ; de l’autre, l’entraînement cible le comportement. Voici ce que chaque option permet, ce qu’elle ne fait pas et comment la déployer en pratique.

Des besoins métiers précis imposent traçabilité et procédures horodatées

Dans un environnement d’exploitation, chaque réponse doit pouvoir être reliée à un document source exploitable à toute heure. Une politique d’astreinte prévoit 15 minutes pour l’accusé de réception par l’intervenant primaire avant escalade au secondaire, puis 10 minutes avant d’alerter le chef d’équipe. Les incidents touchant le paiement ou le passage en caisse déclenchent directement l’alerte au chef d’équipe, indépendamment des accusés de réception. Les runbooks décrivent des gestes précis, comme vérifier le retard de réplication Postgres avec une requête SQL dédiée, promouvoir le standby si le retard est inférieur à 30 secondes, mettre à jour immédiatement la chaîne de connexion, et s’abstenir de basculer si le retard dépasse 5 minutes en escaladant vers l’équipe base de données. Les post-mortems documentent les causes et remédiations, tel un cas de mars 2026 où une réduction du pool de connexions de 100 à 20 a mené à une exhaustion, corrigée par un retour à la taille initiale, l’ajout d’une alerte et l’exigence d’un second relecteur côté plateforme avant fusion.

RAG répond aux connaissances qui évoluent, pas aux défauts de comportement

La génération augmentée par récupération ne modifie pas le modèle : elle injecte, à l’inférence, les passages les plus pertinents issus d’une base documentaire avec la requête de l’utilisateur. Cette approche vise les corpus volumineux et changeants, et permet de s’appuyer sur des références explicites. Elle ne corrige toutefois pas le ton, la discipline de formatage ni l’usage d’un vocabulaire secteur. Dans un contexte d’ingénierie où les runbooks et post-mortems s’enrichissent en continu, RAG convient car les connaissances évoluent chaque semaine et les réponses doivent rester traçables. Côté mise en place, l’exemple proposé requiert Python 3.10 ou plus, l’installation de scikit-learn et d’anthropic, ainsi qu’une clé API d’Anthropic.

L’entraînement sur des exemples façonne les réponses du modèle

L’entraînement sur des exemples entrée/sortie adapte le modèle pour que le comportement souhaité devienne par défaut, rendant superflue l’injection de schémas à l’inférence. Les techniques LoRA et QLoRA, majoritaires, entraînent un adaptateur souvent inférieur à 1 % des paramètres du modèle, ramenant l’effort à quelques centaines de dollars et quelques heures, au lieu d’un réentraînement complet. Le fine-tuning ajuste le style, la structure et la reconnaissance de motifs, mais ne fournit pas de manière fiable des connaissances factuelles ; le rappel de faits précis appris pendant l’entraînement reste incertain, notamment pour des éléments granulaires. Le fine-tuning doit donc être considéré comme un outil de comportement plutôt que de connaissance.

Implémenter une récupération simple : découpage par phrases et TF‑IDF

Un pipeline minimal de RAG peut découper les documents sur des frontières de phrases afin d’éviter de briser des étapes de procédure, en groupant par défaut deux phrases par fragment. Chaque fragment est représenté par une structure contenant l’identifiant du document, le titre et le texte. L’index construit des vecteurs TF‑IDF sur les fragments et calcule la similarité cosinus avec la requête. La recherche retourne, classés par pertinence décroissante, les trois meilleurs fragments par défaut.