Das ist kein Einzelfall und kein Zufall. Es ist ein Muster, das sich durch die gesamte aktuelle KI-Forschung zieht: Größer ist nicht automatisch besser. Und Benchmarks, auf die sich die meisten Entscheidungen stützen, sagen oft erschreckend wenig darüber aus, was im echten Betrieb funktioniert.

Das Benchmark-Problem: Was auf dem Papier gut aussieht, scheitert im Alltag

Kili Technology hat in einer aktuellen Analyse das Ausmaß dieses Problems beziffert: Enterprise-Agentensysteme zeigen im Schnitt eine Lücke von 37 Prozent zwischen Labor-Benchmark-Werten und tatsächlicher Performance im produktiven Einsatz. Bei Kostenvergleichen ist die Streuung noch dramatischer – bis zum 50-Fachen Unterschied zwischen Ansätzen, die auf dem Papier ähnlich gut abschneiden.

Woran liegt das?

Mehrere Gründe kommen zusammen:

Benchmarks sind gesättigt.
MMLU, einst der Goldstandard für KI-Fähigkeiten, wird heute von praktisch jedem führenden Modell mit über 88 Prozent gelöst. Unterschiede zwischen Modellen liegen dort im Bereich des statistischen Rauschens – sie sagen nichts mehr aus.

Benchmarks werden kontaminiert.
Modelle haben Testfragen oft schon während des Trainings gesehen. Bei SWE-Bench Verified, dem früheren Coding-Standard, zeigte ein Audit, dass praktisch alle führenden Modelle Überlappungen mit den Trainingsdaten aufweisen – und fast 60 Prozent der schweren Aufgaben fehlerhaft konstruiert waren.

Benchmarks können manipuliert werden.
Der internationale KI-Sicherheitsbericht 2026 dokumentierte, dass Spitzenmodelle zwischen Test- und Produktionskontext unterscheiden können – und sich in Tests sicherer verhalten als im echten Einsatz. Ein besonders deutliches Beispiel: Ein Modell, das eigentlich die Ausführungsgeschwindigkeit optimieren sollte, schrieb stattdessen einfach die Timer-Funktion um, damit sie schnelle Ergebnisse meldete – ohne die tatsächliche Performance zu verbessern.

Benchmarks testen die falsche Sache.
Ein Modell, das bei Humanity’s Last Exam glänzt – einem Test mit Fragen an der Grenze des akademischen Wissens –, sagt wenig darüber aus, ob es in eurem Kundenservice-Bot vernünftig mit einer mehrdeutigen Anfrage umgeht. Produktionssysteme interagieren mit Teams, verarbeiten unklare Eingaben und laufen über lange Zeiträume. Kein Standard-Benchmark berichtet Kosten pro Aufgabe, Latenz oder Zuverlässigkeit über mehrere Durchläufe.

Teilen

Der Gegenbeweis: Wie ein 1,3-Milliarden-Modell größere Modelle schlug

Schon 2023 lieferte Microsoft Research mit dem Modell „phi-1“ einen der eindrücklichsten Belege dafür, dass Modellgröße nicht der entscheidende Faktor ist. Phi-1 hatte gerade einmal 1,3 Milliarden Parameter – winzig im Vergleich zu den meisten Konkurrenten. Trainiert wurde es mit weniger als 7 Milliarden Tokens, ein Bruchteil dessen, was vergleichbare Modelle damals verschlangen.

Das Ergebnis: 50,6 Prozent Pass-Rate auf dem HumanEval-Coding-Benchmark – und schlug damit Modelle, die zehnmal größer und mit hundertmal mehr Trainingsdaten gefüttert worden waren. StarCoder etwa, ein Modell mit 15,5 Milliarden Parametern und einer Billion Trainings-Tokens, kam nur auf vergleichbare oder schlechtere Werte.

Der Grund war kein cleverer Trick in der Architektur. Es war die Qualität der Trainingsdaten. Statt phi-1 mit dem üblichen, riesigen, aber unsauberen Mix aus öffentlichem Code zu trainieren, kuratierten die Forscher gezielt „lehrbuchqualitative“ Daten – sauber strukturierter, instruktiver Code statt zufällig zusammengewürfelter Repositories voller Boilerplate und unverständlicher Snippets. Ergänzt wurde das durch synthetisch generierte Übungsaufgaben.

Das Team zeigte sogar, dass dieser Effekt nicht auf Zufall oder versehentliche Kontamination der Testdaten zurückzuführen war: Selbst nachdem sie aggressiv über 40 Prozent der Trainingsdaten entfernt hatten, die HumanEval-Aufgaben auch nur entfernt ähnelten, blieb die Leistung von phi-1 stabil deutlich über der von StarCoder.

Die Kernerkenntnis aus diesem Paper, treffend zusammengefasst im Titel selbst: „Textbooks Are All You Need“.

Saubere, gezielt kuratierte Daten schlagen rohe Masse.

Teilen

GLM-5.2: Dasselbe Prinzip, drei Jahre später, im großen Maßstab

Was bei phi-1 im Kleinen demonstriert wurde, zeigt sich heute bei GLM-5.2 im Maßstab von Hunderten Milliarden Parametern. GLM-5.2 wurde nicht als Alleskönner trainiert, der nebenbei auch programmieren kann.

Es wurde gezielt für Coding-Aufgaben und für das Arbeiten in agentischen Umgebungen wie Claude Code oder OpenCode trainiert – mit einer effizienten MoE-Architektur und Optimierungen, die den Rechenaufwand pro Token drastisch senken.

Das Ergebnis bestätigt das Muster: In einer realen Aufgabe – dem Bau eines WebGL-3D-Plattformers von Grund auf – kostete GLM-5.2 rund 5,39 US-Dollar, während Opus 4.8 etwa 21,92 US-Dollar verschlang. Opus war zwar schneller fertig und lieferte das sauberere Ergebnis, aber der Kostenunterschied von etwa dem Vierfachen zeigt deutlich: Spezialisierung auf eine klar definierte Aufgabe schlägt rohe Modellgröße, wenn das Verhältnis von Aufwand zu Ergebnis zählt.

Was das für euer Unternehmen bedeutet

Die Kili-Analyse formuliert es treffend: Benchmarks sollten als Filter dienen, nicht als Urteil. Ein Benchmark-Score sagt euch, welches Modell es wert ist, weiter getestet zu werden – nicht, welches Modell für eure Nutzer tatsächlich funktioniert.

Für den Mittelstand heißt das konkret:

Hört auf, dem größten verfügbaren Modell automatisch zu vertrauen. Die Annahme „größer ist besser“ ist bequem, aber empirisch immer wieder widerlegt – von phi-1 vor drei Jahren bis zu GLM-5.2 heute.

Investiert in die Qualität eurer eigenen Daten, nicht in die Größe des Modells.
Phi-1 zeigt eindrücklich: Ein kleines Modell mit sauberen, gezielt kuratierten Trainingsdaten kann ein riesiges Modell mit unsauberen Daten schlagen. Das gilt nicht nur für die Modelle der großen Labs – es gilt genauso für jedes Custom-AI-Projekt, das auf euren eigenen Geschäftsdaten aufbaut.

Testet gegen eure eigene Realität, nicht gegen ein Leaderboard.
Ein Modell, das bei Humanity’s Last Exam brilliert, kann bei eurer konkreten Reklamationsbearbeitung trotzdem scheitern – und ein kleineres, spezialisiertes Modell kann genau dort gewinnen, wo es darauf ankommt.

Bewertet automatisierte Metriken, Modell-Screening und menschliche Fachexpertise gemeinsam.
Genau dieses gestaffelte Vorgehen empfiehlt auch die Kili-Analyse für produktionsreife KI-Bewertung – und es deckt sich mit dem, was sich in der Praxis als robust erweist: Kein einzelner Test ersetzt das Urteil von jemandem, der weiß, was in eurem spezifischen Kontext „richtig“ bedeutet.

Die eigentliche Frage ist also nicht „Welches Modell hat den höchsten Benchmark-Score?“. Die eigentliche Frage ist: „Welches Modell – trainiert auf welchen Daten, getestet gegen welche Realität – löst mein konkretes Problem am verlässlichsten und am günstigsten?”

Genau das ist der Unterschied zwischen einem KI-Projekt, das beeindruckende Folien produziert, und einem, das im Alltag tatsächlich läuft.

Jetzt abonnieren

Diese Geschichte hören nicht nur wir immer wieder. In seiner Studie vom Juli 2025 stellte das MIT fest, dass 95 % der Unternehmen keinen messbaren Erfolg durch den Einsatz insbesondere von GenAI feststellen können.

Wir denken, dass das Problem nicht an fehlender Technologie oder Unfähigkeit der Teams liegt, sondern daran, dass KI-Projekte falsch angegangen werden.

Jetzt abonnieren

Das Problem: KI als isoliertes Feature

Die Mehrheit der Unternehmen betrachtet KI als eine zusätzliche Komponente. Ein Chatbot hier, ein Empfehlungsalgorithmus dort, ein Prognosemodell für die Finanzabteilung. Jedes Team ist für den Aufbau seiner eigenen Datenpipeline, das Trainieren eigener Modelle sowie die Bewältigung des Change-Managements verantwortlich.

Die Realität dahinter:

• Team A braucht 6 Monate, um Kundendaten zu strukturieren

• 3 Monate später beginnt Team B erneut mit dem Bau derselben Datenpipeline.

• Team C scheitert am Widerstand der Fachabteilung, weil niemand versteht, was das Tool eigentlich bringt

Jedes Projekt kostet dabei mehrere hunderttausend Euro. Der ROI? Bestenfalls marginal.

Der Wendepunkt: In Produkten denken, nicht in Projekten

Stell dir vor, dein Vertrieb wäre eine geschlossene Domäne. Die Generierung von Leads, die Kommunikation mit Kunden, das Forecasting und die Churn-Prävention sind alle miteinander verbunden. Jede frisch eingeführte KI-Applikation verwendet die gleiche Dateninfrastruktur. Jedes trainierte Modell verbessert das nächste. Das Team wird durch jeden Erfolg motiviert, den nächsten Schritt zu machen.

Ein konkretes Beispiel aus der Praxis:

Ein Online-Shop-Unternehmen hat den Bereich „Kundenerlebnis“ in drei Schritten verändert:

1. Start (Monat 1–3): Produktempfehlungen basierend auf historischen Käufen

   • Dateninfrastruktur aufgebaut: Kundenverhalten, Produktkatalog, Transaktionen

   • Impact: +12 % Conversion bei wiederkehrenden Kunden

2. Ausbau (Monat 4–6): Dynamische Preisoptimierung für Bestandskunden

   • Nutzte die gleiche Dateninfrastruktur wie Schritt 1

   • Erweiterte Customer-Insights um Preissensitivität

   • Impact: +8 % Marge bei gleichbleibender Kundenzufriedenheit

3. Skalierung (Monat 7–9): Predictive Churn Prevention

   • Kombinierte Daten aus Schritt 1 und 2

   • Team hatte inzwischen Erfahrung und Vertrauen

   • Impact: –23 % Kundenabwanderung in der Risikogruppe

Gesamtergebnis nach 9 Monaten: 3,2 Mio € zusätzlicher Jahresumsatz bei 680.000 € Investment.

Warum dieser Ansatz funktioniert

1. Daten als Produkt, nicht als Abfallprodukt

In isolierten Projekten sind Daten ein notwendiges Übel. Im Produkt-Ansatz werden sie zum Asset. Du baust einmal eine saubere, gut dokumentierte Dateninfrastruktur auf – und jede weitere Initiative profitiert davon.

Konkret bedeutet das:

• Einheitliche Datenqualität über alle Use Cases hinweg

• Wiederverwendbare Features (z.B. “Customer Lifetime Value” einmal berechnen, überall nutzen)

• Reduzierte Time-to-Market für neue KI-Anwendungen um 60-70%

Der Schlüssel zum Erfolg liegt nicht darin, die gesamte Organisation auf einmal umzukrempeln – ein solches Unterfangen ist zu komplex und birgt hohe Risiken. Stattdessen sollten Unternehmen einen entscheidenden Geschäftsbereich oder eine „Domäne“ identifizieren und diesen von Grund auf neu denken. Eine solche ganzheitliche Transformation eines Kernprozesses oder einer Funktion führt zu erheblichen Leistungssteigerungen, die isolierte Anwendungen niemals erreichen können.

Die Vorteile des Produkt-Ansatzes:

1. Synergien: Jede neue KI-Initiative kann auf der vorherigen aufbauen, indem Daten wiederverwendet und Fähigkeiten für gemeinsame Interessengruppen erweitert werden.

2. Organischer Wandel: Dieser Ansatz löst einen organischen Veränderungszyklus innerhalb der Domänen aus. Wenn Führungskräfte und Mitarbeiter sehen, wie KI funktioniert und welche Vorteile sie bringt, entsteht eine Eigendynamik für den KI-Einsatz im gesamten Unternehmen.

3. Kontinuierliche Verbesserung: Der Domänen-Ansatz fördert eine Denkweise der kontinuierlichen Verbesserung, die angesichts der rasanten Entwicklung der KI-Technologie unerlässlich ist. KI-Transformationen sind keine einmaligen Projekte, sondern fortlaufende Anstrengungen.

2. Der Mensch vor der Technologie

Veränderungen in Organisationen entstehen nicht durch verbesserte Computerprogramme, sondern durch Menschen, die mitmachen und begreifen. Indem Mitarbeiter aus dem gesamten Domäne-Zyklus (unabhängig davon, wo sie zuvor in der Organisation saßen) einberufen und ihnen Verantwortung für die Arbeit übertragen wird, fördert es die Beteiligung an einer Initiative und erzeugt Begeisterung und Dynamik. Es ist wichtig, dass diese Faktoren berücksichtigt werden, damit Mitarbeiter bei der Entwicklung von Lösungen über das Übliche hinausdenken und dem Projekt dabei helfen, unvorhergesehene Hindernisse zu überwinden.

Um auf unser Beispiel zurückzukommen: Im Rahmen des ersten Projekts erfährt das Vertriebsteam Folgendes: „Offenbar hat das KI-Tool unsere vielversprechendsten Leads zutreffend prognostiziert.“

Im zweiten Projekt stellen sie sich die Frage: „Können wir das auch für X verwenden?“

Beim dritten Projekt arbeiten sie an der Entwicklung ihrer eigenen Ideen.

Messbare Indikatoren:

• Adoption-Rate steigt von typischen 30 % (isoliertes Projekt) auf 75–85 % (dritte Initiative in der Domäne)

• Time-to-Value sinkt von durchschnittlich 8 Monaten auf 3–4 Monate

3. Prozesse, die mit der Technologie wachsen

Die Entwicklung der KI-Technologie schreitet rapide voran. GPT-4 jetzt, GPT-5 morgen, multimodale Modelle am Tag danach. Wer immer wieder von Null beginnt, der verliert.

Durch den Produkt-Ansatz werden Prozesse zur fortlaufenden Verbesserung etabliert:

• Regelmäßige Model-Retraining-Cycles

• A/B-Testing neuer Ansätze gegen etablierte Lösungen

• Feedback-Loops zwischen Business und Data Science

Die Notwendigkeit ist echt

Während du diese Zeilen liest, optimiert ein Konkurrent möglicherweise bereits seine Lieferkette unter Zuhilfenahme von künstlicher Intelligenz. Ein Startup revolutioniert deine Industrie mit einem Geschäftsmodell, das auf KI zugeschnitten ist. Ein weiterer CEO genehmigte letzte Woche den Produkt-Ansatz für seinen Vertrieb.

Die gute Nachricht: Die meisten Unternehmen haben durch die COVID-Jahre bereits erste KI-Erfahrungen gesammelt. Teams sind aufgebaut. Erste Projekte laufen.

Die Herausforderung: Diese Punktlösungen in eine kohärente, domänenweite Transformation zu überführen.

Deine nächsten Schritte

1. Identifiziere eine kritische Domäne. Wo würden 20–30 % Effizienzsteigerung den größten Business-Impact haben?

2. Mappe die Datenlage: Welche Daten existieren bereits? Was fehlt? Was ist die Qualität?

3. Definiere 3–5 vernetzte Use Cases. Nicht isolierte Projekte, sondern eine zusammenhängende Transformationsstory

4. Starte klein, denke groß. Erstes Projekt in 8–12 Wochen live, aber mit Infrastruktur, die skaliert.

Weiterführende Ressourcen:

• Framework für Domänen-Mapping – systematisches Vorgehen zur Identifikation der richtigen Domäne

• Data Product Canvas – Template für die Konzeption von Daten als Produkt

• KI-Readiness-Assessment – Evaluiere die Ausgangslage deiner Organisation.

Frage in die Community: Welche Domäne in eurem Unternehmen hätte das größte Transformationspotenzial? Und was hält euch aktuell davon ab, den ersten Schritt zu gehen?

Noch keine Data-Community?

Read more