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
   │
   ├─ 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

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:

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.

6.2 KiB Raw Permalink Blame History