Hyper-Extract: Wissensextraktion aus Dokumenten über die Kommandozeile
Hypergraph is more powerful. Transform unstructured text into structured knowledge with LLMs. Graphs, hypergraphs, and spatio-temporal extractions — with one command.
Auf einen Blick
- Was ist das?
- Hyper-Extract wandelt unstrukturierte Texte per LLM in Graphen, Hypergraphen und raum-zeitliche Strukturen um. Die CLI deckt Extraktion, Abfrage, Provenienz und Obsidian-Export ab, ist aber auf ein funktionierendes LLM-Backend angewiesen.
- Für wen ist es gedacht?
- Sinnvoll ist Hyper-Extract für Teams, die bereits einen LLM-Zugang betreiben und wiederkehrend Dokumente zu durchsuchbaren Wissensstrukturen verarbeiten wollen, ohne dafür eigene Extraktionspipelines zu schreiben. Wer eine reine Vektorsuche braucht oder keine GPU beziehungsweise keinen API-Schlüssel bereitstellen kann, sollte beim vorhandenen chunk_rag-Stack bleiben.
- 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. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, 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 Hyper-Extract adressiert
Unstrukturierte Dokumente in eine abfragbare Struktur zu bringen, ist ein wiederkehrender Aufwand: Chunking, Prompt-Design, Schema-Definition, Speicherung, Provenienz. Hyper-Extract bündelt diese Schritte in einem Kommandozeilenwerkzeug. Der Aufruf he parse examples/en/tesla.md -t general/biography_graph -o ./output/ -l en erzeugt aus einer Markdown-Datei eine Wissensstruktur, die anschließend mit he search ./output/ "What are Tesla's major achievements?" abgefragt werden kann.
Zielgruppe sind laut README drei Rollen: Forschende, die Paper in Konzeptgraphen überführen, Finanzanalysten, die Kennzahlen und Personen aus Berichten ziehen, sowie Betreiber lokaler Installationen, die Daten im eigenen Netz halten wollen. Der gemeinsame Nenner ist, dass ein LLM vorhanden ist oder beschafft werden kann. Ohne Modellzugang läuft nichts, denn die Extraktion selbst ist ein LLM-Aufruf.
Die beworbene Besonderheit liegt beim Strukturtyp. Das Repository nennt neun Wissensstrukturen, von einfachen Chunk-Korpora über Listen bis zu Graphen, Hypergraphen und raum-zeitlichen Graphen. Ein Hypergraph erlaubt Kanten mit mehr als zwei Endpunkten, was für Aussagen mit mehreren Beteiligten relevant ist. Ob das im Einzelfall besser trägt als ein normaler Graph, hängt vom Schema der gewählten Vorlage ab.
Wie die Extraktion tatsächlich abläuft
Das Modell ist zweistufig. Zuerst wird ein Template ausgewählt, im Beispiel general/biography_graph. Diese Templates liegen als YAML vor, das Repository spricht von über 80 Stück für Finance, Legal, Medical, TCM, Industry und General. Das Template legt fest, welche Entitätstypen und Beziehungen das LLM suchen soll. Danach übernimmt ein Extraktionsmotor die Arbeit. Hier nennt das README elf oder mehr Engines, darunter chunk_rag als kostenlosen Basiswert, GraphRAG, LightRAG, Hyper-RAG und KG-Gen.
Die Trennung von Template und Engine ist der eigentliche Gestaltungspunkt. Wer ein neues Fachgebiet braucht, schreibt kein Python, sondern ein YAML-Schema. Wer eine andere Extraktionsstrategie braucht, wechselt die Engine. Beides ist unabhängig voneinander.
Der Datenfluss endet nicht beim einmaligen Parsen. Mit he feed ./output/ updated-tesla.md --source tesla.md lassen sich Aktualisierungen unter derselben Quelle nachschieben, wobei das README davon spricht, dass alte Fakten automatisch zurückgerollt werden. he info ./output/ --sources gibt aus, welche Dokumente zu welchem Teil der Struktur beigetragen haben. he remove --document entfernt eine Quelle wieder. Das ist ein Provenienzmodell, kein reiner Batch-Job. Wer Wissensbasen über Monate pflegt, merkt den Unterschied erst, wenn ein Dokument falsch war.
Installation und Provider-Konfiguration
Die Installation erfolgt über uv oder pipx. Das README zeigt uv tool install hyperextract nach der Installation von uv selbst über das Skript von astral.sh. Für die Python-API existiert zusätzlich uv pip install hyperextract. Die Dokumentation nennt Python 3.11 oder neuer als Anforderung.
Danach muss ein Provider konfiguriert werden, und hier liegt die erste Stolperstelle. OpenAI und Alibaba Bailian liefern LLM und Embeddings unter einem Schlüssel, weshalb he config init -p openai -k YOUR_OPENAI_API_KEY beziehungsweise die Bailian-Variante ausreicht. Anthropic und DeepSeek sind laut README reine LLM-Anbieter und müssen mit einem OpenAI-kompatiblen Embedder kombiniert werden. Der dokumentierte Weg dafür sind zwei getrennte Aufrufe: he config llm -p deepseek -k YOUR_DEEPSEEK_API_KEY und he config embedder -p openai -k YOUR_OPENAI_API_KEY.
Für lokale Installationen zeigt das README vLLM mit zwei Endpunkten, einem für das LLM und einem für den Embedder, konfiguriert über he config llm -p vllm -u http://localhost:8000/v1 -k dummy -m Qwen/Qwen3.5-9B. Der API-Schlüssel ist in diesem Fall der Platzhalter dummy. Das ist konsistent mit einem selbst betriebenen Server, der keine Authentifizierung erzwingt. Wer vLLM hinter einen Proxy mit Auth stellt, muss den Schlüssel entsprechend ersetzen.
Für Dokumentformate jenseits von .txt und .md, also PDF, Word, PowerPoint, Excel, HTML und EPUB, ist ein Extra namens ingest nötig: pip install "hyperextract[ingest]". Ohne dieses Extra bleibt die Eingabe auf Text beschränkt.
Was die Kostenangaben im README wert sind
Das README nennt für DeepSeek einen Bereich von etwa 0,001 bis 0,005 US-Dollar pro Seite und bezeichnet den Anbieter als kostengünstigste Option. Diese Zahl ist eine Dokumentationsangabe des Projekts, keine unabhängige Messung. Sie hängt zudem an der Seitenlänge, der Prompt-Größe des jeweiligen Templates und der Anzahl der Durchläufe pro Dokument. Wer ein 200-seitiges PDF mit einem komplexen Hypergraph-Template verarbeitet, sollte nicht erwarten, dass die Obergrenze hält.
Der Kostenvergleich zwischen den Providern ist im README als Entscheidungshilfe angelegt: OpenAI und Bailian bündeln LLM und Embeddings, Anthropic und DeepSeek erfordern zwei Schlüssel und damit zwei Abrechnungen, vLLM kostet kein Geld pro Aufruf, verlangt aber eine GPU. Diese Darstellung ist nachvollziehbar, lässt aber einen Punkt offen. Die Embedding-Kosten skalieren mit der Anzahl der Chunks, nicht mit der Seitenzahl, und dazu macht das README keine Aussage.
Für den lokalen Betrieb nennt das README Qwen3.5-9B in Kombination mit bge-m3. Beide Modelle laufen auf einer Maschine mit ausreichend VRAM, die Größenangabe fehlt in der Dokumentation. Wer die Hardware noch nicht hat, sollte diesen Posten vor der Entscheidung klären, nicht danach.
Grenzen und Fälle, in denen das Werkzeug nicht passt
Die wichtigste Einschränkung ist struktureller Natur: Hyper-Extract ist ein Wrapper um ein Sprachmodell. Die Qualität der Ausgabe ist die Qualität des Modells in Kombination mit dem Template. Bei einem lokalen 9B-Modell und einem dichten Fachschema ist mit anderen Ergebnissen zu rechnen als bei einem großen kommerziellen Modell. Das README diskutiert diese Abhängigkeit nicht, was ein echter Mangel ist, denn die Wahl des Providers ist damit nicht nur eine Kostenfrage, sondern eine Qualitätsfrage.
Zweitens ist die Provenienzfunktion an eine Bedingung geknüpft: Wer he feed ohne korrektes --source aufruft, verliert die Zuordnung, auf der Rollback und Audit beruhen. Die automatische Rücknahme alter Fakten funktioniert nur, wenn die Quelle konsistent benannt wird. Das ist eine Konvention, die das Werkzeug nicht erzwingen kann.
Drittens ist der Lizenzstatus unklar. Die Repository-Metadaten melden NOASSERTION, während das README ein Apache-2.0-Badge trägt. Diese Abweichung sollte vor einer kommerziellen Nutzung geklärt werden, und zwar anhand der LICENSE-Datei, nicht anhand des Badges. Eine rechtliche Bewertung ist hier nicht möglich und auch nicht beabsichtigt.
Schließlich ist die Ausgabe nicht deterministisch. Zwei Läufe über dasselbe Dokument können unterschiedliche Kanten ergeben, weil das LLM Temperature-abhängig arbeitet. Wer reproduzierbare Extraktionen für Audits braucht, muss diesen Punkt selbst absichern.
Wo der Unterschied zu GraphRAG und LightRAG liegt
GraphRAG und LightRAG sind im README als Engines innerhalb von Hyper-Extract gelistet, nicht als Konkurrenzprodukte. Das ist eine bewusste Einordnung: Wer bereits eine dieser Pipelines betreibt, kann sie hier als Backend einhängen und bekommt die CLI, die Provenienzverwaltung und den Obsidian-Export dazu.
Der Unterschied liegt damit weniger im Extraktionsalgorithmus als in der Betriebsschicht. Microsofts GraphRAG liefert eine eigene Pipeline mit Community-Erkennung und Zusammenfassungen pro Cluster, ist aber auf seinen eigenen Ablauf festgelegt. Hyper-Extract setzt darüber eine Vorlagenauswahl, eine Quellenbuchhaltung und einen Export nach Markdown mit [[wikilinks]].
Für Anwender bedeutet das eine Abwägung. Wer die volle Kontrolle über die Pipeline braucht und eigene Nachverarbeitungsschritte einbaut, ist mit einer direkt eingebundenen GraphRAG-Installation besser bedient. Wer dagegen mehrere Dokumente über die Zeit pflegt und wissen will, welches Dokument welche Kante beigesteuert hat, bekommt hier Funktionen, die in den Basispipelines nicht vorgesehen sind. Der Obsidian-Export ist dabei der pragmatischste Teil: Die Ausgabe ist Markdown, also ohne Werkzeug lesbar und versionierbar.
Wartung, Upgrades und Reifegrad
Die Release-Historie ist dicht. Zwischen v0.8.1 am 4. September und v0.9.0 am 6. September 2026 liegen zwei Veröffentlichungen, dazwischen v0.8.2. Die Versionsnummer bleibt unter 1.0, was auf eine noch nicht eingefrorene Schnittstelle hindeutet. Wer die CLI in eine bestehende Pipeline einbaut, sollte damit rechnen, dass sich Kommandos oder Konfigurationsschlüssel zwischen Minor-Versionen ändern können. Das README dokumentiert keine Stabilitätsgarantie.
Der letzte Push liegt auf demselben Datum wie das jüngste Release, das Projekt ist also aktiv. Die Themenliste umfasst unter anderem ai-agents, hypergraph und rag, was die Ausrichtung bestätigt. Ob die Weiterentwicklung anhält, lässt sich aus einem einzelnen Datum nicht ableiten.
Das jüngste Release trägt den Titel Rich Document Ingestion und chunk_rag Baseline. Der kostenlose Basiswert chunk_rag ist damit neu hinzugekommen, vermutlich als Vergleichsmaßstab und als Einstieg ohne API-Kosten. Für Evaluierungen ist das nützlich, weil es eine Untergrenze liefert, gegen die sich teurere Engines messen lassen.
Die Lizenzfrage bleibt offen und ist der einzige Punkt, der vor einem produktiven Einsatz zwingend zu klären ist. Alles andere lässt sich ausprobieren: Der Einstieg über he config init mit einem OpenAI-Schlüssel und ein einzelnes he parse auf einer Beispieldatei zeigt in wenigen Minuten, ob die Ausgabequalität für den eigenen Anwendungsfall reicht.
Redaktionelles Fazit
Sinnvoll ist Hyper-Extract für Teams, die bereits einen LLM-Zugang betreiben und wiederkehrend Dokumente zu durchsuchbaren Wissensstrukturen verarbeiten wollen, ohne dafür eigene Extraktionspipelines zu schreiben. Wer eine reine Vektorsuche braucht oder keine GPU beziehungsweise keinen API-Schlüssel bereitstellen kann, sollte beim vorhandenen chunk_rag-Stack bleiben. Vor dem Einsatz ist zu klären, ob die Lizenzangabe im Repository mit der im README genannten Apache-2.0-Angabe übereinstimmt, und ob die 80+ YAML-Templates das eigene Fachgebiet tatsächlich abdecken.
Community-Notizen