Documentos órfãos no Azure AI Search: como remover

O arquivo saiu da pasta, mas continua aparecendo na resposta

Uma empresa remove uma política comercial da fonte. O agente de atendimento continua encontrando trechos dela. A busca funciona, o modelo cita o documento e a resposta parece sustentada. O índice ainda conserva uma cópia que perdeu sua origem válida.

No Azure AI Search, atualizar arquivos e detectar exclusões são comportamentos diferentes. A documentação da Microsoft explica que determinadas estratégias de indexação precisam de uma política explícita de exclusão. Em outros caminhos, a aplicação precisa remover os documentos pelas chaves que gravou.

Este guia trata da limpeza de documentos órfãos num índice específico. O resultado esperado é um manifesto de chaves removidas e verificadas, com evidência de escopo e pendências. Ele complementa a política de retenção de dados, que define finalidade e ciclo de vida, e a sincronização incremental, que mantém uma projeção entre rodadas.

As fontes oficiais foram consultadas em 21 de outubro de 2026. Os exemplos são sintéticos. Nenhum índice Azure foi alterado para produzir este artigo.

Descubra quem escreve e quem deve limpar

Antes de apagar, identifique serviço, índice, ambiente, cliente, origem e responsável pelo caminho de ingestão. Um índice pode reunir conteúdo de vários produtores. Uma rotina não deve limpar registros pertencentes a outra.

Registre como cada documento chega:

• aplicação que envia documentos diretamente, no modo push;
• indexador com relação entre arquivo de origem e documento de busca;
• parsing direto de linhas CSV ou elementos JSON;
• projeção que cria trechos filhos a partir de um documento pai.

Esses caminhos não possuem o mesmo ciclo de exclusão. No modo push, a aplicação responde pela remoção. No parsing direto de linhas ou elementos, retirar uma linha do arquivo pode deixar seu registro antigo no índice. A documentação de múltiplos indexadores atribui essa limpeza à aplicação.

Projeções de documentos possuem outro mecanismo de relacionamento com o pai. Não transfira automaticamente as regras de parsing de CSV para projeções de chunks. Confira a configuração e o contrato do recurso efetivamente utilizado.

Quando soft delete evita o órfão

Para os cenários suportados com Azure Storage, a Microsoft descreve duas estratégias: soft delete nativo de blobs e marcação por metadado personalizado.

Na estratégia por metadado, o fluxo documentado é:

1. marcar a fonte para exclusão;
2. executar o indexador com a política correspondente;
3. confirmar que o documento saiu do índice;
4. só então remover fisicamente o arquivo da origem.

O soft delete nativo possui requisitos próprios. A documentação consultada exige suporte do tipo de armazenamento, chave compatível e ausência de blob versioning nesse caminho. O indexador precisa observar o blob ainda no estado de soft delete. Por isso, a retenção desse estado precisa acomodar o intervalo de execução e possíveis interrupções.

Definir a política depois do problema não reconstrói todos os sinais perdidos. A Microsoft alerta que documentos removidos antes de uma política configurada desde a primeira execução podem continuar no índice, mesmo após adicionar a política e reiniciar o indexador.

Nesse caso, avalie limpeza explícita pelas chaves ou reconstrução controlada. Reiniciar repetidamente o mesmo indexador pode preservar exatamente os registros que você quer retirar.

Prepare um manifesto antes de executar deletes

O campo-chave do índice identifica o documento de busca. Ele pode ser diferente do identificador empresarial, do nome do arquivo ou do ID do documento pai.

Confira o schema e guarde as chaves reais. Para chunks, preserve também o vínculo com a origem. Não tente adivinhar chaves geradas a partir do título do arquivo.

Um manifesto de limpeza deve conter:

operacao: LIMPEZA-SINTETICA-01
ambiente: homologacao
indice: conhecimento-exemplo
produtor: csv-politicas
escopo: cliente-ficticio-A
versao_da_fonte: exportacao-confirmada-17
coleta_da_fonte: COMPLETA
chaves_candidatas: [csv_a_02, csv_a_04]
aprovador: preencher antes da execucao
estado: PROPOSTA

Esse manifesto é ilustrativo. Campos de produtor e escopo precisam corresponder a metadados verificáveis ou a um registro de propriedade mantido pela aplicação.

Para cada candidata, preserve a evidência que justifica a remoção. Se a decisão é por ausência na fonte, confirme que a fonte foi percorrida por completo, com acesso ao mesmo conjunto e sem filtros novos.

Uma exportação vazia depois de um erro de permissão não autoriza esvaziar o índice. A paginação de APIs ajuda a separar coleta completa de travessia interrompida.

EXEMPLO SINTÉTICO — proposta documental de limpeza
Ambiente: homologacao | Índice: conhecimento-exemplo
Produtor: csv-politicas | Escopo: cliente-ficticio-A
Fonte: exportacao-confirmada-17 | Coleta: COMPLETA
Índice no mesmo produtor e escopo: {csv_a_01, csv_a_02, csv_a_03, csv_a_04, csv_a_05}
Fonte completa autorizada: {csv_a_01, csv_a_03, csv_a_05}
Diferença candidata: {csv_a_02, csv_a_04}
Fora da operação: pdf_b_01, de outro produtor.
Estado: PROPOSTA | Aprovador: preencher antes da execução.
Antes de autorizar: confirmar completude, propriedade das chaves e snapshots equivalentes; coleta incremental ou interrompida bloqueia a diferença como fundamento de delete.
Após eventual execução real: ler resultado por chave, consultar ausência individual e testar recuperação com documentos de controle. Sucesso de delete não prova existência anterior. Manter falhas parciais pendentes; caches e exportações exigem tratamento próprio.

Compare conjuntos equivalentes

Considere um exemplo fictício de documentos enviados por uma aplicação:

CHAVES NO ÍNDICE PARA O PRODUTOR csv-politicas E O CLIENTE A
csv_a_01
csv_a_02
csv_a_03
csv_a_04
csv_a_05

CHAVES AUTORIZADAS NA EXPORTAÇÃO COMPLETA 17
csv_a_01
csv_a_03
csv_a_05

REGISTRO DE OUTRO PRODUTOR, FORA DO ESCOPO
pdf_b_01

A diferença entre os dois primeiros conjuntos aponta csv_a_02 e csv_a_04 como candidatas. pdf_b_01 permanece fora da operação.

Essa comparação só vale quando o contrato informa que a exportação representa o conjunto completo de documentos autorizados naquele escopo. Uma lista incremental não serve como inventário total. Se a coleta retorna apenas mudanças, ausência não significa exclusão.

Também evite comparar snapshots de momentos incompatíveis enquanto há novos escritores ativos. Fixe uma versão ou coordene a manutenção com o produtor. Caso contrário, uma chave recém-criada pode parecer órfã porque a lista da fonte foi capturada antes dela.

Exclua pelas chaves e leia o resultado de cada item

A API de indexação aceita a ação delete. No exemplo abaixo, o schema fictício usa id como campo-chave:

{
  "value": [
    {"@search.action": "delete", "id": "csv_a_02"},
    {"@search.action": "delete", "id": "csv_a_04"}
  ]
}

O corpo é uma especificação documental, não um pedido executado. O endpoint, a versão da API, a identidade e o nome real do campo-chave devem vir da configuração homologada. Use uma identidade autorizada para o índice e mantenha credenciais fora do prompt, dos exemplos e dos logs.

A Microsoft documenta exclusão idempotente: tentar excluir uma chave inexistente também pode retornar sucesso. Isso permite repetir o delete de uma chave conhecida quando necessário, mas impede usar o retorno como prova de que o registro existia antes.

Inspecione o resultado por documento. Se um lote trouxer falha em parte dos itens, mantenha a pendência apenas nas chaves não confirmadas. O guia de falha parcial em lotes detalha esse controle.

Erros de formato ou permissão precisam de correção. Indisponibilidade temporária pode admitir nova tentativa limitada. Nenhum erro autoriza ampliar o escopo de exclusão.

Confirme ausência sem confundir falha de consulta com limpeza

Após o delete, consulte cada chave no serviço e índice corretos. A documentação aponta 404 de documento não encontrado como evidência esperada para a consulta individual. Um índice inexistente, acesso negado ou timeout exige investigação; não comprova ausência do documento.

Complete a conferência com consultas de recuperação que representem o uso do agente. Verifique que as chaves removidas não retornam e que os documentos de controle continuam acessíveis. Uma consulta sem resultados pode indicar filtro errado, indisponibilidade ou falta de permissão.

As estatísticas de quantidade e armazenamento ajudam, mas possuem atraso. A Microsoft informa que a remoção física e a atualização de métricas podem acontecer depois. Espaço vetorial liberado e conteúdo que deixou de ser recuperável são observações diferentes.

O registro de encerramento deve separar:

• pedido de exclusão aceito;
• chaves cuja ausência foi confirmada;
• consultas funcionais verificadas;
• métricas ainda aguardando atualização;
• outros derivados fora do escopo desta operação.

Caches de resposta, conversas antigas e exportações não desaparecem porque o índice foi limpo. A linhagem de dados ajuda a localizar esses caminhos sem alegar eliminação completa após uma única operação.

Teste a limpeza antes de aplicá-la ao acervo real

Use um índice de homologação e conteúdo sintético. Inclua uma chave órfã, uma chave válida, outra de produtor diferente e uma chave já ausente.

O teste precisa mostrar que a rotina mantém escopo, tolera repetição e deixa falha parcial visível. Acrescente uma coleta incompleta e confirme que ela bloqueia o plano de exclusão. Por fim, execute novamente o produtor para verificar se ele recria indevidamente o conteúdo removido.

Para o exemplo deste artigo, uma checagem local de conjuntos confirmou duas candidatas e a preservação das três chaves válidas e do registro externo. Essa checagem não testa Azure, concorrência, consistência do serviço ou comportamento do indexador. Esses pontos dependem de execução real na arquitetura escolhida.

Quando encerrar a operação

O responsável técnico deve conseguir apresentar o escopo aprovado, a versão completa da fonte, as chaves tratadas e a leitura de confirmação de cada destino. O dono do processo valida que o conteúdo restante corresponde ao que o agente pode consultar.

Se houver chave sem prova de origem, falha de coleta ou produtor capaz de reintroduzir o registro, mantenha a limpeza pendente. Corrigir o caminho de ingestão evita que a próxima execução recrie o problema.

Fontes oficiais

Consultadas em 21 de outubro de 2026:

• Microsoft Learn: Delete documents in a search index, para chaves, ação de exclusão, resultado por documento, idempotência e conferência.
• Microsoft Learn: Change and delete detection for Azure Storage, para políticas de soft delete, ordem das operações, requisitos e documentos órfãos anteriores à política.
• Microsoft Learn: Multiple indexers for one search index, na seção de operação e reconciliação, para propriedade das chaves e diferença entre projeções e parsing direto. O tutorial dessa fonte usa recursos preview; este artigo não prescreve sua implantação nem depende deles.