Como é que o controlo de versões de documentos mantém as respostas RAG associadas aos ficheiros atuais?
O controlo de versões dos documentos mantém as respostas RAG atualizadas, associando cada segmento indexado a uma identidade documental estável e a um estado de revisão explícito.
Uma base de conhecimento doméstica pode conservar simultaneamente um contrato de arrendamento antigo, uma apólice de seguro revista, um guia de router atualizado, um plano de projeto editado e um procedimento doméstico arquivado. A semelhança semântica, por si só, não consegue determinar qual é hoje a fonte autorizada, porque uma revisão antiga pode corresponder à consulta tão bem quanto o ficheiro novo. O controlo de versões acrescenta informações sobre o ciclo de vida que a recuperação pode aplicar antes de o modelo de resposta receber as evidências.
Uma identidade documental estável deve sobreviver a renomeações e revisões de ficheiros
O primeiro requisito é separar “que documento é este?” de “que revisão deste documento é esta?”. Um caminho ou nome de ficheiro, por si só, é frágil, porque os utilizadores renomeiam, movem, copiam e substituem ficheiros.
Identificadores e payloads estáveis de pontos podem armazenar um ID do documento principal, um ID da revisão, a posição do segmento e campos de estado atual, sem tornar o próprio caminho do ficheiro na única chave de identidade.
Quando um ficheiro é editado, o pipeline deve criar ou reconhecer uma nova revisão dentro da mesma família documental, em vez de o tratar como uma fonte não relacionada.
Esta camada de identidade também impede que um ficheiro de arquivo copiado se torne silenciosamente um segundo documento “atual” apenas porque o seu caminho mudou.
Os metadados de revisão fornecem um filtro de estado atual para a recuperação
Cada segmento pode herdar metadados como o número da revisão, o hash do conteúdo, a hora de ingestão, a data de entrada em vigor, o caminho da fonte, o ID do documento principal e um estado como ativo, substituído, rascunho ou arquivado.
Acompanhar a atualidade e substituição das fontes é importante porque uma passagem antiga pode continuar a ser muito semelhante a uma consulta sobre o estado atual, mesmo depois de uma revisão mais recente se tornar a fonte autorizada.
Uma consulta sobre o estado atual pode filtrar a revisão ativa antes de calcular a semelhança vetorial ou antes de aceitar os candidatos finais. Uma consulta histórica pode alargar deliberadamente esse filtro a uma data ou revisão solicitada.
Os novos segmentos devem tornar-se ativos como uma revisão coerente
Os ficheiros grandes são normalmente divididos em vários segmentos, pelo que uma atualização cria uma família de registos, e não um único vetor. Publicar esses segmentos um a um pode expor um estado misto, no qual algumas passagens são novas e outras antigas.
As atualizações incrementais de embeddings podem preservar os registos inalterados, substituindo ou removendo os segmentos derivados associados ao conteúdo da fonte que foi alterado e mantendo a transição da revisão limitada a uma única família documental.
Uma transição de versão mais segura cria a nova família, verifica os segmentos e metadados esperados e só depois muda a revisão ativa, quando a ingestão for concluída com sucesso.
Se o processamento falhar a meio do OCR, da divisão em segmentos, da criação de embeddings ou da inserção de vetores, a revisão completa anterior pode continuar ativa, em vez de expor um documento híbrido.
Os segmentos substituídos devem ser retirados da recuperação predefinida, não necessariamente destruídos
Conservar o histórico é útil para auditorias, comparações de alterações e perguntas sobre o que uma política dizia no ano passado. O problema não é a existência de segmentos antigos; é permitir que concorram em igualdade de condições com as evidências atuais.
Os registos RAG associados à fonte mantêm os vetores associados a metadados ao nível do documento, para que as revisões possam ser geridas sem perder a relação com a fonte original.
Uma revisão substituída pode continuar disponível através de um filtro de arquivo, ficando excluída das perguntas normais sobre o estado atual. Esta separação preserva a rastreabilidade sem obrigar o modelo de resposta a decidir em qual de várias passagens quase idênticas deve confiar.
As citações precisam da mesma identidade de versão usada pela recuperação
O controlo de versões fica incompleto quando a recuperação seleciona o segmento atual, mas a apresentação da citação reconstrói uma ligação usando apenas o nome do ficheiro, o caminho ou a família documental.
Mesmo quando a recuperação encontra um segmento atual, os metadados das citações podem divergir do estado da recuperação se a camada de citações reconstruir as referências a partir de identificadores menos fiáveis, como apenas o nome ou o caminho do ficheiro.
O registo da citação deve incluir o ID da revisão, o caminho da fonte ou uma referência imutável ao objeto, a localização da página ou do segmento e o mesmo estado ativo/histórico utilizado durante a pesquisa.
Assim, o utilizador pode verificar a revisão exata que fundamentou a resposta, em vez de abrir um ficheiro mais recente cujo texto já não corresponde às evidências citadas.
O controlo de versões continua a depender de uma deteção fiável de alterações
Um esquema consciente das versões não ajuda quando o pipeline de ingestão nunca deteta que uma fonte foi alterada ou quando uma atualização falhada deixa os registos antigos ativos indefinidamente.
A consistência fiável da ingestão é um pré-requisito para a recuperação consciente das versões, porque o índice não pode selecionar uma revisão que nunca foi ingerida de forma completa ou correta.
Observadores de ficheiros, reconciliação agendada, hashes de conteúdo, fluxos de alterações da base de dados e eventos explícitos de carregamento podem alimentar o ciclo de vida das versões. A camada de controlo de versões decide então qual revisão se torna atual.
As respostas atuais só permanecem fiáveis quando a deteção, a ingestão, a ativação, a recuperação e as citações utilizam o mesmo contrato de identidade documental e de revisão.
FAQ
Um carimbo temporal de modificação do ficheiro é suficiente para definir uma versão RAG?
Não. Os carimbos temporais podem mudar durante operações de cópia ou restauro e não identificam qual conteúdo ou família de segmentos se tornou a fonte autorizada. Um ID documental estável, juntamente com metadados de revisão explícitos, é uma opção mais segura.
As versões antigas dos documentos devem ser eliminadas da base de dados vetorial?
Não necessariamente. Podem continuar disponíveis para consulta histórica ou auditorias, desde que a recuperação predefinida as exclua e as citações preservem claramente a respetiva identidade de revisão.
O controlo de versões pode impedir respostas desatualizadas quando as atualizações nunca são detetadas?
Não. O controlo de versões gere as revisões conhecidas. Continua a ser necessário um mecanismo separado de deteção de alterações e reconciliação para descobrir edições, eliminações ou tarefas de ingestão falhadas que não tenham sido detetadas.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
As câmaras domésticas conseguem sincronizar eventos sem serviços de hora na nuvem?
Uma explicação baseada primeiro no mecanismo do tempo da câmara sem cloud, as suas contrapartidas na partilha de recursos, três perguntas frequentes sobre a...
Um serviço de IA local consegue detetar camadas de modelos corrompidas antes da inferência?
Uma explicação baseada primeiro no mecanismo da deteção de corrupção na camada do modelo, dos seus compromissos em termos de recursos partilhados, de três...
É possível restaurar um sistema RAG sem regenerar todos os embeddings?
Uma explicação, centrada no mecanismo, do restauro de RAG sem re-embedding, das suas contrapartidas em recursos partilhados, de três perguntas frequentes sobre a expansão...
