Wichtigste Erkenntnisse
- Wählen Sie eine von drei Referenzarchitekturen, statt von Grund auf zu designen. Obsidian-zentriert (notiz-zentrisch, ~50K Elemente), AnythingLLM-zentriert (dokumenten-zentrisch, ~100K Elemente) oder eigener Python + ChromaDB Stack (engineer-zentrisch, 1M+ Elemente). Architekturen zu mischen lohnt sich selten — der Integrationsaufwand dominiert.
- Eine lokale KI-PKB hat fünf Schichten: Capture, Speicherung, Embeddings, Retrieval, Schnittstelle. Die meisten Anfängerfehler passieren in der Capture-Schicht, nicht im LLM. Wenn Items nicht aus Mobile und E-Mail in das System fließen, rettet kein noch so cleveres Retrieval den Build.
- Hardware-Untergrenze: 16 GB RAM. Darunter müssen Sie zwischen Embedding-Modell und Chat-Modell wählen — beides geht nicht. Mit 16 GB lassen sich Llama 3.2 3B + nomic-embed-text parallel betreiben. Mit 32 GB können Sie auf Qwen3 7B aufrüsten oder mehrere Chat-Sitzungen führen. Ab 100.000 Elementen Embeddings auf einen Heimserver auslagern.
- Empfohlene Modelle 2026: Chat — Llama 3.2 3B (Standard), Phi-4 Mini (8-GB-Systeme), Qwen3 7B (Qualität ab 32 GB); Embeddings — nomic-embed-text (768-dim, schnell), mxbai-embed-large (1024-dim, präziser), bge-m3 (mehrsprachig).
- Capture ist der Skalierungs-Engpass, nicht Retrieval. Die meisten Wissens-Items entstehen mobil (Web-Clippings, Screenshots, Sprachnotizen, weitergeleitete E-Mails). Entwerfen Sie den Pfad Mobile Share Sheet → Vault, bevor Sie das LLM tunen. iOS Shortcuts → Obsidian / Working Copy / a-Shell sind die drei tragfähigen iOS-Pfade.
- Die Sync-Methode bestimmt, was auf Mobile funktioniert. Obsidian Sync verarbeitet binäre Embedding-Indizes sauber; iCloud Drive korrumpiert sie plattformübergreifend; Git erfordert .gitignore-Disziplin und geräteweise Re-Indexing. Sync zuerst wählen, Plugins danach.
- Backup ist nicht optional. Drei Schichten: Vault-Snapshot (Time Machine, Backblaze, restic), Git-Historie der Klartext-Inhalte und ein quartalsweiser Export von Embeddings + Metadaten als sauberer Wiederaufbaupfad. Embeddings sind regenerierbar, aber teuer — sichern Sie sie ab 10.000 Elementen ebenfalls.
Quick Facts
- Behandelte Architekturen: Obsidian-zentriert, AnythingLLM-zentriert, eigener Python + ChromaDB Stack.
- LLM-Backend: Ollama (empfohlen) — betreibt Chat- und Embedding-Modelle hinter einem lokalen Endpoint unter
http://localhost:11434. - Empfohlene Chat-Modelle 2026: Llama 3.2 3B (16-GB-Systeme), Phi-4 Mini (8 GB), Qwen3 7B (ab 32 GB).
- Empfohlene Embedding-Modelle 2026: nomic-embed-text (768-dim, schnell), mxbai-embed-large (1024-dim, präzise), bge-m3 (mehrsprachig).
- Element-Zielgrößen: Obsidian ~50.000 Notizen, AnythingLLM ~100.000 Dokumente, eigener Python + ChromaDB Stack 1 Mio.+.
- Hardware-Untergrenze: Laptop mit 16 GB RAM. Ab 10.000 Elementen: 32 GB empfohlen. Ab 100.000 Elementen: Heimserver mit 64 GB.
- Mobile Capture-Pfade (iOS): Shortcuts → Obsidian, Shortcuts → Working Copy (Git), Shortcuts → a-Shell. Android: Tasker oder HTTP Shortcuts.
Welche Architektur sollten Sie bauen?
Wählen Sie die Architektur, die zu Ihrem bestehenden Wissensfluss passt — nicht diejenige, die am leistungsstärksten klingt. Wenn Sie bereits täglich Notizen schreiben, bauen Sie Obsidian-zentriert. Wenn Ihr Wissen überwiegend aus Dokumenten besteht (PDFs, Exporte, Web-Clippings), bauen Sie AnythingLLM-zentriert. Bauen Sie nur dann einen eigenen Python + ChromaDB Stack, wenn Sie wirklich 100.000+ Elemente haben oder Multi-User-Zugriff brauchen — die Wartungskosten sind real und unterhalb dieser Schwelle selten gerechtfertigt.
📍 In einem Satz
Notiz-zentrische Workflows wählen Obsidian + Smart Connections + Copilot + Ollama; dokumenten-zentrische Archive wählen AnythingLLM + Ollama; Engineers mit 100K+ Elementen wählen einen eigenen Python + ChromaDB Stack.
💬 In einfachen Worten
Drei Wege, ein Ziel. Wenn Sie ohnehin in einer Notiz-App leben, packt Obsidian KI-Funktionen um Ihre vorhandene Routine. Wenn Sie hauptsächlich PDFs und Webseiten sammeln, ist AnythingLLM eine einzelne App, die einliest, indexiert und chattet. Wenn Sie programmieren und volle Kontrolle wollen, lässt Sie Python + ChromaDB exakt das bauen, was Sie wollen — aber Sie warten es selbst. Wählen Sie den Weg, der zu Ihrer bestehenden Arbeitsweise passt; ändern Sie nicht Ihre Gewohnheiten, um zur Architektur zu passen.
Entscheidung: Welche PKB-Architektur?
Use a local LLM if:
- •Sie nutzen bereits Obsidian oder wünschen einen notiz-zentrischen Workflow mit Markdown-Dateien → Obsidian-zentriert
- •Ihr Wissen besteht überwiegend aus PDFs, Exporten, Web-Clippings und E-Mail-Archiven → AnythingLLM-zentriert
- •Sie haben 100.000+ Elemente, eigene Schema-Anforderungen oder Multi-User-Zugriff → eigener Python + ChromaDB Stack
- •Sie wollen eine App, die Capture, Speicherung, RAG und Chat abdeckt → AnythingLLM-zentriert
- •Sie wollen volle Kontrolle über Chunking, Retrieval und Re-Ranking → eigener Python + ChromaDB Stack
Use a cloud model if:
- •Sie brauchen GPT-4o-Klasse Reasoning bei jeder Anfrage und Ihr Archiv ist klein → Notion AI oder ChatGPT mit Custom GPTs (der lokale Stack ist bei Synthese rund 70 % so leistungsfähig)
- •Sie haben keinen Rechner mit 16 GB+ RAM und keinen Heimserver → Cloud-SaaS-PKB (Mem, Reflect)
- •Ihr Team braucht gleichzeitigen Multi-User-Zugriff und Sie wollen keine Dienste hosten → Cloud-Äquivalent
Quick decision:
- →Standard für notiz-zentrische Anwender: Obsidian + Smart Connections + Copilot + Ollama
- →Standard für dokumenten-zentrische Anwender: AnythingLLM + Ollama
- →Engineer mit 100K+ Elementen: eigener Python + ChromaDB + Llama 3.2 3B Stack
💡Tip: Starten Sie nicht mit dem eigenen Python-Stack, nur weil er leistungsfähiger klingt. Bauen Sie zuerst Obsidian-zentriert oder AnythingLLM-zentriert, betreiben Sie es zwei Monate, identifizieren Sie die Schicht, die nicht zu Ihrem Workflow passt, und ersetzen Sie erst dann diese eine Schicht durch eine eigene Komponente. Jedes PKB-Projekt, das „from scratch in Python" begonnen und länger als sechs Monate gelaufen ist, konvergierte am Ende ohnehin zu Obsidian- oder AnythingLLM-Form.
Architektur-Vergleichstabelle
Die drei Referenzarchitekturen unterscheiden sich auf fünf Achsen, die für die meisten Builder relevant sind: Setup-Komplexität, Element-Obergrenze, Mobile Sync, Capture-Flexibilität und Wartungsaufwand. Die Setup-Komplexität wächst grob linear mit der Kontrolle — und ebenso die Wartungskosten.
📍 In einem Satz
Obsidian ist mittelkomplex bei ~50K Elementen, AnythingLLM ist niedrigkomplex bei ~100K Elementen, und ein eigener Python + ChromaDB Stack ist hochkomplex, skaliert aber über 1 Mio. Elemente.
💬 In einfachen Worten
AnythingLLM ist am einfachsten einzurichten und skaliert von den beiden „fertigen" Optionen am weitesten — ist aber meinungsstark, wie Dokumente organisiert sein sollten. Obsidian liefert die ausdrucksstärkste Notiz-Schicht und ein aktives Plugin-Ökosystem, gegen einen leicht höheren Setup-Aufwand. Eigenes Python ist unbegrenzt, aber Sie warten alles: Chunking, Re-Ranking, Deduplikation, Sync, Backups. Wählen Sie nach Ihrer Geduld für Wartung, nicht allein nach Element-Anzahl.
| Architektur | Setup-Komplexität | Max. Elemente | Mobile Sync | Am besten für |
|---|---|---|---|---|
| Obsidian-zentriert | Mittel | ~50.000 | Ja (Obsidian Sync; iCloud / Git mit Einschränkungen) | Notiz-zentrische Power-User mit täglicher Schreibroutine |
| AnythingLLM-zentriert | Niedrig | ~100.000 | Eingeschränkt (Web-UI vom Smartphone via LAN / Tailscale) | Dokumentenlastige PKBs (PDFs, Exporte, Web-Clippings) |
| Eigener Python + ChromaDB | Hoch | 1 Mio.+ | Manuell (eigene API + mobiler Client erforderlich) | Engineers mit voller Kontrolle + Multi-User |
💡Tip: Mobile Sync ist die am stärksten unterschätzte Vergleichsachse. AnythingLLM ist technisch einfacher einzurichten als Obsidian, aber auf Mobile heißt das „LAN-Web-UI in Safari öffnen" — keine native Erfahrung. Obsidian Mobile, kombiniert mit Obsidian Sync, liefert Ihnen eine nahezu native iOS- / Android-App mit Offline-Lesen. Wenn mobiles Capture und Lesen wichtig sind, gewichten Sie Obsidian höher als die Tabelle vermuten lässt.
Die fünf Schichten einer lokalen KI-PKB
Jede lokale KI-PKB hat unabhängig von der Architektur dieselben fünf Schichten: Capture, Speicherung, Embeddings, Retrieval, Schnittstelle. Fehler entstehen meist, weil eine Schicht nicht zu den anderen passt — am häufigsten ein anspruchsvolles Retrieval gepaart mit einer kaputten Capture-Pipeline, die niemand benutzt.
- 1Capture
Why it matters: Wie Items ins System gelangen. Web Clipper, E-Mail-Forwarder, Mobile Share Sheet, Sprachnotiz, manuelles Einfügen. Die am häufigsten übersprungene Schicht in Anfänger-Builds — und die Schicht, die entscheidet, ob das System den Alltag überlebt. Wenn Capture mobil länger als 5 Sekunden dauert, sammelt das System Staub. - 2Speicherung
Why it matters: Wo Items auf der Platte liegen. Markdown-Vault (Obsidian, Logseq), Dokumentenordner + Datenbank (AnythingLLM) oder Dateisystem + Manifest (eigenes Python). Wählen Sie ein Speicherformat, das jeden Tool-Wechsel überlebt — Klartext-Markdown ist am portabelsten; binäre Datenbanken sind es am wenigsten. - 3Embeddings
Why it matters: Vektordarstellungen von Items für die semantische Suche. Erzeugt von einem lokalen Modell (nomic-embed-text oder mxbai-embed-large via Ollama). Das Embedding-Modell lässt sich später wechseln, aber die Migrationskosten lauten „alles neu embedden" — einmal wählen, dabei bleiben. - 4Retrieval
Why it matters: Wie Items zur Abfragezeit gefunden werden. Top-k-Vektorsuche, optional Re-Ranking, optional Metadaten-Filter (Tags, Daten, Quellen). Der Qualitätsunterschied zwischen einem naiven Top-5 und einem getunten Top-20-mit-Re-Ranker ist der Unterschied zwischen „nützlich" und „magisch". - 5Schnittstelle
Why it matters: Wie Sie abfragen und lesen. Sidebar (Smart Connections), Chat (Copilot, AnythingLLM), CLI (eigenes Python) oder API. Die meisten Anwender greifen standardmäßig zum Chat — aber eine Sidebar mit verwandten Notizen bringt vergessenes Material hervor, das Chat nicht findet, weil Sie nicht wissen, wonach Sie fragen sollen.
⚠️Warning: Ein häufiges Build-Muster, das scheitert: das leistungsstärkste Retrieval (eigene Hybridsuche mit Re-Ranking), das klügste Chat-Modell (Qwen3 7B) — und Capture wird ignoriert. Drei Wochen später hat der Vault 47 Items, weil mobil nichts hineinfließt. Die Korrektur ist immer dieselbe: Retrieval vereinfachen, Chat vereinfachen, Capture reparieren und akzeptieren, dass 80 % des Werts daraus entstehen, dass Items überhaupt im System landen.
Architektur A: Obsidian-zentriert
Obsidian + Smart Connections + Copilot for Obsidian + Ollama ist 2026 die Standardarchitektur für notiz-zentrische Workflows. Sie skaliert sauber bis ~50.000 Notizen auf einem 16-GB-Mac M3 Pro oder PC, unterstützt mobiles Lesen via Obsidian Mobile und hält alles in Klartext-Markdown, das Sie zu jedem zukünftigen Tool mitnehmen können.
- Speicherung: Markdown-Dateien in einem Ordner („Vault"). Klartext, einfache Ordner, keine Datenbank. Übersteht Tool-Migration.
- Capture: Obsidian Web Clipper (Browser-Erweiterung), Obsidian Mobile Share Sheet (iOS / Android), E-Mail-zu-Obsidian via Mailspike oder ein eigenes IFTTT-Rezept, manuelles Einfügen.
- Embeddings: Smart Connections Plugin → Ollama unter
http://localhost:11434/api/embeddings→ nomic-embed-text (Standard) oder mxbai-embed-large (präziser). Index liegt in.smart-env/innerhalb des Vaults. - Retrieval: Smart Connections Sidebar (Verwandte-Notizen-Ansicht) + Copilot for Obsidian Vault-QA-Modus (RAG über den Vault für Chat-Anfragen). Beide nutzen den Embedding-Index.
- Schnittstelle: Smart Connections Sidebar (passive Entdeckung) + Copilot Chat-Panel (aktive Anfragen) + Text Generator Templates (wiederholbare Workflows wie tägliche Zusammenfassungen).
- Setup-Zeit: ~30 Min. (Ollama installieren, Modelle pullen, drei Plugins installieren, Endpoints konfigurieren, initialen Index aufbauen lassen).
- Hardware: mindestens 16 GB RAM (Llama 3.2 3B + nomic-embed-text parallel). 32 GB empfohlen ab 10.000 Notizen. SSD dringend empfohlen — Index-Neuaufbau ist auf HDDs I/O-gebunden.
- Element-Obergrenze: ~50.000 Notizen praktikabel; getestet bis 20.000 mit Sub-Sekunden-Inkrement-Reindex. Ab 50K+ Notizen läuft der Initial-Index 4–8 Stunden, und Sie sollten Sub-Vaults erwägen.
- Am besten für: Anwender mit täglicher Schreibroutine, Markdown-First-Vorlieben und dem Wunsch nach einer „Denkpartner"-Sidebar, die vergessene Notizen hervorholt.
- Nicht geeignet für: Anwender, deren Wissen überwiegend aus PDFs und Web-Clippings besteht (AnythingLLM-zentriert wählen); Anwender, die eine einzelne All-in-One-App wünschen (Obsidian-zentriert ist „Obsidian + 3 Plugins + Ollama").
💡Tip: Eine Vertiefung der Plugin-Schicht dieser Architektur (welche 5 Plugins, Konfigurationsschritte, Vault-Skalierungswerte) finden Sie im Obsidian + Local LLM Plugin-Guide. Diese Seite behandelt die Architektur; der Plugin-Guide behandelt die Konfiguration.
Architektur B: AnythingLLM-zentriert
AnythingLLM + Ollama ist die All-in-One-Option: Capture, Speicherung, RAG und Chat sind in einer Desktop- oder selbstgehosteten App gebündelt. Sie skaliert bis ~100.000 Dokumente (gemischt PDFs, Web-Clippings, Exporte) und ist die richtige Wahl, wenn Ihr Wissen überwiegend als Dokumente und nicht als Notizen entsteht.
- Speicherung: AnythingLLM-interne Datenbank (standardmäßig SQLite; Postgres für Multi-User Self-Hosting). Dokumente werden über die UI eingelesen; Originale können auch in einem Ordner verbleiben, den Sie spiegeln.
- Capture: In-App-Upload (PDFs / Dateien per Drag & Drop in einen Workspace), Browser-Erweiterung für Webseiten, öffentliche API für programmatische Ingestion (
POST /api/v1/document/upload), E-Mail-Forwarder via offizielle Integration oder eigenes Relay. - Embeddings: AnythingLLM nutzt Ihren konfigurierten Embedding-Provider — wählen Sie „Ollama" → Endpoint
http://localhost:11434→ Modellnomic-embed-text. Embeddings im integrierten Vector Store (standardmäßig LanceDB; ChromaDB / Pinecone optional). - Retrieval: RAG über den Workspace. Konfigurierbare Chunk-Größe, Top-k-Retrieval, optionales Re-Ranking. Mehrere Workspaces erlauben Partitionierung nach Thema (z. B. „Arbeit", „Lesen", „Projekte").
- Schnittstelle: AnythingLLM Web-UI (funktioniert in Desktop- und Mobile-Browsern), öffentliche API für eigene Frontends, OpenAI-kompatibler Endpoint, um andere Tools an Ihre PKB anzubinden.
- Setup-Zeit: ~15 Min. (AnythingLLM Desktop oder Docker installieren, auf Ollama zeigen, Dokumente hineinziehen).
- Hardware: mindestens 16 GB RAM. 32 GB empfohlen ab 10.000 Dokumenten. AnythingLLM ist bei gleicher Element-Anzahl speichersparsamer als Obsidian + Plugins, weil ein Prozess statt zwei läuft.
- Element-Obergrenze: ~100.000 Dokumente in einem einzigen Workspace; ab 50K in mehrere Workspaces partitionieren, um die Retrieval-Latenz unter ~1 Sek. zu halten.
- Am besten für: Anwender mit PDF-lastigen Archiven, Web-Clipping-lastigem Capture und Vorliebe für eine App statt eines Plugin-Stacks. Auch die richtige Wahl für kleine Teams, die eine geteilte PKB selbst hosten.
- Nicht geeignet für: Anwender, die eine notiz-zentrische Schreibfläche wollen (Obsidian); Anwender, die ihre Speicherung als Klartext-Markdown besitzen wollen (AnythingLLMs Vector Store ist intern).
💡Tip: Eine Schritt-für-Schritt-Einrichtung der hier verwendeten RAG-Schicht (Ollama + AnythingLLM, Ingestion, Chunk-Tuning) finden Sie im Walkthrough Local RAG on Your PDFs in 30 Minutes. Zur Skalierung von RAG über Spielzeugbeispiele hinaus auf 1.000+ PDFs siehe Chat With 1000+ PDFs Locally.
Architektur C: Eigener Python + ChromaDB Stack
Ein eigener Python + ChromaDB + Ollama Stack ist nur dann die richtige Wahl, wenn Sie tatsächlich 100.000+ Elemente, Multi-User-Anforderungen oder spezifische Schema-Anforderungen haben, die Standard-Tools nicht abbilden können. Die Wartungskosten sind real: Chunking, Deduplikation, Re-Ranking, Sync, Backup — Sie verantworten alles selbst.
ChromaDB-Ingestion (Python-Skizze)
“import chromadb, ollama, pathlib client = chromadb.PersistentClient(path="./chroma") coll = client.get_or_create_collection("kb") for p in pathlib.Path("vault").rglob("*.md"): text = p.read_text() emb = ollama.embeddings(model="nomic-embed-text", prompt=text)["embedding"] coll.upsert(ids=[str(p)], embeddings=[emb], documents=[text], metadatas=[{"source": str(p)}])”
Abfrage mit Re-Ranking (Skizze)
“q = "What did I write about local RAG sync?" q_emb = ollama.embeddings(model="nomic-embed-text", prompt=q)["embedding"] hits = coll.query(query_embeddings=[q_emb], n_results=20) # pass hits["documents"] through a re-ranker, keep top 5 # send top 5 + question to Llama 3.2 3B via Ollama chat endpoint”
- Speicherung: Dateisystem (ein Ordner pro Quelle:
notes/,pdfs/,web/,email/) + ein Metadaten-Manifest (SQLite oder JSONL). Quelldateien bleiben in offenen Formaten, damit Sie Retrieval-Schichten ohne erneutes Einlesen austauschen können. - Capture: Skripte, ausgelöst von Webhooks (Web Clipper → HTTP-Endpoint → Datei schreiben), E-Mail-Forwarder → IMAP-Poller → Datei schreiben, Mobile Share Sheet → Tailscale-Endpoint → Datei schreiben. Jeder Capture-Pfad ist ein kleiner Python-Service.
- Embeddings: ChromaDB (Local Mode, persistiert auf Platte) + Ollama-Embeddings über den OpenAI-kompatiblen Endpoint. Re-Embedding bei Datei-Änderung über einen Watchdog-Prozess. ChromaDB skaliert mit HNSW-Indexing auf einer einzelnen Maschine bis in die Millionen Vektoren.
- Retrieval: ChromaDB Top-k-Ähnlichkeit + ein Re-Ranker (BGE Re-ranker oder lokales Cohere-Äquivalent) + Metadaten-Filter (Datumsbereich, Tags, Quelle). Optional Hybridsuche mit BM25 über Chunks für Exakt-Term-Matching.
- Schnittstelle: beliebige Kombination aus: kleinem FastAPI-Service mit OpenAI-kompatiblem
/v1/chat/completions-Endpoint, Streamlit- / Gradio-UI, CLI oder allen drei. Open WebUI davorschalten, um eine polierte Chat-Oberfläche ohne UI-Code zu erhalten. - Setup-Zeit: ~1 Tag für eine lauffähige v1; ~2 Wochen Iteration, um Chunking, Retrieval-Qualität und Capture-Pipelines auf Ihre Daten zu tunen.
- Hardware: Laptop mit 32 GB RAM für die Entwicklung; Heimserver mit 64 GB RAM ab 100.000 Elementen, damit der Embedding-Service nicht mit Ihrem Laptop konkurriert. Eine dedizierte GPU (RTX 4060 oder besser) ab 500K Elementen für Chat-Durchsatz.
- Element-Obergrenze: 1 Mio.+ Elemente praktikabel mit HNSW + Sharding; der Engpass verschiebt sich von Retrieval zu Capture-Pipeline-Zuverlässigkeit und Re-Embedding-Kosten bei Schema-Änderungen.
- Am besten für: Engineers, die den Stack selbst besitzen wollen, Teams mit eigenem Schema (z. B. „jedes Item hat einen Confidence Score, eine Quelle und einen Autor") oder Anwender, die in Obsidian oder AnythingLLM an harte Grenzen stoßen (50K bzw. 100K).
- Nicht geeignet für: Nicht-Engineers; alle, die die Wartungskosten unterschätzen; Anwender, deren Use Case bereits von einer Standardlösung abgedeckt wird.
⚠️Warning: Das häufigste Versagensmuster in eigenen Builds: das gesamte Archiv bei jeder Code-Änderung neu zu embedden, weil das Schema nicht stabil ist. Fixieren Sie Embedding-Modell und Chunk-Größe, bevor Sie mehr als ~5.000 Elemente einlesen. Eine Migration von nomic-embed-text 768-dim zu mxbai-embed-large 1024-dim bei 100K Elementen kostet Stunden Compute und bricht die ChromaDB-Collection — Dimensionen lassen sich nicht mischen.
Capture-Pipeline: Web, E-Mail, Mobil, Sprache
Die Capture-Schicht entscheidet, ob Ihre PKB den Alltag überlebt. Die meisten Wissens-Items entstehen außerhalb des Desktops — mobil, in E-Mail, in Sprachnotizen — und eine Capture-Pipeline, die zuerst eine Desktop-App öffnen verlangt, wird umgangen. Bauen Sie für die vier Hauptzuflüsse und akzeptieren Sie, dass 80 % der Items mobil ankommen.
- Web Clipper (Desktop + Mobile): Obsidian Web Clipper, AnythingLLM Browser-Erweiterung oder ein eigenes Bookmarklet, das die aktuelle Seite an Ihren Capture-Endpoint POSTet. Mobile Share Sheet → Web-Clipper-Erweiterung → Vault.
- E-Mail-Forwarder: dedizierte Adresse (z. B.
kb@ihre-domain.de) + IMAP-Poller → Datei schreiben. Leiten Sie die E-Mails weiter, die Sie behalten möchten; der Poller erledigt die Ingestion. Verwenden Sie ein Quelle-Präfix im Dateinamen, damit das Retrieval nach Sender filtern kann. - Mobile Share Sheet: der meistgenutzte Capture-Pfad. iOS Share → Obsidian (schreibt eine Markdown-Datei), iOS Share → Working Copy (committet zu Git), iOS Share → eigener Shortcut (POST an Ihre Capture-API). Android: HTTP Shortcuts oder Tasker.
- Sprachnotizen: AudioPen-artiges Capture wird 2026 zunehmend gängig. Auf dem Smartphone aufnehmen → lokal mit Whisper.cpp oder über einen selbstgehosteten Whisper-Service transkribieren → Transkript als Markdown-Datei schreiben → embedden.
- Manuelles Einfügen: der Fallback. Funktioniert immer, skaliert nie. Verwenden Sie es für den Long Tail.
- Screenshot-OCR: Screenshots sind ein verlustbehaftetes Capture-Format. Nutzen Sie Apple Live Text auf iOS oder eine lokale OCR-Pipeline (Tesseract, Apple Vision, EasyOCR), um Text zu extrahieren + eine Markdown-Datei mit Bild und OCR-Text zu schreiben.
💡Tip: Auditieren Sie Ihre bestehenden Capture-Gewohnheiten, bevor Sie die Pipeline entwerfen. Schauen Sie, was Sie bereits speichern: Browser-Bookmarks, Screenshots, weitergeleitete E-Mails, Sprachnotizen. Die PKB-Capture-Schicht sollte diese bestehenden Zuflüsse spiegeln — wenn Sie ohnehin ständig Screenshots machen, bauen Sie den OCR-Pfad; wenn Sie ohnehin E-Mails an sich selbst weiterleiten, bauen Sie den E-Mail-Forwarder. Neue Gewohnheiten hinzuzufügen („ab jetzt kopiere ich jeden Artikel manuell in die KB") funktioniert nie.
Mobile Capture: iOS Shortcuts, Working Copy, a-Shell
iOS hat 2026 drei tragfähige Capture-Pfade in eine lokale KI-PKB: Shortcuts → Obsidian, Shortcuts → Working Copy (Git) oder Shortcuts → a-Shell (skriptgesteuert). Jeder passt natürlicherweise zu einer der drei Referenzarchitekturen. Wählen Sie den Pfad, dessen Sync-Modell zu Ihrer Gesamtarchitektur passt.
- Shortcuts → Obsidian (Obsidian-zentriert): der Obsidian-Shortcut „An Notiz anhängen" schreibt den erfassten Inhalt direkt in den Vault. Sync via Obsidian Sync (kostenpflichtig, empfohlen) oder iCloud Drive (kostenlos, mit Einschränkungen). Am besten für notiz-zentrische Workflows.
- Shortcuts → Working Copy (Git): der erfasste Inhalt wird in ein Working-Copy-Repository auf dem iPhone geschrieben, automatisch committet und gepusht. Der Desktop pullt. Kostenlos, robust, funktioniert mit jedem Markdown-Vault. Hinweis: Working Copy ist kostenpflichtig (einmalig ca. 22 €). Am besten für Git-synchronisierte Vaults.
- Shortcuts → a-Shell: a-Shell ist ein kostenloses iOS-Terminal, das Skripte ausführt. Bauen Sie einen Shortcut, der den erfassten Text an ein a-Shell-Skript leitet, das eine Datei schreibt und entweder via
gitcommittet, viarsyncüber Tailscale synchronisiert oder zu Ihrem eigenen Capture-Endpoint hochlädt. Am besten für engineer-gebaute Eigenarchitekturen. - Android-Pendants: Tasker + Termux + Git als Pendant zum iOS Working Copy Pfad. HTTP Shortcuts für den Custom-Endpoint-Pfad. Obsidian Mobile Share Sheet für den Obsidian-Pfad.
- Latenzbudget: Mobile Capture sollte Ende-zu-Ende in unter 5 Sekunden abgeschlossen sein (Share Sheet → Datei geschrieben / committet / hochgeladen). Alles Langsamere und der Anwender öffnet die App einmal und nie wieder.
- Offline-Capture: alle drei iOS-Pfade puffern offline (Shortcuts puffert, Working Copy puffert Commits, a-Shell-Skripte können lokal schreiben und später syncen). Essentiell für Capture in Flugzeugen, im ÖPNV und in ländlichen Gebieten.
⚠️Warning: Bauen Sie keinen mobilen Capture-Pfad, der voraussetzt, dass der Desktop online ist (z. B. POST an einen Tailscale-geschützten Endpoint, der nur erreichbar ist, wenn Ihr Laptop wach ist). Sie verlieren Captures während Meetings, im Sleep-Modus und nachts. Betreiben Sie den Capture-Endpoint entweder auf einem dauerhaft laufenden Heimserver / NAS oder schreiben Sie in einen Eventually-consistent-Store (Obsidian Sync, Git, iCloud), der offline puffert.
Skalierung: 1K, 10K, 100K Elemente
Die Skalierung einer lokalen KI-PKB hat drei Regimes: Unter 1.000 Elementen ist alles auf jedem modernen Laptop schnell; bei 1.000–10.000 Elementen wird der Embedding-Index zu einem realen Artefakt, das verwaltet werden muss; ab 10.000 Elementen wird Hardware zum Engpass und die Capture-Pipeline-Zuverlässigkeit dominiert das Ergebnis. Realistische Werte unten gehen von Mac M3 Pro / RTX 4060 PC mit nomic-embed-text und Llama 3.2 3B aus.
| Element-Anzahl | Empfohlene Architektur | Initialer Embedding-Lauf | Hardware | Hinweise |
|---|---|---|---|---|
| 1.000 Elemente | Beliebige der drei | ~2 Min. | Laptop mit 16 GB RAM | Alles fühlt sich sofort an. Architekturwahl rein nach Workflow-Passung. |
| 10.000 Elemente | Obsidian oder AnythingLLM | ~25 Min. | Laptop mit 16 GB RAM (32 GB empfohlen) | Embedding-Index ~150–250 MB. Re-Embed-Zeit bei Bearbeitungen sub-sekündlich. Sweet Spot für die meisten Wissensarbeitenden. |
| 50.000 Elemente | AnythingLLM oder eigenes Python | ~3 Stunden | Laptop mit 32 GB RAM oder Heimserver | Initial-Index läuft über Nacht. Ab hier in Sub-Vaults / Workspaces aufteilen. Disk-Verbrauch ~1,5–2 GB für Embeddings. |
| 100.000 Elemente | AnythingLLM (Multi-Workspace) oder eigenes Python | 6–8 Stunden | mindestens 32 GB RAM; Heimserver bevorzugt | Embeddings auf einen dedizierten Heimserver auslagern. Capture-Pipeline-Zuverlässigkeit ist nun der primäre Fehlermodus, nicht Retrieval. |
| 500.000+ Elemente | Eigenes Python + ChromaDB | 24+ Stunden | Heimserver mit 64 GB RAM + dedizierte GPU | Sharding, Deduplikation und inkrementelle Re-Embed-Pipelines werden notwendig. Standard-Tools passen nicht mehr. |
💡Tip: Die initialen Embedding-Kosten sind eine Einmalrechnung. Nach dem ersten Index werden nur geänderte Items neu embeddet — meist in unter einer Sekunde pro Save, selbst bei 100K Elementen. Die langsame erste Erfahrung ist real, aber nicht wiederkehrend. Lassen Sie den Initial-Index über Nacht auf einem netzgespeisten Gerät laufen und vergessen Sie ihn.
Backup, Versionierung, Multi-Device-Sync
Eine lokale KI-PKB benötigt drei Backup-Schichten: Vault-Snapshots (Time Machine, Backblaze, restic), Git-Historie der Klartext-Inhalte und einen quartalsweisen Export von Embeddings und Metadaten als sauberen Wiederaufbaupfad. Embeddings sind technisch regenerierbar, aber bei 100K+ Elementen kostet die Regeneration Stunden — sichern Sie sie ebenfalls.
- Vault-Snapshots (Dateisystem-Ebene): Time Machine (macOS) oder restic (Linux) alle 24 Stunden. Backblaze oder rsync.net für Off-Site. Erfasst alles inklusive Embeddings.
- Git-Historie (nur Inhalte): Klartext-Markdown-Dateien in einem Git-Repo committet (lokal + GitHub / Gitea privat). Fügen Sie
.smart-env/,vector_store/und alle weiteren binären Index-Ordner zu.gitignorehinzu. Git liefert pro-Notiz-Versionshistorie; Vault-Snapshots liefern System-Rollback. - Embedding-Export (quartalsweise): Vector Store in ein portables Format exportieren (ChromaDB → Parquet, Smart Connections → JSON-Dump, AnythingLLM → integrierter Export). Die letzten zwei Exporte off-site aufbewahren. Falls ein Vault-Snapshot fehlschlägt oder der Embedding-Index korrumpiert, ist dies Ihr schneller Wiederaufbaupfad.
- Multi-Device-Sync — Obsidian-zentriert: Obsidian Sync verarbeitet Klartext + binäre Indizes sauber (Ende-zu-Ende-verschlüsselt). iCloud Drive funktioniert für Klartext, korrumpiert aber binäre Indizes plattformübergreifend. Git via Working Copy / Termux funktioniert nur für Klartext — Re-Index pro Gerät.
- Multi-Device-Sync — AnythingLLM-zentriert: AnythingLLM als selbstgehosteten Docker-Container auf einem Heimserver betreiben. Alle Geräte verbinden sich per LAN oder Tailscale mit derselben Instanz. Kein Client-seitiger Sync nötig.
- Multi-Device-Sync — eigenes Python: Die Architektur, die Sie bauen, bestimmt das. Die meisten Builds verwenden einen zentralen API-Service (FastAPI auf einem Heimserver) + Clients, die Captures POSTen und Anfragen GETten. Tailscale liefert die Netzwerkschicht.
- Migration auf einen neuen Rechner: Vault-Snapshot wiederherstellen → Git-Repo wiederherstellen → Ollama neu starten → Embedding-Indexer neu starten. Embedding-Regeneration ist automatisch, falls Sie den Embedding-Export-Schritt übersprungen haben; manueller Re-Index, falls Sie ihn gesichert haben, das Format aber plattform-spezifisch ist.
- Selektives Teilen: Für das Teilen von Vault-Teilen (z. B. ein Forschungsprojekt mit Mit-Autoren) Sub-Vaults oder ein Tagged-Export-Skript verwenden. Den ganzen Vault nicht teilen — die meisten lokalen KI-PKBs sammeln sensible Items (medizinisch, finanziell, persönlich), die den lokalen Stack nie verlassen sollten.
💡Tip: Testen Sie Ihre Wiederherstellung einmal pro Quartal. Die meisten „Ich habe Backups"-Aussagen sind Wunschdenken — der Test ist „Kann ich meinen Vault auf einem frischen Laptop in unter 2 Stunden wiederherstellen?" Führen Sie den Test durch. Beim ersten Mal werden Sie feststellen, dass eine der drei Schichten (Snapshot, Git, Embedding-Export) seit sechs Monaten falsch konfiguriert war.
Häufige Fehler
- Die Retrieval-Schicht vor der Capture-Schicht designen. Eine eigene Hybridsuche mit Re-Ranking ist bei 47 Items im Vault verschwendet. Bauen Sie zuerst Capture, akzeptieren Sie naives Top-5-Retrieval und optimieren Sie Retrieval erst, wenn der Vault 1.000+ Items hat und Sie Retrieval-Qualität an realen Anfragen messen können.
- Architekturen mischen. „Obsidian für Notizen + AnythingLLM für PDFs + eigenes Python für E-Mails" klingt sauber, aber der Integrationsaufwand dominiert. Wählen Sie eine Architektur, akzeptieren Sie die Einschränkungen und ergänzen Sie höchstens einen einzigen Connector, wenn unbedingt nötig (z. B. AnythingLLM, das einen Obsidian-Vault-Ordner read-only einliest).
- Embedding-Modell wechseln, ohne das Archiv neu zu embedden. Das Mischen von nomic-embed-text 768-dim und mxbai-embed-large 1024-dim Vektoren im selben Store bricht das Retrieval lautlos. Wählen Sie ein Embedding-Modell + Dimension, fixieren Sie es und wechseln Sie nur mit vollständigem Re-Embedding des Archivs.
- Backup des Embedding-Index ab 10.000 Elementen ignorieren. „Ich kann ihn regenerieren" stimmt, aber die Regeneration dauert Stunden. Nehmen Sie den Embedding-Store ab 10K Elementen in Ihre Backup-Strategie auf.
- Für Desktop designen, obwohl 80 % des Captures mobil passieren. Eine PKB ohne mobilen Capture-Pfad sammelt Staub. Testen Sie den mobilen Capture-Flow am ersten Tag — Share Sheet zu Vault sollte in unter 5 Sekunden abgeschlossen sein.
- iCloud Drive für binäre Embedding-Indizes nutzen. iCloud verarbeitet Klartext sauber; binäre Indizes (Smart Connections
.smart-env/, AnythingLLM Vector Store) korrumpieren plattformübergreifend. Nutzen Sie Obsidian Sync, eine selbstgehostete Instanz oder akzeptieren Sie geräteweises Re-Indexing. - Bei 100K Elementen nicht partitionieren. Ein einzelner Workspace / Vault mit 100K+ Elementen hat Retrieval-Latenzen im Sekundenbereich. Partitionieren Sie nach Thema (Arbeit, Lesen, Projekte) in mehrere Workspaces oder Sub-Vaults; fragen Sie jeden separat oder über einen Router ab.
- DSGVO-Risiko unterschätzen. PKBs sammeln zwangsläufig sensible Daten (E-Mails von Mandanten, Patienten, Kollegen, finanzielle und gesundheitsbezogene Notizen). Auch bei rein lokaler Verarbeitung greifen DSGVO Art. 6 + Art. 32 — und Cloud-Backups (Backblaze, Dropbox) machen aus Ihrem privaten Stack einen Verarbeitungsvorgang mit Auftragsverarbeitungsvertrag-Pflicht. Für berufliche Nutzung On-Premise-Backups (NAS, externe SSD) bevorzugen.
Quellen
- Obsidian — obsidian.md und help.obsidian.md (Vault-Struktur, Mobile-Sync-Architektur, Plugin-Dokumentation).
- AnythingLLM — github.com/Mintplex-Labs/anything-llm (Open-Source selbstgehostete RAG-Anwendung).
- Ollama — ollama.com und github.com/ollama/ollama (lokale LLM-Runtime; Chat- + Embedding-Endpoints).
- ChromaDB — trychroma.com und github.com/chroma-core/chroma (Open-Source lokale Vektordatenbank).
- Working Copy — workingcopy.app (iOS Git-Client für mobile Capture-Pipelines).
- a-Shell — holzschu.github.io/a-Shell_iOS/ (kostenloses iOS-Terminal für skriptgesteuertes Mobile Capture).
FAQ
Wie erfasse ich Webseiten in meiner Wissensdatenbank?
Drei Optionen, nach Aufwand sortiert. (1) Browser-Erweiterungs-Web-Clipper — Obsidian Web Clipper oder AnythingLLM Browser-Erweiterung schreiben die aktuelle Seite direkt in Ihren Vault / Workspace. (2) Mobile Share Sheet — Safari / Chrome teilen → Obsidian (schreibt eine Markdown-Datei) oder → Working Copy (committet zu Git) oder → eigener Shortcut (POSTet zu Ihrer Capture-API). (3) Bookmarklet — für Browser ohne Erweiterung; POSTet die aktuelle URL + Auswahl an Ihren Capture-Endpoint. Das Mobile Share Sheet ist in der Praxis der meistgenutzte Pfad — entwerfen Sie es zuerst.
Kann ich E-Mails ins System weiterleiten?
Ja. Richten Sie eine dedizierte Adresse ein (z. B. ein Fastmail- / Migadu-Alias kb@ihre-domain.de) und betreiben Sie auf Ihrem Heimserver oder Laptop einen IMAP-Poller, der neue Mails herunterlädt und eine Markdown-Datei pro E-Mail in Ihren Vault schreibt. Verwenden Sie ein From-Adress-Präfix im Dateinamen, damit das Retrieval nach Sender filtern kann. AnythingLLM hat eine First-Party-E-Mail-Integration; Obsidian-Anwender bauen den IMAP-Poller meist selbst oder nutzen IFTTT- / Zapier-Alternativen wie n8n.
Wie synchronisiere ich Desktop und Mobile?
Architekturabhängig. Obsidian-zentriert: Obsidian Sync (kostenpflichtig, verarbeitet binäre Indizes sauber), iCloud Drive (kostenlos, nur Klartext — Re-Index pro Gerät) oder Git via Working Copy (kostenlos + einmalige Working-Copy-Gebühr, nur Klartext — Re-Index pro Gerät). AnythingLLM-zentriert: AnythingLLM in Docker auf einem Heimserver betreiben, alle Geräte per LAN oder Tailscale verbinden — kein Client-seitiger Sync nötig. Eigenes Python: zentralen API-Service auf einem Heimserver bauen; Clients POSTen Captures und GETten Anfragen.
Soll ich einen großen Vault verwenden oder nach Themen aufteilen?
Ein Vault bis ~50.000 Elemente. Ab 50K nach Thema aufteilen (Arbeit, Lesen, Projekte, Privat) aus zwei Gründen: Retrieval-Latenz bleibt unter ~1 Sek., und ungewollter Cross-Leak zwischen Kontexten (z. B. private Notizen tauchen in Arbeitsabfragen auf) wird ab dieser Größe möglich. Früher als 50K aufzuteilen ist verfrüht — Sie verlieren die zufälligen Cross-Domain-Verbindungen, die ein Hauptwert einer PKB sind.
Wie oft sollte ich für Genauigkeit neu embedden?
Niemals wegen „Genauigkeitsdrift" neu embedden — Embeddings degradieren nicht. Embedden Sie nur dann neu, wenn Sie das Embedding-Modell wechseln (z. B. Upgrade von nomic-embed-text auf mxbai-embed-large für besseres Retrieval bei technischen Inhalten). Alle drei Architekturen bewältigen inkrementelles Re-Embedding bei Datei-Änderungen automatisch; Sie planen nichts. Ausnahme sind eigene Python-Stacks, in denen Sie den Indexer kontrollieren — dort ist Watchdog-getriebenes inkrementelles Re-Embedding bei Save Standard.
Kann ich meine Wissensdatenbank versionieren?
Ja für Klartext-Inhalte (Markdown-Vault → Git-Repo, lokal + GitHub / Gitea privat). Fügen Sie binäre Index-Ordner (.smart-env/, vector_store/, ChromaDB-Persistenz-Verzeichnis) zu .gitignore hinzu — sie blähen die Historie auf und führen zu Merge-Konflikten. Git liefert pro-Notiz-Versionshistorie; Vault-Snapshots (Time Machine, restic) liefern Gesamtsystem-Rollback. Beide Schichten, nicht entweder/oder.
Wie behandle ich PDFs in diesem System?
Obsidian-zentriert: PDFs neben Markdown-Notizen ablegen; Smart Connections embeddet PDF-Inhalte nicht direkt — extrahieren Sie zuerst Text (z. B. via PDF++ Plugin oder ein Vorverarbeitungsskript, das eine Markdown-Zusammenfassung neben jedes PDF schreibt). AnythingLLM-zentriert: PDFs direkt in einen Workspace ziehen; AnythingLLM übernimmt PDF-Parsing und Chunking automatisch. Eigenes Python: pypdf oder pdfplumber für die Text-Extraktion in Ihrer Ingestion-Pipeline nutzen, dann den extrahierten Text embedden. AnythingLLM ist die reibungsärmste Option für PDF-lastige Archive.
Kann ich Teile meiner KB selektiv teilen?
Ja, aber von Tag eins darauf hin entwerfen. Verwenden Sie Sub-Vaults (Obsidian) oder Workspaces (AnythingLLM), um „teilbare" und „private" Inhalte in getrennten Stores zu halten. Für einmaliges Teilen ein Tagged-Export-Skript bauen, das Items per Tag (z. B. #shareable) in ein portables Markdown-Bundle zieht. Den ganzen Vault nicht teilen — die meisten lokalen KI-PKBs sammeln sensible Items (medizinisch, finanziell, persönliche Korrespondenz), die den lokalen Stack nie verlassen sollten.
Welche Backup-Strategie ist die beste?
Drei Schichten: (1) Dateisystem-Snapshot alle 24 Stunden (Time Machine / restic) mit Off-Site-Kopie (Backblaze / rsync.net); (2) Git-Historie der Klartext-Inhalte für pro-Notiz-Versionswiederherstellung; (3) quartalsweiser Export von Embeddings + Metadaten als schneller Wiederaufbaupfad. Wiederherstellung einmal pro Quartal testen — „Kann ich meinen Vault auf einem frischen Laptop in unter 2 Stunden aufbauen?" Der erste Wiederherstellungstest enthüllt meist, dass eine der drei Schichten falsch konfiguriert war.
Wie migriere ich auf einen neuen Rechner?
Vault-Snapshot wiederherstellen → Ollama installieren und dieselben Modelle pullen → Obsidian / AnythingLLM / Ihren eigenen Python-Stack installieren → Embedding-Indexer neu starten. Mit Obsidian Sync oder selbstgehostetem AnythingLLM ist die Migration „Client installieren und einloggen" — keine manuelle Wiederherstellung nötig. Ohne diese rechnen Sie mit ~30 Min. für einen 10K-Element-Vault, ~2 Stunden für 50K und über Nacht ab 100K, falls Sie den Embedding-Export-Schritt übersprungen haben.
Muss ich bei einer lokalen KI-Wissensdatenbank die DSGVO beachten?
Eine lokale KI-PKB speichert potenziell sensible personenbezogene Daten (Notizen, E-Mails, PDFs, Kontakte). DSGVO Art. 6 + Art. 32 verlangen Rechtsgrundlage + technisch-organisatorische Maßnahmen, auch bei privater oder beruflicher Nutzung. Lokale Inferenz (kein Cloud-Egress) erfüllt die meisten Anforderungen an Datenresidenz und Verarbeitung, weil kein Drittanbieter als Auftragsverarbeiter nach Art. 28 vertraglich gebunden werden muss. Aber: Backups auf Backblaze, Dropbox usw. bleiben Cloud-Dienste mit Auftragsverarbeitungsvertrag-Pflicht. Für Selbstständige (Anwälte, Ärzte, Steuerberater) mit Mandanten-/Patientendaten: rein lokale Backups (NAS, externe SSD) oder BSI-C5-zertifizierte Anbieter bevorzugen. Der lokale Stack ist der einfachere Compliance-Pfad als jede Cloud-PKB.
Ist eine lokale KI-Wissensdatenbank für den deutschen Mittelstand geeignet?
Ja — und für Mittelständler mit sensiblen Geschäftsdaten häufig die geeignetere Wahl als Cloud-PKBs. Empfohlene Aufstellung: AnythingLLM-zentriert auf einem Linux-Heimserver (oder Synology- / QNAP-NAS mit Docker) mit Ollama + Llama 3.2 3B. Das erfüllt BSI-Grundschutz-Bausteine SYS.1 + APP.4 mit auditierbarem On-Premise-Datenfluss. Mehrere Arbeitsplätze via Tailscale für Remote-Zugriff. Initiale Investition: ca. 3.000–5.000 € für Server mit 64 GB + Storage. Gesamtkosten über 3 Jahre liegen bei Teams ab fünf Personen unter den meisten Cloud-PKB-Abos. Für Mittelstand in Finanz, Recht und Medizin ist das die nüchterne Wahl.