Lass mich ganz direkt sein: Das hier ist kein Artikel über Technologie-Hype. RAG, also Retrieval-Augmented Generation, wird in den meisten Berichten entweder als Enterprise-Lösung für Konzerne mit IT-Abteilung dargestellt oder als Spielzeug für Entwickler, die gerne mit Python-Notebooks hantieren. Beides stimmt nicht. Und beides hat mich dazu gebracht, das einfach selbst zu bauen.
Seit gestern läuft mein eigenes RAG-System auf meiner Infrastruktur. Mein kompletter Blog mit über 520 Artikeln ist darin indexiert. Neue Artikel kommen täglich automatisch dazu. Ich kann über Claude Desktop per MCP-Verbindung direkt in meiner eigenen Wissensbasis suchen, und die Antworten, die ich bekomme, basieren auf dem, was ich tatsächlich geschrieben habe. Nicht auf dem, was ein Sprachmodell irgendwann mal über mein Thema gelernt hat.
Das ist ein anderes Gespräch. Qualitativ anders. Und ich erkläre dir jetzt, warum.
Was RAG eigentlich ist, ohne Fachchinesisch
Jedes Sprachmodell, das du kennst, hat einen Wissensstand bis zu einem bestimmten Datum. Es weiß viel, aber es weiß nicht, was du letzte Woche geschrieben hast. Es weiß nicht, was in deinem letzten Angebot stand. Es kennt nicht die spezifische Formulierung, mit der du ein Konzept deinen Kunden erklärst.
RAG löst genau dieses Problem. Der Name erklärt das Konzept eigentlich gut, wenn man ihn auseinandernimmt: Retrieval bedeutet, du holst dir zuerst die relevanten Informationen aus einer eigenen Datenbank. Augmented bedeutet, du erweiterst damit den Kontext, den du dem Sprachmodell gibst. Generation ist dann die Antwort, die das Modell auf Basis dieses Kontexts produziert.
Das Resultat: Das KI-System antwortet nicht aus seinem allgemeinen Training, sondern auf Basis deiner eigenen Inhalte. Wenn ich frage „Was habe ich über Memory MCPs geschrieben?“, sucht das System zuerst in meinen indexierten Artikeln, findet die relevantesten Textstellen, und gibt diese als Kontext an Claude weiter. Claude antwortet dann mit meinen eigenen Gedanken, meiner eigenen Sprache, meinen eigenen Beobachtungen.
Was mich beim ersten echten Test überrascht hat: Das Ergebnis klingt wie ich. Weil es von mir ist.
Wie das technisch funktioniert, ohne dass du Entwickler sein musst
Der technische Kern des Systems ist eine sogenannte Vektordatenbank. Das klingt komplizierter, als es ist. Eine normale Datenbank speichert Text und sucht nach exakten Übereinstimmungen. Eine Vektordatenbank speichert die semantische Bedeutung von Texten als mathematische Darstellung, und sucht nach inhaltlicher Ähnlichkeit.
Das bedeutet konkret: Wenn ich nach „KI-Regulierung in Österreich“ suche, findet das System auch Artikel, in denen die Wörter „KI-Regulierung“ und „Österreich“ gar nicht gemeinsam vorkommen, der Inhalt aber genau dieses Thema behandelt. Keyword-Suche kann das nicht. Semantische Vektorsuche schon.
Für mein System habe ich folgende Komponenten zusammengebaut:
Qdrant ist die Vektordatenbank. Open Source, in Rust geschrieben, schnell und zuverlässig. Läuft als Docker-Container auf meinem Hetzner-Server.
Gemini Embeddings von Google wandeln jeden Text in einen Vektor um. Dieser Schritt passiert automatisch, wenn ich einen neuen Artikel indexiere, und genauso automatisch bei jeder Suchanfrage. Die Kosten dafür liegen bei meinem aktuellen Volumen unter einem Euro pro Monat.
FastAPI ist der Python-Service, der alles zusammenhält. Er nimmt Dokumente entgegen, chunked sie in sinnvolle Abschnitte, erstellt Embeddings, speichert sie in Qdrant. Und auf der anderen Seite: nimmt Suchanfragen entgegen, erstellt Embeddings, sucht die ähnlichsten Chunks, gibt sie zurück.
Das ganze System läuft auf meiner Hetzner-Infrastruktur, die ich seit über einem Jahr mit Coolify als Deployment-Plattform betreibe. Coolify ist im Wesentlichen ein selbst gehostetes Heroku: Docker-Container deployen, Domains zuweisen, SSL-Zertifikate verwalten, alles ohne tiefes DevOps-Wissen.
Ich habe dazu eine Web-UI gebaut, über die ich direkt URLs, Dateien, Notizen oder meinen ganzen WordPress-Blog indexieren kann, alles über eine einfache Oberfläche. Keine Kommandozeile, kein Python-Notebook.
Der Datenschutz-Aspekt, den die meisten übersehen
Das ist der Punkt, über den in den meisten Artikeln zu wenig gesprochen wird.
Wenn du ein SaaS-RAG-Tool verwendest, landen deine Dokumente auf fremden Servern. Deine Blogartikel, deine internen Dokumente, deine Kundenpräsentationen, alles wird verarbeitet, indexiert, gespeichert. Von wem? Wo? Unter welchen Bedingungen?
Bei meinem Setup bleibt alles unter meiner Kontrolle. Die Vektordatenbank läuft auf meinem Server. Die Embeddings, also die mathematischen Darstellungen meiner Inhalte, verlassen meine Infrastruktur nicht. Der einzige externe Dienst, den ich für die Vektorisierung nutze, sind die Gemini Embeddings von Google.
Und hier ist ein Detail, das für mich entscheidend war: Ich nutze Google Workspace. Das bedeutet, meine Anfragen an die Gemini API laufen über mein Workspace-Konto. Google verwendet Workspace-Daten nicht für das Training seiner Modelle. Das ist vertraglich geregelt, nicht nur eine Versprechen. Für mich ist das die pragmatische DSGVO-konforme Lösung: selbst gehostete Infrastruktur, Embedding-API über einen Anbieter mit klaren Datenschutzgarantien.
Das Ergebnis: Ich kann auch sensiblere Dokumente indexieren, Kundenmaterialien, interne Konzepte, Angebote, ohne dass ich mir Gedanken machen muss, wo diese Daten landen.
Was in meiner Wissensbasis steckt und wie sie wächst
Aktuell hat mein RAG-System 1.344 Chunks aus meinen indexierten Inhalten. Das klingt nach einer abstrakten Zahl. Was das konkret bedeutet: Ein Blogartikel von 1.500 Wörtern wird in etwa drei bis fünf Chunks aufgeteilt, mit leichtem Überlapp damit kein Kontext verloren geht.
Der Inhalt kommt aus mehreren Quellen. Der komplette digitalhandwerk.rocks Blog seit dem ersten Artikel. Neue Artikel kommen täglich automatisch über einen Crawler dazu, der die WordPress REST API nutzt und nur Artikel der letzten 24 Stunden holt. Ich muss nichts manuell anstoßen, das System lernt mit, ohne dass ich daran denke.
Zusätzlich kann ich direkt über die Web-UI Notizen eingeben, URLs indexieren, oder Dateien hochladen. PDF, Word-Dokument, Markdown, plain Text, alles wird automatisch verarbeitet. Eine Beratungsnotiz nach einem Kundengespräch, ein interessanter Artikel, den ich gefunden habe, eine eigene Idee, die ich festhalten will: alles landet in derselben semantischen Wissensbasis und ist sofort durchsuchbar.
Was mich dabei am meisten überrascht hat: Ich habe Inhalte wiedergefunden, an die ich selbst nicht mehr gedacht hätte. Artikel aus 2023, die exakt das Thema behandeln, nach dem ein Kunde fragt. Notizen aus einem Workshop, die jetzt auf einmal relevant sind. Das System erinnert sich besser als ich.
Die MCP-Verbindung zu Claude Desktop
Der für mich praktisch wichtigste Teil ist die Integration mit Claude Desktop über das Model Context Protocol, kurz MCP.
MCP ist ein offener Standard von Anthropic, der es erlaubt, externe Tools und Dienste direkt in Claude einzubinden. Ich habe einen kleinen Node.js-Server gebaut, etwa 60 Zeilen Code, der mein RAG-System als MCP-Tool für Claude Desktop bereitstellt.
Das bedeutet konkret: Wenn ich in Claude Desktop eine Frage stelle, kann Claude automatisch entscheiden, ob es sinnvoll ist, meine Wissensbasis zu befragen. Das passiert im Hintergrund, ohne dass ich es manuell anstoßen muss. Claude stellt die Anfrage an mein RAG-System, bekommt die relevantesten Textstellen zurück, und antwortet dann auf Basis dieser Inhalte.
Ein Beispiel aus der Praxis, gestern Abend: Ein Beratungsgespräch über AI-Visibility-Strategien für einen KMU-Kunden. Ich habe Claude gefragt, was ich zu dem Thema bereits erarbeitet habe. Claude hat automatisch mein RAG befragen, drei relevante Blogartikel gefunden, die Kernpunkte daraus zusammengefasst, und mir eine strukturierte Übersicht gegeben. In 20 Sekunden, aus meinen eigenen Inhalten. Das hätte ich manuell nicht schneller gemacht.
Der nächste Schritt ist die Integration in VINCI, meinen Desktop-KI-Assistenten, den ich selbst entwickelt habe. VINCI wird das RAG als primäre Wissensdatenbank nutzen, das bisherige Outline-basierte System ablösen, und bei jeder Anfrage automatisch in meinen eigenen Inhalten suchen, bevor es antwortet. Das bedeutet: jede KI-Anfrage, egal über welches Interface, hat Zugriff auf alles, was ich je dokumentiert habe.
Und weil mir das noch nicht reichte, läuft das RAG jetzt auch direkt in claude.ai im Browser.
Der Weg dorthin war kürzer als erwartet. Anthropic unterstützt seit März 2026 sogenannte Remote MCP Server als Custom Connectors – das bedeutet, ein MCP Server läuft nicht mehr lokal auf dem Rechner, sondern öffentlich erreichbar im Netz, und claude.ai verbindet sich von Anthropics Cloud-Infrastruktur aus damit. Ich habe also einen zweiten kleinen Node.js-Service gebaut, der auf meiner Hetzner-Infrastruktur läuft und als Brücke zwischen claude.ai und meiner RAG API funktioniert.
Das Ergebnis: Unter den Konnektoren in claude.ai taucht jetzt „Prompt Rocker RAG“ auf, mit zwei Tools – rag_search und rag_ingest_note. Ich kann Claude direkt auffordern, in meiner Wissensbasis nachzuschauen. Kein Umweg über Claude Desktop, kein lokaler Server der laufen muss. Funktioniert auf jedem Gerät mit Browser, also auch am iPhone unterwegs.
Ein kleiner Fallstrick war die Gzip-Komprimierung in Traefik, meinem Reverse Proxy. Server-Sent Events, über die MCP kommuniziert, vertragen keine Komprimierung. Eine deaktivierte Middleware später lief die Verbindung durch.
Warum das für EPU und KMU relevant ist
Ich arbeite als KI-Berater und Trainer mit Einzelunternehmen und kleinen bis mittleren Unternehmen in der DACH-Region. Die häufigste Frustration, die ich in Beratungsgesprächen höre, ist diese: „Ich nutze schon KI-Tools, aber ich muss jedem Tool immer wieder erklären, was mein Unternehmen macht, was meine Kunden brauchen, wie ich arbeite.“
Das ist das Problem, das RAG löst. Nicht für Konzerne mit dedizierter IT-Abteilung, sondern für Einzelunternehmer, Berater, Agenturen, jeden der Wissen produziert und dieses Wissen wiederverwendbar machen will.
Die Einstiegshürde ist niedriger als die meisten vermuten. Du brauchst keinen Softwareentwickler im Haus. Du brauchst kein tiefes technisches Wissen. Du brauchst eine Infrastruktur wie Hetzner mit Coolify, eine Gemini API, und etwas Zeit für das initiale Setup.
Was du am Ende hast: Eine semantische Wissensbasis, die mit dir wächst. Ein KI-System, das deine eigenen Inhalte kennt. Einen MCP-Server, der diese Wissensbasis direkt in Claude Desktop verfügbar macht. Alles unter deiner Kontrolle, auf deiner Infrastruktur, ohne monatliche SaaS-Kosten die ins Unendliche wachsen.
Was ich in der Beratung anbiete
Ich baue das nicht nur für mich. Ich baue das für Kunden.
Wenn du als EPU oder KMU entscheidest, dass du dein eigenes RAG-System willst, kenne ich den Weg. Jedes Detail davon. Welche Infrastruktur funktioniert und welche nicht. Wo die typischen Probleme liegen. Wie man ein Embedding-Modell wählt, das zur eigenen Datenmenge und zum Budget passt. Wie man sicherstellt, dass das System DSGVO-konform betrieben werden kann. Wie man den MCP-Server für Claude Desktop konfiguriert.
In zwei bis drei Tagen intensiver Zusammenarbeit hat ein Kunde sein eigenes RAG-System, inkl. Web-UI für die Ingest-Verwaltung, MCP-Integration für Claude Desktop, automatischem WordPress-Crawler wenn relevant, und die Dokumentation für den laufenden Betrieb.
Das ist kein Standardprodukt. Es ist ein Setup, das zu deiner spezifischen Infrastruktur, deinen Inhalten und deinen Workflows passt. Ich bringe das Wissen darüber mit, was funktioniert. Du bringst das Wissen über dein Unternehmen.
Das ist, in meinen Augen, die sinnvollste Form von KI-Beratung im Jahr 2026: nicht darüber reden, was KI theoretisch kann, sondern gemeinsam etwas bauen, das du morgen nutzen kannst.
Was als nächstes kommt
Ich bin dabei, das System weiter auszubauen. Die VINCI-Integration ist der nächste konkrete Schritt. Danach kommt die Frage, wie ich Kundenmaterialien strukturiert und DSGVO-konform einbinden kann, also projektbezogene Wissensdatenbanken für einzelne Mandate.
Das Problem der Duplikate habe ich bereits gelöst. Bevor neue Chunks einer URL gespeichert werden, löscht das System automatisch alle bestehenden Chunks derselben Quelle. Technisch: ein delete_by_filter gegen die Qdrant-Collection, gefiltert nach der source-URL im Payload, direkt vor dem Upsert. Getestet, funktioniert. Einen Artikel zweimal crawlen ergibt dieselbe Chunk-Anzahl wie einmal crawlen.
Und ich teste gerade verschiedene Chunk-Größen und Overlap-Konfigurationen für unterschiedliche Content-Typen. Blogartikel verhalten sich anders als Beratungsnotizen. Längere technische Dokumente anders als kurze Social-Media-Posts. Die optimale Konfiguration ist nicht universell, und das ist ein Bereich, der in den meisten Tutorials zu wenig Aufmerksamkeit bekommt.
Das ist übrigens auch der Grund, warum ich das selbst gebaut habe und nicht ein fertiges Tool genommen habe: Ich will an diesen Parametern drehen können. Ich will verstehen, warum ein Suchergebnis gut oder schlecht ist. Ich will das System anpassen können, wenn sich meine Inhalte oder meine Nutzungsszenarien ändern.
Ein SaaS-Tool gibt mir eine Oberfläche. Mein eigenes Setup gibt mir das Fundament.
Die ehrliche Einschätzung
Ist das für jeden sinnvoll? Nein. Wenn du gelegentlich mit KI-Tools arbeitest und keine systematische Wissensbasis aufbauen willst, ist das Overkill.
Aber wenn du regelmäßig Inhalte produzierst und diese Inhalte immer wieder als Kontext für KI-Anfragen nutzen willst: dann ist das der Weg, der mich am weitesten gebracht hat. Nicht weil er der einfachste ist, sondern weil er der flexibelste ist.
Ich sage das nicht, um zu beeindrucken. Ich sage das, weil ich einen Unterschied in der Qualität meiner KI-Arbeit gespürt habe, der schwer zu beschreiben ist, bis man es selbst erlebt.
Das Gespräch mit einer KI, die deine eigenen Inhalte kennt, ist ein anderes Gespräch. Direkter. Relevanter. Weniger Erklärungsaufwand, mehr substanzielle Antworten.
Du kannst warten. Oder du kontaktierts mich. Ich weiß wie es geht.
