Porque é que as atualizações parciais de ficheiros deixam excertos desatualizados num índice RAG local?
As atualizações parciais de ficheiros deixam passagens RAG obsoletas quando são inseridos novos fragmentos sem invalidar todos os fragmentos indexados derivados da versão anterior do ficheiro.
Uma base de conhecimento local raramente armazena um vetor por ficheiro. Extrai texto, divide o ficheiro em fragmentos, gera embeddings, associa metadados e pode colocar em cache resultados analisados ou recuperados. Editar um parágrafo pode deslocar os limites dos fragmentos seguintes, alterar hashes, remover texto antigo e criar novos IDs de fragmentos. Se o fluxo de atualização processar apenas as partes alteradas ou recém-detetadas, as passagens antigas podem continuar pesquisáveis juntamente com o conteúdo substituto, mesmo que o próprio ficheiro de origem pareça correto.
Um Ficheiro de Origem Torna-se Muitos Registos de Índice Independentes
Uma atualização de documento não corresponde a uma única atualização de linha na base de dados quando o pipeline de ingestão armazena vários fragmentos, registos de páginas, resumos e embeddings.
A OptyxStack explica que a substituição parcial pode deixar fragmentos antigos e novos misturados da mesma família de documentos.
A nova passagem pode ser indexada com sucesso, enquanto uma passagem mais antiga, com um identificador diferente, continua válida do ponto de vista da base de dados vetorial.
Pequenas Edições Podem Deslocar Todos os Limites dos Fragmentos Seguintes
Adicionar um parágrafo perto do início altera as posições dos tokens utilizadas pelos fragmentadores de tamanho fixo ou sobrepostos. Vários fragmentos seguintes podem receber conteúdo novo, mesmo quando o respetivo texto de origem não foi editado diretamente.
A Extend descreve como a deriva da ingestão surge quando as premissas de fragmentação e metadados mudam entre documentos ou atualizações.
Um atualizador que volte a gerar embeddings apenas para a região visivelmente editada pode não detetar os fragmentos posteriores cujos limites ou sobreposição foram alterados. As posições estáveis na origem, por si só, não são suficientes quando a extração ou a fragmentação produz um novo esquema.
A identidade da versão do documento deve agrupar todos os registos derivados, para que o pipeline possa substituir toda a família antiga quando necessário.
Os Caminhos de Inserção São Muitas Vezes Mais Testados do que os Caminhos de Eliminação
Os trabalhos de ingestão verificam naturalmente se foram criados novos fragmentos. Podem não demonstrar que os fragmentos removidos da origem já não são pesquisáveis.
A análise de Ranjan Kumar sobre a lacuna de obsolescência do índice trata os eventos de inserção, atualização e eliminação como alterações distintas que necessitam todas de propagação.
Uma secção renomeada ou um parágrafo eliminado pode sobreviver indefinidamente quando o trabalhador de atualização executa upserts, mas não dispõe de um marcador de eliminação nem de um inventário dos fragmentos antigos.
Teste a eliminação pesquisando frases distintivas do conteúdo removido após cada caminho de atualização.
Um Trabalho Concluído com Sucesso Pode Ainda Deixar o Índice Parcialmente Atualizado
A análise, a fragmentação, a geração de embeddings, a eliminação, a inserção, a escrita de metadados e a invalidação da cache podem ser executadas como etapas separadas. Algumas podem ser concluídas antes de uma falha noutro trabalhador.
Jamie Maguire descreve a lacuna operacional em que um trabalho de ingestão parece ter sido concluído com sucesso, ou é concluído apenas parcialmente, enquanto o índice de pesquisa permanece obsoleto.
Um único estado final pode ocultar qual versão do ficheiro, número de fragmentos e conjunto de embeddings se tornaram realmente consultáveis. Registe a conclusão ao nível de cada etapa e a última versão do documento totalmente confirmada.
A Fragmentação do Índice Permite que Versões em Conflito Compitam
Quando as passagens antigas e recentes partilham o mesmo nome de ficheiro ou ID de documento, ambas podem parecer relevantes para a mesma consulta.
A lista de verificação de falhas da LlamaIndex identifica a fragmentação do índice como uma causa de recuperação contraditória e dados obsoletos após atualizações da origem.
O modelo de resposta pode selecionar a formulação antiga por ter uma correspondência lexical mais forte ou um fragmento mais curto e mais limpo. Os metadados de atualidade só ajudam quando o recuperador ou o reranqueador os utiliza efetivamente.
A supressão de duplicados deve comparar a versão da origem e a identidade do conteúdo, não apenas a similaridade vetorial.
Reconcilie o Índice Antes de Promover uma Nova Versão do Documento
Um pipeline local deve comparar periodicamente os ficheiros de origem com as famílias de documentos indexadas, os hashes dos fragmentos, as versões e os marcadores de eliminação, em vez de confiar apenas nos eventos do monitor ou nas contagens de upserts concluídos com sucesso.
O guia da Oracle sobre deriva do índice recomenda a reconciliação entre origem e índice, para que o conteúdo atualizado e eliminado seja verificado após a ingestão.
Crie os fragmentos de substituição sob uma nova versão do documento, verifique a respetiva contagem, os metadados e o comportamento de recuperação e, em seguida, altere a versão ativa antes de retirar a família anterior. Isto impede que um trabalho de eliminação ou de geração de embeddings incompleto exponha duas versões como igualmente atuais.
O artigo da ZimaSpace sobre indexação em segundo plano explica por que motivo a deteção de alterações é apenas uma parte do pipeline mais amplo de extração e base de dados.
A atualização mais segura nem sempre é a mais pequena. Para ficheiros domésticos curtos, substituir uma família de documentos completa pode ser mais simples e fiável do que tentar aplicar uma correção frágil ao nível dos fragmentos.
FAQ
Alterar a data de modificação do ficheiro atualiza todos os fragmentos?
Não. O monitor pode detetar o ficheiro, mas o código de ingestão continua a ter de identificar, substituir e invalidar todos os registos derivados da versão anterior.
A similaridade vetorial pode suprimir automaticamente os fragmentos obsoletos?
Não. As passagens antigas e novas podem ser semanticamente relevantes. A similaridade não determina qual é a versão atual.
É sempre necessário reconstruir todo o índice?
Não. A substituição da família de documentos e a reconciliação podem preservar a operação incremental, mas os caminhos de eliminação e de versionamento devem ser testados com o mesmo rigor que a inserção.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Porque é que as previsões da casa inteligente se tornam menos precisas após mudanças sazonais na rotina?
As rotinas sazonais alteram a relação entre o tempo, os sensores, a ocupação e as ações pretendidas, tornando obsoleto um modelo treinado com hábitos...
Porque é que um NVR doméstico não regista eventos breves quando o seguimento de objetos está ativado?
O seguimento precisa de deteções suficientes para iniciar e confirmar uma trajetória, pelo que um objeto que apareça brevemente pode desaparecer antes de o...
Porque é que as etiquetas de fotografias geradas por IA mudam após uma atualização do modelo?
Uma atualização do modelo altera a representação e a classificação utilizadas para atribuir etiquetas, pelo que a mesma fotografia pode ultrapassar diferentes limites semânticos...
