Eine Demo überzeugt einen Raum. Sie überzeugt keinen Prüfer, und sie sollte auch Sie nicht überzeugen. “Sieht gut aus” ist ein Gefühl, das aus einer Handvoll Fragen entsteht, die jemand zufällig gestellt hat. In dem Moment, in dem ein System eine echte Entscheidung berührt, muss aus diesem Gefühl eine Zahl werden, die Sie verteidigen können, mit einer Methode dahinter. LLM-Evaluation im Finanzwesen ist die Disziplin, genau diese Zahl zu erzeugen.
Die meisten Teams überspringen sie, weil der Aufbau eines Evaluationssets langsamer ist als das Ausliefern. Dann gibt das System zum Quartalsende eine selbstbewusst falsche Antwort, und es fehlt jeder Nachweis, ob das ein Einzelfall war oder bereits der dritte Fehler dieser Art in diesem Monat. Die folgende Arbeit beschreibt, wie wir das vermeiden.
Wählen Sie die eine Kennzahl, die an der Entscheidung hängt
Bevor Sie irgendetwas messen, legen Sie fest, wofür das System tatsächlich da ist. Ein Werkzeug, das Zahlen aus Geschäftsberichten extrahiert, wird an der Extraktionsgenauigkeit gegenüber dem Quelldokument gemessen. Ein Werkzeug, das Abstimmungsdifferenzen markiert, wird am Recall gemessen, denn eine übersehene Differenz kostet mehr als ein Fehlalarm, den jemand in einer Sekunde verwerfen kann. Ein abrufgestützter Auskunftsassistent wird daran gemessen, ob die zitierte Passage die Aussage tatsächlich stützt.
Eine Kennzahl, gebunden an die Entscheidung, die das Ergebnis auslöst. Verfolgen Sie gerne sekundäre Werte, aber benennen Sie die eine, auf die Sie den Produktivstart setzen würden. Teams, die einen Korb aus vagen Scores berichten, weichen dieser Entscheidung meist nur aus.
Bauen Sie das Evaluationsset aus echten Fällen
Ein gutes Evaluationsset ist gelabelt, und es stammt aus Fällen, denen das System wirklich begegnen wird, nicht aus synthetischen Fragen, die ihm schmeicheln sollen. Wir greifen auf die reale Historie zurück: tatsächliche Geschäftsberichte, tatsächliche Abstimmungsdateien, tatsächliche Analystenfragen. Jeder Fall erhält eine Ground-Truth-Antwort, der ein Fachexperte zustimmt.
Die schwierigen Beispiele zählen mehr als die einfachen. Ein Evaluationsset, dem Finanzteams vertrauen können, umfasst:
- Grenzfälle: Restatements, geänderte Berichte, in Fußnoten ausgewiesene Zahlen, die der Schlagzeilenzahl widersprechen
- Adversariale Eingaben: mehrdeutige Entitätsnamen, fast identische Kontrahenten, Prompts, die zu einer selbstbewussten Vermutung verleiten, wo die ehrliche Antwort “nicht angegeben” lautet
- Bekannte Fehlerfälle: jeder Produktivfehler, zurück ins Set gefaltet, sodass er für immer mitgetestet wird
Besteht das Set nur aus Aufschlägen, die man bequem verwandeln kann, ist die resultierende Kennzahl reine Dekoration. Der Sinn ist, herauszufinden, wo das System bricht, solange Sie es noch günstig beheben können.
Messen Sie gegen den bestehenden Prozess
Eine Zahl bedeutet für sich genommen nichts. Der Bezugspunkt ist der Prozess, den das System ablöst. Wenn ein Junior-Analyst diese Zahlen heute mit 96 % Genauigkeit extrahiert, dann ist eine KI-Modellvalidierung, die 91 % zeigt, ein Rückschritt im Gewand des Fortschritts, so beeindruckend sich die Demo auch angefühlt haben mag.
Die Baseline-Kennzahlen aus dem bestehenden Workflow sind die Messlatte. Lassen Sie das Evaluationsset durch den aktuellen Prozess laufen, halten Sie den Score fest und messen Sie das neue System daran. Wenn es diese Latte nicht überspringt, ist es weitaus besser, das in Woche drei zu erfahren als nach sechs Monaten Entwicklung.
Trennen Sie Retrieval von Generierung
Wenn ein retrieval-augmentiertes System eine Antwort falsch beantwortet, gibt es zwei Verdächtige: Es hat den falschen Kontext geholt, oder es hat über dem richtigen Kontext schlecht geschlussfolgert. Verschmelzen Sie beides zu einem Score, können Sie nicht erkennen, was zu beheben ist.
Deshalb messen wir beides getrennt. Die Retrieval-Qualität fragt, ob die korrekte Passage unter dem Zurückgelieferten war. Die Generierungsqualität fragt, ausgehend von der korrekten Passage, ob die Antwort dieser treu ist. Ein System kann eine starke Ende-zu-Ende-Zahl ausweisen und dabei ein schwaches Retrieval verbergen, das in dem Moment versagt, in dem sich der Korpus verschiebt. Die getrennte Messung legt das offen.
Behalten Sie es als Regressionstest und als Artefakt
Das Evaluationsset ist kein einmaliges Tor. Jede Änderung am Prompt, an der Modellversion, am Retrieval-Index, am Chunking läuft vor der Auslieferung dagegen. Modellanbieter aktualisieren Gewichte, und das Verhalten driftet; eine stille Regression ist genau der Fehler, für dessen Abfangen eine Evaluation-Suite gebaut ist.
Es überdauert auch die Entwicklung. Im Rahmen der Erwartungen an Modellrisiko und Revision wird irgendwann jemand fragen, woher Sie wissen, dass das System funktioniert, und woher Sie es vor dem Go-live wussten. Ein versioniertes Evaluationsset, mit seinen Labels, den Scores gegenüber der Baseline und einer datierten Ergebnishistorie, ist eine direkte Antwort. Es speist Modellvalidierung und Konformitätsbewertung, statt Sie im Nachhinein Belege rekonstruieren zu lassen.
Nichts davon ist glamourös. Es ist der Unterschied zwischen einer Zahl, die Sie einer Aufsichtsbehörde vorlegen können, und einem Gefühl, das Sie aus einer Demo mitgenommen haben.