Anatomie d'un system prompt de production

Un prompt de prod n'est pas une question, c'est une spec

Le prompt d'extraction du pipeline étudié (celui qui lit les bons de commande) tient en quelques blocs — chacun répond à un bug passé :

[RÔLE]        Tu extrais des lignes de commande de documents B2B.
[RÈGLES]      - N'invente JAMAIS de SKU.                    ← anti-hallucination
              - quantity = null si rien n'est écrit.        ← doctrine transcription
              - Conserve le texte source dans raw_text.     ← traçabilité
              - Champs manquants = null, jamais devinés.
[CONTEXTE]    Le message accompagnant le document : {context_text}
[FORMAT]      (imposé par le schéma du tool forcé — pas par la prose)

Les principes transposables :

1. le rôle borne le comportement : « tu extrais » exclut d'office le bavardage, les excuses, les conseils — une ligne économise dix règles négatives ;
2. les règles sont des interdits vérifiables, exactement comme dans un manifeste d'équipe (cours agents !) — « n'invente jamais de SKU » se teste, « sois précis » non ;
3. chaque règle vient d'un incident : raw_text obligatoire est né du besoin d'auditer, quantity=null du formulaire aux 161 lignes inventées. Un prompt de prod est un journal de cicatrices — et c'est pour ça qu'on ne le « nettoie » jamais sans consulter l'éval ;
4. le format ne se demande pas en prose : la sortie structurée passe par le schéma du tool forcé (leçon suivante) — la prose motive, le schéma contraint.

Ce qui dégrade un prompt (les anti-patterns mesurés)

• la règle contradictoire : « sois exhaustif » + « sois concis » — le modèle arbitre au hasard ;
• l'empilement sans tri : chaque incident ajoute sa règle, personne n'en retire — au-delà d'un certain poids, les règles se diluent mutuellement (l'éval le mesure : ajouter ≠ améliorer) ;
• l'exemple périmé : un few-shot qui contredit une règle récente gagne souvent — les exemples parlent plus fort que les instructions ;
• le prompt qui explique au lieu d'ordonner : le modèle n'a pas besoin de comprendre ta base de données, il a besoin de savoir quoi produire.