Azure AI Search dimensioniert nicht danach, wie viele Vektoren man hat. Es dimensioniert nach Tier: Der vector index ist durch den Speicher begrenzt, den die SKU für Vektorsuche reserviert, und im Serverless-Modell durch harte 300 MB pro Index, deren Überschreitung den Indexing-Job schlicht fehlschlagen lässt. Diese eine Eigenschaft, kein Feature-Vergleich, entscheidet, ob die Retrieval-Schicht des Unternehmens in Azure AI Search gehört oder in eine dedizierte Vektordatenbank. Teil 6 hat wiederholte Fragen billig gemacht. Dieser Teil behandelt den weit häufigeren Fall, dass das Modell Fakten braucht, die es nie gesehen hat, und die Retail-Wissenssuche aus Teil 1 wird endlich gebaut.

Wo Retrieval relativ zum Gateway sitzt

Ein Punkt, der vor jedem Vergleich geklärt gehört, weil er die Prämisse der Serie intakt hält: Retrieval ist kein Gateway-Traffic. Die Anwendung fragt den Suchindex direkt an, baut aus dem Ergebnis einen Prompt und schickt diesen Prompt durch das Gateway wie jede andere Completion. Das Gateway misst die Tokens, die der abgerufene Kontext hinzufügt, und genau diese Sichtbarkeit will man, denn Retrieval ist üblicherweise die Stelle, an der sich die Promptgröße still verdreifacht.

Der eine Teil, der das Gateway doch berührt, ist das Embedding. Query- und Dokument-Embeddings zu erzeugen ist ein Modellaufruf, also geht er durch dieselbe Tür wie alles andere, mit derselben Quota und derselben Zuordnung. Das heißt auch: Das Embeddings-Deployment, das Teil 6 für semantic caching angelegt hat, ist wahrscheinlich dasselbe Deployment, das Retrieval braucht, und seine Kapazität dient jetzt zwei Herren.

Die Limits, die es tatsächlich entscheiden

Feature-Checklisten lassen Azure AI Search und einen dedizierten Vektor-Store austauschbar aussehen. Die Service-Limits tun das nicht.

  • Die Größe des vector index ist eine Funktion der SKU, nicht der Daten. Im Dedicated-Preismodell ist sie durch den auf dem Tier für Vektorsuche reservierten Speicher begrenzt; in Serverless sind es 300 MB pro Index, grob 30 Prozent des gesamten Index-Speichers, und ein hartes Limit, an dem Indexing fehlschlägt statt zu degradieren.
  • Vektor-Limits hängen davon ab, wann der Service erstellt wurde. Höhere Vektor-Quotas gelten für Services, die ab April 2024 in Regionen mit der zusätzlichen Kapazität erstellt wurden. Ein älterer Service in einer unterstützten Region braucht dafür unter Umständen ein explizites Upgrade, was eine Migrationsfrage ist statt eines Config-Schalters.
  • Kapazität ist replicas multipliziert mit partitions. Basic unterstützt drei partitions und drei replicas, neun search units, auf Services, die nach dem 3. April 2024 erstellt wurden; ältere Basic-Services sind auf eine partition begrenzt. S1 bis S3 gehen auf je zwölf.
  • Das SLA ist eine Replica-Zahl. Zwei oder mehr replicas für Query-Workloads, drei oder mehr für Query und Indexing. Die Partition-Zahl spielt für das SLA überhaupt keine Rolle, was Leute überrascht, die für Storage skaliert haben und Verfügbarkeit gleich mit erwartet hatten.
  • Die Index-Zahl ist pro Tier gedeckelt. Fünf oder fünfzehn auf Basic, fünfzig auf S1, zweihundert auf S2 und S3. Eine Plattform, die jedem Tenant einen eigenen Index gibt, trifft diese Decke lange vor dem Storage, und Index-pro-Tenant ist der Default-Instinkt.
  • Maximal 4096 Dimensionen pro Vektorfeld, auf jedem Tier, was großzügig ist, aber bekannt sein sollte, bevor jemand ein größeres Embedding-Modell zum Standard macht.

Zusammen gelesen sagen diese Limits etwas Spezifisches: Azure AI Search wird als Suchdienst bepreist und skaliert, der auch Vektoren kann. Ist der Vektor-Korpus der dominante Kostentreiber und wächst er unabhängig vom Query-Volumen, bezahlt man search units dafür, Speicher zu halten. Das ist die Bedingung, unter der eine dedizierte Vektordatenbank gewinnt, und sie ist eine quantitative Bedingung, die sich nachrechnen lässt, statt einer Architektur-Präferenz.

Was Azure AI Search liefert und ein Vektor-Store nicht

Das Gegengewicht ist real und für eine Unternehmens-Wissensbasis oft entscheidend.

Hybrid search in einem Request. Eine einzelne Query trägt sowohl einen search-Parameter als auch vectorQueries, führt Volltext- und Vektor-Retrieval parallel aus und fusioniert beide per Reciprocal Rank Fusion zu einem gerankten Ergebnis-Set. Text-Ranking nutzt BM25; Vektor-Ranking nutzt HNSW oder exhaustive KNN. Das zählt, weil Produktdokumentation voller exakter Tokens ist, Modellnummern, Fehlercodes, Teilenummern, die lexikalische Suche zuverlässig findet und Embeddings verwischen.

{
  "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
}

Filtering, Faceting, Sortierung und Scoring-Profile gelten für denselben Request, sodass Autorisierung auf Dokumentebene (dieser Tenant, diese Produktlinie, diese Sprache) ein Filter ist statt eines separaten Index. Integrated vectorization über Indexer zieht aus Blob Storage, Cosmos DB, Azure SQL oder OneLake und embedded beim Ingest, was eine komplette Pipeline entfernt, die das Plattform-Team sonst betreiben müsste. Und der Index lässt sich als Knowledge Source für Agent-Szenarien in Microsoft Foundry anbinden.

Ein Kapazitätsdetail versteckt sich in der Geschichte von der Ranking-Qualität. Der semantic ranker wird über eine Queue gedrosselt, mit einem Maximum gleichzeitiger Requests pro search unit von 2 auf Basic, 3 auf S1 und 4 ab S2, plus einer begrenzten Queue dahinter. Läuft die Queue über, werden Requests abgelehnt und müssen wiederholt werden. Der Weg nach oben sind mehr search units, oder ein Support-Request. Eine Retrieval-Schicht, die semantic ranking für jede Query einschaltet, hat ihre Concurrency-Decke damit zu einer Funktion des Search-Tiers gemacht, und diese Decke ist auf Basic klein.

Die Entscheidung, als Test formuliert

Keine Präferenz. Drei Prüfungen, in dieser Reihenfolge:

  • Braucht der Korpus lexikalisches und Vektor-Retrieval zusammen? Wenn exakte Identifier zählen, und bei Produktdokumentation tun sie das immer, ist hybrid plus semantic ranking in einem Service viel wert, und es über einem reinen Vektor-Store nachzubauen heißt, zusätzlich einen invertierten Index zu betreiben.
  • Wächst der Vektor-Footprint unabhängig vom Query-Volumen? Wenn ja, die search units modellieren, die ihn halten, und gegen eine auf Storage dimensionierte Vektordatenbank rechnen. Das ist Arithmetik, und es ist üblicherweise die Stelle, an der die Antwort kippt.
  • Wie viele logische Korpora gibt es? Index-pro-Tenant trifft die Index-Decke des Tiers schnell. Die Alternative ist ein Index mit einem tenant filter, der ein Security-Control ist, das in der Query-Schicht durchgesetzt werden muss, nicht im Client.

Für diese Plattform lautet die Antwort Azure AI Search, weil die Retail-Wissensbasis ein paar Dutzend Gigabyte Produktdokumentation ist, in der exakte Modellnummern zählen, und weil die Betriebskosten eines weiteren Managed Service niedriger sind als die eines selbst betriebenen Vektor-Stores auf demselben AKS-Cluster. Für einen Agent-Memory-Store mit Hunderten Millionen Vektoren und ohne lexikalische Anforderung wäre die Antwort das Gegenteil, und die Serie läge falsch, wenn sie etwas anderes behauptete.

Tenancy, und der Filter, der ein Security-Control ist

Ein Index mit einem tenant filter ist unter der Index-Zahl-Decke der richtige Default, und er legt eine Autorisierungsentscheidung in die Query. Die Regel ist dieselbe wie bei vary-by in Teil 6: Der Filterwert kommt aus dem validierten Token, nie aus einem Request-Parameter. Eine Anwendung, die ihre eigene Tenant-ID übergibt, ist einen Bug davon entfernt, die von jemand anderem zu übergeben.

Weil Retrieval nicht durch API Management läuft, ist der Enforcement-Punkt die Anwendung oder die Control Plane, nicht eine Gateway-Policy. Das ist eine echte Lücke im One-Door-Modell, und es ist besser, sie zu benennen, als sie zu übergehen: Das Gateway regelt den Modellzugriff, der Suchdienst regelt den Dokumentzugriff, und das sind zwei verschiedene Control Planes, die sich einig sein müssen, wer der Tenant ist. Beide aus demselben Entra ID Claim abzuleiten ist das, was sie vom Auseinanderdriften abhält.

Fehlerbilder, die man im Blick behalten sollte

  • Indexing, das an einem Größenlimit fehlschlägt statt zu degradieren. Das Überschreiten der Vektor-Obergrenze pro Index auf Serverless lässt die Operation fehlschlagen. Kapazität für den vector index ist ein Planungs-Input, nichts, das man während eines Bulk Load entdeckt.
  • Ein alter Search Service mit alten Vektor-Quotas. Erstellt vor April 2024, in einer Region, die inzwischen mehr bietet, und still begrenzt, bis ihn jemand upgraded.
  • Partitions skalieren und Verfügbarkeit erwarten. Partitions sind Storage. Das SLA zählt replicas, zwei für Queries und drei, wenn Indexing parallel läuft.
  • Semantic-ranker-Throttling unter Last. Concurrency gilt pro search unit und ist auf niedrigen Tiers klein. Das Symptom sind abgelehnte Queries in der Spitze, keine langsamen.
  • Index-pro-Tenant gegen eine Tier-Decke. Es funktioniert wunderbar für das erste Dutzend Tenants und hört dann auf, und die Migration auf einen gefilterten Index ist an diesem Punkt ein Datenprojekt.
  • Abgerufener Kontext, der die Promptgröße sprengt. Das Gateway misst ihn, also taucht er in den Zahlen aus Teil 5 als Token-Anstieg auf, den keine Code-Änderung erklärt. Auf Tokens pro Request pro Tenant alerten, nicht nur auf die Gesamtausgaben.

Was Teil 8 erbt

Eine Retrieval-Schicht, die die Anwendungen direkt aufrufen, ein mit dem Cache geteiltes Embeddings-Deployment und Prompts, die jetzt deutlich größer sind als vorher. Was die Frage aufwirft, um die es im nächsten Teil geht: Gehört, sobald eine Anwendung Retrieval, Tool Calling und mehrere Modell-Hops braucht, ein Orchestrierungs-Framework auf dieses Gateway, oder fängt das Framework an, es zu bekämpfen.

Weiterlesen

Für die Infrastruktur- und Plattform-Seite, so etwas in diesem Maßstab zu betreiben, gibt es die Field Notes auf ercan.cloud, und der Hub liegt auf ercanermis.com.

Referenzen