129 lines
6.2 KiB
Markdown
129 lines
6.2 KiB
Markdown
# 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.
|