Die Frage ist nicht mehr, ob der Einsatz von künstlicher Intelligenz sinnvoll ist, sondern welcher Modelltyp zu welchem Problem passt. In den letzten zwei Jahren habe ich technische Teams gesehen, die Budget in APIs generativer Modelle investiert haben für Aufgaben, bei denen ein maßgeschneiderter trainierter Klassifikator einen Bruchteil gekostet und mehr Vorhersagbarkeit geboten hätte. Und auch das Gegenteil: der Versuch, ein Problem der Informationsextraktion aus natürlicher Sprache mit Regeln und Entscheidungsbäumen zu lösen, das ein LLM an einem Arbeitstag erledigt. Dieser Vergleich richtet sich an alle, die zwischen beiden Optionen mit realem Budget und echten Fristen entscheiden müssen.
Was ein LLM wirklich von einem traditionellen Modell unterscheidet
Ein traditionelles Modell (logistische Regression, Random Forest, Gradient Boosting, SVM, spezifische Faltungsnetzwerke) wird für eine konkrete Aufgabe mit einem gelabelten Datensatz trainiert und liefert begrenzte Ausgaben: eine Klasse, eine Zahl, eine Wahrscheinlichkeit. Ein LLM ist ein Sprachmodell, das auf massiven Korpora vortrainiert wurde, das nächste Token vorhersagt und von dort aus auf Aufgaben generalisiert, für die es nicht explizit angepasst wurde.
Der wichtigste praktische Unterschied ist nicht die Architektur, sondern der Nutzungsvertrag. Bei einem klassischen Modell weiß man genau, welche Eingabe es erwartet und welchen Ausgabebereich es liefert. Bei einem LLM ist die Eingabe freier Text und die Ausgabe freier Text, was den Engineering-Aufwand vom Training hin zum Prompt-Design, zur Validierung der Ausgaben und zur kontinuierlichen Evaluierung verlagert.
Kosten: nicht nur der Preis pro Token
Die Kosten eines LLM werden pro Eingabe- und Ausgabe-Token gemessen und skalieren mit der Nutzung. Bei einem traditionellen Modell konzentrieren sie sich auf die Phase des Labelings und Trainings, danach ist die Inferenz günstig und lokal. In einem realen Fall der Klassifizierung von Support-Tickets in fünf Kategorien mit Zehntausenden Tickets pro Monat kostet die Inferenz eines kleinen angepassten Modells auf eigener Infrastruktur Cents pro tausend Anfragen, während der Aufruf eines großen LLM für jedes Ticket die Ausgaben vervielfacht und Netzwerklatenz hinzufügt. Bei hohem Volumen und stabiler Aufgabe gewinnt das klassische Modell meist bei den Gesamtkosten.
Daten: der Engpass verschiebt sich
Ein traditionelles Modell erfordert qualitativ hochwertige gelabelte Daten. Wenn man sie nicht hat, stockt das Projekt. Ein LLM erlaubt einen Start ohne Labels, aber man braucht Evaluierungsbeispiele, um zu wissen, ob es richtig liegt. In der Praxis beginnen viele Teams mit einem LLM zum Prototyping, generieren damit Labels und trainieren dann ein klassisches Modell mit diesen von Menschen überprüften Labels. Diese Destillationsstrategie funktioniert gut, wenn die Domäne eng begrenzt ist; sie scheitert, wenn die Klassen mehrdeutig sind oder die Sprache sehr variabel ist.
Szenarien, in denen jede Option gewinnt
Wann ein traditionelles Modell die richtige Wahl ist
- Strukturierte tabellarische Daten: Risikoscoring, Churn-Vorhersage, Betrugserkennung mit numerischen und kategorialen Variablen. Gradient-Boosting-Modelle bleiben in diesen Fällen laut der Dokumentation der wichtigsten Branchenbibliotheken die Referenz.
- Strenge Latenzanforderungen: wenn man Antworten in Millisekunden benötigt, ohne von einer externen API abhängig zu sein, ist ein kleines lokales Modell zuverlässiger.
- Regulatorische Auditierbarkeit: in Branchen mit der Pflicht, Entscheidungen zu erklären, ist ein Modell mit dokumentierter Variablenwichtigkeit leichter zu verteidigen als die Ausgabe eines LLM.
- Repetitive und klar definierte Aufgaben: Klassifizierung von Produktbildern, Anomalieerkennung in Zeitreihen, Sentiment-Labeling in einer sehr konkreten Domäne.
Wann das LLM etwas bietet, das das klassische Modell nicht kann
- Informationsextraktion aus unstrukturiertem Text: E-Mails, Verträge oder Berichte in strukturierte Felder umwandeln, ohne vorab ein starres Schema zu definieren.
- Aufgaben mit wechselnden Anweisungen: mit einem anderen Ton zusammenfassen, Ausgaben umformatieren oder Antworten an einen variierenden Kontext anpassen, ohne neu zu trainieren.
- Generierung und Transformation von Inhalten: unterstütztes Verfassen, Übersetzung mit Nuancen, Umschreiben.
- Schnelles Prototyping: validieren, ob ein Anwendungsfall Wert hat, bevor in gelabelte Daten investiert wird.
Der Fehler, den ich immer wieder sehe: das LLM als Datenbank behandeln
Ein Muster, das immer wieder auftaucht, ist, das Modell zu bitten, sich Geschäftsinformationen (Preise, Richtlinien, Katalog) zu merken, und darauf zu vertrauen, dass es sie korrekt zurückgibt. Das tut es nicht zuverlässig: es halluziniert plausible, aber falsche Daten. Die Lösung ist nicht, das Modell zu wechseln, sondern eine Informationsabfrage (RAG) mit einer konsultierbaren Wahrheitsquelle hinzuzufügen. Und selbst dann bleibt die Validierung der endgültigen Antwort für sensible Daten erforderlich.
Ein weiterer häufiger Fehler: ein LLM mit zehn manuellen Beispielen evaluieren und es für gut befinden. Ohne einen repräsentativen und wiederholbaren Evaluierungsdatensatz gibt es keine Möglichkeit, Regressionen zu erkennen, wenn man die Modellversion ändert oder den Prompt anpasst. Laut der Dokumentation der wichtigsten Anbieter werden die Versionen häufig aktualisiert und das Verhalten kann sich ohne klare Ankündigung ändern.
Praktischer Vergleich nach Entscheidungskriterien
| Kriterium | Traditionelles Modell | LLM |
|---|---|---|
| Für den Start benötigte Daten | Gelabelt und repräsentativ | Keine fürs Prototyping; Beispiele zur Evaluierung |
| Inferenzkosten | Niedrig und vorhersagbar | Variabel je nach Tokens und Anbieter |
| Latenz | Sehr niedrig lokal | Abhängig von Netzwerk und Modellgröße |
| Erklärbarkeit | Hoch mit den geeigneten Techniken | Begrenzt; die Argumentationskette ist nicht immer zuverlässig |
| Anpassung an neue Aufgaben | Erfordert Neutraining | Änderung der Anweisungen reicht meist aus |
| Robustheit bei seltenen Eingaben | Verschlechtert sich vorhersagbar | Kann erfinden oder abschweifen |
Hybride Architekturen: was in der Praxis wirklich funktioniert
In den meisten ausgereiften Projekten besteht die Antwort nicht darin, eines der beiden zu wählen, sondern sie zu kombinieren. Ein übliches Muster: ein klassisches Modell filtert und klassifiziert den Großteil des Volumens (zum Beispiel Trennung dringender von informativen Anfragen), und nur die mehrdeutigen oder komplexen Fälle gehen an ein LLM, das Informationen verfasst oder extrahiert. Das senkt die Kosten, hält die Latenz kontrolliert und reserviert die Kapazität des generativen Modells für die Bereiche, in denen es Mehrwert bringt.
Ein weiteres Muster: das LLM nutzen, um synthetische Trainingsdaten zu generieren oder in großem Umfang zu labeln, und danach ein klassisches Modell mit menschlicher Überprüfung trainieren. Es funktioniert gut in geschlossenen Domänen; es empfiehlt sich, eine Stichprobe zu prüfen, um vom automatischen Labeling geerbte Verzerrungen zu erkennen.
Grenzen, die man vor dem Start akzeptieren sollte
Keine der beiden Optionen löst Probleme schlecht definierter Daten. Wenn die Labels inkonsistent sind, lernt das klassische Modell die Inkonsistenz und das LLM reproduziert sie mit größerer Sicherheit. Es gibt auch in keinem der beiden Fälle eine Garantie auf hundertprozentige Genauigkeit: jedes System im Produktivbetrieb benötigt Monitoring, Konfidenzschwellen und einen Eskalationsweg zur menschlichen Überprüfung.
LLMs haben zudem Kontextgrenzen, steigende Kosten mit der Eingabelänge und Abhängigkeit von externen Anbietern, wenn sie nicht lokal bereitgestellt werden. Traditionelle Modelle hingegen generalisieren nicht außerhalb der Verteilung, mit der sie trainiert wurden: eine Änderung im Format der Eingabedaten kann die Leistung verschlechtern, ohne dass ein Alarm ausgelöst wird.
Wie man in der Praxis entscheidet
Eine Abfolge, die ich meist empfehle: zuerst die Erfolgsmetrik und das erwartete Volumen definieren; dann prüfen, ob eine gelabelte Datenquelle existiert oder aufgebaut werden kann; wenn es sich um eine Aufgabe der natürlichen Sprache handelt und keine Daten vorliegen, mit einem LLM prototypen, um den Wert zu validieren; wenn das Volumen hoch und die Aufgabe stabil ist, prüfen, ob ein klassisches Modell mit den generierten Daten trainiert werden kann; und in allen Fällen einen Evaluierungsdatensatz aufbauen, bevor man in Produktion geht. Die Entscheidung zwischen LLM und traditionellem Modell ist nicht ideologisch: sie hängt vom Volumen, der Latenz, der geforderten Erklärbarkeit und der Datenverfügbarkeit ab. Seine Meinung zu ändern, wenn die Zahlen es rechtfertigen, gehört zur Arbeit.