Ich habe in den letzten Tagen an etwas gebaut, das ich am liebsten an mir selbst teste, bevor ich groß darüber schreibe: einen Kontext-Graphen für meiersworld.de. Der Unterschied zu einem klassischen Wissensgraphen klingt zunächst wie Wortklauberei, ist es aber nicht. Ein Wissensgraph beantwortet die Frage „Was ist X?“ — eine Entität, ihre Kategorie, ihre Beziehungen zu anderen Entitäten. Ein Kontext-Graph beantwortet eine andere Frage: „Warum vertrete ich X aktuell in dieser Form — und seit wann nicht mehr in der alten?“
📦 Kurzversion für Eilige und Maschinen
Diese Box enthält strukturierte Metadaten zum Artikel – maschinenlesbar und für einen schnellen Überblick.
- Texttyp
- Technischer Blogartikel
- Besprochenes Werk / Thema
- Entwicklung eines Kontext-Graphen für zeitlich gültige Wissensrepräsentation in RAG-Systemen
- Zentrales Argument
-
Retrieval-Systeme müssen zeitliche Gültigkeit von Aussagen tracken, um verlässlich zu sein und veraltete Behauptungen nicht mit aktuellen gleichzusetzen
- Kernthese
- Ein Kontext-Graph muss Behauptungen mit ihrer zeitlichen Gültigkeit und Relationen dokumentieren, nicht nur Wissensfakten speichern
- Relevante Konzepte
- Empfohlen für
- Entwickler, KI-Praktiker, Wissensmanagementsystem-Architekten
- Einordnung durch den Autor
- Technische Dokumentation mit architekturellen Erkenntnissen
- Verweise im Text
- Entitäten
Der Anlass war banal. Ich habe über Monate Behauptungen in Artikeln aufgestellt, manche davon später präzisiert, manche schlicht überholt. Für mich als Autor ist das normal — Meinungen entwickeln sich. Für ein Retrieval-System, das meine Artikel als Kontext für KI-Antworten nutzt, ist es ein Problem: Ohne zeitliche Gültigkeit zitiert ein System meine These von vor sechs Monaten mit derselben Autorität wie die von heute, obwohl ich sie längst korrigiert habe.
Die Architektur in Kürze
Technisch sitzt das Ganze auf meinem bestehenden RAGPaddy-Stack in Supabase, ergänzt um zwei neue Tabellen: Knoten und Kanten. Ein Knoten ist eine These, ein Artikel, eine Entität, ein Beleg. Eine Kante beschreibt die Beziehung — „äußert“, „ersetzt“, „präzisiert“, „widerspricht“, „belegt durch“. Die Extraktion übernimmt Claude: Für jeden Artikel fragt ein mu-Plugin gezielt danach, welche überprüfbaren Thesen ich tatsächlich vertrete — nicht, worüber der Text handelt, sondern was ich als Autor tatsächlich behaupte. Referierte oder widerlegte Fremdpositionen zählen ausdrücklich nicht.
Dubletten sind das eigentliche Problem bei so einem System. Wenn ich dieselbe These in einem deutschen und einem englischen Artikel formuliere, will ich nicht zwei Knoten, die nichts voneinander wissen. Die Lösung ist Embedding-basierte Ähnlichkeit über Voyage AI: Liegt eine neue These über 93 Prozent Ähnlichkeit zu einer bestehenden, wird der alte Knoten wiederverwendet — sprachübergreifend, ohne dass ich manuell verlinke.
Eine Sache hat mich beim Entwerfen der Datenbank-Logik überrascht: Automatisierte Statuslogik per Datenbank-Trigger ist der einzige Weg, veraltete Behauptungen zuverlässig zu markieren, ohne dass ich jede Aktualisierung von Hand nachpflegen muss. Sobald ich eine „ersetzt“- oder „präzisiert“-Kante im Backend bestätige, setzt ein Postgres-Trigger automatisch den Status der älteren These und trägt das Gültigkeits-Enddatum nach. Ich selbst muss nur noch eine Kante bestätigen, nicht zwei Zustände synchron halten.
📢 Wollen Sie passende Werbung sehen?
Diese Werbung wird durch Google AdSense bereitgestellt und zum Thema dieses Artikels passend ausgewählt.
Themen: Entwicklung eines Kontext-Graphen für zeitlich gültige Wissensrepräsentation in RAG-Systemen, Kontext-Graph, Wissensgraph, RAG-System, Embedding-Ähnlichkeit, Ontologie, Ein Kontext-Graph muss Behauptungen mit ihrer zeitlichen Gültigkeit und Relationen dokumentieren, nicht nur Wissensfakten speichern, Entwickler, KI-Praktiker, Wissensmanagementsystem-Architekten, Technische Dokumentation mit architekturellen Erkenntnissen
Werbung wird geladen …
Zum Thema bei Amazon
🔍 „Wissensgraph Ontologie Software" auf Amazon suchen* Affiliate-Link. Bei einem Kauf erhalte ich eine kleine Provision.
Die Lücke, die ich übersehen hatte
Interessant wurde es, als ich mit Claude über das Thema Ontologien gesprochen habe — im formalen Sinn: Klassen, Instanzen, Relationen, Axiome. Dabei ist aufgefallen, dass mein System zwar funktioniert, aber nirgends dokumentiert war, was jede Relation eigentlich bedeuten darf. Durfte „handelt von“ nur von einem Artikel zu einer Entität zeigen, oder auch von einer These? Stand nirgends fest. Eine informelle Sammlung von Tags reicht eben nicht aus, sobald ein System selbstständig entscheiden soll, ob zwei Behauptungen sich widersprechen oder eine die andere nur präzisiert — dafür braucht es feste, dokumentierte Bedeutungen, nicht nur funktionierenden Code.
Konkret hieß das: Mein GEO-Agent (das Plugin, das automatisch die GEO-Infobox befüllt — Kernthese, Konzepte, erkannte Entitäten) und mein Kontext-Graph kannten zwei getrennte Entitäten-Vokabulare. Der GEO-Agent erkennt „Typ: Name“-Paare wie „Unternehmen: Anthropic“ rein für die Anzeige. Der Kontext-Graph kannte Entitäten nur, wenn sie zufällig in einer extrahierten These auftauchten. Ein Artikel ohne extrahierbare These — aber mit klar erkennbaren Firmen, Produkten oder Personen — hätte diese Entitäten schlicht verloren.
Was jetzt passiert
Die Lösung war pragmatischer, als ich erwartet hatte, und ich lasse sie mit genau diesem Artikel hier zum ersten Mal laufen: Der GEO-Agent schreibt seine erkannten Entitäten jetzt direkt in den Kontext-Graphen, über dieselbe Ähnlichkeits-Prüfung wie die Thesen. Erkennt Claude in diesem Text zum Beispiel Anthropic, Claude selbst, Supabase oder WordPress als Entität, prüft das System zuerst, ob der Name exakt existiert — und erst danach, ob eine ähnlich formulierte Entität schon im Graphen liegt. Neu ist vor allem, dass beide Wege — Thesen-Extraktion und GEO-Agent — jetzt dieselbe Dedup-Funktion nutzen, statt zwei parallele Mini-Logiken zu pflegen, die irgendwann auseinanderlaufen.
Ob das im Alltag wirklich weniger Pflegeaufwand bedeutet, weiß ich noch nicht — das ist eher eine Hoffnung als eine belegte These. Aber die Grundannahme dahinter würde ich schon jetzt unterschreiben: Ein Retrieval-System ist nur so vertrauenswürdig wie sein Umgang mit widerrufenen Behauptungen. Und genau das lässt sich nicht nachträglich reparieren, wenn man es nicht von Anfang an mitdenkt.
🕸️ Wissenskarte dieses Artikels
Knoten sind verschiebbar · Hover für Details · Klick öffnet verlinkte Seite
🧭 Thesen dieses Artikels — und wo sie heute stehen
Ein Retrieval-System, das Artikeltexte als Kontext für KI-Antworten nutzt, ist ohne explizite zeitliche Gültigkeitsmarkierung unzuverlässig, weil es veraltete und aktuelle Behauptungen desselben Autors mit gleicher Autorität behandelt.
gilt · seit 12.09.2026
Automatisierte Statuslogik per Datenbank-Trigger ist der einzige praktikable Weg, veraltete Behauptungen in einem Kontext-Graphen zuverlässig zu markieren, ohne manuellen Synchronisationsaufwand pro Aktualisierung.
gilt · seit 12.09.2026
Eine informelle Tag-Sammlung reicht nicht aus, sobald ein System selbstständig entscheiden soll, ob zwei Behauptungen sich widersprechen oder eine die andere nur präzisiert — dafür sind formal dokumentierte Relationen mit festen Bedeutungen erforderlich.
gilt · seit 12.09.2026
Die Vertrauenswürdigkeit eines Retrieval-Systems hängt unmittelbar davon ab, wie es mit widerrufenen Behauptungen umgeht, und dieser Aspekt lässt sich nicht nachträglich in ein bestehendes System einbauen.
gilt · seit 12.09.2026
Jede These ist ein Knoten im Kontext-Graphen von meiersworld.de: mit Gültigkeit, Belegen und Nachfolger, falls sie revidiert wurde.