Ein praktisches RAG System Beispiel: So gehts!

Die Wissensquellen für das RAG-System festlegen

Für unser Beispiel soll ein interner Assistent Fragen zur Urlaubsplanung beantworten. Er darf deshalb nicht auf beliebige Webseiten oder ungeprüfte Texte zugreifen. Entscheidend sind die Dokumente, die im Unternehmen tatsächlich gelten.

Geeignet sind etwa die aktuelle Urlaubsrichtlinie, Regelungen zu Elternzeit und Krankheit, Hinweise aus dem Personalhandbuch sowie verbindliche Informationen aus dem Intranet. Ergänzende FAQ-Dokumente können helfen. Alte Rundmails gehören dagegen nur dann in den Bestand, wenn ihr Gültigkeitszeitraum eindeutig feststeht.

Relevanz vor Datenmenge

Ein großer Dokumentbestand macht ein RAG-System nicht automatisch besser. Widersprüchliche oder veraltete Inhalte erhöhen vielmehr das Risiko falscher Antworten. Für den Start reicht ein klar abgegrenztes Set aus zehn bis dreißig geprüften Dokumenten. So lässt sich leichter erkennen, ob jede Quelle wirklich einen Nutzen bringt.

Vor dem Import sollte jedes Dokument einige Metadaten erhalten:

• Dokumenttyp: Richtlinie, FAQ, Vertragshinweis oder Formular
• Gültig ab: Datum, ab dem die Information gilt
• Gültig bis: Ablaufdatum oder Kennzeichnung „unbegrenzt“
• Verantwortliche Stelle: etwa Personalabteilung oder Rechtsabteilung
• Zielgruppe: alle Beschäftigten, Führungskräfte oder bestimmte Standorte
• Freigabestatus: Entwurf, geprüft oder verbindlich

Diese Angaben sind später mehr als Ordnungshilfe. Das System kann damit eine alte Regel aus den Treffern ausschließen oder eine standortbezogene Vorschrift bevorzugen.

Strukturierte Daten getrennt behandeln

Tabellen und Datenbanken sollten nicht wie normale Textdateien behandelt werden. Für die Frage „Wie viele Urlaubstage habe ich noch?“ braucht der Assistent zum Beispiel den Kontostand einer Person. Diese Information gehört in eine geschützte Anwendungsschnittstelle, nicht in einen frei durchsuchbaren Dokumentindex.

Richtlinien liefern die Regeln, ein Personalsystem individuelle Werte. Erst beide Informationen zusammen ergeben eine brauchbare Antwort. Dadurch sinkt das Risiko, dass vertrauliche Personaldaten versehentlich in allgemeine Suchergebnisse gelangen.

Zugriffsrechte bereits an der Quelle übernehmen

Ein Dokumentindex darf keine neue Berechtigungsschicht erzeugen, die bestehende Rechte aushebelt. Beim Einlesen sollte jede Datei deshalb mit Rollen, Abteilungen oder Nutzergruppen verknüpft werden. Eine Führungskraft darf andere Inhalte sehen als ein externes Teammitglied.

Der Suchdienst filtert Dokumente bereits vor der Antworterstellung. Ein Modell erhält dann nur Quellen, die der jeweiligen Person angezeigt werden dürfen. Diese Regel ist besonders wichtig bei Gehaltsbändern, Betriebsvereinbarungen und personenbezogenen Fällen.

Eine belastbare Quellenliste erstellen

Für das Urlaubsbeispiel könnte die erste Quellenliste so aussehen:

• Urlaubsrichtlinie, Version 4.2, gültig ab 1. Januar 2026
• FAQ zur Übertragung von Resturlaub, geprüft am 12. Februar 2026
• Regelung für Teilzeitkräfte, gültig für den Standort Berlin
• Hinweise zur Genehmigung durch Vorgesetzte
• API-Ausgabe des persönlichen Urlaubskontos

Jede Quelle bekommt einen Besitzer und einen klaren Prüfzeitpunkt. Fehlt diese Verantwortung, veraltet der Bestand leise. Bei internen Wissenssystemen ist das ein häufiger Stolperstein: Nicht die Technik bricht zuerst, sondern die Pflege der Inhalte.

Dokumente bereinigen, teilen und als Vektoren speichern

Bevor Text in den Suchindex gelangt, muss er technisch und inhaltlich vorbereitet werden. Ziel ist nicht, möglichst viele Abschnitte zu erzeugen. Jeder Vektor soll eine klar verständliche Information abbilden, die später zu einer konkreten Frage passt.

Entferne zunächst doppelte Dateien, leere Seiten, Navigationsreste und technische Fußzeilen. Bei PDF-Dateien lohnt sich eine Kontrolle der Texterkennung: Ein Scan kann zwar sichtbar korrekt aussehen, aber intern nur Bilddaten enthalten. Tabellen, Seitenumbrüche und Spalten sollten ebenfalls geprüft werden. Sonst landen Satzteile in falscher Reihenfolge im Index.

Zusätzlich sollten sensible Inhalte vor der Verarbeitung maskiert werden. Namen, Personalnummern oder interne Zugangsdaten gehören nicht in einen allgemeinen Dokumentbestand. Die Originaldatei bleibt unverändert und wird getrennt verwaltet.

Beispiel: Aus einer Urlaubsrichtlinie wird nicht einfach der komplette PDF-Text übernommen. Überschrift, Abschnittsname und Regeltext werden zusammengeführt. Ein isolierter Satz wie „Dies gilt ab dem 1. Juli“ wäre ohne seinen Bezug kaum brauchbar.

Beim Teilen der Dokumente sind semantische Grenzen wichtiger als starre Zeichenmengen. Ein Abschnitt sollte möglichst eine vollständige Regel, Definition oder Handlung enthalten. Als praktikabler Startwert eignen sich etwa 300 bis 700 Wörter pro Segment. Bei langen Absätzen kann eine Überlappung von ungefähr 10 bis 15 Prozent helfen, damit Bezüge zwischen zwei Teilen erhalten bleiben.

• Überschrift und zugehörige Erläuterung zusammenhalten
• Aufzählungen nicht mitten in einem Sachpunkt trennen
• Ausnahmen direkt bei der zugehörigen Regel speichern
• Tabellenzeilen in lesbare Textsätze umwandeln
• Abschnitte mit Dokument-ID und Seitenzahl versehen

Jedes Segment sollte neben dem eigentlichen Inhalt auch Suchmerkmale tragen. Dazu zählen Dokumenttitel, Abschnitt, Sprache, Version und Seitenreferenz. Diese Informationen helfen bei Filtern und ermöglichen später einen direkten Link zur Originalstelle.

Erst danach erzeugt ein Embedding-Modell für jeden Abschnitt eine Zahlenfolge. Sie bildet die Bedeutung des Textes in einem Vektorraum ab. Ähnliche Inhalte liegen dort näher beieinander als thematisch fremde Passagen. Ein Index mit 1.000 Segmenten enthält folglich 1.000 Vektoren plus die jeweiligen Texte und Metadaten.

Für einen ersten Prototyp genügen meist 768 bis 1.536 Dimensionen. Wichtig ist, dass Dokumente und Suchanfragen mit demselben Embedding-Modell verarbeitet werden. Ein späterer Modellwechsel erfordert in der Regel eine neue Berechnung des gesamten Bestands.

Die Speicherung kann in einer Vektordatenbank oder in einer relationalen Datenbank mit Vektorerweiterung erfolgen. Für die Urlaubsrichtlinie sollte ein Eintrag mindestens diese Felder enthalten:

• content: bereinigter Abschnittstext
• embedding: numerische Darstellung des Abschnitts
• source: Name und Pfad der Originaldatei
• page: Fundstelle im Dokument
• version: Versionsnummer
• access: erlaubte Nutzergruppe

Vor dem produktiven Einsatz lohnt ein kleiner Suchtest mit echten Fragen. Liefert die Suche bei „Kann Resturlaub ins nächste Jahr übertragen werden?“ tatsächlich den Abschnitt zur Übertragung – und nicht nur eine allgemeine Passage über Urlaub? Wenn nicht, liegt das Problem oft bei der Segmentierung, bei fehlenden Metadaten oder beim Embedding. Erst den Index prüfen, dann am Sprachmodell drehen.

Wichtige Bausteine eines praktischen RAG-Systems

Die Nutzerfrage analysieren und passende Inhalte abrufen

Die Suchqualität entscheidet sich bereits bei der Formulierung der Anfrage. Eine Frage wie „Wie viel Urlaub?“ enthält zu wenig Kontext. Besser ist: „Kann ich fünf Resturlaubstage aus 2026 ins Jahr 2027 übertragen, wenn ich in Berlin arbeite?“ Daraus lassen sich Zeitraum, Ort, Thema und gewünschte Handlung ableiten.

Vor der eigentlichen Suche kann ein kleines Anfrage-Modul die Eingabe in Suchmerkmale zerlegen:

• Thema: Resturlaub
• Zeitraum: 2026 bis 2027
• Standort: Berlin
• Rolle: Beschäftigte Person
• Absicht: Übertragungsmöglichkeit klären

Unklare Fragen sollten nicht blind an den Index gehen. Fehlt etwa der Standort, fragt das System gezielt nach: „Für welchen Standort gilt deine Frage?“ Das ist meist besser als ein scheinbar sicherer Treffer aus dem falschen Regelwerk.

Für die Suche empfiehlt sich eine Kombination aus mehreren Verfahren. Die Vektorsuche erkennt ähnliche Bedeutungen, auch wenn die Begriffe abweichen. Eine Stichwortsuche findet dagegen exakte Begriffe wie „Ausschlussfrist“, „Teilzeit“ oder eine Versionsnummer. Zusammen liefern beide Methoden oft bessere Ergebnisse als jeweils allein.

Die Treffer lassen sich anschließend neu sortieren. Ein sogenannter Reranker bewertet, welcher Abschnitt die konkrete Frage am besten beantwortet. Dabei können Inhalt, Aktualität, Standort und Nutzerrolle gemeinsam einfließen. Ein Abschnitt mit hoher sprachlicher Ähnlichkeit ist nicht automatisch der richtige Treffer.

Für das Beispiel kann die Suchlogik so aussehen:

• zuerst Zugriffsrechte und Standort filtern
• danach fünf bis zehn Kandidaten aus Vektor- und Stichwortsuche ermitteln
• die Kandidaten nach Fragebezug neu bewerten
• nur die besten drei bis fünf Abschnitte weitergeben
• bei widersprüchlichen Versionen den Konflikt ausdrücklich markieren

Ein nützliches Ergebnis ist nicht nur der gefundene Text, sondern auch eine strukturierte Trefferliste mit Dokument-ID, Abschnitt, Seitenzahl und Relevanzwert. So kann die nächste Komponente nachvollziehen, warum ein Abschnitt ausgewählt wurde.

Bleiben die Treffer schwach, sollte das System nicht einfach mehr Text nachladen. Es kann stattdessen eine Rückfrage stellen oder offen mitteilen, dass keine passende Regel gefunden wurde. Diese Bremse verhindert manche kühne und falsche Antwort.

Gefundene Textstellen als Kontext an das Sprachmodell übergeben

Die gefundenen Abschnitte werden nicht ungeordnet an das Sprachmodell weitergereicht. Sie bilden einen kontrollierten Kontextblock, aus dem das Modell die Antwort ableiten soll. Seine Aufgabe ist damit begrenzt: Es beantwortet die Frage anhand der bereitgestellten Belege und ergänzt fehlende Informationen nicht frei.

Ein robuster Kontext enthält zuerst die Nutzerfrage, danach die relevanten Fundstellen und zuletzt konkrete Antwortregeln. Jede Fundstelle sollte eine eindeutige Kennung tragen. So kann das Modell später auf Dokumenttitel, Abschnitt oder Seite verweisen.

Für das Urlaubsbeispiel kann der Kontext etwa diese Informationen enthalten:

• die konkrete Frage der beschäftigten Person
• den Standort und den betroffenen Zeitraum
• die drei wichtigsten Textstellen
• den Gültigkeitsstatus jeder Fundstelle
• eine Anweisung zur Quellenverknüpfung

Die Reihenfolge beeinflusst die Ausgabe. Beginnt der Kontext mit langen Randinformationen, kann die zentrale Regel untergehen. Besser steht der relevanteste Abschnitt zuerst. Widersprüche sollten nicht versteckt werden: Das Modell muss erkennen, wenn eine allgemeine Regel und eine standortbezogene Ausnahme nebeneinanderstehen.

Auch die Länge verdient Aufmerksamkeit. Ein überfüllter Kontext erhöht Kosten und kann die Antwort verschlechtern. Als Startpunkt genügen oft drei bis fünf Textstellen mit zusammen etwa 2.000 bis 5.000 Wörtern. Bei sehr langen Dokumenten sollte das System die wichtigsten Passagen auswählen, statt das komplette Handbuch einzusetzen.

Eine klare Anweisung für das Modell könnte sinngemäß lauten: Nutze ausschließlich die bereitgestellten Fundstellen. Beantworte die Frage knapp. Nenne die Quelle hinter jeder wesentlichen Aussage. Wenn die Belege nicht ausreichen, sage das offen.

Quellenmarker sollten stabil und gut lesbar sein. Statt interner IDs wie „vec_8f31“ eignen sich Angaben wie „Urlaubsrichtlinie 2026, Abschnitt 4.2“. Die Anwendung kann daraus automatisch einen anklickbaren Verweis auf die Originalseite erzeugen.

Bei personenbezogenen Fragen darf der Kontext nur die Werte enthalten, die für die Berechnung nötig sind. Für fünf verbleibende Urlaubstage braucht das Modell keinen vollständigen Personalstammdatensatz. Weniger Kontext ist hier nicht nur günstiger, sondern auch datensparsamer.

Eine belegte Antwort mit Quellenangaben erzeugen

Die Antwort sollte aus überprüfbaren Aussagen bestehen. Dafür verbindet die Generierung jede zentrale Aussage mit der Fundstelle, aus der sie stammt. Eine bloße Quellenliste am Ende reicht nicht: Der Leser muss erkennen können, welcher Beleg zu welchem Satz gehört.

Im Urlaubsbeispiel könnte die Ausgabe so aufgebaut sein: „Resturlaub kann übertragen werden, wenn betriebliche oder persönliche Gründe vorliegen. Quelle: Urlaubsrichtlinie 2026, Abschnitt 4.2, Seite 7.“ Eine ergänzende Standortregel erhält ihren eigenen Quellenhinweis. Dadurch bleiben allgemeine Regel und Ausnahme sauber getrennt.

Für eine verlässliche Antwort gelten drei Schreibregeln:

• Nur Aussagen verwenden, die im Kontext tatsächlich belegt sind.
• Unsicherheit klar benennen, statt eine Lücke zu erraten.
• Quellen direkt hinter der jeweiligen Aussage angeben.

Das System sollte außerdem zwischen Fakten, Berechnungen und Empfehlungen unterscheiden. „Fünf Urlaubstage sind noch verfügbar“ stammt aus einem Kontosystem. „Die Übertragung ist möglich“ folgt aus einer Richtlinie. „Stelle den Antrag bis zum 31. März“ kann bereits eine Handlungsempfehlung sein. Diese drei Ebenen dürfen nicht zu einem scheinbar einheitlichen Fakt verschmelzen.

Eine gute Antwort bleibt kurz, auch wenn mehrere Dokumente geprüft wurden. Für die konkrete Frage reichen meist das Ergebnis, die wichtigste Begründung und die zugehörigen Nachweise. Lange Auszüge erschweren die Kontrolle.

Quellenlinks sollten auf die genaue Dokumentversion und möglichst auf die passende Seite führen. Ein Link auf die Startseite des Intranets hilft wenig. Bei internen Dateien kann die Anwendung stattdessen einen geschützten Dokumentpfad mit Abschnittsanker ausgeben.

Fehlen ausreichende Belege, sollte die Ausgabe etwa lauten: „Dazu finde ich keine verbindliche Regel in den zugänglichen Dokumenten. Bitte kläre den Fall mit der Personalabteilung.“ Diese Antwort ist fachlich sauber. Gerade bei Fristen, Ansprüchen und Ausnahmen ist Zurückhaltung ein Qualitätsmerkmal.

Beispiel: Unternehmensrichtlinie zur Urlaubsplanung beantworten

Eine Mitarbeiterin stellt die Frage: „Ich habe noch fünf Urlaubstage aus 2026. Darf ich sie nach 2027 übertragen und bis wann muss ich sie nehmen?“ Das System behandelt diese Eingabe nicht als reine Wissensfrage. Sie enthält zwei Prüfungen: den möglichen Übertrag und die maßgebliche Frist.

Für die Antwort werden deshalb drei Informationen zusammengeführt:

• die allgemeine Regel zur Entstehung und zum Verfall von Urlaub
• die konkrete Ausnahme für eine Übertragung in das Folgejahr
• der persönliche Urlaubssaldo der anfragenden Person

Angenommen, die Richtlinie erlaubt eine Übertragung nur bei dokumentiertem betrieblichen oder persönlichen Grund. Dann darf das System nicht schlicht „Ja“ schreiben. Es muss zuerst prüfen, ob ein solcher Grund hinterlegt ist. Fehlt dieser Nachweis, lautet die korrekte Antwort etwa: „Eine Übertragung ist nach der Richtlinie nur unter bestimmten Voraussetzungen möglich. In deinem Konto ist dafür derzeit kein bestätigter Grund hinterlegt. Bitte reiche den Nachweis bei der Personalabteilung ein.“

Ein anderer Fall zeigt die Stärke der Kombination: Die Richtlinie erlaubt die Übertragung, das Urlaubskonto weist fünf Tage aus und die Frist endet am 31. März 2027. Dann kann die Antwort lauten: „Du hast noch fünf Urlaubstage aus 2026. Eine Übertragung bis zum 31. März 2027 ist möglich, sofern der erforderliche Grund anerkannt wurde. Beantrage die Tage rechtzeitig über das Zeiterfassungssystem.“

Die Anwendung sollte dabei keine rechtliche Endentscheidung vortäuschen. Arbeitsrechtliche Sonderfälle, längere Krankheit oder widersprüchliche Einträge gehören an eine zuständige Stelle. Das System kann den Fall vorbereiten, die betroffenen Regeln nennen und fehlende Angaben sichtbar machen.

Für die praktische Umsetzung lohnt ein festes Antwortschema:

• Ergebnis: Was gilt im konkreten Fall?
• Voraussetzung: Welche Bedingung muss erfüllt sein?
• Frist: Bis wann ist eine Handlung nötig?
• Nächster Schritt: Was soll die Person jetzt tun?
• Beleg: Wo steht die maßgebliche Regel?

So entsteht keine wortreiche Dokumentzusammenfassung, sondern eine handlungsfähige Antwort. Der praktische Wert des RAG-Systems liegt darin, eine interne Regel mit einem konkreten Vorgang zu verbinden, ohne aus einer unsicheren Annahme eine verbindliche Zusage zu machen.

Antworten mit Guardrails und LLM-Judge prüfen

Guardrails prüfen die Ausgabe, bevor sie den Nutzer erreicht. Sie können verbotene Inhalte erkennen, fehlende Quellen markieren und Antworten blockieren, die nicht zum verfügbaren Kontext passen. Im Urlaubsassistenten wäre etwa eine Prüfung sinnvoll, die verbindliche Zusagen zu Ansprüchen verhindert, wenn eine notwendige Bedingung im Personalsystem fehlt.

Ein Guardrail sollte nicht nur den fertigen Text untersuchen. Bereits vor der Generierung kann es die Anfrage auf unzulässige Datenzugriffe prüfen. Nach der Generierung folgen Kontrollen auf Quellenbezug, Widersprüche, sensible Daten und das gewünschte Antwortformat.

• Zugriff: Darf die anfragende Person diese Information erhalten?
• Beleg: Besitzt jede wesentliche Aussage eine passende Fundstelle?
• Vollständigkeit: Wurden wichtige Bedingungen oder Ausnahmen ausgelassen?
• Widerspruch: Weichen Aussagen innerhalb der Antwort voneinander ab?
• Ton: Ist die Formulierung sachlich und frei von einer unzulässigen Zusage?

Ein LLM-Judge kann diese Prüfung ergänzen. Er bewertet eine Antwort nach festen Kriterien und vergibt zum Beispiel Punkte von 0 bis 2. Eine Antwort erhält null Punkte, wenn sie eine Regel erfindet, einen Punkt bei einem teilweise passenden Beleg und zwei Punkte bei korrekter, vollständiger und nachvollziehbarer Begründung.

Wichtig ist ein fester Bewertungsbogen. Ohne ihn beurteilt der Prüfer oft nur Stil und Flüssigkeit. Für das Beispiel sollten vor allem sachliche Kriterien zählen:

• Trifft die Antwort die konkrete Frage?
• Stützt jede zentrale Aussage eine zugängliche Quelle?
• Werden Bedingungen und Fristen korrekt genannt?
• Wird fehlende Information offen ausgewiesen?
• Enthält die Antwort keine Daten einer anderen Person?

Die Bewertung sollte nicht allein über die Veröffentlichung entscheiden. Bei niedriger Punktzahl kann das System eine zweite Suche auslösen, eine Rückfrage stellen oder die Anfrage an die Personalabteilung weiterleiten. Bei kritischen Themen genügt ein guter Score ohnehin nicht als automatische Freigabe.

Für den Betrieb werden Prüfprotokolle benötigt. Gespeichert werden sollten Bewertungsgrund, Regelverletzung, verwendete Dokumentversion und die technische Entscheidung. Vollständige Gesprächsinhalte sind dafür nicht immer nötig. Eine knappe, zugriffsgeschützte Diagnose reicht häufig aus.

Ein sinnvoller Testdatensatz enthält neben normalen Fragen auch absichtlich schwierige Fälle: veraltete Richtlinien, fehlende Standorte, widersprüchliche Fristen und Anfragen nach fremden Urlaubskonten. Erst solche Grenzfälle zeigen, ob die Schutzschicht wirklich trägt.

Vollständige und inkrementelle Datenaktualisierungen einrichten

Ein zuverlässiger Aktualisierungsprozess braucht zwei Wege: den kompletten Neuaufbau und die gezielte Änderung einzelner Datensätze. Der komplette Lauf eignet sich für größere Umstellungen. Die inkrementelle Variante hält den Bestand im Alltag frisch, ohne alle Dokumente erneut zu verarbeiten.

Für jedes Dokument sollte ein Änderungswert gespeichert werden, zum Beispiel eine Prüfsumme aus dem Dateiinhalt. Beim nächsten Lauf vergleicht der Importdienst diese Prüfsumme mit dem gespeicherten Stand:

• unverändert: nicht erneut einlesen
• geändert: alte Segmente ersetzen und neue Vektoren berechnen
• neu: vollständig aufnehmen
• gelöscht: aus dem Suchindex entfernen

Eine bloße Dateiprüfung reicht nicht immer. Inhalte können sich ändern, obwohl der Dateiname gleich bleibt. Deshalb gehören auch Versionsnummer, Freigabedatum und Änderungszeitpunkt in den Datensatz. Bei einem geänderten Abschnitt sollten nur die betroffenen Segmente neu berechnet werden.

Beim Ersetzen muss der Import atomar arbeiten. Zuerst werden die neuen Einträge vorbereitet. Erst wenn alle Vektoren erfolgreich gespeichert sind, schaltet das System auf die neue Dokumentversion um. Scheitert der Lauf, bleibt der bisherige Index nutzbar.

Ein vollständiger Neuaufbau ist sinnvoll, wenn:

• das Embedding-Modell gewechselt wurde
• die Aufteilung der Texte deutlich verändert wurde
• Metadaten oder Zugriffsregeln neu strukturiert wurden
• viele Dateien gleichzeitig ersetzt wurden
• der Index beschädigt oder unvollständig ist

Für den laufenden Betrieb kann ein nächtlicher Delta-Lauf genügen. Kritische Richtlinien sollten dagegen unmittelbar nach ihrer Freigabe verarbeitet werden. Ein Zeitstempel allein beweist aber nicht, dass der neue Inhalt bereits abrufbar ist. Der Prozess braucht daher einen Status wie „veröffentlicht“, „in Verarbeitung“ oder „fehlgeschlagen“.

Jede Änderung sollte nachvollziehbar bleiben. Ein Protokoll mit Dokument-ID, alter und neuer Version, Startzeit, Ergebnis und Fehlergrund hilft bei Rückfragen. Für das Urlaubssystem lässt sich damit später prüfen, welche Regel zum Zeitpunkt einer Antwort aktiv war.

Nach dem Import folgt ein kurzer Funktionstest. Eine bekannte Frage muss die neue Regel finden, während eine entfernte Passage nicht mehr auftauchen darf. Erst dann wird die neue Version für Antworten freigegeben.

RAG-Qualität mit klaren Messwerten bewerten

Ein RAG-System sollte nicht nur überzeugend klingen. Seine Leistung muss sich an messbaren Ergebnissen zeigen. Dafür braucht das Urlaubsbeispiel einen festen Testsatz mit realistischen Fragen, eindeutigen Referenzantworten und klaren Grenzfällen.

Trenne drei Fehlerquellen: Findet die Suche den richtigen Abschnitt? Versteht das Sprachmodell den gefundenen Inhalt? Und bleibt die fertige Antwort für den Nutzer brauchbar? Diese Aufteilung zeigt, an welcher Stelle nachgebessert werden muss.

• Trefferquote: Wie oft gehört die benötigte Fundstelle zu den ersten fünf Suchergebnissen?
• Antworttreue: Wie viele Aussagen lassen sich direkt durch den Kontext belegen?
• Vollständigkeit: Werden notwendige Bedingungen, Ausnahmen und Fristen genannt?
• Fehlerrate: Wie oft enthält die Antwort eine unbelegte oder falsche Aussage?
• Reaktionszeit: Wie lange dauert die Ausgabe vom Absenden bis zur fertigen Antwort?
• Abbruchquote: Wie oft muss das System eine Anfrage an einen Menschen weitergeben?

Für den Prototyp genügen zunächst 50 bis 100 Testfragen. Der Datensatz sollte einfache Fragen, Synonyme, Tippfehler und mehrdeutige Formulierungen enthalten. Ergänze außerdem Fälle, bei denen die richtige Antwort „nicht ausreichend belegt“ lautet. Sonst misst der Test nur, wie gut das System selbstbewusst antwortet.

Ein Beispiel für ein Zielset könnte so aussehen: Mindestens 90 Prozent der benötigten Fundstellen erscheinen unter den ersten fünf Treffern. Mindestens 95 Prozent der wesentlichen Aussagen sind belegbar. Kritische Falschaussagen, etwa eine erfundene Frist, müssen bei Testfragen vollständig ausbleiben.

Bewerte nicht nur den Durchschnitt. Ein Mittelwert von 95 Prozent kann einen einzelnen schweren Fehler verdecken. Werte deshalb kritische Kategorien getrennt aus: Fristen, Ansprüche, personenbezogene Angaben und fehlende Nachweise. Für diese Bereiche sollte ein strengerer Schwellenwert gelten.

Die Messung endet nicht beim Start des Systems. Vergleiche monatlich Antwortqualität, Suchtreffer und Bearbeitungszeit. Steigt die Fehlerrate nach einer Änderung, lässt sich anhand der gespeicherten Testfälle erkennen, ob neue Dokumente, eine andere Segmentierung oder ein Modellwechsel die Ursache sind.

Auch Rückmeldungen der Beschäftigten sind nützlich. Ein Knopf für „hilfreich“ oder „nicht hilfreich“ liefert zwar kein vollständiges Qualitätsurteil, zeigt aber auffällige Fragen. Besonders wertvoll sind kurze Begründungen wie „Frist fehlt“ oder „falscher Standort“. Daraus entstehen neue Testfälle und der Messrahmen wird praxisnäher.

Fazit: Mit kleinen Tests starten und das System laufend verbessern

Ein kleines, klar begrenztes RAG-System lässt sich schneller beurteilen als eine umfangreiche Plattform. Beginne deshalb mit wenigen Dokumenten, einem festen Fragenkatalog und einem überschaubaren Nutzerkreis. So wird sichtbar, ob das System im echten Alltag hilft oder nur in einer Demo gut aussieht.

Verbessere danach immer nur einen Baustein auf einmal. Ändere beispielsweise die Suchlogik, die Antwortvorlage oder die Auswahl des Sprachmodells. Wenn mehrere Komponenten gleichzeitig wechseln, bleibt unklar, wodurch sich das Ergebnis verändert hat.

• zuerst einen Ausgangswert für Qualität, Kosten und Antwortzeit festhalten
• die häufigsten Fehlermuster nach ihrer Auswirkung ordnen
• kleine Änderungen an einem kontrollierten Testbestand prüfen
• erst nach erfolgreicher Prüfung weitere Nutzer freischalten
• jede neue Erkenntnis in den nächsten Testlauf übernehmen

Auch die Kosten gehören zur Praxistauglichkeit. Kürzere Kontexte, gezielte Suchabfragen und eine passende Modellgröße senken den Verbrauch. Für einfache Richtlinienfragen braucht es nicht immer das leistungsstärkste Modell. Bei komplexen Ausnahmen kann ein stärkeres Modell dagegen sinnvoll sein, wenn die zusätzliche Genauigkeit den Mehraufwand rechtfertigt.

Plane außerdem einen klaren Ausstieg ein. Kann das System eine Frage nicht sicher beantworten, muss ein erreichbarer Kontakt übernehmen. Eine gute Übergabe enthält die ursprüngliche Frage, die ermittelten Fundstellen und die noch offene Unsicherheit. Der Mensch beginnt dann nicht wieder bei null.

Rechtlich und organisatorisch sollte der Einsatz dokumentiert werden. Bei bestimmten Anwendungen können Vorgaben der EU-KI-Verordnung zur Transparenz, Protokollierung oder menschlichen Aufsicht greifen. Prüfe daher vor dem produktiven Betrieb den konkreten Zweck, die Datenarten und die Risikoklasse. Eine Kennzeichnung als KI-gestützte Antwort kann zusätzlich Vertrauen schaffen.

Das praktische Ziel ist kein allwissender Chatbot. Es ist ein begrenztes Werkzeug, das passende Informationen findet, verständlich verarbeitet und seine Grenzen kennt. Wer mit einem kleinen, messbaren Szenario startet, erhält belastbare Erkenntnisse statt einer teuren Großbaustelle. Danach darf das System wachsen – Schritt für Schritt und mit echten Fragen aus dem Arbeitsalltag.

FAQ zu einem praktischen RAG-System-Beispiel