O RAG pode citar um ficheiro antigo após a sincronização porque a chegada do ficheiro, a ingestão bem-sucedida, a ativação do índice e a seleção da versão atual são transições de estado distintas.
Uma interface NAS pode mostrar imediatamente a nova cópia, enquanto o índice de recuperação ainda contém apenas a versão anterior. Mesmo depois de o novo documento ser convertido em embeddings, ambas as cópias podem continuar pesquisáveis, e o fragmento mais antigo pode obter uma classificação superior porque o seu texto, metadados ou vetor correspondem melhor. Um sistema fiável precisa de uma identidade de versão explícita e de uma ativação atómica, não apenas da recência do nome do ficheiro.
A Sincronização Termina Antes de o Pipeline de Recuperação
Um cliente de sincronização considera o trabalho concluído depois de os bytes e metadados chegarem ao destino. O indexador ainda tem de detetar a alteração, aguardar que o ficheiro esteja estável, analisá-lo ou aplicar-lhe OCR, dividi-lo, gerar embeddings, escrever registos e publicar uma geração do índice.
Uma descrição de atualização incremental do índice separa a deteção de alterações, o processamento de conteúdo e as atualizações do índice. Esse modelo faseado explica a lacuna de atualização em que um ficheiro está presente no armazenamento, mas indisponível para recuperação. Esta distinção continua visível durante os testes domésticos posteriores.
Filas, recuos entre tentativas, ficheiros bloqueados, formatos não suportados ou salvaguardas contra cópias parciais podem prolongar a lacuna. Comparar os carimbos temporais do NAS com os carimbos temporais de confirmação do índice revela mais do que verificar se o novo nome de ficheiro existe. O resultado intermédio deve continuar a ser inspecionável antes de a automatização avançar.
Ambas as Versões Podem Competir Depois de a Nova Cópia Ser Indexada
Se o ficheiro atualizado receber um novo ID de documento sem que o antigo seja retirado, a recuperação trata-os como evidências independentes. Conteúdo semelhante produz fragmentos quase idênticos, e pequenas alterações de redação ou nos limites dos fragmentos determinam qual obtém a classificação mais alta.
A abordagem de recuperação sensível à atualidade estuda a recuperação sensível à atualidade para conhecimento em mudança. A sua premissa mostra por que razão a relevância, por si só, é insuficiente quando coexistem várias respostas válidas em momentos diferentes. Esse limite deve ser medido separadamente em condições de funcionamento realistas.
A data de modificação do sistema de ficheiros é uma identidade de versão fraca, porque a cópia pode preservá-la ou reescrevê-la, os relógios podem diferir e os ficheiros renomeados podem representar a mesma linhagem. Um ID de documento estável, juntamente com uma versão monotónica ou uma linhagem de conteúdo, é mais seguro.
A Montagem da Citação Pode Preservar um Mapeamento de Origem Obsoleto
O gerador pode utilizar um fragmento atual enquanto uma cache de citações, um serviço de pré-visualização ou uma tabela de origem ainda resolve o seu ID lógico para um caminho antigo. Por outro lado, o próprio resultado da recuperação pode estar obsoleto, enquanto o nome de ficheiro apresentado parece atual.
Uma estrutura para mapeamentos de proveniência de dados trata a proveniência como mapeamentos de artefactos derivados para as entradas de origem e transformações. Aplicar essa cadeia ao RAG distingue uma recuperação obsoleta de uma apresentação de citação obsoleta. A consequência prática surge quando várias fontes competem por um contexto limitado.
O limite de falha consiste em avaliar a atualidade apenas a partir do rótulo da citação. Verifique os bytes citados, o ID da versão, o hash do conteúdo, o carimbo temporal da indexação, o fragmento recuperado e a origem apresentada. Um ficheiro antigo renomeado e um documento realmente atual podem partilhar um nome amigável.
Teste a Ativação da Versão Com uma Atualização Controlada do Ficheiro
Crie um documento cujas versões antiga e nova contenham factos distinguíveis. Registe a conclusão da sincronização, o evento do observador, a conclusão da análise, a gravação do embedding, a geração do índice ativo, o marcador da versão retirada, o resultado da recuperação, a resolução da citação e a pré-visualização da origem enquanto consulta o sistema ao longo da atualização.
Compare a implementação com o controlo de versões de documentos para RAG. A nova versão deve tornar-se ativa atomicamente, e a anterior deve deixar de participar nas consultas atuais sem destruir a linhagem necessária para explicar respostas históricas. Esta dependência deve continuar explícita na interface final.
Considere aprovado apenas quando os filtros da versão atual selecionarem os novos bytes após a ativação e as consultas durante a ingestão devolverem a última versão completa ou um estado explícito de atualização. Se ambas as versões obtiverem classificação, corrija a identidade e a retirada antes de ajustar a semelhança.
Centro de Tecnologia e IA
Mais para Ler

Porque é que as alterações de ficheiros SMB chegam a um indexador incremental em rajadas?
Veja como o armazenamento em cache de escrita SMB, as concessões, CHANGE_NOTIFY, o transbordamento do buffer, a reconexão e o processamento em lotes do...

Porque é que o OCR não deteta texto ténue depois de um PDF ser recomprimido?
Saiba como a recompressão de PDF altera pixels ténues, por que razão os visualizadores podem ocultar essa perda e como testar a resolução, o...

Porque é que a latência da IA local oscila com a curva da ventoinha de um servidor doméstico?
Veja como o calor, o controlo da ventoinha, os limites do relógio, o atraso dos sensores e o timing da carga de trabalho criam...

