NVIDIA NeMo Guardrails

Olá, daqui fala o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 1 de 10. Tu nunca ligarias uma base de dados raw diretamente à internet pública, no entanto, muitas aplicações expõem modelos de linguagem sem restrições diretamente aos utilizadores finais. Depender exclusivamente de um system prompt para manter a segurança é uma arquitetura frágil. Hoje abordamos o imperativo dos AI Guardrails: Abstrações Essenciais. O NeMo Guardrails atua como uma camada intermédia programável entre a tua aplicação de utilizador e o modelo de linguagem. Não substitui o teu modelo. Em vez disso, cria um pipeline separado de verificações de segurança discretas chamadas rails. Em vez de implorares ao modelo para se comportar através de prompt engineering complexa, tu orquestras a segurança através desta camada determinística. Considera um bot de apoio ao cliente. Um utilizador envia uma mensagem, o sistema recupera artigos de suporte relevantes, o modelo redige uma resposta, e pode desencadear uma ação no backend, como processar um reembolso. Precisas de diferentes tipos de proteção em cada fase. Para lidar com isto, o Guardrails define cinco tipos distintos de rails. Primeiro, a mensagem do utilizador chega ao Input Rail. Este rail inspeciona o texto antes sequer de o modelo de linguagem principal o ver. Se um utilizador tentar um ataque de prompt injection ou enviar texto altamente tóxico, o Input Rail interceta a mensagem imediatamente. Interrompe o pipeline e devolve uma recusa predefinida. O modelo principal nunca processa o texto malicioso, poupando compute e prevenindo um exploit. Se o input for seguro, o sistema avalia os Dialog Rails. Estes gerem o fluxo esperado da conversa. Se um utilizador pedir ao bot de suporte uma opinião sobre um concorrente, um Dialog Rail identifica o tópico. Força o bot a seguir um caminho predeterminado, talvez respondendo que só discute os seus próprios produtos. Os Dialog Rails impedem que o modelo se desvie do tópico ou responda a perguntas que não lhe dizem respeito. A seguir, quando o teu bot pesquisa na tua knowledge base para fundamentar a sua resposta, os Retrieval Rails entram em ação. Estes inspecionam os chunks de texto extraídos da base de dados antes de serem anexados ao prompt do modelo. Se uma pesquisa mal configurada capturar acidentalmente um documento interno de recursos humanos em vez de um manual público, o Retrieval Rail deteta a informação sensível e remove-a da context window. Se a conversa exigir que o bot execute uma tarefa, os Execution Rails entram em ação. Controlam que ações personalizadas o modelo pode acionar. Quando o modelo pede para executar código ou fazer uma tool call externa, o Execution Rail verifica se essa ação específica é permitida, dado o estado atual da conversa. Bloqueia a execução de comandos não autorizados. Por fim, temos os Output Rails. Esta é a última linha de defesa. Depois de o modelo gerar uma resposta, o Output Rail avalia o texto antes de chegar ao utilizador. Verifica se há factos alucinados, tom inadequado ou fugas de dados sensíveis. Se o texto não passar na verificação, o Output Rail interceta-o e altera ou bloqueia a mensagem final. Esta arquitetura muda fundamentalmente a forma como constróis aplicações generativas. Deixas de depender de um motor probabilístico para policiar o seu próprio comportamento e, em vez disso, constróis uma rede de segurança determinística que controla inputs, lógica e outputs de forma independente. Já agora, se achas estes episódios úteis e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 2 de 10. Escrever raw Python para gerir state machines de diálogo complexas e ramificadas é um verdadeiro pesadelo. No momento em que o teu utilizador se desvia de um script rígido, a tua lógica hardcoded quebra. A arquitetura de configuração do NeMo Guardrails resolve isto tratando as conversas como flows event-driven, em vez de código estático. O NeMo Guardrails separa a mecânica da tua aplicação da lógica da tua conversa. Isto acontece através de duas peças de configuração distintas. Primeiro, tens o teu ficheiro de configuração YAML. Ele trata de todo o wiring do modelo. É onde declaras o teu language model principal, defines os teus embedding models e registas ações personalizadas da aplicação. O ficheiro YAML liga a infraestrutura subjacente. Ele fornece o engine, mas não sabe absolutamente nada sobre o que o utilizador vai realmente dizer. A lógica da conversa em si é governada pelo Colang 2.0. O Colang é uma linguagem de modelação de interações event-driven. Em vez de escreveres código imperativo standard com conditional statements infinitos para fazeres o tracking de onde o utilizador está numa conversa, defines flows. Um flow modela uma sequência de interações. Quando um utilizador envia uma mensagem, isso gera um evento. A state machine apanha este evento, procura um flow ativo que corresponda à interação e dita o próximo passo do assistente. Esta é a parte que interessa. O Colang usa Natural Language Descriptions para preencher a lacuna entre o código estrito e a ambiguidade humana. Em vez de escreveres regular expressions complexas para fazer o parse de uma mensagem do utilizador, instruis o sistema usando linguagem humana diretamente na lógica do teu flow. Juntas estas descrições com o generation operator, que se escreve simplesmente como três pontos. Quando a state machine encontra esses três pontos, pausa temporariamente a execução. Passa o contexto atual e a tua natural language description para o language model subjacente, pedindo-lhe que gere ou extraia o valor exato de que precisas. Vamos olhar para um cenário concreto, como reservar um bilhete de avião. Precisas de saber quando é que o utilizador quer viajar. No teu ficheiro Colang, defines um flow de reserva de voo. Dentro desse flow, dizes ao sistema para esperar que o utilizador fale. Assim que ele falar, precisas de extrair a data. Declaras uma context variable, talvez chamada flight date. Atribuis-lhe o valor de uma natural language description, escrevendo literalmente a frase "a data em que o utilizador quer voar", imediatamente seguida pelo generation operator, aqueles três pontos. Quando o utilizador diz "Preciso de um bilhete para a próxima terça-feira", a state machine do Colang captura o evento. Chega à tua variable assignment. Passa a mensagem do utilizador e a tua natural language instruction para o language model. O modelo lê o contexto, identifica "próxima terça-feira" como o target value, e devolve-o. O generation operator é resolvido, e a tua context variable agora guarda com segurança a data extraída. O teu flow prossegue então para o passo seguinte, que pode envolver chamar uma API de reservas externa definida na tua configuração YAML. O verdadeiro poder desta arquitetura é que paras de lutar contra dialogue states com código rígido. Permites que um ficheiro YAML fixe a infraestrutura estática, e deixas o Colang usar a capacidade de raciocínio do language model para navegar na realidade imprevisível da conversa humana. Gostava de tirar um momento para te agradecer por ouvires — ajuda-nos imenso. Tem um excelente dia!

Olá, daqui fala o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 3 de 10. Depender de um modelo massivo com setenta mil milhões de parâmetros para fazer moderação básica de conteúdo é um enorme desperdício de compute. É lento, caro, e tira poder de processamento à geração de respostas reais. A solução é a Segurança de Conteúdo Especializada com o Nemotron NIM. Em vez de pedires ao teu modelo principal da aplicação para escrever código e verificar a toxicidade, divides a carga de trabalho. O modelo principal lida com o raciocínio complexo e a geração. Um segundo modelo, muito mais pequeno, lida com a segurança. Especificamente, estamos a falar do Llama 3 point 1 Nemotron Safety Guard 8B V3. Este é um modelo com oito mil milhões de parâmetros, com fine-tuning feito inteiramente para uma única tarefa: avaliar a segurança do conteúdo. Corre como um microserviço standalone, ou NIM, que o NeMo Guardrails chama através de uma API. Para configurar isto, defines o Nemotron NIM na tua configuração de guardrails como um modelo distinto. Rotulas o seu tipo como content safety, enquanto o teu modelo principal continua a ser o tipo main. Esta distinção é crucial porque o Guardrails encaminha o tráfego de forma diferente com base nestas labels. Uma vez configurado, ativas o safety guard como um input rail e um output rail. Quando um utilizador envia um prompt, o Guardrails interceta-o antes mesmo de chegar ao teu modelo principal. Envia o prompt para o NIM de segurança Nemotron. O NIM avalia o texto contra vinte e três categorias específicas de conteúdo inseguro. Estas categorias abrangem tudo, desde discurso de ódio e violência até conteúdo sexual e planeamento criminoso. Considera uma aplicação multilingue onde um utilizador submete um prompt em francês, a pedir instruções passo a passo sobre como fazer uma ligação direta a um carro. O input rail apanha isto. O Guardrails envia o texto em francês para o NIM Nemotron. Como o modelo de segurança é treinado com dados de segurança multilingues, entende a intenção independentemente do idioma. Sinaliza o request como pertencendo à categoria de aconselhamento criminoso e devolve um sinal de unsafe ao Guardrails. O Guardrails interrompe então imediatamente o processo e devolve uma mensagem de recusa standard ao utilizador. O teu modelo principal nem sequer vê o prompt, poupando-te o custo de inference de processar um request tóxico. Exatamente a mesma lógica aplica-se de forma inversa aos output rails. Se um prompt aparentemente inofensivo de alguma forma enganar o modelo principal e o levar a gerar uma resposta unsafe, o Guardrails interceta esse texto gerado antes de chegar ao utilizador. Envia o output para o NIM de segurança, verifica-o contra essas mesmas vinte e três categorias e bloqueia-o se violar as regras. Configurar isto requer atualizar os teus ficheiros de configuração. Declaras o modelo Nemotron na tua lista de modelos, apontando-o para o teu endpoint do NIM. Depois, ativas os flows default de self-check input e self-check output, dizendo explicitamente ao Guardrails para usar o teu modelo de content safety para estas verificações. Não precisas de escrever prompts customizados a instruir o modelo sobre como avaliar a toxicidade. O modelo Nemotron espera um formato de prompt muito específico para avaliar texto, e o NeMo Guardrails formata essa chamada de API automaticamente nos bastidores. Só tens de apontar os rails para o NIM e deixá-lo fazer a classificação. Fazer o decoupling da tua lógica de moderação num modelo dedicado e mais pequeno garante que o modelo principal da tua aplicação gasta os seus ciclos a gerar valor, enquanto um guard especializado lida eficientemente com a segurança de perímetro. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 4 de 10. A maneira mais fácil de evitar que o teu chatbot crie um desastre de relações públicas é garantir que ele simplesmente se recusa a falar sobre o desastre. Não podes confiar num modelo de linguagem de uso geral para rejeitar de forma fiável, e por si só, todos os tópicos irrelevantes ou arriscados. É por isso que usamos a imposição de limites de domínio com controlo de tópicos. Os modelos de linguagem gerais estão sempre ansiosos por agradar. Se um utilizador fizer uma pergunta inteligente, o modelo vai tentar responder. Se criares um bot de apoio ao cliente, só queres que ele fale sobre apoio ao cliente. Precisas de um limite rigoroso. Para criar este limite, usas o Llama 3.1 NemoGuard 8B TopicControl NIM. Este é um modelo especializado, concebido para uma tarefa específica. Não gera respostas conversacionais. Ele avalia. Imagina um bot de suporte de telecomunicações. O seu trabalho é ajudar os utilizadores com faturas de telefone, falhas de rede e planos de dados. Um utilizador liga-se ao chat e pede a opinião do bot sobre uma eleição política recente. Sem guardrails, o teu modelo principal recebe o prompt, processa-o e pode gerar uma resposta inadequada. Com o NeMo Guardrails, configuras um Input Rail. Um Input Rail interceta o request do utilizador antes que qualquer outra coisa aconteça. O modelo de linguagem principal nem sequer vê o request. Quando o utilizador pergunta sobre a eleição, o guardrail encaminha o input diretamente para o modelo TopicControl. Controlas o comportamento deste modelo definindo diretrizes rigorosas no seu system prompt. Para o teu bot de telecomunicações, o teu system prompt define que os tópicos aceitáveis são faturação, estado da rede e gestão de conta. O modelo TopicControl recebe o prompt do utilizador e compara-o com essas diretrizes exatas. De seguida, devolve uma classificação rígida. Retorna uma avaliação de on-topic ou off-topic. Se o utilizador perguntar porque é que as suas tarifas de roaming estão altas, o modelo TopicControl lê o prompt, verifica as diretrizes e retorna on-topic. O guardrail abre a porta, e o prompt do utilizador passa para o teu modelo conversacional principal para gerar uma resposta útil. Quando o utilizador pergunta sobre a eleição política, o modelo TopicControl avalia o prompt em relação às diretrizes de telecomunicações. Reconhece a incompatibilidade e retorna off-topic. O guardrail interrompe imediatamente o pipeline. Impede que o request chegue ao teu modelo principal. Em vez disso, o guardrail aciona uma resposta de recusa estática e predefinida. O bot diz ao utilizador que está equipado apenas para lidar com serviços de telecomunicações. Usar um modelo dedicado para controlo de tópicos separa a lógica de avaliação da lógica conversacional. Não estás a desperdiçar compute cycles caros a pedir a um modelo enorme e de uso geral para descobrir se tem permissão para responder a uma pergunta. Usas um modelo mais pequeno e altamente otimizado, com oito mil milhões de parâmetros, para atuar como um segurança à porta. Isto mantém os limites do teu domínio estritamente impostos, sem exigir um prompt engineering complexo e frágil no teu modelo principal. A maneira mais segura de lidar com um request fora dos limites é garantir que o teu motor de raciocínio principal permaneça completamente alheio ao facto de o request ter sequer sido feito. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 5 de 10. Se o teu sistema de retrieval-augmented generation ingerir uma base de dados de colaboradores não anonimizada, já cometeste uma violação de conformidade antes mesmo de o modelo de linguagem gerar uma única palavra. Assim que dados sensíveis entram no contexto do prompt, perdes o controlo sobre para onde eles vão. A Deteção e Mascaramento Dinâmico de PII é a forma como intercetas esses dados em trânsito. Vamos olhar para um bot interno de recursos humanos. Um gestor faz uma pergunta geral ao bot sobre a política de avaliação de desempenho da empresa. O bot pesquisa na base de conhecimento interna. A pesquisa devolve o documento de política relevante, mas os chunks de texto recuperados incluem acidentalmente o registo específico de um colaborador anexado ao ficheiro, completo com nome, morada e email. Se o sistema passar esses chunks recuperados diretamente para o modelo de linguagem, esses dados sensíveis tornam-se parte da context window. O NeMo Guardrails lida com isto posicionando-se entre os componentes da tua aplicação e filtrando a stream de texto. Oferece duas abordagens distintas. A deteção envolve identificar informações pessoalmente identificáveis e tomar uma ação drástica, como bloquear completamente o prompt ou lançar um erro. O mascaramento é mais flexível. Encontra a informação sensível e substitui-a por um placeholder genérico on the fly. O texto john@example.com torna-se uma string entre parênteses retos a dizer EMAIL. A base de dados subjacente permanece completamente intacta. Para executar isto, o sistema de guardrails depende de ferramentas externas especializadas. Configuras a framework para chamar um engine como o Microsoft Presidio ou o GLiNER. O Presidio normalmente usa pattern matching, expressões regulares e lógica baseada em regras para detetar formatos padrão, como números de telefone ou cartões de crédito. O GLiNER, que significa Generalist and Lightweight Indicator for Named Entity Recognition, usa um pequeno modelo de machine learning para identificar entidades com base no contexto envolvente. Defines um array de tipos de entidades que te interessam, e o engine selecionado trata da extração. Esta proteção opera em três pontos específicos do fluxo da aplicação. O primeiro é o input rail. Se um utilizador digitar o seu próprio número de segurança social na janela de chat, o input rail examina a string recebida e mascara o número antes mesmo de o modelo de linguagem receber o prompt. O modelo processa o request usando o placeholder, completamente alheio ao número real. O segundo ponto é o retrieval rail. Esta é a parte que importa. Quando o teu sistema consulta uma vector database e recupera chunks de texto brutos, o guardrail interceta esses chunks antes de serem injetados no prompt template final. Examina o texto recuperado, remove os nomes e moradas reais e substitui-os pelas tags mascaradas. O teu mecanismo de retrieval pode extrair dados de fontes de dados desorganizadas e não anonimizadas, mas o modelo de linguagem fica protegido dos detalhes sensíveis. O terceiro ponto é o output rail. Se o modelo de linguagem gerar dados sensíveis, seja por alucinação ou porque algum dado passou de alguma forma pelos rails anteriores, o output rail atua como um checkpoint final. Examina a resposta gerada e mascara o texto sensível antes que chegue ao ecrã do utilizador. Como tudo isto acontece dinamicamente em memória durante a execução de um único request, a tua arquitetura de dados não precisa de ser alterada. Evitas o enorme overhead de engenharia de manter bases de dados duplicadas e pré-anonimizadas apenas para correr uma aplicação de chat. A forma mais segura de lidar com dados sensíveis numa aplicação de modelo de linguagem é garantir, em primeiro lugar, que o modelo nunca processe os dados reais. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 6 de 10. Alguns dos ataques de prompt injection mais devastadores não se parecem nada com engenharia social inteligente. Para um humano, parecem apenas um completo disparate. O utilizador não está a tentar enganar o bot com um enigma, mas sim sobrecarregá-lo matematicamente. Detetar isto requer Jailbreak Detection através de Perplexity Heuristics. Considera um cenário de ataque específico. Um utilizador malicioso quer que a tua aplicação faça output de algo prejudicial, mas sabe que tens instruções de segurança no teu system prompt. Para contornar essas instruções, ele pega no seu pedido malicioso e faz um padding com uma enorme string de caracteres aleatórios, símbolos obscuros ou palavras sem sentido. Quando o language model processa este input, os mecanismos de attention ficam sobrecarregados pelo enorme volume de tokens imprevisíveis. O modelo perde o rasto do seu safety alignment subjacente e simplesmente responde ao pedido malicioso. Não consegues detetar este ataque com filtros de keywords standard, porque o padding é aleatório. Poderias usar outro language model para avaliar o prompt recebido à procura de padrões adversários, mas isso adiciona uma enorme penalidade de latência a cada pedido do utilizador. Precisas de um filtro que seja rápido, matemático e que corra localmente. É aqui que entra a perplexity. A perplexity é uma métrica standard que mede o quão previsível um pedaço de texto é para um language model. Frases humanas normais seguem padrões previsíveis, resultando numa perplexity baixa. Uma string de caracteres aleatórios, ou uma sequência bizarra de palavras não relacionadas, é altamente imprevisível. Isso gera uma perplexity alta. Ao calcular a perplexity de um prompt recebido, obténs uma medida estatística da sua aleatoriedade. O NeMo Guardrails usa este conceito para bloquear ataques de gibberish através de duas heurísticas principais. A primeira é Length per Perplexity. Ataques adversários geralmente exigem uma longa string de garbage text para desviar com sucesso o modelo principal. Uma string curta de nonsense é normalmente ignorada pelo mecanismo de attention. Esta heurística calcula um rácio usando o comprimento total do prompt e o seu score geral de perplexity. Se um prompt for invulgarmente longo e altamente imprevisível, ultrapassa um threshold matemático predefinido. O guardrail interceta o input, sinaliza-o como um potencial jailbreak, e bloqueia o pedido antes sequer que o teu modelo principal o veja. A segunda heurística lida com uma variação mais cirúrgica do mesmo ataque. Às vezes, um atacante esconde o gibberish. Escreve uma frase completamente normal, de baixa perplexity, no meio do seu prompt, mas acrescenta um bloco denso de tokens aleatórios mesmo no fim. Se calculares a perplexity em todo o prompt, o texto normal pode diluir o score médio o suficiente para passar pelo primeiro filtro. Para combater isto, o NeMo Guardrails usa Prefix e Suffix Perplexity. Em vez de olhar para o prompt inteiro, esta heurística isola um número fixo de tokens logo no início e no fim do input do utilizador. Calcula a perplexity destas fronteiras de forma independente. Se o utilizador anexar um payload adversário de caracteres aleatórios ao final de uma pergunta normal, o score de suffix perplexity dispara. O guardrail deteta a anomalia na fronteira e descarta o pedido. Todo este processo acontece sem fazer uma API call externa para um language model massivo. Depende de um modelo local mais pequeno para calcular os scores de perplexity, o que mantém o overhead de latência num mínimo absoluto. Ao remover o significado semântico do texto, paras de analisar o que o utilizador está a tentar dizer e começas a analisar a forma matemática das suas palavras. As perplexity heuristics permitem-te bloquear ataques adversários complexos usando estatísticas puras, protegendo a tua aplicação à velocidade da matemática. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 7 de 10. Dar acesso a um modelo de linguagem para executar queries numa base de dados é como entregar as chaves da tua base de dados a um estranho. Dizes ao modelo para ir buscar dados de utilizador, mas um prompt inteligente engana-o, fazendo com que adicione um comando para fazer drop a uma tabela. Proteger agentic workflows com execution rails é como impedes que agentes autónomos comprometam o teu backend. A maioria dos guardrails foca-se na resposta do chat. Eles impedem que o modelo use linguagem imprópria ou fuja do assunto. Os execution rails fazem algo completamente diferente. Eles protegem as tools que o agente usa. Quando um agente decide usar uma tool para correr um script Python gerado ou executar uma query SQL, o execution rail interceta o payload exatamente no ponto de transferência, mesmo antes de a tool correr. O NeMo Guardrails lida com esta validação usando regras YARA. YARA é um motor de pattern-matching tradicionalmente usado por analistas de cibersegurança para identificar malware com base em assinaturas textuais ou binárias específicas. Nesta framework, a NVIDIA fornece um catálogo predefinido de padrões YARA criados especificamente para apanhar vulnerabilidades de modelos de linguagem. O motor de guardrails passa o input da tool por estas regras YARA para procurar assinaturas de ataques conhecidos. Este catálogo foca-se em quatro ameaças específicas. A primeira é SQL injection, onde o modelo gera comandos de base de dados com modificações maliciosas. A segunda é code injection, onde o agente tenta executar comandos de sistema não autorizados dentro de um script Python gerado dinamicamente. A terceira é template injection, onde um atacante manipula motores de server-side rendering. Por fim, deteta cross-site scripting, bloqueando payloads desenhados para executar scripts maliciosos num web browser. Imagina um agente encarregue de receber um request de um utilizador, escrever um script Python para processar alguns dados locais e corrê-lo. Se um utilizador esconder um comando de sistema para expor variáveis de ambiente no seu prompt, o modelo de linguagem pode incluir cegamente esse comando no script Python final. O execution rail apanha isto. Ele faz o scan do código Python gerado, faz match com a regra YARA para code injection, e sinaliza o payload antes sequer de o motor de execução o ver. Quando o sistema deteta um padrão malicioso, toma uma ação com base na tua configuração. Tens duas opções. A primeira ação é reject. Isto bloqueia completamente a execução da tool. O workflow para, o código malicioso nunca corre, e o sistema devolve uma resposta segura. A segunda ação é omit. Isto diz ao guardrail para remover a string maliciosa específica do payload, mas permite que a tool execute o que sobrar. A escolha entre reject e omit depende inteiramente da tool. Se o teu agente estiver a correr uma query SQL contra uma base de dados, reject é a única opção segura. Omitir uma string de uma query SQL complexa vai provavelmente resultar em sintaxe malformada ou acesso imprevisível a dados. Omit é geralmente reservado para tarefas básicas de processamento de texto, onde remover uma string maliciosa ainda deixa um payload utilizável e seguro. Configuras estas proteções diretamente nos teus ficheiros YAML, ativando os agentic security rails e mapeando-os para tools específicas. O motor YARA subjacente faz o trabalho pesado, fazendo match aos padrões predefinidos sem exigir que escrevas expressões regulares personalizadas. Os execution rails tratam o modelo de linguagem como um utilizador não fiável, obrigando-te a validar cada comando que ele gera antes de tocar na tua infraestrutura. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 8 de 10. Um bot dizer que não sabe a resposta é um pouco irritante. Um bot financeiro declarar com confiança que a tua empresa falhou o objetivo de receitas do terceiro trimestre por cinquenta milhões de dólares, quando na verdade o superou, é um desastre. Para impedir que o teu sistema de Retrieval-Augmented Generation invente números e destrua a tua credibilidade, precisas de Grounding RAG: Alucinações e Fact-Checking. Vamos esclarecer uma confusão comum logo à partida. O fact-checking e a deteção de alucinações são duas coisas diferentes. A deteção de alucinações normalmente envolve fazer a mesma pergunta ao language model várias vezes. Se as amostras resultantes se contradisserem, é provável que o modelo esteja a alucinar. O fact-checking avalia uma única resposta gerada em relação a um conjunto específico de documentos de confiança. O NeMo Guardrails usa fact-checking para manter as tuas pipelines RAG grounded. Os language models preveem texto. Eles não sabem intrinsecamente o que é verdade. Num setup RAG standard, vais buscar chunks de texto à tua base de dados, passas isso ao modelo e pedes-lhe que responda com base apenas nesse texto. Às vezes, o modelo continua a alucinar, misturando o seu conhecimento pré-treinado com os teus dados, ou simplesmente inventando uma métrica que soa plausível. O NeMo Guardrails impede isto usando um output rail chamado self check facts. Quando ativo, este rail interceta a resposta gerada pelo modelo antes de chegar ao utilizador. O sistema trata esta resposta não verificada como uma hipótese. A seguir, extrai os snippets de texto exatos que foram recuperados da tua base de dados. Estes snippets são guardados automaticamente numa variável de contexto chamada relevant chunks. Esta variável é a evidência concreta. O guardrail corre então uma avaliação. Passa a hipótese e a evidência para um modelo avaliador. O avaliador verifica se a evidência comprova estritamente a hipótese. Voltando ao nosso bot financeiro, se o texto gerado alegar um número de receitas específico, mas esse número não existir em lado nenhum na variável relevant chunks, o avaliador sinaliza-o como ungrounded. O guardrail bloqueia imediatamente a resposta alucinada. Em vez disso, devolve uma mensagem de fallback segura, admitindo que não tem informação suficiente. Usar um language model de propósito geral para fazer fact-checking é fácil de configurar, mas traz uma penalização. Adiciona latência, gasta tokens, e o modelo avaliador pode, por vezes, confundir-se com contexto denso. Não és obrigado a usar o setup default. Podes substituir a verificação standard baseada em prompts por ferramentas externas especializadas. Abordagens que usam modelos como AlignScore ou Patronus Lynx são altamente eficazes aqui. Estes são modelos criados de propósito, treinados exclusivamente para detetar inconsistências entre um texto de origem e uma afirmação gerada. Quando passas os relevant chunks e a hipótese por um destes modelos especializados, fazes bypass por completo ao avaliador do language model standard. Isto proporciona um veredicto mais rápido, mais barato e, muitas vezes, mais rigoroso sobre se o teu bot está a dizer a verdade. Esta é a parte que importa. Fazer o grounding de uma pipeline RAG não é sobre tornar o teu modelo generativo inerentemente mais verdadeiro. É sobre tratar cada palavra gerada como uma afirmação suspeita que tem de sobreviver a um escrutínio rigoroso contra os teus dados de origem exatos antes de ver a luz do dia. Se nos quiseres ajudar a continuar a fazer estes episódios, podes apoiar o programa procurando por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 9 de 10. Passas semanas a afinar os teus filtros de input para bloquear prompts de texto maliciosos. E depois, um utilizador contorna todo o teu trabalho árduo simplesmente ao tirar um screenshot do seu prompt malicioso e ao fazer o upload como imagem. Os filtros de texto são completamente cegos a isto. Para detetar isto, precisas de Multimodal Content Safety. Imagina um utilizador que faz o upload da foto de uma espingarda de assalto personalizada e escreve a pergunta: como é que modifico isto para disparar mais rápido. Um guardrail de texto standard vê apenas uma pergunta sobre como modificar um objeto genérico. Não faz ideia de que o objeto é uma arma. A intenção maliciosa só existe quando combinas a imagem e o texto. Lidamos com isto utilizando um Vision Language Model a atuar como um LLM-as-a-judge. No NeMo Guardrails, configuras isto na fase de input rail. Antes mesmo que o pedido do utilizador chegue ao teu modelo conversacional principal, o guardrail interceta o payload multimodal. Os dados da imagem geralmente chegam num de dois formatos. Ou é uma string em Base64 embutida diretamente na API call, ou é um URL direto. As strings em Base64 tornam o payload do request imediato muito maior, mas garantem que a imagem está disponível. Os URLs mantêm o payload inicial leve, mas exigem que o modelo de avaliação tenha acesso de rede outbound para ir buscar o ficheiro. De qualquer forma, configuras o input rail com um prompt template específico, concebido para avaliação multimodal. Este template contém uma rubrica rigorosa que define categorias de conteúdo inseguro, como violência, atos ilegais, automutilação ou armas. O guardrail constrói um request de avaliação. Ele empacota a tua rubrica de segurança, o texto do utilizador e a imagem do utilizador. Envia este pacote combinado para o vision model e força o modelo a responder com um structured output, tipicamente uma simples label de safe ou unsafe. O modelo atua estritamente como um juiz. Ele analisa a arma na foto, lê o request sobre como a modificar, e verifica o significado combinado em relação às tuas categorias restritas. Se o vision model detetar uma violação, devolve um veredicto de unsafe. O input rail sinaliza o request, bloqueia o seu avanço e aciona uma mensagem de recusa predefinida. O teu modelo de aplicação principal nem sequer vê o request malicioso. Presta atenção a esta parte em relação aos limites de contexto. Os vision models processam imagens ao convertê-las em tokens. Dependendo da arquitetura do modelo e da resolução da imagem, uma única imagem pode consumir milhares de tokens. A tua string em Base64 ou URL da imagem, combinada com o texto do utilizador e a tua rubrica de segurança multicategoria, tem de caber inteiramente dentro da context window do vision model. Se passares imagens enormes e de alta resolução juntamente com um texto de prompt longo, vais exceder o limite de tokens. A avaliação do guardrail vai falhar, ou o modelo vai truncar o input e não vai detetar a violação de todo. Tens de implementar um pré-processamento para redimensionar ou comprimir as imagens antes que cheguem ao guardrail, mantendo o consumo de tokens previsível. Avaliar texto e imagens isoladamente já não é suficiente, porque o abuso moderno esconde-se exatamente no espaço onde essas duas modalidades se intersetam. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. NVIDIA NeMo Guardrails, episódio 10 de 10. Criar regras de segurança diretamente num script Python é ótimo para testes, mas péssimo para escalar numa empresa poliglota. Se o teu frontend usa Node JS e o teu backend é uma mistura de Python e Go, não podes duplicar a tua lógica de segurança em todas as linguagens. A solução é usar os três Enterprise Integration Patterns para o NeMo Guardrails. Imagina um cenário de migração típico. Criaste um protótipo de um bot de apoio ao cliente usando LangChain. Adicionaste guardrails para o impedir de falar sobre concorrentes. Funciona perfeitamente no teu portátil. Agora precisas de migrar este protótipo para uma arquitetura de microserviços escalável em produção, onde várias aplicações o vão consultar. Tens três maneiras principais de integrar os guardrails para que isso aconteça. O primeiro método é o SDK nativo de Python, especificamente um objeto chamado LLMRails. Este é o motor principal. Se estiveres a construir um backend em Python de raiz, sem depender de frameworks de orquestração, usas este. Instancias o LLMRails, apontas para o teu diretório de configuração que contém os teus ficheiros Colang e YAML, e usas isso para processar inputs. Passas uma lista de dicionários de mensagens que representam o histórico da conversa, e ele devolve a resposta avaliada. É direto e dá-te acesso raw às mecânicas subjacentes dos guardrails. Como já tens um protótipo em LangChain, reescrever tudo para usar o SDK raw é um desperdício de esforço. É aqui que se aplica o segundo método, que é a integração com LangChain usando o RunnableRails. O NeMo Guardrails integra-se nativamente na LangChain Expression Language. Crias uma instância de RunnableRails carregada com a tua configuração e anexas diretamente à tua chain existente. Se a tua chain recebe um prompt, vai buscar documentos e chama um modelo de linguagem, envolves todo esse fluxo com o runnable do guardrail. O guardrail interceta o input antes de chegar à tua chain e avalia o output depois da tua chain gerar uma resposta. O código principal da tua aplicação praticamente não muda, mas a tua lógica de LangChain agora está protegida. Esta é a parte que importa à escala. Pensa no contexto empresarial mais amplo. Outra equipa quer usar exatamente as tuas mesmas políticas de segurança, mas estão a construir um web gateway em Node JS ou um router de alta performance em Go. Eles não podem importar um objeto LangChain de Python. Para isso, usas o terceiro método, o API Server standalone. O NeMo Guardrails inclui um servidor built-in que podes correr através da linha de comandos ou fazer deploy como um container. Inicias o servidor e apontas para a tua pasta de configuração. Ele expõe imediatamente endpoints REST que imitam a API standard da OpenAI. Para as tuas aplicações em Go ou Node JS, o servidor de guardrails parece exatamente um modelo de linguagem standard. Elas enviam requests JSON standard para o endpoint de chat completions. O servidor lida com os guardrails de input, comunica com o modelo subjacente real, processa os guardrails de output, e devolve o texto limpo. Desacoplar as tuas regras da lógica da tua aplicação usando um servidor standalone é a única maneira fiável de impor políticas de segurança consistentes em toda a organização. Consulta a documentação oficial para experimentares estes integration patterns na prática, ou visita a DEV STORIES DOT EU para sugerires tópicos para futuras séries. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.