Nachschlagewerk · Weave
Jeder Begriff, der in diesem Projekt gefallen ist — erst allgemein erklärt, dann übersetzt in das, was er konkret in Weave tut. Nach Dienst gruppiert und durchsuchbar.
| Begriff | Bedeutung |
|---|---|
| OCROptical Character Recognition | Aus Pixeln wird Text: Software erkennt Buchstaben in Scans, Fotos und PDFs ohne Textebene. In WeavePaddleOCR verarbeitet PDF, DOCX, PPTX, XLSX, Bilder und E-Mails. Was hier falsch gelesen wird, kann später keine Suche mehr reparieren — deshalb hängt am Ende ein Quality-Gate. |
| Layout-AnalysePP-StructureV3 | Erkennt nicht nur Zeichen, sondern Rollen: Was ist Überschrift, was Tabelle, was Fußnote — und wo auf der Seite steht es. In WeaveDiese Blockstruktur wird zu echtem Markdown mit Überschriftenhierarchie und Tabellen. Genau davon lebt das Chunking später: ohne Struktur bliebe nur Fließtext. |
| YAML-Frontmatter--- … --- am Dateianfang | Ein Metadatenblock über dem eigentlichen Text, in YAML notiert und von Werkzeugen maschinell lesbar.
In WeaveDer Datenvertrag zwischen Ingest und Knowledge: source, content_sha256, document_version, engine, team, collection. Ein Vertragstest prüft, dass alle Verarbeitungswege dieselben Felder liefern. |
| Content-HashSHA-256 | Ein kurzer Fingerabdruck des Inhalts. Gleicher Inhalt ergibt immer denselben Hash, jede Änderung einen völlig anderen. In WeaveErkennt unveränderte Re-Uploads (die gar nicht erst verarbeitet werden) und dient zusammen mit der Job-ID als Idempotenz-Schlüssel für Events. |
| Versionsketteprevious_job_id | Jede neue Fassung eines Dokuments zeigt auf ihren Vorgänger, statt ihn zu überschreiben. So bleibt die Historie nachvollziehbar. In WeaveLädt jemand eine geänderte Datei hoch, entsteht Version N+1. Der Index ersetzt daraufhin die Chunks der Vorversion — in derselben Transaktion, damit nie beide gleichzeitig auffindbar sind. |
| Supersedestatus = superseded | Das geordnete Ablösen einer Vorversion: sie wird nicht gelöscht, aber als überholt markiert und aus der Suche genommen. In WeaveVerhindert den klassischen RAG-Fehler, dass ein Bot aus einer alten Vertragsfassung zitiert, weil deren Chunks noch im Index lagen. |
| Quality-GateA · B · C → allow · warn · block | Eine automatische Note für die Verarbeitungsqualität, berechnet aus OCR-Konfidenz, erkannter Struktur und Textrauschen (Wiederholungen, Sonderzeichen, unlesbare Zeichenfolgen).
In WeaveDokumente mit Empfehlung block werden erst gar nicht indiziert. Fehlt die Bewertung ausnahmsweise, gilt das bewusst wie warn — nie wie allow. |
| document.released | Signiertes Event aus Ingest, das anzeigt: Für diesen Auftrag liegt ein unveränderlicher, manuell freigegebener Markdown-Snapshot vor.
In WeaveNur dieses Event wird regulär indexiert — document.processed wird nur mit dem Status awaiting_release quittiert. Freigaben sind damit das Herz des Wissensportals. |
| Collectionslug · read_teams | Eine benannte Sammlung von Dokumenten mit einer Liste von Teams, die sie lesen dürfen. In WeaveDer Slug wandert bis in die Chunk-Metadaten, die Zugriffsliste bewusst nicht: sie lebt in einer Registry. Deshalb kostet ein Rechteentzug kein Neuindizieren und wirkt sofort. |
| read_teams | Liste von Teamnamen an einer Collection — in Ingest „Wissensbereich" genannt —, die entscheidet, wer ihre Dokumente im Chat findet. Eine leere Liste bedeutet: für alle lesbar. In WeaveWird per Registry-Sync von Ingest nach Knowledge gespiegelt; Administratoren pflegen sie unter Administration → Wissensbereiche. Der Teamname muss dabei zeichengleich passen. |
| Begriff | Bedeutung |
|---|---|
| Chunk | Ein Textstück als kleinste Einheit, die gesucht und dem Sprachmodell gezeigt wird. Zu groß macht Treffer unpräzise, zu klein reißt den Sinn auseinander. In WeaveStandardmäßig rund 3 000 Zeichen mit 200 Zeichen Überlappung, damit ein Satz an der Schnittkante nicht verlorengeht. |
| Strukturbewusstes Chunking | Schneiden an inhaltlichen Grenzen statt nach Zeichenzahl — an Überschriften und Absätzen, nicht mitten in einer Tabelle. In WeaveÜberschriftenpfad, Seitenmarker und Confluence-Breadcrumb wandern in die Metadaten. Tabellen und Code-Blöcke bleiben unteilbar, weil eine halbe Tabelle nichts mehr aussagt. |
| EmbeddingVektor, z. B. 1536 Zahlen | Ein Text, übersetzt in eine lange Zahlenreihe. Texte mit ähnlicher Bedeutung landen dabei nah beieinander — auch ohne ein gemeinsames Wort. In WeaveDeshalb findet „Wie lange muss ich kündigen?" einen Abschnitt über Fristen. Der Modellname wird pro Chunk gespeichert; nur passend eingebettete Chunks werden durchsucht. |
| e5-Präfixe | intfloat/multilingual-e5-* erwartet vor jedem Text ein Präfix, das seine Rolle markiert: query: vor Suchanfragen, passage: vor Dokumenttexten.
In WeaveWerden anhand von input_type automatisch gesetzt. Fehlen sie, sinkt die Trefferqualität, ohne dass irgendwo ein Fehler auftaucht. |
| Dimension | Wie viele Zahlen ein Vektor hat. Eine Eigenschaft des Embedding-Modells, keine freie Einstellung. In WeaveEin Wechsel der Dimension bedeutet Migration und Reindex — deshalb steht sie in den Settings und wird von der Migration gelesen, statt fest im Code zu stehen. |
| pgvector | Eine Postgres-Erweiterung, die Vektoren als echten Spaltentyp kennt und Ähnlichkeit direkt in SQL berechnen kann. In WeaveDer Grund, warum keine zweite Datenbank nötig ist: Vektoren, Volltext und Metadaten liegen in einer Tabelle und werden in einer Abfrage gefiltert. |
| Cosine-DistanzOperator <=> | Misst den Winkel zwischen zwei Vektoren, nicht ihre Länge — es zählt die Richtung der Bedeutung, nicht die Textmenge.
In WeaveDas Standardmaß für Text-Embeddings und der Grund, warum der Index mit vector_cosine_ops angelegt ist: Index und Abfrage müssen dasselbe Maß benutzen, sonst wird er ignoriert. |
| HNSW-IndexHierarchical Navigable Small World | Ein mehrstöckiger Graph über allen Vektoren. Die Suche springt oben grob in die richtige Gegend und verfeinert nach unten — statt alles zu vergleichen. In WeaveOhne diesen Index läse jede Ähnlichkeitssuche die komplette Chunk-Tabelle. Genau das fand der Review: der Index war beschrieben, aber nicht angelegt. |
| ANNApproximate Nearest Neighbour | Näherungssuche: Man verzichtet bewusst auf die Garantie, den allerbesten Treffer zu finden, und gewinnt dafür enorm an Tempo. In WeaveEin fairer Tausch, weil ohnehin 20 Kandidaten geholt und danach neu sortiert werden — ob Platz 19 exakt stimmt, ändert das Ergebnis nicht. |
| tsvector & GIN-Index | Postgres' Volltext-Werkzeuge: tsvector ist der auf Wortstämme normalisierte Text, der GIN-Index macht ihn schnell durchsuchbar.
In WeaveWird beim Schreiben automatisch mitgeführt (generierte Spalte) und bildet den zweiten Suchpfad neben den Vektoren — den, der Aktenzeichen und Paragraphen findet. |
| Reindex | Bestehende Chunks neu einbetten, ohne sie neu zu schneiden — nötig bei einem Wechsel des Embedding-Modells. In WeaveAls eigener CLI-Befehl umgesetzt, weil Neu-Chunken teuer und selten nötig ist, Neu-Einbetten aber regelmäßig ansteht. |
| Registry & Spiegel | Eine Tabelle, die Daten aus einem anderen Dienst nachführt, statt sie gemeinsam zu besitzen. Der Spiegel darf kurz hinterherhinken. In WeaveDie Collection-Registry wird von Ingest gespiegelt: alle 60 Sekunden turnusmäßig, bei einer Rechteänderung sofort per signiertem Event. |
| Registry-Sync | Knowledge zieht Ingests GET /collections/registry — Slug, Name, Beschreibung, read_teams — in seine eigene collections-Tabelle; Retrieval filtert danach.
In WeaveEin Ingest-Token, das keinem Administrator gehört, liefert eine leere Antwort und lässt damit die Registry leer. |
| Begriff | Bedeutung |
|---|---|
| RAGRetrieval-Augmented Generation | Erst in eigenen Dokumenten suchen, die Fundstellen ins Prompt legen, dann das Modell antworten lassen. So antwortet es aus deinen Daten statt aus dem Gedächtnis. In WeaveBewusst nicht der Standardweg jeder Anfrage, sondern ein Werkzeug hinter dem Router — die zentrale Architekturentscheidung des ganzen Systems. |
| Hybrid Search | Zwei Suchverfahren parallel laufen lassen und die Ergebnisse verschmelzen: semantische Vektorsuche und wörtliche Volltextsuche. In WeaveDie Vektorsuche versteht Umschreibungen, die Volltextsuche findet „§ 12 Absatz 3" und „Kundennummer 4711". Jede allein hätte eine systematische Schwäche. |
| BM25 / Volltextsuche | Klassische Stichwortsuche mit Gewichtung: seltene Wörter zählen mehr als häufige, und ein Wort in einem kurzen Text wiegt schwerer als im langen.
In WeaveÜber Postgres' websearch_to_tsquery und ts_rank umgesetzt — kein zusätzlicher Suchserver nötig. |
| RRF1 / (k + Rang), k = 60 | Reciprocal Rank Fusion verschmilzt zwei Trefferlisten über die Plätze statt über die Punktzahlen — denn ein Vektor-Score und ein BM25-Score sind schlicht nicht vergleichbar. Jede Liste steuert pro Treffer 1/(k+Rang) bei, die Summe entscheidet.
In WeaveWas in beiden Listen vorkommt, steigt dadurch nach oben — ein Treffer, der semantisch und wörtlich passt, schlägt einen, der nur eines von beidem tut. |
| RerankerCross-Encoder | Ein Modell, das Frage und Textstück gemeinsam liest und bewertet, wie gut sie zueinander passen. Viel genauer als der Vektorvergleich, aber zu langsam für den ganzen Bestand.
In WeaveDeshalb die Reihenfolge: grob 20 Kandidaten holen (SEARCH_TOP_K), dann mit einem Cross-Encoder wie BAAI/bge-reranker-v2-m3 genau bewerten und auf SEARCH_FINAL_K reduzieren. Fällt der Reranker aus, liefert die Suche die RRF-Reihenfolge — sie scheitert nie am Reranker. |
| top_k / final_k20 → 5 | Zwei Stellschrauben: wie viele Kandidaten die Suche holt, und wie viele nach dem Reranking übrig bleiben und ins Prompt wandern.
In WeavePro Bot einstellbar. final_k größer als top_k wird abgelehnt — ein Reranker kann eine Menge nur verkleinern. |
| Metadaten-Filter | Einschränken, bevor gesucht wird — nach Team, Abteilung, Sprache, Collection. In WeaveWichtiger als der perfekte Embedding-Algorithmus und zugleich die Zugriffsgrenze: gefiltert wird in SQL vor dem Ranking, nie nachträglich am Ergebnis. |
| Eval-Harness | Ein Messaufbau für Suchqualität: dieselben Fragen, dieselbe Messlatte, vor und nach jeder Änderung.
In WeaveAls CLI mit --min-recall-Schwelle umgesetzt. Ohne so etwas ist jede Änderung an der Suche Bauchgefühl — man merkt Verschlechterungen erst bei den Nutzern. |
| Golden-SetYAML | Eine handgepflegte Liste aus Fragen und den Dokumenten, die als richtige Antwort gelten — die Wahrheit, gegen die gemessen wird. In WeaveJe Eintrag eine Frage plus die erwarteten Quellen. Der Aufwand liegt im Pflegen dieser Liste; das ist der eigentliche Preis für messbare Suchqualität. |
| Recall@k | Von allen richtigen Dokumenten: Welcher Anteil taucht in den ersten k Treffern auf? Bei 3 richtigen Dokumenten und 2 davon in den Top 5 ist Recall@5 gleich 0,67. In WeaveDie wichtigste Kennzahl, denn was die Suche nicht findet, kann das Modell nicht zitieren — ein Ausfall, den keine noch so gute Antwortformulierung heilt. |
| MRRMean Reciprocal Rank | Für jede Frage 1 / Position des ersten richtigen Treffers, gemittelt über alle Fragen. Platz 1 gibt 1,0, Platz 2 gibt 0,5, Platz 4 nur noch 0,25.
In WeaveMisst nicht nur ob, sondern wie weit oben gefunden wird — relevant, weil nur die besten fünf Chunks ins Prompt kommen. |
| Hit@1 | Wie oft ist gleich der erste Treffer richtig? Die strengste und zugleich anschaulichste Kennzahl. In WeaveDer beste Indikator dafür, ob der Reranker seine Arbeit tut — er soll genau diesen ersten Platz verbessern. |
| Begriff | Bedeutung |
|---|---|
| Bot-MVPV1 → V2 → V3 | Die kleinste Ausbaustufe, die schon echten Nutzen bringt — bewusst vor allem Weiteren fertiggestellt, statt gleich das Vollbild zu bauen. In WeaveV1: Frage → belegte Antwort. V2: Werkzeuge und Aktionen. V3: Planer und Gedächtnis. Agentic RAG steht bewusst ganz hinten — erst wenn die Messung eine Lücke zeigt. |
| Intent-Router | Ein Vorschalter, der zuerst bestimmt, welche Art Anfrage vorliegt, und erst danach den passenden Weg wählt.
In WeaveFünf Absichten: conversational, knowledge, document, action, complex. Nur knowledge löst eine Suche aus — „Hallo" braucht keine Vektordatenbank. |
| Bot als KonfigurationKonfiguration statt Code | Ein Bot ist ein Eintrag mit Modell, Anweisung, Wissensquellen und Rechten — kein eigenes Programm.
In WeaveEin neuer Fachbot ist eine neue YAML-Datei auf derselben Laufzeit: kein Deployment, kein Code-Review, keine zweite Betriebsumgebung. Seit v0.1.0 gibt es dafür zwei Wege: YAML-Dateien im Volume runtime_bots und n8n-Bots, die Administratoren in Ingest pflegen. Runtime führt beide Quellen bei jeder Anfrage zu einer Liste zusammen; bei gleicher id gewinnt der zentrale Eintrag. |
| System-Prompt | Die Grundanweisung, die vor jedem Gespräch steht und Rolle sowie Tonfall festlegt — für den Nutzer unsichtbar. In WeavePro Bot in der YAML. Die gefundenen Textstellen kommen als klar abgegrenzter, nummerierter Kontextblock dazu — getrennt von den Anweisungen, damit Dokumenteninhalt nicht als Befehl gelesen wird. |
| Response-Guard | Die letzte Prüfung, bevor eine Antwort das System verlässt: Erfüllt sie die Bedingungen, die für diesen Bot gelten? In WeaveVerlangt ein Bot Belege und die Suche liefert nichts, geht die konfigurierte Auskunft „dazu finde ich nichts Belegtes" hinaus — statt einer flüssig formulierten, aber unbelegten Antwort. Das gilt auch im Streaming. |
| no_context / no_collections | Die zwei Gründe, aus denen der Guard greift: nichts gefunden — oder gar nicht erst gesucht, weil keine Sammlung freigegeben war. In WeaveDer zweite Fall ist eine Sicherheitsgrenze: ein Bot mit Collection-Beschränkung sucht nie ohne wirksame Grenze, auch nicht „vorsichtshalber". |
| Trace | Ein Begleitprotokoll zur Antwort: welche Absicht erkannt wurde, ob gesucht wurde, wie viele Treffer es gab, wie lange jeder Schritt dauerte. In WeaveFester Teil jeder Antwort. Ohne ihn ist bei einer schlechten Antwort nicht unterscheidbar, ob der Router, die Suche oder das Modell danebenlag. |
| LLM-Provider-Abstraktion | Eine dünne Zwischenschicht, hinter der das konkrete Sprachmodell austauschbar ist. In WeaveOpenAI-kompatible Endpunkte, dazu ein deterministischer Fake-Provider für Tests — so laufen alle Tests ohne API-Schlüssel, ohne Kosten und mit immer gleichem Ergebnis. |
| Zentrale Chat-Provider-KonfigurationADR-0007 | Endpoint, Modell, API-Key, Timeout und Temperatur des OpenAI-kompatiblen Chat-Providers werden zentral gepflegt statt je Dienst konfiguriert.
In WeaveVerwaltet in Ingest unter Administration → Chat & LLM, der Schlüssel Fernet-verschlüsselt. Runtime liest vor jedem direkten Turn einen frischen Snapshot über eine mit CHAT_CONFIG_SERVICE_TOKEN geschützte interne Schnittstelle — ein Providerwechsel braucht keinen Neustart. n8n-Bots verwalten ihr Modell weiter in n8n. |
| SSE / Streamingtext/event-stream | Server-Sent Events: eine offene HTTP-Verbindung, über die der Server Häppchen nachschiebt. So erscheint die Antwort Wort für Wort statt nach Sekunden am Stück. In WeaveDie Reihenfolge ist garantiert: erst der Trace, dann die Text-Häppchen, dann die Quellen, dann das Ende. Rechte, Suche und Guard laufen vollständig vor dem ersten Zeichen. |
| n8n | Ein Werkzeug, in dem Automatisierungen als Ablaufdiagramm zusammengeklickt werden — inklusive Agenten, die selbst entscheiden, welchen Schritt sie als Nächstes tun. In WeaveEin Bot kann statt eines Modells einen n8n-Flow als Provider haben. Der Flow bekommt ein kurzlebiges Token mit genau den Leserechten des Fragenden — und sucht damit über Weave-Tools zurück. Seit Vertragsversion 2 streamt der Flow, mit Keepalives entlang der ganzen Kette, sodass ein einzelner Turn auch Stunden dauern darf. |
| Agentenmodus | Statt einer einzelnen Suche zerlegt der Bot eine Frage in Teilfragen und lässt sie parallel von eigenen Recherche-Durchläufen bearbeiten, bevor er die Ergebnisse zu einer Antwort zusammenführt.
In WeaveEin LangGraph-Ablauf mit den Knoten plan, research (mehrfach parallel), merge und answer. Eine einfache Anfrage nimmt weiterhin den kurzen Pfad ohne Zerlegung. |
| Rechercheprofil | Ein Subagent im Agentenmodus mit eigener Frage, eigenem Budget und einer festen Bindung an bestimmte Wissensbereiche — er sieht nie mehr, als ihm zugewiesen wurde. In WeaveDer Umfang ist die Schnittmenge aus den Rechten des Fragenden, den Sammlungen des Hauptbots und den Sammlungen des Profils. Bricht ein Profil ergebnislos ab, nennt die Antwort die Lücke ausdrücklich — nie eine erfundene Antwort an ihrer Stelle. |
| Begriff | Bedeutung |
|---|---|
| Föderierte AnmeldungADR-0006 | Weave-API hat keine eigene Identität mehr: Der Chat schickt zum Anmelden auf die Ingest-Anmeldeseite, und wer sich dort ausweisen kann — Passwort oder eine der OIDC-Verbindungen —, ist damit auch am Chat angemeldet.
In WeaveTeam und Admin-Bit werden bei jeder Anmeldung neu gelesen. Konten sind über die Ingest-Benutzer-ID verknüpft (Präfix weave-ingest:), nie über Name oder E-Mail. |
| Handoff-Code | Einmal-Code, mit dem Ingest eine angemeldete Identität an Weave-API übergibt. Er reist in einer Redirect-URL und ist deshalb absichtlich wertlos für sich allein.
In WeaveEinmalig, rund 60 Sekunden gültig, nur mit dem geteilten WEAVE_HANDOFF_SECRET server-zu-server einlösbar (/api/v1/auth/handoff/exchange). Das Rücksprungziel liegt fest in Ingests HANDOFF_CALLBACK_URL, nie in einem Parameter. |
| Session-Exchange-Code | Der zweite Einmal-Code derselben Kette: Weave-API übergibt damit die frische Sitzung an die Chat-Oberfläche.
In WeaveLandet am Endpunkt /api/auth/sso/callback, dessen Backend ihn gegen ein Sitzungstoken tauscht — dasselbe Muster wie beim Handoff-Code, ein Glied weiter. |
| Secure-Cookie | Ein mit Secure markiertes Cookie, das über http verworfen wird. Safari macht dabei anders als Chrome auch für localhost keine Ausnahme.
In WeaveDas Flag folgt deshalb dem Schema der Anfrage (X-Forwarded-Proto), nicht NODE_ENV, das im Container immer production ist. |
| Harte Grenzeallowed_teams · allowed_collections | Eine Einschränkung, die der Server selbst setzt und die der Aufrufer nicht weglassen kann — im Gegensatz zu einem Filter, den man einfach nicht mitschickt. In WeaveWird als SQL-Bedingung vor dem Ranking erzwungen. Ein Filter kann innerhalb der Grenze verfeinern, sie aber nie erweitern. |
| Sentinel__none__ | Ein reservierter Sonderwert, der einen Fall ausdrückt, für den es keinen echten Wert gibt.
In WeaveSteht für „Dokumente ganz ohne Collection". Nötig, weil IN (…) in SQL niemals auf NULL passt — ohne den Sentinel wäre der gesamte Altbestand still aus jeder Suche verschwunden. |
| Delegations-Token | Ein kurzlebiger Ausweis, den ein Dienst für einen anderen ausstellt und in den er den erlaubten Umfang gleich hineinschreibt und mitsigniert. In WeaveRuntime stellt ihn für n8n und MCP aus: fünf Minuten gültig, die lesbaren Collections eingebettet. Damit kann der Agent nie mehr sehen als der Mensch, für den er arbeitet. |
| Dienst-Token | Statisches Bearer-Token für Aufrufe zwischen Diensten, etwa RETRIEVAL_API_TOKEN, RUNTIME_API_TOKEN, KNOWLEDGE_API_TOKEN, EMBEDDINGS_API_TOKEN oder RERANKER_API_TOKEN.
In WeaveImmer fail-closed — nicht gesetzt heißt 503, nie „Auth aus". Verglichen wird konstant in der Zeit, nie mit einem einfachen ==. |
| KNOWLEDGE_API_TOKEN | Dienst-Token vor Weave-Knowledges Lese-API (/documents, /collections), die sonst den indizierten Bestand an der Team-Prüfung vorbei herausgeben würde.
In WeaveOptional, weil kein anderer Dienst diese Routen aufruft. Ohne Wert antworten sie 503, Webhook und /health laufen unbeeinflusst weiter. |
| X-Tools-Service-Token | Zweiter Ausweis bei Weave-Tools neben Authorization: Der Header beantwortet „darf dieses Deployment hier überhaupt anfragen", Authorization „wessen Rechte gelten für diesen Aufruf".
In WeaveBewusst zwei getrennte Header, damit ein einzelner Aufruf beide Fragen zugleich beantworten kann. |
| HMAC-SHA256 | Eine Prüfsumme mit geteiltem Geheimnis. Nur wer das Geheimnis kennt, kann sie erzeugen — also belegt sie Herkunft und Unverändertheit zugleich. In WeaveSigniert Webhook-Zustellungen und Delegations-Token. Geprüft wird immer über den rohen Body: neu zusammengesetztes JSON hätte eine andere Signatur. |
| HMAC-Webhook | Knowledges Eingang prüft eingehende Ereignisse per HMAC-SHA256 über den rohen Rumpf (X-Weave-Ingest-Signature: sha256=…) und fail-closed.
In WeaveEin Bearer-Token würde nur belegen, dass der Absender ein Geheimnis kennt — nicht, dass der Rumpf unterwegs unverändert blieb. Deshalb HMAC für Schreibzugriffe, Dienst-Token für Lesezugriffe. |
| Constant-time-Vergleichhmac.compare_digest | Ein Vergleich, der immer gleich lange dauert. Ein normaler Vergleich bricht beim ersten falschen Zeichen ab — aus diesem Zeitunterschied lässt sich ein Geheimnis Zeichen für Zeichen erraten. In WeavePflicht bei jedem Token- und Signaturvergleich. |
| Token-Introspection | Ein Dienst fragt beim Identitätsdienst nach: Gehört dieses Token zu jemandem, und zu wem? In WeaveSo prüft der MCP-Dienst Rechte, ohne die Nutzerdatenbank mitzulesen. Die Antwort verrät nie, warum ein Token ungültig ist — sonst wäre sie ein Orakel zum Ausprobieren. |
| MCPModel Context Protocol | Ein offener Standard, über den ein Sprachmodell externe Werkzeuge und Daten anspricht — ein einheitlicher Stecker statt einer Sonderlösung je Anbindung.
In WeaveBietet list_collections und search an. Entscheidend: der Umfang kommt aus dem Token, nie aus den Werkzeug-Argumenten — sonst könnte das Modell sich selbst Zugriff erteilen. |
| SSRFServer-Side Request Forgery | Ein Angreifer bringt den Server dazu, eine Adresse seiner Wahl aufzurufen — und erreicht so interne Dienste, die von außen unerreichbar wären. In WeaveZwei Vorkehrungen: Adressen werden lokal aus der Konfiguration gebaut statt aus Fremddaten übernommen, und n8n-Webhook-URLs müssen schon beim Laden der Bot-Datei zu einer Allowlist passen. |
| IDORInsecure Direct Object Reference | Ein Objekt wird allein über seine ID herausgegeben, ohne zu prüfen, ob der Anfragende es sehen darf. Wer IDs durchprobiert, liest fremde Daten. In WeaveGespräche sind in der Abfrage selbst an ihren Eigentümer gebunden — ein fremdes Gespräch ergibt 404, nicht 403: auch die Existenz bleibt geheim. |
| Prompt-Injection | In einem Dokument oder einer Webseite stehen Anweisungen, die das Modell als Befehl liest — obwohl sie nur Inhalt sind. In WeaveDer Grund für die klare Trennung zwischen Anweisungsteil und nummeriertem Kontextblock im Prompt: gefundene Textstellen sind Daten, nicht Aufträge. |
| Rate-LimitFixed Window | Höchstens N Anfragen je Zeitfenster. „Fixed Window" heißt: der Zähler springt zum Fenstergrenzwert zurück — einfach, aber an der Grenze kurz doppelt so durchlässig.
In WeavePro Nutzer im Gateway, mit Retry-After in der Antwort. Bewusst prozesslokal für den Anfang, mit dokumentierter Grenze bei mehreren Instanzen. |
| Fernet & HKDF | Fernet verschlüsselt Daten im Ruhezustand; HKDF leitet aus einem Hauptschlüssel getrennte Teilschlüssel je Zweck ab, sodass ein Leck nicht alles betrifft. In WeaveSchützt gespeicherte Zugangsdaten. Bekannte Schwachstelle des Erbes: der Hauptschlüssel war nicht rotierbar — das ADR zur Secrets-Strategie löst es über eine versionierte Schlüsselliste. |
| Technische Identitätwti_…-Token | Ein eigener Ausweis für ein System statt für eine Person — für eine eigenständige Integration oder einen externen KI-Agenten, der ohne menschliche Sitzung dahinter auf Wissen zugreifen soll. In WeaveStandardmäßig ohne jeden Wissenszugriff, bis ein Administrator Wissensbereiche ausdrücklich zuweist. Nur der Hash liegt in der Datenbank, das Token selbst nur einmal bei Erstellung oder Rotation sichtbar. Widerruf, Ablauf und ein eigenes Audit-Log gehören dazu; Zugriff läuft immer über Weave-Tools, nie direkt auf Retrieval. |
| Begriff | Bedeutung |
|---|---|
| weave.yaml | Die eine Konfigurationsquelle der Plattform im Wurzelverzeichnis des Repos. Jeder Wert wird genau einmal deklariert: geteilte Werte unter shared: mit ihren Zielen aus Dienst und Variablenname, dienstspezifische Werte unter services.<dienst>.settings.
In WeaveGeheimnisse stehen nie in der Datei selbst, sondern nur als Name der Umgebungsvariable, aus der render ihren Wert zur Laufzeit liest. |
| renderpython scripts/weave_config.py render | Erzeugt aus weave.yaml die deploy/.env für den Stack. Geteilte Werte werden dabei einmal berechnet und in jede ihrer Zielvariablen gespiegelt.
In WeaveDie erzeugte Datei wird nie von Hand bearbeitet — sie trägt eine Kopfzeile, an der check erkennt, dass sie generiert ist. |
| checkpython scripts/weave_config.py check | Prüft eine bestehende .env auf Widersprüche: auseinandergelaufene geteilte Werte (Geheimnisse dabei nur als Fingerabdruck), fehlende Pflichtwerte und ob die Datei noch zu weave.yaml passt.
In WeaveDazu zählen auch inhaltliche Regeln wie SEARCH_TOP_K > RERANKER_MAX_DOCUMENTS, die zum Embedding-Modell passende EMBEDDING_DIMENSION, zu FRONTEND_PORT passende CORS_ORIGINS und die vollständige Anmeldekette über drei Dienste. |
| Geteilte Werte | Werte, die in mehreren Diensten zeichengleich sein müssen, weil der eine sie erzeugt und der andere sie prüft — etwa RETRIEVAL_API_TOKEN beim Aufrufer und beim Prüfer, oder EMBEDDING_API_KEY gegenüber EMBEDDINGS_API_TOKEN.
In WeaveDrift zeigt sich nicht als Fehlermeldung, sondern als stilles 401 oder 503 an einer Dienstgrenze — deshalb prüft check sie ausdrücklich. |
| CORS_ORIGINS / FRONTEND_PORT | Zwei Einstellungen, die zusammengehören: CORS_ORIGINS ist bei Ingest zugleich die CSRF-Herkunftsprüfung und muss den Port nennen, unter dem der Browser das Frontend lädt.
In WeaveWer nur FRONTEND_PORT verschiebt, weil 3000 belegt ist, bekommt „Disallowed CORS origin" beim Preflight — check meldet diese Kombination. |
| Celery, Broker, Queue | Arbeit, die zu lange für eine HTTP-Antwort dauert, wandert als Auftrag in eine Warteschlange (den Broker, hier Redis) und wird von Worker-Prozessen abgearbeitet.
In WeaveOCR und Indexierung laufen so. Jeder Dienst hat eine eigene benannte Queue — sonst würden sich die Worker gegenseitig die Aufträge wegnehmen. Ingest trennt seit v0.7.0 zusätzlich die lange OCR (weave.ingest.ocr) von allem anderen (weave.ingest.default), damit ein Import nie hinter einem Scan wartet. |
| OCR-Profil--profile ocr | Ein Compose-Profil, hinter dem der mehrere Gigabyte große PaddleOCR-Worker hängt, damit der Rest des Stacks in Minuten statt erst nach dessen Download startet.
In WeaveOhne dieses Profil bleiben Aufträge auf PENDING stehen, und die Logs-Ansicht bleibt leer, weil erst der Worker sie füllt. |
| Idempotenz | Dieselbe Aktion mehrfach ausführen, ohne dass mehr passiert als beim ersten Mal.
In WeaveÜber den Schlüssel job_id:content_sha256: ein doppelt zugestelltes Event erzeugt kein zweites Dokument, sondern wird als Wiederholung erkannt. |
| At-least-once | Eine Zustellgarantie: die Nachricht kommt mindestens einmal an — bei Wiederholungen möglicherweise öfter. „Genau einmal" ist verteilt kaum ehrlich zu haben. In WeaveGenau deshalb liegt die Idempotenz beim Empfänger. Der Sender darf ruhig doppelt liefern. |
| Alembic-Migration | Schemaänderungen als versionierte, aufeinander aufbauende Skripte statt handgeschriebener SQL-Befehle auf dem Server. In WeaveJede Migration muss auf SQLite (Tests) und Postgres (Betrieb) laufen — und gegen eine gefüllte Tabelle, nicht nur gegen eine leere. |
| ADRArchitecture Decision Record | Eine kurze Notiz zu einer Architekturentscheidung: Kontext, Entscheidung, Konsequenzen, verworfene Alternativen.
In WeaveSieben Stück in docs/adr/, zuletzt 0006 (föderierte Anmeldung) und 0007 (zentrale Chat-Provider-Konfiguration). Sie beantworten die Frage, die in einem Jahr am teuersten wird: „Warum eigentlich so?" |
| Read-Model & Single Writer | Genau ein Dienst darf schreiben, andere lesen dieselben Daten mit. Das vermeidet Schreibkonflikte, ohne alles durch eine API zu zwängen. In WeaveKnowledge schreibt den Chunk-Store, Retrieval liest ihn nur — weil Vektor- und Volltextsuche zwingend in der Datenbank laufen müssen. Als Vertrag dokumentiert. |
| Vertragstest | Ein Test, der nicht Verhalten prüft, sondern die vereinbarte Form — gegen ein Schema, das beide Seiten teilen. In WeavePrüft das Frontmatter aller Verarbeitungswege gegen ein JSON-Schema. Die Lücke, die er nicht schließt: dass jeder Dienst gegen sein eigenes Bild des Nachbarn testet — genau da schlug der Registry-Fehler zu. |
| Webhook | Statt regelmäßig nachzufragen, ruft der Sender bei einem Ereignis von sich aus eine hinterlegte Adresse auf.
In WeaveTrägt document.released, document.processed und collection.updated — signiert, mit Wiederholung bei Fehlern und einem Auslieferungsprotokoll. Indexiert wird nur die Freigabe. |
| OpenAI-kompatibler Shim | Ein Adapter, der ein fremdes System so aussehen lässt wie die OpenAI-Schnittstelle — dann funktionieren alle vorhandenen Clients ohne Anpassung.
In WeavePOST /v1/chat/completions, wobei der Modellname die Bot-ID ist. So können bestehende OpenAI-kompatible Clients optional dieselbe Rechte-, Bot- und Laufzeitkette wie die eigene Chat-Oberfläche nutzen. |
| Dokumenten-Compiler | Ein Bild aus dem Übersetzerbau: Aus vielen Eingabeformaten entsteht eine einzige, saubere Zwischenform, auf der alles Weitere aufsetzt. In WeaveDie Rolle von Weave-Ingest. PDF, Office, Mail und Confluence gehen hinein, strukturiertes Markdown mit Metadaten kommt heraus — die einzige Form, die alle anderen Dienste kennen müssen. |
| Sicherung & WiederherstellungDisaster Recovery | Ein passphrasegeschütztes Archiv aller Ingest-Daten, das sich auf einer frischen Installation wieder einspielen lässt — der Notausgang, wenn eine Umgebung neu aufgesetzt werden muss. In WeaveVerschlüsselte Spalten werden unter der Passphrase neu verschlüsselt, nicht unter dem Server-eigenen Schlüssel. Der Wissensindex selbst gehört nicht zum Archiv: Nach dem Import baut er sich aus den weiterhin gültigen Freigaben von selbst wieder auf, eingespielt vom ersten neuen Administrator. |
| Index-Wartung | Manuelle Werkzeuge im Admin-Bereich für die drei Fälle, in denen der Index von selbst nicht nachzieht: Vektoren neu berechnen, den Index aus den Freigaben neu aufbauen, oder ein einzelnes Dokument beziehungsweise einen ganzen Wissensbereich gezielt neu indizieren. In Weave„Index neu aufbauen" stößt denselben Nachliefer-Mechanismus an, der auch nach einer Wiederherstellung greift. „Vektoren neu berechnen" ist der richtige Schritt nach einem Wechsel des Embedding-Modells. |
Kein Begriff passt zu dieser Suche.