Viele Fragen in einer Jev-Anfrage: das Fan-out-Muster in der Praxis

Die Dokumentation von TypeSafe enthält ein Muster namens spekulatives Fan-out. Statt einer Kette von Aufrufen, in der die zweite Frage auf das Ergebnis der ersten wartet, erhält Jev alle Fragen in einer einzigen Anfrage, auch solche, deren Antwort am Ende vielleicht gar nicht verwendet wird. Was für den jeweiligen Fall wichtig ist, entscheidet erst Ihr Code. S74 Für einen Onlineshop, der täglich Hunderte Nachrichten sortiert, bedeutet das weniger Warten auf das Netz und einfacheren Code. Das Muster hat jedoch Grenzen, zu denen die Seite schweigt.

So sieht das Beispiel aus der Dokumentation aus

Das Beispiel sortiert Tickets des Kundensupports. Eine Anfrage enthält den Tickettext und fünf Fragen: Choice category (im Code kommen die Werte bug_report, billing und feature_request vor), Score bug_severity, Noul has_reproducible_steps, Noul refund_requested und Score frustration. Schwere des Fehlers und beschriebene Schritte zu seiner Reproduktion sind nur bei Fehlermeldungen sinnvoll, die Frage nach einer Rückerstattung nur bei Abrechnungsthemen, und die Frustration prüft der Code bei jedem Ticket. S74

Danach verzweigt der Code. Eine Fehlermeldung mit einem Schweregrad über 1,5 und einer Wahrscheinlichkeit beschriebener Schritte über 0,6 geht an die Entwickler, andere Meldungen landen in der Fehlerliste. Ein Abrechnungsticket mit einer Wahrscheinlichkeit für einen Erstattungswunsch über 0,7 erhält eine Markierung, ein Funktionswunsch wird nur protokolliert, und eine Frustration über 1,5 bedeutet eine bevorzugte Antwort unabhängig von der Kategorie. S74

Die Dokumentation stellt das Muster einem Vorgehen gegenüber, bei dem zuerst die Kategorie ermittelt und der Schweregrad mit einem weiteren Aufruf ergänzt wird. Wird eine spekulative Antwort gebraucht, entfällt der zweite Aufruf; wird sie nicht gebraucht, lässt der Code sie einfach ungenutzt. S74

Was das Muster verspricht und was es nicht angibt

Laut Dokumentation werden die Fragen parallel ausgewertet, sodass weitere Fragen die Antwortzeit in der Regel kaum verlängern. S74 Es handelt sich um eine Herstellerangabe; die Seite nennt dazu keine Messwerte. S74 Die API-Beschreibung ergänzt, dass sich alle Fragen einer Anfrage auf einen gemeinsamen state beziehen und dass Fragetypen in einer Anfrage gemischt werden können. Eine Höchstzahl von Fragen pro Anfrage nennt die API-Beschreibung nicht. S75

Bei den Kosten ist Vorsicht geboten. TypeSafe berechnet Eingabe-Token, bei Jev 1.14 wie 1.13 mit 0,042 USD pro Million, und Ausgabe-Token sind derzeit kostenlos. S01 Den Verbrauch meldet die Antwort in einem einzigen usage-Objekt für die gesamte Anfrage, nicht pro Frage. S75 Weder die Seite zum Muster noch die API-Beschreibung erklären jedoch, um wie viele Eingabe-Token jede weitere Frage eine Anfrage verlängert. S74 S75 Aus der Logik des Musters folgt, dass Sie den gemeinsamen Text einmal statt in mehreren getrennten Aufrufen senden; die tatsächliche Ersparnis sollten Sie aber anhand des Werts input_tokens mit eigenen Daten prüfen. Bei der Kostenschätzung hilft der Kostenrechner.

Außerdem gelten Größenlimits. Standardmäßig sind es 64k Token pro Anfrage und 32k pro Frage; mit dem Header TypeSafe-Danger-Zone-Long-Context: true steigen beide Grenzen auf 262k. S01 Weitere Details beschreibt der Leitfaden Preise und Limits.

Die Schwellenwerte im Beispiel sind keine Empfehlung

Die Werte 1,5, 0,6 und 0,7 dienen im Beispiel nur der Veranschaulichung. Bei einer Score-Frage ist das Ergebnis ein gewichteter Durchschnitt der Stufennummern, die ab null gezählt werden; bei drei Stufen reicht der Score also von 0 bis 2. S04 Die Fan-out-Seite gibt nicht an, wie viele Stufen bug_severity und frustration haben. S74 Die Bedeutung des Schwellenwerts 1,5 lässt sich dem Beispiel daher nicht entnehmen: Bei drei Stufen liegt er nahe am oberen Ende der Skala, bei fünf (0 bis 4) unter ihrer Mitte. Das ist unsere eigene Berechnung, keine Herstellerangabe.

Für Noul-Fragen schlägt die Dokumentation vor, mit einem Schwellenwert von 0,7 für Ja und 0,3 für Nein zu beginnen und die Werte dann an die eigenen Ergebnisse anzupassen. S06 Wie man Schwellenwerte festlegt und überprüft, erläutert der Leitfaden Confidence und Kalibrierung.

Im Beispiel fehlt außerdem ein Zweig für ein Ticket, das in keine der drei Kategorien im Code fällt. S74 Für den Produktivbetrieb empfehlen wir, einen solchen Zweig zu ergänzen und diese Fälle an einen Menschen zu übergeben.

Die Falle: ein gemeinsamer State für alle Fragen

Fan-out verleitet dazu, alles, was irgendeine Frage braucht, in einen einzigen state zu packen. Die Seite zu den Schwächen von Jev 1.13, zuletzt am 2. Oktober 2026 überprüft, warnt jedoch, dass die Genauigkeit sinkt, wenn der State um Inhalte wächst, die mit der Entscheidung nichts zu tun haben. Sie empfiehlt, im Code vorab nur die Felder auszuwählen, die die Frage braucht. S07 Die Seite betrifft Version 1.13; eine eigene Übersicht der Schwächen für 1.14 haben wir in der Dokumentation nicht gefunden.

Unser Vorschlag: Fassen Sie in einer Anfrage Fragen zusammen, die mit derselben Eingabe arbeiten, etwa mit dem Text einer einzelnen Nachricht. Braucht eine Frage andere Daten, zum Beispiel die Bestellhistorie, senden Sie sie separat mit einem eigenen, kürzeren State.

Was das für einen slowakischen Onlineshop bedeutet

Nehmen wir die Nachricht „Balík neprišiel, chcem peniaze späť.“ („Das Paket ist nicht angekommen, ich will mein Geld zurück.“) Nach dem Muster kann eine Anfrage eine Choice-Frage zur Absicht der Nachricht, eine Noul-Frage zum Erstattungswunsch und eine Score-Frage zum Grad der Unzufriedenheit enthalten. Der Code baut aus den Antworten den weiteren Ablauf: Die Absicht bestimmt die Warteschlange, die Erstattungswahrscheinlichkeit entscheidet über eine Markierung für die Buchhaltung, und hohe Unzufriedenheit rückt die Nachricht nach vorn. Diese Arbeitsteilung zwischen Modell und Code entspricht dem Beispiel aus der Dokumentation. S74 Ausführlicher haben wir das Routing von Nachrichten nach Absicht im Artikel über das Sortieren von Kundennachrichten beschrieben.

Zwei Dinge sollten Sie jedoch selbst prüfen. Die Dokumentation des Musters sagt nichts über Slowakisch, legen Sie Schwellenwerte daher erst anhand einer Stichprobe eigener Nachrichten fest; das Vorgehen beschreibt der Leitfaden Slowakisch testen. Und weil der Code das Ergebnis aus mehreren getrennten Antworten zusammensetzt, sollten Sie auch auf Fälle vorbereitet sein, in denen sie einander widersprechen. Wie Antworten auf verwandte Fragen auseinandergehen können, haben wir im Artikel zur Übereinstimmung zwischen Choice und Noul besprochen.