# SearXNG-Visualisierung Das Neural Brain meldet sowohl die technische SearXNG-Suche als auch die vollständige Artikelrecherche an das Frontend. Bei der Artikelrecherche folgen auf `article.research.results` eine Kandidatenbewertung, der Volltextabruf und eine zweite Evidenzprüfung. Erst `article.research.ingested` bedeutet, dass geprüfte Volltextbelege als Forschungs-Nodes aufgenommen und mit internen Wissensquellen verknüpft wurden. Jede konkrete Query trägt eine eigene `research_id`. Die Query endet mit `article.research.completed`; dadurch bleibt die Animation während Fetch, Graph-Reload und Node-Erzeugung erhalten. ## Animation Während der Suche erscheinen grüne Scanringe und externe Quellenpunkte um das Gehirn. Nach Eingang der Treffer fließen Quellenpakete in die betroffenen Wissensregionen. Beim Erzeugen der neuen Forschungs-Nodes werden diese mit sechseckigen Markierungen hervorgehoben. Die Abschlussanimation läuft nach dem Reload und der Einblendung der neuen Nodes mindestens zwei Sekunden weiter. Sie ist unabhängig von der normalen Partikel- und LOD-Liste und wird deshalb durch eine Neuerstellung des Rendergraphen nicht entfernt. Die Animation wird sowohl in der Neural- als auch in der Honeycomb-Ansicht dargestellt. In Honeycomb werden weiterhin keine regulären Graph-Edges gezeichnet; sichtbar sind nur die zeitlich begrenzten Recherchepfade. ## Aktivitätsfeed Der linke Feed zeigt jetzt: - bereits gelernte Volltextbelege, die ohne erneuten Seitenabruf wiederverwendet werden; - Recherche-Runde, Wissenslücke und Sprache; - konkrete Suchanfrage und SearXNG-Trefferzahl; - Anzahl ausgewählter Kandidaten; - Volltextabruf mit URL, Content-Type, Zeichenanzahl und Laufzeit; - Relevanz, Quellenklasse, Qualitätswert und Handlungsrelevanz; - Begründung für Annahme oder Ablehnung; - unmittelbare semantische Einbettung der akzeptierten Webbelege; - Anzahl neu verknüpfter Forschungs-Nodes und Edges; - nach jeder Runde gelöste und verbleibende kritische Lücken. Damit ist getrennt erkennbar, ob SearXNG Treffer lieferte, ob die Seiten tatsächlich geladen wurden und ob ihr Volltext als fachlicher Beleg akzeptiert wurde. Ein SearXNG-Treffer allein wird nicht mehr gelernt. ## Direkter Funktionstest Im Einstellungsbereich unter **FILTER → SearXNG-Diagnose** steht eine direkte Testsuche zur Verfügung. Sie ruft SearXNG unabhängig von Qwens Entscheidung auf und übernimmt die Treffer nicht dauerhaft in den Graphen. Damit kann eindeutig zwischen zwei Fällen unterschieden werden: - SearXNG ist technisch nicht erreichbar oder liefert kein JSON. - SearXNG funktioniert, aber Qwen hat für einen bestimmten Wissensverbund keine Recherche angefordert. Der Test erzeugt die Events: - `research.test.started` - `research.test.results` - `research.test.failed` Die normale Rechercheanimation wird dabei ebenfalls mindestens zwei Sekunden angezeigt. ### Diagnoseinformationen `GET /api/research/status` liefert den zuletzt bekannten Zustand. `POST /api/research/test` akzeptiert beispielsweise: ```json { "query": "Btrfs Snapshots und ZFS History Unterschiede Timeline", "limit": 4 } ``` Die Antwort beziehungsweise das Fehler-Event enthält: ```json { "configured": true, "base_url": "http://searxng:8080", "ok": false, "duration_ms": 29, "http_status": 403, "content_type": "text/html", "error_kind": "http_status", "error": "SearXNG lieferte HTTP 403 ..." } ``` Im linken Aktivitätsfeed wird der vollständige Fehlertext einschließlich Endpoint angezeigt. Typische Fehlerklassen sind `dns`, `connection_refused`, `timeout`, `tls`, `http_status` und `invalid_json`. ## Häufige Docker-Fehler `SEARXNG_URL=http://localhost:8080` ist in einem getrennten Brain-Container normalerweise falsch. `localhost` bezeichnet dort den Brain-Container selbst. Bei gemeinsamem Compose-Netzwerk sollte stattdessen beispielsweise gelten: ```env BRAIN_RESEARCH_ENABLED=true SEARXNG_URL=http://searxng:8080 ``` Läuft SearXNG direkt auf dem Docker-Host, kann je nach Plattform verwendet werden: ```env SEARXNG_URL=http://host.docker.internal:8080 ``` SearXNG muss außerdem JSON-Antworten erlauben: ```yaml search: formats: - html - json ``` Eine HTML-Seite, Login-Seite oder Proxy-Fehlerseite wird jetzt als `invalid_json` mit Content-Type und kurzem Antwortausschnitt gemeldet. ## Iterative Artikelrecherche Die vollständige Eventfolge und die Sicherheits- und Qualitätsregeln sind in [`ITERATIVE-GROUNDED-RESEARCH.md`](ITERATIVE-GROUNDED-RESEARCH.md) dokumentiert.