RAG (Retrieval-Augmented Generation) ist ein Ansatz, bei dem ein Sprachmodell seine Antwort auf Textstellen aus den eigenen Dokumenten einer Organisation stützt. Dieser Beitrag beschreibt, welche Entscheidungen die Person, die ein RAG-Projekt steuert, früh festhalten sollte; es ist meine Arbeitsmethode, keine Aussage über ein gemessenes Ergebnis.
Warum ist ein RAG-Projekt ein Managementproblem?
In RAG-Projekten ist das Modell oft ein fertiger Dienst; die eigentliche Arbeit liegt in Entscheidungen wie: Welche Dokumente werden genutzt, wer darf was sehen und wie wird die Genauigkeit der Antworten gemessen? Werden diese Entscheidungen nicht festgehalten, endet das Projekt bei „die Demo sieht gut aus, im Betrieb ist sie nicht verlässlich“. Die folgenden Schritte entsprechen der Reihenfolge, die ich in KI-Projekten verwende.
1. Umfang: Welche Fragen soll es beantworten?
Der erste Schritt ist, aufzuschreiben, welche Nutzerfragen das System beantwortet und welche nicht. „Alle Firmendokumente abfragen“ ist ein Wunsch, kein Umfang. Beispielfragen von Nutzern werden gesammelt; sie bestimmen sowohl den Umfang als auch die spätere Evaluation.
2. Quelldokumente und Datenverantwortung
Welche Dokumente kommen in den Index? Sind sie aktuell, gibt es widersprüchliche Versionen, enthalten sie personenbezogene Daten? Jede Dokumentengruppe braucht einen Verantwortlichen, und wie der Index bei Änderungen aktualisiert wird, wird vorab festgelegt. Die Grundlage einer Antwort muss zeigbar sein: Nutzer sollten sehen können, aus welchem Abschnitt welches Dokuments die Antwort entstanden ist.
3. Zugriffskontrolle
RAG kann den Inhalt vertraulicher Dokumente an Personen ohne Zugriff preisgeben. Die Zugriffsregel wird deshalb zur Abfragezeit angewendet und im ersten Plan festgehalten: Wer darf zu welcher Dokumentengruppe fragen? Das ist eine Architekturentscheidung, kein nachträgliches Feature.
4. Das Evaluationsset
Aus echten Nutzerfragen und den dafür erwarteten Quelldokumenten wird ein kleines Evaluationsset erstellt. Jede Version wird daran verglichen; „sieht gut aus“ genügt nicht. Ob das System das richtige Dokument findet und ob es aus dem gefundenen Dokument die richtige Schlussfolgerung zieht, wird getrennt betrachtet.
5. Pilot, Kosten und Latenz
Der Pilot läuft mit einer begrenzten Nutzergruppe. In dieser Phase werden Antwortzeit und Nutzungskosten gemessen; die Entscheidung über die Ausweitung wird schriftlich getroffen, nachdem Genauigkeit, Zeit und Kosten gemeinsam abgewogen wurden.
6. Überwachung und Änderungsmanagement
Im Betrieb werden Nutzerfeedback, unbeantwortete Fragen und Dokumentänderungen überwacht. Ändern sich Modell, Prompt oder Dokumentenmenge, wird das Evaluationsset erneut ausgeführt. Dieser Prozess deckt sich mit den Fragen zu Lebenszyklus und Überwachung in der ISO/IEC-42001-Checkliste.
Häufige Fragen
Was ist der Unterschied zwischen RAG und Feintuning?
RAG stützt die Antwort auf zur Abfragezeit abgerufene Dokumentpassagen; bei Änderungen wird der Index aktualisiert. Feintuning trainiert das Modell selbst mit Beispielen. Beides lässt sich kombinieren; die Wahl hängt von Datenaktualität, Nachvollziehbarkeit und Kosten ab.
Was ist der häufigste Managementfehler in einem RAG-Projekt?
Evaluationsset und Zugriffskontrolle ans Ende zu schieben. Beides beeinflusst die Architektur und gehört in den ersten Plan.
Wie lange dauert ein RAG-Projekt?
Das hängt von Dokumentenzahl, Komplexität der Zugriffskontrolle und Integrationen ab; nach der Festlegung des Umfangs wird die Pilotdauer geplant. Eine nicht gemessene Dauer verspreche ich nicht.