Die Frage, welches KI-Modell in ein Projekt gehört, war vor wenigen Jahren schnell beantwortet: Es gab kaum Auswahl. Heute unterhalten selbst einzelne Anbieter ganze Modellfamilien, die sich in Größe, Antwortverhalten, Reaktionszeit und Preis unterscheiden. Für Entwicklungs- und Automatisierungsvorhaben ist das keine angenehme Fülle, sondern eine Entscheidung, die begründet werden muss.
In der Praxis fällt sie häufig nach Bauchgefühl: Man nimmt das Modell, das man aus dem Chatfenster kennt, oder das, über das gerade am meisten geschrieben wird. Beides sind schlechte Auswahlkriterien, weil sie die eigentliche Aufgabe nicht berücksichtigen. Ein Modell, das im freien Dialog überzeugt, kann bei streng strukturierter Datenextraktion enttäuschen – und umgekehrt.
Erst die Aufgabe, dann das Modell
Der erste Schritt ist unspektakulär, wird aber oft übersprungen: die Aufgabe präzise beschreiben. Nicht "Texte zusammenfassen", sondern: welcher Input, welche Länge, welche Sprache, welches Ausgabeformat, welche Fehler sind tolerierbar und welche nicht.
Aus dieser Beschreibung ergibt sich meist schon eine Vorauswahl. Typische Aufgabenklassen in Web- und Softwareprojekten sind:
- Klassifikation und Routing: Anfragen einsortieren, Tickets zuordnen, Inhalte verschlagworten. Hier zählen Konsistenz und Geschwindigkeit mehr als sprachliche Eleganz.
- Extraktion: aus Dokumenten strukturierte Daten gewinnen. Entscheidend ist, dass das Ausgabeformat verlässlich eingehalten wird.
- Textproduktion: Entwürfe, Übersetzungen, Varianten. Hier wirkt sich Qualitätsunterschied unmittelbar sichtbar aus.
- Mehrschrittige Aufgaben: Recherche, Codeänderungen, Abläufe mit Werkzeugaufrufen. Solche Fälle stellen die höchsten Anforderungen und rechtfertigen oft ein teureres Modell.
Diese Einteilung hat einen praktischen Nebeneffekt: Sie zeigt, dass in einem Projekt selten ein Modell die richtige Antwort ist. Die einfache Vorsortierung von Eingaben und die anspruchsvolle Endbearbeitung können unterschiedliche Modelle bedienen.
Qualität messbar machen
Ohne eigene Messung bleibt jede Modellauswahl Geschmackssache. Nötig ist kein wissenschaftliches Verfahren, sondern ein kleines Testset aus echten Fällen des Projekts – gerne mit den unangenehmen Ausnahmen, die im Alltag Probleme machen.
Zu jedem Fall gehört eine Vorstellung davon, wie ein akzeptables Ergebnis aussieht. Bei strukturierten Ausgaben lässt sich das automatisiert prüfen, bei Texten hilft eine kurze Bewertungsskala und ein zweites Paar Augen. Wichtig ist die Wiederholbarkeit: Dasselbe Testset wird bei jedem Modellwechsel erneut durchlaufen.
Ein oft unterschätzter Punkt ist die Streuung. Modelle antworten nicht deterministisch, dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen. Ein Modell, das im Schnitt gut, aber unberechenbar ist, kann in einem automatisierten Prozess schlechter geeignet sein als ein etwas schwächeres, dafür stabileres.
Kosten realistisch rechnen
Die Abrechnung erfolgt typischerweise über Tokens, also Text- und Datenbausteine bei Ein- und Ausgabe. Der Preis pro Einheit allein sagt wenig aus. Aussagekräftig ist erst der Betrag pro erledigtem Vorgang – also pro geprüftem Dokument, pro beantworteter Anfrage, pro erzeugtem Entwurf.
Dabei lohnt der Blick auf Mengen: Ein teures Modell in einem Prozess, der zehnmal am Tag läuft, ist unkritisch. Dasselbe Modell in einem Prozess mit Zehntausenden Durchläufen verändert die Projektkalkulation deutlich. Hinzu kommen indirekte Kosten, die leicht übersehen werden: Nacharbeit durch Menschen, zusätzliche Prüfschritte, Wiederholungen bei fehlerhaften Ausgaben.
Was neben Qualität und Preis zählt
Einige Kriterien entscheiden die Auswahl schneller als jeder Qualitätsvergleich, weil sie harte Rahmenbedingungen setzen:
- Antwortzeit: In interaktiven Oberflächen ist Wartezeit ein Qualitätsmerkmal. In nächtlichen Batchläufen ist sie irrelevant.
- Datenschutz und Betriebsort: Wo werden Daten verarbeitet, was darf das Unternehmen überhaupt übergeben, ist ein Betrieb in eigener Infrastruktur nötig.
- Kontextlänge: Wie viel Material muss das Modell in einem Durchgang überblicken.
- Verfügbarkeit und Lebensdauer: Modelle werden abgelöst. Wer eine Anwendung auf genau ein Modell festnagelt, plant Migrationsaufwand ein, ohne es zu wissen.
Austauschbarkeit als Architekturentscheidung
Weil sich das Angebot laufend verändert, ist die wichtigste Entscheidung oft nicht die für ein Modell, sondern die für eine Struktur, in der Modelle getauscht werden können. Praktisch heißt das: Modellzugriffe hinter einer eigenen Schnittstelle bündeln, Prompts und Bewertungskriterien versioniert ablegen, Ergebnisse protokollieren.
Ist das gegeben, wird aus einer strategischen Grundsatzfrage eine Routineaufgabe: neues Modell anbinden, Testset laufen lassen, Kosten pro Vorgang gegenrechnen, entscheiden. Dieser Durchlauf dauert Stunden statt Wochen.
Was das für Projekte bedeutet
Die Modellvielfalt verlangt kein tieferes Fachwissen über Modellarchitekturen, sondern Projektdisziplin: klare Aufgabenbeschreibung, eigenes Testset, Kostenrechnung pro Vorgang. Wer diese drei Dinge hat, kann jede Neuvorstellung sachlich prüfen, statt ihr zu folgen oder sie zu ignorieren. Und wer die Austauschbarkeit von Anfang an in die Architektur zieht, hält sich die Möglichkeit offen, in zwölf Monaten günstiger oder besser zu arbeiten – ohne das halbe System anzufassen.