# Adaptive Artikelpipeline

Der `clustered`-Betrieb verwendet ab dieser Version standardmäßig eine bedarfsgesteuerte Artikelpipeline. Ziel ist, Web-, Modell- und Grapharbeit erst dann auszuführen, wenn sie für den konkreten Artikel einen messbaren Nutzen hat.

## Ablauf

```text
Relation(en)
   │
   ├─ Cluster/Fast: thematisch kompatible Relationen eines THINK-Zyklus bündeln
   │
   ▼
interne KB-Quellen auswählen
   │
   ├─ unveränderter Work-Fingerprint? ── ja ──> sofort überspringen
   │
   ▼
Artikelplan
   │
   ├─ nur 2 kohärente Quellen für how_to/troubleshooting? ──> Gap-Research
   │
   ▼
Aktualitätsdetektor
   │
   ├─ aktuelle Version/CVE/Support/Preis/Live-Status? ──> kleine SearXNG-Runde
   │
   └─ statisches Thema ──> kein Web
   │
   ▼
Gemma / Autor schreibt intern-first
   │
   ├─ <3 Lösungsschritte oder keine Validierung? ──> feldgerichtete Webrunde + Neufassung
   ├─ research_needed / freshness_sensitive? ──> kleine gezielte Webrunde + Neufassung
   │
   ▼
Qwen / Reviewer prüft den fertigen Text Claim für Claim
   │
   ├─ unbelegte Claims? ──> gezielte Repair-Recherche + Revision
   │
   ▼
Artikel akzeptiert
   │
   ├─ nur vom Reviewer tatsächlich zitierte Webquellen materialisieren
   └─ Work-/Source-Fingerprint persistieren
```

## Warum Gemma nicht in einem separaten Vorab-Call gefragt wird

Ein eigener LLM-Aufruf nur für die Frage „brauche ich Webrecherche?“ würde bei jedem Artikel zusätzliche GPU-Zeit verbrauchen. Stattdessen erledigt der erste normale Gemma-Draft beides gleichzeitig. Das Antwortschema besitzt unsichtbare interne Routing-Felder:

- `research_needed`
- `research_queries`
- `freshness_sensitive`
- `research_reason`

Diese Felder erscheinen niemals im sichtbaren KB-Artikel. Wenn die internen Quellen ausreichen, bleibt die Pipeline ohne Webzugriff. Zusätzlich zu Gemmas Routingfeldern kann der deterministische Task-Completeness-Guard Recherche auslösen: Ein `how_to`/`troubleshooting` mit weniger als drei konkreten Schritten oder ohne Validierung gilt als Evidenzlücke. Findet bereits der Planner nur zwei kohärente interne Quellen, werden ebenfalls gezielte Gap-Queries erzeugt, statt den Auftrag sofort zu verwerfen.

## Aktualitätsdetektor

Der Aktualitätsdetektor ist deterministisch und benötigt keinen Modellaufruf. Er reagiert bewusst nur auf klare zeitabhängige Signale, z. B.:

- aktuell/neueste/heute/derzeit;
- aktuelle oder unterstützte Versionen, Support-Matrix, EOL;
- CVE, Security Advisory, aktueller Patch-/Firmwarestand;
- aktuelle Preise/Lizenzstände;
- Outages, Statusseiten, laufende Vorfälle.

Ein statisches Thema wie „Least Privilege unter Windows konfigurieren“ löst allein wegen des Wortes Windows oder einer Versionsnennung in einer Quelle keine automatische Webrunde aus.

## Recherchemodi

```env
BRAIN_ARTICLE_RESEARCH_STRATEGY=auto
```

- `auto`: `precise` verwendet `always`, `clustered` verwendet `adaptive`.
- `always`: breites Webmaterial vor dem ersten Draft wie im bisherigen Generate-then-Review-Pfad.
- `adaptive`: intern/Gemma-first; Web bei Aktualität, Planner-Gap, fehlenden operationalen Schritten/Validierung, Autor-Evidenzbedarf oder Reviewer-Gap.
- `review_only`: kein initiales Web; ausschließlich der Reviewer darf Nachrecherche auslösen.

Budget für die erste adaptive Runde:

```env
BRAIN_ARTICLE_ADAPTIVE_INITIAL_QUERIES=2
BRAIN_ARTICLE_ADAPTIVE_INITIAL_FETCH=3
```

Im `adaptive`-Modus ist auch Reviewer-Repair auf höchstens drei Queries begrenzt und verwendet dasselbe kleine Fetch-Budget pro Query.

## Delayed Graph Materialization

Frisch geladene Webvolltexte werden zunächst ausschließlich unter `research-evidence/` persistiert. Sie erzeugen noch keine `external`-Nodes, Embeddings oder `research_evidence`-Fan-out-Edges.

Erst wenn der finale Reviewer einen `supported`- oder `partially_supported`-Claim auf eine konkrete Webquelle zurückführt und der Artikel akzeptiert wird:

1. wird die Quelle als `external`-Node materialisiert;
2. wird sie eingebettet;
3. erhält der Artikel eine `grounded_by`-Edge;
4. wird `validation_state=grounded` gesetzt.

Damit ist „recherchiert“ nicht mehr gleich „dauerhaftes Graphwissen“.

## Reviewer-Provenienz

Im Cluster-Modus sieht der Reviewer nur einen priorisierten Teil des Research-Pools. Die Referenzen `R1`, `R2`, … werden jetzt gegen genau diesen an den Reviewer übergebenen Teilpool aufgelöst. Zuvor konnten `R<n>` gegen den vollständigen Research-Pool interpretiert werden; dadurch war Grounding trotz verwendeter Quellen unterzählbar oder falsch zugeordnet.

## Artikel-Batching

```env
BRAIN_CLUSTER_ARTICLE_BATCHING=true
```

Im Cluster-Modus werden die akzeptierten Relationen eines THINK-Zyklus zunächst thematisch gruppiert. Relationen mit gemeinsamem Seed oder ausreichend ähnlichem Thema/Kategorieverbund werden in einem gemeinsamen Artikelauftrag verarbeitet. Unabhängige Themen bleiben getrennt.

Dadurch kann aus drei Relationen z. B. ein einzelner Research-/Gemma-/Qwen-Workflow statt drei vollständiger Artikelpipelines entstehen.

## Persistente Wiederholsperren

Zwei Fingerprints werden gespeichert:

- Work-Fingerprint: Quelleninhalte + Relationskontext. Er wird vor dem Artikelplan geprüft und kann einen bereits erfolgreich abgearbeiteten unveränderten Auftrag ohne Modellcall überspringen.
- Source-Fingerprint: tatsächlich vom Artikelplan ausgewählte Quellen + Action/Target/Artikeltyp. Er verhindert eine erneute Synthese desselben finalen Pflegeauftrags.

Die Fingerprints basieren auf Inhalts-Hashes und enthalten außerdem Sprache, Autor-/Reviewer-Modell, effektive Research-Strategie und Repair-Konfiguration. Ändert sich der Inhalt einer Quellseite oder wird die Pipeline bewusst anders konfiguriert, darf der Artikel erneut verarbeitet werden.

## Relationsrecherche

SearXNG-Recherche zur Entscheidung über eine unsichere Relation bleibt möglich, weil sie ein anderes Problem löst als die Artikelrecherche. Die gefundenen Treffer werden aber erst dann als Research-Nodes materialisiert, wenn Qwen die Relation nach der Recherche tatsächlich akzeptiert. Bei verworfenen Relationen bleibt kein Research-Beifang im Graphen zurück.