EvoOntology: Selbstentwickelnde Ontologie-Schicht für Datenagenten veröffentlicht

Paper und Code auf ArXiv und GitHub veröffentlicht

Ein Team der Renmin University of China hat EvoOntology veröffentlicht: eine selbstentwickelnde Ontologie-Schicht für Datenagenten, die die Lücke zwischen Agent und heterogenen Daten schließen soll. Das Paper von Meiduo Chong, Shaolei Zhang, Ju Fan und Xiaoyong Du ist auf ArXiv erschienen, der zugehörige Code liegt auf GitHub – in Python, unter MIT-Lizenz. Die Autoren beschreiben EvoOntology als eine Schicht, die Tabellen, Dateien und Datenbanken über einen MCP-Server erschließt und sich anhand von Ausführungs-Trajektorien kontinuierlich anpasst. Zum Repository gehören Plugins für Claude Code und Codex sowie Benchmark-Integrationen für BIRD, DDR-10K und InsightBench. Die BIRD-Integration etwa vergleicht eine Baseline-Bedingung, die ausschließlich rohe SQLite-Explorations-Tools nutzt, mit einer Semantik-Bedingung, die den EvoOntology-MCP-Server samt Text-to-SQL-Context-Enrichment- und Ontology-Layer einbindet; die Konfigurationen dafür sind als YAML-Dateien im Repository hinterlegt. Nach Angaben der Autoren handelt es sich um die erste selbstentwickelnde Ontologie-Schicht für Datenagenten; diese Einordnung ist durch unabhängige Literaturrecherche zu prüfen. Das Repository wurde am 15. September 2026 erstellt, der letzte Push datiert auf den 21. September 2026. Zu diesem Zeitpunkt verzeichnet es 258 Sterne, 21 Forks, 2 Issues beziehungsweise Pull Requests und 4 Watcher. Der Code ist als deterministischer Python-Kern organisiert, ergänzt um Client-Plugins, eigenständige Benchmarks und eine Test-Suite. Die MIT-Lizenz erlaubt freie Nutzung, Modifikation und Weitergabe unter den üblichen Bedingungen. Die Autoren betonen, dass die Ontologie-Schicht als trainierbarer Agenten-Zustand konzipiert ist, nicht als Modellgewichte – ein zentraler Unterschied zu klassischen Ansätzen, die Semantik statisch in Prompts injizieren.

Drei Layer und ein Selbstverbesserungs-Loop: Die Architektur

EvoOntology kapselt die Ontologie als MCP-Server, der aus drei miteinander verbundenen Layern besteht: einem Schema-Layer, einem Content-Layer und einem Tool-Layer. Der Schema-Layer definiert die strukturellen Regeln und Repräsentationsvorgaben, der Content-Layer hält die inhaltlichen semantischen Objekte – Konzepte, Mappings, Constraints und deren Evidenz – und der Tool-Layer stellt den Laufzeitzugriff bereit. Datenagenten können die Ontologie damit zur Laufzeit aktiv abfragen, statt sie als statisches Prompt-Dokument injiziert zu bekommen. Der Aufbau erfolgt nicht manuell: Ein Builder-Agent konstruiert die Ontologie autonom, indem er Kandidaten-Konzepte aus Workloads extrahiert, sie an den Rohdaten validiert und eine erste Version veröffentlicht. Danach greift ein Self-Evolution-Loop, der sich in fünf Schritte gliedert: Build, Use, Evolve, Evaluate und Publish or reject. Zunächst werden aus dem Workload Kandidaten-Konzepte extrahiert und in einer initialen Ontologie-Version veröffentlicht. Anschließend nutzt der Datenagent die Ontologie und zeichnet dabei Werkzeuginteraktionen und Aufgabenergebnisse auf. Im Evolve-Schritt diagnostiziert der Loop wiederkehrende Fehlverhalten aus den Ausführungs-Trajektorien, attribuiert die Ursache auf einen der drei Layer und schlägt einen typisierten, evidenzgestützten Edit vor. Entscheidend ist die Annahme-Hürde im Evaluate-Schritt: Ein Kandidat wird nur dann veröffentlicht, wenn er eine Backbone-bedingte Paar-Evaluation besteht – das heißt, Parent und Candidate werden unter identischen Bedingungen mit demselben LLM-Backbone verglichen. Nur wenn der Kandidat gewinnt, wird er zur neuen Ontologie-Version; andernfalls bleibt der Parent erhalten und das Ergebnis fließt in die nächste Runde ein. Die Autoren beschreiben die Ontologie-Schicht damit als trainierbaren Agenten-Zustand, nicht als Modellgewichte. Dieser Ansatz soll semantische Unsicherheit reduzieren, wiederholte Datenexploration vermeiden und die Wartungskosten senken, da Updates überprüfbar, vergleichbar und rückrollbar sind.

Benchmarks zeigen Überlegenheit – Effizienzgewinne in der Analyse

Die experimentelle Evaluation umfasst nach Angaben des Papers drei etablierte Data-Agent-Benchmarks: BIRD für Text-to-SQL über relationale Datenbanken, DDR-10K und InsightBench. Der Abstract spricht von Experimenten mit vier LLM-Backbones; die Autoren berichten, EvoOntology übertreffe starke Baselines und bestehende Semantic-Layer-Ansätze konsistent. Die BIRD-Integration vergleicht zwei Bedingungen: eine Baseline mit rohen SQLite-Explorations-Tools und eine Semantik-Bedingung, die den EvoOntology-MCP-Server samt Text-to-SQL-Context-Enrichment- und Ontology-Layer einbindet. Die Konfigurationen dafür sind als YAML-Dateien im Repository hinterlegt; sie definieren Experimentbedingungen, Agenten-Eigenschaften wie Modell, Temperatur und maximale Turns sowie die Anbindung der MCP-Server. Eine Kurzanalyse des Papers („The paper in 90 seconds“) ergänzt Effizienzkennzahlen: Demnach sanken die durchschnittlichen Turns pro Aufgabe von 14,6 auf 8,4, die Gesamt-Tokens pro Aufgabe von 52,6K auf 42,0K. Die Kurzanalyse weist zugleich darauf hin, dass die Haupttabellen sechs Backbones umfassen, während das Vier-Backbone-Subset separat zu lesen ist. Diese Zahlen sind nicht austauschbar, weil die Haupttabellen eine breitere Backbone-Basis abdecken und die Ergebnisse je nach Backbone unterschiedlich ausfallen können; das Vier-Backbone-Subset ist eine Teilmenge, die isoliert betrachtet werden muss, um Verzerrungen zu vermeiden. Die stärkste Evidenz liegt laut dieser Analyse in den Ablationsstudien: Sie isolieren den Beitrag des Evaluations-Gates, der Attribution, der Diagnose, der editierbaren Layer und der Content-Objekt-Familien. Die Ergebnisse sind bislang nicht unabhängig repliziert; die Überlegenheitsaussage stammt aus dem Paper selbst.

Installation über GitHub Marketplace und /evo-build

Die Installation erfolgt über den GitHub Marketplace. Für Claude Code wird das Plugin mit `claude plugin marketplace add MeiduoChong/EvoOntology` hinzugefügt, anschließend mit `claude plugin install evoontology@evoontology` installiert. Nach dem Start einer neuen Session wird der Build-Prozess mit `/evo-build` angestoßen. Für Codex existiert ein eigenes Plugin unter `plugins/evoontology-codex`. Die Plugins bauen und evolvieren die Ontologie-Schicht über den Daten. Das Repository wurde am 15. September 2026 erstellt, der letzte Push datiert auf den 21. September 2026. Zu diesem Zeitpunkt verzeichnet es 258 Sterne, 21 Forks, 2 Issues beziehungsweise Pull Requests und 4 Watcher. Die Sprache ist Python, die Lizenz MIT. Die Installation erfordert kein Klonen des Repos, keine virtuelle Umgebung und kein separates pip install – die Plugins werden direkt über den Marketplace bezogen. Nach der Installation kann der Nutzer mit `/evo-build` in einer neuen Session den Build-Prozess starten; die Ontologie wird dann über die MCP-Tools `browse_semantics` und `resolve_semantics` für die Datenanalyse angebunden.

Widersprüche und offene Fragen: Spielentwicklung oder Datenagenten?

Die Einordnung von EvoOntology ist nicht frei von Widersprüchen. Eine Sichtung ordnet das Projekt dem Spielentwicklungs- und Lebenszyklus zu und spricht von Datenagenten im gesamten Spielentwicklungs- und Lebenszyklus. Diese Zuordnung stützt sich auf ein anderes Paper, das Foundation Models im Game-Lifecycle behandelt und EvoOntology nicht erwähnt. Die Primärquellen – ArXiv-Abstract und GitHub-README – beschreiben EvoOntology dagegen ausschließlich als Ontologie-Schicht für Datenagenten über heterogene Daten wie Tabellen, Dateien und Datenbanken. Ein Spielbezug ist dort nicht belegt. Die Diskrepanz beruht offenbar auf einer Vermischung der beiden Themen: Das Game-Lifecycle-Paper liefert den Kontext für Spielentwicklung, während EvoOntology sich auf Datenagenten konzentriert. Ein zweiter offener Punkt betrifft die Anzahl der LLM-Backbones: Der Abstract nennt vier Backbones, die Kurzanalyse spricht von Sechs-Backbone-Haupttabellen und warnt ausdrücklich davor, das Vier-Backbone-Analyse-Subset mit den Haupttabellen zu vermischen. Unklar bleibt, welche Zahl die Gesamtzahl der getesteten Backbones korrekt beschreibt – der Abstract erwähnt nur vier, die Haupttabellen sechs, und die Kurzanalyse liefert keine Auflösung. Auch die Herstellerangabe, EvoOntology sei die erste selbstentwickelnde Ontologie-Schicht für Datenagenten, ist bislang nicht unabhängig geprüft. Gleiches gilt für die Behauptung, die Schicht überbrücke die Agent-Daten-Lücke effektiv – dies wäre durch unabhängige Replikation der Benchmarks zu validieren. Die Architektur selbst ist im Repository einsehbar; die Ergebnis-Aussagen stammen aus dem Paper und sind als Autorenangaben zu lesen. Der Kernartikel „Selbstentwickelnde Ontologie-Schicht für Datenagenten vorgestellt“ ordnet das Projekt entsprechend ein.