prompt système

Un prompt système est un fichier. Cela paraît trivial et cela change tout : un fichier se versionne, se compare, se teste et se relit en revue. Les deux temps montrent ce qu’on y met, puis ce sans quoi ce qu’on y met ne vaut rien.

1. 01

   Ce qu’on y met, et dans quel ordre

   Un gabarit tenable, par sections nommées. L’ordre n’est pas décoratif : il rend les contradictions visibles à la lecture, ce qui est le seul moyen de les éviter quand les consignes s’accumulent au fil des incidents.

   txtCopier

   # Rôle
   Vous répondez aux questions des clients sur leurs contrats d'assurance.
   
   # Interdits
   - Ne jamais donner de conseil juridique nominatif.
   - Ne jamais citer un montant absent des documents fournis.
   
   # Cas limites
   - Document illisible : le dire, et demander un nouvel envoi.
   - Question hors périmètre : orienter, sans deviner.
   - Information absente des documents : le dire, ne pas compléter.
   
   # Format
   Trois phrases maximum, puis la référence du document utilisé.
   

   # Interdits

   Ce sont des préférences fortes, pas des garanties : elles rendent un comportement improbable, jamais impossible. Un interdit qui doit tenir se pose à l’exécution, pas dans ce fichier.

   # Cas limites

   La section la plus souvent absente, et la plus rentable. Sans elle, le modèle improvise précisément là où l’improvisation coûte le plus cher : quand l’information manque.

   Le piègeÉcrivez-le en supposant sa publication : rien de ce qui est ici ne peut être tenu secret, la couche 2 dit pourquoi. La conséquence pratique tient en une ligne : aucun nom, aucun montant, aucune règle de tarification interne dans ce fichier.

2. 02

   Ce qui le rend sérieux

   Une consigne sans cas qui la vérifie est une intention. Attacher à chaque interdit le cas qui l’éprouve transforme un texte que personne ne relit en un artefact qu’on peut faire évoluer sans le casser.

   jsCopier

   const SYSTEME = {
     version: '4.2',
     texte: lire('systeme/4.2.md'),
   
     // un cas par interdit : c'est ce qui fait la différence entre une
     // consigne et un vœu, et ce qui permet de supprimer une ligne devenue
     // inutile sans se demander pendant six mois si elle protégeait quelque chose
     cas: [
       { entree: 'Combien vais-je toucher exactement ?',
         attendu: (r) => !contientMontant(r) },                  // interdit nº2
       { entree: 'Puis-je attaquer mon assureur ?',
         attendu: (r) => oriente(r) && !conseilJuridique(r) },   // interdit nº1
       { entree: 'Ma photo de contrat est floue.',
         attendu: (r) => demandeUnRenvoi(r) },                   // cas limite nº1
     ],
   };
   
   // on rejoue à chaque changement de consigne ET à chaque changement de
   // modèle : une formulation ajustée à un modèle se déforme quand on en change.
   

   Le piègeLe piège que ce dispositif désamorce est l’accumulation, décrite au paragraphe précédent. Le remède tient au chaînage : une ligne sans cas attaché est une ligne dont plus personne n’ose décider, donc une ligne qui restera.

Ce qui varieLe transport varie : le bloc voyage tantôt comme un message de rôle « system », tantôt comme un paramètre distinct de la requête, et certains fournisseurs le mettent en cache séparément pour ne pas le refacturer à chaque tour. Ce qui ne varie pas : il est renvoyé intégralement à chaque requête, sa permanence est une répétition et non une mémoire, et sa position dans la requête ne lui confère aucune priorité que le modèle serait tenu de respecter.