Es ist ein Sonntagnachmittag im Juli, und Felix sitzt vor einem grauen Kasten, der neben seinem Router im Wohnzimmerschrank leise vor sich hin summt. Der Kasten ist eine NAS (Network Attached Storage, ein kleiner, immer laufender Speicherserver für zu Hause), und auf ihr liegen drei Terabyte seines Berufslebens. Angebote, Verträge, Protokolle, gescannte Rechnungen, Fotos von Whiteboards, eine Handvoll Excel-Dateien, die irgendjemand vor Jahren angefangen und nie zu Ende gebracht hat. Alles da. Nichts findbar. Daneben steht, meist im Ruhezustand, ein Mac mini mit Apple-Silicon-Chip, den wird Felix später für die rechenintensiven Arbeiten brauchen, aber dazu kommen wir, wenn es so weit ist.
Wer die erste Folge dieser Serie gelesen hat, kennt Felix schon. Damals suchte er vier Stunden lang nach einer Präsentation, die er vor Jahren einmal gehalten hatte, die mit dem Bild aus den drei verschachtelten Kreisen, und fand sie nicht, weil die Volltextsuche seines Betriebssystems zwar jedes Wort kennt, aber keine Ahnung hat, was die Wörter bedeuten, und weil Felix nicht mehr wusste, nach welchen Wörtern er überhaupt suchen sollte. Am Ende jenes Artikels stand ein Versprechen: Beim nächsten Mal schauen wir uns an, wie man das Ding baut, das dieses Problem löst. Heute lösen wir das Versprechen ein und zeichnen den kompletten Bauplan.
Und weil das ein ehrlicher Text werden soll, sage ich gleich vorweg: Wir schrauben heute nicht wirklich an Felix‘ NAS. Dieser Artikel ist der Bauplan, nicht das fertige Gebäude, die Landkarte, auf der jede Station eingezeichnet ist, mit den Entscheidungen, die an jeder Weggabelung anstehen, und den Fallen, die man kennen sollte, bevor man den ersten Handschlag tut. Es wird kein Zaubertrick, und an vielen Stellen ist die einfache Lösung die bessere als die beeindruckende. Wer diesen Plan verstanden hat, kann anschließend etwas bauen, an dessen Aufbau selbst viele größere Organisationen noch arbeiten: einen durchsuchbaren, befragbaren Gedächtnisspeicher, der die eigenen Dokumente kennt, auf zwei kleinen Geräten im eigenen Heimnetz, die zusammen weniger Platz brauchen als ein Aktenordner.
Warum das plötzlich alle wollen (und fast keiner hinbekommt)
Bevor wir loslegen, kurz die Frage: Warum ist das überhaupt ein Thema? Die Software-Firma Atlassian hat 2025 rund 12.000 Wissensarbeitende und 200 Führungskräfte befragt und kam zu dem Ergebnis, dass Teams im Schnitt ein Viertel ihrer Arbeitswoche mit der reinen Suche nach Informationen verbringen. Gleichzeitig behaupten laut dem Beratungshaus McKinsey inzwischen 88 Prozent aller Organisationen, KI in mindestens einer Funktion zu nutzen, aber nur 7 Prozent haben sie wirklich flächendeckend im Betrieb ausgerollt. Zwischen „mal ausprobiert“ und „unsere KI kennt unser Unternehmen“ liegt ein Graben, in den fast alle fallen. Der Grund ist selten das Modell. Es ist das Wissen, auf das es zugreifen kann.
Das ist der Punkt, an dem der Begriff fällt, um den sich alles dreht: RAG, kurz für Retrieval Augmented Generation. Statt einem Sprachmodell bei jeder Frage die kompletten drei Terabyte in den Rachen zu schieben (was technisch gar nicht ginge und teuer wäre), baut man vorher ein Bedeutungsverzeichnis. Wird eine Frage gestellt, schlägt das System dort nach, zieht die drei, vier wirklich relevanten Textstellen heraus und legt nur die dem Modell vor, das erhält damit echte Belege als Grundlage und kann seine Antwort darauf stützen. Halluzinationen verhindert das nicht vollständig; deshalb gehören Quellenangaben und Felix‘ Testset später zwingend dazu. Die konzeptionelle Tour durch dieses Prinzip steht im ersten Artikel; hier geht es um die Architektur.
Ein Wort noch zum Titel, denn er steckt einen bewussten Kontrast ab. Seit Jahren geistert der Begriff „Second Brain“ durch die Produktivitäts-Szene: die Idee, man müsse nur alles fein säuberlich in Obsidian, Notion oder einer anderen Notiz-App ablegen, dann habe man ein zweites Gehirn. Wer das versucht hat, weiß: Man bekommt vor allem ein zweites Chaos. Ablegen ist nicht dasselbe wie Wiederfinden. Der Weg vom Second Brain zum echten Wissensmanagement führt genau über diesen Unterschied. Schon 1945 formulierte der amerikanische Ingenieur Vannevar Bush das eigentliche Problem: nicht das Speichern von Wissen, sondern das Herstellen eines wiederauffindbaren Zusammenhangs. Genau daran arbeitet RAG.
Wie ein solcher persönlicher Wissensspeicher aussieht, wenn man ihn mit einem Chat-Bot verbindet, hat die zweite Folge dieser Serie am Beispiel von Mark gezeigt, der seinen Obsidian-Speicher an einen kleinen Bot im Heizungskeller angeschlossen hat und ihn per Telegram befragt. Felix‘ Aufgabe ist die andere Hälfte: das Archivproblem. Am Ende werden wir beide Fäden zusammenknoten.
Bevor irgendein Werkzeug installiert wird: aufräumen
Es gibt eine Versuchung, bei solchen Projekten sofort loszulegen, Software zu installieren und Dokumente hineinzukippen. Felix widersteht ihr, und das ist die erste kluge Entscheidung. Denn eine RAG-Pipeline ist nur so gut wie das, was vorne hineinkommt. Also macht er zuerst Inventur.
Auf seiner Synology-NAS läuft dafür ein bordeigenes Werkzeug namens Storage Analyzer, das einen Bericht erzeugt: Welche Dateitypen liegen wo, wie viel davon sind Dubletten, welche Ordner sind aufgebläht. Für die Dublettenjagd nimmt er zusätzlich ein kleines, schnelles Kommandozeilen-Werkzeug namens fclones, aber, und das ist wichtig, ausschließlich im Lese-Modus. Erst ein Backup, erst prüfen, dann irgendwann vielleicht löschen. Ein RAG-System, das über halbe Karteileichen und dreifach abgelegte Entwürfe stolpert, gibt später wirre Antworten.
Wichtiger als das Aufräumen ist aber die zweite Übung: das Sortieren nach Vertraulichkeit. Aus dem Mark-Artikel stammt eine simple Ampel, die Felix hier wiederverwendet. Grün sind harmlose, eigene Unterlagen, die dürfen lokal oder auch mal durch einen Cloud-Dienst laufen. Gelb sind Kunden- und Personendaten, die verarbeitet Felix ausschließlich lokal, mit einem Berechtigungsfilter, und ihre Zugriffsrechte müssen erhalten bleiben. Rot sind Geheimnisse, hochsensible Personendaten, vertraglich ausgeschlossene Dinge, die durchlaufen weder OCR noch Indexierung, sondern bleiben ganz außen vor. Das ist ausdrücklich Felix‘ eigene, bewusst strenge Hausregel, kein Rechtsgutachten: Kunden- oder Personendaten dürfen unter den richtigen vertraglichen und datenschutzrechtlichen Voraussetzungen durchaus in einer Cloud verarbeitet werden. Felix entscheidet sich für die lokale Variante, weil sie ihm die Prüferei erspart und die Kontrolle behält. Diese Dreiteilung ist keine sprachliche Kosmetik, sondern die Grundlage der ganzen Sicherheitsarchitektur, und sie zieht sich durch jede folgende Station.
Dahinter steckt mehr als Vorsicht. Die deutschen Datenschutzbehörden haben in ihrer Orientierungshilfe zu KI und Datenschutz ein paar Grundsätze formuliert, die sich hier auszahlen. Zwei davon sind für den Bau entscheidend. Erstens: Die Berechtigungen eines Quelldokuments müssen bis zur angezeigten Antwort erhalten bleiben. Ein gemeinsamer Suchindex darf nicht „vergessen“, dass eine bestimmte Datei eigentlich nur für die Buchhaltung war. Zweitens: Wird ein Dokument im Original gelöscht, muss diese Löschung überall ankommen, in den Textschnipseln, in den Vektoren, in den Zwischenspeichern. Bei den Sicherungskopien ist das eine Frage des Aufbewahrungszyklus, nicht des sofortigen Zugriffs. Wer das nicht von Anfang an mitplant, baut sich ein Datenschutz-Problem ein, das später kaum noch zu entwirren ist.
Station 1: OCR, aus einem Foto von Text wird Text
Jetzt geht es los. Die erste Station der Pipeline ist die, die in den meisten RAG-Erklärungen fast untergeht und die trotzdem alles trägt: OCR (Optical Character Recognition, die maschinelle Umwandlung von Bildern in maschinenlesbaren Text).
Warum braucht man das? Weil Felix‘ Archiv eben nicht aus sauberen Textdateien besteht. Da liegen gescannte Verträge, abfotografierte Whiteboards, PDFs mit zweispaltigem Layout und Tabellen, die quer über die Seite laufen. Ein Sprachmodell kann mit einem Scan, der eigentlich nur ein Foto von Buchstaben ist, wenig anfangen. Also übersetzt man jedes Dokument zuerst in sauberes, strukturiertes Markdown (ein schlichtes Textformat, in dem Überschriften, Listen und Tabellen mit einfachen Zeichen markiert werden).
Hier trifft Felix seine erste echte Entscheidung, und sie fällt entlang der Ampel. Für die Cloud-Variante gibt es Mistral OCR vom französischen KI-Unternehmen Mistral, inzwischen in der vierten Version. Die ist gut, schnell und günstig, grob zwischen 1,75 und 3,50 Euro pro tausend Seiten, je nachdem ob man es eilig hat oder den günstigeren Stapelbetrieb nutzt. Aber die Dokumente verlassen dafür das Haus. Für Felix‘ grüne Dokumente ist das in Ordnung; für die gelben kommt es nicht in Frage, und die roten wandern ohnehin gar nicht erst in die Pipeline. Und die vollständig selbst gehostete Variante von Mistral ist ein Enterprise-Angebot mit individuellem Vertrag, keine Option für den Wohnzimmerschrank.
Also braucht er für die gelben Dokumente lokale Werkzeuge, und davon gibt es 2026 erfreulich gute. Sein Arbeitspferd wird Docling, ein Open-Source-Projekt von IBM Research unter der freien MIT-Lizenz. Docling ist weniger ein reiner Text-Erkenner als ein Dokument-Versteher: Es übernimmt Dokumentstruktur und Lesereihenfolge auch bei mehrspaltigen Seiten, bewahrt Tabellen und liefert am Ende ordentliches Markdown. Für gescannte Seiten nutzt es je nach Konfiguration direkt eine lokale Zeichenerkennung wie Tesseract oder RapidOCR, beide seit Jahren erprobt und mit brauchbarer Deutsch-Erkennung. Digital erzeugte PDFs, bei denen der Text ohnehin schon drinsteckt, gehen den schnellen Weg über ein schlankes Extraktionswerkzeug ganz ohne OCR.
Ein Detail, das Felix erst später zu schätzen lernt: Er lässt seine Pipeline zu jedem Textschnipsel gleich mitnotieren, aus welcher Datei und von welcher Seite er stammt. Ohne diese Fußnoten könnte sein System später zwar Antworten geben, aber nicht sagen, woher sie kommen, und eine Antwort ohne Quelle ist bei Verträgen ungefähr so wertvoll wie ein Gerücht.
Zum Ausprobieren jagt Felix zwei alte gescannte Rechnungen durch Docling. Die erste kommt sauber heraus. Bei der zweiten stutzt er: Eine Tabelle mit Positionspreisen ist um eine Spalte verrutscht, Einzelpreis und Gesamtpreis stehen vertauscht im Markdown. Genau solche Fehler sind der Grund, warum die Bestandsaufnahme und ein Prüfschritt kein bürokratischer Luxus sind. Ein falsch erkannter Wert wird später mit derselben Selbstsicherheit zitiert wie ein richtiger.
Eine ehrliche Einschränkung an dieser Stelle: Handschrift. Für Felix‘ abfotografierte Whiteboard-Notizen mit seiner eigenen Klaue liefern die lokal praktikablen Werkzeuge noch keine Qualität, auf die er sich ungeprüft verlassen möchte. Manche Dinge muss man von Hand nacharbeiten oder eben weglassen. Das ist kein Versagen der Technik, das ist ihr aktueller Rand.
Station 2: Chunking, die Kunst, im richtigen Moment zu schneiden
Nun liegt jedes Dokument als sauberes Markdown vor. Aber man legt ein 40-seitiges Handbuch nicht als einen Brocken in den Index, nicht, weil ein Modell so viel Text nicht verarbeiten könnte (das kann es problemlos, dazu später mehr), sondern weil ein einzelner Riesen-Chunk für die Suche unbrauchbar ist: Er verwässert jede Bedeutung zu Brei. Man muss ihn zerschneiden, und dieses Zerschneiden heißt Chunking (das Aufteilen eines Textes in kleinere, in sich sinnvolle Häppchen, die „Chunks“).
Das klingt trivial, ist aber die Stelle, an der viele Selbstbau-Systeme heimlich scheitern. Schneidet man zu grob, landen in einem Häppchen drei Themen gleichzeitig, und die Bedeutung verwischt. Schneidet man zu fein, verliert ein Satz den Zusammenhang, der ihn erst verständlich macht. Die Definition eines Vertragsbegriffs steht auf Seite 5, verwendet wird er auf Seite 47. Zerschneidet man ungeschickt, findet das System nie beide Stellen zusammen.
In vielen Anleitungen kursiert eine Faustregel: tausend Zeichen pro Häppchen, hundert Zeichen Überlappung zum nächsten. Als Startpunkt ist das brauchbar, aber es lohnt sich, die Zahl zu misstrauen. Tausend Zeichen sind auf Deutsch, je nach Text, nur etwa 200 bis 300 Token (die kleinen Wort- und Silbenbausteine, in denen ein Sprachmodell rechnet). Es gibt keinen universellen Idealwert. Wer schnelle Faktenfragen beantworten will, fährt oft mit kleineren Häppchen besser, wer analytische Zusammenhänge sucht, mit größeren. Wichtiger als die exakte Zeichenzahl ist, an sinnvollen Grenzen zu schneiden: an Absätzen, an Überschriften, nicht mitten im Wort.
Es gibt eine elegante Verfeinerung, die Felix im Hinterkopf behält, auch wenn er sie nicht sofort einbaut. Das Forschungsteam von Anthropic hat 2024 gezeigt, dass man die Trefferquote deutlich verbessert, wenn man jedem Häppchen vor dem Speichern ein, zwei Sätze Kontext voranstellt, eine Art Mini-Zusammenfassung, die verrät, worum es im Gesamtdokument geht. In ihrem eigenen Testkorpus sank die Zahl der fehlgeschlagenen Suchvorgänge dadurch in Kombination mit der lexikalischen Suche um 49 Prozent, mit anschließendem Reranking sogar um 67 Prozent. Man sollte diese Zahlen richtig lesen: Es ist die relative Verringerung von Fehlgriffen auf bestimmten Datensätzen, keine Garantie für Felix‘ Archiv. Und billig ist es nicht umsonst: Der Zusatzkontext muss zunächst für jeden einzelnen Chunk erzeugt werden, ein cleveres Zwischenspeichern der Prompts senkt die Kosten, beseitigt sie aber nicht, und bei einer halben Million Häppchen ist das ein spürbarer Posten der Erstindexierung.
Station 3: Embeddings, wie eine Maschine Bedeutung in Zahlen gießt
Jetzt kommt der Teil, der sich am meisten nach Magie anfühlt und doch reine Mathematik ist. Jedes Text-Häppchen muss in eine Form gebracht werden, mit der eine Maschine Ähnlichkeit berechnen kann. Diese Form ist ein Embedding, eine lange Liste von Zahlen (ein „Vektor“), die die Bedeutung eines Textes in einem mathematischen Raum verortet.
Der Trick dahinter: Texte mit ähnlicher Bedeutung erhalten ähnliche Zahlenlisten und liegen in diesem Raum nah beieinander; Texte mit völlig anderem Inhalt liegen weit auseinander. „Hund“ und „Katze“ sind Nachbarn, „Hund“ und „Steuererklärung“ nicht. Fragt Felix später etwas, wird seine Frage in dieselbe Zahlensprache übersetzt, und das System sucht schlicht die nächstgelegenen Nachbarn.
Die Übersetzung erledigt ein spezialisiertes Embedding-Modell, und hier gibt es Auswahl. Wer maximale Qualität aus der Cloud will, greift zu Modellen von OpenAI, Google oder Voyage. Wer, wie Felix, möglichst viel lokal halten möchte, hat 2026 gute Kandidaten: EmbeddingGemma, ein sehr kleines Modell von Google, das selbst auf schwacher Hardware läuft (kostenlos unter Googles Gemma-Nutzungsbedingungen, was nicht ganz dasselbe ist wie eine klassische Open-Source-Lizenz), oder Qwen3-Embedding in seiner kleinsten Variante unter Apache-2.0-Lizenz. Beide beherrschen Deutsch ordentlich; ob sie flüssig auf der NAS oder besser auf dem separaten Mac mini laufen, hängt stark von CPU, Arbeitsspeicher und Architektur ab. Belastbare Durchsatzzahlen für Heimhardware gibt es kaum, und ich erfinde hier keine.
Ein Wort zur Vorsicht bei Ranglisten: Es gibt eine öffentliche Bestenliste für Embedding-Modelle namens MTEB, und sie ist nützlich, aber sie ändert sich ständig, die Werte melden die Hersteller teils selbst, und einen stabilen „Deutschland-Sieger für Juli 2026″ gibt es schlicht nicht. Felix macht deshalb, was ich jedem empfehlen würde: Er baut sich ein kleines Prüfset aus zwanzig echten Fragen an sein eigenes Archiv und schaut, welches Modell seine Fragen am besten beantwortet. Der eigene Test schlägt jede fremde Rangliste.
Zwei technische Stellschrauben soll man kennen. Erstens die Dimensionen, die Länge der Zahlenliste. Mehr Dimensionen bedeuten feinere Bedeutungsunterschiede, aber auch mehr Speicher und langsamere Suche. Felix rechnet kurz nach: 500.000 Häppchen mit je 768 Dimensionen ergeben rund anderthalb Gigabyte reine Vektoren, für seine NAS problemlos. Mit 3.072 Dimensionen wären es das Vierfache. Er wählt die kleinere Zahl, die EmbeddingGemma ohnehin liefert. Praktischerweise unterstützen moderne Modelle eine Technik namens Matryoshka (benannt nach den russischen Schachtelpuppen): Man kann die Zahlenliste nachträglich auf weniger Dimensionen kürzen, ohne ein anderes Modell trainieren zu müssen. Ob die bestehende Datenbank das direkt mitmacht, hängt allerdings vom Vektorindex ab. Oft muss zumindest der Index neu aufgebaut werden. Zweitens die eiserne Regel, an der schon viele gescheitert sind: Man muss zum Suchen exakt dasselbe Modell verwenden wie zum Einspeichern. Wechselt man das Embedding-Modell, muss das komplette Archiv neu verarbeitet werden. Das ist, nebenbei, der eigentliche Grund, warum man vorsichtig sein sollte, sich an einen Cloud-Anbieter zu ketten, dazu gleich mehr.
Station 4: Die Vektordatenbank, und die Falle, in die man nicht tappen sollte
Die ganzen Zahlenlisten müssen irgendwo hin, und zwar so, dass man blitzschnell die nächsten Nachbarn zu einem Suchvektor findet. Eine normale Datenbank, die exakte Werte vergleicht, scheitert hier, bei tausenddimensionalen Zahlenlisten gibt es nie eine exakte Übereinstimmung, nur mehr oder weniger nahe. Dafür gibt es die Vektordatenbank, spezialisiert genau auf diese geometrische Nachbarschaftssuche.
Felix‘ Wahl fällt auf pgvector. Das ist keine eigene, exotische Software, sondern eine Erweiterung für PostgreSQL, eine der ältesten, langweiligsten und zuverlässigsten Datenbanken der Welt. Genau das ist der Reiz: eine Datenbank, ein Backup, ein System, das er schon kennt. Für seine halbe Million Häppchen ist das mehr als ausreichend; pgvector wird produktiv mit weit größeren Mengen betrieben. Wer lieber ein spezialisiertes Werkzeug möchte, nimmt Qdrant, das ebenfalls frei und schnell ist. Beide sind als Container (Docker, eine Technik, die eine Software samt allem, was sie zum Laufen braucht, in ein abgeschottetes, transportables Paket verpackt) verfügbar und können auf geeigneten Synology-Modellen laufen; ob das sinnvoll ist, hängt von Prozessorarchitektur und Arbeitsspeicher ab.
Und jetzt die Falle. Es gibt bequeme Rundum-sorglos-Angebote von den großen Cloud-Anbietern, Amazon, Microsoft, Google, spezialisierte Dienste wie Pinecone, die einem die ganze Arbeit dieser Pipeline abnehmen. Verlockend. Aber man sollte genau verstehen, was man da eingeht. Man hört oft die Warnung, man bekomme seine Vektoren „nie wieder heraus“. Das ist, ehrlich gesagt, überzeichnet, die meisten Dienste bieten durchaus einen Export der Daten. Der wahre Haken liegt anderswo: Nicht portabel sind der fertige Suchindex, die Ranglogik, die ganze Betriebsmechanik, und vor allem hängt alles am gewählten Embedding-Modell. Wechselt man den Anbieter, muss man ohnehin alles neu berechnen.
Der eigentliche Schatz, den Felix hütet, sind deshalb nicht die Vektoren. Es sind seine Originaldokumente, das saubere Markdown, die Häppchen mit ihren Kennungen und das „Rezept“, nach dem er sie erzeugt hat. Solange er das bei sich behält und versioniert, kann ihn kein Anbieter der Welt einsperren, und weil seine Datenbank ohnehin auf der eigenen NAS läuft, zieht sie im Zweifel mit einem simplen Datenbank-Abzug auf andere Hardware um. Das ist digitale Selbstbestimmung im praktischen Sinn: nicht Ideologie, sondern Versicherung.
Station 5: Hybrid Search, wenn Bedeutung und Buchstaben zusammenarbeiten
Jetzt kommt der Moment, in dem sich zeigt, warum die reine Bedeutungssuche allein nicht reicht. Sie ist brillant darin, sinnverwandte Dinge zu finden. Aber sie ist erstaunlich schlecht darin, exakte Zeichenketten zu treffen. Und Felix‘ Archiv ist voll davon: Projektnummern, Artikelcodes, Eigennamen. Fragt er nach FB-2019-047, hilft ihm keine Bedeutungsnähe. Er will genau diese Zeichenfolge.
Dafür gibt es die alte, ehrwürdige Stichwortsuche, deren bekanntester moderner Vertreter ein Algorithmus namens BM25 ist. Das „25″ ist übrigens eine Versionsnummer aus den Forschungslabors der 1980er und 90er, nicht das Jahr 2025, ein hübsches Missverständnis, das sich hartnäckig hält. Solche Verfahren bewerten einen Treffer nach drei Dingen: wie oft der Suchbegriff im Häppchen vorkommt, wie selten er im gesamten Archiv ist (ein seltenes „FB-2019-047″ zählt mehr als ein häufiges „Projekt“), und wie lang das Häppchen ist. Felix wird gleich nicht das lehrbuchreine BM25 installieren, sondern die eingebaute Volltextsuche seiner Datenbank. Sie verfolgt dasselbe Ziel, relevante Stichworttreffer nach vorn zu bringen, verwendet dafür aber eine eigene Ranglogik. Für sein Archiv reicht sie zunächst völlig.
Die eigentliche Kunst ist, beide Welten zu verbinden, das nennt sich Hybrid Search. Man lässt die Bedeutungssuche und die Stichwortsuche parallel laufen, jede produziert ihre eigene Rangliste, und dann verschmilzt man die beiden mit einem verblüffend simplen Verfahren namens Reciprocal Rank Fusion. Man muss dafür nicht einmal die unterschiedlichen Punktzahlen der beiden Systeme vergleichbar machen; man addiert nur die Kehrwerte der Ränge. Ein Häppchen, das in beiden Listen weit oben steht, gewinnt fast immer gegen eines, das nur in einer Liste punktet.
Ein konkretes Beispiel aus Felix‘ Archiv macht es greifbar. Sucht er nach einem Angebot mit der Nummer FB-2019-047, landet das richtige Dokument bei der Stichwortsuche auf Platz 1 und bei der Bedeutungssuche nur auf Platz 8. Ein thematisch ähnliches, aber falsches Angebot schafft es bei der Bedeutungssuche auf Platz 1, taucht aber bei der Stichwortsuche kaum auf. Die Fusion rechnet beide zusammen, und das exakte Dokument mit der richtigen Nummer setzt sich durch. Genau die Art von Suche, an der Felix früher regelmäßig scheiterte, ist damit in Millisekunden gelöst.
Technisch ist das in PostgreSQL kein Hexenwerk: Man legt neben den Vektoren eine zweite, textbasierte Suchspalte an, mit der deutschen Sprachkonfiguration, damit „läuft“ und „laufen“ als dasselbe erkannt werden. Wer später echtes BM25 will, kann PostgreSQL um eine Erweiterung wie pg_search ergänzen. Eine Eigenheit bleibt so oder so: Der deutsche Stemmer zerlegt zusammengesetzte Wörter nicht. „Schneckenradsatz“ findet nicht automatisch „Schneckenrad“. Wer viele solche Komposita hat, baut sich ein kleines eigenes Synonym-Wörterbuch aus dem eigenen Bestand, das wirkt oft besser als ein weiteres großes Suchsystem danebenzustellen.
Station 6: Reranking, der strenge Prüfer am Ende
Die Hybrid Search liefert eine solide Vorauswahl, sagen wir zwanzig Kandidaten. Aber die Reihenfolge ist noch nicht perfekt. Bei anspruchsvolleren Archiven ist die letzte Qualitätsstufe deshalb das Reranking, ein spezialisiertes Modell, das Frage und Kandidat noch einmal gemeinsam liest und sehr genau bewertet, wie gut dieser eine Textabschnitt diese eine Frage wirklich beantwortet. Nicht jede kleine RAG-Anwendung braucht diesen Schritt; für ein Archiv von Felix‘ Größe lohnt er sich.
Der Unterschied zur bisherigen Suche ist fein, aber wichtig. Beim Einspeichern wurden Frage und Text getrennt in Zahlen übersetzt, schnell, aber grob. Der Reranker liest beide zusammen an einem Tisch und erkennt Nuancen, Verneinungen, Details, die der grobe Vektorvergleich übersieht. Das kostet mehr Rechenzeit, weshalb man es nur auf die letzten zwanzig Kandidaten anwendet, nicht auf alle halbe Million. Erst grob filtern, dann fein prüfen.
Auch hier hat Felix die Wahl zwischen Cloud und lokal. Der Marktführer ist Coheres Reranker, gut und mehrsprachig, aber die Daten verlassen wieder das Haus. Lokal laufen Modelle wie bge-reranker oder ein kleiner Qwen-Reranker, die für Felix‘ gelbe Dokumente die passendere Wahl sind. Er entscheidet sich für bge-reranker-v2-m3. Wie schnell das auf seiner konkreten Hardware ist, lässt sich pauschal nicht sagen. Belastbare Messwerte für Heimhardware existieren schlicht nicht, und ich erfinde hier keine. Realistisch reicht es, nur die zwanzig Kandidaten bewerten zu lassen, und das erledigt bei Felix der Mac mini, nicht die NAS.
Der Zusammenbau: So fügt sich der Plan zusammen
Jetzt fügt sich alles zu einem Bild. Auf der Indexierungsseite läuft die Kette einmal durch: Ein nächtlicher Lauf sammelt die neuen und geänderten Dateien in Felix‘ Ordnern ein, schickt sie durch OCR, schneidet sie in Häppchen, übersetzt diese in Vektoren und schreibt sie in die Datenbank. Auf der Abfrageseite läuft bei jeder Frage der umgekehrte Weg: Frage übersetzen, Hybrid Search, Reranking, und die drei besten Häppchen wandern zusammen mit der Frage in ein Sprachmodell, das daraus eine Antwort formuliert, mit Dateiname und Seitenzahl als Beleg.
Und hier trennt sich der ehrliche vom marktschreierischen Rat. Man kann das alles selbst zusammenprogrammieren, und wer den Weg über Werkzeuge wie n8n (eine Software zum visuellen Zusammenklicken von Automatisierungs-Abläufen) und einen KI-Programmierassistenten geht, versteht am Ende jedes Zahnrad. Für Felix ist das der richtige Weg, denn nur so behält er die Kontrolle über die zwei Dinge, die gleich noch wichtig werden: den Berechtigungsfilter und die Löschlogik. Seine eigene kleine Pipeline, Docling, EmbeddingGemma, PostgreSQL, die Fusion aus Volltext- und Vektorsuche, der Reranker, ist das eigentliche System.
Es gibt zwar fertige, quelloffene Baukästen, die eine komplette RAG-Pipeline mitbringen, etwa AnythingLLM oder Open WebUI. Aber Felix nutzt einen davon bewusst nicht als zweite, parallele Pipeline, sondern nur als Bedienoberfläche. Open WebUI nimmt seine Frage entgegen und reicht sie an Felix‘ eigene Schnittstelle weiter; dort passiert die ganze Arbeit, Rechteprüfung, Suche, Reranking, und Open WebUI zeigt am Ende nur das Ergebnis samt Quellen an. Die eingebaute Dokumentenindexierung des Baukastens bleibt ungenutzt. Das ist die entscheidende Architekturfrage, und Felix beantwortet sie klar: eine eigene Pipeline, eine Oberfläche obendrauf, kein Vermischen.
Diese Reihenfolge, erst selbst verstehen, dann eine fertige Oberfläche vorsetzen, ist meine Empfehlung an jeden, der diesen Entwurf umsetzt. Verstehen und bequem Bedienen sind zwei verschiedene Dinge, und die Oberfläche darf das eine nie unter dem anderen begraben.
Am Ende des Plans steht ein Anschlusspunkt, der den Bogen zurück zu Mark aus der zweiten Folge schlägt. Vor die fertige Pipeline gehört später eine kleine Schnittstelle, eine API (eine definierte Anfrage-Adresse, über die ein Programm ein anderes ansprechen kann), über die sich das Archiv als Fähigkeit an Marks Bot im Heizungskeller anbinden ließe. Dann könnte Felix sein Archiv eines Tages per Telegram vom Sofa aus befragen. Aus dem Datengrab würde ein Gesprächspartner. Aber genau dieser Übergang ist die heikelste Stelle des ganzen Plans. Und noch etwas gehört hierher, weil es im Datenschutz-Kapitel versprochen wurde: der Berechtigungsfilter. Die Abfragekette ist nämlich nicht einfach „Frage → Suche → Antwort“, sondern „angemeldeter Nutzer → Rechteprüfung → Suche nur in den erlaubten Häppchen“, sonst entsteht genau der gemeinsame Suchindex, vor dem die Datenschutzbehörden warnen, bei dem die Buchhaltungsunterlage plötzlich in der Antwort für den Praktikanten auftaucht. Vier Regeln fasst Felix sich dafür zusammen:
Vier Regeln, bevor Felix sein Archiv ins Netz hängt
- Keine direkte Portfreigabe der NAS ins Internet, der Zugang läuft nur über einen abgesicherten, verschlüsselten Kanal.
- Authentifizierung vor jeder Anfrage. Niemand fragt das Archiv anonym.
- Rechtefilter vor dem Retrieval, jedes Häppchen trägt Dokument-ID, Pfad, Eigentümer und Zugriffsrechte als Metadaten; gesucht wird nur in dem, was der Fragende sehen darf.
- Löschungen über stabile Dokument-IDs nachführen, aktive Daten und Index sofort, Sicherungskopien über ihren Aufbewahrungszyklus; bei einer Wiederherstellung werden die Löschmarkierungen erneut angewendet.
Wer diese vier Regeln lax nimmt, macht sein privates Gedächtnis versehentlich öffentlich. Der Unterschied zwischen einem Werkzeug und einem Datenleck.
Bleibt eine Frage, die man sich ehrlich stellen muss: Woher wüsste Felix, dass ein solches System funktioniert und nicht nur beeindruckend aussieht? Antwort: durch ein kleines Ritual, das in jeden solchen Entwurf gehört. Er schreibt sich zwanzig echte Fragen auf, zu denen er die richtige Antwort und die richtige Quelldatei kennt, exakte Nummern, Datumsfragen, Fragen über mehrere Dokumente hinweg, und bewusst auch ein paar Fragen, deren Antwort nicht im Archiv steht. Nach jeder Änderung lässt er dieses Set einmal durchlaufen. Findet das System die richtige Seite? Und, fast noch wichtiger: Sagt es ehrlich „nicht gefunden“, wenn es nichts weiß, statt etwas zu erfinden? Diese zwanzig Fragen sind Felix‘ Sonntags-TÜV.
Felix‘ Referenz-Stack auf einen Blick
Damit der Entwurf nicht in lauter „entweder … oder“ zerfasert, hier die Konfiguration, für die Felix sich am Ende des Nachmittags entscheidet, eine von vielen möglichen, aber eine konkrete:
- NAS (Synology): lagert die Originaldokumente und betreibt PostgreSQL mit der pgvector-Erweiterung als Datenbank.
- Separater Mac mini (Apple Silicon): übernimmt die rechenintensiven Schritte, OCR, das Erzeugen der Embeddings und das Reranking. Er läuft nicht durchgehend, sondern wird für den nächtlichen Indexierungslauf geweckt, sofern Modell und Netzwerkkonfiguration Wake-on-LAN unterstützen, sonst per Zeitplan oder manuellem Start, und danach wieder schlafen gelegt.
- OCR: Docling für Struktur und Lesereihenfolge, mit Tesseract als lokaler Zeichenerkennung für deutsche Scans.
- Embedding-Modell: EmbeddingGemma mit 768 Dimensionen, lokal ausführbar und kostenlos unter Googles Gemma-Nutzungsbedingungen.
- Suche: PostgreSQLs eingebaute Volltextsuche für exakte Begriffe plus Vektorsuche für Bedeutung, zusammengeführt per Reciprocal Rank Fusion.
- Reranking: bge-reranker-v2-m3, nur auf die letzten zwanzig Kandidaten, auf dem Mac mini.
- Oberfläche: Open WebUI im Container, ausschließlich als Anzeige für Felix‘ eigene RAG-Schnittstelle, nicht als eigene Pipeline.
- Aktualisierung: kein ständiger Datei-Wächter, sondern ein nächtlicher Aufgabenplan der NAS, der geänderte Dateien einsammelt und den Mac mini dafür weckt.
Bis auf den ersten OCR-Test ist an diesem Sonntag noch nichts produktiv umgesetzt, aber jeder Baustein ist entschieden, und das ist der eigentliche Zweck eines Entwurfs.
Wann du das alles gar nicht brauchst
An dieser Stelle die vielleicht wichtigste Einsicht des ganzen Artikels, und sie widerspricht dem eigenen Bauwerk: RAG ist kein Allheilmittel, und oft ist es schlicht überflüssig.
Die Sprachmodelle von heute haben riesige Kontextfenster (die Menge an Text, die ein Modell auf einmal verarbeiten kann), bis zu einer Million Token, grob eine Dreiviertelmillion Wörter. Anthropic, die Firma hinter dem Modell Claude, hat dazu 2024 eine schöne Faustregel veröffentlicht: Ist die gesamte Wissensbasis kleiner als ungefähr 200.000 Token, grob 500 Textseiten, kippt man sie einfach komplett ins Modell und spart sich die ganze Pipeline. Ein einzelner zwanzigseitiger Vertrag, zu dem man eine Frage hat, gehört direkt ins Modell, nicht in eine Datenbank. In den Projekt-Funktionen von Claude gibt es allerdings keine veröffentlichte feste Seitenzahl: Dort schaltet sich RAG automatisch dazu, sobald sich das Projektwissen dem jeweiligen Kontextlimit nähert, das hängt also vom Modell und vom Inhalt ab.
Der Grund, warum RAG trotzdem nicht ausstirbt, ist teils schlicht ökonomisch: Bei demselben Modell und linearer Tokenabrechnung verursacht ein Trefferkontext von zehntausend Token ungefähr ein Prozent der Eingabekosten eines Kontexts mit einer Million Token. Wer denselben großen Bestand hundertmal am Tag befragt, für den summiert sich das gewaltig. Und teils ist es eine Frage der Aufmerksamkeit. Es gibt ein gut belegtes Phänomen namens Lost in the Middle: Modelle finden Informationen am Anfang und Ende eines langen Textes zuverlässiger als in der Mitte. Ein großes Kontextfenster ist eben nicht dasselbe wie nutzbare Aufmerksamkeit über die ganze Länge. Man sollte deshalb weder „großes Kontextfenster löst alles“ noch „Modelle finden in der Mitte nichts“ glauben, die Wahrheit liegt dazwischen und hängt vom Fall ab.
Die Entscheidungsregel für Felix ist damit einfach: Ein Dokument, eine einmalige Frage? Direkt ins Modell. Hunderte Dokumente, wiederkehrende Fragen, ständig neues Material, und man weiß nicht mal, in welcher Datei die Antwort steckt? Dann, und erst dann, lohnt die ganze Pipeline.
Noch eine Warnung, die in jeden solchen Plan gehört, weil sie so oft ignoriert wird. Bequeme Werkzeuge wie Googles NotebookLM verführen dazu, Firmenwissen einfach hochzuladen. Bei den kostenlosen, privaten Konten gilt aber: Gibt man Feedback zu einer Antwort, können damit verbundene Inhalte von Menschen geprüft werden. Ein solches Privatkonto ist für vertrauliche Kundendaten keine vernünftige Wahl. Bei den Unternehmensangeboten müsste man Auftragsverarbeitung, Datenstandort, Administrationskontrollen und die konkreten Vertragsbedingungen gesondert prüfen, pauschal verbieten kann man es nicht. Für Felix bleibt die lokale Lösung schlicht der klarste Weg zur Datensouveränität. Das ist kein Grund zur Panik, aber ein Grund zur Sorgfalt.
Der Blick über den Zaun: warum Konzerne dasselbe Problem haben, nur größer
Man könnte meinen, das sei alles eine Spielerei für Technik-Enthusiasten mit zu viel Sonntagszeit. Ist es nicht. Was Felix im Kleinen löst, ist im Großen eine der drängendsten Fragen der deutschen Wirtschaft.
Das Statistische Bundesamt hat vorgerechnet, dass in den kommenden fünfzehn Jahren rund 13,3 Millionen Erwerbspersonen das Rentenalter erreichen, knapp ein Drittel aller heute Arbeitenden. Die geburtenschwachen Jahrgänge können sie zahlenmäßig nicht ersetzen; die Geburtenziffer sank 2025 auf 1,32 Kinder je Frau, den niedrigsten Stand seit 1997, während die absolute Zahl der Geburten mit rund 654.000 den niedrigsten Wert der Nachkriegszeit erreichte. Parallel meldet die KfW, dass 57 Prozent der Mittelstands-Inhaber 55 Jahre oder älter sind und bis 2029 mehr Unternehmen eine Schließung als eine Nachfolge planen. Jeden Werktag verlassen erfahrene Köpfe den Arbeitsmarkt, und nehmen ihr Wissen mit, wenn es niemand vorher auffindbar gemacht hat.
Wie viel auf diesem Spezialwissen lastet, zeigt eine Firma wie die Vacuumschmelze aus Hanau, seit über hundert Jahren Weltspitze bei magnetischen Werkstoffen. Im Juni 2026 vereinbarte der US-Konzern Energy Fuels die Übernahme des Unternehmens für einen rechnerischen Eigenkapitalwert von rund 1,9 Milliarden Dollar; vollzogen ist die Transaktion noch nicht, der Abschluss wird nach regulatorischen Genehmigungen für Anfang 2027 erwartet. Natürlich werden dabei auch Anlagen, Patente und Kundenbeziehungen gekauft, aber der eigentliche Wert liegt in einem über Generationen gewachsenen Können, das sich nicht in vertretbarer Zeit nachbauen lässt. Genau dieses Können droht im deutschen Mittelstand gerade lautlos in den Ruhestand abzuwandern.
Vor diesem Hintergrund ist Felix‘ Vorhaben kein Hobby, sondern ein Muster. Die Fähigkeit, Wissen so zu speichern, dass eine Maschine es im richtigen Moment findet, ist eine zunehmend relevante technische Kompetenz. Die logischen Bausteine sind dabei dieselben wie bei Felix: die Kette aus OCR, Chunking, Embedding, Hybrid Search und Reranking bleibt im Kern gleich, ob im Wohnzimmerschrank oder im Rechenzentrum. Was die Konzern-Version schwerer macht, ist nicht die Größe allein, sondern das Drumherum, Identitätsverwaltung, Mandantentrennung, Nachvollziehbarkeit, Ausfallsicherheit, Governance. Aber der Kern ist erlernbar, und das ist der Punkt.
Fazit, und eine offene Frage
Am Ende dieses Sonntags summt der graue Kasten im Wohnzimmerschrank immer noch leise vor sich hin, und bis auf einen ersten OCR-Test an zwei Rechnungen ist er noch genau das Datengrab, das er am Morgen war. Aber auf Felix‘ Notizblock liegt jetzt etwas, das vorher nicht da war: ein vollständiger Bauplan. Jede Station ist eingezeichnet, jede Weggabelung entschieden, jede Falle markiert. Aus drei Terabyte, in denen nichts zu finden war, wird kein fertiges Gedächtnis an einem Nachmittag, aber der Weg dorthin ist keine Nebelwand mehr. Felix hat dafür keine Zaubertechnik gebraucht, sondern das Verständnis für ein paar freie Werkzeuge, ein wenig Sorgfalt bei der Vertraulichkeit und die Disziplin, an den richtigen Stellen die einfache Lösung zu wählen. Der Bauplan für den Bibliothekar liegt bereit; das Einziehen ist die Arbeit der nächsten Abende.
Denn ehrlich bleibt auch das: Ein Sonntagnachmittag reicht für den Plan und vielleicht für einen ersten Prototyp über einen einzelnen Ordner. Die vollständige Erstindexierung von drei Terabyte mit Scans, Tabellen, einer halben Million Häppchen, Berechtigungen und Dublettenprüfung läuft danach noch über Nächte, und das Aufräumen dauert vermutlich länger. Das ist keine Schwäche des Plans, sondern seine Ehrlichkeit.
Das eigentlich Bemerkenswerte ist nicht die Technik. Es ist, dass all das, Dinge, für die Konzerne sechsstellige Beratungsprojekte beauftragen, im Prinzip auf zwei kleinen Geräten im eigenen Heimnetz Platz findet, unter der Kontrolle eines einzelnen Menschen, mit Daten, die das Haus nicht verlassen müssen. Das ist Demokratisierung im wörtlichen Sinn: Ein Wissen, das gestern noch großen Organisationen vorbehalten war, liegt heute in Reichweite jedes neugierigen Menschen mit einer NAS und ein paar freien Abenden.
Im nächsten Teil verlässt Felix den Zeichentisch: Dann setzen wir genau diesen Referenzaufbau tatsächlich auf, beginnend mit einem einzigen Projektordner und den zwanzig Fragen aus Felix‘ Testset, damit sich zeigt, wo der Plan trägt und wo die Realität ihn korrigiert.
Bleibt eine Frage, die mich nicht loslässt, seit ich diesen Entwurf durchgegangen bin. Wenn das Suchen aufhört, Arbeit zu sein, wenn jede Information sofort und mühelos abrufbar wird, verlernen wir dann etwas? Das mühsame Wiederfinden hatte ja auch eine Nebenwirkung: Beim Suchen stolpert man über Dinge, die man nicht gesucht hat, man erinnert sich neu, man ordnet im Kopf. Ein perfekt auffindbares Gedächtnis nimmt uns diese Reibung ab. Vielleicht ist das reiner Gewinn. Vielleicht war das Vergessen und das Wiedersuchen aber auch eine leise Form des Denkens, die wir gerade wegautomatisieren. Felix weiß es noch nicht. Und ich, ehrlich gesagt, auch nicht.