Deploy mindnet to llm-node / deploy (push) Successful in 4s

Details

01_knowledge_design update mit overrides

2025-12-17 10:31:09 +01:00

9.3 KiB

Raw Blame History

doc_type	audience	scope	status	version	context
user_manual	user, author	vault, markdown, schema	active	2.7.0	Regelwerk für das Erstellen von Notizen im Vault. Die 'Source of Truth' für Autoren.

Knowledge Design Manual

Quellen: knowledge_design.md, types.yaml

⚡ Die 5 Goldenen Regeln (TL;DR)

Damit Mindnet als dein Digitaler Zwilling funktioniert, beachte beim Schreiben diese Grundsätze:

Atomare Gedanken: Eine Notiz = Ein Thema. Wenn du über zwei Projekte schreibst, mach zwei Notizen draus.
Explizite Typen: Setze immer den type im Frontmatter. Mindnet behandelt eine decision ("Wir machen X") völlig anders als ein concept ("Was ist X").
Semantische Links: Schreibe nicht nur [[Link]], sondern [[rel:depends_on Link]]. Sag dem System wie Dinge zusammenhängen.
Werte & Ziele definieren: Damit die Decision Engine dich beraten kann, musst du deine Kriterien (type: value, type: goal) explizit als Notizen anlegen.
Emotionales Bridging: Damit die Empathie funktioniert, nutze in Erfahrungsberichten (type: experience) emotionale Schlüsselwörter ("Krise", "Freude", "Angst").

1. Zweck & Scope

Mindnet ist mehr als eine Dokumentablage. Es ist ein vernetztes System, das deine Persönlichkeit abbildet. Die Markdown-Dateien in deinem Vault sind die einzige Quelle der Wahrheit ("Source of Truth"). Was nicht im Markdown steht, existiert für das System nicht.

2. Note-Struktur & Frontmatter

Jede Notiz benötigt einen YAML-Header (Frontmatter).

Pflichtfelder:

---
id: 20251212-projekt-alpha     # Eindeutige Kennung (YYYYMMDD-slug empfohlen)
title: Projekt Alpha           # Sprechender Titel
type: project                  # Steuert Chunking & Wichtigkeit
status: active                 # active, archived, draft
created: 2025-12-12            # ISO 8601
tags: [ki, entwicklung]        # Taxonomie
---

2.1 Advanced Overrides: Die KI-Steuerung übernehmen

In 95% der Fälle setzt der type (z.B. "concept") automatisch die richtigen Einstellungen. In Spezialfällen kannst du diese manuell im Frontmatter überschreiben, um das Verhalten der KI zu erzwingen.

A. `retriever_weight`: Die Sichtbarkeit steuern

Dieser Faktor (Default: 1.0) ist ein Multiplikator für das Ranking in der Vektorsuche. Er entscheidet, welche Notiz "gewinnt", wenn zwei Texte inhaltlich ähnlich sind.

Standard (1.0): Normale Wichtigkeit.
Boost (1.2 - 2.0): "Das hier ist die Wahrheit."
- Einsatz: Finale Entscheidungen, Kernprinzipien, die "Single Source of Truth".
- Effekt: Verdrängt weniger wichtige Notizen (z.B. Meeting-Protokolle) aus dem Kontext-Fenster der KI.
Deboost (0.5 - 0.8): "Nur Kontext, keine Fakten."
- Einsatz: Glossare, externe Quellen (source), reine Datensammlungen.
- Effekt: Die Notiz wird nur gefunden, wenn man sehr spezifisch danach sucht.

B. `chunking_profile`: Die Zerstückelung steuern

Das Profil bestimmt, wie der Text für die Datenbank zerschnitten wird. Falsches Chunking zerreißt den Kontext. Wähle das Profil basierend auf der Struktur deines Textes.

Profil-Name	Strategie	Einsatzzweck & Wirkung
`sliding_standard`	Sliding Window	Der Allrounder. Für Fließtexte (Tagebuch, Artikel). Der Text wird in überlappende Fenster geschnitten. Gut, wenn der Inhalt von oben nach unten fließt.
`sliding_short`	Sliding Window (Klein)	Für Dichte. Für Texte mit sehr hoher Informationsdichte (Glossare, Task-Listen), wo jeder Satz wichtig ist. Erzeugt viele kleine Chunks.
`sliding_smart_edges`	Sliding + AI	Der Intelligente. Wie Standard, aber das LLM analysiert jeden Chunk zusätzlich auf implizite Querverweise. Standard für `concept` und `project`.
`structured_smart_edges`	Heading Split (Soft)	Für Strukturierte Texte. Trennt an Überschriften (H2). Besonderheit: Wenn ein Abschnitt sehr kurz ist, wird er mit dem nächsten verschmolzen ("Soft Mode"), um den Kontext zu wahren.
`structured_smart_edges_strict`	Heading Split (Hard)	Für Listen & Kataloge. Trennt zwingend an jeder H2-Überschrift. Verhindert das Verschmelzen. Wichtig für: `decision` (Option A darf nicht mit Option B verschmelzen), `value`, `profile`.

Beispiel für ein Override:

---
title: Sammlung meiner Passwörter-Regeln
type: list
# Wir erzwingen eine strikte Trennung, damit Regel 1 nicht mit Regel 2 vermischt wird.
chunking_profile: structured_smart_edges_strict
# Extrem wichtig, soll immer beachtet werden.
retriever_weight: 1.5
---

3. Typ-Referenz & Verhalten

Wähle den Typ, der die Rolle der Notiz am besten beschreibt. Der Typ setzt die Defaults für die oben genannten Parameter.

Typ	Default Profil	Default Gewicht	Einsatzzweck
`concept`	`sliding_smart_edges`	0.60	Fachbegriffe, Theorien. Zeitloses Wissen.
`project`	`sliding_smart_edges`	0.97	Aktive Vorhaben mit Ziel und Status.
`experience`	`sliding_smart_edges`	0.90	Persönliche Lektionen (für Empathie).
`decision`	`structured_..._strict`	1.00	Entscheidungen. Muss atomar getrennt sein (Optionen vs. Ergebnis).
`value`	`structured_..._strict`	1.00	Werte/Prinzipien.
`principle`	`structured_..._strict_L3`	0.95	Handlungsleitlinien (Trennt bis Ebene H3).
`goal`	`sliding_smart_edges`	0.95	Strategische Ziele.
`risk`	`sliding_short`	0.85	Risiken (kurz und prägnant).
`journal`	`sliding_standard`	0.80	Zeitbezogene Logs.
`source`	`sliding_standard`	0.50	Externe Quellen (niedrig gewichtet).

4. Edges & Verlinkung

Mindnet versteht Zusammenhänge durch Kanten.

4.1 Inline-Relationen (Semantische Verknüpfung)

Dies ist die mächtigste Methode. Du sagst dem System explizit, wie Dinge zusammenhängen.

"Daher rel:depends_on Qdrant." "Dieses Konzept ist rel:similar_to Pinecone."

Gültige Relationen:

depends_on: Hängt ab von / Benötigt.
blocks: Blockiert oder gefährdet (z.B. Risiko -> Projekt).
caused_by: Wurde verursacht durch (Kausalität).
similar_to: Ähnelt / Ist vergleichbar mit.
solves: Löst (Problem).
based_on: Basiert auf (Fundament).

4.2 Callout-Edges

Für Zusammenfassungen am Ende einer Notiz:

> [!edge] related_to: [[Vector Embeddings]] [[AI Agents]]

5. Schreiben für den KI-Zwilling (Szenarien)

Damit der RAG-Chat dich berät, musst du "Futter" für die Decision Engine liefern.

Szenario A: Decision Engine (`DECISION`)

Ziel: Das System soll abwägen: "Passt Tool X zu mir?"
Vorgehen: Erstelle Notizen mit type: value oder type: goal.

Beispiel Notiz:

---
type: value
title: Prinzip: Datensparsamkeit
---
Wir speichern nur das Minimum an Daten. Cloud-Uploads persönlicher Daten sind verboten, es sei denn, sie sind E2E-verschlüsselt.

Effekt: Wenn du fragst "Soll ich Notion nutzen?", lädt die Engine diese Notiz und antwortet: "Nein, Notion ist SaaS ohne E2E. Das verletzt dein Prinzip der Datensparsamkeit."

Szenario B: Empathie (`EMPATHY`)

Ziel: Das System soll dich verstehen.
Vorgehen: Erstelle type: experience mit emotionalen Brückenwörtern.

Beispiel Notiz:

---
type: experience
title: Erfahrung: Der Durchbruch nach der Krise
tags: [krise, hoffnung, grau, angst]
---
Es gibt Projektphasen, da wirkt alles **sinnlos** und **grau**.
Ich habe gelernt: Das ist oft das Zeichen kurz vor dem Durchbruch.

Effekt: Bei "Alles ist grau" findet das System diese Notiz und spiegelt die Lektion zurück.

6. Best Practices & Beispiele

6.1 Beispiel: Projekt-Notiz (Standard)

Projekte profitieren von depends_on, um Abhängigkeiten zu klären.

---
id: 20251115-proj-mindnet
title: Mindnet Implementierung
type: project
status: active
---

# Mindnet Implementierung

Wir bauen ein persönliches Wissensnetz.

## Tech Stack
Wir nutzen [[rel:depends_on Qdrant]] für die Vektorsuche und [[rel:depends_on FastAPI]] für das Backend.

## Architektur
Das Konzept basiert auf [[RAG Architecture]].

6.2 Beispiel: Advanced Tuning (Manuelles Override)

Hier zwingen wir das System, eine Entscheidung extrem kleinteilig (strict) zu zerlegen und in der Suche maximal zu priorisieren.

---
id: 20251120-adr-vektordb
title: ADR: Wahl von Qdrant
type: decision
status: final
tags: [architektur, db]
# OVERRIDES: Wir wollen diese Notiz extrem wichtig machen und strikt trennen.
# Da "strict" genutzt wird, landet "Alternativen" in einem eigenen Chunk 
# und vermischt sich nicht mit der Entscheidung selbst.
chunking_profile: structured_smart_edges_strict
retriever_weight: 1.5
---

# Entscheidung: Qdrant

Wir haben uns für Qdrant entschieden.

## Alternativen
Wir haben auch [[rel:similar_to Pinecone]] und [[rel:similar_to Weaviate]] betrachtet.

7. Virtual Schema Layer

Grundsätzlich gilt das Prinzip des Virtual Schema Layers. Die Logik (wie chunk_size) wird zentral in der types.yaml verwaltet. Aber: Als Power-User hast du über die oben genannten Overrides (chunking_profile) jederzeit die Möglichkeit, aus diesem Standard auszubrechen, wenn eine spezifische Notiz eine Sonderbehandlung benötigt.

9.3 KiB Raw Blame History