Como manter um corpus RAG atualizado e confirmar que os documentos antigos deixam de aparecer

Manter o corpus não é avaliar as respostas

Um corpus RAG está atualizado quando o conteúdo disponível para recuperação continua a corresponder às fontes que a equipa considera válidas. O trabalho inclui identificar documentos e versões, processar as alterações, atualizar as unidades indexadas e verificar o resultado. Esta tarefa é diferente de avaliar se o modelo redige uma resposta correta ou se a fundamenta adequadamente nos fragmentos recuperados. As duas avaliações podem estar relacionadas, mas não são intercambiáveis: um teste de recuperação pode revelar que um documento retirado continua a aparecer, mesmo que a resposta gerada pareça razoável.

A documentação fornecida da Microsoft descreve a criação de uma pipeline de dados não estruturados para aplicações de IA. A documentação da Google Cloud aborda a administração de um corpus RAG e indica, de acordo com a informação disponível, que inclui criar um corpus e importar ou carregar documentos. Estas referências servem de contexto para o processamento e a incorporação de conteúdo, mas a informação disponível não confirma um procedimento universal para atualizar ou eliminar documentos. Por isso, os passos seguintes constituem um desenho operacional adaptável, e não uma afirmação de que uma determinada funcionalidade existe em todos os produtos.

O objetivo prático é conseguir responder a perguntas sobre o estado do conteúdo: que fonte deu origem a um fragmento, que versão foi processada, se ocorreu uma falha parcial e que teste demonstra que uma remoção foi bem-sucedida. Se a equipa não conseguir responder a estas perguntas, não deve considerar o corpus atualizado apenas porque terminou uma execução de processamento.

Inventariar as fontes antes de automatizar

Comece por enumerar as fontes que podem alimentar o corpus e atribua um responsável a cada uma. Uma fonte pode ser um repositório de documentação interna, um catálogo, um conjunto de normas ou uma coleção de ficheiros. O inventário não tem de depender de um produto específico, mas deve permitir distinguir cada origem e saber quem decide se o conteúdo é incorporado, alterado ou removido.

Para cada documento, guarde um identificador estável, caso o sistema de origem o disponibilize. Registe também a localização ou coleção de origem, o responsável, uma data ou versão verificável e o estado do documento, por exemplo, ativo, pendente de processamento ou removido. Se não existir uma versão formal, pode registar um sinal de alteração disponível na origem, desde que a equipa documente o seu significado e as suas limitações. Não parta do princípio de que uma data de modificação basta para distinguir dois conteúdos idênticos ou duas revisões diferentes.

Associe estas propriedades a cada unidade derivada que é indexada, como um fragmento ou registo. O objetivo é conseguir localizar todas as unidades provenientes de uma fonte quando esta for alterada ou removida. Se o mecanismo de indexação não permitir armazenar metadados ou não documentar como filtrar e remover registos, registe essa limitação e teste-a; não assuma que a eliminação do ficheiro de origem elimina automaticamente os seus derivados.

Defina também as regras de incorporação e remoção. Por exemplo, especifique quem autoriza que um documento passe a ativo, o que significa uma substituição e como são resolvidas fontes contraditórias. Estas são decisões de governação da equipa, não propriedades inerentes ao RAG. Deixá-las por escrito evita que uma atualização técnica determine, por acidente, que versão deve ser considerada válida.

Decidir que alterações devem ser reprocessadas

Nem todas as alterações têm de implicar o mesmo trabalho. Uma correção localizada pode exigir o processamento de um documento; uma alteração às regras de extração ou à forma de dividir o texto pode afetar uma coleção inteira. Uma alteração da configuração que transforme a representação armazenada pode justificar uma reconstrução mais abrangente. Estas são categorias de decisão: antes de as aplicar, é necessário verificar que componentes a pilha utiliza e que operações suporta.

Escreva uma política que associe os sinais de alteração ao âmbito do reprocessamento. Por exemplo: uma nova versão identificada na origem ativa o reprocessamento desse documento; uma alteração global da extração ativa uma revisão da coleção afetada; uma dúvida sobre a consistência do conjunto pode ativar uma reconstrução de teste. Não transforme estes exemplos em automatismos sem validar primeiro a identidade dos documentos, a capacidade de os eliminar e o comportamento da ferramenta.

A pipeline descrita pela Microsoft pode servir de referência geral para pensar no processamento de dados não estruturados, mas a informação disponível não especifica que operações de atualização incremental, sincronização ou eliminação implementa. Do mesmo modo, a referência da Google Cloud sobre a administração do corpus confirma que o tema inclui a criação e a importação, mas não permite concluir que condições se aplicam à alteração ou eliminação de registos. O comportamento real deve ser verificado na documentação da pilha escolhida e através de testes controlados.

Desenhar o ciclo de inclusão e alteração

Um ciclo de atualização pode ser organizado em etapas explícitas. Primeiro, deteta-se uma nova fonte ou uma alteração através de um sinal disponível no sistema de origem. Depois, regista-se a versão observada e valida-se se o documento é admissível segundo as regras da equipa. Em seguida, extrai-se o conteúdo, processa-se com a configuração acordada e conservam-se metadados que permitam rastreá-lo até à respetiva fonte.

Antes de publicar o resultado, decida como tratar a transição entre versões. Uma estratégia possível é preparar e verificar a nova versão antes de a disponibilizar, se a plataforma permitir mantê-la separada. Outra possibilidade é substituir diretamente o conteúdo e verificá-lo depois. Não se deve afirmar que uma destas estratégias é sempre superior: a escolha depende das funcionalidades documentadas, da tolerância do sistema a uma interrupção e da forma como o estado parcial é gerido.

O registo da execução deve indicar, no mínimo, a fonte e a versão pretendidas, a data de deteção, o âmbito previsto, o estado de cada etapa e o resultado das verificações. Se o processo for interrompido, esta informação ajuda a distinguir entre uma fonte que não foi detetada, uma extração falhada e uma atualização aplicada apenas em parte. Evite marcar uma versão como vigente só porque o seu processamento foi iniciado.

Inclua um critério de conclusão observável. Por exemplo, a operação só passa a concluída depois de se verificar que as unidades esperadas são recuperáveis e que a versão anterior já não aparece quando deveria ter sido substituída. O critério tem de ser viável com a ferramenta concreta. Se esta não oferecer uma forma de o verificar, registe essa limitação e conceba um teste externo de recuperação.

Gerir remoções e substituições sem deixar vestígios

Remover um ficheiro da origem e remover as suas representações do índice são ações diferentes, a menos que a integração concreta documente e demonstre o contrário. Uma remoção pode deixar fragmentos, cópias derivadas ou registos repetidos se não for possível identificar tudo o que provém da fonte. Por isso, a relação entre o identificador da fonte e as unidades indexadas deve ser concebida antes da primeira remoção.

No caso de uma substituição, registe que versão deixa de ser válida e qual deve ocupar o seu lugar. Verifique se a nova versão foi processada corretamente e se a anterior deixa de aparecer nas pesquisas em que era pertinente. Se as duas versões tiverem de coexistir por uma razão legítima, estabeleça como as distinguir e qual o estado de cada uma. Não as apresente como equivalentes se a política da fonte as considerar incompatíveis.

A remoção deve deixar evidências: fonte removida, momento do pedido, responsável, unidades afetadas ou âmbito da operação, resultado e consultas de teste. Se a operação falhar, mantenha um estado pendente ou falhado e evite apresentar o corpus como plenamente atualizado. A recuperação pode consistir em tentar novamente, reconstruir uma parte ou escalar o problema; a escolha depende das capacidades disponíveis e deve ficar registada.

As fontes fornecidas não confirmam suficientemente que uma plataforma específica elimine automaticamente todos os fragmentos derivados quando um documento é apagado. A conversa do Reddit incluída como fonte é anedótica e não permite estabelecer um comportamento garantido. Verifique as funcionalidades de eliminação na documentação oficial do produto concreto e, sobretudo, confirme o resultado com um teste reproduzível.

Controlar atualizações parciais e falhas

Um processo de atualização pode parar depois de detetar a alteração, durante a extração ou depois de modificar apenas uma parte do índice. O desenho operacional deve tornar estas diferenças visíveis. Defina estados simples, como pendente, em processamento, concluído e falhado, e especifique o significado de cada um. Se a equipa precisar de registar etapas mais detalhadas, pode acrescentá-las, desde que os operadores compreendam como se relacionam.

Decida que conteúdo é considerado disponível enquanto uma atualização está incompleta. Em alguns sistemas pode ser possível manter a versão anterior até a nova ser validada; noutros, a atualização pode causar um período de indisponibilidade ou resultados mistos. Não prometa atomicidade ou substituição sem interrupções, a menos que a documentação da plataforma o confirme e um teste o verifique.

Estabeleça uma política de novas tentativas que não crie duplicados. Antes de voltar a executar um processo, verifique se a operação anterior deixou unidades parciais e como as identificar. Se não for possível determiná-lo, trate o resultado como incerto e evite uma segunda gravação às cegas. Registe o âmbito, a decisão tomada e o teste posterior, para que outro operador possa reconstruir que versão estava disponível.

Escolher entre atualização incremental e reconstrução

A atualização incremental limita o trabalho aos documentos ou coleções afetados; pode ser adequada quando o sistema permite identificar cada fonte com precisão e remover ou substituir os seus derivados. A reconstrução volta a processar um conjunto mais amplo e pode facilitar uma verificação integral, mas também pode exigir mais tempo e recursos. Estas são considerações operacionais gerais, não garantias de desempenho nem descrições de uma ferramenta específica.

Compare as duas opções com dados do ambiente: volume de fontes, frequência das alterações, duração observada, custo de processamento, facilidade de identificar os elementos afetados e consequências de uma atualização incompleta. Inclua também as capacidades documentadas da pilha para atualizar, apagar, consultar estados e restaurar uma versão anterior. Se uma capacidade essencial não estiver confirmada, registe-a como uma incerteza que deve ser resolvida antes da automatização.

Não escolha a opção incremental apenas por parecer mais barata, nem reconstrua automaticamente perante qualquer alteração. A decisão depende de ser possível limitar o impacto e demonstrar a consistência do resultado. Um teste de reconstrução num ambiente controlado pode ajudar a estimar a duração e a detetar diferenças; por si só, não demonstra que uma reconstrução em produção seja segura.

Testar se o corpus reflete o estado esperado

Os testes de aceitação devem verificar o comportamento do corpus, não apenas confirmar que uma tarefa técnica terminou sem erro. A informação fornecida sobre a criação de corpus orientados para RAG e a sua utilização na avaliação sustenta a pertinência de conceber verificações para sistemas RAG, mas não define aqui um conjunto de testes específico nem um limiar universal. As consultas e os critérios devem resultar das fontes e dos riscos de cada aplicação.

Construa um conjunto pequeno e estável de consultas. Inclua consultas que devam recuperar uma versão atual, consultas distintivas de uma fonte removida e consultas sobre documentos não relacionados que devem continuar disponíveis. Registe que fonte e versão são esperadas, que resultado foi observado e quando o teste foi executado. Se a recuperação depender da ordenação, de limiares ou de outras definições, registe a configuração relevante para poder interpretar as alterações entre execuções.

Acrescente testes para detetar duplicados e conflitos. Uma pesquisa pode devolver a versão antiga e a nova, duas cópias do mesmo documento ou fragmentos que não conservam proveniência suficiente para serem distinguidos. Defina que resultados são aceitáveis: por exemplo, uma única versão ativa quando a política exige exclusividade, ou ambas as versões claramente identificadas quando a coexistência é autorizada.

Um teste negativo — não recuperar uma fonte removida — exige cuidado: o facto de ela não aparecer numa consulta concreta não demonstra que tenha desaparecido de todo o índice. Utilize várias consultas representativas e, se a ferramenta o permitir, inspecione os registos associados ao identificador da fonte. Explicite o alcance real da verificação e evite transformar uma amostra numa garantia absoluta.

A avaliação da recuperação também não determina, por si só, se o modelo redige uma resposta correta. Se a equipa também precisar de avaliar a resposta final, deve manter um conjunto de testes separado, com critérios adequados a essa tarefa. Assim, é possível distinguir um problema de atualidade do corpus de um problema de geração ou de utilização do contexto.

Rotina periódica e limites das evidências

Uma rotina periódica deve rever as alterações pendentes, as execuções falhadas, as fontes sem responsável, as versões cuja vigência não foi confirmada e os testes de aceitação que ainda não foram executados. A frequência depende do ritmo das alterações e do risco: uma coleção normativa pode exigir controlos mais frequentes do que um arquivo de consulta ocasional. As fontes fornecidas não estabelecem uma periodicidade universal; cada equipa deve justificar a sua.

Verifique também se as regras de extração ou processamento mudaram desde a última atualização e se essa alteração obriga a reprocessar documentos anteriores. Confirme que os identificadores e metadados continuam associados às unidades recuperadas. Se não for possível reconstruir que fonte e versão contribuíram para um teste, dê prioridade à correção desta falta de rastreabilidade antes de ampliar a automatização.

As fontes disponíveis têm um âmbito limitado. A documentação da Microsoft confirma o tema das pipelines de dados não estruturados para IA; a da Google Cloud, a administração e importação de documentos para um corpus RAG; e o artigo do Instituto de Engenharia do Conhecimento, a criação de corpus para RAG e a sua utilização na avaliação. Nenhum dos excertos fornecidos confirma o comportamento exato de uma plataforma em relação a remoções, substituições, transações, reconstruções ou atualizações incrementais. Estas funcionalidades devem ser verificadas na documentação atual do produto e em testes no ambiente real.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.