Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Note
O Pesquisa de IA do Azure está disponível através do portal Azure, APIs REST e SDKs do Azure. Também sustenta o Foundry IQ, a camada de conhecimento gerida que transforma conteúdos empresariais em bases de conhecimento reutilizáveis e conscientes de permissões para agentes no portal Microsoft Foundry.
Este artigo responde a perguntas comuns sobre métricas de armazenamento que parecem inconsistentes entre o portal Azure, APIs REST e SDKs Azure.
Os valores de armazenamento no Pesquisa de IA do Azure são recolhidos periodicamente e podem não refletir o estado em tempo real. Por isso, são esperadas discrepâncias de curto prazo na maioria dos cenários.
Para informações sobre como as métricas são recolhidas e reportadas, consulte Monitorizar Pesquisa de IA do Azure.
Porque é que o armazenamento não muda imediatamente quando apago ou atualizo documentos?
Quando elimina documentos, o Pesquisa de IA do Azure reconhece imediatamente a eliminação, mas a recuperação do armazenamento físico ocorre através de operações de fusão em segundo plano. O documento subjacente é marcado como eliminado e omitido durante consultas subsequentes. À medida que novos documentos são indexados e o índice interno cresce, o sistema limpa os documentos apagados e recupera os recursos. Isto significa que é provável que observe um atraso entre a eliminação de documentos e a libertação dos recursos subjacentes.
As atualizações de documentos têm um efeito semelhante no armazenamento. Como os documentos são imutáveis, uma atualização é internamente uma operação de apagar e inserir: a versão antiga é marcada como eliminada e uma nova versão é inserida. Até que as operações de fusão em segundo plano limpem a versão antiga, pode notar que o armazenamento aumenta temporariamente em vez de se manter igual.
Estas operações de fusão normalmente terminam entre 24 a 72 horas, dependendo da carga do serviço. Se estiver perto do limite de armazenamento do seu escalão de preço, tenha em conta este aumento temporário ao planear grandes atualizações ou substituições de documentos.
Para mais informações, consulte Eliminar documentos num índice de pesquisa e Sobrecarga de exclusão ou atualização de documentos dentro do índice.
Porque é que os valores do portal e da API diferem ao mesmo tempo?
O portal Azure e as APIs REST podem reportar valores diferentes porque têm cadências de atualização distintas. Specifically:
- O separador Utilização na página de Visão Geral do portal atualiza-se periodicamente, normalmente a cada poucos minutos.
-
As Estatísticas de Serviço GET devolvem contadores de nível de serviço, incluindo
storageSize,vectorIndexSize, edocumentCount. - O GET Index Statistics devolve contadores por indicador.
As estatísticas ao nível do serviço e ao nível do índice são recolhidas de forma independente e em intervalos diferentes. Uma captura de uma superfície pode não alinhar-se com uma captura da outra se não estiverem capturadas ao mesmo tempo. Este comportamento é normal e não indica qualquer defeito.
Para mais informações sobre monitorização de superfícies, consulte Monitorizar Pesquisa de IA do Azure.
Porque é que um índice reconstruído é maior do que um índice mais antigo com conteúdo semelhante?
Um índice reconstruído pode mostrar temporariamente um perfil de armazenamento diferente porque as operações de fusão em segundo plano ainda não terminaram de limpar as versões antigas dos documentos. Dependendo da carga de serviço, estas fusões normalmente demoram entre 24 a 72 horas. Durante este período, o armazenamento pode parecer maior do que o esperado, o que é especialmente importante a considerar se estiver perto do limite de armazenamento do seu orçamento. Planeie grandes operações de reconstrução ou migração durante períodos de menor atividade de indexação e monitorize métricas de armazenamento até que as fusões estejam concluídas.
Mesmo após a conclusão das operações de fusão, o tamanho final de um índice reconstruído pode diferir ligeiramente do original. O tamanho do armazenamento do índice é não determinístico, e vários fatores influenciam o resultado:
- Alterações de esquema, como adicionar campos, analisadores ou configurações vetoriais.
- Padrões de ingestão e atualização que afetam a proporção de documentos eliminados.
- Definições de otimização vetorial, como opções de quantização ou redução de armazenamento.
Para mais informações sobre fatores que afetam o tamanho, consulte Tamanho e limites do índice vetorial e Limites de serviço no Pesquisa de IA do Azure.
Porque é que o armazenamento total não corresponde ao tamanho do índice vetorial?
storageSize e vectorIndexSize medem coisas diferentes:
-
storageSizeé a pegada total do disco de um índice, incluindo conteúdos de todos os tipos de dados, como texto, metadados e vetores. -
vectorIndexSizeé um limite para o tamanho de um índice vetorial carregado na memória. Campos vetoriais que utilizam o algoritmo exaustivo KNN não consomem quota de índice vetorial e reportam zero paravectorIndexSize. Para mais informações, veja Tamanho e limites do índice vetorial.
No disco, o armazenamento total consumido pelos vetores pode ser maior do que o tamanho do índice vetorial em memória porque o Pesquisa de IA do Azure armazena múltiplas cópias dos campos vetoriais para diferentes finalidades. Para informações sobre o que são estas cópias e como reduzir o consumo de disco, veja Eliminar instâncias vetoriais opcionais do armazenamento.
Como devo comparar corretamente as métricas?
Para determinar se uma discrepância é real ou um artefato de tempo, capture valores da mesma superfície dentro de uma janela de tempo que seja consistente em UTC.
- Execute GET Estatísticas de Serviço e GET Estatísticas do Índice dentro da mesma janela de cinco minutos.
- Amostragem repetida numa cadência fixa, como a cada 20 a 30 minutos.
- Compare pelo menos três janelas consecutivas antes de concluir que os valores não estão a convergir.
- Avalie
storageSizeseparadamente devectorIndexSizeporque eles acompanham diferentes estruturas físicas.
Quando é que se espera uma discrepância em comparação com um defeito real?
A maioria das discrepâncias é esperada e resolve-se sem intervenção. Se os critérios de defeito forem cumpridos, abra um pedido de apoio com as provas descritas na secção seguinte.
Divergência esperada
- Recentemente realizou uma indexação pesada, atualizações ou eliminações, e os valores continuam a convergir.
- Os valores do portal e da API diferem, mas a diferença diminui ao longo de amostras repetidas.
-
storageSizeevectorIndexSizenão coincidem, o que é intencional porque medem coisas diferentes.
Possível defeito
- A discrepância persiste ao longo de pelo menos três janelas de amostragem alinhadas durante um período de baixa atividade de escrita ou eliminação.
- Não é visível nenhuma tendência de convergência apesar das amostragens repetidas.
- Os valores reportados levam a decisões operacionais incorretas, como disparo automático atrasado ou falhas na aplicação de quotas.
O que devo incluir num pedido de apoio?
Inclua as seguintes informações no seu pedido de apoio:
- Carimbos de data UTC para cada portal e amostra de API.
- Respostas JSON brutas das Estatísticas de Serviço GET e das Estatísticas do Índice GET.
- Aproximar o volume de ingestão, atualização e eliminação durante o período de observação.
- Descrição do impacto operacional, como um atraso de escalabilidade, bloco de quotas ou reporte incorreto de capacidade.