Was RAG konkret bedeutet
Ein allgemeines Sprachmodell kennt Ihre aktuelle Preisliste, Ihre Arbeitsanweisung oder das Handbuch einer intern eingesetzten Maschine nicht automatisch. Bei RAG werden diese Informationen außerhalb des Modells in einer durchsuchbaren Wissensbasis bereitgestellt. Kommt eine Frage, sucht das System zuerst relevante Ausschnitte und ergänzt damit die Eingabe an das Sprachmodell. Das Modell formuliert anschließend eine Antwort auf Basis dieses zusätzlichen Kontexts.
Die Dokumentation zu Amazon Bedrock Knowledge Bases beschreibt den typischen Ablauf: Dokumente werden in kleinere Textabschnitte zerlegt, als Vektoren indexiert und anhand semantischer Ähnlichkeit zur Frage gesucht. Die OpenAI-Dokumentation zu Retrieval erläutert denselben Grundmechanismus für Vector Stores; hinzugefügte Dateien werden dort für die Suche zerlegt, eingebettet und indexiert.
RAG ist damit keine eigene Modellart. Es ist ein Systemmuster rund um ein Sprachmodell. Die Wissensbasis kann bei einem Cloud-Anbieter liegen, in einer vorhandenen Suchplattform aufgebaut oder als individuelle Lösung betrieben werden. Die technische Wahl folgt erst, wenn Quellen, Nutzerkreis und Qualitätsanforderungen geklärt sind.
RAG, Training und Fine-Tuning sind verschiedene Dinge
Die Begriffe werden in Projekten häufig vermischt. Bei RAG bleiben die Dokumente in einer separaten Wissensbasis. Sie werden bei Bedarf gesucht und als Kontext für eine einzelne Antwort verwendet. Ein geändertes Dokument kann neu indexiert werden, ohne das zugrunde liegende Sprachmodell neu zu trainieren.
Fine-Tuning verändert dagegen das Verhalten eines Modells anhand von Beispielen. Das kann etwa für wiederkehrende Ausgabeformate oder sehr spezifische Aufgaben interessant sein. Es ist normalerweise nicht der beste Weg, um laufend wechselnde Handbücher, Preislisten oder Richtlinien als Faktenbestand bereitzustellen. Für solches Wissen ist ein aktualisierbarer Suchbestand leichter zu kontrollieren.
Auch Datenschutz und Speicherung müssen getrennt betrachtet werden. „Die Daten trainieren das Modell nicht“ bedeutet nicht automatisch, dass keine Dateien oder Anwendungsdaten gespeichert werden. Anbieter unterscheiden zwischen Training, Protokollen und gespeichertem Anwendungszustand. Die aktuellen Angaben stehen beispielsweise in den OpenAI API Data Controls. Vor einer Entscheidung sind Vertrag, gewählter Dienst, Aufbewahrung, Löschmöglichkeit, Region und tatsächliche Konfiguration zu prüfen. Der bestehende Beitrag über KI-Datenschutz in Unternehmen ordnet diese Fragen ausführlicher ein.
Für welche Aufgaben RAG im KMU brauchbar sein kann
Ein geeigneter Anwendungsfall hat einen überschaubaren Nutzerkreis, wiederkehrende Fragen und eine bekannte Menge verlässlicher Unterlagen. Gute Kandidaten sind interne Arbeitsanweisungen, freigegebene Produktunterlagen, Servicehandbücher, Qualitätsdokumente oder ein gepflegtes Prozesshandbuch.
Ein Serviceteam könnte beispielsweise fragen, welche Prüfschritte bei einer bestimmten Fehlermeldung vorgesehen sind. Das System sucht die passende Version des Handbuchs, nennt die Fundstelle und formuliert eine kurze Antwort. Eine Personalabteilung könnte freigegebene Fragen zu Reisekosten oder Weiterbildung beantworten lassen. Kritische Einzelfälle werden weiterhin an die zuständige Person geleitet.
Weniger geeignet ist RAG, wenn die eigentliche Information kaum dokumentiert ist, sich widerspricht oder nur im Erfahrungswissen einzelner Personen steckt. Auch ein ungeklärter Prozess wird durch eine Wissensbasis nicht zuverlässig. Dann ist zuerst zu klären, welcher Ablauf gelten soll, wer ihn verantwortet und welche Unterlage verbindlich ist. Der Artikel Warum ein unklarer Prozess durch KI nicht besser wird zeigt dafür eine kompakte Methode.
Die Dokumentqualität entscheidet über die Antwortqualität
Eine Dateiablage ist noch keine Wissensbasis. Veraltete Versionen, doppelte Dokumente, unklare Gültigkeitsbereiche und schlecht lesbare Scans führen zu falschen oder widersprüchlichen Treffern. Vor einem Pilot sollten deshalb Dokumente ausgewählt werden, die fachlich freigegeben, ausreichend aktuell und technisch lesbar sind.
Für jedes Dokument helfen wenige Metadaten: Dokumenttyp, verantwortliche Stelle, Gültigkeitsbeginn, Version, Sprache, Produkt oder Standort und gegebenenfalls eine Vertraulichkeitsstufe. Solche Angaben unterstützen Filter. Eine Frage zur aktuellen Wartungsanweisung muss keine ersetzte Fassung oder Unterlagen eines anderen Produkts durchsuchen.
Auch die Aufteilung in Textabschnitte beeinflusst die Suche. Zu kleine Abschnitte verlieren wichtigen Zusammenhang; zu große Abschnitte bringen viel irrelevanten Text in die Antwort. Tabellen, Fußnoten, gescannte Seiten und mehrspaltige PDFs brauchen besondere Aufmerksamkeit. Ein Pilot sollte deshalb verschiedene Dokumenttypen enthalten, darunter bewusst schwierige Beispiele.
Berechtigungen müssen bis zur einzelnen Antwort reichen
Ein häufiger Fehler besteht darin, einen gemeinsamen Suchindex aufzubauen und alle angemeldeten Personen darin suchen zu lassen. Das kann Inhalte sichtbar machen, für die jemand in der ursprünglichen Ablage keine Leseberechtigung hat. Die Anwendung braucht daher ein Berechtigungskonzept, das bereits bei der Suche greift. Eine nachträgliche Warnung im Antworttext schützt vertrauliche Inhalte nicht.
Die Microsoft-Dokumentation zu dokumentbezogener Zugriffskontrolle in Azure AI Search zeigt mehrere technische Muster: Berechtigungsinformationen werden mit Dokumenten indexiert und bei der Abfrage gegen die Identität der anfragenden Person geprüft. Einzelne native Varianten waren am 9. September 2026 noch als Vorschau gekennzeichnet. Das konkrete Produktdetail kann sich ändern; die fachliche Anforderung bleibt gleich: Die Suche darf nur Inhalte liefern, die diese Person lesen darf.
Für einen kleinen Pilot kann eine getrennte Wissensbasis pro Nutzergruppe einfacher und sicherer sein als ein komplexes Regelwerk. Sobald mehrere Abteilungen, vertrauliche Kundendokumente oder personenbezogene Daten beteiligt sind, gehören Identitäten, Gruppenrechte, Protokollierung und Berechtigungsänderungen ausdrücklich in den Testplan.
Quellenbelege machen Antworten prüfbar, aber nicht automatisch richtig
Eine gute RAG-Anwendung nennt Dokumentname, Version und möglichst die konkrete Fundstelle. Die OpenAI-Dokumentation zu File Search beschreibt Antworten mit Dateizitaten; auch Amazon Bedrock kann Antworten mit Verweisen auf die zugrunde liegenden Quellen ausgeben. Solche Belege verkürzen die Prüfung und helfen, einen Treffer von einer bloß plausiblen Formulierung zu unterscheiden.
Ein Zitat ist jedoch kein Gütesiegel. Die gefundene Stelle kann veraltet, aus dem Zusammenhang gerissen oder für den konkreten Fall unpassend sein. Die Oberfläche sollte deshalb Unsicherheit sichtbar machen, Originalstellen leicht öffnen lassen und bei fehlender Grundlage eine klare Nicht-Antwort erlauben. Ein System, das bei jeder Frage selbstbewusst Text liefert, ist im Betrieb schwerer zu kontrollieren als eines, das Grenzen benennt.
So lässt sich ein RAG-Pilot sinnvoll testen
Ein Pilot braucht einen Testkatalog aus echten Fragen. Dazu gehören häufige Standardfragen, mehrdeutige Formulierungen, Fragen mit mehreren notwendigen Quellen, veraltete Begriffe, bewusst nicht beantwortbare Fragen und Fälle, die vertrauliche Dokumente betreffen. Für jede Frage wird vorab festgehalten, welche Antwort oder welche Fundstellen erwartet werden.
Die Prüfung sollte Suche und Antwort getrennt betrachten. Hat das System die richtige Passage gefunden? Fehlt ein entscheidendes Dokument? Stützt die Passage tatsächlich die formulierte Antwort? Sind die Quellen vollständig und korrekt zugeordnet? Die AWS-Dokumentation zu RAG-Evaluationen unterscheidet entsprechend Kennzahlen für Relevanz und Abdeckung der gefundenen Texte sowie Korrektheit, Vollständigkeit, Quellentreue und Qualität der Zitate.
Für einen KMU-Pilot reichen oft 30 bis 60 repräsentative Fragen, wenn sie sorgfältig ausgewählt und fachlich geprüft werden. Wichtiger als eine einzelne Durchschnittsnote ist die Fehlerverteilung: Bei welchen Dokumenttypen, Themen oder Formulierungen versagt das System? Ein sicherheitskritischer Fehler kann schwerer wiegen als zehn gut beantwortete Routinefragen.
Aktualisierung und Betrieb gehören von Anfang an dazu
Nach einer überzeugenden Demo beginnt die laufende Arbeit. Neue Dokumente müssen aufgenommen, ersetzte Versionen entfernt und Änderungen an Berechtigungen synchronisiert werden. Fehlerhafte Antworten brauchen einen nachvollziehbaren Meldeweg. Zudem sollte klar sein, wer den Wissensbestand fachlich betreut und wer die technische Verarbeitung überwacht.
Hilfreiche Betriebskennzahlen sind der Anteil der Fragen mit brauchbarer Quelle, die Zahl unbeantwortbarer Fragen, gemeldete Fehlantworten, überholte Fundstellen und die Zeit bis zur Aktualisierung nach einer Dokumentänderung. Nutzerfeedback allein genügt nicht: Eine angenehm formulierte Antwort kann sachlich falsch sein, während eine knappe Antwort mit guter Quelle ihren Zweck erfüllt.
Kosten entstehen durch Dokumentverarbeitung, Speicher, Suchabfragen, Modellnutzung, Integration und Betreuung. Die günstigste Lösung ist deshalb selten anhand eines einzelnen Token- oder Speicherpreises erkennbar. Entscheidend ist, wie viele Personen das System nutzen, wie häufig der Bestand wechselt und wie aufwendig Berechtigungen und Qualitätskontrollen sind.
Typische Fehlerbilder und klare Abbruchkriterien
Wenn Antworten gut klingen, aber regelmäßig auf falsche Versionen verweisen, liegt das Problem meist im Bestand oder in der Suche. Werden passende Quellen gefunden und trotzdem falsch zusammengefasst, betrifft der Fehler eher Prompt, Modell oder Antwortlogik. Diese Trennung verhindert, dass jede Schwäche mit einem größeren Modell beantwortet wird. Sie zeigt auch, ob eine technische Anpassung genügt oder zuerst Dokumente und Verantwortlichkeiten bereinigt werden müssen.
Ein Pilot sollte pausieren, wenn vertrauliche Inhalte bei unberechtigten Testpersonen erscheinen, kritische Antworten keine überprüfbare Fundstelle haben oder veraltete Dokumente trotz Kennzeichnung bevorzugt werden. Gleiches gilt, wenn niemand die Wissensbasis nach Projektende pflegen kann. Niedrige Trefferquoten bei einzelnen Fragearten sind dagegen ein Anlass zum Eingrenzen: bestimmte Dokumenttypen ausschließen, Metadaten ergänzen oder den Anwendungsfall auf gut dokumentierte Routinen beschränken.
Ein pragmatischer Entscheidungsrahmen
RAG passt, wenn sechs Fragen überwiegend mit Ja beantwortet werden können: Gibt es einen abgegrenzten Dokumentbestand? Sind die Unterlagen fachlich verlässlich? Treten ähnliche Fragen regelmäßig auf? Können erwartete Antworten und Quellen beschrieben werden? Lassen sich Berechtigungen technisch durchsetzen? Gibt es eine verantwortliche Person für Aktualisierung und Fehler?
Wenn zwei oder mehr Grundlagen fehlen, sollte das Vorhaben mit Dokument- und Prozessarbeit beginnen. Wenn die Grundlagen vorhanden sind, reicht für den Einstieg ein begrenzter Ablauf: eine Nutzergruppe, ein klarer Dokumenttyp, ein Testkatalog und eine Oberfläche, die Quellen offenlegt. Erst nach bestandener Prüfung werden weitere Datenquellen oder automatisierte Folgeaktionen ergänzt.
Jacob Damböck ordnet solche Vorhaben im Rahmen einer KI-Potenzialanalyse oder einer technisch konkreteren OpenAI-API-Beratung ein. Dabei steht zuerst die Frage im Mittelpunkt, ob RAG für den vorhandenen Wissensbestand und Arbeitsablauf tatsächlich die passende Lösung ist.
Primärquellen und redaktionelle Einordnung
Die technischen Beschreibungen zu Retrieval, Vector Stores, Zitaten, Zugriffskontrolle und Evaluationsmaßen stammen aus den verlinkten Herstellerdokumentationen von OpenAI, Microsoft und Amazon Web Services. Produktstatus, Funktionsumfang und Aufbewahrungsregeln wurden am 9. September 2026 geprüft und können sich ändern.
Die Auswahlkriterien, Pilotgröße und empfohlenen Betriebskennzahlen sind die redaktionelle Einordnung von Jacob Damböck. Sie sind kein allgemeingültiger Standard und ersetzen keine Datenschutz-, Rechts- oder Sicherheitsprüfung für den konkreten Einsatz.