Eine Quelle ist noch kein Wissen

Diesen Beitrag anhören (13 Min.)

Zwei Uploads tragen verschiedene Dateinamen. Ihr Inhalt ist bytegleich. Ein dritter Upload beschreibt dasselbe Meeting, enthält aber eine nachträglich ergänzte Zeile. Für einen Dateiordner sind das drei Dokumente. Für eine Wissensbasis sind es eine technische Wiederholung und zwei fachlich unterschiedliche Quellenstände.

WikiKit trennt deshalb Aufnahme und Bedeutung. Beim Ingest wird das Rohmaterial erworben, extrahiert, normalisiert archiviert und über SHA-256 adressiert. Erst danach beginnt die Frage, welche Konzepte und Claims davon betroffen sein könnten. Diese Folge bleibt beim ersten Teil: Was eine Quelle ist, warum sie unverändert bleiben muss und weshalb ihr Besitz noch kein Wissen beweist.

Die Quelle ist der Rückweg

Eine Konzept-Seite kann sich im Lauf der Zeit ändern. Claims werden ergänzt, bestritten oder stillgelegt. Der ursprüngliche Text darf dabei nicht mit jeder neuen Interpretation umgeschrieben werden. Sonst verliert ein Zitat seinen festen Bezugspunkt.

Eingabe · Text, URL oder Dokument mit Herkunft annehmen
Extraktion · genau die später gelesene Markdown-Fassung erzeugen
Hash · bytegleiche Inhalte erkennen und deduplizieren
Archiv · den verwendeten Quellenstand unveränderlich bewahren
Vorschlag · spätere Interpretation getrennt und revidierbar halten

Bei Markdown und Text ist der eingereichte Inhalt direkt lesbar. PDF, DOCX, XLSX und CSV benötigen eine Extraktion. WikiKit bewahrt den daraus gewonnenen Markdown-Inhalt als Quelle, weil genau diese Fassung für Klassifikation und Synthese verwendet wird. Der originale Uploadtyp, Titel und weitere Metadaten bleiben zuordenbar.

Das ist keine Behauptung, dass Extraktion fehlerfrei sei. Eine Tabelle kann missverständlich umgebrochen, ein PDF unvollständig erkannt oder eine URL später verändert werden. Gerade deshalb muss die vom Modell tatsächlich gelesene Fassung erhalten bleiben. Nur dann lässt sich später beurteilen, ob ein Fehler schon in der Quelle, in der Extraktion oder in der Interpretation entstand.

Derselbe Inhalt erhält denselben Hash

SHA-256 bildet aus dem Quellinhalt einen festen Digest. Zwei identische Inhalte erzeugen denselben Wert. WikiKit verwendet ihn zur Deduplizierung und antwortet bei einem bereits aufgenommenen Inhalt mit 409 already_ingested.

import { createHash } from "node:crypto";

function sourceDigest(markdown: string): string {
  return createHash("sha256").update(markdown, "utf8").digest("hex");
}

Der Hash vergleicht Inhalt, nicht Bedeutung. Ein zusätzliches Leerzeichen kann je nach vorheriger Normalisierung einen neuen Digest erzeugen. Zwei unterschiedlich formulierte Protokolle mit derselben Entscheidung bleiben verschiedene Quellen. Umgekehrt ist ein identischer Text nicht plötzlich fachlich neu, nur weil sein Dateiname oder seine Upload-URL wechselt.

Diese Grenze ist hilfreich. Semantische Deduplizierung durch ein Modell wäre probabilistisch: Heute könnten zwei Texte als gleich gelten, morgen als verschieden. Der kryptografische Digest beantwortet eine engere Frage deterministisch: Ist die archivierte Eingabe identisch?

URLs werden zu einem Stand

Eine URL ist kein unveränderlicher Beleg. Die Seite dahinter kann morgen einen anderen Text ausliefern oder verschwinden. Beim URL-Ingest ruft WikiKit den Inhalt ab, wendet seine Sicherheitsregeln gegen unerwünschte Netzwerkziele an und archiviert die gelesene Fassung. Die URL bleibt Metadatum; zitiert wird der gespeicherte Stand.

curl -X POST "$WK/v1/spaces/engineering/ingest" \
  -H "Authorization: Bearer $WK_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Retry policy reference",
    "url": "https://docs.example.com/retry-policy",
    "source_kind": "article"
  }'

URL-Abruf braucht einen SSRF-Schutz. Ein Wissensdienst darf nicht zum Proxy für localhost, Link-Local-Adressen oder private Netze werden. Weiterleitungen müssen erneut geprüft, Antwortgrößen begrenzt und Zeitüberschreitungen sauber behandelt werden. Das sind Eigenschaften des Ingest-Wegs, keine Aufgaben eines späteren prüfende Personen.

Ein erneuter Ingest derselben URL kann einen neuen Quellstand ergeben, wenn sich der Inhalt geändert hat. Das ist sinnvoll. Die beiden Quellen zeigen, was zu zwei Zeitpunkten tatsächlich gelesen wurde. Ein Claim kann später die neuere Quelle zitieren, während die ältere Revision weiterhin auf ihren damaligen Beleg verweist.

Ein Dateityp ändert den Ablauf nicht

Dokumente gelangen über einen Upload-Pfad in denselben Ingest. Die Dateiendung wählt den Extraktor; danach folgt wieder Markdown, Hash, Archiv, Klassifikation und Vorschlag.

curl -X POST "$WK/v1/spaces/engineering/ingest/document?filename=decision.pdf" \
  -H "Authorization: Bearer $WK_KEY" \
  --data-binary @decision.pdf

Für Menschen ist wichtig, dass ein erfolgreich hochgeladenes PDF noch keine freigegebene Konzept-Seite bedeutet. Der Request liefert einen asynchronen Ingest-Handle. Sein Status endet mit done oder failed. done enthält die source_id; eine proposal_id kann fehlen, wenn die Klassifikation keine relevante Wissensänderung erkennt.

Der Ablauf unterscheidet damit mehrere Ergebnisse:

identischer Inhalt: keine neue Quelle, already_ingested;
neuer Inhalt ohne betroffene Konzepte: Quelle archiviert, kein Vorschlag;
neuer Inhalt mit möglicher Änderung: Quelle archiviert, Vorschlag wartet auf Review;
Extraktions- oder Providerfehler: Ingest schlägt mit einem erklärten Fehler fehl.

Diese Zustände verhindern den verbreiteten Kurzschluss „Upload erfolgreich, Wissen aktualisiert“. Aufnahme ist nur die erste Stufe.

Asynchron heißt beobachtbar, nicht unbestimmt

Der Ingest antwortet früh, weil Dokumentextraktion und LLM-Verarbeitung länger dauern können als ein gewöhnlicher API-Request. Der zurückgegebene Handle macht den Vorgang trotzdem eindeutig. Ein Client speichert die ingest_id, folgt dem Location-Header und polliert mit begrenztem Intervall bis zu einem Endzustand.

{
  "ingest_id": "ing_01J8Z",
  "status": "done",
  "source_id": "source_7f2c",
  "proposal_id": "proposal_91ab",
  "error": null
}

source_id und proposal_id beantworten verschiedene Fragen. Die Quelle kann erfolgreich archiviert sein, obwohl kein Vorschlag nötig ist. Umgekehrt darf es keinen Vorschlag ohne seine referenzierten Quellen geben. Bei failed liefert der Fehler eine maschinenlesbare Kennung und eine verständliche Beschreibung; der Client soll nicht aus einem fehlenden Vorschlag-Feld auf Erfolg oder Misserfolg schließen.

Ein Workflow benötigt zusätzlich einen Timeout für das Polling. Wird der Ingest innerhalb der vereinbarten Zeit nicht fertig, bleibt seine ID im Ausführungsprotokoll. Ein späterer Lauf kann den Status erneut prüfen, statt das Dokument sofort noch einmal einzureichen. So entsteht bei einer langsamen Providerantwort keine Kaskade identischer Jobs.

Für eine interaktive Nutzung reicht dieselbe Mechanik. Der Mensch sieht „Quelle wird verarbeitet“, danach „kein Wissensvorschlag nötig“ oder einen Link auf die wartende Änderungsvorschlag. Die Oberfläche oder der Agent muss dafür keinen eigenen versteckten Zustand erfinden.

Quelle und Citation sind verschiedene Objekte

Eine Quelle kann zwanzig Seiten umfassen. Eine Citation zeigt auf eine konkrete Passage daraus und trägt das wörtliche Zitat. Der Claim verweist auf diese Citation. Dadurch muss ein Leser nicht jedes Mal das gesamte Dokument durchsuchen.

{
  "source_id": "source_7f2c",
  "quote": "The retry budget is shared across all attempts.",
  "locator": "Decision, paragraph 2"
}

Der Locator hilft beim Finden, ist aber kein Ersatz für das Zitat. Seitenzahlen können sich bei einer anderen PDF-Darstellung verschieben, Abschnittsnamen doppelt vorkommen. Das verbatim gespeicherte Zitat ist der mechanisch prüfbare Anker. WikiKit kontrolliert, ob es tatsächlich im archivierten Inhalt vorkommt.

Diese Kontrolle beweist weiterhin nicht, dass das Zitat korrekt interpretiert wurde. Ein Satz kann durch seinen Absatz eingeschränkt werden. Dafür gibt es den Review. Der Dienst trennt also eine automatisierbare Prüfung – Zitat vorhanden – von einer fachlichen – Aussage durch Kontext gedeckt.

Metadaten brauchen dieselbe Zurückhaltung

Titel, Quellart, URL und Zeitpunkt erleichtern das Finden. Sie dürfen jedoch keine vertraulichen Informationen enthalten, die der eigentliche Inhaltsschutz später nicht berücksichtigt. Ein Dateiname wie termination-alice-2026.pdf verrät bereits mehr als ein neutraler Titel. Das gilt besonders für Logs, Webhooks und Reportstatistiken, die Metadaten aggregieren.

WikiKits Produktstatistikpfade geben deshalb begrenzte Summen über Ingests, Review-Aktivität, LLM-Nutzung und Webhooks aus. Sie liefern keine Quelltexte, Prompts, Identitäten, Secrets oder internen Zeilenkennungen. Das operative Reporting kann erkennen, dass zehn Dokumente verarbeitet wurden, ohne ihre Titel offenzulegen.

{
  "window": {
    "from": "2026-08-10T00:00:00Z",
    "to": "2026-08-11T00:00:00Z"
  },
  "ingests": {
    "completed": 10,
    "failed": 1
  }
}

Die eigentlichen Quellen sind Space-isoliert. Ein Schlüssel für engineering kann keine Quelle aus finance lesen. Ein Export enthält nur den angeforderten Space. Diese Grenze ist bedeutender als ein Namenspräfix, weil sie von Authentifizierung und Query-Pfaden durchgesetzt wird.

Aufbewahrung folgt dem Zweck. Quellen, die sichtbare Claims tragen, müssen so lange erhalten bleiben, wie deren Herkunft prüfbar sein soll. Eine harte Löschung würde Citations beschädigen. Sensible Daten sollten deshalb schon vor dem Ingest minimiert, in den passenden Space gelegt und nach einer bewusst festgelegten Policy verarbeitet werden. Ein Wissenssystem ist kein geeigneter Ort für Material, das eigentlich gar nicht dauerhaft aufbewahrt werden darf.

Extraktion wird selbst zum prüfbaren Schritt

Bei einem PDF kann die prüfende Person die archivierte Markdown-Fassung neben das Original legen. Fehlt eine entscheidende Tabellenzeile, wird nicht der daraus entstandene Claim repariert, als sei nur seine Formulierung falsch. Die Quelle wird mit einem korrigierten Extraktionsweg erneut aufgenommen, und der neue Vorschlag verweist auf den neuen Quellstand.

Dieser Unterschied bewahrt die Fehlerursache. Ein Claim-Edit hätte den Anschein erweckt, die ursprüngliche Quelle habe die korrigierte Aussage getragen. Eine neue Quelle zeigt dagegen, dass sich die maschinenlesbare Grundlage geändert hat.

Für häufige Dokumenttypen lohnt ein kleiner Golden-Testbestand. Ein Beispiel-PDF, eine DOCX-Datei und eine Tabelle werden bei jeder Änderung des Extraktors erneut in erwartetes Markdown umgewandelt. So fällt ein Bibliotheksupgrade auf, das Überschriften, Zellreihenfolge oder Zeichencodierung verändert.

fixture document
  -> extractor
  -> normalized markdown
  -> snapshot diff
  -> ingest pipeline tests

Die Wissensbasis muss dafür nicht behaupten, das Originalformat vollständig zu verstehen. Sie braucht einen stabilen, lesbaren Arbeitsstand und einen nachvollziehbaren Weg, Fehler zu korrigieren.

Was sich seit damals geändert hat

Sauberes Grounding I zeigte, wie ein Modell eine plausible, aber nicht vorhandene Methode erfinden kann. Die damalige Konsequenz war, die echte Codebasis oder Dokumentation in den Kontext zu holen, statt auf Modellwissen zu vertrauen. Das bleibt richtig.

Neu ist der dauerhafte Quellstand zwischen Dokument und Agent. WikiKit archiviert genau die Fassung, die verarbeitet wurde, dedupliziert technische Wiederholungen und bindet spätere Claims an wörtliche Passagen. Grounding ist damit nicht nur eine Aktion innerhalb einer Session. Es erhält eine wiederverwendbare Herkunftskette, die weitere Sessions unabhängig vom ursprünglichen Chat lesen können.

Der Artikel Wissen, das die Session überlebt warnte außerdem vor einer Halde veralteter Wissensdateien. Unveränderte Quellen lösen dieses Problem nicht allein. Sie bewahren die Geschichte; der aktuelle Geltungsstatus liegt bei Claims und Revisionen. Gerade die Trennung erlaubt beides: Originale bleiben erhalten, sichtbares Wissen darf sich kontrolliert verändern.

Was eine Quelle nicht leisten soll

Ein großer Quellbestand ist kein Qualitätsbeweis. Tausend PDFs können unauffindbar, widersprüchlich oder veraltet sein. WikiKit ist deshalb keine Ablage, die durch Masse besser wird. Quellen erhalten ihren Wert erst, wenn sie einen geprüften Claim, eine Entscheidung oder eine nachvollziehbare Änderung tragen.

Die Quelle entscheidet auch nicht über Wahrheit. Ein Meeting-Protokoll kann einen Irrtum enthalten. Eine offizielle Dokumentation kann veraltet sein. Zwei Quellen können sich widersprechen. Das System bewahrt diese Belege, macht ihren Konflikt sichtbar und überlässt die fachliche Entscheidung dem Review.

Für den Einstieg genügt eine kleine Disziplin: Quelle so einreichen, wie sie tatsächlich vorlag; Titel und Art verständlich benennen; Ingest bis zum Ende pollieren; den Vorschlag lesen; erst danach über Freigabe sprechen. So bleibt der erste Schritt klein und die spätere Prüfung möglich.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare