Scikit-LLM: ZeroShotGPTClassifier als Scikit-Learn-Estimator
Seamlessly integrate LLMs into scikit-learn.
Auf einen Blick
- Was ist das?
- Scikit-LLM verpackt LLM-Aufrufe in die fit/predict-Schnittstelle von scikit-learn. Der Ansatz passt für Prototypen mit wenigen Labels, nicht für Pipelines, die deterministische Vorhersagen oder tragbare Kosten brauchen.
- Für wen ist es gedacht?
- Sinnvoll ist Scikit-LLM für Teams, die bereits scikit-learn nutzen und LLM-Aufrufe ohne eigene Wrapper-Schicht in bestehende Estimator-Code einhängen wollen, etwa für schnelle Zero-Shot-Experimente.
- 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 15 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
Welches Problem Scikit-LLM adressiert
Textklassifikation mit LLMs endet bei den meisten Teams in einer selbstgebauten Schleife: Prompt zusammensetzen, HTTP-Aufruf, Antwort parsen, Labels den ursprünglichen Zeilen zuordnen. Scikit-LLM setzt genau an dieser Stelle an und verpackt den Aufruf in die Estimator-Konvention von scikit-learn. Statt einer eigenen Pipeline-Stufe gibt es eine Klasse mit fit und predict, die sich neben Vektorizer und Klassifikator in eine bestehende Verarbeitungskette einfügen lässt. Das README nennt als Ziel die Integration von Modellen wie ChatGPT in scikit-learn für Textanalyse-Aufgaben und zeigt als Einstieg ein Zero-Shot-Beispiel mit den Labels positive, negative und neutral. Die Zielgruppe sind damit Data-Science-Teams, die scikit-learn schon im Einsatz haben und keine zweite Abstraktionsschicht für Prompt-Aufrufe pflegen wollen. Wer bereits eine eigene LLM-Orchestrierung mit Retry, Caching und Kostenkontrolle betreibt, gewinnt durch den Estimator-Wrapper wenig.
Wie der Estimator an die API kommt: SKLLMConfig
Der Einstieg läuft über zwei Konfigurationsaufrufe, die das README zeigt: SKLLMConfig.set_openai_key mit dem Schlüssel und SKLLMConfig.set_openai_org mit der Organisations-ID. Beide Werte werden global im Modul hinterlegt, nicht pro Instanz übergeben. Das ist bequem für ein Notebook und unangenehm in allem, was mehr als einen Mandanten oder mehr als einen Schlüssel pro Prozess verwalten muss. Wer denselben Prozess für zwei Kunden mit getrennten OpenAI-Konten nutzt, muss die Konfiguration zwischen den Aufrufen umschreiben, und in nebenläufigen Workern ist der letzte set-Aufruf der gültige. Das README dokumentiert keine Umgebungsvariablen und keine Konstruktorparameter für Zugangsdaten. Ob die Bibliothek zusätzlich Umgebungsvariablen liest, lässt sich aus dem vorliegenden Material nicht bestätigen. Wer die Konfiguration in einem Modul auf oberster Ebene setzt, importiert damit einen Seiteneffekt in jeden Test, der dieses Modul lädt.
Der Zero-Shot-Pfad: fit ohne Training
Das README-Beispiel lädt über get_classification_dataset einen Demo-Datensatz und übergibt X und y an fit, bevor predict aufgerufen wird. Bei ZeroShotGPTClassifier ist fit jedoch kein Trainingsschritt im üblichen Sinn. Es gibt keine Gewichte, die angepasst werden, und keine Verlustfunktion. Was das Modell aus y übernimmt, ist die Menge der Labels, die später im Prompt als Auswahl angeboten wird. Der eigentliche Klassifikationsschritt passiert bei predict, wo pro Eingabe ein API-Aufruf an das konfigurierte Modell geht, im Beispiel gpt-4. Daraus folgen zwei Dinge. Erstens skaliert predict linear mit der Anzahl der Zeilen, sowohl in der Laufzeit als auch in den API-Kosten. Zweitens ist das Ergebnis nicht deterministisch im Sinne eines trainierten Klassifikators: Derselbe Text kann bei zwei Aufrufen unterschiedlich zugeordnet werden, abhängig von Modellversion und Sampling. Das README macht dazu keine Aussage über Temperatur oder Seed. Wer eine Fehleranalyse auf Basis stabiler Vorhersagen plant, sollte diesen Punkt vorher in der Dokumentation unter skllm.beastbyte.ai prüfen.
Installation und der erste Aufruf
Die Installation ist ein einzelner Befehl: pip install scikit-llm. Der Importpfad folgt dem Kürzel skllm, nicht dem Paketnamen. Das README-Beispiel importiert get_classification_dataset aus skllm.datasets, SKLLMConfig aus skllm.config und ZeroShotGPTClassifier aus skllm.models.gpt.classification.zero_shot. Diese Pfadtiefe zeigt, dass die GPT-Modelle in einer eigenen Hierarchie unter skllm.models.gpt liegen und innerhalb dieser nach Aufgabe sortiert sind: classification, dann zero_shot. Wer andere Aufgaben sucht, findet sie vermutlich als Geschwisterknoten derselben Ebene, aber das README nennt nur diesen einen Pfad. Das Modell wird als Zeichenkette übergeben, im Beispiel model="gpt-4". Welche Modellnamen gültig sind und ob neben OpenAI weitere Anbieter unterstützt werden, geht aus dem vorliegenden Material nicht hervor. Die Topics im Repository nennen chatgpt, deep-learning, llm, machine-learning, scikit-learn und transformers, was auf mehr als einen Modellpfad hindeutet, aber das ist eine Ableitung aus Metadaten, kein Beleg.
Wo der Ansatz bricht
Der offensichtliche Grenzfall ist die Kostenkontrolle. Ein predict über zehntausend Zeilen bedeutet zehntausend API-Aufrufe. Es gibt im README keinen Hinweis auf Batching, Caching oder eine Möglichkeit, Ergebnisse zwischenzuspeichern. Für einen Prototyp mit hundert Zeilen ist das irrelevant, für einen nächtlichen Batch-Job ist es die dominierende Größe. Der zweite Grenzfall ist die Verfügbarkeit: Fällt die API aus oder greift ein Rate Limit, schlägt predict fehl, und die gesamte Pipeline endet dort. Ob die Bibliothek Wiederholungsversuche implementiert, sagt das Material nicht. Der dritte Grenzfall ist die Datenabgabe. Jeder zu klassifizierende Text verlässt die eigene Infrastruktur und geht an den Anbieter. Für interne Dokumente, Kundendaten oder alles unter Aufsichtsauflagen ist das eine Entscheidung, die vor dem ersten fit geklärt sein muss, nicht danach. Und schließlich: Wenn ohnehin ein feinabgestimmtes Modell für eine feste Klassifikationsaufgabe existiert, ist der Zero-Shot-Weg über einen externen Dienst der teurere und langsamere Pfad.
Abgrenzung zu SetFit und klassischen Pipelines
Der naheliegende Vergleich ist SetFit, das ebenfalls wenige Beispiele pro Klasse nutzt, aber anders vorgeht. SetFit erzeugt aus den vorhandenen Beispielen Kontrastivpaare und trainiert damit einen Satz-Encoder, auf den ein kleiner Klassifikationskopf gesetzt wird. Das Ergebnis ist ein lokales Modell, das nach dem Training ohne API auskommt und bei predict deterministisch antwortet. Scikit-LLM geht den entgegengesetzten Weg: kein Training, dafür ein externer Aufruf pro Vorhersage. Der Unterschied zeigt sich in drei Größen. SetFit braucht Trainingszeit und Beispieldaten pro Klasse, Scikit-LLM braucht nur Labelnamen. SetFit hat fixe Inferenzkosten, Scikit-LLM hat variable pro Zeile. SetFit läuft offline, Scikit-LLM nicht. Für eine Aufgabe mit zwanzig beschrifteten Beispielen pro Klasse und hohem Volumen ist SetFit meist die bessere Wahl; für eine Aufgabe, bei der sich die Labelmenge wöchentlich ändert, ist der Zero-Shot-Ansatz flexibler, weil nur die Label-Liste angepasst werden muss und kein Retraining ansteht. Klassische Pipelines aus TfidfVectorizer und LogisticRegression bleiben für alles geeignet, was mit Stichwörtern oder kurzen Phrasen trennbar ist; sie sind schneller, billiger und reproduzierbar, scheitern aber bei Bedeutungsnuancen, die kein gemeinsames Vokabular haben.
Wartung, Versionen und Lizenz
Die Release-Historie zeigt v1.4.3 im Januar 2026, v1.4.2 im September 2025 und v1.4.1 im November 2024. Zwischen v1.4.1 und v1.4.2 liegen rund zehn Monate, zwischen v1.4.2 und v1.4.3 etwa vier. Das Repository ist nicht archiviert, der letzte Push datiert auf September 2026. Wer die Bibliothek produktiv einsetzt, sollte die Upgrade-Kosten nicht unterschätzen: Ändert der Anbieter sein Modellverhalten, ändert sich die Ausgabequalität, ohne dass sich die Version von scikit-llm bewegt. Ein Upgrade der Bibliothek kann zusätzlich Modellnamen oder Prompt-Formate anpassen. Beides zusammen bedeutet, dass ein Testsuite-Lauf nach jedem Upgrade und nach jeder Modelländerung nötig ist, wenn die Ergebnisse stabil bleiben sollen. Die Lizenz ist MIT, was die Nutzung in kommerziellen Projekten erlaubt und die Weitergabe des Quellcodes nicht erzwingt. Das betrifft nur den Code von Scikit-LLM selbst. Die Nutzung der angebundenen Modelle unterliegt den Bedingungen des jeweiligen Anbieters, und dazu macht das Repository keine Aussage. Wer die Bibliothek in einem Produkt einsetzt, muss die Anbieterbedingungen separat prüfen; das ist keine Rechtsberatung, sondern ein Hinweis auf die zwei getrennten Regelwerke.
Redaktionelles Fazit
Sinnvoll ist Scikit-LLM für Teams, die bereits scikit-learn nutzen und LLM-Aufrufe ohne eigene Wrapper-Schicht in bestehende Estimator-Code einhängen wollen, etwa für schnelle Zero-Shot-Experimente. Wer reproduzierbare, offline lauffähige oder kostenstabile Pipelines braucht, sollte es nicht einsetzen: Jede fit- und predict-Ausführung hängt an einer externen API, und die Zero-Shot-Klasse lernt laut README-Beispiel keine Gewichte, sondern nutzt die Label-Liste als Klassenkatalog. Vor dem Einsatz zu prüfen sind die Dokumentation unter skllm.beastbyte.ai, die tatsächlich unterstützten Modellnamen und Anbieter sowie das Verhalten von SKLLMConfig bei mehreren Prozessen. Wer diese drei Punkte nicht vorher klärt, debuggt später API-Fehler statt Modelle.
Community-Notizen