RAG mit SQL Server 2025: KI-Antworten mit Kontext

Große Sprachmodelle (Large Language Models, LLMs) wirken oft beeindruckend, weil sie flüssig formulieren, übersetzen, zusammenfassen und sogar Code erzeugen können. Genau darin liegt aber auch ein Missverständnis: Ein LLM ist kein verlässlicher Wissensspeicher. Es berechnet Wahrscheinlichkeiten für die nächste sinnvolle Textfolge, prüft jedoch keine Fakten und kennt weder die internen Dokumente eines Unternehmens noch aktuelle betriebliche Details. Ohne zusätzlichen Kontext entstehen deshalb Antworten, die zwar plausibel klingen, aber inhaltlich ungenau oder schlicht falsch sein können.

Retrieval Augmented Generation, kurz RAG, schließt genau diese Lücke. Das Sprachmodell bleibt unverändert, erhält aber vor der Generierung gezielt passende Informationen aus einer externen Wissensbasis. Dadurch formuliert es nicht mehr nur aus statistischer Sprachkompetenz heraus, sondern auf Basis realer Inhalte aus Dokumenten, Datenbanken oder internen Systemen. Der entscheidende Vorteil liegt darin, dass Antworten nachvollziehbarer, präziser und häufig auch mit Quellen belegbar werden. Für Unternehmen bedeutet das den Unterschied zwischen allgemeiner KI-Demonstration und produktiv nutzbarem Wissenssystem.

Umsetzung mit Microsoft Technologien

Im Microsoft-Umfeld lässt sich dieses Pattern heute durchgängig umsetzen. Azure OpenAI übernimmt die Sprachverarbeitung, SQL Server 2025 oder Azure AI Search dienen als semantische Wissensbasis, und .NET 10 bildet die Integrationsschicht. Besonders interessant ist dabei, dass SQL Server 2025 nicht mehr nur relationale Daten hält, sondern mit VECTOR-Datentyp, Embedding-Funktionen und semantischer Suche selbst zu einem zentralen Bestandteil der RAG-Architektur wird.

Ein RAG-System besteht im Kern aus fünf Phasen: Ingestion, Embedding, Speicherung, Retrieval und Generierung. In der Ingestion-Phase werden Inhalte aus Quellen wie PDFs, Word-Dateien, Wikis, Ticketsystemen oder relationalen Tabellen aufgenommen. Dieser Schritt klingt banal, ist in der Praxis aber aufwendig. Dokumente enthalten Fußnoten, Zeilenumbrüche, Tabellenreste oder Formatierungsartefakte, die für die KI wertlos oder sogar schädlich sind. Deshalb müssen Texte zunächst extrahiert und bereinigt werden. Bei gescannten Dokumenten kommt zusätzlich OCR zum Einsatz, um überhaupt maschinenlesbaren Text zu gewinnen.

Chunking

Unmittelbar danach folgt das Chunking, also die Zerlegung in kleinere Texteinheiten. Dieser Schritt entscheidet wesentlich über die spätere Antwortqualität. Zu große Chunks vermischen mehrere Themen und verwässern die Semantik. Zu kleine Chunks verlieren den Zusammenhang und liefern dem Modell nur Fragmente. Bewährt haben sich semantisch geschlossene Abschnitte mittlerer Größe, ergänzt um Metadaten wie Quelle, Autor, Zeitstempel oder Vertraulichkeitsstufe. Erst diese Kombination aus Text und Kontext schafft eine Wissensbasis, die sich später sauber filtern, absichern und zurückverfolgen lässt.

In der Embedding-Phase wird jeder Chunk in einen numerischen Vektor übersetzt. Modelle wie text-embedding-3-large oder sql-text-embedding-ada-002 erzeugen dafür typischerweise 1536 Dimensionen (abhängig vom Modell). Der Text wird dadurch nicht inhaltlich gespeichert, sondern mathematisch repräsentiert. Semantisch ähnliche Aussagen liegen im Vektorraum nahe beieinander, auch wenn sie unterschiedliche Begriffe verwenden. Genau deshalb findet eine vektorbasierte Suche später nicht nur identische Wörter, sondern auch inhaltlich verwandte Inhalte.

Wichtig ist dabei Konsistenz. Alle Embeddings innerhalb eines Suchraums müssen mit demselben Modell und idealerweise derselben Modellversion erzeugt worden sein. Andernfalls verlieren Distanzwerte ihre Aussagekraft. Unterschiedliche Dimensionen machen einen Vergleich sogar technisch unmöglich. Ein produktives System braucht deshalb Regeln für Versionierung, Re-Embedding und kontrollierte Migration.

Speicherung im SQL Server

Für die Speicherung gibt es im Microsoft-Stack zwei naheliegende Wege. Azure AI Search ist ein vollständig verwalteter Cloud-Dienst, der semantische Suche, Partitionierung, Ranking und Hybrid Search direkt mitbringt. SQL Server 2025 verfolgt einen anderen, für viele Unternehmen besonders interessanten Ansatz: Die Embeddings werden zusammen mit Text und Metadaten direkt in relationalen Tabellen abgelegt. Der neue VECTOR-Datentyp macht den SQL Server damit selbst zum semantischen Speicher. Bestehende Mechanismen für Backup, Monitoring, Rollen, Auditing und Betrieb bleiben erhalten. Das reduziert zusätzliche Infrastruktur und hält die Architektur näher an der vertrauten Datenplattform.

Retrieval

Beim Retrieval wird für die Benutzerfrage genauso ein Embedding erzeugt wie für die gespeicherten Vektoren. Anschließend wird die semantische Distanz zwischen Anfrage-Vektor und gespeicherten Embeddings berechnet. SQL Server 2025 bietet dafür Funktionen wie VECTOR_DISTANCE() und VECTOR_SEARCH(). Inhaltlich geht es also nicht mehr um exakte Stichwörter, sondern um Bedeutungsnähe. Eine Anfrage zu Datenbankschutz kann dadurch auch Inhalte finden, die von SQL Server Security sprechen, obwohl die Begriffe nicht identisch sind.

Für produktive Systeme sind zwei Suchansätze relevant. Die exakte k-Nearest-Neighbor-Suche vergleicht alle Kandidaten und liefert die präzisesten Ergebnisse, skaliert aber bei großen Datenmengen schlecht. DiskANN arbeitet mit Approximate Nearest Neighbors und nutzt spezialisierte Indizes, um in sehr kurzer Zeit gute Näherungstreffer zu liefern. Für interaktive RAG-Szenarien ist das meist der sinnvollere Weg, auch wenn die Ergebnisse nur genähert sind und es damit passieren kann, das noch bessere Ergebnisse nicht gefunden werden. Geschwindigkeit gegen Präzision!

Ein großer Vorteil der Integration in SQL Server besteht darin, dass semantische Suche mit klassischen Filtern kombiniert werden kann. So lassen sich Ergebnisse nicht nur nach Ähnlichkeit, sondern zugleich nach Zeitraum, Sprache, Dokumenttyp oder Freigabestatus einschränken. Das ist im Unternehmenskontext entscheidend, weil Relevanz nicht nur semantisch, sondern immer auch fachlich und organisatorisch definiert ist.

Generierung

Die letzte Phase ist die Generierung. Das LLM erhält die ursprüngliche Frage zusammen mit den semantisch ermittelten Chunks als Kontextfenster. Dadurch formuliert es Antworten auf Basis der bereitgestellten Inhalte statt aus reinem Weltwissen. Genau hier zeigt sich der eigentliche Nutzen von RAG: weniger Halluzinationen, mehr Präzision und im Idealfall belastbare Quellenhinweise.

In .NET 10 lässt sich die gesamte Pipeline gut strukturieren, etwa mit dem Semantic Kernel. Die einzelnen Phasen können dabei als austauschbare Komponenten oder Plug-ins organisiert werden. Das vereinfacht Tests, erlaubt klare Verantwortlichkeiten und macht Architekturentscheidungen reversibel. So kann beispielsweise das Retrieval zunächst über SQL Server laufen und später, falls nötig, gegen Azure AI Search ausgetauscht werden, ohne dass die Anwendungslogik neu entworfen werden muss.

Der schwierigste Teil eines RAG-Systems liegt allerdings nicht in der Anbindung eines Sprachmodells, sondern in der Qualität der Datenbasis. Schlechte Textextraktion, falsches Chunking, fehlende Metadaten oder unsaubere Berechtigungen führen fast zwangsläufig zu unbefriedigenden Ergebnissen. Ein erfolgreiches RAG-Projekt ist deshalb immer auch ein Projekt für Datenhygiene, Informationsarchitektur und Governance.

Sicherheit und Compliance

Gerade Sicherheit und Compliance dürfen dabei nicht nachträglich ergänzt werden. Unternehmenswissen unterliegt Rollen, Vertraulichkeit und häufig regulatorischen Anforderungen. SQL Server 2025 bringt hier mit Row-Level Security, Rollenmodellen und Auditierbarkeit eine starke Grundlage mit. Embeddings sind zwar kein Klartext, aber auch sie müssen kontrolliert verwaltet werden. Entscheidend ist, dass nur solche Inhalte in Retrieval und Generierung einfließen, die der jeweilige Nutzer tatsächlich sehen darf.

Auch wirtschaftlich ist eine nüchterne Betrachtung wichtig. Der Retrieval-Teil ist meist vergleichsweise günstig und schnell. Die eigentlichen Kosten entstehen beim Large Language Model, weil jede Generierung Tokens verbraucht. Deshalb lohnt es sich, nur die wirklich relevanten Textstücke als Kontext zu übergeben und Prompts bewusst zu gestalten.

Fazit

RAG ist damit weit mehr als ein technischer Trend. Es ist ein Architekturpattern, das Sprachmodelle mit der realen Wissensbasis eines Unternehmens verbindet. Im Microsoft-Stack entsteht daraus eine besonders pragmatische Lösung: Azure OpenAI für Sprache, SQL Server 2025 und Azure AI Search für Semantik und .NET 10 für Integration und Orchestrierung. Der eigentliche Mehrwert liegt nicht in spektakulärer KI, sondern in kontrolliert nutzbarem Wissen.