Définition technique
Deux façons d’adapter un LLM à vos données. Le fine-tuning : réentraînement (ou entraînement additionnel) du modèle sur un jeu de données ciblé pour modifier son comportement ou ses connaissances. Coûteux, nécessite des données de qualité et de la puissance de calcul ; le modèle « sait » mieux dans son propre poids. Le RAG (Retrieval-Augmented Generation) : pas de modification du modèle ; on récupère des passages pertinents dans une base (souvent vectorielle) et on les injecte dans le contexte à chaque requête. Données à jour facilement, coût par requête (API + retrieval). En pratique : RAG pour des connaissances évolutives et privées ; fine-tuning pour un ton, un format ou un domaine très spécifique quand le volume et le budget le permettent.
Comment ça fonctionne ?
RAG : à chaque requête, recherche de passages pertinents (base vectorielle), construction du prompt avec contexte + question, appel LLM. Fine-tuning : entraînement (ou continuation d’entraînement) du modèle sur des paires question/réponse ou des textes ; le modèle déployé intègre ces connaissances.
L'erreur classique à éviter
Fine-tuner pour des connaissances qui changent souvent (coût et lourdeur). Utiliser uniquement le RAG sans délimiter le contexte (trop de bruit, coût). Croire que le fine-tuning dispense de tout prompt engineering.
Impact business : pourquoi s'en soucier ?
Le RAG est souvent le premier pas : vous connectez vos documents et votre FAQ au LLM sans toucher au modèle. Idéal pour du support, de la doc, des données qui changent. Le fine-tuning devient pertinent pour des cas où le RAG ne suffit pas (style de réponse, tâche très niche) ou pour réduire la dépendance aux appels API. Le choix impacte le coût, la maintenabilité et la vitesse d’itération.
La règle d'or
Commencer par du RAG pour les connaissances métier. Envisager le fine-tuning pour le ton, le format ou des cas où le RAG atteint ses limites. Mesurer coût, latence et qualité avant de scaler.