Unstract: Dokumentenextraktion als Prompt statt als Template

Das Problem hinter dem Repo: Schemaänderung statt Modellwechsel

Wer Rechnungen, Policen oder KYC-Unterlagen automatisiert ausliest, kennt das eigentliche Kostenproblem. Es ist nicht die Texterkennung. Es ist die Pflege der Extraktionsregeln. Jeder neue Lieferant bringt ein anderes Layout mit, und in klassischen Pipelines bedeutet das neue Templates, neue reguläre Ausdrücke, neue Tests. Das Repository beschreibt diesen Zustand in einer Vergleichstabelle mit der Zeile Schema definition: ohne Unstract schreibe man Regex und baue Templates pro Anbieter, mit Unstract schreibe man den Prompt einmal und decke Variationen ab. Für einen neuen Dokumenttyp nennt die Tabelle Tage Entwicklungsarbeit gegenüber Minuten in Prompt Studio. Solche Gegenüberstellungen sind Marketing, keine Messung, und die README liefert keine Zahlen dahinter. Die Aussage, die trägt, ist eine andere: Das Schema wird zur Konfiguration, nicht zum Code. Zielgruppe sind laut README Teams in finance, insurance, healthcare und KYC/compliance. Das sind Branchen mit vielen Dokumentvarianten und mit Audit-Anforderungen, was den zweiten Teil des Projekts erklärt, die Deploymentschicht.

Vier Dienste, ein Docker-Compose-Aufruf

Die README zeigt ein Architekturdiagramm mit vier Blöcken: Frontend, Backend, Worker und Platform Service. Der genaue Datenfluss zwischen diesen Diensten lässt sich aus dem vorliegenden Material nicht rekonstruieren, das Diagramm ist im Auszug abgeschnitten. Was erkennbar ist: Die Verarbeitung ist nicht in einem Monolithen gebündelt, sondern auf getrennte Komponenten verteilt, und es gibt eine Weboberfläche (Frontend), eine API-Schicht (Backend) sowie einen Worker für die eigentliche Abarbeitung. Dazu passen die beiden Ausgabewege, die die README nennt. Bei API Deployment wird ein Dokument per REST gesendet und JSON zurückgegeben, ein synchroner Pfad. Bei der ETL Pipeline werden Dokumente aus einem Ordner geholt, verarbeitet und in ein Warehouse geladen, ein Batch-Pfad. Dass beide Wege auf derselben Extraktionsdefinition aufsetzen, ist der eigentliche Entwurfsgedanke: Das in Prompt Studio definierte Schema ist die Einheit, die man einmal pflegt und dann in zwei Betriebsarten verwendet. Die LLM-Anbindung läuft laut README über austauschbare Provider, genannt werden OpenAI, Anthropic, Bedrock und Ollama. Der letzte Eintrag ist für regulierte Umgebungen relevant, weil er einen lokalen Betrieb ohne externen API-Aufruf erlaubt.

Inbetriebnahme: ein Skript, viele Flags

Der Einstieg ist bewusst kurz gehalten. Die README nennt als Voraussetzungen Linux oder macOS, Docker und Docker Compose, mindestens 8 GB RAM und Git. Dann folgen drei Zeilen: git clone https://github.com/Zipstack/unstract.git, cd unstract, ./run-platform.sh. Danach ist die Oberfläche unter http://frontend.unstract.localhost erreichbar, mit dem Benutzernamen unstract und dem Passwort unstract. Dass die Standardzugangsdaten im Klartext in der README stehen, ist für eine lokale Testinstanz üblich und für alles andere ein sofort zu ändernder Zustand. Interessanter als der Standardfall sind die Flags, weil sie den Reifegrad des Betriebs verraten. Es gibt -v für einen bestimmten Versions-Tag, -u für ein Upgrade, -b für einen lokalen Build, -e für das reine Anlegen der Umgebungsdateien, -p für den reinen Image-Pull, -d für den Detached-Modus und -h für die Hilfe. Die Kombinierbarkeit wird an Beispielen gezeigt, etwa ./run-platform.sh -u -b -v current für ein Upgrade mit lokal gebauten Images vom Arbeitsbranch. Solche Flags deuten darauf hin, dass das Projekt selbst als Testfeld für Entwicklungsversionen gedacht ist, nicht nur als Endnutzerprodukt. Der Hinweis auf Python, uv, Vite, Bun und Biome in den Badges betrifft dagegen die Entwicklung des Repos, nicht den Betrieb über Docker.

Der Schlüssel, dessen Verlust die Konfiguration mitnimmt

Die README enthält genau eine Warnung, und sie ist die wichtigste Zeile im Dokument. Der ENCRYPTION_KEY verschlüsselt Adapter-Zugangsdaten, also die Verbindungen zu Datenquellen und Zielsystemen. Geht er verloren, sind bestehende Adapter nicht mehr zugänglich. Das ist kein theoretisches Risiko, sondern eine direkte Folge davon, dass der Stack die Zugangsdaten selbst verwaltet statt sie bei jedem Aufruf mitzugeben. Der Schlüssel liegt laut README in backend/.env oder platform-service/.env und soll an einen sicheren Ort kopiert werden. Wer Unstract als Containerverbund betreibt, muss diesen Schlüssel also in dieselbe Kategorie einordnen wie Datenbank-Backups: ohne ihn ist der Zustand nicht wiederherstellbar. Bemerkenswert ist, dass die README an dieser Stelle sehr deutlich wird und an allen anderen Stellen knapp bleibt. Das lässt den Schluss zu, dass hier in der Praxis Schaden entstanden ist.

Wo das Modell an die Grenze kommt

Die README verspricht, dass ein einmal geschriebener Prompt Layoutvarianten abdeckt. Das ist eine Erwartung, die man prüfen muss, und das Material liefert dazu keine Belege. Ein LLM kann mit unbekannten Layouts umgehen, aber es liefert keine Garantie. Zwei Dokumente mit gleichem Inhalt können unterschiedliche Ergebnisse produzieren, und genau das ist in einer Pipeline problematisch, die in ein Warehouse schreibt. Wer Felder wie Beträge, Policennummern oder Diagnosecodes extrahiert, braucht eine Validierungsschicht hinter dem Modell, und die README beschreibt keine. Ein zweiter Punkt betrifft die Abhängigkeit von den genannten Providern. Der Betrieb über Ollama ist möglich, aber die Qualität der Extraktion hängt dann am lokalen Modell, und dazu macht die README keine Angabe. Schließlich ist Unstract der falsche Werkzeugkasten für einen einzelnen, stabilen Dokumenttyp mit festem Layout. Wer nur einen Belegtyp verarbeitet, baut mit einer Bibliothek und einem API-Aufruf eine kleinere Lösung, die weniger Dienste, weniger Konfiguration und weniger Angriffsfläche hat. Der Aufwand für vier Dienste, eine Oberfläche und ein Schlüsselmanagement lohnt sich erst, wenn die Variantenvielfalt real ist.

Prompt-Schema gegen Parser-Bibliothek und direkten API-Aufruf

Die naheliegende Alternative ist ein direkter Aufruf einer Vision-fähigen Modell-API aus einem eigenen Skript, ohne Zwischenschicht. Der Unterschied liegt nicht im Modell, sondern in dem, was drumherum fehlt: kein Prompt Studio zum Iterieren am Schema, keine Versionierung der Extraktionsdefinition, kein getrennter Batch-Pfad, keine Weboberfläche für Fachanwender. Man tauscht also Bedienkomfort und Nachvollziehbarkeit gegen wenige hundert Zeilen eigenen Code. Die zweite Alternative sind Dokumenten-Parser wie docling, die auf Layoutanalyse und Textextraktion spezialisiert sind. Deren Ansatz ist grundsätzlich anders: Sie liefern eine Repräsentation des Dokuments, aus der man Felder deterministisch herauszieht, statt ein Modell nach dem gewünschten JSON zu fragen. Das ist reproduzierbarer und billiger pro Dokument, scheitert aber genau dort, wo das Schema nicht formal beschreibbar ist. Unstract setzt auf das Gegenteil: Ausgabeform zuerst, Wege dorthin offen. Wer Belege mit stark schwankender Struktur und wechselnden Formulierungen verarbeitet, fährt mit dem Prompt-Ansatz besser. Wer feste Tabellen mit stabilen Spalten ausliest, sollte beim Parser bleiben und sich die Modellkosten sparen.

Lizenz und Release-Takt

Unstract steht unter AGPL-3.0. Das ist eine Copyleft-Lizenz mit einer Besonderheit, die für Netzwerkdienste greift: Wer eine modifizierte Version als Dienst über ein Netzwerk anbietet, muss den Quellcode den Nutzern zugänglich machen. Für den internen Betrieb ändert sich dadurch nichts. Sobald aber ein Produkt auf Unstract aufsetzt und Kunden darüber zugreifen, wird die Frage relevant, ob die eigenen Änderungen offengelegt werden müssen. Die README verlinkt daneben eine Enterprise-Seite und ein CLA, was auf ein kommerzielles Modell neben der offenen Variante hindeutet. Das ist eine übliche Konstruktion, aber sie bedeutet, dass Funktionen je nach Ausgabe unterschiedlich verfügbar sein können, und die README trennt das nicht sauber. Zur Wartung: Die veröffentlichten Versionen liegen dicht beieinander, v0.187.1 und v0.187.2 im Abstand von zwei Tagen, v0.188.0 rund eine Woche später. Ein solcher Takt bedeutet häufige Patch- und Minor-Releases und damit einen wiederkehrenden Upgrade-Aufwand, den das Skript mit -u und -v zwar technisch abbildet, aber nicht bewertet. Wer den Stack produktiv betreibt, sollte eine feste Versionsnummer pinnen und Upgrades bewusst fahren, statt dem jeweils neuesten Tag zu folgen.

MCP, n8n und die Frage der Einbettung

Neben den beiden Hauptwegen nennt die README zwei Integrationspunkte. Ein MCP Server verbindet Unstract mit KI-Agenten, ein n8n Node fügt es in bestehende Automatisierungsworkflows ein. Beide verschieben die Rolle des Projekts: Statt eines eigenständigen Dienstes mit eigener Oberfläche wird es zu einem Baustein in einer fremden Orchestrierung. Das ist praktisch, wenn bereits ein Agent oder ein Workflow-System im Einsatz ist, und es entlastet von der Frage, wie Fachanwender an das Schema kommen. Es hat aber einen Preis, den die README nicht diskutiert: Die Extraktionsdefinition lebt dann in einem System, dessen Fehlerbehandlung und Wiederholungslogik man nicht kontrolliert. Für Teams, die ohnehin n8n betreiben, ist der Node der kürzere Weg. Für alle anderen ist die REST-API die klarere Schnittstelle, weil sie sich mit denselben Mitteln testen und überwachen lässt wie der Rest der Pipeline.

Redaktionelles Fazit

Unstract passt zu Teams, die viele Dokumenttypen mit variierendem Layout verarbeiten und dafür keine Regex- oder Template-Fabrik betreiben wollen, sowie zu Umgebungen, in denen ein selbst gehosteter Stack mit Docker Compose akzeptabel ist. Wer nur einen einzelnen, stabilen Belegtyp verarbeitet, ist mit einer schlanken Bibliothek wie docling oder einer direkt angesteuerten Vision-API besser bedient. Vor dem Produktiveinsatz zu klären sind zwei Dinge: ob die AGPL-3.0-Bedingungen mit dem eigenen Vertriebsmodell zusammenpassen, und ob der ENCRYPTION_KEY aus backend/.env beziehungsweise platform-service/.env gesichert ist, denn ohne ihn sind bestehende Adapter nicht mehr erreichbar.

Offizielle Quellen

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Zipstack/unstract on GitHub