Utopia: bitemporaler Wissensgraph mit Ontologie, ein Rust-Binary und Postgres

Welches Problem Utopia löst und für wen es gebaut ist

Ein Vektorspeicher beantwortet die Frage, was dem System heute als ähnlich gilt. Ein klassischer Knowledge Graph beantwortet, was heute als Fakt gilt. Beide verlieren die Zwischenstände. Utopia setzt genau dort an: Das README beschreibt als eines der Gründungsziele, den gesamten Verlauf sich ändernder Auffassungen festzuhalten, und übersetzt das in einen bitemporalen Wissensgraphen. Ein Fakt trägt demnach zwei Zeitachsen, nämlich wann er in der Welt galt und wann das System begann, ihn zu glauben. Eine Korrektur überschreibt nicht, sondern schließt die alte Version und verknüpft die neue damit.

Die Zielgruppe lässt sich aus dem Funktionsumfang ableiten. Wer eine Wissensbasis für Agenten braucht, die auf nachvollziehbare Herkunft angewiesen ist, findet hier Extraktion, Suche, Chat und Graph in einer Anwendung. Wer aus regulatorischen Gründen einen Prüfpfad braucht und die Daten nicht an einen fremden Dienst geben darf, findet einen Betrieb, der laut README offline möglich ist, sofern der LLM-Endpunkt lokal läuft. Und wer Ontologie nicht als Nachgedanken behandeln will, bekommt sie im Kern: Konflikterkennung, Reasoning und Entscheidungen laufen gegen dieses Vokabular. Das ist kein Werkzeug für jemanden, der schnell eine Vektorsuche in eine bestehende Anwendung einbauen möchte. Es ist eine komplette Anwendung mit eigenem Datenmodell.

Ein Binary, eine Postgres, und die Aufgabenverteilung dahinter

Der Betrieb ist bewusst klein gehalten. Nach Angaben des README laufen Volltextsuche, Vektoren und Job-Queue in derselben Postgres-Instanz: Tantivy ist in das Binary eingebettet, Vektoren liegen in pgvector, und die Warteschlange ist eine Tabelle statt eines separaten Brokers. Das ist eine Architekturentscheidung mit Konsequenzen. Man spart einen Dienst und bekommt dafür einen gemeinsamen Ausfallpunkt sowie einen gemeinsamen Skalierungspfad. Wer Postgres bereits betreibt, kann dasselbe Backup, dasselbe Monitoring und dieselbe Rechteverwaltung verwenden.

Die Suche kombiniert beide Verfahren über Reciprocal Rank Fusion, also eine Fusion der Ranglisten statt einer gewichteten Addition von Punktzahlen. Antworten werden mit Inline-Zitaten gestreamt, die den zugrunde liegenden Abschnitt öffnen. Für den Modellzugriff nennt das README OpenAI-kompatible Endpunkte, darunter DeepSeek, Qwen, GLM, Ollama und vLLM. Das ist der Hebel für den Offline-Betrieb: Ohne kompatiblen Endpunkt gibt es keine Antwortgenerierung, aber die Such- und Graphfunktionen bleiben davon getrennt. Der Agent selbst hat lesenden Zugriff auf Dokumente, kann den Graphen durchlaufen, etwa die Fakten einer Entität zu einem Stichtag oder Änderungen in einem Zeitraum, und eine eingebundene Datenbank abfragen. Dieselben Werkzeuge werden zusätzlich über MCP bereitgestellt.

Ontologie als Startbedingung, nicht als Nachtrag

Eine neue Wissensbasis hat kein eigenes Vokabular. Utopia löst das über Packs, die bei der Erstellung ausgewählt werden. Fünf davon liegen laut README im Binary: schema.org, W3C Org, PROV-O, FOAF und IOF Core. Begriffe außerhalb dieser Packs werden beim Auftreten gezählt, und bestätigt man die häufigen, wandern sie in die Ontologie. Dieser Zählmechanismus ist der eigentliche Einstieg in die Domänenanpassung, und er erklärt, warum die erste Inbetriebnahme nicht mit einer vollständigen Ontologie beginnt, sondern mit einer Auswahl und einem Beobachtungszeitraum.

Die Extraktion erzeugt aus Dokumenten Entitäten und Fakten entlang dieser Ontologie. Jeder Fakt trägt Gültigkeit und Herkunft. Die Auflösung von Duplikaten läuft in drei Stufen: exakter Name oder Alias, Ähnlichkeit der Einbettung, dann das Urteil eines Modells bei den zweifelhaften Paaren. Jede Zusammenführung ist umkehrbar, unsichere Fälle landen in einer Prüfliste, zusammen mit Extraktionen mit niedriger Konfidenz und Verstößen gegen Kardinalitäten. Das ist der Teil, der in der Praxis Aufwand erzeugt: Die Prüfliste ist kein Nebeneffekt, sondern ein Arbeitsvorrat, den jemand abarbeiten muss.

Ableitung per Forward Chaining und warum sie standardmäßig aus ist

Ontologie-Axiome werden zu Regeln kompiliert. Transitivität, Symmetrie, inverse Beziehungen und die Hierarchie von Relationen leiten per Forward Chaining neue Fakten ab. Abgeleitete Fakten werden im Graphen als solche markiert, tragen Gültigkeit und Konfidenz wie jeder andere Fakt und zeigen, woraus sie abgeleitet wurden. Widerspricht ein abgeleiteter Fakt einem behaupteten, gilt der behauptete.

Bemerkenswert ist die Voreinstellung: Die Ableitung ist standardmäßig deaktiviert, mit der Begründung im README, dass ein falsches Axiom falsche Fakten ableitet. Das ist eine ehrliche Einschätzung der Fehlerfortpflanzung. In einem Graphen, in dem Transitivität über eine unsauber gepflegte Relation läuft, kann eine einzelne Fehlannotation eine große Zahl abgeleiteter Fakten erzeugen, die alle plausibel aussehen, weil sie eine Herkunftskette besitzen. Die Markierung als abgeleitet macht sie prüfbar, aber sie macht sie nicht richtig. Wer die Ableitung einschaltet, sollte zuerst die Axiome prüfen, nicht die Ergebnisse.

Inbetriebnahme: Container, Datenquellen, Modell-Endpunkt

Das Repository nennt ein Container-Image unter ghcr.io/deeplethe/utopia sowie eine Schnittstelle über die API. Für den Datenimport sind die Formate im README aufgezählt: PDF, DOCX, PPTX, XLSX, XLS, ODS, CSV, TSV, Markdown, HTML und Klartext, wobei ältere Zeichenkodierungen beim Einlesen erkannt werden. Für wiederkehrende Quellen nennt das README Zeitpläne für Webseiten, RSS, GitHub, Jira, Notion, WebDAV und S3-kompatible Buckets. Alles andere kommt über die API.

Für den Modellzugriff ist ein OpenAI-kompatibler Endpunkt zu konfigurieren. Konkrete Schlüsselnamen für die Konfigurationsdatei gibt das vorliegende Material nicht her; hier wäre die Dokumentation im Repository oder auf utopia.bi zu prüfen, bevor man einen Deployment-Plan darauf aufbaut. Der Standardbranch ist dev, die letzten veröffentlichten Stände sind v0.1.0-rc5 vom 5. September 2026, davor v0.1.0-rc4 und v0.1.0-rc3 im Abstand von Tagen. Diese Taktung zeigt einen schnellen Reifeprozess, aber sie zeigt auch, dass es noch keine stabile Version gibt. Wer jetzt einsteigt, betreibt einen Release Candidate.

Grenzen: Prüfaufwand, Ontologie-Lücken und der Release-Status

Die erste Einschränkung ist der Prüfaufwand. Zwei der drei Auflösungsstufen arbeiten mit Ähnlichkeit und einem Modellurteil, beide sind fehleranfällig. Das System fängt das nicht durch Automatik ab, sondern durch eine Warteschlange. In einem Bestand mit vielen Namensvarianten wächst diese Warteschlange schneller, als eine kleine Gruppe sie abarbeiten kann. Die Umkehrbarkeit jeder Zusammenführung ist dabei der Ausgleich, nicht die Lösung.

Die zweite Einschränkung ist die Ontologie-Abdeckung. Fünf Packs sind im Binary enthalten, und das README verweist für Branchenbedarf auf ein Issue-Formular. Für Domänen wie Medizin, Bauwesen oder spezialisierte Fertigung ist damit zu rechnen, dass ein erheblicher Teil der Begriffe zunächst nur gezählt und nicht eingeordnet wird. Bis diese bestätigt sind, arbeitet die Extraktion mit einem dünnen Vokabular, und die Qualität der abgeleiteten Fakten hängt direkt daran.

Die dritte Einschränkung ist der Stand. Drei Release Candidates innerhalb weniger Tage, ein dev-Branch als Standard und keine stabile Version bedeuten, dass sich Datenmodell und Schnittstellen noch bewegen können. Für einen Prototyp mit eigenem Datenbestand ist das handhabbar. Für ein System, das mehrere Jahre ohne Migrationen laufen soll, ist es ein Risiko, das man vorher benennen sollte.

Wo der Unterschied zu Vektorspeichern und Graphdatenbanken liegt

Der naheliegende Vergleich ist eine Kombination aus Vektordatenbank und Graphdatenbank, etwa pgvector zusammen mit einem Graph-Framework. Der Unterschied liegt nicht in den Bausteinen, sondern in dem, was als Erstklassig behandelt wird. In der Kombination ist Zeit meist ein Feld, das man selbst pflegt, und Ontologie eine Konvention, die im Anwendungscode lebt. In Utopia sind beide Teil des Kerns: Fakten werden versioniert statt überschrieben, und Axiome werden zu Regeln kompiliert, die der Graph selbst auswertet.

Der zweite Unterschied ist die Abgeschlossenheit. Eine selbstgebaute Kombination liefert Bausteine, Utopia liefert eine Anwendung mit Konsole, Graphbrowser und Ontologie-Werkbank. Das spart Integrationsarbeit, kostet aber Anpassungsfreiheit: Wer eine eigene Oberfläche oder ein eigenes Datenmodell braucht, arbeitet gegen die Struktur des Systems statt sie zu nutzen. Umgekehrt gilt: Wer nur Ähnlichkeitssuche über Dokumente braucht, fährt mit einem reinen Vektorspeicher deutlich einfacher, weil Extraktion, Ontologiepflege und Prüfliste dann vollständig entfallen.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

Der Wartungsaufwand verteilt sich auf drei Posten. Erstens die Prüfliste: Duplikate, unsichere Extraktionen und Kardinalitätskonflikte brauchen eine Zuständigkeit. Zweitens die Ontologie: Begriffe, die häufig auftreten, müssen bestätigt werden, sonst bleibt die Extraktion flach. Drittens der Betrieb selbst, der sich auf ein Binary und eine Postgres beschränkt, was Upgrades und Backups vereinfacht, aber auch bedeutet, dass die Datenbank ein einzelner Punkt ist, an dem Suche, Vektoren und Job-Queue gleichzeitig hängen.

Lizenziert ist das Projekt unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Modifikation und enthält eine ausdrückliche Patentgewährung sowie die üblichen Pflichten zur Beibehaltung von Copyright- und Lizenzhinweisen. Wer das Binary unverändert intern betreibt, hat damit wenig Berührungspunkte. Wer es verändert und weitergibt, muss die Hinweise mitführen und die Änderungen kennzeichnen. Das ist eine Einordnung, keine Rechtsberatung; für den eigenen Fall gehört die LICENSE-Datei ins Onboarding.

Zu klären ist vorab, ob die eigene Domäne von den fünf Ontologie-Packs abgedeckt wird, ob der Betrieb ohne externen LLM-Endpunkt für die geplanten Zwecke ausreicht, und wie ein Upgrade von v0.1.0-rc5 auf eine spätere Version aussieht. Solange das Projekt keine stabile Version veröffentlicht hat, ist die Versionsnummer im eigenen Deployment der belastbarste Indikator dafür, wann ein erneuter Blick auf das Repository sinnvoll ist.

Redaktionelles Fazit

Utopia passt zu Teams, die einen selbst gehosteten, luftgetrennt betreibbaren Wissensspeicher mit nachvollziehbarer Zeitachse brauchen und bereit sind, einen Release Candidate zu betreiben. Wer stabile Schnittstellen für den Produktivbetrieb oder eine breite Ontologie-Abdeckung außerhalb der fünf mitgelieferten Packs erwartet, sollte warten. Vor dem Einsatz zu prüfen: ob die eigene Domäne von schema.org, W3C Org, PROV-O, FOAF oder IOF Core abgedeckt wird, ob der Betrieb ohne externen LLM-Endpunkt für die Zwecke ausreicht, und wie sich ein Upgrade von v0.1.0-rc5 auf eine spätere Version verhält, da das Projekt noch keine stabile Version veröffentlicht hat.

Offizielle Quellen

1. deeplethe/utopia on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases