Die Auswahl eines Modells ist eine betriebliche Entscheidung, keine Benchmark-Entscheidung

Es gibt einen bekannten Ablauf. Ein Team vergleicht Modelle, wählt anhand veröffentlichter Ergebnisse eines aus, baut darauf auf und stellt fest, dass sich der Agent auf eine Weise unvorhersehbar verhält, die im Vergleich nie ans Licht kam. Also probieren sie ein anderes Modell aus. Das Verhalten ändert sich; die Unvorhersehbarkeit nicht.

Die Diagnose ist normalerweise dieselbe: Das Modell war nie die Variable, die zählte.

Welche Benchmarks Ihnen sagen können und welche nicht

Ein veröffentlichter Score gibt Aufschluss darüber, wie sich ein Modell bei einem festgelegten Satz von Problemen unter Bedingungen verhält, die jemand anderes gewählt hat. Das sind wirklich nützliche Informationen über die Leistungsfähigkeit im Allgemeinen und als Prognose für Ihre spezifische Arbeit nahezu nutzlos.

Ihre Arbeit hat einen Kontext, den sie nicht hatten. Ihre Dokumente, Ihre Konventionen, Ihre Vorstellung einer akzeptablen Antwort, Ihre Toleranz für eine selbstbewusste falsche Antwort gegenüber einer abgesicherten richtigen. Ein Modell, das in der Zusammenfassung geringfügig besser abschneidet, kann leicht die schlechtere Wahl für einen Arbeitsablauf sein, bei dem Fehler eine bestimmte Form haben.

Dies ist kein Argument gegen Benchmarks. Es ist ein Argument dagegen, sie als Ersatz für die Bewertung Ihrer eigenen Arbeit zu betrachten.

Erstellen Sie die Bewertung, bevor Sie eine Auswahl treffen

Der praktische Rat ist unspektakulär: Stellen Sie dreißig bis fünfzig reale Beispiele aus der Arbeit zusammen, die Sie tatsächlich automatisieren möchten, und zwar mit dem Ergebnis, das Sie für richtig halten würden. Dieses Set ist aus drei Gründen mehr wert als jede Vergleichstabelle.

Es misst, was Ihnen am Herzen liegt. Es misst es ständig, wenn Sie etwas anderes ändern. Und es macht die Modellwahl umkehrbar, denn der Austausch eines Modells wird zu einem Experiment mit einem Ergebnis und nicht zu einer Migration mit einer Hoffnung.

Teams, die diesen Satz früh aufbauen, neigen dazu, Modellentscheidungen schnell zu treffen und nicht mehr darauf einzugehen. Teams, die es überspringen, überdenken die Entscheidung auf unbestimmte Zeit, weil sie durch nichts geklärt wird.

Warum sich das gleiche Modell für zwei Teams unterschiedlich verhält

Fast alles rund um das Modell ist eine Variable. Die Abrufstrategie bestimmt, was das Modell sieht. Das Toolset bestimmt, was es versuchen kann und wie viel Kontext es enthält, bevor es startet. Die Eingabeaufforderung sammelt über Monate hinweg die Randfallbearbeitung an. Die Fehlerrichtlinie bestimmt, ob eine wackelige Antwort zurückgegeben oder zurückgehalten wird.

Ändern Sie diese und das Verhalten ändert sich messbar, normalerweise um mehr, als dies bei einem Modellwechsel der Fall wäre. Aus diesem Grund betrachten wir die Modellauswahl als eine Einstellung innerhalb eines Betriebssystems und nicht als dessen Grundlage.

Wo die Kosten ins Spiel kommen

Der Modellpreis ist der sichtbarste und selten der größte Kostenfaktor. Wiederholungsversuche, übergroßer Kontext und ungenutzte Werkzeugdefinitionen machen regelmäßig mehr aus, und keine davon ändert sich, wenn Sie das Modell wechseln.

Aus diesem Grund misst der Optimierer die Modellauswahl, die Eingabeaufforderungsform und den Werkzeugsatz zusammen mit Ihren Bewertungen. Der Wechsel zu einem günstigeren Modell ist nur dann eine Ersparnis, wenn die Qualität Ihren eigenen Kriterien entspricht. Manchmal passiert es, und die Ersparnis ist real. Manchmal ist dies nicht der Fall, und Sie haben einen sichtbaren Preis gegen einen unsichtbaren eingetauscht.

Unsere eigentliche Empfehlung

Wählen Sie ein leistungsfähiges Modell aus, erstellen Sie Ihren Evaluierungssatz, ermitteln Sie die Kosten pro Agent und widmen Sie sich dann dem Abruf, den Tools, der Richtlinie und der Überprüfung. Besuchen Sie das Modell noch einmal, wenn Ihre Bewertungen es Ihnen sagen, und nicht, wenn eine neue Partitur veröffentlicht wird.

Das ist eine weniger spannende Antwort als eine Vergleichstabelle. Es ist dasjenige, das in den von uns beobachteten Bereitstellungen stabile Systeme hervorgebracht hat.

Als nächstes

Die Versionsseite deckt jede Generation des Yaju Agent Orchestration System und die jeweils hinzugefügten Elemente ab. Die Seiten zum Agent Orchestration System decken die Bewertungs- und Optimierungsebenen ab, die die Modellauswahl zu einer umkehrbaren Entscheidung machen.