Structured Output für Finanzdaten JSON statt Freitext-Chaos.

Ein Sprachmodell, das auf die Frage nach dem Gewinn pro Aktie mit „Der Gewinn lag bei etwa 3,40 Euro, was einer soliden Entwicklung entspricht“ antwortet, ist im interaktiven Chat charmant — und in einer automatisierten Pipeline unbrauchbar. Wer LLM-Ausgaben weiterverarbeiten, in einen Backtest einspeisen oder mit anderen Datenquellen verknüpfen will, braucht keine schönen Sätze, sondern zuverlässig parsebare Felder: eine Zahl, eine Einheit, ein Datum, eine Quelle. Genau das leisten strukturierte Ausgaben — erzwungene JSON-Schemata und Function-Calling, die garantieren, dass das Modell ein bestimmtes Format einhält, statt zu improvisieren. Dieser Beitrag zeigt, wie man LLM-Antworten zu Finanzdaten so erzwingt, dass sie maschinenlesbar und reproduzierbar werden, wie Validierung und Wiederholungslogik die letzten Lücken schließen und wo die Methode an Grenzen stößt. Es geht um den unscheinbaren, aber entscheidenden Schritt zwischen einem klugen Modell und einer verlässlichen Datenpipeline — den Schritt, an dem viele Projekte scheitern, weil sie ihn unterschätzen.

Warum Freitext im Backtest scheitert.

Stellen Sie sich vor, ein Modell extrahiert aus tausend Earnings-Meldungen jeweils das Sentiment und die genannte Guidance-Änderung. Im Freitext antwortet es mal mit „positiv“, mal mit „leicht optimistisch“, mal mit „der Ton war konstruktiv“. Drei Formulierungen für dieselbe Kategorie — und ein Parser, der daran verzweifelt.

In einem Backtest ist das fatal. Jede nicht erkannte Antwort ist entweder ein stiller Datenausfall oder ein Fehler, der sich durch die ganze Auswertung zieht. Und weil Freitext bei jedem Lauf leicht anders ausfällt, ist das Ergebnis nicht reproduzierbar — derselbe Input erzeugt morgen eine minimal andere Formulierung, die der Parser plötzlich nicht mehr greift.

Die Lösung ist nicht, den Parser robuster zu machen — das ist ein Wettrüsten ohne Ende. Die Lösung ist, das Modell gar nicht erst frei formulieren zu lassen. Wenn die Ausgabe ein festes Schema einhalten muss, verschwindet das Problem an der Wurzel.

JSON-Schema erzwingen statt erhoffen.

Es gibt einen feinen, aber entscheidenden Unterschied zwischen „bitte antworte als JSON“ im Prompt und einem erzwungenen Schema auf API-Ebene. Die Bitte im Prompt funktioniert meistens — und genau das „meistens“ ist das Problem. Ab und zu rutscht ein erklärender Satz davor, fehlt eine Klammer, taucht ein nicht vorgesehenes Feld auf.

Erzwungene strukturierte Ausgabe geht weiter: Man hinterlegt ein JSON-Schema — welche Felder, welche Typen, welche erlaubten Werte — und die Antwort wird garantiert dagegen validiert. Ein Feld sentiment mit erlaubten Werten positiv, neutral, negativ kann nichts anderes enthalten. Ein Feld eps ist garantiert eine Zahl. Halluzinierte Zusatzfelder werden ausgeschlossen.

Für Function-Calling gilt dasselbe mit striktem Modus: Die Parameter, mit denen das Modell ein Werkzeug aufruft, validieren exakt gegen das Schema. Beides zusammen verwandelt das Modell von einem Texterzeuger in einen Datenlieferanten, dessen Format man vertraglich festgelegt hat.

Ein gutes Schema für Finanzdaten entwerfen.

Die Qualität der Ausgabe hängt am Schema. Ein schlampiges Schema erzwingt zwar ein Format, aber nicht die richtigen Inhalte. Bewährt haben sich einige Prinzipien:

• Einheiten und Währung explizit als Felder — nicht „3,40“, sondern wert, einheit, waehrung getrennt. Sonst entsteht später Chaos zwischen Euro und Cent, Millionen und Milliarden.
• Quellenverweis als Pflichtfeld — jede extrahierte Zahl bekommt einen Verweis auf das Dokument, aus dem sie stammt. Das macht die Pipeline prüfbar.
• Ein „nicht gefunden“-Wert — das Schema muss erlauben, dass eine Information fehlt. Sonst erfindet das Modell, um ein Pflichtfeld zu füllen.
• Kategorien statt Freitext, wo immer möglich — feste Aufzählungswerte für alles, was später gefiltert oder aggregiert wird.

Eine Einschränkung gehört dazu: Nicht jede Schema-Funktion wird überall unterstützt. Zahlenbereiche, Mindestlängen oder rekursive Strukturen lassen sich oft nicht direkt erzwingen — die werden besser nachgelagert validiert, statt sich auf das Schema allein zu verlassen.

Validierung und Wiederholungslogik.

Erzwungene Schemata garantieren das Format, nicht die fachliche Plausibilität. Ein erzwungenes Zahlenfeld kann formal korrekt und inhaltlich Unsinn sein — eine Marge von 340 Prozent, ein Datum in der Zukunft, ein negativer Umsatz. Hier setzt die nachgelagerte Validierung an.

Bewährt ist ein zweistufiges Vorgehen. Zuerst prüft eine Datenklasse — etwa über ein Validierungs-Framework — Typen, Wertebereiche und Konsistenz. Schlägt die Prüfung fehl, greift eine Wiederholungslogik: Die Anfrage wird mit dem Validierungsfehler als zusätzlichem Hinweis erneut gestellt, sodass das Modell die Gelegenheit bekommt, den Fehler zu korrigieren.

Diese Schleife sollte eine harte Obergrenze haben — zwei, höchstens drei Versuche. Wer endlos wiederholt, verbrennt Tokens und verschleiert ein echtes Problem. Bleibt die Validierung dauerhaft hängen, ist das ein Signal: Entweder das Dokument ist untauglich, oder das Schema passt nicht zur Realität der Daten. Beides will gesehen, nicht weggeschluckt werden.

Reproduzierbarkeit als eigentlicher Gewinn.

Der oft übersehene Vorteil strukturierter Ausgaben ist nicht nur die Parsebarkeit, sondern die Reproduzierbarkeit. Wenn das Format vertraglich festgelegt ist, erzeugt derselbe Input zuverlässig dieselbe Struktur — die Voraussetzung dafür, dass ein Backtest überhaupt belastbar ist.

Das heißt nicht, dass das Modell deterministisch wird. Die extrahierten Werte können bei verschiedenen Läufen geringfügig variieren, gerade bei nuancierten Urteilen wie Sentiment. Aber das Format steht fest, und die Variation ist begrenzt und messbar — man kann sie als Rauschen behandeln, statt an einem zerbrochenen Parser zu scheitern.

Für jede Pipeline, die LLM-Ausgaben in eine Strategie einspeist, ist das die Eintrittskarte. Ohne stabile Struktur lässt sich nicht sauber backtesten, nicht versionieren, nicht reproduzieren. Mit ihr wird die LLM-Komponente zu einer Datenquelle wie jede andere — mit klar definiertem Format und dokumentierten Fehlerquoten.

Grenzen und ehrliche Fehlerquoten.

Strukturierte Ausgaben lösen das Formatproblem, nicht das Verständnisproblem. Wenn das Modell eine Kennzahl falsch interpretiert — etwa operativen mit Netto-Gewinn verwechselt — füllt es das Schema mit einer formal korrekten, fachlich falschen Zahl. Das Format gibt hier keine Sicherheit; es macht den Fehler nur sauber parsebar.

Auch der erste Aufruf mit einem neuen Schema ist langsamer, weil das Schema einmalig verarbeitet wird; danach läuft es schnell. Und einige fortgeschrittene Einschränkungen lassen sich, wie erwähnt, nicht im Schema selbst erzwingen, sondern müssen nachgelagert geprüft werden.

Die realistische Erwartung: Strukturierte Ausgaben bringen die Formatfehler-Quote praktisch auf null und reduzieren erfundene Felder deutlich. Die fachliche Fehlerquote — falsch verstandene Zahlen — bleibt bestehen und liegt je nach Aufgabe und Datenqualität im einstelligen Prozentbereich. Wer beide Quellen sauber trennt und die fachliche Prüfung nicht dem Format überlässt, baut eine Pipeline, der man trauen kann.

Sie wollen LLM-Ausgaben verlässlich in Ihre Datenpipeline oder Ihren Backtest einspeisen, ohne am Parsing zu scheitern? Unverbindlich anfragen — wir entwerfen gemeinsam ein tragfähiges Schema, die passende Validierung und eine Wiederholungslogik, die Fehler sichtbar macht statt verschluckt.