RAG und wissensgestützte Workflows

RAG und wissensgestützte Workflows

0:00 Wenn eine RAG-Anwendung falsch antwortet, gibt fast jeder dem Modell die Schuld und fängt an, den Prompt zu verbessern. Das ist in den meisten Fällen die falsche Baustelle. Denn die Antwort kann nur so gut sein wie das Stück Text, das die Suche geliefert hat — und wenn die daneben gegriffen hat, hilft kein noch so kluger Prompt.

0:18 Dieses Modul zeigt Ihnen den ganzen Weg: wie Wissen in den Speicher kommt, wie gesucht wird und, besonders wichtig, wie Sie im Fehlerfall unterscheiden, an welcher der beiden Stufen es lag.

RAG und wissensgestützte Workflows

0:28 Wir bleiben am vierten Tag und bauen auf dem Modellaufruf von eben auf. Zuerst die Grundidee: Warum reicht ein Prompt allein nicht? Dann die Aufnahme — Zerlegen, Einbetten, Metadaten; dort entsteht die Qualität. Danach das Suchen und Antworten, mit zwei möglichen Wegen. Und zum Schluss der Betrieb: Ein Wissensbestand, den niemand pflegt, wird von einer Hilfe zur Fehlerquelle. Dazu die Frage, wann RAG überhaupt das richtige Werkzeug ist.

Vom Prompt zum Retrieval

0:57 Fangen wir mit der Grundidee an. Sie ist erstaunlich einfach — und der Name Retrieval-Augmented Generation klingt komplizierter, als die Sache ist. Retrieval-Augmented Generation gibt Modellen Zugriff auf kontextspezifische Quellen, damit sie passende Antworten erzeugen können. Der Kern steht im zweiten Satz: Statt das gesamte Wissen in den Prompt zu schreiben, wird zur Frage das passende Stück gesucht und mitgegeben.

1:22 Denken Sie an eine Prüfung mit erlaubten Unterlagen. Die Kandidatin muss nicht alles auswendig wissen — sie muss wissen, wo es steht, und es zur richtigen Frage aufschlagen. Genau das tut ein RAG-System: Es schlägt nach und legt die Seite daneben, bevor es antwortet. Wie findet es die richtige Seite? Über Embeddings — numerische Darstellungen von Daten als Vektoren. Ein Vector Store speichert sie und erlaubt Ähnlichkeitssuchen.

1:47 Und jetzt kommt der Unterschied zur klassischen Suche: Gesucht wird nach semantischer Bedeutung statt nach übereinstimmenden Stichwörtern. Wenn jemand nach „Heizung macht komische Geräusche" fragt, findet eine Stichwortsuche nichts, wenn im Handbuch „Betriebsgeräusche der Umwälzpumpe" steht. Eine Ähnlichkeitssuche findet es — weil beide Formulierungen im selben Bedeutungsraum liegen. Das ist die eigentliche Leistung dieser Technik.

2:13 Fünf Stationen, und die Reihenfolge erklärt, warum später die Fehlersuche zweistufig ist. Die Frage kommt herein. Sie wird eingebettet — in denselben Bedeutungsraum übersetzt wie die gespeicherten Textstücke. Die Ähnlichkeitssuche findet die nächstliegenden. Diese Stücke wandern als Kontext in den Prompt. Und erst dann antwortet das Modell.

2:33 Sie sehen: Zwischen Frage und Antwort liegen drei Schritte, in denen das Modell noch gar nicht beteiligt ist. Wenn also etwas schiefgeht, ist es keineswegs gesagt, dass es am Modell lag. Vier Gründe, warum man diesen Aufwand betreibt. Der Kontext ist begrenzt und wird mit jeder Zeile teurer — Sie können nicht einfach das ganze Handbuch mitschicken.

2:54 Hausinternes Wissen steckt nicht im Modell und gehört auch nicht hinein; das ist ein Punkt, der in Datenschutzgesprächen hilft. Änderungen am Wissensbestand sollen nicht jeden Prompt anfassen — Sie aktualisieren ein Dokument, nicht zwanzig Workflows. Und der vierte ist der wichtigste für die Qualität: Ohne Fundstelle lässt sich eine Antwort nicht überprüfen.

3:16 Der erste Punkt ist der teuerste Architekturfehler: RAG wird gebaut, wo eine Datenbankabfrage die exakte Antwort gehabt hätte. Dazu kommen wir im vierten Kapitel zurück. Der zweite ist der Aufwandsfehler in die andere Richtung: Das gesamte Handbuch wandert in den Prompt statt in einen Vector Store. Der dritte ist ein Betriebsfehler mit Ablaufdatum: Der Bestand wird einmal aufgenommen und nie wieder aktualisiert.

3:40 Und der vierte macht jede Prüfung unmöglich: Die Antwort nennt keine Quelle.

Wissen aufnehmen

3:45 Jetzt zur Aufnahme. Und hier ist die wichtigste Erkenntnis dieses Moduls versteckt: Die Qualität eines RAG-Systems entsteht beim Zerlegen, nicht beim Antworten. Fünf Schritte. Holen Sie die Quelldaten mit den passenden Bausteinen — das Handwerk aus Modul sieben. Setzen Sie einen Vector-Store-Baustein mit der Operation Insert Documents ein.

4:06 Wählen Sie ein Embedding-Modell, das den Text in Vektoren überführt. Ergänzen Sie einen Default Data Loader, der den Inhalt in Stücke zerlegt. Und geben Sie je Stück Metadaten mit, damit später gefiltert werden kann — das ist optional und lohnt sich fast immer. Die Fußzeile trägt eine Regel, gegen die man genau einmal verstößt: Beim Abfragen muss dasselbe Embedding-Modell verwendet werden wie beim Aufnehmen. Sonst passt nichts zusammen.

4:33 Drei Arten zu zerlegen. Der Character Text Splitter schneidet nach Zeichenlänge — schlicht und blind für Struktur. Der Token Text Splitter schneidet nach Token, was näher an der Arbeitsweise des Modells liegt. Und der Recursive Character Text Splitter versucht, an sinnvollen Grenzen zu schneiden: an Markdown-Struktur, an HTML, an Code-Blöcken — und erst wenn das nicht geht, an Zeichen.

4:55 Genau deshalb ist er die Empfehlung der Dokumentation für die meisten Fälle. Denn ein Stück, das mitten in einer Tabelle endet, ist für die Suche fast wertlos. Vier Hinweise, und es ist eine Abwägung ohne richtige Antwort. Kleine Stücke von etwa zweihundert bis fünfhundert Token treffen fein, aber eng — sie finden genau die Stelle und verlieren den Zusammenhang.

5:17 Große Stücke tragen mehr Zusammenhang und verwässern leichter; je mehr in einem Stück steht, desto unschärfer sein Bedeutungsschwerpunkt. Eine sinnvolle Überlappung hält den Kontext über die Schnittstelle hinweg — das ist der einfachste Hebel, den viele weglassen. Und Zusatzkontext zum Herkunftsdokument verbessert die Treffer spürbar. Probieren Sie zwei Größen aus und vergleichen Sie; anders findet man es nicht heraus.

5:42 Der erste Punkt ist eine verpasste Chance: Die Stückgröße wird nie variiert, obwohl die Trefferqualität daran hängt. Der zweite fällt erst auf, wenn man ihn braucht: Metadaten fehlen, und später lässt sich nicht nach Baureihe filtern — dann durchsuchen Sie alle Handbücher, auch die zur falschen Anlage. Der dritte ist der Regelverstoß von eben: Beim Abfragen wird ein anderes Embedding-Modell gewählt als beim Aufnehmen; die Ergebnisse sind dann nicht falsch, sondern zufällig.

6:08 Und der vierte ist der Grund für den rekursiven Splitter: Tabellen und Code werden mitten im Element zerschnitten.

Suchen und antworten

6:15 Jetzt zur Abfrage. Es gibt zwei Wege, und sie unterscheiden sich in einem Punkt, der Ihnen inzwischen vertraut sein dürfte: Wer entscheidet, ob nachgeschlagen wird — Sie oder das Modell? Beim ersten Weg hängen Sie den Vector Store als Werkzeug an einen Agenten. Und dann kommt der Punkt, den man leicht unterschätzt: Das Werkzeug braucht eine Beschreibung.

6:36 Diese Beschreibung sagt dem Agenten, wann er nachschlagen soll — sie ist also keine Dokumentation für Menschen, sondern eine Anweisung an das Modell. Ist sie vage, schlägt der Agent nie nach und antwortet aus seinem allgemeinen Wissen. Dazu kommen zwei Einstellungen: Das Limit legt fest, wie viele Stücke zurückkommen, und Include Metadata gibt dem Modell den Zusammenhang je Stück mit.

6:58 Der zweite Weg kommt ohne Agenten aus: Sie setzen den Vector-Store-Baustein mit der Operation Get Many ein und stellen die Frage direkt im Baustein. Der Vorteil steht im dritten Punkt und ist beträchtlich: Der Ablauf bleibt deterministisch und nachvollziehbar. Es gibt keine Entscheidung des Modells darüber, ob nachgeschlagen wird — es wird nachgeschlagen, immer.

7:18 Für einen festen Anwendungsfall ist das der ruhigere Weg, und ich würde damit anfangen. Den Agenten nehmen Sie, wenn die Frage offen ist und mehrere Quellen infrage kommen. Groundedness misst, wie genau die Antwort eines Modells die Quellen wiedergibt. Eine ungegroundete Antwort spekuliert oder halluziniert, ohne dass die Quellen das decken.

7:38 Der Begriff ist deshalb wichtig, weil er eine Qualität benennt, die man sonst nur ungenau beschreiben kann — „stimmt ungefähr" ist keine Kategorie. Und daraus folgt der letzte Satz: Die Fundstelle mit auszugeben ist kein Zierrat, sondern die Voraussetzung, das überhaupt zu prüfen. Nur wenn Sie wissen, worauf sich die Antwort stützt, können Sie nachsehen, ob sie das auch hergibt.

8:01 Der erste Punkt ist der aus dem Agenten-Weg: Die Werkzeugbeschreibung ist vage, und der Agent schlägt nie nach. Der zweite ist eine Einstellungsfalle: Das Limit steht auf eins, und die ganze Antwort hängt an einem einzigen Treffer — bei Ähnlichkeitssuchen ist der zweite oft der bessere. Der dritte ist eine halbe Prüfung: Es wird angezeigt, woher die Antwort stammt, aber niemand prüft, ob es passt.

8:23 Und der vierte ist tückisch: Der Agent bekommt den Vector Store zusätzlich zu seinem freien Modellwissen und mischt beides — dann steht neben einer belegten Aussage eine erfundene, und beide sehen gleich aus.

Betrieb und Entscheidung

8:35 Zum Abschluss der Betrieb. Ein Wissensbestand, der nicht gepflegt wird, ist nicht neutral — er wird aktiv zur Fehlerquelle, weil er veraltete Auskünfte mit derselben Sicherheit gibt wie aktuelle. Vier Punkte. Geänderte Dokumente müssen ersetzt werden, nicht ergänzt — sonst liegen beide Fassungen im Speicher, und die Suche findet mal die eine, mal die andere.

8:57 Gelöschte Inhalte müssen auch aus dem Vector Store verschwinden. Berechtigungen gehören in die Metadaten, wenn nicht alle alles sehen dürfen; das ist die einzige praktikable Stelle dafür. Und ohne Stand am Dokument ist später nicht erkennbar, was veraltet ist. Diese vier zusammen sind ein Pflegeprozess — und den muss jemand verantworten, sonst passiert er nicht.

9:19 Diese Tabelle beantwortet die Architekturfrage aus dem ersten Kapitel, und sie tut es über die Form der Frage. Lautet die Frage „Was steht zu diesem Schlüssel exakt im Bestand?" — dann ist es eine Datenbankabfrage. Exakt ist das Stichwort; für Exaktheit ist eine Ähnlichkeitssuche das falsche Werkzeug. Lautet sie „Wie ist der aktuelle Stand im Fremdsystem?" — dann ein API-Aufruf.

9:43 Und erst wenn sie lautet „Was sagen unsere Texte sinngemäß dazu?", ist RAG richtig. Sinngemäß ist hier das Schlüsselwort. Wer den Preis eines Ersatzteils per RAG sucht, bekommt eine plausible Zahl. Das ist schlimmer als keine. Und hier ist die Antwort auf die Frage aus meiner Einleitung. Prüfen Sie zuerst, ob die Suche das richtige Stück geliefert hat.

10:06 Erst danach, ob das Modell daraus richtig geantwortet hat. Retrieval-Qualität und Antwortqualität sind getrennte Maße — und man kann sie getrennt messen, das sehen wir im übernächsten Modul. Der letzte Satz beschreibt, was passiert, wenn man das nicht trennt: Wer beides vermischt, verbessert den Prompt und ändert nichts.

10:24 Diese Erfahrung machen sehr viele Teams, und sie kostet Wochen. Der erste Punkt ist genau dieser Irrweg: Der Prompt wird immer weiter verfeinert, obwohl die Suche danebengreift. Der zweite ist ein Betriebsfehler mit Folgen für die Richtigkeit: Ein gelöschtes Dokument beantwortet weiter Fragen. Der dritte kann heikel werden: Alle Mandanten teilen einen Bestand ohne Filterung — dann erfährt Kunde A etwas über Kunde B.

10:49 Und der vierte ist der Grund für alle anderen: Es gibt keinen Prozess für die Aktualisierung, nur eine einmalige Aufnahme im Projekt.

Übung

10:57 Jetzt bauen Sie eine kleine RAG-Pipeline — vollständig, von der Aufnahme bis zur Antwort mit Fundstelle. Und Sie üben die Fehlersuche, die wir gerade besprochen haben. Kesselwerk hat Gerätehandbücher und Wartungsanweisungen als PDF und Markdown. Die Servicekräfte sollen im Einsatz Fragen dazu stellen können und eine Antwort mit Fundstelle bekommen — Handbuch, Abschnitt, Baureihe.

11:21 Achten Sie auf diese drei Angaben: Sie sind genau die Metadaten, die Sie beim Aufnehmen mitgeben müssen. Wer sie beim Zerlegen vergisst, kann sie später nicht ausgeben — und auch nicht danach filtern. Das ist der Grund, warum die Aufnahme über die Qualität entscheidet. Das Lernziel: Aufnahme, Suche und Antwort so trennen, dass sich eine falsche Antwort einer der drei Stufen zuordnen lässt.

11:44 Erfolgreich sind Sie, wenn drei Testfragen mit Fundstelle beantwortet werden und Sie für eine falsch beantwortete Frage belegen können, ob die Suche oder das Modell danebenlag. Diese Zuordnung ist die eigentliche Fähigkeit — sie unterscheidet systematisches Verbessern von Herumprobieren. Wer früh fertig ist, filtert die Suche über die Baureihe in den Metadaten. Dann sehen Sie unmittelbar, wie viel Präzision ein einziges Metadatenfeld bringt.

12:10 Siebzig Minuten, fünf Schritte. Nehmen Sie die Dokumente auf und setzen Sie je Stück Baureihe und Abschnitt als Metadaten. Probieren Sie den rekursiven Splitter mit zwei Stückgrößen aus und vergleichen Sie — mit denselben Fragen, sonst vergleichen Sie nichts. Prüfen Sie die Suche zunächst direkt über den Baustein, ohne Agenten; so sehen Sie die Treffer roh.

12:30 Erzeugen Sie dann die Antwort mit Fundstelle und halten Sie sie gegen das Handbuch. Und sehen Sie sich für eine falsche Antwort die getroffenen Stücke an — dort steht die Ursache. Vier Fallen, und die erste ist hinterhältig: Die Fundstelle wird vom Modell erzeugt statt aus den Metadaten übernommen. Dann erfindet das Modell auch die Quelle, und Ihre Prüfbarkeit ist dahin. Die zweite ist ein Methodenfehler: Verglichen werden zwei Stückgrößen, aber mit unterschiedlichen Fragen.

12:58 Die dritte ist mit Absicht eingebaut: Die vierte Frage betrifft einen Preis — dafür ist RAG das falsche Werkzeug, und wer das erkennt, hat das vierte Kapitel verstanden. Und die vierte ist ein Betriebsunfall: Die Aufnahme läuft zweimal, und jedes Stück liegt doppelt im Bestand.