RAG verstehen — wenn AI Dein Wissen braucht
Was RAG wirklich ist, in einfachen Worten. Wann Du es brauchst, wann nicht. Das kürzeste RAG-Erklärstück im Netz.
Das Problem
Du fragst ChatGPT nach einer Information die in Deinem eigenen Handbuch steht. ChatGPT weiss es nicht, weil es mit dem Wissen der Welt trainiert wurde, nicht mit Deinem Handbuch. Jetzt hast Du zwei Möglichkeiten: die Information bei jeder Frage wieder reinkopieren, oder eine Lösung bauen die das automatisch macht. Die zweite Lösung heisst RAG. Retrieval-Augmented Generation.
Was die Wörter bedeuten
"Retrieval" ist nur ein schönes Wort für "Suchen". "Augmented" heisst "ergänzt". "Generation" heisst "Antwort erzeugen".
Also: Wenn Du eine Frage stellst, sucht das System zuerst in Deinem eigenen Material, packt die gefundenen Textstellen automatisch in den Prompt, und das Modell beantwortet Deine Frage mit dieser zusätzlichen Information. Du siehst davon nichts. Du fragst wie immer, die Antwort kommt passend zurück, nur eben mit Deinem Wissen drin.
Wann brauchst Du RAG wirklich
Du brauchst RAG wenn drei Sachen stimmen:
- Du hast eigenes Material das nicht im Training der Modelle drin war (Handbücher, Kunden-Protokolle, interne Prozesse, Produkt-Spezifikationen, medizinische Patienten-Akten, Anwaltsfälle)
- Das Material ist zu gross um es jedes Mal in den Prompt zu kopieren (mehr als ein paar Seiten)
- Du willst dass die Antwort sich präzise auf dieses Material bezieht und nicht halluziniert wird
Wenn eine dieser drei Bedingungen nicht stimmt, brauchst Du kein RAG. Wenn Dein Material in einen Chat-Kontext passt, kopier es einfach rein und fertig. Wenn Du keine private Daten hast und Standard-Infos reichen, reicht ChatGPT allein.
Wie ein RAG-System aufgebaut ist
Das Gerüst hat immer die gleichen vier Teile:
- Deine Dokumente irgendwo liegend. PDFs, Word-Dateien, Datenbanken, egal.
- Ein Zerleger der diese Dokumente in kleinere Stücke schneidet, sogenannte Chunks. Meistens ein paar Absätze pro Chunk.
- Eine Vektor-Datenbank die diese Chunks so speichert dass man sie semantisch durchsuchen kann (also nicht "welche Chunks enthalten das Wort X", sondern "welche Chunks bedeuten ungefähr das Gleiche wie meine Frage").
- Eine Anwendung die Deine Frage nimmt, in der Vektor-Datenbank sucht, die passendsten Chunks rausholt, sie zusammen mit der Frage in den Prompt packt, und die Antwort erzeugt.
Das ist RAG. Komplette Architektur in vier Sätzen.
Warum semantische Suche und nicht Keyword-Suche
Weil Keyword-Suche versagt wenn Dein User anders formuliert als Dein Dokument. Wenn im Handbuch steht "wir verwenden Magic-Link-Authentifizierung" und der User fragt "wie logge ich mich ohne Passwort ein" — eine Keyword-Suche findet gar nichts, weil kein Wort übereinstimmt. Eine semantische Suche versteht dass beide Texte das Gleiche meinen und findet die richtige Stelle.
Die Zauberei passiert über sogenannte Embeddings. Das sind lange Zahlenlisten die für einen Textblock stehen und die sich mathematisch vergleichen lassen. Wenn zwei Texte ähnlich bedeuten, sind ihre Embeddings mathematisch nah beieinander. Das ist alles.
Du musst das nicht selbst implementieren. Es gibt fertige Werkzeuge die das Embedding-Geraffel komplett für Dich erledigen. Du gibst Text rein, bekommst Vektoren raus, speicherst sie, suchst später.
Die typischen Stolpersteine
Falsche Chunk-Grösse: Zu klein und der Chunk hat keinen Kontext. Zu gross und zu viel Irrelevantes kommt mit. Sweet Spot liegt meistens bei 300 bis 800 Worten pro Chunk.
Fehlende Metadaten: Wenn Du nicht mitspeicherst aus welchem Dokument ein Chunk kommt, kannst Du keine Quellen-Angabe machen. Immer mindestens Dokument-Titel + Seite + Datum mitspeichern.
Keine Aktualisierungs-Strategie: Was passiert wenn ein Dokument geändert wird? Wenn Du es nicht neu chunkst und neu indexierst, gibt Dein RAG-System veraltete Antworten. Ein Update-Mechanismus ist Pflicht.
Zu viele irrelevante Treffer: Wenn Deine Vektor-DB zu jeder Frage dreissig Chunks zurückgibt und die meisten nichts mit der Frage zu tun haben, wird das Modell verwirrt. Meistens reichen fünf bis zehn Treffer. Qualität vor Menge.
RAG vs. Long-Context
Neuere Modelle haben Context-Fenster von einer Million Tokens. Das heisst Du könntest theoretisch ein ganzes Buch reinkopieren statt RAG zu bauen. Wann lohnt sich das?
Bei einmaligem Einsatz: Buch reinkopieren und fragen. Fertig.
Bei wiederholtem Einsatz über viele User und viele Fragen: immer noch RAG. Tokens kosten Geld. Bei 1000 Anfragen pro Tag, die jede das Buch mitkopieren, wird das sehr teuer. RAG pickt nur die relevanten Stellen raus und spart den Rest.
Was RAG NICHT kann
RAG ersetzt kein gutes Training. Wenn Dein Modell nicht medizinisch ausgebildet ist, wird es auch mit noch so guten RAG-Dokumenten keine sinnvollen medizinischen Empfehlungen geben. RAG gibt dem Modell Fakten. Es ändert nicht was das Modell kann.
RAG ersetzt auch keine Datenbank-Abfragen. Wenn Deine Frage "wie viele Kunden haben wir diese Woche gewonnen" ist, braucht es SQL, kein RAG. Wenn Deine Frage "was steht in unserem Willkommens-E-Mail" ist, ist RAG richtig.
Das fertige Beispiel — wie eine Kanzlei RAG nutzt
Anwaltskanzlei hat 2000 PDF-Gerichtsurteile im Archiv. Jeder Anwalt schlägt regelmässig nach für seine Fälle. Die PDFs passen nicht alle in den Claude-Context, und manuelles Suchen im Intranet dauert lang.
Lösung: Kanzlei lässt alle PDFs durch ein RAG-System jagen, einmal. Danach fragt der Anwalt in einer Claude-Oberfläche "gab es ein Urteil zu Betriebsausgaben bei Homeoffice vor 2024?" und bekommt drei relevante Urteile mit Zitat + Fundstelle zurück. Zeit-Ersparnis: 30 Minuten pro Frage. Fehlerquote sinkt weil Claude jetzt konkrete Urteile nennen kann statt sich was auszudenken.
Das ist RAG in Praxis.
Was Du jetzt machen kannst
Wenn Du RAG selbst bauen willst, gibt es fertige Baukästen: LlamaIndex, LangChain, Haystack für Python. Vercel AI SDK für JavaScript. Alle mit Tutorials für die ersten Schritte.
Wenn Du RAG nutzen willst ohne zu bauen: ChatGPT hat "Custom GPTs" mit File-Upload, Claude hat "Projects" mit eigenem Knowledge-Bereich, beide machen das automatisch für kleine Dokumenten-Mengen. Das ist RAG für Nicht-Entwickler, verpackt in die normale Chat-Oberfläche.
Wie es weitergeht
Im Level 4 zeigen wir wie Du nicht nur Dokumente, sondern auch Memory und Knowledge-Graphs portabel über mehrere AI-Tools verteilen kannst. Das ist ein Schritt weiter als RAG: nicht nur "Dokumente durchsuchen" sondern "Wissen strukturiert ablegen und verlinken".
Und in Level 6 baust Du selbst das Backend dazu, als eigener MCP-Server mit Vektor-DB-Anbindung. Dann weisst Du nicht nur was RAG ist, sondern hast selbst einen RAG-Service der zu Deinem eigenen Projekt passt.