266 lines
8.6 KiB
Markdown
266 lines
8.6 KiB
Markdown
# BRAIN ANALYSIS CENTER
|
|
|
|
Das technische Analyse-Dashboard ist von der animierten Gehirnansicht getrennt:
|
|
|
|
- Visualisierung: `http://localhost:8090/`
|
|
- Analyse: `http://localhost:8090/analysis.html`
|
|
- Kurzpfad: `http://localhost:8090/analysis`
|
|
|
|
## Zweck
|
|
|
|
Das Dashboard soll nicht nur einzelne Events anzeigen, sondern beantworten:
|
|
|
|
- Was hat ein Workflow tatsächlich bewirkt?
|
|
- Wie lange dauerte er und wo liegen P50/P95-Ausreißer?
|
|
- Wie viele Nodes, Edges oder Embeddings wurden erzeugt, verändert oder gelöscht?
|
|
- Wie teuer waren Artikel-, Research-, Security- und THINK-Läufe relativ zueinander?
|
|
- Wurde Research aus der Source Inbox wiederverwendet oder musste SearXNG arbeiten?
|
|
- Wie viele Security-Meldungen wurden materialisiert, verworfen oder sind fehlgeschlagen?
|
|
- Welche Claims hat der Article Reviewer unterstützt, nur teilweise gestützt, verworfen oder als widersprüchlich bewertet?
|
|
- Ist die Analysehistorie vollständig genug oder wurde sie von Telemetrie-/Queue-Limits beschnitten?
|
|
|
|
## Persistentes Auditprotokoll
|
|
|
|
Die Historie liegt in `BRAIN_DATA_DIR/graph.db`:
|
|
|
|
```text
|
|
analysis_events
|
|
analysis_points
|
|
analysis_changes
|
|
```
|
|
|
|
`analysis_events` enthält Aktivitäten und Metadaten. `analysis_points` speichert den dazugehörigen Graphzustand und exakte Mutation-Deltas. `analysis_changes` enthält die konkreten Node-, Edge- und Vector-Änderungen.
|
|
|
|
Die Rohhistorie wird 90 Tage aufbewahrt. Detailänderungen sind pro Event auf 2.000 Datensätze begrenzt; die aggregierten Mutation-Zähler bleiben auch bei Kürzung vollständig.
|
|
|
|
## Event-Hygiene
|
|
|
|
Hochfrequente Hintergrundtelemetrie darf fachlich relevante Läufe nicht aus dem Analysefenster verdrängen.
|
|
|
|
### Unveränderte KB-Scans
|
|
|
|
`learning.scan.started` wird nicht mehr separat persistiert. Ein `learning.scan.completed` mit `result=unchanged` und ohne Graphänderung wird gesammelt. Standardmäßig werden bis zu 15 solcher Läufe beziehungsweise maximal fünf Minuten zu einem Event verdichtet:
|
|
|
|
```text
|
|
learning.scan.unchanged.aggregate
|
|
```
|
|
|
|
Das Aggregate enthält unter anderem:
|
|
|
|
- exakte Anzahl der Scan-Läufe,
|
|
- äquivalente Zahl früherer Roh-Events,
|
|
- First/Last Timestamp,
|
|
- Gesamt-, Durchschnitts-, Minimal- und Maximallaufzeit,
|
|
- Zahl der geprüften Wissenselemente,
|
|
- Ollama-Status.
|
|
|
|
### Embedding-Batches
|
|
|
|
Repetitive `embedding.batch`-Fortschrittsereignisse werden ebenfalls verdichtet. Bis zu 16 Batch-Events beziehungsweise maximal 60 Sekunden werden zu
|
|
|
|
```text
|
|
embedding.batch.aggregate
|
|
```
|
|
|
|
zusammengefasst. Anders als bei reiner Telemetrie bleiben hierbei die Mutation-Deltas erhalten: Vector-Created/Updated/Deleted werden exakt aufsummiert und vorhandene Detailänderungen in das Aggregate übernommen.
|
|
|
|
### Bestehende Datenbanken
|
|
|
|
Alte Rohdaten werden nicht gelöscht oder umgeschrieben. Beim Lesen des Dashboards werden historische unveränderte Scans und historische Embedding-Batches zusätzlich virtuell verdichtet. Dadurch wird eine bestehende `graph.db` sofort übersichtlicher.
|
|
|
|
Der Bereich **Analysequalität / Event-Hygiene** zeigt:
|
|
|
|
- persistierte Events,
|
|
- tatsächlich geladene aussagekräftige Events,
|
|
- verdichtete No-op-Scans,
|
|
- verdichtete Embedding-Batches,
|
|
- durch die neue Persistenz künftig vermiedene Roh-Events,
|
|
- ausgelassene Events durch das Anzeige-Limit,
|
|
- Audit-Queue-Fehler oder verworfene Detailänderungen.
|
|
|
|
## Laufmodell
|
|
|
|
Zusammengehörige Events werden zu Workflows gruppiert. Unterstützt werden unter anderem:
|
|
|
|
- `learning`
|
|
- `thinking`
|
|
- `research`
|
|
- `autonomous-research`
|
|
- `security-source`
|
|
- `article`
|
|
- `query`
|
|
- `searxng-test`
|
|
- Persistenz-/Synchronisationsaktionen
|
|
|
|
### Article Pipeline
|
|
|
|
Ein Artikellauf beginnt bei `article.plan.started` und endet bei einem Terminal-Event wie:
|
|
|
|
```text
|
|
article.created
|
|
article.draft.rejected
|
|
article.failed
|
|
article.duplicate
|
|
article.skipped
|
|
article.plan.skipped
|
|
```
|
|
|
|
Zwischenereignisse wie Draft, Rewrite, Inbox Research, SearXNG Research, Revision und Review werden demselben Lauf zugeordnet.
|
|
|
|
### Security Source Pipeline
|
|
|
|
Neue proactive Security-Verarbeitung erzeugt einen echten Lifecycle:
|
|
|
|
```text
|
|
source.security.started
|
|
-> source.security.research optional
|
|
-> source.security.materialized
|
|
| source.security.rejected
|
|
| source.security.failed
|
|
```
|
|
|
|
Die Terminal-Events enthalten `duration_ms`. Damit sind ab dieser Version echte Laufzeitstatistiken für Security-Materialisierung möglich. Ältere bereits materialisierte Security-Nodes bleiben in den Zählern sichtbar, besitzen aber rückwirkend keine rekonstruierbare Startzeit.
|
|
|
|
### Research Lifecycle
|
|
|
|
Nur Root-Events öffnen oder schließen einen Research-Lauf:
|
|
|
|
```text
|
|
research.started / completed / failed
|
|
article.research.started / completed / failed
|
|
```
|
|
|
|
Fetch-, Ranking-, Material- und Evidence-Events sind Unterereignisse. Doppelte native Run-IDs erzeugen keinen zweiten aktiven Prozess. Historische Relationsrecherchen ohne Terminal-Event können nach einer Grace-Period als Legacy-Abschluss rekonstruiert werden.
|
|
|
|
## Workflow-Kosten
|
|
|
|
Der Bereich **Ressourcen / Laufzeit** aggregiert pro Workflow-Typ:
|
|
|
|
- Anzahl Läufe,
|
|
- Success/Warning/Error/Running,
|
|
- Anzahl Events,
|
|
- summierte Graphmutationen,
|
|
- Gesamtzeit,
|
|
- Durchschnitt,
|
|
- P50,
|
|
- P95,
|
|
- Maximum.
|
|
|
|
Die Gesamtzeit ist eine aufsummierte Workflow-Zeit und bei parallelen Läufen nicht mit Wall-Clock-Zeit gleichzusetzen.
|
|
|
|
Das Laufprotokoll kann sortiert werden nach:
|
|
|
|
- neueste zuerst,
|
|
- langsamste zuerst,
|
|
- meiste Graphänderungen,
|
|
- meiste Events.
|
|
|
|
## Pipeline-Bilanzen
|
|
|
|
### Security Pipeline
|
|
|
|
Das Dashboard zeigt separat:
|
|
|
|
- materialisierte Meldungen,
|
|
- verworfene Meldungen,
|
|
- Fehler,
|
|
- Zusatzrecherchen,
|
|
- ergänzende Quellen,
|
|
- durchschnittliche Gemma-Konfidenz,
|
|
- Severity-Verteilung,
|
|
- Security-Eventtyp-Verteilung,
|
|
- letzte Security-Läufe samt Dauer und Mutationen.
|
|
|
|
### Article Pipeline
|
|
|
|
Separat dargestellt werden:
|
|
|
|
- erzeugte Artikel,
|
|
- Reviews,
|
|
- Rejections/Failures,
|
|
- Duplicates/Skips,
|
|
- Source-Inbox-Treffer,
|
|
- Web-Fetches,
|
|
- supported / partially-supported / unsupported / contradicted Claims,
|
|
- letzte Artikelläufe.
|
|
|
|
## Änderungssemantik
|
|
|
|
### Nodes
|
|
|
|
- `created`: neue Node-ID wurde aufgenommen.
|
|
- `updated`: vorhandene Node wurde mit geändertem Inhalt ersetzt.
|
|
- `deleted`: Node ist aus einer verwalteten Quelle verschwunden.
|
|
|
|
### Edges
|
|
|
|
- `created`: neue Relation wurde aufgenommen.
|
|
- `updated`: Typ, Status, Confidence, Evidenz oder Metadaten wurden verändert.
|
|
- `deleted`: Relation wurde entfernt.
|
|
|
|
### Vektoren
|
|
|
|
- `created`: Node erhielt erstmals ein Embedding.
|
|
- `recalculated`: vorhandenes Embedding wurde ersetzt.
|
|
- `deleted`: Vektor wurde invalidiert oder der Node entfernt.
|
|
|
|
## Queue-Diagnostik
|
|
|
|
Die Ollama-/Research-Zusammenfassung zeigt neben Active/Waiting auch Operationstypen wie:
|
|
|
|
```text
|
|
searxng.search
|
|
web.fetch
|
|
ollama.chat
|
|
ollama.embedding
|
|
```
|
|
|
|
Damit lässt sich unterscheiden, ob Arbeit wirklich ausgeführt wird oder nur auf GPU-/Queue-Kapazität wartet.
|
|
|
|
## HTTP-API
|
|
|
|
```text
|
|
GET /api/analysis/dashboard?hours=24&limit=400
|
|
GET /api/analysis/export?hours=24&limit=1000
|
|
```
|
|
|
|
`hours` ist auf 1 bis 2.160 Stunden begrenzt. `limit` ist auf maximal 1.000 Events/Läufe begrenzt. Der Dashboard-JSON-Export verwendet standardmäßig 1.000, damit Diagnoseexporte deutlich mehr Workflow-Kontext enthalten.
|
|
|
|
Neue History-Bereiche:
|
|
|
|
```json
|
|
{
|
|
"history": {
|
|
"event_selection": {},
|
|
"run_stats": [],
|
|
"pipelines": {
|
|
"security": {},
|
|
"articles": {}
|
|
},
|
|
"runs": [],
|
|
"events": [],
|
|
"changes": [],
|
|
"timeline": []
|
|
}
|
|
}
|
|
```
|
|
|
|
## Performance
|
|
|
|
Die Analyseaufzeichnung bleibt außerhalb des Engine-Hotpaths:
|
|
|
|
1. Graphmutationen aktualisieren konstante Zähler und begrenzte Detaildaten.
|
|
2. Activities übernehmen nur einen billigen Graphcheckpoint.
|
|
3. Hintergrundtelemetrie wird vor der SQLite-Persistenz verdichtet.
|
|
4. Audit-Records werden asynchron und gebündelt geschrieben.
|
|
5. Die aufwendige strukturelle Graphanalyse wird erst beim Öffnen des Dashboards berechnet und nach Graphversion gecacht.
|
|
6. Die animierte Gehirnansicht lädt die Analysehistorie nicht.
|
|
|
|
Es sind für die Observability-V2-Änderungen keine neuen ENV-Variablen erforderlich.
|
|
|
|
## Production Readiness v1
|
|
|
|
Das Dashboard unterscheidet jetzt globale Timeline-Deltas von kausal einem Workflow zugeordneten Mutationen. Bei Parallelität wird eine unbekannte Kausalität ausdrücklich als „nicht kausal gemessen“ angezeigt statt fremde Graphänderungen einem offenen Run zuzuschreiben. Security-Runs werden zusätzlich mit dem autoritativen Source-Inbox-Lifecycle reconciled.
|
|
|
|
Der Bereich **Produktionsreife** prüft Startup-Bootstrap, Audit-Verlust, Embedding-Coverage/-Dimension, Scan-Cadence, Persistenz, Ollama/Artikelmodelle, SearXNG, Agenten, Source-Inbox↔Graph und die Security-Run-Rekonstruktion. Rot ist ein Betriebsblocker; Gelb ist ein plausibler Übergangs- oder Tuningzustand.
|