Construire des LLM fiables, étape par étape
Je présente une méthode complète de context engineering pour passer des prompts isolés à de vraies applications LLM, en découpant les problèmes, en orchestrant des agents et en contrôlant les flux d’information. DSPy sert de colonne vertébrale déclarative pour obtenir des sorties structurées, introduire du raisonnement, appeler des outils, et implémenter RAG avancé. J’ajoute des bonnes pratiques de production — évaluation, tolérance aux pannes et observabilité — avec code, dépôt GitHub et un cours vidéo dédié.
Points clés
- Le context engineering, inspiré notamment par un tweet d’Andrej Karpathy, dépasse le prompt engineering atomique: il segmente les problèmes, relie des agents via des flux de contrôle et gère explicitement le contexte intermédiaire (raisonnements, outils, mémoire).
- Remplir des fenêtres de contexte “longues” dégrade la qualité: des effets de context poisoning/rot ont été documentés (rapport Chroma), d’où la nécessité d’approches systématiques plutôt que de tout “gaver” au modèle.
- DSPy sépare contrats d’E/S (Signatures) et logique (Modules), génère des sorties structurées validées (Pydantic) et relance automatiquement en cas d’erreur, ce qui évite les plantages liés au parsing.
- Le raisonnement de type Chain of Thought s’active simplement (dspy.ChainOfThought), injectant les étapes intermédiaires dans le contexte pour améliorer la qualité des réponses.
- Des flux séquentiels et agentiques exploitent des modèles adaptés à chaque sous-tâche: par exemple OpenAI gpt-4.1-mini pour l’idéation et gpt-4.1 pour la génération, optimisant coût, latence et qualité.
- La sélection conditionnelle s’appuie sur un juge: génération parallèle de num_samples=5 idées, choix du meilleur index, puis conversion en sortie finale — un schéma qui illustre l’orchestration et l’évaluation interne.
- Le tool calling (dspy.ReAct) intègre des fonctions Python, comme Tavily pour des actualités des 7 derniers jours (max_iters=2), et s’étend à des outils système (scratchpad, I/O fichiers) voire à des serveurs MCP (standard client-serveur d’outillage).
- Le RAG “fiable” combine métadonnées de chunks, réécriture de requêtes, HYDE, recherche hybride (cosine + BM25) et fusion RRF; le multi-hop renvoie les documents au LLM pour générer de nouvelles requêtes; les réponses peuvent inclure des citations.
- La mémoire type Mem0 marie récupération et appels d’outils: le LLM décide d’écrire/modifier des souvenirs, puis les récupère lors des réponses, améliorant la cohérence conversationnelle.
- Pour la production: “design evaluation first”, sorties structurées “partout”, design for failure et monitoring (MLflow; alternatives Langfuse, Logfire) des KPI clés — usage de tokens, latence, coût — plus ressources pratiques (cours YouTube de 1 h 20 et dépôt GitHub).
À retenir
Commencez simple: découpez votre problème, choisissez des modèles à la bonne taille et n’essayez pas de fourrer Wikipédia dans la fenêtre de contexte (votre carte bleue et votre CPU vous diront merci). Préférez des sorties structurées, prévoyez les échecs — ils arriveront — et surveillez tokens, latence et coût comme du lait sur le feu. Pour les données, mixez sémantique et mots-clés, ajoutez HYDE et RRF, et appelez des outils via ReAct quand c’est pertinent. Et si tout marche du premier coup, félicitations: vous venez d’inventer une nouvelle loi de la physique.
Sources
