NVIDIA NeMo Guardrails

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 1 di 10. Non collegheresti mai un database raw direttamente a internet, eppure molte applicazioni espongono language model senza vincoli direttamente agli utenti finali. Affidarsi esclusivamente a un system prompt per mantenere la sicurezza è un'architettura fragile. Oggi parliamo dell'imperativo degli AI Guardrails: Core Abstractions. NeMo Guardrails funge da layer intermedio programmabile che si interpone tra la tua applicazione utente e il language model. Non sostituisce il tuo modello. Piuttosto, crea una pipeline separata di controlli di sicurezza discreti chiamati rails. Invece di implorare il modello di comportarsi bene attraverso del complesso prompt engineering, tu orchestri la sicurezza tramite questo layer deterministico. Pensa a un bot per l'assistenza clienti. Un utente invia un messaggio, il sistema recupera gli articoli di supporto pertinenti, il modello elabora una risposta e potrebbe attivare un'azione di backend, come l'elaborazione di un rimborso. Hai bisogno di diversi tipi di protezione in ogni fase. Per gestire tutto questo, Guardrails definisce cinque tipi distinti di rails. Innanzitutto, il messaggio dell'utente arriva all'Input Rail. Questo rail ispeziona il testo prima ancora che il language model principale lo veda. Se un utente tenta un attacco di prompt injection o invia un testo altamente tossico, l'Input Rail intercetta immediatamente il messaggio. Ferma la pipeline e restituisce un rifiuto predefinito. Il modello principale non elabora mai il testo malevolo, risparmiando compute e prevenendo un exploit. Se l'input è sicuro, il sistema valuta i Dialog Rails. Questi gestiscono il flusso previsto della conversazione. Se un utente chiede al bot di supporto un'opinione su un competitor, un Dialog Rail identifica il topic. Forza il bot a seguire un percorso predeterminato, magari rispondendo che discute solo dei propri prodotti. I Dialog Rails impediscono al modello di andare off-topic o di rispondere a domande che non gli competono. Successivamente, quando il tuo bot cerca nella tua knowledge base per fare grounding della sua risposta, entrano in gioco i Retrieval Rails. Questi ispezionano i chunk di testo estratti dal database prima che vengano accodati al prompt del modello. Se una ricerca configurata male seleziona accidentalmente un documento interno delle risorse umane invece di un manuale pubblico, il Retrieval Rail rileva le informazioni sensibili e le rimuove dalla context window. Se la conversazione richiede al bot di eseguire un task, intervengono gli Execution Rails. Questi controllano quali azioni custom il modello è autorizzato ad attivare. Quando il modello richiede di eseguire del codice o di chiamare un tool esterno, l'Execution Rail verifica se quella specifica azione è consentita dato lo stato attuale della conversazione. Blocca l'esecuzione di comandi non autorizzati. Infine, abbiamo gli Output Rails. Questa è l'ultima linea di difesa. Dopo che il modello ha generato una risposta, l'Output Rail valuta il testo prima che raggiunga l'utente. Controlla la presenza di fatti allucinati, tono inappropriato o leak di dati sensibili. Se il testo non supera il controllo, l'Output Rail lo intercetta e altera o blocca il messaggio finale. Questa architettura cambia radicalmente il modo in cui costruisci applicazioni generative. Smetti di affidarti a un motore probabilistico per controllare il proprio comportamento, e costruisci invece una rete di sicurezza deterministica che controlla input, logica e output in modo indipendente. A proposito, se trovi utili questi episodi e vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a costruire!

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 2 di 10. Scrivere Python puro per gestire state machine complesse e ramificate per i dialoghi è un vero incubo. Nel momento in cui il tuo utente si discosta da uno script rigido, la tua logica hardcoded salta. L'architettura di configurazione in NeMo Guardrails risolve questo problema trattando le conversazioni come flow event-driven anziché come codice statico. NeMo Guardrails separa la meccanica della tua applicazione dalla logica della tua conversazione. Questo avviene attraverso due elementi di configurazione distinti. Per prima cosa, hai il tuo file di configurazione YAML. Questo gestisce tutto il wiring del modello. È qui che dichiari il tuo language model principale, definisci i tuoi modelli di embedding e registri le action personalizzate dell'applicazione. Il file YAML connette l'infrastruttura sottostante. Fornisce il motore, ma non sa assolutamente nulla di ciò che l'utente dirà effettivamente. La logica di conversazione vera e propria è gestita da Colang 2.0. Colang è un linguaggio di modellazione delle interazioni event-driven. Invece di scrivere codice imperativo standard con infiniti statement condizionali per tenere traccia di dove si trova l'utente in una conversazione, definisci dei flow. Un flow modella una sequenza di interazioni. Quando un utente invia un messaggio, genera un evento. La state machine cattura questo evento, cerca un flow attivo che faccia match con l'interazione e detta la mossa successiva dell'assistente. Questa è la parte che conta. Colang usa le Natural Language Description per colmare il divario tra il codice rigoroso e l'ambiguità umana. Invece di scrivere complesse regular expression per parsare un messaggio dell'utente, istruisci il sistema usando il linguaggio umano direttamente all'interno della logica del tuo flow. Abbini queste descrizioni al generation operator, che si scrive semplicemente come tre punti. Quando la state machine incontra quei tre punti, mette temporaneamente in pausa l'esecuzione. Passa il contesto corrente e la tua natural language description al language model sottostante, chiedendogli di generare o estrarre il valore esatto di cui hai bisogno. Guardiamo uno scenario concreto come la prenotazione di un biglietto aereo. Devi sapere quando l'utente vuole viaggiare. Nel tuo file Colang, definisci un flow di prenotazione del volo. All'interno di quel flow, dici al sistema di aspettare che l'utente parli. Una volta che lo fa, devi estrarre la data. Dichiari una variabile di contesto, magari chiamata flight date. Le assegni il valore di una natural language description, scrivendo letteralmente la frase "the date the user wants to fly", seguita immediatamente dal generation operator, quei tre punti. Quando l'utente dice "Ho bisogno di un biglietto per martedì prossimo", la state machine di Colang cattura l'evento. Incontra l'assegnazione della tua variabile. Passa il messaggio dell'utente e la tua istruzione in natural language al language model. Il modello legge il contesto, identifica "martedì prossimo" come valore target e lo restituisce. Il generation operator si risolve, e la tua variabile di contesto ora contiene in modo sicuro la data estratta. Il tuo flow procede quindi allo step successivo, che potrebbe comportare la chiamata a un'API di prenotazione esterna definita nella tua configurazione YAML. Il vero potere di questa architettura è che smetti di combattere con gli stati del dialogo usando codice rigido. Lasci che un file YAML blocchi l'infrastruttura statica, e lasci che Colang usi la capacità di ragionamento del language model per navigare la realtà imprevedibile della conversazione umana. Voglio prendermi un momento per ringraziarti per l'ascolto: ci aiuta tantissimo. Buona giornata!

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 3 di 10. Affidarsi a un enorme modello da settanta miliardi di parametri per fare la moderazione di base dei contenuti è un enorme spreco di compute. È lento, costoso e toglie potenza di calcolo alla generazione delle risposte vere e proprie. La soluzione è la Content Safety specializzata con Nemotron NIM. Invece di chiedere al tuo modello applicativo principale sia di scrivere codice che di controllare la tossicità, suddividi il carico di lavoro. Il modello principale gestisce il ragionamento complesso e la generazione. Un secondo modello, molto più piccolo, si occupa della sicurezza. Nello specifico, stiamo guardando Llama 3 punto 1 Nemotron Safety Guard 8B V3. È un modello da otto miliardi di parametri fine-tuned interamente per un solo compito, ovvero valutare la content safety. Gira come microservizio standalone, o NIM, che NeMo Guardrails richiama tramite un'API. Per configurarlo, definisci il Nemotron NIM nella tua configurazione di Guardrails come un modello distinto. Etichetti il suo type come content safety, mentre il tuo modello primario rimane il type main. Questa distinzione è fondamentale perché Guardrails instrada il traffico in modo diverso in base a queste label. Una volta configurato, attivi la safety guard come input rail e output rail. Quando un utente invia un prompt, Guardrails lo intercetta prima ancora che raggiunga il tuo modello principale. Invia il prompt al NIM di sicurezza Nemotron. Il NIM valuta il testo confrontandolo con ventitré categorie specifiche di contenuti unsafe. Queste categorie coprono di tutto, dall'hate speech e la violenza, fino ai contenuti sessuali e alla pianificazione criminale. Considera un'applicazione multilingua dove un utente invia un prompt in francese, chiedendo istruzioni passo passo su come far partire un'auto facendo i contatti. L'input rail lo intercetta. Guardrails spedisce il testo in francese al NIM Nemotron. Dato che il modello di sicurezza è addestrato su dati di sicurezza multilingua, capisce l'intento a prescindere dalla lingua. Flagga la richiesta come appartenente alla categoria criminal advice e restituisce un segnale unsafe a Guardrails. A quel punto Guardrails interrompe immediatamente il processo e restituisce un messaggio di rifiuto standard all'utente. Il tuo modello principale non vede nemmeno il prompt, risparmiandoti il costo di inferenza per l'elaborazione di una richiesta tossica. L'esatta stessa logica si applica al contrario per gli output rail. Se un prompt apparentemente innocuo in qualche modo inganna il modello principale facendogli generare una risposta unsafe, Guardrails intercetta quel testo generato prima che raggiunga l'utente. Invia l'output al NIM di sicurezza, lo controlla rispetto a quelle stesse ventitré categorie e lo blocca se viola le regole. Configurare tutto questo richiede di aggiornare i tuoi file di configurazione. Dichiari il modello Nemotron nella tua lista dei modelli, puntandolo al tuo endpoint NIM. Poi, abiliti i flow di default self-check input e self-check output, dicendo esplicitamente a Guardrails di usare il tuo modello di content safety per questi controlli. Non hai bisogno di scrivere prompt custom per istruire il modello su come valutare la tossicità. Il modello Nemotron si aspetta un formato di prompt molto specifico per valutare il testo, e NeMo Guardrails formatta quella chiamata API automaticamente dietro le quinte. Ti basta puntare i rail verso il NIM e lasciargli fare la classificazione. Disaccoppiare la tua logica di moderazione in un modello dedicato e più piccolo assicura che il tuo modello applicativo primario impieghi i suoi cicli a generare valore, mentre una guard specializzata gestisce in modo efficiente la sicurezza perimetrale. Questo è tutto per questo episodio. Grazie per l'ascolto, e continuate a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 4 di 10. Il modo più semplice per evitare che il tuo chatbot crei un disastro di pubbliche relazioni è assicurarti che si rifiuti semplicemente di parlare del disastro. Non puoi fare affidamento su un language model general-purpose per rifiutare in modo affidabile ogni topic irrilevante o rischioso da solo. Ecco perché usiamo l'Enforcing Domain Boundaries con il Topic Control. I language model general-purpose sono sempre pronti ad accontentarti. Se un utente fa una domanda intelligente, il modello cercherà di rispondere. Se crei un bot di customer service, vuoi che parli solo di customer service. Hai bisogno di un boundary rigoroso. Per creare questo boundary, usi il NIM Llama 3.1 NemoGuard 8B TopicControl. È un modello specializzato, progettato per un task specifico. Non genera risposte conversazionali. Valuta. Prendi ad esempio un bot di supporto telefonico. Il suo compito è aiutare gli utenti con bollette telefoniche, disservizi di rete e piani dati. Un utente si connette alla chat e chiede al bot un'opinione su una recente elezione politica. Senza guardrail, il tuo modello principale riceve il prompt, lo elabora e potrebbe generare una risposta inappropriata. Con NeMo Guardrails, configuri un Input Rail. Un Input Rail intercetta la request dell'utente prima che succeda qualsiasi altra cosa. Il language model principale non vede nemmeno la request. Quando l'utente fa una domanda sulle elezioni, il guardrail instrada l'input direttamente al modello TopicControl. Controlli il comportamento di questo modello definendo delle linee guida rigorose all'interno del suo system prompt. Per il tuo bot telefonico, il tuo system prompt stabilisce che i topic accettabili sono la fatturazione, lo stato della rete e la gestione dell'account. Il modello TopicControl prende il prompt dell'utente e lo valuta rispetto a quelle esatte linee guida. Quindi restituisce in output una classificazione rigida. Restituisce una valutazione on-topic o off-topic. Se l'utente chiede perché i suoi costi di roaming sono alti, il modello TopicControl legge il prompt, controlla le linee guida e restituisce on-topic. Il guardrail apre il cancello e il prompt dell'utente passa al tuo modello conversazionale principale per generare una risposta utile. Quando l'utente fa domande sulle elezioni politiche, il modello TopicControl valuta il prompt rispetto alle linee guida delle telecomunicazioni. Riconosce l'incongruenza e restituisce off-topic. Il guardrail interrompe immediatamente la pipeline. Impedisce alla request di raggiungere il tuo modello principale. Invece, il guardrail attiva una risposta di rifiuto statica e predefinita. Il bot dice all'utente che è equipaggiato solo per gestire servizi di telecomunicazione. Usare un modello dedicato per il topic control separa la logica di valutazione dalla logica conversazionale. Non sprechi costosi cicli di compute chiedendo a un enorme modello general-purpose di capire se è autorizzato a rispondere a una domanda. Usi un modello più piccolo e altamente ottimizzato da otto miliardi di parametri per fare da buttafuori all'ingresso. Questo mantiene i tuoi domain boundaries rigorosamente rispettati senza richiedere un prompt engineering complesso e fragile sul tuo modello principale. Il modo più sicuro per gestire una request out-of-bounds è assicurarti che il tuo reasoning engine principale rimanga completamente all'oscuro del fatto che la request sia mai stata fatta. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 5 di 10. Se il tuo sistema di retrieval-augmented generation acquisisce un database dei dipendenti non anonimizzato, hai già commesso una violazione di compliance prima ancora che il language model generi una singola parola. Una volta che i dati sensibili entrano nel context del prompt, perdi il controllo su dove vanno a finire. La Dynamic PII Detection and Masking è il modo in cui intercetti questi dati in transito. Prendiamo ad esempio un bot interno per le risorse umane. Un manager fa al bot una domanda generale sulla policy aziendale di valutazione delle performance. Il bot cerca nella knowledge base interna. La ricerca restituisce il documento di policy pertinente, ma i chunk di testo recuperati includono accidentalmente un record specifico di un dipendente accodato al file, completo di nome, indirizzo di casa ed email. Se il sistema passa questi chunk recuperati direttamente al language model, quei dati sensibili diventano parte della context window. NeMo Guardrails gestisce questo problema posizionandosi tra i componenti della tua applicazione e filtrando lo stream di testo. Offre due approcci distinti. La detection prevede l'identificazione delle personally identifiable information e l'esecuzione di un'azione drastica, come bloccare completamente il prompt o lanciare un errore. Il masking è più flessibile. Individua le informazioni sensibili e le sostituisce al volo con un placeholder generico. Il testo john@example.com diventa una string tra parentesi quadre con scritto EMAIL. Il database sottostante rimane completamente inalterato. Per eseguire tutto questo, il sistema di guardrails si basa su tool esterni specializzati. Configuri il framework per chiamare un engine come Microsoft Presidio o GLiNER. Presidio utilizza in genere il pattern matching, le regular expression e una logica rule-based per individuare formati standard come numeri di telefono o carte di credito. GLiNER, acronimo di Generalist and Lightweight Indicator for Named Entity Recognition, utilizza un piccolo modello di machine learning per identificare le entità in base al contesto circostante. Definisci un array di tipi di entità che ti interessano, e l'engine selezionato si occupa dell'estrazione. Questa protezione opera in tre punti specifici del flow dell'applicazione. Il primo è l'input rail. Se un utente digita il proprio codice fiscale nella finestra di chat, l'input rail scansiona la string in arrivo e maschera il numero prima ancora che il language model riceva il prompt. Il modello elabora la request utilizzando il placeholder, completamente all'oscuro del numero effettivo. Il secondo punto è il retrieval rail. Questa è la parte che conta. Quando il tuo sistema interroga un vector database e recupera chunk di testo grezzo, il guardrail intercetta quei chunk prima che vengano iniettati nel prompt template finale. Scansiona il testo recuperato, rimuove i nomi e gli indirizzi reali e li sostituisce con i tag mascherati. Il tuo meccanismo di retrieval può attingere a fonti di dati disordinate e non anonimizzate, ma il language model è protetto dai dettagli sensibili. Il terzo punto è l'output rail. Se il language model genera dati sensibili, producendo un'allucinazione o perché un dato è in qualche modo sfuggito ai rail precedenti, l'output rail funge da checkpoint finale. Scansiona la risposta generata e maschera il testo sensibile prima che raggiunga lo schermo dell'utente. Poiché tutto questo avviene dinamicamente in memoria durante l'esecuzione di una singola request, la tua architettura dati non deve cambiare. Eviti l'enorme overhead ingegneristico di mantenere database duplicati e pre-anonimizzati solo per far girare un'applicazione di chat. Il modo più sicuro per gestire i dati sensibili in un'applicazione basata su language model è assicurarsi che il modello non esegua mai calcoli sui dati effettivi fin dal principio. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 6 di 10. Alcuni degli attacchi di prompt injection più devastanti non sembrano affatto astuti trucchi di ingegneria sociale. A un essere umano, sembrano semplicemente del testo completamente senza senso. L'utente non sta cercando di ingannare il bot con un indovinello, ma piuttosto di sovraccaricarlo matematicamente. Intercettare questo attacco richiede la Jailbreak Detection tramite Perplexity Heuristics. Consideriamo uno scenario di attacco specifico. Un utente malintenzionato vuole che la tua applicazione generi un output dannoso, ma sa che hai delle istruzioni di sicurezza nel tuo system prompt. Per aggirare queste istruzioni, prende la sua richiesta dannosa e applica un padding con una stringa enorme di caratteri casuali, simboli oscuri o parole senza senso. Quando il language model elabora questo input, i meccanismi di attention vengono trascinati giù dall'enorme volume di token imprevedibili. Il modello perde traccia del suo safety alignment di base e risponde semplicemente alla richiesta dannosa. Non puoi intercettare questo attacco con i classici filtri basati su keyword, perché il padding è casuale. Potresti usare un altro language model per valutare il prompt in entrata alla ricerca di adversarial pattern, ma questo aggiunge un'enorme penalità di latenza a ogni singola richiesta dell'utente. Hai bisogno di un filtro veloce, matematico e che giri in locale. È qui che entra in gioco la perplexity. La perplexity è una metrica standard che misura quanto un pezzo di testo sia prevedibile per un language model. Le normali frasi umane seguono pattern prevedibili, risultando in una perplexity bassa. Una stringa di caratteri casuali, o una bizzarra sequenza di parole non correlate, è altamente imprevedibile. Questo genera una perplexity alta. Calcolando la perplexity di un prompt in entrata, ottieni una misura statistica della sua casualità. NeMo Guardrails usa questo concetto per bloccare gli attacchi gibberish attraverso due euristiche principali. La prima è Length per Perplexity. Gli adversarial attack di solito richiedono una lunga stringa di testo spazzatura per mandare in tilt il modello principale. Una breve stringa senza senso viene tipicamente ignorata dall'attention mechanism. Questa euristica calcola un rapporto usando la lunghezza totale del prompt e il suo perplexity score complessivo. Se un prompt è insolitamente lungo e altamente imprevedibile, supera una soglia matematica predefinita. Il guardrail intercetta l'input, lo flagga come potenziale jailbreak e blocca la richiesta prima ancora che il tuo modello principale lo veda. La seconda euristica gestisce una variante più chirurgica dello stesso attacco. A volte un attaccante nasconde il gibberish. Scrive una frase completamente normale e a bassa perplexity nel mezzo del prompt, ma appende un blocco denso di token casuali proprio alla fine. Se calcoli la perplexity sull'intero prompt, il testo normale potrebbe diluire il punteggio medio abbastanza da eludere il primo filtro. Per contrastare questo problema, NeMo Guardrails usa la Prefix e Suffix Perplexity. Invece di guardare l'intero prompt, questa euristica isola un numero fisso di token proprio all'inizio e proprio alla fine dell'input dell'utente. Calcola la perplexity di questi boundary in modo indipendente. Se l'utente attacca un adversarial payload di caratteri casuali alla fine di una domanda normale, il punteggio di suffix perplexity schizza alle stelle. Il guardrail rileva l'anomalia al boundary e scarta la richiesta. Questo intero processo avviene senza fare una chiamata API esterna verso un language model enorme. Si affida a un modello locale più piccolo per calcolare i perplexity score, il che mantiene l'overhead di latenza al minimo assoluto. Eliminando il significato semantico del testo, smetti di analizzare cosa l'utente sta cercando di dire e inizi ad analizzare la forma matematica delle sue parole. Le euristiche di perplexity ti permettono di bloccare adversarial attack complessi usando statistiche pure, mettendo in sicurezza la tua applicazione alla velocità della matematica. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 7 di 10. Dare a un language model l'accesso per eseguire query sul database è come dare le chiavi del tuo database a uno sconosciuto. Dici al modello di recuperare i dati utente, ma un prompt astuto lo inganna e gli fa aggiungere un comando per fare il drop di una tabella. Mettere in sicurezza gli agentic workflow con gli execution rails è il modo in cui impedisci agli agenti autonomi di compromettere il tuo backend. La maggior parte dei guardrails si concentra sulla risposta in chat. Impediscono al modello di usare un linguaggio inappropriato o di andare fuori tema. Gli execution rails fanno qualcosa di completamente diverso. Proteggono i tool che l'agente utilizza. Quando un agente decide di usare un tool per lanciare uno script Python generato o eseguire una query SQL, l'execution rail intercetta il payload esattamente nel punto di handoff, un attimo prima che il tool venga effettivamente eseguito. NeMo Guardrails gestisce questa validazione usando le YARA rules. YARA è un pattern-matching engine tradizionalmente usato dagli analisti di cybersecurity per identificare malware basandosi su specifiche signature testuali o binarie. In questo framework, NVIDIA fornisce un catalogo predefinito di pattern YARA creati appositamente per intercettare le vulnerabilità dei language model. Il guardrails engine passa l'input del tool attraverso queste YARA rules per cercare signature di attacco note. Questo catalogo punta a quattro minacce specifiche. La prima è la SQL injection, dove il modello genera comandi per il database contenenti modifiche malevole. La seconda è la code injection, dove l'agente tenta di eseguire comandi di sistema non autorizzati all'interno di uno script Python generato dinamicamente. La terza è la template injection, dove un attaccante manipola i server-side rendering engine. Infine, rileva il cross-site scripting, bloccando i payload progettati per eseguire script malevoli in un web browser. Considera un agente incaricato di prendere una richiesta utente, scrivere uno script Python per elaborare dei dati locali e lanciarlo. Se un utente nasconde un comando di sistema per esporre le variabili d'ambiente all'interno del suo prompt, il language model potrebbe includere ciecamente quel comando nello script Python finale. L'execution rail intercetta tutto questo. Scansiona il codice Python generato, trova un match con la YARA rule per la code injection e flagga il payload prima ancora che l'execution engine lo veda. Quando il sistema rileva un pattern malevolo, agisce in base alla tua configurazione. Hai due scelte. La prima azione è reject. Questo blocca completamente l'esecuzione del tool. Il workflow si ferma, il codice malevolo non viene mai eseguito e il sistema restituisce una risposta sicura. La seconda azione è omit. Questo dice al guardrail di rimuovere la specifica string malevola dal payload, ma permette al tool di eseguire tutto ciò che rimane. Scegliere tra reject e omit dipende interamente dal tool. Se il tuo agente sta eseguendo una query SQL su un database, reject è l'unica scelta sicura. Omettere una string da una query SQL complessa porterà probabilmente a una sintassi malformata o a un accesso ai dati imprevedibile. Omit è generalmente riservato ai task di elaborazione del testo di base, dove la rimozione di una string malevola lascia comunque un payload utilizzabile e sicuro. Configuri queste protezioni direttamente nei tuoi file YAML abilitando gli agentic security rails e mappandoli a tool specifici. Il YARA engine sottostante fa il lavoro sporco, trovando i match con i pattern predefiniti senza richiederti di scrivere regular expression custom. Gli execution rails trattano il language model come un utente non fidato, costringendoti a validare ogni singolo comando che genera prima che tocchi la tua infrastruttura. Grazie per l'ascolto, happy coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 8 di 10. Un bot che dice di non conoscere la risposta è leggermente fastidioso. Un bot finanziario che dichiara con sicurezza che la tua azienda ha mancato l'obiettivo di fatturato del terzo trimestre di cinquanta milioni di dollari, quando in realtà lo ha superato, è un disastro. Per impedire al tuo sistema Retrieval-Augmented Generation di inventare numeri e distruggere la tua credibilità, hai bisogno di Grounding RAG: Hallucinations and Fact-Checking. Chiariamo subito un equivoco comune. Il fact-checking e l'hallucination detection sono due cose diverse. L'hallucination detection in genere prevede di fare al modello linguistico la stessa domanda più volte. Se i sample risultanti si contraddicono a vicenda, è probabile che il modello stia avendo un'allucinazione. Il fact-checking valuta una singola risposta generata confrontandola con un set specifico di documenti affidabili. NeMo Guardrails usa il fact-checking per mantenere le tue pipeline RAG grounded. I modelli linguistici predicono il testo. Non sanno intrinsecamente cosa sia vero. In un setup RAG standard, recuperi dei chunk di testo dal tuo database, li passi al modello e gli chiedi di rispondere basandosi esclusivamente su quel testo. A volte il modello ha comunque delle allucinazioni, mescolando la sua conoscenza pre-addestrata con i tuoi dati, o semplicemente inventando una metrica che suona plausibile. NeMo Guardrails ferma tutto questo usando un output rail chiamato self check facts. Quando è attivo, questo rail intercetta la risposta generata dal modello prima che arrivi all'utente. Il sistema tratta questa risposta non verificata come un'ipotesi. Poi recupera gli esatti snippet di testo che sono stati estratti dal tuo database. Questi snippet vengono salvati automaticamente in una context variable chiamata relevant chunks. Questa variabile è la prova schiacciante. Il guardrail esegue quindi una valutazione. Passa l'ipotesi e la prova a un modello evaluator. L'evaluator verifica se la prova implica strettamente l'ipotesi. Tornando al nostro bot finanziario, se il testo generato dichiara un numero di fatturato specifico, ma quel numero non esiste da nessuna parte nella variabile relevant chunks, l'evaluator lo flagga come ungrounded. Il guardrail blocca immediatamente la risposta allucinata. Al suo posto, restituisce un messaggio di fallback sicuro, ammettendo di non avere abbastanza informazioni. Usare un modello linguistico general purpose per fare fact-checking è facile da configurare, ma ha un costo. Aggiunge latenza, brucia token e il modello evaluator a volte può confondersi con un contesto denso. Non sei obbligato a usare il setup di default. Puoi sostituire il controllo standard basato su prompt con tool esterni specializzati. Approcci che usano modelli come AlignScore o Patronus Lynx sono molto efficaci in questo caso. Sono modelli creati appositamente, addestrati esclusivamente per rilevare le incongruenze tra un testo sorgente e un'affermazione generata. Quando instradi i relevant chunks e l'ipotesi attraverso uno di questi modelli specializzati, bypassi completamente l'evaluator del modello linguistico standard. Questo fornisce un verdetto più veloce, più economico e spesso più rigoroso sul fatto che il tuo bot stia dicendo la verità. Questa è la parte che conta. Fare il grounding di una pipeline RAG non significa rendere il tuo modello generativo intrinsecamente più veritiero. Significa trattare ogni singola parola generata come un'affermazione sospetta che deve sopravvivere a un rigoroso esame incrociato con i tuoi esatti dati sorgente prima di vedere la luce del giorno. Se vuoi aiutarci a continuare a fare questi episodi, puoi supportare lo show cercando DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 9 di 10. Passi settimane a calibrare i tuoi filtri di input per bloccare i prompt di testo dannosi. Poi un utente aggira tutto il tuo duro lavoro semplicemente facendo uno screenshot del suo prompt dannoso e caricandolo come immagine. I filtri di testo sono completamente ciechi di fronte a questo. Per intercettarlo, hai bisogno della Multimodal Content Safety. Immagina un utente che carica la foto di un fucile d'assalto personalizzato e digita la domanda, come posso modificarlo per farlo sparare più velocemente. Un normale guardrail di testo vede solo una richiesta di modifica di un oggetto generico. Non ha idea che l'oggetto sia un'arma. L'intento dannoso esiste solo quando combini l'immagine e il testo. Gestiamo questo problema usando un Vision Language Model che agisce come LLM-as-a-judge. In NeMo Guardrails, lo configuri nella fase di input rail. Prima ancora che la richiesta dell'utente raggiunga il tuo modello conversazionale principale, il guardrail intercetta il payload multimodale. I dati dell'immagine di solito arrivano in uno di questi due formati. O è una stringa codificata in Base64 incorporata direttamente nella chiamata API, o è un URL diretto. Le stringhe Base64 rendono il payload della richiesta immediata molto più grande, ma garantiscono che l'immagine sia disponibile. Gli URL mantengono il payload iniziale leggero, ma richiedono che il modello di valutazione abbia accesso alla rete in uscita per recuperare il file. In entrambi i casi, configuri l'input rail con uno specifico prompt template progettato per la valutazione multimodale. Questo template contiene una rigida griglia di sicurezza che definisce le categorie di contenuti non sicuri, come violenza, atti illegali, autolesionismo o armi. Il guardrail costruisce una richiesta di valutazione. Impacchetta la tua griglia di sicurezza, il testo dell'utente e l'immagine dell'utente. Invia questo pacchetto combinato al vision model e forza il modello a rispondere con un output strutturato, in genere una semplice etichetta safe o unsafe. Il modello agisce strettamente come un giudice. Analizza l'arma nella foto, legge la richiesta su come modificarla e verifica il significato combinato rispetto alle tue categorie limitate. Se il vision model rileva una violazione, restituisce un verdetto unsafe. L'input rail segnala la richiesta, le impedisce di procedere e innesca un messaggio di rifiuto predefinito. Il tuo modello applicativo principale non vede nemmeno la richiesta dannosa. Fai attenzione a questa parte che riguarda i limiti di contesto. I vision model elaborano le immagini convertendole in token. A seconda dell'architettura del modello e della risoluzione dell'immagine, una singola immagine può consumare migliaia di token. La tua stringa Base64 o l'URL dell'immagine, combinati con il testo dell'utente e la tua griglia di sicurezza multicategoria, devono rientrare interamente nella context window del vision model. Se passi immagini enormi e ad alta risoluzione insieme a un prompt di testo lungo, supererai il limite di token. La valutazione del guardrail fallirà, oppure il modello troncherà l'input e si perderà completamente la violazione. Devi implementare un preprocessing per ridimensionare o comprimere le immagini prima che raggiungano il guardrail, mantenendo prevedibile l'impronta dei token. Valutare testo e immagini separatamente non è più sufficiente, perché gli abusi moderni si nascondono esattamente nello spazio in cui queste due modalità si intersecano. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 10 di 10. Costruire regole di sicurezza direttamente dentro uno script Python è ottimo per i test, ma pessimo per scalare in un'azienda poliglotta. Se il tuo frontend usa Node JS e il tuo backend è un mix di Python e Go, non puoi duplicare la tua logica di sicurezza in ogni linguaggio. La soluzione è usare i tre pattern di integrazione enterprise per NeMo Guardrails. Prendiamo uno scenario di migrazione standard. Hai creato un prototipo di bot per il customer service usando LangChain. Hai aggiunto dei guardrails per impedirgli di parlare dei competitor. Funziona perfettamente sul tuo laptop. Ora devi migrare questo prototipo in un'architettura a microservizi scalabile in produzione, dove più applicazioni lo interrogheranno. Hai tre modi principali per integrare i guardrails per farlo. Il primo metodo è l'SDK Python nativo, nello specifico un oggetto chiamato LLMRails. Questo è il core engine. Se stai creando un backend Python custom da zero senza affidarti a framework di orchestrazione, usi questo. Istanzi LLMRails, lo punti alla tua directory di configurazione contenente i tuoi file Colang e YAML, e lo usi per processare gli input. Passi una lista di dizionari di messaggi che rappresentano la history della conversazione, e lui ti restituisce la risposta valutata. È diretto e ti dà accesso raw alle meccaniche sottostanti dei guardrails. Dato che hai già un prototipo in LangChain, riscrivere tutto per usare l'SDK raw è uno sforzo inutile. È qui che entra in gioco il secondo metodo, ovvero l'integrazione con LangChain usando RunnableRails. NeMo Guardrails si integra nativamente nel LangChain Expression Language. Crei un'istanza di RunnableRails caricata con la tua configurazione e la attacchi direttamente alla tua chain esistente. Se la tua chain prende un prompt, recupera documenti e chiama un language model, wrappi l'intero flusso con il runnable del guardrail. Il guardrail intercetta l'input prima che arrivi alla tua chain e valuta l'output dopo che la tua chain ha generato una risposta. Il codice core della tua applicazione cambia a malapena, ma la tua logica LangChain ora è protetta. Questa è la parte che conta su larga scala. Considera l'azienda nel suo complesso. Un altro team vuole usare esattamente le tue stesse policy di sicurezza, ma sta sviluppando un web gateway in Node JS o un router ad alte prestazioni in Go. Non possono importare un oggetto LangChain in Python. Per questo, usi il terzo metodo, l'API Server standalone. NeMo Guardrails include un server built-in che puoi lanciare da riga di comando o deployare come container. Avvii il server e lo punti alla tua cartella di configurazione. Espone immediatamente degli endpoint REST che replicano le API standard di OpenAI. Per le tue applicazioni Go o Node JS, il server dei guardrails sembra esattamente un language model standard. Inviano richieste JSON standard all'endpoint di chat completions. Il server gestisce gli input guardrails, comunica con il modello sottostante effettivo, processa gli output guardrails e restituisce il testo pulito. Disaccoppiare le tue regole dalla logica della tua applicazione usando un server standalone è l'unico modo affidabile per applicare policy di sicurezza coerenti in tutta l'organizzazione. Dai un'occhiata alla documentazione ufficiale per provare questi pattern di integrazione hands-on, oppure visita DEV STORIES DOT EU per suggerire argomenti per le serie future. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.