Garantindo implantações de RAG seguras e cientes de permissões
Na área acelerada da inteligência artificial, Retrieval Augmented Generation (RAG) surgiu como uma abordagem poderosa para aprimorar as capacidades de modelos generativos, como a série GPT da OpenAI e o Gemini do Google. No entanto, com grande potencial vem uma responsabilidade significativa, especialmente quando se trata de proteger dados sensíveis e garantir a conformidade com regulamentações de privacidade.
À medida que as organizações dependem cada vez mais de soluções impulsionadas por IA, compreender as implicações de segurança dessas tecnologias é crucial. Implementar medidas de segurança robustas que não apenas protejam os dados, mas também construam a confiança dos usuários, é essencial para aplicações RAG prontas para produção.
Em um recente Unstructured Data Meetup organizado pela Zilliz, Oz Wasserman, Co-Founder da Opsin, destacou considerações-chave de segurança para implantações RAG, enfatizando a importância da anonimização de dados, criptografia forte, validação de entrada/saída e controles de acesso robustos, entre outras medidas críticas de segurança.
Neste blog, discutiremos os principais aspectos de implantações RAG seguras e cientes de permissões. Também percorreremos um exemplo de notebook de um pipeline RAG usando o banco de dados vetorial Milvus e pós-processadores do LlamaIndex projetados para remover informações sensíveis, garantindo privacidade de dados e conformidade.
Diagrama da Arquitetura RAG
Em sua palestra, Oz começou explicando uma arquitetura RAG fundamental semelhante à mostrada na Figura 1. Essencialmente, um sistema RAG aprimora um modelo de linguagem grande (LLM) integrando uma base de conhecimento alimentada por banco de dados vetorial que armazena documentos para recuperar conteúdo relevante em resposta à consulta de um usuário. Essa abordagem melhora a precisão, garante maior relevância contextual e minimiza alucinações frequentemente vistas em saídas de LLMs independentes.
No entanto, esse pipeline básico carece de medidas de segurança específicas, a menos que elas sejam integradas nas várias etapas. Oz destacou um gráfico de fluxo de trabalho RAG (veja a Figura 2) de Ken Huang, da DistributedApps.ai, onde controles de segurança podem ser implementados ao longo de todo o pipeline RAG:
Etapa de Fonte de Dados/VectorDB
Etapa de Recuperação
Etapa de Geração
Figura- Banco de dados vetorial facilitando chatbot RAG.png
Figura 1: Arquitetura RAG Básica
Figura 2- Arquitetura RAG Detalhada (Autor- Ken Huang)
Figura 2: Arquitetura RAG Detalhada (Autor: Ken Huang)
Etapa de Fonte de Dados/VectorDB
Bancos de dados vetoriais, como Milvus e Zilliz Cloud (o Milvus gerenciado), armazenam, indexam e recuperam embeddings vetoriais convertidos de dados não estruturados. Eles são repositórios críticos de informações valiosas. No entanto, também podem se tornar alvos de violações de dados ou acesso não autorizado, tornando necessária a implementação de estratégias de proteção robustas, como criptografia, controle de acesso ou anonimização de dados.
Figura 3- Fonte de Dados:Controles de Segurança do VectorDB.png
Figura 3: Controles de Segurança da Fonte de Dados/VectorDB
A primeira ameaça à segurança pode ser encontrada na anonimização de dados. Os dados contêm informações pessoais sensíveis, comumente chamadas de Informações de Identificação Pessoal (PII). Esses dados devem ser anonimizados para proteger a privacidade individual. Esta etapa é obrigatória antes de qualquer processamento de dados para garantir que essas informações não possam ser rastreadas até indivíduos específicos.
Depois que os dados forem anonimizados, eles podem ser indexados e embeddings podem ser gerados para permitir a busca semântica para recuperar conteúdo relevante. Nesta etapa, é importante definir quem pode armazenar e recuperar os dados no e do banco de dados vetorial, em outras palavras, quem tem acesso a eles. Implementar controles de acesso rigorosos é essencial para impedir o acesso não autorizado, o que poderia resultar em manipulação ou vazamento de dados.
O controle de acesso pode ser dividido em várias etapas:
Autenticação: Garantir que o usuário verifique sua identidade, normalmente usando métodos como OAuth 2.0.
Autorização: Com base na identidade verificada, permissões específicas e direitos de acesso são concedidos ao usuário.
Rastreabilidade: Monitorar o acesso para garantir que quaisquer tentativas de acessar dados sejam registradas e possam ser rastreadas, fornecendo uma trilha de auditoria para conformidade de segurança.
Essas medidas ajudam a proteger o banco de dados vetorial e garantem que apenas usuários autorizados possam interagir com dados sensíveis.
Outra camada de segurança pode ser adicionada com criptografia para tornar os dados ininteligíveis em repouso (quando armazenados) ou em trânsito (quando transmitidos). A criptografia tradicional usa chaves de criptografia, mas técnicas mais avançadas, como Privacidade Diferencial ou Descentralização & Sharding, também estão sendo cada vez mais adotadas para aprimorar a segurança dos dados.
Zilliz Cloud é um serviço de banco de dados vetorial totalmente gerenciado, desenvolvido com Milvus. Ele oferece todas essas medidas essenciais de segurança de dados. Ele pode fornecer outras soluções, como Private Link, para evitar acesso pela internet pública, backup e restauração para garantir backups de dados regulares e seguros, e recuperação da base de conhecimento em caso de perda de dados.
Figura 6- Segurança de nível empresarial em várias camadas da Zilliz
Figura 6: Segurança de nível empresarial em várias camadas da Zilliz (Fonte)
Etapa de Recuperação
A etapa de recuperação é outro passo crítico em que as preocupações de segurança devem ser abordadas. Como na etapa anterior, controlar o acesso à base de conhecimento por meio de consultas é essencial. Além disso, durante esta etapa, vários riscos de segurança também precisam ser mitigados:
Validação de Consultas: Validar consultas é crucial para prevenir ataques de injeção de prompt. Essa abordagem garante que as entradas dos usuários não explorem vulnerabilidades do sistema, potencialmente levando a acesso não autorizado ou manipulação dos dados.
Riscos da Busca por Similaridade: Também é importante gerenciar os riscos associados às buscas por similaridade. Medidas adequadas devem estar em vigor para garantir que a busca por similaridade não exponha inadvertidamente informações sensíveis nem forneça acesso não autorizado a dados restritos.
Figura 7- Etapa de Validação de Consultas
Figura 7: Etapa de Validação de Consultas
Oz compartilhou um exemplo (veja a Figura 8) de injeção de prompt ao apresentar um modelo interno. Este é um bom exemplo de manipulação de prompt, em que o prompt é alterado para recuperar dados.
Figura 8- Exemplo de Injeção de Prompt
Figura 8: Exemplo de Injeção de Prompt
Além disso, Oz discutiu vários riscos associados à busca por similaridade, incluindo:
Vazamento de Dados: Ao manipular consultas de similaridade, os atacantes podem influenciar o mecanismo de busca para recuperar dados sensíveis indiretamente.
Manipulação de Resultados de Busca: Os atacantes poderiam modificar o processo de busca para influenciar quais resultados são recuperados, levando à possível exposição de informações restritas.
Reconhecimento e Análise de Padrões: Os atacantes podem analisar padrões em consultas e respostas de busca para mapear a estrutura do banco de dados e obter insights sobre os dados armazenados.
Exaustão de Recursos: Consultas contínuas ou excessivas poderiam levar a condições de negação de serviço, esgotando recursos do sistema e reduzindo a disponibilidade para outros usuários.
Vemos que técnicas de segurança semelhantes devem ser implementadas para a etapa de recuperação, como controle de acesso ou validação de dados. Além disso, a criptografia (em trânsito) deve ser considerada, pois os dados são transmitidos entre componentes.
Etapa de Geração
A etapa final no pipeline RAG é a etapa de geração, em que o Large Language Model (LLM) gera respostas com base no conteúdo recuperado do banco de dados vetorial. Embora o LLM seja o ator central nesta etapa, questões de segurança e conformidade podem surgir dependendo da natureza dos dados usados para treinar o modelo. Alguns riscos-chave incluem:
Violações de Privacidade de Dados: O LLM pode revelar inadvertidamente informações sensíveis ou privadas se for treinado com dados que incluam informações de identificação pessoal (PII) ou outro conteúdo confidencial. Isso poderia resultar em violações de regulamentos de privacidade, como GDPR ou HIPAA.
Manipulação de Saída: Os atacantes poderiam manipular a saída do LLM influenciando as consultas de entrada, levando à geração de conteúdo malicioso ou enganoso. Isso é particularmente preocupante em ambientes onde as saídas são confiadas sem verificação.
Viés e Conteúdo Ofensivo: Se os dados de treinamento contiverem elementos tendenciosos ou ofensivos, o LLM pode produzir respostas tendenciosas ou ofensivas, o que poderia levar a responsabilidades legais, especialmente em ambientes de produção.
Abordar esses riscos requer um pós-processamento cuidadoso do conteúdo gerado, incluindo técnicas como:
Filtragem de Conteúdo: Filtrar automaticamente as saídas para detectar e bloquear conteúdo sensível, tendencioso ou ofensivo.
Validação de Saída: Validar a resposta do modelo para garantir que ela esteja em conformidade com as políticas de segurança e os padrões regulatórios antes de entregá-la ao usuário.
Ajuste Fino do Modelo: Garantir que o modelo seja ajustado com dados em conformidade regulatória e aplicar estratégias de aprendizagem por reforço para evitar saídas prejudiciais.
Ao incorporar essas estratégias, a etapa de geração pode se tornar mais segura e confiável e adiciona uma camada de segurança.
Vamos agora nos aprofundar em um exemplo de Anonimização de Dados, em que diferentes pós-processadores do LlamaIndex serão comparados e um exemplo de Violações de Privacidade de Dados será mostrado.
RAG Seguro Usando LlamaIndex e Milvus
O seguinte notebook é um exemplo de um pipeline RAG criado com LlamaIndex como framework de LLM, Milvus como banco de dados vetorial e três módulos diferentes especializados em mascaramento de PII: um usando um modelo NER da Hugging Face, outro usando um LLM (OpenAI) e o Presidio, uma biblioteca da Microsoft.
Você também pode verificar o código completo neste colab notebook.
Etapa 1: Configurar variáveis de ambiente
Precisamos de uma chave da OpenAI para testar o módulo usando modelos da OpenAI.
from google.colab import userdata
import os
os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')
Etapa 2: Definir texto com dados privados
Primeiro, definimos um texto curto que contém informações privadas, como números de cartão de crédito, nomes ou datas de nascimento.
from llama_index.core.postprocessor import NERPIINodePostprocessor
from llama_index.core.schema import TextNode, NodeWithScore
text = """
Hi, I'm Sarah Mitchell, and I just got a new credit card with the number 3714-496089-47322.
My personal email is sarah.mitchell@mailbox.com, and I'm currently based in Sydney.
By the way, I tried paying my utility bill with card number 6011-5832-9109-1726, but it didn't work.
For my bank transactions, I use this IBAN: NL91ABNA0417164300.
Also, can you help me with my Wi-Fi issues? I keep getting blocked by IP address 203.0.113.15.
I've shared a family photo on my personal blog at https://www.sarahs-lifediary.org/.
Oh, and my grandfather, George Stone, was born in 1921, while my grandmother, Emily Clarkson, was born in 1925.
Last question--what's the spending limit on my main card, the one ending in 8473?
"""
node = TextNode(text=text)
Etapa 3: Modelo NER para mascaramento de PII: NERPIINodePostprocessor
NERPIINodePostprocessor é um módulo do Llama Index que mascara essas informações usando um modelo da Hugging Face especializado em NER (reconhecimento de entidades nomeadas).
from llama_index.core.postprocessor import NERPIINodePostprocessor
from llama_index.core.schema import TextNode, NodeWithScore
processor = NERPIINodePostprocessor()
new_nodes = processor.postprocess_nodes([NodeWithScore(node=node)])
print(new_nodes[0].node.get_text())
Vemos que esse modelo específico mascara algumas informações, mas dados privados ainda ficam visíveis. Usar essa abordagem representaria um vazamento de dados. Portanto, outro modelo ou abordagem deve ser usado.
"""
Output:
Hi, I'm [PER_9], and I just got a new credit card with the number 3714-496089-47322.
My personal email is sarah.mitchell@mailbox.com, and I'm currently based in [LOC_169].
By the way, I tried paying my utility bill with card number 6011-5832-9109-1726, but it didn't work.
For my bank transactions, I use this IBAN: NL91ABNA0417164300.
Also, can you help me with my Wi-[MISC_374] issues? I keep getting blocked by IP address 203.0.113.15.
I've shared a family photo on my personal blog at https://www.sarahs-lifediary.org/.
Oh, and my grandfather, [PER_545], was born in 1921, while my grandmother, [PER_599], was born in 1925.
Last question--what's the spending limit on my main card, the one ending in 8473?
"""
Etapa 4: LLM para mascaramento de PII: PIINodePostprocessor
PIINodePostprocessor é um módulo do Llama Index que usa um modelo LLM para mascarar informações confidenciais. Para testar a eficiência dessa abordagem, usaremos o modelo padrão da OpenAI.
from llama_index.core.postprocessor import PIINodePostprocessor
from llama_index.core.schema import TextNode, NodeWithScore
from llama_index.llms.openai import OpenAI
processor = PIINodePostprocessor(llm=OpenAI())
new_nodes = processor.postprocess_nodes([NodeWithScore(node=node)])
print(new_nodes[0].node.get_text())
Seguindo essa abordagem, o modelo consegue reconhecer todas as informações confidenciais e mascará-las adequadamente.
"""
Output:
Olá, eu sou [NAME1] [NAME2], e acabei de receber um novo cartão de crédito com o número [CREDIT_CARD_NUMBER1].
Meu e-mail pessoal é [EMAIL], e atualmente moro em [CITY].
A propósito, tentei pagar minha conta de serviços públicos com o número do cartão [CREDIT_CARD_NUMBER2], mas não funcionou.
Para minhas transações bancárias, uso este IBAN: [IBAN].
Além disso, você pode me ajudar com meus problemas de Wi-Fi? Continuo sendo bloqueado pelo endereço IP [IP_ADDRESS].
Compartilhei uma foto de família no meu blog pessoal em [URL].
Ah, e meu avô, [NAME3] [NAME4], nasceu em [DATE1], enquanto minha avó, [NAME5] [NAME6], nasceu em [DATE2].
Última pergunta--qual é o limite de gastos do meu cartão principal, aquele que termina em [CREDIT_CARD_ENDING].
"""
Etapa 5: Presidio para mascaramento de PII
Por fim, testamos o Presidio, uma biblioteca da Microsoft que mascara informações sensíveis usando um modelo Spacy especializado em NER.
from llama_index.postprocessor.presidio import PresidioPIINodePostprocessor
from llama_index.core.schema import TextNode, NodeWithScore
from llama_index.llms.openai import OpenAI
processor = PresidioPIINodePostprocessor()
new_nodes = processor.postprocess_nodes([NodeWithScore(node=node)])
print(new_nodes[0].node.get_text())
Desta vez, vemos que o modelo consegue mascarar todas as informações, exceto o número do cartão de crédito, pois ele é considerado parte dele como uma carteira de motorista. Na próxima etapa, testaremos várias consultas com este modelo e mostraremos como violações de privacidade de dados são possíveis porque parte do número do cartão de crédito está disponível.
"""
Output:
Hi, I'm <PERSON_3>, and I just got a new credit card with the number 3714-<US_DRIVER_LICENSE_1>-47322.
My personal email is <EMAIL_ADDRESS_1>, and I'm currently based in <LOCATION_1>.
By the way, I tried paying my utility bill with card number <IN_PAN_1>9109-1726, but it didn't work.
For my bank transactions, I use this IBAN: <IBAN_CODE_1>.
Also, can you help me with my Wi-Fi issues? I keep getting blocked by IP address <IP_ADDRESS_1>.
I've shared a family photo on my personal blog at <URL_1>
Oh, and my grandfather, <PERSON_2>, was born in <DATE_TIME_2>, while my grandmother, <PERSON_1>, was born in <DATE_TIME_1>.
Last question--what's the spending limit on my main card, the one ending in 8473?
"""
Etapa 6: Recuperação usando Milvus
Primeiro, vamos criar um banco de dados vetorial Milvus para armazenar nosso texto.
from llama_index.core import VectorStoreIndex, StorageContext
from llama_index.vector_stores.milvus import MilvusVectorStore
vector_store = MilvusVectorStore(
uri="./milvus_demo.db", dim=1536, overwrite=True
)
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex([n.node for n in new_nodes], storage_context=storage_context)
Em seguida, vamos testar algumas consultas.
Esta primeira consulta funciona corretamente. Ela nos fornece a resposta correta e mantém as informações mascaradas.
response = index.as_query_engine().query(
"What is the name of the person?"
)
print(str(response))
"""
Output:
The name of the person is <PERSON_3>.
"""
Agora tentamos obter o número do cartão de crédito, e vemos que recebemos o número completo com parte dele mascarada como uma carteira de motorista.
response = index.as_query_engine().query(
"What is the number of the credit card?"
)
print(str(response))
"""
Output:
The number of the credit card is 3714-<US_DRIVER_LICENSE_1>-47322.
"""
Mas também se sabe que todos os emissores de cartões de crédito têm IIN (Issuer Identification Number) atribuídos. Os primeiros dígitos definem o emissor. Então, neste caso, 37 significa American Express. Se você não souber, podemos verificar perguntando ao modelo.
response = index.as_query_engine().query(
"What is the issuer of the credit card number?"
)
print(str(response))
The issuer of the credit card number is American Express
Então, vemos que o modelo consegue reconhecer o emissor do cartão, mesmo que essa informação não tenha sido fornecida no texto. Isso significa que o modelo foi treinado com informações de cartão de crédito sobre emissores e consegue fornecer a resposta com seu conhecimento. Este é um exemplo de Violações de Privacidade de Dados na Etapa de Geração, descrito acima.
Conclusão
Oz nos guiou pelas várias etapas de um pipeline RAG e destacou onde as preocupações de segurança podem ser abordadas. A primeira preocupação fundamental envolve a anonimização de dados, garantindo que dados sensíveis não possam ser acessados por terceiros não autorizados. No entanto, é importante lembrar que os modelos de base de LLM podem ter sido treinados com esses dados, tornando os próprios modelos potenciais fontes de vazamento de dados.
Para proteger o acesso e a transmissão de dados, controle de acesso e criptografia são fundamentais. Essas técnicas fornecem um alto nível de segurança e controle, mas ameaças como injeção de prompt e manipulação de busca ainda representam riscos para informações sensíveis.
Portanto, adicionar várias camadas de segurança ao longo do pipeline é essencial para mitigar ameaças potenciais. Uma aplicação RAG pronta para produção deve integrar medidas de segurança robustas em cada etapa para garantir que o sistema seja resiliente contra ataques e esteja em conformidade com normas regulatórias.
Recursos Adicionais
Continue lendo
Zilliz Cloud Update: Tiered Storage, Business Critical Plan, Cross-Region Backup, and Pricing Changes
This release offers a rebuilt tiered storage with lower costs, a new Business Critical plan for enhanced security, and pricing updates, among other features.
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Why Not All VectorDBs Are Agent-Ready
Explore why choosing the right vector database is critical for scaling AI agents, and why traditional solutions fall short in production.