Wie Jev einen KI-Agenten effizienter macht
- Die Frage
- Kann ein kleines, günstiges Modell, das nur klassifiziert, entscheiden, was in den Kontext eines großen Modells gelangt, ohne die Leistung des Agenten zu verschlechtern?
- Ergebnis
- Ja, und es lohnt sich: im Durchschnitt 29 % günstiger, bei der besten Aufgabe 61 %, wobei in jedem Testarm 99 % der Qualitätsprüfungen bestanden wurden.
Was ich herausfinden wollte
Im Juli habe ich argumentiert, dass kleine Modelle entscheiden sollten, was große Modelle sehen, und abschließend festgestellt, dass die Wirtschaftlichkeit ein Grund für Experimente ist, aber noch kein Beweis für eine allgemeine Lösung.
Jev wurde am 15. September veröffentlicht. Es schreibt keinerlei Text, sondern gibt kalibrierte Wahrscheinlichkeiten für Antworten zurück, die im Code definiert sind, und kostet 0,042 $ pro Million Input-Token. Damit wurden zwei konkrete Versionen der Idee günstig genug, um sie tatsächlich zu messen, also habe ich sie getestet:
- Skills vorgeladen. Das Modell liest die Anfrage und die einzeilige Beschreibung jedes internen Dokuments und injiziert die relevanten Informationen vor dem ersten Zug des Agenten, sodass dieser keinen Roundtrip für das Abrufen benötigt.
- Tool-Payload filtern. Das Modell bewertet jedes Feld einer API-Antwort und entfernt diejenigen, auf die der Agent nicht reagieren wird, bevor sie in das Kontextfenster gelangen und in jedem weiteren Zug erneut gesendet werden.
Beides sind Klassifizierungsprobleme. Keines davon benötigt ein Modell, das schreiben kann.
Wie getestet wurde
Ein fiktives B2B-SaaS mit 17 Tools, deren Payloads die Struktur von Stripe, Zendesk, HubSpot und einem Help-Centre-CMS widerspiegeln, 11 interne Richtliniendokumente (von denen einige irrelevant sind) und 8 Aufgaben, die zwei Achsen abdecken: die Anzahl der Züge und der Anteil an Rauschen im Payload.
Vier Testarme, jeweils sechs Wiederholungen, 192 Durchläufe. Die Bewertung ist deterministisch: 59 Prüfungen, wobei jede entweder ein Tool-Aufruf mit exakten Argumenten oder eine Tatsache ist, die nur in einem Richtliniendokument vorkommt. Es gibt keinen LLM-Judge, sodass die Frage “hatte der Agent tatsächlich Zugriff auf die Richtlinie” messbar und nicht diskutabel ist.
Die Ergebnisse
Durchschnittskosten eines Agenten-Runs, basierend auf Claude Opus 5
Der Durchschnitt ist 29 % günstiger. Bei der besten Aufgabe 61 %, bei der schlechtesten 13 %. Die Anzahl der Züge sinkt von 4,44 auf 3,71, und die frischen Input-Token, die teure Sorte, sinken um 49 %.
Die beiden Mechanismen reagieren auf völlig unterschiedliche Faktoren. Das ist wichtiger als der Durchschnitt, wenn man entscheiden muss, welchen man einsetzt:
Vorladen reagiert auf entbehrliche ZügeNicht auf Payload-Größe
- Am effektivsten, wenn eine Aufgabe eine Richtlinie benötigt und ein Zug für das Abrufen aufgewendet würde
- Wertlos, wenn keine Richtlinie anwendbar ist
- Kann ins Negative wirken: ein falsch geladenes Dokument wird in jedem Zug erneut gesendet
Filterung reagiert auf Payload-DichteNicht auf Aufgabenlänge
- Am effektivsten, wenn die meisten Bytes aus Text bestehen, den niemand liest
- Nahe Null, wenn jedes Feld essenziell ist
- Kumulativer Effekt, da ein entferntes Feld im nächsten Zug nicht erneut gesendet wird
Mein Fazit
Ein Feld ist nicht an sich nützlich. Es ist nützlich für das, was der Agent damit tun wird, und diese Information steckt nicht im Payload. Wenn man dem Scorer mitteilt, welche Tools der Agent noch aufrufen kann, steigt der Wert des Feldes, von dem die Aufgabe abhängt, von 0,18 auf 0,73, während die Anzahl der behaltenen Felder von 51 auf 27 sinkt. Ein reichhaltigerer Kontext macht den Filter gleichzeitig sicherer und aggressiver.
Der Preis Ihres Hauptmodells entscheidet, ob Filterung sich lohnt. Sie kostet eine feste Anzahl günstiger Token und spart eine variable Anzahl teurer Token, wodurch sich das Vorzeichen dreht. Bei einem Modell für 0,20 $ pro Million kostet sie 21 % mehr, als sie einspart; bei Opus 5 spart sie 29 %. Der Schnittpunkt liegt bei etwa 0,55 $ pro Million bei aktiviertem Prompt-Caching.
Ein entferntes Feld erzeugt keinen Fehler. Es erzeugt eine selbstbewusst falsche Antwort. Eine frühe Version entfernte eine Account-ID und deren Duplikat, woraufhin der Agent die einzige verbliebene Kennung nutzte, die jedoch zum falschen Objekt gehörte, und darüber einen sauberen Bericht erstellte. Alles, was in Produktion geht, benötigt definierte kritische Pfade und einen darauf kalibrierten Schwellenwert.
Hier wurden zwei Ausgangspunkte getestet. Die Entscheidung, welche Dateien ein Agent öffnet, wann ein Gespräch komprimiert wird oder das Prüfen eines Schreibvorgangs vor dessen Ausführung: Nichts davon wurde gemessen, und ich würde nicht davon ausgehen, dass es funktioniert, bis es bewiesen ist.