Die These in einem Satz: Das KI-Modell zu wechseln ist das Erste, was man tut, wenn etwas nicht funktioniert, und das Letzte, was man tun sollte. Ein neues Modell kommt raus, jemand liest, dass es schlauer ist, und das Gespräch im Team wechselt von „Warum bringt das keine Leistung?“ zu „Steigen wir auf das neueste um?“. Es ist die bequemste Reaktion der Welt —sie verlangt keinen Blick nach innen— und fast immer die falsche. Der Flaschenhals ist selten das Modell. Es sind der Prozess, den niemand sauber definiert hat, und die Daten, die niemand geputzt hat.
Das KI-Modell zu wechseln behandelt das Symptom, nicht die Krankheit
Wenn ein KI-Projekt enttäuscht, gibt es zwei mögliche Schuldige: den Motor oder alles drumherum. Der Motor ist das Modell; das Drumherum ist, wie ihm die Information zukommt, was man von ihm verlangt, mit welchen Daten es arbeitet und was man mit seiner Antwort anfängt. Die ganze Branche drängt dich, auf den Motor zu schauen, weil das verkauft, verglichen und in den Schlagzeilen genannt wird. Aber in den meisten Projekten, die feststecken, ist der Motor nicht das Problem: Das Problem ist, dass du ihn über einen Prozess raten lässt, den nicht mal du klar hast, gefüttert mit Daten, die sich gegenseitig widersprechen.
Denk es dir mit einer langweiligen, aber exakten Analogie: Wenn dein Auto nicht anspringt, weil der Tank leer ist, bewegt es der Tausch gegen einen stärkeren Motor keinen Meter. Das Modell zu wechseln, wenn die Bremse der Prozess ist, ist genau das —eine teure Baustelle, die die Ursache nicht berührt. Und in der Zwischenzeit redet sich das Team ein, „alles versucht“ zu haben, obwohl es das Einzige, worauf es ankam, gar nicht angefasst hat.
Der echte Flaschenhals: schlecht definierter Prozess und schmutzige Daten
Ein KI-Modell ist nur so gut wie die Klarheit der Arbeit, die du ihm aufträgst, und die Qualität dessen, was du ihm zum Arbeiten gibst. Wenn es versagt, versagt es fast immer an einem dieser beiden Dinge, nicht an fehlender roher Intelligenz:
Schlecht definierter Prozess
Wenn du den Prozess nicht in klaren Schritten erklären kannst, wird ihn die KI auch nicht für dich erfinden. Viele „KI-Anwendungsfälle“ sind in Wirklichkeit Prozesse, die nie dokumentiert wurden: Jeder machte sie auf seine Art, mit Ausnahmen im Kopf und Kriterien, die niemand aufschrieb. Du bittest die KI, dieses Chaos zu automatisieren, und logischerweise produziert sie Chaos mit besserer Grammatik. Ein stärkeres Modell gibt dir nicht die Prozessdefinition, die dir fehlt. Wie man eine Aufgabe in Anweisungen zerlegt, denen eine KI wirklich folgen kann, ist die halbe Arbeit, und darum geht es in Aufgaben mit ChatGPT automatisieren.
Schmutzige Daten
Die andere Hälfte ist, wovon es sich ernährt. Wenn die KI aus veralteter, doppelter, widersprüchlicher oder auf zehn Orte verteilter Information antwortet, die nicht miteinander reden, wird die Antwort schlecht sein, egal wie hervorragend das Modell ist. Müll rein, Müll raus —das repariert kein Release. Diese Bremse ist so verbreitet, dass wir ihr einen ganzen Artikel widmen: unordentliche Daten sind die echte Bremse der KI. Und wenn dein Fall verlangt, dass das Modell dein Geschäft kennt, ist die Lösung fast nie ein Modellwechsel: Es ist, ihm geordneten Zugang zu deiner Information zu geben, was wir in den Agenten mit deiner eigenen Information trainieren aufdröseln.
Warum ein Modellwechsel so verlockend ist (und so nutzlos)
Wenn das Problem fast immer der Prozess ist, warum ist die Reflexreaktion dann der Modellwechsel? Weil er einfach ist. Das Modell zu wechseln ist eine Entscheidung von einem Nachmittag: Du fasst eine Einstellung an, zeigst auf einen anderen Endpoint, fertig. Prozess und Daten zu reparieren ist eine Entscheidung von Wochen, verlangt Gespräche mit den Leuten, die die Arbeit machen, das zu dokumentieren, was niemand dokumentiert hat, und das zu putzen, was niemand putzen will. Vor dieser Wahl bevorzugt der Mensch die, die nach Fortschritt aussieht, ohne unbequem zu sein.
- Es fühlt sich nach Handeln an, ohne es zu sein. Ein Modellwechsel wirkt produktiv —es gibt etwas anzufassen, ein Vorher und ein Nachher— auch wenn sich am Ergebnis nichts bewegt. Es ist Fortschrittstheater.
- Das Marketing liefert dir das Alibi. Jedes Release kommt mit Benchmarks, die einen Sprung versprechen. Es ist kinderleicht, sich einzureden, DAS sei jetzt das fehlende, statt zu akzeptieren, dass der Fehler bei dir zu Hause liegt.
- Der Blick nach innen ist unbequem. Zuzugeben, dass dein Prozess nicht definiert war oder deine Daten ein Desaster sind, zeigt auf eigene Entscheidungen. Den Anbieter zu wechseln lagert die Schuld aus: Es war das Modell, nicht wir.
Und es gibt Kosten, die fast niemand verbucht: Jede Modellmigration ist nicht gratis. Du schreibst Prompts um, validierst Ergebnisse neu, justierst die Integration und testest alles erneut. Machst du das auf der Jagd nach einem Problem, das gar nicht im Modell steckte, verpulverst du diesen Aufwand, um am selben Punkt zu landen —mit dem Prozess genauso kaputt, aber mit einem anderen Modell, dem man beim nächsten Mal die Schuld geben kann.
Wann ein Modellwechsel doch die richtige Entscheidung ist
Das ist kein „Wechsle nie das Modell“. Manchmal ist der Motor tatsächlich die Grenze, und dann ist wechseln vernünftig. Der Unterschied ist, dass du es machst, nachdem du den Rest ausgeschlossen hast, nicht bevor du hinschaust. Das sind die Signale, dass das Modell wirklich deine Decke ist:
- Ein Mensch mit deinen gleichen Anweisungen und Daten macht es gut, und die KI nicht. Wenn die Aufgabe sauber definiert ist, die Daten geputzt sind und eine Person mit genau dieser Information richtig liegt, das Modell aber bei einer konkreten Art des Denkens versagt, dann ist der Motor tatsächlich die Grenze.
- Du stößt an eine echte technische Grenze. Zu kleines Kontextfenster für deinen Fall, eine Sprache, die das Modell schlecht beherrscht, Latenz oder Kosten pro Token, die bei deinem Volumen nicht aufgehen: Das sind Grenzen des Motors, nicht des Prozesses.
- Du hast es unter gleichen Bedingungen getestet. Du hast nur das Modell gewechselt, mit demselben Prozess und denselben, bereits geordneten Daten, und das neue gewinnt messbar und wiederholbar —nicht in einer glücklichen Demo.
Beachte die Reihenfolge: Zuerst reparierst du Prozess und Daten, und erst dann, mit dieser sauberen Basis, wird der Vergleich von Modellen zu einer sinnvollen Entscheidung statt einer Flucht nach vorn. Wie man diese Basis aufbaut, um den Motor ohne Schmerz wechseln zu können —indem man die Anwendung vom Anbieter entkoppelt—, haben wir in Open-Source-KI vs. geschlossene API geschrieben.
Was du am Montag tun kannst, statt das Modell zu wechseln
- Schreib den Prozess von Hand auf, in Schritten. Kannst du ihn nicht auf einer klaren Seite erklären, wird die KI nicht retten, was du nicht definiert hast. Dieses Dokument ist die Lösung, nicht das Modell.
- Schau, wovon sich die KI ernährt. Verfolge die Information, die sie nutzt, bis zu ihrem Ursprung und prüfe, ob sie aktuell, eindeutig und widerspruchsfrei ist. Ordne das, bevor du sonst irgendetwas anfasst.
- Mach den Test mit dem neuen Mitarbeiter. Würde ein brillanter Mensch mit diesen Anweisungen und diesen Daten die Aufgabe gut machen? Wenn nicht, repariere die Anweisungen und die Daten. Wenn ja und die KI versagt, dann —und nur dann— vergleiche Modelle.
Wenn du dabei entdeckst, dass die Bremse nicht das Modell war, sondern der Prozess —was das Wahrscheinlichste ist—, ist das genau die Arbeit, die wir machen: den Prozess definieren, die Daten ordnen und die Automatisierung obendrauf am Laufen lassen, mit Automatisierung von Abläufen. Das Modell ist der einfache Teil; dass die Arbeit gut gemacht wird, der schwere.