⚡ HomelabVergleich

Lokale RAG-Pipeline: eigene Dokumente durchsuchen, ohne sie in die Cloud zu geben

Du hast einen Berg eigener Unterlagen — Handbücher, Verträge, Notizen, ein Wiki-Export — und möchtest Fragen daran stellen können, ohne alles zu einer US-Cloud hochzuladen. Genau dafür gibt es Retrieval-Augmented Generation (RAG). Dieser Artikel zeigt, wie eine solche Pipeline lokal aussieht, welche Bausteine es wirklich gibt, und wo die typischen Qualitätsfallen liegen.

Eine Abgrenzung vorweg, damit keine Verwechslung entsteht: Der Artikel LLM-Server-Software im Vergleich behandelt die Frage, welche Software ein Sprachmodell als Dienst betreibt — Ollama, llama.cpp server, vLLM, LM Studio. RAG beginnt erst danach. Ein laufender LLM-Server ist die Voraussetzung, nicht das Thema. Dieser Text beschäftigt sich mit dem Weg von deinen Dokumenten zur fundierten Antwort mit Quellenangabe: dem Einbetten, Speichern, Wiederfinden und Belegen.

Was RAG gegenüber reinem Prompten mit Volltext ändert

Reines Prompten mit Volltext heißt: Du kopierst ganze Dokumente in die Eingabe und hoffst, dass das Modell die richtige Stelle findet. Das funktioniert bei einer Seite. Bei einem Handbuch mit 300 Seiten passt der Text gar nicht mehr in den Kontext — und selbst wenn er passt, sinkt die Treffsicherheit, weil das Modell zwischen viel Irrelevantem die eine relevante Passage suchen muss. Außerdem zahlst du bei jedem Aufruf für den gesamten Text, auch wenn du nur eine Zahl brauchst.

RAG dreht das um. Statt alles zu übergeben, sucht der Suchschritt zuerst die passenden Abschnitte und legt dem Modell nur diese vor. Der Unterschied liegt also nicht im Sprachmodell, sondern in der Vorarbeit: einem durchsuchbaren Index, der aus Textabschnitten und ihren Zahlen-Vertretern (Embeddings) besteht. Das Modell bekommt bei jeder Frage nur die drei bis fünf relevantesten Abschnitte und soll daraus antworten — mit Verweis auf die Quelle. Der Nutzen in drei Punkten: der Kontext bleibt klein und bezahlbar, die Antwort stützt sich auf belegbare Stellen statt auf Modellgedächtnis, und du kannst nachvollziehen, woher eine Aussage stammt. RAG macht ein Modell nicht klüger — es gibt ihm nur die richtigen Seiten auf den Tisch.

Der Datenfluss in sieben Schritten

Eine RAG-Pipeline hat eine feste Reihenfolge. Jeder Schritt hängt vom vorherigen ab; wenn du einen überspringst, merkst du das erst an der Antwortqualität.

1. Dokumente sammeln. Alle Quellen zusammenführen: Dateiordner, Wiki-Export, Mail-Anhänge, Netzlaufwerk. Wichtig ist eine Quelle der Wahrheit — dieselbe Datei zweimal im Index erzeugt Dubletten in den Treffern.

2. Aufbereiten. Aus dem Rohformat reinen Text machen: PDF-Textschicht auslesen, Scans per OCR in Text verwandeln, HTML/Markdown von Formatierungsballast befreien. Hier entsteht die Textqualität, die alle späteren Schritte trägt.

3. In Abschnitte teilen (Chunking). Den Text in handliche Stücke zerlegen, die als Einheit gesucht werden. Zu große Stücke verwässern die Antwort, zu kleine verlieren den Zusammenhang.

4. Einbetten. Jeden Abschnitt mit einem Embedding-Modell in einen Zahlenvektor umrechnen. Ähnliche Bedeutung ergibt ähnliche Vektoren — das ist die Grundlage der semantischen Suche.

5. In die Vektor-Datenbank schreiben. Die Vektoren samt Metadaten (Quelldatei, Kapitel, Mandant, Datum) speichern und einen Suchindex anlegen.

6. Retrieval. Die Frage ebenfalls einbetten und die ähnlichsten Abschnitte abrufen — meist die k nächsten Nachbarn im Vektorraum.

7. Antwort mit Quellenangabe. Die gefundenen Abschnitte plus die Frage an das Sprachmodell geben und eine Antwort verlangen, die ihre Fundstellen zitiert. Der Rücksprung von der Aussage zur Quelldatei ist der wichtigste Teil des Ganzen.

Komponenten und welchen Zuschnitt man nimmt

Einbettungsmodell: lokal oder API

Das Embedding-Modell bestimmt, wie gut ähnliche Stellen gefunden werden, und welche Vektorlänge die Datenbank erwartet. Zwei Wege:

Die harte Regel: Vektorlänge und Modell gehören zusammen. Wer das Modell tauscht, muss den Index neu bauen (siehe Qualitätsfallen).

Vektor-Datenbanken

Die Vektor-Datenbank speichert die Vektoren und findet die nächsten Nachbarn schnell wieder.

LiteRAG, fertige Oberflächen und Frameworks

Vergleichstabelle

| Komponente | Einrichtung | Speicherbedarf | Modellwechsel | Offline-Fähigkeit |

|---|---|---|---|---|

| Chroma | Niedrig – als Bibliothek in dein Skript, keine Serverinstallation | Gering – Vektoren und Metadaten in einer lokalen Datei/Verzeichnis | Einfach: neues Embedding-Modell, Collection neu befüllen (Vektorlänge muss passen) | Vollständig – läuft rein lokal, kein Netzwerk nötig |

| Qdrant | Mittel – Container starten, Collection anlegen (Größe + Distanz) | Mittel – eigener Dienst mit eigenem Datenspeicher; wächst mit Anzahl der Abschnitte | Collection mit passender Vektorlänge neu anlegen und neu befüllen | Vollständig – selbst gehostet im eigenen Netz |

| pgvector | Mittel – Postgres-Erweiterung aktivieren, Spalte + Index anlegen | Gering zusätzlich – nutzt deine bestehende Postgres-Instanz und deren Backup | Spalte/Index neu anlegen; Rechte und Backups bleiben erhalten | Vollständig – Teil deiner eigenen Datenbank |

| FAISS | Niedrig – reine Bibliothek im Python-Skript | Gering – Index als Datei auf Platte | Index neu bauen; Metadaten-Filter und Rechte selbst ergänzen | Vollständig – reine lokale Bibliothek |

| LiteRAG | Mittel – Framework einrichten, Graph-Index aufbauen | Höher – Graph-Struktur zusätzlich zu Vektoren | Modellwechsel bedeutet Neuaufbau des Graph-Index | Vollständig – lokal betreibbar |

| Open WebUI (RAG) | Niedrig – Container/Installation, Dokumente im Web-UI hochladen | Mittel – Embeddings + Dokumentstore der Instanz | RAG_EMBEDDING_MODEL ändern und Bestand neu einbetten | Vollständig lokal, wenn Embeddings lokal laufen |

| AnythingLLM | Niedrig – Desktop-App oder Container, Workspace anlegen | Mittel – je Workspace eigene Vektoren + Quelldokumente | Embedder pro Workspace umstellbar, Dokumente neu einbetten | Vollständig lokal bei lokalem Embedder |

| LlamaIndex | Hoch – eigenes Python-Projekt, Verdrahtung selbst | Gering – nur Framework; Speicher steckt im gewählten Vector-Store | Modell im Code tauschen, Index neu bauen | Vollständig – reines Framework |

Kurz gefasst: Für einen Einzelplatz nimmst du Chroma oder FAISS, für einen Dienst im Netz Qdrant, und wenn Postgres schon läuft, ist pgvector der geringste Zusatzaufwand. Fertige Oberflächen wie Open WebUI oder AnythingLLM sparen dir den Eigenbau, kosten aber an Kontrolle über Chunking und Filter.

Wie Dokumenttypen unterschiedlich behandelt werden

Alle Dokumente landen als Text im Index — aber der Weg dorthin ist je nach Typ anders, und genau hier entstehen die meisten stillen Fehler.

Drei realistische Anleitungen

Anleitung 1: Reine Notizsuche auf dem eigenen Rechner

Ziel: Deine eigenen Notizen, Markdown-Dateien und Textdateien semantisch durchsuchen — kein Mehrbenutzer, kein Server, kein Internet.

Voraussetzungen: Python-Umgebung mit chromadb und einem Einbettungsmodell (lokal über sentence-transformers oder Ollama).

Schritt 1 — Notizen einlesen. Sammle alle .md- und .txt aus deinem Notizordner, lies sie ein und teile sie nach Überschriften in Abschnitte. Als Metadaten speicherst du den Dateipfad und die Überschrift.

Schritt 2 — Einbetten. Erzeuge für jeden Abschnitt das Embedding. Lokal reicht ein kleines mehrsprachiges Modell; für einen Notizbestand ist die Geschwindigkeit ausreichend.

Schritt 3 — In Chroma ablegen. Mit PersistentClient(path="./chroma") und get_or_create_collection("notizen"), dann add(documents, embeddings, id="pfad#abschnitt", metadatas={"pfad": ..., "titel": ...}).

Schritt 4 — Suchen. Frage einbetten und query(query_embeddings=[...], n_results=5) aufrufen. Du bekommst die fünf ähnlichsten Abschnitte samt Pfad zurück — für eine Notizsuche ist das oft schon das Ergebnis, ganz ohne Sprachmodell.

Schritt 5 — Optional beantworten lassen. Willst du eine formulierte Antwort, gib die gefundenen Abschnitte und die Frage an ein lokales Modell (Ollama) und verlange die Quellenangabe.

Anleitung 2: Frage-Antwort über Handbuch oder Vertragsdokumente

Ziel: Fragen wie „Welche Kündigungsfrist steht im Vertrag von 2024?" oder „Was sagt das Handbuch zur Wartung?" — mit Belegstelle.

Voraussetzungen: Ein laufender LLM-Server (siehe LLM-Server-Software im Vergleich), ein Embedding-Modell, eine Vektor-Datenbank (hier Qdrant oder Chroma).

Schritt 1 — Dokumente aufbereiten. Vertrags-PDFs haben meist eine Textschicht; Handbücher teils nicht. Prüfe stichprobenweise, ob Text herauskommt, und rüste für Scans OCR nach.

Schritt 2 — Abschnittsgröße festlegen. Vertragsklauseln sind kurz; Handbuchabschnitte länger. Setze die Stückgröße so, dass eine vollständige Klausel in ein Stück passt, und gib etwas Überlappung mit, damit ein Satz über die Grenze nicht zerrissen wird.

Schritt 3 — Einbetten und ablegen. Metadaten tragen hier Dokumentname, Datum und Abschnittsnummer — sie erscheinen später in der Quellenangabe.

Schritt 4 — Antwort mit Zitat erzwingen. Der Prompt muss verlangen, dass die Antwort nur aus den gelieferten Abschnitten stammt und jede Aussage mit Dokumentname und Abschnitt belegt. Ohne diese Vorgabe liefert das Modell dir flüssige Sätze ohne Fundstelle — und du kannst nichts prüfen.

Schritt 5 — Gegentest. Stelle eine Frage, deren Antwort du kennst, und eine, deren Antwort es in den Unterlagen gar nicht gibt. Bei der zweiten muss „dazu finde ich nichts" kommen — kommt ein erfundener Satz, ist die Vorgabe zu schwach oder es werden zu viele Abschnitte übergeben.

Anleitung 3: Mehrbenutzer-Setup mit Zugriffskontrolle je Mandant

Ziel: Mehrere Personen oder getrennte Mandanten fragen ihre eigenen Unterlagen ab — und niemand sieht fremde Dokumente.

Voraussetzungen: Eine Vektor-Datenbank mit Metadatenfilter (Qdrant, pgvector oder Chroma), eine Oberfläche mit Benutzerkonten, ein gemeinsames Einbettungsmodell.

Schritt 1 — Mandant als Metadatenfeld. Jeder Abschnitt bekommt ein Feld mandant (oder gruppe). Das ist der Schlüssel, an dem später gefiltert wird.

Schritt 2 — Beim Abrufen filtern, nicht danach. Die Berechtigung muss in die Abfrage hinein, nicht erst in die Oberfläche. In Qdrant per filter, in pgvector als WHERE-Bedingung, in Chroma via where={"mandant": "a"}.

Schritt 3 — Getrennte Collections als Alternative. Statt eines Metadatenfeldes kannst du je Mandant eine eigene Collection anlegen. Mehr Aufwand, aber sauberer isoliert — ein vergessener Filter kann dann nicht fremde Daten liefern.

Schritt 4 — Oberfläche nur als Tür, nicht als Schloss. Benutzerkonten in Open WebUI oder AnythingLLM sind die Anmeldung. Sie sind nicht die Zugriffskontrolle auf den Index — die liegt in der Abfrage. Wer nur die Oberfläche absichert, aber alle Dokumente in einem gemeinsamen, ungefilterten Index hält, hat in Wahrheit keine Trennung.

Schritt 5 — Rechte testen. Melde dich als Mandant A an und stelle absichtlich eine Frage, deren Antwort nur in den Unterlagen von Mandant B steht. Kommt eine Antwort, ist der Filter falsch — dann nicht in Produktion gehen.

Qualitätsfallen und Abhilfe

Falsche Abschnittsgröße. Zu große Abschnitte (etwa eine ganze PDF-Seite) enthalten viel Beiwerk; der relevante Satz geht in der Ähnlichkeitsbewertung unter. Zu kleine Abschnitte (Halbsätze) verlieren den Zusammenhang. Abhilfe: an der Struktur trennen, nicht an der Zeichenzahl — nach Überschriften, nach Absätzen, nach Klauseln. Überschriften im Abschnitt mitführen. Stückgröße an echten Fragen testen, nicht theoretisch festlegen.

Embedding-Modell tauschen ohne Neuaufbau des Index. Der häufigste stille Fehler. Vektoren aus zwei verschiedenen Modellen liegen in unterschiedlichen Räumen und sind nicht vergleichbar — die Suche liefert dann Unsinn, ohne eine Fehlermeldung. Auch eine andere Vektorlänge passt nicht in die alte Collection. Abhilfe: Modellwechsel immer als Neuindex behandeln: alle Abschnitte neu einbetten und die Collection neu anlegen.

Antworten ohne Quellenangabe. Ohne Prompt-Vorgabe liefert das Modell gern schöne, unbelegte Sätze. Abhilfe: die Quelle zur Pflicht machen — im Prompt verlangen, dass jede Aussage Dokumentname und Abschnitt nennt, und in der Oberfläche die Fundstelle mit anzeigen. Eine Antwort ohne Beleg ist im Zweifel nicht brauchbar.

Halluzination trotz Belegen. Selbst mit gelieferten Abschnitten kann das Modell etwas ergänzen, was dort nicht steht — und trotzdem eine Quelle dranhängen. Abhilfe: im Prompt schreiben, dass nur belegt werden darf, was im Text steht, und bei fehlender Grundlage ausdrücklich „nicht in den Unterlagen" zu antworten. Der Gegentest aus Anleitung 2 deckt das auf.

Berechtigungen, die nur die Schnittstelle betreffen. Die Oberfläche zeigt nur die eigenen Dokumente — die Vektor-Datenbank hält aber alles in einem ungefilterten Index, und die Abfrage holt ohne Filter über alle Mandanten. Abhilfe: Rechte in der Abfrage erzwingen (Metadatenfilter oder getrennte Collection), nicht in der Anzeige.

Häufige Fehler — mit realen Beispielen

Beispiel 1: Der leere Scan-Index. Ein Nutzer lädt einen Ordner eingescannte Rechnungen in Open WebUI, stellt Fragen und bekommt entweder nichts oder frei erfundene Beträge. Ursache: Die PDFs hatten keine Textschicht, das System hat leere Abschnitte eingebettet. Lehre: vor dem Index prüfen, ob überhaupt Text herauskommt — bei Scans erst OCR, dann einbetten.

Beispiel 2: Der unsichtbare Modellwechsel. Jemand stellt in AnythingLLM den Embedder von einem kleinen auf ein größeres Modell um, ohne den Bestand neu einbetten zu lassen. Die Suche liefert danach zufällig wirkende Treffer. Ursache: alte Vektoren im neuen Raum. Lehre: Modellwechsel heißt immer Neuindex, nie nur Umschalten.

Beispiel 3: Die zu grobe Trennung. Ein Handbuch wird komplett seitenweise eingebettet. Fragen wie „Welcher Drehmomentwert gilt für Schraube X?" liefern zwar die richtige Seite, aber das Modell wählt daraus den falschen Wert. Lehre: kleine, in sich geschlossene Abschnitte — eine Tabelle oder ein Absatz, nicht eine Seite.

Beispiel 4: Zwei Mandanten, ein Index. Zwei Firmen teilen sich eine Instanz, alle Dokumente liegen mit einem Mandantenfeld zusammen. Die Oberfläche zeigt nur die eigenen Dateien — aber die Suche filtert nicht, und in einer Antwort taucht eine Vertragsklausel der anderen Firma auf. Ursache: Berechtigung nur in der Anzeige. Lehre: Der Filter gehört in die Abfrage.

Beispiel 5: Die doppelte Quelle. Derselbe Ordner liegt einmal im Original und einmal als Kopie im Index. Jede Antwort zitiert denselben Inhalt zweimal und wirkt widersprüchlich. Lehre: eine Quelle der Wahrheit, Dubletten vor dem Einbetten aussortieren.

Beispiel 6: Kein Backup des Index. Der Vektor-Index ist nach einem Ausfall weg, und niemand weiß mehr, welche Abschnittsgröße und welches Modell benutzt wurde. Lehre: Index und seine Konfiguration gehören ins Backup — siehe Datenbank-Backups.

FAQ

Brauche ich dafür eine GPU?

Für das Embedding selbst meist nicht zwingend. Kleine Modelle wie all-MiniLM-L6-v2 laufen auf der CPU, das Erstindexieren dauert dann länger, ist aber machbar. Eine GPU beschleunigt das Einbetten großer Bestände deutlich. Erst das Sprachmodell, das die Antwort formuliert, profitiert stark von GPU — und das ist derselbe Server, den du ohnehin für Textaufgaben brauchst. Kurz: RAG allein läuft ohne GPU; willst du flüssige Antworten, hilft sie.

Wie oft muss ich neu einbetten?

Nur wenn sich etwas ändert. Kommen Dokumente dazu oder ändern sie sich, bette die betroffenen Abschnitte neu ein und ersetze sie im Index — kein Grund, alles neu zu bauen. Neu einbetten musst du immer dann, wenn du das Embedding-Modell wechselst, weil dann der ganze Vektorraum ein anderer ist. Für den Grundbestand gilt: einmal einbetten, danach nur noch pflegen.

Kann ich PDF-Dateien einfach so hineinwerfen?

Nur, wenn sie eine Textschicht haben. Bei Scans ohne Text bekommst du leere Abschnitte. Prüfe vorher stichprobenweise, ob Text herauskommt, und rüste für Scans OCR nach.

Muss ich die Vektor-Datenbank separat sichern?

Ja. Der Index ist genauso ein Datenbestand wie deine Unterlagen und nach einem Ausfall nicht ohne die Quelldateien und die Einbettungs-Einstellungen rekonstruierbar. Sichere ihn mit.

Reicht eine fertige Oberfläche oder brauche ich Eigenbau?

Für einen Einzelplatz oder ein kleines Team reicht Open WebUI oder AnythingLLM. Eigenbau mit Chroma, Qdrant oder LlamaIndex lohnt sich, wenn du bestimmtes Chunking, eigene Filter, getrennte Mandanten oder eine eigene Anwendung brauchst, die keine fertige Oberfläche bietet.

Interne Verlinkungsvorschläge zu vorhandenen BsN-Artikeln

Bildvorschläge

Bild 1

Bild 2

Bild 3

Bild 4

Bild 5

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.