113 lines
6.0 KiB
Markdown
113 lines
6.0 KiB
Markdown
---
|
||
doc_type: archive
|
||
audience: historian, architect
|
||
status: archived
|
||
context: "Archivierte Details zu abgeschlossenen Workpackages (WP01-WP19). Referenz für historische Design-Entscheidungen."
|
||
---
|
||
|
||
# Legacy Workpackages (Archiv)
|
||
|
||
**Quellen:** `Programmplan_V2.2.md`, `Active Roadmap`
|
||
|
||
**Status:** Abgeschlossen / Implementiert.
|
||
Dieses Dokument dient als Referenz für die Entstehungsgeschichte von Mindnet v2.6.
|
||
|
||
## Phase A: Fundament (WP01-03)
|
||
|
||
### WP-01 – Wissensdesign
|
||
* **Ziel:** Definition der Datenstruktur.
|
||
* **Ergebnis:** Entscheidung gegen komplexe Ontologien (RDF/OWL), für pragmatische Typen (`project`, `concept`). Definition der YAML-Frontmatter-Pflichtfelder.
|
||
* **Artefakt:** `01_knowledge_design.md`.
|
||
|
||
### WP-02 – Chunking & Hash-Strategie
|
||
* **Ziel:** Texte suchbar machen und Änderungen erkennen.
|
||
* **Ergebnis:** Implementierung des `SlidingWindowChunker`. Einführung von UUIDv5 für deterministische IDs.
|
||
* **Learning:** Starre Chunking-Grenzen zerschneiden oft den Kontext. Daher Einführung von Overlap (50 Tokens).
|
||
|
||
### WP-03 – Import-Pipeline & Edge-System
|
||
* **Ziel:** Markdown in Vektoren wandeln.
|
||
* **Ergebnis:** Der "Importer" (`import_markdown.py`). Entscheidung, Kanten (`_edges`) als eigene Collection zu führen statt als Payload in Chunks (für bessere Graphen-Algorithmen wie Centrality).
|
||
|
||
---
|
||
|
||
## Phase B: Semantik (WP04)
|
||
|
||
### WP-04a – Retriever & Graph-Scoring
|
||
* **Ziel:** Bessere Suchergebnisse als reines Vektor-Matching.
|
||
* **Ergebnis:** Die Formel `Score = Semantik + GraphBonus + TypGewicht`.
|
||
* **Learning:** Reine Vektorsuche reichte nicht, um den Kontext ("Warum ist das wichtig?") zu erfassen. Der "Graph Bonus" war der Durchbruch für assoziatives Finden.
|
||
|
||
### WP-04b – Explanation Layer ("Why-Layer")
|
||
* **Ziel:** Transparenz.
|
||
* **Ergebnis:** `explain=True` Parameter. Die API liefert menschenlesbare Gründe ("Gefunden, weil Projekt Alpha davon abhängt").
|
||
|
||
### WP-04c – Feedback Logging
|
||
* **Ziel:** Datenbasis für zukünftiges Lernen schaffen.
|
||
* **Ergebnis:** Das "Data Flywheel". Jede Suche und Bewertung wird in JSONL-Dateien geloggt (`search_history.jsonl`, `feedback.jsonl`).
|
||
|
||
---
|
||
|
||
## Phase C: Persönlichkeit (WP05-07)
|
||
|
||
### WP-05 – RAG-Chat
|
||
* **Ziel:** Natürliche Sprache statt Suchergebnisse.
|
||
* **Ergebnis:** Integration von Ollama (`phi3`).
|
||
* **Tech:** Prompt-Engineering (`prompts.yaml`) statt Fine-Tuning, um flexibel zu bleiben.
|
||
|
||
### WP-06 – Decision Engine
|
||
* **Ziel:** Strategische Beratung statt nur Fakten.
|
||
* **Ergebnis:** Der Hybrid Router.
|
||
* **Konzept:** Unterscheidung von *Fragen* (RAG) und *Handlungen* (Interview). Strategisches Laden von Werten (`type: value`), um Entscheidungen moralisch zu begründen.
|
||
|
||
### WP-07 – Interview-Assistent
|
||
* **Ziel:** Bekämpfung des "Writer's Block".
|
||
* **Ergebnis:** One-Shot Extraction. Der Chatbot generiert aus einem losen Satz ("Neues Projekt Alpha") einen strukturierten Markdown-Draft.
|
||
|
||
---
|
||
|
||
## Phase D: Interaktion (WP10-15)
|
||
|
||
### WP-10/10a – Web UI & Draft Editor
|
||
* **Ziel:** Usability für Nicht-Techniker.
|
||
* **Ergebnis:** Streamlit App. Ablösung des Terminals.
|
||
* **Feature:** "Healing Parser", der defektes JSON vom LLM repariert.
|
||
|
||
### WP-11 – Backend Intelligence
|
||
* **Ziel:** Automatisierung der Vernetzung.
|
||
* **Ergebnis:** AsyncIO Umstellung für Performance. Einführung von `nomic-embed-text` (768d) für präzise Semantik. Matrix-Logik für automatische Kanten-Typisierung.
|
||
|
||
### WP-15 – Smart Edge Allocation (Meilenstein)
|
||
* **Problem:** "Broadcasting". Ein Chunk erbte alle Links der Note, auch irrelevante. Das verwässerte die Suchergebnisse.
|
||
* **Lösung:** LLM prüft jeden Chunk auf Link-Relevanz.
|
||
* **Tech:** Einführung von **Traffic Control** (Semaphore), um Import und Chat zu parallelisieren, ohne die Hardware zu überlasten.
|
||
|
||
---
|
||
|
||
## Phase E: Visualisierung & Maintenance (WP19)
|
||
|
||
### WP-19 – Graph Visualisierung & Modularisierung
|
||
* **Ziel:** Transparenz über die Datenstruktur schaffen und technische Schulden (Monolith) abbauen.
|
||
* **Ergebnis:**
|
||
* **Modularisierung:** Aufsplittung der `ui.py` in Router, Services und Views (`ui_*.py`).
|
||
* **Graph Explorer:** Einführung von `st-cytoscape` für stabile, nicht-überlappende Layouts (COSE) als Ergänzung zur Legacy-Engine (Agraph).
|
||
* **Single Source of Truth:** Der Editor lädt Inhalte nun direkt vom Dateisystem statt aus (potenziell veralteten) Vektor-Payloads.
|
||
* **UX:** Einführung von URL-Persistenz für Layout-Settings und CSS-basiertes Highlighting zur Vermeidung von Re-Renders.
|
||
|
||
|
||
## Phase E+: Architektur-Konsolidierung (WP-14)
|
||
|
||
### WP-14 – Modularisierung & Paket-Struktur
|
||
* **Ziel:** Auflösung technischer Schulden und Beseitigung von Zirkelbezügen (Circular Imports).
|
||
* **Ergebnis:**
|
||
* **Domänen-Pakete:** Aufteilung der monolithischen `app/core/` Struktur in spezialisierte Pakete: `database/`, `ingestion/`, `retrieval/` und `graph/`.
|
||
* **Proxy-Pattern:** Einsatz von Fassaden-Modulen (z. B. `graph_adapter.py`) zur Aufrechterhaltung der Abwärtskompatibilität für bestehende API-Endpunkte.
|
||
* **Registry-Zentralisierung:** Auslagerung neutraler Hilfsfunktionen (wie `clean_llm_text`) in eine unabhängige `registry.py`, um Abhängigkeitsschleifen zwischen Diensten zu brechen.
|
||
* **Tech:** Einführung von `__init__.py` Exporten zur Definition sauberer Paket-Schnittstellen.
|
||
|
||
### WP-15b – Two-Pass Ingestion & Candidate Validation
|
||
* **Problem:** Die ursprüngliche Smart Edge Extraktion (WP-15) war teuer und neigte zu Halluzinationen, da sie ohne globalen Kontext operierte.
|
||
* **Lösung:** Implementierung eines **Two-Pass Workflows**.
|
||
* **Pass 1 (Pre-Scan):** Schnelles Einlesen aller Notizen zur Erstellung eines `LocalBatchCache` (Metadaten & Summaries).
|
||
* **Pass 2 (Processing):** Gezielte semantische Verarbeitung nur für geänderte Dateien.
|
||
* **Feature:** **Binary Validation Gate**. Statt Kanten frei zu erfinden, validiert das LLM nun Kanten-Kandidaten aus einem Pool gegen den Kontext des `LocalBatchCache`. Dies garantiert 100% Konformität mit der Edge Registry.
|
||
* **Ergebnis:** Höhere Geschwindigkeit durch Reduktion komplexer LLM-Prompts auf binäre Entscheidungen (VALID/INVALID). |