Vous avez un problème que votre LLM standard ne résout pas. Claude ou GPT-4 gèrent bien les tâches basiques, mais pour votre cas d’utilisation spécifique — extraire des données de clauses contractuelles, noter des dissertations selon votre programme, ou classifier des tickets de support client avec 95 % de précision — le modèle standard dérive. Vous devez donc choisir entre trois voies : régler finement le modèle, concevoir de meilleurs prompts, ou construire un système RAG. Chacune fonctionne. Chacune échoue pour des raisons différentes. La différence entre choisir la bonne et la mauvaise solution est la différence entre livrer cette semaine et s’enliser trois mois dans une solution trop coûteuse et trop lente.
Sachez ce que vous essayez réellement de corriger
Avant de vous engager dans une approche, diagnostiquez le problème réel.
Exécutez 20 à 30 exemples sur votre modèle de base. Sauvegardez les échecs. Observez le schéma. Le modèle :
- Invente des faits qu’il ne connaît pas ? RAG résout cela. Le réglage fin ne le fera pas.
- Comprend mal la terminologie ou la logique spécifiques à votre domaine ? Le réglage fin ou un prompting très spécifique résout cela.
- Oublie les instructions à mi-chemin d’une longue réponse ? L’ingénierie de prompt (structure, optimisation des tokens) résout cela. Parfois, RAG aide.
- Fait des erreurs négligentes dans le formatage ou le raisonnement qu’il comprend clairement ? L’ingénierie de prompt résout presque toujours cela en premier.
J’ai vu des équipes dépenser 40 000 $ pour régler finement un modèle afin de gérer les hallucinations alors qu’une couche RAG aurait coûté 800 $ et aurait été livrée en deux semaines. Le diagnostic précède la prescription.
Ingénierie de prompt : Votre premier arrêt
Commencez ici. Toujours.
L’ingénierie de prompt est gratuite (en termes de calcul), réversible, et résout 60 % des problèmes pour lesquels les gens pensent qu’un réglage fin est nécessaire. Une approche disciplinée prend quatre heures, pas quatre semaines.
Voici un avant/après réaliste :
# Mauvais prompt
Extrais les termes clés du contrat de ce document :
{document_text}
Mode d’échec : Le modèle choisit des termes aléatoires, manque des dates critiques, confond les dates d’entrée en vigueur avec les dates de résiliation.
# Prompt amélioré
Vous êtes un analyste de contrats juridiques. Extrayez uniquement les termes suivants du contrat :
- Date d'entrée en vigueur (quand le contrat commence)
- Date de résiliation (quand il se termine)
- Conditions de renouvellement (automatique ou manuel)
- Montant du paiement (valeur totale du contrat)
- Calendrier de paiement (quand les paiements sont effectués)
Pour chaque terme :
1. Trouvez la référence exacte de la clause (par exemple, « Section 3.2 »)
2. Citez le texte pertinent
3. Fournissez la valeur extraite
4. Si un terme n'est pas présent, écrivez « NON TROUVÉ » — ne devinez pas
Document :
{document_text}
Analyse :
Mieux. Pas magique — vous avez simplement supprimé l’ambiguïté et ajouté des instructions explicites pour gérer les données manquantes. En pratique, cette approche réduit les erreurs d’extraction de 40 à 60 % sur les tâches structurées. Utilisez des prompts d’ancrage (fournir au modèle le contexte dont il a besoin) et la chaîne de pensée (faire en sorte que le modèle montre son travail) avant de penser au réglage fin.
Quand l’ingénierie de prompt seule échoue : Vous avez optimisé le prompt, l’avez testé sur plus de 100 exemples, et vous obtenez toujours 75 % de précision alors que vous avez besoin de 95 %. C’est votre signal pour passer à la couche suivante.
RAG : Pour les connaissances que votre modèle n’a pas
RAG (Retrieval-Augmented Generation) fonctionne en fournissant au modèle un contexte pertinent qu’il n’a pas dans ses données d’entraînement. Vous lui donnez une base de données vectorielle de vos documents de domaine, et avant chaque réponse, le système récupère les passages les plus pertinents.
Construisez un RAG quand :
- Votre modèle doit citer des sources spécifiques ou répondre à des questions sur vos données propriétaires
- Votre base de connaissances change mensuellement (contrats, politiques, documentation produit)
- Vous devez réduire les hallucinations sur les questions factuelles
- Vous voulez que le modèle dise « Je ne sais pas » plutôt que de deviner
Voici un exemple pratique en Python utilisant Claude et une fonction de récupération fictive :
import anthropic
def retrieve_context(query: str) -> list[str]:
# En production, cela interroge une base de données vectorielle (Pinecone, Weaviate, etc.)
# Pour la démo, renvoie des documents fictifs
docs = {
