Welches Sprachmodell für welchen Use Case? Auswahlkriterien jenseits von Benchmarks

Warum öffentliche Benchmarks die falsche Primärfrage sind

Öffentliche Benchmarks messen, wie Modelle bei standardisierten Aufgaben abschneiden: Multiple-Choice-Fragen, klassische Programmieraufgaben, Mathe-Puzzles. Für einen ersten Vergleich sind diese Werte nicht wertlos, aber sie sagen wenig darüber aus, wie ein Modell in Ihrem Support-Ticket, Ihrem Vertragstext oder Ihrer Mehrfachfrage mit internem Kontext reagiert. Ein Modell auf Rang zwei im Leaderboard kann für Ihren Use Case besser geeignet sein als das vermeintliche Spitzenmodell.

Hinzu kommt, dass Benchmark-Zahlen einen Zustand zu einem Stichtag abbilden. Neue Versionen erscheinen in kurzen Abständen, Preise und Verfügbarkeiten ändern sich, Latenzen schwanken je nach Region. Eine Entscheidung, die nur auf der aktuellen Rangliste basiert, veraltet in Wochen. Sinnvoller ist eine Entscheidung, die sich an Eigenschaften orientiert, die länger stabil bleiben.

Wovon die Auswahl tatsächlich abhängt

In der Praxis entscheiden sechs Dimensionen, ob ein Modell für einen konkreten Einsatz passt: die Aufgabentyp-Eignung, die benötigte Kontextgröße, die Latenzanforderung, die Kostenstruktur, der Betriebsort samt Vertragsmodell und die Anpassbarkeit durch Prompts, Tool-Use und gegebenenfalls Fine-Tuning. Jede dieser Dimensionen kann ein Ausschlusskriterium sein, auch wenn die reinen Qualitätswerte sonst überzeugen.

Wer diese Dimensionen von Anfang an in die Bewertung nimmt, engt das Feld schneller ein, als es auf den ersten Blick scheint. Für viele Unternehmens-Use- Cases bleiben realistisch zwei bis vier Modelle im engeren Vergleich übrig, nicht zwanzig.

Aufgabentyp: was das Modell konkret leisten soll

Ein Modell, das in freien Zusammenfassungen glänzt, muss nicht auch bei strukturierter Extraktion aus Formularen überzeugen. Ein Modell, das flüssig Code generiert, ist nicht automatisch ein guter Zusammenfasser juristischer Texte. Vor der Auswahl lohnt sich die Frage, ob es primär um Verständnis langer Texte, um strukturierte Ausgabe, um Dialogführung, um Code, um Reasoning bei mehrstufigen Aufgaben oder um Tool-Use mit externen Systemen geht.

Diese Einordnung klingt banal, ist aber in Kundenprojekten der häufigste Bruch: Ein Modell wird auf Basis eines generischen Eindrucks ausgewählt und zeigt später Schwächen genau dort, wo der eigentliche Use Case seine Kernanforderung hat. Ein kleiner Aufgabenkatalog mit realen Beispielen aus dem eigenen Alltag ist hier Gold wert.

Kontextgröße, Latenz, Kosten

Die Kontextgröße entscheidet, wie viel Information Sie dem Modell pro Anfrage mitgeben können. Für Anwendungen, die Dokumente als Ganzes verarbeiten, ist ein sehr großer Kontext attraktiv, aber nicht jedes Modell nutzt große Kontexte gleich gut. In der Praxis lohnt es sich, Kontextgröße und Kontextqualität getrennt zu bewerten, nicht nur die maximale Tokenzahl aus dem Datenblatt.

Latenz wird in Piloten kaum gemessen, in Produktion schnell zum dominanten Thema. Ein Modell, das drei Sekunden für eine Antwort braucht, ist im Chat-Kontext nicht dasselbe wie ein Modell mit acht Sekunden. Für nutzerseitige Anwendungen lohnt sich in vielen Fällen ein Mix aus einem schnellen Modell für einfache Fälle und einem stärkeren Modell für komplexe Fälle, statt eines einzigen Premium-Modells für alles.

Kosten folgen dem gleichen Muster. Die Preisunterschiede zwischen Modellen sind in produktiven Setups oft zweistellige Faktoren. Wer früh eine abgestufte Strategie einplant, hält sich die Möglichkeit offen, Kosten zu steuern, ohne die Anwendung neu bauen zu müssen. Solche Architekturfragen gehören in unseren Bereich AI Engineering.

Betriebsort und Betreiber

Der Ort, an dem ein Modell läuft, ist keine reine Technikfrage. Er entscheidet über Latenz, über Vertragsbeziehungen, über Verfügbarkeit bei Ausfällen und über die Flexibilität, später umzuziehen. Für sensible Anwendungen zählen regionale Bereitstellungen und dedizierte Endpunkte, für einfache Produktivität reichen geteilte Standard-APIs.

Ein Punkt, der in der Entscheidung oft untergeht, ist die Flexibilität des Betreibers. Manche Anbieter liefern stabile Modelle mit klaren Lebenszyklen, andere rollen schnell neue Versionen aus und deprecieren ältere. Beides kann passen, aber es hat unterschiedliche Konsequenzen für Ihren Betrieb. Stabile Lebenszyklen sind für produktive Kernanwendungen oft wichtiger als das jeweils aktuellste Modell.

Anpassbarkeit: Prompting, Tool-Use, Fine-Tuning

Die drei Hebel, ein Modell an einen konkreten Use Case anzupassen, sind Prompting, Tool-Use und Fine-Tuning. Prompting ist in den meisten Fällen der erste und wichtigste Schritt, weil es schnell, reversibel und unabhängig vom Modellanbieter ist. Wer früh auf Fine-Tuning setzt, ohne Prompting auszureizen, optimiert an der falschen Stelle.

Tool-Use, also die Fähigkeit, Funktionen oder externe Systeme aufzurufen, verändert den Raum der möglichen Anwendungen grundlegend. Modelle unterscheiden sich hier deutlich in Stabilität, Schema-Treue und Geschwindigkeit. Wer Agenten oder Assistenten mit Systemzugriff baut, sollte die Modellauswahl nicht anhand klassischer Chat-Metriken treffen. Für diesen Bereich arbeiten wir auch bei KI-Agenten eng mit den Eigenheiten der jeweiligen Modelle zusammen.

Fine-Tuning ist dann sinnvoll, wenn ein klar abgegrenzter Aufgabentyp mit genug eigenen Beispielen vorliegt und sich das gewünschte Verhalten über Prompting allein nicht stabil herstellen lässt. Es ist nicht der Einstieg in Unternehmens-KI, sondern eine gezielte Optimierung. Für viele Use Cases ist die Kombination aus gutem Retrieval, klaren Prompts und strukturierter Ausgabe deutlich wirksamer.

Produktive vs. erkundende Szenarien

Ein Punkt, der in der Modellwahl oft fehlt, ist die Unterscheidung zwischen produktiven und erkundenden Szenarien. Für eine interne Anwendung, die 500 Mitarbeitende mehrfach täglich nutzen, zählen Stabilität, Kosten und Latenz mehr als das letzte Prozent Qualität. Für die Analyse eines einmaligen großen Dokumentenbestands kann das Gegenteil gelten.

Diese Trennung erlaubt, im selben Unternehmen unterschiedliche Modelle für unterschiedliche Zwecke bewusst einzusetzen. Ein Modell für Breite und Betrieb, ein anderes für tiefe Analysen, ein schnelles Modell für Oberflächenfälle. Wer das sauber orchestriert, holt deutlich mehr aus derselben Budgetgröße heraus.

Evaluation: wie man die Auswahl belastbar macht

Am Ende entscheidet nicht das Gefühl, sondern eine Messung gegen eigene Aufgaben. In der Praxis heißt das: ein fester Satz realer Beispiele aus dem Use Case, definierte Erwartungen an das Ergebnis, ein einfacher Vergleich der Kandidaten-Modelle gegen diesen Satz. Das kann schlank sein, muss aber systematisch sein, sonst wiederholt sich jede Diskussion beim nächsten Modellwechsel.

Für produktive Setups ist diese Messung kein einmaliger Vorgang. Modelle ändern sich, Anforderungen ändern sich, neue Kandidaten kommen dazu. Eine wiederholbare Evaluation gehört deshalb in die LLM-Qualitätssicherung und sollte nicht als einmaliges Projekt verstanden werden.

Typische Fehler bei der Modellauswahl

Der häufigste Fehler ist, sich auf ein einziges Modell festzulegen, bevor die Anwendung gebaut ist. Das spart Diskussionen, kostet aber später Flexibilität. Eine saubere Abstraktionsschicht, hinter der sich das Modell austauschen lässt, ist in den meisten Projekten eine bessere Startinvestition als die perfekte erste Wahl.

Der zweite Fehler ist, den Entscheidungsrahmen zu eng zu halten. Wer nur Chat- Qualität prüft, übersieht Latenz, Tool-Use und Betriebsstabilität. Wer nur Kosten rechnet, übersieht Qualitätsunterschiede, die im Alltag zu Mehrarbeit führen. Eine gute Auswahl betrachtet alle sechs Dimensionen zusammen.

Der dritte Fehler ist, Auswahlentscheidungen nicht zu dokumentieren. Ohne festgehaltene Begründung sind alte Entscheidungen nicht mehr überprüfbar, und bei der nächsten Diskussion beginnt die Analyse wieder bei null. Ein kurzes Entscheidungsdokument mit Kriterien, Kandidaten und Ergebnissen bezahlt sich mehrfach zurück.

Wann professionelle Unterstützung sinnvoll ist

Für klar geschnittene Use Cases ist die Modellauswahl in wenigen Tagen machbar. Sobald aber mehrere Use Cases, unterschiedliche Anforderungen an Latenz, Kosten und Betrieb und eine heterogene Systemlandschaft zusammenkommen, wird die Auswahl zur Architekturfrage. Hier lohnt sich eine strukturierte Bewertung, die nicht in einer Tool-Diskussion endet, sondern in einer Entscheidung, die sich in Ihrem Alltag hält.

Wir begleiten Unternehmen bei genau dieser Auswahl: vom Zuschnitt der Bewertungskriterien über die Evaluation an eigenen Beispielen bis zur Architektur, die Modellwechsel später erlaubt. Ziel ist nicht das beeindruckendste Modell, sondern das im Alltag belastbare.