AI Functions auf Databricks: Wann KI direkt in SQL sinnvoll ist
Die Kernaussagen auf einen Blick.
- Mit AI Functions lassen sich Modellaufrufe direkt in Databricks-SQL-Abfragen einbinden. Je nach aktuellem Funktionsumfang stehen spezialisierte Funktionen und ai_query für Aufrufe gegen konfigurierte Modellendpoints zur Verfügung.
- Ein wesentlicher Vorteil ist die enge Verbindung mit bestehenden Datenpipelines und Governance-Prozessen.
- Berechtigungen, Metadaten und Auditinformationen lassen sich in die Unity-Catalog-Struktur einbinden.
- Für klar abgegrenzte Batchaufgaben kann dadurch eine zusätzliche Python- oder API-Schicht entfallen.
- Vor einem produktiven Einsatz sollten drei Entscheidungen getroffen werden: welcher Endpoint und welches Modell für den Anwendungsfall genutzt werden, wie Verbrauch, Kapazität und Kosten gemessen und gesteuert werden, und wie Aufrufe, Ergebnisse, Verantwortlichkeiten und Qualitätsprüfungen dokumentiert werden.
- Als Einstieg eignen sich vor allem Batch-Klassifikation und strukturierte Extraktion auf bereits verwalteten Daten. Externe Modellendpoints bleiben sinnvoll, wenn sie bei Qualität, Funktionen, Latenz oder bestehender Integration klare Vorteile bieten.
Inhaltsverzeichnis
Was ändert sich, wenn KI in SQL läuft?
Ein typischer Anwendungsfall ist die Klassifikation einer großen Zahl offener Service-Tickets. Ein ai_classify-Aufruf lässt sich technisch mit wenig SQL-Code in eine Pipeline integrieren. Dadurch entsteht schnell der Eindruck, dass auch der produktive Betrieb entsprechend einfach ist. Für den Betrieb müssen jedoch zusätzliche Fragen geklärt werden:
- Welches Modell und welcher Endpoint werden tatsächlich verwendet?
- Welche Kosten entstehen bei der geplanten Datenmenge und Wiederholungsfrequenz?
- Welche Nutzer, Gruppen und Jobs dürfen den Modellaufruf ausführen?
- Werden Daten an einen externen Anbieter übertragen, und welche vertraglichen sowie technischen Bedingungen gelten dabei?
Diese Fragen entscheiden darüber, ob AI Functions nur für einzelne Experimente oder als verbindlicher Plattformbaustein genutzt werden. Sie eignen sich sowohl für schnelle Tests als auch für produktive Datenprozesse. Die passende Nutzung hängt von Datenlage, Qualitätsanforderungen, Kostenmodell und Verantwortlichkeiten ab.
Wenn Daten und Berechtigungen bereits in Unity Catalog verwaltet werden, kann ein Modellaufruf direkt in bestehende SQL-Prozesse eingebunden werden. Bei bereits etablierten Python-, API- oder Microservice-Lösungen muss geprüft werden, ob ein zusätzlicher SQL-basierter Inferenzweg tatsächlich einen Vorteil bietet.
Die Dokumentation erklärt in der Regel Funktionen und technische Nutzung. Ob ein konkreter Workload fachlich und wirtschaftlich passt, bleibt eine eigene Architekturentscheidung.
Ein typisches Pipeline-Muster sieht so aus: Ticketsystem, E-Mail, Chat und Telefon-Notizen liefern Rohdaten an einen gemeinsamen ai_classify-Aufruf. Der Prompt ordnet jedes Ticket einer Kategorie zu (Störung, Frage, Beschwerde, Bestellung) und bestimmt zusätzlich Dringlichkeit und nächste Aktion. Das Ergebnis sind geschäftsbereite Felder (Kategorie, Dringlichkeit, Sentiment), die sich direkt für Priorisierung und nächste Schritte nutzen lassen.
Was sind Databricks AI Functions?
AI Functions stellen Modellaufrufe als SQL-Funktionen bereit. Sie können in SELECT-, UPDATE-, MERGE- oder weiteren unterstützten SQL-Anweisungen eingesetzt werden. Das Ergebnis lässt sich wie ein normaler SQL-Wert weiterverarbeiten oder materialisieren.
Für die Plattformarchitektur sind insbesondere drei Eigenschaften relevant:
Integration in Datenprozesse
Die Funktionen laufen in Datenprozessen, die über Unity Catalog verwaltet werden. Der Modellaufruf bleibt näher an bestehenden Daten-, Berechtigungs- und Auditprozessen.
Endpoint-Abstraktion
Die SQL-Logik adressiert einen konfigurierten Modellendpoint statt eines direkten Providerzugangs. Ein Endpointwechsel ist oft ohne große Abfrage-Änderungen möglich. Qualität, Latenz und Kosten müssen trotzdem erneut geprüft werden.
Anwendung auf viele Datensätze
AI Functions lassen sich auf viele Tabellenzeilen anwenden. Eine Abfrage wie ai_classify(ticket_text, ...) erzeugt grundsätzlich einen Modellaufruf pro verarbeiteter Zeile.
AI Functions sind eine SQL-Schnittstelle zu bestehenden Modellen und Serving-Endpunkten. Das Team muss weiterhin festlegen, welches Modell für Qualität, Sprache, Kosten und Datenschutz geeignet ist. Weniger Anwendungscode bedeutet nicht automatisch geringere Modellkosten.
Wie AI Functions, Genie und das BI-/Analytics-Erlebnis im Hub zusammenhängen, klären wir im Überblick zu Databricks für Entscheider.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Welche AI Functions gibt es?
Grundsätzlich lassen sich spezialisierte Funktionen und der generische Aufruf über ai_query unterscheiden. Spezialisierte Funktionen kapseln klar definierte Aufgaben wie Klassifikation, Extraktion oder Zusammenfassung. ai_query ermöglicht einen frei konfigurierbaren Aufruf gegen einen ausgewählten Endpoint. Für standardisierte Aufgaben sind spezialisierte Funktionen meist einfacher, während individuelle Prompts mehr Flexibilität über ai_query benötigen.
Spezialisierte Funktionen
| Funktion | Aufgabe | Output-Stabilität | Kostencharakter | Validierungsbedarf |
|---|---|---|---|---|
| ai_classify | Klassifikation | hoch | mittel | mittel |
| ai_extract | Extraktion | mittel | mittel | hoch |
| Dokument-Parsing | Dokument-Parsing | mittel | hoch | hoch |
| ai_summarize | Zusammenfassung | mittel | mittel | mittel |
| ai_translate | Übersetzung | hoch | niedrig | niedrig |
| ai_sentiment | Sentiment | mittel | niedrig | mittel |
| ai_similarity | Ähnlichkeit | hoch | niedrig | niedrig |
| ai_mask | PII-Maskierung | mittel | mittel | hoch |
| ai_fix_grammar | Grammatik | hoch | niedrig | niedrig |
| Forecasting | Forecast | mittel | mittel | mittel |
Generischer Aufruf
| Funktion | Aufgabe | Output-Stabilität | Kostencharakter | Validierungsbedarf |
|---|---|---|---|---|
| ai_query | freier Call | niedrig | variabel | hoch |
| ai_gen | offene Generierung | niedrig | hoch | hoch |
Bei frei formulierten Antworten muss mit Formatabweichungen, Zusatztexten und unvollständigen Ergebnissen gerechnet werden. Ein definiertes Antwortschema kann die Weiterverarbeitung vereinfachen, ersetzt aber keine Validierung fehlerhafter oder unvollständiger Ausgaben. Flache, klar beschriebene Strukturen sind für Modelle meist zuverlässiger als tief verschachtelte Formate.
Spezialisierte Funktionen sind besonders geeignet, wenn Kategorien, Zielsprache oder Ausgabeschema eindeutig feststehen. Bei echter mehrstufiger Orchestrierung reicht ein einzelner ai_query-Aufruf häufig nicht aus; dafür ist eine eigene Anwendung oder Agentenlogik besser geeignet.
Interne, reservierte und externe Endpoints
Modell, Endpoint-Typ, Tokenvolumen und Auslastung beeinflussen die Gesamtkosten. Dafür stehen mehrere Betriebsmodelle zur Verfügung, die sich in Betrieb, Audit und Kosten unterscheiden.
Verwaltete Modelle
Databricks-bereitgestellte Modelle laufen über verwaltete Endpoints. Region, Hostingvariante und Verarbeitungsort müssen für das konkrete Modell und den Vertrag bestätigt werden. Ein verwalteter Endpoint vereinfacht Governance, ersetzt aber keine Datenschutzprüfung.
Reservierte Kapazität
Bei hoher, planbarer Nutzung kann reservierte Kapazität Leistung und Kosten besser planbar machen als reine Verbrauchsabrechnung. Eine pauschale Volumenschwelle gibt es nicht; sie muss anhand aktueller Preise und Lastprofile berechnet werden.
Externe Anbieter
Externe Modelle laufen über registrierte Serving-Endpunkte, die SQL-Schnittstelle bleibt gleich. Es gelten die Datenverarbeitungs-, Logging- und Vertragsbedingungen des jeweiligen Anbieters. Bei sensiblen Daten vorab prüfen.
Die Wahl sollte pro Anwendungsfall auf Basis von Qualität, Kosten, Datenart, Latenz und bestehender Architektur erfolgen:
- Welches Modell erreicht die erforderliche Qualität für den konkreten Anwendungsfall?
- Wie hoch ist die zu erwartende Token-Last pro Monat?
- Welche Daten werden an das Modell übertragen, und welche Datenschutzlage gilt für diese Daten?
- Handelt es sich um einen Batchprozess oder einen interaktiven Anwendungsfall?
Verwaltete Plattformmodelle sind ein sinnvoller Ausgangspunkt für standardisierte Aufgaben, sofern sie die Qualitätsanforderungen erfüllen. Externe Endpoints bleiben sinnvoll, wenn ein bestimmtes Modell, eine Funktion oder ein vertraglicher Vorteil nur dort verfügbar ist.
Was kosten AI Functions?
Für eine verlässliche Kalkulation sind die aktuelle Preisliste und ein repräsentativer Testlauf notwendig. Verbindliche Werte stehen nur auf der aktuellen Databricks-Pricing-Seite für AI Functions. Unabhängig vom Modell bestimmen vor allem Eingabe, Ausgabe, Häufigkeit und Wiederholungslogik die Kosten.
Die Kosten hängen im Wesentlichen von drei Faktoren ab:
Eingabetokens pro Datensatz
Prompt, Tabelleninhalt und Kontextinformationen bilden die Eingabemenge. Bei langen Dokumenten dominieren meist die Eingabetokens die Rechnung.
Ausgabetokens pro Datensatz
Klassifikationen erzeugen kurze Ausgaben, Zusammenfassungen und Extraktionen deutlich längere. Maximale Ausgabelänge und Antwortschema sollten bewusst begrenzt werden.
Modellauswahl
Größere, leistungsfähigere Modelle sind meist teurer als kleinere Modelle für Standardaufgaben. Konkrete Preisunterschiede ändern sich schnell und sollten nicht pauschal über Modellklassen verallgemeinert werden.
Bei einer einmaligen oder klar abgegrenzten Klassifikation kann ein vorhandenes Foundation Model günstiger sein als Aufbau und Betrieb eines eigenen Modells. Bei regelmäßigem Volumen sollte geprüft werden, ob ein eigenes Modell oder reservierte Kapazität langfristig günstiger ist. Konkrete DBU- oder Euroangaben sollten nur mit aktuell verifizierter Preisquelle und dokumentierten Annahmen verwendet werden.
Dokumentlänge, Ausgabeumfang, Modellwahl und Wiederholungsrate bleiben die zentralen Kostentreiber. Bei nutzungsabhängiger Abrechnung steigen die Kosten grundsätzlich mit dem verarbeiteten Volumen. Reservierte Kapazität verursacht feste Kosten innerhalb des gebuchten Zeitraums und ist nur bei ausreichender Auslastung wirtschaftlich. Für jeden produktiven Anwendungsfall sollte vor dem Rollout eine Kostenprognose mit realen Daten erstellt werden.
Zwei Hebel, die in dieser Rechnung oft übersehen werden:
- Kurze und klare Prompts reduzieren Eingabetokens und vereinfachen häufig auch die Ausgabe.
- Nur neue, geänderte und tatsächlich relevante Zeilen sollten einen Modellaufruf auslösen. Klassische SQL-Logik sollte immer vor einem kostenpflichtigen Modellaufruf eingesetzt werden, wenn sie denselben Zweck zuverlässig erfüllt.
Wie werden AI Functions auditierbar?
Die Nähe zu SQL und Unity Catalog erleichtert die Einbindung in bestehende Governance-Prozesse. Welche Funktionen als katalogisierte Objekte verwaltet werden und welche Systemfunktionen direkt verwendet werden, hängt von der konkreten Implementierung ab. Genutzt werden können dabei Unity Catalog und die zugehörigen Auditmechanismen.
Für den Betrieb ergeben sich daraus mehrere Aspekte:
Wrapper-Funktionen
Eigene Wrapper-Funktionen mit klaren EXECUTE-Berechtigungen legen Endpoint, Prompt, Schema und zulässige Nutzung pro Anwendungsfall fest. Direkte generische Modellaufrufe lassen sich darüber gezielt einschränken.
System- und Audit-Tabellen
Audit-Tabellen liefern Informationen zu Nutzer, Zeitpunkt, Abfrage und Endpoint. Wie vollständig die Nachvollziehbarkeit ist, hängt von aktivierten Logs, Retention und unterstützten Ereignissen ab.
Lineage
AI-gestützte Transformationen gehören in die Daten-Lineage. Modell- und Endpointinformationen müssen dafür teils zusätzlich als Metadaten dokumentiert werden, damit die Lineage fachlich aussagekräftig bleibt.
Eine vorgelagerte Maskierung kann sinnvoll sein, wenn der eigentliche Modellendpoint die sensiblen Inhalte nicht erhalten soll. Die Wirksamkeit der Maskierung muss jedoch für Sprache, Datenart und Fehlerrisiko getestet werden.
Engpässe bei Latenz und Durchsatz
Die SQL-Integration ändert nichts daran, dass Modellinferenz Zeit und Kapazität benötigt. Große Tabellen können eine sehr hohe Zahl einzelner Inferenzaufrufe verursachen.
Durchsatzgrenzen pro Endpoint
Endpoints haben je nach Modell und Bereitstellungsform Grenzen für Parallelität, Tokenrate und Anfragevolumen. Bei Batchläufen müssen Drosselung, Warteschlangen und längere Laufzeiten eingeplant werden.
Latenz im interaktiven Pfad
Für interaktive BI- oder Anwendungspfade mit niedrigen Antwortzeiten eignen sich AI Functions nur eingeschränkt. Vorberechnete, materialisierte Ergebnisse sind für Dashboards meist geeigneter als Modellaufrufe zur Abfragezeit.
Wiederholungen und Throttling
Pipelines müssen mit temporären Fehlern, Limits und Teilfehlschlägen umgehen können. Ergebnisse und Status sollten materialisiert werden, damit ein Wiederanlauf keine bereits verarbeiteten Zeilen erneut berechnet.
Bei stabiler hoher Auslastung sollte reservierte Kapazität gegen nutzungsabhängige Endpoints gerechnet werden. Die Kapazität des Modellendpoints sollte bei Pipelines mit festen SLAs vorab dimensioniert werden.
Wie kommen AI Functions in die Pipeline?
In den meisten produktiven Setups laufen AI Functions als Schritt in einer Medallion-Pipeline und nicht als isolierter Einzel-Notebook-Aufruf.
Unstrukturierte Rohdaten
PDF-Auszüge, Ticketbeschreibungen und Belegtexte lassen sich in der Silber-Schicht in strukturierte Felder überführen. Kostenpflichtige Modellergebnisse sollten in einer Tabelle gespeichert und versioniert werden.
Klassifikationen und Zusammenfassungen
Sie ergänzen nachgelagerte Reporting- und Analysemodelle (etwa Tickettypen, Sentiment-Verteilungen oder Belegkategorien).
Inkrementelle Verarbeitung
Nur neue, geänderte oder bisher nicht verarbeitete Datensätze sollten an das Modell gesendet werden. Das ist eine der wirkungsvollsten Maßnahmen zur Kostenkontrolle.
Nicht materialisierte Aufrufe können bei wiederholten Abfragen mehrfach ausgeführt werden und sollten deshalb vermieden oder bewusst gekapselt werden. Eine View mit direktem Modellaufruf kann bei jeder Abfrage erneut Kosten verursachen.
Die von Databricks vorgesehene Mengenverarbeitung sollte genutzt werden, sofern sie zum Fehler- und Wiederanlaufkonzept passt. Eigene Batchlogik sollte nur eingesetzt werden, wenn Limits, Priorisierung oder Wiederanlauf dies tatsächlich erfordern. Wie Parallelisierung und Retry-Verhalten umgesetzt werden, hängt von Funktion, SQL Warehouse und Endpoint ab und sollte nicht ohne Test vorausgesetzt werden.
Wann braucht es eigene ML-, RAG- oder Agenten-Architektur?
AI Functions sollten klar von anderen KI-Architekturen abgegrenzt werden.
Eigene Modelle
Sinnvoll, wenn proprietäre Trainingsdaten und domänenspezifische Qualität entscheidend sind. AI Functions vereinfachen Inferenz, nicht Feature Engineering, Training, Evaluation und Versionierung.
RAG und Retrieval
Für Antworten auf großen eigenen Wissensbeständen bleibt Retrieval und Indexierung nötig. Ein SQL-basierter Modellaufruf kann Teil einer RAG-Pipeline sein, ersetzt aber nicht Suchindex, Retrieval und Quellenbewertung.
Agenten-Orchestrierung
Mehrstufige Abläufe, Toolaufrufe und länger laufende Konversationen brauchen programmatische Orchestrierung. AI Functions passen am besten zu einzelnen, nachvollziehbaren Zeilen- oder Batch-Transformationen.
Die passende Architektur hängt von Datenbasis, Latenz, Zustandsbedarf, Qualität und Wartungsaufwand ab. Für Retrieval auf großen Wissensbeständen bleibt Vector Search der zuständige Baustein.
Wie sich Mosaic AI Agents, Vector Search und RAG-Patterns auf Databricks zueinander verhalten, klären wir im Überblick zu Künstliche Intelligenz auf Databricks.
Grenzen
AI Functions eignen sich für viele klar abgegrenzte KI-Aufgaben. Für bestimmte Anforderungen sind jedoch andere Architekturen geeigneter.
Modell-Verfügbarkeit
Nicht jedes benötigte Modell lässt sich über einen unterstützten Endpoint ansprechen. Dann trägt AI Functions den Anwendungsfall nicht allein.
Latenz in Echtzeit-Pfaden
Feste Latenzgrenzen lassen sich nicht pauschal angeben. Für echtzeitnahe Anwendungen sind AI Functions meist nicht der bevorzugte Pfad.
Kein Modelllebenszyklus
AI Functions verwalten keinen vollständigen Modelllebenszyklus. Modellversionierung, A/B-Tests und systematische Evaluationsschleifen gehören in eine MLOps-/LLMOps-Strecke, nicht in eine SQL-Funktion.
Kostenrisiko bei Rohaufrufen
Ungefilterte Aufrufe auf großen Tabellen können erhebliche, unerwartete Kosten verursachen. Kostenkontrollen, Limits und Reviewprozesse müssen fest in Pipeline und Governance eingebaut werden.
Plattformbindung
Eine tiefe Integration vereinfacht den Betrieb, erhöht aber den Aufwand eines späteren Plattformwechsels. Ein externer Modellanbieter reduziert diese Bindung nur teilweise.
Preview-Status
Einzelne Funktionen, Modelle und Parameter können sich in Preview befinden oder regional eingeschränkt sein. Verfügbarkeit und Reifegrad vor Architektur- und SLA-Entscheidungen verifizieren.
Fazit
AI Functions ermöglichen Modellaufrufe direkt innerhalb von Databricks-SQL-Prozessen.
Besonders hilfreich sind die Nähe zu bestehenden Daten, Berechtigungen und Auditprozessen sowie der geringere Integrationsaufwand. Zu berücksichtigen sind Modellkosten, Latenz, Endpointabhängigkeit, Qualitätsprüfung und Databricks-spezifische Syntax.
Geeignet sind vor allem klar definierte, mengenorientierte Aufgaben auf bereits verwalteten Daten. Eigene Modelle, komplexes Retrieval und mehrstufige Agenten benötigen weiterhin spezialisierte Architekturen.
Als erster produktiver Anwendungsfall eignen sich Batch-Klassifikation oder strukturierte Extraktion mit begrenztem Datenumfang. Dafür sollten Wrapper-Funktionen, eindeutige Berechtigungen, materialisierte Ergebnisse und ein Kostenreport pro Use Case vorgesehen werden. Bestehende externe Endpoints sollten nicht allein aus Plattformgründen ersetzt werden. Ein Wechsel ist sinnvoll, wenn Tests einen nachvollziehbaren Vorteil bei Qualität, Kosten, Betrieb oder Governance zeigen.
Ob AI Functions eure KI-Use-Cases wirtschaftlich tragen oder zusätzliche Komplexität erzeugen, lässt sich in einem ersten Data & AI Assessment gut einordnen.
- welche eurer KI-Use-Cases echte Kandidaten für AI Functions auf Databricks sind
- welche Governance-, Compliance- und Kosten-Risiken vor dem produktiven Einsatz geprüft werden müssen
- welcher Modell- und Architektur-Ansatz für eure Situation trägt: Foundation Models on Databricks, reservierter Durchsatz oder externer Endpoint
FAQ
AI Functions sind eingebaute SQL-Funktionen, die Aufrufe an Sprach- oder andere KI-Modelle als Teil einer SQL-Abfrage ausführen. Funktionen wie ai_query, ai_classify, ai_extract, ai_summarize, ai_translate oder ai_mask laufen gegen Model Serving Endpoints im Workspace und geben den Modell-Output als reguläre Spalte zurück. Sie sind die deklarative Schicht für KI-Operationen auf Catalog-Daten.
