Generative AI auf Databricks: Wie die wichtigsten Bausteine zusammenspielen

In vielen Unternehmen entsteht zu Beginn ein ähnliches Bild. Mehrere Teams entwickeln unabhängig voneinander Prototypen mit unterschiedlichen Werkzeugen und Anbietern. Wie daraus ein stabiler produktiver Betrieb entstehen soll, ist jedoch noch ungeklärt. Ein Wissensassistent nutzt beispielsweise LangChain, einen externen Vektorspeicher und eine direkte Modell-API. Ein weiterer Assistent verteilt seine Logik auf Databricks und zusätzliche Cloud-Funktionen. Ein interner Chatbot verwendet einen separaten Anbieterzugang, für dessen Ablösung kein klarer Plan besteht. Gleichzeitig werden mehrere Embedding-Modelle und Vektorspeicher parallel verwendet. Die Berechtigungslogik unterscheidet sich dabei von Anwendung zu Anwendung.

Solche Strukturen entstehen häufig, wenn Teams ohne gemeinsame Architektur- und Governance-Vorgaben starten. Die Modellauswahl steht oft im Mittelpunkt, weil sie leicht vergleichbar und nach außen sichtbar ist. Der größere Betriebsaufwand entsteht jedoch bei Retrieval, Berechtigungen, Evaluation, Kostenzuordnung und späteren Modellwechseln.

Typischerweise stellen sich dabei mehrere Fragen:

• Welche Datenquellen darf der Assistent abhängig von Nutzer und Rolle verwenden?
• Wie kann ein Modell ausgetauscht werden, ohne die gesamte Anwendung neu zu entwickeln?
• Wie werden Modellkosten einzelnen Teams und Anwendungsfällen zugeordnet?
• Wie wird mit bestehenden Vektorindizes umgegangen, wenn das Embedding-Modell geändert wird?
• Wie wird regelmäßig geprüft, ob die Antworten weiterhin die definierten Qualitätsanforderungen erfüllen?

GenAI-Anwendungen auf Databricks sollten deshalb als Zusammenspiel mehrerer Plattformkomponenten geplant werden. Wer die Komponenten gemeinsam plant, reduziert Schnittstellen und doppelte Betriebsprozesse. Eine rein funktionsorientierte Auswahl ohne Gesamtarchitektur führt dagegen schnell zu neuen Einzellösungen.

Die folgende Übersicht ordnet die wichtigsten Komponenten nach ihrer Rolle im Anwendungsprozess. Sie kann als Ausgangspunkt für die Entscheidung zwischen Eigenentwicklung, Databricks-Dienst und externer Lösung dienen.

Diese acht Bausteine lassen sich strukturell zu vier funktionalen Schichten zusammenfassen: Anwendungslogik (Agent Bricks, AI Playground, AI Functions), Modellzugriff (Foundation Model APIs, Unity AI Gateway, Model Serving), Retrieval (Vector Search) und Evaluation (MLflow-Eval), getragen von Unity Catalog als gemeinsamem Governance-Fundament für Identität, Berechtigungen, Lineage und Kostenzuordnung. Der Übergang zur nächsten Frage: wie ein typischer GenAI-Aufruf durch diese vier Schichten hindurchläuft.

Foundation Model APIs sind für viele Teams ein einfacher Einstieg in die Nutzung gehosteter Modelle. Welche Modellfamilien verfügbar sind, hängt vom aktuellen Angebot, der Region und dem gewählten Endpoint-Typ ab. Für viele Wissensassistenten, Klassifikationsaufgaben und interne Chat-Anwendungen reicht ein gehosteter Modellzugang zunächst aus.

Wenn ein bestimmtes proprietäres Modell benötigt wird, kann es über das Unity AI Gateway eingebunden werden. Das ist sinnvoll, wenn ein Anbieter bei Qualität, Kontextfenster, Multimodalität oder Tool-Nutzung klare Vorteile bietet. Die übrige Architektur kann dabei weitgehend bestehen bleiben, sofern Schnittstellen und Funktionen kompatibel sind.

Eigenes Hosting über Model Serving kommt vor allem bei besonderen technischen Anforderungen oder hohem, planbarem Lastvolumen infrage. Mögliche Gründe sind besondere Anforderungen an Datenverarbeitung, Latenz, Modellanpassung oder dauerhaft hohe Last. Auch ein nachweisbarer Qualitätsgewinn durch Fine-Tuning kann für ein eigenes Modell sprechen. Vor dem Aufbau eigener Inferenzinfrastruktur sollte ein Vergleich mit gehosteten Modellen, verbessertem Prompting und RAG erfolgen.

Diese schrittweise Vorgehensweise reduziert unnötigen Betriebsaufwand. Wer direkt mit eigenem Hosting beginnt, baut möglicherweise Infrastruktur auf, bevor der fachliche Nutzen ausreichend belegt ist. Ein gehosteter Endpoint ermöglicht zunächst eine schnelle fachliche Validierung. Spätere Modellwechsel bleiben möglich, wenn die Anwendung sauber von der Modellschnittstelle entkoppelt wurde.

Mehrere Anwendungsarten eignen sich grundsätzlich für eine produktive Umsetzung auf Databricks.

Wissensassistent auf eigenen Dokumenten. Ein Wissensassistent auf internen Dokumenten ist ein typischer Einstieg. Dokumente aus Systemen wie SharePoint oder Confluence werden zunächst in die Datenplattform übernommen. Anschließend werden sie für die semantische Suche indexiert. Ein gehostetes oder externes Modell erzeugt die Antwort. Die Orchestrierung kann über Agent Bricks oder eine eigene RAG-Anwendung erfolgen. Dieser Anwendungsfall eignet sich häufig als erster produktiver Test. Der Nutzen ist besonders hoch, wenn Datenzugriff, Lineage und Retrieval bereits in Databricks organisiert werden.

Analyse-Assistent (Text-to-SQL). Ein Analyse-Assistent übersetzt natürliche Sprache in Abfragen auf Unternehmensdaten. Spezialisierte Databricks-Funktionen wie Genie können dafür einen Ausgangspunkt bieten. Der Integrationsaufwand ist geringer, wenn Tabellen und Metadaten bereits sauber in Unity Catalog gepflegt sind.

Dokumenten-Klassifizierung über AI Functions. Dokumente, Tickets oder E-Mails können über AI Functions direkt in Datenpipelines klassifiziert und angereichert werden. Das Modell wird dabei als Teil eines SQL- oder Batchprozesses aufgerufen. Eine eigene Agentenlogik oder Benutzeroberfläche ist dafür nicht zwingend erforderlich.

Interner Chat mit Modell-Routing. Ein gemeinsamer interner Chat kann abhängig vom Anwendungsfall unterschiedliche Modelle verwenden. Nutzung und Kosten lassen sich über ein zentrales Gateway erfassen. Das zugrunde liegende Modell kann später angepasst werden.

Diese Anwendungsfälle profitieren besonders von mehreren gemeinsamen Plattformfunktionen. Dazu gehören Datenzugriff, Retrieval, zentrale Berechtigungen, Evaluation und Logging. Anwendungen ohne Bezug zu Databricks-Daten oder Governance sollten mit einer direkten Anbieter-API verglichen werden. In solchen Fällen ist der Integrationsvorteil der Plattform geringer.

Unity Catalog bildet die zentrale Grundlage für Berechtigungen, Metadaten und Lineage in vielen GenAI-Architekturen auf Databricks. Welche dieser Objekte direkt in Unity Catalog verwaltet werden, hängt von der jeweiligen Funktion und Produktversion ab. Für viele Objekte lassen sich jedoch ähnliche Berechtigungs- und Eigentümerkonzepte wie bei Tabellen verwenden. Ziel ist eine möglichst einheitliche Steuerung des Zugriffs auf Daten, Modelle und Funktionen. Bei einer korrekt umgesetzten Berechtigungsarchitektur sollte ein Nutzer nur Inhalte abrufen können, für die er autorisiert ist.

Ergänzend werden Richtlinien für Modellnutzung, Sicherheit und Compliance benötigt. Databricks stellt dafür Funktionen zur Durchsetzung von Richtlinien und zur Protokollierung von Modellnutzung bereit (Mosaic AI Governance). In Kombination mit Unity AI Gateway und MLflow können Richtlinien, Modellaufrufe und Auswertungen miteinander verbunden werden. Welche Richtlinie an welcher Stelle gepflegt und technisch durchgesetzt wird, sollte in der Zielarchitektur eindeutig dokumentiert sein.

Der Nutzen wird bei typischen Governance- und Auditfragen sichtbar. Welche Datenquellen wurden für eine konkrete Antwort verwendet? Welche Modellversion hat die Antwort erzeugt? Wer hat die verwendete Promptvorlage geprüft und freigegeben? Bei verteilten Systemen müssen diese Informationen über mehrere Plattformen hinweg zusammengeführt werden. Eine integrierte Plattform kann diesen Nachweis deutlich vereinfachen.

Der Einsatz von Databricks für GenAI ist eine bewusste Plattformentscheidung. Mehrere Einschränkungen sollten dabei berücksichtigt werden.

Diese Einschränkungen ergeben eine praktische Prüfliste, die vor dem produktiven Start bearbeitet werden sollte.