Prevenir o Envenenamento de Dados RAG: Proveniência de Fontes, Quarentena e Testes de Reindexação

Um chatbot de website pode fornecer uma resposta cortês, linguisticamente convincente e tecnicamente bem gerada – e, ainda assim, operar com base numa base de conhecimento envenenada. No envenenamento de dados RAG, a formulação de uma consulta individual não é o principal alvo da manipulação. Em vez disso, conteúdos falsos, adulterados ou insuficientemente verificados entram na cadeia de dados permanente: fonte, parser, chunk, metadados, embedding e, finalmente, o índice de retrieval em produção. O erro permanece assim ao longo de muitas sessões e pode impactar até perguntas normais.

Portanto, uma proteção eficaz começa muito antes do prompt. As equipas devem ser capazes de responder a estas perguntas para cada bloco de conhecimento: De onde vem, quem é o responsável, que versão foi processada, que transformações ocorreram e através de que verificação foi aprovado para pesquisa? A proveniência da fonte fornece esse rasto. Uma quarentena tecnicamente isolada pode impedir que alterações não verificadas fiquem imediatamente acessíveis. Testes de reindexação direcionados verificam subsequentemente se o conteúdo limpo substituiu efetivamente os chunks antigos.

O que é o envenenamento de dados RAG – e o que não é

A classificação OWASP LLM04:2025 sobre Data and Model Poisoning descreve as manipulações em dados de pré-treino, fine-tuning ou embeddings como um risco de integridade. Para um chatbot de website, a última variante é particularmente concreta: um documento é ingerido e dividido em secções; estes chunks são convertidos em embeddings e armazenados como vetores no índice de retrieval. Se este documento for adulterado, intencionalmente ou por engano, pode surgir como uma base aparentemente relevante ao responder a perguntas correspondentes.

Os riscos devem ser distinguidos, embora se possam sobrepor: o Prompt Injection tenta injetar instruções ou dados no momento da execução para alterar o comportamento previsto do sistema; o Prompt Injection indireto também pode entrar no contexto através de documentos recuperados. O envenenamento de dados, por outro lado, altera a base de conhecimento de longa duração ou as suas derivações. Os direitos de acesso também resolvem um problema diferente: determinam que pessoa pode ver um documento. A proveniência e a aprovação determinam se esse documento deve entrar no índice como uma fonte de conhecimento confiável. Numa arquitetura robusta, todos estes três riscos precisam de controlos próprios e de transições coordenadas.

A superfície de ataque abrange toda a cadeia de dados

Um índice RAG raramente surge de uma coleção única e verificada manualmente. Os crawlers leem páginas web, os conectores sincronizam pastas na nuvem, os utilizadores carregam ficheiros e as APIs importam dados de produtos. A isto somam-se parsers, OCR, limpeza de linguagem, chunking e enriquecimento de metadados. Cada etapa pode assimilar conteúdos incorretos ou isolar uma afirmação originalmente correta do seu contexto.

As causas típicas incluem um sistema de origem comprometido, um documento espelho recém-associado, um ficheiro de rascunho publicado acidentalmente, um tenant incorretamente atribuído ou uma atualização do parser que associa valores de tabelas aos títulos errados. A comparação de um hash de conteúdo criptográfico com um valor de referência confiável pode detetar discrepâncias; um hash correspondente não prova nem a veracidade, nem a atualidade, nem a aprovação do conteúdo.

Proveniência como um conjunto de dados auditável

Cada documento e cada chunk dele derivado deve ter um registo de proveniência associado. Na prática, são úteis pelo menos um ID de fonte estável, o URL de origem canónico, o proprietário responsável, a hora de recolha, a versão do documento, o hash do conteúdo, o estado de aprovação, a classe de confiança, a versão do parser, a versão do chunking, o modelo de embedding e a geração do índice. No caso de carregamentos manuais, acrescentam-se a função do utilizador que fez o upload e a licença verificada. Em sistemas sincronizados, também é importante saber através de que conector autenticado o ficheiro chegou.

O NIST AI 600-1 Generative AI Profile aborda a proveniência de conteúdos, a documentação rastreável, bem como testes e avaliações como componentes essenciais da gestão de risco na IA generativa. Traduzido para sistemas RAG, isto significa: não conta apenas o índice atual. A relação rastreável entre a revisão da fonte, a execução do processamento e a geração do índice publicado também faz parte da documentação operacional.

A quarentena separa a ingestão da publicação

Um elemento arquitetural central é a separação rigorosa: conteúdos novos ou alterados não ficam imediatamente pesquisáveis. Eles vão primeiro para uma zona de ingestão. Aí, a pipeline valida a origem, o tipo de ficheiro, o tamanho, a assinatura ou o hash esperado, o tenant permitido, a integridade dos metadados e a extensão das alterações. Só depois é que o texto e os chunks são gerados numa geração de índice não produtiva.

As regras devem ser baseadas no risco. Uma alteração numa página de FAQ autenticada e de responsabilidade interna pode ser aprovada após testes automatizados. Já um novo domínio, uma alteração de texto invulgarmente extensa, um proprietário de ficheiro desconhecido ou uma fonte sem pessoa responsável acionam a quarentena e a revisão humana. Se faltar uma informação obrigatória, aplica-se o princípio de "fail closed": a geração antiga e confirmada permanece ativa; o novo estado não é publicado silenciosamente.

Aprovação como uma geração de índice imutável

Após a verificação, o índice de produção não é sobrescrito gradualmente. É preferível criar uma nova geração versionada com um manifesto: documentos esperados, chunks esperados, hashes de origem, versões de transformação e carimbos de data/hora. Apenas quando os testes estiverem a verde é que um alias ou uma configuração de encaminhamento muda atomicamente para esta geração. A geração anterior permanece disponível para rollback durante um período limitado e definido.

O procedimento assemelha-se a uma migração controlada. O nosso artigo sobre a mudança de um modelo de embedding RAG mostra por que razão as gerações de índice paralelas e os testes comparativos são úteis mesmo em alterações técnicas. Em caso de suspeita de envenenamento, junta-se a questão de segurança: que revisão da fonte e que chunks derivados precisam de ser bloqueados?

Cenário de exemplo fictício: um prazo de devolução incorreto chega ao bot de suporte

Suponha que um comerciante opera um chatbot para dúvidas sobre produtos e serviços. A base de conhecimento sincroniza todas as noites o centro de ajuda oficial e alguns portais de fabricantes autorizados. Após uma alteração de hiperligação, um conector segue um redirecionamento para uma página espelho não autorizada. Nela, num PDF visualmente plausível, consta um prazo de devolução de 90 dias em vez de 30. O ficheiro é dividido em chunks; várias secções entram no índice com elevada similaridade semântica.

Na manhã seguinte, o bot promete o prazo incorreto ao responder a perguntas sobre devoluções. O modelo de linguagem não foi reprogramado e os utilizadores não inseriram qualquer instrução maliciosa. O retrieval forneceu simplesmente uma base errada. A monitorização dispara um alarme porque um novo domínio surge pela primeira vez como fonte de resposta e um teste Golden Set para o prazo de devolução diverge da fonte de referência esperada.

Quarentena e recuperação controladas

1. A equipa interrompe apenas a fonte de ingestão afetada e congela a geração de índice atual para impedir novas alterações.
2. O ID do documento suspeito, todos os IDs de chunk dele derivados e as respostas em que apareceram são registados no incidente.
3. O domínio espelho é bloqueado e os seus chunks são movidos para a quarentena. Para perguntas sobre o prazo de devolução, o bot fornece temporariamente um aviso seguro a direcionar para o suporte humano ou para a página de políticas confirmada.
4. O alias é revertido para a última geração de índice comprovadamente limpa. Com isto, outras áreas de conhecimento não afetadas permanecem disponíveis.
5. O conector é restrito à fonte canónica. Em seguida, a pipeline constrói uma nova geração a partir do manifesto confirmado.
6. Esta geração só vai para produção após os testes de reindexação e a aprovação especializada.

Esta sequência limita os danos sem desligar prematuramente todo o chatbot. A chave é a ligação entre os dados de origem e as suas derivações: sem o mapeamento do documento para os chunks, não seria claro quais os vetores que precisam de ser removidos.

Os testes de reindexação devem demonstrar mais do que uma pipeline bem-sucedida

Um estado de job a verde apenas prova que o processo terminou do ponto de vista técnico. Não prova que os chunks antigos desapareceram, nem que as fontes corretas prevalecem perante perguntas reais. Um pacote de testes robusto avalia, portanto, o inventário, o retrieval e o comportamento de resposta.

1. Verificação de manifesto e eliminação

Compare a nova geração com o manifesto aprovado. Cada versão de documento esperada tem de estar presente; os IDs de documentos e chunks bloqueados não podem constar. Os "tombstones" para conteúdos eliminados ou substituídos são especialmente importantes. De outro modo, a simples adição de novos embeddings permite que resultados antigos e envenenados continuem no índice.

2. Testes de retrieval com fontes esperadas

Para perguntas críticas, não basta obter um texto de resposta esperado. Defina adicionalmente IDs de fontes permitidas e proibidas, um número mínimo de resultados e condições de exclusão. O prazo de devolução, por exemplo, deve provir da política canónica; o domínio espelho colocado em quarentena não pode aparecer nem nos principais resultados nem no contexto do modelo. A estrutura destes conjuntos de teste é explicada no artigo sobre qualidade de resposta com Golden Set e testes RAG.

3. Testes negativos e de manipulação

Num ambiente de teste isolado, as equipas podem injetar uma fonte de teste claramente identificada e não aprovada. A pipeline deve mantê-la em quarentena; a pesquisa em ambiente pré-produtivo não a pode recuperar. Adicionalmente, testam-se mudanças invulgares de domínio, proprietários em falta, diferenças extremas de conteúdo e datas contraditórias. O relatório NIST AI 100-2 sobre Adversarial Machine Learning classifica o envenenamento como uma categoria de ataque na sua taxonomia e sublinha que as contramedidas e os seus limites devem ser analisados de forma sistemática.

4. Comparação antes e depois da transição

Execute as mesmas perguntas contra a última geração limpa e a nova geração. Compare as fontes dos resultados, a ordem de classificação, os comprovativos das respostas, a taxa de ausência de resposta (no-answer rate) e a avaliação especializada. Uma pequena percentagem em formato Canary pode fornecer sinais de produção adicionais, desde que os utilizadores não tenham acesso a fontes não verificadas. A mudança definitiva para produção só ocorre quando os limites definidos de segurança e qualidade forem cumpridos.

Monitorização: detetar anomalias precocemente

Não monitorize apenas as avaliações das respostas. São altamente indicativos os domínios de origem novos ou raros, a proporção de fontes não verificadas no fluxo de ingestão, tamanhos de documento invulgares, fortes divergências no hash ou no texto, muitos chunks novos associados a um único proprietário, alterações nas principais fontes do Golden Set e respostas sem um comprovativo confirmado. As métricas devem fazer referência a IDs de proveniência e não a perguntas completas de utilizadores armazenadas desnecessariamente.

A atualidade também continua a ser relevante. Uma política antiga e há muito substituída não está envenenada intencionalmente, mas pode ter o mesmo efeito. O artigo sobre a atualidade das bases de conhecimento e Crawl QA complementa os controlos de segurança com cadência, responsabilidade e rotas de eliminação.

Checklist para ingestões RAG seguras

• Cada fonte tem um ID estável, origem canónica, pessoa responsável e classe de confiança?
• O hash, a versão do documento, o parser, o chunking e o modelo de embedding são registados em conjunto?
• As fontes novas ou fortemente alteradas permanecem fora da pesquisa em produção até serem verificadas?
• Novos domínios, assinaturas em falta ou alterações de conteúdo não plausíveis acionam a quarentena?
• Os índices aprovados são publicados como gerações versionadas com um alias reversível?
• A reindexação remove comprovadamente os chunks substituídos, em vez de apenas adicionar novos dados?
• Um Golden Set testa tanto as respostas como as fontes esperadas e proibidas?
• Existe um fallback seguro para tópicos cujas fontes estejam bloqueadas durante um incidente?
• As funções para ingestão, aprovação especializada, resposta a incidentes e republicação estão claramente separadas?
• Após cada incidente, documenta-se qual o controlo que falhou e que teste de regressão foi adicionado?

Conclusão

O envenenamento de dados RAG não se resolve com uma única regra de prompt. A proteção resulta de uma cadeia de fornecimento de conhecimento auditável: documentar a origem, verificar alterações em quarentena, versionar índices, remover derivações antigas com segurança e testar o retrieval com as fontes esperadas. Comece pelas classes de documentos de maior risco e por um Golden Set reduzido. Esta combinação torna visível que fonte sustenta uma resposta – e permite um caminho de reversão focado antes que um estado de conhecimento incorreto se torne o novo padrão definitivo.

Fontes

• OWASP GenAI Security Project: LLM04:2025 Data and Model Poisoning
• NIST AI 600-1: Artificial Intelligence Risk Management Framework – Generative Artificial Intelligence Profile
• NIST AI 100-2: Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations