Deutsches LLM Wiki – ein Obsidian-Plugin

Seit einiger Zeit sammle ich Wissen in Obsidian. Unterrichtsmaterialien, Ideen für den Physikunterricht, Notizen zu Robotik-Projekten, Schul-IT, Büchern, etc – alles brav verlinkt, aber irgendwie doch schwer durchsuchbar. Dann stieß ich auf LLM Wiki, ein Plugin, das Andrej Karpathys Idee von LLM Knowledge Bases umsetzt. Dabei geht es darum, mit einem LLM eine persönliche, durchsuchbare Wissensbasis aus den eigenen Notizen zu bauen. Dieses Plugin klang vielversprechend und entsprach dem, was ich gesucht habe – aber es gab einen Haken: die deutsche Sprache.

Was das Plugin macht

LLM Wiki liest den gesamten Vault, schickt jede Notiz an ein lokales Sprachmodell und extrahiert daraus strukturiertes Wissen: Entitäten (Personen, Tools, Projekte, Bücher…), Konzepte und die Verbindungen zwischen ihnen. Alles landet in einer wiki/knowledge.json-Datei, und für jede Entität wird eine eigene Markdown-Seite generiert – kompatibel mit Obsidians Bases. Fragen stellt man dann in natürlicher Sprache, das Plugin sucht den passenden Kontext heraus und schickt ihn zusammen mit der Frage ans Modell.

)

Das Ganze läuft per Default vollständig lokal: Ollama mit bei mir gemma4:e4b-it-qat als Chat-Modell. Das im englischen PlugIn voreingestellte nomic-embed-text für Embeddings habe ich für die deutsche Version durch qllama/multilingual-e5-base ersetzt, da es bessere Ergebnisse lieferte.

Beide Modelle laufen auf meiner nicht unbedingt auf KI-Anwendung ausgelegten und nicht ganz neuen Hardware sehr flüssig und ohne Probleme:

• Grafikkarte: AMD Radeon RX 7600 mit 8 GB dediziertem Speicher
• CPU: Intel(R) Xeon(R) W-1250 CPU @ 3.30GHz mit 64 GB RAM

Gemma4 habe ich mittels Modelfile noch zusätzlich an den Einsatz in Obsidian angepasst. Der allgemeine Befehl dazu lautet ollama create choose-a-model-name -f <location of the file e.g. ./Modelfile> und das ist mein verwendetes Modelfile

Kein Cloud-Account, keine Daten, die das eigene Gerät verlassen. So muss ich mir als Lehrer, der auch mit Schüler- und Unterrichtsdaten arbeitet, keine Sorgen bei der Verwendung von KI machen.

Warum ein Fork für Deutsch?

Das Original-Plugin ist ganz auf die Sprache Englisch ausgerichtet. Nicht nur die UI – der eigentliche Extraction-Prompt, der Herzschlag des Systems, fragte das Modell in englischen Instruktionen nach englischen Ausgaben. Für einen deutschsprachigen Vault bedeutet das: Das LLM extrahiert Entitäten und beschreibt Konzepte auf Englisch, obwohl die Quellen auf Deutsch sind. Suchen auf Deutsch finden dann nichts oder Falsches.

Noch schlimmer war aber, dass beim Aufbau der Wissensdatenbank deutsche Stoppwörter nicht ausgefiltert wurden und so alles zugemüllt wurde. Das Ergebnis war kaum brauchbar.

Ich habe deshalb llm-wiki-german als Fork gestartet – als Proof of Concept dafür, dass LLM Knowledgebases auch auf Deutsch brauchbare Ergebnisse liefern, wenn auf die Besonderheiten der Sprache Rücksicht genommen wird.

Gleichzeitig war es eine gute Gelegenheit, Vibe Coding mit der Gemini CLI auszuprobieren.

Die sprachlichen Herausforderungen

Der Extraction-Prompt auf Deutsch

Der erste und wichtigste Schritt war, den Extraction-Prompt komplett auf Deutsch umzuschreiben. Im Fork ist er jetzt vollständig auf Deutsch formuliert – von den Regeln für das Modell bis zu den JSON-Beispielen. Der Prompt instruiert das Modell explizit, die Ausgabe in der konfigurierten {output_language} zu liefern, unabhängig von der Sprache des Quelltexts. So kann man auch einen gemischten Vault (z. B. mit englischen Fachartikeln und deutschen Unterrichtsnotizen) konsistent auf Deutsch oder Englisch indexieren. Die Extraktionssprache ist inzwischen frei konfigurierbar: Deutsch, Englisch, Französisch, Spanisch, Italienisch, Niederländisch und Portugiesisch stehen zur Auswahl.

Stoppwörter und Tokenisierung

Die Keyword-Suche im Original war rein auf Englisch ausgelegt. Für den deutschen Vault musste ich die Stoppwortliste in terms.ts massiv erweitern: der, die, das, ein, eine, ist, sind, von, zu, und, oder, aber, wenn… Ohne das würden diese häufigen Wörter das Ranking dominieren und irrelevante Treffer nach oben spülen.

Morphologie: Flexion, Umlaute und Komposita

Hier liegt die eigentliche Komplexität. Das Deutsche flektiert Nomen in vier Fällen, Adjektive in drei Genera, und Verben konjugieren vielfältig. Ein einfacher Stemmer, der den Wortstamm zurückgeben soll, muss also Endungen wie -ern, -ers, -en, -er, -es, -em, -e und -n abschneiden. Dazu kommt die Umlaut-Normalisierung: ä → a, ö → o, ü → u, ß → ss. Das erlaubt es, dass eine Suche nach „Buch" auch „Bücher" findet, weil beide auf denselben Wortstamm (Stem) reduziert werden.

Noch kniffliger sind Komposita – das deutsche Spezialphänomen, beliebig lange Wörter zu bilden. „Wissensbasis", „Unterrichtsmaterial", „Schülerarbeitsblatt" sind für einen naiven Tokenizer ein einziges langes Token, das semantisch gesehen aus mehreren Konzepten besteht. Im Fork gibt es dafür eine heuristische Compound-Splitting-Funktion: Wörter ab 8 Zeichen werden an typischen Fugenmorphemen (vor allem dem Fugen-s) aufgesplittet. So wird Wissensbasis in Wissen und Basis zerlegt, und beide Teile fließen separat ins Ranking ein.

Embeddings und semantische Suche

Der semantische Teil der Suche läuft über qllama/multilingual-e5-base, mein Ersatz für nomic-embed-text, das primär auf Englisch trainiert wurde. Das mehrsprachige Embedding-Modell multilingual-e5 liefert deutlich bessere Ergebnisse für deutsche Texte.

Zusätzliche Features über das Original hinaus

Im Laufe der Entwicklung ist das Plugin deutlich über die reine Deutschsprachigkeit hinausgewachsen. Eine Auswahl der Features, die im Original nicht vorhanden sind:

Mehrere LLM-Anbieter. Neben Ollama unterstützt das Plugin jetzt OpenAI, Anthropic, Google Gemini, Mistral, LlamaCpp als lokales Backend und einen generischen OpenAI-kompatiblen Endpunkt (z. B. für LM Studio oder eigene vLLM-Server). Cloud-Anbieter sind opt-in und in den Einstellungen klar als solche gekennzeichnet – wer auf Datenschutz angewiesen ist (ich als Lehrer definitiv), bleibt einfach bei Ollama.

Multi-Folder-Index. Man kann festlegen, welche Vault-Ordner in die Wissensdatenbank einfließen. Das ist sinnvoll, wenn man z. B. nur Unterrichtsmaterialien indexieren möchte, aber nicht die privaten Tagebucheinträge.

Integritätsprüfung (Lint). Der Befehl „Wissensdatenbank aufräumen und prüfen" analysiert die gesamte kb.json auf Probleme: verwaiste Verbindungen, fehlende Quellen, doppelte Einträge, redundante Fakten. Für viele Probleme gibt es eine automatische Bereinigung – redundante Fakten werden sogar per LLM zusammengeführt.

Protokollierung. Alle Extraktionen, Dateilöschungen und Abfragen landen in wiki/log.md. So lässt sich jederzeit nachvollziehen, was mit der Wissensdatenbank passiert ist.

Inhaltsverzeichnis. In der Datei wiki/index.md sind alle Begriffe das Wikis aufgelistet und verlinkt.

Mehrere Gesprächsrunden. Chats werden gespeichert und sind fortsetzbar. Man kann ein Gespräch dort weitermachen, wo man aufgehört hat – hilfreich für längere Recherchen.

Inhaltsbasierte Deduplizierung. Die Erkennung, ob eine Notiz seit der letzten Extraktion geändert wurde, läuft jetzt über SHA-256-Hashes statt über Datei-Timestamps. Das verhindert unnötige Neu-Extraktionen, wenn z. B. iCloud oder OneDrive die Timestamps beim Sync anfasst.

Vibe Coding mit Gemini CLI / Antigravity / Cline

Ein persönlicher Bonus dieses Projekts war das Ausprobieren von Gemini CLI als Coding-Assistent. Die Kombination aus einem klar beschriebenen Problem (Deutsch-Support) und einem iterativ arbeitenden LLM-Assistenten hat gut funktioniert – besonders für die Prompt-Übersetzung und das Ausarbeiten der Stemmer-Logik. Der Ansatz zeigt, wie man ein bestehendes Open-Source-Plugin relativ schnell für die eigene Sprache adaptieren kann, ohne von Null anzufangen.

Nachdem Gemini CLI eingestellt und Antigravity im kostenfreien Betrieb nur mehr sehr eingeschränkt nutzbar wurde, wechselte ich vermehrt auf Cline - AI Coding. Was mit der Open-Source Lösung Cline und seinen frei zur Verfügung stehenden Modellen möglich ist, ist beeindruckend und war für dieses überschaubare Projekt jedenfalls eine große Hilfe.

Aktueller Stand und Ausblick

Das Plugin ist lauffähig und in meinem Vault im Einsatz. Die aktuelle Version ist 1.0.6.

Für eine erste Indexierung von ~600 Notizen muss man Geduld mitbringen – die im englischen angegebenen Zeiten (ca. 4 Stunden) werden durch die komplexeren Abläufe im Deutschen etwas verlängert. Im laufenden Betrieb werden nur geänderte Dateien neu extrahiert (erkannt via SHA-256-Hash), was in Sekunden erledigt ist. Für vollständige Aktualisierungen gibt es optional einen nächtlichen Planer.

Befehle

Der Quellcode liegt offen auf github.com/matheharry/llm-wiki-german. Wer ebenfalls einen deutschen Obsidian-Vault hat und LLM Wiki ausprobieren will, ist herzlich eingeladen, mitzumachen – Issues, PRs und Erfahrungsberichte sind willkommen.