Lars/mindnet
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 21 Wiki Activity

doku

Browse Source
This commit is contained in:
Lars 2025-12-19 09:02:49 +01:00
parent 0d71f41a13
commit 2cd3605017
8 changed files with 334 additions and 263 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
app/services/edge_registry.py
View File

@ -31,7 +31,7 @@ class EdgeRegistry:
settings = get_settings()
env_vocab_path = os.getenv("MINDNET_VOCAB_PATH")
env_vault_root = os.getenv("MINDNET_VAULT_ROOT") or getattr(settings, "MINDNET_VAULT_ROOT", "./vault_master")
env_vault_root = os.getenv("MINDNET_VAULT_ROOT") or getattr(settings, "MINDNET_VAULT_ROOT", "./vault")
if env_vocab_path:
self.full_vocab_path = os.path.abspath(env_vocab_path)

49
docs/00_General/00_glossary.md
View File

@ -2,43 +2,40 @@
doc_type: glossary
audience: all
status: active
version: 2.6.0
context: "Definitionen zentraler Begriffe und Entitäten im Mindnet-System."
version: 2.7.0
context: "Zentrales Glossar für Mindnet v2.7. Definitionen von Entitäten, WP-22 Scoring-Konzepten und der Edge Registry."
---
# Mindnet Glossar
**Quellen:** `appendix.md`, `Overview.md`
**Quellen:** `01_edge_vocabulary.md`, `retriever_scoring.py`, `edge_registry.py`
## Kern-Entitäten
* **Note:** Repräsentiert eine Markdown-Datei. Die fachliche Haupteinheit.
* **Chunk:** Ein Textabschnitt einer Note. Die technische Sucheinheit (Vektor). Durch neue Strategien kann dies ein Fließtext-Abschnitt oder ein logisches Kapitel (Heading) sein.
* **Edge:** Eine gerichtete Verbindung zwischen zwei Knoten (Chunks oder Notes).
* **Note:** Repräsentiert eine Markdown-Datei. Die fachliche Haupteinheit. Verfügt über einen **Status** (stable, draft, system), der das Scoring beeinflusst.
* **Chunk:** Ein Textabschnitt einer Note. Die technische Sucheinheit (Vektor).
* **Edge:** Eine gerichtete Verbindung zwischen zwei Knoten. Wird in WP-22 durch die Registry validiert.
* **Vault:** Der lokale Ordner mit den Markdown-Dateien (Source of Truth).
* **Frontmatter:** Der YAML-Header am Anfang einer Notiz (enthält `id`, `type`, `title`).
* **Frontmatter:** Der YAML-Header am Anfang einer Notiz (enthält `id`, `type`, `title`, `status`).
## Komponenten
* **Importer:** Das Python-Skript (`import_markdown.py`), das Markdown liest und in Qdrant schreibt.
* **Retriever:** Die Komponente, die sucht. Nutzt hybrides Scoring (Semantik + Graph).
* **Decision Engine:** Teil des Routers, der entscheidet, wie auf eine Anfrage reagiert wird (z.B. Strategie wählen).
* **Hybrid Router v5:** Die Logik, die erkennt, ob der User eine Frage stellt (`RAG`) oder einen Befehl gibt (`INTERVIEW`).
* **Draft Editor:** Die Web-UI-Komponente, in der generierte Notizen bearbeitet werden.
* **Traffic Control (WP15):** Ein Mechanismus im `LLMService`, der Prioritäten verwaltet (`realtime` für Chat vs. `background` für Import) und Hintergrund-Tasks mittels Semaphoren drosselt.
* **Edge Registry:** Der zentrale Dienst (SSOT), der Kanten-Typen validiert und Aliase in kanonische Typen auflöst. Nutzt `01_edge_vocabulary.md` als Basis.
* **Retriever:** Besteht in v2.7 aus der Orchestrierung (`retriever.py`) und der mathematischen Scoring-Engine (`retriever_scoring.py`).
* **Decision Engine:** Teil des Routers, der Intents erkennt und entsprechende **Boost-Faktoren** für das Retrieval injiziert.
* **Traffic Control:** Verwaltet Prioritäten und drosselt Hintergrund-Tasks (z.B. Smart Edges) mittels Semaphoren.
* **Unknown Edges Log:** Die Datei `unknown_edges.jsonl`, in der das System Kanten-Typen protokolliert, die nicht im Dictionary gefunden wurden.
## Konzepte & Features
* **Active Intelligence:** Feature im Web-Editor, das während des Schreibens automatisch Links vorschlägt.
* **Smart Edge Allocation (WP15):** Ein KI-Verfahren, das prüft, ob ein Link in einer Notiz für einen spezifischen Textabschnitt relevant ist, statt ihn blind allen Chunks zuzuordnen.
* **Strict Heading Split:** Chunking-Strategie, bei der Überschriften (z.B. H2) als harte Grenzen dienen. Verhindert das Vermischen von Themen (z.B. zwei unterschiedliche Rollen in einem Chunk). Besitzt ein "Safety Net" für zu lange Abschnitte.
* **Soft Heading Split:** Chunking-Strategie, die Überschriften respektiert, aber kleine Abschnitte zusammenfasst, um Vektor-Kontext zu füllen ("Fuller Chunks").
* **Healing Parser:** UI-Funktion, die fehlerhaften Output des LLMs (z.B. defektes YAML) automatisch repariert.
* **Explanation Layer:** Die Schicht, die dem Nutzer erklärt, *warum* ein Suchergebnis gefunden wurde (z.B. "Weil Projekt X davon abhängt").
* **Provenance:** Die Herkunft einer Kante.
* `explicit`: Vom Mensch geschrieben.
* `smart`: Vom LLM validiert.
* `rule`: Durch Config-Regel erzeugt.
* **Matrix Logic:** Regelwerk, das den Typ einer Kante basierend auf Quell- und Ziel-Typ bestimmt (z.B. Erfahrung -> Wert = `based_on`).
* **Idempotenz:** Die Eigenschaft des Importers, bei mehrfacher Ausführung dasselbe Ergebnis zu liefern ohne Duplikate.
* **Resurrection Pattern:** UI-Technik, um User-Eingaben beim Tab-Wechsel zu erhalten.
* **Canonical Type:** Der standardisierte System-Name einer Kante (z.B. `based_on`), der in der Datenbank gespeichert wird.
* **Alias (Edge):** Ein nutzerfreundliches Synonym (z.B. `basiert_auf`), das während der Ingestion automatisch zum Canonical Type aufgelöst wird.
* **Lifecycle Scoring (WP-22):** Ein Mechanismus, der die Relevanz einer Notiz basierend auf ihrem Status gewichtet (z.B. Bonus für `stable`, Malus für `draft`).
* **Intent Boosting:** Dynamische Erhöhung der Kanten-Gewichte basierend auf der Nutzerfrage (z.B. Fokus auf `caused_by` bei "Warum"-Fragen).
* **Provenance Weighting:** Gewichtung einer Kante nach ihrer Herkunft:
* `explicit`: Vom Mensch gesetzt (Prio 1).
* `smart`: Von der KI validiert (Prio 2).
* `rule`: Durch System-Regeln/Matrix erzeugt (Prio 3).
* **Smart Edge Allocation:** KI-Verfahren zur Relevanzprüfung von Links für spezifische Textabschnitte.
* **Strict Heading Split:** Chunking-Strategie mit harten Grenzen an Überschriften und integriertem "Safety Net" gegen zu große Chunks.
* **Matrix Logic:** Bestimmung des Kanten-Typs basierend auf Quell- und Ziel-Entität (z.B. Erfahrung -> Wert = `based_on`).

104
docs/02_concepts/02_concept_graph_logic.md
View File

@ -3,13 +3,13 @@ doc_type: concept
audience: architect, product_owner
scope: graph, logic, provenance
status: active
version: 2.6
context: "Fachliche Beschreibung des Wissensgraphen: Knoten, Kanten, Provenance und Matrix-Logik."
version: 2.7.0
context: "Fachliche Beschreibung des Wissensgraphen: Knoten, Kanten, Provenance, Matrix-Logik und WP-22 Scoring-Prinzipien."
---
# Konzept: Die Graph-Logik
**Quellen:** `mindnet_functional_architecture.md`, `chunking_strategy.md`
**Quellen:** `mindnet_functional_architecture.md`, `chunking_strategy.md`, `01_edge_vocabulary.md`, `retriever_scoring.py`, `03_tech_retrieval_scoring.md`
Mindnet ist keine reine Dokumentablage, sondern ein **semantischer Graph**. Dieses Dokument beschreibt, wie aus statischen Textdateien ein vernetztes Wissensobjekt wird.
@ -19,7 +19,7 @@ Der Graph besteht aus zwei Ebenen von Knoten.
### 1.1 Die Note (Das Fachobjekt)
Eine Note repräsentiert ein atomares Konzept (z.B. "Projekt Alpha").
* **Eigenschaften:** Titel, Typ, Tags, Erstellungsdatum.
* **Eigenschaften:** Titel, Typ, Tags, Erstellungsdatum sowie der **Status** (Lifecycle).
* **Rolle:** Sie ist der Container für Metadaten und steuert via `type`, wie der Inhalt verarbeitet wird (siehe `types.yaml`).
* **Identität:** Definiert durch eine deterministische UUIDv5.
@ -29,71 +29,97 @@ Da LLMs (Large Language Models) nicht unendlich viel Text auf einmal lesen könn
* **Rolle:** Dies sind die eigentlichen Treffer bei einer Suche.
* **Hierarchie:** Jeder Chunk gehört streng zu einer Note (`belongs_to`).
### 1.3 Content Lifecycle & Status (WP-22)
Seit v2.7 beeinflusst der `status` einer Note direkt deren Gewichtung im Retrieval (Lifecycle Scoring).
* **Stable:** Notizen mit `status: stable` erhalten einen positiven Modifier (Standard: 1.0), da sie geprüftes Wissen repräsentieren.
* **Draft:** Notizen mit `status: draft` werden durch einen Malus (Standard: 0.5 - 0.8) herabgestuft, um "Rauschen" durch unfertige Gedanken zu reduzieren.
* **System/Template:** Diese Status-Typen führen zu einem vollständigen Ausschluss aus dem Index.
---
## 2. Die Kanten (Edges)
Kanten machen aus isolierten Informationen Wissen. Mindnet nutzt gerichtete Kanten mit semantischer Bedeutung.
Kanten machen aus isolierten Informationen Wissen. Mindnet nutzt gerichtete Kanten mit semantischer Bedeutung, die durch die **Edge Registry** validiert werden.
### 2.1 Semantische Typen
### 2.1 Kanonische Typen & Aliase
Um eine konsistente mathematische Gewichtung zu garantieren, werden alle Kanten auf **kanonische Typen** normalisiert.
| Kanten-Typ | Frage, die er beantwortet | Beispiel |
| Kanonischer Typ | Aliase (Beispiele) | Bedeutung |
| :--- | :--- | :--- |
| `references` | Worüber wird gesprochen? | Text erwähnt "Python". |
| `depends_on` | Was ist Voraussetzung? | Projekt braucht "Budget". |
| `caused_by` | Warum ist das passiert? | Bug durch "Commit X". |
| `blocks` | Was steht im Weg? | Risiko blockiert "Release". |
| `based_on` | Worauf fußt das? | Erfahrung basiert auf "Wert Y". |
| `derived_from` | Woher kommt das? | Prinzip stammt aus "Buch Z". |
| `related_to` | Was ist ähnlich? | "Hund" ist verwandt mit "Wolf". |
| `solves` | Was ist die Lösung? | "Qdrant" löst "Vektorsuche". |
| `caused_by` | `ausgelöst_durch`, `wegen` | Kausalität: A löst B aus. |
| `derived_from` | `abgeleitet_von`, `quelle` | Herkunft: A stammt von B. |
| `based_on` | `basiert_auf`, `fundament` | Fundament: B baut auf A auf. |
| `solves` | `löst`, `fix_für` | Lösung: A ist Lösung für Problem B. |
| `part_of` | `teil_von`, `cluster` | Hierarchie: Kind -> Eltern. |
| `depends_on` | `braucht`, `requires` | Abhängigkeit: A braucht B. |
| `blocks` | `blockiert`, `risiko_für` | Blocker: A verhindert B. |
| `related_to` | `siehe_auch`, `kontext` | Lose Assoziation. |
### 2.2 Provenance (Herkunft & Vertrauen)
Nicht alle Kanten sind gleich viel wert. Mindnet unterscheidet in v2.6 drei Qualitätsstufen (**Provenance**), um Konflikte aufzulösen.
Nicht alle Kanten sind gleich viel wert. Mindnet unterscheidet drei Qualitätsstufen (**Provenance**), um bei der Berechnung des Edge-Bonus Prioritäten zu setzen.
**1. Explicit (Der Mensch hat es gesagt)**
* *Quelle:* Inline-Links (`[[rel:...]]`) oder Wikilinks im Text.
* *Vertrauen:* **Hoch (1.0)**.
* *Bedeutung:* Dies ist hartes Faktenwissen. "Ich habe diesen Link bewusst gesetzt."
* *Bedeutung:* Hartes Faktenwissen. Die explizite menschliche Intention wird im Scoring am stärksten gewichtet.
**2. Smart (Die KI hat es bestätigt)**
* *Quelle:* Smart Edge Allocation (WP15).
* *Vertrauen:* **Mittel (0.9)**.
* *Bedeutung:* Ein LLM hat geprüft, ob der Link im Kontext dieses Textabschnitts wirklich relevant ist. Dies filtert "Rauschen" heraus (z.B. Links im Footer, die nichts mit dem Absatz zu tun haben).
* *Bedeutung:* Ein LLM hat die Relevanz des Links im Kontext geprüft. Dies filtert irrelevante Links (z.B. aus Navigationsleisten) heraus.
**3. Rule (Die Regel hat es vermutet)**
* *Quelle:* `types.yaml` Defaults.
* *Quelle:* `types.yaml` Defaults oder Matrix-Logik.
* *Vertrauen:* **Niedrig (0.7)**.
* *Bedeutung:* Eine Heuristik. "Weil es ein Projekt ist, nehmen wir an, dass es von allen erwähnten Technologien abhängt."
* *Bedeutung:* Systemseitige Heuristik. Diese Verbindungen dienen der Entdeckung neuer Pfade, haben aber weniger Gewicht als explizite Links.
---
## 3. Matrix-Logik (Kontext-Sensitivität)
Mit WP11 wurde eine Intelligenz eingeführt, die Kanten-Typen nicht nur anhand des Quell-Typs, sondern auch anhand des Ziel-Typs bestimmt ("Matrix").
Die Matrix-Logik bestimmt Kanten-Typen dynamisch anhand der Quell- und Ziel-Typen der verknüpften Notizen.
**Logik-Beispiele:**
* **Quelle `experience` → Ziel `value`**
* *Standard:* `references`
* *Matrix:* `based_on` (Erfahrungen basieren auf Werten).
* **Quelle `principle` → Ziel `source` (Buch)**
* *Standard:* `references`
* *Matrix:* `derived_from` (Prinzipien stammen aus Quellen).
* **Quelle `project` → Ziel `tool`**
* *Standard:* `references`
* *Matrix:* `uses` (Projekte nutzen Tools).
*Nutzen:* Dies erlaubt im Chat präzise Fragen wie: *"Auf welchen Werten basiert diese Entscheidung?"* (Suche nach eingehenden `based_on` Kanten).
* **Quelle `experience` → Ziel `value`**: Wird zu `based_on` (Erfahrungen fußen auf Werten).
* **Quelle `principle` → Ziel `source`**: Wird zu `derived_from` (Prinzipien stammen aus Quellen).
---
## 4. Idempotenz & Konsistenz
## 4. Semantisch bezogene Booster & Scoring-Logik
Das Scoring in Mindnet v2.7 folgt einer hybriden Logik, bei der semantische Ähnlichkeit durch kontextuelle Faktoren modifiziert wird.
### 4.1 Semantische Modifikatoren (Type & Status)
Bevor der Graph-Bonus berechnet wird, durchläuft die semantische Ähnlichkeit (Cosine Similarity) zwei Filter:
1. **Type-Weight ($W_{type}$):** Bestimmt die "Wichtigkeit" einer Notizklasse. Ein Wert von 1.0 (z. B. für `decision`) lässt die volle semantische Stärke durch. Ein Wert von 0.4 (z. B. für `glossary`) dämpft den Treffer massiv ab, es sei denn, die Frage passt exakt auf den Text.
2. **Status-Modifier:** Agiert als Qualitätsfilter. `draft` markierte Inhalte werden herabgestuft, damit `stable` Inhalte bei gleicher semantischer Passung immer oben stehen.
### 4.2 Graph-Boosting (Additive Boni)
Der Graph-Bonus wird auf den modifizierten semantischen Score addiert. Dies ermöglicht es Inhalten, im Ranking nach oben zu steigen, wenn sie stark mit anderen relevanten Treffern vernetzt sind.
| Parameter-Gruppe | Wertebereich | Logik |
| :--- | :--- | :--- |
| **Notiz-Gewichte** | 0.1 - 1.0 | Multiplikativ. Dient als Relevanz-Filter für Informationstypen. |
| **Kanten-Boosts** | 0.1 - 3.0+ | Additiv. Hebt vernetztes Wissen über isolierte Texttreffer. |
| **Status-Malus** | 0.5 - 0.9 | Multiplikativ. Bestraft unfertiges Wissen (Drafts). |
---
## 5. Dynamic Intent Boosting (WP-22)
In v2.7 ist die Graph-Gewichtung nicht mehr statisch, sondern hängt vom **Intent** der Nutzerfrage ab (Query-Time Boosting).
Der Intent-Router injiziert spezifische Multiplikatoren für kanonische Typen:
* **Intent `EMPATHY`**: Boostet `based_on` (Fokus auf Werte).
* **Intent `WHY`**: Boostet `caused_by` (Fokus auf Ursachenforschung).
---
## 6. Idempotenz & Konsistenz
Das System garantiert fachliche Konsistenz auch bei mehrfachen Importen.
* **Stabile IDs:** Importiert man dieselbe Datei zweimal, ändern sich die IDs der Knoten nicht.
* **Keine Duplikate:** Kanten werden dedupliziert. Die "stärkere" Quelle (Explicit > Smart > Rule) gewinnt.
* **Lösch-Garantie:** Wenn eine Notiz gelöscht wird, verschwinden auch alle ihre Chunks und ausgehenden Kanten (via `--sync-deletes`).
* **Stabile IDs:** Deterministische IDs verhindern Duplikate bei Re-Imports.
* **Deduplizierung:** Kanten werden anhand ihrer Identität erkannt. Die "stärkere" Provenance gewinnt.

146
docs/03_Technical_References/03_tech_configuration.md
View File

@ -1,19 +1,19 @@
---
doc_type: technical_reference
audience: developer, admin
scope: configuration, env
scope: configuration, env, registry, scoring
status: active
version: 2.7.0
context: "Referenztabellen für Umgebungsvariablen und YAML-Konfigurationen."
version: 2.7.2
context: "Umfassende Referenztabellen für Umgebungsvariablen, YAML-Konfigurationen und die Edge Registry Struktur."
---
# Konfigurations-Referenz
Dieses Dokument beschreibt die Steuerungsdateien von Mindnet.
Dieses Dokument beschreibt alle Steuerungsdateien von Mindnet. In der Version 2.7 wurde die Konfiguration professionalisiert, um die Edge Registry und dynamische Scoring-Parameter (Lifecycle & Intent) zu unterstützen.
## 1. Environment Variablen (`.env`)
Diese Variablen steuern die Infrastruktur, Timeouts und Feature-Flags.
Diese Variablen steuern die Infrastruktur, Pfade und globale Timeouts.
| Variable | Default | Beschreibung |
| :--- | :--- | :--- |
@ -21,6 +21,8 @@ Diese Variablen steuern die Infrastruktur, Timeouts und Feature-Flags.
| `QDRANT_API_KEY` | *(leer)* | Optionaler Key für Absicherung. |
| `COLLECTION_PREFIX` | `mindnet` | Namensraum für Collections (erzeugt `{prefix}_notes` etc). |
| `VECTOR_DIM` | `768` | **Muss 768 sein** (für Nomic Embeddings). |
| `MINDNET_VOCAB_PATH` | *(Pfad)* | **Neu (WP-22):** Absoluter Pfad zur `01_edge_vocabulary.md`. Definiert den Ort des Dictionarys. |
| `MINDNET_VAULT_ROOT` | `./vault` | Basis-Pfad für Datei-Operationen. Dient als Fallback-Basis, falls `MINDNET_VOCAB_PATH` nicht gesetzt ist. |
| `MINDNET_TYPES_FILE` | `config/types.yaml` | Pfad zur Typ-Registry. |
| `MINDNET_RETRIEVER_CONFIG`| `config/retriever.yaml`| Pfad zur Scoring-Konfiguration. |
| `MINDNET_DECISION_CONFIG` | `config/decision_engine.yaml` | Pfad zur Router & Intent Config. |
@ -30,9 +32,8 @@ Diese Variablen steuern die Infrastruktur, Timeouts und Feature-Flags.
| `MINDNET_OLLAMA_URL` | `http://127.0.0.1:11434`| URL zum LLM-Server. |
| `MINDNET_LLM_TIMEOUT` | `300.0` | Timeout in Sekunden (Erhöht für CPU Cold-Starts). |
| `MINDNET_API_TIMEOUT` | `300.0` | Frontend Timeout (Erhöht für Smart Edge Wartezeiten). |
| `MINDNET_LLM_BACKGROUND_LIMIT`| `2` | **Traffic Control (Neu):** Max. parallele Import-Tasks (Semaphore). |
| `MINDNET_VAULT_ROOT` | `./vault` | Pfad für Write-Back Operationen (Drafts). |
| `MINDNET_CHANGE_DETECTION_MODE` | `full` | **Change Detection (Neu):** `full` (Text + Meta) oder `body` (nur Text). |
| `MINDNET_LLM_BACKGROUND_LIMIT`| `2` | **Traffic Control:** Max. parallele Hintergrund-Tasks (Semaphore). |
| `MINDNET_CHANGE_DETECTION_MODE` | `full` | `full` (Text + Meta) oder `body` (nur Text). |
---
@ -42,102 +43,119 @@ Steuert das Import-Verhalten, Chunking und die Kanten-Logik pro Typ.
### 2.1 Konfigurations-Hierarchie (Override-Logik)
Seit Version 2.7.0 gilt für `chunking_profile` und `retriever_weight` folgende Priorität:
1. **Frontmatter (Höchste Prio):** Ein Wert direkt in der Markdown-Datei überschreibt alles.
* *Beispiel:* `chunking_profile: structured_smart_edges_strict` im Header einer Notiz erzwingt diesen Splitter, egal welcher Typ eingestellt ist.
2. **Type Config:** Der Standardwert für den `type` (z.B. `concept`) aus `types.yaml`.
2. **Type Config:** Der Standardwert für den `type` aus `types.yaml`.
3. **Global Default:** Fallback aus `defaults` in `types.yaml`.
### 2.2 Typ-Referenztabelle
### 2.2 Typ-Referenztabelle (Vollständig)
| Typ (`type`) | Chunk Profile (Standard) | Retriever Weight | Smart Edges? | Beschreibung |
| Typ (`type`) | Chunk Profile (Standard) | Retriever Weight ($W_{type}$) | Smart Edges? | Beschreibung |
| :--- | :--- | :--- | :--- | :--- |
| **concept** | `sliding_smart_edges` | 0.60 | Ja | Abstrakte Begriffe. |
| **project** | `sliding_smart_edges` | 0.97 | Ja | Aktive Vorhaben. |
| **decision** | `structured_smart_edges_strict` | 1.00 | Ja | Entscheidungen (ADRs). Atomar. |
| **experience** | `sliding_smart_edges` | 0.90 | Ja | Persönliche Learnings. |
| **journal** | `sliding_standard` | 0.80 | Nein | Logs / Dailies. |
| **value** | `structured_smart_edges_strict` | 1.00 | Ja | Werte/Prinzipien. Atomar. |
| **decision** | `structured_strict` | 1.00 | Ja | Entscheidungen. Atomar. |
| **value** | `structured_strict` | 1.00 | Ja | Werte/Prinzipien. Atomar. |
| **project** | `sliding_smart` | 0.97 | Ja | Aktive Vorhaben. |
| **experience** | `sliding_smart` | 0.90 | Ja | Persönliche Learnings. |
| **concept** | `sliding_smart` | 0.60 | Ja | Abstrakte Begriffe. |
| **principle** | `structured_L3` | 0.95 | Nein | Prinzipien (Tiefer Split). |
| **belief** | `sliding_short` | 0.90 | Nein | Glaubenssätze. |
| **risk** | `sliding_short` | 0.90 | Nein | Risiken. |
| **journal** | `sliding_standard` | 0.80 | Nein | Logs / Dailies. |
| **person** | `sliding_standard` | 0.50 | Nein | Profile. |
| **source** | `sliding_standard` | 0.50 | Nein | Externe Quellen. |
| **event** | `sliding_standard` | 0.60 | Nein | Meetings. |
| **goal** | `sliding_smart_edges` | 0.95 | Nein | Strategische Ziele. |
| **belief** | `sliding_short` | 0.90 | Nein | Glaubenssätze. |
| **profile** | `structured_smart_edges_strict` | 0.70 | Nein | Rollenprofile. Strict Split. |
| **principle** | `structured_smart_edges_strict_L3`| 0.95 | Nein | Prinzipien. Tiefer Split (H3) für Mikro-Prinzipien. |
| **task** | `sliding_short` | 0.80 | Nein | Aufgaben. |
| **glossary** | `sliding_short` | 0.40 | Nein | Begriffsdefinitionen. |
| **default** | `sliding_standard` | 1.00 | Nein | Fallback. |
| **default** | `sliding_standard` | 1.00 | Nein | Fallback für alle anderen. |
*Hinweis: `Smart Edges?` entspricht dem YAML-Key `enable_smart_edge_allocation: true`.*
*Richtwert für $W_{type}$: 0.1 (minimale Relevanz/Filter) bis 1.0 (maximale Relevanz).*
---
## 3. Retriever Config (`retriever.yaml`)
Steuert die Gewichtung der Scoring-Formel (WP04a).
**Beispielkonfiguration:**
Steuert die Gewichtung der Scoring-Formel und die neuen Lifecycle-Modifier.
```yaml
scoring:
semantic_weight: 1.0 # Basis-Relevanz (Cosine Similarity)
edge_weight: 0.7 # Einfluss des Graphen (Bonus)
centrality_weight: 0.5 # Einfluss von Hubs
centrality_weight: 0.5 # Einfluss von Hubs (Zentralität)
# WP-22 Lifecycle Modifier (Multiplikativ auf Semantik)
lifecycle_weights:
stable: 1.2 # Bonus: Geprüftes Wissen wird 20% höher gewichtet
draft: 0.5 # Malus: Entwürfe werden auf 50% gedämpft
system: 0.0 # Ausschluss aus dem Index
# Kanten-spezifische Basis-Gewichtung (Ohne Intent-Boost)
edge_weights:
# Multiplikatoren für den Edge-Bonus
depends_on: 1.5 # Harte Abhängigkeiten stark gewichten
blocks: 1.5 # Risiken stark gewichten
caused_by: 1.2 # Kausalitäten stärken
related_to: 0.5 # Weiche Themen schwächer gewichten
blocks: 1.5 # Blocker/Risiken stark gewichten
caused_by: 1.2 # Kausalitäten moderat stärken
based_on: 1.3 # Werte-Bezug stärken
related_to: 0.5 # Weiche Assoziation schwächen
references: 0.8 # Standard-Referenzen
based_on: 1.3 # Werte-Bezug
```
---
## 4. Edge Typen Referenz
## 4. Edge Typen & Registry Referenz
Definiert die Semantik der `kind`-Felder in der Edge-Collection.
Die `EdgeRegistry` ist die **Single Source of Truth** für das Vokabular.
| Kind | Symmetrisch? | Herkunft (Primär) | Bedeutung |
### 4.1 Dateistruktur & Speicherort
Die Registry erwartet eine Markdown-Datei an folgendem Ort:
* **Standard-Pfad:** `<MINDNET_VAULT_ROOT>/01_User_Manual/01_edge_vocabulary.md`.
* **Custom-Pfad:** Kann via `.env` Variable `MINDNET_VOCAB_PATH` überschrieben werden.
### 4.2 Aufbau des Dictionaries (Markdown-Schema)
Die Datei muss eine Markdown-Tabelle enthalten, die vom Regex-Parser gelesen wird.
**Erwartetes Format:**
```markdown
| System-Typ (Canonical) | Erlaubte Aliasse (User) | Beschreibung |
| :--- | :--- | :--- |
| **`based_on`** | `basiert_auf`, `fundament` | Fundament: B baut auf A auf. |
| **`caused_by`** | `ausgelöst_durch`, `wegen` | Kausalität: A löst B aus. |
```
**Regeln für die Spalten:**
1. **Canonical:** Muss fett gedruckt sein (`**type**` oder `**`type`**`). Dies ist der Wert, der in der DB landet.
2. **Aliasse:** Kommagetrennte Liste von Synonymen. Diese werden beim Import automatisch zum Canonical aufgelöst.
3. **Beschreibung:** Rein informativ für den Nutzer.
### 4.3 Verfügbare Kanten-Typen (System-Standard)
| Kind (Canonical) | Symmetrisch? | Herkunft | Bedeutung |
| :--- | :--- | :--- | :--- |
| `references` | Nein | Wikilink | Standard-Verweis. "Erwähnt X". |
| `references` | Nein | Wikilink | Standard-Verweis ("Erwähnt X"). |
| `belongs_to` | Nein | Struktur | Chunk gehört zu Note. |
| `next` / `prev` | Ja | Struktur | Lesereihenfolge. |
| `depends_on` | Nein | Inline / Default | Harte Abhängigkeit. |
| `related_to` | Ja | Callout / Default | Thematische Nähe. |
| `similar_to` | Ja | Inline | Inhaltliche Ähnlichkeit. |
| `caused_by` | Nein | Inline | Kausalität. |
| `solves` | Nein | Inline | Lösung für ein Problem. |
| `blocks` | Nein | Inline | Blockade / Risiko. |
| `derived_from` | Nein | Matrix | Herkunft (z.B. Prinzip -> Buch). |
| `based_on` | Nein | Matrix | Fundament (z.B. Erfahrung -> Wert). |
| `uses` | Nein | Matrix | Nutzung (z.B. Projekt -> Tool). |
| `caused_by` | Nein | Inline | Kausalität: A löst B aus. |
| `based_on` | Nein | Matrix | Fundament: A fußt auf B. |
| `blocks` | Nein | Inline | Blocker: A verhindert B. |
| `solves` | Nein | Inline | Lösung: A ist Lösung für Problem B. |
| `next` / `prev` | Ja | Struktur | Sequenzielle Lesereihenfolge. |
---
## 5. Decision Engine (`decision_engine.yaml`)
Steuert den Hybrid Router (WP06). Definiert, welche Keywords welche Strategie auslösen.
Steuert den Hybrid Router und das dynamische Intent-Boosting (WP-22).
**Beispielauszug:**
**Beispielauszug für Intent-Boosting:**
```yaml
# Strategie-Definitionen
strategies:
DECISION:
description: "Hilfe bei Entscheidungen"
inject_types: ["value", "principle", "goal", "risk"] # Strategic Retrieval
llm_fallback_enabled: true
INTERVIEW:
description: "Wissenserfassung"
trigger_keywords: ["erstellen", "neu", "anlegen", "festhalten"]
intents:
EMPATHY:
description: "Emotionaler Support"
description: "Emotionaler Support / Werte-Fokus"
boost_edges:
based_on: 2.0 # Verdoppelt den Einfluss von Werte-Kanten
related_to: 1.5 # Stärkt assoziative Bezüge
inject_types: ["experience", "belief"]
WHY:
description: "Ursachenanalyse (Kausalität)"
boost_edges:
caused_by: 2.5 # Massiver Boost für Kausalitätsketten
derived_from: 1.8 # Fokus auf die Herkunft
```
*Richtwert für Kanten-Boosts: 0.1 (Abwertung) bis 3.0+ (Dominanz gegenüber Text-Match).*

96
docs/03_Technical_References/03_tech_ingestion_pipeline.md
View File

@ -1,19 +1,19 @@
---
doc_type: technical_reference
audience: developer, devops
scope: backend, ingestion, smart_edges
scope: backend, ingestion, smart_edges, edge_registry
status: active
version: 2.7.0
version: 2.7.1
context: "Detaillierte technische Beschreibung der Import-Pipeline, Chunking-Strategien und CLI-Befehle."
---
# Ingestion Pipeline & Smart Processing
**Quellen:** `pipeline_playbook.md`, `Handbuch.md`
**Quellen:** `pipeline_playbook.md`, `Handbuch.md`, `edge_registry.py`, `01_edge_vocabulary.md`, `06_active_roadmap.md`
Die Ingestion transformiert Markdown in den Graphen. Entrypoint: `scripts/import_markdown.py` (CLI) oder `routers/ingest.py` (API).
Die Ingestion transformiert Markdown in den Graphen. Entrypoint: `scripts/import_markdown.py` (CLI) oder `routers/ingest.py` (API). Seit v2.7 integriert dieser Prozess die **Edge Registry** zur Normalisierung des Vokabulars und beachtet den **Content Lifecycle**.
## 1. Der Import-Prozess (14-Schritte-Workflow)
## 1. Der Import-Prozess (15-Schritte-Workflow)
Der Prozess ist **asynchron** und **idempotent**.
@ -21,27 +21,39 @@ Der Prozess ist **asynchron** und **idempotent**.
* **API (`/save`):** Nimmt Request entgegen, validiert und startet Background-Task ("Fire & Forget"). Antwortet sofort mit `202/Queued`.
* **CLI:** Iteriert über Dateien und nutzt `asyncio.Semaphore` zur Drosselung.
2. **Markdown lesen:** Rekursives Scannen des Vaults.
3. **Frontmatter extrahieren:** Validierung von Pflichtfeldern (`id`, `type`, `title`).
4. **Config Resolution:**
3. **Frontmatter Check & Hard Skip (WP-22):**
* Extraktion von `status` und `type`.
* **Hard Skip Rule:** Wenn `status` in `['system', 'template']` ist, wird die Datei **sofort übersprungen**. Sie wird weder vektorisiert noch in den Graphen aufgenommen.
* Validierung der Pflichtfelder (`id`, `title`) für alle anderen Dateien.
4. **Edge Registry Initialisierung (WP-22):**
* Laden der Singleton-Instanz der `EdgeRegistry`.
* Validierung der Vokabular-Datei unter `MINDNET_VOCAB_PATH`.
5. **Config Resolution:**
* Bestimmung von `chunking_profile` und `retriever_weight`.
* **Priorität:** 1. Frontmatter (Override) -> 2. `types.yaml` (Type) -> 3. Default.
5. **Note-Payload generieren:**
* Erstellen des JSON-Objekts für `mindnet_notes`.
* **Priorität:** 1. Frontmatter (Override) -> 2. `types.yaml` (Type) -> 3. Global Default.
6. **Note-Payload generieren:**
* Erstellen des JSON-Objekts inklusive `status` (für Scoring).
* **Multi-Hash Calculation:** Berechnet Hashtabellen für `body` (nur Text) und `full` (Text + Metadaten).
6. **Change Detection:**
7. **Change Detection:**
* Vergleich des Hashes mit Qdrant.
* Strategie wählbar via ENV `MINDNET_CHANGE_DETECTION_MODE` (`full` oder `body`).
7. **Chunking anwenden:** Zerlegung des Textes basierend auf dem ermittelten Profil (siehe Kap. 3).
8. **Smart Edge Allocation (WP15):**
8. **Chunking anwenden:** Zerlegung des Textes basierend auf dem ermittelten Profil (siehe Kap. 3).
9. **Smart Edge Allocation (WP15):**
* Wenn `enable_smart_edge_allocation: true`: Der `SemanticAnalyzer` sendet Chunks an das LLM.
* **Traffic Control:** Request nutzt `priority="background"`. Semaphore (Limit via `.env`) drosselt die Last.
* **Resilienz:** Bei Timeout (Ollama) greift ein Fallback (Broadcasting an alle Chunks).
9. **Inline-Kanten finden:** Parsing von `[[rel:...]]`.
10. **Callout-Kanten finden:** Parsing von `> [!edge]`.
11. **Default-Edges erzeugen:** Anwendung der `edge_defaults` aus Registry.
12. **Strukturkanten erzeugen:** `belongs_to`, `next`, `prev`.
13. **Embedding (Async):** Generierung via `nomic-embed-text` (768 Dim).
14. **Diagnose:** Integritäts-Check nach dem Lauf.
10. **Inline-Kanten finden:** Parsing von `[[rel:...]]`.
11. **Alias-Auflösung & Kanonisierung (WP-22):**
* Jede Kante wird via `edge_registry.resolve()` normalisiert.
* Aliase (z.B. `basiert_auf`) werden zu kanonischen Typen (z.B. `based_on`) aufgelöst.
* Unbekannte Typen werden in `unknown_edges.jsonl` protokolliert.
12. **Callout-Kanten finden:** Parsing von `> [!edge]`.
13. **Default- & Matrix-Edges erzeugen:** Anwendung der `edge_defaults` aus Registry und Matrix-Logik.
14. **Strukturkanten erzeugen:** `belongs_to`, `next`, `prev`.
15. **Embedding (Async):** Generierung via `nomic-embed-text` (768 Dim).
16. **Diagnose:** Integritäts-Check nach dem Lauf.
---
@ -69,7 +81,7 @@ export MINDNET_CHANGE_DETECTION_MODE="full"
> Das Flag `--purge-before-upsert` ist kritisch. Es löscht vor dem Schreiben einer Note ihre alten Chunks/Edges. Ohne dieses Flag entstehen **"Geister-Chunks"** (alte Textabschnitte, die im Markdown gelöscht wurden, aber im Index verbleiben).
### 2.2 Full Rebuild (Clean Slate)
Notwendig bei Änderungen an `types.yaml` (z.B. neue Chunking-Profile) oder Modell-Wechsel.
Notwendig bei Änderungen an `types.yaml` (z.B. neue Chunking-Profile), der Registry oder Modell-Wechsel.
```bash
# 0. Modell sicherstellen
@ -89,16 +101,16 @@ python3 -m scripts.import_markdown --vault ./vault --prefix "mindnet" --apply --
Das Chunking ist profilbasiert und in `types.yaml` konfiguriert.
### 3.1 Profile und Strategien
### 3.1 Profile und Strategien (Vollständige Referenz)
| Profil | Strategie | Parameter | Einsatzgebiet |
| :--- | :--- | :--- | :--- |
| `sliding_short` | `sliding_window` | Max: 350, Target: 200 | Kurze Logs, Chats, Risiken. |
| `sliding_standard` | `sliding_window` | Max: 650, Target: 450 | Massendaten (Journal, Quellen). |
| `sliding_smart_edges`| `sliding_window` | Max: 600, Target: 400 | Fließtexte mit hohem Wert (Projekte, Erfahrungen). |
| `structured_smart_edges` | `by_heading` | `strict: false` (Soft) | Strukturierte Texte, wo kleine Abschnitte gemergt werden dürfen. |
| `structured_smart_edges_strict` | `by_heading` | `strict: true` (Hard) | **Atomare Einheiten**: Entscheidungen, Werte, Profile. |
| `structured_smart_edges_strict_L3`| `by_heading` | `strict: true`, `level: 3` | Tief geschachtelte Prinzipien (Tier 2/MP1 Logik). |
| `sliding_smart_edges`| `sliding_window` | Max: 600, Target: 400 | Fließtexte mit hohem Wert (Projekte). |
| `structured_smart_edges` | `by_heading` | `strict: false` (Soft) | Strukturierte Texte, Merging erlaubt. |
| `structured_smart_edges_strict` | `by_heading` | `strict: true` (Hard) | **Atomare Einheiten**: Entscheidungen, Werte. |
| `structured_smart_edges_strict_L3`| `by_heading` | `strict: true`, `level: 3` | Tief geschachtelte Prinzipien (Tier 2/MP1). |
### 3.2 Die `by_heading` Logik (v2.9 Hybrid)
@ -110,44 +122,46 @@ Die Strategie `by_heading` zerlegt Texte anhand ihrer Struktur (Überschriften).
* *Merge-Check:* Wenn der vorherige Chunk leer war (nur Überschriften), wird gemergt (verhindert verwaiste Überschriften).
* *Safety Net:* Wird ein Abschnitt zu lang (> `max` Token), wird auch ohne Überschrift getrennt.
* **Modus "Soft" (`strict_heading_split: false`):**
* **Hierarchie-Check:** Überschriften *oberhalb* des Split-Levels (z.B. H1 bei Level 2) erzwingen **immer** einen Split.
* **Hierarchie-Check:** Überschriften *oberhalb* des Split-Levels erzwingen **immer** einen Split.
* **Füll-Logik:** Überschriften *auf* dem Split-Level (z.B. H2) lösen nur dann einen neuen Chunk aus, wenn der aktuelle Chunk die `target`-Größe erreicht hat.
* *Safety Net:* Auch hier greift das `max` Token Limit.
### 3.3 Payload-Felder (Qdrant)
* `text`: Der reine Inhalt (Anzeige im UI). Überschriften bleiben erhalten.
* `window`: Inhalt plus Overlap (für Embedding). Bei `by_heading` wird der Kontext (Eltern-Überschrift) oft vorangestellt.
* `text`: Der reine Inhalt (Anzeige im UI).
* `window`: Inhalt plus Overlap (für Embedding).
* `chunk_profile`: Das effektiv genutzte Profil (zur Nachverfolgung).
---
## 4. Edge-Erzeugung & Prioritäten
## 4. Edge-Erzeugung & Prioritäten (Provenance)
Kanten werden nach Vertrauenswürdigkeit (`provenance`) priorisiert. Die höhere Prio gewinnt.
| Prio | Quelle | Rule ID | Confidence |
| :--- | :--- | :--- | :--- |
| **1** | Inline | `inline:rel` | 0.95 |
| **2** | Callout | `callout:edge` | 0.90 |
| **3** | Wikilink | `explicit:wikilink` | 1.00 |
| **4** | Smart Edge | `smart:llm_filter` | 0.90 |
| **5** | Type Default | `edge_defaults` | 0.70 |
| **6** | Struktur | `structure` | 1.00 |
| Prio | Quelle | Rule ID | Confidence | Erläuterung |
| :--- | :--- | :--- | :--- | :--- |
| **1** | Wikilink | `explicit:wikilink` | **1.00** | Harte menschliche Setzung. |
| **2** | Inline | `inline:rel` | **0.95** | Typisierte menschliche Kante. |
| **3** | Callout | `callout:edge` | **0.90** | Explizite Meta-Information. |
| **4** | Smart Edge | `smart:llm_filter` | **0.90** | KI-validierte Verbindung. |
| **5** | Type Default | `edge_defaults` | **0.70** | Heuristik aus der Registry. |
| **6** | Struktur | `structure` | **1.00** | System-interne Verkettung. |
---
## 5. Quality Gates & Tests
## 5. Quality Gates & Monitoring
Diese Tests garantieren die Stabilität der Pipeline.
In v2.7 wurden Tools zur Überwachung der Datenqualität integriert:
**1. Payload Dryrun (Schema-Check):**
**1. Registry Review:** Prüfung der `data/logs/unknown_edges.jsonl`. Administratoren sollten hier gelistete Begriffe als Aliase in die `01_edge_vocabulary.md` aufnehmen.
**2. Payload Dryrun (Schema-Check):**
Simuliert Import, prüft JSON-Schema Konformität.
```bash
python3 -m scripts.payload_dryrun --vault ./test_vault
```
**2. Full Edge Check (Graph-Integrität):**
**3. Full Edge Check (Graph-Integrität):**
Prüft Invarianten (z.B. `next` muss reziprok zu `prev` sein).
```bash
python3 -m scripts.edges_full_check

102
docs/03_Technical_References/03_tech_retrieval_scoring.md
View File

@ -1,25 +1,25 @@
---
doc_type: technical_reference
audience: developer, data_scientist
scope: backend, retrieval, scoring
scope: backend, retrieval, scoring, modularization
status: active
version: 2.6
context: "Formeln und Algorithmen des Hybrid Retrievers und Explanation Layer."
version: 2.7.1
context: "Detaillierte Dokumentation der Scoring-Algorithmen, inklusive WP-22 Lifecycle-Modifier, Intent-Boosting und Modularisierung."
---
# Retrieval & Scoring Algorithmen
Der Retriever (`app/core/retriever.py`) unterstützt **Semantic Search** und **Hybrid Search**. Seit v2.4 (WP04a) nutzt Mindnet ein gewichtetes Scoring-Modell, das Semantik, Graphentheorie und Metadaten kombiniert.
Der Retriever unterstützt **Semantic Search** und **Hybrid Search**. Seit v2.4 nutzt Mindnet ein gewichtetes Scoring-Modell, das Semantik, Graphentheorie und Metadaten kombiniert. Mit Version 2.7 (WP-22) wurde dieses Modell um **Lifecycle-Faktoren** und **Intent-Boosting** erweitert sowie die Architektur modularisiert.
## 1. Scoring Formel (WP04a)
## 1. Scoring Formel (v2.7.0)
Der Gesamtscore eines Treffers berechnet sich als gewichtete Summe. Alle Gewichte ($W$) sind in `retriever.yaml` konfigurierbar.
Der Gesamtscore eines Treffers berechnet sich als gewichtete Summe. Alle Gewichte ($W$) und Modifier ($M$) sind in `retriever.yaml` und `decision_engine.yaml` konfigurierbar.
$$
TotalScore = (W_{sem} \cdot S_{sem} \cdot \max(W_{type}, 0)) + (W_{edge} \cdot B_{edge}) + (W_{cent} \cdot B_{cent})
TotalScore = (W_{sem} \cdot S_{sem} \cdot W_{type} \cdot M_{status}) + (W_{edge} \cdot B_{edge}) + (W_{cent} \cdot B_{cent}) + B_{intent}
$$
### Die Komponenten
### Die Komponenten (Klassisch v2.4)
**1. Semantic Score ($S_{sem}$):**
* **Basis:** Cosine Similarity des Vektors.
@ -27,87 +27,103 @@ $$
* **Wertebereich:** 0.0 bis 1.0.
**2. Type Weight ($W_{type}$):**
* **Herkunft:** Feld `retriever_weight` aus der Note/Chunk Payload.
* **Herkunft:** Feld `retriever_weight` aus der Note/Chunk Payload oder `types.yaml`.
* **Zweck:** Priorisierung bestimmter Dokumententypen unabhängig vom Inhalt.
* **Beispiel:** Eine `decision` (Gewicht 1.0) schlägt ein `concept` (Gewicht 0.6) bei gleicher textueller Ähnlichkeit.
* **Beispiel:** Eine `decision` (1.0) schlägt ein `concept` (0.6) bei gleicher Ähnlichkeit.
**3. Edge Bonus ($B_{edge}$):**
* **Kontext:** Berechnet im lokalen Subgraphen (Expansion Tiefe 1).
* **Logik:** Summe der `confidence` aller eingehenden Kanten, die von Knoten stammen, die *ebenfalls* im aktuellen Result-Set (oder dem übergebenen Kontext) enthalten sind.
* **Logik:** Summe der `confidence` aller eingehenden Kanten von Knoten im aktuellen Result-Set.
* **Zweck:** Belohnt Chunks, die "im Thema" vernetzt sind.
**4. Centrality Bonus ($B_{cent}$):**
* **Kontext:** Berechnet im lokalen Subgraphen.
* **Logik:** Eine vereinfachte PageRank-Metrik (Degree Centrality) im temporären Graphen.
* **Zweck:** Belohnt "Hubs", die viele Verbindungen zu anderen Treffern haben.
* **Logik:** Vereinfachte PageRank-Metrik (Degree Centrality).
* **Zweck:** Belohnt "Hubs" mit vielen Verbindungen zu anderen Treffern.
### Die WP-22 Erweiterungen (v2.7.0)
**5. Status Modifier ($M_{status}$):**
* **Herkunft:** Feld `status` aus dem Frontmatter.
* **Zweck:** Bestraft unfertiges Wissen (Drafts) oder bevorzugt stabiles Wissen.
* **Werte (Auftrag WP-22):** * `stable`: **1.2** (Bonus für Qualität).
* `draft`: **0.5** (Malus für Entwürfe).
* `system`: Exkludiert (siehe Ingestion).
**6. Intent Boost ($B_{intent}$):**
* **Herkunft:** Dynamische Injektion durch die Decision Engine basierend auf der Nutzerfrage.
* **Zweck:** Erhöhung des Scores für Knoten, die über spezifische Kanten-Typen (z.B. `caused_by` bei "Warum"-Fragen) verbunden sind.
---
## 2. Hybrid Retrieval Flow
## 2. Hybrid Retrieval Flow & Modularisierung
Der Hybrid-Modus ist der Standard für den Chat (`/chat`). Er läuft in drei Phasen ab:
In v2.7 wurde die Engine in einen Orchestrator (`retriever.py`) und eine Scoring-Engine (`retriever_scoring.py`) aufgeteilt.
**Phase 1: Vector Search (Seed Generation)**
* Suche die Top-K (z.B. 20) Kandidaten via Embeddings in Qdrant.
* Dies sind die "Seeds" für den Graphen.
* Der Orchestrator sucht Top-K (Standard: 20) Kandidaten via Embeddings in Qdrant.
* Diese bilden die "Seeds" für den Graphen.
**Phase 2: Graph Expansion**
* Nutze `graph_adapter.expand(seeds, depth=1)`.
* Lade alle direkten Nachbarn (Incoming & Outgoing) der Seeds aus der `_edges` Collection.
* Konstruiere einen temporären `NetworkX`-Graphen im Speicher (`Subgraph`).
* Lade direkte Nachbarn aus der `_edges` Collection.
* Konstruiere einen `NetworkX`-Graphen im Speicher.
**Phase 3: Re-Ranking**
* Berechne für jeden Knoten im Subgraphen die Boni ($B_{edge}$, $B_{cent}$).
* Wende die Scoring-Formel an.
* Sortiere die Liste neu absteigend nach `TotalScore`.
* Schneide die Liste beim finalen Limit (z.B. 5) ab.
**Phase 3: Re-Ranking (Modular)**
* Der Orchestrator übergibt den Graphen und die Seeds an die `ScoringEngine`.
* Berechne Boni ($B_{edge}$, $B_{cent}$) sowie die neuen Lifecycle- und Intent-Modifier.
* Sortierung absteigend nach `TotalScore` und Limitierung auf Top-Resultate (z.B. 5).
---
## 3. Explanation Layer (WP04b)
## 3. Explanation Layer (WP-22 Update)
Wenn der Parameter `explain=True` an die API übergeben wird, generiert der Retriever ein `Explanation` Objekt für jeden Treffer.
Bei `explain=True` generiert das System eine detaillierte Begründung.
**JSON-Struktur der Erklärung:**
**Erweiterte JSON-Struktur:**
```json
{
"score_breakdown": {
"semantic": 0.85,
"type_boost": 1.0,
"lifecycle_modifier": 0.5,
"edge_bonus": 0.4,
"intent_boost": 0.5,
"centrality": 0.1
},
"reasons": [
"Hohe textuelle Übereinstimmung (>0.85).",
"Bevorzugt, da Typ 'decision' (Gewicht 1.0).",
"Wird referenziert von 'Projekt Alpha' via 'depends_on'."
"Status 'draft' reduziert Relevanz (Modifier 0.5).",
"Wird referenziert via 'caused_by' (Intent-Bonus 0.5).",
"Bevorzugt, da Typ 'decision' (Gewicht 1.0)."
]
}
```
**Logik der Text-Generierung:**
* **Semantik:** Wenn $S_{sem} > 0.8$: "Hohe Übereinstimmung".
* **Typ:** Wenn $W_{type} > 0.8$: "Bevorzugt, da Typ X".
* **Graph:** Listet bis zu 3 eingehende Kanten mit hoher Konfidenz auf ("Wird referenziert von...").
---
## 4. Konfiguration (`retriever.yaml`)
Diese Datei steuert die Balance der Formel.
Steuert die Gewichtung der mathematischen Komponenten.
```yaml
scoring:
semantic_weight: 1.0 # Basis-Relevanz (sollte immer ca. 1.0 sein)
edge_weight: 0.7 # Einfluss des Graphen (0.5 - 1.0 empfohlen)
centrality_weight: 0.5 # Einfluss der Zentralität (Hub-Bonus)
semantic_weight: 1.0 # Basis-Relevanz
edge_weight: 0.7 # Graphen-Einfluss
centrality_weight: 0.5 # Hub-Einfluss
# Kanten-spezifische Gewichtung für den Edge-Bonus
# WP-22 Lifecycle Konfiguration (Abgleich mit Auftrag)
lifecycle_weights:
stable: 1.2 # Bonus für Qualität
draft: 0.5 # Malus für Entwürfe
# Kanten-Gewichtung für den Edge-Bonus (Basis)
edge_weights:
depends_on: 1.5 # Harte Abhängigkeiten sehr stark gewichten
blocks: 1.5 # Risiken/Blocker stark gewichten
caused_by: 1.2 # Kausalitäten moderat stärken
related_to: 0.5 # Weiche Themen schwächer gewichten
depends_on: 1.5 # Harte Abhängigkeiten
blocks: 1.5 # Risiken/Blocker
caused_by: 1.2 # Kausalitäten
based_on: 1.3 # Werte-Bezug
related_to: 0.5 # Weiche Themen
references: 0.8 # Standard-Referenzen
```

22
docs/04_Operations/04_admin_operations.md
View File

@ -1,10 +1,10 @@
---
doc_type: operations_manual
audience: admin, devops
scope: deployment, maintenance, backup
scope: deployment, maintenance, backup, edge_registry
status: active
version: 2.6
context: "Installationsanleitung, Systemd-Units und Wartungsprozesse."
version: 2.7.0
context: "Installationsanleitung, Systemd-Units und Wartungsprozesse für Mindnet v2.7."
---
# Admin Operations Guide
@ -58,6 +58,7 @@ User=llmadmin
Group=llmadmin
WorkingDirectory=/home/llmadmin/mindnet
# Startet Uvicorn (Async Server)
# Hinweis: Die .env muss MINDNET_VOCAB_PATH für die Edge Registry enthalten.
ExecStart=/home/llmadmin/mindnet/.venv/bin/uvicorn app.main:app --host 0.0.0.0 --port 8001 --env-file .env
Restart=always
RestartSec=5
@ -96,7 +97,7 @@ WantedBy=multi-user.target
---
## 3. Wartung & Cronjobs
## 3. Wartung & Monitoring
### 3.1 Regelmäßiger Import (Cron)
Führt den Sync stündlich durch. Nutzt `--purge-before-upsert` für Sauberkeit.
@ -106,7 +107,16 @@ Führt den Sync stündlich durch. Nutzt `--purge-before-upsert` für Sauberkeit.
0 * * * * cd /home/llmadmin/mindnet && .venv/bin/python3 -m scripts.import_markdown --vault ./vault --prefix "mindnet" --apply --purge-before-upsert --sync-deletes >> ./logs/import.log 2>&1
```
### 3.2 Troubleshooting Guide
### 3.2 Monitoring der Edge Registry (WP-22)
Administratoren sollten regelmäßig das Log für unbekannte Kanten-Typen prüfen.
* **Pfad:** `data/logs/unknown_edges.jsonl`.
* **Aktion:** Wenn neue Typen häufig auftreten, sollten diese als Alias in die `01_edge_vocabulary.md` aufgenommen werden.
### 3.3 Troubleshooting Guide
**Fehler: "Registry Initialization Failure" (Neu in v2.7)**
* **Symptom:** API startet, aber Kanten werden nicht gewichtet oder Fehlermeldung im Log.
* **Lösung:** Prüfen Sie `MINDNET_VOCAB_PATH` in der `.env`. Der Pfad muss absolut sein und auf eine existierende Markdown-Tabelle zeigen.
**Fehler: "ModuleNotFoundError: No module named 'st_cytoscape'"**
* Ursache: Alte Dependencies oder falsches Paket installiert.
@ -115,8 +125,6 @@ Führt den Sync stündlich durch. Nutzt `--purge-before-upsert` für Sauberkeit.
source .venv/bin/activate
pip uninstall streamlit-cytoscapejs
pip install st-cytoscape
# Oder sicherheitshalber:
pip install -r requirements.txt
```
**Fehler: "Vector dimension error: expected 768, got 384"**

70
docs/06_Roadmap/06_active_roadmap.md
View File

@ -2,18 +2,18 @@
doc_type: roadmap
audience: product_owner, developer
status: active
version: 2.7
version: 2.7.0
context: "Aktuelle Planung für kommende Features (ab WP16), Release-Strategie und Historie der abgeschlossenen WPs."
---
# Mindnet Active Roadmap
**Aktueller Stand:** v2.6.0 (Post-WP15/WP19)
**Fokus:** Visualisierung, Exploration & Intelligent Ingestion.
**Aktueller Stand:** v2.7.0 (Post-WP-22)
**Fokus:** Professionalisierung, Content Lifecycle & Graph Intelligence.
## 1. Programmstatus
Wir haben mit der Implementierung des Graph Explorers (WP19) und der Smart Edge Allocation (WP15) die Basis für ein intelligentes, robustes System gelegt. Der nächste Schritt (WP19a) vertieft die Analyse, während WP16 die "Eingangs-Intelligenz" erhöht.
Wir haben mit der Implementierung des Graph Explorers (WP19) und der Smart Edge Allocation (WP15) die Basis für ein intelligentes, robustes System gelegt. Der Abschluss von WP-22 (Content Lifecycle) professionalisiert nun die Datenhaltung und das Vokabular-Management.
| Phase | Fokus | Status |
| :--- | :--- | :--- |
@ -21,7 +21,7 @@ Wir haben mit der Implementierung des Graph Explorers (WP19) und der Smart Edge
| **Phase B** | Semantik & Graph | ✅ Fertig |
| **Phase C** | Persönlichkeit | ✅ Fertig |
| **Phase D** | Interaktion & Tools | ✅ Fertig |
| **Phase E** | Maintenance & Visualisierung | 🚀 Aktiv |
| **Phase E** | Maintenance & Professionalisierung | 🚀 Aktiv (v2.7.0) |
---
@ -44,16 +44,19 @@ Eine Übersicht der implementierten Features zum schnellen Auffinden von Funktio
| **WP-10a**| Draft Editor | GUI-Komponente zum Bearbeiten und Speichern generierter Notizen. |
| **WP-11** | Backend Intelligence | `nomic-embed-text` (768d) und Matrix-Logik für Kanten-Typisierung. |
| **WP-15** | Smart Edge Allocation | LLM-Filter für Kanten in Chunks + Traffic Control (Semaphore) + Strict Chunking. |
| **WP-19** | Graph Visualisierung | **Frontend Modularisierung:** Umbau auf `ui_*.py`.<br>**Graph Engines:** Parallelbetrieb von Cytoscape (COSE) und Agraph.<br>**Tools:** "Single Source of Truth" Editor, Persistenz via URL. |
| **WP-20** | Cloud Hybrid Mode | Nutzung von Public LLM für schnellere Verarbeitung und bestimmte Aufgaben |
| **WP-21** | Semantic Graph Routing & Canonical Edges | Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden. Das System soll verstehen, *welche* Art von Verbindung für die aktuelle Frage relevant ist ("Warum?" vs. "Was kommt danach?"). |
| **WP-22** | Content Lifecycle & Meta-Configuration | Professionalisierung der Datenhaltung durch Einführung eines Lebenszyklus (Status) und "Docs-as-Code" Konfiguration. |
| **WP-19** | Graph Visualisierung | **Frontend Modularisierung:** Umbau auf `ui_*.py`.<br>**Graph Engines:** Parallelbetrieb von Cytoscape und Agraph.<br>**Tools:** SSOT Editor, Persistenz via URL. |
| **WP-20** | Cloud Hybrid Mode | Nutzung von Public LLM für schnellere Verarbeitung und bestimmte Aufgaben. |
| **WP-21** | Semantic Graph Routing | Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden. |
| **WP-22** | **Content Lifecycle & Registry** | **Ergebnis:** SSOT via `01_edge_vocabulary.md`, Alias-Mapping, Status-Scoring (`stable`/`draft`) und Modularisierung der Scoring-Engine. |
### 2.1 WP-22 Lessons Learned
* **Architektur:** Die Trennung von `retriever.py` und `retriever_scoring.py` war notwendig, um LLM-Context-Limits zu wahren und die Testbarkeit der mathematischen Formeln zu erhöhen.
* **Kanten-Validierung:** Die Edge Registry muss beim Start explizit initialisiert werden (Singleton), um "Lazy Loading" Probleme in der API zu vermeiden.
---
## 3. Offene Workpackages (Planung)
Diese Features stehen als nächstes an oder befinden sich in der Umsetzung.
### WP-19a – Graph Intelligence & Discovery (Sprint-Fokus)
**Status:** 🚀 Startklar
**Ziel:** Vom "Anschauen" zum "Verstehen". Deep-Dive Werkzeuge für den Graphen.
@ -63,10 +66,10 @@ Diese Features stehen als nächstes an oder befinden sich in der Umsetzung.
### WP-14 – Review / Refactoring / Dokumentation
**Status:** 🟡 Laufend (Phase E)
**Ziel:** Technische Schulden abbauen, die durch schnelle Feature-Entwicklung (WP15/WP19) entstanden sind.
**Ziel:** Technische Schulden abbauen, die durch schnelle Feature-Entwicklung entstanden sind.
* **Refactoring `chunker.py`:** Die Datei ist monolithisch geworden (Parsing, Strategien, LLM-Orchestrierung).
* *Lösung:* Aufteilung in ein Package `app/core/chunking/` mit Modulen (`strategies.py`, `orchestration.py`, `utils.py`).
* **Dokumentation:** Kontinuierliche Synchronisation von Code und Docs (v2.6 Stand).
* **Dokumentation:** Kontinuierliche Synchronisation von Code und Docs (v2.7.0 Stand).
### WP-16 – Auto-Discovery & Intelligent Ingestion
**Status:** 🟡 Geplant
@ -106,40 +109,29 @@ Diese Features stehen als nächstes an oder befinden sich in der Umsetzung.
### WP-21 – Semantic Graph Routing & Canonical Edges
**Status:** 🟡 Geplant
**Ziel:** Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden. Das System soll verstehen, *welche* Art von Verbindung für die aktuelle Frage relevant ist ("Warum?" vs. "Was kommt danach?").
**Ziel:** Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden.
**Problem:**
1. **Statische Gewichte:** Aktuell ist `caused_by` immer gleich wichtig (z.B. 1.2), egal ob der User nach Ursachen oder Definitionen fragt.
2. **Vokabular-Zwang:** Der Nutzer muss exakte System-Begriffe (`caused_by`) verwenden. Natürliche Synonyme (`führt_zu`, `ausgelöst_durch`) werden als unbekannte Kanten ignoriert oder nicht speziell gewichtet.
1. **Statische Gewichte:** Aktuell ist `caused_by` immer gleich wichtig, egal ob der User nach Ursachen oder Definitionen fragt.
2. **Vokabular-Zwang:** Der Nutzer muss exakte System-Begriffe verwenden.
**Lösungsansätze & Kern-Features:**
1. **Canonical Edge Mapping (Middleware):**
* Einführung einer Mapping-Schicht (z.B. in `edges.yaml`).
* *Funktion:* Normalisiert User-Vokabular (`leads_to`, `triggers`, `starts`) automatisch auf System-Typen (`caused_by`).
* *Benefit:* Maximale Schreibfreiheit für den Nutzer bei gleichzeitiger System-Konsistenz.
* *Funktion:* Normalisiert User-Vokabular automatisch auf System-Typen.
2. **Dynamic Intent Boosting (Query-Time):**
* Erweiterung der `Decision Engine`.
* *Funktion:* Der Router erkennt den Intent der Frage (z.B. `EXPLANATION` für "Warum-Fragen") und injiziert temporäre `edge_weights` in den Retriever.
* *Beispiel:* Bei "Warum ist das passiert?" wird `caused_by` von 1.2 auf 2.5 geboostet, während `related_to` auf 0.1 sinkt.
* *Funktion:* Der Router erkennt den Intent der Frage und injiziert temporäre Gewichte.
3. **Graph Reasoning:**
* Der Retriever priorisiert Pfade, die dem semantischen Muster der Frage entsprechen, nicht nur dem Text-Match.
* Der Retriever priorisiert Pfade, die dem semantischen Muster der Frage entsprechen.
### WP-22 – Content Lifecycle & Meta-Configuration
**Status:** 🟡 Geplant
**Ziel:** Professionalisierung der Datenhaltung durch Einführung eines Lebenszyklus (Status) und "Docs-as-Code" Konfiguration.
**Problem:**
1. **Müll im Index:** Unfertige Ideen (`draft`) oder System-Dateien (`templates`) verschmutzen die Suchergebnisse.
2. **Redundanz:** Kanten-Typen müssen in Python-Code und Obsidian-Skripten doppelt gepflegt werden.
**Status:** ✅ Fertig (v2.7.0)
**Ziel:** Professionalisierung der Datenhaltung durch Einführung eines Lebenszyklus und "Docs-as-Code" Konfiguration.
**Lösungsansätze:**
1. **Status-Logik (Frontmatter):**
* `status: system` / `template` → **Hard Skip** im Importer (Kein Index).
* `status: draft` vs. `stable` → **Scoring Modifier** im Retriever (Stabiles Wissen wird bevorzugt).
2. **Single Source of Truth (SSOT):**
* Die Datei `01_edge_vocabulary.md` wird zur führenden Konfiguration.
* Eine neue `Registry`-Klasse liest diese Markdown-Datei beim Start und validiert Kanten dagegen.
3. **Self-Learning Loop:**
* Unbekannte Kanten-Typen (vom User neu erfunden) werden nicht verworfen, sondern in ein `unknown_edges.jsonl` Log geschrieben, um das Vokabular organisch zu erweitern.
1. **Status-Logik (Frontmatter):** `stable` vs. `draft` Scoring Modifier.
2. **Single Source of Truth (SSOT):** Die Registry nutzt `01_edge_vocabulary.md` als führende Konfiguration.
3. **Self-Learning Loop:** Protokollierung unbekannter Kanten in `unknown_edges.jsonl`.
---
## 4. Abhängigkeiten & Release-Plan
@ -152,7 +144,7 @@ graph TD
WP15 --> WP14(Refactoring)
WP03(Import) --> WP18(Health Check)
WP03/WP04 --> WP13(MCP)
graph TD
WP06(Decision Engine) --> WP21(Semantic Routing)
WP03(Import Pipeline) --> WP21
WP15(Smart Edges) --> WP21
WP21 --> WP22(Lifecycle/Registry)
WP22 --> WP14
```