SQL Server 2025: KI mit Vektoren und externen Modellen

Eine Suche nach Begriffen findet nur, was sprachlich zusammenpasst. Eine semantische Suche soll dagegen auch dann passende Inhalte liefern, wenn Anfrage und Dokument unterschiedliche Wörter verwenden. Dafür benötigen Sie Embeddings, eine geeignete Speicherung und eine Ähnlichkeitssuche. SQL Server 2025 bringt diese Bausteine näher an Ihre relationalen Daten. Externe KI-Modelle lassen sich zudem aus T-SQL ansprechen. Das kann zusätzliche Infrastruktur einsparen – ersetzt aber weder die Modellauswahl noch ein belastbares Betriebs- und Sicherheitskonzept.

KI in SQL Server 2025: Funktionen, Voraussetzungen und Preview-Status

Für datenbankgestützte KI-Anwendungen sind vor allem vier Bausteine relevant:

• Der Datentyp VECTOR speichert numerische Vektoren direkt in einer Tabelle.
• VECTOR_DISTANCE berechnet den Abstand zwischen zwei Vektoren.
• Vektorindizes und approximative Suche sollen ähnliche Vektoren finden, ohne jeden Datensatz vollständig vergleichen zu müssen.
• Externe Modelle und REST-Aufrufe ermöglichen es, KI-Dienste in datenbanknahe Abläufe einzubinden.

Diese Funktionen sind nicht mit einem vollständig in SQL Server eingebauten Sprachmodell gleichzusetzen. Ein Embedding-Modell oder ein generatives Modell läuft weiterhin außerhalb der Datenbank, beispielsweise in Azure oder auf einem eigenen Inferenzserver.

Wichtig ist außerdem die Unterscheidung zwischen verfügbaren Kernfunktionen und Preview-Erweiterungen. Vektorindizes, approximative Suche und die deklarative Einbindung externer Modelle wurden für SQL Server 2025 als Preview-Funktionen eingeführt. Prüfen Sie für Ihren konkreten Build den aktuellen Freigabestatus, die Einschränkungen und gegebenenfalls die erforderliche Aktivierung von Preview-Funktionen.

Übertragen Sie insbesondere Beispiele für Azure SQL Database nicht ungeprüft auf SQL Server. Ähnliche Syntax bedeutet nicht automatisch identischen Funktionsumfang oder dieselben Betriebsvoraussetzungen.

Der VECTOR-Datentyp: Embeddings direkt in SQL Server speichern

Ein Embedding bildet einen Inhalt auf einen numerischen Vektor ab. Inhalte können beispielsweise Produktbeschreibungen, Supportfälle oder Textabschnitte aus Dokumenten sein. Ein geeignetes Modell erzeugt die Vektoren so, dass fachlich ähnliche Inhalte häufig nahe beieinanderliegen.

Mit VECTOR(n) legen Sie die Anzahl der Dimensionen fest. Diese muss zum verwendeten Embedding-Modell beziehungsweise zu dessen konfigurierter Ausgabe passen.

Für eine Dokumentensuche bietet sich beispielsweise eine Tabelle mit folgenden Informationen an:

• Dokument- und Abschnitts-ID
• Text des Abschnitts
• Mandant, Sprache und Dokumenttyp
• verwendetes Embedding-Modell einschließlich Version
• Embedding und Erstellungszeitpunkt

Die relationalen Attribute bleiben wichtig. Sie steuern Berechtigungen, begrenzen den Suchraum und ermöglichen nachvollziehbare Ergebnisse. Eine Vektorsuche ersetzt keine saubere Datenmodellierung.

Ein häufiger Projektfehler: Embeddings verschiedener Modelle werden in derselben Suche vermischt. Auch bei gleicher Dimensionszahl sind deren Koordinatenräume nicht automatisch vergleichbar. Ein Modellwechsel erfordert deshalb typischerweise eine erneute Berechnung der gespeicherten Embeddings und eine kontrollierte Migration.

Speichern Sie außerdem nicht zwangsläufig ein vollständiges Handbuch als einzelnes Embedding. Für viele Suchanwendungen sind sinnvoll abgegrenzte Textabschnitte geeigneter. Die Abschnittsbildung beeinflusst die Trefferqualität erheblich.

T-SQL-Kurzbeispiel: Ähnlichkeit mit VECTOR_DISTANCE berechnen

Das folgende Beispiel verwendet dreidimensionale, künstliche Vektoren. Es demonstriert die Syntax, nicht die Qualität eines realen Embedding-Modells.

CREATE TABLE #Dokumentvektoren
(
    DokumentID int NOT NULL PRIMARY KEY,
    Bezeichnung nvarchar(100) NOT NULL,
    Embedding VECTOR(3) NOT NULL
);

INSERT INTO #Dokumentvektoren
    (DokumentID, Bezeichnung, Embedding)
VALUES
    (1, N'Beispiel A', CAST('[1.0, 0.0, 0.0]' AS VECTOR(3))),
    (2, N'Beispiel B', CAST('[0.8, 0.2, 0.0]' AS VECTOR(3))),
    (3, N'Beispiel C', CAST('[0.0, 1.0, 0.0]' AS VECTOR(3)));

DECLARE @Suchvektor VECTOR(3) =
    CAST('[1.0, 0.0, 0.0]' AS VECTOR(3));

SELECT TOP (3)
    DokumentID,
    Bezeichnung,
    VECTOR_DISTANCE(
        'cosine',
        Embedding,
        @Suchvektor
    ) AS Distanz
FROM #Dokumentvektoren
ORDER BY Distanz ASC, DokumentID ASC;

DROP TABLE #Dokumentvektoren;

Bei der Cosine Distance bedeutet ein kleinerer Wert eine größere Ähnlichkeit der Vektorrichtung. Neben 'cosine' unterstützt VECTOR_DISTANCE auch 'euclidean' und 'dot'. Wählen Sie die Metrik nach den Empfehlungen des Embedding-Modells.

Verwechseln Sie eine Distanz nicht mit einer Wahrscheinlichkeit: Ein Wert von beispielsweise 0,2 bedeutet nicht „80 Prozent fachlich korrekt“. Geeignete Schwellenwerte müssen Sie anhand repräsentativer Anfragen und bewerteter Treffer bestimmen.

Das Beispiel berechnet die Distanz für alle berücksichtigten Zeilen und sortiert anschließend das Ergebnis. Für überschaubare Datenmengen oder stark eingeschränkte Suchräume kann dieses exakte Vorgehen bereits ausreichend sein.

Vektorindizes: Schnellere Suche und Abwägung zwischen Tempo und Genauigkeit

Mit wachsendem Datenbestand werden vollständige Distanzberechnungen teuer. Vektorindizes unterstützen eine Approximate Nearest Neighbor Search, kurz ANN. Dabei wird der Suchraum so erschlossen, dass nicht jeder Vektor vollständig verglichen werden muss.

Der Gewinn an Geschwindigkeit hat einen Preis: Die Suche garantiert nicht, immer dieselben nächsten Nachbarn wie eine vollständige Berechnung zu finden. Eine zentrale Qualitätsgröße ist deshalb der Recall – also der Anteil der tatsächlich nächsten Treffer, den die approximative Suche wiederfindet.

Wichtig für die Implementierung: Erwarten Sie nicht, dass eine vorhandene Abfrage mit ORDER BY VECTOR_DISTANCE(...) allein durch das Anlegen eines Vektorindex automatisch zur ANN-Suche wird. Für die indexgestützte approximative Suche ist die dafür vorgesehene VECTOR_SEARCH-Funktion relevant. Beachten Sie deren dokumentierte Syntax und Einschränkungen für Ihren Build.

Vergleichen Sie vor einer Einführung:

• Laufzeit und Ressourcenverbrauch
• Trefferqualität gegenüber einer exakten Referenzsuche
• Verhalten bei zusätzlichen Filtern
• Aufwand für Aufbau und Pflege des Index

Gerade Mandanten- oder Berechtigungsfilter verdienen Aufmerksamkeit. Werden Kandidaten zunächst approximativ bestimmt und erst danach eingeschränkt, können zu wenige zulässige Treffer übrig bleiben. Prüfen Sie deshalb nicht nur ungefilterte Demonstrationsabfragen, sondern Ihre tatsächlichen Suchfälle.

Externe KI-Modelle aus T-SQL aufrufen: Einrichtung und Einsatzmöglichkeiten

SQL Server 2025 bietet unterschiedliche Wege zur Modellanbindung. Mit sp_invoke_external_rest_endpoint lassen sich unterstützte HTTPS-Endpunkte aufrufen. Darauf aufbauend ermöglichen deklarierte externe Modelle eine stärker integrierte Nutzung, etwa zur Embedding-Erzeugung mit AI_GENERATE_EMBEDDINGS.

Ein externes Modell wird dabei durch Metadaten beschrieben. Dazu gehören insbesondere Endpunkt, API-Format, Modelltyp und gegebenenfalls ein zugeordnetes Credential. Die Definition hostet das Modell nicht in SQL Server.

Für die Einrichtung benötigen Sie typischerweise:

1. einen erreichbaren, unterstützten Modellendpunkt,
2. eine zur Schnittstelle passende Authentifizierung,
3. die erforderliche Server- beziehungsweise Datenbankkonfiguration,
4. Berechtigungen für Credentials, Modellobjekte und Aufrufe,
5. getestete Fehler- und Wiederholungsbehandlung.

Bei REST-Aufrufen muss unter anderem die Serveroption external rest endpoint enabled passend konfiguriert sein. Die konkrete Einrichtung hängt vom gewählten Integrationsweg ab.

Praktische Einsatzmöglichkeiten sind das Erzeugen neuer Embeddings, das Klassifizieren eingehender Texte oder das Vorbereiten einer Retrieval-Augmented-Generation-Anwendung. Bei RAG liefert SQL Server passende Inhalte; ein generatives Modell formuliert daraus eine Antwort.

Vermeiden Sie Modellaufrufe pro Zeile in interaktiven Massenabfragen. Netzwerkwartezeiten, Rate Limits und Dienstfehler werden sonst unmittelbar zum Datenbankproblem. Für größere Mengen sind asynchrone Verarbeitung und wiederanlaufbare Batches meist geeigneter.

Betrieb und Sicherheit: Berechtigungen, Datenschutz und Kosten

Ein lokaler SQL Server bedeutet nicht automatisch lokale KI-Verarbeitung. Sobald Sie Texte an einen externen Dienst senden, verlassen diese die Datenbankumgebung. Prüfen Sie Datenkategorien, Verarbeitungsregion, Aufbewahrung und vertragliche Regelungen des Anbieters.

Weitere Betriebsregeln:

• Secrets nicht im Anwendungscode speichern: Verwenden Sie geeignete Credentials und beschränken Sie deren Verwaltung.
• Berechtigungen trennen: Nicht jeder Benutzer, der suchen darf, benötigt auch das Recht, externe Dienste aufzurufen.
• Berechtigungen vor der Modellausgabe durchsetzen: Ein Sprachmodell ist keine Zugriffskontrolle.
• Embedding-Erzeugung entkoppeln: Halten Sie externe Aufrufe aus lang laufenden fachlichen Transaktionen heraus.
• Fehler sichtbar machen: Protokollieren Sie Status, Modellversion und Verarbeitungszustand, ohne unnötig sensible Inhalte mitzuschreiben.

Auch Embeddings sollten Sie nicht pauschal als anonym betrachten. Sie sind abgeleitete Daten und können weiterhin schutzbedürftig sein.

Kalkulieren Sie neben Modellaufrufen auch Speicher, Indexpflege, CPU, Backups und erneute Embedding-Erzeugung nach Modellwechseln. Änderungsprüfungen und persistierte Ergebnisse helfen, identische Inhalte nicht wiederholt kostenpflichtig zu verarbeiten.

Für wen lohnt sich das?

Für DBAs lohnt sich die Beschäftigung, sobald Such- oder KI-Workloads auf bestehenden relationalen Daten aufsetzen. Im Mittelpunkt stehen Ressourcenbedarf, Berechtigungen, Wiederherstellbarkeit und die Freigabe neuer Funktionen.

Für Entwickler ist die Integration attraktiv, wenn relationale Filter und semantische Suche eng zusammengehören. Eine zusätzliche Vektordatenbank ist dann nicht zwangsläufig erforderlich.

Für IT-Entscheider zählt die Gesamtarchitektur: Die vorhandene SQL-Server-Plattform kann Entwicklung und Betrieb vereinfachen. Bei spezialisierten Anforderungen oder sehr großen Suchlasten bleibt ein Vergleich mit eigenständigen Suchdiensten sinnvoll.

Fazit

SQL Server 2025 verbindet relationale Datenhaltung mit Vektorsuche und externer Modellnutzung. Beginnen Sie mit einem begrenzten Anwendungsfall, einer exakten Referenzsuche und messbaren Qualitätskriterien. Entscheiden Sie erst danach über Vektorindizes und automatisierte Modellaufrufe. So wird aus einer technischen Möglichkeit eine belastbare Anwendung – mit kontrollierbarer Trefferqualität, nachvollziehbaren Kosten und klaren Sicherheitsgrenzen.

Sie möchten tiefer einsteigen? In unseren Schulungen vermitteln wir SQL Server, Power BI und KI praxisnah – online oder bei Ihnen vor Ort. Fragen? Kontaktieren Sie uns oder buchen Sie ein kostenloses Info-Gespräch.