Ein kleines RAG-System bauen: Was man dafür wirklich braucht

Ein RAG-System klingt nach großer Infrastruktur, nach Serverfarmen und Data-Engineering-Teams. Für ein kleines, persönliches oder firmeninternes Projekt braucht es davon nichts. Im Kern reichen vier Bausteine: ein paar Dokumente, ein Werkzeug, das Text in Bedeutung übersetzt, ein Ort, an dem diese Bedeutung gespeichert wird, und ein Sprachmodell, das am Ende die Antwort formuliert. Dieser Artikel geht Schritt für Schritt durch, was man dafür konkret braucht, ohne dass Programmiererfahrung vorausgesetzt wird.

Baustein 1: Die Dokumente, aus denen das System schöpft

Am Anfang steht die Frage, worüber das System überhaupt Auskunft geben soll. Das kann ein Ordner mit PDFs sein, eine Sammlung von Word-Dateien, exportierte Notizen oder einfache Textdateien. Wichtig ist nur: Die Inhalte sollten in einem Format vorliegen, aus dem sich Text extrahieren lässt, PDF, Word, Markdown oder reiner Text funktionieren alle gut.

Für ein kleines System reichen schon wenige Dutzend Seiten, um sinnvoll zu testen, ob die Antworten treffend werden. Man muss nicht gleich eine ganze Bibliothek digitalisieren, um loszulegen.

Baustein 2: Die Dokumente in mundgerechte Stücke teilen

Ein Sprachmodell kann nicht ein ganzes 200-seitiges Handbuch auf einmal durchsuchen. Deshalb wird jedes Dokument vorher in kleinere Abschnitte zerlegt, meist ein paar hundert Wörter pro Stück, mit etwas Überlappung zwischen den Abschnitten, damit kein wichtiger Satz genau an der Schnittstelle zerrissen wird.

Dieser Schritt heißt Chunking und entscheidet mehr über die spätere Antwortqualität, als man zunächst annimmt. Zu kleine Abschnitte verlieren Zusammenhang, zu große verwässern die Suche später mit zu viel Nebensächlichem. Für den Einstieg reicht eine einfache Faustregel: Abschnitte in der Größe von etwa einem halben bis einem ganzen Absatz, orientiert an natürlichen Trennstellen wie Überschriften oder Absatzenden statt an einer starren Zeichenzahl.

Baustein 3: Ein Embedding-Modell, das Text in Zahlen übersetzt

Damit ein Computer "ähnliche Bedeutung" erkennen kann, muss Text zuerst in eine Zahlenreihe umgewandelt werden, ein sogenanntes Embedding. Zwei Textabschnitte, die inhaltlich Ähnliches meinen, auch mit ganz unterschiedlichen Wörtern, landen dabei nah beieinander im Zahlenraum.

Google bietet dafür mit der Gemini Embedding API ein Modell an, das genau diese Umwandlung übernimmt (aktuell gemini-embedding-001 für reinen Text, mit einer neueren Variante, die zusätzlich auch Bilder und Audiodateien verarbeiten kann). Der Einstieg ist bewusst niedrigschwellig gehalten: Man meldet sich in Google AI Studio an, holt sich dort einen kostenlosen API-Schlüssel und kann direkt Text zur Umwandlung schicken, ganz ohne eigene Serverinfrastruktur.

Jeder Textabschnitt aus Baustein 2 durchläuft dieses Modell einmal und bekommt so seinen eigenen Zahlen-Fingerabdruck.

Baustein 4: Ein Ort, um diese Zahlen zu speichern und wiederzufinden

Die entstandenen Zahlenreihen müssen irgendwo abgelegt werden, und zwar so, dass man später blitzschnell die ähnlichsten davon zu einer neuen Frage finden kann. Dafür gibt es sogenannte Vektordatenbanken.

Für ein kleines System ist eine aufwendige, gehostete Lösung nicht nötig. Ein beliebter Einstiegspunkt ist ChromaDB: eine kostenlose, quelloffene Vektordatenbank, die ganz ohne eigenen Server läuft und sich direkt auf dem eigenen Rechner installieren lässt. Sie speichert die Embeddings zusammen mit dem dazugehörigen Originaltext und erledigt die Ähnlichkeitssuche im Hintergrund. Für den Anfang reicht das völlig aus; erst wenn ein System auf sehr viele Nutzer oder sehr große Datenmengen wächst, lohnt sich der Umstieg auf eine größere, gehostete Vektordatenbank.

Baustein 5: Das Sprachmodell, das am Ende antwortet

Der letzte Baustein ist das eigentliche Sprachmodell, das aus Frage und gefundenen Textabschnitten eine verständliche Antwort formuliert. Hier bietet sich naheliegend ein Modell aus derselben Familie an, etwa Gemini über die Gemini API, weil Embedding-Modell und Sprachmodell dann aus einem Guss kommen und mit demselben API-Schlüssel nutzbar sind.

Der Ablauf zur Anfragezeit ist dann immer derselbe: Die Nutzerfrage wird ebenfalls in ein Embedding umgewandelt, die Vektordatenbank sucht die ähnlichsten gespeicherten Abschnitte heraus, und diese Abschnitte werden zusammen mit der ursprünglichen Frage an das Sprachmodell geschickt, das daraus die endgültige Antwort formuliert, mit dem Hinweis, sich nur auf die mitgelieferten Textstellen zu stützen.

Wie die Bausteine zusammenspielen

Zusammengefasst braucht ein kleines RAG-System also fünf Dinge, die im Aufbau einmalig zusammengesteckt und dann bei jeder Anfrage erneut durchlaufen werden:

1. Dokumente, die als Wissensquelle dienen.
2. Chunking, um diese Dokumente in überschaubare Abschnitte zu zerlegen.
3. Ein Embedding-Modell (zum Beispiel Gemini Embedding), das jeden Abschnitt in eine Zahlenreihe verwandelt.
4. Eine Vektordatenbank (zum Beispiel ChromaDB), die diese Zahlenreihen speichert und durchsuchbar macht.
5. Ein Sprachmodell (zum Beispiel Gemini), das aus Frage und gefundenen Abschnitten die Antwort schreibt.

Der Aufbau selbst läuft einmalig im Voraus ab: Dokumente einlesen, zerlegen, in Embeddings umwandeln, in der Datenbank speichern. Die eigentliche Nutzung passiert dann bei jeder neuen Frage aufs Neue: Frage einbetten, ähnliche Abschnitte suchen, Antwort generieren lassen.

Womit man realistisch rechnen sollte

Ein kleines RAG-System dieser Art lässt sich mit überschaubarem Aufwand aufbauen, aber es ersetzt keine sorgfältige Pflege. Werden die zugrunde liegenden Dokumente nicht aktualisiert, bleibt auch das System auf altem Stand. Ist die Zerlegung in Abschnitte schlecht gewählt, findet die Suche später nur unvollständige Informationen, und das Sprachmodell füllt Lücken mitunter mit eigenen Vermutungen auf. Wer mit wenigen Dokumenten anfängt, die Antworten stichprobenartig überprüft und die Chunk-Größe bei Bedarf anpasst, bekommt so aber schon mit überschaubarem Aufwand ein funktionierendes, persönliches Nachschlagesystem.