Quand affiner, interroger, ou utiliser RAG — Un cadre de décision

Trois mois après avoir construit la couche d’extraction de signaux de trading d’AlgoVesta, nous avons dépensé 8 000 $ pour l’affinage de GPT-3.5 sur 15 000 documents financiers. La précision s’est améliorée de 3 %. Nous sommes ensuite passés à une approche d’ingénierie des prompts différente et à une architecture RAG — mêmes données, mêmes modèles, structure différente. La précision a bondi à 89 %. Le problème n’était pas la technique. C’était l’utilisation de la mauvaise technique pour le problème.

L’affinage (fine-tuning), l’ingénierie des prompts (prompt engineering), et la génération augmentée par récupération (RAG) ne sont pas des outils interchangeables en compétition pour le même emploi. Ils résolvent des problèmes différents, ont des coûts différents, et nécessitent une charge de maintenance différente. La plupart des équipes en choisissent un parce qu’il leur semble familier ou parce qu’elles ont lu un tutoriel, pas parce qu’il correspond à leurs contraintes réelles.

Ce cadre clarifie la situation. Il est construit sur des échecs de production répétés — les miens et ceux d’autres — et non sur des comparaisons théoriques.

Les différences fondamentales : Ce que fait réellement chaque technique

Commencez ici car les distinctions sont importantes.

L’ingénierie des prompts façonne le comportement du modèle sans modifier ses poids. Vous écrivez des instructions, structurez des exemples, et concevez le format d’entrée. Le modèle lui-même reste figé. Le coût est par token. La latence est déterministe. Les changements prennent quelques secondes.

L’affinage met à jour les poids du modèle en l’entraînant sur vos données spécifiques. Vous créez un ensemble de données, lancez un travail d’entraînement (heures à jours), et déployez une nouvelle version du modèle. Le coût inclut le temps d’entraînement initial, puis l’inférence par token. C’est permanent à moins de réentraîner.

RAG ne modifie pas du tout le modèle. Il récupère le contexte pertinent d’une base de données externe, l’injecte dans le prompt, et laisse le modèle de base répondre avec des informations fondées. Le coût dépend de la vitesse de récupération et de la taille du contexte injecté. Il évolue avec la taille de votre base de connaissances, pas avec vos données d’entraînement.

La distinction semble évidente une fois écrite. En pratique, les équipes les confondent constamment. Une erreur courante : quelqu’un entraîne un modèle affiné pour « améliorer la précision » alors que le vrai problème est que le prompt n’était pas assez spécifique. Autre erreur : construire un système RAG alors que l’affinage serait plus rapide et moins cher.

Quand l’ingénierie des prompts suffit (et quand elle cesse de fonctionner)

L’ingénierie des prompts est votre premier recours. Toujours.

Elle fonctionne lorsque le modèle de base comprend déjà le concept et a juste besoin de meilleures instructions. Elle ne coûte rien au départ. Vous obtenez un retour en quelques secondes. Vous pouvez itérer 20 fois en une heure. Pour la classification, la synthèse, et l’extraction structurée de textes que le modèle a vus pendant le pré-entraînement, l’ingénierie des prompts résout souvent 70 à 85 % du problème.

Voici un exemple réel avant/après d’extraction de facteurs de risque à partir de documents SEC en utilisant Claude Sonnet 4 :

## Mauvais prompt
Extrayez les principaux facteurs de risque de ce document.

## Sortie
- Les conditions générales du marché pourraient impacter notre activité
- Nous faisons face à la concurrence d'autres entreprises
- La réglementation peut changer
- Nous dépendons du personnel clé
(Vague, manque de spécificité, confond les niveaux de gravité)

## Prompt amélioré
À partir du dépôt 10-K ci-joint, extrayez tous les facteurs de risque qui apparaissent
dans la section "Item 1A. Risk Factors". Pour chaque risque :

1. Incluez l'en-tête exact du dépôt
2. Fournissez une phrase principale résumant le risque (quel événement négatif pourrait se produire)
3. Indiquez si la société quantifie la probabilité ou l'impact (si oui, incluez-le)
4. Marquez comme : MARCHÉ / OPÉRATIONNEL / RÉGLEMENTAIRE / STRATÉGIQUE / FINANCIER
5. Si le dépôt indique explicitement que ce risque a diminué par rapport à l'année précédente,
 notez-le

Omis les risques génériques qui apparaissent dans tous les 10-K (par exemple, "conditions économiques générales"). Concentrez-vous sur les risques spécifiques à l'activité de cette entreprise.

## Sortie
- Brèches de cybersécurité et pertes de données (OPÉRATIONNEL) :
 Pourraient compromettre les données des clients et déclencher des actions réglementaires.
 La société a estimé l'exposition à "jusqu'à 500 millions de dollars" en cas de "violation matérielle".
- Perte de partenariats clés (STRATÉGIQUE) :
 Spécifique à cette entreprise. Deux des cinq principaux canaux de revenus dépendent
 du renouvellement annuel des contrats.
(Spécifique, hiérarchique, triable)

Le second prompt fonctionne car il :

• Spécifie la structure de sortie (le modèle suit mieux les instructions structurées que les requêtes vagues)
• Ajoute des exemples négatifs (ce qu’il ne faut PAS inclure aide autant que ce qu’il faut inclure)
• Crée un système de classification (MARCHÉ/OPÉRATIONNEL/etc. — cela donne au modèle un arbre de décision)
• Quantifie la précision (« phrase principale résumant le risque » et non « résumer le risque »)

L’ingénierie des prompts cesse de fonctionner lorsque :

• Le concept est en dehors des données d’entraînement du modèle. Vous ne pouvez pas contourner cela avec des prompts. Si vous demandez à GPT-4o d’extraire du jargon spécifique à un domaine des rapports d’imagerie médicale et que le modèle n’a jamais vu ces données pendant le pré-entraînement, il devinera.
• Vous avez besoin d’un comportement cohérent sur plus de 10 000 requêtes similaires. La variance des prompts s’accumule. Certaines requêtes tomberont sur des cas limites et le prompt ne les gérera pas. Vous avez besoin d’un réentraînement systématique du comportement.
• Votre seuil de précision est d’environ 85 à 90 % mais vous avez besoin de 96 %+. L’ingénierie des prompts atteint un plateau. Les gains mineurs au-delà nécessitent soit un affinage, soit des changements architecturaux (comme RAG).
• La tâche nécessite des faits qui ne sont pas dans les données d’entraînement. Si vous extrayez les prix des produits de 2024 et que votre modèle a été entraîné jusqu’en avril 2023, le prompting n’aidera pas. RAG le fera.

RAG : Quand votre problème est un contexte manquant ou obsolète

RAG résout un problème spécifique et courant : le modèle sait raisonner mais manque des faits dont il a besoin.

Vous construisez un système RAG lorsque :

• Vos connaissances se mettent à jour plus rapidement que les cycles d’entraînement des modèles. Si vous réentraînez un modèle affiné chaque semaine pour ajouter de nouvelles données, RAG est moins cher. Vous mettez à jour une base de données vectorielle à la place. Le coût par requête est plus élevé (récupération + recherche d’embedding) mais vous évitez les frais de réentraînement.
• Votre précision échoue à cause d’hallucinations, pas de raisonnement. Le modèle sait comment extraire des informations et les structurer — il invente simplement des détails lorsqu’il ne sait pas quelque chose. RAG le fonde sur des données réelles.
• Vous avez besoin d’attributions. « De quel document provient ce fait ? » L’affinage ne peut pas répondre à cela. RAG le peut car il récupère explicitement la source.
• Votre tâche implique des faits que le modèle n’a jamais réellement vus. Un modèle affiné ne peut pas apprendre quelque chose qui n’était pas dans ses données d’entraînement. Un système RAG peut le récupérer d’une base de données.

Exemple réel d’AlgoVesta : nous traitons plus de 500 rapports de recherche par jour et extrayons des signaux d’achat/vente. Les rapports font référence à des métriques et des dates spécifiques. Les prix et le contexte temporel changent constamment. Nous avons construit RAG en :

1. Découpant chaque rapport en sections de 300 à 500 tokens (les limites sémantiques comptent — couper au milieu d’une phrase tue le contexte)
2. Créant des embeddings pour chaque section avec text-embedding-3-small d’OpenAI (bon marché, rapide, suffisant pour les données financières)
3. Stockant les embeddings + le texte original dans une base de données vectorielle (Pinecone, dans notre cas)
4. Au moment de la requête : créer l’embedding de la question de l’utilisateur, récupérer les 5 sections sémantiquement les plus similaires, les injecter dans le prompt, envoyer à Claude Sonnet 4

La métrique clé : sans RAG, le modèle inventait des chiffres spécifiques environ 15 % du temps. Avec RAG, 1,2 %. Nous n’avons pas affiné. Nous n’avons pas beaucoup amélioré le prompt. Nous avons juste donné au modèle le matériel source dont il avait besoin.

RAG échoue lorsque :

• Votre logique de récupération est défaillante. Si votre base de données vectorielle renvoie des sections non pertinentes, le modèle travaillera avec de mauvaises entrées. Vous avez simplement déplacé le problème en amont. Vous devez valider la qualité de la récupération — examinez réellement les 5 meilleurs résultats pour un échantillon de requêtes.
• Vous injectez trop de contexte. La fenêtre de contexte de Claude Sonnet 4 est de 200K tokens. Cela semble infini jusqu’à ce que vous injectiez 15 sections × 500 tokens chacune, plus un long prompt, plus la requête de l’utilisateur. L’encombrement du contexte provoque des pics de latence et de coût. Plus de contexte n’améliore pas toujours la précision — cela peut introduire du bruit.
• Votre modèle d’embedding ne correspond pas à votre domaine. Si vous utilisez un modèle d’embedding à usage général sur des données très spécialisées (contrats juridiques, dossiers médicaux, signaux de trading), la similarité sémantique s’effondre. Vous pourriez avoir besoin d’embeddings spécifiques au domaine ou de récupérateurs affinés.
• Votre base de connaissances est petite ou statique. Si vous avez 50 documents qui changent rarement et que vos données proviennent de la période d’entraînement du modèle, RAG ajoute de la complexité pour un gain minime. L’ingénierie des prompts est plus rapide.

Affinage : Quand vous avez besoin d’un changement de comportement systématique

L’affinage est votre dernier recours — non pas parce qu’il est faible, mais parce qu’il est coûteux et crée une charge de déploiement.

Vous affinez lorsque :

• Le modèle de base a du mal avec votre format ou votre domaine spécifique de manière constante. Si l’ingénierie des prompts vous amène à 75 % et que vous avez épuisé les variations de prompts, l’affinage peut vous faire passer à 88–92 % en réajustant les poids du modèle vers votre distribution de données.
• Vous avez besoin de garanties de latence que l’ingénierie des prompts ne peut pas fournir. Un modèle affiné est plus petit, plus rapide et plus prévisible que les modèles de base avec des prompts longs et complexes. Si vous traitez 10 000 requêtes/sec et que les SLA de latence sont serrés, cela compte.
• Le coût par requête est votre contrainte, pas le coût initial. L’affinage est coûteux au départ (50–500 $ selon la taille de l’ensemble de données et le modèle) mais l’inférence par token est moins chère que l’inférence du modèle de base. Si vous avez un volume élevé, les calculs s’inversent.
• Vous avez besoin d’un comportement cohérent sur les cas limites que votre prompt ne peut pas couvrir. Si vous avez construit un prompt de 2 000 tokens essayant de gérer 12 variations d’entrée différentes et qu’il échoue toujours 8 % du temps, un modèle affiné entraîné sur ces variations sera plus robuste.

Exemple : une équipe de support client utilisant GPT-4o pour classer les tickets. L’ingénierie des prompts leur a permis d’atteindre 82 % de précision sur 50 catégories de tickets. Ils ont étiqueté manuellement 2 000 tickets, ont affiné Mistral 7B (modèle plus petit, inférence plus rapide), et ont atteint 91 % de précision. Coût initial : 4 heures d’étiquetage + 60 $ de coût d’affinage. Économies mensuelles : 1 200 $ en appels API (moins de tokens GPT-4o nécessaires). Retour sur investissement : 3 semaines.

L’affinage échoue lorsque :

• Vous n’avez pas de données d’entraînement de haute qualité. Si votre ensemble de données étiquetées est petit (<500 exemples) ou bruyant, l'affinage surajustera ou apprendra des schémas fallacieux. L'ingénierie des prompts est plus robuste avec des données limitées.
• Votre problème est spécifique au domaine et votre modèle est trop général. Affiner GPT-4o sur 1 000 exemples de classification de structures moléculaires ne lui apprendra pas la chimie. Un modèle spécifique au domaine ou une approche d’embedding spécialisée serait préférable.
• Votre distribution de données change fréquemment. Les modèles affinés se dégradent lorsqu’ils rencontrent des données différentes de leur ensemble d’entraînement. Si vous affinez aujourd’hui et que vos modèles d’entrée changent le mois prochain, vous devez réentraîner. RAG gère mieux le changement de distribution car vous mettez à jour la base de connaissances, pas le modèle.
• Vous devez déployer plusieurs variantes. Si vous affinez un modèle pour l’anglais, un pour l’espagnol et un pour un domaine différent, vous gérez maintenant trois modèles distincts, trois déploiements distincts, trois pipelines de surveillance distincts. Cette surcharge opérationnelle est réelle.

La Matrice de Décision : Guide concret pour votre problème

Utilisez ce tableau pour raccourcir l’analyse. Trouvez votre contrainte à gauche, suivez la ligne, et elle pointera vers le bon outil.

Un Flux de Décision Réel : Trois Études de Cas

Cas 1 : Signalement de risques dans les contrats juridiques

Une startup doit analyser les contrats entrants et signaler les termes inhabituels. Ils ont 200 contrats étiquetés. Leur modèle de base (Claude Sonnet 4) détecte 70 % des risques mais manque le langage spécifique au domaine.

Décision : Commencer par l’ingénierie des prompts (2 heures, gratuit). Résultats : 78 %. Ajouter ensuite RAG en utilisant leurs contrats étiquetés comme base de connaissances (8 heures de configuration, 50 $ de coûts d’embedding). Résultats : 86 %. Le plafond de précision semble proche. L’affinage nécessiterait 1 000+ contrats étiquetés (semaines de travail). Décision : s’arrêter à RAG. Coût : ~2 $/mois en base de données vectorielle. Cela fonctionne pendant 3 à 6 mois jusqu’à ce qu’ils aient plus de données étiquetées.

Cas 2 : Classification des avis produits (50 000 avis/mois)

Une entreprise SaaS doit classer 50 000 avis mensuels dans 12 catégories de sentiment. Les coûts de l’API GPT-4o sont de 400 $/mois pour cette tâche. Ils étiquettent 3 000 exemples et affinent Mistral 7B. Coût : 120 $ d’affinage + 8 $/mois d’inférence (en utilisant Together AI pour une inférence bon marché). Résultats : 88 % de précision (contre 82 % avec l’ingénierie des prompts). Économies mensuelles : 370 $. Retour sur investissement de l’affinage : 4 semaines.

Décision : affinage. Mais voici le hic : ils redéploient un nouvel affinage chaque mois au fur et à mesure que de nouveaux avis arrivent. Après 6 mois, ils ont effectué 6 cycles d’affinage. Au mois 7, la dernière version fonctionne moins bien sur les anciens schémas (dérive). Ils auraient dû investir dans RAG ou une stratégie de prompting rafraîchie à la place. On apprend en vivant.

Cas 3 : Q&R sur la documentation de l’entreprise (plus de 1 000 pages)

Le département RH souhaite que les employés posent des questions sur les avantages sociaux, les politiques et les procédures. Ils ont un manuel de 1 500 pages qui est mis à jour trimestriellement. Le modèle de base (GPT-4o) invente des détails sur les politiques dans 12 % des cas.

Option A : Ingénierie des prompts. Injecter l’intégralité du manuel dans le prompt. Résultats : surcharge de plus de 100 Ko de tokens par requête. Latence : 4–5 secondes. Coût : 0,80 $ par requête. Hallucinations : 5 %. Intenable à grande échelle.

Option B : RAG. Découper le manuel (1 500 pages = ~1 000 morceaux). Créer des embeddings une fois. Au moment de la requête : récupérer les 5 morceaux pertinents, les injecter (~2 Ko de tokens), envoyer au modèle. Latence : 800 ms. Coût : 0,12 $ par requête. Hallucinations : 0,8 %. Décision : évidente. Construire RAG. Implémentation : Pinecone + Claude Sonnet 4 = deux semaines du début à la fin.

Approches Hybrides : Quand une seule technique ne suffit pas

Le monde réel choisit rarement une seule approche. Les équipes qui réussissent les combinent stratégiquement.

Ingénierie des prompts + RAG (courant, efficace)

Vous utilisez RAG pour fonder les faits, puis l’ingénierie des prompts pour guider le raisonnement. Exemple : Extraire les facteurs de risque d’un 10-K (RAG récupère les sections pertinentes) puis classer leur gravité en utilisant un modèle de prompt structuré (ingénierie des prompts). Coût : surcharge de récupération + inférence. Latence : acceptable. Précision : élevée.

Affinage + RAG (avancé, coûteux)

Vous affinez un modèle pour comprendre votre domaine, puis utilisez RAG pour lui donner des faits actuels. Exemple : affiner un modèle médical pour classer les symptômes des patients, mais utiliser RAG pour le fonder sur des données d’interaction médicamenteuse actuelles qui n’étaient pas dans l’entraînement. Coût : élevé (deux systèmes à maintenir). Avantage : compréhension du domaine + précision factuelle. Cas d’utilisation : domaines à haut risque où les deux comptent.

Ingénierie des prompts + ingénierie des prompts (en cascade) (sous-estimé)

Vous utilisez un modèle bon marché pour un filtrage initial, puis un modèle puissant pour une sortie raffinée. Exemple : GPT-3.5 classe si un e-mail est lié au support (bon marché, rapide), puis Claude Sonnet 4 rédige une réponse seulement si c’est le cas (économise de l’argent). Coût : deux appels API mais 70 % moins cher au total. Latence : acceptable si le premier modèle est rapide. Fonctionne bien pour les tâches de routage et de filtrage.

Évaluer votre approche : ce qu’il faut mesurer

Vous ne pouvez pas choisir la bonne technique sans métriques de référence. Avant de construire quoi que ce soit, mesurez :

• La précision sur un ensemble de test distinct (50–100 exemples sur lesquels vous ne vous entraînez pas). La précision dépend du contexte — 80 % peut être excellent pour certaines tâches, terrible pour d’autres. Connaissez votre cible.
• Le coût par requête (tokens × prix du modèle). Incluez les coûts de récupération si vous utilisez RAG. Incluez l’affinage amorti sur le volume de requêtes attendu si vous affinez.
• Les percentiles de latence, pas les moyennes (p50, p95, p99). La latence moyenne masque les lenteurs extrêmes. Si 1 % des requêtes prennent 30 secondes, cela casse l’expérience utilisateur même si la moyenne est de 2 secondes.
• Les modes d’échec (pas seulement la précision globale). Classez vos erreurs : hallucinations, erreurs de raisonnement, erreurs de format, entrée ambiguë. Les différentes techniques échouent différemment. Les hallucinations orientent vers RAG. Les erreurs de format orientent vers une meilleure ingénierie des prompts ou un affinage.
• La variance selon les types d’entrée (pas un chiffre de précision monolithique). Si votre modèle fonctionne très bien sur des entrées courtes mais échoue sur des entrées longues, vous avez un problème structurel, pas un problème de technique.

Exemple d’AlgoVesta : nous avons mesuré la précision de l’extraction des signaux de trading non pas comme un seul chiffre mais comme :

• Précision sur les rapports récents (2024) : 91 %
• Précision sur les rapports archivés (2020–2022) : 73 % (lacune de connaissances)
• Précision lorsque les données de prix sont référencées : 88 %
• Précision sur les tickers de cas limites : 62 % (actions rares, pics d’hallucinations)

Cette ventilation a révélé que RAG résolvait le problème des années 2020–2022 et le problème de référence des prix (ils sont dans la base de connaissances), mais ne résolvait pas le problème des tickers de cas limites (le modèle nécessite un affinage ou une meilleure désambiguïsation des tickers dans le prompt). Un seul chiffre ne nous aurait pas dit cela.

Quoi faire dès lundi

Si vous êtes confronté à cette décision maintenant :

Étape 1 : Choisissez un petit échantillon (10–50 exemples) de votre cas d’utilisation et mesurez la précision de base avec l’option la moins chère en premier : GPT-3.5 Turbo avec un prompt simple. Cela prend 30 minutes et vous donne un point de départ. Peut être suffisant. Souvent, ce n’est pas le cas.

Étape 2 : Écrivez un prompt plus spécifique (référez-vous à la section précédente pour les règles de modèle de prompt). Mesurez à nouveau.** Généralement 5 à 15 % d’amélioration sans coût supplémentaire. Arrêtez-vous si cela atteint votre précision cible. N’en faites pas trop.