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

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
   │
   ▼
Aktualitätsdetektor
   │
   ├─ aktuelle Version/CVE/Support/Preis/Live-Status? ──> kleine SearXNG-Runde
   │
   └─ statisches Thema ──> kein Web
   │
   ▼
Gemma / Autor schreibt intern-first
   │
   ├─ 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. Wenn Gemma eine konkrete Lücke erkennt, werden höchstens wenige präzise Queries ausgeführt und der Draft einmal mit dem neuen Material neu erzeugt.

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

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 nur bei Aktualität, 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:

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:

wird die Quelle als external-Node materialisiert;
wird sie eingebettet;
erhält der Artikel eine grounded_by-Edge;
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

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.

5.7 KiB Raw Blame History