AI Functions: Definition, Funktionsklassen und Abgrenzung

AI Functions sind Zusatz-Befehle in SQL (der Abfragesprache für Datenbanken) auf Databricks, mit denen sich ein KI-Modell direkt aus einer Datenbank-Abfrage aufrufen lässt. Statt Daten aus der Datenbank zu exportieren, an ein Modell zu schicken und die Antwort zurückzuschreiben, steht der Modellaufruf als Funktion in der Abfrage. Beispiele sind ai_classify(...) zum Einsortieren eines Textes in vorgegebene Kategorien oder ai_query(...) für einen frei formulierten Auftrag an das Modell.

Was sind AI Functions?

AI Functions verbinden die SQL-Abfrage-Ausführung von Databricks mit einem Modell-Endpoint (eine bereitgestellte Adresse, unter der ein KI-Modell angesprochen werden kann). Der Modellaufruf steht in der Abfrage neben klassischen SQL-Ausdrücken (etwa SUM(...) oder LOWER(...)) und liefert einen Wert pro Zeile zurück. Ausgeführt wird die Funktion in einem SQL Warehouse (der SQL-Rechenumgebung von Databricks) oder in einem Notebook (interaktives Code-Dokument) auf einem Databricks-Cluster; das Ergebnis lässt sich weiterverarbeiten, als dauerhafte Tabelle speichern oder als Schritt einer Verarbeitungsstrecke versionieren.

Zwei Klassen tragen den Begriff. Erstens die spezialisierten Funktionen für klar abgegrenzte Aufgaben: ai_classify (Klassifikation gegen ein vorgegebenes Label-Set), ai_extract (Feld-Extraktion aus unstrukturiertem Text), ai_summarize, ai_translate, ai_sentiment, ai_similarity, ai_mask (PII-Maskierung), ai_fix_grammar sowie Forecasting- und Dokument-Parsing-Funktionen. Zweitens der generische Aufruf ai_query (und ai_gen), der einen beliebigen Prompt gegen einen konfigurierten Endpoint schickt. Anzahl und Reifegrad der Funktionen sind produkt- und regionsabhängig; verbindliche Referenz bleibt die aktuelle Databricks-Dokumentation.

Der aufgerufene Endpoint ist entkoppelt von der SQL-Syntax. Möglich sind von Databricks bereitgestellte Foundation-Model-Endpoints, reservierte Kapazität über [Model Serving](/insights/databricks/artificial-intelligence/model-serving/) oder registrierte externe Modellanbieter. Berechtigungen, Metadaten und Audit-Informationen laufen über Unity Catalog; Wrapper-Funktionen mit definierten EXECUTE-Rechten sind ein üblicher Governance-Baustein.

Abgrenzung zu Model Serving, RAG und AI Agents

Der Begriff wird häufig mit Nachbar-Komponenten des Databricks-AI-Stacks vermischt. Die relevanten Trennlinien:

Begriff	Was ist es?	Verhältnis zu AI Functions
Model Serving	Runtime-Layer, der Modelle als Endpoint bereitstellt	Der Layer darunter: AI Functions rufen einen Serving-Endpoint auf
Foundation Model APIs	Vorkonfigurierte Endpoints für Basismodelle über REST	Ein möglicher Endpoint-Typ hinter einer AI Function
RAG (Retrieval-Augmented Generation)	Antwortmuster mit Suche über Vektorindex + Generierung	Kann eine AI Function als Generator-Schritt einschließen, ersetzt aber Retrieval und Indexierung nicht
AI Agent	LLM-basierter Loop mit Werkzeug-Aufrufen und Zustand	Andere Klasse: mehrstufige Orchestrierung statt einer Zeilenoperation
Agent Bricks	Template-Produkt mit Evaluation und Serving	Höhere Abstraktion für Agenten-Use-Cases, nicht für Batch-Transformationen

AI Functions und Model Serving werden zusammen benutzt, adressieren aber unterschiedliche Ebenen: Serving stellt das Modell bereit, die Funktion ruft es aus SQL heraus auf. Ein Endpoint kann von AI Functions, aus Python-Code oder aus einer Applikation angesprochen werden.

Von RAG- und Agenten-Mustern trennt AI Functions vor allem der Kontrollfluss. Eine AI Function ist ein Single-Call ohne Zustand und ohne Werkzeug-Schleife; sie berechnet ein Feld pro Zeile. RAG ergänzt den Modellaufruf um Retrieval aus einem Vektorindex; ein AI Agent lässt das Modell zur Laufzeit über den nächsten Schritt entscheiden. Für mehrstufige Abläufe reicht ein einzelner ai_query-Aufruf in der Regel nicht aus.

Beispiel: Batch-Klassifikation von Service-Tickets

Ein typischer Anwendungsfall ist die Klassifikation offener Service-Tickets in einer Silver-Schicht. Aus unstrukturierten Ticket-Texten entstehen strukturierte Felder für Priorisierung und Reporting. Der SQL-Aufruf hat die Form:

sql

SELECT
  ticket_id,
  ai_classify(ticket_text, array('Störung', 'Frage', 'Beschwerde', 'Bestellung')) AS kategorie,
  ai_sentiment(ticket_text) AS sentiment
FROM bronze.tickets
WHERE ingest_ts > current_timestamp() - INTERVAL 1 HOUR;

Pro verarbeiteter Zeile entsteht ein Modellaufruf. Die Ergebnisse werden in eine Delta-Tabelle materialisiert, sodass wiederholte Abfragen keinen erneuten Modellaufruf auslösen. Nur neue oder geänderte Zeilen werden an das Modell übergeben; klassische SQL-Filter laufen vor der Funktion, um Kosten zu begrenzen. Der Endpoint, das Modell und der Prompt werden in einem Wrapper mit definierten Berechtigungen gekapselt, damit Governance, Kosten und Ausgabeformat pro Anwendungsfall kontrolliert bleiben.