Weave Architektur und Ablauf

Wie eine Frage zu einer belegten Antwort wird

Zwei Blicke auf dasselbe System: erst die Topologie der sechs Kerndienste, ihrer Worker und der geteilten Mitte, dann der zeitliche Ablauf einer einzelnen Wissensfrage — samt der Stellen, an denen Rechte geprüft werden.

Stand 03.10.2026 · v0.7.06 Kerndienste · 3 Datenbanken · 2 CPU-Modelle lokal verifiziert

Drei Zonen, eine geteilte Mitte

Oben wird kompiliert, unten geantwortet — und beide greifen auf dieselbe Mitte zu. Weave-Knowledge schreibt in Postgres, Weave-Retrieval liest dieselbe Datenbank nur lesend, weil pgvector-Ähnlichkeit und Volltext-Ranking als SQL in der Datenbank laufen müssen. Die beiden Modelldienste bedienen beide Pipelines: einmal für Passagen beim Indizieren, einmal für die Suchanfrage.

Was oben passiert

Der OCR-Worker macht aus PDF, Mail und Confluence strukturiertes Markdown mit Metadaten
Indiziert wird erst nach manueller Freigabe: sie erzeugt den unveränderlichen Snapshot und das signierte document.released-Event
Der Index-Worker chunkt strukturbewusst und lässt jede Passage einbetten
Eine neue Version ersetzt die Chunks der alten in derselben Transaktion

Was die Mitte trägt

Postgres hält drei Datenbanken; der Chunk-Store trägt Vektoren und Volltext-Index
Redis bedient nur Weave-Ingest (DB 0) und Weave-Knowledge (DB 1) als Celery-Broker — die übrigen Dienste sind zustandslose HTTP-Services ohne eigenen Worker
Die Modelldienste sprechen dieselbe Schnittstelle wie ein externer Anbieter — austauschbar
Dieselbe Modellangabe muss beim Indizieren und beim Suchen gelten, sonst findet die Suche nichts

Was unten entscheidet

Der Router bestimmt zuerst die Art der Anfrage — nur Wissensfragen suchen überhaupt
Weave-Tools leiht Agenten die Rechte des Fragenden über ein kurzlebiges signiertes Token
n8n und MCP-Clients sehen nie mehr als der Mensch dahinter
Das Sprachmodell ist austauschbar und wird erst nach dem Router überhaupt gefragt

Eine Wissensfrage, von links nach rechts und wieder zurück

Die Zeit läuft nach unten. Auffällig ist, wo nicht gearbeitet wird: Rechte und Absicht klärt die Runtime, bevor irgendjemand sucht — und ob eine Antwort überhaupt hinausgeht, entscheidet ganz am Ende der Guard. Findet die Suche nichts, geht der konfigurierte Hinweis raus statt einer flüssig formulierten, aber unbelegten Antwort. Für Bots im Agentenmodus verzweigt Weave-Runtime an dieser Stelle in einen LangGraph-Ablauf: Statt einer einzelnen Suche plant der Bot Teilfragen, lässt sie parallel gebundene Rechercheprofile bearbeiten und führt die Treffer erst danach zur Antwort zusammen — eine Recherche, die nichts findet, wird als benannte Lücke gemeldet, nie als erfundene Antwort.