Azure AI Search ne se dimensionne pas selon le nombre de vecteurs que vous détenez. Il se dimensionne par tier : le vector index est borné par la mémoire réservée à la recherche vectorielle sur votre SKU, et sur le modèle Serverless par une limite dure de 300 MB par index qui fait échouer net le job d'indexation quand elle est dépassée. Cette seule propriété, et non une comparaison de fonctionnalités, décide si la couche de retrieval de l'entreprise appartient à Azure AI Search ou à une base vectorielle dédiée. La partie 6 a rendu les questions répétées bon marché. Cette partie traite le cas bien plus fréquent où le modèle a besoin de faits qu'il n'a jamais vus, et la recherche de connaissances retail de la partie 1 se construit enfin.

Où se situe le retrieval par rapport à la gateway

Un point à trancher avant toute comparaison, parce que c'est lui qui préserve la prémisse de la série : le retrieval n'est pas du trafic de gateway. L'application interroge le search index directement, assemble un prompt à partir de ce qui revient, et envoie ce prompt à travers la gateway comme n'importe quelle autre completion. La gateway mesure les tokens que le contexte récupéré ajoute, ce qui est exactement la visibilité voulue, puisque le retrieval est en général l'endroit où la taille des prompts triple en silence.

La seule pièce qui touche la gateway est l'embedding. Générer les embeddings de requête et de document est un appel de modèle, il passe donc par la même porte que tout le reste, avec le même quota et la même attribution. Cela veut aussi dire que le déploiement d'embeddings créé par la partie 6 pour le semantic caching est probablement celui-là même que le retrieval réclame, et sa capacité sert désormais deux maîtres.

Les limites qui décident réellement

Les checklists de fonctionnalités font paraître Azure AI Search et un vector store dédié interchangeables. Les limites de service, non.

  • La taille du vector index est une fonction du SKU, pas de vos données. Dans le modèle de tarification Dedicated, elle est bornée par la mémoire réservée à la recherche vectorielle sur le tier ; en Serverless, c'est 300 MB par index, environ 30 pour cent du stockage total de l'index, et une limite dure qui fait échouer l'indexation plutôt que de la dégrader.
  • Les limites vectorielles dépendent de la date de création du service. Les quotas vectoriels plus élevés s'appliquent aux services créés à partir d'avril 2024 dans les régions disposant de la capacité supplémentaire. Un service plus ancien dans une région supportée peut exiger un upgrade explicite pour les obtenir, ce qui est une question de migration plutôt qu'un simple réglage de configuration.
  • La capacité, ce sont les replicas multipliés par les partitions. Basic supporte trois partitions et trois replicas, soit neuf search units, sur les services créés après le 3 avril 2024 ; les services Basic plus anciens sont limités à une seule partition. S1 à S3 montent à douze de chaque.
  • Le SLA est un nombre de replicas. Deux replicas ou plus pour les workloads de requête, trois ou plus pour requête et indexation. Le nombre de partitions n'entre pas du tout dans le SLA, ce qui surprend ceux qui ont scalé pour le stockage en supposant que la disponibilité venait avec.
  • Le nombre d'index est plafonné par tier. Cinq ou quinze sur Basic, cinquante sur S1, deux cents sur S2 et S3. Une plateforme qui donne à chaque tenant son propre index atteint ce plafond bien avant d'atteindre celui du stockage, et l'index par tenant est le réflexe par défaut.
  • Maximum 4096 dimensions par champ vectoriel, sur tous les tiers, ce qui est généreux mais vaut d'être su avant que quelqu'un ne standardise sur un modèle d'embeddings plus large.

Lues ensemble, ces limites disent quelque chose de précis : Azure AI Search est tarifé et scalé comme un service de recherche qui fait aussi des vecteurs. Si le corpus vectoriel est le principal poste de coût et qu'il grandit indépendamment du volume de requêtes, vous payez des search units pour tenir de la mémoire. C'est la condition sous laquelle une base vectorielle dédiée gagne, et c'est une condition quantitative que l'on peut vérifier plutôt qu'une préférence architecturale.

Ce qu'Azure AI Search vous donne et qu'un vector store n'a pas

Le contrepoids est réel et souvent décisif pour une base de connaissances d'entreprise.

La hybrid search en une seule requête. Une même query porte à la fois un paramètre search et des vectorQueries, exécute la recherche full-text et la recherche vectorielle en parallèle, et les fusionne avec Reciprocal Rank Fusion en un seul jeu de résultats classés. Le classement textuel utilise BM25 ; le classement vectoriel utilise HNSW ou un KNN exhaustif. Cela compte parce que la documentation produit est pleine de tokens exacts, numéros de modèle, codes d'erreur, références de pièces, que la recherche lexicale trouve de manière fiable et que les embeddings brouillent.

{
  "search": "device not connecting after the firmware update",
  "vectorQueries": [
    { "kind": "vector", "vector": [ ... ], "k": 50,
      "fields": "contentVector", "exhaustive": false, "oversampling": 10 }
  ],
  "queryType": "semantic",
  "semanticConfiguration": "kb-semantic",
  "top": 10
}

Le filtrage, le faceting, le tri et les scoring profiles s'appliquent à la même requête, donc l'autorisation au niveau document (ce tenant, cette gamme de produits, cette langue) est un filtre plutôt qu'un index séparé. Integrated vectorization via les indexers tire depuis Blob Storage, Cosmos DB, Azure SQL ou OneLake et génère les embeddings à l'ingestion, ce qui supprime un pipeline entier que l'équipe plateforme devrait sinon posséder. Et l'index peut être attaché comme source de connaissances pour les scénarios d'agents dans Microsoft Foundry.

Un détail de capacité se cache dans l'histoire de la qualité de classement. Le semantic ranker est throttlé par une file d'attente, avec un maximum de requêtes concurrentes par search unit de 2 sur Basic, 3 sur S1 et 4 sur S2 et au-delà, plus une file bornée derrière. Dépassez la file et les requêtes sont rejetées et doivent être retentées. Le moyen d'augmenter ce plafond est d'ajouter des search units, ou d'ouvrir une demande au support. Une couche de retrieval qui active le semantic ranking sur chaque requête vient donc de faire de son plafond de concurrence une fonction du tier de recherche, et ce plafond est petit sur Basic.

La décision, formulée comme un test

Pas une préférence. Trois vérifications, dans l'ordre :

  • Le corpus a-t-il besoin du retrieval lexical et vectoriel ensemble ? Si les identifiants exacts comptent, et pour la documentation produit ils comptent toujours, la hybrid search plus le semantic ranking dans un seul service valent beaucoup, et les réimplémenter au-dessus d'un pur vector store veut dire exploiter aussi un index inversé.
  • L'empreinte vectorielle grandit-elle indépendamment du volume de requêtes ? Si oui, modélisez les search units nécessaires pour la tenir et comparez avec une base vectorielle dimensionnée sur le stockage. C'est de l'arithmétique, et c'est en général là que la réponse bascule.
  • Combien y a-t-il de corpus logiques ? L'index par tenant heurte vite le plafond d'index du tier. L'alternative est un seul index avec un tenant filter, ce qui est un contrôle de sécurité qui doit être appliqué dans la couche de requête, pas dans le client.

Pour cette plateforme, la réponse est Azure AI Search, parce que la base de connaissances retail représente quelques dizaines de gigaoctets de documentation produit où les numéros de modèle exacts comptent, et parce que le coût opérationnel d'un service managé de plus est inférieur à celui d'un vector store auto-exploité sur le même cluster AKS. La réponse pour une mémoire d'agent comptant des centaines de millions de vecteurs et sans aucune exigence lexicale serait l'inverse, et la série aurait tort de prétendre le contraire.

La tenancy, et le filtre qui est un contrôle de sécurité

Un seul index avec un tenant filter est le bon défaut sous le plafond du nombre d'index, et cela place une décision d'autorisation dans la requête. La règle est la même que pour vary-by dans la partie 6 : la valeur du filtre vient du token validé, jamais d'un paramètre de requête. Une application qui transmet son propre tenant ID est à un bug de transmettre celui de quelqu'un d'autre.

Parce que le retrieval ne passe pas par API Management, le point d'application est l'application ou le control plane, pas une politique de gateway. C'est une vraie brèche dans le modèle à une seule porte, et mieux vaut la nommer que la masquer : la gateway gouverne l'accès aux modèles, le service de recherche gouverne l'accès aux documents, et ce sont deux control planes distincts qui doivent s'accorder sur l'identité du tenant. Tirer les deux du même claim Entra ID est ce qui les empêche de diverger.

Modes de défaillance à surveiller

  • Une indexation qui échoue sur une limite de taille plutôt que de se dégrader. Dépasser le plafond vectoriel par index en Serverless fait échouer l'opération. La capacité du vector index est une donnée de planification, pas quelque chose à découvrir pendant un bulk load.
  • Un vieux service de recherche avec de vieux quotas vectoriels. Créé avant avril 2024, dans une région qui en offre désormais davantage, et silencieusement limité jusqu'à ce que quelqu'un l'upgrade.
  • Scaler les partitions en espérant de la disponibilité. Les partitions, c'est du stockage. Le SLA compte les replicas, deux pour les requêtes et trois quand l'indexation tourne en parallèle.
  • Le semantic ranker qui throttle sous charge. La concurrence est par search unit et petite sur les tiers bas. Le symptôme, ce sont des requêtes rejetées au pic, pas des requêtes lentes.
  • L'index par tenant contre un plafond de tier. Cela fonctionne à merveille pour la première douzaine de tenants puis s'arrête, et la migration vers un index filtré devient alors un projet de données.
  • Un contexte récupéré qui fait exploser la taille des prompts. La gateway le mesure, donc il apparaît dans les chiffres de la partie 5 comme une hausse de tokens sans aucun changement de code pour l'expliquer. Alertez sur les tokens par requête et par tenant, pas seulement sur la dépense totale.

Ce dont hérite la partie 8

Une couche de retrieval que les applications appellent directement, un déploiement d'embeddings partagé avec le cache, et des prompts désormais nettement plus gros qu'avant. Ce qui pose la question dont traite la partie suivante : dès qu'une application a besoin de retrieval, de tool calling et de plusieurs sauts de modèles, un framework d'orchestration a-t-il sa place au-dessus de cette gateway, ou le framework se met-il à la combattre.

À lire ensuite

Pour le volet infrastructure et plateforme de l'exploitation de tout cela à grande échelle, les notes de terrain sont sur ercan.cloud, et le hub se trouve sur ercanermis.com.

Références