Eine Anfrage nach ihrem Einsatz zu routen, gelingt nur, wenn der Router den Einsatz sieht
Victoria Shinder2 Min. LesezeitCloudflare hat diesen Monat einen Modell-Router in die öffentliche Beta gebracht: Man setzt das Modell auf cloudflare/auto, und ein Klassifikator wählt je Anfrage eines aus. Er bewertet sie von eins bis fünf nach Komplexität, Mehrdeutigkeit, Einsatz und Abhängigkeit vom früheren Kontext und verrechnet das mit Benchmark-Zahlen nach einer schlichten Formel — Nutzen gleich erwartete Qualität minus adaptiver Kostenstrafe. Das Entwaffnendste an der Ankündigung: Cloudflare veröffentlichte einen Benchmark, in dem der eigene Router gegen ein starkes festes Modell verliert. Diese Ehrlichkeit ist den Eintrittspreis wert, und sie zeigt direkt auf die wahre Schwäche des Entwurfs.
Der Klassifikator liest nur die jüngsten Züge, begrenzt auf acht Kilobyte. Ein Tech Lead, der Banken- und Gesundheitsplattformen gebaut hat, benannte das Problem in einem Satz: In einer langen Sitzung sagt ein Nutzer früh "das ist eine Kundenerstattung" und viele Züge später nur noch "mach weiter". Die Anweisung, die das Geld bewegt, ist der kürzeste, blasseste Zug des Gesprächs — und auf einen Blick, der die letzten Züge bevorzugt, wirkt sie billig, einsatzarm, sicher für das kleine Modell. Der Zug, der den Schaden anrichtet, ist genau der, den der Router am schlechtesten erkennt.
Sein Lösungsvorschlag hat die richtige Form, und es ist nicht Cloudflares Aufgabe, ihn umzusetzen: ein anwendungseigenes Risikolabel über die ganze Sitzung mitzuführen, gesetzt, sobald die Erstattung erstmals genannt wird, und damit zu entscheiden, ob eine Anfrage cloudflare/auto überhaupt berühren darf. Eine kurze Schlussanweisung darf die Risikoklasse der darunterliegenden Handlung nicht stillschweigend senken. Das ist eine Aussage darüber, wo die Verantwortung sitzt. Der Router kann den Einsatz aus Text schätzen; nur die Anwendung weiß, dass dieses Gespräch befugt ist, Geld zu bewegen, und dieses Wissen lässt sich aus den letzten acht Kilobyte nicht rekonstruieren.
Es gibt kleinere Fallen, die man nennen sollte. Die Routing-Gewichte stammen aus Benchmark-Ergebnissen, ein neues Modell routet also erst gut, wenn jemand es von Hand in die Bewertungsmatrix einträgt — der Klassifikator ist nur so aktuell wie seine letzte Kalibrierung, eine unangenehme Eigenschaft in einem Markt, in dem Modelle monatlich erscheinen. Ohne Sitzungs-ID können Anfragen eines Gesprächs auf verschiedenen Modellen landen und den Prompt-Cache verlieren; Cloudflare erhebt eine Wechselstrafe, die mit dem Kontext wächst, weil ein neues Modell Schlussfolgern zu Ausgabepreisen wiederholen kann. Und der Standard-Pool ist nicht der Pool des Schlagzeilen-Benchmarks; die beiden Modelle, die den Router schlagen, liegen in einer Opt-in-Liste — wer die Zahlen nachstellt, sollte prüfen, was sein Gateway tatsächlich wählt.
Nichts davon macht automatisches Routen zur schlechten Idee. Die Einheit, die zählt, ist die Aufgabe, nicht die Anfrage — ein billigeres Modell spart nichts, wenn jemand eine Stunde mit dem Nachbessern verbringt — und ein Router, der Schwierigkeit bewertet und bepreist, ist ein vernünftiger Weg dorthin. Doch die ehrliche Lesart dieses Starts lautet: Routen nach Einsatz verschiebt das schwere Problem, statt es zu lösen. Man muss immer noch entscheiden, was auf dem Spiel steht, und der einzige Ort, an dem diese Entscheidung richtig fällt, liegt über dem Router — in der Anwendung, die weiß, wozu das Gespräch dient.