Databricks News

KI-Entscheidungsmodelle: Mit Databricks direkt aus SQL nutzen

Ailio Redaktion · 25. September 2026 · 6 Min. Lesezeit

Datenplattform

KI-Entscheidungsmodelle: Mit Databricks direkt aus SQL nutzen

Ailio

Texte einer Kategorie zuordnen, Serviceanfragen vorsortieren oder Meldungen zur Prüfung markieren: Viele betriebliche KI-Aufgaben brauchen keine langen Antworten, sondern eine Auswahl aus vorgegebenen Optionen. Genau dafür sind KI-Entscheidungsmodelle interessant. Databricks zeigt jetzt, wie sich ein solches Modell mit offenen Gewichten auf Serverless-GPUs bereitstellen und über die SQL-Funktion ai_query auf bereits verwaltete Daten anwenden lässt. Für Unternehmen mit Azure und Databricks eröffnet das einen Weg, Klassifikation enger in bestehende Datenprozesse einzubauen.

Kurz gesagt: Databricks demonstriert mit SemIf-OpenJev die Bereitstellung eines offenen Entscheidungsmodells über einen verwalteten Model-Serving-Endpunkt. Über ai_query können SQL-Abfragen und Lakeflow-Jobs das Modell aufrufen und Klassifikationen samt Wahrscheinlichkeitswerten zurückerhalten. Der praktische Nutzen liegt in der Verbindung von Modellbetrieb und vorhandenen Datenabläufen – nicht in einer automatisch garantierten Entscheidungsqualität.

Was ist neu an KI-Entscheidungsmodellen in Databricks?

Neu am gezeigten Ansatz ist die durchgängige Verbindung aus Serverless-GPU-Bereitstellung, verwaltetem Model Serving und SQL-Aufrufen für ein offenes Entscheidungsmodell. Teams können damit einen eigenen Modell-Endpunkt nutzen, ohne für jeden Anwendungsfall zuerst eine separate Anwendung entwickeln zu müssen.

Ein Entscheidungsmodell wählt zwischen festgelegten Möglichkeiten, statt primär freien Text zu erzeugen. Für einen internen Serviceprozess könnten das beispielsweise „Ersatzteilanfrage“, „technische Störung“ und „Terminabstimmung“ sein. Die Ausgabe lässt sich anschließend als strukturiertes Ergebnis weiterverarbeiten.

Dabei ist eine Unterscheidung wichtig: Offene Modellgewichte bedeuten nicht automatisch uneingeschränkt freie Nutzung. Vor einem betrieblichen Einsatz solltest Du Lizenzbedingungen und Nutzungsrechte prüfen. Auch ein offen verfügbares Modell muss zur Sprache, zum Fachvokabular und zu den Entscheidungskriterien Deines Unternehmens passen.

Wie kommen Modell und Unternehmensdaten zusammen?

Das Modell wird als verwalteter Endpunkt bereitgestellt und anschließend mit ai_query aus SQL oder einem Lakeflow-Job aufgerufen. Die Datenverarbeitung übergibt dabei die benötigten Eingaben an den Endpunkt und verarbeitet dessen Antwort weiter.

Der vorgestellte Bereitstellungsweg nutzt ein importierbares Notebook. Nach Auswahl des Modellnamens beziehungsweise Schemas und der Serverless-GPU-Ausführung übernimmt der Ablauf mehrere technische Schritte:

  • Die Modelldateien von SemIf-OpenJev werden heruntergeladen.
  • Das Modell wird mithilfe von Express Deployments protokolliert und registriert.
  • Ein GPU-basierter Model-Serving-Endpunkt wird automatisch angelegt.
  • Databricks AI Runtime stellt die benötigte GPU-Rechenleistung bereit, ohne dass das Team dafür eigene GPU-Infrastruktur aufsetzen und verwalten muss.

Bemerkenswert ist die Schnittstelle: ai_query ist hier nicht auf ein standardisiertes Chat-Format beschränkt. Die Funktion unterstützt benutzerdefinierte Modell-APIs und kann das strukturierte Anfrageformat des Modells übermitteln.

SQL vereinfacht die Einbindung, ersetzt aber keine Betriebsplanung

Für Dein Datenteam wird der Modellaufruf damit Teil einer vertrauten Verarbeitungskette. Eingabedaten auswählen, Klassifikation anstoßen und Ergebnisse für weitere Auswertungen aufbereiten lässt sich in SQL-basierten Abläufen organisieren.

Trotzdem bleibt ein Modellaufruf ein zusätzlicher Verarbeitungsschritt mit Laufzeit, Kosten und möglichen Fehlern. Wiederholungen fehlgeschlagener Aufrufe, Protokollierung und der Umgang mit unvollständigen Ergebnissen gehören deshalb in die Planung. Eine funktionierende Notebook-Demonstration ist noch kein belastbarer Produktionsbetrieb.

Für welche Aufgaben im Mittelstand lohnt sich der Ansatz?

Der Ansatz lohnt sich vor allem für wiederkehrende Klassifikationsaufgaben mit klar definierten Auswahlmöglichkeiten und ausreichend verfügbaren Textdaten. Weniger passend ist er für Aufgaben, deren Ergebnisumfang offen ist oder bei denen die benötigten Informationen nicht im Eingabetext enthalten sind.

Denkbare Einsatzfelder sind:

  • Service: Eingehende Anfragen nach Anliegen sortieren und zur zuständigen Gruppe weiterleiten.
  • Einkauf: Freitextmeldungen zu Lieferproblemen nach definierten Ursachen einordnen.
  • Produktion: Wartungsnotizen für eine anschließende fachliche Prüfung vorsortieren.
  • Vertrieb: Rückmeldungen nach Produktinteresse oder genanntem Handlungsbedarf kategorisieren.

Das sind mögliche Anwendungen, keine belegten Ergebnisse des vorgestellten Modells. Gerade deutsche Fachbegriffe, Abkürzungen und knappe Werkstattnotizen solltest Du mit eigenen Beispielen testen.

Der wirtschaftliche Vorteil entsteht nicht allein durch den Modelltyp. Entscheidend ist, ob die Klassifikation einen tatsächlichen Arbeitsschritt verbessert und sich zuverlässig in den Folgeprozess einfügt. Wenn Dir dafür noch die Datengrundlage fehlt, ist eine tragfähige Datenplattform wichtiger als die schnelle Auswahl eines neuen Modells.

Was müssen Unternehmen mit Azure Databricks prüfen?

Unternehmen mit Azure Databricks müssen vor dem Einsatz insbesondere Funktionsverfügbarkeit, Datenverarbeitung, Berechtigungen und Betriebskosten für ihre konkrete Umgebung prüfen. Aus dem beschriebenen Ablauf lässt sich keine pauschale Verfügbarkeit aller beteiligten Funktionen in jeder Azure-Region ableiten.

Verfügbarkeit und Datenwege klären

Prüfe zunächst, ob Serverless-GPU-Funktionen, AI Runtime und die benötigte Serving-Konfiguration in Deiner Region und Deinem Workspace nutzbar sind. Kläre außerdem, wo Eingaben verarbeitet werden und welche Netzwerk- und Sicherheitsvorgaben dafür gelten.

Die Einbindung in eine verwaltete Datenplattform ist hilfreich, aber kein automatischer Nachweis für Datenschutzkonformität. Enthalten Serviceanfragen personenbezogene Daten, solltest Du Datenminimierung, Zugriffsrechte und die Speicherung von Ein- und Ausgaben ausdrücklich regeln.

Datenrechte und Modellzugriff getrennt betrachten

Wer eine Tabelle lesen darf, sollte nicht zwangsläufig jeden Modell-Endpunkt aufrufen oder sämtliche Ergebnisse sehen können. Definiere deshalb, welche Identitäten Daten lesen, Inferenz ausführen und Resultate speichern dürfen.

Für nachvollziehbare Entscheidungen empfiehlt es sich außerdem, die verwendete Modellversion und die jeweiligen Entscheidungskriterien mitzuführen. So kannst Du später untersuchen, warum sich Klassifikationen nach einer Änderung unterscheiden.

Kosten mit dem eigenen Datenvolumen testen

Serverless reduziert den Aufwand für die Infrastrukturverwaltung, macht die Verarbeitung aber nicht kostenlos. Miss Laufzeit, Durchsatz und Kosten mit repräsentativen Texten. Plane außerdem, ob Du nur neue und geänderte Datensätze bewerten kannst, statt regelmäßig den gesamten Bestand erneut zu verarbeiten.

Wie wird aus dem Test eine belastbare Entscheidungshilfe?

Eine belastbare Entscheidungshilfe entsteht durch fachlich geprüfte Testdaten, klare Qualitätskriterien und definierte Regeln für unsichere Ergebnisse. Vom Modell ausgegebene Wahrscheinlichkeitswerte allein reichen dafür nicht aus.

Ein hoher Wert ist zunächst eine Modellausgabe, keine garantierte Trefferwahrscheinlichkeit für Deinen Anwendungsfall. Prüfe daher systematisch:

  1. Referenzfälle: Stelle typische und schwierige Beispiele zusammen, die Fachverantwortliche eindeutig bewertet haben.
  2. Fehlerfolgen: Unterscheide zwischen harmloser Fehlsortierung und Fehlern mit erheblichen betrieblichen Auswirkungen.
  3. Prüfregeln: Lege fest, wann Menschen übernehmen und wann eine automatische Weiterverarbeitung zulässig ist.
  4. Vergleich: Teste, ob einfache Regeln oder ein vorhandenes Klassifikationsverfahren dieselbe Aufgabe ausreichend gut lösen.
  5. Überwachung: Kontrolliere die Qualität auch nach dem Start, insbesondere bei neuen Produkten oder verändertem Sprachgebrauch.

Eine passende KI-Strategie hilft Dir, solche Anwendungen nach Nutzen, Risiko und Datenreife zu priorisieren, statt jedes verfügbare Modell sofort produktiv einzusetzen.

Was das für dich bedeutet

Wenn Deine Unternehmensdaten bereits in Databricks liegen, bietet der Ansatz einen konkreten Einstieg in SQL-gestützte Klassifikation. Starte mit einer eng abgegrenzten Aufgabe, überprüfbaren Kategorien und menschlicher Kontrolle. Entscheide erst nach dem Qualitätstest, welche Schritte Du automatisierst.

Du möchtest klären, ob Deine Azure-Databricks-Umgebung dafür geeignet ist? Mit unserer Databricks-Beratung unterstützen wir Dich bei Architektur, Datenanbindung und der Bewertung eines passenden KI-Anwendungsfalls.

Redaktionelle Einordnung auf Basis eines Beitrags im Databricks-Blog.

Datenplattform & Lakehouse

Ein Datenfundament, auf dem KI und Analytics wirklich tragen.

Databricks oder Fabric, Medallion-Architektur, Governance und Betrieb: Wir bauen deine Datenplattform so, dass der erste produktive Use-Case nicht Jahre, sondern Wochen entfernt ist.

  • Databricks- & Microsoft-Fabric-Expertise
  • Governance, Qualität und Kosten von Anfang an im Griff
  • Plattform und erster Use-Case parallel statt nacheinander