ConardLi/easy-dataset: Dokumente zu Fine-Tuning-Datensätzen machen
A powerful tool for creating datasets for LLM fine-tuning 、RAG and Eval
Auf einen Blick
- Was ist das?
- Easy Dataset ist eine JavaScript-Anwendung, die PDFs, Markdown und DOCX in strukturierte Frage-Antwort-Datensätze für Fine-Tuning, RAG und Evaluation umwandelt. Die Lizenzdatei erlaubt keine eindeutige Aussage, und die Lizenzangabe im Repository ist widersprüchlich.
- Für wen ist es gedacht?
- Wer aus vorhandenen Fachdokumenten schnell einen Frage-Antwort-Datensatz bauen will, ohne eine eigene Pipeline zu schreiben, findet hier einen fertigen Ablauf mit Dokumentenparsing, Segmentierung, Prompt-Templates und Export nach Alpaca oder ShareGPT.
- Darf ich es kommerziell nutzen?
- Erst prüfen. Die Lizenz dieses Repositorys ordnen wir nicht automatisch ein; lesen Sie vor jeder kommerziellen Nutzung die LICENSE-Datei.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 137 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich JavaScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem Easy Dataset löst
Der Ausgangspunkt ist ein Stapel Fachdokumente und die Frage, wie daraus Trainingsdaten werden. Die README beschreibt den Ablauf als Umwandlung domänenspezifischer Dokumente in strukturierte Datensätze, die für Fine-Tuning, Retrieval-Augmented Generation und Modellbewertung gedacht sind. Der eigentliche Aufwand liegt selten im Training, sondern davor: Dokumente zerlegen, brauchbare Fragen formulieren, konsistente Antworten erzeugen, alles bereinigen und in ein Format bringen, das eine Trainingspipeline akzeptiert.
Genau diese Kette ist der Gegenstand des Projekts. Die Zielgruppe sind nach der Selbstbeschreibung sowohl technische als auch nicht-technische Nutzer, was sich in der Form niederschlägt: Es gibt Desktop-Clients für Windows, macOS und Linux, daneben einen lokalen Startweg über Node.js. Wer schon eine eigene Datenpipeline mit Skripten betreibt, wird den Nutzen anders bewerten als jemand, der zum ersten Mal einen Fine-Tuning-Datensatz aufsetzt. Für die zweite Gruppe ist der Reiz, dass Parsing, Segmentierung, Prompt-Verwaltung und Export in einer Oberfläche zusammenlaufen, statt aus fünf separaten Werkzeugen zusammengesetzt zu werden.
Vom Dokument zur Frage: der Ablauf im Inneren
Die Verarbeitung folgt einer sichtbaren Kette. Zuerst wird ein Dokument hochgeladen, unterstützt werden laut README PDF, Markdown, DOCX, TXT und EPUB. Für PDFs und Bilddaten nennt die Dokumentation Vision-Modelle wie Gemini und Claude, das Parsing kann also je nach Modellwahl multimodal erfolgen. Danach folgt die Segmentierung, und hier bietet das Projekt mehrere Algorithmen an: Aufteilung nach Markdown-Struktur, rekursive Trenner, feste Länge und Code-bewusstes Chunking. Die Segmentierung ist im Interface visuell anpassbar, was praktisch relevant ist, weil die Qualität der späteren Fragen direkt davon abhängt, ob ein Chunk einen zusammenhängenden Gedanken enthält.
Aus den Segmenten werden Fragen extrahiert, mit Frage-Templates und Batch-Generierung. Ein Domänen-Label-Baum wird laut README auf Basis der Dokumentstruktur aufgebaut, mit automatischer Verschlagwortung. Die Antworten erzeugt anschließend ein LLM über eine API, optional inklusive Chain-of-Thought. Das bedeutet: Die Anwendung selbst trainiert nichts und bewertet nichts lokal, sie orchestriert Aufrufe an ein Modell. Die Datenqualität ist damit zu einem großen Teil eine Funktion des gewählten Modells und der Prompt-Templates, die projektweit überschreibbar sind. Wer die Standard-Prompts unverändert übernimmt, bekommt generische Fragen; die Anpassung ist kein optionales Extra, sondern der Hebel, an dem die Domänenspezifität entsteht.
Datensatztypen jenseits einfacher Frage-Antwort-Paare
Die README listet mehrere Ausgabeformen. Neben klassischen Single-Turn-QA-Paaren gibt es mehrstufige Dialogdatensätze mit konfigurierbaren Rollen und Szenarien, Bild-QA-Datensätze mit Import über Verzeichnis, PDF oder ZIP sowie eine als Data Distillation bezeichnete Variante, die Label-Baum und Fragen direkt aus Domänenthemen erzeugt, ohne dass Dokumente hochgeladen werden. Diese letzte Option ist dann sinnvoll, wenn das Wissen im Modell bereits steckt und nur in eine strukturierte Form gebracht werden soll.
Für die Vielfalt der Daten nennt die README GA-Pair-Generierung, also Genre-Audience-Paare, die dieselbe Frage aus unterschiedlichen Perspektiven variieren. Dazu kommen Exportformate Alpaca, ShareGPT und Multilingual-Thinking als JSON oder JSONL, mit der Möglichkeit, die Anzahl der Exporte pro Tag zu begrenzen, um den Datensatz auszubalancieren. Wer ohnehin schon in einem dieser Schemata arbeitet, spart sich das Umschreiben. Wer ein exotisches Format braucht, muss nach dem Export selbst konvertieren.
Installation und Betrieb: Client oder Node.js
Der einfachste Weg führt über die Desktop-Clients. Die README verlinkt für Windows eine Setup.exe, für macOS getrennte Builds für Intel und Apple Silicon sowie Linux-Pakete, jeweils über die Release-Seite des Repositories. Das ist der Weg, den die Dokumentation für nicht-technische Nutzer nahelegt, weil dabei keine Node.js-Umgebung eingerichtet werden muss.
Für den lokalen Start aus dem Quellcode ist Node.js die Voraussetzung, das Projekt ist in JavaScript geschrieben. Die README verweist für die konkreten Schritte auf die Dokumentation unter docs.easy-dataset.com, die den Abschnitt Local Run enthält. Die Modellanbindung läuft über die OpenAI-kompatible API: Laut README werden alle LLM-APIs unterstützt, die diesem Format folgen, genannt werden OpenAI, MiniMax, Ollama für lokale Modelle, Zhipu AI, Alibaba Bailian und OpenRouter. In der Konfiguration sind also Endpunkt, API-Schlüssel und Modellname die zentralen Felder, und für einen vollständig lokalen Betrieb ist Ollama der in der README genannte Weg. Ein Hinweis zur Vorsicht: Die README zeigt in diesem Abschnitt Tabellen mit Download-Links, aber keine vollständigen Befehlszeilen für den Quellcode-Start. Wer diesen Weg gehen will, muss die Dokumentationsseite lesen, statt sich auf die README zu verlassen.
Evaluation und Blindvergleich
Mit Version 1.7.0 kamen Evaluationsfunktionen hinzu. Die Release Notes beschreiben die Umwandlung von Dokumenten in Evaluationsdatensätze mit Fragetypen wie Wahr/Falsch, Einfachauswahl, Mehrfachauswahl, Kurzantwort und offene Fragen. Die automatische Bewertung erfolgt über ein Judge Model mit anpassbaren Bewertungsregeln, und für einen unverzerrten Vergleich zweier Modelle gibt es einen doppelblinden Arena-Modus. Zusätzlich nennt die README eine automatische Qualitätsbewertung der erzeugten Datensätze mit Filterung.
Das ist mehr, als der Name des Projekts vermuten lässt, und es verschiebt den Charakter: Easy Dataset ist damit nicht nur ein Generator, sondern auch ein Ort, an dem Modellantworten gegen einen selbst erstellten Testsatz laufen. Die Aussagekraft steht und fällt mit dem Judge Model. Wenn dasselbe Modell Fragen erzeugt, Antworten generiert und diese Antworten bewertet, ist die Bewertung nicht unabhängig. Der Blindvergleich ist der methodisch sauberere Teil, weil dort Menschen die Antworten ohne Modellkenntnis einordnen.
Grenzen und Fälle, in denen das Werkzeug nicht passt
Die Lizenzlage ist die erste offene Fläche. Die README trägt ein Badge mit AGPL 3.0, die Repository-Metadaten melden dagegen NOASSERTION, also keine maschinenlesbare Lizenzangabe. Beides zusammen bedeutet: Wer das Projekt in einem kommerziellen Produkt einsetzen will, muss die Datei LICENSE im Repository selbst lesen und gegebenenfalls rechtlichen Rat einholen. Eine Aussage über die tatsächlichen Pflichten lässt sich aus dem vorliegenden Material nicht ableiten.
Die zweite Grenze ist der Modellzwang. Ohne konfigurierten LLM-Endpunkt erzeugt die Anwendung keine Fragen und keine Antworten. Wer keine API nutzen darf oder will, braucht ein lokal laufendes Modell, und dessen Qualität bestimmt das Ergebnis. Das ist kein Fehler des Projekts, aber es macht die Entscheidung für Easy Dataset zu einer Entscheidung über die Modellinfrastruktur.
Die dritte Grenze betrifft den Anspruch auf Bequemlichkeit. Die Dokumentation ist überwiegend auf Chinesisch und Englisch, die README liegt zusätzlich auf Türkisch vor. Wer die Prompt-Templates nicht anpasst, erhält austauschbare Fragen. Und die Anwendung ist kein Ersatz für eine Datenprüfung: Die README nennt Datenbereinigung und automatische Qualitätsbewertung, aber die Verantwortung für die inhaltliche Korrektheit eines Trainingsdatensatzes bleibt beim Nutzer.
Alternative: selbst gebaute Skripte gegen eine Oberfläche
Der naheliegende Vergleich ist eine eigene Pipeline aus Python-Skripten, die Dokumente mit einer Bibliothek wie PyMuPDF oder Unstructured parst, Chunks bildet und über die OpenAI-API Fragen und Antworten erzeugt. Der Unterschied liegt nicht in der Funktionsliste, sondern im Zustand. Eigene Skripte sind reproduzierbar und versionierbar, aber jede Änderung an der Segmentierung oder am Prompt-Format erfordert Code-Änderungen und einen erneuten Lauf über den gesamten Korpus.
Easy Dataset setzt dagegen auf einen persistenten Arbeitsbereich: Projekte, Label-Bäume, hochgeladene Dokumente, generierte Fragen und Antworten liegen in einer Oberfläche und lassen sich einzeln nachbearbeiten. Der Preis dafür ist Bindung an die Datenhaltung der Anwendung und eine Konfiguration über Formulare statt über eine Datei im Repository. Wer seine Datensätze als Code-Artefakte behandeln und in einer CI-Pipeline neu erzeugen will, ist mit Skripten besser bedient. Wer iterativ mit Fachleuten an einem Datensatz arbeitet und einzelne Fragen von Hand korrigieren möchte, profitiert von der Oberfläche.
Pflege, Upgrades und was vor dem Einsatz zu prüfen ist
Die Release-Historie ist eng getaktet: 1.7.1 im Januar 2026, 1.7.2 im Februar, 1.7.3 im April, der letzte Push auf main datiert auf den 1. Mai 2026. Das spricht für aktive Entwicklung, sagt aber nichts über die Stabilität der Datenhaltung zwischen Versionen. Wer den Quellcode-Weg wählt, sollte vor einem Upgrade prüfen, ob sich das Schema der Projektdateien geändert hat, weil sonst vorhandene Datensätze nicht mehr lesbar sein könnten. Die README macht dazu keine Zusage, und die Release Notes zu 1.7.3 enthalten im vorliegenden Material keine Angaben zu Migrationen.
Für die Lizenz gilt: Die Angabe AGPL 3.0 im Badge und NOASSERTION in den Metadaten widersprechen sich. Bei AGPL wäre ein Betrieb als Netzwerkdienst mit Offenlegungspflichten verbunden, aber diese Einordnung ist ohne Blick in die Datei LICENSE nicht belastbar. Ein Upgrade auf eine neuere Version kann zudem neue Evaluationsfunktionen mitbringen, die zusätzliche API-Aufrufe verursachen. Das Dashboard zur Ressourcenüberwachung mit Token-Statistik und API-Aufrufverfolgung ist deshalb kein Beiwerk, sondern das Werkzeug, mit dem sich die Kosten eines Generierungslaufs vor dem nächsten Schritt abschätzen lassen.
Redaktionelles Fazit
Wer aus vorhandenen Fachdokumenten schnell einen Frage-Antwort-Datensatz bauen will, ohne eine eigene Pipeline zu schreiben, findet hier einen fertigen Ablauf mit Dokumentenparsing, Segmentierung, Prompt-Templates und Export nach Alpaca oder ShareGPT. Wer die Datenhoheit nicht an einen externen LLM-Anbieter abgeben möchte, sollte vor dem Start prüfen, ob ein lokales Modell über Ollama oder ein selbst gehosteter OpenAI-kompatibler Endpunkt konfiguriert werden kann, und ob das die gewünschte Antwortqualität erreicht. Vor jedem produktiven Einsatz ist die Datei LICENSE im Repository zu lesen, weil die README AGPL 3.0 nennt, die Repository-Metadaten aber NOASSERTION melden.
Community-Notizen