NVIDIA NeMo Guardrails

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 1 din 10. Nu ai conecta niciodată o bază de date raw direct la internetul public, însă multe aplicații expun modele de limbaj neconstrânse direct utilizatorilor finali. Să te bazezi exclusiv pe un system prompt pentru a menține securitatea este o arhitectură fragilă. Astăzi discutăm despre imperativul AI Guardrails: abstracții de bază. NeMo Guardrails acționează ca un strat intermediar programabil situat între aplicația ta și modelul de limbaj. Nu înlocuiește modelul. În schimb, creează un pipeline separat de verificări de siguranță discrete, numite rails. În loc să te rogi de model să se comporte cum trebuie printr-un prompt engineering complex, orchestrezi siguranța prin acest strat determinist. Gândește-te la un bot de customer service. Un utilizator trimite un mesaj, sistemul aduce articole de suport relevante, modelul redactează un răspuns și ar putea declanșa o acțiune de backend, cum ar fi procesarea unui refund. Ai nevoie de diferite tipuri de protecție în fiecare etapă. Pentru a gestiona acest lucru, Guardrails definește cinci tipuri distincte de rails. În primul rând, mesajul utilizatorului ajunge la Input Rail. Acest rail inspectează textul înainte ca modelul de limbaj principal să-l vadă vreodată. Dacă un utilizator încearcă un atac de prompt injection sau trimite un text foarte toxic, Input Rail-ul interceptează imediat mesajul. Oprește pipeline-ul și returnează un refuz predefinit. Modelul principal nu procesează niciodată textul malițios, economisind compute și prevenind un exploit. Dacă input-ul este sigur, sistemul evaluează Dialog Rails. Acestea gestionează flow-ul așteptat al conversației. Dacă un utilizator îi cere botului de suport o părere despre un competitor, un Dialog Rail identifică subiectul. Forțează botul să urmeze o rută predeterminată, poate răspunzând că discută doar despre propriile produse. Dialog Rails împiedică modelul să devieze de la subiect sau să răspundă la întrebări care nu îl privesc. Apoi, când botul tău caută în knowledge base pentru a-și fundamenta răspunsul, Retrieval Rails preiau controlul. Acestea inspectează chunk-urile de text extrase din baza de date înainte să fie adăugate la prompt-ul modelului. Dacă un search configurat greșit trage accidental un document intern de resurse umane în loc de un manual public, Retrieval Rail-ul detectează informațiile sensibile și le elimină din context window. Dacă conversația cere ca botul să execute un task, intervin Execution Rails. Acestea controlează ce acțiuni custom are voie modelul să declanșeze. Când modelul cere să execute cod sau să apeleze un tool extern, Execution Rail-ul verifică dacă acea acțiune specifică este permisă, având în vedere starea curentă a conversației. Blochează execuția comenzilor neautorizate. În cele din urmă, avem Output Rails. Aceasta este ultima linie de apărare. După ce modelul generează un răspuns, Output Rail-ul evaluează textul înainte să ajungă la utilizator. Verifică dacă există halucinații, un ton nepotrivit sau scurgeri de date sensibile. Dacă textul pică verificarea, Output Rail-ul îl interceptează și modifică sau blochează mesajul final. Această arhitectură schimbă fundamental modul în care construiești aplicații generative. Nu te mai bazezi pe un motor probabilistic ca să-și controleze propriul comportament, ci construiești o plasă de siguranță deterministă care controlează independent input-urile, logica și output-urile. Apropo, dacă ți se par utile aceste episoade și vrei să susții podcastul, poți căuta DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mersi că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 2 din 10. Să scrii cod Python raw pentru a gestiona state machines complexe, cu dialog ramificat, este un coșmar absolut. În momentul în care userul deviază de la un script rigid, logica ta hardcoded crapă. Arhitectura de configurare din NeMo Guardrails rezolvă asta tratând conversațiile ca flow-uri event-driven, în loc de cod static. NeMo Guardrails separă mecanica aplicației tale de logica conversației. Asta se întâmplă prin două componente distincte de configurare. În primul rând, ai fișierul tău de configurare YAML. Acesta se ocupă de tot wiring-ul modelului. Aici îți declari language model-ul principal, îți definești embedding models și înregistrezi acțiuni custom pentru aplicație. Fișierul YAML conectează infrastructura din spate. El oferă motorul, dar nu știe absolut nimic despre ce va spune userul de fapt. Logica propriu-zisă a conversației este guvernată de Colang 2.0. Colang este un limbaj de modelare a interacțiunilor de tip event-driven. În loc să scrii cod imperativ standard, cu instrucțiuni condiționale nesfârșite ca să urmărești unde se află userul într-o conversație, definești flow-uri. Un flow modelează o secvență de interacțiuni. Când un user trimite un mesaj, se generează un event. State machine-ul prinde acest event, caută un flow activ care face match cu interacțiunea și dictează următoarea mișcare a asistentului. Asta e partea care contează. Colang folosește Natural Language Descriptions pentru a acoperi prăpastia dintre codul strict și ambiguitatea umană. În loc să scrii regular expressions complexe pentru a face parse la un mesaj de la user, instruiești sistemul folosind limbaj uman direct în logica flow-ului tău. Asociezi aceste descrieri cu generation operator, care este scris pur și simplu ca trei puncte. Când state machine-ul întâlnește acele trei puncte, pune pe pauză temporar execuția. Pasează contextul curent și descrierea ta în limbaj natural către language model-ul din spate, cerându-i să genereze sau să extragă valoarea exactă de care ai nevoie. Hai să ne uităm la un scenariu concret, cum ar fi rezervarea unui bilet de avion. Trebuie să știi când vrea userul să călătorească. În fișierul tău Colang, definești un flow de rezervare a zborului. În interiorul acelui flow, îi spui sistemului să aștepte ca userul să vorbească. Odată ce o face, trebuie să extragi data. Declari o variabilă de context, numită poate flight date. Îi atribui valoarea unei descrieri în limbaj natural, scriind efectiv fraza „the date the user wants to fly”, urmată imediat de generation operator, acele trei puncte. Când userul spune „Am nevoie de un bilet pentru marțea viitoare”, state machine-ul Colang capturează acel event. Ajunge la atribuirea variabilei tale. Pasează mesajul userului și instrucțiunea ta în limbaj natural către language model. Modelul citește contextul, identifică „marțea viitoare” ca valoare target și o returnează. Acel generation operator face resolve, iar variabila ta de context stochează acum în siguranță data extrasă. Flow-ul tău trece apoi la pasul următor, care ar putea implica apelarea unui API extern de booking, definit dincolo în configurația ta YAML. Adevărata putere a acestei arhitecturi este că nu te mai lupți cu dialogue states folosind cod rigid. Lași un fișier YAML să fixeze infrastructura statică și îl lași pe Colang să folosească capacitatea de reasoning a language model-ului pentru a naviga realitatea imprevizibilă a conversației umane. Aș vrea să îmi iau un moment să îți mulțumesc că ne asculți — ne ajută enorm. Să ai o zi super!

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 3 din 10. Să te bazezi pe un model masiv de șaptezeci de miliarde de parametri pentru a face o moderare de conținut de bază este o risipă uriașă de compute. Este lent, scump și ia din puterea de procesare necesară pentru generarea de răspunsuri reale. Soluția este Specialized Content Safety cu Nemotron NIM. În loc să-i ceri modelului principal al aplicației tale să scrie cod și să verifice toxicitatea în același timp, împarți workload-ul. Modelul principal se ocupă de raționamentul complex și de generare. Un al doilea model, mult mai mic, se ocupă de securitate. Mai exact, ne uităm la Llama 3 point 1 Nemotron Safety Guard 8B V3. Acesta este un model de opt miliarde de parametri, cu fine-tuning făcut special pentru un singur job: evaluarea siguranței conținutului. Rulează ca un microserviciu standalone, sau NIM, pe care NeMo Guardrails îl apelează printr-un API. Pentru a seta asta, definești Nemotron NIM în configurația ta de guardrails ca un model distinct. Îi pui label-ul de tip content safety, în timp ce modelul tău principal rămâne de tipul main. Această distincție este critică, deoarece Guardrails face routing la trafic diferit, în funcție de aceste label-uri. Odată configurat, activezi safety guard-ul ca un input rail și un output rail. Când un utilizator trimite un prompt, Guardrails îl interceptează înainte să ajungă vreodată la modelul tău principal. Trimite prompt-ul către safety NIM-ul Nemotron. NIM-ul evaluează textul în raport cu douăzeci și trei de categorii specifice de conținut unsafe. Aceste categorii acoperă totul, de la hate speech și violență, până la conținut sexual și planificare de infracțiuni. Gândește-te la o aplicație multilingvă în care un utilizator trimite un prompt în franceză, cerând instrucțiuni pas cu pas despre cum să pornească o mașină fără cheie. Input rail-ul prinde asta. Guardrails trimite textul în franceză către Nemotron NIM. Pentru că modelul de safety este antrenat pe date de safety multilingve, înțelege intenția indiferent de limbă. Marchează request-ul ca făcând parte din categoria de criminal advice și returnează un semnal de unsafe înapoi la Guardrails. Guardrails oprește apoi imediat procesul și îi returnează utilizatorului un mesaj standard de refuz. Modelul tău principal nici măcar nu vede prompt-ul, economisindu-ți costul de inference pentru procesarea unui request toxic. Exact aceeași logică se aplică invers pentru output rails. Dacă un prompt aparent inofensiv păcălește cumva modelul principal să genereze un răspuns unsafe, Guardrails interceptează acel text generat înainte să ajungă la utilizator. Trimite output-ul către safety NIM, îl verifică în raport cu aceleași douăzeci și trei de categorii și îl blochează dacă încalcă regulile. Să setezi asta necesită actualizarea fișierelor tale de configurare. Declari modelul Nemotron în lista ta de modele, direcționându-l către endpoint-ul tău NIM. Apoi, activezi flow-urile default de self-check input și self-check output, spunându-i explicit lui Guardrails să folosească modelul tău de content safety pentru aceste verificări. Nu trebuie să scrii prompt-uri custom care să instruiască modelul cum să evalueze toxicitatea. Modelul Nemotron se așteaptă la un format de prompt foarte specific pentru a evalua textul, iar NeMo Guardrails formatează acel API call automat, în spate. Tu doar direcționezi rails către NIM și îl lași să facă clasificarea. Decuplarea logicii tale de moderare într-un model dedicat, mai mic, asigură că modelul principal al aplicației tale își consumă ciclurile generând valoare, în timp ce un guard specializat gestionează eficient securitatea perimetrului. Asta e tot pentru acest episod. Mersi că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 4 din 10. Cea mai ușoară modalitate de a împiedica chatbot-ul tău să creeze un dezastru de PR este să te asiguri că pur și simplu refuză să vorbească despre dezastru. Nu te poți baza pe un model de limbaj general-purpose ca să refuze în mod fiabil, pe cont propriu, fiecare subiect irelevant sau riscant. De aceea folosim Enforcing Domain Boundaries cu Topic Control. Modelele de limbaj general-purpose sunt dornice să facă pe plac. Dacă un utilizator pune o întrebare isteață, modelul va încerca să răspundă la ea. Dacă construiești un bot de suport clienți, vrei să vorbească doar despre suport clienți. Ai nevoie de o limită strictă. Pentru a crea această limită, folosești Llama 3.1 NemoGuard 8B TopicControl NIM. Acesta este un model specializat conceput pentru o sarcină specifică. Nu generează răspunsuri conversaționale. Evaluează. Gândește-te la un bot de suport telecom. Sarcina lui este să ajute utilizatorii cu facturile de telefon, întreruperile de rețea și planurile de date. Un utilizator se conectează la chat și îi cere bot-ului părerea despre alegerile politice recente. Fără guardrails, modelul tău principal primește prompt-ul, îl procesează și ar putea genera un răspuns nepotrivit. Cu NeMo Guardrails, configurezi un Input Rail. Un Input Rail interceptează request-ul utilizatorului înainte să se întâmple orice altceva. Modelul de limbaj principal nici măcar nu vede request-ul. Când utilizatorul întreabă despre alegeri, guardrail-ul rutează input-ul direct către modelul TopicControl. Tu controlezi cum se comportă acest model definind reguli stricte în system prompt-ul lui. Pentru bot-ul tău de telecom, system prompt-ul tău precizează că subiectele acceptabile sunt facturarea, statusul rețelei și managementul contului. Modelul TopicControl preia user prompt-ul și îl evaluează în raport cu acele reguli exacte. Apoi generează o clasificare rigidă. Returnează o evaluare de tip on-topic sau off-topic. Dacă utilizatorul întreabă de ce costurile lui de roaming sunt mari, modelul TopicControl citește prompt-ul, verifică regulile și returnează on-topic. Guardrail-ul deschide poarta, iar user prompt-ul trece mai departe către modelul tău conversațional principal pentru a genera un răspuns util. Când utilizatorul întreabă despre alegerile politice, modelul TopicControl evaluează prompt-ul în raport cu regulile de telecom. Recunoaște nepotrivirea și returnează off-topic. Guardrail-ul oprește imediat pipeline-ul. Blochează request-ul înainte să ajungă la modelul tău principal. În schimb, guardrail-ul declanșează un răspuns de refuz static, predefinit. Bot-ul îi spune utilizatorului că este echipat doar pentru a gestiona servicii telecom. Utilizarea unui model dedicat pentru topic control separă logica de evaluare de logica conversațională. Nu irosești compute cycles costisitoare întrebând un model masiv, general-purpose, ca să afli dacă are voie să răspundă la o întrebare. Folosești un model mai mic, extrem de optimizat, de opt miliarde de parametri, care să acționeze ca un paznic la ușă. Asta îți menține acele domain boundaries strict aplicate, fără să necesite un prompt engineering complex și fragil pe modelul tău principal. Cel mai sigur mod de a gestiona un request out-of-bounds este să te asiguri că motorul tău principal de raționament rămâne complet inconștient că acel request a fost făcut vreodată. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 5 din 10. Dacă sistemul tău de retrieval-augmented generation ingerează o bază de date de angajați neredactată, ai comis deja o încălcare a conformității înainte ca language model-ul să genereze măcar un singur cuvânt. Odată ce datele sensibile intră în contextul prompt-ului, pierzi controlul asupra locului în care ajung. Detectarea și mascarea dinamică a datelor PII este modul prin care interceptezi aceste date în tranzit. Să ne uităm la un bot intern de resurse umane. Un manager îi pune bot-ului o întrebare generală despre politica companiei de evaluare a performanței. Bot-ul caută în baza de cunoștințe internă. Căutarea returnează documentul relevant, dar chunk-urile de text recuperate includ accidental o înregistrare specifică a unui angajat atașată la fișier, completă cu un nume, o adresă de domiciliu și un email. Dacă sistemul transmite aceste chunk-uri recuperate direct către language model, acele date sensibile devin parte din context window. NeMo Guardrails gestionează acest lucru plasându-se între componentele aplicației tale și filtrând stream-ul de text. Oferă două abordări distincte. Detecția implică identificarea informațiilor de tip PII și luarea unei măsuri stricte, cum ar fi blocarea completă a prompt-ului sau aruncarea unei erori. Mascarea este mai flexibilă. Găsește informațiile sensibile și le înlocuiește cu un placeholder generic, on the fly. Textul john@example.com devine un string între paranteze care spune EMAIL. Baza de date din spate rămâne complet neatinsă. Pentru a executa acest lucru, sistemul de guardrails se bazează pe tool-uri externe specializate. Configurezi framework-ul pentru a apela un engine precum Microsoft Presidio sau GLiNER. Presidio utilizează de obicei pattern matching, regular expressions și rule-based logic pentru a detecta formate standard, cum ar fi numere de telefon sau carduri de credit. GLiNER, care vine de la Generalist and Lightweight Indicator for Named Entity Recognition, utilizează un model mic de machine learning pentru a identifica entitățile pe baza contextului înconjurător. Definești un array de tipuri de entități care te interesează, iar engine-ul selectat se ocupă de extragere. Această protecție funcționează în trei puncte specifice din flow-ul aplicației. Primul este input rail-ul. Dacă un utilizator își introduce propriul număr de securitate socială în fereastra de chat, input rail-ul scanează string-ul primit și maschează numărul înainte ca language model-ul să primească prompt-ul. Modelul procesează cererea folosind placeholder-ul, complet orb față de numărul real. Al doilea punct este retrieval rail-ul. Aceasta este partea care contează. Când sistemul tău interoghează o bază de date vectorială și extrage chunk-uri de text brut, guardrail-ul interceptează acele chunk-uri înainte de a fi injectate în prompt template-ul final. Scanează textul recuperat, elimină numele și adresele reale și le substituie cu tag-uri mascate. Mecanismul tău de retrieval poate extrage date din surse dezordonate și neredactate, dar language model-ul este protejat de detaliile sensibile. Al treilea punct este output rail-ul. Dacă language model-ul generează date sensibile, fie prin halucinații, fie pentru că o parte din date a trecut cumva de rail-urile anterioare, output rail-ul acționează ca un checkpoint final. Scanează răspunsul generat și maschează textul sensibil înainte ca acesta să ajungă pe ecranul utilizatorului. Deoarece toate acestea se întâmplă dinamic în memorie în timpul executării unui singur request, arhitectura ta de date nu trebuie să se schimbe. Eviți overhead-ul masiv de engineering necesar pentru a menține baze de date duplicate, pre-redactate, doar pentru a rula o aplicație de chat. Cea mai sigură metodă de a gestiona datele sensibile într-o aplicație cu language model este să te asiguri că modelul nu calculează niciodată pe datele reale în primul rând. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 6 din 10. Unele dintre cele mai devastatoare atacuri de tip prompt injection nu par deloc a fi inginerie socială ingenioasă. Pentru un om, par doar un text complet fără sens. Utilizatorul nu încearcă să păcălească botul cu o ghicitoare, ci mai degrabă să-l supraîncarce matematic. Detectarea acestui lucru necesită Jailbreak Detection prin euristici de perplexitate. Ia în considerare un scenariu specific de atac. Un utilizator rău intenționat vrea ca aplicația ta să genereze ceva dăunător, dar știe că ai instrucțiuni de siguranță în system prompt. Pentru a ocoli aceste instrucțiuni, ia request-ul dăunător și îi face padding cu un string masiv de caractere random, simboluri obscure sau cuvinte fără sens. Când modelul de limbaj procesează acest input, mecanismele de atenție sunt trase în jos de volumul uriaș de token-uri imprevizibile. Modelul pierde din vedere alinierea sa de siguranță și pur și simplu răspunde la request-ul malițios. Nu poți detecta acest atac cu filtre standard de cuvinte cheie, deoarece padding-ul este random. Ai putea folosi un alt model de limbaj pentru a evalua prompt-ul primit pentru pattern-uri adversariale, dar asta adaugă o penalizare masivă de latență la fiecare request al utilizatorului. Ai nevoie de un filtru care este rapid, matematic și care rulează local. Aici intervine perplexitatea. Perplexitatea este o metrică standard care măsoară cât de previzibilă este o bucată de text pentru un model de limbaj. Propozițiile umane normale urmează pattern-uri previzibile, rezultând într-o perplexitate scăzută. Un string de caractere random, sau o secvență bizară de cuvinte fără legătură, este extrem de imprevizibil. Asta generează o perplexitate ridicată. Calculând perplexitatea unui prompt primit, obții o măsură statistică a gradului său de randomness. NeMo Guardrails folosește acest concept pentru a bloca atacurile de tip gibberish prin două euristici principale. Prima este Length per Perplexity. Atacurile adversariale necesită de obicei un string lung de text de tip garbage pentru a deraia cu succes modelul principal. Un string scurt fără sens este de obicei ignorat de mecanismul de atenție. Această euristică calculează un raport folosind lungimea totală a prompt-ului și scorul său general de perplexitate. Dacă un prompt este atât neobișnuit de lung, cât și extrem de imprevizibil, acesta depășește un threshold matematic predefinit. Guardrail-ul interceptează input-ul, îl marchează ca un potențial jailbreak și blochează request-ul înainte ca modelul tău principal să apuce să-l vadă. A doua euristică gestionează o variantă mai chirurgicală a aceluiași atac. Uneori, un atacator ascunde textul gibberish. Scrie o propoziție complet normală, cu perplexitate scăzută, în mijlocul prompt-ului, dar face append la un bloc dens de token-uri random chiar la final. Dacă calculezi perplexitatea pe întregul prompt, textul normal ar putea dilua scorul mediu suficient de mult încât să treacă de primul filtru. Pentru a contracara asta, NeMo Guardrails folosește Prefix and Suffix Perplexity. În loc să se uite la întregul prompt, această euristică izolează un număr fix de token-uri chiar la începutul și chiar la sfârșitul input-ului de la utilizator. Calculează independent perplexitatea acestor limite. Dacă utilizatorul atașează un payload adversarial de caractere random la sfârșitul unei întrebări normale, scorul de perplexitate al sufixului crește brusc. Guardrail-ul detectează anomalia la limită și dă drop la request. Întregul proces are loc fără a face un API call extern către un model de limbaj masiv. Se bazează pe un model local, mai mic, pentru a calcula scorurile de perplexitate, ceea ce menține overhead-ul de latență la un minim absolut. Eliminând sensul semantic al textului, te oprești din a analiza ce încearcă utilizatorul să spună și începi să analizezi forma matematică a cuvintelor sale. Euristicile de perplexitate îți permit să blochezi atacuri adversariale complexe folosind statistici brute, securizându-ți aplicația la viteza matematicii. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 7 din 10. Să îi dai unui language model acces să execute database queries este ca și cum i-ai da cheile bazei tale de date unui străin. Îi spui modelului să facă fetch la user data, dar un prompt isteț îl păcălește să adauge o comandă de drop a table. Securizarea de agentic workflows cu execution rails este modul prin care oprești agenții autonomi să îți compromită backend-ul. Majoritatea guardrails-urilor se concentrează pe răspunsul din chat. Ele opresc modelul din a folosi un limbaj vulgar sau de a devia de la subiect. Execution rails fac ceva complet diferit. Ele protejează tool-urile pe care le folosește agentul. Când un agent decide să folosească un tool pentru a rula un script Python generat sau pentru a executa un SQL query, execution rail-ul interceptează payload-ul exact la punctul de handoff, chiar înainte ca tool-ul să ruleze efectiv. NeMo Guardrails gestionează această validare folosind YARA rules. YARA este un pattern-matching engine folosit în mod tradițional de analiștii de securitate cibernetică pentru a identifica malware pe baza unor semnături textuale sau binare specifice. În acest framework, NVIDIA oferă un catalog predefinit de YARA patterns construite special pentru a prinde vulnerabilitățile de language model. Motorul de guardrails trece tool input-ul prin aceste YARA rules pentru a căuta semnături de atac cunoscute. Acest catalog vizează patru amenințări specifice. Prima este SQL injection, unde modelul generează database commands care conțin modificări malițioase. A doua este code injection, unde agentul încearcă să execute comenzi de sistem neautorizate în interiorul unui script Python generat dinamic. A treia este template injection, unde un atacator manipulează server-side rendering engines. În cele din urmă, detectează cross-site scripting, blocând payload-urile concepute pentru a executa scripturi malițioase într-un web browser. Gândește-te la un agent care are sarcina de a prelua un user request, de a scrie un script Python pentru a procesa niște date locale și de a-l rula. Dacă un utilizator ascunde o comandă de sistem pentru a expune environment variables în interiorul promptului său, language model-ul ar putea include orbește acea comandă în scriptul Python final. Execution rail-ul prinde acest lucru. Scanează codul Python generat, face match pe YARA rule pentru code injection și dă flag la payload înainte ca execution engine-ul să îl vadă vreodată. Când sistemul detectează un pattern malițios, ia măsuri pe baza configurației tale. Ai două opțiuni. Prima acțiune este reject. Asta blochează complet execuția tool-ului. Workflow-ul se oprește, codul malițios nu rulează niciodată, iar sistemul returnează un răspuns sigur. A doua acțiune este omit. Asta îi spune guardrail-ului să elimine string-ul malițios specific din payload, dar să permită tool-ului să execute ce a mai rămas. Alegerea între reject și omit depinde în întregime de tool. Dacă agentul tău rulează un SQL query pe o bază de date, reject este singura opțiune sigură. Să dai omit la un string dintr-un SQL query complex va duce probabil la o malformed syntax sau la un data access imprevizibil. Omit este în general rezervat pentru task-uri de bază de text processing, unde eliminarea unui string greșit lasă în continuare un payload utilizabil și sigur. Configurezi aceste protecții direct în fișierele tale YAML prin activarea de agentic security rails și maparea lor la tool-uri specifice. Motorul YARA din spate face greul, făcând match pe pattern-urile predefinite fără să îți ceară să scrii regular expressions custom. Execution rails tratează language model-ul ca pe un untrusted user, forțându-te să validezi fiecare comandă pe care o generează înainte să îți atingă infrastructura. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 8 din 10. Un bot care spune că nu știe răspunsul este ușor enervant. Un bot financiar care declară cu încredere că firma ta a ratat obiectivul de venituri pentru trimestrul al treilea cu cincizeci de milioane de dolari, când de fapt a depășit obiectivul, este un dezastru. Pentru a împiedica sistemul tău Retrieval-Augmented Generation să inventeze cifre și să-ți distrugă credibilitatea, ai nevoie de Grounding RAG: Hallucinations și Fact-Checking. Să clarificăm imediat o confuzie comună. Fact-checking-ul și detectarea halucinațiilor sunt două lucruri diferite. Detectarea halucinațiilor implică, de obicei, să pui aceeași întrebare modelului de limbaj de mai multe ori. Dacă sample-urile rezultate se contrazic, modelul probabil halucinează. Fact-checking-ul evaluează un singur răspuns generat în raport cu un set specific de documente de încredere. NeMo Guardrails folosește fact-checking pentru a-ți menține pipeline-urile RAG grounded. Modelele de limbaj prezic text. Ele nu știu în mod intrinsec ce este adevărat. Într-un setup RAG standard, extragi chunk-uri de text din baza ta de date, le dai modelului și îi ceri să răspundă exclusiv pe baza acelui text. Uneori, modelul tot halucinează, combinând cunoștințele sale pre-antrenate cu datele tale, sau pur și simplu inventând o metrică ce sună plauzibil. NeMo Guardrails oprește asta folosind un output rail numit self check facts. Când este activ, acest rail interceptează răspunsul generat de model înainte să ajungă la utilizator. Sistemul tratează acest răspuns neverificat ca pe o ipoteză. Apoi extrage exact acele snippet-uri de text care au fost aduse din baza ta de date. Aceste snippet-uri sunt stocate automat într-o variabilă de context numită relevant chunks. Această variabilă reprezintă dovada concretă. Guardrail-ul rulează apoi o evaluare. Trimite ipoteza și dovezile către un model evaluator. Evaluatorul verifică dacă dovezile implică strict ipoteza. Revenind la bot-ul nostru financiar, dacă textul generat susține o anumită cifră de venituri, dar acea cifră nu există nicăieri în variabila relevant chunks, evaluatorul îl marchează ca ungrounded. Guardrail-ul blochează imediat răspunsul halucinat. În schimb, servește un mesaj de fallback sigur, admițând că nu are suficiente informații. Folosirea unui model de limbaj general purpose pentru fact-checking este ușor de setat, dar vine cu o penalizare. Adaugă latență, consumă token-uri, iar modelul evaluator poate fi uneori încurcat de un context dens. Nu ești obligat să folosești setup-ul default. Poți înlocui verificarea standard bazată pe prompt-uri cu tool-uri externe specializate. Abordările care folosesc modele precum AlignScore sau Patronus Lynx sunt extrem de eficiente aici. Acestea sunt modele purpose-built, antrenate exclusiv pentru a detecta neconcordanțele dintre un text sursă și o afirmație generată. Când rutezi relevant chunks și ipoteza printr-unul dintre aceste modele specializate, faci bypass complet la evaluatorul modelului de limbaj standard. Asta oferă un verdict mai rapid, mai ieftin și adesea mai riguros despre faptul dacă bot-ul tău spune adevărul. Asta e partea care contează. Să faci grounding unui pipeline RAG nu înseamnă să-ți faci modelul generativ inerent mai sincer. Este vorba despre a trata fiecare cuvânt generat ca pe o afirmație suspectă, care trebuie să supraviețuiască unei examinări stricte încrucișate cu datele tale sursă exacte, înainte să vadă lumina zilei. Dacă vrei să ne ajuți să continuăm să realizăm aceste episoade, poți susține emisiunea căutând DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mersi că ne-ai ascultat și spor la construit!

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 9 din 10. Petreci săptămâni întregi ajustând filtrele de input pentru a bloca prompt-urile de text malițioase. Apoi, un utilizator îți ocolește toată munca doar făcând un screenshot la acel bad prompt și încărcându-l ca imagine. Filtrele de text sunt complet oarbe la așa ceva. Pentru a detecta asta, ai nevoie de Multimodal Content Safety. Imaginează-ți un utilizator care încarcă o poză cu o pușcă de asalt customizată și tastează întrebarea: cum o modific ca să tragă mai repede. Un text guardrail standard vede doar o întrebare despre modificarea unui obiect generic. Habar nu are că obiectul este o armă. Intenția malițioasă există doar atunci când combini imaginea și textul. Gestionăm asta folosind un Vision Language Model care acționează ca un LLM-as-a-judge. În NeMo Guardrails, configurezi asta în etapa de input rail. Înainte ca request-ul utilizatorului să ajungă vreodată la modelul tău conversațional principal, guardrail-ul interceptează payload-ul multimodal. Datele imaginii ajung de obicei într-unul din două formate. Este fie un string encodat Base64, embedded direct în API call, fie un URL direct. String-urile Base64 fac payload-ul request-ului imediat mult mai mare, dar garantează că imaginea este disponibilă. URL-urile mențin payload-ul inițial ușor, dar necesită ca modelul care face evaluarea să aibă outbound network access pentru a face fetch la fișier. În orice caz, configurezi input rail-ul cu un prompt template specific, conceput pentru evaluare multimodală. Acest template conține o rubrică strictă care definește categorii de conținut nesigur, cum ar fi violența, actele ilegale, autovătămarea sau armele. Guardrail-ul construiește un request de evaluare. Împachetează rubrica ta de siguranță, textul utilizatorului și imaginea utilizatorului. Trimite acest pachet combinat către vision model și forțează modelul să răspundă cu un structured output, de obicei o simplă etichetă de safe sau unsafe. Modelul acționează strict ca un judecător. Analizează arma din fotografie, citește request-ul despre modificarea ei și verifică semnificația combinată în raport cu categoriile tale restricționate. Dacă vision model-ul detectează o încălcare, returnează un verdict de unsafe. Input rail-ul dă flag request-ului, îl blochează din a continua și declanșează un mesaj de refuz predefinit. Modelul principal al aplicației tale nici măcar nu vede request-ul malițios. Fii atent la partea asta legată de context limits. Vision models procesează imaginile convertindu-le în token-uri. În funcție de arhitectura modelului și de rezoluția imaginii, o singură poză poate consuma mii de token-uri. String-ul tău Base64 sau URL-ul imaginii, combinate cu textul utilizatorului și rubrica ta de siguranță multi-categorie, trebuie să încapă complet în context window-ul vision model-ului. Dacă trimiți imagini masive, de înaltă rezoluție, alături de un prompt text lung, vei depăși token limit-ul. Evaluarea guardrail-ului va eșua, sau modelul va trunchia input-ul și va rata complet încălcarea. Trebuie să implementezi o preprocesare pentru a redimensiona sau comprima imaginile înainte ca ele să ajungă la guardrail, menținând token footprint-ul previzibil. Evaluarea textului și a imaginilor în mod izolat nu mai este suficientă, deoarece abuzul modern se ascunde exact în spațiul în care aceste două modalități se intersectează. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodul 10 din 10. Să construiești reguli de siguranță direct într-un script Python este excelent pentru testare, dar groaznic pentru scalarea la nivelul unei companii poliglote. Dacă frontend-ul tău folosește Node JS și backend-ul este un mix de Python și Go, nu poți duplica logica de siguranță în fiecare limbaj. Soluția este să folosești cele trei Enterprise Integration Patterns pentru NeMo Guardrails. Ia un scenariu standard de migrare. Ai construit un prototip de bot de suport clienți folosind LangChain. Ai adăugat guardrails pentru a-l opri să vorbească despre concurenți. Funcționează perfect pe laptopul tău. Acum trebuie să migrezi acest prototip într-o arhitectură scalabilă de microservicii în producție, unde mai multe aplicații îl vor interoga. Ai trei modalități principale de a integra aceste guardrails pentru a face asta. Prima metodă este SDK-ul nativ Python, mai exact un obiect numit LLMRails. Acesta este motorul principal. Dacă construiești un backend Python custom de la zero, fără să te bazezi pe framework-uri de orchestrare, pe acesta îl folosești. Instanțiezi LLMRails, îi indici directorul de configurare care conține fișierele tale Colang și YAML, și îl folosești pentru a procesa input-urile. Îi pasezi o listă de dicționare cu mesaje care reprezintă istoricul conversației, iar el returnează răspunsul evaluat. Este direct și îți oferă acces raw la mecanica guardrails din spate. Din moment ce ai deja un prototip LangChain, să rescrii totul pentru a folosi SDK-ul raw este o pierdere de timp. Aici se aplică a doua metodă, și anume integrarea LangChain folosind RunnableRails. NeMo Guardrails se integrează nativ în LangChain Expression Language. Creezi o instanță RunnableRails încărcată cu configurația ta și o atașezi direct la chain-ul existent. Dacă chain-ul tău primește un prompt, preia documente și apelează un language model, tu faci wrap la întregul flux cu runnable-ul guardrail. Guardrail-ul interceptează input-ul înainte să ajungă în chain-ul tău și evaluează output-ul după ce chain-ul generează un răspuns. Codul core al aplicației tale abia se schimbă, dar logica ta LangChain este acum protejată. Asta e partea care contează la scalare. Gândește-te la companie în ansamblu. O altă echipă vrea să folosească exact aceleași politici de siguranță ale tale, dar ei construiesc un web gateway în Node JS sau un router high performance în Go. Ei nu pot importa un obiect Python LangChain. Pentru asta, folosești a treia metodă, API Server-ul standalone. NeMo Guardrails include un server built-in pe care îl poți rula din linia de comandă sau îi poți face deploy ca un container. Pornești serverul și îi indici folderul de configurare. Acesta expune imediat endpoint-uri REST care imită API-ul standard OpenAI. Pentru aplicațiile tale Go sau Node JS, serverul de guardrails arată exact ca un language model standard. Ele trimit request-uri JSON standard către endpoint-ul de chat completions. Serverul gestionează input guardrails, comunică cu modelul real din spate, procesează output guardrails și returnează textul curat. Decuplarea regulilor de logica aplicației tale folosind un server standalone este singura modalitate fiabilă de a impune politici de siguranță consistente în întreaga organizație. Consultă documentația oficială pentru a încerca aceste integration patterns hands-on, sau vizitează DEV STORIES DOT EU pentru a sugera subiecte pentru seriile viitoare. Îți mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.