Corpus vivo para RAG: versionar fontes, retirar conteúdo obsoleto e demonstrar a evidência de cada resposta

O problema: uma citação pode ser exata e, ainda assim, não servir

Um sistema de geração aumentada por recuperação, ou RAG, costuma ser avaliado perguntando se recupera um texto relevante e se a resposta se apoia nele. Esse controle é necessário, mas não basta quando o corpus muda. Uma resposta pode reproduzir com precisão um trecho de uma política anulada, de um manual substituído ou de um contrato que já não se aplica à pessoa que consulta. Nesse caso, a falha não está necessariamente na geração: está no ciclo de vida da evidência.

Convém separar duas perguntas. A primeira é semântica: o trecho recuperado responde à consulta? A segunda é de governança: ele era uma fonte autorizada, acessível e vigente para esta consulta e neste momento? A similaridade vetorial, por si só, não resolve a segunda. Um texto antigo pode parecer mais semelhante à pergunta do que uma revisão nova; uma cópia local pode conter instruções diferentes de uma política central; e um trecho indexado quando uma pessoa tinha acesso pode continuar aparecendo depois que ela perde essa permissão.

A tese operacional é simples: adicionar arquivos a um índice não cria uma base de conhecimento sustentável. Para isso, é necessária uma identidade estável para o documento, uma revisão identificável, um intervalo de vigência, uma regra de autoridade, controles de acesso aplicados durante a recuperação e um registro que vincule cada resposta às evidências realmente consultadas. Também é necessária uma retirada explícita: deixar de publicar um arquivo na origem não garante que ele desapareça dos índices, réplicas, caches ou registros derivados.

Este guia trata o corpus como um sistema de registros sujeito a mudanças, e não como uma pasta de arquivos. O objetivo não é prometer respostas infalíveis. É conseguir demonstrar por que uma evidência era elegível, detectar quando ela deixou de ser e abster-se quando as regras disponíveis não permitem determinar qual, entre várias fontes ativas, deve prevalecer.

Separar identidade, revisão, vigência, autoridade e acesso

A identidade responde a qual objeto documental está sendo gerenciado. Ela deve permanecer estável mesmo que o título, o local ou o formato mudem. Por exemplo, uma política corporativa pode manter seu identificador canônico ao passar de um documento de escritório para uma página web. A revisão responde a qual edição concreta contém o texto. Uma correção editorial e uma substituição normativa podem criar revisões distintas, ainda que a mudança pareça pequena.

A vigência expressa quando uma revisão pode ser usada como evidência. Ela não deve ser confundida com a data de indexação nem com a data de modificação técnica do arquivo. Uma política publicada hoje pode entrar em vigor no próximo mês; outra pode ser mantida apenas para consultas históricas. Por isso, é útil armazenar pelo menos um início de vigência, um fim de vigência quando houver e um estado operacional, como rascunho, aprovado, ativo, retirado ou excepcionalmente restaurado.

A autoridade ordena fontes que podem tratar do mesmo assunto. Uma política global aprovada pode prevalecer sobre uma orientação local, salvo se houver uma exceção válida para uma jurisdição, unidade ou produto. Essa regra não pode ser inferida de forma confiável pela redação nem pela similaridade. Ela deve ser um atributo governado, com um responsável e uma regra explícita de precedência. Se duas fontes ativas se contradizem e não há uma regra aplicável, o comportamento prudente é não escolher uma por popularidade ou proximidade semântica.

A permissão de acesso é outra dimensão independente. Um trecho não deixa de conter informação protegida porque foi dividido, vetorizado ou armazenado em um índice. Os filtros de autorização devem ser aplicados antes de ordenar os resultados por relevância e devem ser atualizados quando as listas de controle de acesso mudam. A documentação de serviços de busca confirma que a segurança em nível de documento pode restringir quais documentos de um índice uma pessoa pode ver e que alterações de permissões exigem manter sincronizados os documentos afetados.

Este design se alinha a uma ideia básica de proveniência: distinguir entidades, atividades e agentes. O documento canônico, sua revisão e cada trecho são entidades; a extração, a segmentação, a criação de embeddings e a indexação são atividades; o proprietário, o aprovador e o serviço que executa um processo são agentes. Modelar essas relações não obriga a adotar uma tecnologia específica, mas evita transformar a rastreabilidade em notas livres difíceis de consultar.

Modelo de dados mínimo para um corpus governado

Um modelo mínimo não precisa capturar todos os metadados possíveis, mas deve incluir aqueles que permitem decidir a elegibilidade e reconstruir fatos. A entidade documento canônico pode incluir um identificador imutável, tipo documental, âmbito, proprietário responsável, fonte de origem e classificação. A entidade revisão deve ter seu próprio identificador, uma impressão digital do conteúdo recebido, estado de aprovação, início e fim de vigência, data conhecida de publicação e relação com a revisão anterior ou substituída.

Cada trecho recuperável deve trazer o identificador do documento canônico e da revisão, uma posição ou intervalo estável dentro da revisão, a impressão digital de seu texto normalizado e os atributos necessários para filtrar. O embedding não é o trecho: é uma representação derivada. Por isso, precisa de seu próprio identificador de modelo, versão de configuração, data de cálculo e referência ao trecho exato que o originou. O índice também é uma entidade operacional: registre sua versão, partição ou réplica, configuração de busca, momento de publicação e conjunto de revisões incluído.

Adicione relações explícitas para substitui, deriva de, funde e retira. Uma fusão documental não equivale necessariamente a uma substituição de um para um: vários documentos podem ser absorvidos por uma nova fonte, enquanto parte da informação pode ficar sem sucessor. Essa distinção permite responder se um documento foi retirado, qual é seu sucessor quando existe e se uma consulta histórica deve continuar podendo encontrá-lo sob controles específicos.

Os campos temporais merecem disciplina especial. Guarde o tempo observado na origem, o tempo de aprovação, o intervalo de vigência de negócio, o tempo de extração e o tempo de publicação no índice. Não suponha que sejam intercambiáveis. Para reconstruir uma resposta, é importante saber o que se sabia e o que estava disponível operacionalmente, além de qual texto afirmava estar vigente. Quando os relógios de vários sistemas não estão sincronizados ou uma data provém de metadados pouco confiáveis, registre essa incerteza em vez de convertê-la em uma certeza artificial.

Fluxos de mudança: atualizar não é uma única operação

A inclusão inicial começa com a validação da origem, identidade, proprietário, classificação e regras de acesso. Depois, o conteúdo é extraído, uma revisão é criada, o texto é segmentado, representações são calculadas e uma versão de índice é publicada. A publicação deve ser atômica do ponto de vista da consulta ou, ao menos, deve evitar estados nos quais uma parte de uma revisão esteja visível e outra não. Se forem necessárias aprovações, um rascunho pode ser processado tecnicamente sem ser elegível para responder.

Uma correção menor exige comparar a nova impressão digital com a revisão anterior e localizar quais segmentos mudaram. Recalcular somente os trechos afetados pode reduzir trabalho, mas apenas se o algoritmo de segmentação mantiver referências corretas. Se uma modificação desloca títulos, numeração ou seções, ela pode afetar mais trechos do que indica uma comparação literal. A otimização deve estar subordinada à rastreabilidade: é preferível reindexar mais conteúdo a preservar vínculos ambíguos entre um embedding e um texto.

Uma substituição de política é um evento de governança. Ela deve criar uma revisão ou documento sucessor, fixar a data de entrada em vigor, encerrar a vigência do anterior quando aplicável e propagar a retirada a todos os artefatos derivados. Em determinados sistemas de indexação, documentos que já não estão presentes na origem podem exigir uma ação explícita de exclusão; portanto, uma nova execução não deve ser assumida como prova de retirada completa. A verificação deve consultar o estado dos índices e das réplicas, não apenas o registro da origem.

Uma retirada total preserva, se a política de retenção permitir, um histórico não elegível para respostas ordinárias. O histórico pode ser necessário para auditoria, investigação de incidentes ou reconstrução de uma resposta passada. Ele deve ficar separado dos índices ativos, com controles de acesso e uma finalidade definida. Restaurar uma fonte retirada é excepcional: deve produzir um novo evento, justificar a mudança de estado e desencadear uma nova publicação verificável, em vez de apagar o rastro da retirada anterior.

Reindexação, caches e duplicados: manter coerência entre representações

A reindexação seletiva é útil quando se consegue demonstrar a relação entre cada representação e sua entrada. Calcule diferenças de texto e de metadados. Uma mudança no conteúdo exige revisar os trechos e embeddings afetados. Uma mudança de vigência, autoridade, jurisdição ou permissão pode não alterar o texto, mas altera a elegibilidade para recuperação; por isso, deve atualizar filtros, índices de metadados e caches. Tratar somente modificações textuais deixa uma via para respostas incorretas com conteúdo literalmente inalterado.

Nem todos os caches armazenam a mesma coisa. Podem existir caches de download da origem, de trechos processados, de embeddings, de resultados de recuperação e de respostas finais. Cada um precisa de uma chave que incorpore as dependências relevantes, como a versão do índice, a revisão das fontes, a identidade da pessoa ou seu grupo de acesso, a jurisdição e a data da consulta quando se responde sobre vigência. Reutilizar uma resposta sem essas dimensões pode revelar conteúdo ou ressuscitar uma política retirada.

Os princípios de cache web distinguem frescor, validação e invalidação, e estabelecem que solicitações que alteram o estado do recurso devem invalidar as representações armazenadas aplicáveis. Em um corpus RAG, o mecanismo concreto pode ser diferente, mas o princípio é transferível: quando uma fonte ou sua elegibilidade muda, é preciso localizar e remover ou invalidar as representações derivadas que ainda poderiam servir a versão anterior.

Os duplicados semânticos exigem uma política explícita. Dois trechos podem expressar a mesma regra e pertencer a revisões distintas; retornar ambos pode aumentar artificialmente a confiança do modelo. Agrupe candidatos por documento canônico ou por relação de revisão antes de gerar a resposta. O agrupamento não deve ocultar conflitos: se duas fontes ativas e igualmente autorizadas divergem, preserve o conflito como sinal para abster-se ou solicitar revisão humana.

Recuperar com tempo, autoridade e permissões antes de ordenar por similaridade

A consulta de recuperação deve ser construída como uma sequência de restrições e ordenação, e não como uma busca vetorial seguida de uma verificação opcional. Primeiro, determine o contexto: identidade de quem consulta, permissões efetivas, produto, jurisdição, audiência, data relevante e possível necessidade de consultar o histórico. Depois, filtre as revisões e os trechos que não atendem a esse contexto. Somente os candidatos elegíveis devem seguir para o cálculo de similaridade, para a busca lexical ou para uma combinação de ambas.

A data relevante merece uma decisão de produto visível. Para perguntas sobre a norma atual, use o momento da consulta. Para perguntas como “qual política se aplicava quando assinei?”, solicite ou infira com cautela uma data de referência e busque no histórico autorizado. Se a data não for conhecida, não apresente uma reconstrução histórica como se fosse atual. É preferível pedir a informação, mostrar o alcance temporal da evidência ou limitar a resposta ao que puder ser justificado.

A autoridade pode ser implementada como uma pontuação, mas não deveria ser sempre reduzida a um número. Algumas regras são rígidas: uma norma obrigatória para uma jurisdição pode excluir uma orientação geral. Outras podem ser preferenciais e admitir coexistência. Documente as regras, seu proprietário e as exceções. O sistema generativo não deve inventar uma hierarquia a partir do tom dos documentos.

Antes de redigir, preserve a lista de candidatos filtrados, os motivos de exclusão, a configuração do índice e os trechos finalmente utilizados. O registro deve distinguir entre evidência recuperada e evidência citada na resposta. Também deve registrar a hora da consulta e a versão das regras de filtragem. Sem esses dados, uma investigação posterior pode encontrar o documento atual, mas não demonstrar qual corpus produziu o resultado original.

Testes de regressão, critérios de interrupção e responsabilidades

Os testes devem avaliar o comportamento do sistema diante de mudanças, e não apenas a qualidade da recuperação em um conjunto estável. Construa casos com uma política retirada que preserve maior similaridade do que sua substituta, um trecho removido de uma revisão, uma política aprovada com data de vigência futura, uma cópia local que contradiz uma fonte central e uma permissão revogada após a indexação. Cada caso deve declarar quais documentos são elegíveis, qual deve prevalecer se houver uma regra de autoridade e quando a saída correta é abster-se.

Teste também a propagação temporal. Meça o prazo entre a aprovação de uma retirada e sua exclusão efetiva de índices, réplicas e caches relevantes. Não basta testar o índice principal: uma resposta previamente gerada pode estar armazenada em outra camada. Defina objetivos de tempo distintos conforme o risco da fonte. Uma política de segurança ou um documento com dados sensíveis pode exigir invalidação mais rápida do que uma orientação editorial interna.

Estabeleça critérios de interrupção claros. Bloqueie uma resposta quando faltar o vínculo entre trecho e revisão, quando as permissões não puderem ser avaliadas, quando a fonte não tiver proprietário ou quando houver conflito ativo sem regra de precedência. Mostre a data de atualização quando ela ajudar a interpretar a resposta, mas não a use para encobrir incerteza. Encaminhe para revisão humana se houver evidência potencialmente relevante que o sistema não consiga ordenar com regras explícitas.

As responsabilidades devem ser separadas, embora uma mesma pessoa possa assumir várias em equipes pequenas. O proprietário da fonte responde pelo conteúdo e por seu ciclo de vigência. O responsável pela indexação responde pela extração, publicação e invalidação técnica. O aprovador de vigência decide quando uma revisão é utilizável. O responsável por incidentes coordena a retirada urgente, a avaliação de exposição e a comunicação. A equipe de produto define como a abstenção é expressa e como contexto adicional é solicitado à pessoa usuária.

Como próximo passo, transforme este modelo em uma lista de controles verificáveis e relacione-o aos guias do centro de aprendizado sobre avaliação de assistentes, comparação de abordagens de recuperação e descoberta de fontes. A implementação dependerá da arquitetura, mas o critério de sucesso permanece: para cada resposta relevante, a equipe deve conseguir explicar qual evidência podia ser usada, qual foi usada, por que era autorizada e o que teria impedido a resposta.

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.