Otimizar os custos para o modelo de preços sem servidor no Pesquisa de IA do Azure 

Note

Pesquisa de IA do Azure  está disponível por meio do portal Azure, APIs REST e SDKs do Azure. Ele também sustenta o IQ do Foundry, a camada de conhecimento gerenciado que transforma o conteúdo da empresa em bases de conhecimento reutilizáveis e com reconhecimento de permissão para agentes no portal do Microsoft Foundry.

Pesquisa de IA do Azure  dá suporte a dois modelos de preços, cada um projetado para diferentes padrões de carga de trabalho:

  • Dedicado: preço fixo medido por SUs (Unidades de Pesquisa). Você seleciona uma camada de serviço e é cobrado por hora com base em unidades provisionadas.

  • Sem servidor (versão prévia): preços baseados em consumo medidos por UNIDADES de Computação por hora (/hr) e por GB/mês para armazenamento indexado.

Importante

A camada desenvolvedor sem servidor está atualmente em versão prévia. Essa versão prévia é fornecida sem um contrato de nível de serviço e não é recomendada para cargas de trabalho de produção. Alguns recursos podem não ter suporte ou podem ter restrição de recursos. Para obter mais informações, consulte Termos de Uso Complementares para Versões Prévias do Microsoft Azure.

A cobrança da camada Serverless Developer ainda não está habilitada na prévia. Os custos estimados para seu uso estão disponíveis no portal Azure e na telemetria, mas esse uso não aparecerá em sua fatura de Azure durante esse período inicial. Microsoft fornecerá pelo menos 30 dias de aviso prévio antes do início da cobrança. O adiamento da cobrança durante essa versão prévia é temporário. O Desenvolvedor sem servidor é uma camada paga e você será responsável por todos os encargos acumulados após o início da cobrança.

A camada de Desenvolvedor sem Servidor não dá suporte à migração para ou de outros tipos de preço e alguns recursos disponíveis em outras camadas não têm suporte durante a Visualização Pública. Limites de serviço, recursos com suporte e detalhes de preços podem ser alterados antes da disponibilidade geral.

Atualmente, a versão prévia está disponível apenas no Centro-Oeste dos EUA, Norte da Suíça e Leste do Japão.

Para obter mais informações sobre as diferenças do modelo de preços e da camada de serviço, consulte Escolher um modelo de preços e uma camada de serviço.

Como o custo é determinado no modelo sem servidor

No modelo sem servidor, a otimização de desempenho afeta diretamente o custo. O custo está diretamente vinculado à execução da carga de trabalho:

  • Consultas e indexação consomem computação, medida em UNIDADES de Computação por hora (/h).
  • O armazenamento é cobrado separadamente com base no tamanho do índice no disco.
  • Quando o serviço está ocioso sem consultas ativas ou indexação, o uso de computação é zero. Não há cobrança por capacidade reservada ou mínima.

O modelo de preços sem servidor é mais econômico para cargas de trabalho com tráfego variável, intermitente ou imprevisível, em que a capacidade provisionada seria subutilizada.

Importante

As suas cobranças de Unidade de Computação por hora (CU/h) não incluem ranqueador semântico, recuperação por meio de agentes, extração de imagens e execução de habilidades. Esses recursos são cobrados separadamente.

Entender as CUs (Unidades de Computação)

Uma Unidade de Computação (CU) representa a medida dos recursos do sistema necessários para executar operações de pesquisa e indexação no modelo sem servidor. O custo da CU é determinado principalmente pela utilização de CPU, memória e E/S e, em segundo lugar, pelo tamanho do índice e pelo tamanho da carga útil do documento, sendo o uso cobrado em Unidade de Computação por hora (CU/h).

Dimensionamento de custos de computação com:

  • Complexidade da consulta
  • Tamanho do índice (GB) e estrutura
  • Tamanho da carga do documento (KB)
  • Número de campos e resultados recuperados

Diferentes operações têm perfis de custo diferentes:

  • Consulta: Baixo custo. Recuperar um único documento por sua ID é a operação mais eficiente.
  • Pesquisa de palavra-chave: baixo custo. A pesquisa de texto usa índices invertidos, que são otimizados para velocidade e baixo uso de computação.
  • Pesquisa de vetor: alto custo. As consultas vetoriais são computacionalmente caras porque exigem cálculos de similaridade entre inserções de alta dimensão. Em comparação com a pesquisa de palavras-chave, elas consomem significativamente mais computação.
  • Pesquisa híbrida: combina os custos da pesquisa por palavra-chave e da pesquisa vetorial, pois ambos os pipelines são executados para cada consulta, além de uma pequena sobrecarga adicional para a Reciprocal Rank Fusion (RRF), usada para mesclar os resultados.

Monitorar o uso de computação

O monitoramento do consumo de computação ajuda você a identificar operações caras, otimizar padrões de consulta e estimar custos. O custo da Unidade de Computação (CU) de cada solicitação é retornado no cabeçalho de resposta HTTP x-ms-request-charge na forma de um número de ponto flutuante. Use esse cabeçalho para identificar operações caras e otimizar padrões de consulta. Você pode acompanhar o custo em CU de cada solicitação ao inspecionar os cabeçalhos de resposta HTTP e os eventos de operação no Azure Monitor. Para obter mais diretrizes sobre os tipos de dados de monitoramento disponíveis e métodos para analisar esses dados, consulte Monitor Pesquisa de IA do Azure .

  • Cabeçalho: x-ms-request-charge: <value>
  • Valor: um número de ponto flutuante que representa as CUs consumidas.

Exemplo:

Status: 200 OK
Content-Type: application/json
x-ms-request-charge: 12.45

Neste exemplo, a solicitação consumiu 12,45 unidades de computação. Você pode usar esse valor para identificar operações de alto custo e comparar o custo relativo de diferentes padrões de consulta.

Para examinar o consumo de computação histórico para um serviço de pesquisa sem servidor, use as métricas de Azure Monitor no portal Azure:

  1. Navegue até seu serviço de pesquisa.
  2. Selecione Métricas.
  3. Selecione + Adicionar métrica.
  4. Na lista de métricas, selecione Uso de unidades de computação.
  5. Use o gráfico para analisar tendências de uso e identificar períodos de aumento do consumo de computação.

O monitoramento do uso agregado ajuda você a entender os custos gerais do serviço e a identificar cargas de trabalho que consomem mais recursos de computação. Para obter descrições das métricas de monitoramento disponíveis, consulte Referência de Dados de Monitoramento. Você pode usar Azure Monitor logs para acompanhar o uso agregado de CU ao longo do tempo e correlacioná-lo com mudanças no volume de consultas e na carga de trabalho.

Captura de tela do painel de monitoramento de métricas para Unidades de Computação sem servidor no portal do Azure.

Configurar alertas para uso de computação

Você pode criar uma regra de alerta para ser notificado quando o consumo de computação atingir um limite especificado no portal Azure.

  1. Vá para Alertas em seu serviço de pesquisa.
  2. Selecione + Criar regra de alerta.
  3. Em Condição, escolha o uso de unidades de computação como o sinal.
  4. Defina a lógica de alerta. Por exemplo, dispare quando o uso total for maior que um valor especificado.
  5. Configure Ações, como notificações por email, SMS ou webhook.
  6. Conclua as etapas restantes e selecione Examinar + criar.

Os alertas ajudam você a responder proativamente a picos de uso inesperados e gerenciar custos.

Captura de tela da criação de uma regra de alerta no portal do Azure.

Estimar os custos sem servidor

A calculadora de preços Azure e as diretrizes de planejamento de capacidade baseadas em SU (unidade de pesquisa) não se aplicam aos serviços que usam o modelo de preços sem servidor.

Para estimar os custos sem servidor:

  1. Indexe dados de amostra representativos.
  2. Execute cargas de trabalho típicas de indexação e consulta.
  3. Registre o x-ms-request-charge valor retornado para cada operação.
  4. Use as métricas do Azure Monitor para medir o uso agregado ao longo do tempo.
  5. Extrapolar custos com base no tráfego de produção esperado.

Como a mesma solicitação executada em relação aos mesmos dados geralmente produz consumo de computação semelhante, cargas de trabalho representativas podem fornecer uma base confiável para estimativa de custo.

O uso sem servidor é medido continuamente e agregado para cobrança. O consumo de computação é acompanhado ao longo de cada minuto e emitido somente quando recursos de computação são usados.

Ao estimar os custos, use os valores de cobrança da solicitação para entender o custo de operações individuais e as métricas do Azure Monitor para entender os padrões gerais de consumo do serviço.

A cobrança é baseada no uso de computação agregado em vez de solicitações individuais. O uso é medido em intervalos de um minuto e arredondado para cima para o múltiplo de 0,25 CU por minuto mais próximo. Esses intervalos de uso de um minuto se acumulam ao longo de uma hora para determinar a quantidade faturável de CU/hora. Internamente, o uso é agregado de unidades de computação em milésimos (mCU) para unidades de computação (CU) e convertido no uso por hora informado para cobrança.

Operações diferentes consomem diferentes quantidades de computação. Em geral:

  • As pesquisas de palavra-chave normalmente usam os recursos de computação mínimos.
  • Pesquisas de vetor normalmente usam mais recursos de computação do que pesquisas de palavra-chave.
  • Pesquisas híbridas combinam a palavra-chave e a execução da pesquisa de vetor, de modo que normalmente usam mais recursos de computação do que qualquer técnica sozinha.

O consumo real de computação depende de fatores como complexidade da consulta, tamanho do índice, volume de dados, configuração de vetor e o número de resultados retornados. Monitorar encargos de solicitação e métricas de uso agregado podem ajudá-lo a identificar oportunidades de otimização e prever melhor os custos de produção.

Reduzir os custos de computação por meio da otimização

Consultas eficientes e um bom projeto de índices reduzem o consumo de recursos computacionais e os custos.

Otimizar seu esquema

O esquema de índice determina os custos de computação e armazenamento da linha de base:

  • Limitar atributos de campo: habilitar somente atributos (pesquisáveis, filtrados, facetáveis, classificáveis) quando necessário. Cada atributo aumenta o tamanho do índice e o custo de indexação.
  • Nivelar tipos complexos: mapeie estruturas JSON aninhadas para campos simples ou coleções, sempre que possível.
  • Defina retrievable=false para campos somente filtro ou somente classificação: se um campo for usado para filtragem ou classificação, mas não precisar ser retornado nos resultados, mantenha-o indexado e definido retrievable=false para reduzir o armazenamento em disco e o custo de armazenamento por GB/mês.
  • Use campos somente recuperáveis quando possível: por exemplo, os campos usados apenas para exibição (como URLs de imagem) não devem ser pesquisáveis.
  • Reduzir dimensões de vetor: vetores de dimensões mais altas aumentam o custo de armazenamento e consulta. Use modelos de inserção menores ou quantização quando apropriado.
  • Minimizar o tamanho da carga do documento antes da indexação: documentos maiores custam mais para indexar. Remova campos desnecessários, corte texto longo e remova HTML antes de enviar documentos para o índice.

Otimizar solicitações de indexação

Como você envia dados para o índice afeta o custo e a taxa de transferência:

  • Use lotes maiores quando possível: a indexação em lote reduz a sobrecarga por requisição, distribuindo os custos de rede e processamento entre mais documentos. Em geral, lotes de até ~1.000 documentos ou ~16 MB são mais eficientes em termos de CU do que várias solicitações pequenas. No entanto, o tamanho ideal do lote depende da carga de trabalho. Teste para balancear a taxa de transferência, a latência e a confiabilidade.

  • Indexar apenas dados novos ou alterados: evite reindexação total quando possível. Enviar apenas adições e atualizações reduz o número de documentos processados, reduzindo o custo de computação e melhorando a velocidade de ingestão.

  • Use a detecção de alterações para indexação incremental: detecte o que mudou antes de reprocessar o conteúdo. A indexação incremental evita o trabalho repetido em documentos inalterados e mantém os custos de reprocessamento baixos.

  • Ignore a extração de imagem, a menos que você precise: a extração de imagem adiciona um trabalho de processamento extra e pode se tornar um driver de custo separado. Ative-o apenas para documentos ou fluxos de trabalho que realmente precisam de conteúdo de imagem.

  • Direcione habilidades para campos e documentos relevantes: aplique habilidades de enriquecimento de escopo aos campos ou documentos específicos necessários. Evite aplicar habilidades a conteúdos que não precisam de enriquecimento, especialmente quando os resultados não são usados nas etapas posteriores do fluxo.

  • Leve em consideração o crescimento do tamanho do índice: sempre que possível, crie índices menores. À medida que um índice aumenta, os custos de indexação aumentam porque mais dados devem ser armazenados e mantidos, e as operações exigem mais computação. Para conjuntos de dados muito grandes, considere particionar dados em vários índices para ajudar a gerenciar o desempenho e os custos. Embora os custos aumentem com o tamanho do índice, o aumento é sublinear. Índices maiores custam mais por operação, mas não proporcionalmente mais.

Para obter mais diretrizes, consulte Tips para obter melhor desempenho em Pesquisa de IA do Azure .

Otimizar suas consultas

O design da consulta é um driver primário de custo variável:

  • Use $select para limitar os campos retornados: isso reduz o tamanho da carga e a computação necessárias para serialização.

    GET /docs?search=test&$select=id,title,url
    
  • Use searchFields para limitar onde o texto é pesquisado: restrinja a correspondência de tempo de consulta aos campos que importam para o cenário. Cada campo pesquisável adicional aumenta o processamento da consulta e pode aumentar o CU/h.

  • Prefira correspondência exata ou consultas simples por palavra-chave: consultas aproximadas, com curingas, regex e por prefixo podem forçar varreduras amplas no índice e consumir significativamente mais CU/h. Use-as somente quando precisar de um comportamento de correspondência parcial e escolher consultas de correspondência exata ou de palavra-chave mais simples sempre que possível.

  • Use consultas por ID em vez de buscas, quando possível: consultar um documento por ID é mais eficiente do que executar uma consulta de busca. Se você souber o ID do documento, use uma consulta direta em vez de uma consulta de busca. As pesquisas são mais eficientes porque recuperam um documento diretamente por chave, enquanto as consultas de pesquisa invocam o pipeline de consulta completo (análise, passagem de índice, pontuação e classificação), o que aumenta o custo de computação.

  • Evite paginação profunda ($skip): valores grandes $skip aumentam a computação porque o mecanismo deve processar e classificar todos os resultados anteriores (por exemplo, $skip=5000 requer pontuação de pelo menos 5.000 documentos que não são retornados). Isso desperdiça capacidade computacional (CUs) e aumenta os custos. Em vez disso, use filtros para restringir os resultados e limitar o número retornado com $top. Dimensione corretamente $top para corresponder à exibição da interface do usuário. Por exemplo, $top=10 os custos são menores do que $top=50 porque menos resultados são pontuados e retornados. Solicite apenas quantos resultados o aplicativo precisar e evite padrões que exijam que o mecanismo processe um grande número de resultados não utilizados.

  • Minimizar a contagem de facetas e o escopo da faceta: solicite apenas as facetas exibidas na interface do usuário e mantenha cada valor de faceta count tão baixo quanto prático. Facetas exigem agregações para cada consulta, e contagens elevadas aumentam o custo computacional.

  • Use search.in para filtragem: ao filtrar por uma lista de IDs ou valores, use a search.in função em vez de várias or condições (por exemplo, id eq '1' or id eq '2'). Essa abordagem é mais eficiente e reduz a sobrecarga de computação. Você também deve evitar marcar campos de alta cardinalidade (aqueles com um grande número de valores exclusivos, como IDs exclusivos ou descrições em texto livre) como filtráveis ou facetáveis, a menos que isso seja necessário, pois isso aumenta o tamanho do índice e o custo da consulta.

Otimizar suas solicitações administrativas

Além das operações de consulta e indexação, Pesquisa de IA do Azure  inclui operações administrativas no nível do objeto e no nível do serviço (como recuperar esquemas de índice ou estatísticas de serviço). Essas solicitações têm um custo fixo por solicitação. Embora cada solicitação seja barata, chamadas repetidas ou desnecessárias podem se acumular ao longo do tempo e aumentar o uso geral da computação.

  • Evite solicitações administrativas excessivas: armazene em cache metadados, como esquemas de índice, no cliente, em vez de recuperá-los repetidamente. Por exemplo, buscar o esquema do índice antes de cada operação de gravação introduz um custo desnecessário. No modelo sem servidor, esse padrão aumenta diretamente os encargos de computação, enquanto nos serviços dedicados, o impacto geralmente é oculto por cobrança fixa por hora.

Otimizar custos com vetores

As cargas de trabalho de vetor normalmente são o componente de maior custo na pesquisa do modelo de preços sem servidor porque afetam as Unidades de Computação (consultas e indexação) e o armazenamento (tamanho do vetor no disco). Para reduzir o custo, otimize a forma como os vetores são armazenados e como eles são consultados.

Otimizar o armazenamento e o esquema de vetor

Os campos de vetor podem aumentar significativamente o tamanho do índice e o custo de indexação. Use as seguintes técnicas para reduzir a sobrecarga de armazenamento:

  • Use a compactação para reduzir o tamanho do vetor: aplique a quantização para reduzir o volume de armazenamento com impacto mínimo de relevância. Por exemplo, a quantização escalar pode reduzir o armazenamento de vetores em até 4× com impacto mínimo na qualidade da pesquisa.

  • Desabilite o armazenamento para vetores quando não for necessário: defina stored=false em campos de vetor se você precisar apenas de vetores para pesquisa, não recuperação. Isso evita armazenar os vetores originais no índice, reduzindo o custo de armazenamento sem afetar o comportamento da consulta.

  • Use dimensões de inserção menores quando possível: vetores de dimensões mais altas aumentam o custo de armazenamento e de consulta. Para cargas de trabalho não críticas, use modelos de inserção menores (por exemplo, dimensões 384 ou 768 em vez de 1536) para reduzir o custo.

Otimizar a execução da consulta vetor

As consultas vetoriais são intensivas em computação porque exigem cálculos de similaridade em estruturas de dados de alta dimensão.

  • Use a busca híbrida seletivamente: as consultas híbridas executam tanto a recuperação por palavra-chave quanto a recuperação vetorial. Use somente quando necessário para relevância.

  • Aplicar filtros antes das consultas de vetor: restrinja o conjunto de candidatos antes da pesquisa de vetor para reduzir a quantidade de dados processados. Veja como a filtragem funciona em consultas de vetor.

Reduzir custos minimizando o uso

O modelo sem servidor cobra apenas pelos recursos consumidos. Quando não há solicitações, o uso de computação diminui de acordo.

Para minimizar os custos de uso:

  • Execute consultas somente quando necessário.
  • Evite solicitações redundantes ou excessivamente frequentes.
  • Monitore o uso e ajuste cargas de trabalho com base na demanda.

Dica

A mesma consulta pode ter diferentes perfis de latência e de CU, dependendo de o serviço estar em estado quente ou frio. Após um período sem tráfego de leitura ou gravação, o uso de computação no modelo de preços sem servidor cai para zero. A próxima solicitação pode ter maior latência e consumir mais CUs enquanto os caminhos de dados se aquecem. Índices maiores geralmente levam mais tempo para aquecer do que índices menores, de modo que efeitos de início frio geralmente são mais perceptíveis em serviços maiores.

Otimizar os custos de armazenamento

O armazenamento é cobrado por GB/mês com base no tamanho do índice em disco, que pode exceder o tamanho bruto dos dados. Para reduzir os custos de armazenamento:

  • Remova índices não utilizados.
  • Minimize os campos armazenados.
  • Projete esquemas com a sobrecarga de armazenamento em mente.
  • Use sugestores seletivamente porque eles podem aumentar drasticamente o tamanho do armazenamento.

Para técnicas específicas de vetor (compactação, poda e configurações de armazenamento), consulte Otimizar para armazenamento e processamento de vetores.

Para obter mais diretrizes sobre compensações de desempenho de armazenamento e consulta, consulte Tips para obter melhor desempenho em Pesquisa de IA do Azure .