Model-Routing und Fallback für Kosten und Zuverlässigkeit

Routing schickt jede Anfrage an das günstigste Modell, das sie korrekt beantworten kann, und fällt auf ein anderes Modell zurück, wenn das erste ausfällt oder degradiert. Eine Cascade eskaliert anhand der Qualität: Ein kleines Modell antwortet, und nur Fälle mit geringer Confidence steigen zu einem größeren auf. Fallback behandelt operatives Versagen: Ein Timeout oder ein Rate Limit leitet auf einen gesunden Provider um. Die meisten Finanz-Workloads brauchen beides.

Der Reflex, wenn eine Workload live geht, ist, das stärkste Modell zu wählen und alles darauf zu richten. Im Demo funktioniert das und es lässt sich einfach durchdenken. Es ist zugleich das teuerste und am wenigsten zuverlässige Design, das Sie ausliefern können. Das starke Modell ist langsam, es rate-limitet unter einem Quartalsend-Peak, und Sie zahlen Frontier-Preise dafür, zu klassifizieren, ob ein Dokument eine Rechnung oder ein Remittance Advice ist. Genau diese Aufgabe erledigt ein deutlich kleineres Modell korrekt, und schneller.

Der Sinn von Routing ist, damit aufzuhören, einen heterogenen Strom von Anfragen so zu behandeln, als verdiene jede einzelne dieselbe Compute-Leistung. In einer Finanzoperation ist der Strom tatsächlich heterogen. Felder aus einem sauberen, strukturierten Kontoauszug zu extrahieren ist nicht dasselbe Problem wie drei Quellen abzustimmen, die einander widersprechen, und keines davon ist dasselbe wie das Verfassen eines Narrativs, das ein Freigebender abzeichnet.

Klassifizieren Sie die Anfrage, bevor Sie das Modell wählen

Routing beginnt mit einer günstigen Entscheidung über die Anfrage, getroffen bevor irgendein teures Modell läuft. Sie beantworten zwei Fragen: Wie schwer ist dieser Aufruf, und wie viel kostet hier eine falsche Antwort.

Die Schwierigkeit lässt sich oft ganz ohne Modell direkt aus dem Input ablesen. Länge, Struktur, das Vorhandensein von Tabellen, die Anzahl der Quellsysteme, die die Antwort berühren muss. Ein einzelnes wohlgeformtes PDF ist nicht derselbe Job wie ein Bündel gescannter Anhänge. Wo eine Regel nicht ausreicht, liefert ein kleiner Classifier oder ein kurzes lokales Modell für den Bruchteil eines Cents einen Schwierigkeitsscore.

Die Fehlerkosten sind der Punkt, an dem sich Finanzarbeit vom allgemeinen Chat-Routing unterscheidet. Manche Outputs werden einmal gelesen und verworfen. Andere gehen in eine Zahlungsdatei, ein Hauptbuch oder eine Verdachtsmeldung ein, und eine falsche Zahl dort hat Folgen weit über die API-Rechnung hinaus. Solche Fälle routen Sie zu einem stärkeren Modell und auf einen aufwendigeren Verifikationspfad, egal wie leicht der Input aussieht. Routen Sie über beide Achsen:

• Geringe Schwierigkeit, geringe Stakes: kleinstes Modell, keine Verifikation. Feldextraktion aus sauberen Dokumenten, offensichtliche Klassifikationen.
• Hohe Schwierigkeit, geringe Stakes: mittleres oder großes Modell. Zusammenfassungen und Entwürfe, die ein Mensch prüft, bevor irgendetwas passiert.
• Beliebige Schwierigkeit, hohe Stakes: stärkstes Modell plus eine unabhängige Prüfung der Zahlen. Alles, was in ein Hauptbuch schreibt, Geld bewegt oder in eine aufsichtsrechtliche Meldung einfließt.

Halten Sie den Router selbst langweilig. Regeln, wo Sie sie formulieren können, ein kleines Modell, wo nicht, und jede Entscheidung geloggt mit einem Hash des Inputs, damit Sie nachspielen können, warum eine Anfrage wohin ging. Der Router liegt für jeden Aufruf auf dem kritischen Pfad, also darf er nicht der langsame oder wackelige Teil sein.

Cascade für Qualität, und wissen, wann sie sich nicht mehr auszahlt

Eine Cascade lässt zuerst das günstige Modell laufen und eskaliert nur, wenn die Antwort nicht gut genug ist. Die gesamte Ingenieurskunst steckt im Wort “genug”. Sie brauchen ein Signal dafür, dass ein kleines Modell danebenlag, berechnet ohne das große Modell, das Sie gerade vermeiden wollen.

Nützliche Signale im Finanzkontext sind konkret statt gefühlt. Stimmt eine extrahierte Summe mit der Summe der Einzelposten überein. Passt ein ausgewiesener Saldo zum Quelldokument. Hat das Modell gültiges JSON gegen das Schema zurückgegeben. Liegt die berichtete Confidence, oder die Token-Level-Wahrscheinlichkeit auf den Feldern, die zählen, unter einem Schwellenwert, den Sie aus einem Eval-Set festgelegt statt geraten haben. Wenn die günstige Antwort diese Prüfungen besteht, behalten Sie sie. Wenn nicht, eskalieren Sie.

Die Zahl, die Ihnen sagt, ob sich die Cascade ihren Platz verdient, ist die Eskalationsrate auf realem Traffic. Wenn neun von zehn Aufrufen auf der günstigen Stufe abschließen, ist die Ökonomie exzellent. Wenn die Hälfte davon zum teuren Modell aufsteigt, zahlen Sie für zwei Inferenzen plus die Prüfung, um eine Antwort zu bekommen, und Sie wären besser dran, diese Input-Klasse direkt zum starken Modell zu routen. Messen Sie das pro Input-Typ, nicht aggregiert, denn eine gesunde Gesamtrate kann einen Dokumententyp verstecken, der fast jedes Mal eskaliert. Dieser Dokumententyp gehört auf eine direkte Route.

Justieren Sie die Eskalationsschwellen gegen ein gelabeltes Eval-Set mit einem False-Positive-Budget, das Sie mit dem Business vereinbart haben, genau so, wie Sie einen Fraud-Score justieren würden. Zu eifriges Eskalieren verbrennt die Ersparnisse. Zu seltenes Eskalieren lässt falsche Antworten durch. Keines von beidem ist eine Einstellung, die Sie per Intuition finden.

Fallback hält die Workload am Laufen, wenn ein Provider ausfällt

Fallback deckt das Modell ab, das gut geantwortet hätte, aber nie die Chance dazu bekam. Der Provider rate-limitet Sie, eine Region ist down, die Latenz hat Ihr Budget gesprengt, oder ein Deploy auf deren Seite hat das Verhalten über Nacht verändert. Nichts davon dreht sich darum, welche Antwort besser ist. Es geht darum, oben zu bleiben.

Bauen Sie es als Klempnerei:

• Setzen Sie ein hartes Timeout und ein Retry-Budget pro Aufruf. Wenn beide erschöpft sind, ziehen Sie weiter, statt die Queue hängen zu lassen.
• Halten Sie ein zweites Modell bereit, idealerweise von einem anderen Provider, das dieselbe Anfrage mit demselben Prompt-Contract und Schema bedienen kann. Wenn ein Wechsel Prompt-Chirurgie braucht, ist es kein Fallback, dem Sie um drei Uhr morgens vertrauen können.
• Nutzen Sie einen Circuit Breaker. Nach einer Serie von Fehlern hören Sie auf, das primäre Modell zu hämmern, schicken Traffic zum sekundären und prüfen das primäre leise, bevor Sie zurückkehren.
• Degradieren Sie bewusst für den High-Stakes-Pfad. Wenn beide Modelle unerreichbar sind, sollte ein zahlungsrelevanter Aufruf für menschliche Bearbeitung in die Queue gehen, nicht raten. Stilles Best-Effort ist der falsche Default, wenn Geld fließt.

Die beiden Designs komponieren. Der Router entscheidet, wohin eine Anfrage gehen soll, die Cascade entscheidet, ob die günstige Antwort hält, und Fallback entscheidet, was zu tun ist, wenn das vorgesehene Modell nicht antworten will. Halten Sie sie als getrennte Schichten, damit Sie über jede einzeln nachdenken können. Und loggen Sie den gesamten Pfad für jede Anfrage, denn wenn eine Finanzzahl Wochen später hinterfragt wird, muss die Antwort auf “welches Modell hat das produziert und warum” aus einem Record kommen, nicht aus einer Rekonstruktion. In einer Workload, die Hauptbücher und Meldungen berührt, ist dieser Audit-Trail Teil des Produkts und nicht Overhead, den man später kürzt.