Azure AI Search: Der komplette Leitfaden 2026

Azure AI Search als Retrieval-Backend für RAG, Vektor- und Hybrid-Suche im eigenen Azure-Tenant Pexon Consulting (Microsoft Partner) | Geprüft von einem Azure Solutions Architect | 16 Min. Lesezeit | Stand: Juni 2026

Inhaltsverzeichnis

• TL;DR
• Was ist Azure AI Search?
• Warum Azure AI Search statt einer selbstgehosteten Vektordatenbank
• Was kostet Azure AI Search? (Preise 2026)
• Was Sie am Ende haben werden
• Voraussetzungen
• Teil 1: Such-Infrastruktur mit Terraform
• Teil 2: Index mit Vektor-Feldern anlegen
• Teil 3: Daten indexieren – Integrated Vectorization vs. Push-API
• Teil 4: Hybrid-Suche in Azure AI Search – BM25 + Vektor + Semantic Ranker
• Teil 5: Azure AI Search als RAG-Backend anbinden
• Agentic Retrieval und Foundry IQ – was 2026 neu ist
• Wann sich Azure AI Search lohnt – und wann nicht
• Häufig gestellte Fragen
• Nächster Schritt

TL;DR

Azure AI Search (früher Azure Cognitive Search) ist Microsofts gemanagte Such- und Retrieval-Plattform und das naheliegende Backend, wenn Sie RAG-Anwendungen im eigenen Azure-Tenant betreiben wollen. Sie kombiniert klassische Volltextsuche (BM25) mit Vektorsuche (HNSW) in einer einzigen Hybrid-Query, fusioniert die Ergebnisse per Reciprocal Rank Fusion (RRF) und schiebt optional einen Semantic Ranker als zweite Bewertungsstufe darüber. Daten bleiben in West Europe oder Germany West Central, Zugriff läuft über Microsoft Entra ID und Private Endpoints. Pexon Consulting (Microsoft Partner) setzt das produktiv bei Kunden in Versicherung, Fertigung und Energie ein. Der produktive Einstieg liegt im Basic-Tier bei rund 74 USD pro Search Unit und Monat.

Was ist Azure AI Search?

Azure AI Search ist eine vollständig gemanagte PaaS-Such- und Retrieval-Plattform von Microsoft Azure, die Volltextsuche (BM25), Vektorsuche (HNSW) und KI-gestütztes Semantic Reranking in einem Dienst vereint. Sie ist das Retrieval-Backend für KI-Anwendungen: Sie speichert und durchsucht Ihre Dokumente, generiert aber keine Antworten. Die Antwort erzeugt ein Sprachmodell (z.B. Azure OpenAI), dem Sie die gefundenen Passagen als Kontext mitgeben. Search ist das „R“ in RAG, nicht das „G“.

Der Dienst hieß bis Ende 2023 Azure Cognitive Search und wurde auf der Microsoft Ignite umbenannt, um die KI- und Vektor-Fähigkeiten zu betonen. Es ist derselbe Dienst – ältere Dokumentation, SDKs und Blog-Artikel sprechen noch von „Cognitive Search“.

Der Kern von Azure AI Search sind vier Such- und Ranking-Methoden, die sich kombinieren lassen:

Warum Azure AI Search statt einer selbstgehosteten Vektordatenbank

Azure AI Search ersetzt eine selbstgehostete Vektordatenbank dann, wenn Sie Volltext- und Vektorsuche kombinieren, Embeddings automatisch synchron halten und Betrieb plus Compliance an einen PaaS-Dienst abgeben wollen. Eine reine Vektordatenbank (Qdrant, Weaviate, pgvector) liefert nur Approximate-Nearest-Neighbor-Suche und keinen gemanagten Betrieb.

Die meisten RAG-Prototypen starten mit einer Open-Source-Vektordatenbank. Das funktioniert für eine Demo. In Produktion fängt dann die Arbeit an, die im Prototyp niemand eingeplant hat: Embeddings synchron halten, wenn sich Dokumente ändern. Volltext- und Vektor-Treffer sinnvoll kombinieren, weil reine Vektorsuche bei exakten Begriffen, Produktnummern und Eigennamen verblüffend schlecht ist. Hochverfügbarkeit, Backups, Zugriffskontrolle, Audit-Logs.

Azure AI Search nimmt Ihnen genau diese Betriebsarbeit ab. Es ist kein reiner Vektor-Speicher, sondern eine Retrieval-Engine: Volltextsuche mit BM25, Vektorsuche mit dem HNSW-Algorithmus, beides parallel in einer einzigen Anfrage, fusioniert über Reciprocal Rank Fusion (RRF). Darüber lässt sich ein Semantic Ranker schalten, der die Top-50-Treffer mit einem von Microsoft trainierten, mehrsprachigen Deep-Learning-Modell neu bewertet – die zweite Stufe, die in der Praxis bestimmt, ob die richtige Passage oben steht oder auf Platz sieben.

Wir raten nicht pauschal jedem zu Azure AI Search. Wenn Sie eine einzelne Anwendung mit ein paar tausend Dokumenten bauen, ohne Compliance-Anforderungen und ohne Azure-Bindung, ist pgvector neben Ihrer bestehenden Postgres günstiger und schneller aufgesetzt. Sobald aber mehrere Datenquellen, Zugriffssteuerung pro Nutzergruppe, Datenresidenz in der EU und ein gemanagter Betrieb dazukommen – also der typische Mittelstands- und Enterprise-Fall – kippt die Rechnung deutlich Richtung Azure AI Search. Mehr dazu in unserer Private-AI-Beratung.

Was kostet Azure AI Search? (Preise 2026)

Azure AI Search startet kostenlos (Free-Tier, 50 MB), der produktive Einstieg liegt im Basic-Tier bei rund 74 USD pro Search Unit und Monat. Semantic Ranker und Agentic Retrieval werden separat abgerechnet.

Es gibt zwei Abrechnungsmodelle:

Eine Search Unit (SU) ist das Abrechnungsmaß im Dedicated-Modell und entspricht einem Replica × einer Partition. Partitionen liefern Storage und Index-Größe, Replicas liefern Query-Durchsatz und SLA. Den Semantic Ranker gibt es im Standard-Plan mit den ersten 1.000 Anfragen pro Monat kostenfrei, danach pro 1.000 Anfragen abgerechnet.

Stand Juni 2026: Microsoft hat das Pricing-Modell zuletzt um das Serverless-Modell erweitert. Die exakten Tier-Preise prüfen Sie im Azure Pricing Calculator für Ihre Region – der größte versteckte Kostentreiber ist nicht der Tier selbst, sondern der Vektor-Index-Speicher (siehe Teil 2).

Was Sie am Ende haben werden

• Einen produktionsreifen Azure-AI-Search-Service in West Europe oder Germany West Central
• Einen Index mit Vektor- und Textfeldern, bereit für Hybrid-Suche
• Automatische Embedding-Erzeugung per Integrated Vectorization gegen Azure OpenAI
• Eine Hybrid-Query, die Volltext, Vektor und Semantic Ranker kombiniert
• Eine Infrastructure-as-Code-Basis mit Terraform, die Sie versionieren und im Disaster Recovery wiederherstellen können
• Die Grundlage, um Azure OpenAI „On Your Data“ oder einen eigenen RAG-Stack auf Ihre Unternehmensdokumente zu setzen

Wichtig: Azure AI Search speichert und durchsucht Ihre Dokumente, es generiert keine Antworten. Die Antwort erzeugt ein Sprachmodell, dem Sie die gefundenen Passagen als Kontext mitgeben.

Voraussetzungen

Bevor wir starten, brauchen Sie:

• Azure-Abonnement mit Rechten zum Anlegen von Ressourcen (Contributor auf Subscription- oder Resource-Group-Ebene reicht)
• Einen Azure-OpenAI-Zugang im selben Tenant (für Embeddings, z.B. text-embedding-3-large)
• Terraform lokal installiert (mindestens 1.7)
• Azure CLI installiert und mit az login authentifiziert
• curl und jq für die REST-Aufrufe gegen den Such-Service
• Grundkenntnisse Kommandozeile, Azure, JSON

Zeitaufwand: 2-3 Stunden für die komplette Ersteinrichtung inklusive erstem indexierten Datenbestand.

Teil 1: Such-Infrastruktur mit Terraform

Wir deployen den Such-Service als Code. Das hat den Vorteil, dass Sie Tier, Replicas und Partitionen versioniert haben und eine zweite Umgebung (Staging) per terraform apply in Minuten hochziehen.

1.1 Terraform-Dateien anlegen

providers.tf – ersetzen Sie SUBSCRIPTION_ID_HIER mit Ihrer Subscription-ID (az account show --query id -o tsv):

variable "subscription_id" {
  default = "SUBSCRIPTION_ID_HIER"
}

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=4.37.0"
    }
  }
}

provider "azurerm" {
  features {}
  subscription_id = var.subscription_id
}

main.tf – der Such-Service plus ein Azure-OpenAI-Embedding-Deployment, das wir später für die Integrated Vectorization brauchen:

variable "location" { default = "westeurope" }

resource "azurerm_resource_group" "main" {
  name     = "rg-ai-search"
  location = var.location
}

# Azure AI Search Service
resource "azurerm_search_service" "main" {
  name                = "search-pexon-demo"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location

  sku             = "basic"   # free | basic | standard | standard2 | standard3 | storage_optimized_l1 | storage_optimized_l2
  replica_count   = 1         # Query-Durchsatz + SLA (ab 2 Replicas Lese-SLA, ab 3 auch Schreib-SLA)
  partition_count = 1         # Storage + Index-Größe

  semantic_search_sku = "standard"  # aktiviert den Semantic Ranker; "free" für Test, "standard" für Produktion

  # Managed Identity, damit Search ohne Keys auf Azure OpenAI und Blob Storage zugreifen kann
  identity {
    type = "SystemAssigned"
  }

  # In Produktion: Public-Zugang aus, Zugriff nur über Private Endpoint
  public_network_access_enabled = true
  local_authentication_enabled  = true   # in Produktion auf false und reine Entra-ID-Auth nutzen
}

# Azure OpenAI für Embeddings
resource "random_string" "suffix" {
  length  = 6
  special = false
  upper   = false
}

resource "azurerm_cognitive_account" "openai" {
  name                  = "openai-${random_string.suffix.result}"
  location              = azurerm_resource_group.main.location
  resource_group_name   = azurerm_resource_group.main.name
  kind                  = "OpenAI"
  sku_name              = "S0"
  custom_subdomain_name = "openai-${random_string.suffix.result}"
}

resource "azurerm_cognitive_deployment" "embeddings" {
  name                 = "text-embedding-3-large"
  cognitive_account_id = azurerm_cognitive_account.openai.id

  model {
    format  = "OpenAI"
    name    = "text-embedding-3-large"
    version = "1"
  }

  sku {
    name     = "Standard"
    capacity = 120   # = 120.000 TPM (Tausend Tokens/Minute) - beim initialen Full-Indexing der Engpass
  }
}

# Outputs
output "search_endpoint"  { value = "https://${azurerm_search_service.main.name}.search.windows.net" }
output "search_admin_key" { value = azurerm_search_service.main.primary_key; sensitive = true }
output "openai_endpoint"  { value = azurerm_cognitive_account.openai.endpoint; sensitive = true }
output "openai_key"       { value = azurerm_cognitive_account.openai.primary_access_key; sensitive = true }

Tier im Blick behalten: Der Basic-Tier kostet rund 74 USD pro Search Unit und Monat, bietet 15 GB Storage pro Partition und ist mit bis zu drei Replicas SLA-fähig. Das reicht für die meisten Mittelstands-RAG-Anwendungen mit einigen hunderttausend Dokumenten – vorausgesetzt, der Vektor-Index-Speicher (eigenes Quota, siehe Teil 2) passt. Erst bei großen Vektor-Beständen (zweistellige Millionen Chunks) oder hohem Query-Durchsatz brauchen Sie Standard S1/S2/S3.

1.2 Infrastruktur deployen

terraform init
terraform plan  -out=tf.plan
terraform apply tf.plan

Nach 2-4 Minuten steht der Service. Notieren Sie sich die Werte:

terraform output -raw search_endpoint
terraform output -raw search_admin_key
terraform output -raw openai_endpoint
terraform output -raw openai_key

Rollenzuweisung statt Keys: Der sauberste Weg ist, der System-Managed-Identity des Such-Service zwei Rollen zu geben – Cognitive Services OpenAI User auf dem Azure-OpenAI-Konto (für den Vectorizer) und Storage Blob Data Reader auf dem Storage Account (für den Indexer). Ohne die Blob-Rolle schlägt der Indexer später beim Lesen der Dokumente fehl – ein häufiger und schwer zu findender Fehler.

SEARCH_PRINCIPAL=$(az search service show --name search-pexon-demo 
  --resource-group rg-ai-search --query identity.principalId -o tsv)

# Rolle 1: Vectorizer-Zugriff auf Azure OpenAI
az role assignment create 
  --assignee "$SEARCH_PRINCIPAL" 
  --role "Cognitive Services OpenAI User" 
  --scope $(az cognitiveservices account show --name <openai-name> 
            --resource-group rg-ai-search --query id -o tsv)

# Rolle 2: Indexer-Lesezugriff auf den Blob Storage
az role assignment create 
  --assignee "$SEARCH_PRINCIPAL" 
  --role "Storage Blob Data Reader" 
  --scope $(az storage account show --name <storage-name> 
            --resource-group rg-ai-search --query id -o tsv)

Teil 2: Index mit Vektor-Feldern anlegen

Ein Index ist das Schema Ihrer durchsuchbaren Daten. Für Hybrid-Suche brauchen Sie mindestens drei Arten von Feldern: ein Schlüsselfeld, durchsuchbare Textfelder und ein Vektorfeld.

Wir legen den Index per REST-API an. Setzen Sie zuerst zwei Variablen:

export SEARCH_ENDPOINT="https://search-pexon-demo.search.windows.net"
export SEARCH_KEY="<search_admin_key aus Schritt 1.2>"
export API_VERSION="2024-07-01"   # letzte Stable mit GA-Vektor & Integrated Vectorization; aktuelle Stable Stand 2026: 2026-04-01

Index-Definition index.json. Beachten Sie die drei Blöcke: fields (das Schema), vectorSearch (Algorithmus + Vectorizer) und semantic (Konfiguration für den Semantic Ranker):

{
  "name": "dokumente",
  "fields": [
    { "name": "id",      "type": "Edm.String", "key": true, "filterable": true },
    { "name": "title",   "type": "Edm.String", "searchable": true, "analyzer": "de.microsoft" },
    { "name": "content", "type": "Edm.String", "searchable": true, "analyzer": "de.microsoft" },
    { "name": "source",  "type": "Edm.String", "filterable": true, "facetable": true },
    { "name": "groups",  "type": "Collection(Edm.String)", "filterable": true },
    {
      "name": "contentVector",
      "type": "Collection(Edm.Single)",
      "searchable": true,
      "dimensions": 3072,
      "vectorSearchProfile": "hnsw-profile"
    }
  ],
  "vectorSearch": {
    "algorithms": [
      {
        "name": "hnsw-config",
        "kind": "hnsw",
        "hnswParameters": { "m": 4, "efConstruction": 400, "efSearch": 500, "metric": "cosine" }
      }
    ],
    "compressions": [
      {
        "name": "scalar-quant",
        "kind": "scalarQuantization",
        "rerankWithOriginalVectors": true
      }
    ],
    "vectorizers": [
      {
        "name": "azure-openai-vectorizer",
        "kind": "azureOpenAI",
        "azureOpenAIParameters": {
          "resourceUri": "https://openai-xxxxx.openai.azure.com",
          "deploymentId": "text-embedding-3-large",
          "modelName": "text-embedding-3-large"
        }
      }
    ],
    "profiles": [
      {
        "name": "hnsw-profile",
        "algorithm": "hnsw-config",
        "vectorizer": "azure-openai-vectorizer",
        "compression": "scalar-quant"
      }
    ]
  },
  "semantic": {
    "configurations": [
      {
        "name": "semantic-config",
        "prioritizedFields": {
          "titleField": { "fieldName": "title" },
          "prioritizedContentFields": [ { "fieldName": "content" } ]
        }
      }
    ]
  }
}

Drei Punkte, an denen Setups regelmäßig scheitern:

• dimensions muss exakt zum Embedding-Modell passen. text-embedding-3-large liefert 3072 Dimensionen, text-embedding-3-small und ada-002 jeweils 1536. Falscher Wert = der Index nimmt keine Vektoren an.
• Der vectorizer im Index erlaubt Vektor-Queries mit reinem Text. Ohne ihn müssten Sie bei jeder Suchanfrage selbst erst ein Embedding erzeugen. Mit ihm schickt Search den Suchtext intern an Azure OpenAI.
• Der deutsche Analyzer (de.microsoft) sorgt für korrektes Stemming („Maschinen“ findet „Maschine“). Ohne ihn ist die BM25-Komponente deutlich schwächer.

Der versteckte Kostenhebel: Vektor-Speicher und Quantization

Der größte Sizing-Fehler bei Azure AI Search ist, nur auf den Gesamt-Storage zu schauen. Vektoren liegen in einem eigenen Vektor-Index mit eigenem Quota pro Partition. Ein 3072-dimensionaler Vektor in float32 belegt rund 12 KB – und beim Chunking wird aus einem Dokument schnell ein Dutzend Chunks und damit ein Dutzend Vektoren. Bei hunderttausenden Chunks ist der Vektor-Index, nicht der Dokument-Storage, der limitierende Faktor.

Deshalb der compressions-Block oben: Scalar Quantization (int8) reduziert den Vektor-Speicher um rund 75 % bei minimalem Recall-Verlust. Mit rerankWithOriginalVectors: true werden die Top-Treffer am Ende gegen die unkomprimierten Originale nachbewertet, sodass die Qualität praktisch erhalten bleibt. In Produktion mit 3072-dim ist Quantization fast immer die richtige Wahl – und der größte Hebel, um auf einem kleineren (günstigeren) Tier zu bleiben.

Die HNSW-Parameter steuern den Trade-off zwischen Qualität, Speicher und Geschwindigkeit: m (Anzahl der Kanten pro Knoten, Default 4, Max 10), efConstruction (Default 400) und efSearch (Default 500), Distanzmetrik standardmäßig cosine. Für kleine Bestände oder genauigkeitskritische Fälle können Sie statt HNSW (approximativ) auch exhaustiveKnn (100 % Recall, teurer) konfigurieren oder pro Query mit "exhaustive": true erzwingen. m: 8-10 erhöht die Recall-Qualität bei großen Beständen auf Kosten von Speicher.

Index anlegen:

curl -X PUT "$SEARCH_ENDPOINT/indexes/dokumente?api-version=$API_VERSION" 
  -H "Content-Type: application/json" 
  -H "api-key: $SEARCH_KEY" 
  -d @index.json

Teil 3: Daten indexieren – Integrated Vectorization vs. Push-API

Es gibt zwei Wege, Dokumente in den Index zu bekommen:

Variante A: Integrated Vectorization (der empfohlene Weg)

Das ist die Funktion, die Azure AI Search von einer reinen Vektordatenbank abhebt. Integrated Vectorization erzeugt Embeddings automatisch beim Indexieren über ein Skillset und hält sie bei Dokumentänderungen via Change Detection synchron – ohne eigene Embedding-Pipeline. Sie brauchen drei Objekte: eine Data Source, ein Skillset und einen Indexer.

Data Source (hier: Azure Blob Storage, Auth über Managed Identity per ResourceId):

curl -X POST "$SEARCH_ENDPOINT/datasources?api-version=$API_VERSION" 
  -H "Content-Type: application/json" -H "api-key: $SEARCH_KEY" 
  -d '{
    "name": "blob-dokumente",
    "type": "azureblob",
    "credentials": { "connectionString": "ResourceId=/subscriptions/.../storageAccounts/..." },
    "container": { "name": "dokumente" }
  }'

Skillset mit Split-Skill (Chunking) und Embedding-Skill:

curl -X POST "$SEARCH_ENDPOINT/skillsets?api-version=$API_VERSION" 
  -H "Content-Type: application/json" -H "api-key: $SEARCH_KEY" 
  -d '{
    "name": "skillset-embeddings",
    "skills": [
      {
        "@odata.type": "#Microsoft.Skills.Text.SplitSkill",
        "textSplitMode": "pages",
        "maximumPageLength": 2000,
        "pageOverlapLength": 200,
        "inputs":  [ { "name": "text", "source": "/document/content" } ],
        "outputs": [ { "name": "textItems", "targetName": "chunks" } ]
      },
      {
        "@odata.type": "#Microsoft.Skills.Text.AzureOpenAIEmbeddingSkill",
        "resourceUri": "https://openai-xxxxx.openai.azure.com",
        "deploymentId": "text-embedding-3-large",
        "modelName": "text-embedding-3-large",
        "dimensions": 3072,
        "context": "/document/chunks/*",
        "inputs":  [ { "name": "text", "source": "/document/chunks/*" } ],
        "outputs": [ { "name": "embedding", "targetName": "vector" } ]
      }
    ]
  }'

Indexer, der alles verbindet und auf einen Zeitplan legt:

curl -X POST "$SEARCH_ENDPOINT/indexers?api-version=$API_VERSION" 
  -H "Content-Type: application/json" -H "api-key: $SEARCH_KEY" 
  -d '{
    "name": "indexer-dokumente",
    "dataSourceName": "blob-dokumente",
    "skillsetName": "skillset-embeddings",
    "targetIndexName": "dokumente",
    "schedule": { "interval": "PT2H" }
  }'

Ab jetzt zieht der Indexer alle zwei Stunden neue und geänderte Dokumente aus dem Blob Storage, zerlegt sie, erzeugt Embeddings und schreibt sie in den Index – ohne eine Zeile Pipeline-Code von Ihnen.

Zwei Praxis-Hinweise: Indexer haben eine tier-abhängige maximale Laufzeit. Bei großen Blob-Beständen kann der erste Full-Index-Lauf in ein Timeout laufen – dann in Batches indexieren oder den Lauf mehrfach anstoßen (der Indexer setzt am letzten Stand auf). Und die Chunk-Größe ist eine Stellschraube, kein Set-and-forget: 2000 Zeichen mit 200 Zeichen Overlap ist ein guter Startwert für Fließtext. Bei strukturierten Dokumenten (Tabellen, Stücklisten, Verträge mit Klauseln) lohnt es sich zu tunen – zu große Chunks verwässern die Vektor-Relevanz, zu kleine zerreißen den Kontext.

Variante B: Push-API (volle Kontrolle)

Sie erzeugen die Embeddings in Ihrer eigenen Anwendung und schieben fertige Dokumente in den Index. Geeignet, wenn Ihre Daten ohnehin durch eine eigene Verarbeitungspipeline laufen.

curl -X POST "$SEARCH_ENDPOINT/indexes/dokumente/docs/index?api-version=$API_VERSION" 
  -H "Content-Type: application/json" 
  -H "api-key: $SEARCH_KEY" 
  -d '{
    "value": [
      {
        "@search.action": "upload",
        "id": "doc-001",
        "title": "Wartungshandbuch Anlage 4",
        "content": "Die Hydraulikpumpe ist alle 5000 Betriebsstunden zu prüfen ...",
        "source": "confluence",
        "groups": ["instandhaltung", "werk-nord"],
        "contentVector": [0.0123, -0.0456, 0.0789, "... 3072 Werte ..."]
      }
    ]
  }'

Teil 4: Hybrid-Suche in Azure AI Search – BM25 + Vektor + Semantic Ranker

Jetzt der Teil, der den Unterschied macht. Eine reine Vektorsuche scheitert an exakten Begriffen – Produktnummern, Eigennamen, Fehlercodes. Eine reine Volltextsuche scheitert an Bedeutung – „Pumpe macht Geräusche“ findet nicht „Hydraulikaggregat erzeugt Vibrationen“. Hybrid macht beides parallel und fusioniert.

Eine Hybrid-Suche in Azure AI Search kombiniert in einer Query vier Stufen:

curl -X POST "$SEARCH_ENDPOINT/indexes/dokumente/docs/search?api-version=$API_VERSION" 
  -H "Content-Type: application/json" -H "api-key: $SEARCH_KEY" 
  -d '{
    "search": "Wartungsintervall Hydraulikpumpe Anlage 4",
    "vectorQueries": [
      {
        "kind": "text",
        "text": "Wartungsintervall Hydraulikpumpe Anlage 4",
        "fields": "contentVector",
        "k": 50
      }
    ],
    "queryType": "semantic",
    "semanticConfiguration": "semantic-config",
    "top": 5,
    "select": "title,content,source"
  }'

Was hier passiert, in der Reihenfolge:

1. BM25-Volltextsuche auf search läuft über die Textfelder.
2. Vektorsuche auf vectorQueries – "kind": "text" heißt: der Index-Vectorizer erzeugt das Embedding des Suchtexts selbst. Sie schicken kein Embedding mit.
3. RRF-Fusion mischt beide Trefferlisten zu einem Ranking. Ein Dokument, das in beiden Listen weit oben steht, gewinnt.
4. Semantic Ranker (queryType: semantic) nimmt die Top-50-Treffer der Fusion und bewertet sie mit einem Microsoft-Sprachmodell nach echter Relevanz zur Frage neu.

Setzen Sie bei Hybrid-Suche mit Semantic Ranking immer "k": 50 in der Vektor-Query – der Semantic Ranker nimmt maximal 50 Treffer als Input, ein kleinerer Wert verschenkt Reranking-Qualität.

Diese Vierfach-Kombination – BM25 + Vektor + RRF + Semantic Ranker – ist in der Praxis die stärkste Standardkonfiguration. In Microsofts eigenen Benchmarks und in unseren Kundenprojekten liefert sie spürbar bessere Top-3-Treffer als jede Einzelmethode, gerade bei deutschsprachigen Fachdokumenten.

Zwei Punkte, die Architekten einplanen sollten: "kind": "text" bedeutet einen synchronen Embedding-Call an Azure OpenAI pro Suchanfrage – das addiert Latenz (typisch im zweistelligen bis niedrigen dreistelligen Millisekunden-Bereich) und belastet Ihr Azure-OpenAI-Token-Quota. Und der Semantic Ranker wird separat abgerechnet (im standard-Modus pro 1000 Anfragen, erste 1000/Monat frei).

Teil 5: Azure AI Search als RAG-Backend anbinden

Sie haben jetzt ein funktionierendes Retrieval. Der letzte Schritt ist, die Treffer an ein Sprachmodell zu geben, das daraus eine Antwort formuliert. Zwei Wege:

Der schnelle Weg – Azure OpenAI „On Your Data“: In Azure AI Foundry verbinden Sie ein Chat-Deployment direkt mit Ihrem Such-Index. Microsoft übernimmt Retrieval, Prompt-Konstruktion und Zitate. Gut für ein internes Wissens-Chat ohne eigenen Code.

Der kontrollierte Weg – eigener RAG-Stack: Sie rufen die Such-API selbst auf, bauen den Prompt zusammen und schicken ihn an Azure OpenAI. Mehr Aufwand, aber volle Kontrolle über Prompt, Filterung und Zitatformat – siehe auch unsere RAG-Plattform-Beratung.

from openai import AzureOpenAI
import requests

# 1. Retrieval gegen Azure AI Search
hits = requests.post(
    f"{SEARCH_ENDPOINT}/indexes/dokumente/docs/search?api-version=2024-07-01",
    headers={"api-key": SEARCH_KEY, "Content-Type": "application/json"},
    json={
        "search": frage,
        "vectorQueries": [{"kind": "text", "text": frage, "fields": "contentVector", "k": 50}],
        "queryType": "semantic",
        "semanticConfiguration": "semantic-config",
        "top": 5,
        "select": "title,content,source",
    },
).json()["value"]

kontext = "nn".join(f"[{h['source']}] {h['content']}" for h in hits)

# 2. Generierung mit Azure OpenAI
client = AzureOpenAI(azure_endpoint=OPENAI_ENDPOINT, api_key=OPENAI_KEY, api_version="2024-12-01-preview")
antwort = client.chat.completions.create(
    model="gpt-4.1",
    messages=[
        {"role": "system", "content": "Antworte nur auf Basis des Kontexts. Zitiere die Quelle in eckigen Klammern."},
        {"role": "user", "content": f"Kontext:n{kontext}nnFrage: {frage}"},
    ],
)
print(antwort.choices[0].message.content)

Document-Level Security: nur sehen, was man darf

Der entscheidende Hebel für Datenschutz steckt in Schritt 1: Filtern Sie die Suche auf die Dokumente, die der angemeldete Nutzer sehen darf. Dann bekommt das Sprachmodell nie Inhalte zu Gesicht, die der Nutzer nicht sehen dürfte – der häufigste und teuerste Fehler in unsauber gebauten RAG-Systemen.

Speichern Sie dazu pro Dokument die berechtigten Entra-ID-Gruppen im filterbaren Feld groups und setzen Sie bei jeder Suche einen Filter auf die Gruppen des angemeldeten Nutzers:

{
  "search": "...",
  "vectorQueries": [ { "kind": "text", "text": "...", "fields": "contentVector", "k": 50 } ],
  "filter": "groups/any(g: search.in(g, 'instandhaltung,werk-nord'))",
  "queryType": "semantic",
  "semanticConfiguration": "semantic-config",
  "top": 5
}

Die Filterung passiert im Such-Service, bevor Treffer überhaupt an das Sprachmodell gehen. Azure AI Search bietet dafür inzwischen auch native Document-Level Permissions mit ACL-Feldern und Entra-ID-Integration.

Agentic Retrieval und Foundry IQ – was 2026 neu ist

Zwei Erweiterungen, die seit 2026 produktiv nutzbar sind und die Architektur oben ergänzen:

Agentic Retrieval ist eine Azure-AI-Search-Funktion, die eine Nutzerfrage per Sprachmodell in mehrere Subqueries zerlegt, diese parallel ausführt und die Teilergebnisse zu einer Antwort zusammenführt. Statt „Was kostet Wartung und welche Intervalle gelten bei Anlage 4 und 7?“ in einer schwachen Einzelsuche zu verarbeiten, splittet die Engine in saubere Teilfragen. Spürbar bessere Trefferqualität bei Mehrteil-Fragen – auf Kosten zusätzlicher LLM-Aufrufe.

Foundry IQ ist die neue Wissensschicht, die Azure AI Search direkt an Azure-AI-Foundry-Agenten anbindet und Connectors zu SharePoint, OneLake und Web-Quellen mitbringt – inklusive automatisch generierter Datenpipelines. Für Unternehmen, die ihr Wissen ohnehin in SharePoint liegen haben, verkürzt das den Weg zum produktiven Wissens-Agenten erheblich.

Unsere Einordnung: Beide Features sind echte Verbesserungen, aber kein Pflichtprogramm. Eine sauber gebaute Hybrid-Suche mit Semantic Ranker (Teil 4) deckt den Großteil der Anwendungsfälle ab. Agentic Retrieval lohnt sich, wenn Ihre Nutzer komplexe Mehrteil-Fragen stellen; Foundry IQ, wenn SharePoint Ihre primäre Wissensquelle ist.

Wann sich Azure AI Search lohnt – und wann nicht

Unsere klare Empfehlung nach Kundenprojekten in Versicherung, Fertigung und Energie:

Lohnt sich: sobald Sie mehrere Datenquellen anbinden, Zugriffssteuerung pro Nutzergruppe brauchen, Datenresidenz in der EU einhalten müssen oder ohnehin auf Azure OpenAI setzen. Die Integrated Vectorization spart Ihnen die komplette Embedding-Pipeline, der Semantic Ranker hebt die Trefferqualität, und Sie bleiben in Ihrem Azure-Tenant mit Ihren Audit-Logs.

Lohnt sich nicht für eine einzelne kleine Anwendung mit wenigen tausend Dokumenten ohne Compliance-Anforderungen. Dann ist pgvector neben Ihrer bestehenden Postgres günstiger und schneller aufgesetzt. Auch wenn Sie eine reine semantische Ähnlichkeitssuche ohne Volltext-Komponente brauchen, ist eine schlanke Vektordatenbank möglicherweise die einfachere Wahl – der Mehrwert von Azure AI Search liegt gerade in der Kombination der Methoden.

Pexon Consulting

Sie wollen wissen, wie das konkret für Ihr Unternehmen aussehen kann?

Jetzt persönliche Beratung vereinbaren – Kostenfreie Erstberatung

Häufig gestellte Fragen

Was ist Azure AI Search?

Azure AI Search ist eine vollständig gemanagte Such- und Retrieval-Plattform (PaaS) von Microsoft Azure. Sie kombiniert Volltextsuche (BM25), Vektorsuche (HNSW) und KI-gestütztes Semantic Reranking in einem Dienst und dient typischerweise als Retrieval-Backend für RAG-Anwendungen. Sie hieß bis Ende 2023 Azure Cognitive Search.

Was ist der Unterschied zwischen Azure AI Search und Azure Cognitive Search?

Es ist derselbe Dienst. Microsoft hat Azure Cognitive Search Ende 2023 auf der Microsoft Ignite in Azure AI Search umbenannt, um die KI- und Vektor-Fähigkeiten zu betonen. Ältere Dokumentation, SDKs und Blog-Artikel sprechen noch von „Cognitive Search“ – gemeint ist dasselbe Produkt.

Was kostet Azure AI Search im Monat?

Der Basic-Tier kostet rund 74 USD pro Search Unit und Monat (15 GB Storage pro Partition, bis 3 Replicas, SLA-fähig) und reicht für die meisten Mittelstands-RAG-Anwendungen. Dazu kommen der Azure-OpenAI-Token-Verbrauch für Embeddings (einmalig beim Indexieren, danach nur bei Änderungen) und die Semantic-Ranker-Kosten pro 1000 Anfragen, für die es ein kostenloses Monatskontingent (1.000 Anfragen) gibt. Für große Vektor-Bestände skalieren Sie auf Standard S1/S2/S3 – exakte Preise im Azure Pricing Calculator.

Was ist der Unterschied zwischen Azure AI Search und einer Vektordatenbank?

Eine Vektordatenbank (z.B. Qdrant, Weaviate, pgvector) speichert und durchsucht nur Embeddings per Approximate Nearest Neighbor. Azure AI Search ist eine Retrieval-Engine, die zusätzlich BM25-Volltextsuche, RRF-Fusion, Semantic Reranking und gemanagte Indexer für externe Datenquellen mitbringt – und den Betrieb als PaaS übernimmt.

Was ist der Unterschied zwischen Hybrid-Suche und Vektorsuche in Azure AI Search?

Vektorsuche findet semantisch ähnliche Inhalte, scheitert aber an exakten Begriffen wie Produktnummern. Hybrid-Suche kombiniert Vektorsuche (HNSW) mit BM25-Volltextsuche, fusioniert beide Trefferlisten per Reciprocal Rank Fusion (RRF) und liefert dadurch in der Praxis robustere Ergebnisse als jede Einzelmethode.

Welches Embedding-Modell soll ich für Azure AI Search nutzen?

text-embedding-3-large (3072 Dimensionen) liefert die höchste Qualität, text-embedding-3-small und ada-002 (jeweils 1536 Dimensionen) sind günstiger und schneller. Azure AI Search unterstützt Vektorfelder mit bis zu 3072 Dimensionen; bei großen Beständen reduziert Scalar oder Binary Quantization den Speicherbedarf um rund 75 %.

Ist Azure AI Search DSGVO-konform?

Ja, bei Betrieb in einer EU-Region (West Europe oder Germany West Central) mit Microsoft Entra ID, Private Endpoints und Document-Level Security. Die Daten bleiben im eigenen Azure-Tenant, Zugriffe sind über RBAC und Audit-Logs nachvollziehbar. Für Kunden mit strikter Data-Residency-Anforderung ist Germany West Central der sauberste Weg.

Was ist Agentic Retrieval in Azure AI Search?

Agentic Retrieval zerlegt eine komplexe Nutzerfrage per Sprachmodell in mehrere Subqueries, führt diese parallel aus und fasst die Teilergebnisse zusammen. Das verbessert die Trefferqualität bei Mehrteil-Fragen deutlich, kostet aber zusätzliche LLM-Aufrufe.

Wie halte ich die Embeddings synchron, wenn sich Dokumente ändern?

Genau das nimmt Ihnen die Integrated Vectorization ab. Der Indexer erkennt geänderte Dokumente in der Quelle (Change Detection) und aktualisiert die betroffenen Chunks und Vektoren beim nächsten geplanten Lauf automatisch. Bei der Push-API müssen Sie die Synchronisierung selbst bauen – das ist der Hauptgrund, warum wir in fast allen Projekten zur Integrated Vectorization raten.

Funktioniert das auch in Germany West Central statt West Europe?

Ja, setzen Sie location = "germanywestcentral" in main.tf. Achten Sie darauf, dass auch Ihr Azure-OpenAI-Embedding-Deployment in einer Region verfügbar ist, die Sie compliance-seitig akzeptieren.

Nächster Schritt

Sie wollen Azure AI Search als Retrieval-Backend für Ihre Unternehmensdokumente aufsetzen, ohne die typischen Stolpersteine selbst zu erwischen (Chunking-Strategie, Vektor-Quantization, Document-Level Security, Embedding-Dimensionen, Indexer-Scheduling)? Unsere Azure-AI-Search-Beratung hat dieses Setup in unterschiedlichen Varianten bei Kunden in Versicherung, Fertigung und Energie produktiv gestellt und kann es in einem fixen Rahmen bei Ihnen aufbauen – inklusive Anbindung an Azure OpenAI und einen produktionsreifen RAG-Chatbot.

Zum 6-Wochen-Pilotprojekt Generative AI

Pexon RAG auf Azure – Schlüsselfertig statt 20 Edge Cases selbst lösen: Chunking, Hybrid-Tuning, Quantization-Sizing, Document-Level Security, Semantic-Ranker-Kalibrierung. Wir bauen Ihre Retrieval-Plattform auf Azure AI Search auf und binden RAG auf Ihre Unternehmensdokumente an.

Azure AI Search schlüsselfertig → · RAG-Chatbot auf Azure →

Quellen

• Microsoft Learn – Azure AI Search Dokumentation (Hybrid Search, Vector Search, Integrated Vectorization, HNSW-Parameter, Semantic Ranker)
• Azure Pricing Calculator / Azure AI Search Pricing (Tier- und Semantic-Ranker-Preise, Stand Juni 2026)
• Microsoft Ignite 2023 – Ankündigung der Umbenennung Azure Cognitive Search → Azure AI Search

Verwandte Themen