Function Calling in Finanz-Workflows zuverlässig machen

Ein Modell, das das falsche Tool mit den falschen Argumenten aufruft, ist ein Produktionsvorfall, keine schlechte Antwort. Function Calling wird im Finanzumfeld zuverlässig, indem Sie jedes Tool als typisierten Vertrag behandeln, Argumente vor der Ausführung sowohl gegen ein Schema als auch gegen Ihre Geschäftsregeln validieren, das bereitgestellte Tool-Set klein und eindeutig halten und die Aufrufgenauigkeit auf einem festen Eval-Set genauso messen, wie Sie ein Modell messen.

Die meisten Teams bringen die Demo zum Laufen und gehen davon aus, dass der schwierige Teil erledigt ist. Die Demo funktioniert, weil die Eingabe sauber und die Tool-Liste kurz war. Der Vorfall passiert drei Wochen später, zum Quartalsende, wenn ein Reconciliation-Agent post_adjustment statt stage_adjustment aufruft, weil beide Beschreibungen “Adjustment” erwähnen und das Modell geraten hat. Niemand hat einen falschen Satz geschrieben. Eine Buchung ist im Ledger gelandet, die auf die Prüfung hätte warten sollen.

Die Fehlermodi sind langweilig, und genau darum geht es

Function Calling in einem Finanz-Workflow scheitert auf eine kleine Zahl vorhersehbarer Weisen, und keine davon sieht aus wie die Halluzinationsgeschichten, über die sich die Leute Sorgen machen.

• Richtiges Tool, falsches Argument. Das Modell ruft get_positions auf, übergibt aber as_of als heutiges Datum, obwohl der Workflow den vorherigen Geschäftstag brauchte. Der Aufruf gelingt. Die Zahl stimmt nicht. Das ist ein Point-in-Time-Korrektheitsfehler im Kostüm einer erfolgreichen API-Antwort.
• Falsches Tool, plausibler Name. Zwei Tools mit sich überschneidenden Beschreibungen, und das Modell wählt jenes, das dem Prompt am nächsten liest. Namenskollisionen verursachen mehr Fehlaufrufe als Reasoning-Fehler.
• Wohlgeformt, außerhalb der Policy. Die Argumente validieren gegen das JSON-Schema und verletzen dennoch eine Regel, die das Schema nicht kodiert: ein Transfer oberhalb eines Schwellenwerts, eine Gegenpartei auf einer Sperrliste, ein Datum außerhalb der offenen Periode.
• Stille Koerzierung. Das Modell gibt "1.250,00" aus, und etwas weiter unten parst es das je nach Locale als 1 oder 1250. Die String-zu-Zahl-Koerzierung an einer Tool-Grenze ist der Ort, an dem sich Geldbeträge unbemerkt um drei Größenordnungen verändern.

Der Grund, diese aufzuzählen, ist, dass jeder davon eine spezifische Kontrolle hat. Sie beheben sie nicht mit einem besseren Prompt. Sie beheben sie mit Struktur rund um den Aufruf.

Behandeln Sie jedes Tool als typisierten Vertrag, dann validieren Sie zweimal

Beginnen Sie damit, die Argumentfläche so eng zu machen, wie die Aufgabe es zulässt. Wenn ein Tool eine Bewertung abruft, sollten seine Parameter eine Instrumentenkennung und ein aufgelöster Point-in-Time-Zeitstempel sein, kein Freitext-Query, das das Modell komponieren muss. Jeder Freiheitsgrad, den Sie dem Modell überlassen, ist ein Freiheitsgrad, den es falsch machen kann. Enumerationen schlagen freie Strings. Ein geschlossenes Set von report_period-Werten, aus dem das Modell wählt, kann nicht auf die Weise abdriften, wie es ein von ihm konstruierter Datums-String tut.

Dann validieren Sie in zwei Schichten, denn sie fangen unterschiedliche Dinge ab.

• Strukturelle Validierung. Die Argumente müssen zum JSON-Schema passen: Typen, Pflichtfelder, Formate, Enum-Zugehörigkeit. Das ist billig, deterministisch und verwirft die fehlerhaft geformten Aufrufe, bevor sie ein System erreichen, das etwas kostet. Verwerfen Sie sie und geben Sie den Fehler an das Modell zurück, damit es mit der Korrektur im Kontext erneut versuchen kann.
• Semantische Validierung. Die Argumente müssen Geschäftsregeln erfüllen, die das Schema nicht ausdrücken kann. Liegt das as_of-Datum innerhalb einer offenen Buchungsperiode? Ist die Entität zu einer einzigen, eindeutigen Gegenpartei aufgelöst und nicht ein Fuzzy-Match über drei Schreibweisen hinweg? Liegt der Betrag innerhalb der Befugnis dessen, der die Anfrage ausgelöst hat? An diesen Prüfungen werden Entity Resolution und Point-in-Time-Korrektheit tatsächlich durchgesetzt.

Ein wohlgeformtes Argument, das die semantische Validierung nicht besteht, ist der gefährliche Fall, weil das Schema Ja gesagt hat. Halten Sie diese beiden Schichten in Ihrem Code getrennt, damit die semantische Schicht lesbar und prüfbar bleibt für jemanden aus der Controls-Seite, der Ihre Typdefinitionen nicht liest.

Eine weitere Regel, an der wir festhalten: Mutierende Tools und lesende Tools leben in unterschiedlichen Ebenen. Ein Read, das die falsche Zahl zurückgibt, ist ein Bug, den Sie weiter unten abfangen. Ein Write, das bucht, transferiert oder freigibt, hinterlässt eine Spur. Alles, was den Zustand verändert, sollte einen expliziten, validierten Bestätigungsschritt erfordern und sollte niemals im selben ungeschützten Aufrufpfad erreichbar sein wie ein Lookup.

Halten Sie das Tool-Set klein und entschärfen Sie die Überlebenden

Die Modellgenauigkeit bei der Tool-Auswahl verschlechtert sich, je größer die Tool-Liste wird und je stärker sich die Beschreibungen überschneiden. Der Instinkt, fünfzig Fähigkeiten an einer Aufrufstelle bereitzustellen, ist derselbe Instinkt, der Fehlaufrufe des falschen Tools produziert.

• Routen Sie zuerst, präsentieren Sie dann eine Handvoll. Klassifizieren Sie die Anfrage in einen Workflow und stellen Sie nur die Tools bereit, die dieser Workflow braucht. Ein Reconciliation-Agent muss die Onboarding-Tools nicht sehen.
• Schreiben Sie Beschreibungen, die den Kontrast zwischen Tools herausarbeiten. Wenn Sie stage_adjustment und post_adjustment haben, sollte die Beschreibung jedes Tools sagen, was das andere tut und wann man nicht danach greifen sollte. Das Modell entschärft anhand des Textes, den Sie ihm geben.
• Bevorzugen Sie ein parametrisiertes Tool gegenüber fünf Fast-Duplikaten, wenn der Unterschied ein Argument ist und keine Fähigkeit. Fünf Tools, die sich nur nach Berichtstyp unterscheiden, laden zu Auswahlfehlern ein; ein Tool mit einem report_type-Enum tut das nicht.

Messen Sie die Aufrufgenauigkeit, wie Sie ein Modell messen

Sie würden keinen Classifier ohne Eval-Set ausliefern. Ein Function-Calling-System ist ein Classifier über Ihren Tool-Raum plus ein Argumentgenerator, und es verdient dieselbe Disziplin.

Bauen Sie ein festes Set von Fällen, die eine Eingabe auf das exakte Tool und die Argumente abbilden, die daraus resultieren sollten. Nehmen Sie die adversarialen mit auf: die mehrdeutige Entität, die geschlossene Periode, den Betrag einen Cent über dem Schwellenwert, die Anfrage, die überhaupt kein Tool aufrufen sollte. Bewerten Sie exakten Tool-Match und Argumentkorrektheit getrennt, denn ein System, das das richtige Tool mit einem falschen Datum wählt, scheitert anders als eines, das das falsche Tool wählt.

Führen Sie das bei jeder Modelländerung, jeder Prompt-Änderung und jeder Tool-Erweiterung aus. Achten Sie auf Drift, wenn ein Anbieter ein Modell unter Ihnen aktualisiert, denn das Verhalten der Tool-Auswahl verschiebt sich auf Weisen, die einen Smoke-Test bestehen und Ihren Closed-Period-Fall durchfallen lassen. Halten Sie ein False-Positive-Budget für die mutierenden Tools und bleiben Sie hart dabei. Der ganze Sinn von Straight-Through Processing ist, dass die Ausnahmen an einen Menschen geroutet werden, und Sie können Ihre Ausnahmequote nicht kennen, ohne die Aufrufe zu messen, die sie erzeugt haben.

Der Audit-Trail ergibt sich hieraus ganz natürlich, wenn Sie es richtig machen. Jeder Aufruf trägt seine aufgelösten Argumente, die Validierungsergebnisse beider Schichten und das Resultat. Wenn in sechs Monaten jemand fragt, warum an einem Dienstag ein Adjustment gebucht wurde, ist die Lineage bereits vorhanden, um sie nachzulesen.