Das richtige KI-Modell wählen, mit Absicht

Alle paar Wochen erscheint ein neues KI-Modell. Mit Datenblatt, Anleitung, einer Seite voller Bestwerte. Eine Stunde später hat das halbe Internet entschieden, dass sich gerade alles geändert hat, die andere Hälfte hält den Anbieter für erledigt.

Am Nachmittag steht jemand aus Ihrem Team in der Tür mit der einzigen Frage, die Sie wirklich betrifft: Sollten wir wechseln?

Eine ehrliche Antwort haben Sie nicht. Sie haben ein Bauchgefühl, einen Screenshot von einer Bestenliste und das diffuse Gefühl, das mal testen zu sollen. Also tauschen Sie auf gut Glück oder lassen es und fragen sich einen Monat lang, ob Sie Qualität oder Geld liegen lassen.

Das ist kein Modellproblem, das ist ein fehlendes Verfahren. Genau das beschreibt dieser Text: wie Sie ein KI-Modell auswählen, mit Belegen statt mit Bauchgefühl, in einem Nachmittag wiederholbar bei jeder neuen Veröffentlichung.

Warum die Bestenliste Ihre Frage nicht beantwortet

Wenn ein Modell erscheint, reisen die großen Bestwerte mit: wie gut es programmiert, recherchiert, im Web sucht. Das ist in genau einem Punkt nützlich. Es sagt Ihnen grob, ob ein Modell in einer breiten Fähigkeit besser geworden ist. Ein höherer Code-Wert heißt: breit gesehen ein stärkerer Programmierer. Schön.

Der Fehler beginnt, sobald Sie das als Antwort auf Ihre Frage lesen. Ihre Arbeit ist nicht der Test. Ein Code-Test bewertet abgeschlossene, saubere Programmieraufgaben. Ihr Agent muss erst eine entlegene Ecke einer Schnittstelle im Web recherchieren und dann umsetzen. Schon zwei Fähigkeiten, die der Test getrennt gemessen hat, hier zusammengeklebt, so wie er es nie geprüft hat.

Echte Arbeit ist gemischt. Sie kreuzt Fähigkeiten, trifft auf Ihre Daten, scheitert auf eine Weise, die typisch für Sie ist. Eine Bestenliste sortiert nach einem Mittelwert über fremde Aufgaben. Die Rangliste, die zählt, ist die auf Ihren Aufgaben. Und die kann nur einer erstellen: Sie.

Ein kleiner, gut gebauter Prüfstand auf Ihrer eigenen Arbeit verrät Ihnen mehr über die Modellwahl als jede öffentliche Bestenliste je könnte.

Die Größe, die wirklich zählt

Es gibt einen Satz, der die ganze Entscheidung umsortiert. Das richtige Modell ist nicht das, das pro Token am günstigsten ist. Es ist das, das pro brauchbarem Ergebnis am günstigsten ist.

Der Preis pro Token steht auf der Seite, deshalb zitiert ihn jeder. Für sich genommen ist er fast wertlos. Er ignoriert, wie viele Token die Aufgabe wirklich frisst und wie oft der Lauf überhaupt gelingt. Ein Modell, das pro Token billig ist, aber drei Anläufe braucht und am Ende jeden fünften Fall trotzdem vergeigt, kann pro fertigem, korrektem Ergebnis teurer sein als ein vermeintlich teureres, das es einmal sauber erledigt.

Die Rechnung ist simpel: Kosten pro brauchbarem Ergebnis sind die durchschnittlichen Kosten pro Lauf, geteilt durch die Erfolgsquote. Ein Lauf für vier Cent mit 70 Prozent Erfolg kostet rund sechs Cent pro Erfolg. Ein Lauf für sechs Cent mit 95 Prozent Erfolg kostet ungefähr genauso viel und reicht nicht jedem fünften Nutzer eine falsche Antwort. Drehen Sie die Quoten um, ist das teure Modell plötzlich das billige. Auf der Preisliste sehen Sie davon nichts, erst wenn Sie Erfolg messen.

Das ist auch unser eigener Filter, offen gesagt: Wir empfehlen, was sich rechnet. Nicht das auffälligste Modell und nicht den niedrigsten Aufkleberpreis, sondern das, was auf der Aufgabe vor Ihnen die meisten korrekten Ergebnisse pro Euro liefert.

Bauen Sie sich einen kleinen Prüfstand

Aus der Formel wird erst dann eine Entscheidung, wenn Sie Erfolg messen können. Dafür brauchen Sie einen eigenen Prüfstand. Im Englischen heißt das Eval. Wir nennen es lieber Prüfstand, weil es genau das ist: eine Werkbank, auf der Sie jedes Modell gegen Ihre echte Arbeit laufen lassen.

Die kleinste Einheit ist eine Testaufgabe aus drei Teilen. Der Eingang: eine realistische Anfrage mit dem Kontext, den das System wirklich sähe. Das Erfolgskriterium: was richtig in genau diesem Fall bedeutet, von Ihnen festgelegt, vorab. Und die Prüfer: die Checks, die automatisch entscheiden, ob ein Lauf das Kriterium erfüllt hat. Sammeln Sie genug solcher Fälle, und Sie haben einen Datensatz, gegen den jedes Modell eine vergleichbare Zahl liefert.

Der schwere Teil ist nicht die Mechanik. Es ist die Ehrlichkeit: für jede Aufgabe festzulegen, was das richtige Ergebnis tatsächlich ist. Diese Arbeit kann nur ein Mensch leisten, der den Job versteht. Sie ist der Hebel.

Geprüft wird mit zwei Werkzeugen. Für alles Eindeutige eine harte Code-Prüfung: Hat der Agent das vorgeschriebene Werkzeug aufgerufen? Den Datensatz vor der Entscheidung geladen? Das sind Regeln, und Code prüft sie schnell, kostenlos und nie launisch. Für alles Unscharfe ein Modell als Gutachter: Schreibt der Agent eine Abfrage, die anders aussieht als Ihre Vorlage, aber dieselben Daten holt, erkennt ein Gutachter die Gleichwertigkeit, wo ein starrer Textvergleich fälschlich durchfallen ließe. Die meisten guten Aufgaben nutzen beides.

• Bewerten Sie das Ergebnis: Ist am Ende das Richtige herausgekommen?
• Bewerten Sie den Weg: Hat das Modell das richtige Werkzeug gerufen, ist es in seinen Grenzen geblieben? Ein Service-Agent kann eine perfekt klingende Antwort schreiben und dabei den Datensatz des falschen Kunden gezogen haben. Nur der Blick auf den Weg fängt das.
• Bleiben Sie klein und echt: Ein Dutzend realer Fälle reicht für erste belegte Entscheidungen. Ein repräsentativer Datensatz schlägt einen großen, generischen. Speisen Sie ihn laufend aus dem Betrieb, mit echten Fragen und echten Pannen.

Drei Arten, wie die Zahlen Sie täuschen

Ein Prüfstand liefert Zahlen, und Zahlen fühlen sich nach Wahrheit an. Sind sie nicht, nicht von allein. Drei Wege, auf denen sie in die Irre führen, mit je einer Abwehr.

Rauschen. Modell A holt einmal 84 Prozent, Modell B 81, Sie schließen: A ist besser. Beim zweiten Lauf kippt es vielleicht, denn Modelle sind nicht streng vorhersagbar. Abwehr: jede Aufgabe mehrfach laufen lassen, auf die Streuung schauen, nie auf einen Unterschied handeln, der kleiner ist als das Rauschen.

Ein technischer Ausfall mit Modellgesicht. Ein Modell sieht unerwartet schwach aus. Ein Blick in die Protokolle zeigt dann oft kein schlechtes Denken, sondern eine Kette aus Zeitüberschreitungen und gescheiterten Werkzeugaufrufen. Die Leitung war kaputt, nicht das Modell. Abwehr: Protokolle lesen, eine Zeitüberschreitung nicht als falsche Antwort zählen.

Und die leise Sättigung. Ihr Prüfstand zeigt seit Monaten 95 Prozent, also schauen Sie nicht mehr hin. Inzwischen hat sich Ihr echter Verkehr verschoben, und der eingefrorene Datensatz ähnelt der Wirklichkeit nicht mehr. Die Zahl ist hoch und bedeutungslos. Abwehr: den Datensatz lebendig halten, frische Fälle aus dem Betrieb nachziehen.

Wenn Sie aus all dem eine Gewohnheit mitnehmen, dann diese: Lesen Sie die Protokolle. Je näher Sie an den Rohdaten sind, desto besser wird jede Entscheidung danach.

Wann ein kleineres Modell reicht, wann das große nötig ist

Mit einem Prüfstand können Sie tun, was die Bestenliste nicht kann: jeden Kandidaten gegen Ihre Aufgaben laufen lassen und auftragen. Qualität auf der einen Achse, Kosten oder Tempo auf der anderen. Das Ergebnis ist Ihre Grenzkurve der besten verfügbaren Abwägungen. Modellwahl wird zur Wahl eines Punktes auf einer Kurve, die Sie sehen.

Hier folgt der Teil, an dem der Instinkt die meisten Leute täuscht. Der Instinkt sagt: kleineres Modell, weniger Token, schneller, billiger, greif zum Kleinen.

Die Messung sagt oft das Gegenteil. Ein fähigeres Modell erledigt eine Aufgabe in weniger Schritten. Es plant besser, verzettelt sich nicht beim Selbstprüfen, dreht keine Schleifen. Weniger Schritte heißen geringere Wartezeit und am Ende sogar weniger Token, obwohl es pro Token mehr kostet.

In unserer eigenen Arbeit sehen wir beides. Für eine simple, gut umrissene Routine reicht das kleine Modell und spart spürbar. Für eine Aufgabe mit Recherche, Verzweigungen und Urteilskraft liefert das große die höhere Trefferquote und braucht weniger Anläufe. Wer nach dem Reflex kleiner ist schneller wählt, greift manchmal zur langsameren, schwächeren Variante und merkt es nie. Oft lautet die richtige Antwort auf welches Modell darum: dieses, bei der passenden Einstellung von Nachdenken und Aufwand.

Die ganze Kurve verschieben

Sich auf der Kurve zu bewegen ist gut. Die ganze Kurve zu verschieben ist besser: mehr Qualität zum gleichen Preis, auf ganzer Breite. Zwei Hebel tun das, beide unglamourös, weshalb sie zu selten genutzt werden.

Der erste ist das Zwischenspeichern fester Prompt-Teile. Bleibt der Anfang Ihres Prompts gleich, zahlen Sie bei Folgeabrufen nur einen Bruchteil des Eingabepreises dafür, grob ein Zehntel. So holen Sie die Qualität eines stärkeren Modells zum Preis eines schwächeren. Es funktioniert nur, wenn Sie hinten ergänzen, nie umschreiben, und keinen laufenden Zeitstempel ganz oben halten.

Der zweite Hebel ist saubere Eingabe. Die meisten Werkzeuge reichen die rohe Antwort einer Schnittstelle direkt ans Modell weiter, voller doppelter Struktur und redundanter Datensätze. Räumen Sie das auf, bevor es das Modell erreicht: Sie verbrauchen weniger Token, und das Modell denkt besser, weil es weniger Lärm zu durchwaten hat. Behandeln Sie Werkzeug-Ausgaben wie etwas, das ein Mensch lesen muss. Dieser schlichte Schritt schlägt leise einen Großteil der aufwendigen Mehr-Agenten-Architektur, an der so viele bauen.

Aus einer Wahl wird eine Gewohnheit

Laufen Sie dieses Verfahren einmal durch, haben Sie die heutige Frage gut beantwortet. Schauen Sie aber, was Sie wirklich gebaut haben: keine Antwort, eine Routine. Denn die Frage kommt immer wieder.

Nächsten Monat erscheint ein neues Modell, Ihr Verkehr verschiebt sich, Ihr eingefrorener Prüfstand sättigt leise. Die beste Entscheidung von heute verfällt zum schalen Standard, wenn niemand die Schleife dreht. Den meisten Teams fehlt nicht das Verständnis. Es fehlt, dass die Disziplin in einem Kopf steckt und einmal läuft, statt eine Gewohnheit des ganzen Teams zu sein.

Genau hier hilft eine dokumentierte Arbeitsroutine. Bei uns leben solche Routinen als Skills, und alles, was die KI über Ihr Unternehmen wissen muss, steht im BrandOS, versioniert wie Code. Eine so verankerte Modellwahl läuft bei jeder Veröffentlichung neu, ohne dass jemand das Rad neu erfindet. Dazu unsere Grenzen, weil Nein sagen zum Verfahren gehört: kein Modell von einer Bestenliste, neuer ist eine Vermutung. Optimiert wird auf das günstigste brauchbare Ergebnis. Und wir setzen uns nie zwischen Sie und das Modell; Sie bringen Ihre eigenen Zugänge mit.

Wenn Sie ein Fundament wollen, auf dem diese Disziplin von Anfang an mitläuft, ist AI Academy der Weg dorthin.