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

21 Releases 37 Tags

RSS Feed
  • v3.2.0 d0012355b9
    Compare

    Mindnet v3.2.0 - Feature Release - Phase 3 Agentic Edge Validation & Chunk-Aware Multigraph-System
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 4s
    Details
    Stable

    Lars released this 2026-01-12 10:55:12 +01:00 | 13 commits to main since this release

    🎯 Überblick

    Mit WP-24c wurde MindNet um ein finales Validierungs-Gate (Phase 3 Agentic Edge Validation) erweitert, das "Geister-Verknüpfungen" verhindert und die Graph-Qualität sichert. Zusätzlich wurde das System um automatische Spiegelkanten (Invers-Logik) und Note-Scope Zonen erweitert, die es ermöglichen, globale Verbindungen für ganze Notizen zu definieren.

    Diese Version markiert einen wichtigen Schritt zur Graph-Integrität: Von manueller Kanten-Pflege hin zu automatischer Validierung und bidirektionaler Durchsuchbarkeit.

    ✨ Neue Features

    1. Phase 3 Agentic Edge Validation

    Implementierung (app/core/ingestion/ingestion_validation.py v2.14.0):

    Finales Validierungs-Gate für alle Kanten mit candidate: Präfix:

    • Trigger-Kriterium: Kanten in ### Unzugeordnete Kanten Sektionen erhalten candidate: Präfix
    • Validierungsprozess: LLM prüft semantisch, ob die Verbindung zum Kontext passt
    • Ergebnis: VERIFIED (Präfix entfernt, persistiert) oder REJECTED (nicht in DB geschrieben)
    • Kontext-Optimierung: Note-Scope nutzt Note-Summary/Text, Chunk-Scope nutzt spezifischen Chunk-Text

    Vorteile:

    • Graph-Qualität: Verhindert persistente "Geister-Verknüpfungen"
    • Präzision: Höhere Validierungs-Genauigkeit durch Kontext-Optimierung
    • Fehlertoleranz: Unterscheidung zwischen transienten (Netzwerk) und permanenten (Config) Fehlern

    2. Automatische Spiegelkanten (Invers-Logik)

    Implementierung (app/core/ingestion/ingestion_processor.py v2.13.12):

    Automatische Erzeugung von Spiegelkanten für explizite Verbindungen:

    • Funktionsweise: Explizite Kante A depends_on: B erzeugt automatisch B enforced_by: A
    • Priorität: Explizite Kanten haben Vorrang (keine Duplikate)
    • Schutz: System-Kanten (belongs_to, next, prev) können nicht manuell überschrieben werden
    • Phase 2 Injektion: Spiegelkanten werden am Ende des Imports in einem Batch-Prozess injiziert

    Vorteile:

    • Bidirektionale Durchsuchbarkeit: Beide Richtungen sind durchsuchbar ohne manuelle Pflege
    • Konsistenz: Volle Graph-Konsistenz ohne "Link-Nightmare"
    • Höhere Wirksamkeit: Explizite Kanten haben höhere Confidence-Werte als automatisch generierte

    3. Note-Scope Zonen (v4.2.0)

    Implementierung (app/core/graph/graph_derive_edges.py v1.1.2):

    Globale Verbindungen für ganze Notizen:

    • Format: Links in ## Smart Edges Zonen werden als scope: note behandelt
    • Priorität: Höchste Priorität bei Duplikaten
    • Phase 3 Validierung: Nutzt Note-Summary (Top 5 Chunks) oder Note-Text für bessere Validierung
    • Konfigurierbar: Header-Namen und -Ebene via ENV-Variablen

    Vorteile:

    • Globale Verbindungen: Links gelten für die gesamte Note, nicht nur einen Abschnitt
    • Bessere Validierung: Note-Kontext ermöglicht präzisere LLM-Validierung
    • Flexibilität: Konfigurierbare Header-Namen für verschiedene Workflows

    4. Chunk-Aware Multigraph-System

    Erweiterung des bestehenden Multigraph-Systems:

    • Section-basierte Links: [[Note#Section]] wird präzise in target_id und target_section aufgeteilt
    • Multigraph-Support: Mehrere Kanten zwischen denselben Knoten möglich, wenn sie auf verschiedene Sections zeigen
    • Semantische Deduplizierung: Basierend auf src->tgt:kind@sec Key

    Vorteile:

    • Präzision: Präzise Verlinkung innerhalb langer Dokumente
    • Flexibilität: Mehrere Verbindungen zur gleichen Note möglich
    • Konsistenz: Verhindert "Phantom-Knoten"

    🔧 Technische Änderungen

    Konfigurationsdateien

    config/llm_profiles.yaml (v1.3.0):

    • Keine Änderungen: Bestehende Profile bleiben unverändert
    • ingest_validator Profil: Wird für Phase 3 Validierung genutzt (Temperature 0.0 für Determinismus)

    config/prompts.yaml (v3.2.2):

    • Keine Änderungen: Bestehende Prompts bleiben unverändert
    • edge_validation Prompt: Wird für Phase 3 Validierung genutzt

    Environment Variablen (.env)

    Neue Variablen für WP-24c:

    # --- WP-24c v4.2.0: Konfigurierbare Markdown-Header für Edge-Zonen ---
# Komma-separierte Liste von Headern für LLM-Validierung
# Format: Header1,Header2,Header3
MINDNET_LLM_VALIDATION_HEADERS=Unzugeordnete Kanten,Edge Pool,Candidates

# Header-Ebene für LLM-Validierung (1-6, Default: 3 für ###)
MINDNET_LLM_VALIDATION_HEADER_LEVEL=3

# Komma-separierte Liste von Headern für Note-Scope Zonen
# Format: Header1,Header2,Header3
MINDNET_NOTE_SCOPE_ZONE_HEADERS=Smart Edges,Relationen,Global Links,Note-Level Relations,Globale Verbindungen

# Header-Ebene für Note-Scope Zonen (1-6, Default: 2 für ##)
MINDNET_NOTE_SCOPE_HEADER_LEVEL=2

    Default-Werte:

    • MINDNET_LLM_VALIDATION_HEADERS: Unzugeordnete Kanten,Edge Pool,Candidates
    • MINDNET_LLM_VALIDATION_HEADER_LEVEL: 3 (für ###)
    • MINDNET_NOTE_SCOPE_ZONE_HEADERS: Smart Edges,Relationen,Global Links,Note-Level Relations,Globale Verbindungen
    • MINDNET_NOTE_SCOPE_HEADER_LEVEL: 2 (für ##)

    Hinweis: Falls diese Variablen nicht gesetzt sind, werden die Default-Werte verwendet. Das System funktioniert ohne explizite Konfiguration.

    Code-Komponenten

    Neue/Erweiterte Module:

    • app/core/ingestion/ingestion_validation.py: v2.14.0

      • Phase 3 Validierung mit Kontext-Optimierung
      • Differenzierte Fehlerbehandlung (transient vs. permanent)
      • Lazy-Prompt-Orchestration Integration

    • app/core/ingestion/ingestion_processor.py: v2.13.12

      • Automatische Spiegelkanten-Generierung (Phase 2)
      • Authority-Check für explizite Kanten
      • ID-Konsistenz mit Phase 1

    • app/core/graph/graph_derive_edges.py: v1.1.2

      • Note-Scope Zonen Extraktion
      • LLM-Validierung Zonen Extraktion
      • Konfigurierbare Header-Erkennung

    • app/core/chunking/chunking_processor.py: v2.13.0

      • LLM-Validierung Zonen Erkennung
      • candidate: Präfix-Setzung

    • app/core/chunking/chunking_parser.py: v2.12.0

      • Header-Level Erkennung
      • Zonen-Extraktion

    📋 Migration Guide

    Für Endbenutzer

    Keine Migration erforderlich! Das System funktioniert ohne Änderungen.

    Optionale Nutzung neuer Features:

    1. Explizite Links (empfohlen):

      Diese Entscheidung [[rel:depends_on Performance-Analyse]] wurde getroffen.
      • Sofortige Übernahme, höchste Priorität, keine Validierung

    2. Validierte Links (für explorative Verbindungen):

      ### Unzugeordnete Kanten

related_to:Mögliche Verbindung
depends_on:Unsicherer Link
      • Phase 3 Validierung, kann abgelehnt werden

    3. Note-Scope Links (für globale Verbindungen):

      ## Smart Edges

[[rel:depends_on|Projekt-Übersicht]]
[[rel:part_of|Größeres System]]
      • Globale Verbindung für ganze Note, höchste Priorität

    Für Administratoren

    1. Environment Variablen hinzufügen (optional):

    Fügen Sie die folgenden Zeilen zu Ihrer .env oder config/prod.env hinzu:

    # --- WP-24c v4.2.0: Konfigurierbare Markdown-Header für Edge-Zonen ---
MINDNET_LLM_VALIDATION_HEADERS=Unzugeordnete Kanten,Edge Pool,Candidates
MINDNET_LLM_VALIDATION_HEADER_LEVEL=3
MINDNET_NOTE_SCOPE_ZONE_HEADERS=Smart Edges,Relationen,Global Links,Note-Level Relations,Globale Verbindungen
MINDNET_NOTE_SCOPE_HEADER_LEVEL=2

    Hinweis: Falls diese Variablen nicht gesetzt sind, werden die Default-Werte verwendet. Das System funktioniert ohne explizite Konfiguration.

    2. LLM-Profil prüfen:

    Stellen Sie sicher, dass das ingest_validator Profil in config/llm_profiles.yaml existiert:

    ingest_validator:
  provider: ollama
  model: phi3:mini
  temperature: 0.0
  fallback_profile: null

    3. Prompt prüfen:

    Stellen Sie sicher, dass der edge_validation Prompt in config/prompts.yaml existiert.

    4. System neu starten:

    Nach dem Hinzufügen der ENV-Variablen:

    systemctl restart mindnet-prod
systemctl restart mindnet-ui-prod

    Für Entwickler

    Keine Code-Änderungen erforderlich! Die neuen Features sind vollständig rückwärtskompatibel.

    Optionale Integration:

    • Phase 3 Validierung: Nutzen Sie validate_edge_candidate() aus ingestion_validation.py
    • Note-Scope Zonen: Nutzen Sie extract_note_scope_zones() aus graph_derive_edges.py
    • Spiegelkanten: Werden automatisch erzeugt, keine manuelle Integration erforderlich

    🚀 Deployment-Anweisungen

    Pre-Deployment Checkliste

    • Backup: Vollständiges Backup von Qdrant und Vault durchführen
    • ENV-Variablen: Neue ENV-Variablen zu .env hinzufügen (optional)
    • LLM-Profil: ingest_validator Profil in llm_profiles.yaml prüfen
    • Prompt: edge_validation Prompt in prompts.yaml prüfen
    • Dependencies: requirements.txt aktualisieren (falls neue Abhängigkeiten)
    • Tests: Unit Tests und Integration Tests ausführen

    Deployment-Schritte

    1. Code aktualisieren:

    git pull origin main
# oder
git checkout WP24c
git merge main

    2. Dependencies aktualisieren:

    source .venv/bin/activate
pip install -r requirements.txt

    3. ENV-Variablen konfigurieren (optional):

    # Fügen Sie die neuen Variablen zu .env hinzu
nano .env
# oder
nano config/prod.env

    4. Services neu starten:

    systemctl restart mindnet-prod
systemctl restart mindnet-ui-prod

    5. Health Check:

    curl http://localhost:8001/healthz
curl http://localhost:8501/healthz

    6. Logs prüfen:

    journalctl -u mindnet-prod -n 50 --no-pager
journalctl -u mindnet-ui-prod -n 50 --no-pager

    Post-Deployment Validierung

    1. Phase 3 Validierung testen:

    Erstellen Sie eine Test-Notiz mit ### Unzugeordnete Kanten:

    ---
type: concept
title: Test-Notiz
---

# Test-Notiz

Hier ist der Inhalt...

### Unzugeordnete Kanten

related_to:Test-Ziel

    Erwartetes Verhalten:

    • Log zeigt 🚀 [PHASE 3] Validierung: ...
    • Log zeigt ✅ [PHASE 3] VERIFIED: oder 🚫 [PHASE 3] REJECTED:
    • Kante wird nur bei VERIFIED persistiert

    2. Note-Scope Zonen testen:

    Erstellen Sie eine Test-Notiz mit ## Smart Edges:

    ---
type: decision
title: Test-Entscheidung
---

# Test-Entscheidung

Hier ist der Inhalt...

## Smart Edges

[[rel:depends_on|Test-Projekt]]

    Erwartetes Verhalten:

    • Link wird als scope: note behandelt
    • provenance: explicit:note_zone
    • Höchste Priorität bei Duplikaten

    3. Automatische Spiegelkanten testen:

    Erstellen Sie eine explizite Kante:

    [[rel:depends_on Projekt Alpha]]

    Erwartetes Verhalten:

    • Log zeigt 🔄 [SYMMETRY] Add inverse: ...
    • Beide Richtungen sind durchsuchbar
    • Explizite Kante hat höhere Priorität

    🐛 Bekannte Probleme & Einschränkungen

    Keine bekannten Probleme.

    Hinweise:

    • Phase 3 Validierung: Erfordert LLM-Verfügbarkeit. Bei transienten Fehlern wird die Kante erlaubt (Datenintegrität vor Präzision).
    • Spiegelkanten: Werden nur für explizite Kanten erzeugt. Validierte Kanten erhalten keine Spiegelkanten, bis sie VERIFIED sind.
    • Note-Scope: Header-Namen müssen exakt (case-insensitive) übereinstimmen.

    📚 Dokumentation

    Aktualisierte Dokumente:

    • docs/01_User_Manual/01_knowledge_design.md - Automatische Spiegelkanten, Phase 3 Validierung, Note-Scope Zonen
    • docs/01_User_Manual/NOTE_SCOPE_ZONEN.md - Phase 3 Validierung integriert
    • docs/01_User_Manual/LLM_VALIDIERUNG_VON_LINKS.md - Phase 3 statt global_pool
    • docs/02_concepts/02_concept_graph_logic.md - Phase 3 Validierung, automatische Spiegelkanten, Note-Scope vs. Chunk-Scope
    • docs/03_Technical_References/03_tech_data_model.md - candidate: Präfix, verified Status, virtual Flag
    • docs/03_Technical_References/03_tech_configuration.md - Neue ENV-Variablen dokumentiert
    • docs/04_Operations/04_admin_operations.md - Troubleshooting für Phase 3 Validierung
    • docs/05_Development/05_testing_guide.md - WP-24c Test-Szenarien

    Neue Dokumente:

    • Keine neuen Dokumente (alle Features in bestehenden Dokumenten integriert)

    ✅ Breaking Changes

    Keine Breaking Changes!

    Das System ist vollständig rückwärtskompatibel. Bestehende Notizen funktionieren ohne Änderungen.

    🎉 Danksagungen

    Diese Version wurde entwickelt, um die Graph-Integrität zu sichern und die Benutzerfreundlichkeit durch automatische Spiegelkanten zu verbessern.

    Status: ✅ WP-24c ist zu 100% implementiert und audit-geprüft.
    Nächster Schritt: WP-25c (Kontext-Budgeting & Erweiterte Prompt-Optimierung).

    Downloads
  • v3.1.1 548c503e7c
    Compare

    Feature Release - Lazy-Prompt-Orchestration & Full Resilience
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 5s
    Details
    Stable

    Lars released this 2026-01-03 15:14:05 +01:00 | 90 commits to main since this release

    MindNet v3.1.1 - Release Notes: WP-25b

    Release Date: 2026-01-02
    Type: Feature Release - Lazy-Prompt-Orchestration & Full Resilience
    Version: 3.1.1 (WP-25b)

    🎯 Überblick

    Mit WP-25b wurde MindNet von statischer Prompt-Formatierung auf eine hierarchische Lazy-Prompt-Orchestration umgestellt. Prompts werden erst im Moment des Modellaustauschs geladen, basierend auf dem exakt aktiven Modell. Dies ermöglicht modell-spezifisches Tuning und maximale Resilienz bei Modell-Fallbacks.

    Diese Version markiert einen weiteren Architektur-Sprung: Von vorformatierter Prompt-Strings hin zu einer dynamischen, modell-spezifischen Prompt-Auflösung mit vollständiger Traceability.

    ✨ Neue Features

    1. Hierarchisches Prompt-Resolution-System

    Implementierung (app/services/llm_service.py v3.5.5):

    Dreistufige Auflösungs-Logik für maximale Präzision und Resilienz:

    1. Level 1 (Modell-ID): Exakte Übereinstimmung für spezifische Modelle

      • Beispiel: google/gemini-2.0-flash-exp:free, meta-llama/llama-3.3-70b-instruct:free
      • Vorteil: Modell-spezifische Optimierungen für maximale Präzision
      • Logging: 🎯 [PROMPT-TRACE] Level 1 Match: Model-specific

    2. Level 2 (Provider): Fallback auf Provider-Standards

      • Beispiel: openrouter, ollama, gemini
      • Vorteil: Bewährte Standards aus v3.1.2 bleiben erhalten
      • Logging: 📡 [PROMPT-TRACE] Level 2 Match: Provider-fallback

    3. Level 3 (Default): Globaler Sicherheits-Satz

      • Fallback-Kette: default → gemini → ollama → ""
      • Vorteil: Vermeidung von Fehlern bei unbekannten Konfigurationen
      • Logging: ⚓ [PROMPT-TRACE] Level 3 Match: Global Default

    Vorteile:

    • Modell-spezifisches Tuning: Jedes Modell kann optimierte Prompts erhalten
    • Maximale Resilienz: Bei Modell-Fallbacks wird automatisch das passende Template geladen
    • Traceability: Vollständige Transparenz über genutzte Instruktionen

    2. Lazy-Prompt-Orchestration

    Implementierung (app/services/llm_service.py v3.5.5):

    • Lazy Loading: Prompts werden erst zur Laufzeit geladen, wenn das aktive Modell bekannt ist
    • Parameter: prompt_key und variables statt vorformatierter Strings
    • Integration: Vollständig in Chat, Ingestion und DecisionEngine integriert

    Vorteile:

    • Dynamische Anpassung: Prompt wird basierend auf aktivem Modell geladen
    • Fallback-Resilienz: Bei Cloud → Local Fallback wird automatisch das passende Template verwendet
    • Wartbarkeit: Zentrale Konfiguration in prompts.yaml statt verstreuter String-Formatierungen

    3. Ultra-robustes Intent-Parsing

    Implementierung (app/core/retrieval/decision_engine.py v1.3.2):

    • Regex-basierter Parser: Bereinigt Modell-Artefakte zuverlässig
    • Beispiele: CODING[/S] → CODING, DECISION</s> → DECISION
    • Robustheit: Ignoriert Stop-Marker, Newlines oder Plaudereien des Modells

    Vorteile:

    • Präzises Routing: Strategie-Erkennung funktioniert auch bei freien Modellen mit Artefakten
    • Fehlerresistenz: Systemabstürze durch fehlerhafte Modell-Antworten werden verhindert

    4. Differenzierte Ingestion-Validierung

    Implementierung (app/core/ingestion/ingestion_validation.py v2.14.0):

    • Fehler-Differenzierung: Unterscheidung zwischen transienten und permanenten Fehlern
    • Transiente Fehler: Timeout, Connection, Network → Kante wird erlaubt (Datenverlust vermeiden)
    • Permanente Fehler: Config, Validation, Invalid Response → Kante wird abgelehnt (Graph-Qualität schützen)

    Vorteile:

    • Datenintegrität: Transiente Netzwerkfehler führen nicht zu Datenverlust
    • Graph-Qualität: Permanente Konfigurationsfehler schützen vor fehlerhaften Kanten

    5. PROMPT-TRACE Logging

    Implementierung (app/services/llm_service.py v3.5.5):

    • Vollständige Transparenz: Protokollierung der genutzten Prompt-Auflösungs-Ebene
    • Log-Format: [PROMPT-TRACE] Level X Match: ...
    • Debugging: Einfache Nachverfolgung von Prompt-Entscheidungen

    Vorteile:

    • Debugging: Schnelle Identifikation von Prompt-Problemen
    • Optimierung: Verständnis, welche Prompts tatsächlich genutzt werden
    • Audit: Vollständige Nachvollziehbarkeit der System-Entscheidungen

    🔧 Technische Änderungen

    Konfigurationsdateien

    Aktualisierte Dateien:

    • config/prompts.yaml v3.2.2: Hierarchische Struktur mit Modell-spezifischen Overrides
      • Erhalt: 100% der Original-Prompts aus v3.1.2 für die Provider-Ebene
      • Neu: Modell-spezifische Overrides für Gemini 2.0, Llama 3.3, Qwen 2.5
      • Neu: compression_template für DecisionEngine v1.3.0

    Code-Komponenten

    Komponente Version Änderungen
    app/services/llm_service.py v3.5.5 Hierarchische Prompt-Resolution, Lazy-Loading, PROMPT-TRACE
    app/core/retrieval/decision_engine.py v1.3.2 Ultra-robustes Intent-Parsing via Regex
    app/core/ingestion/ingestion_validation.py v2.14.0 Lazy-Prompt-Integration, differenzierte Fehlerbehandlung
    app/routers/chat.py v3.0.3 Lazy-Prompt-Loading für Chat-Synthese

    API-Änderungen

    Neue Parameter:

    • prompt_key: Schlüssel für Lazy-Loading (statt vorformatierter Strings)
    • variables: Daten-Dict für Prompt-Formatierung

    Veraltete Parameter:

    • Vorformatierte prompt Strings werden weiterhin unterstützt (Abwärtskompatibilität)

    🐛 Behobene Probleme

    • ✅ Behoben: Modell-Artefakte in Intent-Router (z.B. CODING[/S] → CODING)
    • ✅ Behoben: Fehlende modell-spezifische Prompt-Optimierungen
    • ✅ Behoben: Fehlerhafte Prompt-Auflösung bei Modell-Fallbacks
    • ✅ Behoben: Undifferenzierte Fehlerbehandlung in Ingestion-Validierung

    📚 Dokumentation

    Aktualisierte Dokumente:

    • ✅ 03_tech_chat_backend.md: Hierarchisches Prompt-Resolution-System und Lazy-Prompt-Orchestration
    • ✅ 03_tech_configuration.md: prompts.yaml hierarchische Struktur dokumentiert
    • ✅ 02_concept_ai_personality.md: Lazy-Prompt-Orchestration Konzept
    • ✅ 03_tech_ingestion_pipeline.md: Differenzierte Validierung
    • ✅ 00_glossary.md: Neue Begriffe (Lazy-Prompt, PROMPT-TRACE, hierarchische Resolution)
    • ✅ 05_developer_guide.md: Lazy-Prompt-Orchestration für Entwickler
    • ✅ 06_active_roadmap.md: WP25b als abgeschlossen markiert

    🚀 Migration & Upgrade

    Für Administratoren

    1. Keine Breaking Changes:

      • Vorformatierte Prompts werden weiterhin unterstützt
      • System funktioniert ohne Änderungen

    2. Optional: Modell-spezifische Optimierungen:

      # config/prompts.yaml
decision_synthesis_v1:
  "google/gemini-2.0-flash-exp:free": |
    # Modell-spezifische Optimierung
    ...

    3. PROMPT-TRACE aktivieren:

      • Logs zeigen automatisch die genutzte Auflösungs-Ebene
      • Keine zusätzliche Konfiguration erforderlich

    Für Entwickler

    API-Änderungen:

    • LLMService.generate_raw_response() unterstützt nun prompt_key und variables
    • Vorformatierte prompt Strings bleiben für Abwärtskompatibilität erhalten

    Best Practice:

    • Nutze prompt_key und variables für neue Implementierungen
    • Lazy-Loading ermöglicht automatische Modell-Anpassung

    Konfiguration:

    • Neue Modell-spezifische Prompts können in prompts.yaml definiert werden
    • Hierarchische Struktur: Modell-ID → Provider → Default

    🔮 Ausblick (WP-25c)

    • Kontext-Budgeting: Intelligente Token-Verteilung
    • Stream-specific Provider: Unterschiedliche KI-Modelle pro Wissensbereich
    • Erweiterte Prompt-Optimierung: Dynamische Anpassung basierend auf Kontext und Historie

    📊 Metriken & Performance

    Erwartete Verbesserungen:

    • Präzision: Modell-spezifische Prompts erhöhen Antwortqualität
    • Resilienz: Automatische Prompt-Anpassung bei Modell-Fallbacks
    • Debugging: PROMPT-TRACE vereinfacht Fehleranalyse
    • Wartbarkeit: Zentrale Prompt-Konfiguration statt verstreuter Strings

    Status: ✅ WP-25b ist zu 100% implementiert und audit-geprüft.
    Nächster Schritt: WP-25c (Kontext-Budgeting & Erweiterte Prompt-Optimierung).

    Downloads
  • V3.1.0 d41da670fc
    Compare

    MindNet v3.1.0 - WP-25a LLM-Profil basierte Steuerung
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 3s
    Details
    Stable

    Lars released this 2026-01-02 13:56:17 +01:00 | 98 commits to main since this release

    MindNet v3.1.0 - Release Notes: WP-25a

    Release Date: 2026-01-02
    Type: Feature Release - Mixture of Experts (MoE) & Fallback-Kaskade
    Version: 3.1.0 (WP-25a)

    🎯 Überblick

    Mit WP-25a wurde MindNet von einer provider-basierten Steuerung auf eine profilbasierte Experten-Architektur (Mixture of Experts) umgestellt. Jede Systemaufgabe (Synthese, Ingestion-Validierung, Routing, Kompression) wird nun einem dedizierten Profil zugewiesen, das Modell, Provider und Parameter unabhängig von der globalen Konfiguration definiert.

    Diese Version markiert einen fundamentalen Architektur-Sprung: Von einer monolithischen LLM-Konfiguration hin zu einer modularen, aufgabenspezifischen Experten-Steuerung mit automatischer Resilienz.

    ✨ Neue Features

    1. Mixture of Experts (MoE) Architektur

    Zentrale Experten-Steuerung (llm_profiles.yaml v1.3.0):

    • Einführung von Experten-Profilen für spezifische Aufgaben:
      • synthesis_pro: Hochwertige Synthese für Chat-Antworten
      • tech_expert: Fachspezialist für Code & Technik (Claude 3.5 Sonnet)
      • compression_fast: Schnelle Kompression & Routing (Mistral 7B)
      • ingest_validator: Deterministische Validierung (Temperature 0.0)
      • identity_safe: Lokaler Anker (Ollama/Phi-3) für maximale Privacy
      • embedding_expert: Zentrale Steuerung des Embedding-Modells

    Vorteile:

    • Aufgabenspezifische Optimierung: Jede Aufgabe nutzt das optimale Modell
    • Hardware-Optimierung: Lokaler Anker für kleine Hardware-Umgebungen
    • Wartbarkeit: Zentrale Konfiguration statt verstreuter ENV-Variablen

    2. Rekursive Fallback-Kaskade

    Implementierung (app/services/llm_service.py v3.5.2):

    • Automatische Fallback-Logik bei Provider-Fehlern:
      1. Versucht primäres Profil (z.B. synthesis_pro)
      2. Bei Fehler → fallback_profile (z.B. synthesis_backup)
      3. Bei weiterem Fehler → nächster Fallback (z.B. identity_safe)
      4. Terminaler Endpunkt: identity_safe hat keinen Fallback (lokales Modell)

    Schutzmechanismen:

    • Zirkuläre Referenzen: visited_profiles-Tracking verhindert Endlosschleifen
    • Background-Semaphore: Parallele Tasks werden gedrosselt (konfigurierbar via BACKGROUND_LIMIT)

    3. Pre-Synthesis Kompression (Module A)

    Implementierung (app/core/retrieval/decision_engine.py v1.2.1):

    • Wissens-Streams, die den Schwellenwert (compression_threshold) überschreiten, werden asynchron verdichtet, bevor sie die Synthese erreichen
    • Konfigurierbar pro Stream: Z.B. 2500 Zeichen für Values Stream, 3500 für Facts Stream
    • Profil-gesteuert: Nutzt compression_profile (z.B. compression_fast für schnelle Zusammenfassung)
    • Parallelisierung: Mehrere Streams können gleichzeitig komprimiert werden

    Vorteile:

    • Reduziert Token-Verbrauch bei langen Streams
    • Beschleunigt Synthese durch kürzere Kontexte
    • Erhält Relevanz durch intelligente Zusammenfassung

    4. Profilgesteuerte Ingestion (Wissens-Gatekeeper)

    Implementierung:

    • app/core/ingestion/ingestion_processor.py v2.14.0
    • app/core/ingestion/ingestion_validation.py v2.13.0

    Features:

    • Semantische Kanten-Validierung erfolgt zwingend über das MoE-Profil ingest_validator (Temperature 0.0 für Determinismus)
    • Embedding-Konsolidierung: Der EmbeddingsClient (v2.6.0) bezieht Modellvorgaben und Dimensionen direkt aus dem Profil embedding_expert
    • Entfernung der Embedding-Konfiguration aus der .env zugunsten zentraler Profil-Registry

    5. Startup-Schutz & Audit-Fixes

    Implementierung (app/main.py v1.1.0):

    • Verifiziert beim Booten die Existenz und Validität von llm_profiles.yaml und decision_engine.yaml
    • Audit-Fix: Behebung einer Sicherheitslücke in der DecisionEngine, durch die Fallback-Aufrufe bei Template-Fehlern die Profilsteuerung umgangen hätten
    • Circular Import Fix: Ingestion-Module nutzen nun die neutrale app.core.registry für Text-Bereinigung und Registry-Lookups

    🔧 Technische Änderungen

    Konfigurationsdateien

    Neue Datei:

    • config/llm_profiles.yaml v1.3.0: Zentrale Experten-Registry

    Aktualisierte Dateien:

    • config/decision_engine.yaml v3.2.2: Decoupled MoE Logic, Integration von compression_thresholds

    Code-Komponenten

    Komponente Version Änderungen
    app/services/llm_service.py v3.5.2 Rekursive Fallback-Kaskade, Profil-Auflösung
    app/core/retrieval/decision_engine.py v1.2.1 Profile-Driven Orchestration, Pre-Synthesis Kompression
    app/core/ingestion/ingestion_processor.py v2.14.0 Profilgesteuerte Validierung
    app/core/ingestion/ingestion_validation.py v2.13.0 MoE-Profil ingest_validator
    app/services/embeddings_client.py v2.6.0 Profil-basierte Modell-Auflösung
    app/main.py v1.1.0 Startup-Validierung der YAML-Dateien

    Environment-Variablen

    Neue Variable:

    • MINDNET_LLM_PROFILES_PATH: Pfad zur Profil-Registry (Default: config/llm_profiles.yaml)

    Legacy (nur noch Fallback):

    • MINDNET_LLM_PROVIDER, MINDNET_LLM_MODEL, etc. dienen nur noch als Fallback, wenn kein Profil angegeben wird

    🐛 Behobene Probleme

    • ✅ Behoben: Sicherheitslücke in der DecisionEngine - Fallback-Aufrufe nutzen nun korrekt profile_name
    • ✅ Behoben: Circular Import zwischen Ingestion-Modulen und Registry
    • ✅ Behoben: Fehlende Startup-Validierung der YAML-Konfigurationen

    📚 Dokumentation

    Aktualisierte Dokumente:

    • ✅ 03_tech_configuration.md: llm_profiles.yaml Dokumentation
    • ✅ 03_tech_chat_backend.md: MoE Architektur und Fallback-Kaskade
    • ✅ 02_concept_ai_personality.md: Mixture of Experts Konzept
    • ✅ 03_tech_ingestion_pipeline.md: Profilgesteuerte Validierung
    • ✅ 00_glossary.md: Neue Begriffe (MoE, Profile, Fallback-Kaskade)
    • ✅ 05_developer_guide.md: Teach-the-AI mit Profilen
    • ✅ 04_admin_operations.md: Konfigurations-Updates
    • ✅ 06_active_roadmap.md: WP25a als abgeschlossen markiert

    🚀 Migration & Upgrade

    Für Administratoren

    1. Neue Konfigurationsdatei erstellen:

      cp config/llm_profiles.yaml.example config/llm_profiles.yaml
# Anpassen nach Bedarf

    2. Startup-Validierung prüfen:

      # System startet nicht, wenn llm_profiles.yaml fehlt oder ungültig ist
python3 -m app.main

    3. ENV-Variablen (optional):
      Die .env Variablen MINDNET_LLM_PROVIDER, MINDNET_LLM_MODEL etc. dienen nur noch als Fallback. Die primäre Steuerung erfolgt über llm_profiles.yaml.

    Für Entwickler

    API-Änderungen:

    • LLMService.generate_raw_response() unterstützt nun profile_name Parameter
    • Fallback-Kaskade erfolgt automatisch bei Fehlern
    • visited_profiles-Tracking verhindert Zirkel-Referenzen

    Konfiguration:

    • Neue Profile können in llm_profiles.yaml definiert werden
    • decision_engine.yaml referenziert Profile über router_profile, llm_profile, compression_profile

    🔮 Ausblick (WP-25b: Prompt-Orchestration & Model-Specific Tuning)

    • Pre-Synthesis: LLM-basierte Komprimierung überlanger Streams (✅ bereits implementiert)
    • Kontext-Budgeting: Intelligente Token-Verteilung
    • Stream-specific Provider: Unterschiedliche KI-Modelle pro Wissensbereich
    • Prompt-Orchestration: Dynamische Prompt-Anpassung basierend auf Profil und Kontext

    📊 Metriken & Performance

    Erwartete Verbesserungen:

    • Resilienz: Automatische Fallback-Kaskade reduziert Ausfallzeiten
    • Token-Effizienz: Pre-Synthesis Kompression reduziert Token-Verbrauch bei langen Streams
    • Determinismus: Profilgesteuerte Validierung (Temperature 0.0) erhöht Konsistenz
    • Wartbarkeit: Zentrale Profil-Registry vereinfacht Konfigurations-Management

    Status: ✅ WP-25a ist zu 100% implementiert und audit-geprüft.
    Nächster Schritt: WP-25b (Prompt-Orchestration & Model-Specific Tuning).

    Downloads
  • v3.0.0 3d2f3d12d9
    Compare

    Mindnet v3.0.0 (WP25)
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 5s
    Details
    Stable

    Lars released this 2026-01-01 20:26:54 +01:00 | 106 commits to main since this release

    Release Notes: Mindnet v3.0.0 (WP25)

    Release Date: 2026-01-01
    Type: Feature Release - Agentic Multi-Stream RAG Orchestration
    Branch: WP25

    🎯 Übersicht

    Diese Version markiert den Übergang von Mindnet von einer klassischen, linearen RAG-Architektur zu einer Agentic Multi-Stream Engine. Das System agiert nun als intelligenter Orchestrator, der Nutzeranfragen analysiert, in parallele Wissens-Streams aufteilt und diese zu einer kontextreichen, wertebasierten Antwort synthetisiert.

    ✨ Neue Features

    Agentic Multi-Stream RAG Orchestration

    Mindnet führt nun parallele Abfragen in spezialisierten Wissens-Streams aus, anstatt einer einzelnen Suche:

    Stream-Library:

    • Values Stream: Extrahiert Identität, Ethik und Prinzipien (value, principle, belief, trait, boundary, need, motivation).
    • Facts Stream: Liefert operative Daten zu Projekten, Tasks und Status (project, decision, task, goal, event, state).
    • Biography Stream: Greift auf persönliche Erfahrungen und Journal-Einträge zu (experience, journal, profile, person).
    • Risk Stream: Identifiziert Hindernisse und potenzielle Gefahren (risk, obstacle, bias).
    • Tech Stream: Bündelt technisches Wissen, Code und Dokumentation (concept, source, glossary, idea, insight, skill, habit).

    Vorteile:

    • Präzise Kontext-Ladung: Jeder Stream fokussiert auf spezifische Wissensbereiche.
    • Parallele Ausführung: Alle Streams werden gleichzeitig abgefragt (asyncio.gather).
    • Stream-Tracing: Jeder Treffer wird mit stream_origin markiert für Feedback-Optimierung.
    • Fehler-Resilienz: Einzelne Stream-Fehler blockieren nicht die gesamte Anfrage.

    Intent-basiertes Routing ("The Brain")

    Der Router wurde zu einem hybriden System erweitert, das Anfragen klassifiziert, bevor die Suche beginnt:

    Strategien:

    • FACT_WHAT: Wissen/Listen (z.B. "Was ist...", "Welche sind...").
    • FACT_WHEN: Zeitpunkte (z.B. "Wann...", "Datum...").
    • DECISION: Beratung (z.B. "Soll ich...", "Sollte ich...", "Empfehlung...").
    • EMPATHY: Reflexion (z.B. "Fühle...", "Stress...", "Angst...").
    • CODING: Technik (z.B. "Code...", "Python...", "Bug...").
    • INTERVIEW: Datenerfassung (z.B. "Neues Projekt...", "Erfahrung...").

    Hybrid-Modus:

    • Keyword Fast-Path: Sofortige Erkennung von Triggern wie "Soll ich" oder "Wann" ohne LLM-Call.
    • LLM Slow-Path: Komplexe semantische Analyse für unklare Anfragen.
    • Type Keywords: Automatische Erkennung von Objekt-Typen für Interview-Modus.

    Vorteil: Reduziert Latenz durch schnelle Keyword-Erkennung, nutzt LLM nur bei Bedarf.

    Wissens-Synthese

    Die Zusammenführung der Daten erfolgt über spezialisierte Templates in der prompts.yaml:

    Template-Struktur:

    • Explizite Variablen für jeden Stream (z.B. {values_stream}, {risk_stream}).
    • Pre-Initialization: Alle möglichen Stream-Variablen werden vorab initialisiert (verhindert KeyErrors).
    • Provider-spezifische Templates: Separate Versionen für Ollama, Gemini und OpenRouter.

    Synthese-Strategien:

    • FACT_WHAT/FACT_WHEN: Kombiniert Fakten, Biographie und Technik.
    • DECISION: Wägt Fakten gegen Werte ab, evaluiert Risiken.
    • EMPATHY: Fokus auf Biographie und Werte.
    • CODING: Technik und Fakten.

    Vorteil: Ermöglicht dem LLM eine differenzierte Abwägung zwischen Fakten und persönlichen Werten.

    🔧 Verbesserungen

    Stream-Konfiguration & Typ-Synchronisation

    Jeder Stream nutzt individuelle Edge-Boosts und Filter-Types, die strikt mit der types.yaml (v2.7.0) synchronisiert sind:

    Beispiele:

    • Values Stream: guides: 3.0, enforced_by: 2.5, based_on: 2.0.
    • Facts Stream: part_of: 2.0, depends_on: 1.5, implemented_in: 1.5.
    • Risk Stream: blocks: 2.5, impacts: 2.0, risk_of: 2.5.

    Vorteil: Präzise Gewichtung der Graph-Kanten je nach Wissensbereich.

    Template-Robustheit

    Pre-Initialization: Automatische Vor-Initialisierung aller Stream-Variablen in der DecisionEngine verhindert KeyError-Abstürze bei unvollständigen Konfigurationen.

    Fallback-Mechanismus: Bei Template-Fehlern wird ein vereinfachter Prompt mit allen verfügbaren Stream-Ergebnissen verwendet.

    Ollama Context-Throttling

    Vor der Übergabe an Ollama prüft der Chat-Router, ob der Kontext (RAG-Hits) die Grenze von MAX_OLLAMA_CHARS überschreitet (Standard: 10.000) und kürzt diesen ggf.

    Vorteil: Verhindert VRAM-Überlastung bei großen Kontexten.

    🐛 Bugfixes

    • ✅ Behoben: Vault-Import Performance - "Empty Response Guard" korrigiert, damit kurze Ingest-Antworten (YES/NO) nicht mehr fälschlicherweise langsame Fallbacks auslösen.
    • ✅ Behoben: Cloud-Resilienz - Sicherheitscheck für das choices-Array in _execute_openrouter implementiert, um JSON-Errors bei überlasteten APIs zu verhindern.
    • ✅ Behoben: Template-Robustheit - Automatische Vor-Initialisierung aller Stream-Variablen verhindert KeyError-Abstürze.
    • ✅ Behoben: Intent-Kollision - Generische Begriffe (wie "Projekt") wurden aus den Keyword-Triggern entfernt, um sicherzustellen, dass strategische Fragen (z.B. "Soll ich...?") korrekt als DECISION geroutet werden.

    ⚠️ Breaking Changes & Migration

    Keine Migration erforderlich

    WICHTIG: Diese Version ist rückwärtskompatibel. Bestehende Vaults funktionieren ohne Re-Import.

    Konfigurations-Updates:

    • decision_engine.yaml wurde auf v3.1.6 aktualisiert (Multi-Stream Struktur).
    • prompts.yaml wurde auf v3.1.2 aktualisiert (Stream-Templates).
    • Empfehlung: Backup der alten Konfigurationsdateien vor dem Update.

    📚 API-Änderungen

    Erweiterte DTOs

    QueryHit (erweitert):

    class QueryHit(BaseModel):
    # ... bestehende Felder ...
    stream_origin: Optional[str] = None  # Neu: Name des Ursprungs-Streams

    ChatResponse (erweitert):

    class ChatResponse(BaseModel):
    # ... bestehende Felder ...
    intent: Optional[str] = "FACT"  # Neu: Die gewählte WP-25 Strategie
    intent_source: Optional[str] = "LLM_Router"  # Neu: Quelle der Intent-Erkennung

    Impact für API-Consumer:

    • Frontend kann stream_origin für visuelle Kennzeichnung der Quellen nutzen.
    • intent und intent_source ermöglichen Debugging und Analytics.

    📖 Dokumentation

    Alle relevanten Dokumente wurden aktualisiert:

    • ✅ 03_tech_chat_backend.md: Agentic Multi-Stream RAG, Intent-basiertes Routing, Wissens-Synthese
    • ✅ 03_tech_configuration.md: decision_engine.yaml, prompts.yaml (Stream-Struktur)
    • ✅ 03_tech_api_reference.md: Erweiterte DTOs (stream_origin, intent)

    🔄 Technische Details

    Geänderte Module

    Decision Engine:

    • app/core/retrieval/decision_engine.py: Multi-Stream Orchestrator (v1.0.3)
      • Paralleles Retrieval via _execute_parallel_streams()
      • Stream-Tracing mit stream_origin
      • Pre-Initialization der Stream-Variablen

    Chat Router:

    • app/routers/chat.py: Hybrid Router Integration (v3.0.2)
      • Keyword Fast-Path + LLM Slow-Path
      • Multi-Stream Orchestrierung
      • Ollama Context-Throttling

    LLM Service:

    • app/services/llm_service.py: Ingest-Stability Patch (v3.4.2)
      • Entfernung des <5-Zeichen Guards
      • Empty Response Guard für OpenRouter
      • Lazy Initialization der DecisionEngine

    DTOs:

    • app/models/dto.py: Stream-Tracing Support (v0.7.1)
      • stream_origin in QueryHit
      • intent und intent_source in ChatResponse

    Main:

    • app/main.py: Lifespan Management (v1.0.0)
      • Startup-Integritäts-Check
      • Ressourcen-Cleanup beim Shutdown
      • Globale Fehlerbehandlung

    Konfiguration:

    • config/decision_engine.yaml: Multi-Stream Konfiguration (v3.1.6)
    • config/prompts.yaml: Stream-Templates (v3.1.2)

    Versionsnummern

    • Decision Engine: v1.0.3
    • Chat Router: v3.0.2
    • LLM Service: v3.4.2
    • DTOs: v0.7.1
    • Main: v1.0.0
    • decision_engine.yaml: v3.1.6
    • prompts.yaml: v3.1.2

    🚀 Upgrade-Pfad

    Für Administratoren

    1. Code aktualisieren:

      git pull origin main
source .venv/bin/activate
pip install -r requirements.txt

    2. Konfiguration prüfen:

      # Backup der alten Konfigurationen
cp config/decision_engine.yaml config/decision_engine.yaml.backup
cp config/prompts.yaml config/prompts.yaml.backup

# Prüfen, ob neue Konfigurationen vorhanden sind
ls -la config/decision_engine.yaml config/prompts.yaml

    3. Services neu starten:

      sudo systemctl restart mindnet-prod
sudo systemctl restart mindnet-ui-prod

    Für Entwickler

    • Keine Code-Änderungen erforderlich, wenn nur API genutzt wird
    • Frontend kann neue Felder (stream_origin, intent, intent_source) optional nutzen
    • Stream-Tracing ermöglicht Feedback-Optimierung pro Wissensbereich

    📝 Bekannte Einschränkungen

    • Stream-Parallelität: Maximale Anzahl paralleler Streams ist durch asyncio-Limits begrenzt (typischerweise 5-10 Streams).
    • Kontext-Größe: Große Kontexte (>10.000 Zeichen) werden bei Ollama automatisch gekürzt.

    🔮 Ausblick (WP-25a: Agentic Refinement)

    Auf Basis des stabilen WP-25 Fundaments sind folgende Erweiterungen geplant:

    • Pre-Synthesis: LLM-basierte Komprimierung überlanger Streams vor der finalen Antwortgenerierung.
    • Kontext-Budgeting: Intelligente Verteilung der verfügbaren Token auf die aktivierten Streams.
    • Stream-specific Provider: Zuweisung unterschiedlicher KI-Modelle pro Wissensbereich (z.B. lokales Ollama für Identitäts-Werte, Gemini für technische Fakten).

    🙏 Danksagungen

    Diese Version wurde durch umfangreiche Architektur-Überarbeitung ermöglicht. Besonderer Fokus lag auf:

    • Transformation zu einer Agentic Multi-Stream Engine
    • Intelligente Intent-Erkennung mit Hybrid-Routing
    • Parallele Wissens-Synthese mit wertebasierter Abwägung
    • Robustheit und Fehler-Resilienz

    Vollständige Changelog: Siehe Git-Commits für detaillierte Änderungen
    Support: Bei Fragen siehe Admin Operations Guide

    Downloads
  • v2.9.3 67d7154328
    Compare

    Feature Release - Multigraph & Diversity Engine
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 4s
    Details
    Stable

    Lars released this 2025-12-31 16:57:45 +01:00 | 115 commits to main since this release

    Release Notes: Mindnet v2.9.3 (WP15c)

    Release Date: 2025-12-31
    Type: Feature Release - Multigraph & Diversity Engine
    Branch: WP15c

    🎯 Übersicht

    Diese Version transformiert den Graphen von einer flachen Struktur zu einem hochpräzisen Multigraphen mit intelligenter Ergebnis-Filterung (Diversity) und gewichtetem Scoring. Die Änderungen verbessern die Retrieval-Qualität durch präzise Sektions-Links, Note-Level Diversity Pooling und mathematische Super-Edge Aggregation.

    ✨ Neue Features

    Section-Präzision & Multigraph-Modus

    Mindnet erkennt nun präzise Obsidian-Anker ([[Note#Section]]) und Self-Links ([[#Section]]):

    Obsidian-Anker:

    [[rel:based_on Mein Leitbild#P3 – Disziplin]]

    Self-Links:

    [[#P3 – Disziplin]]  → Verlinkt innerhalb derselben Note

    Technische Details:

    • Links werden in target_id="Note" und target_section="Section" aufgelöst
    • Edge-IDs enthalten variant (Section) für eindeutige Identifikation
    • Multigraph-Modus: Mehrere Kanten zwischen denselben Notizen möglich, wenn sie auf verschiedene Sections zeigen
    • Verhindert "Phantom-Knoten" durch korrekte Trennung von Note-Name und Abschnitt

    Provenance Firewall (Edge Registry v0.8.0)

    Die Edge Registry stellt sicher, dass System-Kanten (next, prev, belongs_to) ausschließlich durch interne Struktur-Prozesse und nicht durch Nutzer oder KI manipuliert werden können:

    Schutz-Mechanismus:

    • System-Kanten dürfen nur mit provenance="structure" gesetzt werden
    • Alle anderen Provenienzen (explicit, semantic_ai, inherited, global_pool, rule) werden blockiert
    • Automatischer Fallback auf related_to bei unerlaubter Verwendung
    • Logging in data/logs/unknown_edges.jsonl für Admin-Review

    Vorteil: Garantiert Graph-Integrität und verhindert Manipulationen an der internen Struktur.

    Note-Level Diversity Pooling

    Um das "Note-Flooding" (Dominanz einer einzigen Notiz durch viele ähnliche Chunks) zu verhindern, wird pro note_id nur noch der relevanteste Treffer im Endergebnis behalten:

    Workflow:

    1. Alle Kandidaten werden nach finalem Score sortiert
    2. Pro note_id wird nur der Hit mit dem höchsten total_score behalten
    3. Begrenzung auf top_k nach dem Diversity-Pooling

    Impact: Verhindert, dass 10 Chunks derselben Note andere KeyNotes verdrängen. Erhöht die Vielfalt der Suchergebnisse.

    Super-Edge Aggregation

    Parallele Kanten zwischen zwei Notizen werden mathematisch zu einer "Super-Edge" aggregiert:

    Aggregations-Logik:

    • Primäre Kante (höchstes Gewicht) zählt voll
    • Jede weitere Kante (z.B. auf eine andere Sektion) wird mit Dämpfungsfaktor 0.1 gewichtet
    • Formel: total_weight = primary_weight + sum(secondary_weights * 0.1)

    Vorteil: Verhindert Score-Explosionen durch multiple Links auf verschiedene Sections derselben Note.

    Metadaten:

    • is_super_edge: Flag für Explanation Layer
    • edge_count: Anzahl der aggregierten Kanten

    🔧 Verbesserungen

    Mathematisches Scoring (WP-22 Integration)

    Die Engine berechnet den finalen Score basierend auf einer hybriden Multiplikations-Formel:

    Final = (Semantic * StatusMult) * (1 + TypeBoost + EdgeBonus + CentBonus)

    Komponenten:

    • Base Score: Semantic * StatusMult (Lifecycle-Filter)
    • Status-Gatekeeper: stable = 1.2, draft = 0.5, active = 1.0
    • Boosts: TypeBoost + EdgeBonus + CentBonus (additiv, dann multiplikativ auf Base)
    • Graph Boost Factor: Intent-spezifische Verstärkung (1.5x bei aktivem Intent)

    Vorteil: Status wirkt als Multiplikator auf die Basis-Relevanz, Graph-Boni werden proportional verstärkt.

    Explanation Layer

    Der Retriever liefert detaillierte Begründungen für jeden Bonus:

    • Sektions-Links (z.B. "Link zu 'Mein Leitbild#P3 – Disziplin'")
    • Hub-Zentralität (z.B. "Note ist zentraler Knoten mit 5 eingehenden Kanten")
    • Super-Edge-Informationen (z.B. "3 parallele Kanten aggregiert")
    • Provenance-Informationen (z.B. "Explizite Kante vom Nutzer")

    Impact: Massiv erhöhte Transparenz für Debugging und Nutzer-Vertrauen.

    Metadaten-Persistenz

    Der In-Memory Subgraph und der Datenbank-Adapter wurden so erweitert, dass Metadaten durchgängig erhalten bleiben:

    Erhaltene Metadaten:

    • target_section: Abschnitts-Name für präzise Verlinkung
    • provenance: Herkunft der Kante (explicit, smart, rule, structure)
    • confidence: Vertrauenswürdigkeit (0.0 - 1.0)
    • is_super_edge: Flag für aggregierte Kanten

    Vorteil: Ermöglicht präzises Retrieval-Reasoning und Explanation Layer.

    Profil-Synchronisation (Ingestion v2.13.12)

    Der Ingestion-Prozessor löst Chunking-Profile hierarchisch über die types.yaml auf:

    Hierarchie:

    1. Frontmatter (höchste Priorität)
    2. types.yaml Typ-Config
    3. Global Defaults

    Impact: Konsistente Verarbeitung je nach Notiz-Typ. Note-Typen wie value erhalten automatisch das korrekte Profil (structured_smart_edges_strict).

    🐛 Bugfixes

    • ✅ Behoben: "Phantom-Knoten" durch korrekte Trennung von Note-Name und Section in target_id
    • ✅ Behoben: Score-Explosionen durch multiple Links auf verschiedene Sections
    • ✅ Behoben: "Note-Flooding" durch fehlende Diversity-Filterung
    • ✅ Behoben: Inkonsistente Metadaten durch fehlende Persistenz im Subgraph
    • ✅ Behoben: Manipulation von System-Kanten durch Provenance Firewall

    ⚠️ Breaking Changes & Migration

    Keine Migration erforderlich

    WICHTIG: Diese Version ist rückwärtskompatibel. Bestehende Vaults funktionieren ohne Re-Import.

    Empfehlung: Optionaler Re-Import für optimale Nutzung der neuen Features:

    python3 -m scripts.import_markdown --vault ./vault --prefix "mindnet" --apply --force

    Was passiert beim Re-Import?

    • Bestehende Links werden neu geparst und in target_id + target_section aufgeteilt
    • Self-Links ([[#Section]]) werden korrekt aufgelöst
    • Edge-Struktur wird konsolidiert (Multigraph-Support)

    📚 API-Änderungen

    Keine Breaking Changes

    Die API bleibt vollständig kompatibel. Neue Metadaten werden optional zurückgegeben:

    EdgeDTO (erweitert):

    class EdgeDTO(BaseModel):
    # ... bestehende Felder ...
    target_section: Optional[str] = None  # Neu: Abschnitts-Name
    is_super_edge: Optional[bool] = False    # Neu: Aggregations-Flag

    QueryResponse (erweitert):

    • Explanation Layer enthält nun Super-Edge-Informationen
    • Metadaten wie target_section werden in Edge-Objekten zurückgegeben

    📖 Dokumentation

    Alle relevanten Dokumente wurden aktualisiert:

    • ✅ 02_concept_graph_logic.md: Provenance Firewall, Self-Links, Multigraph-Support
    • ✅ 03_tech_retrieval_scoring.md: Hybrid Scoring Formula, Note-Level Diversity, Super-Edge Aggregation
    • ✅ 03_tech_data_model.md: Section-Support, Metadaten-Persistenz
    • ✅ 03_tech_ingestion_pipeline.md: Registry-First Profiling (bereits dokumentiert)

    🔄 Technische Details

    Geänderte Module

    Graph Topology:

    • app/services/edge_registry.py: Provenance Firewall (v0.8.0)
    • app/core/graph/graph_utils.py: parse_link_target() für Section-Extraktion & Self-Links (v1.1.2)
    • app/core/graph/graph_derive_edges.py: Multigraph-Support, target_section in Edge-Payload (v1.1.2)
    • app/core/graph/graph_subgraph.py: Metadaten-Persistenz (v1.2.0)
    • app/core/graph/graph_db_adapter.py: Vollständige Metadaten-Durchreichung (v1.1.1)

    Retrieval:

    • app/core/retrieval/retriever.py: Note-Level Diversity Pooling, Super-Edge Aggregation (v0.7.0)
    • app/core/retrieval/retriever_scoring.py: Hybrid Scoring Formula (v1.0.3)

    Ingestion:

    • app/core/ingestion/ingestion_processor.py: Registry-First Profiling (v2.13.12)

    Versionsnummern

    • Edge Registry: v0.8.0
    • Graph Utils / Derive Edges: v1.1.2
    • Graph Subgraph: v1.2.0
    • Graph DB Adapter: v1.1.1
    • Retriever: v0.7.0
    • Retriever Scoring: v1.0.3
    • Ingestion Processor: v2.13.12

    🚀 Upgrade-Pfad

    Für Administratoren

    1. Code aktualisieren:

      git pull origin main
source .venv/bin/activate
pip install -r requirements.txt

    2. Services neu starten:

      sudo systemctl restart mindnet-prod
sudo systemctl restart mindnet-ui-prod

    3. Optional: Re-Import für optimale Nutzung:

      python3 -m scripts.import_markdown --vault ./vault --prefix "mindnet" --apply --force

    Für Entwickler

    • Keine Code-Änderungen erforderlich, wenn nur API genutzt wird
    • Frontend kann neue Metadaten (target_section, is_super_edge) optional nutzen
    • Explanation Layer enthält nun Super-Edge-Informationen

    📝 Bekannte Einschränkungen

    • Re-Import-Dauer: Große Vaults (>10.000 Notizen) können 30+ Minuten benötigen (optional)
    • Temporärer Speicher: Während des Re-Imports kann Qdrant-Speicher temporär ansteigen

    🙏 Danksagungen

    Diese Version wurde durch umfangreiche Code-Analyse und Dokumentationsprüfung ermöglicht. Besonderer Fokus lag auf:

    • Transformation zu einem hochpräzisen Multigraphen
    • Intelligente Ergebnis-Filterung (Diversity Engine)
    • Mathematisches Scoring mit gewichteten Boni
    • Graph-Integrität durch Provenance Firewall

    Vollständige Changelog: Siehe Git-Commits für detaillierte Änderungen
    Support: Bei Fragen siehe Admin Operations Guide

    Downloads
  • v2.9.2 cd5056d4c9
    Compare

    v.2.9.2 Section-basierte Links, Atomic Section Logic & Registry-First Profiling
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 4s
    Details
    Stable

    Lars released this 2025-12-30 12:27:36 +01:00 | 123 commits to main since this release

    Release Notes: Mindnet v2.9.2 (WP4d)

    🎯 Übersicht

    Diese Version führt Section-basierte Links ein, verbessert das Chunking durch Atomic Section Logic und implementiert Registry-First Profiling für konsistentere Konfigurationsauflösung. Die Änderungen erfordern einen vollständigen Re-Import bestehender Vaults.

    ✨ Neue Features

    Section-basierte Links (Deep-Links)

    Mindnet unterstützt nun Deep-Links zu spezifischen Abschnitten innerhalb einer Note:

    [[rel:based_on Mein Leitbild#P3 – Disziplin]]

    Vorteile:

    • Mehrere Links zur gleichen Note möglich (verschiedene Sections)
    • Präzise Kontext-Ladung (nur relevanter Abschnitt)
    • Keine "Phantom-Knoten" mehr durch korrekte Trennung von Note-Name und Abschnitt

    Technische Details:

    • Links werden in target_id="Note" und target_section="Section" aufgeteilt
    • Edge-ID enthält variant (Section) für Multigraph-Support
    • Semantische Deduplizierung basiert auf src->tgt:kind@sec Key

    Atomic Section Logic (Chunking v3.9.9)

    Das Chunking hält nun Sektions-Überschriften und deren Inhalte atomar zusammen:

    "Pack-and-Carry-Over" Verfahren:

    • Regel 1 & 2: Sektionen werden zusammengepackt, wenn sie in den Token-Limit passen
    • Regel 3: Zu große Sektionen werden intelligent zerlegt, Rest wird zurück in Queue gelegt
    • H1-Context Preservation: Dokumenttitel wird als Breadcrumb in alle Chunks injiziert

    Vorteile:

    • Keine getrennten Überschriften mehr
    • Bessere semantische Kohärenz in Chunks
    • Verbesserte Retrieval-Qualität durch vollständigen Kontext

    Registry-First Profiling (v2.13.12)

    Die Konfigurationsauflösung folgt nun einer klaren Hierarchie:

    1. Frontmatter (höchste Priorität)
    2. types.yaml Typ-Config
    3. Global Defaults

    Impact:

    • Note-Typen wie value erhalten automatisch das korrekte Profil (structured_smart_edges_strict)
    • Keine manuellen Overrides mehr nötig für Standard-Typen
    • Konsistente Metadaten in Qdrant

    🔧 Verbesserungen

    Extraction & Parsing

    • Multi-line Callout-Blocks: Korrekte Verarbeitung von mehrzeiligen [!edge] Callouts
    • Robuste Fallbacks: "Headless" Blocks werden korrekt behandelt
    • Liberalisierte Regex: Unterstützung für Umlaute und Sonderzeichen in Link-Targets

    Format-agnostische De-Duplizierung

    • Kanten werden unabhängig vom Format (Inline, Callout, Wikilink) erkannt
    • Verhindert Dopplungen, wenn Kanten bereits via [!edge] Callout vorhanden sind
    • Ziel-basierte Prüfung statt String-Match

    Deterministic Hashing

    • full-Hash inkludiert strategische Parameter (split_level, strict_heading_split)
    • Konfigurationsänderungen im Frontmatter lösen zwingend Re-Import aus
    • Zuverlässigere Change Detection

    🐛 Bugfixes

    • ✅ Behoben: Mehrere Links zur gleichen Note in einem Callout-Block wurden zu einer Kante gemergt
    • ✅ Behoben: "Phantom-Knoten" durch Einbeziehung des Anchors in target_id
    • ✅ Behoben: Redundante [[rel:...]] Links in Chunks
    • ✅ Behoben: Inkonsistente Metadaten in Qdrant durch fehlerhafte Profil-Auflösung
    • ✅ Behoben: TypeError durch Parameter-Mismatch zwischen Orchestrator und Strategien

    ⚠️ Breaking Changes & Migration

    Migration erforderlich

    WICHTIG: Nach dem Update auf v2.9.1 ist ein vollständiger Re-Import erforderlich:

    python3 -m scripts.import_markdown --vault ./vault --prefix "mindnet" --apply --force

    Warum?

    • Behebt "Phantom-Knoten" durch korrekte Aufteilung von [[Note#Section]] Links
    • Konsolidiert Edge-Struktur mit neuem target_section Feld
    • Aktualisiert Chunking basierend auf Atomic Section Logic

    Was passiert beim Re-Import?

    • Alle bestehenden Links werden neu geparst und in target_id + target_section aufgeteilt
    • Chunks werden mit neuer Atomic Section Logic neu generiert
    • Edge-Struktur wird konsolidiert (Multigraph-Support)

    Dauer: Abhängig von Vault-Größe (typischerweise 5-30 Minuten)

    📚 API-Änderungen

    EdgeDTO erweitert

    class EdgeDTO(BaseModel):
    # ... bestehende Felder ...
    target_section: Optional[str] = None  # Neu: Abschnitts-Name

    Impact für API-Consumer:

    • Graph-Endpunkte (/graph/{note_id}) enthalten nun target_section in Edge-Objekten
    • Frontend kann Section-Informationen für präzisere Visualisierung nutzen

    📖 Dokumentation

    Alle relevanten Dokumente wurden aktualisiert:

    • ✅ 03_tech_data_model.md: Edge Payload Schema mit target_section
    • ✅ 02_concept_graph_logic.md: Section-basierte Links & Multigraph-Support
    • ✅ 03_tech_ingestion_pipeline.md: Chunking-Strategien, Registry-First Profiling
    • ✅ 03_tech_api_reference.md: EdgeDTO mit target_section
    • ✅ 01_knowledge_design.md: Deep-Links dokumentiert
    • ✅ 00_glossary.md: Neue Begriffe ergänzt
    • ✅ 04_admin_operations.md: Migration-Hinweis

    🔄 Technische Details

    Geänderte Module

    Graph Topology:

    • app/core/graph/graph_utils.py: parse_link_target() für Section-Extraktion
    • app/core/graph/graph_derive_edges.py: target_section in Edge-Payload
    • app/core/graph/graph_extractors.py: Multi-line Callout-Parser

    Chunking:

    • app/core/chunking/chunking_strategies.py: Atomic Section Logic (v3.9.9)
    • app/core/chunking/chunking_propagation.py: Format-agnostische De-Duplizierung

    Ingestion:

    • app/core/ingestion/ingestion_processor.py: Registry-First Profiling (v2.13.12), Deterministic Hashing

    Database:

    • app/core/database/qdrant.py: Keyword-Index für target_section
    • app/core/database/qdrant_points.py: Explizites Durchreichen von target_section

    API:

    • app/models/dto.py: EdgeDTO mit target_section Feld (v0.6.7)

    Versionsnummern

    • Graph Topology: v2.9.1
    • Chunking Strategies: v3.9.9
    • Ingestion Processor: v2.13.12
    • API DTO: v0.6.7

    🚀 Upgrade-Pfad

    Für Administratoren

    1. Backup erstellen:

      docker stop qdrant
tar -czf qdrant_backup_$(date +%F).tar.gz ./qdrant_data
docker start qdrant

    2. Code aktualisieren:

      git pull origin main
source .venv/bin/activate
pip install -r requirements.txt

    3. Re-Import durchführen:

      python3 -m scripts.import_markdown --vault ./vault --prefix "mindnet" --apply --force

    4. Services neu starten:

      sudo systemctl restart mindnet-prod
sudo systemctl restart mindnet-ui-prod

    Für Entwickler

    • Keine Code-Änderungen erforderlich, wenn nur API genutzt wird
    • Frontend kann target_section Feld in Edge-Objekten nutzen (optional)

    📝 Bekannte Einschränkungen

    • Migration-Dauer: Große Vaults (>10.000 Notizen) können 30+ Minuten benötigen
    • Temporärer Speicher: Während des Re-Imports kann Qdrant-Speicher temporär ansteigen

    🙏 Danksagungen

    Diese Version wurde durch umfangreiche Code-Analyse und Dokumentationsprüfung ermöglicht. Besonderer Fokus lag auf:

    • Konsistenz zwischen Code und Dokumentation
    • Vollständige Abdeckung aller Rollen (Entwickler, Administratoren, Anwender, Tester, Deployment)
    • Klare Migration-Pfade

    Vollständige Changelog: Siehe Git-Commits für detaillierte Änderungen
    Support: Bei Fragen zur Migration siehe Admin Operations Guide

    Downloads
  • v.2.9.1-WP14_WP19b 23b1cb2966
    Compare

    2.9.1 – "The Modular Leap"
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 4s
    Details
    Stable

    Lars released this 2025-12-27 22:17:29 +01:00 | 176 commits to main since this release

    Release Note v2.9.1 – "The Modular Leap"

    Release-Datum: 2025-12-27
    Status: Stable
    Workpackages: WP-14, WP-15b

    Zusammenfassung

    Mindnet v2.9.1 stellt einen Meilenstein in der Wartbarkeit und Intelligenz des Systems dar. Durch die vollständige Modularisierung der Kern-Komponenten wurde das Fundament für zukünftige agentische Features gelegt. Die neue Two-Pass Ingestion garantiert eine bisher unerreichte Präzision bei der automatischen Vernetzung von Wissen.

    Highlights

    1. Architektur-Modularisierung (WP-14)

    • Domain-Driven Design: Die Geschäftslogik wurde in vier Pakete (database, ingestion, retrieval, graph) separiert, was die Testbarkeit und Entkopplung massiv erhöht.
    • Registry-Pattern: Eine zentrale registry.py fungiert als Single Source of Truth für Typen und Textbereinigungen, wodurch kritische Import-Schleifen beseitigt wurden.
    • Legacy-Support: Dank neu eingeführter Proxy-Bridges bleiben bestehende Integrationen und API-Endpunkte voll funktionsfähig.

    2. Two-Pass Ingestion & Smart Edges (WP-15b)

    • Globaler Kontext-Cache: In einem initialen Pre-Scan (Pass 1) erfasst das System Metadaten und Summaries des gesamten Vaults.
    • Präzisions-Validierung: Chunks werden nun nicht mehr "blind" analysiert, sondern die KI validiert Link-Kandidaten semantisch gegen den globalen LocalBatchCache.
    • Integrität: Halluzinationen bei Kanten-Typen werden durch striktes Registry-Enforcement unterbunden.

    3. Mathematisches Scoring (WP-22 Integration)

    • Die Scoring-Engine wurde isoliert und berechnet die Relevanz nun präzise basierend auf dem Lifecycle-Status (stable/draft) und dynamischen Intent-Boosts.

    Technische Details

    • Datenmodell: Unterstützung für Multi-Hashes (Body/Full) für hocheffiziente Change-Detection.
    • Datenbank: Einführung von Named Vectors Support via MINDNET_VECTOR_NAME Konfiguration.
    • Dokumentation: Vollständiges Update des Developer Guides und der technischen Referenzen auf v2.9.1 Stand.

    Hinweis: Ein Full Rebuild des Index mit python3 -m scripts.import_markdown --apply --force wird empfohlen, um von der neuen Kanten-Validierung zu profitieren.

    Downloads
  • v2.8.2-dynamicResilince d1a065fec8
    Compare

    v2.8.2 „Dynamic Resilience“ (WP20a)
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 4s
    Details
    Stable

    Lars released this 2025-12-26 17:25:23 +01:00 | 200 commits to main since this release

    🚀 Release Notes v2.8.2 „Dynamic Resilience“

    Status & Versionierung

    • Version: 2.8.2
    • Codename: Dynamic Resilience
    • Datum: 2025-12-26
    • Basis: WP-20 "Deep Resilience" (v2.8.1)

    💎 Zusammenfassung

    Das Release v2.8.2 überführt die in v2.8.1 eingeführten Stabilitäts-Fixes in eine vollständig konfigurierbare Ebene. Es entkoppelt die technischen Schutzmechanismen (Kontext-Drosselung, Timeouts) vom Quellcode und erlaubt eine feingranulare Steuerung über Umgebungsvariablen.

    🛠 Änderungen seit v2.8.1

    1. Dynamische Kontext-Drosselung (Chat API)

    Die Begrenzung des Kontext-Fensters für lokale LLM-Anfragen ist nicht länger statisch im Code verankert.

    • Implementierung: chat.py (v2.7.9) nutzt nun get_settings().MAX_OLLAMA_CHARS zur Laufzeit-Drosselung.
    • Flexibilität: Das Limit kann ohne Code-Änderung an die verfügbare Hardware (VRAM/RAM) angepasst werden.
    • Safety: Standardmäßig ist ein Sicherheitswert von 10.000 Zeichen hinterlegt, um decode: cannot decode batches Fehler zu verhindern.

    2. Synchronisierter LLM-Dispatch (v3.3.7)

    Der LLMService wurde final auf das "Fail-Fast"-Prinzip des Echtzeit-Chats optimiert.

    • Retry-Management: Strikte Beachtung des max_retries=0 Parameters bei Chat-Anfragen zur Vermeidung von kumulativen Timeouts.
    • Rate-Limit Sync: Die interne Cloud-Warteschleife (429 Handling) wird nun durch den max_retries Wert des Aufrufers begrenzt.
    • Memory Guard: Festschreibung von num_ctx: 8192 im Ollama-Payload zur Stabilisierung der lokalen Inferenz.

    3. Gehärtete Konfigurationsschicht (v0.6.7)

    Die zentrale Konfiguration wurde um neue Parameter und Validierungen erweitert.

    • Typ-Casting: Alle kritischen Performance-Parameter (TIMEOUT, RETRIES, WAIT) werden nun strikt in numerische Typen konvertiert.
    • Override-Support: load_dotenv(override=True) stellt sicher, dass manuelle Änderungen in der .env sofort nach dem Dienst-Neustart aktiv werden.

    ⚙️ Erforderliche Konfiguration (.env)

    Folgende Parameter müssen für die volle Funktionalität in der .env definiert sein:

    Variable Empfohlener Wert Zweck
    MAX_OLLAMA_CHARS 10000 Maximale Zeichenanzahl für Ollama-Kontext.
    MINDNET_LLM_TIMEOUT 60.0 Maximalzeit für API-Antworten (verhindert 300s Hänger).
    MINDNET_LLM_RATE_LIMIT_RETRIES 0 oder 1 Verhindert lange Cloud-Wartezeiten im Chat.
    MINDNET_LLM_MODEL phi3:stable Verweis auf das stabilisierte lokale Modell.

    📦 Deployment-Checkliste

    1. Docker: Sicherstellen, dass ulimits (nofile: 65535) in der docker-compose.yaml aktiv sind.
    2. Dateien: Einspielen von chat.py (v2.7.9), llm_service.py (v3.3.7) und config.py (v0.6.7).
    3. Restart: Ausführen von sudo systemctl restart mindnet-prod, um die Konfiguration neu zu laden.
    Downloads
  • v2.8.1-DeepResilienceMultiLLM f6f3213b84
    Compare

    Mindnet v2.8.1 "Deep Resilience" (WP20)
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 5s
    Details
    Stable

    Lars released this 2025-12-25 22:24:23 +01:00 | 207 commits to main since this release

    doc_type version codename date status
    release_notes 2.8.1 Deep Resilience 2025-12-25 active

    Release Notes: Mindnet v2.8.1 "Deep Resilience"

    Dieses Release markiert die Transformation von Mindnet von einem lokalen RAG-System zu einer hybriden Intelligenz-Plattform. Durch den Abschluss von Arbeitspaket WP-20 kombiniert das System nun die Verarbeitungsgeschwindigkeit globaler Cloud-Modelle mit der Ausfallsicherheit und Datensouveränität lokaler Infrastruktur.

    🚀 Strategische Highlights

    1. Hybride LLM-Landschaft & Provider-Kaskade

    Mindnet v2.8.1 führt eine intelligente Orchestrierung verschiedener KI-Provider ein:

    • Multi-Provider Support: Nahtlose Integration von OpenRouter (Mistral), Google Gemini und lokalem Ollama.
    • Bulletproof Prompt-Auflösung: Ein neues Kaskaden-System in get_prompt() garantiert die Rückgabe eines validen Strings durch automatisches Zurückfallen auf kompatible Templates (Aktiver Provider -> Gemini -> Ollama), was Systemabstürze (HTTP 500) verhindert.
    • Task-Mapping: Die Konfiguration erlaubt nun spezialisierte Modelle pro Aufgabe (z. B. Mistral für strukturierte Extraktion, Gemini für RAG-Chat mit großem Kontext).

    2. Deep Fallback Mechanismus (v2.11.14)

    Die Ingestion-Pipeline wurde grundlegend gehärtet, um inhaltliche Blockaden der Cloud zu umgehen:

    • Skeptische Ingestion: Das System validiert nun nicht mehr nur die JSON-Struktur, sondern prüft, ob die Cloud inhaltlich verwertbare Daten geliefert hat.
    • Silent Refusal Detection: Erkennt proaktiv, wenn Cloud-Provider (z. B. wegen Policy Violations wie "No data training") eine technisch erfolgreiche, aber inhaltlich leere Antwort senden.
    • Erzwungener lokaler Sprung: In solchen Fällen wird automatisch ein Deep Fallback auf Ollama ausgelöst. Dies stellt sicher, dass auch sensible oder "schwierige" Dokumente (z. B. Leitbilder, Protokolle) ihre strukturellen Kanten im Graphen erhalten.

    3. Speed Mode: Turbo Ingestion

    Die Nutzung von Cloud-Ressourcen ermöglicht eine massive Beschleunigung des Vault-Imports:

    • Holistische Extraktion: Das System verarbeitet bis zu 6.000 Zeichen Kontext pro Note für die KI-gestützte Kanten-Zuweisung.
    • Hintergrund-Drosselung: Ein globaler Semaphor begrenzt parallele Import-Tasks (MINDNET_LLM_BACKGROUND_LIMIT), um Cloud-Quoten zu schonen und lokale Hardware-Überlastung zu verhindern, während Chat-Anfragen priorisiert vorbeigeleitet werden.

    🛠️ Technische Details & Härtung

    LLM Service (v3.3.6)

    • Quoten-Resilienz: Automatisierte Erkennung von HTTP 429 (Rate-Limit) mit intelligentem Backoff (LLM_RATE_LIMIT_WAIT) und bis zu drei Cloud-Retries vor dem Ollama-Fallback.
    • API-Stabilität: Erzwungene Nutzung der v1-Version für die Google GenAI Integration zur Erhöhung der Zuverlässigkeit.

    Ingestion Pipeline (v2.11.14)

    • Mistral-safe Parsing: Der JSON-Extraktor bereinigt nun aktiv technische Steuerzeichen (<s>, </s>) und Framework-Tags ([OUT], [/OUT]).
    • Dictionary Recovery: Erweiterte Logik zur Rettung von Kanten-Listen aus verschachtelten JSON-Objekten (Suche nach Keys wie matches, results, edge_list).
    • Multi-Hash Logic: Präzise Änderungserkennung durch getrennte Hashes für body (Inhalt) und full (inkl. Metadaten) zur Vermeidung redundanter KI-Aufrufe.

    ⚙️ Neue Konfigurationsparameter (.env)

    Für den vollen Funktionsumfang von v2.8.1 müssen folgende Parameter in der Umgebung definiert sein:

    # Resilience & Fallback
LLM_FALLBACK_ENABLED=true             # Aktiviert den Sprung zu Ollama
MINDNET_LLM_RATE_LIMIT_WAIT=60        # Sekunden Wartezeit bei HTTP 429
MINDNET_LLM_RATE_LIMIT_RETRIES=3      # Anzahl der Cloud-Wiederholungsversuche

# Multi-LLM Mapping
MINDNET_LLM_PROVIDER=openrouter       # Globaler Standard-Provider
OPENROUTER_MODEL=mistralai/mistral-7b-instruct:free
GEMINI_MODEL=gemini-2.0-flash-lite-preview-02-05

    📖 Dokumentations-Status

    Folgende Dokumente wurden auf den Stand v2.8.1 aktualisiert:

    • 00_glossary.md: Definitionen für Deep Fallback und Silent Refusal hinzugefügt.
    • 02_concept_ai_personality.md: Konzept der hybriden Resilienz integriert.
    • 03_tech_chat_backend.md: Detaillierung der Prompt-Kaskade und Traffic-Control.
    • 03_tech_ingestion_pipeline.md: Dokumentation des 16-Schritte-Workflows inkl. Deep Fallback.
    • 06_active_roadmap.md: WP-20 als abgeschlossen markiert.

    Administrator-Hinweis:
    Durch die neue Deep-Fallback-Logik kann die Import-Dauer bei umfangreichen Vaults steigen, da blockierte Cloud-Anfragen nun geduldig lokal abgearbeitet werden. Dies ist ein gewollter Prozess zur Sicherstellung der Datenintegrität.

    Downloads
  • v2.7.0-Lifecycle_EdgeScoring 59bcd227f9
    Compare

    Release v2.7.0 – "The Quality & Lifecycle Update & Edge-Scoring
    All checks were successful
    Deploy mindnet to llm-node / deploy (push) Successful in 4s
    Details
    Stable

    Lars released this 2025-12-19 10:00:24 +01:00 | 260 commits to main since this release

    Release v2.7.0 – "The Quality & Lifecycle Update"

    Datum: 18.12.2024
    Status: Stable
    Fokus: Datenqualität, Vokabular-Management, Intelligentes Scoring

    Mit Version 2.7.0 führt Mindnet ein Bewusstsein für den "Reifegrad" von Wissen ein. Das System unterscheidet nun mathematisch zwischen flüchtigen Notizen und gefestigtem Wissen. Zudem beenden wir das Chaos unterschiedlicher Kanten-Bezeichnungen durch eine zentrale Registry.

    ✨ Neue Features

    🧠 Content Lifecycle Scoring

    Mindnet vertraut nicht mehr jedem Text gleich stark. Der Status im Frontmatter steuert die Relevanz:

    • Stable (status: stable): Erhält einen 20% Relevanz-Boost. Gefestigtes Wissen setzt sich gegen Rauschen durch.
    • Drafts (status: draft): Werden mit einem 50% Malus gedämpft. Sie sind findbar, dominieren aber nicht die Ergebnisse.
    • System-Filter: Templates und System-Configs werden nun komplett aus dem Suchindex herausgehalten ("Hard Skip").

    🔗 Central Edge Registry & Alias Support

    Schluss mit Fragmentierung (ursache, ausgelöst_durch, caused_by).

    • Single Source of Truth: Die Datei 01_edge_vocabulary.md definiert das Gesetz.
    • Auto-Translation: Schreiben Sie [[rel:fundament_von ...]] – das System speichert automatisch den kanonischen Typ based_on.
    • Quality Gate: Unbekannte Kanten-Typen werden automatisch geloggt (unknown_edges.jsonl), um das Vokabular organisch wachsen zu lassen.

    🎯 Dynamic Intent Boosting

    Der Retriever "versteht" jetzt die Intention der Frage besser.

    • Bei "Warum"-Fragen werden Kanten wie caused_by massiv verstärkt.
    • Bei "Wie"-Fragen rücken uses und solves Verbindungen in den Fokus.

    🛠 Technische Verbesserungen

    • Modularisierung: Die ScoringEngine ist nun ein eigenständiges Modul, was die Wartbarkeit erhöht.
    • Robustes Parsing: Verbesserte Regex-Erkennung für Markdown-Tabellen (unterstützt nun Fettdruck und Backticks).
    • Traffic Control: Optimierte Semaphore-Steuerung für Hintergrund-Prozesse.

    ⚠️ Migration Guide

    1. Environment aktualisieren:
      Fügen Sie Ihrer .env den Pfad zum Vokabular hinzu: 
      MINDNET_VOCAB_PATH=./vault_master/01_User_Manual/01_edge_vocabulary.md
    Downloads