RAG-Pilot richtig planen: Scope, Testfragen und Erfolgskriterien

Ein RAG-Pilot klingt zunächst recht einfach: Einige Dokumente einlesen, eine Suchfunktion ergänzen, ein Sprachmodell anschließen und Fragen stellen. Technisch lässt sich so ein erster Prototyp tatsächlich schnell bauen.

Die wichtigere Frage ist aber nicht, ob eine Antwort erscheint. Die Frage ist, ob die Antwort im Arbeitsalltag verlässlich genug ist. Findet das System die richtige Quelle? Versteht es, welche Version aktuell ist? Bleibt eine vertrauliche Information für unberechtigte Personen unsichtbar? Und sagt es klar, wenn die vorhandenen Daten nicht ausreichen?

Genau dafür ist ein Pilot da. Er ist keine kleine Ausgabe der späteren Gesamtlösung. Er ist ein kontrollierter Test, der eine belastbare Entscheidung ermöglichen soll.

„Wir möchten mit unserem gesamten Unternehmenswissen chatten“ ist kein sinnvoller Pilotumfang. Dafür sind Datenquellen, Nutzergruppen und Erwartungen zu unterschiedlich. Besser ist ein klarer Arbeitsfall mit einem erkennbaren Anfang und Ende.

Ein einfaches Beispiel: Ein Serviceteam soll Fragen zu einer bestimmten Produktgruppe anhand freigegebener Handbücher beantworten können. Damit sind die Nutzergruppe, der Dokumentenbereich und die Art der Fragen bereits deutlich enger gefasst.

Für den Start sollten fünf Punkte eindeutig sein:

• Nutzergruppe: Wer arbeitet im Pilot tatsächlich mit dem System?
• Aufgabe: Welche konkrete Tätigkeit soll leichter oder schneller werden?
• Quellenbereich: Welche Dokumente und Systeme gehören dazu und welche bewusst nicht?
• Rechte: Wer darf welche Informationen sehen?
• Entscheidung: Was wollen wir nach dem Pilot wissen, das wir heute noch nicht wissen?

Die aktuelle Fraunhofer-IAO-Studie zu RAG beschreibt den Nutzen vor allem darin, unternehmensinterne Informationen zugänglich zu machen, ohne dass Mitarbeitende die genaue Ablagestruktur kennen müssen. Genau deshalb muss der gewählte Quellenbereich im Pilot fachlich sinnvoll und nachvollziehbar vorbereitet sein.

Ein RAG-System wirkt in einer kurzen Demo fast immer überzeugend. Man stellt einige einfache Fragen, die passenden Dokumente sind bekannt und die Antworten sehen gut aus. Das sagt noch wenig darüber aus, wie sich das System bei echten Fragen verhält.

Als pragmatische Arbeitsgröße für einen überschaubaren Pilot bietet sich ein erster Testsatz mit ungefähr 25 bis 40 Fragen an. Das ist keine allgemeingültige Norm. Wichtig ist die Mischung:

1. Einfache Treffer: Die Antwort steht klar in einem gültigen Dokument.
2. Verteilte Informationen: Die Antwort muss aus mehreren Abschnitten oder Dokumenten zusammengesetzt werden.
3. Unterschiedliche Begriffe: Die Frage verwendet andere Wörter als die Quelle.
4. Veraltete Versionen: Es gibt alte und neue Dokumentstände.
5. Fehlende Information: Die korrekte Reaktion ist, keine belastbare Antwort zu geben.
6. Berechtigungsfälle: Eine Information existiert, darf der testenden Person aber nicht angezeigt werden.

Zu jeder Frage gehören eine erwartete Kernaussage, die gültige Quelle und eine fachlich verantwortliche Person. Sonst bleibt die Bewertung am Ende bei „klingt gut“ oder „gefällt mir nicht“ hängen.

RAG besteht vereinfacht aus zwei Schritten. Zuerst sucht das System passende Textstellen. Danach formuliert das Sprachmodell daraus eine Antwort. Eine schlechte Antwort kann daher zwei unterschiedliche Ursachen haben: Entweder wurden die falschen Inhalte gefunden oder richtige Inhalte wurden schlecht verwendet.

Diese Trennung ist wichtig. Wenn die Suche eine veraltete Arbeitsanweisung liefert, hilft auch der beste Prompt nicht. Wenn die Suche die richtige Stelle findet, die Antwort aber eine zusätzliche Behauptung erfindet, liegt das Problem an einer anderen Stelle.

Auch etablierte Evaluationsansätze unterscheiden deshalb zwischen der Qualität der gefundenen Inhalte und der Qualität der fertigen Antwort. Für einen Unternehmenspilot müssen daraus keine komplizierten Kennzahlen entstehen. Eine nachvollziehbare Prüfliste reicht häufig für den Anfang.

Wichtig ist, die Kriterien vor dem Test festzulegen. Wer sie erst nach den ersten Ergebnissen definiert, passt den Maßstab leicht an das an, was der Prototyp zufällig gut kann.

Wir grenzen Nutzergruppe, Aufgabe und gewünschtes Ergebnis ab. Gleichzeitig wird festgelegt, wer Quellen freigibt und wer Antworten fachlich beurteilt.

Die ausgewählten Dokumente werden auf Aktualität, Dubletten, Dateiformate, Metadaten und Berechtigungen geprüft. Es muss nicht das ganze Unternehmen aufgeräumt werden. Der Pilotbereich muss aber verständlich sein.

Der technische Aufbau wird mit den vorbereiteten Quellen verbunden. Danach läuft der vollständige Fragensatz durch das System. Fehler werden nicht nur gezählt, sondern einer Ursache zugeordnet: Quelle, Suche, Aufbereitung, Antwort oder Berechtigung.

Am Ende steht keine Hochglanzdemo, sondern eine Entscheidung: weiterführen, gezielt nachbessern oder stoppen. Bei einem positiven Ergebnis wird festgelegt, welche Datenquellen, Nutzergruppen und Prozesse als Nächstes hinzukommen.

Ein Pilot darf auch zeigen, dass RAG für den gewählten Fall derzeit nicht sinnvoll ist. Das ist kein gescheitertes Projekt, sondern eine wertvolle Erkenntnis, bevor eine größere Investition erfolgt.

Ein Abbruch oder eine grundlegende Überarbeitung ist sinnvoll, wenn:

• keine verlässliche Quelle für die wichtigsten Fragen existiert,
• niemand fachlich für Aktualität und Freigabe verantwortlich ist,
• Berechtigungen im gewählten Datenbereich nicht sauber abgebildet werden können,
• die Pilotgruppe trotz guter Treffer keinen praktischen Nutzen erkennt,
• Fehler nicht nachvollzogen und gezielt verbessert werden können.

Der Europäische Datenschutzbeauftragte weist bei RAG unter anderem auf Risiken durch sensible Daten, unpassende Zugriffe und indirekte Manipulationen hin. Ein Pilot sollte diese Punkte daher nicht als spätere Betriebsfrage behandeln, sondern von Anfang an testen.

Ein guter RAG-Pilot beweist nicht, dass eine Chatoberfläche Antworten erzeugen kann. Er zeigt, ob ein klar abgegrenzter Arbeitsfall mit den vorhandenen Daten, Rechten und Verantwortlichkeiten belastbar funktioniert.

Dafür braucht es einen engen Scope, echte Testfragen und vorab vereinbarte Erfolgskriterien. So wird aus einer interessanten Demo eine fundierte Entscheidungsgrundlage.

Beim RAG-Pilot von Trixner digital solutions beginnen wir deshalb mit dem Arbeitsfall und den Daten. Erst danach wählen wir die technische Architektur und prüfen Schritt für Schritt, ob ein Ausbau sinnvoll ist.

• Fraunhofer IAO: Unternehmensdokumente erschließen mit RAG
• Europäischer Datenschutzbeauftragter: Retrieval-augmented generation (RAG)
• Microsoft Azure Architecture Center: RAG end-to-end evaluation
• RAGAS: Automated Evaluation of Retrieval Augmented Generation