Limites de serviço no Pesquisa de IA do Azure 

Os limites máximos de armazenamento, cargas de trabalho e quantidades de índices e outros objetos dependem do modelo de preços do serviço Pesquisa de IA do Azure .

Pesquisa de IA do Azure  dá suporte a dois modelos de preços, cada um com camadas de serviço associadas. A camada selecionada afeta os limites de serviço descritos nesta orientação.

• Dedicado: preço fixo medido por SUs (Unidades de Pesquisa). As opções da camada de serviço incluem: Básico, Standard (S1-S3, incluindo S3 HD), Otimizado para Armazenamento (L1-L2) e uma camada Gratuita com recursos limitados do serviço de pesquisa.
• Serverless (prévia): preços com base no consumo, medidos em Unidades de Computação por hora (CU/hr) e por GB/mês para armazenamento indexado. A camada de visualização atual é: Desenvolvedor sem servidor. Os limites são definidos pelos limites máximos por índice, pelas contagens de objetos por serviço e pelo comportamento de limitação sem servidor.

Para saber mais, confira Escolher um modelo de preços e uma camada de serviço.

Diagnosticar falhas de cota, capacidade ou limite

As falhas de quota e capacidade decorrem de controles separados. Use o erro da operação concluída para localizar qual deles se aplica.

Se uma operação de criação, escala ou atualização ainda estiver em execução, aguarde até que o estado de provisionamento se torne Succeeded ou Failed. Uma operação em andamento não é evidência de um problema de cota ou capacidade. Se uma operação de escala falhar, consulte Erros durante o dimensionamento.

A cota de assinatura disponível não garante a capacidade regional e solicitar mais cota não resolve uma restrição de capacidade. Se a falha persistir, abra uma solicitação Suporte do Azure que inclua a assinatura, a região, a camada, a configuração solicitada, o texto de erro completo, a hora UTC e qualquer ID de correlação ou operação.

Limites de assinatura

Você pode criar vários serviços de pesquisa faturáveis (Básico e superior), até o número máximo de serviços permitidos em cada nível, por região. Por exemplo, você pode criar até 16 serviços na camada Básica e outros 16 serviços na camada S1 na mesma assinatura e região. Em seguida, você pode criar mais 16 serviços Básicos em outra região para um total combinado de 32 serviços Básicos na mesma assinatura. Para obter mais informações sobre as camadas de serviço, consulte Escolher um modelo de preços e uma camada de serviço.

Você pode aumentar os limites máximos de serviço por solicitação. Se você precisar de mais serviços na mesma assinatura, apresente uma solicitação de suporte.

¹ Você pode ter um serviço de pesquisa gratuito por assinatura do Azure. A camada gratuita baseia-se na infraestrutura compartilhada com outros clientes. Como o hardware não é dedicado, não há suporte para escalar verticalmente e o armazenamento é limitado a 50 MB. Um serviço de pesquisa gratuito pode ser excluído após longos períodos de inatividade para abrir espaço para mais serviços.

² As SU (unidades de pesquisa) são unidades faturáveis, alocadas como uma réplica ou como uma partição. Você precisa das duas. Para saber mais sobre combinações de SU, consulte Estimar e gerenciar a capacidade de um serviço de pesquisa.

Limites de serviço

No modelo de preço dedicado, planeje a capacidade multiplicando réplicas por partições (unidades de pesquisa).

¹ A camada Básica dá suporte a três partições e três réplicas, para um total de nove SU (unidades de pesquisa) em novos serviços de pesquisa criados após 3 de abril de 2024. Os serviços Basic mais antigos se limitam a uma partição e três réplicas.

Um serviço de pesquisa está sujeito a um limite máximo de armazenamento (tamanho de partição multiplicado pelo número de partições) ou um limite rígido no número máximo de índices ou indexadores, o que for o limite primeiro.

Os SLAs (contratos de nível de serviço) se aplicam a serviços faturáveis que têm duas ou mais réplicas para cargas de trabalho de consulta ou três ou mais réplicas para cargas de trabalho de consulta e indexação. O número de partições não é uma consideração de SLA. Para obter mais informações, consulte Confiabilidade no Pesquisa de IA do Azure.

Os serviços gratuitos não têm partições ou réplicas fixas e compartilham recursos com outros assinantes.

Capacidade de armazenamento da partição (GB)

Os limites de armazenamento por serviço variam de acordo com dois fatores: data e região de criação do serviço. A maioria das regiões com suporte oferece limites mais altos para serviços mais recentes.

Esta tabela mostra a progressão de aumentos da cota de armazenamento em GB ao longo do tempo. A partir de abril de 2024, partições de maior capacidade entraram online nas regiões listadas nas notas de rodapé. Se você tiver um serviço mais antigo em uma região com suporte, verifique se pode atualizar seu serviço para obter limites de armazenamento mais altos.

¹ Armazenamento de capacidade superior para Basic, S1, S2 e S3 nessas regiões. Américas: Sul do Brasil, Canadá Central, Leste do Canadá, Leste dos EUA, Leste dos EUA 2, Centro dos EUA, Centro-Norte dos EUA, Centro-Sul dos EUA, Oeste dos EUA, Oeste dos EUA 2, Oeste dos EUA 3, Centro-Oeste dos EUA. Europa: França Central. Norte da Itália, Norte da Europa, Leste da Noruega, Centro da Polônia, Norte da Suíça, Suécia Central, Sul do Reino Unido, Oeste do Reino Unido. Oriente Médio: Norte dos EAU. África: Norte da África do Sul. Pacífico Asiático: Leste da Austrália, Sudeste da Austrália, Índia Central, Oeste da Índia Jio, Leste da Ásia, Sudeste Asiático, Leste do Japão, Oeste do Japão, Coreia Central, Sul da Coreia.

² Armazenamento de capacidade maior para L1 e L2. Mais regiões fornecem capacidade maior em cada camada faturável. Américas: Leste dos EUA 2 EUAP. Europa: Norte da Alemanha, Centro-Oeste da Alemanha, Oeste da Suíça. Azure Governamental: Texas, Arizona, Virgínia. África: Norte da África do Sul. Pacífico Asiático: Norte da China 3, Leste da Ásia 3.

³ O armazenamento de maior capacidade está disponível na Europa Ocidental.

Limites de índice

¹ Serviços básicos criados antes de dezembro de 2017 têm menos limites (5 em vez de 15) em índices.

² o limite superior dos campos inclui campos de primeiro nível e subcampos aninhados em uma coleção complexa. Por exemplo, se um índice contiver 15 campos e duas coleções complexas com 25 subcampos cada, a contagem de campos dele será 25. Índices com uma coleção de campos muito grande podem ser lentos, especialmente em serviços básicos mais antigos. Limite campos e atributos a apenas aqueles de que você precisa e execute testes de indexação e consulta para garantir que o desempenho seja aceitável.

³ Serviços básicos criados antes de 3 de abril de 2024 dão suporte a um máximo de 100 campos por índice. Os serviços básicos mais recentes dão suporte a 1.000 campos por índice.

⁴ Existe um limite superior para os elementos porque ter um grande número deles aumenta significativamente o armazenamento necessário para o índice. Um elemento de uma coleção complexa é definido como um membro dessa coleção. Por exemplo, suponha um documento de Hotel com uma coleção complexa de Rooms. Cada sala na coleção Rooms é considerada um elemento. Durante a indexação, o mecanismo de indexação pode processar com segurança um máximo de 3.000 elementos no documento como um todo. Esse limite foi introduzido em api-version=2019-05-06 e se aplica apenas a coleções complexas e não a coleções de cadeias de caracteres ou a campos complexos.

⁵ Para a maioria das camadas, o tamanho máximo do índice é o armazenamento total disponível em seu serviço de pesquisa. Para serviços S2, S3 e S3 HD com várias partições e, portanto, mais armazenamento, o tamanho máximo de um único índice é fornecido na tabela. Aplica-se aos serviços de pesquisa criados após 3 de abril de 2024. Os índices de serviços configurados com o modelo sem servidor (versão prévia) têm um tamanho máximo definido fornecido na tabela.

É possível encontrar alguma variação em limites máximos se o serviço for provisionado em um cluster mais potente. Os limites aqui representam o denominador comum. Os índices criados nas especificações acima são portáteis em todas as camadas de serviço equivalentes em qualquer região.

Limites do documento

Cada índice dá suporte ao seguinte número de documentos:

• 24 bilhões no Basic, S1, S2 e S3
• 2 bilhões no S3 HD
• 288 bilhões em L1
• 576 bilhões em L2

Cada documento pode ter até aproximadamente 16 MB de tamanho. O limite de tamanho do documento realmente se aplica ao tamanho do conteúdo da solicitação de API de indexação, que é de 16 MB. Esse conteúdo pode ser um único documento ou um lote de documentos. Para um lote com um único documento, o tamanho máximo de documentos é de 16 MB de JSON.

O limite de tamanho do documento se aplica à indexação do modo push que carrega documentos em um serviço de pesquisa. Se você estiver usando um indexador para indexação de modo pull, seus arquivos de origem poderão ter qualquer tamanho de arquivo, sujeito aos limites do indexador. Para o indexador de blob, os limites de tamanho do arquivo são maiores para camadas mais altas. Por exemplo, o limite S1 é de 128 MB e o limite S2 é de 256 MB.

Ao estimar o tamanho do documento, lembre-se de indexar apenas os campos que adicionam valor aos cenários de pesquisa. Exclua os campos de origem que não têm nenhuma finalidade nas consultas que você pretende executar.

Limites de tamanho do índice de vetor

Ao indexar documentos com campos de vetor, a Pesquisa de IA do Azure constrói os índices de vetor internos usando os parâmetros de algoritmo que você fornece.

O tamanho desses índices de vetor é restrito por:

• A memória reservada para pesquisa de vetor para a camada do serviço (ou SKU) no modelo de preço dedicado.
• Limites de armazenamento por índice no modelo de preços sem servidor.

Para obter diretrizes sobre como gerenciar e maximizar o armazenamento de vetores, confira Tamanho do índice vetor e como manter-se abaixo dos limites.

Os limites de vetor variam de acordo com:

• Data de criação do serviço
• Região
• Modelo de preços e camada de serviço selecionada

Há limites de vetor mais altos a partir de abril de 2024 em novos serviços de pesquisa em regiões que fornecem a capacidade extra, que é a maioria delas. Se você tiver um serviço mais antigo em uma região com suporte, verifique se pode atualizar seu serviço para os limites de vetor mais altos.

No modelo de preços sem servidor, os limites de vetor são definidos por índice em vez de por partição.

• Tamanho máximo do índice vetor por índice (sem servidor): 300 MB
  • Esse tamanho representa aproximadamente 30% do armazenamento total do índice, consistente com a taxa de vetor para armazenamento usada em camadas de serviço dedicadas.
  • Esse tamanho é um limite rígido por índice. As tentativas de exceder esse limite durante a indexação falham.

Esta tabela mostra a progressão de aumentos da cota de vetor em GB ao longo do tempo. A cota é por partição, portanto, se você dimensionar um novo serviço Standard (S1) para 6 partições, a cota total de vetores será 35 multiplicada por 6.

¹ Limites iniciais de vetor durante a versão prévia antecipada.

² Limites de vetor durante o período de versão prévia posterior. Três regiões não tinham os limites mais altos: Centro-Oeste da Alemanha, Oeste da Índia e Catar Central.

³ Cota de vetor maior com base nas partições maiores para camadas e regiões com suporte.

⁴ Cota de vetor maior para mais camadas e regiões com base nas atualizações de tamanho de partição.

O serviço impõe uma cota de tamanho de índice vetor:

• Dedicado: Por partição no seu serviço Pesquisa
• Sem servidor: Por índice

Essa cota é um limite rígido para garantir que seu serviço permaneça íntegro. Novas tentativas de indexação depois que o limite é excedido resultam em falha. Você pode retomar a indexação depois de liberar a cota disponível:

• Excluindo documentos vetoriais
• Reduzindo o tamanho do vetor ou a dimensionalidade
• (Somente dedicado) Dimensionamento de partições

Limites de indexador

Os tempos máximos de execução existem para fornecer balanceamento e estabilidade ao serviço como um todo, mas conjuntos de dados maiores podem precisar de mais tempo de indexação do que o máximo permitido. Se não for possível concluir um trabalho de indexação no tempo máximo permitido, tente executá-lo de maneira agendada. O agendador monitora o status da indexação. Se um trabalho de indexação agendado for interrompido por algum motivo, o indexador poderá continuar de onde parou na próxima execução agendada.

Limites de objeto do indexador e de taxa de transferência

¹ Os serviços gratuitos têm um tempo máximo de execução do indexador de 3 minutos para fontes do blob e 1 minuto para todas as outras fontes de dados. A invocação do indexador é uma vez a cada 180 segundos. Para a indexação de IA que utiliza as ferramentas Foundry, os serviços gratuitos são limitados a 20 transações gratuitas por indexador por dia, onde uma transação é definida como um documento que passa com sucesso pelo pipeline de enriquecimento. (Dica: você pode reiniciar um indexador para reiniciar seu contador.)

² Serviços básicos criados antes de dezembro de 2017 têm menos limites (5 em vez de 15) em indexadores, fontes de dados e conjuntos de habilidades.

³ O suporte para o indexador HD do S3 está em versão preliminar e requer a versão 2025-11-01-preview da API REST ou posterior. Os indexadores S3 HD são executados apenas no ambiente de execução multilocatário e não dão suporte a recursos de link privado compartilhados. Na versão prévia, o suporte para o indexador S3 HD é mais adequado para cargas de trabalho de pequeno porte (com tamanho de índice de aproximadamente 1 GB), sem conjuntos de habilidades ou com conjuntos mínimos. Para obter diretrizes sobre comportamento geral, monitoramento e planejamento, consulte Execução do indexador no Serverless e no S3 HD.

⁴ Máximo de 30 habilidades por conjunto de habilidades.

⁵ Em relação à duração máxima permitida de 2 ou 24 horas para indexadores: um máximo de 2 horas é o mais comum e é isso que você deve considerar ao planejar. Ele se refere aos indexadores executados no ambiente público, que descarrega o processamento computacionalmente intensivo e deixa mais recursos para consultas. O limite de 24 horas se aplicará se você configurar o indexador para ser executado em um ambiente privado usando apenas a infraestrutura alocada ao serviço de pesquisa. Alguns indexadores mais antigos são incapazes de executar no ambiente público e esses indexadores sempre têm um intervalo de processamento de 24 horas. Se você tiver indexadores não programados que são executados continuamente por 24 horas, é porque esses indexadores não puderam ser migrados para a infraestrutura mais recente. Como regra geral, para indexar trabalhos que não podem ser concluídos dentro de duas horas, coloque o indexador em um agendamento de 5 minutos para que o indexador possa retomar rapidamente de onde parou. Na Camada gratuita, o tempo máximo de execução de 3 a 10 minutos é para indexadores com conjuntos de habilidades.

⁶ Nos serviços S3 HD e Serverless, todos os indexadores compartilham 24 horas de tempo de execução cumulativo por serviço em cada janela de 24 horas em UTC. Para obter orientações sobre comportamento de cotas, monitoramento e planejamento, consulte execução do indexador no Serverless e no S3 HD (versão prévia).

Limites para arquivos de origem em indexadores do tipo blob

O processamento de arquivos ocorre em estágios e cada estágio tem seus próprios limites:

1. Um conector de fonte de dados baixa um item de origem, sujeito aos limites específicos do conector da fonte.
2. Pesquisa de IA do Azure  extrai o conteúdo do item, sujeito ao tamanho máximo do arquivo de origem e aos limites de caractere extraído na tabela a seguir.
3. Opcionalmente, um conjunto de habilidades envia esse conteúdo para serviços downstream, em que o limite de entrada de uma habilidade individual pode ser menor do que o que o indexador extrai.

O tamanho máximo do arquivo de origem e os limites de caracteres extraídos na tabela a seguir se aplicam aos indexadores do Armazenamento de Blobs do Azure, do ADLS Gen2, do SharePoint no Microsoft 365, do OneLake e do Arquivos do Azure. Para obter limites por habilidade, verifique o artigo de referência para cada habilidade em seu conjunto de habilidades.

¹ O número máximo de caracteres é baseado em unidades de código Unicode, especificamente UTF-16.

² Ao usar delimitedText o modo de análise para arquivos CSV, um limite de tamanho de buffer de 10 MB por linha de arquivo se aplica.

³ Ao usar delimitedText o modo de análise para arquivos CSV, o limite de "tamanho máximo de conteúdo extraído" não se aplica.

⁴ Os indexadores do tipo blob incluem o indexador do Armazenamento de Blobs do Azure (indexador de blob), o indexador do ADLS Gen2, o indexador do SharePoint no Microsoft 365, o indexador do OneLake e o indexador do Arquivos do Azure. A fonte de conhecimento do arquivo de upload direto não usa um indexador e tem limites separados.

Limites do recurso do link privado compartilhado

Os indexadores podem acessar outros recursos do Azure por meio de pontos de extremidade privados gerenciados pela API de recurso de link privado compartilhado. Esta seção descreve os limites associados a esse recurso.

¹ O enriquecimento da IA e a análise de imagem fazem uso intensivo dos recursos de computação e consomem uma quantidade desproporcional da capacidade de processamento disponível. Por esse motivo, as conexões privadas são desabilitadas em camadas inferiores para garantir o desempenho e a estabilidade do serviço de pesquisa propriamente dito. Nos serviços básicos, as conexões privadas com um recurso do Microsoft Foundry não têm suporte para preservar a estabilidade do serviço. Para a camada S1, verifique se o serviço foi criado com limites mais altos após 3 de abril de 2024. Os indexadores com mais de 2 habilidades de inserção multimodal do Azure OpenAI Embedding ou do Azure Vision são impedidos de serem executados em ambiente privado e as conexões privadas não estão disponíveis.

Há suporte para ² conexões privadas para um modelo de incorporação em serviços de pesquisa de alta capacidade Básico e S1 criados após 3 de abril de 2024, com limites mais altos para armazenamento e processamento computacional.

³ O número de tipos de recursos distintos é calculado como o número de valores groupId exclusivos usados em todos os recursos de link privado compartilhado para um determinado serviço de pesquisa, independentemente do status do recurso.

Limites de sinônimos

O número máximo de mapas de sinônimos varia de acordo com a camada. Cada regra pode ter até 20 expansões, onde uma expansão é um termo equivalente. Por exemplo, dada a palavra "gato", a associação com "gatinho", "felino" e "felis" (o gênero dos gatos) conta como três expansões.

Limites de aliases de índice

O número máximo de aliases de índices varia conforme a camada e a data de criação do serviço. Em todas as camadas, se o serviço tiver sido criado após outubro de 2022, o número máximo de aliases será o dobro do número máximo de índices permitidos. Se o serviço tiver sido criado antes de outubro de 2022, o limite será o número de índices permitidos.

¹ Serviços básicos criados antes de dezembro de 2017 têm menos limites (5 em vez de 15) em índices.

Limites de recuperação agênica

Uma base de conhecimento especifica uma ou mais fontes de conhecimento e um esforço de raciocínio de recuperação (versão prévia) que controla o nível de processamento pelo modelo de linguagem de grande porte (LLM) para recuperação agêntica. Os limites variam de acordo com o tipo de preço, a versão da API e o nível de esforço de raciocínio.

¹ Os serviços básicos criados antes de 3 de abril de 2024 têm limites inferiores (5) em fontes de conhecimento e bases de dados de conhecimento.

² Esses limites se aplicam aos serviços S3 HD que dão suporte a bases de dados de conhecimento e fontes de conhecimento. Alguns serviços S3 HD mais antigos não dão suporte a esses recursos.

Seleção da fonte de conhecimento durante a recuperação

Uma base de conhecimento pode conter até o limite máximo específico do nível mostrado acima, independentemente da versão da API ou do esforço de raciocínio na recuperação. Em vez disso, a versão da API e o esforço de raciocínio afetam quantas fontes de conhecimento podem ser selecionadas durante a recuperação.

O 2025-08-01-preview usa o contrato legado do agente de conhecimento e não oferece suporte a retrievalReasoningEffort.

² O minimal esforço de raciocínio usa todas as fontes de conhecimento na base de conhecimento porque contorna o planejamento de consultas baseado em LLM.

Obter tempo de execução da requisição

O maxRuntimeInSeconds limite é o mesmo entre as camadas com suporte.

O limite máximo aplica-se apenas à solicitação de recuperação do Pesquisa de IA do Azure . Para ver exemplos de configuração, consulte Substitua o esforço de raciocínio padrão e defina limites de solicitação.

Limites de dados (enriquecimento de IA)

Os limites de dados se aplicam a um pipeline de enriquecimento de IA que chama a Linguagem do Azure no Foundry Tools. A entrada máxima é de 50.000 caracteres, conforme medido pela String.Lengthhabilidade de Reconhecimento de Entidade, habilidade de Vinculação de Entidade, habilidade de Extração de Frases-Chave, habilidade de Detecção de Idioma e habilidade de Detecção de PII. A habilidade de Sentimento tem um limite máximo de 5.000 caracteres.

Use a habilidade de Divisão de Texto quando precisar dividir texto maior antes do processamento downstream.

Esses limites se aplicam a modelos de preços dedicados e sem servidor.

Limitações

Os limites de limitação ajudam a garantir a estabilidade do serviço controlando a taxa de solicitações de API.

No modelo de preço dedicado, a limitação é baseada em unidades de pesquisa (réplicas × partições).

No modelo de preços sem servidor, a limitação não é baseada em unidades de pesquisa. Em vez disso, os limites de operação no nível de serviço e o comportamento geral de consumo regem a taxa de transferência. Os limites de uso e serviço gerenciam a capacidade, não a configuração de réplicas e partições.

Limites de limitação do classificador semântico

O classificador semântico usa um sistema de enfileiramento para gerenciar solicitações simultâneas. Esse sistema permite que os serviços de pesquisa obtenham o maior número de consultas por segundo possível. Quando o limite de solicitações simultâneas é atingido, o sistema coloca solicitações adicionais em uma fila. Se a fila estiver cheia, o sistema rejeitará novas solicitações e elas deverão ser repetidas.

O total de consultas de classificador semântico por segundo varia de acordo com os seguintes fatores:

• O nível do serviço de pesquisa. A capacidade da fila e os limites de solicitação simultânea variam de acordo com a camada de serviço.
• O número de unidades de pesquisa no serviço de pesquisa. A maneira mais simples de aumentar o número máximo de consultas simultâneas do classificador semântico é adicionar unidades de pesquisa adicionais ao serviço de pesquisa.
• A capacidade total do classificador semântico disponível na região.
• O tempo necessário para atender a uma consulta usando o classificador semântico. Esse tempo varia de acordo com o quão ocupado é o serviço de pesquisa.

A tabela a seguir descreve os limites de limitação do classificador semântico por nível, sujeitos à capacidade disponível na região. Você pode entrar em contato com o suporte da Microsoft para solicitar um aumento de limite.

Limites de solicitação de API

Existem limites de consultas porque consultas não associadas podem desestabilizar seu serviço de pesquisa. Em geral, essas consultas são criadas programaticamente. Se a sua aplicação gerar consultas de pesquisa programaticamente, projete-a de modo que não gere consultas de tamanho ilimitado.

Os limites de cargas existem por motivos semelhantes, garantindo a estabilidade do serviço de pesquisa. O limite se aplica a toda a solicitação, incluindo todos os seus componentes. Por exemplo, se a solicitação reunir vários documentos ou comandos, toda a solicitação deverá caber dentro do limite suportado.

Se você precisar exceder um limite com suporte, teste sua carga de trabalho para saber o que esperar.

Exceto quando observado, as solicitações de API a seguir se aplicam a todas as interfaces programáveis, incluindo os SDKs do Azure.

Geral:

• O limite máximo de carga com suporte é de 16 MB para indexação e solicitação de consulta por meio da API REST e SDKs.
• Comprimento máximo de URL de 8 KB (aplica-se somente às APIs REST).

APIs de indexação:

• Suporte para até 1.000 documentos por lote de carregamento, mesclagem ou exclusão de índices.
• Cada solicitação dá suporte entre 1 e 32.000 ações de indexação.

APIs de consulta:

• Máximo de 10 campos em uma consulta de vetor
• Máximo de 32 campos na cláusula $orderby.
• Máximo de 100.000 caracteres em uma cláusula de pesquisa.
• O número máximo de cláusulas na pesquisa é de 3.000.
• Limites máximos em caractere curinga e de expressão regular, conforme imposto por Lucene. Ele limita o número de padrões, variações ou correspondências a 1.000 instâncias. Esse limite está em vigor para evitar a sobrecarga do mecanismo.

Termos de Pesquisa:

• O tamanho máximo do termo de pesquisa com suporte é de 32.766 bytes (32 KB menos 2 bytes) de texto codificado em UTF-8. Aplica-se à pesquisa de palavra-chave e à propriedade de texto da busca em vetores.
• O tamanho máximo do termo de pesquisa com suporte é de 1.000 caracteres para pesquisa de prefixo e pesquisa regex.

Limites de resposta da API

• Cada página de resultados da pesquisa retorna até 1.000 documentos.
• Cada solicitação de API de Sugestão retorna até 100 sugestões.

O mecanismo de pesquisa retorna 50 resultados por padrão, mas você pode substituir esse parâmetro até o limite máximo.

Limites de chave de API

Use chaves de API para autenticação de serviço. Existem dois tipos de chaves de API. As chaves de administrador, que você especificar no cabeçalho da solicitação, fornecem acesso completo de leitura e gravação ao serviço. As chaves de consulta, que você especifica na URL, são somente de leitura e normalmente distribuídas aos aplicativos cliente.

• Cada serviço dá suporte a até duas chaves de administrador.
• Cada serviço dá suporte a até 50 chaves de consulta.