Limites de service de la recherche Azure AI

Les limites maximales sur le stockage, les charges de travail et les quantités d’index et d’autres objets dépendent du modèle de tarification de votre service Recherche Azure AI.

Recherche Azure AI prend en charge deux modèles tarifaires, chacun avec des niveaux de service associés. Le niveau que vous sélectionnez a un impact sur les limites de service décrites dans cette aide.

• Dédié : tarification fixe mesurée en unités de recherche (SUs). Les options de niveau de service sont les suivantes : De base, Standard (S1-S3, y compris S3 HD), Stockage optimisé (L1-L2) et niveau Gratuit avec des fonctionnalités limitées du service de recherche.
• Serverless (préversion) : tarification basée sur la consommation mesurée par unités de calcul par heure (CU/hr) et par Go/mois pour le stockage indexé. Le niveau d’évaluation actuel est : Serverless Developer. Les limites sont définies par les plafonds par index, le nombre d’objets par service et le comportement de limitation du mode serverless.

Pour plus d’informations, consultez Choisir un modèle tarifaire et un niveau de service.

Diagnostiquer les erreurs liées aux quotas, à la capacité ou aux limites

Les défaillances de quota et de capacité proviennent de contrôles distincts. Utilisez l’erreur de l’opération terminée pour rechercher celle qui s’applique.

Si une opération de création, de mise à l’échelle ou de mise à niveau est toujours en cours d’exécution, attendez que l’état d’approvisionnement devienne Succeeded ou Failed. Une opération en cours n’est pas une preuve d’un problème de quota ou de capacité. En cas d’échec d’une opération de mise à l’échelle, consultez Erreurs lors de la mise à l’échelle.

Le quota d’abonnement disponible ne garantit pas la capacité régionale et la demande d’un quota supplémentaire ne résout pas une contrainte de capacité. Si l’échec persiste, ouvrez une demande de support Azure incluant l’abonnement, la région, le niveau, la configuration demandée, le texte d’erreur complet, l’heure UTC et toute corrélation ou ID d’opération.

Limites d’abonnement

Vous pouvez créer plusieurs services de recherche facturables (de niveau Essentiel et supérieur), dans la limite du nombre maximal de services autorisé à chaque niveau, par région. Par exemple, vous pouvez créer jusqu’à 16 services au niveau De base et 16 autres services au niveau S1 au sein du même abonnement et de la même région. Vous pouvez ensuite créer 16 services de base supplémentaires dans une autre région pour un total combiné de 32 services de base sous le même abonnement. Pour plus d’informations sur les niveaux de service, consultez Choisir un modèle tarifaire et un niveau de service.

Vous pouvez augmenter les limites de service maximales par demande. S’il vous faut davantage de services dans le même abonnement, remplissez une demande de support.

¹ Vous pouvez avoir un service de recherche gratuit par abonnement Azure. Le niveau gratuit est basé sur l’infrastructure partagée avec d’autres clients. Étant donné que le matériel n’est pas dédié, le scale-up n’est pas pris en charge et le stockage est limité à 50 Mo. Un service de recherche gratuit peut être supprimé après de longues périodes d’inactivité pour faire de la place à des services supplémentaires.

² Les unités de recherche sont des unités de facturation, allouées en tant que réplicas ou partitions. Vous devez disposer des deux. Pour obtenir plus d’informations sur les combinaisons de SU, consultez Estimer et gérer la capacité d’un service de recherche.

Limites du service

Dans le modèle tarifaire dédié, planifiez la capacité en multipliant les réplicas par partitions (unités de recherche).

¹ Le niveau de base prend en charge trois partitions et trois répliques, pour un total de neuf unités de recherche (SU) pour les nouveaux services de recherche créés après le 3 avril 2024. Les anciens services de niveau Basic sont limités à une partition et à trois répliques.

Un service de recherche est soumis à une limite de stockage maximale (taille de partition multipliée par le nombre de partitions) ou à une limite dure sur le nombre maximal d’index ou d’indexeurs, selon la limite en premier.

Les contrats de niveau de service (SLA) s’appliquent aux services facturables avec deux réplicas ou plus pour les charges de travail de requête, ou trois réplicas ou plus pour les charges de travail de requête et d’indexation. Le nombre de partitions n’est pas pris en compte dans les SLA. Pour plus d’informations, consultez Fiabilité dans la Recherche Azure AI.

Les services gratuits n’ont pas de partitions fixes ou de réplicas et partagent des ressources avec d’autres abonnés.

Stockage de partitions (Go)

Les limites de stockage par service varient en fonction de deux facteurs : la date et la région de création de service. La plupart des régions prises en charge offrent des limites plus élevées pour les services plus récents.

Ce tableau montre la progression des augmentations d’espace de stockage en Go au fil du temps. À compter d’avril 2024, des partitions de capacité plus élevées sont en ligne dans les régions répertoriées dans les notes de bas de page. Si vous avez un service plus ancien dans une région prise en charge, vérifiez si vous pouvez mettre à niveau votre service pour obtenir des limites de stockage plus élevées.

¹ Stockage de capacité plus élevé pour basic, S1, S2 et S3 dans ces régions. Amériques : Brésil Sud, Canada Centre, Canada Est, USA Est, USA Est 2, USA Centre Nord, USA Centre Sud, USA Ouest, USA Ouest 2, USA Ouest 3, USA Centre Ouest. Europe : France Centre. Italie Nord, Europe Nord, Norvège Est, Pologne Centre, Suisse Nord, Suède Centre, Royaume-Uni Sud, Royaume-Uni Ouest. Moyen-Orient : Émirats arabes unis Nord. Afrique : Afrique du Sud Nord. Asie Pacifique : Australie Est, Australie Sud-Est, Inde Centre, Jio Inde Ouest, Asie Est, Asie Sud-Est, Japon Est, Japon Ouest, Corée Centre, Corée Sud.

² Stockage de capacité plus élevé pour L1 et L2. Plus de régions offrent une capacité plus élevée à chaque niveau facturable. Amériques : USA Est 2 EUAP. Europe : Allemagne Nord, Allemagne Centre-Ouest, Suisse Ouest. Azure Government : Texas, Arizona, Virginie. Afrique : Afrique du Sud Nord. Asie-Pacifique : Chine Nord 3, Chine Est 3.

³ Un stockage de capacité plus élevé est disponible en Europe Ouest.

Limites d’index

¹ Les services de base créés avant décembre 2017 présentent des limites inférieures (5 au lieu de 15) sur les index.

² La limite supérieure des champs comprend à la fois les champs de premier niveau et les sous-champs imbriqués dans une collection complexe. Par exemple, si un index contient 15 champs et a deux collections complexes avec cinq sous-champs chacun, le nombre de champs de votre index est de 25. Les index avec une collection de champs très volumineux peuvent être lents, en particulier sur les services de base plus anciens. Limitez les champs et les attributs à ceux dont vous avez besoin, puis exécutez des tests d’indexation et de requête pour garantir que les performances sont acceptables.

³ Services de base créés avant le 3 avril 2024 prennent en charge un maximum de 100 champs par index. Les services de base plus récents prennent en charge 1 000 champs par index.

⁴ Une limite supérieure existe pour les éléments, car le fait d’avoir un grand nombre d’entre eux augmente considérablement le stockage requis pour votre index. Un élément d’une collection complexe est défini en tant que membre de cette collection. Par exemple, prenons un document Hôtel avec une collection complexe de chambres. Chaque pièce de la collection Rooms est considérée comme un élément. Pendant l’indexation, le moteur d’indexation peut traiter en toute sécurité un maximum de 3 000 éléments dans l’ensemble du document. Cette limite a été introduite dans api-version=2019-05-06 et s’applique uniquement aux collections complexes, et non aux collections de chaînes ou aux champs complexes.

⁵ Pour la plupart des niveaux, la taille maximale de l’index est le stockage total disponible sur votre service de recherche. Pour les services S2, S3 et S3 HD avec plusieurs partitions, et donc plus de stockage, la taille maximale d’un index unique est fournie dans la table. S’applique aux services de recherche créés après le 3 avril 2024. Les index pour les services configurés avec le modèle serverless (préversion) ont une taille maximale définie fournie dans la table.

Il se peut que vous constatiez une variation des limites maximales si votre service se trouve être provisionné sur un cluster plus puissant. Les limites ici représentent le dénominateur commun. Les index intégrés aux spécifications ci-dessus sont portables sur les niveaux de service équivalents dans n’importe quelle région.

Limites du document

Chaque index prend en charge jusqu’au nombre de documents suivant :

• 24 milliards sur Basic, S1, S2 et S3
• 2 milliards sur S3 HD
• 288 milliards sur L1
• 576 milliards sur L2

Chaque document peut avoir une taille d’environ 16 Mo. La limite de taille du document s’applique réellement à la taille de la charge utile de requête de l’API d’indexation, qui est de 16 Mo. Cette charge utile peut être un document unique ou un lot de documents. Pour un lot comprenant un seul document, la taille maximale du document est de 16 Mo de JSON.

La limite de taille de document s’applique à l’indexation en mode Push qui charge les documents dans un service de recherche. Si vous utilisez un indexeur pour l’indexation en mode Pull, vos fichiers sources peuvent être n’importe quelle taille de fichier, sous réserve de limitesd’indexeur. Pour l’indexeur d’objets blob, les limites de taille de fichier sont plus grandes pour les niveaux supérieurs. Par exemple, la limite S1 est de 128 Mo et la limite S2 est de 256 Mo.

Lorsque vous estimez la taille du document, n’indexez que les champs qui ajoutent de la valeur à vos scénarios de recherche. Excluez les champs sources qui n’ont aucun objectif dans les requêtes que vous envisagez d’exécuter.

Limite de la taille de l’index vectoriel

Quand vous indexez des documents avec des champs vectoriels, la Recherche Azure AI construit des index vectoriels internes en utilisant les paramètres d’algorithme que vous avez spécifiés.

La taille de ces index vectoriels est limitée par :

• Mémoire réservée à la recherche vectorielle pour le niveau tarifaire de votre service (ou SKU) dans le modèle de tarification dédié.
• Limites de stockage par index dans le modèle de tarification Serverless.

Pour obtenir des conseils sur la gestion et l’optimisation du stockage vectoriel, consultez Taille d’index vectoriel et respect des limites.

Les limites vectorielles varient en fonction des éléments suivants :

• Date de création du service
• Région
• Modèle tarifaire et niveau de service sélectionnés

Depuis avril 2024, les limites vectorielles sont plus élevées sur les nouveaux services de recherche dans les régions fournissant la capacité supplémentaire, c’est-à-dire la plupart d’entre elles. Si vous avez un service plus ancien dans une région prise en charge, vérifiez si vous pouvez mettre à niveau votre service vers les limites de vecteur supérieures.

Dans le modèle de tarification Serverless, les limites de vecteurs sont définies par index plutôt que par partition.

• Taille maximale de l’index vectoriel par index (serverless) : 300 Mo
  • Cette taille représente environ 30% du stockage total d’index, conformément au ratio de vecteur à stockage utilisé dans les niveaux de service dédiés.
  • Cette taille est une limite stricte par index. Les tentatives de dépassement de cette limite lors de l’indexation échouent.

Ce tableau montre la progression des augmentations des quotas de vecteurs en Grande-Bretagne au fil du temps. Le quota est par partition. Par conséquent, si vous mettez à l’échelle un nouveau service Standard (S1) à 6 partitions, le quota total de vecteurs est de 35 multiplié par 6.

¹ Limites initiales du vecteur lors de la préversion anticipée.

² Limites du vecteur pendant la dernière période de prévision. Trois régions n’avaient pas de limites plus élevées : Allemagne Centre-Ouest, Inde Ouest, Qatar Central.

³ Quota de vecteurs plus élevé en fonction des partitions les plus grandes pour les régions et les niveaux pris en charge.

⁴ Quota de vecteurs plus élevé pour un plus grand nombre de régions et de niveaux en fonction des mises à jour de la taille des partitions.

Le service applique un quota de taille d’index vectoriel :

• Dédié : par partition dans votre service de recherche
• Serverless : Par index

Ce quota est une limite difficile pour garantir que votre service reste sain. D’autres tentatives d’indexation une fois la limite dépassée entraînent un échec. Vous pouvez reprendre l’indexation une fois que vous libérez le quota disponible en :

• Suppression de documents vectoriels
• Réduction de la taille ou de la dimensionnalité du vecteur
• (Dédié uniquement) Montée en puissance des partitions

Limites de l’indexeur

Les durées d’exécution maximales existent pour fournir équilibre et stabilité au service dans son ensemble, mais l’indexation des jeux de données volumineux peut prendre plus de temps que la valeur maximale ne le permet. Si un travail d’indexation ne peut pas être terminé dans le délai maximal autorisé, essayez de l’exécuter selon une planification. Le planificateur effectue le suivi de l’état de l’indexation. Si une tâche d’indexation planifiée est interrompue pour une raison quelconque, à la prochaine exécution planifiée, l’indexeur peut repartir de là où il s’était arrêté.

Limites d’objet et de débit de l’indexeur

¹ Les services du niveau Gratuit bénéficient d’une durée d’exécution maximale de l’indexeur de 3 minutes pour les sources d’objets blob, et de 1 minute pour toutes les autres sources de données. L’appel de l’indexeur se fait une fois toutes les 180 secondes. Pour l’indexation par IA qui appelle Foundry Tools, les services gratuits sont limités à 20 transactions gratuites par indexeur par jour, où une transaction est définie comme un document qui passe correctement par le pipeline d’enrichissement. (Conseil : vous pouvez réinitialiser un indexeur pour réinitialiser son nombre.)

² Les services de base créés avant décembre 2017 présentent des limites inférieures (5 au lieu de 15) sur les index, les sources de données et les ensembles de compétences.

³ La prise en charge de l’indexeur S3 HD est en préversion et nécessite la version 2025-11-01-preview de l’API REST ou une version ultérieure. Les indexeurs HD S3 s’exécutent uniquement dans l’environnement d’exécution mutualisé et ne prennent pas en charge les ressources de liaison privée partagée. Lors de la préversion, la prise en charge de l’indexeur S3 HD est mieux adaptée aux charges de travail légères (avec une taille d’index d’environ 1 Go), sans ensembles de compétences ou avec des ensembles de compétences minimaux. Pour obtenir des conseils sur le comportement d’agrégation, la surveillance et la planification, consultez l’exécution de l’indexeur sur Serverless et S3 HD.

⁴ Nombre maximal de 30 compétences par group de compétences.

⁵ Concernant la durée maximale de 2 ou 24 heures pour les indexeurs : une durée maximale de 2 heures est la plus courante et c’est ce que vous devez planifier. Il fait référence aux indexeurs qui s’exécutent dans l’environnement public, ce qui décharge le traitement gourmand en calcul et laisse plus de ressources pour les requêtes. La limite de 24 heures s’applique si vous configurez l’indexeur pour qu’il s’exécute dans un environnement privé en utilisant uniquement l’infrastructure allouée à votre service de recherche. Certains indexeurs plus anciens ne peuvent pas s’exécuter dans l’environnement public, et ces indexeurs ont toujours une plage de traitement de 24 heures. Si vous avez des indexeurs non planifiés qui s’exécutent en continu pendant 24 heures, vous pouvez supposer que ces indexeurs n’ont pas pu être migrés vers l’infrastructure plus récente. En règle générale, pour les travaux d’indexation qui ne peuvent pas se terminer dans les deux heures, placez l’indexeur dans une planification de 5 minutes afin que l’indexeur puisse rapidement reprendre là où il s’est arrêté. Dans le niveau Gratuit, le temps maximal d'exécution, limité entre 3 et 10 minutes, est destiné aux indexeurs ayant des compétences spécifiques.

⁶ Sur les services S3 HD et Serverless, tous les indexeurs partagent 24 heures de runtime cumulé par service dans chaque fenêtre UTC de 24 heures. Pour obtenir des conseils sur le comportement des quotas, la surveillance et la planification, consultez l’exécution de l’indexeur sur Serverless et S3 HD (préversion).

Limites de fichier source pour les indexeurs de type blob

Le traitement des fichiers se produit en phases, et chaque étape a ses propres limites :

1. Un connecteur de source de données télécharge un élément source, soumis à des limites de connecteur spécifiques à la source.
2. Recherche Azure AI extrait le contenu de l'élément, sous réserve de la taille maximale du fichier source et des limites de caractères extraites dans le tableau suivant.
3. Si vous le souhaitez, un ensemble de compétences envoie ce contenu aux services en aval, où la limite d’entrée d’une compétence individuelle peut être inférieure à ce que l’indexeur extrait.

La taille maximale du fichier source et les limites de caractères extraites dans le tableau suivant s’appliquent aux indexeurs Stockage Blob Azure, ADLS Gen2, SharePoint dans Microsoft 365, OneLake et Azure Files indexeurs. Pour connaître les limites par compétence, consultez l’article de référence pour chaque compétence de votre ensemble de compétences.

¹ Le nombre maximal de caractères est basé sur des unités de code Unicode, en particulier UTF-16.

² Lorsque vous utilisez delimitedText le mode d’analyse pour les fichiers CSV, une limite de taille de mémoire tampon de 10 Mo par ligne de fichier s’applique.

³ Lorsque vous utilisez delimitedText le mode d’analyse pour les fichiers CSV, la limite « taille maximale du contenu extrait » ne s’applique pas.

⁴ Les indexeurs de type blob incluent l’indexeur Stockage Blob Azure (indexeur blob), l’indexeur ADLS Gen2, l’indexeur SharePoint dans Microsoft 365, l’indexeur OneLake et l’indexeur Azure Files. La source de connaissances de fichier de chargement direct n’utilise pas d’indexeur et a des limites distinctes.

Limites de ressource de liaison privée partagée

Les indexeurs peuvent accéder aux autres ressources Azure via des points de terminaison privés gérés via l’API de ressource de liaison privée partagée. Cette section décrit les limites associées à cette fonctionnalité.

¹ L’enrichissement par IA et l’analyse d’images sont gourmands en ressources et consomment une quantité disproportionnée de la puissance de traitement disponible. Pour cette raison, les connexions privées sont désactivées sur les niveaux inférieurs pour garantir les performances et la stabilité du service de recherche lui-même. Sur les services de base, les connexions privées à une ressource Microsoft Foundry ne sont pas prises en charge pour préserver la stabilité du service. Pour le niveau S1, vérifiez que le service a été créé avec des limites plus élevées après le 3 avril 2024. Les indexeurs avec plus de 2 compétences d’incorporation Azure OpenAI ou d’incorporations multimodales Azure Vision ne peuvent pas s’exécuter dans un environnement privé et les connexions privées ne sont pas disponibles.

² Les connexions privées à un modèle d’incorporation sont prises en charge sur les services de recherche Essentiel et S1 à haute capacité créés après le 3 avril 2024, avec les limites supérieures pour le stockage et le traitement du calcul.

³ Le nombre de types de ressources distincts est calculé en tant que nombre de valeurs groupId uniques utilisées dans toutes les ressources de liaison privée partagée pour un service de recherche donné, quel que soit l’état de la ressource.

Limites des synonymes

Le nombre maximal de mappages de synonymes varie selon le niveau. Chaque règle peut avoir jusqu’à 20 expansions, où une expansion est un terme equivalvent. Par exemple, pour le mot « chat », l’association avec « minou », « félin » et « felis » (le genre des chats) est comptée comme 3 expansions.

Limites des alias d’index

Le nombre maximal d’alias d’index varie selon la date de création de niveau et de service. Sur tous les niveaux, si le service a été créé après octobre 2022, le nombre maximal d’alias est double du nombre maximal d’index autorisés. Si le service a été créé avant octobre 2022, la limite correspond au nombre d’index autorisés.

¹ Les services de base créés avant décembre 2017 présentent des limites inférieures (5 au lieu de 15) sur les index.

Limites de récupération agentique

Une base de connaissances spécifie une ou plusieurs sources de connaissances et un effort de raisonnement de récupération (préversion) qui contrôle le niveau de traitement du modèle de langage volumineux (LLM) pour la récupération agentique. Les limites varient selon le niveau tarifaire, la version de l’API et le niveau d’effort de raisonnement.

¹ Services de base créés avant le 3 avril 2024 ont des limites inférieures (5) sur les sources de connaissances et les bases de connaissances.

² Ces limites s’appliquent aux services S3 HD qui prennent en charge les bases de connaissances et les sources de connaissances. Certains services S3 HD plus anciens ne prennent pas en charge ces ressources.

Sélection de la source de connaissances lors de la récupération

Une base de connaissances peut contenir jusqu’au maximum propre au niveau indiqué ci-dessus, quelle que soit la version de l’API ou le niveau d’effort du raisonnement de récupération. La version de l’API et l’effort de raisonnement affectent plutôt le nombre de sources de connaissances qui peuvent être sélectionnées lors de la récupération.

Le 2025-08-01-preview utilise le contrat hérité de l’agent de connaissances et ne prend pas en charge retrievalReasoningEffort.

² L’effort minimal de raisonnement utilise toutes les sources de connaissances dans la base de connaissances, car elle contourne la planification des requêtes basées sur LLM.

Récupérer le runtime de requête

La maxRuntimeInSeconds limite est identique entre les niveaux pris en charge.

La valeur maximale s’applique uniquement à la demande de récupération Recherche Azure AI. Pour obtenir des exemples de configuration, consultez Remplacer l’effort de raisonnement par défaut et définir des limites de requête.

Limites de données (enrichissement de l’IA)

Les limites de données s’appliquent à un pipeline d’enrichissement IA qui fait appel à Azure Language dans Foundry Tools. L’entrée maximale est de 50 000 caractères, comme mesuré par String.Length, pour la compétence Reconnaissance d’entité, la compétence Liaison d’entités, la compétence d’extraction d’expressions clés, la compétence Détection de langue et la compétence détection d’identité personnelle. La compétence Sentiment a un maximum de 5 000 caractères.

Utilisez la compétence Fractionnement de texte lorsque vous devez diviser du texte plus grand avant le traitement en aval.

Ces limites s’appliquent aux modèles tarifaires dédiés et serverless.

Limites de la limitation

Les limites de limitation permettent de garantir la stabilité du service en contrôlant le taux de demandes d’API.

Dans le modèle de tarification dédié, la limitation du débit est basée sur les unités de recherche (réplicas × partitions).

Dans le modèle de tarification Serverless, la limitation n’est pas basée sur les unités de recherche. Au lieu de cela, les limites d’opération au niveau du service et le comportement de consommation global régissent le débit. Les limites d’utilisation et de service gèrent la capacité, et non la configuration des réplicas et des partitions.

Limites de limitation de l’éditeur de classement sémantique

Ranker sémantique utilise un système de mise en file d’attente pour gérer les requêtes simultanées. Ce système permet aux services de recherche d’obtenir le nombre maximal de requêtes par seconde possible. Lorsque la limite des requêtes simultanées est atteinte, le système place des requêtes supplémentaires dans une file d’attente. Si la file d’attente est pleine, le système rejette les requêtes supplémentaires et celles-ci doivent être renvoyées.

Le nombre total de requêtes de classement sémantique par seconde varie en fonction des facteurs suivants :

• Niveau du service de recherche. La capacité de file d’attente et les limites de requête simultanées varient selon le niveau.
• Nombre d’unités de recherche dans le service de recherche. La façon la plus simple d’augmenter le nombre maximal de requêtes de classement sémantique simultanées consiste à ajouter plus d’unités de recherche à votre service de recherche.
• Capacité totale du classeur sémantique disponible dans la région.
• Temps nécessaire pour traiter une requête à l’aide d’un ranker sémantique. Cette période varie en fonction de la disponibilité du service de recherche.

Le tableau suivant décrit les limites d'étranglement de l'outil de classement sémantique par niveau, en fonction de la capacité disponible dans la région. Vous pouvez contacter le support technique de Microsoft pour demander une augmentation de limite.

Limites de requête d’API

Il existe des limites sur les requêtes, car les requêtes non liées peuvent déstabiliser votre service de recherche. En général, de telles requêtes sont créées par programmation. Si votre application génère des requêtes de recherche par programmation, concevez-la de sorte qu’elle ne génère pas de requêtes de taille non limitée.

Des limites sur les charges utiles existent pour des raisons similaires, afin de garantir la stabilité de votre service de recherche. La limite s'applique à l'ensemble de la demande, y compris tous ses composants. Par exemple, si la demande regroupe plusieurs documents ou commandes, l'ensemble de la demande doit tenir dans la limite autorisée.

Si vous devez dépasser une limite prise en charge, testez votre charge de travail afin de savoir ce que vous devez attendre.

Sauf indication contraire, les demandes d’API suivantes s’appliquent à toutes les interfaces programmables, y compris les Kits de développement logiciel (SDK) Azure.

Général :

• La charge utile maximale prise en charge est de 16 Mo pour l'indexation et les requêtes via l'API REST et les SDK.
• Longueur maximale de l’URL de 8 Ko (s’applique uniquement aux API REST).

API d’indexation :

• 1 000 documents maximum pris en charge par lot de charges, de fusions ou de suppressions d’index.
• Chaque requête prend en charge entre 1 et 32 000 actions d’indexation.

API de requête :

• Maximum 10 champs dans une requête vectorielle
• 32 champs maximum dans la clause $orderby.
• Maximum 100 000 caractères dans une clause de recherche.
• Le nombre maximum de clauses dans la recherche est de 3 000.
• Limites maximales sur les requêtes de caractères génériques et d’expression régulière, comme appliqué par Lucene. Il limite le nombre de motifs, de variations ou de correspondances à 1 000 cas. Cette limite a pour but d'éviter la surcharge du moteur.

Rechercher des termes :

• La taille maximale pris en charge des termes de recherche du texte encodé en UTF-8 est de 32 766 octets (32 Ko moins 2 octets). S'applique à la recherche par mot-clé et à la propriété texte de la recherche vectorielle.
• La taille maximale prise en charge des termes de recherche est de 1 000 caractères pour la recherche de préfixe et la recherche par expression régulière.

Limites de réponse d’API

• Chaque page des résultats de recherche retourne jusqu’à 1 000 documents.
• Chaque demande d’API Suggest retourne jusqu’à 100 suggestions.

Le moteur de recherche retourne 50 résultats par défaut, mais vous pouvez remplacer ce paramètre jusqu’à la limite maximale.

Limites de clés API

Utilisez des clés API pour l’authentification de service. Deux types de clés API existent. Les clés d’administration, que vous spécifiez dans l’en-tête de requête, fournissent un accès en lecture-écriture complet au service. Les clés de requête, que vous spécifiez sur l’URL, sont en lecture seule et généralement distribuées aux applications clientes.

• Chaque service prend en charge jusqu’à deux clés d’administration.
• Chaque service prend en charge jusqu’à 50 clés de requête.