ContextGem: Dokumentenextraktion als deklaratives Modell statt als Prompt-Bastelarbeit

Das Problem hinter dem Framework

Strukturierte Extraktion aus Fließtext ist in der Praxis kein einzelner Modellaufruf, sondern eine Kette. Ein Prompt muss formuliert, ein Validierungsmodell gebaut, die Modellantwort darauf abgebildet und anschließend noch geklärt werden, an welcher Stelle im Original ein extrahierter Wert eigentlich steht. ContextGem setzt genau an dieser Kette an. Die Projektdokumentation beschreibt den Ausgangspunkt so, dass verlässliche Extraktion üblicherweise das Schreiben von Extraktionsprompts, das Entwerfen von Validierungsmodellen, das Zurückführen der Ausgaben auf Quellen, die Orchestrierung mehrstufiger Pipelines und die Nutzungsverfolgung über mehrere LLMs umfasst. Das Framework beansprucht, all das über Abstraktionen zu übernehmen: Man beschreibt in natürlicher Sprache, was extrahiert werden soll, und überlässt dem Framework das Wie.

Die Zielgruppe lässt sich an den Topics des Repositories ablesen: contract-analysis, legaltech, document-intelligence, text-analysis. Wer regelmäßig Verträge, Berichte oder andere lange Dokumente auswertet und die Ergebnisse in einer Datenbank oder einem nachgelagerten Prozess braucht, ist der Adressat. Das README nennt als Beispiel ausdrücklich die Extraktion von Anomalien aus einem Rechtsdokument, also einen Fall, in dem ein einzelner Wert nicht genügt, sondern Kontext nötig ist.

Aspects, Concepts und die Herkunft jedes Werts

Das Datenmodell von ContextGem besteht aus zwei tragenden Begriffen. Aspects sind Themen, Kategorien oder Themenbereiche innerhalb eines Dokuments. Concepts sind die konkreten Dinge, die man daraus ziehen will: Entitäten, Fakten, Schlussfolgerungen, Bewertungen. Die Dokumentation verlinkt dazu eigene Seiten unter aspects/aspects/ und concepts/supported_concepts/, was zeigt, dass es sich um fest definierte, nicht um frei erfundene Typen handelt. Wer ein Feld braucht, das in keine der unterstützten Concept-Kategorien fällt, muss prüfen, ob sich das mit dem vorhandenen Satz abbilden lässt.

Interessanter ist die Verschachtelung. Concepts können innerhalb von Aspects liegen, und Aspects können hierarchisch aufgebaut sein. Ein Vertrag wird also nicht als eine flache Textmenge behandelt, sondern in Abschnitte zerlegt, aus denen jeweils eigene Felder gezogen werden. Zusammen mit den granularen Referenzen, die das README auf Absatz- und Satzebene verortet, entsteht daraus der eigentliche Nutzen: Ein extrahierter Wert kommt nicht allein zurück, sondern mit der Stelle, an der er im Dokument steht, plus einer Begründung. Für Prüfpfade in juristischen oder regulatorischen Kontexten ist das der Unterschied zwischen einem brauchbaren und einem unbrauchbaren Ergebnis. Die automatische Datenmodellierung und die dynamischen Prompts sind Mittel zum Zweck, nicht der Zweck selbst.

Installation und der Einstiegspunkt

Die Installation ist unspektakulär. Das README empfiehlt uv und nennt den Befehl uv add contextgem, alternativ pip install -U contextgem. Unterstützt werden laut den Badges die Python-Versionen 3.10 bis 3.14. Ein Paketname, ein Befehl, keine weiteren Schritte.

Der Einstiegspunkt ist das Document-Objekt, das laut README ein einheitliches, serialisierbares Speichermodell für Dokumente bereitstellt. Was genau serialisiert wird und in welchem Format, geht aus dem vorliegenden Material nicht hervor; das ist eine der Stellen, an denen man die Dokumentation unter contextgem.dev aufsuchen muss, bevor man das Framework in eine Pipeline einbaut. Das README zeigt einen Codeausschnitt zur Extraktion von Anomalien aus einem Rechtsdokument, der in der vorliegenden Fassung jedoch abgeschnitten ist. Konkrete Klassennamen und Methodenaufrufe lassen sich daraus nicht ableiten, und ich erfinde hier keine. Wer den Einstieg sucht, findet ihn in der Quickstart-Sektion der Projektdokumentation, nicht in diesem Text.

Wo die Abstraktion an ihre Grenzen stößt

Der Kern des Versprechens ist zugleich die größte Einschränkung. Wenn das Framework die Prompts erzeugt, kann man sie nicht mehr von Hand nachschärfen, ohne die Abstraktion zu verlassen. Bei Aufgaben, die auf einer sehr spezifischen Formulierung beruhen, oder bei Modellen, die auf bestimmte Prompt-Muster empfindlich reagieren, ist das ein echter Verlust. Man tauscht Kontrolle gegen Code-Einsparung, und dieser Tausch ist nicht in jedem Fall richtig.

Dazu kommt die Frage der Kosten. Die Architektur arbeitet mit Aspects und darin verschachtelten Concepts, dazu mit Begründungen und Referenzzuordnung. Jede dieser Ebenen bedeutet Modellaufrufe. Das README nennt als Feature ausdrücklich die Nutzungsverfolgung über LLMs, was implizit bestätigt, dass mehrere Aufrufe pro Dokument anfallen können. Wie viele es konkret sind, steht im vorliegenden Material nicht. Bei langen Verträgen und einem hierarchischen Aspect-Baum sollte man das vor einem Produktiveinsatz selbst messen, denn die Rechnung skaliert mit der Dokumentlänge und der Zahl der definierten Concepts, nicht mit der Zahl der Dokumente allein.

Ein dritter Punkt ist die Dokumentbasis. Das README nennt Text und Bilder als Eingaben. Wer PDFs, gescannte Akten oder Office-Formate verarbeiten will, muss klären, ob und wie diese vor der Übergabe an ContextGem in Text oder Bild umgewandelt werden. Das Framework ist keine Dokumentenkonvertierung.

Der Unterschied zu Pydantic plus Provider-SDK

Die naheliegende Alternative ist der direkte Weg: Pydantic für das Schema, das SDK des jeweiligen Anbieters für den Aufruf, ein eigener Prompt als Konstante im Code. Diesen Weg geht man ohne zusätzliche Abhängigkeit, mit voller Kontrolle über jede Zeile und mit der Freiheit, jede Modellfunktion zu nutzen, die der Anbieter anbietet. Der Preis ist Handarbeit. Referenzzuordnung auf Absatzebene, Begründungen und die verschachtelte Aspect-Struktur muss man selbst bauen und selbst pflegen. Genau diese Teile sind es, die in der Praxis viel Zeit fressen und gern halbfertig bleiben.

Der zweite denkbare Weg sind allgemeine Orchestrierungs-Frameworks für LLM-Ketten. Deren Abstraktionsebene liegt typischerweise bei Schritten und Werkzeugen, nicht bei Dokumenten und Feldern. Man modelliert also den Ablauf und nicht das Extraktionsziel. Das ist flexibler, wenn der Ablauf selbst komplex ist, und unbequemer, wenn man nur wiederkehrend dieselben Felder aus vielen ähnlichen Dokumenten ziehen will. ContextGem setzt die Abstraktion genau auf der Dokument- und Feldebene an, was für gleichförmige Massenverarbeitung spricht und für stark variierende Abläufe eher nicht.

Wartung, Release-Takt und Lizenz

Das Repository ist nicht archiviert, der letzte Push datiert auf den 13. August 2026, die letzte Veröffentlichung v0.27.0 auf denselben Tag. Die Versionsnummer steht noch vor der 1.0. Der Abstand zwischen v0.25.1 im Juni und v0.27.0 im August zeigt einen Takt von mehreren Releases pro Quartal. Für Nutzer heißt das: Die API kann sich zwischen Minor-Versionen bewegen, und ein Upgrade sollte nicht blind erfolgen. Wer das Framework produktiv einsetzt, pinnt die Version und liest die Release Notes, bevor er anhebt.

Positiv für die Wartbarkeit ist die Werkzeugkette, die das README auflistet: uv, Ruff, ty, pre-commit, deptry, Hatch, dazu CodeQL, Bandit und ein Lizenzkompatibilitäts-Check in der CI. Das deutet auf ein Projekt hin, das seine Abhängigkeiten und Lizenzen im Blick behält, ohne dass man daraus auf die Qualität der Extraktionsergebnisse schließen könnte.

Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung der Lizenzhinweise und enthält eine ausdrückliche Patentgewährung. Wer das Framework in ein Produkt einbettet und weitergibt, muss die NOTICE-Datei mitführen. Das ist keine Rechtsberatung, sondern der Hinweis, dass die Lizenzpflichten beim Weiterverteilen greifen und nicht erst beim Verkauf.

Redaktionelles Fazit

ContextGem passt zu Python-Teams, die aus Verträgen, Berichten oder anderen Fließtextdokumenten wiederkehrend strukturierte Felder mit Quellenangabe brauchen und die Prompt-Erzeugung bewusst abgeben wollen. Wer den Prompt Zeichen für Zeichen kontrollieren, eigene Provider-Logik einbauen oder Dokumente jenseits der unterstützten Formate verarbeiten muss, ist hier falsch und sollte direkt mit Pydantic und einem Provider-SDK arbeiten. Vor der Adoption zu prüfen: ob die tatsächlich benötigten Dokumenttypen und Concept-Typen abgedeckt sind, wie viele LLM-Aufrufe ein einzelner Extraktionslauf laut Dokumentation auslöst, und ob die Apache-2.0-Lizenz zu den eigenen Weitergabeplänen passt.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. shcherbak-ai/contextgem on GitHub