Chapitre 2 — Modèles de base et ingénierie de prompt

Deuxième billet de la tournée chapitre par chapitre de LLM Primer V : Construire des applications LLM réelles. Le chapitre qui traite l'ingénierie de prompt comme de l'ingénierie — gabarits versionnés, délimiteurs défensifs, sorties structurées — au lieu d'un art jugé aux sensations.

Pourquoi ce chapitre existe

Le Chapitre 1 soutenait que le modèle est un composant à l'intérieur d'une enveloppe déterministe. Le Chapitre 2 examine ce composant de près. Le catalogue de modèles en 2026 est une taxonomie à distinctions nettes, pas une liste d'équivalents. Les paramètres d'échantillonnage transforment les mêmes poids en classifieur déterministe ou en écrivain créatif. Les prompts sont des artefacts structurés dont l'anatomie fait la différence entre survivre à l'entrée adversariale et ne pas y survivre. Des mécanismes existent pour forcer la sortie dans une forme que l'enveloppe peut valider, et choisir le mauvais pour la tâche coûte, en tentatives de validation, davantage que le mécanisme n'a fait économiser. Une équipe qui traite « le modèle » comme une ressource anonyme unique, utilise les valeurs par défaut partout, écrit ses prompts comme des chaînes jetables et valide la sortie en espérant — cette équipe a laissé au sol l'essentiel du contrôle d'ingénierie disponible.

2.1 La sélection de modèle comme décision d'ingénierie de premier plan

Le catalogue se divise en quatre familles : les petits modèles de langage optimisés pour la vitesse et le coût sur des tâches bornées ; les modèles généralistes de milieu de gamme qui gèrent la plupart des charges de production ; les modèles frontière pour le raisonnement le plus dur et les contextes les plus longs ; et les modèles de raisonnement qui dépensent du calcul d'inférence supplémentaire dans une étape de délibération cachée. Le multimodal traverse les quatre. La sélection est une décision de routage par requête, non un défaut global : requêtes courtes vers le SLM, tâches non triviales mais bien bornées vers le milieu de gamme, raisonnement le plus dur vers la frontière, modèles de raisonnement là où la latence est acceptable et où le gain de précision est réel. Le routeur journalise sa décision à côté de la réponse, si bien qu'une régression peut être filtrée par palier. La sélection n'est pas non plus une décision unique — le paysage des modèles bouge plus vite que toute autre infrastructure dont l'équipe dépend, et la discipline consiste à réexécuter le jeu d'évaluation trimestriellement et à migrer quand les preuves le soutiennent.

2.2 L'échantillonnage comme profil délibéré

La température met à l'échelle la distribution des tokens avant échantillonnage ; le top-p tronque au noyau au-dessus d'un seuil de probabilité ; le min-p filtre les tokens loin sous le sommet ; la seed offre une répétabilité au mieux. Deux profils méritent d'être nommés explicitement — le profil déterministe (température zéro, top-p 1.0, seed fixée) pour les tâches de classification, d'extraction et de routage dont le contrat est « même entrée, même sortie » ; et le profil créatif (température autour de 0,8, top-p 0,95) pour la génération où la variation est le produit. Mélanger les deux par accident, en utilisant la température 0,7 par défaut sur une tâche de classification, produit la classe des tests instables et des défaillances intermittentes que les équipes attribuent au modèle alors que la responsabilité appartient au choix de paramètres. Le streaming est orthogonal à l'échantillonnage : mêmes paramètres, transport différent, et le time-to-first-token remplace la latence totale comme métrique de vitesse perçue.

2.3 Prompts défensifs et sorties structurées

Un prompt de production a une anatomie en cinq parties — rôle, tâche, contraintes, exemples, entrée délimitée — et l'ordre compte parce que l'attention du modèle sur chaque composante est influencée par ce qui la précède. L'entrée délimitée, ancrée des deux côtés par le rappel que le contenu entre les marqueurs est de la donnée et non des instructions, est le plancher sous lequel un prompt ne devrait pas descendre. Les prompts sont des artefacts de code versionnés ; un nom comme prompts/classify_support_v3, journalisé dans chaque trace, est la façon dont une régression se ramène au changement qui l'a causée. Les sorties structurées — Pydantic en Python, Zod en TypeScript, passées au fournisseur comme schéma de réponse — imposent la forme de la sortie au moment du décodage. L'imposition côté fournisseur d'un schéma JSON retire une classe entière de défaillances de validation. Là où JSON Schema n'est pas assez expressif — SQL, formats à forme de regex, arguments d'outil face à un catalogue fermé — le décodage contraint par une grammaire, via Outlines, offre la même garantie au niveau du token.

Ce que prépare le Chapitre 2

Le Chapitre 2 supposait que ce que contient le prompt suffit pour la tâche. Pour beaucoup de tâches — classification, extraction, transformation — cette hypothèse tient. Pour la plupart des systèmes de production tournés vers l'utilisateur elle échoue, parce que l'utilisateur pose des questions sur des faits que l'équipe possède et que le modèle n'a jamais vus : documents internes, la politique de cette semaine, l'historique de commandes du client. Le geste d'ingénierie qui ferme cet écart est la génération augmentée par la récupération. Le Chapitre 3 parcourt le pipeline RAG de bout en bout — chargement, découpage, embedding, récupération, génération — puis les techniques qui séparent un pipeline de démo d'un pipeline de production : récupération hybride, découpage sensible à la structure et transformations de requête comme HyDE et step-back.

Prochaine étape — Chapitre 3 : Génération augmentée par la récupération. Le pipeline qui donne au modèle le contexte que ses données d'entraînement n'ont jamais couvert — de bout en bout, du chargeur au générateur.