RAG statt Copy & Paste: Wie KI wirklich mit Unternehmenswissen arbeitet

In Teil 2 ist ein geordneter, lokaler Wissensbestand entstanden – Markdown-Dateien mit Prozessen, Kundenwissen und Entscheidungen. Was noch fehlt, ist die Brücke zwischen diesem Wissen und einem Sprachmodell. Diese Brücke heißt RAG: Retrieval-Augmented Generation. Dieser Teil erklärt, wie sie technisch funktioniert – ohne Buzzwords, aber mit genug Tiefe, um die Architektur tatsächlich zu verstehen.

Der Begriff klingt komplizierter, als die Idee ist. „Retrieval” heißt Abrufen, „Augmented Generation” heißt angereicherte Erzeugung. Statt das Modell aus dem Gedächtnis antworten zu lassen, holt man vor jeder Antwort die passenden Stellen aus dem eigenen Wissen und legt sie dem Modell vor. Das Modell antwortet dann nicht aus seinem allgemeinen Training, sondern auf Basis konkret bereitgestellter Fakten. Eine ausführlichere, technische Grundlage liefert der Artikel RAG technisch erklärt – ohne Buzzwords; hier liegt der Fokus auf der Anwendung auf Unternehmenswissen.

Warum LLMs ohne RAG halluzinieren

Ein Sprachmodell hat kein Faktengedächtnis im eigentlichen Sinne. Es hat während des Trainings statistische Muster der Sprache gelernt und erzeugt Antworten, indem es das jeweils wahrscheinlichste nächste Wort vorhersagt. Das funktioniert verblüffend gut für allgemeines Wissen, weil dieses im Trainingsmaterial millionenfach vorkam.

Für unternehmensspezifische Fragen bricht dieser Mechanismus zusammen. Das Modell hat den konkreten Kunden, den konkreten Vertrag, den internen Prozess nie gesehen. Gefragt danach, erzeugt es trotzdem eine Antwort – die plausibel klingt, aber erfunden ist. Das ist keine Fehlfunktion, sondern die direkte Folge des Funktionsprinzips: Ein Modell, das immer das wahrscheinlichste nächste Wort liefert, hat keinen eingebauten Begriff von „das weiß ich nicht”.

Embeddings: Bedeutung als Zahlen

Der Kern von RAG ist eine Technik namens Embedding. Ein Embedding-Modell wandelt einen Textabschnitt in eine lange Liste von Zahlen um – einen Vektor. Das Besondere: Texte mit ähnlicher Bedeutung erhalten ähnliche Vektoren. „Wie storniere ich eine Bestellung?” und „Bestellung rückgängig machen” landen im Zahlenraum dicht beieinander, obwohl sie kaum ein Wort teilen.

Das ist der entscheidende Unterschied zur klassischen Stichwortsuche. Eine Volltextsuche findet nur, was wörtlich übereinstimmt. Die semantische Suche über Embeddings findet, was gemeint ist. Für Unternehmenswissen ist das zentral, weil Menschen Fragen selten in genau den Worten stellen, in denen die Antwort dokumentiert wurde.

Chunking: Wissen in verdauliche Stücke teilen

Bevor Embeddings entstehen, muss das Wissen zerlegt werden. Ein komplettes Prozessdokument als ein einziger Vektor wäre zu grob – die Bedeutung verwischt. Deshalb wird der Text in Abschnitte (Chunks) geteilt, typischerweise einige Absätze groß, oft mit leichter Überlappung, damit kein Zusammenhang an der Schnittkante verloren geht.

Hier zahlt sich die Vorarbeit aus Teil 2 aus: Sauber mit Markdown-Überschriften gegliederte Dokumente lassen sich entlang ihrer Struktur zerlegen. Die Gliederung, die für menschliche Leser gedacht war, wird zur Schnittlinie für die Maschine. Schlecht strukturiertes Wissen erzeugt schlechte Chunks – und damit schlechte Antworten.

Die Vektordatenbank: durchsuchbarer Bedeutungsraum

Die erzeugten Vektoren werden in einer Vektordatenbank abgelegt. Ihre Aufgabe ist es, zu einer Anfrage blitzschnell die ähnlichsten gespeicherten Vektoren zu finden – also die inhaltlich passendsten Wissens-Chunks. Bei einer Frage wird die Frage selbst in einen Vektor umgewandelt und die Datenbank liefert die nächstgelegenen Treffer zurück.

Verbreitete Optionen sind Qdrant, Weaviate und Chroma – allesamt selbst hostbar, was zur Datensouveränitäts-Logik dieser Serie passt. Für überschaubare Wissensbestände reicht oft schon eine schlanke, lokale Lösung; eine große verteilte Datenbank ist erst bei entsprechendem Volumen nötig.

Die komplette Pipeline

Setzt man die Bausteine zusammen, ergibt sich eine klare Kette vom Wissen bis zur Antwort:

Zwei Phasen sind dabei zu unterscheiden. Die Indexierung (Chunking, Embeddings, Speichern) läuft einmalig und danach bei jeder Wissensänderung – idealerweise automatisch, wenn eine Markdown-Datei sich ändert. Die Abfrage (Frage einbetten, abrufen, Antwort erzeugen) läuft bei jeder Nutzeranfrage. Diese Trennung erklärt, warum RAG-Systeme schnell antworten können: Die teure Arbeit ist bereits erledigt, bevor die Frage gestellt wird.

Werkzeuge im Obsidian-Umfeld

Für den praktischen Einstieg muss man diese Pipeline nicht von Grund auf bauen. Im Obsidian-Ökosystem gibt es fertige Bausteine. Plugins wie Smart Connections oder Copilot for Obsidian bringen Embedding-Erzeugung und semantische Suche direkt in den Vault – mit der Option, ein lokales oder ein API-basiertes Modell anzubinden. Das ist die „praktisch nutzbare” Ebene aus Teil 1: überschaubarer Aufwand, schneller Nutzen.

Für die KI-Modelle selbst gibt es zwei grundsätzliche Wege. Über API-Anbindung an Claude, GPT oder Gemini bekommt man die stärksten Modelle ohne eigene Hardware – um den Preis, dass Daten das Haus verlassen. Über lokale Modelle via Ollama bleibt alles auf der eigenen Maschine – um den Preis von etwas weniger Spitzenleistung und der nötigen Hardware. Welcher Weg richtig ist, hängt von der Sensibilität der Daten ab, nicht von der Mode.

Wo Mistral ins Spiel kommt

Für die lokale und europäische Variante ist Mistral besonders interessant, und zwar aus einem strukturellen Grund: Mistral positioniert sich eher als Infrastruktur denn als Plattform. Während OpenAI und Anthropic vor allem geschlossene Plattformen bauen, liefert Mistral offene Modelle, die man selbst betreiben kann.

Konkret relevant für ein Unternehmens-RAG sind mehrere Bausteine. Mistral Small und die kompakte Ministral-Familie laufen auf vertretbarer Hardware und eignen sich gut für die Antwortgenerierung in einem lokalen Setup. Mistral Embed liefert die Embeddings – also genau den Schritt, der das Wissen durchsuchbar macht. Dazu kommen OCR-Fähigkeiten für das Erschließen von PDFs und Scans sowie die Option auf EU-Hosting, was den DSGVO-Rahmen deutlich vereinfacht.

Das heißt nicht, dass Mistral immer die richtige Wahl ist. Eine ehrliche Abwägung, wann sich der Aufwand lohnt und wann ein US-Anbieter pragmatischer ist, steht in Braucht man Mistral überhaupt?. Für den datenschutzsensiblen, selbst gehosteten Fall ist Mistral aber oft das stärkere europäische Angebot.

Quellen statt Behauptungen

Ein unterschätzter Vorteil von RAG: Weil die Antwort auf konkret abgerufenen Chunks beruht, lässt sich angeben, woher sie stammt. Ein gut gebautes System nennt die Quelldokumente und macht die Antwort damit überprüfbar. Das verwandelt die KI von einer Black Box, der man glauben muss, in ein Werkzeug, dessen Aussagen sich kontrollieren lassen.

Das macht RAG nicht unfehlbar. Wenn der Retriever die falschen Chunks liefert oder das Wissen schlicht lückenhaft ist, kann auch ein RAG-System danebenliegen. Wo die Grenzen liegen und wie viel RAG am Halluzinations-Problem wirklich ändert, behandelt Reduziert RAG wirklich Halluzinationen? – die kurze Antwort: deutlich, aber nicht vollständig.

Einordnung

RAG ist der technische Mechanismus, der aus einem geordneten Wissensbestand ein befragbares Unternehmens-Gehirn macht. Die Architektur ist überschaubar – Chunking, Embeddings, Vektordatenbank, Retrieval, Generierung – und in einer ersten, praktisch nutzbaren Form mit vorhandenen Werkzeugen erreichbar.

Das eigentlich Anspruchsvolle ist nicht die Technik, sondern die Qualität des zugrunde liegenden Wissens. Ein RAG-System ist eine Verstärkung des vorhandenen Wissens, kein Ersatz für dessen Pflege. Teil 4 blickt darauf, wie sich solche Systeme weiterentwickeln – von der befragbaren Wissensbasis zur eigentlichen KI-Infrastruktur eines Unternehmens.