AI Search auf Databricks: Wie Retrieval auf Daten aus Unity Catalog aufgebaut wird
Die Kernaussagen auf einen Blick.
- AI Search stellt die Retrieval-Funktionen für RAG-Anwendungen auf Basis von Mosaic AI Vector Search bereit. Die Indizes können direkt auf Tabellen in Unity Catalog aufsetzen und mit deren Daten synchronisiert werden.
- Ein wesentlicher Vorteil ist die direkte Synchronisation zwischen Quelltabelle und Suchindex. Zusätzlich können Berechtigungen und Governance enger mit Unity Catalog verbunden werden.
- Vor der Einführung sollten drei Fragen beantwortet werden: Liegen die relevanten Daten in einer Form vor, die sich sinnvoll über Delta Sync aktualisieren lässt? Deckt die kombinierte semantische und lexikalische Suche die Anforderungen des Anwendungsfalls ab? Wer verantwortet Auswahl, Kosten und spätere Änderungen des Embedding-Modells?
- Für den ersten produktiven RAG-Anwendungsfall bietet sich ein Delta Sync Index mit Hybrid Search als Ausgangspunkt an. Ein externer Vektorspeicher sollte gezielt für Anforderungen wie Multi-Cloud, sehr hohe Last oder spezielles Index-Tuning geprüft werden.
Inhaltsverzeichnis
Vom RAG-Prototyp zum produktiven Retrieval
In vielen Projekten zeigt sich ein ähnlicher Ablauf. Ein Wissensassistent beantwortet im Notebook erste Testfragen. Die Demo überzeugt fachlich. Anschließend muss geklärt werden, wie daraus ein stabiler produktiver Dienst entsteht. Häufig fehlen zu diesem Zeitpunkt noch Synchronisation, Berechtigungen, Monitoring und Betriebsprozesse. Im Pilot wird möglicherweise bereits ein externer Vektorspeicher verwendet. Neue und geänderte Dokumente werden jedoch noch manuell oder über eine provisorische Pipeline aktualisiert. Die Zugriffsrechte auf die Quelldaten sind in Unity Catalog oder dem Quellsystem bereits definiert. Im separaten Vektorspeicher müssen sie häufig erneut abgebildet werden.
Mit mehreren parallelen RAG-Projekten wiederholen sich dieselben Aufgaben. Teams entscheiden sich unabhängig voneinander für unterschiedliche Embedding-Modelle. Auch Datenübernahme und Aktualisierung werden mehrfach implementiert. Zugriffsrechte und Nutzeridentitäten müssen in jedem Projekt erneut geklärt werden. Ein großer Teil der Entwicklungszeit fließt dadurch in Infrastruktur statt in die fachliche Qualität der Anwendung. Datenpipelines und Identitätszuordnung binden erhebliche Engineering-Ressourcen.
AI Search soll diese wiederkehrenden Integrationsaufgaben innerhalb der Databricks-Plattform reduzieren. Die Entscheidung sollte nicht allein als Produktvergleich zwischen Vektordatenbanken geführt werden. Entscheidend ist, ob Daten, Aktualisierung und Governance gut zur bestehenden Unity-Catalog-Architektur passen. Für Anforderungen außerhalb dieses Modells sollte eine externe Lösung gezielt geprüft werden.
Was ist Databricks AI Search?
AI Search stellt Such- und Retrieval-Funktionen für GenAI-Anwendungen auf Daten aus dem Lakehouse bereit. Der typische Anwendungsfall ist Retrieval-Augmented Generation (RAG): Ein Sprachmodell beantwortet eine Frage auf Basis von Dokumenten, die zur Laufzeit aus einem Suchindex geholt und in den Prompt mitgegeben werden. AI Search ist die Retrieval-Schicht, die diese Dokumente liefert. Als Ausgangspunkt dient eine Tabelle in Unity Catalog. Zusätzlich werden Textspalten, Metadatenfelder und eine Embedding-Strategie festgelegt. Databricks erstellt daraus einen Suchindex. Je nach Indextyp kann dieser Index mit Änderungen der Quelltabelle aktualisiert werden. Suchanfragen können semantische und lexikalische Treffer kombinieren. Die gefundenen Inhalte werden anschließend einer RAG-Anwendung oder einem Agenten bereitgestellt. Mögliche Verbraucher sind Agenten, eigene Anwendungen über SDK oder REST sowie SQL-basierte AI-Funktionen.
Die eigentliche Index- und Suchinfrastruktur wird von Mosaic AI Vector Search bereitgestellt. AI Search bündelt darauf aufbauend Indexerstellung, Synchronisation, Embedding und Abfrage. Wie Berechtigungen bei Indexierung und Laufzeit wirken, hängt von der konkreten Architektur und Identität ab und sollte ausdrücklich getestet werden. Microsoft Learn beschreibt AI Search als in die Data Intelligence Platform eingebaute Vektor-Such-Lösung. Wie der Index selbst aufgebaut ist, welche Datentypen er kennt und wie Storage- und Compute-Trennung im Index laufen, klären wir im Überblick zu Vector Search auf Databricks. Bei Delta-Sync-Szenarien entfällt eine zusätzliche Exportpipeline in einen separat betriebenen Vektorspeicher. Der Suchindex bleibt eng an die vorhandenen Lakehouse-Tabellen gekoppelt.
AI Search eignet sich für semantische und lexikalische Suche auf dokumenten- und textorientierten Daten. Nicht abgedeckt werden eine frei konfigurierbare Suchinfrastruktur, allgemeine Datenexploration oder klassische Hochlast-Websuche. Wie sich die Retrieval-Schicht in die übrige GenAI-Strecke einordnet, von Foundation Model APIs bis zum Agent Builder, zeigen wir im Überblick zu künstlicher Intelligenz auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Von der Delta Table zum Endpoint..
AI Search baut auf Mosaic AI Vector Search auf: Quelltabellen und Dokumente werden geparst, per Delta Sync synchronisiert und über REST oder SDK an RAG-Agenten und Chatbots ausgeliefert, alles innerhalb der Unity-Catalog-Governance.
Delta Lake
ParquetDie Indextypen im Überblick
AI Search kennt zwei Indextypen mit klar getrenntem Anwendungsprofil. Die Wahl bestimmt, wer für Aktualisierung und Embedding-Berechnung verantwortlich ist. Sie beeinflusst damit direkt Betriebsaufwand und Flexibilität.
Delta Sync Index wählen, wenn
- Die Quelldaten bereits als Delta-Tabelle in Unity Catalog vorliegen
- Änderungen kontinuierlich oder geplant automatisch in den Index übernommen werden sollen
- Die Embeddings über einen konfigurierten Modellendpoint erzeugt werden sollen
- Ein geringerer Plattformaufwand gegenüber einer selbst betriebenen Indexpipeline gewünscht ist
Direct Vector Access Index wählen, wenn
- Bereits vorhandene Embeddings oder externe Datenquellen eingebunden werden sollen
- Das eigene Team Vektoren selbst über API oder SDK schreiben und aktualisieren will
- Embedding-Modell, Versionierung und Synchronisation in eigener Verantwortung bleiben sollen
- Der größere Gestaltungsspielraum den zusätzlichen Entwicklungs- und Betriebsaufwand rechtfertigt
Für Daten, die bereits als Delta-Tabelle vorliegen, ist Delta Sync häufig der naheliegende Einstieg. Der Vorteil gegenüber einer externen Lösung liegt vor allem in der engeren Integration mit Daten und Plattformbetrieb. Ein Suchendpoint wird mit einer geeigneten Quelltabelle verbunden. Dabei werden Text-, Metadaten- und Embedding-Konfigurationen festgelegt. Microsoft Learn beschreibt das Muster knapp: Mit AI Search lässt sich ein Suchindex direkt aus einer Delta-Tabelle mit eingebetteten Daten und Metadaten erstellen, abgefragt über REST oder SDK. Neue, geänderte und gelöschte Datensätze können abhängig von Quelltabelle und Synchronisationslogik übernommen werden. Eine separate ETL-Pipeline für den Index kann in vielen Fällen entfallen.
Direct Vector Access ist sinnvoll, wenn Embeddings bereits von einer eigenen Pipeline erzeugt werden oder wenn die Daten nicht über eine geeignete Delta-Tabelle bereitgestellt werden können. Das Team übernimmt Schreiben, Aktualisierung und Löschen der Vektoren. Damit liegt die vollständige Synchronisationslogik außerhalb von AI Search. Für klassische Wissens- und Dokumentenanwendungen ist dieser zusätzliche Aufwand häufig nicht notwendig.
Die zentrale Frage lautet daher, ob die Plattform oder das eigene Team die Aktualisierung kontrollieren soll. Wenn keine eigene Embedding- oder Synchronisationslogik benötigt wird, ist Delta Sync meist einfacher.
Warum semantische und lexikalische Suche kombinieren?
Semantische Suche eignet sich gut für beschreibende Anfragen, Synonyme und inhaltlich ähnliche Formulierungen. Bei exakten IDs, Produktcodes oder seltenen Fachbegriffen kann sie jedoch schwächer sein. In Unternehmensanwendungen treten beide Arten von Suchanfragen regelmäßig auf. Ein Nutzer sucht möglicherweise nach einer konkreten Vertragsnummer statt nach einer thematischen Umschreibung.
Hybrid Search kombiniert semantische Ähnlichkeit mit klassischer Stichwortsuche. Die Ergebnisse beider Verfahren werden in einer gemeinsamen Trefferliste zusammengeführt. Beide Sucharten können innerhalb desselben AI-Search-Index genutzt werden. Die Gewichtung und Rankinglogik werden von der Plattform übernommen. Eine separate Elasticsearch- oder BM25-Komponente ist für viele RAG-Anwendungen nicht erforderlich.
Wann welche Strategie passt, hängt am Anfrageprofil:
Reine semantische Suche
Kann ausreichen, wenn Anfragen überwiegend in natürlicher Sprache formuliert sind und keine exakten Schlüsselbegriffe enthalten. Beispiel: ein interner Chatbot auf einem Onboarding-Leitfaden.
Hybrid Search
Besonders sinnvoll, wenn exakte Bezeichnungen, Codes und Namen gemeinsam mit semantischer Ähnlichkeit relevant sind. Beispiel: ein Vertragsassistent, der auch über eine Referenznummer findet.
Reine Stichwortsuche
Reicht für einfache Lookups, stößt bei semantisch formulierten Fragen aber schnell an Grenzen.
Die integrierte Hybrid Search kann den Aufwand gegenüber einer Kombination aus externer Vektorsuche und zusätzlicher Volltextsuche deutlich reduzieren. Eine selbst gebaute Kombination verursacht zusätzliche Implementierung, Tests und Betrieb.
Wie wählt man das Embedding-Modell?
Die Wahl des Embedding-Modells hat häufig großen Einfluss auf Recall, Mehrsprachigkeit und fachliche Suchqualität. Grundsätzlich lassen sich drei Bereitstellungswege unterscheiden.
Foundation Model APIs
Ein von Databricks bereitgestellter Embedding-Endpoint dient als einfacher Ausgangspunkt. Generische mehrsprachige Modelle reichen für viele Standardanwendungen, müssen aber auf eigenen Daten getestet werden.
Unity AI Gateway
Externe Embedding-Modelle lassen sich zentral über Zugangsdaten und Kosten steuern. Die eigentliche Datenverarbeitung bleibt vom Providervertrag abhängig.
Eigener Endpoint
Ein eigenes oder feinabgestimmtes Modell über Model Serving lohnt sich bei stark domänenspezifischer Fachsprache. Das erhöht aber den Aufwand für Training, Versionierung und Re-Indexierung.
Vor dem produktiven Aufbau eines großen Index sollte ein belastbarer Vergleich mehrerer Embedding-Modelle erfolgen. Viele unterschiedliche Embedding-Modelle erhöhen Kosten, Betriebsaufwand und Komplexität bei späteren Änderungen. Ein generisches Plattformmodell ist häufig ein sinnvoller Ausgangspunkt. Ein eigenes Modell sollte erst eingesetzt werden, wenn eine Evaluation einen klaren Qualitätsvorteil zeigt.
Wie greifen Berechtigungen bei AI Search?
Die mögliche Integration mit Unity Catalog ist ein wichtiger Unterschied zu getrennt betriebenen Vektorspeichern.
AI-Search-Objekte lassen sich in die Unity-Catalog-Governance einbinden. Berechtigungen, Ownership und Auditinformationen können zentral verwaltet werden. Die Identität, unter der der Index erstellt und abgefragt wird, muss in der Zielarchitektur eindeutig festgelegt sein.
Bei externen Vektorspeichern müssen Berechtigungen häufig separat synchronisiert oder in Metadaten und Filterlogik abgebildet werden. Dadurch steigt der Aufwand für Betrieb, Nachweise und Fehleranalyse.
Eine vorhandene und nutzbare Berechtigungsstruktur kann den Weg in den produktiven Betrieb verkürzen. Wie weit bestehende Berechtigungen wiederverwendet werden können, sollte pro Use Case und Zugriffsmuster geprüft werden. Wie die Berechtigungs- und Lineage-Mechanik im Katalog selbst aufgebaut ist, schauen wir uns im Überblick zu Unity Catalog auf Databricks genauer an.
Welche Anwendungen nutzen AI Search?
Ein AI-Search-Index kann von unterschiedlichen Anwendungen genutzt werden. Welche Use Cases in die Brick-Form passen und wann ein Custom-Agent besser geeignet ist, klären wir im Überblick zu Agent Bricks auf Databricks. Wie die RAG-Strecke gegen reines Prompt-Engineering steht, klären wir im Überblick zu Retrieval-Augmented Generation auf Databricks. Wie AI Functions Retrieval direkt in SQL-Pipelines einbinden, zeigen wir im verlinkten Überblick.
Agent Bricks Knowledge Assistant
Vorkonfigurierte Agentenbausteine vereinfachen Entwicklung und Evaluation standardisierter Wissensassistenten. Das ist ein schneller Einstieg für klar abgegrenzte Standardfälle.
Eigene RAG-Anwendungen
Über REST und SDK abrufbar. Die nachgelagerte Anwendung entscheidet, wie Treffer gefiltert, gerankt und an ein Sprachmodell übergeben werden.
AI Functions in SQL
SQL-basierte Funktionen integrieren Retrieval direkt in tabellarische Datenprozesse. Das eignet sich für einfache Batch- und Anreicherungsaufgaben ohne eigene Anwendungsschicht.
Mehrere Anwendungen können grundsätzlich denselben Index wiederverwenden. Ob ein gemeinsamer Index sinnvoll ist, hängt von Datenumfang, Berechtigungen, Suchprofil und Verantwortlichkeiten ab. Eine gemeinsame Datenquelle und Aktualisierungslogik können den Betriebsaufwand reduzieren.
Wie bleibt die Vector Search aktuell?
Die direkte Kopplung an Delta-Tabellen ist ein zentraler Unterschied zu separat betriebenen Vektorspeichern. Drei Punkte sind vor der produktiven Nutzung relevant. Externe Quellen müssen dafür zunächst zuverlässig in eine geeignete Tabelle oder eigene Upsert-Pipeline überführt werden. Der Ingest kann beispielsweise über Lakeflow, Auto Loader oder eine andere ETL-Lösung erfolgen.
Synchronisation
Kontinuierlich oder geplant, je nach Datenvolumen und Aktualitätsanforderung. Ein kontinuierlicher Modus reduziert die Verzögerung zwischen Tabellenänderung und Indexaktualisierung.
Embedding-Berechnung
Übernimmt bei verwalteten Delta-Sync-Indizes die Plattform. Neue oder veränderte Inhalte verursachen zusätzliche Embedding- und Indexierungskosten.
Externe Quellen
Müssen zunächst zuverlässig in eine geeignete Tabelle oder eigene Upsert-Pipeline überführt werden, bevor die Indexaktualisierung automatisiert werden kann.
Wann braucht es eine externe Vector Search?
Mehrere Anforderungen können für eine spezialisierte externe Lösung sprechen.
Multi-Cloud ohne Databricks
Bei bewusst cloudübergreifenden Anwendungen ohne zentrale Databricks-Plattform kann ein neutraler Vektordienst einfacher sein. AI Search ist an die Databricks-Region gebunden.
Sehr hohe Last
Bei sehr hoher öffentlicher Last oder extrem niedrigen Latenzanforderungen kann eine spezialisierte Suchinfrastruktur mehr Kontrolle bieten. Das sollte durch Lasttests und konkrete SLAs belegt werden.
Spezifische Index-Tunings
Spezielle Anforderungen an Indexparameter, Distanzmetriken oder Filterausführung können einen externen Store rechtfertigen.
pgvector für Postgres
Bei einer überwiegend Postgres-basierten Anwendung kann pgvector eine einfache und gut integrierte Lösung sein.
Eine Mischarchitektur kann sinnvoll sein, wenn die Verantwortungsgrenzen zwischen Lakehouse- und externen Workloads klar bleiben. Zwei parallele Retrievalsysteme für dieselben Daten erhöhen dagegen Synchronisations-, Test- und Governance-Aufwand.
Was AI Search nicht abdeckt
Zwei Abgrenzungen sind dabei besonders wichtig. Wie sich die beiden Such-Welten zueinander verhalten, schauen wir uns im Überblick zu Unity Catalog auf Databricks an.
Keine Hochlast-Volltextplattform
Für öffentliche Produktsuche, Loganalyse oder klassische Website-Suche sind spezialisierte Suchsysteme oft besser skalierbar und flexibler. Hybrid Search ist vor allem auf Retrieval für GenAI- und Wissensanwendungen ausgerichtet.
Kein Ersatz für Datenkatalog-Suche
Für die Suche nach Tabellen, Dashboards oder Datenprodukten bleiben Unity Catalog und die entsprechenden Databricks-Oberflächen zuständig.
Diese Grenzen helfen dabei, das Produkt für die passenden Anwendungsfälle einzusetzen.
Was kostet AI Search?
Die Gesamtkosten bestehen im Wesentlichen aus Endpoint-Compute, Embedding-Berechnung und Indexspeicherung. Databricks dokumentiert die Tarife für AI Search Standard sowie für Storage-optimierte Varianten im AI-Search-Preisblatt.
Endpoint-Compute
Laufende Compute-Kosten je nach Endpoint-Typ, Region, Last und Indexgröße. Ob mehrere Indizes auf einem Endpoint wirtschaftlich gebündelt werden können, sollte anhand der aktuellen Plattformgrenzen geprüft werden.
Embedding-Berechnung
Neue oder geänderte Inhalte müssen in Vektoren umgerechnet werden. Vollständige Re-Indexierungen können bei großen Korpora erhebliche Kosten verursachen.
Speicher & Synchronisation
Zusätzliche Speicher- und Synchronisationskosten. Unterschiedliche Endpoint-Klassen können andere Kosten-, Speicher- und Latenzprofile haben.
In einer integrierten Lösung können zusätzliche Infrastruktur- und Engineeringkosten entfallen oder geringer ausfallen. Dazu können separate Synchronisationslogik, zusätzliche Berechtigungsmodelle und der Betrieb eines weiteren Datendienstes gehören. Ob diese Einsparungen den Preisunterschied ausgleichen, muss für den konkreten Anwendungsfall berechnet werden.
Grenzen
Mehrere Einschränkungen sollten vor dem produktiven Einsatz berücksichtigt werden.
Begrenzte Indexkonfiguration
Eigene Parameter für Indexstruktur, Distanzmaß und Suchalgorithmus sind nur begrenzt steuerbar, weniger tief als bei manchen spezialisierten Vektordatenbanken.
Cloud- und Regionsabhängigkeit
Verfügbarkeit und Funktionsumfang können sich nach Cloud und Region unterscheiden. Bei nicht verfügbarer Region sind alternative Architektur- oder Rolloutentscheidungen erforderlich.
Skalierung über Endpoint-Klassen
Durchsatz wird über die von Databricks angebotenen Endpoint-Klassen gesteuert. Für hohe Lasten sind Lasttests und ggf. eine verteilte Endpoint-Architektur nötig.
Modellwechsel erfordert Neuberechnung
Ein Wechsel des Embedding-Modells erfordert normalerweise eine vollständige Neuberechnung der Vektoren. Die Auswahl sollte vor großen produktiven Indizes mit einem repräsentativen Evalset abgesichert werden.
Diese Einschränkungen schließen AI Search nicht grundsätzlich aus. Sie helfen jedoch bei der Entscheidung, ob die verwaltete Lösung oder ein spezialisierter Store besser geeignet ist.
Fazit
AI Search ist besonders interessant, wenn RAG-Anwendungen produktiv werden sollen und die relevanten Daten bereits in Unity Catalog liegen.
Dann können Datenbereitstellung, Indexierung und Governance enger miteinander verbunden werden. Der integrierte Ansatz ist besonders hilfreich, wenn Teams Synchronisation und Berechtigungen nicht für jeden Anwendungsfall neu aufbauen möchten. Ein Teil der Indexaktualisierung kann von der Plattform übernommen werden. Je nach Zugriffsmuster kann vorhandene Governance wiederverwendet oder zumindest enger angebunden werden.
Für Daten außerhalb der Databricks-Plattform, sehr hohe Last oder spezielle Indexanforderungen kann ein externer Store geeigneter sein. Eine hybride Plattformstrategie ist möglich, wenn Verantwortlichkeiten und Datenflüsse klar getrennt bleiben. Zwei parallele Retrievallösungen für denselben Datenbestand sind dagegen meist unnötig komplex.
Für einen ersten Wissensassistenten bietet sich ein Delta Sync Index mit Hybrid Search als Referenzarchitektur an. Als Ausgangspunkt sollte ein unterstütztes Embedding-Modell aus der Plattform gegen ein repräsentatives Testset geprüft werden. Die gewünschte Berechtigungswirkung sollte mit realen Nutzeridentitäten und geschützten Daten ausdrücklich getestet werden. Externe Vektorspeicher sollten nur für klar begründete Anforderungen ergänzt werden.
Bei AI Search geht es nicht nur um die Auswahl eines Vektorspeichers. Entscheidend sind vor allem Aktualisierung, Governance, Embedding-Strategie und die Wiederverwendung über mehrere RAG-Anwendungen hinweg.
FAQ
AI Search ist die Retrieval-Schicht für GenAI auf der Lakehouse-Datenbasis. Sie sitzt auf Mosaic AI Vector Search, hält Indizes gegen Unity-Catalog-Tabellen automatisch synchron, beantwortet Anfragen über Hybrid Search und reicht Treffer an Verbraucher wie Agent Bricks, eigene RAG-Apps oder die ai_query-Funktion in Databricks SQL durch. Berechtigungen erben direkt aus dem Katalog.
