AI Search

AI Search bezeichnet die Sammelkategorie moderner Such-Systeme, die KI-Modelle wie [Embeddings](/insights/glossar/embeddings/), LLM-basiertes Query-Understanding und neuronales Reranking einsetzen, um Relevanz und Verständnis gegenüber klassischer keyword-basierter Volltextsuche (BM25, TF-IDF) zu verbessern. Der Begriff umfasst technische Bausteine ([Vector Search](/insights/glossar/vector-search/), [Semantic Search](/insights/glossar/semantic-search/), [Hybrid Search](/insights/glossar/hybrid-search/), [Reranking](/insights/glossar/reranking/), Query-Expansion) ebenso wie kommerzielle Produkte (Databricks AI Search, Azure AI Search, Vertex AI Search, Elastic AI Search).

Was ist AI Search?

AI Search ist ein Produkt- und Architektur-Frame, keine einzelne Technik. Der Begriff hat sich zwischen 2022 und 2024 durchgesetzt, als Foundation-Model-Embeddings, dichte Retriever und LLM-basierte Reranker den Sprung aus dem Forschungsumfeld in produktive Enterprise-Stacks geschafft haben. Hersteller nutzen ihn als Klammer für die Ablösung oder Erweiterung klassischer Such-Produkte (Elasticsearch, OpenSearch, Solr, Coveo, klassischer Sharepoint-Search) durch neuronale Komponenten. Was ein System zu einem AI-Search-System macht, ist die Kombination aus mehreren Bausteinen und die Integration mit einer Governance-Ebene.

Der typische Aufbau folgt einer Retrieval-Pipeline mit vier Stufen. Erstens ein Query-Understanding-Schritt: Ein Sprachmodell oder ein spezialisierter Klassifikator normalisiert die Nutzeranfrage, extrahiert Entitäten, erkennt die Intent-Klasse und übersetzt sie gegebenenfalls in eine strukturierte Anfrage. Dieser Schritt umfasst [Query-Rewriting](/insights/glossar/query-rewriting/), Query-Expansion, Synonym-Auflösung und in agentischen Varianten auch Query-Decomposition. Zweitens ein Retrieval-Schritt: Ein dichter Retriever (Embeddings-basiert, meist [Vector Search](/insights/glossar/vector-search/) über einen HNSW- oder IVF-PQ-Index) liefert semantisch ähnliche Kandidaten, häufig parallel zu einem lexikalischen Retriever (BM25 über einen invertierten Index). Beide Zweige werden über [Reciprocal Rank Fusion](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf) oder gewichtete Score-Fusion zu einer Kandidatenliste kombiniert ([Hybrid Search](/insights/glossar/hybrid-search/)). Drittens ein Reranking-Schritt: Ein Cross-Encoder oder LLM sortiert die Top-Kandidaten nach ihrer tatsächlichen Relevanz zur Anfrage um. Viertens optional ein Answer-Generation-Schritt: Ein Sprachmodell formuliert eine natürlichsprachliche Antwort mit Quellenverweisen. Diese vierte Stufe verwandelt AI Search in eine [RAG-Pipeline](/insights/glossar/rag/); ohne sie endet AI Search an der Trefferliste.

Der Begriff existiert, weil klassische Volltextsuche bei drei Fragen strukturell schwach ist: Synonyme und Paraphrasen ("Krankmeldung" vs. "Arbeitsunfähigkeitsbescheinigung"), mehrsprachige Anfragen und implizite Intents ("Was passiert wenn X" statt einer Term-Anfrage). Klassische Ranking-Funktionen wie BM25 vergleichen Zeichenketten und Termstatistik im Vokabular, während Bedeutung außerhalb dieser Ebene liegt. Embedding-basierte Retriever schließen diese Lücke, indem sie Anfrage und Dokumente in einen gemeinsamen Bedeutungsraum abbilden. Der Preis ist doppelte Infrastruktur (Embedding-Modell im Serving plus Vektor-Index), eine harte Bindung zwischen Vektoren und Erzeuger-Modell sowie eine strukturelle Schwäche bei exakten Bezeichnern wie Vertragsnummern, Produktcodes oder Ticket-IDs, die im Embedding-Raum verwischen.

Der Produkt-Markt hat sich um diese Architektur herum konsolidiert. Databricks AI Search kombiniert Mosaic AI Vector Search als Retrieval-Engine auf Unity-Catalog-Tabellen mit Genie-Retrieval für strukturierte Daten und positioniert sich als Retrieval-Layer für RAG-Anwendungen auf dem Lakehouse. [Azure AI Search](https://learn.microsoft.com/en-us/azure/search/) (ehemals Cognitive Search) verbindet Volltext-Index, kNN-Vektorsuche, semantisches Ranking und einen "Chat with your data"-Modus in einem Service. Google [Vertex AI Search](https://cloud.google.com/enterprise-search) integriert Retrieval mit Grounding auf Gemini. Elastic AI Search erweitert den bestehenden Elasticsearch-Stack um dichte Retriever, ELSER als Sparse-Encoder und einen "AI Assistant" für natürlichsprachliche Anfragen. AWS OpenSearch bringt Neural Search und Semantic Highlighting als Erweiterungen mit. Daneben stehen Enterprise-Search-Anbieter wie Coveo, Glean und Lucidworks Fusion, die AI-Search-Bausteine in ihren Konnektor-schweren Enterprise-Stacks vereinen. Trotz gleicher Grundarchitektur unterscheiden sich die Produkte in Ingest-Modell, Governance-Bindung (Unity Catalog, Purview, Chronicle), Reranker-Modellen, Multi-Modalität und Antwortgenerierungs-Fähigkeiten deutlich.

Abgrenzung zu Vector Search, Semantic Search, RAG, Enterprise Search und Volltextsuche

Der Begriff wird häufig mit seinen Bausteinen, seinem übergeordneten Anwendungsmuster und seinen Vorläufer-Kategorien vermischt. Die Abgrenzung sitzt jeweils an einer klaren funktionalen Grenze.

Der Unterschied zu [Vector Search](/insights/glossar/vector-search/) ist der zwischen Kategorie und Baustein. Vector Search bezeichnet ein konkretes Verfahren: Approximate Nearest Neighbor Search über einem Vektor-Index, meist mit HNSW oder IVF-PQ. AI Search ist die übergeordnete Produkt- und Architektur-Klasse, die Vector Search als eine Komponente enthält, daneben aber Query-Understanding, Hybrid Fusion, Reranking und optional Answer Generation. Ein reines Vector-Search-Feature auf einer Datenbank erfüllt die AI-Search-Definition erst mit diesen Nachbarstufen. Umgekehrt ist Vector Search der dominierende Retrieval-Baustein moderner AI-Search-Angebote.

Der Unterschied zu [Semantic Search](/insights/glossar/semantic-search/) ist der zwischen Konzept und Kategorie. Semantic Search beschreibt das Anwendungsziel: Retrieval nach Bedeutung, umgesetzt über Embeddings und ANN-Suche. AI Search ist die weiter gefasste Klammer, die Semantic Search enthält und zusätzlich Query-Understanding, Hybrid mit lexikalischen Retrievern, Reranking und Answer-Generation umfasst. Semantic Search ist ein Verfahren; AI Search ist die Produktkategorie, in der dieses Verfahren eingesetzt wird.

Der Unterschied zu [RAG](/insights/glossar/rag/) ist der zwischen Retrieval-Layer und Anwendungsmuster mit Generierung. AI Search endet in der Regel an der Trefferliste: Top-k Kandidaten mit Score, Metadaten und Quellenverweis. RAG (Retrieval-Augmented Generation) setzt darauf auf. Ein Sprachmodell verarbeitet die Kandidaten zu einer natürlichsprachlichen Antwort mit Grounding. Der Übergang ist fließend; viele AI-Search-Produkte bieten inzwischen eine optionale Answer-Generation-Stufe an ("Chat with your data", "AI Assistant") und werden damit selbst zur RAG-Plattform. Konzeptionell bleibt die Trennung nützlich: AI Search ist Retrieval, RAG ist Retrieval-plus-Generation.

Der Unterschied zu [Enterprise Search](/insights/glossar/enterprise-search/) liegt im technologischen Kern und im historischen Bezug. Enterprise Search bezeichnet die ältere Produktkategorie organisationsweiter Suche über Konnektoren zu Sharepoint, Confluence, Fileshares, CRM-Systemen, Wikis und Datenbanken, mit dem Fokus auf Datenintegration, Berechtigungsvererbung und Federated-Ranking. Klassische Enterprise-Search-Produkte (FAST, Autonomy, Vivisimo, Coveo) basierten auf lexikalischen Verfahren und regelbasierter Relevanz. AI Search ist die neuronale Erweiterung dieses Frames. Die Ingest- und Governance-Seite bleibt vergleichbar; der Retrieval-Kern wird durch Embeddings, Reranker und Query-Understanding ersetzt. Anbieter wie Glean, Coveo und Lucidworks positionieren sich heute als "AI-native Enterprise Search"; klassische Enterprise-Search-Produkte modernisieren ihren Retrieval-Layer, um den Anschluss zu halten.

Der Unterschied zu klassischer Volltextsuche liegt in der Repräsentationsebene. Volltextsuche arbeitet über einem invertierten Index und rankt mit BM25 oder TF-IDF über Term-Frequenz und Dokument-Frequenz. Zwei Dokumente mit denselben Wörtern gelten als ähnlich, unabhängig von ihrer Bedeutung. AI Search deckt Bedeutung über Embeddings ab und fällt bei exakten Bezeichnern (Vertragsnummern, Produktcodes) zurück. Produktive AI-Search-Systeme integrieren beide Zweige als Hybrid Search und gewinnen so die Robustheit lexikalischer Verfahren für exakte Treffer bei gleichzeitiger Bedeutungs-Deckung über den dichten Zweig.

Beispiel: AI Search als Retrieval-Layer eines internen Wissensassistenten

Ein mittelständisches Fertigungsunternehmen betreibt einen internen Wissensassistenten für Servicetechniker. Der Dokumentenbestand umfasst rund 45.000 Chunks aus technischen Handbüchern, Service-Anleitungen, Betriebsanleitungen, Wartungsprotokollen und einem CRM-Feed mit 12.000 Support-Ticket-Lösungen. Die Anfragen kommen über ein Chat-Interface auf Tablets in der Werkstatt.

Der Retrieval-Layer läuft auf Databricks AI Search. Alle Chunks liegen als Delta-Tabelle im Unity Catalog mit den Metadaten sprache, maschinen_typ, dokumentklasse und sichtbarkeit. Ein Delta-Sync-Index materialisiert die Vektoren über voyage-3-large (1.024 Dimensionen) in Mosaic AI Vector Search. Ein zweiter Index hält den lexikalischen BM25-Zweig über denselben Text. Zur Query-Zeit fragt ein Techniker: "Fehlercode E-402 am Kompressor, was tun?"

Der Query-Understanding-Schritt erkennt den Fehlercode E-402 als exakten Bezeichner und die Entität Kompressor als Anlagenklasse. Der Retriever läuft zweigleisig. Der lexikalische Zweig findet Chunks, die den exakten Fehlercode enthalten (Handbuch-Seiten, Support-Tickets). Der dichte Zweig findet Chunks, die den Fehlercode nicht enthalten, aber semantisch relevant sind: allgemeine Passagen zu Druckverlust am Kompressor oder Wartungsprotokolle mit demselben Symptombild. Reciprocal Rank Fusion kombiniert beide Trefferlisten zu einer Top-30-Kandidatenliste. Ein Cross-Encoder-Reranker (bge-reranker-v2-m3) sortiert die Top-30 nach Relevanz zur konkreten Frage um und liefert die Top-5 an das Application-Layer. Die Latenz des gesamten Retrieval-Pfads liegt bei etwa 180 Millisekunden.

Die Top-5 dienen einem Sprachmodell (Databricks-hosted Llama 3.3 70B) als Kontext für die Antwortformulierung mit Quellenverweisen. Ab dieser Stufe wird aus AI Search eine RAG-Pipeline. Für die reine Trefferliste (ohne Antwort-Generation, etwa bei Compliance-Anfragen: "Wo steht Regel X im Betriebshandbuch?") stoppt das System an der Reranker-Ausgabe.

Der Betrieb bringt drei typische Aufgaben mit sich. Erstens die Ingest-Synchronisation: Änderungen an den Quelldokumenten müssen über Change Data Feed in den Vektor-Index nachgezogen werden, sonst driften Wissensbasis und Antworten auseinander. Zweitens die Reranker-Wahl: Cross-Encoder-Reranker sind teuer pro Kandidat; die Kandidatenzahl vor dem Reranker ist eine der wichtigsten Tuning-Achsen für Kosten und Antwortqualität. Drittens die Governance-Bindung: Row-Level-Security aus dem Unity Catalog wird als Metadaten-Filter durch die Retrieval-Kette propagiert, damit ein Techniker nur Dokumente sieht, für die sein Team leseberechtigt ist. Vergleichbare Muster laufen produktiv auf Azure AI Search mit Purview-Bindung, auf Vertex AI Search mit Grounding auf Gemini und auf Elastic AI Search mit ELSER als Sparse-Encoder.