Spekulatives Fan-out: einem Entscheidungsmodell alle Fragen in einer Anfrage stellen und im Code entscheiden

Worum es geht

Eine Anfrage an die TypeSafe-API trägt einen Zustand und eine Zuordnung von Fragen. Die Dokumentation hält fest, dass jede Frage parallel und isoliert gegen denselben Zustand ausgewertet wird, dass das Hinzufügen von Fragen die Antwortzeit kaum verändert und dass das Hinzufügen von Fragen keinen Context Rot erzeugt, weil keine Frage die Antwort einer anderen sieht. Das Fan-out-Muster folgt daraus: Statt zuerst die Kategorie zu erfragen und dann in einem zweiten Aufruf, sobald die Kategorie bekannt ist, den Schweregrad, beides auf einmal erfragen und den Schweregrad nur lesen, falls sich die Kategorie als Fehlermeldung herausstellt.

Warum es wichtig ist

Sequenzielle Entscheidungsketten in einer Agentenschleife kosten einen Round-Trip je Hop, und jeder Hop ist eine Stelle, an der ein teilweiser Fehlschlag den Arbeitsablauf halb entschieden zurücklässt. Eine Anfrage mit allen Fragen hat eine Latenz, einen Fehlermodus und einen Protokolleintrag. Das Kochbuch des Anbieters zu parallelen Fragen lässt ein dreizehnfragiges regulatorisches Briefing über den Wikipedia-Artikel zur DSGVO laufen und berichtet, dass das Bündeln aller Fragen in einen Aufruf 12,2-mal günstiger und 10,0-mal schneller war als getrennte Aufrufe, ohne Änderung an den Antworten; die Modellseite hält fest, dass der Zustand einmal je Anfrage eingelesen und jede Frage dagegen ausgewertet wird, woher der Kostenunterschied zwischen einer Anfrage und vielen stammt, da die Preisgestaltung je Input-Token erfolgt.

So wird es angewendet

• Jede Frage sammeln, die ein Arbeitsablauf für einen gegebenen Zustand brauchen könnte, einschliesslich spekulativer Fragen für Zweige, die vielleicht nicht eingeschlagen werden, und sie zusammen senden.
• Die Fragen danach benennen, was sie entscheiden, und sie im Code in der vom Arbeitsablauf benötigten Reihenfolge lesen; Antworten ignorieren, deren Vorbedingung nicht zutraf.
• Den Zustand auf das beschränken, was die Fragen brauchen. Fan-out vervielfacht den Wert eines schlanken Zustands, und das Budget beträgt 64k Token für Zustand plus alle Fragen, mit 32k für Zustand plus die längste Frage.
• Denselben Zustand für alle Fragen verwenden; brauchen zwei Entscheidungen unterschiedliches Material, sind das zwei Anfragen, nicht ein grosser Zustand.
• Die gesamte Antwort protokollieren, damit eine spätere Frage, warum ein Zweig eingeschlagen wurde, aus den erfassten Wahrscheinlichkeiten beantwortet werden kann.

Stolpersteine

Unabhängigkeit wirkt in beide Richtungen: Eine Folgefrage kann innerhalb derselben Anfrage nicht von einer früheren Antwort abhängen, sodass eine tatsächlich bedingte Frage (Schweregrad eines Fehlers, gegeben, dass es ein Fehler ist) unbedingt gestellt und danach gefiltert wird. Antworten auf Fragen, deren Vorbedingung falsch ist, sind weiterhin reale Ausgaben mit realen Wahrscheinlichkeiten; sie als Rauschen behandeln, nicht als Beleg. Die Faktoren des Kochbuchs sind die eigenen Zahlen des Anbieters zu seinem eigenen Beispiel.