WerkWorks
EN Kontakt
Menü
← Zurück zum Blog

Weave: drei Entscheidungen, die den Unterschied zur Dokumentensuche ausmachen

Weave liest Dokumente ein und macht sie in einem Chat beantwortbar, mit der Quelle neben jeder Aussage. Was die Plattform tut, steht auf der Produktseite. Dieser Beitrag beschreibt die drei Entscheidungen, die sie von einer gewöhnlichen Dokumentensuche unterscheiden, und verweist an jeder Stelle auf das Dokument, das den Punkt ausführt. Er ist ein Wegweiser, kein Ersatz für diese Dokumente, und löst die frühere Fassung dieses Beitrags ab, die noch den Stand v0.2.1 beschrieb.

Der aktuelle Stand ist v0.7.0: sechs Kerndienste (Ingest, Knowledge, Retrieval, Runtime, Tools, API), zwei optionale reine CPU-Modelldienste für Embeddings und Reranking, veröffentlichte Container-Images und ein Helm-Chart für die vollständige Plattform, in dem jeder Dienst mit mehreren Repliken laufen kann. Offline nimmt Weave-Ingest Dokumente entgegen, offline schreibt Weave-Knowledge daraus einen durchsuchbaren Chunk-Store; online entscheidet ein Router pro Anfrage, ob dafür überhaupt gesucht werden muss. Die Gesamtarchitektur zeigt beide Pipelines auf einem Bild.

1. Verarbeitet ist nicht veröffentlicht

Ein Ordner, den jemand hochlädt, ist damit noch nicht auffindbar. Weave trennt Verarbeitung und Veröffentlichung: Das Ereignis document.processed bestätigt nur, dass ein Auftrag verarbeitet wurde, und die Portalantwort dazu heißt awaiting_release. Regulär indexiert Weave-Knowledge ausschließlich document.released.

Diese Freigabe ist eine bewusste Handlung. Pro Auftrag gibt es genau eine, sie darf nur der Dokument- oder Wissensbereichseigentümer oder ein Administrator auslösen, und ein Quality-Block verweigert sie. Was dabei entsteht, ist ein unveränderlicher Snapshot. Ein Bearbeiten oder Neuverarbeiten eines freigegebenen Auftrags wird mit HTTP 409 abgewiesen; für geänderten Inhalt braucht es eine neue Dokumentversion. Auch der Export liefert immer den Freigabe-Snapshot, nie den späteren lokalen Stand.

Der Fachbereich sieht davon eine Statuskette: Freigegeben → Wird indiziert → Für KI verfügbar. Der letzte Zustand erscheint erst, wenn Knowledge genau diese Freigabe samt ihrem Snapshot-Hash bestätigt hat und die Textabschnitte mit ihren Embeddings vollständig gespeichert sind. „Verarbeitet” bedeutet an keiner Stelle „indexiert”.

Wo die Freigabe in der Architektur sitzt, zeigt die Gesamtarchitektur; wie das signierte Ereignis den Index-Worker erreicht, steht in Architektur und Ablauf.

Eine freigegebene Dokumentversion lässt sich nach ausdrücklicher Bestätigung aus Knowledge zurückziehen. Dokument und Textabschnitte werden transaktional aus dem Suchindex entfernt; ein Tombstone verhindert, dass eine verspätete Freigabe dieselbe Version erneut indexiert. Importhistorie, Originaldatei und Freigabe-Snapshot bleiben für die Nachvollziehbarkeit erhalten.

2. Rechte wirken in der Abfrage, nicht als Filter danach

Der übliche Bauplan sucht erst und filtert dann, was der Fragende nicht sehen darf. Das ist die Stelle, an der solche Systeme lecken. In Weave entscheidet die Datenbankabfrage selbst, was gelesen werden darf. Teams geben Zugriff auf Wissensbereiche, und die Runtime schneidet vor der Suche die lesbaren Wissensbereiche des Nutzers mit der Bot-Konfiguration und einem eventuellen Anfragefilter.

Wer außerhalb eines Wissensbereichs steht, bekommt daher keine Treffer: keinen versteckten Treffer und keine Fehlermeldung, die dessen Existenz verrät. Für Agenten gilt dasselbe, ob es sich um einen n8n-Flow, einen MCP-Client mit delegierten Rechten oder eine technische Identität handelt — dazu unten mehr. Keiner von ihnen kann seinen Zugriff ausweiten und keiner sieht mehr als der Mensch, für den er fragt.

Die Reihenfolge ist der ganze Punkt, und sie ist in Architektur und Ablauf als Zeitachse gezeichnet: Bot laden, Rechte, Intent — und erst danach sucht überhaupt jemand.

3. Ohne Belege keine Antwort

Am Ende jeder Anfrage steht ein Guard. Findet die Suche keine Passagen, gibt Weave den konfigurierten Hinweis zurück, mit einer leeren Quellenliste. Es gibt keine flüssig formulierte, unbelegte Antwort — genau die ist der Fehlermodus, der solche Systeme unbrauchbar macht.

Der Weg dorthin ist absichtlich kurz gehalten: Nicht jede Anfrage braucht Suche, der Router bestimmt zuerst die Art der Frage, und das Sprachmodell wird erst danach überhaupt gefragt. Beide Verzweigungen stehen im Ablaufdiagramm in Architektur und Ablauf.

Was seit v0.2.1 dazugekommen ist

Agentenmodus. Ein LLM-Bot kann statt der eigenen direkten Wissenssuche mehrere Subagenten konfigurieren, jeder mit eigener Mission und explizit gebundenem Wissensbereich. Der Haupt-Bot plant die Teilfragen, die Subagenten recherchieren innerhalb ihres Suchbudgets parallel, die Treffer werden zusammengeführt und gegen genau die tatsächlich abgerufenen Belege geprüft, und die Antwort trägt die kombinierten Quellen. Der Fortschritt läuft live im Chat mit. Scheitert ein Subagent, wird das benannt — nie stillschweigend übergangen, nie durch eine erfundene Antwort ersetzt; bleibt am Ende gar nichts Verwertbares übrig, greift derselbe Guard wie bei der direkten Suche. n8n-Bots können außerdem inkrementell antworten, sodass ein einzelner Zug auch mehrere Stunden dauern darf, gehalten von Keepalive-Zeilen über die gesamte Kette.

Externer Zugriff über technische Identitäten. Eine eigenständige Integration oder ein externer KI-Agent bekommt ein wti_…-Token mit explizit zugeteilten Wissensbereichen — standardmäßig keinen. Rotation, Ablauf, Widerruf und ein Audit-Log gehören dazu, und der Zugriff läuft ausschließlich über Weave-Tools, per MCP oder REST, unter derselben Rechte-Schnittmenge wie bei einem Menschen. Interne Retrieval-Zugangsdaten verlassen den Stack dabei nie.

Desaster-Recovery. Ein passphrase-verschlüsseltes Archiv exportiert alle Ingest-Daten — Nutzer, Wissensbereiche, Aufträge, Verbindungen samt Zugangsdaten, Dateien. Seit v0.7.0 entsteht es aus einem konsistenten Datenbank-Snapshot und fließt direkt in den Browser, ohne Zwischendatei auf dem Server. Die Wiederherstellung auf einer frischen Installation übernimmt der erste neue Administrator, der nicht dieselbe Person sein muss, die die Sicherung erstellt hat. Danach baut sich der Wissensindex von selbst neu auf, sobald ein Ingest-Worker läuft; die Indexwartung im Adminbereich erlaubt daneben, denselben Neuaufbau manuell anzustoßen, alle Vektoren neu zu berechnen oder den Index vollständig aus den bestehenden Freigaben neu aufzubauen.

Horizontale Skalierung (v0.7.0). Kein Dienst hält mehr Zustand, den nur er kennt. Originale, Ergebnisse und Bilder liegen in PostgreSQL statt auf einem gemeinsamen Dateivolume, sodass Backend- und Worker-Pods keine Dateien teilen; Ratenbegrenzung, Laufzeiteinstellungen und Migrationssperren liegen ebenfalls in der Datenbank. OCR läuft im Cluster in einem eigenen Worker-Pool, Importe, Webhooks und Freigaben in einem zweiten, damit nichts hinter einem langen Scan wartet. Jeder laufende Auftrag meldet sich regelmäßig in der Datenbank; verschwindet ein Pod, wird sein Auftrag nach etwa zwei Minuten neu eingestellt. Skaliert wird per HPA oder, als Schalter im Helm-Chart, per KEDA nach Länge der Warteschlange. Das Chart rechnet beim Rendern die Datenbankverbindungen aller Repliken nach und verweigert ein Deployment, das das Budget von PostgreSQL sprengen würde. Diese Chart-Version ist für neue Installationen gedacht; eine Übernahme alter Dateiablagen gibt es nicht.

MCP-Anmeldung per SSO (v0.7.0). Ein MCP-Client wie VS Code meldet sich jetzt auch direkt mit dem Konto seines Nutzers an — über Entra ID oder Keycloak, mit OAuth und PKCE. Weave-Ingest prüft das Zugriffstoken und ordnet es einem vorhandenen, aktiven Nutzer zu. Angelegt wird dabei niemand, und die Rechte kommen aus den Teams in Weave, nie aus Gruppen im Token.

Ein ehrlicher Absatz zum 22. September. An diesem Tag hat ein Schub gleichzeitiger Freigaben so viele parallele Embedding-Anfragen erzeugt, dass der Embeddings-Pod aus Speichermangel abgeschossen wurde und Dokumente dauerhaft auf „Indizierung fehlgeschlagen” stehen blieben. Die Behebung begrenzt den Embeddings-Dienst auf eine feste Zahl gleichzeitiger Anfragen mit begrenzter Warteschlange, macht aus Embedding-Fehlern geplante Wiederholungen, die einen Neustart des Pods überstehen, und lässt den Indizierungs-Worker mit kleiner, fester Nebenläufigkeit statt einem Prozess pro CPU-Kern laufen.

Was ein Betreiber vor dem Produktivstellen wissen muss

Das Netz ist flach. Alle fünfzehn Container liegen in einem einzigen Bridge-Netz, es gibt kein zweites und kein abgeschottetes Segment. Die Trennung zwischen den Diensten leistet nicht das Netz, sondern der Bearer-Token, den jeder Dienst verlangt; geprüft wird fail-closed, ein nicht gesetzter Token liefert 503 statt einer offenen Tür.

Im Auslieferungszustand veröffentlicht der Compose-Stack elf Host-Ports. Für Nutzer gedacht sind sechs davon: Portal-Oberfläche und Ingest-API, die der Browser direkt aufruft, die Chat-Oberfläche, das API-Gateway, die Tools-REST-Schnittstelle und — neu seit v0.2.1 als eigener Container — die Tools-MCP-Schnittstelle für externe Integrationen und KI-Agenten. Die übrigen fünf — Knowledge, Retrieval, Runtime und die beiden Modelldienste — braucht von außen niemand, veröffentlicht werden sie trotzdem. Dazu zwei Punkte aus derselben Datei: Kein ports:-Eintrag trägt eine Bind-Adresse, alle elf hängen also an 0.0.0.0, und deploy/ enthält weder Reverse-Proxy noch Ingress noch Zertifikate — jeder Hop ist Klartext-HTTP. TLS und die Bindung an 127.0.0.1 bleiben Aufgabe des Betreibers. Ohne Host-Port sind nur PostgreSQL und Redis.

Vier der internen Zugangsdaten sind faktisch Generalschlüssel: einer löst die Identität hinter jedem persönlichen Token auf, einer — neu seit den technischen Identitäten — die hinter jedem technischen Token und jedem SSO-Zugriffstoken für MCP, einer zieht die vollständige Zugriffskarte über alle Wissensbereiche, einer holt den entschlüsselten Provider-Schlüssel des Sprachmodells. Sie gehören entsprechend behandelt.

Das Netzdesign zeigt diese Topologie als Bild, inklusive der Ports, die veröffentlicht sind, ohne dass jemand sie von außen braucht.

Wenn die Begriffe im Weg stehen

Chunk, RRF, pgvector, Cross-Encoder: Der Beitrag kommt ohne diese Wörter nicht ganz aus, die Dokumente erst recht nicht. Das Glossar erklärt 82 Begriffe zweimal — einmal allgemein und einmal in ihrer konkreten Rolle in Weave — und ist nach Dienst gruppiert.

Der Quellcode liegt öffentlich unter github.com/bl0rb/Weave. Das Wiki ist deutschsprachig und der bessere Einstieg, wenn es um die Bedienung geht; die README des Repositorys beschreibt das Repository selbst.