RAG für eine Obsidian-Wissensdatenbank: Technische Ansätze

Der Nutzer verfügt über eine Obsidian-Wissensdatenbank, in der Markdown-Dateien mit typisierten Inhalten (FileClasses wie Person, Projekt, Deliverable etc.) verwaltet werden. Die Notizen enthalten strukturierte YAML-Metadaten (unterstützt durch Plugins wie Metadata Menu) und sind durch viele Wiki-Links miteinander vernetzt. Standardisierte Templates (via Templater) sorgen dafür, dass z.B. Personenseiten immer ähnliche Felder (Name, ORCID, etc.) aufweisen.

Ziel ist es, mithilfe eines Language Models (LLM) wiederkehrende Aufgaben zu erleichtern, zum Beispiel: automatisch YAML-Felder ausfüllen (etwa fehlende ORCID iDs bei Personen ergänzen), neue Entitätsseiten anhand von Templates befüllen oder sinnvolle Verlinkungen zwischen Notizen vorschlagen. Dabei reicht ein tägliches Neu-Einlesen der Obsidian-Daten (via Cronjob o.Ä.) aus – eine Echtzeit-Synchronisation ist optional. Die Obsidian-internen Wikilinks ([[...]]) müssen im LLM-Ausgabeformat nicht unbedingt klickbar sein (es genügt, wenn sie referenziert werden).

Um diese Funktionen umzusetzen, bieten sich verschiedene technische Ansätze an. Im Folgenden werden fünf Optionen untersucht: (1) Nutzung eines Vektorspeichers für semantische Suche, (2) Aufbau eines Knowledge Graph aus den Notizen, (3) eine Hybrid-Lösung aus Graph und Vektor, (4) Extraktion & Normalisierung der YAML-Metadaten und (5) existierende Tools/Workflows zur Automatisierung. Jede Option wird mit Funktionsweise, Vorund Nachteilen, Aufwand, Integrationsmöglichkeiten (insb. mit lokalen LLMs wie LLaMA, Deepseek, Cogito etc.) sowie konkreten Tool-Empfehlungen dargestellt.

1. Vektorbasierter Ansatz: Semantic Search mit Embeddings

Prinzip

Alle Markdown-Notizen (bzw. deren Inhalt) werden in kleinere Chunks zerlegt und durch einen Embedding-Modell in hochdimensionale Vektoren umgewandelt. Diese Vektoren werden in einem Vektorstore (wie ChromaDB oder Weaviate) gespeichert. Bei Anfragen des LLM (z.B. “Welche Projekte hat Person X?” oder “Erstelle eine neue Organisation XYZ basierend auf ähnlichen Einträgen”), können mittels ähnlichkeitssuche semantisch passende Notiz-Abschnitte abgerufen und dem LLM als Kontext mitgegeben werden (Retrieval-Augmented Generation).

Implementierung

In der Praxis ließe sich z.B. ein Workflow mit Ollama + Nomic Embeddings + Chroma¹ aufbauen. Ollama stellt ein lokales LLM-Serving bereit und bietet auch eine API für Embeddins [1]. Man könnte ein spezialisiertes Embeddin-Modell wie nomic-embed-text verwenden, welches kompakte 1024-dimensionale Textvektoren liefert [1]. Die Notizen des Obsidian Vault würden per Skript täglich eingelesen, in Sinnabschnitte (Chunks) aufgeteilt (z.B. nach Überschriften oder einer festen Token-Länge) und über Ollamas Embedding-API in Vektoren umgewandelt [1]. Diese Vektoren speichert man in einer lokalen DB wie Chroma. Anfragen an das LLM werden dann zunächst an den Vektorstore gestellt, um die relevantesten Notiz-Abschnitte zu finden, welche dann zusammen mit der eigentlichen Frage an das LLM gegeben werden (klassischer RAG-Pipeline). Dieses Verfahren ist vergleichbar mit dem Smart Connections Obsidian-Plugin: Dort wird ebenfalls ein “Text Embedding Model” auf den Vault angewendet, um zu einer Nutzerfrage automatisch thematisch passende Notizen zu finden und dem LLM bereitzustellen [2]. So konnte im Beispiel ein lokales LLaMA-basiertes Modell Fragen zum eigenen Vault korrekt beantworten, indem es zuvor den passenden Ausschnitt (hier: eine Styleguide-Notiz) über Embeddings gefunden hatte [2].

¹ Alle diese Teile laufen bereits individuell in der Arbeitsgruppe bzw. werden schon genutzt.

Integration mit lokalen LLMs

Ein Vorteil dieses Ansatzes ist, dass er schon heute mit lokalen Open-Source-LLMs funktioniert. Beispielsweise ließ sich in Smart Connections ein lokal gehostetes LLaMA-Model (3B Instruct) via text-generation-webui einbinden [2]. Alternativ kann man auch LLM-as-a-service Tools wie Ollama nutzen, um ein Modell wie Llama 2 bereitzustellen. Die Open-Source-Tools LangChain oder LlamaIndex bieten Module, um Vektorstores anzubinden und mit LLM-Abfragen zu kombinieren – dies kann man auch mit lokal eingebundenen Modellen (z.B. über LlamaCpp oder GPT4All) verwenden. Zahlreiche fertige Projekte demonstrieren dieses Vorgehen: z.B. privateGPT kombiniert LangChain, GPT4All (lokales LLM) und Chroma, um komplett offline Fragen über lokale Dateien zu beantworten [3]. Auch Khoj verfolgt einen ähnlichen Pfad: Es indexiert den Vault und erlaubt semantische Natürliche Sprache Suche über Markdown-Inhalte sowie “ähnliche Notizen finden” [4].

Leistung

Dank moderner Embedding-Modelle können semantisch ähnliche Inhalte gefunden werden, selbst wenn die Schlagwörter nicht exakt übereinstimmen. Das löst das in Obsidian bekannte Problem, dass die eingebaute Suche nur exakte Worttreffer findet [5]. Der Ansatz skaliert auch auf größere Wissensbasen; Vektordatenbanken wie Weaviate oder Chroma sind für zehntausende Einträge ausgelegt. Eine tägliche Aktualisierung ist machbar, da nur neue/geänderte Notizen re-embedded werden müssen.

Nachteile und Aufwand

Die Einrichtung erfordert mehrere Komponenten. Man benötigt Pipeline-Schritte für das Chunking, Embedding und das Handling des Vektorstores – dies bedeutet anfängliche Komplexität und Rechenaufwand [5]. Insbesondere das Generieren der Embeddings kann bei großen Vaults zeitund speicherintensiv sein (je nach Modell und Hardware) [5]. Laufende Kosten sind bei rein lokaler Verarbeitung allerdings kein Thema außer CPU/GPU-Last. Ein potenzieller Nachteil ist, dass rein embeddings-basierte Suche keine strukturierte Abfrage erlaubt – das Modell findet zwar thematisch passende Textpassagen, aber um z.B. eine bestimmte Eigenschaft (wie eine fehlende ORCID) gezielt abzufragen, müsste man dennoch im Text suchen oder zusätzliche Logik anwenden. Das LLM kann aus den gefundenen Texten zwar implizit Fakten entnehmen, hat aber kein explizites Wissen über die Datenstruktur. Zudem können irrelevante Kontextstücke eingebunden werden, wenn das semantische Matching fehlerhaft ist (dies erfordert ggf. Feintuning der Chunk-Größe oder Filtern per Dateityp/-klasse)².

² Und diese Nachteile machen dies zu einem Deal-Breaker. Gerade in Tabellen oder Auflistungen kann der Attention-Mechanismus der LLM schnell zu einem Mischen oder Verwechseln von präsentierten Informationen führen. Besonders kleine Netze (meist bis ~7b) sind hier anfällig.

Zusammenfassung – Ansatz 1: Vektordatenbank (Embeddings)

	Details
Vorgehen	Inhalte aller Markdown-Dateien in semantische Vektoren kodieren (z.B. mit `nomic-embed-text` ([1])) und in einer Vektor-DB speichern. LLM-Anfragen per Similarity Search mit relevantem Kontext anreichern.
Stärken	Semantische Suche (findet thematisch passende Infos, nicht nur exakte Worttreffer) [5]. Skaliert auf große Textmengen. Bereits heute mit lokalen LLMs erprobt (z.B. Smart Connections Plugin) [2]. Gut geeignet für Q&A, Textzusammenfassungen und Link-Vorschläge basierend auf Ähnlichkeit.
Schwächen	Komplexeres Setup (Embedding-Model + DB + Pipeline) [5]. Hoher Rechenaufwand für Embeddings bei großen Vaults. Kein explizites Modell von Beziehungen/Metadaten – strukturierte Abfragen (z.B. “zeige alle Personen ohne ORCID”) nur mit Zusatzlogik. Kontexttreffer können ungenau sein (erfordert ggf. Feinjustierung).
Integrations-Optionen	Lokale LLM-Einbindung möglich (z.B. LLaMA 2 über Ollama-API). Tools: ChromaDB, Weaviate oder FAISS als Vektorstore; LangChain/LlamaIndex für Pipeline-Management. Obsidian-Plugins: Smart Connections (komplett integriert mit lokalem Embedder+LLM) [2]; Khoj (separater Suchassistent mit Embeddings) [4].

graph LR
    A[Obsidian Vault] --> B[Chunking]
    B --> C[Embedding Model]
    C --> D[(Vector Database)]
    E[User Query] --> F[Query Embedding]
    F --> G[Similarity Search]
    D --> G
    G --> H[Relevant Chunks]
    H --> I[LLM]
    E --> I
    I --> J[Response]

2. Knowledge-Graph-Ansatz: Strukturierte Graphdatenbank

Prinzip

Statt (oder zusätzlich zu) freiem Text wird der Informationsgehalt des Vaults als Graph modelliert. Jede Notiz entspricht einem Knoten im Graphen (mit Typ-Label gemäß FileClass, z.B. Person, Projekt etc.). Relationen zwischen Notizen – implizit durch Obsidian-Wikilinks gegeben – werden zu expliziten Kanten im Graph (z.B. eine Person “arbeitet in” Organisation, ein Projekt “liefert” ein Deliverable). Auch Metadaten aus YAML können als Knoten oder Properties modelliert werden (z.B. ORCID als Attribut eines Person-Knotens, Tags als Relationen “hat Schlagwort” usw.). Das Ergebnis ist ein Wissensgraph, der ähnlich einem klassischen RDF-Triple-Store oder Neo4j-Property-Graph komplexe Abfragen und Analysen ermöglicht.

Erstellung des Graphen

Eine Möglichkeit ist die Obsidian-Daten nach RDF zu exportieren. So beschreibt Pavlyshyn (2023) ein Verfahren, einen Vault ins RDF-Format zu überführen, um “komplexe Abfragen mit klassischen Semantic-Tools” zu ermöglichen [6]. Alternativ kann man direkt in einer Graphdatenbank wie Neo4j modellieren. Ein Community-Plugin (obsidian-neo4j-stream) hat beispielsweise versucht, den Obsidian-Linkgraph in Neo4j importierbar zu machen [7]. Konkret würde man pro Markdown-Datei einen Node mit dessen YAML-Feldern als Properties anlegen. Bestehende Wiki-Links zwischen Dateien werden als ungerichtete oder gerichtete Edges abgebildet (hier kann man, sofern man mehr Semantik will, Link-Typen einführen – z.B. im Text [[Albert Einstein|Autor]] könnte der Alias “Autor” als Kanten-Label genutzt werden). Da Obsidian standardmäßig keine typisierten Kanten unterstützt, bleiben Relationstypen begrenzt – Plugins wie Juggl oder Graph-Link-Types erlauben allerdings das Hinzufügen von Link-Metadaten, was für eine genauere Graph-Modellierung hilfreich sein könnte [8]. YAML-Inhalte, die auf andere Notizen referenzieren, können ebenfalls als Kanten kodiert werden (Beispiel: In einer Projekt-Notiz listet das YAML-Feld team: mehrere Personen – diese Verweise werden im Graph als Kanten Projekt —hatTeam→ Person umgesetzt). Nicht referenzielle Metadaten (etwa ein ORCID-Wert) bleiben einfach als Datenfeld am Knoten.

Nutzung für LLM-Aufgaben

Ein solcher Graph erlaubt strukturierte Abfragen und Schlussfolgerungen. Für wiederkehrende Aufgaben kann man den Graph gezielt auswerten. Beispielsweise ließen sich “alle Personen ohne ORCID” mittels einer einfachen Graph-Query ermitteln. Das LLM könnte diese Liste als Input erhalten und dann (ggf. mittels Tools oder Wissensbasis) die fehlenden IDs ergänzen. Auch Link-Vorschläge können aus dem Graph gezogen werden: Durch Graph-Analysen wie das Finden von gemeinsamen Nachbarn oder kürzesten Pfaden entdeckt man Verbindungen, die im Vault noch nicht als direkte Links existieren. So könnte man z.B. feststellen, dass zwei Personen an vielen gleichen Meetings teilgenommen haben und dem Nutzer vorschlagen, diese Personen direkt miteinander zu verknüpfen. Oder man erkennt durch link prediction Algorithmen neue mögliche Beziehungen. Forschung und Community sehen hier großes Potential: Eine AI-gestützte Graphanalyse kann helfen, verborgene Zusammenhänge im eigenen Zettelkasten zu finden [9]. Mit Graph-basiertem Reasoning ließe sich sogar neues Wissen entdecken oder logisch konsistente Antworten generieren [8] – etwas, das rein embeddings-basierte Ansätze so nicht leisten.

Integration mit LLMs

Die Integration eines Graphen erfordert meist eine Zwischenschicht. Ein LLM kann nicht direkt “in” einer Neo4j-Datenbank suchen, aber man kann ihm eine Schnittstelle anbieten. Zwei Strategien sind denkbar:

Verbalize & Prompt: Informationen aus dem Graph gezielt ins Prompt einbetten. Z.B. könnte man bei einer Frage wie “In welcher Organisation arbeitet Alice?” erst eine Graphdatenbank-Anfrage (z.B. in Cypher oder SPARQL) ausführen und das Ergebnis (etwa: “Alice – arbeitetBei → AcmeCorp”) in Textform dem Modell vorgeben, bevor es antwortet. Solche Abfragen könnte ein LLM theoretisch sogar selbst generieren (LangChain bietet z.B. Agents, die Cypher-Queries formulieren und ausführen können). Für definierte Use-Cases kann man aber auch feste Query-Vorlagen verwenden.
LLM-in-the-Loop Graph Reasoning: Neuere Libraries wie LlamaIndex ermöglichen es, LLMs als Reasoner über Graphen einzusetzen. Der Graph wird dabei intern z.B. als Tripel-Liste gehalten, und das LLM kann mittels promptbasierter Logik Kettenschlüsse durchführen. Allerdings muss der Graph dafür in das Prompt passen (bei sehr vielen Knoten unrealistisch) – es ist also eher für Teilgraphen oder summarische Beziehungen geeignet³.

³ Via ‘Tool Use’ in Modernen LLM könnte das LLM selbst eine Suche auslösen und so den Teilgraphen wählen. Aber alleine die formulierung der Suche führt dann direkt zu dem hybriden Ansatz unten.

Eine andere interessante Möglichkeit ist die Nutzung graphbasierter KI-Modelle (Graph Neural Networks o.ä.), die aber in unserem Kontext (persönlicher Vault) noch experimentell sind. Erwähnenswert ist z.B. MyKin.ai, ein Projekt, das einen privaten KI-Assistenten baut, der gemeinsam mit dem Nutzer einen persönlichen Wissensgraphen aufbaut und nutzt [8]. Hier übernimmt die KI das “heavy lifting” der Graph-Pflege, während der Nutzer chattet – ein hybrider Ansatz aus Conversation und Graphaufbau. Für unseren Anwendungsfall wäre jedoch eher ein statischer Graph sinnvoll, den wir periodisch aktualisieren.

Zusammenfassung - Ansatz 2: Graphdatenbank

	Details
Vorgehen	Konvertiere Vault-Inhalte in einen strukturierten Graphen (Knoten = Notizen/Entitäten; Kanten = Obsidian-Links oder abgeleitete Relationen). Nutzen von Graph-DB (Neo4j, RDF-Store) für Abfragen und Analysen.
Stärken	Explizite Struktur: ermöglicht genaue Abfragen, z.B. Finde fehlende Werte oder alle Verknüpfungen eines Knotens auf einen Blick. Logische Inferenzen möglich (Graph Reasoning) – unterstützt Link-Empfehlungen und Konsistenzprüfungen [8]. Gute Ergänzung zu YAML-Typisierung: FileClass-Struktur wird vollständig nutzbar. Persistenz: Graph kann unabhängig von Obsidian analysiert, versioniert, mit anderen Daten gemappt werden (z.B. ORCID-Abgleich via externen Datensatz).
Schwächen	Erheblicher Initialaufwand: Datenmodell entwerfen, Export-Skripte schreiben oder Tools einrichten [7]. Keine fertige Out-of-the-box-Lösung für Obsidian↔︎Graph (bislang nur Ansätze in der Community). Laufende Synchronisation nötig (Vault-Änderungen -> Graph-Update). Die LLM-Integration ist komplexer – erfordert Query-Tool oder das Einbetten von Graph-Daten ins Prompt. Für offene Fragen (Freitext) allein nicht ausreichend, da der Graph primär Fakten repräsentiert, nicht Fließtext.
Integrations-Optionen	Neo4j (mit APOC/Neosemantics für RDF-Unterstützung) eignet sich für Property-Graph-Modell; Apache Jena oder GraphDB für RDF-Triple-Store. LangChain bietet Memory/Agent, um Wissensgraphen abzufragen (z.B. ConversationKGMemory). LlamaIndex hat einen KnowledgeGraphIndex, der Tripel extrahieren und durchs LLM traversieren kann. Diese Lösungen sind aber noch experimentell. Evtl. Kombination mit Obsidian-Plugin: Ein früher Plugin-Prototyp streamte Obsidian-Daten nach Neo4j [7] – dieser könnte als Ausgangspunkt dienen.

graph LR
    A[Obsidian Vault] --> B[Entity Extraction]
    A --> C[Relationship Extraction]
    B --> D[Graph Construction]
    C --> D
    D --> E[(Graph Database)]
    F[User Query] --> G[Query Parser]
    G --> H[Graph Traversal]
    E --> H
    H --> I[Structured Facts]
    I --> J[LLM]
    F --> J
    J --> K[Response]

Fazit Graphdatenbank

Ein Wissensgraph spielt seine Stärken vor allem bei strukturbezogenen Aufgaben aus. Für das automatische Ausfüllen von YAML-Feldern oder das Prüfen von Verlinkungen ist er ideal, da solche Fragen direkte Graphabfragen ermöglichen. Auch für neuartige Verknüpfungen (Link-Vorschläge) lässt sich ein Graph analytisch nutzen (z.B. “Link Prediction” auf Basis von Graph-Nachbarschaft). Allerdings ist die Umsetzung deutlich komplexer als beim Vektorstore, und viele RAG-Anwendungsfälle (Zusammenfassungen, inhaltliche Q&A) erfordern trotzdem den Rückgriff auf die eigentlichen Texte – was wiederum den Vektoransatz benötigt. Daher bietet sich oft eine Kombination beider Methoden an.

3. Hybrid-Ansatz: Kombination aus Graph und Vektor-RAG

Dieser Ansatz versucht, semantische Textsuche und strukturierte Graph-Abfragen zu vereinen, um die Vorteile beider Welten auszuschöpfen. In der Praxis gibt es mehrere Möglichkeiten, wie ein hybrides System ausgestaltet sein kann:

Parallelbetrieb mit separaten Pipelines: Vektorstore und Knowledge Graph werden beide gepflegt. Je nach Anfrage oder Teilaufgabe wird das eine oder andere genutzt. Beispiel: Für eine Q&A-Frage holt das System erst relevante Text-Passagen via Vektorstore, und prüft zusätzlich im Graph, welche Entitäten darin vorkommen und ruft deren Beziehungen ab. Das LLM bekäme dann sowohl inhaltliche Ausschnitte als Kontext als auch strukturierte Fakten (z.B. “Alice arbeitetBei AcmeCorp”) als Knowledge-Panel. Für die Aufgabe Link-Vorschläge könnte das System sowohl einen Embedding-Vergleich zwischen Notizen nutzen (um thematisch ähnliche Notes zu finden), als auch den Graphen auswerten (um strukturell nahe, aber unverbundene Knoten zu entdecken). Die finalen Vorschläge wären die Schnittmenge bzw. Union beider Methoden – das erhöht Präzision und Reichweite der Empfehlungen.
Integration innerhalb einer Datenplattform: Moderne Vector-Datenbanken wie Weaviate erlauben es, semantische Vektorsuche mit symbolischen Filtern zu kombinieren. Man kann Objekte (hier: Notizen) mit ihren strukturierten Feldern in Weaviate speichern und neben dem Vektorindex auch die Metadaten abfragen. Z.B. könnte man eine Query formulieren: “Gib mir die 5 ähnlichsten Notizen zu [Text], die vom Typ Projekt sind und nach 2020 erstellt wurden.” – Weaviate würde erst nach Ähnlichkeit filtern, dann die Metadaten-Bedingungen anwenden. So eine hybride Suche könnte man nutzen, um etwa bei Template-Befüllung nur vergleichbare Objekte zum Prompt hinzuzufügen (z.B. nur andere Organisationen, keine Meeting-Notizen). Auch ChromaDB arbeitet an Feature-Filterfunktionen, die so etwas erlauben würden. Alternativ kann man den Graphen selbst mit Vektor-Embeddings anreichern: Man könnte jedem Knotentyp einen eigenen Vektor zuordnen, der den gesamten Inhalt der zugehörigen Notiz(en) repräsentiert. Diese Vektoren ließen sich im Graphen als Attribut halten und für Ähnlichkeitssuchen zwischen Knoten verwenden (knowledge graph embeddings). Allerdings ist das experimentell – man müsste z.B. bei Kanten-Traversierung dynamisch Nachbarschaftsvektoren kombinieren, was nicht trivial ist.
LLM als Orchestrator: Hier steuert das LLM, wann welcher Ansatz gezogen wird. Beispielsweise könnte man ein System bauen, in dem das LLM zunächst entscheidet: “Brauche ich strukturiertes Wissen?” Wenn ja, könnte es per Tool-Use einen Graph-Query durchführen (z.B. via Cypher) – eine Technik, die mit LangChain Agents umsetzbar wäre. Danach würde es ggf. einen zweiten Schritt machen: “Benötige ich noch Detailinformationen oder Zitate?” – dann die Vektor-Datenbank abfragen, relevante Textstücke holen, und schließlich alles in einer konsolidierten Antwort formulieren. Dieser agentenbasierte Ansatz ist sehr flexibel, aber auch am anspruchsvollsten in der Implementierung (er erfordert zuverlässig trainierte/verfeinerte LLM-Prompts, die wissen, wann und wie die jeweiligen Werkzeuge zu benutzen sind).

Vor-/Nachteile

Die Hybridlösung verspricht maximale Abdeckung der Anwendungsfälle. Strukturierte Fakten und unstrukturierte Inhalte können gemeinsam dem LLM präsentiert werden, was sowohl präzise Faktenkenntnis als auch reichhaltigen Kontext ermöglicht. Gerade für komplexe Aufgaben – etwa das automatisierte Erstellen einer neuen Entitätenseite – wären wohl beide Aspekte wichtig: das LLM müsste sich an vorhandenen ähnlichen Seiten inhaltlich orientieren (Vektorsuche nach ähnlichen Organisations-Beschreibungen) und zugleich korrekte Verknüpfungen setzen (Graph checken, ob z.B. die neue Organisation bereits Personen im Vault hat, die als Mitarbeiter verknüpft werden sollten). Ein solches System könnte also dem Nutzer sehr viel Arbeit abnehmen und dabei konsistente, vernetzte Notizen erzeugen.

Dem steht jedoch ein hoher Architekturund Wartungsaufwand gegenüber. Man muss im Grunde zwei Systeme aufbauen und aktuell halten. Zudem ist die Logik, wie die Ergebnisse zusammenfließen, nicht trivial. Ohne gutes Design kann es passieren, dass der Graph-Teil und der Vektor-Teil widersprüchliche oder redundante Informationen liefern. Auch muss man Performance beachten – doppelte Abfragen kosten mehr Zeit. In vielen Fällen mag auch ein einzelner Ansatz ausreichen, sodass die Zusatzkomplexität nicht immer gerechtfertigt ist.

Integrationsmöglichkeiten

Auf technischer Seite ist so ein hybrides System durchaus machbar. Beispielsweise ließe sich LlamaIndex verwenden, um unterschiedliche Indexe (VectorIndex, KnowledgeGraphIndex) zu kombinieren – es gibt Konzepte wie “Composable Indices”, mit denen man hierarchische Abfragen bauen kann. So könnte man erst den Graph nach relevanten Knoten filtern und dann nur die zugehörigen Dokumente vektor-suchen (oder umgekehrt). Weaviate als All-in-one-Lösung wurde bereits erwähnt. In kleineren Umgebungen kann man auch pragmatisch vorgehen: Ein Python-Skript, das bei bestimmten Fragen zuerst einen Neo4j-Query absetzt und dessen Ergebnis dem LLM als Teil des Prompts voranstellt, während es parallel eine Chroma-Query macht, wäre eine einfache implementierbare Variante.

Zusammenfassung – Ansatz 3: Hybrid-Lösung

	Details
Vorgehen	Kombination beider Ansätze: Pflege einer Graph-Struktur und eines Vektorindex. Nutzung je nach Bedarf – entweder separat oder durch orchestrierte Abfragen, um sowohl strukturiertes Wissen als auch relevante Texte bereitzustellen.
Stärken	Sehr leistungsfähig – deckt sowohl faktische als auch kontextuelle Fragen ab. Kann die höchste Antwortqualität liefern (Konsistenz durch Graph-Fakten, Detail durch Textauszüge). Hilft, sowohl “Known-item” Suchen (explizite Werte) als auch “Open-ended” Suchen (Texte) zu bedienen. Für Link-Vorschläge ideal: Kombination aus semantischer Ähnlichkeit und Graph-Nachbarschaft erhöht Trefferquote sinnvoll.
Schwächen	Sehr komplex in Umsetzung und Wartung. Erfordert doppelte Infrastruktur. Koordination zwischen Graph und Vectorstore nötig – potenziell fehleranfällig. Höhere Latenz durch Mehrfach-Abfragen. Nur lohnend, wenn wirklich vielfältige Aufgaben automatisiert werden sollen; für rein textliche Q&A overkill.
Integrations-Optionen	Weaviate (Vectors + strukturierte Class-Properties in einem System), oder Kombination aus Neo4j + Chroma. LangChain Agents könnten Graphund Vektor-Tools parallel nutzen. LlamaIndex bietet experimentell kombinierbare Indizes. Workflows müssen sorgfältig entworfen werden (z.B. zuerst Graph-Query, dann Vector-Query auf Untermenge).

graph LR
    A[Obsidian Vault] --> B[Chunking]
    A --> C[Entity Extraction]
    B --> D[Embedding Model]
    C --> E[Graph Construction]
    D --> F[(Vector Database)]
    E --> G[(Graph Database)]
    H[User Query] --> I[Query Embedding]
    H --> J[Graph Query]
    I --> K[Vector Search]
    J --> L[Graph Traversal]
    F --> K
    G --> L
    K --> M[Text Context]
    L --> N[Structured Facts]
    M --> O[Combined Context]
    N --> O
    H --> P[LLM]
    O --> P
    P --> Q[Enriched Response]

Fazit Hybrid-Lösung

Die Hybrid-Lösung ist die ambitionierteste, aber auch zukunftsträchtigste Option. Sie empfiehlt sich, wenn sowohl inhaltliche Assistenz (Texte zusammenfassen, beantworten) als auch datenbankartige Operationen (Felder validieren, Beziehungen auswerten) gefragt sind – was hier der Fall ist. Oft kann man auch schrittweise vorgehen: zunächst mit einem Vektor-RAG starten (geringerer Aufwand) und dann gezielt Graph-Features ergänzen, sobald z.B. Link-Empfehlungen oder Konsistenzprüfungen wichtiger werden.

4. Datenaufbereitung: YAML-Metadaten extrahieren und normalisieren

Unabhängig vom gewählten Retrieval-Ansatz ist es essenziell, die in YAML front matter steckenden strukturierten Informationen effektiv zu nutzen. Die Obsidian-Plugins Metadata Menu und Templater stellen sicher, dass viele wichtige Daten bereits sauber in den Notizen vorliegen (z.B. hat eine Personenseite Felder wie fullname, birthdate, ORCID usw.). Ein LLM könnte zwar theoretisch auch direkt im Markdown nach diesen Mustern suchen, aber es ist deutlich effizienter, die Daten einmalig zu extrahieren und in einer leichter nutzbaren Form vorzuhalten.

Extraktion

Ein möglicher Schritt im täglichen Refresh ist ein Skript, das alle Dateien durchläuft und die YAML-Blöcke parst (z.B. mit einem YAML-Parser in Python oder JavaScript). Die extrahierten Felder können dann in eine normale Datenbank (SQLite/CSV/JSON) oder direkt als Knoten/Properties in den Knowledge Graph überführt werden. Damit erhält man z.B. eine Tabelle aller Personen mit ihren ORCID-IDs, eine Liste aller Projekte mit Start-/Enddatum etc.

Normalisierung

Oft müssen die Rohwerte etwas vereinheitlicht werden. Beispielsweise sollten Datumsangaben ein konsistentes Format haben, Personennamen evtl. in Vor-/Nachname zerlegt, und fehlende Felder explizit als null markiert werden. Außerdem kann man hier foreign-key-Bezüge auflösen: Wenn z.B. im YAML einer Publikation author: "[[Doe, John]]" steht, könnte das Skript erkennen, dass dies die Person mit UID XYZ ist, und entsprechend in der extrahierten Struktur statt des Link-Codes einen eindeutigen Verweis (auf die Person John Doe) speichern. Diese Normalisierung erleichtert nachfolgende Analysen enorm – insbesondere kann man einfache Regeln ableiten, die dann vom LLM geprüft oder genutzt werden. Zum Beispiel: “Wenn person.ORCID leer ist, schlage vor, ihn zu ergänzen” – das kann das LLM dann direkt als Aufforderung bekommen. Oder: “Beim Erstellen einer neuen Person fülle Felder X,Y nach Vorlage aus” – hier weiß man aus der YAML-Definition bereits, welche Felder existieren müssen.

Nutzung durch LLM

Der aufbereitete YAML-Datensatz kann auf zwei Weisen eingebunden werden:

Inline im Prompt: Für bestimmte Aufgaben kann man dem LLM direkt Ausschnitte aus dieser strukturierten Sammlung geben. Etwa: “In unserer Datenbank fehlt für Person[42] der ORCID. Hier ist eine Liste aller Personennamen mit ORCID, finde anhand des Namens den passenden ORCID und trage ihn ein.” – Falls die Person woanders erwähnt wurde, könnte das Modell es herausfinden. (Eher unwahrscheinlich ohne Internetzugriff – ORCID erfordert eher einen API-Call, aber zumindest könnte das LLM erkennen, dass es fehlt und ggf. den Nutzer nach der ID fragen). Für Link-Empfehlungen könnte man dem LLM eine Liste aller Titel geben – oder besser direkt die Graph-Info wie “Person A und Person B haben 3 gemeinsame Projekte” – siehe Hybrid-Ansatz.
Programmatisch außerhalb des LLMs: Viele Routineaufgaben lassen sich erkennen, ohne das LLM zu bemühen. Man könnte einen Teil der Automatisierung rein mit Skripten vorab erledigen. Z.B. neue Links: Ein Skript könnte alle Personennamen im Fließtext durchsuchen und prüfen, ob sie bereits als [[Link]] markiert sind; wenn nicht, die Stelle hervorheben und dem LLM als “Kandidat für Verlinkung” präsentieren. Oder bei einer neuen Organisation könnten automatisch Felder aus externen APIs gezogen und ins Template eingetragen werden (sofern erlaubt). Das LLM hätte dann eher die Rolle, die zusammengestellten Infos in schönen Prosa-Text zu gießen, anstatt die Fakten selbst zu suchen.

Beispiel-Workflows

YAML-Exports lassen sich mit vorhandenen Tools unterstützen. Es gibt z.B. das Obsidian-Plugin Dataview, welches Abfragen auf YAML ermöglichen kann – allerdings nur innerhalb Obsidian. Man könnte aber ein Dataview JS-Skript⁴ schreiben, das alle Einträge eines Typs ausgibt, und diese Output-Datei dann weiterverarbeiten. Alternativ direkt auf Dateisystemebene arbeiten: Python mit os und pyyaml kann alle .md Files scannen.
Die extrahierten Daten kann man mit dem Graph-Ansatz koppeln: etwa alle Personen ohne ORCID als Cypher-Query generieren lassen und automatisch in eine “ToDo”-Liste (Obsidian Note) schreiben, die vom LLM oder Nutzer geprüft wird.
Durch Templates sind die Felder pro FileClass ja bekannt. Diese Knowledge kann ins Prompt fließen: “Eine Organisation hat die Felder Name, Typ, Beschreibung, Mitarbeiter, etc. Fülle basierend auf den folgenden Infos…” Das Modell weiß dann genau, welche YAML-Spalten es ausgeben soll.

⁴ oder Plugins wie Dataview-Publisher benutzen, die die Ergebnisse als Markdown-Tabell in ein Dokument schreiben

Vor- & Nachteile

Die Vorteile der strukturierten Extraktion liegen auf der Hand – Performance und Präzision. Man muss nicht jedes Mal den gesamten Markdown-Text durchsuchen, um z.B. den Wert eines bestimmten Feldes zu finden; man hat ihn direkt. Außerdem reduziert es die Abhängigkeit vom LLM für einfache Aufgaben (Daten finden, vergleichen). Für die meisten Menschen ist es auch leichter zu verstehen und zu prüfen, wenn man z.B. eine CSV mit allen ORCIDs hat, als wenn man dem LLM blind glauben muss.
Als Nachteil kann gesehen werden, dass es zusätzlicher Implementierungsaufwand ist und eine gewisse Duplizierung der Daten (die YAML-Inhalte leben dann in zwei Formen: im Markdown und in der extrahierten Sammlung). Die Synchronisation muss bei Änderungen immer gewährleistet sein (Cronjob). Allerdings ist das, verglichen mit dem Aufwand der LLM-Integration, relativ gering und gut automatisierbar.

graph LR
    A[Obsidian Vault] --> B[FileClass Detection]
    B --> C[Type-Specific Extraction]
    C --> D[YAML Parser]
    D --> E[Data Validation]
    E --> F[Type Normalization]
    F --> G[(Typed Collections)]
    H[Task Request] --> I[Schema Lookup]
    I --> J[Targeted Data Fetch]
    G --> J
    J --> K[Context Assembly]
    H --> K
    K --> L[LLM Processing]
    L --> M[Schema-Aware Output]

Zusammenfassung – Ansatz 4: Extraktion

In jedem Fall sollte man eine Pipeline vorsehen, die die YAML-Metadaten extrahiert und in eine strukturierte Form bringt. Diese bildet das Rückgrat für den Knowledge-Graph-Ansatz (ohne diese wären die Knoten nackte Titel ohne Attribute) und ist auch für Vektor-RAG nützlich (z.B. als Filter oder zur post-processing der LLM-Antworten). Insbesondere dank der FileClass-Typisierung im Vault kann man hier sehr zielgerichtet vorgehen – etwa nur definierte Entitätstypen verarbeiten. In Community-Diskussionen wurde vorgeschlagen, YAML-Metadaten zu nutzen, um AI-Aufgaben einzuschränken: z.B. NER-Modelle nur auf bestimmten Notizen laufen zu lassen, die laut YAML einen bestimmten Typ haben [9]. Solche Optimierungen werden durch saubere strukturelle Aufbereitung erst möglich.

5. Automatisierungstools und Workflows

Für die Umsetzung der oben beschriebenen Ansätze gibt es bereits einige Tools, Projekte und Best Practices, die man nutzen oder von denen man lernen kann. Hier eine strukturierte Übersicht samt Empfehlungen:

Obsidian-Plugins (In-App KI-Features)

Smart Connections: Plugin, das innerhalb Obsidian mit lokalen Embeddings arbeitet, um ähnliche Notizen zu finden, und einen Chatbot bereitstellt. Es kann ein lokales LLM (oder OpenAI API) einbinden und versorgt es automatisch mit Kontext aus dem Vault [2]. Vorteil: einfache Installation, enge Vault-Integration (Antworten können direkt als Notiz eingefügt werden). Nachteil: begrenzt anpassbar – der Workflow ist vordefiniert (hauptsächlich Q&A Chat). Für den Start aber exzellent, um ein Gefühl für RAG im eigenen Vault zu bekommen.
Khoj: Ein Open-Source Projekt, bestehend aus einem lokalen Backend [4] und Obsidian-Plugin. Ermöglicht natürliche Sprachsuche und Chat über die eigenen Notizen [4]. Es kann sowohl online-Modelle (GPT-4 etc.) als auch lokale Modelle nutzen [10]. Khoj fokussiert auf schnelle semantische Suche; der Chat-Teil ist vor allem QA-orientiert. Als persönlicher Suchassistent ist es sehr interessant – etwa um via Obsidian Command Palette Fragen ans Vault zu stellen. Es ist weniger darauf ausgelegt, automatisch Links zu erzeugen oder YAML zu verändern (dafür wäre wiederum ein LLM mit Schreibrechten nötig).
Obsidian Copilot / GPT-Assistant: Es existieren mehrere Plugins, die GPT-3/4 in Obsidian integrieren (teils auch lokal via LLaMA). Diese sind im Prinzip UI-Verbesserungen, um das LLM “im Editor” zu nutzen. Für RAG kann man sie einsetzen, indem man manuell Kontext reinkopiert, aber automatisches Retrieval bieten sie nicht ohne weiteres.
Obsidian Neo4j Plugin (Experimentell): Das erwähnte obsidian-neo4j-stream von @HEmile [7] könnte als Ausgangspunkt dienen, falls man die Graph-Route ausprobieren will. Es war dazu gedacht, den Vault als kontinuierlichen Stream in Neo4j zu spiegeln. Leider wurde es nicht fertiggestellt/maintained. Dennoch ließe sich der Code evtl. anpassen, um zumindest einmalig einen Export durchzuführen. Alternativ: Im Obsidian-Forum gibt es auch Beispiele, wie man mit ein paar Skriptzeilen alle Links extrahieren kann. Zusammen mit den YAML-Daten könnte man so einen Basic-Graphen schon bekommen.

Externe Anwendungen / Skripte

LlamaIndex (GPT Index): Diese Python-Bibliothek ist eine Schweizer Taschenmesser für RAG. Man kann Dokumente laden (Markdown wird unterstützt), unterschiedliche Indizes erstellen (Vector, List, KnowledgeGraph etc.) und Abfragen mit LLM orchestrieren. Sie eignet sich, um schnell Prototypen zu bauen. Beispielsweise könnte man einen KnowledgeGraphIndex erstellen, der mittels Instruct-LLM Tripel aus den Notizen extrahiert (z.B. “Person X – arbeitet für – Organisation Y”). Anschließend kann man Abfragen in natürlicher Sprache stellen, die vom LLM in Graph-Traversals übersetzt werden. Oder man nutzt den simpleren VectorIndex auf Markdown-Chunks. LlamaIndex kann auch Komposition: man könnte pro FileClass einen Index bauen (z.B. alle Personen in einem VectorIndex, alle Projekte in einem anderen) und dann einen übergeordneten Query laufen lassen. Diese Flexibilität ist mächtig – aber es erfordert eben etwas Programmierung. Für einen produktiven Workflow (täglicher Cronjob) müsste man ein eigenes Python-Skript schreiben, das die Indizes aktualisiert.
LangChain: Ein Framework v.a. für komplexere Chains und Agenten. Es liefert Bausteine, um z.B. eine Tool-using Agent zu bauen, die mit einer Vector DB Suche und einer Graph-DB Abfrage als Tools ausgestattet ist. Damit ließe sich ein Dialogsystem kreieren, das je nach Frage entscheidet, ob es den Neo4j-Graph oder den Chroma-Vektorindex konsultiert. Allerdings setzt dies einiges an Prompt Engineering voraus, damit der Agent zuverlässig funktioniert. Alternativ kann man LangChain auch einfach nutzen, um entweder Vector-search oder Graph-DB-Queries einzeln bequemer zu machen (es gibt z.B. vorgefertigte Neo4j Retriever-Klassen etc.).
Haystack: Das von deepset (evtl. in der Frage mit “Deepseek” gemeint) entwickelte Open-Source-Toolkit Haystack ist ebenfalls auf Dokumenten-QA spezialisiert. Es unterstützt das Indexieren von Markdown, verschiedene Vector-Backends und kann auch Knowledge-Graph-Komponenten integrieren. Zudem hat es Pipeline-Knoten zum z.B. Fragenklassifizieren, dass bestimmte Fragen an bestimmte Reader geleitet werden. Für einen produktiven Einsatz mit lokalem UI ggf. eine Option. Allerdings eher heavy-weight und auf QA fokussiert, weniger auf Wissensbasis-Pflege.
privateGPT / llama.cpp based scripts: Für einfache Frage-Antwort-Systeme auf dem eigenen Vault kann man vorhandene Lösungen wie privateGPT oder GPT4All (mit UI) verwenden [3]. Diese bringen einen Großteil der Vector+LLM Pipeline schon fertig mit. Sie indexieren Ordner voller Dokumente (auch Markdown) und erlauben dann Queries an ein lokales Modell. Der Anpassungsspielraum (z.B. andere Tasks als reines QA) ist aber gering. Als Baseline sind sie nützlich – man könnte damit z.B. testen, wie gut ein LLM mit den eingebetteten Obsidian-Notizen Fragen beantwortet, und daraus Anforderungen ableiten.
Basic Memory (basicmachines): Ein innovativer Ansatz ist hier zu erwähnen: Basic Memory speichert AI-Konversationen als Markdown in Obsidian und baut daraus sukzessive einen semantischen Wissensgraph [11]. D.h. wenn man mit dem LLM chatbasiert arbeitet, erstellt das Tool automatisch Notizen und verbindet sie (z.B. werden erkannte Entitäten verlinkt). Es ist quasi das Gegenstück zu unserem Problem – statt einen bestehenden Vault zu nutzen, erzeugt es einen Vault. Dennoch kann man sich dort Konzepte abschauen: z.B. wie strukturierte Notizen aus LLM-Ausgaben generiert werden können, oder wie man bi-direktional arbeitet (User editiert Notiz, KI liest Änderungen beim nächsten Mal). Basic Memory setzt auf lokale Dateien und betont Privatsphäre, was dem hiesigen Anforderungsprofil ähnelt. Für die konkreten Aufgaben (ORCID-Suche, Link-Vorschlag) liefert es zwar keine fertige Lösung, aber die Idee, KI beim Nutzer Notizen anlegen/ändern zu lassen, ist hier praktisch umgesetzt.
Externe APIs / Datenquellen:
Für bestimmte Felder wie ORCID wird ein rein lokales LLM kaum die Werte erraten können, sofern sie nicht schon irgendwo im Vault stehen. Falls Internetzugriff eine Option ist, könnte man ein Plugin oder einen Workflow integrieren, der ORCID API Abfragen durchführt (z.B. über den Namen der Person) und die ID zurückliefert. Ein LLM-Agent könnte auch so einen API-Call ausführen (via Tools in LangChain). Alternativ: Alle bekannten ORCID-IDs der eigenen Personen könnte man in einer Datei sammeln; wenn das LLM eine Lücke findet, bittet es den Nutzer um Input. Hier muss man die Limitierungen eines LLM realistisch sehen und ggf. klassische Automatisierung (API-Skripte) kombinieren.

graph LR
    subgraph Obsidian
    A[Vault] --> B[Plugins]
    B --> C[Templater]
    B --> D[Metadata Menu]
    B --> E[AI Assistant]
    end

    subgraph External Processing
    A --> F[Daily Export]
    F --> G[Data Processing]
    G --> H[LLM Analysis]
    H --> I[Automation Scripts]
    end

    subgraph Integration
    I --> J[Change Proposals]
    J --> K[User Review]
    K --> L[Accepted Changes]
    L --> M[Vault Updates]
    M --> A
    end

Zusammenfassende Empfehlung

Für einen ersten Prototypen empfiehlt es sich, mit dem Vektorstore-Ansatz (1) zu beginnen, da dieser am schnellsten sichtbare Erfolge bringt. Man kann z.B. mit ChromaDB + einem lokalen LLM experimentieren, oder direkt das Smart-Connections-Plugin ausprobieren, um ein Gefühl für semantische Suche im Vault zu bekommen. Die YAML-Daten sollte man von Anfang an mit-extrahieren (4), da sie die Grundlage für weitere Strukturierungsmaßnahmen bilden. Anschließend kann man gezielt Graph-Features (2) ergänzen: etwa den exportierten Vault in Neo4j laden und ein paar Abfragen formulieren, um Missing Links oder fehlende Felder aufzuspüren. Mittelfristig dürfte eine Kombination (3) notwendig sein, um sowohl Inhalt als auch Struktur abzudecken – dies kann man Schritt für Schritt angehen (z.B. zunächst Vector-RAG für inhaltliche Fragen, und separate Tools/Reports für strukturierte Checks; später dann Integration zu einem einheitlichen KI-Assistenten). Unterstützend sollte man vorhandene Tools (5) nutzen, wo möglich – z.B. Khoj für ad-hoc Fragen, oder LlamaIndex für schnelle Implementierung von Prototypen. Generell gilt: lokale LLMs sind inzwischen leistungsfähig genug für solche Aufgaben, wie die genannten Beispiele zeigen (Chat mit Vault über LLaMA etc.). Wichtig ist es, die Vault-Organisation konsequent weiterzuführen (FileClasses, Templates), da ein sauber strukturiertes Wissen die Grundlage für jede erfolgreiche RAG-Lösung ist – egal ob Vektor, Graph oder hybrid.

Quellen

Die Analyse basiert auf aktuellen Erkenntnissen aus der Obsidian-Community und KI-Fachwelt, u.a. Erfahrungen mit semantischer Suche [2], Diskussionen zu Knowledge Graphs in PKM [9] und Berichten über lokale RAG-Implementierungen [2].

Methodik / LLMs als ‘Autoren’

Erstellt wurde der initial draft mittels Websuche und “Deep-Research” von gpt-4.5 (preview). Systematische Überarbeitungen (Extraktion Bibliographie, Überarbeitung Metadaten) mittels cogito-v0.1 im Editor. Übernahme nach manueller Prüfung. Erstellung der Mermaid-Diagramme mittels Claude 3.7 Sonnet. Abschließendes Korrekturlesen/inhaltliche Prüfung/Layouting durch Nicole Dresselhaus.