kg-gen: Wissensgraphen aus beliebigem Text, mit einem Modell deiner Wahl

Welches Problem kg-gen adressiert

Unstrukturierter Text enthält Beziehungen, die man für maschinelle Weiterverarbeitung erst sichtbar machen muss. Das README nennt vier Anwendungsfälle: Graphen als Grundlage für RAG, synthetische Graph-Daten für Training und Tests, die Strukturierung beliebigen Textes und die Analyse von Beziehungen zwischen Konzepten im Ausgangstext. Der Adressat ist damit kein Datenbankteam, das ein bestehendes Schema pflegt, sondern eher eine Entwicklerin oder ein Forscher, der aus einem Korpus oder einem Chatprotokoll ein Netz aus Entitäten und Relationen ziehen will, ohne dafür eine eigene Extraktionspipeline zu schreiben. Das Projekt ist als Python-Paket auf PyPI veröffentlicht, der zugehörige Artikel ist auf arXiv hinterlegt und trägt den Titel KGGen: Extracting Knowledge Graphs from Plain Text with Language Models. Die Eingabe kann ein einzelner String oder eine Liste von Message-Objekten mit role und content sein, was den Fall abdeckt, dass die Quelle ein Gesprächsverlauf ist und nicht ein zusammenhängender Fließtext.

Der Mechanismus: Modellaufruf, Chunking, Clustering

kg-gen betreibt keine eigene Extraktionslogik im engeren Sinn. Die Arbeit wird an ein Sprachmodell delegiert, und die strukturierte Ausgabe wird über DSPy erzeugt. Die Modellanbindung läuft über LiteLLM, das Modell wird als String im Format {model_provider}/{model_name} übergeben. Das README zeigt openai/gpt-5, gemini/gemini-2.5-flash und ollama_chat/deepseek-r1:14b als Beispiele. Ein base_url lässt sich setzen, wofür im Repository ein Testskript test_custom_api_base.py existiert. Die Rückgabe von generate ist ein Objekt mit den Feldern entities, edges und relations, wobei relations Tripel aus Subjekt, Kante und Objekt sind. Für längere Texte gibt es zwei Parameter: chunk_size teilt den Text auf, cluster=True gruppiert ähnliche Entitäten und Kanten. Aus dem Beispiel im README geht hervor, dass dabei zusätzlich entity_clusters und edge_clusters entstehen, etwa die Zusammenfassung von neural networks, neural nets und NN unter einem Schlüssel. Für mehrere Quellen existiert aggregate, das Graphen zusammenführt, und cluster, das auf einen bereits aggregierten Graphen angewendet werden kann. Diese Trennung ist praktisch relevant: Ob man erst zusammenführt und dann clustert oder umgekehrt, verändert das Ergebnis, und das README zeigt lediglich die Reihenfolge aggregate gefolgt von cluster.

Installation und erste Schritte

Der schnellste Weg ist pip install kg-gen, gefolgt von from kg_gen import KGGen. Der Konstruktor nimmt model, temperature und optional api_key entgegen; laut README ist der Schlüssel nicht nötig, wenn er in der Umgebung gesetzt ist oder ein lokales Modell verwendet wird. Der Aufruf kg.generate(input_data=..., context=...) akzeptiert einen String, eine Message-Liste oder, mit chunk_size, einen längeren Text. Für die Entwicklung aus dem Repository heraus ist pip install -e '.[dev]' vorgesehen, und python tests/test_basic.py aus dem Wurzelverzeichnis dient als Funktionstest; das Skript erzeugt zusätzlich eine Visualisierung in tests/test_basic.html. Wer die Ausgabe ansehen will, nutzt KGGen.visualize(graph, output_path, open_in_browser=True). Für agentenbasierte Nutzung gibt es einen MCP-Server, der mit kggen mcp gestartet wird, nachdem das Paket installiert wurde. Diese Befehle stammen alle aus dem README; eigene Messungen zur Laufzeit oder zum Speicherbedarf lassen sich daraus nicht ableiten.

Wo das Verfahren an seine Grenzen stößt

Die Qualität des Graphen ist die Qualität des Modells. kg-gen normalisiert nicht selbst, sondern bittet ein Modell um strukturierte Ausgabe. Ein kleineres lokales Modell wie das im README erwähnte ollama_chat/deepseek-r1:14b wird bei mehrdeutigen Beziehungen andere Kantenbezeichnungen liefern als ein großes API-Modell, und das Clustering kann diese Unterschiede nur teilweise auffangen. Der temperature-Wert steht standardmäßig auf 0.0, was für Reproduzierbarkeit spricht, aber nicht garantiert, dass zwei Läufe identische Tripel erzeugen, da die Modellinferenz selbst bei gleicher Temperatur nicht deterministisch sein muss. Ein weiterer Punkt: Die Ausgabe ist ein Python-Objekt mit Mengen und Tupeln, kein RDF, kein Property Graph mit Schema. Wer die Daten in Neo4j, SPARQL-Endpunkten oder einem etablierten Triple Store weiterverarbeiten will, muss die Konvertierung selbst schreiben. Und wer eine vollständig offline laufende, auditierbare Extraktion ohne externen Modellaufruf braucht, findet hier keinen Ersatz für regelbasierte oder statistische Verfahren, weil der Kern des Werkzeugs der Modellaufruf ist.

Abgrenzung zu etablierten NLP-Werkzeugen

Klassische Pipelines wie spaCy mit einem Relation-Extraction-Modul oder Stanford OpenIE arbeiten mit trainierten, festen Schemata und liefern reproduzierbare Ergebnisse ohne Netzwerkzugriff. Der Unterschied liegt im Ansatz: Dort wird ein Modell auf einen festen Satz von Entitäts- und Relationsklassen trainiert, hier wird ein generatives Modell gebeten, freie Kantenbezeichnungen zu erzeugen. Das ist flexibler bei Domänen, für die kein Trainingskorpus existiert, und es ist der Grund, warum das README Beispiele wie is type of, is subset of und requires zeigt, die kein vordefiniertes Schema sind. Der Preis ist die Abhängigkeit von einem Modellprovider und die schwierigere Reproduzierbarkeit. Für Anwendungen, in denen jede Extraktion nachvollziehbar und versioniert sein muss, ist der generative Ansatz die falsche Wahl.

Wartung, Releases und Lizenz

Der letzte Push stammt vom 24. März 2026, das Repository ist nicht archiviert. Die jüngsten Releases tragen Namen wie MINE-evaluations-expanded, MINE-deduplication-scikitlearn-vs-faiss und WikiQA-evaluations, was darauf hindeutet, dass die Veröffentlichungen eng an die Benchmark-Arbeit im experiments/MINE-Verzeichnis gekoppelt sind und nicht an das Paket selbst. Wer kg-gen produktiv einsetzt, sollte daher prüfen, ob Versionsnummern auf PyPI mit den getaggten Release-Namen korrelieren, denn aus der Materialbasis geht das nicht hervor. Zur Lizenz enthält das Material keine Angabe; das Feld ist schlicht unbekannt. Ohne Lizenzangabe lässt sich keine Aussage über Weitergabe oder kommerzielle Nutzung treffen, und das ist ein realer Blocker für jede Adoption in einem Unternehmen mit Lizenzprüfung. Das sollte man vor jedem Einsatz im Repository selbst klären, nicht aus zweiter Hand.

Für wen sich der Einsatz lohnt

Der stärkste Fall ist ein Prototyp oder eine Forschungsarbeit, in der aus einem Textkorpus oder einem Chatverlauf schnell ein Graph entstehen soll, und in der bereits ein Modellzugang existiert. Die Kombination aus chunk_size und cluster macht das Werkzeug für Texte tauglich, die nicht in ein Kontextfenster passen, und aggregate erlaubt es, Ergebnisse aus mehreren Quellen zu einem Graphen zu verbinden. Der schwächste Fall ist eine produktive Pipeline, in der jeder Tripel auditierbar sein muss oder in der kein externer Modellaufruf erlaubt ist. Zwischen diesen beiden Polen liegt die Frage, wie stark die Ausgabe schwankt, und genau das lässt sich nur mit dem eigenen Modell und dem eigenen Text prüfen, nicht aus dem README ableiten. Ein erster Test mit python tests/test_basic.py gegen das Zielmodell zeigt, ob die Struktur der Ausgabe den Erwartungen entspricht.

Redaktionelles Fazit

Wer aus unstrukturiertem Text schnell ein Graph-Objekt für eine RAG-Pipeline oder synthetische Trainingsdaten braucht und bereits einen Modellzugang hat, findet in kg-gen einen schlanken Einstieg über pip install kg-gen. Wer eine deterministische, auditierbare Extraktion ohne LLM-Abhängigkeit oder einen etablierten Graph-Stack mit SPARQL und Reasoning braucht, ist hier falsch. Vor dem Produktiveinsatz sollte man die Lizenzangabe im Repository prüfen, denn die Materialbasis nennt keine, und mit python tests/test_basic.py gegen das eigene Modell verifizieren, ob die Ausgabe die erwartete Struktur aus entities, edges und relations liefert.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. Releases
5. stair-lab/kg-gen on GitHub