Wann reicht ein KI-Modell?

💡 Kurz gesagt:

• Ein leistungsfähiges General-Purpose-Modell ist oft ein sinnvoller Start. Ein weiteres Modell sollte nur hinzukommen, wenn es auf der realen Arbeitslast Qualität, Kosten, Geschwindigkeit, Datenkontrolle oder Resilienz messbar verbessert.
• Ein Modell heißt nicht, das gesamte System an das Modell abzugeben. Informationsquellen, Geschäftsregeln, Berechtigungen und Transaktionen können in anderen Softwareteilen bleiben.
• Eine einheitliche Produktschnittstelle beweist nicht, dass nur ein Modell dahinter läuft. Architektur soll der Arbeit des Unternehmens folgen, nicht der Zahl der Oberflächen eines Anbieters.

Ein KI-Supportsystem muss eingehende Nachrichten lesen, Anliegen verstehen, Information finden und Antworten vorbereiten. Sie könnten diese Aufgaben auf drei Modelle verteilen: eines klassifiziert, eines schreibt, eines prüft. Auf dem Papier wirkt das fortschrittlich.

Moderne General-Purpose-Modelle können jedoch mehrere Schritte gemeinsam erledigen: Nachricht verstehen, Erstattungswunsch erkennen, Information aus einer bereitgestellten Quelle ziehen und eine Antwort formulieren. Die relevante Frage lautet deshalb: Verbessert ein zweites Modell das System wesentlich, oder entsteht nur eine weitere Komponente, die das Team betreiben muss? Wenn mehrere Modelle bereits sinnvoll sind, folgt erst danach die Frage, welche Anfrage wohin geht. Wann explizite Regeln genügen und wann ein separates Routing-System gerechtfertigt ist, behandle ich im nächsten Artikel.

Ein Modell ist nicht das ganze System

Ein Nutzer kann ein Chatfenster oder eine API sehen, während ein Anbieter verschiedene Modelle im Hintergrund ausführt. In seiner GPT-5-System-Card beschreibt OpenAI ein System mit schnellem Modell für die meisten Fragen, tieferem Reasoning-Modell für schwierige Fragen und einer Routing-Schicht. Das Produkt erscheint einheitlich, der zugrunde liegende Modellpfad nicht.

Für Unternehmen ist die Frage praktischer: Kann ein Modell Kundennachricht und relevantes Dokument verstehen und die Antwort in benötigter Qualität vorbereiten? Im Supportbeispiel kann das reichen. Ein Suchsystem findet Produktinformation, eine API liefert aktuellen Bestellstatus, Software wendet die Erstattungsregel an und ein autorisiertes Zahlungssystem bewegt Geld. Diese Komponenten sind nicht alles KI-Modelle. Mit einem Modell zu beginnen heißt nicht, jede Information, Regel und Befugnis in das Modell zu zwingen.

Ein Generalmodell kann eine starke Basis sein

Erledigt ein Modell eine Gruppe zusammenhängender Aufgaben gut genug, bringt ihre frühe Aufteilung oft wenig. Das Team pflegt einen Ein- und Ausgabe-Vertrag; Modelländerungen haben eine kleinere Evaluierungsfläche. Bei Fehlern gibt es weniger Modellgrenzen und Versionen zu untersuchen.

Mit besseren Generalmodellen kann Arbeit in ein Modell wandern, die früher eine getrennte Komponente brauchte. Eine Studie von 2026 zum Verständnis von Geschäftsdokumenten verglich Vision-Language-Modelle mit OCR-Pipelines. OCR wandelt gescannten Text in maschinenlesbaren Text. Bei einigen getesteten Dokumenten und Modellen lieferte das Vision-Language-Modell direkt vom Seitenbild vergleichbare Ergebnisse ohne diese Stufe.

Das macht OCR nicht obsolet. Handschrift, mehrere Sprachen, schlechte Scans oder Prozesse, bei denen ein Zeichenfehler schwer wiegt, können andere Ergebnisse verlangen. Es zeigt aber, weshalb eine Spezialkomponente nicht nur deshalb Architektur bleiben sollte, weil sie früher nötig war.

Wie ich zuvor erklärt habe, sollte ein KI-Projekt beim Geschäftsergebnis statt bei der Modellauswahl beginnen. Dasselbe gilt für die Modellzahl: Arbeit, Lücke und relevante Verbesserung zuerst definieren.

Wann verdient ein Spezialmodell seinen Platz?

Erhält ein Supportsystem Millionen Nachrichten im Monat und gehören die meisten zu zehn stabilen Kategorien wie Erstattung, Lieferung, Zahlung und Mitgliedschaft, kann ein kleines speziell für diese Klassifikation trainiertes Modell dieselbe Genauigkeit schneller und günstiger liefern. Es hat dann eine enge Verantwortung und einen messbaren Grund zu existieren.

Eine Studie von 2025 über acht Textklassifikationsaufgaben stellte fest, dass kleine aufgabenadaptierte Modelle große Generalmodelle bei einigen Aufgaben erreichen oder übertreffen können; die notwendige Trainingsdatenmenge variierte stark. Das heißt nicht, dass kleine Modelle immer besser sind, sondern dass Spezialisierung bei enger, wiederkehrender Arbeit messbaren Wert schaffen kann.

Bei manchen Problemen ist ein General-Sprachmodell nicht einmal der natürliche Ausgangspunkt: Ein Prognosemodell kann für Umsatzprognosen geeigneter sein, ein Optimierungsverfahren für Lieferwege. Ein Sprachmodell kann Ergebnis oder Ausnahme erklären, sollte aber die zugrunde liegende Berechnung nur verantworten, wenn es die etablierte Methode übertrifft.

Im Artikel über Fine-Tuning trenne ich Information, explizite Regeln und aus Beispielen zu lernende Muster. Ein Spezialmodell ist nicht nützlich, weil ein Unternehmen möchte, dass es seine Dokumente „kennt“, sondern wenn Evidenz zeigt, dass es eine definierte Aufgabe besser erledigt.

Nicht nur die Preisliste beurteilen

Ein günstigeres Modell macht das Gesamtsystem nicht automatisch günstiger. Ein zweites Modell bringt Integration, Evaluierungsbeispiele, Monitoring, Fehlerbehandlung und Versionsmanagement. Müssen Mitarbeitende mehr Fehler korrigieren, verschwindet die Ersparnis aus der Preistabelle schnell.

Ohne Evidenz in mindestens einem dieser Bereiche ist das zusätzliche Modell eher Annahme als Lösung.

Mehr Modelle schaffen mehr Verantwortung

Bei drei Modellen im Support kann das erste falsch klassifizieren, das zweite trotz richtiger Kategorie falsch antworten und das Prüfmodell eine richtige Antwort ablehnen. Bei schlechtem Endergebnis muss das Team Antwort und Übergaben untersuchen. Ein Update eines Modells kann die Beziehung zu den anderen ändern; Eingabeformate, Fehlverhalten und Kostenabwägungen müssen erneut geprüft werden.

Ein weiterer Anbieter kann theoretisch Resilienz verbessern. Ein Fallback, der noch nie reale Anfragen bearbeitet hat, bleibt am Ausfalltag eine ungetestete Unsicherheit. In meinem Artikel über Abhängigkeit von KI-Anbietern argumentiere ich, dass Portabilität nicht nur API-Kompatibilität bedeutet: Die Alternative muss das nötige Geschäftsergebnis erhalten.

Auch Anthropics Leitfaden zu wirksamen Agenten empfiehlt, mit dem einfachsten funktionierenden Ansatz zu beginnen und Komplexität nur zu ergänzen, wenn sie messbaren Wert schafft. Er schreibt keine Modellzahl vor; die Begründungslast liegt beim Team, das Komplexität hinzufügt.

Für Arbeit, die Nachrichten und Dokumente versteht und Antworten vorbereitet, ist ein leistungsfähiges Generalmodell oft ein vernünftiger Start. Ein zweites Modell sollte erst ins System, wenn das Team zeigen kann, welches Problem es löst, was es verbessert und warum der Nutzen die zusätzliche Betriebslast wert ist. Ändert das Entfernen eines Modells das Geschäftsergebnis nicht, sollten Sie fragen, warum es dort ist.

Im vorherigen Artikel erkläre ich, warum Ergebnis und Evidenz vor der Modellarchitektur definiert sein sollten.

Weitere Entscheidungen zu Modellen, Information, Befugnissen und Evaluierung finden Sie im Leitfaden zum Entwurf eines KI-Systems für Ihr Unternehmen.