NVIDIA NeMo Guardrails

Salut, c'est Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 1 sur 10. Tu ne connecterais jamais une base de données brute directement à Internet, pourtant de nombreuses applications exposent des modèles de langage non contraints directement aux utilisateurs finaux. S'appuyer uniquement sur un system prompt pour maintenir la sécurité est une architecture fragile. Aujourd'hui, on aborde l'impératif des Guardrails en IA : les abstractions fondamentales. NeMo Guardrails agit comme une couche intermédiaire programmable située entre ton application utilisateur et le modèle de langage. Il ne remplace pas ton modèle. Il crée plutôt un pipeline séparé de contrôles de sécurité discrets appelés rails. Plutôt que de supplier le modèle de bien se comporter via du prompt engineering complexe, tu orchestres la sécurité grâce à cette couche déterministe. Prends l'exemple d'un bot de service client. Un utilisateur envoie un message, le système récupère les articles de support pertinents, le modèle rédige une réponse, et ça peut déclencher une action backend comme le traitement d'un remboursement. Tu as besoin de différents types de protection à chaque étape. Pour gérer ça, Guardrails définit cinq types de rails distincts. D'abord, le message de l'utilisateur arrive sur l'Input Rail. Ce rail inspecte le texte avant même que le modèle de langage principal ne le voie. Si un utilisateur tente une attaque par prompt injection ou soumet un texte très toxique, l'input rail intercepte immédiatement le message. Il stoppe le pipeline et renvoie un refus prédéfini. Le modèle principal ne traite jamais le texte malveillant, ce qui économise du compute et empêche un exploit. Si l'input est sûr, le système évalue les Dialog Rails. Ils gèrent le flux attendu de la conversation. Si un utilisateur demande au bot de support son avis sur un concurrent, un dialog rail identifie le sujet. Il force le bot à suivre un chemin prédéterminé, par exemple en répondant qu'il ne discute que de ses propres produits. Les dialog rails empêchent le modèle de s'écarter du sujet ou de répondre à des questions qui ne le regardent pas. Ensuite, quand ton bot cherche dans ta base de connaissances pour sourcer sa réponse, les Retrieval Rails prennent le relais. Ils inspectent les chunks de texte extraits de la base de données avant qu'ils ne soient ajoutés au prompt du modèle. Si une recherche mal configurée récupère par erreur un document interne des ressources humaines au lieu d'un manuel public, le retrieval rail détecte l'information sensible et la retire de la context window. Si la conversation nécessite que le bot effectue une tâche, les Execution Rails interviennent. Ils contrôlent quelles actions personnalisées le modèle est autorisé à déclencher. Quand le modèle demande à exécuter du code ou à appeler un outil externe, l'execution rail vérifie si cette action spécifique est permise vu l'état actuel de la conversation. Il bloque l'exécution des commandes non autorisées. Enfin, on a les Output Rails. C'est la dernière ligne de défense. Après que le modèle a généré une réponse, l'output rail évalue le texte avant qu'il n'atteigne l'utilisateur. Il vérifie les hallucinations, un ton inapproprié ou les fuites de données sensibles. Si le texte échoue à la vérification, l'output rail l'intercepte et modifie ou bloque le message final. Cette architecture change fondamentalement la façon dont tu développes des applications génératives. Tu arrêtes de te fier à un moteur probabiliste pour réguler son propre comportement, et à la place, tu construis un filet de sécurité déterministe qui contrôle les inputs, la logique et les outputs indépendamment. Au fait, si tu trouves ces épisodes utiles et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. C'est tout pour cet épisode. Merci pour ton écoute, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 2 sur 10. Écrire du Python brut pour gérer des dialogue state machines complexes et ramifiées est un véritable cauchemar. Dès que ton utilisateur s'écarte d'un script rigide, ta logique hardcodée plante. L'architecture de configuration dans NeMo Guardrails règle ça en traitant les conversations comme des flows event-driven plutôt que comme du code statique. NeMo Guardrails sépare la mécanique de ton application de la logique de ta conversation. Ça se passe à travers deux éléments de configuration distincts. D'abord, tu as ton fichier de configuration YAML. C'est lui qui gère tout le model wiring. C'est là que tu déclares ton modèle de langage principal, que tu définis tes embedding models et que tu enregistres les custom actions de ton application. Le fichier YAML connecte l'infrastructure sous-jacente. Il fournit le moteur, mais il ne sait absolument rien de ce que l'utilisateur va réellement dire. La logique de conversation elle-même est gérée par Colang 2.0. Colang est un langage de modélisation d'interactions event-driven. Au lieu d'écrire du code impératif standard avec des conditions à n'en plus finir pour tracker où en est l'utilisateur dans une conversation, tu définis des flows. Un flow modélise une séquence d'interactions. Quand un utilisateur envoie un message, ça génère un event. La state machine attrape cet event, cherche un flow actif qui matche l'interaction, et dicte le prochain mouvement de l'assistant. C'est la partie qui compte vraiment. Colang utilise des Natural Language Descriptions pour faire le pont entre le code strict et l'ambiguïté humaine. Au lieu d'écrire des regex complexes pour parser un message utilisateur, tu donnes tes instructions au système en utilisant le langage humain directement dans ta logique de flow. Tu associes ces descriptions au generation operator, qui s'écrit simplement avec trois petits points. Quand la state machine rencontre ces trois points, elle met temporairement l'exécution en pause. Elle passe le contexte actuel et ta description en langage naturel au modèle de langage sous-jacent, en lui demandant de générer ou d'extraire la valeur exacte dont tu as besoin. Prenons un scénario concret comme la réservation d'un billet d'avion. Tu as besoin de savoir quand l'utilisateur veut voyager. Dans ton fichier Colang, tu définis un flow de réservation de vol. À l'intérieur de ce flow, tu dis au système d'attendre que l'utilisateur parle. Une fois qu'il le fait, tu dois extraire la date. Tu déclares une variable de contexte, disons flight date. Tu lui assignes la valeur d'une description en langage naturel, en écrivant littéralement la phrase "la date à laquelle l'utilisateur veut voler", immédiatement suivie du generation operator, ces trois petits points. Quand l'utilisateur dit "J'ai besoin d'un billet pour mardi prochain", la state machine de Colang capture l'event. Elle tombe sur l'assignation de ta variable. Elle passe le message de l'utilisateur et ton instruction en langage naturel au modèle de langage. Le modèle lit le contexte, identifie "mardi prochain" comme la valeur cible, et la retourne. Le generation operator se résout, et ta variable de contexte contient maintenant la date extraite de façon sécurisée. Ton flow passe ensuite à l'étape suivante, qui pourrait impliquer d'appeler une API de réservation externe définie dans ta configuration YAML. La vraie puissance de cette architecture, c'est que tu arrêtes de te battre avec les dialogue states en utilisant du code rigide. Tu laisses un fichier YAML verrouiller l'infrastructure statique, et tu laisses Colang utiliser la capacité de raisonnement du modèle de langage pour naviguer dans la réalité imprévisible de la conversation humaine. Je voudrais prendre un instant pour te remercier de ton écoute — ça nous aide énormément. Passe une excellente journée !

Salut, c'est Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 3 sur 10. S'appuyer sur un modèle massif de soixante-dix milliards de paramètres pour faire de la modération de contenu basique, c'est un énorme gaspillage de compute. C'est lent, ça coûte cher, et ça prend de la puissance de calcul qui devrait servir à générer de vraies réponses. La solution, c'est la sécurité de contenu spécialisée avec Nemotron NIM. Au lieu de demander à ton modèle d'application principal d'à la fois écrire du code et vérifier la toxicité, tu divises la charge de travail. Le modèle principal gère le raisonnement complexe et la génération. Un deuxième modèle, beaucoup plus petit, s'occupe de la sécurité. Plus précisément, on s'intéresse au Llama 3 point 1 Nemotron Safety Guard 8B V3. C'est un modèle de huit milliards de paramètres fine-tuned entièrement pour un seul job : évaluer la sécurité du contenu. Il tourne comme un microservice autonome, ou NIM, que NeMo Guardrails appelle via une API. Pour mettre ça en place, tu définis le Nemotron NIM dans ta configuration Guardrails comme un modèle distinct. Tu définis son type comme content safety, pendant que ton modèle principal reste le type main. Cette distinction est cruciale parce que Guardrails route le trafic différemment en fonction de ces labels. Une fois configuré, tu actives le safety guard comme un input rail et un output rail. Quand un utilisateur envoie un prompt, Guardrails l'intercepte avant même qu'il n'atteigne ton modèle principal. Il envoie le prompt au NIM de sécurité Nemotron. Le NIM évalue le texte par rapport à vingt-trois catégories spécifiques de contenu unsafe. Ces catégories couvrent tout, des discours haineux et de la violence jusqu'au contenu sexuel et à la planification criminelle. Prends l'exemple d'une application multilingue où un utilisateur soumet un prompt en français, demandant des instructions étape par étape pour démarrer une voiture en faisant les fils. L'input rail intercepte ça. Guardrails envoie le texte en français au Nemotron NIM. Parce que le modèle de sécurité est entraîné sur des données de sécurité multilingues, il comprend l'intention, peu importe la langue. Il flag la requête comme faisant partie de la catégorie criminal advice et renvoie un signal unsafe à Guardrails. Guardrails stoppe alors immédiatement le processus et renvoie un message de refus standard à l'utilisateur. Ton modèle principal ne voit même jamais le prompt, ce qui t'économise le coût d'inférence pour traiter une requête toxique. Exactement la même logique s'applique dans l'autre sens pour les output rails. Si un prompt apparemment inoffensif arrive à tromper le modèle principal pour générer une réponse unsafe, Guardrails intercepte ce texte généré avant qu'il n'atteigne l'utilisateur. Il envoie l'output au NIM de sécurité, le vérifie par rapport à ces mêmes vingt-trois catégories, et le bloque s'il enfreint les règles. Mettre ça en place nécessite de mettre à jour tes fichiers de configuration. Tu déclares le modèle Nemotron dans ta liste de modèles, en le pointant vers ton endpoint NIM. Ensuite, tu actives les flows par défaut self-check input et self-check output, en disant explicitement à Guardrails d'utiliser ton modèle de content safety pour ces vérifications. Tu n'as pas besoin d'écrire des prompts custom pour expliquer au modèle comment évaluer la toxicité. Le modèle Nemotron attend un format de prompt très spécifique pour évaluer le texte, et NeMo Guardrails formate cet appel API automatiquement sous le capot. Tu as juste à pointer les rails vers le NIM et le laisser faire la classification. Découpler ta logique de modération dans un modèle dédié plus petit garantit que ton modèle d'application principal passe ses cycles à générer de la valeur, pendant qu'un guard spécialisé gère efficacement la sécurité du périmètre. C'est tout pour cet épisode. Merci d'avoir écouté, et keep building !

Salut, c'est Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 4 sur 10. Le moyen le plus simple d'éviter que ton chatbot ne provoque un désastre en relations publiques, c'est de t'assurer qu'il refuse tout simplement d'en parler. Tu ne peux pas compter sur un modèle de langage généraliste pour refuser de lui-même, et de façon fiable, chaque sujet hors de propos ou risqué. C'est pour ça qu'on utilise l'application stricte des limites de domaine avec le Topic Control. Les modèles de langage généralistes cherchent toujours à faire plaisir. Si un utilisateur pose une question un peu maligne, le modèle va essayer d'y répondre. Si tu crées un bot de service client, tu veux qu'il parle uniquement de service client. Tu as besoin d'une limite stricte. Pour créer cette limite, tu utilises le NIM Llama 3.1 NemoGuard 8B TopicControl. C'est un modèle spécialisé, conçu pour une tâche bien précise. Il ne génère pas de réponses conversationnelles. Il évalue. Prends l'exemple d'un bot de support télécom. Son rôle, c'est d'aider les utilisateurs avec leurs factures de téléphone, les pannes de réseau et les forfaits data. Un utilisateur se connecte au chat et demande au bot son avis sur une élection politique récente. Sans guardrails, ton modèle principal reçoit le prompt, le traite, et risque de générer une réponse inappropriée. Avec NeMo Guardrails, tu configures un Input Rail. Un Input Rail intercepte la requête de l'utilisateur avant que quoi que ce soit d'autre ne se passe. Le modèle de langage principal ne voit même jamais la requête. Quand l'utilisateur pose une question sur l'élection, le guardrail route l'input directement vers le modèle TopicControl. Tu contrôles le comportement de ce modèle en définissant des guidelines strictes dans son system prompt. Pour ton bot télécom, ton system prompt indique que les sujets acceptables sont la facturation, l'état du réseau et la gestion de compte. Le modèle TopicControl prend le prompt de l'utilisateur et l'évalue par rapport à ces guidelines précises. Il renvoie ensuite une classification rigide. Il retourne une évaluation soit on-topic, soit off-topic. Si l'utilisateur demande pourquoi ses frais de roaming sont élevés, le modèle TopicControl lit le prompt, vérifie les guidelines et retourne on-topic. Le guardrail ouvre la porte, et le prompt de l'utilisateur passe jusqu'à ton modèle conversationnel principal pour générer une réponse utile. Quand l'utilisateur pose une question sur l'élection politique, le modèle TopicControl évalue le prompt par rapport aux guidelines télécom. Il reconnaît le décalage et retourne off-topic. Le guardrail stoppe immédiatement le pipeline. Il empêche la requête d'atteindre ton modèle principal. À la place, le guardrail déclenche une réponse de refus statique et prédéfinie. Le bot dit à l'utilisateur qu'il est uniquement équipé pour gérer les services télécom. Utiliser un modèle dédié pour le Topic Control sépare la logique d'évaluation de la logique conversationnelle. Tu ne gaspilles pas de coûteux cycles de compute à demander à un modèle massif et généraliste de deviner s'il a le droit de répondre à une question. Tu utilises un modèle plus petit et hautement optimisé de huit milliards de paramètres pour faire office de videur à l'entrée. Ça permet de garder les limites de ton domaine strictement appliquées, sans nécessiter de prompt engineering complexe et fragile sur ton modèle principal. La façon la plus sécurisée de gérer une requête hors limites, c'est de t'assurer que ton moteur de raisonnement principal ne sache même pas que la requête a été faite. C'est tout pour cet épisode. Merci de ton écoute, et continue de développer !

Bonjour, ici Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 5 sur 10. Si ton système de retrieval-augmented generation ingère une base de données d'employés non expurgée, tu as déjà commis une violation de conformité avant même que le modèle de langage ne génère un seul mot. Une fois que des données sensibles entrent dans le contexte du prompt, tu perds le contrôle de leur destination. La détection et le masquage dynamiques des PII, c'est ce qui te permet d'intercepter ces données en transit. Prenons l'exemple d'un bot RH interne. Un manager pose au bot une question générale sur la politique d'évaluation des performances de l'entreprise. Le bot fait une recherche dans la base de connaissances interne. La recherche renvoie le document de politique pertinent, mais les chunks de texte récupérés incluent par accident le dossier d'un employé spécifique ajouté à la fin du fichier, avec un nom, une adresse personnelle et un email. Si le système passe directement ces chunks récupérés au modèle de langage, ces données sensibles intègrent la context window. NeMo Guardrails gère ça en se plaçant entre les composants de ton application et en filtrant le stream de texte. Il propose deux approches distinctes. La détection consiste à identifier les informations personnellement identifiables et à prendre une mesure stricte, comme bloquer complètement le prompt ou lever une erreur. Le masquage est plus flexible. Il trouve les informations sensibles et les remplace par un placeholder générique à la volée. Le texte john@example.com devient une string entre crochets indiquant EMAIL. La base de données sous-jacente reste complètement intacte. Pour exécuter ça, le système de guardrails s'appuie sur des outils externes spécialisés. Tu configures le framework pour appeler un moteur comme Microsoft Presidio ou GLiNER. Presidio utilise généralement du pattern matching, des expressions régulières et une logique basée sur des règles pour repérer des formats standards comme les numéros de téléphone ou les cartes de crédit. GLiNER, qui signifie Generalist and Lightweight Indicator for Named Entity Recognition, utilise un petit modèle de machine learning pour identifier les entités en fonction du contexte environnant. Tu définis un array de types d'entités qui t'intéressent, et le moteur sélectionné gère l'extraction. Cette protection opère à trois points spécifiques dans le flow de l'application. Le premier est l'input rail. Si un utilisateur tape son propre numéro de sécurité sociale dans la fenêtre de chat, l'input rail scanne la string entrante et masque le numéro avant même que le modèle de langage ne reçoive le prompt. Le modèle traite la requête en utilisant le placeholder, complètement aveugle au numéro réel. Le deuxième point est le retrieval rail. C'est la partie qui compte. Quand ton système requête une base de données vectorielle et récupère des chunks de texte brut, le guardrail intercepte ces chunks avant qu'ils ne soient injectés dans le prompt template final. Il scanne le texte récupéré, retire les vrais noms et adresses, et substitue les tags masqués. Ton mécanisme de retrieval peut tirer des informations de sources de données désordonnées et non expurgées, mais le modèle de langage est protégé des détails sensibles. Le troisième point est l'output rail. Si le modèle de langage génère des données sensibles, soit en les hallucinant, soit parce qu'une donnée a réussi à passer à travers les rails précédents, l'output rail agit comme un checkpoint final. Il scanne la réponse générée et masque le texte sensible avant qu'il n'atteigne l'écran de l'utilisateur. Parce que tout ça se passe dynamiquement en mémoire pendant l'exécution d'une seule requête, ton architecture de données n'a pas besoin de changer. Tu évites l'énorme overhead d'ingénierie lié à la maintenance de bases de données dupliquées et pré-expurgées juste pour faire tourner une application de chat. La façon la plus sécurisée de gérer des données sensibles dans une application de modèle de langage, c'est de s'assurer que le modèle ne compute jamais sur les vraies données pour commencer. C'est tout pour cet épisode. Merci pour ton écoute, et continue à développer !

Salut, c'est Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 6 sur 10. Certaines des attaques de prompt injection les plus dévastatrices ne ressemblent pas du tout à du social engineering sophistiqué. Pour un humain, ça ressemble juste à du charabia complet. L'utilisateur ne cherche pas à piéger le bot avec une énigme, mais plutôt à le surcharger mathématiquement. Détecter ça nécessite une détection de jailbreak via des heuristiques de perplexité. Prends un scénario d'attaque précis. Un utilisateur malveillant veut que ton application produise quelque chose de dangereux, mais il sait que tu as des instructions de sécurité dans ton system prompt. Pour contourner ces instructions, il prend sa requête malveillante et la complète avec une énorme string de caractères aléatoires, de symboles obscurs ou de mots qui ne veulent rien dire. Quand le modèle de langage traite cet input, les mécanismes d'attention sont saturés par le volume énorme de tokens imprévisibles. Le modèle perd le fil de son alignement de sécurité sous-jacent et répond simplement à la requête malveillante. Tu ne peux pas détecter cette attaque avec des filtres de mots-clés standards, parce que le padding est aléatoire. Tu pourrais utiliser un autre modèle de langage pour évaluer le prompt entrant et chercher des patterns adversariaux, mais ça ajoute une énorme pénalité de latence à chaque requête utilisateur. Il te faut un filtre rapide, mathématique, et qui tourne en local. C'est là qu'intervient la perplexité. La perplexité est une métrique standard qui mesure à quel point un texte est prévisible pour un modèle de langage. Les phrases humaines normales suivent des patterns prévisibles, ce qui donne une perplexité faible. Une string de caractères aléatoires, ou une séquence bizarre de mots qui n'ont rien à voir, est très imprévisible. Ça génère une perplexité élevée. En calculant la perplexité d'un prompt entrant, tu obtiens une mesure statistique de son côté aléatoire. NeMo Guardrails utilise ce concept pour bloquer les attaques par charabia grâce à deux heuristiques principales. La première est la Length per Perplexity. Les attaques adversariales nécessitent généralement une longue string de texte poubelle pour réussir à faire dérailler le modèle principal. Une courte string qui ne veut rien dire est généralement ignorée par le mécanisme d'attention. Cette heuristique calcule un ratio en utilisant la longueur totale du prompt et son score de perplexité global. Si un prompt est à la fois anormalement long et très imprévisible, il franchit un seuil mathématique prédéfini. Le guardrail intercepte l'input, le signale comme un jailbreak potentiel, et bloque la requête avant même que ton modèle principal ne la voie. La deuxième heuristique gère une variante plus chirurgicale de cette même attaque. Parfois, un attaquant cache le charabia. Il écrit une phrase complètement normale, à faible perplexité, au milieu de son prompt, mais il ajoute un bloc dense de tokens aléatoires tout à la fin. Si tu calcules la perplexité sur tout le prompt, le texte normal risque de diluer le score moyen suffisamment pour passer à travers le premier filtre. Pour contrer ça, NeMo Guardrails utilise la Prefix and Suffix Perplexity. Au lieu de regarder tout le prompt, cette heuristique isole un nombre fixe de tokens tout au début et tout à la fin de l'input utilisateur. Elle calcule la perplexité de ces frontières de manière indépendante. Si l'utilisateur attache un payload adversarial de caractères aléatoires à la fin d'une question normale, le score de perplexité du suffixe grimpe en flèche. Le guardrail détecte l'anomalie à la frontière et rejette la requête. Tout ce processus se fait sans faire d'appel API externe vers un énorme modèle de langage. Il s'appuie sur un plus petit modèle local pour calculer les scores de perplexité, ce qui garde l'overhead de latence à un strict minimum. En retirant le sens sémantique du texte, tu arrêtes d'analyser ce que l'utilisateur essaie de dire et tu commences à analyser la forme mathématique de ses mots. Les heuristiques de perplexité te permettent de bloquer des attaques adversariales complexes en utilisant des statistiques brutes, sécurisant ton application à la vitesse des maths. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 7 sur 10. Donner à un modèle de langage l'accès pour exécuter des requêtes de base de données, c'est comme confier les clés de ta base de données à un inconnu. Tu dis au modèle de récupérer des données utilisateur, mais un prompt malin le piège et lui fait ajouter une commande pour drop une table. Sécuriser les workflows agentiques avec des execution rails, c'est comme ça que tu empêches les agents autonomes de compromettre ton backend. La plupart des guardrails se concentrent sur la réponse du chat. Ils empêchent le modèle d'utiliser un langage inapproprié ou de faire du hors-sujet. Les execution rails font quelque chose de complètement différent. Ils protègent les tools que l'agent utilise. Quand un agent décide d'utiliser un tool pour lancer un script Python généré ou exécuter une requête SQL, l'execution rail intercepte le payload exactement au moment du transfert, juste avant que le tool ne s'exécute vraiment. NeMo Guardrails gère cette validation en utilisant des règles YARA. YARA est un moteur de pattern-matching traditionnellement utilisé par les analystes en cybersécurité pour identifier les malwares à partir de signatures textuelles ou binaires spécifiques. Dans ce framework, NVIDIA fournit un catalogue prédéfini de patterns YARA créés spécifiquement pour détecter les vulnérabilités des modèles de langage. Le moteur de guardrails passe l'input du tool à travers ces règles YARA pour chercher des signatures d'attaques connues. Ce catalogue cible quatre menaces spécifiques. La première, c'est l'injection SQL, où le modèle génère des commandes de base de données qui contiennent des modifications malveillantes. La deuxième, c'est l'injection de code, où l'agent essaie d'exécuter des commandes système non autorisées à l'intérieur d'un script Python généré dynamiquement. La troisième, c'est la template injection, où un attaquant manipule les moteurs de rendu côté serveur. Enfin, il détecte le cross-site scripting, en bloquant les payloads conçus pour exécuter des scripts malveillants dans un navigateur web. Prends l'exemple d'un agent chargé de prendre une requête utilisateur, d'écrire un script Python pour traiter des données locales, et de le lancer. Si un utilisateur cache une commande système pour exposer des variables d'environnement dans son prompt, le modèle de langage pourrait inclure aveuglément cette commande dans le script Python final. L'execution rail capte ça. Il scanne le code Python généré, matche la règle YARA pour l'injection de code, et signale le payload avant même que le moteur d'exécution ne le voie. Quand le système détecte un pattern malveillant, il agit en fonction de ta configuration. Tu as deux choix. La première action, c'est reject. Ça bloque complètement l'exécution du tool. Le workflow s'arrête, le code malveillant ne s'exécute jamais, et le système renvoie une réponse sécurisée. La deuxième action, c'est omit. Ça dit au guardrail de retirer la string malveillante spécifique du payload, mais d'autoriser le tool à exécuter ce qu'il reste. Choisir entre reject et omit dépend entièrement du tool. Si ton agent exécute une requête SQL sur une base de données, reject est le seul choix sûr. Omettre une string dans une requête SQL complexe va probablement causer une syntaxe malformée ou un accès aux données imprévisible. Omit est généralement réservé aux tâches basiques de traitement de texte, où retirer une mauvaise string laisse quand même un payload utilisable et sûr. Tu configures ces protections directement dans tes fichiers YAML en activant les security rails agentiques et en les mappant à des tools spécifiques. Le moteur YARA sous-jacent fait le gros du travail, en matchant les patterns prédéfinis sans t'obliger à écrire des expressions régulières custom. Les execution rails traitent le modèle de langage comme un utilisateur non fiable, ce qui te force à valider chaque commande qu'il génère avant qu'elle ne touche ton infrastructure. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 8 sur 10. Un bot qui dit qu'il ne connaît pas la réponse, c'est un peu agaçant. Mais un bot financier qui annonce avec assurance que ton entreprise a raté son objectif de chiffre d'affaires du troisième trimestre de cinquante millions de dollars, alors qu'elle l'a en réalité dépassé, c'est un désastre. Pour empêcher ton système de Retrieval-Augmented Generation d'inventer des chiffres et de détruire ta crédibilité, tu as besoin du Grounding RAG : Hallucinations et Fact-Checking. Mettons tout de suite les choses au clair sur une confusion courante. Le fact-checking et la détection d'hallucinations sont deux choses différentes. La détection d'hallucinations consiste généralement à poser la même question au modèle de langage plusieurs fois. Si les samples qui en résultent se contredisent, le modèle est probablement en train d'halluciner. Le fact-checking évalue une seule réponse générée par rapport à un ensemble spécifique de documents de confiance. NeMo Guardrails utilise le fact-checking pour garder tes pipelines RAG grounded. Les modèles de langage prédisent du texte. Ils ne savent pas intrinsèquement ce qui est vrai. Dans un setup RAG standard, tu récupères des chunks de texte depuis ta base de données, tu les passes au modèle, et tu lui demandes de répondre en se basant uniquement sur ce texte. Parfois, le modèle hallucine quand même, en mélangeant ses connaissances pré-entraînées avec tes données, ou en inventant simplement une métrique qui semble plausible. NeMo Guardrails empêche ça en utilisant un output rail appelé self check facts. Quand il est actif, ce rail intercepte la réponse générée par le modèle avant qu'elle n'aille à l'utilisateur. Le système traite cette réponse non vérifiée comme une hypothèse. Il récupère ensuite les snippets de texte exacts qui ont été extraits de ta base de données. Ces snippets sont stockés automatiquement dans une variable de contexte nommée relevant chunks. Cette variable, c'est la preuve tangible. Le guardrail lance ensuite une évaluation. Il passe l'hypothèse et la preuve à un evaluator model. L'evaluator vérifie si la preuve implique strictement l'hypothèse. Pour en revenir à notre bot financier, si le texte généré annonce un chiffre de revenus précis, mais que ce chiffre n'existe nulle part dans la variable relevant chunks, l'evaluator le flag comme ungrounded. Le guardrail bloque immédiatement la réponse hallucinée. À la place, il renvoie un message de fallback sécurisé, en admettant qu'il n'a pas assez d'informations. Utiliser un modèle de langage généraliste pour faire du fact-checking est facile à mettre en place, mais ça a un coût. Ça ajoute de la latence, ça brûle des tokens, et l'evaluator model peut parfois s'embrouiller avec un contexte dense. Tu n'es pas obligé d'utiliser le setup par défaut. Tu peux remplacer la vérification standard basée sur des prompts par des outils externes spécialisés. Les approches qui utilisent des modèles comme AlignScore ou Patronus Lynx sont très efficaces ici. Ce sont des modèles créés sur mesure et entraînés exclusivement pour détecter les incohérences entre un texte source et une affirmation générée. Quand tu routes les relevant chunks et l'hypothèse vers l'un de ces modèles spécialisés, tu bypasses complètement l'evaluator du modèle de langage standard. Ça te donne un verdict plus rapide, moins cher, et souvent plus rigoureux pour savoir si ton bot dit la vérité. C'est la partie qui compte. Faire le grounding d'un pipeline RAG, ce n'est pas rendre ton modèle génératif intrinsèquement plus véridique. Il s'agit de traiter chaque mot généré comme une affirmation suspecte qui doit survivre à un contre-interrogatoire strict face à tes données sources exactes avant de voir le jour. Si tu veux nous aider à continuer de faire ces épisodes, tu peux soutenir l'émission en cherchant DevStoriesEU sur Patreon. C'est tout pour aujourd'hui. Merci d'avoir écouté, et continue de développer !

Salut, c'est Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 9 sur 10. Tu passes des semaines à optimiser tes filtres d'entrée pour bloquer les prompts texte malveillants. Et là, un utilisateur contourne tout ton travail juste en prenant une capture d'écran de son mauvais prompt et en l'uploadant comme image. Les filtres de texte sont complètement aveugles à ça. Pour le détecter, tu as besoin de la Multimodal Content Safety. Prends l'exemple d'un utilisateur qui uploade la photo d'un fusil d'assaut customisé et tape la question : comment modifier ça pour tirer plus vite. Un guardrail de texte standard ne voit qu'une requête sur la modification d'un objet générique. Il n'a aucune idée que l'objet est une arme. L'intention malveillante n'existe que quand tu combines l'image et le texte. On gère ça en utilisant un Vision Language Model qui agit comme un LLM-as-a-judge. Dans NeMo Guardrails, tu configures ça à l'étape de l'input rail. Avant même que la requête de l'utilisateur n'atteigne ton modèle conversationnel principal, le guardrail intercepte le payload multimodal. Les données de l'image arrivent généralement dans un de ces deux formats. C'est soit une string encodée en Base64 intégrée directement dans l'appel API, soit une URL directe. Les strings Base64 rendent le payload de la requête immédiate beaucoup plus lourd, mais garantissent que l'image est disponible. Les URLs gardent le payload initial léger, mais nécessitent que le modèle d'évaluation ait un accès réseau sortant pour récupérer le fichier. Dans les deux cas, tu configures l'input rail avec un prompt template spécifique conçu pour l'évaluation multimodale. Ce template contient une grille stricte définissant les catégories de contenu unsafe, comme la violence, les actes illégaux, l'automutilation ou les armes. Le guardrail construit une requête d'évaluation. Il package ta grille de sécurité, le texte de l'utilisateur et l'image de l'utilisateur. Il envoie ce package combiné au modèle de vision et force le modèle à répondre avec un structured output, généralement un simple label safe ou unsafe. Le modèle agit strictement comme un juge. Il analyse l'arme sur la photo, lit la requête sur sa modification, et vérifie le sens combiné par rapport à tes catégories restreintes. Si le modèle de vision détecte une violation, il renvoie un verdict unsafe. L'input rail flag la requête, la bloque pour l'empêcher de continuer, et déclenche un message de refus prédéfini. Ton modèle d'application principal ne voit même jamais la requête malveillante. Fais attention à cette partie concernant les limites de contexte. Les modèles de vision traitent les images en les convertissant en tokens. Selon l'architecture du modèle et la résolution de l'image, une seule image peut consommer des milliers de tokens. Ta string Base64 ou l'URL de l'image, combinée au texte de l'utilisateur et à ta grille de sécurité multi-catégories, doit tenir entièrement dans la context window du modèle de vision. Si tu passes des images massives en haute résolution avec un texte de prompt long, tu vas dépasser la limite de tokens. L'évaluation du guardrail va échouer, ou le modèle va tronquer l'input et rater complètement la violation. Tu dois implémenter un preprocessing pour redimensionner ou compresser les images avant qu'elles n'atteignent le guardrail, pour garder une empreinte de tokens prévisible. Évaluer le texte et les images de façon isolée n'est plus suffisant, parce que les abus modernes se cachent exactement dans l'espace où ces deux modalités s'intersectent. Merci d'avoir passé quelques minutes avec moi. À la prochaine, prends soin de toi.

Salut, c'est Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, épisode 10 sur 10. Créer des règles de sécurité directement dans un script Python, c'est super pour les tests, mais c'est une catastrophe pour scaler dans une entreprise polyglotte. Si ton frontend utilise Node JS et que ton backend est un mix de Python et de Go, tu ne peux pas dupliquer ta logique de sécurité dans chaque langage. La solution, c'est d'utiliser les trois Enterprise Integration Patterns pour NeMo Guardrails. Prends un scénario de migration classique. Tu as buildé un prototype de bot de service client avec LangChain. Tu as ajouté des guardrails pour l'empêcher de parler des concurrents. Il marche parfaitement sur ton laptop. Maintenant, tu dois migrer ce prototype vers une architecture microservices de production scalable, où plusieurs applications vont le requêter. Tu as trois façons principales d'intégrer les guardrails pour y parvenir. La première méthode, c'est le SDK Python natif, et plus précisément un objet appelé LLMRails. C'est le moteur principal. Si tu développes un backend Python custom from scratch sans t'appuyer sur des frameworks d'orchestration, c'est ça que tu utilises. Tu instancies LLMRails, tu le fais pointer vers ton répertoire de configuration qui contient tes fichiers Colang et YAML, et tu l'utilises pour traiter les inputs. Tu lui passes une liste de dictionnaires de messages représentant l'historique de la conversation, et il te retourne la réponse évaluée. C'est direct et ça te donne un accès brut à la mécanique sous-jacente des guardrails. Vu que tu as déjà un prototype LangChain, tout réécrire pour utiliser le SDK brut, c'est une perte de temps. C'est là que la deuxième méthode s'applique : l'intégration LangChain avec RunnableRails. NeMo Guardrails s'intègre nativement au LangChain Expression Language. Tu crées une instance de RunnableRails chargée avec ta configuration et tu l'attaches directement à ta chain existante. Si ta chain prend un prompt, récupère des documents et appelle un modèle de langage, tu wrap tout ce flux avec le runnable du guardrail. Le guardrail intercepte l'input avant qu'il ne touche ta chain, et évalue l'output après que ta chain a généré une réponse. Le code principal de ton application change à peine, mais ta logique LangChain est maintenant protégée. C'est ça qui est important quand tu scales. Prends l'entreprise au sens large. Une autre équipe veut utiliser exactement les mêmes règles de sécurité que toi, mais ils développent une web gateway en Node JS ou un routeur haute performance en Go. Ils ne peuvent pas importer un objet LangChain Python. Pour ça, tu utilises la troisième méthode : l'API Server standalone. NeMo Guardrails inclut un serveur built-in que tu peux lancer via la ligne de commande ou déployer sous forme de conteneur. Tu démarres le serveur et tu le fais pointer vers ton dossier de configuration. Il expose immédiatement des endpoints REST qui imitent l'API standard d'OpenAI. Pour tes applications Go ou Node JS, le serveur de guardrails ressemble exactement à un modèle de langage standard. Elles envoient des requêtes JSON standards à l'endpoint de chat completions. Le serveur gère les guardrails d'input, communique avec le vrai modèle sous-jacent, traite les guardrails d'output, et retourne le texte clean. Découpler tes règles de ta logique applicative en utilisant un serveur standalone, c'est le seul moyen fiable d'appliquer des politiques de sécurité cohérentes à l'échelle de toute une organisation. Va voir la documentation officielle pour tester ces patterns d'intégration hands-on, ou visite DEV STORIES DOT EU pour suggérer des sujets pour les prochaines séries. Merci d'avoir passé quelques minutes avec moi. À la prochaine, et prends soin de toi.