DocETL: deklarative LLM-Pipelines für unstrukturierte Daten

Welches Problem DocETL adressiert

Wer tausend Support-Tickets, Verträge oder Interviewtranskripte mit einem LLM auswerten will, schreibt in der Regel eine Schleife, die pro Dokument einen Prompt absetzt, das Ergebnis parst, Fehler abfängt und die Ausgabe in eine Tabelle schreibt. DocETL setzt genau an dieser Stelle an. Das README beschreibt den Ausgangspunkt so: ohne DocETL schreibe man jeden LLM-Aufruf selbst, verdrahte ihn und stimme das Ergebnis manuell auf Genauigkeit, Kosten und Latenz ab. Die Zielgruppe sind damit Datenverarbeitungs-Teams, die unstrukturierte Eingaben in abfragbare Tabellen überführen und diesen Schritt wiederholbar halten wollen. Die Ausgabe ist laut README eine Tabelle, die sich in einer Datenbank weiterverarbeiten lässt. Bemerkenswert ist der Anspruch, strukturierte und unstrukturierte Daten gemeinsam zu verarbeiten: DocETL ist kein reiner Textanalyse-Baustein.

Map, Reduce und der Rest: die Operatoren als Baukasten

Das README nennt map, reduce, filter, resolve, split, gather und extract als Operatoren. Das Modell ist an Map-Reduce angelehnt: map wendet einen Prompt auf jedes Dokument an und erzeugt pro Eingabe eine Ausgabezeile mit einem festen Schema. reduce gruppiert diese Zeilen über einen Schlüssel und fasst sie zusammen. Im Python-Beispiel wird zuerst klassifiziert und dann über die Kategorie reduziert. Die Prompts sind Jinja-artige Templates: {{ input.text }} referenziert ein Feld des aktuellen Datensatzes, {% for t in inputs %} iteriert in reduce über die gruppierten Einträge. Das ist der eigentliche Mechanismus, den man verstehen muss. Die Pipeline ist eine Kette von Operatoren, jeder Operator bekommt eine Schema-Definition, und DocETL kümmert sich laut README um die Parallelisierung über die Daten. Wer schon einmal eine Map-Reduce-Pipeline in einem Framework wie Spark gebaut hat, erkennt die Form wieder, nur dass die Map-Funktion hier ein Sprachmodell ist.

Zwei Wege zur Pipeline: Python-API und YAML

DocETL bietet zwei Einstiegspunkte. Die Python-API gilt im README als empfohlen für Produktivcode, Notebooks und Skripte. Man beginnt mit docetl.read_json, hängt map- und reduce-Aufrufe an, setzt optional docetl.default_model und docetl.rate_limits, und ruft am Ende pipeline.collect() für den vollen Lauf oder pipeline.show() für einen Testlauf auf fünf Dokumenten. Der Kostenausweis pipeline.total_cost wird im Beispiel direkt nach dem Lauf ausgegeben. Die YAML-Variante beschreibt dieselbe Struktur deklarativ: ein datasets-Block mit type und path, ein default_model, eine Liste von operations mit name, type, prompt und output.schema, und ein pipeline-Block mit steps und output. Ausgeführt wird sie mit docetl run pipeline.yaml. Beide Wege erzeugen dieselbe Art von Ausführung, die YAML-Variante ist für Teams gedacht, die die Pipeline ohne Python-Code pflegen wollen. Zusätzlich existiert mit DocWrangler eine UI, die das README als visuellen Spielplatz für interaktive Prompt-Entwicklung beschreibt, lokal oder über docetl.org/playground.

Der Optimizer als eigentliches Verkaufsargument

Das README verspricht, DocETL optimiere die Pipeline automatisch: Modelle tauschen, Prompts umschreiben, Operationen zerlegen und Teilaufgaben durch Code ersetzen, wo das möglich ist. Ziel sind höhere Genauigkeit und niedrigere Kosten. Dafür steht ein eigener Optimierer namens MOAR, der im README mit einem VLDB-2026-Papier belegt ist. Das ist der Punkt, an dem sich DocETL von einem dünnen Wrapper um einen LLM-Client unterscheidet. Die Optimierung ist aber auch der Punkt, an dem die Dokumentation am wenigsten über konkrete Ergebnisse sagt: das Material nennt keine Zahlen, keine Genauigkeitsgewinne, keine Kostenreduktion in Prozent. Wer den Optimizer einsetzen will, muss die Wirkung auf den eigenen Daten selbst messen. Der Aufwand dafür ist real, denn eine optimierte Pipeline verhält sich anders als die handgeschriebene Version, und diese Differenz will verstanden sein.

Wo DocETL an Grenzen stößt

Die größte Einschränkung steckt in der Natur der Sache: Jede Ausgabe hängt von einem Sprachmodell ab, dessen Antworten nicht deterministisch sind. DocETL kann das nicht aufheben, nur einrahmen. Dazu kommt die Abhängigkeit von externen Modell-APIs. Das README zeigt export OPENAI_API_KEY=your_key und merkt an, dass jeder andere Anbieter-Schlüssel ebenfalls funktioniert, aber die Verfügbarkeit, Latenz und Preise liegen außerhalb des Projekts. Wer on-premises ohne externen Dienst arbeiten muss, findet im Material keinen Hinweis auf lokale Modelle. Ein zweiter Punkt: Die Beispiele im README sind bewusst klein gehalten. Ob die Parallelisierung bei sehr großen Dokumentmengen trägt, ob Rate-Limits über den llm_call- und llm_tokens-Einträgen sauber greifen, lässt sich aus dem Material nicht ableiten. Und schließlich ist DocETL kein Werkzeug für Einzelfälle. Für ein einzelnes Dokument ist der Konfigurationsaufwand einer Pipeline größer als der eines direkten API-Aufrufs.

Was DocETL von einer handgeschriebenen Schleife unterscheidet

Die naheliegende Alternative ist eine eigene Schleife mit einem LLM-SDK, etwa direkt gegen die OpenAI- oder Anthropic-API. Der Unterschied liegt nicht in der Ausgabe, sondern im Vertrag. Bei einer eigenen Schleife kontrolliert man jede Zeile Code, jedes Retry, jedes Parsing. DocETL nimmt einem diese Kontrolle ab und verlangt dafür, dass man sich an seine Operatoren und Schemata hält. Ein zweiter Vergleichspunkt sind Workflow-Engines wie Airflow oder Prefect, die Tasks orchestrieren, aber nichts über LLM-Prompts oder Schema-Validierung wissen. DocETL sitzt eine Ebene höher: Es ist eine Pipeline-Sprache für semantische Operationen, nicht ein generischer Scheduler. Wer bereits eine Orchestrierung betreibt, kann DocETL als Schritt darin einbetten, statt es zu ersetzen. Der Preis für die Abstraktion ist Bindung: Wer sein Prompt-Tuning tief in DocETL-Operatoren gegossen hat, muss beim Wechsel die Konzepte neu abbilden.

Wartung, Versionen und Lizenz

Die letzten Releases sind 0.3.0 vom Juni 2026, davor 0.2.6 im Dezember 2025 und 0.2.5 im August 2025. Der Abstand zwischen 0.2.6 und 0.3.0 beträgt rund sechs Monate, der zwischen 0.2.5 und 0.2.6 etwa vier. Das deutet auf eine kleine, aber aktive Versionsfolge hin. Die Null vor dem Punkt ist ernst zu nehmen: In der 0.x-Phase sind Breaking Changes zwischen Minor-Versionen üblich, und wer DocETL produktiv einsetzt, sollte die YAML- und Python-Konfiguration bei jedem Sprung gegen die eigene Pipeline prüfen. Das Repository ist nicht archiviert, der letzte Push liegt auf September 2026. Die Lizenz ist MIT, was kommerzielle Nutzung, Änderung und Weitergabe erlaubt, solange der Copyright-Hinweis erhalten bleibt. Das README verlinkt die Lizenzangabe auf opensource.org. Wer DocETL in ein Produkt einbettet, sollte den MIT-Text in der eigenen Distribution mitführen; das ist eine technische Prüfung, keine Rechtsberatung.

Für wen sich der Einstieg lohnt und was zuerst zu prüfen ist

Das README nennt zwei Wege, um beim Schreiben der Pipeline Hilfe zu bekommen: docetl install-skill für Claude Code oder der Prompt unter docetl.org/llms-full.txt für ChatGPT und die Claude-App. Das ist ein Hinweis darauf, für wie erklärungsbedürftig die eigene Konfiguration gehalten wird. Wer einsteigt, sollte mit dem Python-Beispiel beginnen, weil es die Kostenkontrolle über pipeline.total_cost und den Testlauf über pipeline.show() direkt zeigt. Vor jedem größeren Lauf lohnt es sich, die Schema-Definitionen ernst zu nehmen: Wenn map ein Feld category vom Typ str verspricht und das Modell etwas anderes liefert, ist die Pipeline an dieser Stelle fragil. Wie DocETL mit solchen Abweichungen umgeht, geht aus dem Material nicht hervor. Das ist die erste Frage, die man mit einem kleinen Lauf auf eigenen Daten klären sollte, bevor man den Optimizer auf einen vollen Korpus ansetzt.

Redaktionelles Fazit

Sinnvoll ist DocETL für Teams, die wiederkehrende LLM-Auswertungen über Tausende Dokumente fahren und dafür eine deklarative Beschreibung statt handgeschriebener Schleifen wollen. Wer nur gelegentlich ein einzelnes Dokument an ein Modell schickt, trägt mit DocETL mehr Konfigurationsaufwand ein als Nutzen. Vor dem ersten Produktiveinsatz sollte man mit pipeline.show() auf einer kleinen Stichprobe prüfen, ob die Prompts die erwartete Schema-Ausgabe liefern, und mit pipeline.total_cost die tatsächlichen Tokenkosten der eigenen Daten messen, bevor man den Optimizer auf einen größeren Lauf ansetzt.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. ucbepic/docetl on GitHub