Une entreprise veut adapter un modèle à son métier. Trois solutions sont souvent proposées : améliorer le prompt, connecter une base documentaire par RAG ou entraîner le modèle sur des exemples. Elles ne résolvent pas le même problème.
Le prompt donne des instructions au moment de l’appel. Le RAG récupère des informations externes et les ajoute au contexte. Le fine-tuning ajuste les paramètres du modèle pour renforcer un comportement. Une architecture mature peut combiner les trois, mais seulement après avoir identifié la cause des erreurs.
Commencer par une baseline
Avant d’ajouter une technologie, construire une version minimale avec :
- un modèle de référence ;
- un prompt clair ;
- une sortie structurée si nécessaire ;
- vingt à cent cas de test représentatifs ;
- des métriques ;
- une analyse des erreurs.
Sans baseline, il est impossible de savoir si le RAG ou le fine-tuning apporte une amélioration. L’équipe risque de mesurer une impression sur quelques démonstrations favorables.
Le prompt engineering : cadrer la tâche
Un bon prompt précise :
- le rôle attendu ;
- la tâche ;
- les entrées ;
- les contraintes ;
- le format de sortie ;
- les critères de refus ;
- des exemples si utiles ;
- les outils disponibles.
Le prompt est adapté lorsque la connaissance nécessaire est déjà dans le modèle ou fournie dans l’entrée. Il convient pour transformer un texte, extraire des champs, classer, résumer ou appliquer une procédure courte.
Ses avantages sont la rapidité, le faible coût de mise en place et la facilité d’itération. Ses limites apparaissent lorsque les instructions deviennent très longues, contradictoires ou difficiles à maintenir. Un prompt ne met pas à jour les connaissances internes du modèle et ne garantit pas une information métier exacte.
Le RAG : apporter la connaissance au moment de la réponse
Le Retrieval-Augmented Generation recherche des passages pertinents dans des sources puis les transmet au modèle. Il convient lorsque les informations :
- changent régulièrement ;
- appartiennent à l’entreprise ;
- doivent être citées ;
- sont trop nombreuses pour un prompt fixe ;
- possèdent des droits d’accès ;
- doivent être retirées sans réentraîner.
Un RAG n’est pas une simple base vectorielle. Il faut gérer ingestion, découpage, métadonnées, recherche, reranking, droits, citations, évaluation et mise à jour.
Ses défauts proviennent souvent de la recherche, pas du modèle : mauvais document, chunk incomplet, filtre d’accès, vocabulaire différent ou information absente.
Le fine-tuning : apprendre un comportement
Le fine-tuning entraîne le modèle sur des paires d’exemples afin d’augmenter la probabilité d’un comportement. Il peut être pertinent pour :
- respecter un format précis ;
- adopter un style constant ;
- classer selon une taxonomie stable ;
- améliorer une langue ou un jargon ;
- réduire la longueur du prompt ;
- apprendre des décisions répétitives à partir d’exemples de qualité.
Il n’est généralement pas la meilleure solution pour mémoriser une documentation changeante. Les faits deviennent difficiles à mettre à jour et à citer. Un modèle fine-tuné peut également reproduire des erreurs, biais ou données sensibles du corpus.
L’effort principal réside dans la sélection, l’annotation, les droits, la séparation entraînement/test et l’évaluation, pas dans le lancement de la commande d’entraînement.
La question centrale : connaissance ou comportement ?
Lorsque le modèle ne connaît pas la procédure du jour, il manque de connaissance : le RAG est souvent prioritaire. Lorsqu’il connaît les éléments mais ne suit pas un format ou confond une taxonomie, le comportement est en cause : prompt ou fine-tuning peuvent aider.
Certains problèmes sont mixtes. Un assistant support doit retrouver la bonne procédure puis rédiger une réponse conforme au ton de l’entreprise. Le RAG fournit le fond ; le prompt ou le fine-tuning encadre la forme.
Outil local de cadrage
Atelier de cadrage
Structurez les décisions principales avant de lancer un atelier métier. Les réponses restent dans votre navigateur.
Arbre de décision entre prompt, RAG, fine-tuning et approche hybride selon la connaissance, le comportement, la fraîcheur et les preuves.
Comparer les approches
| Critère | Prompt | RAG | Fine-tuning |
|---|---|---|---|
| Mise en place | rapide | moyenne à importante | importante |
| Mise à jour des faits | à chaque appel | par réindexation | nouvel entraînement |
| Citations | limitées aux sources fournies | naturelles si conçues | non natives |
| Données requises | quelques exemples | documents exploitables | exemples supervisés de qualité |
| Contrôle d’accès | dans l’application | jusque dans la recherche | difficile au niveau des connaissances apprises |
| Coût d’exploitation | contexte parfois long | recherche + contexte | modèle personnalisé + inférence |
| Débogage | prompt et sortie | recherche puis génération | données, entraînement et inférence |
| Portabilité | relativement forte | dépend de la chaîne | dépend du fournisseur et du format |
Ce tableau donne des tendances. Le benchmark réel sur la tâche reste décisif.
Le long contexte ne remplace pas toujours le RAG
Les modèles acceptent des contextes de plus en plus longs. Il est tentant d’envoyer tous les documents. Cette approche peut fonctionner pour un dossier ponctuel, mais elle a des limites : coût, latence, bruit, contrôle d’accès, répétition des données et difficulté à garantir que le bon passage sera utilisé.
Le RAG réduit le contexte aux éléments pertinents et permet un index partagé. Pour de petits ensembles, une stratégie hybride peut d’abord filtrer par métadonnées puis envoyer plusieurs documents complets.
Le RAG ne corrige pas tous les comportements
Ajouter davantage de documents ne résout pas un modèle qui refuse mal, ne respecte pas le JSON ou adopte un ton incorrect. Il faut séparer les métriques :
- rappel et précision de la recherche ;
- fidélité aux sources ;
- exactitude de la réponse ;
- format ;
- style ;
- refus ;
- latence ;
- coût.
Cette décomposition montre quel levier modifier.
Le fine-tuning exige un corpus gouverné
Les exemples doivent être :
- représentatifs de la production ;
- corrects ;
- cohérents entre annotateurs ;
- autorisés ;
- exempts de données inutiles ;
- séparés du jeu de test ;
- versionnés.
Un corpus de réponses historiques peut contenir les mauvaises habitudes que l’on souhaite supprimer. Il doit être curé, pas simplement exporté.
Prévoir un modèle card interne : version de base, données, paramètres, limites, résultats, risques et procédure de retrait.
Une stratégie hybride fréquente
Une application robuste peut suivre cette chaîne :
- un prompt système court définit les règles ;
- un classifieur ou routeur choisit la tâche ;
- le RAG récupère les sources autorisées ;
- un modèle éventuellement fine-tuné produit le format attendu ;
- un validateur contrôle schéma et citations ;
- un humain approuve les cas sensibles.
Chaque brique doit justifier sa complexité. Ajouter un modèle fine-tuné avant d’avoir stabilisé les erreurs rend l’architecture plus difficile à maintenir.
Construire une expérience comparative
La décision peut être prise en quatre itérations.
Itération 1 : prompt de référence
Mesurer la qualité sans retrieval ni entraînement. Identifier les erreurs de connaissance, format, raisonnement et sécurité.
Itération 2 : RAG minimal
Indexer un corpus limité, définir des questions de référence et mesurer retrieval puis réponse. Ne pas commencer par toute la documentation.
Itération 3 : fine-tuning ciblé
Uniquement si un comportement répétitif résiste aux prompts et si les exemples sont disponibles. Comparer à la baseline sur un jeu jamais vu.
Itération 4 : combinaison et exploitation
Mesurer latence, coût, dérive, réversibilité et capacité de mise à jour. La meilleure note hors production n’est pas toujours la meilleure solution opérable.
Quand ne pas utiliser le fine-tuning
Éviter de fine-tuner lorsque :
- les faits changent chaque semaine ;
- il faut citer la source ;
- le corpus est petit ou contradictoire ;
- les droits sont incertains ;
- l’erreur vient de la recherche ;
- le besoin peut être résolu par un schéma de sortie ;
- aucune évaluation fiable n’existe.
Quand ne pas construire de RAG
Un RAG est excessif pour une tâche de transformation sans connaissance externe, quelques règles stables ou un document unique fourni à chaque appel. Il ajoute ingestion, index, sécurité et monitoring.
Piloter par le coût par tâche réussie
Comparer le coût complet : préparation des données, infrastructure, appels, annotations, réindexation, entraînement, tests, incidents et maintenance. Une solution moins chère par token peut coûter plus si elle échoue davantage ou nécessite une revue humaine lourde.
La métrique utile est le coût par tâche acceptée, avec le niveau de qualité attendu.
Choisir une méthode réversible
Conserver prompts, corpus, évaluations et schémas indépendamment du fournisseur. Versionner les configurations et prévoir une couche d’adaptation. Un modèle ou une API peut évoluer, être retiré ou changer de prix.
Partitech peut construire la baseline, le pipeline RAG, le corpus de fine-tuning et l’évaluation comparative. La décision ne repose alors ni sur une mode ni sur une démonstration isolée, mais sur des erreurs mesurées, des données maîtrisées et un coût d’exploitation réaliste.
Parlons de votre projet
Construire un benchmark comparant prompt, RAG et fine-tuning sur vos données avec Partitech. Contactez Partitech.