Conceito de exclusão RAG para chatbots de IA: Remover conteúdos do índice, cache e respostas

Tabela de preços expirada, instrução de segurança revogada ou um cliente a solicitar a remoção de dados pessoais: no sistema de origem, o ficheiro em questão é eliminado rapidamente. No entanto, um chatbot de site pode continuar a recorrer ao conteúdo antigo durante minutos, horas ou até mais tempo: uma cópia pode estar na área de importação, o ficheiro foi dividido em vários fragmentos de texto (chunks), os respetivos embeddings estão no índice vetorial e uma cache de respostas mantém uma afirmação já formulada pronta a usar. Por isso, um conceito de exclusão RAG robusto não trata apenas o ficheiro de origem, mas sim toda a cadeia de derivação.

O objetivo não é destruir tudo de forma genérica e imediata. O necessário é um processo controlado que retire imediatamente conteúdos desatualizados ou revogados do fluxo ativo de respostas, considere os deveres legais e operacionais de conservação e, em seguida, comprove que o retrieval e as respostas já não utilizam o conteúdo. É precisamente este comprovativo que distingue uma mera ação de eliminação de um procedimento operacional fiável.

Por que motivo a exclusão num sistema RAG tem várias etapas

A Retrieval-Augmented Generation conecta um modelo de linguagem a conhecimento externo. Entre a fonte original e a resposta existem vários estados técnicos: crawler ou upload, ficheiro normalizado, reconhecimento de texto, chunks, metadados, embeddings, índice vetorial e de texto completo, cache de consultas, excertos selecionados e a resposta gerada a partir deles. Alguns sistemas guardam adicionalmente históricos de sessão, amostras de qualidade ou traces. Se apenas o primeiro estado for removido, as cópias a jusante podem continuar a ser encontradas.

A isto acresce um problema de tempo. Uma exclusão pode ser processada de forma assíncrona, enquanto entram novas consultas em paralelo. Uma reindexação noturna não é suficiente: até à sua execução, o chatbot poderia continuar a fornecer a informação revogada. Por outro lado, uma importação posterior não pode restaurar acidentalmente a fonte. Por isso, cada exclusão necessita tanto de um bloqueio rápido no caminho da consulta como de uma limpeza completa em segundo plano.

Definir claramente o âmbito da exclusão com antecedência

No início está uma identidade de fonte estável. O nome do ficheiro ou a URL isoladamente são frequentemente demasiado fracos, pois podem mudar ou ocorrer várias vezes. É recomendável utilizar um ID interno da fonte, versão, tenant, idioma, área de acesso e um hash do conteúdo importado. Cada chunk e cada entrada do índice devem poder ser rastreados até esta identidade. Só assim é possível determinar com precisão quais as derivações que pertencem a uma fonte.

Em seguida, define-se o que significa "eliminado" no caso concreto. Para uma informação de produto desatualizada, pode ser suficiente desativá-la da base de conhecimento ativa e substituí-la por uma nova versão. No caso de uma revogação, um pedido de proteção de dados ou o fim de uma licença, podem ser afetados prazos mais rigorosos e locais de armazenamento adicionais. Copias de segurança, registos de segurança e comprovativos legalmente exigidos têm muitas vezes regras próprias. A decisão deve, portanto, envolver os responsáveis pelos dados, a equipa de operações e, no caso de conteúdos pessoais ou regulamentados, também as áreas de proteção de dados ou jurídica.

Um fluxo de exclusão seguro em sete passos

1. Registar e verificar o pedido: Anote o ID da fonte, versão, motivo, prazo solicitado, tenants afetados e a pessoa ou função que aprovou. Em exclusões sensíveis, a autorização deve ser verificada antes de alterar quaisquer dados.
2. Aplicar o Tombstone: Marque a fonte imediatamente como bloqueada. Os filtros de retrieval devem ter em conta este estado para que os chunks associados deixem de entrar em novas respostas, mesmo que a limpeza física ainda esteja em curso.
3. Resolver dependências: Identifique cópias brutas, resultados do parser, chunks, embeddings, documentos de texto completo, caches, blocos de resposta pré-gerados e, se aplicável, conjuntos de dados de teste. O ID da fonte serve como chave comum.
4. Limpar índices ativos: Elimine ou desative todos os registos afetados no índice vetorial e de palavras-chave. Verifique os retornos do respetivo serviço; um pedido aceite ainda não é prova de uma exclusão concluída.
5. Invalidar caches: Limpe especificamente as caches de retrieval, consulta e resposta. Onde a invalidação seletiva não for possível, chaves de versão ou um novo namespace ajudam para que as entradas antigas deixem de estar acessíveis.
6. Executar verificações: Faça consultas por formulações conhecidas, títulos de documentos, termos raros e variantes semanticamente semelhantes. Uma consulta direta por ID da fonte e uma amostragem no chatbot devem ambas resultar em zero ocorrências.
7. Concluir o processo: Guarde um registo sucinto de exclusão com data/hora, âmbito, respostas do sistema, resultado do teste e prazos de conservação pendentes. O registo deve comprovar o processo, sem copiar desnecessariamente o conteúdo eliminado.

Por que motivo o tombstone vem antes da eliminação física

Esta ordem previne dois erros típicos. Em primeiro lugar, um crawler nem sempre consegue associar limposamente um ficheiro de origem eliminado a uma entrada existente no índice. Alguns indexadores esperam um sinal de soft-delete enquanto a fonte ainda é reconhecível. Em segundo lugar, tarefas em execução podem voltar a gravar dados entre a eliminação da fonte e a limpeza do índice. Um tombstone central bloqueia esta reintrodução. Ele deve ser mantido mesmo depois de os dados de utilizador propriamente ditos terem sido removidos — mas apenas com os metadados minimamente necessários e um prazo claro de conservação.

O versionamento torna a eliminação de cache controlável

As caches são particularmente suscetíveis a erros quando as chaves consistem apenas na pergunta do utilizador. É preferível uma chave que inclua adicionalmente a versão da base de conhecimento, tenant, idioma e contexto de autorização. Após uma exclusão, a versão é incrementada. Mesmo que uma entrada de cache individual continue tecnicamente a existir até expirar, a aplicação ativa já não a consegue atingir. Isto não substitui a invalidação direcionada em todos os casos, mas reduz o risco de respostas antigas voltarem a surgir.

As caches HTTP, por sua vez, seguem regras próprias. O padrão RFC 9111 descreve quando as respostas armazenadas estão frescas, obsoletas ou devem ser invalidadas. Para aplicações RAG, isto significa: as caches de CDN, API e aplicação devem ser consideradas separadamente. Uma nova versão na base de dados, por si só, não limpa uma cache de resposta servida na periferia (edge).

Exemplo concreto: Um manual de montagem revogado

Suponha que um fabricante revoga a versão 3 de um manual de montagem porque uma etapa de trabalho foi alterada. A versão 4 já foi aprovada. O sistema aplica imediatamente um tombstone à fonte V3 e publica a V4 sob um novo ID de versão. O retriever filtra exclusivamente fontes aprovadas e dá prioridade à versão atual. Em paralelo, um worker remove todos os chunks da V3 do índice vetorial e de texto completo e invalida as caches cuja lista de dependências contenha este ID de fonte.

O controlo de qualidade agora não faz apenas a pergunta "Como monto o componente?". Utiliza também uma formulação marcante da V3, uma pergunta parafraseada e uma pergunta que anteriormente só podia ser respondida com a V3. O esperado é a resposta comprovada da V4 ou uma indicação clara de que não há informação aprovada disponível. Uma referência de fonte à V3, um fragmento literal ou uma resposta sem fonte atual é considerado um erro. Como tornar as fontes visíveis nas respostas é explicado no artigo Fundamentar respostas do chatbot com fontes.

Verificar se a exclusão realmente funciona

Um estado de API a verde não é suficiente. A verificação deve ocorrer em múltiplos níveis. Ao nível do armazenamento, pesquisa-se por ID de fonte, IDs de chunks e hashes conhecidos. Ao nível do retrieval, executam-se perguntas de teste e controlam-se os resultados retornados. Ao nível da resposta, verifica-se se a afirmação antiga continua a aparecer literal ou semanticamente. Por fim, é necessário um teste de reinicialização: após a execução do crawler, reconstrução do índice ou restauração de uma cópia de segurança, a fonte não pode regressar.

Mantenha um pequeno Golden Set de casos positivos e negativos para cada classe crítica de conhecimento. Os casos positivos comprovam que a fonte de substituição é encontrada corretamente; os casos negativos mostram que informações bloqueadas já não aparecem. Este procedimento complementa o QA contínuo para manter atualizada a base de conhecimento do chatbot de IA. Em alterações maiores de índice, ajuda também uma reconstrução paralela com comutação controlada, conforme descrito no guia sobre a mudança de modelo de embedding RAG.

Checklist para a operação diária

• Cada fonte possui um ID estável, versão, origem, idioma e um proprietário responsável.
• Chunks, embeddings, documentos do índice e caches podem ser rastreados até este ID de fonte.
• Um tombstone bloqueia a fonte imediatamente no retrieval e impede uma nova importação.
• A ordem de exclusão é idempotente: uma repetição não gera erros nem novos registos de dados.
• Os workers não reportam apenas "aceite", mas sim um estado concluído com detalhes de eventuais erros.
• As caches de retrieval e resposta podem ser invalidadas seletivamente ou desacopladas através de versões.
• Pesquisa direta, pesquisa semântica, teste de resposta e teste de reinicialização estão documentados.
• Backups e logs têm prazos de conservação definidos e um processo para restaurações futuras.
• O registo de exclusão contém apenas os metadados necessários e nenhuma cópia desnecessária do conteúdo removido.
• A responsabilidade, a escalada e o tempo máximo de processamento estão definidos e são exercitados regularmente.

Não misturar governance e proteção de dados

Um conceito técnico de exclusão responde a como uma fonte desaparece com segurança do fluxo ativo do RAG. Se e quando ela deve ser eliminada é outra questão. O Regulamento Geral sobre a Proteção de Dados (RGPD) prevê no Artigo 17.º o direito ao apagamento sob certas condições, bem como exceções. Uma afirmação genérica como "cada pedido elimina imediatamente todas as cópias de segurança" seria tão arriscada quanto um armazenamento por tempo indeterminado sem finalidade. A base legal e o prazo aplicáveis devem ser definidos para cada caso de uso; o texto oficial do regulamento está disponível através do EUR-Lex.

Organizacionalmente, o procedimento pertence à Content Governance: Quem pode revogar conteúdos? Quem confirma a limpeza? O que acontece se um serviço vetorial externo estiver inacessível? O artigo Content Governance para chatbots de IA mostra como proprietários, aprovações e controlo de alterações trabalham em conjunto. Para riscos elevados, recomenda-se o princípio dos quatro olhos; para atualizações normais, um workflow automatizado e totalmente registado pode ser suficiente.

Fontes oficiais e referências técnicas

• Microsoft Learn: Deteção de blobs alterados e eliminados no Azure AI Search
• Microsoft Learn: Documents API para Azure AI Search
• Google Cloud: Gerir ficheiros e corpora no Vertex AI RAG Engine
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Regulamento Geral sobre a Proteção de Dados

Conclusão: A capacidade de exclusão é uma função de qualidade

Uma base de conhecimento RAG só é fiável se os conteúdos puderem não só ser integrados, mas também revogados de forma controlada. IDs de fonte estáveis, tombstones, listas de dependências, caches versionadas e testes repetíveis transformam uma ação isolada e incerta num processo controlável. Quem combina aprovação funcional, limpeza técnica e QA comprovável reduz respostas desatualizadas e cria a base para um chatbot cujo conhecimento pode ser gerido deliberadamente.