jbergner
b4388d1ebc
All checks were successful
release-tag / release-image (push) Successful in 2m30s
71 lines
4.2 KiB
Markdown
71 lines
4.2 KiB
Markdown
# Architektur und Vertrauensgrenzen
|
||
|
||
```text
|
||
Lokale Knowledge-JSONs ──ro──┐
|
||
GLPI Knowledge Base ─────ro──┼──► Ingest ─► In-Memory Graph + Float32 Vectors
|
||
Agent runs.jsonl ─────────ro──┘ │
|
||
├──► Ollama Pool
|
||
├──► Relation Thinking
|
||
├──► Knowledge Consolidation / Research / Synthesis
|
||
├──► SSE / Hierarchical LOD UI
|
||
└──► Batched Persistence
|
||
├── staging drafts
|
||
├── article metadata sidecars
|
||
├── GLPI cache
|
||
└── SQLite/WAL graph.db
|
||
```
|
||
|
||
## Edge-Klassen
|
||
|
||
- `categorized_as`, `mentions`, `derived_from`: deterministisch aus lokalen oder GLPI-Daten.
|
||
- `research_evidence`: aus explizit kontrollierter Recherche, weiterhin `staging`.
|
||
- `related_to`, `depends_on`, `supports`, `contradicts`, `extends`, `same_topic`, `caused_by`: Qwen-Inferenz mit Confidence und Evidence.
|
||
- `rejected`: intern gespeicherte Prüfung ohne sichtbare Beziehung.
|
||
|
||
## Mehrstufiges Thinking
|
||
|
||
```text
|
||
Kandidatenpaar
|
||
└── Relation Thinking
|
||
├── rejected edge
|
||
└── staging edge
|
||
└── Quellenverbund (3–8 Quellen)
|
||
└── Artikelplanung: create / update / merge / skip
|
||
└── fachliche Wissenskonsolidierung
|
||
├── belegte Fakten und Arbeitsschritte
|
||
├── Widersprüche und Wissenslücken
|
||
└── sequenzielle Recherche
|
||
└── erneute Konsolidierung
|
||
└── reine Artikelgenerierung
|
||
├── KB-Staging-Datei
|
||
├── Metadaten-Sidecar
|
||
├── Embedding
|
||
└── Quellen- und Recherche-Edges
|
||
```
|
||
|
||
Relation Thinking schreibt keine Artikel. Die sichtbare KB-Datei enthält ausschließlich das reguläre KB-Schema. Interne Planung, Bewertung, Confidence, Quellen-IDs und Rechercheprotokolle werden getrennt unter `BRAIN_DATA_DIR/article-metadata/` gespeichert. Der Entwurf wird sofort als In-Memory-Node sichtbar, eingebettet und mit `synthesized_from` beziehungsweise `grounded_by` verknüpft; die Festplattenschreibvorgänge bleiben gebündelt.
|
||
|
||
## Schreibmodell
|
||
|
||
Produktive Knowledge-Dateien und GLPI sind read-only. AI-THINK wird nur in das konfigurierte Staging geschrieben. Ein prozessweiter Coordinator dedupliziert Dateischreibvorgänge und schreibt sie seriell vor der Graphtransaktion.
|
||
|
||
Der Graph Store verwendet `modernc.org/sqlite` über `database/sql`. Nodes, Edges und binäre Float32-Vektoren werden nur bei Änderungen geschrieben. WAL erlaubt eine kompakte laufende Journaldatei; der Export-Endpunkt erzeugt mit `VACUUM INTO` eine portable Einzeldatei ohne WAL-Sidecars.
|
||
|
||
## Ollama-Pool
|
||
|
||
Chat- und Embeddingaufrufe werden als vollständige Requests geroutet. Healthchecks prüfen Erreichbarkeit und Modelle. Ein Per-Node-Inflight-Limit verhindert lokale Überlastung. Failover verändert keine produktiven Daten, da Schreiboperationen erst nach erfolgreicher Inferenz deterministisch ausgeführt werden.
|
||
|
||
## Hierarchische Render-Schicht
|
||
|
||
Der persistierte Wissensgraph bleibt vollständig. Das Frontend leitet eine temporäre LOD-Struktur ab:
|
||
|
||
```text
|
||
Full Graph
|
||
└── Cortex-Region
|
||
└── Themenwolke
|
||
└── lokale Gruppe
|
||
└── einzelner Wissensknoten
|
||
```
|
||
|
||
Außenkanten werden nach sichtbaren Endpunkten, Relationstyp, Richtung, Herkunft und Status aggregiert. Aktivität öffnet nur den betroffenen Hierarchiepfad.
|