Wissensbasis als Dienst, nicht als App — die Architektur hinter dem lokalen RAG

Das Problem: Wissen hängt an einer laufenden App

Im Schwester-Artikel habe ich beschrieben, wie aus 1.532 Markdown-Notizen eine semantische Suche wurde. Funktioniert — aber im ersten Wurf hing der Zugriff an einer geöffneten Editor-App auf genau einem Rechner. Ist die App zu, ist die Wissensbasis stumm. Sitze ich am anderen Gerät, komme ich nicht heran.

Das ist kein technisches Detail, sondern eine Architektur-Entscheidung mit Folgen. Eine Wissensbasis, die nur antwortet, solange ein bestimmtes Programm im Vordergrund läuft, ist keine Infrastruktur — sie ist ein Feature. Ich wollte das Umgekehrte: einen Dienst, der immer da ist, egal welche App gerade offen ist.

Die zentrale Unterscheidung: App, Dateien, Index

Der ganze Architektur-Knoten löst sich, sobald man drei Dinge sauber auseinanderhält, die im Alltag gern verschwimmen. Sie haben völlig unterschiedliche Lebensdauern und Wertigkeiten:

Der oft gehörte Satz „wir brauchen die App nicht mehr“ stimmt — aber nur fürs Abfragen. Die Dateien bleiben die Quelle, an der weiter geschrieben wird; ändert sich eine, wird sie neu indexiert. Der Index ist reine Ableitung: Geht er kaputt, lösche ich ihn und baue ihn aus den Dateien neu. Die Dateien dagegen sind unersetzlich — sie wegzuwerfen wäre Datenverlust, den kein Cache wiederherstellt.

Diese Hierarchie ist der ganze Trick. Sie sagt mir, was geschützt gehört (die Dateien), was beliebig ersetzbar ist (App und Index) und an welcher Stelle ich entkoppeln darf, ohne etwas zu riskieren.

Headless: der Dienst antwortet ohne App

„Headless“ heißt: kein Kopf, keine Oberfläche. Der Dienst läuft als Hintergrundprozess auf dem ohnehin durchlaufenden Mac mini und beantwortet Anfragen — unabhängig davon, ob irgendwo eine App offen ist. Rund um die Uhr, von jedem Gerät im eigenen Netz.

Praktisch wandert die Suchlogik aus der App heraus in einen kleinen, eigenständigen Prozess. Wer fragen will, schickt eine Anfrage; wer eine Notiz ändert, stößt eine Neu-Indizierung an. Die App wird dadurch zu einem von vielen möglichen Frontends — nicht mehr zur Voraussetzung.

# headless: der Dienst lauscht, niemand muss eine App offen haben
def handle_query(question):
    hits = search(question, k=4)          # Vektorsuche auf dem Mac mini
    return synthesize(question, hits)     # Antwort nur bei Bedarf

# erreichbar im eigenen Netz ueber Tailscale, von jedem Geraet

Im eigenen Netz hält Tailscale die Geräte verbunden, sodass das Handy unterwegs dieselbe Wissensbasis erreicht wie der Laptop am Schreibtisch — ohne dass die Dateien je die eigene Hardware verlassen.

MCP: ein Standard, viele Frontends

Damit ist die nächste Frage: Wie spricht eine KI mit diesem Dienst? Die Antwort heißt MCP — das Model Context Protocol. Es ist ein offener Standard, über den ein Sprachmodell externe Werkzeuge einbindet. Ich melde mein RAG als ein solches Werkzeug an, und ab dann kann jede MCP-fähige KI es benutzen — als wäre es eine eingebaute Fähigkeit.

Das ist die eigentliche Pointe der Architektur: ein Backend, beliebig viele Frontends. Derselbe Dienst beantwortet Fragen aus dem Terminal, aus einem Editor-Plugin und vom Handy — ohne dass ich die Logik dreimal baue.

Verbessere ich die Suche einmal im Dienst, profitieren alle drei sofort. Das ist der Unterschied zwischen einem Werkzeug, das ich pflege, und drei Kopien, die auseinanderdriften.

Ehrliche Klarstellung: ein Plugin spart keine Token

Hier ein verbreitetes Missverständnis, das ich gerade selbst ausräumen musste. Es gibt Editor-Plugins, die eine KI direkt in die Schreiboberfläche einbetten. Das fühlt sich an wie „eine eigene KI im Editor“ — ist es aber nicht. Solche Plugins bringen weder ein eigenes Modell noch ein eigenes RAG mit. Sie sind nur ein weiteres Frontend, das denselben Dienst anspricht wie jeder andere Client.

Daraus folgt etwas, das man oft falsch erwartet: Ein Plugin spart keine Token. Token entstehen nicht durch „Plugin gegen Dienst“, sondern dadurch, dass irgendwann eine Cloud-KI rechnet. Ob der Anstoß aus einem Plugin, dem Terminal oder dem Handy kommt, ist der Cloud egal — die Rechnung ist dieselbe.

Der echte Spar-Hebel liegt woanders, an zwei Stellen:

• Lokale KI statt Cloud. Läuft die Antwort-Synthese auf eigener Hardware — bei mir Qwen3.5-35B auf einem Ugreen AI-NAS, nur on-demand geweckt — kostet sie schlicht 0 Cloud-Token. Eine Antwort dauerte im Testlauf rund 37 Sekunden; kein Token floss zu einem Anbieter.
• RAG statt ganze Dateien. Selbst wenn eine Cloud-KI antwortet: Beim RAG landen nur die Treffer-Schnipsel im Kontext, nicht die kompletten Notizen. Der Dienst sucht erst die relevanten Häppchen und reicht nur diese weiter — das hält den Kontext klein, unabhängig vom Frontend.

Beides sind Eigenschaften des Dienstes, nicht des Plugins. Genau deshalb gehört die Intelligenz in den Dienst — und nicht ins Frontend.

Fazit: entkoppelter Dienst statt eingebautes Feature

Die Stichwortsuche über meine Notizen war ohnehin schnell — rund 0,07 bis 0,17 Sekunden. Der Gewinn des RAG ist also nicht Tempo, sondern zweierlei: Bedeutung (es versteht, was ich meine) und Verfügbarkeit (es ist immer erreichbar, von überall, ohne dass eine App laufen muss).

Diese Verfügbarkeit bekomme ich nur, wenn das RAG ein eigenständiger Dienst ist und nicht im Bauch einer App steckt. Die saubere Trennung von App, Dateien und Index sagt mir, wo ich schneiden darf; headless macht den Dienst dauerhaft erreichbar; MCP macht ihn für jede KI nutzbar. Deshalb baue ich das RAG als entkoppelten Dienst — und nicht ins Plugin.

Transparenzhinweis: Dieses Projekt ist selbst finanziert. Die genannten Werkzeuge (Ollama, bge-m3, Qwen, numpy, MCP, Tailscale) sind quelloffen bzw. offene Standards; die Hardware habe ich selbst angeschafft. Es bestehen keine bezahlten Kooperationen mit den genannten Herstellern. Alle Zahlen stammen aus einem echten Testlauf am 17. Juni 2026.