Générer et publier sont deux privilèges
Une bonne architecture suppose que le modèle se trompera parfois. Laissez-le proposer fichiers, métadonnées et changements, mais ne laissez pas la même étape publier silencieusement. Une frontière séparée de build et review rend les erreurs visibles et réversibles.
Limitez les entrées
Fournissez des sources nommées plutôt qu’un contexte illimité. Séparez faits produit autoritatifs, exemples, discussions historiques et contenu utilisateur. Enregistrez quels fichiers ou réponses API ont servi à une révision.
Cela améliore reproductibilité et review.
Validez la structure de façon déterministe
Utilisez schemas pour le frontmatter, vocabulaires contrôlés pour tags et terminologie, parsers pour le code. Vérifiez liens, images, localisations et métadonnées avant toute évaluation par modèle.
Les checks déterministes doivent échouer vite.
Traitez le texte externe comme un input non fiable
Issues, forums, pages web et messages clients peuvent contenir des instructions hors sujet ou hostiles. Extrayez l’information, mais ne les laissez pas redéfinir les agent rules ou la politique de publication.
Exigez des preuves pour les claims risqués
Sécurité, limites, compatibilité, billing, données et opérations destructives demandent une revue renforcée, même si la prose est excellente.
Préservez le rollback
Chaque changement automatique doit être une révision versionnée normale avec un diff clair. Évitez de modifier le contenu publié sans commit ou artefact traçable.
Les guardrails permettent d’augmenter le débit sans diminuer la responsabilité.
Exemple pratique
Testez « Guardrails pour un pipeline LLM qui publie de la documentation technique » sur un échantillon contrôlé avant d’en faire un workflow de production. Sélectionnez dix fragments dont vous connaissez déjà l’état correct : actuels, obsolètes, ambigus et volontairement faux. Gardez les instructions fixes et notez les bonnes décisions comme les erreurs formulées avec assurance.
Relisez comme un éditeur :
- le modèle sépare-t-il preuve et inférence ;
- conserve-t-il terminologie et contraintes produit ;
- invente-t-il des faits ou masque-t-il l’incertitude ;
- un humain peut-il voir ce qui a changé et pourquoi.
La question utile n’est pas de savoir si le modèle écrit avec fluidité, mais si le workflow rend les erreurs visibles avant publication. La confiance vient de limites, d’entrées et de points de revue humaine explicites.
Checklist éditorial rapide
- Générer et publier sont deux privilèges. Une bonne architecture suppose que le modèle se trompera parfois.
- Limitez les entrées. Fournissez des sources nommées plutôt qu’un contexte illimité.
- Validez la structure de façon déterministe. Utilisez schemas pour le frontmatter, vocabulaires contrôlés pour tags et terminologie, parsers pour le code.
- Traitez le texte externe comme un input non fiable. Issues, forums, pages web et messages clients peuvent contenir des instructions hors sujet ou hostiles.
