GraphGen: SFT-Daten aus Wissensgraphen statt aus Prompt-Vorlagen

Welche Lücke GraphGen schließen soll

Instruction-Tuning lebt von Beispielen, die das Modell noch nicht kann. Wer SFT-Daten aus einem Handbuch oder einer Papersammlung zieht, erzeugt meist Variationen dessen, was das Basismodell ohnehin beherrscht. GraphGen setzt genau dort an: Aus dem Quelltext wird zuerst ein feiner Wissensgraph gebaut, danach werden die Wissenslücken des Modells mit dem Expected Calibration Error (ECE) bestimmt, und die Generierung konzentriert sich auf QA-Paare zu hochwertigem Long-Tail-Wissen. Die Zielgruppe sind weniger Einsteiger als Teams, die eine kuratierte Textsammlung besitzen und daraus Trainingsdaten mit nachvollziehbarer Herkunft brauchen. Das Repository nennt als Anwendungsfelder SFT- und Pretrain-Daten, VQA und Benchmark-Synthese für den Bildungsbereich. Die Themenliste verweist auf ai4science und Knowledge Graphs, was zur Bioinformatik-Anbindung passt: NCBI und RNAcentral sind als Suchquellen dokumentiert.

Vom Text zum Graphen und zurück zu Fragen

Der Ablauf lässt sich in drei Stufen lesen. Erstens die Graphkonstruktion: Entitäten und Relationen werden aus dem Quelltext extrahiert und als Knoten und Kanten abgelegt. Zweitens die Lückenanalyse: Der ECE vergleicht die Modellkonfidenz mit der tatsächlichen Trefferquote, und Wissensbereiche mit hoher Kalibrierungsabweichung gelten als lohnende Ziele. Drittens die Generierung, die zwei Techniken kombiniert. Multi-hop Neighborhood Sampling folgt mehreren Kanten vom Startknoten und erfasst dadurch relationale Zusammenhänge, die eine einzelne Textpassage nicht hergibt. Style-controlled Generation variiert die Form der erzeugten Fragen. Ein separater Zweig nutzt Community Detection nach dem Leiden-Algorithmus, um Chain-of-Thought-Daten zu synthetisieren. Seit Dezember 2025 ist die Pipeline auf Ray umgestellt, was die Verteilung der Arbeitsschritte und die Ressourcenverwaltung betrifft. Die Ausgabe geht an LLaMA-Factory oder xtuner, die das Finetuning übernehmen. Der wichtigste Punkt an dieser Architektur: Die Qualität der Fragen hängt an der Qualität des Graphen, und der Graph hängt an der Extraktionsgüte des eingesetzten LLM. Ein falsch extrahiertes Relationspaar pflanzt sich bis in die Trainingsdaten fort.

Installation und der erste Lauf

Das Paket liegt auf PyPI unter dem Namen graphg, nicht graphgen. Ein Installationsbefehl lässt sich aus dem Repository ableiten, das README selbst zeigt an dieser Stelle keinen vollständigen Ablauf. Für VQA-Daten nennt die Änderungsliste ein konkretes Skript: bash scripts/generate/generate_vqa.sh. Wer PDFs als Quelle nutzt, braucht MinerU, das seit Oktober 2025 als Eingabeformat angebunden ist. Die Konfiguration verteilt sich auf mehrere Bereiche, die im Repository unter graphgen/models/llm/ liegen. Für die Anbindung externer Modelle existieren Ollama_client und http_client; lokal stehen HuggingFace Transformers, SGLang und seit Dezember 2025 vLLM als Backends bereit. Als Speicher nennt die Änderungsliste RocksDB für Key-Value-Daten und KuzuDB als Graphdatenbank, beide im Dezember 2025 ergänzt. Wer diese Backends einsetzt, muss sie zusätzlich installieren. Ein Detail, das in der Dokumentation dünn bleibt: Das README beschreibt die Konfigurationsschlüssel nicht im Fließtext, sondern verweist auf einen auskommentierten Abschnitt im Inhaltsverzeichnis. Wer die Parameter für ECE-Schwellen oder Sampling-Tiefe sucht, landet in der Cookbook-Dokumentation oder im Code.

Wo der Ansatz an seine Grenzen stößt

Der ECE als Steuerungsgröße setzt voraus, dass das Modell seine Unsicherheit überhaupt sinnvoll ausdrückt. Ein Endpunkt, der nur eine Antwort ohne Logprobs liefert, macht die Kalibrierungsmessung unmöglich oder zwingt zu Selbstkonsistenz über mehrere Abfragen. Das kostet pro Kandidat mehrere Aufrufe und verschiebt den Aufwand deutlich nach oben. Die zweite Einschränkung liegt in der Domäne. Der Graph muss die Zusammenhänge tragen, die später abgefragt werden. Bei narrativen Texten, Stimmungsbeschreibungen oder stark implizitem Wissen liefert die Extraktion flache oder falsche Kanten, und Multi-hop-Sampling verstärkt den Fehler, weil es mehrere unzuverlässige Kanten zu einer Frage verkettet. Für solche Quellen ist GraphGen das falsche Werkzeug. Drittens die Reproduzierbarkeit: Die Generierung hängt an einem externen Modell, dessen Version und Sampling-Parameter den Output verändern. Ein Lauf von heute lässt sich mit einem aktualisierten Endpunkt nicht identisch wiederholen. Wer Datenversionierung braucht, muss die Rohantworten mitspeichern. Viertens ist die Bewertung des Graphen selbst ein eigener Arbeitsschritt: Seit Dezember 2025 gibt es Metriken für Genauigkeit von Entitäten und Relationen, Konsistenzerkennung sowie strukturelle Robustheit. Ohne diese Prüfung bleibt offen, ob die Fragen auf einem tragfähigen Graphen beruhen.

Was die Pretrain-Zahlen sagen und was nicht

Das README dokumentiert einen Vergleich auf SlimPajama-6B mit Qwen3-0.6B, trainiert von Grund auf. Zwei Epochen auf den Rohdaten erreichen im Durchschnitt 24.24 Punkte über sechs Benchmarks. Eine Epoche auf den Daten mit Executive-Summary-Rephrase kommt auf 26.43 bei ARC-E, 22.70 bei ARC-C, 24.75 bei HellaSwag und 1.36 bei GSM8K, jeweils gegenüber 25.55, 21.08, 24.48 und 0.08 in der Baseline. Der Vergleich ist nicht symmetrisch: eine Epoche gegen zwei, und die Rephrase-Pipeline erzeugt zusätzliche Varianten desselben Korpus. Die Zahlen zeigen daher, dass ein einzelner Durchlauf über reformulierte Daten mehr bringt als zwei Durchläufe über redundante Wiederholung. Sie zeigen nicht, wie GraphGen gegen andere Augmentierungsverfahren abschneidet, und die Tabelle ist im gelieferten Material nach TruthfulQA-MC2 abgeschnitten, sodass die durchschnittliche Punktzahl der zweiten Zeile nicht belegt ist. Wer die Methode für ein eigenes Pretraining erwägt, sollte den Effekt auf seinem Korpus messen, statt die genannten Werte zu übertragen.

Der Unterschied zu Destillation aus einem stärkeren Modell

Die naheliegende Alternative ist Destillation: Ein großes Modell erzeugt Antworten auf Prompts, die aus dem eigenen Korpus stammen, und das kleinere Modell lernt daraus. Der Unterschied liegt in der Auswahl. Destillation deckt ab, was der Prompt-Sampler zufällig trifft, und die Verteilung der Fragen folgt dem Promptdesign. GraphGen wählt die Ziele über die gemessene Kalibrierungsabweichung und über die Graphstruktur aus, und die Fragen entstehen aus Pfaden durch den Graphen statt aus einzelnen Textabschnitten. Das ist der eigentliche Unterschied in der Methode: nicht wer die Antwort formuliert, sondern welche Wissensbereiche überhaupt abgefragt werden. Der Preis dafür ist ein vorgeschalteter Extraktionsschritt, dessen Fehler sich in die Daten einprägen. Ein zweiter Unterschied betrifft die Herkunft: Bei GraphGen lässt sich jede Frage auf Knoten und Kanten im Graphen zurückführen, was Audits erleichtert. Bei reiner Prompt-Destillation ist diese Kette nicht vorhanden, es sei denn, man baut sie nachträglich ein.

Wartung, Releases und Lizenz

Die Änderungsliste zeigt zwischen April und Dezember 2025 eine hohe Taktung: neue Suchquellen wie Google, Bing, Wikipedia und UniProt, dann NCBI und RNAcentral, dazu PDF-Eingabe, VQA, Leiden-Community-Erkennung, die Ray-Umstellung und die Backends RocksDB, KuzuDB und vLLM. Für Betreiber bedeutet das, dass die Konfigurationsoberfläche sich zwischen Releases bewegen kann. Zwei Releases sind im Material verzeichnet: 20250422 und v0.1.0.post20250930. Die Versionsnummer mit post-Suffix deutet auf Nachbesserungen innerhalb derselben Funktionsversion hin. Wer GraphGen produktiv einsetzt, sollte die Version pinnen und die eigene Konfiguration bei jedem Sprung gegen die Cookbook-Dokumentation prüfen. Die Lizenz ist Apache-2.0, was kommerzielle Nutzung und Modifikation erlaubt, sofern die Lizenzbedingungen eingehalten werden. Zwei Punkte sind davon getrennt zu betrachten: Die Lizenz der Quelltexte, aus denen der Graph gebaut wird, kann strenger sein, und die Nutzungsbedingungen des LLM-Endpunkts, der die Generierung ausführt, sind eine eigene Frage. Beides ist keine Rechtsberatung, sondern ein Hinweis darauf, wo vor einem produktiven Lauf zu prüfen ist.

Wann sich der Aufwand trägt

GraphGen ist dann sinnvoll, wenn eine kuratierte, faktenreiche Sammlung vorliegt und das Zielmodell in genau dieser Domäne besser werden soll. Die Bioinformatik-Anbindung an NCBI und RNAcentral macht den Fall konkret: Wer aus DNA- oder RNA-Datenbanken Fragen erzeugen will, findet dafür fertige Suchquellen statt eigener Parser. Auch die Benchmark-Synthese mit Single-Choice, Multiple-Choice, Lückentext und Wahr-Falsch-Aufgaben zielt auf einen klaren Anwendungsfall im Bildungsbereich. Umgekehrt ist GraphGen kein Werkzeug für allgemeine Chat-Daten, für kreative Textsorten oder für Teams ohne Zugriff auf ein Modell, das Unsicherheit ausreichend ausdrückt. Der erste Schritt vor jedem größeren Lauf ist deshalb nicht die Generierung, sondern die Graphprüfung mit den im Dezember 2025 ergänzten Metriken für Entitäts- und Relationsgenauigkeit. Erst wenn der Graph die Fragen trägt, lohnt der Durchlauf durch die Pipeline.

Redaktionelles Fazit

GraphGen passt zu Teams, die eine kuratierte Textsammlung besitzen, einen eigenen LLM-Endpunkt betreiben können und SFT- oder Pretrain-Daten mit nachvollziehbarer Herkunft brauchen. Wer nur schnell ein paar Instruktionsbeispiele aus einem Handbuch ziehen will, ist mit einem einfachen Prompt-Skript besser bedient, weil der Graphaufbau und die Kalibrierungsmessung zusätzliche Modellaufrufe kosten. Vor dem ersten Lauf sollte man drei Dinge prüfen: ob der Zielendpunkt mehrfaches Sampling mit Logprobs oder Selbstkonsistenz erlaubt, welche Graph- und KV-Backends die eigene Installation vorsieht (standardmäßig ist RocksDB im Spiel, KuzuDB muss ergänzt werden), und ob die Lizenz von Apache-2.0 mit den Lizenzen der Quelltexte zusammenpasst, aus denen der Graph gebaut wird.

Offizielle Quellen

1. InternScience/GraphGen on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases