spacy-llm: LLM-Prompts als Pipeline-Komponente in spaCy
🦙 Integrating LLMs into structured NLP pipelines
Auf einen Blick
- Was ist das?
- spacy-llm verpackt Prompting in eine serialisierbare spaCy-Komponente mit Task- und Modul-Registries. Das lohnt sich für Prototypen ohne Trainingsdaten, ist aber laut README ausdrücklich experimentell und kein Ersatz für überwachtes Lernen in der Produktion.
- Für wen ist es gedacht?
- spacy-llm passt zu Teams, die einen Prototyp oder eine Pipeline mit gemischten Komponenten brauchen und dafür bereits spaCy einsetzen. Wer ein stabiles Interface über Minor-Updates hinweg benötigt oder komplett ohne externen API-Aufruf arbeiten will, sollte vorher prüfen, ob eine überwachte Komponente nicht der einfachere Weg ist.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 173 Tagen.
- 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
Welche Lücke spacy-llm in einer spaCy-Pipeline schließt
spaCy deckt Tokenisierung, Tagging, Parsing und benannte Entitäten mit Komponenten ab, die auf überwachtem Lernen oder Regeln beruhen. Für eine neue Aufgabe braucht man dafür üblicherweise einige hundert bis einige tausend annotierte Beispiele. Genau an dieser Stelle setzt spacy-llm an: Das README beschreibt das Paket als Weg, LLM-Prompts in eine spaCy-Pipeline einzuhängen, ohne Trainingsdaten. Die Zielgruppe sind damit weniger Teams, die ein fertiges Modell ausrollen, sondern solche, die eine Aufgabe erst einmal überhaupt lösen wollen, um zu sehen, ob Prompting die richtige Formulierung findet.
Interessanter ist die zweite Zielgruppe. Das README argumentiert explizit, dass ein Produktionssystem nicht vollständig auf LLMs setzen muss. Eine günstige Textklassifikation kann die Texte vorfiltern, die anschließend zusammengefasst werden, und ein regelbasiertes Verfahren kann die Zusammenfassung gegenprüfen. Solche Vor- und Nachstufen sind der eigentliche Grund, warum die Anbindung an spaCy sinnvoll ist und nicht nur ein Wrapper um eine API. Wer ohnehin schon eine spaCy-Pipeline betreibt, bekommt die LLM-Komponente als weiteren Eintrag in derselben Verarbeitungskette.
Task, Modell und Registry: der eigentliche Mechanismus
Das Paket besteht aus zwei beweglichen Teilen. Ein Task beschreibt, wie ein Prompt aus dem Doc gebaut und wie die Antwort zurück in Annotationen geparst wird. Ein Modell beschreibt, wohin der Prompt geht und wie die Antwort zurückkommt. Beide werden über spaCys Registry registriert, was bedeutet, dass eigene Prompting-, Parsing- und Modellfunktionen nach demselben Muster eingehängt werden können wie die mitgelieferten. Das README verweist für ein Beispiel auf einen Abschnitt der Onlinedokumentation.
Aus Nutzersicht ist das der entscheidende Punkt: Die Komponente selbst kennt weder OpenAI noch Hugging Face. Sie kennt nur Task und Modell. Die Kopplung an einen Anbieter steckt in der Modellkonfiguration, nicht in der Pipeline. Das erklärt auch, warum das README eine so breite Anbieterliste führt: OpenAI, Cohere, Anthropic, Google PaLM und Microsoft Azure AI über deren APIs, dazu lokal gehostete Modelle von Hugging Face wie Falcon, Dolly, Llama 2, OpenLLaMA, StableLM und Mistral. Zusätzlich lassen sich laut README alle LangChain-Modelle verwenden, da eine Integration mit LangChain besteht.
Mitgeliefert werden Tasks für Named Entity Recognition, Textklassifikation, Lemmatisierung, Beziehungsextraktion, Sentimentanalyse, Span-Kategorisierung, Zusammenfassung, Entity Linking, Übersetzung und die rohe Prompt-Ausführung. Semantic Role Labeling ist als kommend vermerkt, also noch nicht verfügbar. Wer eine dieser Aufgaben braucht, muss nur die Labels und das Modell konfigurieren. Wer eine andere braucht, schreibt eine eigene registrierte Funktion.
Map-Reduce für Prompts, die nicht ins Kontextfenster passen
Ein einzelner Prompt kann länger sein als das Kontextfenster des Modells. Das README nennt dafür einen Map-Reduce-Ansatz: Der Task zerlegt den zu langen Prompt in Teile, führt sie einzeln aus und führt die Ergebnisse anschließend wieder zusammen. Das ist kein Detail am Rand, sondern eine der wenigen Stellen, an denen das Paket echte Pipeline-Logik beisteuert statt nur einen API-Aufruf zu verpacken.
Die Grenze liegt in der Zusammenführung. Beim Zusammenfassen lässt sich eine Liste von Teilergebnissen noch plausibel verschmelzen. Bei Aufgaben mit Positionen im Text, etwa Entitäten oder Spans, muss die Fusionslogik die Verschiebungen zwischen den Teilen korrekt behandeln, sonst landen Annotationen an der falschen Stelle. Das README beschreibt den Ansatz, geht auf diese Fehlerquelle aber nicht ein. Wer Map-Reduce für eine extrahierende Aufgabe einsetzt, sollte die Offsets an einigen selbst konstruierten Beispielen prüfen, bevor er sich auf die Ergebnisse verlässt.
Installation und der kürzeste lauffähige Aufruf
Installiert wird in derselben virtuellen Umgebung, in der spaCy bereits liegt. Das README nennt einen Befehl:
python -m pip install spacy-llm
Für einen ersten Test in Python genügt ein leeres Sprachmodell. Das README zeigt für die Textklassifikation ab Version 0.5.0 diesen Ablauf: nlp = spacy.blank("en") anlegen, dann nlp.add_pipe("llm_textcat"), anschließend llm.add_label("INSULT") und llm.add_label("COMPLIMENT"), und schließlich doc = nlp("You look gorgeous!"). Die Ausgabe steht in doc.cats. Laut README verwendet die Factory llm_textcat die aktuelle Version des eingebauten Textcat-Tasks und das Standardmodell GPT-3-5 von OpenAI.
Daraus folgen zwei Dinge, die man vorher wissen sollte. Erstens braucht dieser Aufruf einen API-Schlüssel, der als Umgebungsvariable gesetzt ist; das README verweist für Hintergründe auf den Abschnitt zu API keys in der Dokumentation. Zweitens ist die Auswahl des Standardmodells eine Bequemlichkeit für Experimente und keine Empfehlung für den Dauerbetrieb. Sobald die Aufgabe feststeht, gehört das Modell explizit konfiguriert.
Für mehr Kontrolle verweist das README auf spaCys Config-System, in dem die Parameter der llm-Pipeline festgehalten werden. Das ist der Weg, der zur Serialisierbarkeit der Komponente passt: Die Konfiguration beschreibt Task und Modell, die Pipeline bleibt als Datei reproduzierbar.
Warum das Paket selbst vor dem Produktionseinsatz warnt
Das README enthält einen Warnhinweis, den man nicht überlesen sollte: Das Paket sei weiterhin experimentell, und es sei möglich, dass Änderungen am Interface in Minor-Versionen brechend wirken. Das ist keine Floskel, sondern eine Aussage über die Versionspolitik. Wer spacy-llm einsetzt, sollte die Version festnageln und Upgrades als eigene Aufgabe behandeln, nicht als Nebenprodukt eines Dependency-Updates.
Die Release-Historie stützt diese Einschätzung. Version 0.7.4 brachte Unterstützung für Python 3.14, eine Migration auf Pydantic v2 und aktualisierte Abhängigkeiten. Version 0.7.3 sandboxte Jinja, um Codeausführung aus nicht vertrauenswürdigen Konfigurationen zu verhindern. Beides sind Änderungen, die eine bestehende Konfiguration oder eine bestehende Umgebung treffen können. Die Jinja-Sandbox ist dabei ein Sicherheitsfix, der zeigt, dass Konfigurationsdateien in diesem Paket ausführbaren Charakter haben können. Wer Konfigurationen von außerhalb bezieht, sollte diese Grenze kennen.
Der zweite Kostenpunkt ist struktureller Natur. Jeder Aufruf einer LLM-gestützten Komponente geht an einen externen Dienst oder an ein lokal gehostetes Modell. Das bedeutet Latenz und, bei den API-Anbietern, laufende Kosten pro Dokument. Eine Pipeline, die auf einem großen Korpus läuft, verhält sich damit grundlegend anders als eine, die ein trainiertes Modell auf derselben Maschine ausführt. Das README benennt diesen Gegensatz selbst: Effizienz, Zuverlässigkeit und Kontrolle seien beim überwachten Lernen besser, und die Genauigkeit bei wohldefiniertem Output in der Regel ebenfalls.
Wann eine trainierte Komponente die bessere Wahl bleibt
Das README ist an dieser Stelle ungewöhnlich deutlich. Für Aufgaben mit klar definiertem Output sei ein Transformer, der bequem auf einer einzelnen GPU läuft, wahrscheinlich die bessere Wahl. Mit einigen hundert bis einigen tausend Beispiele trainieren lasse sich das Verhalten exakt festlegen. Der Vorteil liegt nicht nur in der Genauigkeit, sondern in der Vorhersagbarkeit: Ein trainiertes Modell liefert für dieselbe Eingabe dieselbe Ausgabe, ein Prompt nicht zwangsläufig.
Daraus ergibt sich die Grenze des Werkzeugs. Wenn die Ausgabe einer festen Menge von Labels oder Span-Typen folgen muss und die Beispiele vorhanden sind, ist spacy-llm der Umweg. Ebenso, wenn keine externen Aufrufe erlaubt sind oder die Latenz pro Dokument gedeckelt ist. Die Stärke des Pakets liegt in der Erkundung und in den Randfällen, in denen sich eine Aufgabe nicht sauber als festes Schema formulieren lässt, etwa wenn aus mehreren Dokumenten eine nuancierte Zusammenfassung entstehen soll. Das README nennt genau das als Fall, in dem ein größeres Modell gerechtfertigt ist.
Der praktische Nutzen liegt also weniger im Endzustand als im Übergang. Man startet mit Prompt-basierten Komponenten, mischt andere Ansätze dazu und ersetzt später einzelne Teile, sobald genug annotierte Daten vorliegen. Diese Reihenfolge ist der eigentliche Vorschlag des Pakets, und sie ist nur dann sinnvoll, wenn die Pipeline von Anfang an so aufgebaut ist, dass sich einzelne Komponenten austauschen lassen.
Lizenz und Instandhaltung
Das Repository steht unter der MIT-Lizenz. Das ist eine permissive Lizenz ohne Copyleft-Wirkung; sie erlaubt Weitergabe und Änderung, verlangt aber, dass der Lizenztext und der Urheberrechtshinweis erhalten bleiben. Für die Nutzung in einem kommerziellen Produkt stellt die Lizenz des Pakets damit keine Hürde dar. Das gilt ausdrücklich nicht für die Modelle und Dienste, die über die Modellkonfiguration angebunden werden: Deren Bedingungen hängen vom jeweiligen Anbieter ab und sind eine separate Prüfung. Rechtsberatung ist das hier nicht.
Der Wartungsaufwand liegt weniger im Paket als in seinem Umfeld. Die letzte Veröffentlichung zum Zeitpunkt dieser Betrachtung ist v0.7.4 vom März 2026, davor v0.7.3 im Januar 2025 und v0.7.2 im Mai 2024. Die Abstände sind unregelmäßig, und die Versionsnummern bleiben im 0.x-Bereich. Zusammen mit dem Hinweis auf mögliche brechende Änderungen in Minor-Versionen bedeutet das: Ein Upgrade ist ein eigener Arbeitsschritt mit eigener Prüfung, nicht ein Routinevorgang. Wer die Version in einer Anforderungsdatei festhält und die Konfiguration versioniert, hat diesen Schritt unter Kontrolle.
Redaktionelles Fazit
spacy-llm passt zu Teams, die einen Prototyp oder eine Pipeline mit gemischten Komponenten brauchen und dafür bereits spaCy einsetzen. Wer ein stabiles Interface über Minor-Updates hinweg benötigt oder komplett ohne externen API-Aufruf arbeiten will, sollte vorher prüfen, ob eine überwachte Komponente nicht der einfachere Weg ist. Vor dem ersten produktiven Einsatz würde ich konkret verifizieren, ob die Task-Ausgabe für die eigene Eingabe überhaupt sauber parst, indem ich den Task über nlp.add_pipe registriere und die geparsten Annotationen an einigen Beispielen mit erwarteten Werten vergleiche.
Community-Notizen