
Open Source Memories: Wie lokale Vektordatenbanken jedes LLM einsetzbar machen — ohne Daten preiszugeben
Das kleine Label im Screenshot oben — "8 memories used" — ist das wichtigste Detail jeder modernen KI-Architektur im Unternehmensumfeld. Und kaum jemand redet darüber.
Es bedeutet: Die Antwort, die ihr gerade gesehen habt, kam nicht aus den Modellgewichten allein. Bevor das LLM den Prompt überhaupt zu Gesicht bekam, hat die Plattform in eine lokale Vektordatenbank gegriffen, die acht relevantesten Ausschnitte aus euren eigenen Dokumenten und früheren Konversationen herausgefischt und dem Modell als Kontext mitgegeben.
Das Modell hat die Worte geschrieben. Eure Daten haben die Antwort geprägt.
Diese kleine Architekturentscheidung — Memory von Inferenz zu trennen — ist genau der Punkt, der es europäischen, schweizerischen oder regulierten Organisationen erlaubt, die weltweit besten Sprachmodelle einzusetzen, ohne die Datensouveränität aufzugeben.
Das Souveränitäts-Dilemma, das niemand zweimal lösen will
Wer 2026 ein KI-Programm im Unternehmen verantwortet, kennt die Klemme:
- Die stärksten Reasoning-Modelle — GPT-5, Claude Opus 4, Gemini 3, Qwen 3, DeepSeek V4 — laufen in Rechenzentren in den USA und in Asien.
- Eure Daten unterliegen DSGVO, EU AI Act, FINMA, BaFin, HIPAA oder welchem Sektorregulator auch immer eure Compliance-Abteilung gerade Kopfzerbrechen bereitet.
- Eurer CISO bekommt zu Recht jedes Mal einen Schreikrampf, wenn ein ungefiltertes Dokument in ein fremdes Chatfenster wandert.
Die Standardreaktion lautet: Cloud-Modelle verbieten, eine Mauer um eine On-Premise-Llama-Instanz bauen und akzeptieren, dass das Team trotzdem heimlich ChatGPT auf dem Handy nutzt.
Es geht besser. Der Trick ist, aufzuhören, "das Modell" und "die Daten" als ein einziges Produkt zu denken.
Memory und Inferenz sind zwei verschiedene Workloads
Eine sauber gebaute KI-Plattform hat zwei getrennte Schichten:
- Eine Memory-Schicht — Vektor-Embeddings eurer Dokumente, Konversationen, Verträge, Tickets, Wiki-Seiten. Reine Daten. Schwer. Sensibel. Stetig wachsend.
- Eine Inferenz-Schicht — das LLM, das aus Prompt plus abgerufenem Kontext eine brauchbare Antwort macht. Rechenintensiv. Austauschbar. Oft am besten zugekauft.
Der Fehler, den die meisten Konzerne machen: Sie nehmen an, beide Schichten müssten vom selben Anbieter kommen. Müssen sie nicht. Sobald die Trennung steht, schrumpft das Souveränitätsproblem auf eine viel kleinere Frage: Was geht über die Grenze, und was bleibt zu Hause?
In einem sauber gebauten RAG-Stack (Retrieval-Augmented Generation) ist die Antwort: Nur der Prompt, die abgerufenen Ausschnitte und die generierte Antwort überqueren die Grenze. Der vollständige Dokumentenbestand — Gigabytes an Verträgen, Recherche, Kundenhistorie, Code — verlässt euer Rechenzentrum nie.
Wie Synaplan das umsetzt
Synaplan ist von Anfang an um diese Trennung herum entworfen. Die Plattform nutzt zwei komplementäre lokale Speicher:
- MariaDB mit der VECTOR-Erweiterung für strukturierte Embeddings, Keyword-Indizes und Metadaten.
- Qdrant für hochperformante semantische Suche über Millionen von Vektoren.
Beide laufen als Docker-Container auf eurer eigenen Hardware (oder in eurem eigenen Cloud-Account). Jedes Dokument, das ihr hochladet — PDFs, DOCX-Dateien, E-Mails, Transkripte, Code — wird lokal in Chunks zerlegt, eingebettet und indiziert. Die rohen Bytes verlassen euer Netz nie.
Stellt ein Nutzer eine Frage, läuft der Ablauf so:
- Die Frage wird lokal eingebettet.
- Synaplan fragt Qdrant und MariaDB VECTOR nach den relevantesten Memories.
- Nur die Frage plus die abgerufenen Ausschnitte gehen an den konfigurierten LLM-Anbieter.
- Die Antwort wird lokal protokolliert und in den Memory-Store zurückgespielt.
Achtet darauf, was nicht passiert: Euer kompletter Dokumentenbestand wird nicht zu OpenAI, Anthropic oder Alibaba hochgeladen. Die sehen pro Anfrage ein paar hundert Tokens Kontext — mehr nicht.
"Wechsle den Motor, behalte den Stapel"
Dieser Satz wirkt in Konzern-Beschaffungsmeetings am stärksten.
Der Vektorspeicher und die Dokumente darin sind das Asset, an dem ihr seit Monaten baut — das Firmengedächtnis. Das LLM ist der Motor, der dieses Gedächtnis in Antworten verwandelt. Mit Synaplan ist der Motor pro Nutzer, pro Chat, sogar pro Anfrage konfigurierbar:
- Nutzt GPT-5 für das Marketing-Team, das Hochglanz-Texte braucht.
- Schickt das Legal-Team auf Claude Opus 4 für lange Vertragsanalysen.
- Routet Code-Fragen an Qwen 3 Coder auf einem Groq-Endpoint.
- Fallt zurück auf ein lokales Llama 3.3 via Ollama für alles, was nie nach draußen darf.
Wenn nächstes Quartal ein neues Modell startet, ändert ihr eine Zeile Konfiguration. Der Memory-Stapel — euer eigentliches geistiges Eigentum — bleibt genau dort, wo er ist.
Das ist das Gegenteil des Lock-in-Musters, das klassische KI-Anbieter verkaufen. Statt eure Daten in OpenAIs "Custom GPTs" oder Anthropics "Projects" zu kippen — und zuzusehen, wie euer Wissen untrennbar mit deren Preismacht verknüpft wird — behaltet ihr das Wissen unter eurem Dach und mietet die Rechenleistung.
Warum das gerade Konzerne betrifft
Drei Gründe, in der Reihenfolge, wie oft sie in unseren Kundengesprächen auftauchen:
1. Compliance ist keine Einzelentscheidung
Ein Startup mit 50 Leuten schreibt einmal eine AVV und gut ist. Ein Konzern mit 50.000 Mitarbeitenden hat Dutzende Rechtseinheiten, hunderte Prozessverantwortliche und in jeder Geschäftseinheit ein anderes Datenklassifizierungsschema. Ein zentraler Memory-Store, den das Unternehmen selbst kontrolliert — gesichert, verschlüsselt, auditierbar und physisch in einer bekannten Jurisdiktion — ist die einzige Architektur, die ein internes Audit in dieser Größenordnung übersteht.
2. Modellrisiko ist jetzt eine echte Risikokategorie
Vorstände stellen inzwischen sehr konkrete Fragen: "Was passiert, wenn unser primärer KI-Anbieter den Preis verdoppelt?" "Was, wenn eine US-Exportkontrollregel uns von einer Modellfamilie abschneidet?" "Was, wenn ein Modell aus Sicherheitsgründen zurückgezogen wird?"
Sind eure Daten an die Plattform eines einzigen Anbieters geschweißt, lautet die Antwort: "Wir haben ein Problem." Liegen eure Daten in eurer eigenen Vektordatenbank, lautet die Antwort: "Wir tauschen die Konfiguration und arbeiten weiter."
3. Die guten Modelle bleiben in Bewegung
2024 war GPT-4 das beste Allround-Modell. 2025 war Claude 3.5 Sonnet für Reasoning vorne, Gemini 1.5 für Kontextlänge. 2026 mischt sich das Leaderboard alle paar Monate neu durch. Jede Architektur, die annimmt "wir haben im Februar den richtigen Anbieter gewählt", ist im September falsch.
Eine souveräne Memory-Schicht macht aus dieser Bewegung eine Chance statt einer Katastrophe. Ihr könnt neue Modelle gegen dieselbe Wissensbasis A/B-testen, mit denselben Evals messen und wechseln, sobald die Zahlen es sagen.
Was bleibt lokal, was geht raus?
Für die Engineers unter euch — die ehrliche Bilanz:
| Bleibt lokal | Geht über die Grenze |
|---|---|
| Vollständiger Dokumentenbestand | Der Prompt des Nutzers |
| Vektor-Embeddings | Eine Handvoll abgerufene Ausschnitte |
| Konversationshistorie (Langzeit) | Die Antwort des Modells |
| Nutzerkonten und Berechtigungen | (Optional) Nutzungs-Telemetrie |
| API-Keys und Audit-Logs |
Wer die rechte Spalte auf Null drücken muss, betreibt Synaplan rein lokal mit Ollama, vLLM oder Triton. Die meisten Konzerne brauchen das gar nicht. Sie brauchen die Option, die Kontrolle und die Sichtbarkeit, um genau zu wissen, welche Bytes wohin fließen.
So fangt ihr an
Synaplan ist Open Source unter Apache 2.0 und kommt als Docker-Compose-Stack. Eine typische Erstinstallation sieht so aus:
- Repository klonen von github.com/metadist/synaplan.
- Stack hochfahren mit
docker compose up -d— FrankenPHP, Vue 3, MariaDB mit VECTOR, Qdrant und das Chat-Widget sind sofort da. - Ersten KI-Anbieter-Key eintragen (OpenAI, Anthropic, Google, Groq, Mistral oder einen beliebigen OpenAI-kompatiblen Endpoint).
- Ein paar Dokumente hochladen und zusehen, wie sich die Memory-Schicht füllt.
- Einen Chat öffnen und dasselbe "memories used"-Label aus dem Screenshot oben wiederfinden.
Von dort aus skaliert ihr, indem ihr mehr Dokumente, mehr Anbieter und — wenn ihr so weit seid — euren bestehenden Identity-Provider, euren Storage und euren Observability-Stack anbindet.
Das Modell ist austauschbar. Die Memory gehört euch.