A fonte sumiu da resposta, mas não da base

Uma ausência muito convincente

Em um assistente que responde perguntas com citações, a busca por trechos acontece antes de o texto ser escrito. A pessoa vê a resposta pronta, mas não sabe se todas as fontes foram consultadas. Ali, a resposta trazia uma ressalva que parecia cuidadosa: aquele assunto não constava dos trechos recuperados. Seria uma frase adequada se a busca tivesse funcionado e não encontrado evidência. Só que o documento continuava na base. O sistema é que não estava conseguindo chegar até ele.

Isso apareceu depois de uma atualização do índice. A fonte principal deixou de ser citada nas perguntas de revisão, enquanto as demais fontes ainda apareciam. O assistente não precisava inventar nada para induzir ao erro. Bastava apresentar um resultado vazio como se fosse uma conclusão sobre o conteúdo.

Uma lista vazia parece um fato simples. Em um sistema de recuperação, ela pode esconder duas histórias bem diferentes: consultei a fonte e não achei o trecho; ou não consegui consultar a fonte.

O arquivo novo e a referência antiga

O índice era recriado na atualização. Ao mesmo tempo, processos que continuavam atendendo perguntas guardavam uma referência aberta para a versão anterior da tabela. Essa referência apontava para arquivos que já não existiam. A consulta falhava ao tentar ler os dados antigos, embora a tabela nova estivesse disponível.

Limpar o cache no processo que fez a atualização ajudava ali, mas não alcançava os outros processos já ativos. Também não dava para contar com uma reinicialização imediata. Enquanto continuassem funcionando, eles guardariam referências para arquivos removidos.

A parte menos visível estava no tratamento do erro. A busca transformava a falha em uma lista vazia. Na etapa seguinte, essa lista virava uma indicação de que a fonte não continha trechos relevantes. O assistente recebia uma aparente ausência de conteúdo, quando o problema era a consulta à fonte.

Uma segunda tentativa, por um motivo específico

A correção precisava começar antes da resposta. Quando o erro indicava que a referência apontava para arquivos removidos, o processo descartava a referência, abria a tabela atual e tentava a consulta mais uma vez. Uma vez só: se a nova leitura também falhasse, insistir indefinidamente apenas esconderia uma falha real por mais tempo.

Havia uma sutileza na busca: ela tentava uma seleção mais completa de colunas e podia recuar para uma seleção básica quando encontrava um índice antigo. Se o erro fosse de referência obsoleta, esse recuo não podia engoli-lo. Era preciso deixar a falha subir até a rotina que sabia reabrir a tabela.

Se a segunda tentativa também falhasse, o problema precisava aparecer nos registros do sistema. O código passou a registrar o erro para permitir o monitoramento. Mas ainda devolvia uma lista vazia para a etapa que montava o contexto. A equipe ganhava um alerta; o leitor continuava sujeito à mesma ambiguidade.

O que a revisão consegue afirmar

O registro do incidente descreve processos ativos com referências antigas após a atualização e a ausência da fonte principal nas perguntas de revisão. No código, há recuperação com uma única tentativa para esse tipo de erro e um registro explícito quando a fonte prioritária fica vazia. Os testes cobrem o erro observado, a reabertura, o limite de uma tentativa e a propagação de falhas sem relação com a referência.

Essas verificações não demonstram que toda resposta futura distinguirá falta de conteúdo e falta de acesso. Na implementação examinada, o alerta operacional melhora, mas a interface ainda recebe uma lista vazia se a segunda tentativa falhar. A próxima fronteira é levar um estado de indisponibilidade até a resposta, para que o leitor não receba uma conclusão sobre um documento que o sistema não conseguiu consultar.