NVIDIA NeMo Guardrails

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 1 de 10. Jamás conectarías una base de datos en crudo directamente a internet, sin embargo, muchas aplicaciones exponen modelos de lenguaje sin restricciones directamente a los usuarios finales. Depender únicamente de un system prompt para mantener la seguridad es una arquitectura frágil. Hoy cubrimos El imperativo de los Guardrails en IA: Abstracciones principales. NeMo Guardrails actúa como una capa intermedia programable entre tu aplicación de usuario y el modelo de lenguaje. No reemplaza tu modelo. En su lugar, crea un pipeline independiente de comprobaciones de seguridad discretas llamadas rails. En lugar de suplicarle al modelo que se comporte bien mediante un prompt engineering complejo, orquestas la seguridad a través de esta capa determinista. Imagina un bot de atención al cliente. Un usuario envía un mensaje, el sistema recupera artículos de soporte relevantes, el modelo redacta una respuesta y podría lanzar una acción en el backend, como procesar un reembolso. Necesitas diferentes tipos de protección en cada etapa. Para gestionar esto, Guardrails define cinco tipos distintos de rails. Primero, el mensaje del usuario llega al Input Rail. Este rail inspecciona el texto antes de que el modelo de lenguaje principal llegue a verlo. Si un usuario intenta un ataque de prompt injection o envía texto altamente tóxico, el input rail intercepta el mensaje de inmediato. Detiene el pipeline y devuelve un rechazo predefinido. El modelo principal nunca procesa el texto malicioso, ahorrando compute y evitando un exploit. Si el input es seguro, el sistema evalúa los Dialog Rails. Estos gestionan el flujo esperado de la conversación. Si un usuario le pide al bot de soporte su opinión sobre un competidor, un dialog rail identifica el tema. Obliga al bot a seguir una ruta predeterminada, quizás respondiendo que solo habla de sus propios productos. Los dialog rails evitan que el modelo se desvíe del tema o responda preguntas en las que no debería meterse. A continuación, cuando tu bot busca en tu knowledge base para hacer grounding de su respuesta, los Retrieval Rails toman el control. Estos inspeccionan los chunks de texto extraídos de la base de datos antes de que se añadan al prompt del modelo. Si una búsqueda mal configurada coge accidentalmente un documento interno de recursos humanos en lugar de un manual público, el retrieval rail detecta la información sensible y la elimina de la context window. Si la conversación requiere que el bot realice una tarea, intervienen los Execution Rails. Estos controlan qué acciones personalizadas se le permite lanzar al modelo. Cuando el modelo pide ejecutar código o llamar a una tool externa, el execution rail verifica si esa acción específica está permitida dado el estado actual de la conversación. Bloquea la ejecución de comandos no autorizados. Finalmente, tenemos los Output Rails. Esta es la última línea de defensa. Después de que el modelo genera una respuesta, el output rail evalúa el texto antes de que llegue al usuario. Comprueba si hay alucinaciones, un tono inapropiado o filtraciones de datos sensibles. Si el texto no supera la comprobación, el output rail lo intercepta y altera o bloquea el mensaje final. Esta arquitectura cambia fundamentalmente cómo construyes aplicaciones generativas. Dejas de depender de un motor probabilístico para vigilar su propio comportamiento y, en su lugar, construyes una red de seguridad determinista que controla los inputs, la lógica y los outputs de forma independiente. Por cierto, si estos episodios te resultan útiles y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 2 de 10. Escribir Python puro para gestionar máquinas de estados de diálogo complejas y ramificadas es una auténtica pesadilla. En cuanto tu usuario se desvía de un guion rígido, tu lógica hardcoded se rompe. La arquitectura de configuración de NeMo Guardrails soluciona esto tratando las conversaciones como flows event-driven en lugar de código estático. NeMo Guardrails separa la mecánica de tu aplicación de la lógica de tu conversación. Esto ocurre a través de dos piezas de configuración distintas. Primero, tienes tu archivo de configuración YAML. Este se encarga de todo el wiring del modelo. Es donde declaras tu modelo de lenguaje principal, defines tus modelos de embeddings y registras las acciones personalizadas de tu aplicación. El archivo YAML conecta la infraestructura subyacente. Proporciona el motor, pero no sabe absolutamente nada sobre lo que el usuario dirá realmente. La lógica real de la conversación está controlada por Colang 2.0. Colang es un lenguaje de modelado de interacciones event-driven. En lugar de escribir código imperativo estándar con infinitas sentencias condicionales para trackear dónde está el usuario en una conversación, defines flows. Un flow modela una secuencia de interacciones. Cuando un usuario envía un mensaje, genera un evento. La máquina de estados captura este evento, busca un flow activo que coincida con la interacción y dicta el siguiente movimiento del asistente. Esta es la parte que importa. Colang utiliza Natural Language Descriptions para salvar la brecha entre el código estricto y la ambigüedad humana. En lugar de escribir expresiones regulares complejas para parsear un mensaje del usuario, instruyes al sistema usando lenguaje humano directamente dentro de la lógica de tu flow. Emparejas estas descripciones con el generation operator, que se escribe simplemente como tres puntos. Cuando la máquina de estados encuentra esos tres puntos, pausa temporalmente la ejecución. Le pasa el contexto actual y tu Natural Language Description al modelo de lenguaje subyacente, pidiéndole que genere o extraiga el valor exacto que necesitas. Veamos un escenario concreto, como reservar un billete de avión. Necesitas saber cuándo quiere viajar el usuario. En tu archivo de Colang, defines un flow de reserva de vuelos. Dentro de ese flow, le dices al sistema que espere a que el usuario hable. Una vez que lo hace, necesitas extraer la fecha. Declaras una variable de contexto, quizás llamada flight date. Le asignas el valor de una Natural Language Description, escribiendo literalmente la frase "the date the user wants to fly", seguida inmediatamente por el generation operator, esos tres puntos. Cuando el usuario dice "Necesito un billete para el próximo martes", la máquina de estados de Colang captura el evento. Llega a la asignación de tu variable. Le pasa el mensaje del usuario y tu instrucción en lenguaje natural al modelo de lenguaje. El modelo lee el contexto, identifica "el próximo martes" como el valor objetivo y lo devuelve. El generation operator se resuelve, y tu variable de contexto ahora guarda de forma segura la fecha extraída. Tu flow luego avanza al siguiente paso, que podría implicar llamar a una API de reservas externa definida en tu configuración YAML. El verdadero poder de esta arquitectura es que dejas de pelear con los estados de diálogo usando código rígido. Dejas que un archivo YAML asegure la infraestructura estática, y dejas que Colang use la capacidad de razonamiento del modelo de lenguaje para navegar por la impredecible realidad de la conversación humana. Me gustaría tomarme un momento para darte las gracias por escucharnos; nos ayuda muchísimo. ¡Que tengas un buen día!

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 3 de 10. Depender de un modelo masivo de setenta mil millones de parámetros para hacer una moderación básica de contenido es un enorme desperdicio de compute. Es lento, caro y quita potencia de procesamiento a la generación de respuestas reales. La solución es la seguridad de contenido especializada con Nemotron NIM. En lugar de pedirle a tu modelo principal de la aplicación que escriba código y compruebe la toxicidad a la vez, divides la carga de trabajo. El modelo principal se encarga del razonamiento complejo y la generación. Un segundo modelo, mucho más pequeño, se encarga de la seguridad. En concreto, estamos viendo el Llama 3 punto 1 Nemotron Safety Guard 8B V3. Este es un modelo de ocho mil millones de parámetros con fine-tuning exclusivamente para una tarea, que es evaluar la seguridad del contenido. Se ejecuta como un microservice independiente, o NIM, al que NeMo Guardrails llama a través de una API. Para configurar esto, defines el Nemotron NIM en tu configuración de Guardrails como un modelo distinto. Etiquetas su tipo como content safety, mientras que tu modelo principal sigue siendo del tipo main. Esta distinción es fundamental porque Guardrails enruta el tráfico de forma diferente basándose en estas etiquetas. Una vez configurado, activas el safety guard como un input rail y un output rail. Cuando un usuario envía un prompt, Guardrails lo intercepta antes de que llegue a tu modelo principal. Envía el prompt al NIM de seguridad de Nemotron. El NIM evalúa el texto frente a veintitrés categorías específicas de contenido inseguro. Estas categorías cubren todo, desde discurso de odio y violencia hasta contenido sexual y planificación criminal. Imagina una aplicación multilingüe donde un usuario envía un prompt en francés, pidiendo instrucciones paso a paso sobre cómo hacerle un puente a un coche. El input rail detecta esto. Guardrails envía el texto en francés al Nemotron NIM. Como el modelo de seguridad está entrenado con datos de seguridad multilingües, entiende la intención independientemente del idioma. Marca la petición como perteneciente a la categoría de asesoramiento criminal y devuelve una señal de unsafe a Guardrails. Guardrails entonces detiene inmediatamente el proceso y devuelve un mensaje de rechazo estándar al usuario. Tu modelo principal ni siquiera llega a ver el prompt, ahorrándote el coste de inference de procesar una petición tóxica. Exactamente la misma lógica se aplica a la inversa para los output rails. Si un prompt aparentemente inofensivo de alguna manera engaña al modelo principal para que genere una respuesta insegura, Guardrails intercepta ese texto generado antes de que llegue al usuario. Envía el output al NIM de seguridad, lo comprueba frente a esas mismas veintitrés categorías, y lo bloquea si viola las reglas. Configurar esto requiere actualizar tus archivos de configuración. Declaras el modelo Nemotron en tu lista de modelos, apuntándolo a tu endpoint del NIM. Luego, habilitas los flujos por defecto de self-check input y self-check output, diciéndole explícitamente a Guardrails que use tu modelo de content safety para estas comprobaciones. No necesitas escribir prompts personalizados instruyendo al modelo sobre cómo evaluar la toxicidad. El modelo Nemotron espera un formato de prompt muy específico para evaluar el texto, y NeMo Guardrails formatea esa llamada a la API automáticamente internamente. Simplemente apuntas los rails al NIM y dejas que haga la clasificación. Desacoplar tu lógica de moderación en un modelo dedicado y más pequeño asegura que tu modelo principal de la aplicación dedique sus ciclos a generar valor, mientras que un guard especializado gestiona eficientemente la seguridad del perímetro. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 4 de 10. La forma más sencilla de evitar que tu chatbot provoque un desastre de relaciones públicas es asegurarte de que simplemente se niegue a hablar del desastre. No puedes confiar en que un modelo de lenguaje de propósito general rechace de forma fiable cualquier tema irrelevante o arriesgado por sí solo. Por eso utilizamos la imposición de límites de dominio con Topic Control. Los modelos de lenguaje generales buscan complacer. Si un usuario hace una pregunta ingeniosa, el modelo intentará responderla. Si creas un bot de atención al cliente, solo quieres que hable de atención al cliente. Necesitas un límite estricto. Para crear este límite, utilizas el TopicControl NIM de Llama 3.1 NemoGuard 8B. Este es un modelo especializado diseñado para una tarea específica. No genera respuestas conversacionales. Evalúa. Imagina un bot de soporte de telecomunicaciones. Su función es ayudar a los usuarios con facturas telefónicas, cortes de red y planes de datos. Un usuario se conecta al chat y le pide al bot su opinión sobre unas elecciones políticas recientes. Sin guardrails, tu modelo principal recibe el prompt, lo procesa y podría generar una respuesta inapropiada. Con NeMo Guardrails, configuras un Input Rail. Un Input Rail intercepta la request del usuario antes de que pase nada más. El modelo de lenguaje principal ni siquiera ve la request. Cuando el usuario pregunta sobre las elecciones, el guardrail enruta el input directamente al modelo TopicControl. Tú controlas cómo se comporta este modelo definiendo directrices estrictas dentro de su system prompt. Para tu bot de telecomunicaciones, tu system prompt indica que los temas aceptables son facturación, estado de la red y gestión de cuentas. El modelo TopicControl coge el prompt del usuario y lo evalúa contra esas directrices exactas. Luego devuelve una clasificación rígida. Devuelve una evaluación de on-topic u off-topic. Si el usuario pregunta por qué sus cargos de roaming son altos, el modelo TopicControl lee el prompt, comprueba las directrices y devuelve on-topic. El guardrail abre la puerta, y el prompt del usuario pasa a tu modelo conversacional principal para generar una respuesta útil. Cuando el usuario pregunta sobre las elecciones políticas, el modelo TopicControl evalúa el prompt contra las directrices de telecomunicaciones. Reconoce la discrepancia y devuelve off-topic. El guardrail detiene inmediatamente el pipeline. Bloquea la request para que no llegue a tu modelo principal. En su lugar, el guardrail activa una respuesta de rechazo estática y predefinida. El bot le dice al usuario que solo está equipado para gestionar servicios de telecomunicaciones. Usar un modelo dedicado para el topic control separa la lógica de evaluación de la lógica conversacional. No estás desperdiciando costosos ciclos de computación pidiéndole a un modelo masivo de propósito general que averigüe si tiene permiso para responder a una pregunta. Usas un modelo más pequeño y altamente optimizado de ocho mil millones de parámetros para que actúe como portero en la puerta. Esto mantiene los límites de tu dominio estrictamente aplicados sin requerir un prompt engineering complejo y frágil en tu modelo principal. La forma más segura de gestionar una request fuera de los límites es asegurarte de que tu motor de razonamiento principal no se entere nunca de que esa request llegó a hacerse. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 5 de 10. Si tu sistema de retrieval-augmented generation ingiere una base de datos de empleados sin anonimizar, ya has cometido una infracción de compliance incluso antes de que el modelo de lenguaje genere una sola palabra. Una vez que los datos sensibles entran en el contexto del prompt, pierdes el control sobre dónde van a parar. La detección y el enmascaramiento dinámico de PII es la forma en que interceptas esos datos en tránsito. Veamos un bot interno de recursos humanos. Un manager le hace al bot una pregunta general sobre la política de evaluación de rendimiento de la empresa. El bot busca en la base de conocimientos interna. La búsqueda devuelve el documento de la política correspondiente, pero los chunks de texto recuperados incluyen accidentalmente el registro de un empleado específico adjunto al archivo, con nombre, dirección y un email. Si el sistema pasa esos chunks recuperados directamente al modelo de lenguaje, esos datos sensibles pasan a formar parte de la context window. NeMo Guardrails gestiona esto situándose entre los componentes de tu aplicación y filtrando el stream de texto. Ofrece dos enfoques distintos. La detección implica identificar información personal identificable y tomar una acción estricta, como bloquear el prompt por completo o lanzar un error. El enmascaramiento es más flexible. Encuentra la información sensible y la reemplaza por un placeholder genérico sobre la marcha. El texto john@example.com se convierte en un string entre corchetes que dice EMAIL. La base de datos subyacente permanece completamente intacta. Para ejecutar esto, el sistema de guardrails se apoya en herramientas externas especializadas. Configuras el framework para llamar a un motor como Microsoft Presidio o GLiNER. Presidio suele utilizar pattern matching, expresiones regulares y lógica basada en reglas para detectar formatos estándar como números de teléfono o tarjetas de crédito. GLiNER, que significa Generalist and Lightweight Indicator for Named Entity Recognition, utiliza un pequeño modelo de machine learning para identificar entidades basándose en el contexto que las rodea. Defines un array de tipos de entidades que te interesan, y el motor seleccionado se encarga de la extracción. Esta protección opera en tres puntos específicos del flujo de la aplicación. El primero es el input rail. Si un usuario escribe su propio número de la seguridad social en la ventana de chat, el input rail escanea el string entrante y enmascara el número antes de que el modelo de lenguaje llegue a recibir el prompt. El modelo procesa la petición utilizando el placeholder, completamente ciego al número real. El segundo punto es el retrieval rail. Esta es la parte que importa. Cuando tu sistema consulta una vector database y recupera chunks de texto en bruto, el guardrail intercepta esos chunks antes de que se inyecten en el template final del prompt. Escanea el texto recuperado, elimina los nombres y direcciones reales, y los sustituye por las etiquetas enmascaradas. Tu mecanismo de retrieval puede extraer información de fuentes de datos desordenadas y sin anonimizar, pero el modelo de lenguaje queda protegido de los detalles sensibles. El tercer punto es el output rail. Si el modelo de lenguaje genera datos sensibles, ya sea alucinándolos o porque algún dato se coló por los rails anteriores, el output rail actúa como un checkpoint final. Escanea la respuesta generada y enmascara el texto sensible antes de que llegue a la pantalla del usuario. Como todo esto ocurre dinámicamente en memory durante la ejecución de una sola request, tu arquitectura de datos no tiene que cambiar. Evitas el enorme overhead de ingeniería de mantener bases de datos duplicadas y pre-anonimizadas solo para ejecutar una aplicación de chat. La forma más segura de manejar datos sensibles en una aplicación de modelo de lenguaje es asegurarte de que el modelo nunca opere con los datos reales en primer lugar. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 6 de 10. Algunos de los ataques de prompt injection más devastadores no parecen en absoluto ingeniería social astuta. Para un humano, simplemente parecen un galimatías total. El usuario no intenta engañar al bot con un acertijo, sino sobrecargarlo matemáticamente. Detectar esto requiere Jailbreak Detection mediante heurísticas de perplejidad. Imagina un escenario de ataque específico. Un usuario malicioso quiere que tu aplicación genere un output dañino, pero sabe que tienes instrucciones de seguridad en tu system prompt. Para eludir esas instrucciones, coge su petición maliciosa y la rellena con un string enorme de caracteres aleatorios, símbolos extraños o palabras sin sentido. Cuando el modelo de lenguaje procesa este input, los mecanismos de atención se ven saturados por el enorme volumen de tokens impredecibles. El modelo pierde de vista su alineación de seguridad subyacente y simplemente responde a la petición maliciosa. No puedes detectar este ataque con filtros de palabras clave estándar porque el padding es aleatorio. Podrías usar otro modelo de lenguaje para evaluar el prompt entrante en busca de patrones adversarios, pero eso añade una penalización de latencia enorme a cada petición del usuario. Necesitas un filtro que sea rápido, matemático y que se ejecute en local. Aquí es donde entra en juego la perplejidad. La perplejidad es una métrica estándar que mide lo predecible que es un texto para un modelo de lenguaje. Las frases humanas normales siguen patrones predecibles, lo que da como resultado una perplejidad baja. Un string de caracteres aleatorios, o una secuencia extraña de palabras sin relación, es altamente impredecible. Eso genera una perplejidad alta. Al calcular la perplejidad de un prompt entrante, obtienes una medida estadística de su aleatoriedad. NeMo Guardrails utiliza este concepto para bloquear ataques de galimatías mediante dos heurísticas principales. La primera es Length per Perplexity. Los ataques adversarios normalmente requieren un string largo de texto basura para descarrilar con éxito al modelo principal. Un string corto sin sentido suele ser ignorado por el mecanismo de atención. Esta heurística calcula un ratio utilizando la longitud total del prompt y su puntuación de perplejidad general. Si un prompt es inusualmente largo y altamente impredecible a la vez, cruza un umbral matemático predefinido. El guardrail intercepta el input, lo marca como un posible jailbreak y bloquea la petición antes de que tu modelo principal llegue a verlo. La segunda heurística se encarga de una variación más quirúrgica del mismo ataque. A veces, un atacante oculta el galimatías. Escribe una frase completamente normal y de baja perplejidad en medio de su prompt, pero añade un bloque denso de tokens aleatorios justo al final. Si calculas la perplejidad de todo el prompt, el texto normal podría diluir la puntuación media lo suficiente como para colarse por el primer filtro. Para contrarrestar esto, NeMo Guardrails utiliza Prefix and Suffix Perplexity. En lugar de analizar todo el prompt, esta heurística aísla un número fijo de tokens justo al principio y al final del input del usuario. Calcula la perplejidad de esos límites de forma independiente. Si el usuario añade un payload adversario de caracteres aleatorios al final de una pregunta normal, la puntuación de perplejidad del sufijo se dispara. El guardrail detecta la anomalía en el límite y descarta la petición. Todo este proceso ocurre sin hacer una llamada a una API externa hacia un modelo de lenguaje masivo. Se basa en un modelo local más pequeño para calcular las puntuaciones de perplejidad, lo que mantiene el overhead de latencia al mínimo absoluto. Al eliminar el significado semántico del texto, dejas de analizar lo que el usuario intenta decir y empiezas a analizar la forma matemática de sus palabras. Las heurísticas de perplejidad te permiten bloquear ataques adversarios complejos usando estadísticas puras, protegiendo tu aplicación a la velocidad de las matemáticas. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 7 de 10. Darle a un modelo de lenguaje acceso para ejecutar queries de base de datos es como entregarle las llaves de tu base de datos a un desconocido. Le indicas al modelo que obtenga datos de usuario, pero un prompt ingenioso lo engaña para que añada un comando para hacer un drop de una tabla. Proteger los workflows de agentes con execution rails es la forma de evitar que los agentes autónomos comprometan tu backend. La mayoría de los guardrails se centran en la respuesta del chat. Evitan que el modelo use lenguaje inapropiado o se desvíe del tema. Los execution rails hacen algo completamente diferente. Protegen las tools que usa el agente. Cuando un agente decide usar una tool para ejecutar un script de Python generado o una query SQL, el execution rail intercepta el payload exactamente en el punto de handoff, justo antes de que la tool se ejecute realmente. NeMo Guardrails gestiona esta validación mediante reglas YARA. YARA es un motor de pattern-matching que tradicionalmente utilizan los analistas de ciberseguridad para identificar malware basándose en firmas textuales o binarias específicas. En este framework, NVIDIA proporciona un catálogo predefinido de patrones YARA creados específicamente para detectar vulnerabilidades en modelos de lenguaje. El motor de guardrails pasa el input de la tool por estas reglas YARA para buscar firmas de ataque conocidas. Este catálogo se centra en cuatro amenazas específicas. La primera es el SQL injection, donde el modelo genera comandos de base de datos con modificaciones maliciosas. La segunda es el code injection, donde el agente intenta ejecutar comandos del sistema no autorizados dentro de un script de Python generado dinámicamente. La tercera es el template injection, donde un atacante manipula los motores de server-side rendering. Finalmente, detecta el cross-site scripting, bloqueando los payloads diseñados para ejecutar scripts maliciosos en un navegador web. Imagina un agente encargado de recibir una request del usuario, escribir un script de Python para procesar algunos datos locales y ejecutarlo. Si un usuario oculta un comando del sistema para exponer variables de entorno dentro de su prompt, el modelo de lenguaje podría incluir ciegamente ese comando en el script de Python final. El execution rail detecta esto. Escanea el código Python generado, hace match con la regla YARA de code injection y marca el payload antes de que el motor de ejecución llegue a verlo. Cuando el sistema detecta un patrón malicioso, actúa según tu configuración. Tienes dos opciones. La primera acción es reject. Esto bloquea completamente la ejecución de la tool. El workflow se detiene, el código malicioso nunca se ejecuta y el sistema devuelve una respuesta segura. La segunda acción es omit. Esto le dice al guardrail que elimine el string malicioso específico del payload, pero permite que la tool ejecute lo que quede. Elegir entre reject y omit depende completamente de la tool. Si tu agente está ejecutando una query SQL contra una base de datos, reject es la única opción segura. Omitir un string de una query SQL compleja probablemente resultará en una sintaxis malformada o un acceso a datos impredecible. Omit generalmente se reserva para tareas básicas de procesamiento de texto donde eliminar un string malo sigue dejando un payload utilizable y seguro. Puedes configurar estas protecciones directamente en tus archivos YAML habilitando los security rails agénticos y mapeándolos a tools específicas. El motor YARA subyacente hace el trabajo pesado, haciendo match con los patrones predefinidos sin requerir que escribas expresiones regulares personalizadas. Los execution rails tratan al modelo de lenguaje como un usuario no confiable, obligándote a validar cada comando que genera antes de que toque tu infraestructura. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 8 de 10. Que un bot diga que no sabe la respuesta es un poco molesto. Que un bot financiero afirme con total seguridad que tu empresa no alcanzó su objetivo de ingresos del tercer trimestre por cincuenta millones de dólares, cuando en realidad lo superó, es un desastre. Para evitar que tu sistema de Retrieval-Augmented Generation se invente cifras y destruya tu credibilidad, necesitas Grounding RAG: alucinaciones y fact-checking. Aclaremos una confusión muy común desde el principio. El fact-checking y la detección de alucinaciones son dos cosas distintas. La detección de alucinaciones normalmente implica hacerle la misma pregunta al modelo de lenguaje varias veces. Si las muestras resultantes se contradicen, es probable que el modelo esté alucinando. El fact-checking evalúa una única respuesta generada comparándola con un conjunto específico de documentos de confianza. NeMo Guardrails utiliza el fact-checking para mantener tus pipelines RAG grounded. Los modelos de lenguaje predicen texto. No saben intrínsecamente qué es verdad. En un setup RAG estándar, recuperas chunks de texto de tu base de datos, se los pasas al modelo y le pides que responda basándose únicamente en ese texto. A veces el modelo sigue alucinando, mezclando su conocimiento preentrenado con tus datos, o simplemente inventándose una métrica que suena plausible. NeMo Guardrails evita esto usando un output rail llamado self check facts. Cuando está activo, este rail intercepta la respuesta generada por el modelo antes de que llegue al usuario. El sistema trata esta respuesta no verificada como una hipótesis. A continuación, extrae los snippets de texto exactos que se recuperaron de tu base de datos. Estos snippets se almacenan automáticamente en una variable de contexto llamada relevant chunks. Esta variable es la evidencia irrefutable. Luego, el guardrail ejecuta una evaluación. Le pasa la hipótesis y la evidencia a un modelo evaluador. El evaluador comprueba si la evidencia respalda estrictamente la hipótesis. Volviendo a nuestro bot financiero, si el texto generado afirma una cifra de ingresos específica, pero esa cifra no existe en ninguna parte de la variable relevant chunks, el evaluador lo marca como ungrounded. El guardrail bloquea inmediatamente la respuesta alucinada. En su lugar, sirve un mensaje de fallback seguro, admitiendo que no tiene suficiente información. Usar un modelo de lenguaje de propósito general para hacer fact-checking es fácil de configurar, pero conlleva una penalización. Añade latencia, quema tokens, y el modelo evaluador a veces puede confundirse con un contexto denso. No estás obligado a usar el setup por defecto. Puedes reemplazar la verificación estándar basada en prompts con herramientas externas especializadas. Los enfoques que utilizan modelos como AlignScore o Patronus Lynx son muy efectivos en este caso. Estos son modelos diseñados específicamente y entrenados exclusivamente para detectar inconsistencias entre un texto fuente y una afirmación generada. Cuando enrutas los relevant chunks y la hipótesis a través de uno de estos modelos especializados, te saltas por completo el evaluador del modelo de lenguaje estándar. Esto proporciona un veredicto más rápido, más barato y, a menudo, más riguroso sobre si tu bot está diciendo la verdad. Esta es la parte que importa. Hacer grounding en un pipeline RAG no se trata de hacer que tu modelo generativo sea inherentemente más veraz. Consiste en tratar cada palabra generada como una afirmación sospechosa que debe sobrevivir a un estricto escrutinio contra tus datos de origen exactos antes de ver la luz. Si quieres ayudarnos a seguir creando estos episodios, puedes apoyar el programa buscando DevStoriesEU en Patreon. Eso es todo por este episodio. Gracias por escuchar, y ¡sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 9 de 10. Pasas semanas ajustando tus filtros de entrada para bloquear prompts de texto maliciosos. Luego, un usuario se salta todo tu esfuerzo simplemente haciendo una captura de pantalla de su prompt malicioso y subiéndola como imagen. Los filtros de texto son completamente ciegos ante esto. Para detectarlo, necesitas seguridad de contenido multimodal. Imagina a un usuario que sube una foto de un rifle de asalto personalizado y escribe la pregunta: cómo modifico esto para que dispare más rápido. Un guardrail de texto estándar solo ve una consulta sobre cómo modificar un objeto genérico. No tiene ni idea de que el objeto es un arma. La intención maliciosa solo existe cuando combinas la imagen y el texto. Gestionamos esto usando un Vision Language Model que actúa como LLM-as-a-judge. En NeMo Guardrails, configuras esto en la fase de input rail. Antes de que la petición del usuario llegue a tu modelo conversacional principal, el guardrail intercepta el payload multimodal. Los datos de la imagen suelen llegar en uno de estos dos formatos. O bien es un string codificado en Base64 incrustado directamente en la llamada a la API, o es una URL directa. Los strings en Base64 hacen que el payload de la petición inmediata sea mucho más grande, pero garantizan que la imagen esté disponible. Las URLs mantienen el payload inicial ligero, pero requieren que el modelo evaluador tenga acceso de salida a la red para descargar el archivo. De cualquier manera, configuras el input rail con un prompt template específico diseñado para la evaluación multimodal. Este template contiene una rúbrica estricta que define categorías de contenido inseguro, como violencia, actos ilegales, autolesiones o armas. El guardrail construye una petición de evaluación. Empaqueta tu rúbrica de seguridad, el texto del usuario y la imagen del usuario. Envía este paquete combinado al modelo de visión y fuerza al modelo a responder con un output estructurado, normalmente una simple etiqueta de seguro o inseguro. El modelo actúa estrictamente como juez. Analiza el arma de la foto, lee la petición sobre cómo modificarla y comprueba el significado combinado frente a tus categorías restringidas. Si el modelo de visión detecta una infracción, devuelve un veredicto de inseguro. El input rail marca la petición, bloquea que siga adelante y lanza un mensaje de rechazo predefinido. Tu modelo de aplicación principal ni siquiera llega a ver la petición maliciosa. Presta atención a esta parte sobre los límites de contexto. Los modelos de visión procesan las imágenes convirtiéndolas en tokens. Dependiendo de la arquitectura del modelo y de la resolución de la imagen, una sola foto puede consumir miles de tokens. Tu string en Base64 o la URL de la imagen, combinados con el texto del usuario y tu rúbrica de seguridad multicategoría, deben caber completamente dentro de la context window del modelo de visión. Si pasas imágenes enormes de alta resolución junto con un texto de prompt largo, superarás el límite de tokens. La evaluación del guardrail fallará, o el modelo truncará el input y se le pasará la infracción por completo. Debes implementar un preprocesamiento para redimensionar o comprimir las imágenes antes de que lleguen al guardrail, manteniendo así un consumo de tokens predecible. Evaluar texto e imágenes de forma aislada ya no es suficiente, porque el abuso moderno se esconde exactamente en el espacio donde esas dos modalidades se cruzan. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episodio 10 de 10. Crear reglas de seguridad directamente dentro de un script de Python es genial para hacer pruebas, pero terrible para escalar en una empresa políglota. Si tu frontend usa Node JS y tu backend es una mezcla de Python y Go, no puedes duplicar tu lógica de seguridad en cada lenguaje. La solución es usar los tres patrones de integración empresarial para NeMo Guardrails. Imagina un escenario de migración estándar. Has creado un prototipo de bot de atención al cliente usando LangChain. Le has añadido guardrails para evitar que hable de la competencia. Funciona perfectamente en tu portátil. Ahora necesitas migrar este prototipo a una arquitectura de microservicios en producción escalable, donde múltiples aplicaciones le harán consultas. Tienes tres formas principales de integrar los guardrails para que esto sea posible. El primer método es el SDK nativo de Python, específicamente un objeto llamado LLMRails. Este es el motor principal. Si estás construyendo un backend en Python a medida desde cero, sin depender de frameworks de orquestación, usas este. Instancias LLMRails, lo apuntas a tu directorio de configuración que contiene tus archivos Colang y YAML, y lo usas para procesar los inputs. Le pasas una lista de diccionarios de mensajes que representan el historial de la conversación, y te devuelve la respuesta evaluada. Es directo y te da acceso raw a la mecánica subyacente de los guardrails. Como ya tienes un prototipo en LangChain, reescribir todo para usar el SDK raw es un esfuerzo inútil. Aquí es donde entra el segundo método, que es la integración con LangChain usando RunnableRails. NeMo Guardrails se integra de forma nativa en LangChain Expression Language. Creas una instancia de RunnableRails cargada con tu configuración y la conectas directamente a tu chain existente. Si tu chain recibe un prompt, recupera documentos y llama a un modelo de lenguaje, envuelves todo ese flujo con el runnable del guardrail. El guardrail intercepta el input antes de que llegue a tu chain, y evalúa el output después de que tu chain genere una respuesta. El código core de tu aplicación apenas cambia, pero tu lógica de LangChain ahora está protegida. Esta es la parte que importa a gran escala. Piensa en el entorno empresarial más amplio. Otro equipo quiere usar exactamente tus mismas políticas de seguridad, pero están construyendo un web gateway en Node JS o un router de alto rendimiento en Go. No pueden importar un objeto de LangChain de Python. Para esto, usas el tercer método, el API Server standalone. NeMo Guardrails incluye un servidor integrado que puedes ejecutar desde la línea de comandos o hacer deploy como contenedor. Arrancas el servidor y lo apuntas a tu carpeta de configuración. Inmediatamente expone endpoints REST que imitan la API estándar de OpenAI. Para tus aplicaciones en Go o Node JS, el servidor de guardrails se ve exactamente como un modelo de lenguaje estándar. Envían requests JSON estándar al endpoint de chat completions. El servidor gestiona los guardrails de input, se comunica con el modelo subyacente real, procesa los guardrails de output y devuelve el texto limpio. Desacoplar tus reglas de la lógica de tu aplicación usando un servidor standalone es la única forma fiable de aplicar políticas de seguridad consistentes en toda una organización. Échale un vistazo a la documentación oficial para probar estos patrones de integración de forma práctica, o visita DEV STORIES DOT EU para sugerir temas para futuras series. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.