Die Frage ist nicht mehr, ob LLMs besser sind als traditionelle NLP-Modelle. Die nützliche Frage ist: Welcher Teil meiner Pipeline braucht welchen Ansatz? Diese Checkliste richtet sich an Teams, die bereits ein Produkt in Produktion haben und schwanken, ob sie ihren klassischen Stack (spaCy, scikit-learn, Regex, CRF, statische Embeddings) durch ein generatives Modell ersetzen oder beides beibehalten sollen.
Jeder Punkt ist eine überprüfbare Entscheidung, keine Meinung. Wenn Sie weniger als die Hälfte ankreuzen, müssen Sie wahrscheinlich noch nicht migrieren.
1. Definieren Sie die Aufgabe, bevor Sie die Technologie wählen
1.1 Handelt es sich um geschlossene Extraktion oder offenes Verständnis?
Wenn Sie Felder mit einem festen Schema extrahieren müssen (Daten, Beträge, Handelsregisternummern, Entitäten einer bestimmten Domäne), gewinnt ein traditionelles überwachtes Modell mit eigener Annotation meist an Präzision und Kosten. LLMs glänzen, wenn sich das Schema jede Woche ändert oder wenn die Ausgabe Schlussfolgerungen über den Text erfordert.
1.2 Benötigen Sie exakte Reproduzierbarkeit?
Ein logistischer Regressionsklassifikator auf TF-IDF liefert bei derselben Eingabe dieselbe Vorhersage. Ein LLM mit Temperatur größer als null nicht. Wenn Ihr Produkt Audit, regulatorische Compliance oder Scoring ist, wiegt die exakte Bestimmtheit mehr als die Flüssigkeit.
1.3 Gibt es eine Referenzmetrik?
Bevor Sie irgendetwas ändern, legen Sie eine Baseline fest: F1 pro Klasse auf einem eingefrorenen Testset. Laut Dokumentation von Anbietern klassischer NLP-Verfahren erreichen lineare Modelle bei Textklassifikationsaufgaben mit klar definierten Kategorien und Tausenden annotierten Beispielen häufig Werte nahe denen großer Modelle – zu einem Bruchteil der Kosten. Wenn Sie diese Baseline nicht haben, können Sie die Migration nicht rechtfertigen.
2. Prüfen Sie die realen Kosten, nicht die der Demo
2.1 Latenz pro Anfrage
Ein klassisches Modell auf der CPU antwortet in Millisekunden. Ein LLM in der Cloud fügt Netzwerk- und Generierungslatenz hinzu. Bei einer internen Suche oder Autovervollständigung ist dieser Unterschied für den Nutzer sichtbar. Das funktioniert nicht für X: Verwenden Sie kein LLM im kritischen Pfad einer Schnittstelle, die eine Antwort unter 200 ms erfordert, es sei denn, Sie haben aggressives Caching oder ein kleines lokales Modell.
2.2 Kosten pro Volumen
Rechnen Sie mit Ihrem realen Traffic: durchschnittliche Eingabe-Tokens × Anfragen × Modellpreis. Ein einmal trainiertes klassisches Modell kostet bei 10.000 Inferenzen praktisch dasselbe wie bei 10 Millionen. Viele Teams entdecken in der Produktion, dass 80 % ihrer Aufrufe triviale Aufgaben sind, die ein klassisches Modell genauso gelöst hätte.
2.3 Kosten der Pflege der Annotation
Das klassische Modell erfordert das Annotieren von Daten. Das LLM erfordert das Verfassen von Prompts, systematisches Evaluieren und die Überwachung von Versionsänderungen des Anbieters. Beide haben menschliche Kosten; wählen Sie die, die Ihr Team tragen kann.
3. Überprüfen Sie die Qualität mit eigenen Daten
3.1 Testen Sie in der Domäne, nicht auf öffentlichen Benchmarks
Ein LLM kann bei einem allgemeinen Benchmark hoch punkten und bei Ihrem Jargon scheitern. Ein konkretes Beispiel, das häufig in Support-Teams auftritt: Ein mit historischen Tickets trainiertes klassisches Modell identifizierte die Kategorie der Rechnungsbeschwerde korrekt, weil es die internen Abkürzungen des Unternehmens gelernt hatte; das allgemeine LLM, ohne Beispiele dieser Abkürzungen im Prompt, verwechselte sie mit Produktnamen. Die Lösung bestand nicht darin, das LLM zu verwerfen, sondern einen vorgelagerten Normalisierungsschritt mit dem klassischen Modell hinzuzufügen.
3.2 Evaluieren Sie mit Stratifizierung nach Schwierigkeit
Teilen Sie Ihren Test in leichte, mehrdeutige und adversariale Fälle auf. Es ist üblich, dass das LLM bei mehrdeutigen gewinnt und bei leichten gleichzieht oder verliert. Wenn Ihre reale Verteilung überwiegend leicht ist, täuscht der Durchschnitt.
3.3 Messen Sie Halluzination, nicht nur Treffer
Bei der Extraktion ist ein erfundenes Feld schlimmer als ein leeres Feld. Klassische Modelle scheitern, indem sie das wahrscheinlichste Label zurückgeben; LLMs können den Wert erfinden. Definieren Sie eine Metrik für korrekte Enthaltung.
4. Überprüfen Sie Datenschutz- und Deployment-Anforderungen
4.1 Dürfen die Daten Ihre Infrastruktur verlassen?
Wenn der Text personenbezogene Daten, Verträge oder medizinische Informationen enthält, erfordert das Senden an eine externe API eine rechtliche Prüfung. Ein lokales klassisches Modell eliminiert diesen Vektor vollständig. Selbst gehostete LLMs existieren, aber sie verändern das Kostenprofil: Sie brauchen eine GPU und jemanden, der sie wartet.
4.2 Müssen Sie offline funktionieren?
Feldgeräte, Kioske, industrielle Umgebungen: Das eingebettete klassische Modell bleibt die pragmatische Option. Ein kleines quantisiertes LLM kann lokal laufen, aber seine Qualität bei komplexen Aufgaben sinkt und muss Aufgabe für Aufgabe validiert werden.
5. Prüfen Sie, ob das Problem in den Daten liegt, nicht im Modell
5.1 Volumen verfügbarer Labels
Mit weniger als einigen Hundert Beispielen pro Klasse stößt das klassische Modell an seine Grenzen und das LLM mit Few-Shot startet mit Vorteil. Bei Zehntausenden schrumpft der Vorteil und die Kosten pro Inferenz werden zum entscheidenden Faktor.
5.2 Domänendrift
Wenn sich Ihr Vokabular schnell ändert (neue Produkte, neuer Jargon), verschlechtert sich das klassische Modell und muss neu trainiert werden. Das LLM absorbiert die Veränderung besser ohne Neutraining, führt aber Variabilität ein. Ein robustes Muster ist, das LLM zum Generieren neuer Labels und das klassische Modell für die Bereitstellung im Maßstab zu verwenden.
5.3 Sprachen und Varietäten
Mehrsprachige klassische Modelle existieren, aber ihre Leistung bei dialektalen Varietäten oder informellem Text ist unregelmäßig. LLMs generalisieren oft besser bei ressourcenschwachen Sprachen. Überprüfen Sie dennoch mit realen Stichproben: Gehen Sie nicht davon aus, dass ein großes Modell Ihre lokale Variante besser versteht als ein mit Ihren Daten trainiertes Modell.
6. Entscheiden Sie sich für die hybride Architektur statt für die Substitution
6.1 Zweistufiges Muster
Klassisches Modell zum Filtern und Klassifizieren des hohen Volumens; LLM nur für die Fälle, die einen Konfidenzschwellenwert überschreiten. Das senkt die Kosten und erhält die Qualität dort, wo sie zählt.
6.2 Muster der Datengenerierung
Verwenden Sie das LLM, um einen anfänglichen Stapel zu labeln, prüfen Sie eine menschliche Stichprobe und trainieren Sie ein klassisches Modell mit diesen Labels. Dies ist eine in der Praxis dokumentierte Methode, um die Annotationskosten zu senken, ohne auf einen deterministischen Server zu verzichten.
6.3 Fallback-Muster
Wenn das LLM ausfällt oder eine Ausgabe zurückgibt, die das Schema nicht validiert, greifen Sie auf das klassische Modell zurück. Lassen Sie niemals zu, dass ein Ausfall der externen API Ihren gesamten Ablauf unterbricht.
7. Abschließende Checkliste, bevor Sie die Produktion anfassen
- ☐ Ich habe eine Baseline, gemessen mit meinem eigenen Test, nicht mit öffentlichen Benchmarks.
- ☐ Ich habe Kosten und Latenz mit meinem realen Volumen berechnet, nicht mit einer Demo.
- ☐ Ich weiß, welche Aufgaben Determinismus erfordern und welche Variabilität tolerieren.
- ☐ Ich habe Datenschutz und Datenstandort mit den zuständigen Stellen geprüft.
- ☐ Ich habe eine Metrik für Enthaltung, nicht nur für Treffer.
- ☐ Es gibt einen Fallback-Plan, falls der Anbieter das Modell ändert.
- ☐ Ich habe den hybriden Ansatz getestet, bevor ich vollständig ersetzt habe.
- ☐ Ich habe dokumentiert, was ich nicht weiß: Grenzen des Modells in meiner Domäne und nicht abgedeckte Fälle.
Keiner dieser Punkte garantiert Ergebnisse. Die Evidenz aus der Branche deutet darauf hin, dass Teams, die beide Ansätze beibehalten, ein besseres Verhältnis von Qualität zu Kosten erzielen als diejenigen, die alles auf eine einzige Technologie setzen, aber jede Domäne hat ihre Ausnahmen, und diese sollten gemessen werden.