Prompts versionieren wie Code reproduzierbares LLM-Research.

Wer LLMs für Finanz-Research einsetzt, ändert seine Prompts ständig - eine Formulierung hier, ein zusätzliches Beispiel dort, ein nachgeschärftes Ausgabeformat. Jede dieser Änderungen verschiebt still die Ergebnisse, oft ohne dass es jemand merkt. Plötzlich klassifiziert das Modell Nachrichten anders, extrahiert andere Kennzahlen, gewichtet Sentiment verschoben - und niemand kann sagen, ob das Research besser geworden ist oder nur anders. Diese schleichende Prompt-Drift ruiniert genau das, was Research auszeichnen sollte: Vergleichbarkeit über die Zeit. Die Lösung kommt aus der Softwareentwicklung. Prompts gehören versioniert wie Code, getestet wie Code, an Modell-Versionen gekoppelt wie Abhängigkeiten. Dieser Beitrag zeigt, wie Sie Prompts mit Git verwalten, ein Golden-Set für Regressionstests aufbauen, Drift messbar machen und die Kopplung an Modell-Versionen sauber dokumentieren - damit ein Research-Ergebnis von heute auch in einem Jahr noch nachvollziehbar und revisionssicher ist.

Warum Prompt-Drift Research unvergleichbar macht.

Ein LLM-gestützter Research-Prozess ist eine Pipeline aus drei beweglichen Teilen: dem Modell, dem Prompt und den Eingangsdaten. Ändert sich einer davon, ändern sich die Ergebnisse. Bei den Daten ist das gewollt - neue Nachrichten, neue Quartalszahlen. Beim Modell ist es bekannt, wenn auch oft unterschätzt. Beim Prompt aber passiert es meist unbemerkt.

Der typische Ablauf: Ein Analyst stellt fest, dass das Modell bei einer bestimmten Meldungsart danebenliegt, fügt eine Anweisung hinzu, testet sie an drei Beispielen, ist zufrieden. Was er nicht sieht: dass diese Anweisung das Verhalten bei zwanzig anderen Meldungsarten subtil verschiebt. Eine Woche später wundert sich jemand, warum die Sentiment-Zeitreihe einen Sprung hat, der zu keinem Marktereignis passt. Es war der Prompt.

Das Problem ist strukturell. Anders als bei klassischem Code, wo ein Logikfehler oft krachend fehlschlägt, produziert ein schlechter Prompt weiterhin plausibel aussehende Ausgaben. Es gibt keinen Stacktrace, keine rote Fehlermeldung. Die Verschlechterung ist still, graduell und genau deshalb gefährlich. Wer Research-Ergebnisse über Monate vergleichen will - etwa um zu prüfen, ob ein Signal noch trägt - braucht die Gewissheit, dass die Verschiebung im Ergebnis aus dem Markt kommt und nicht aus einer unprotokollierten Prompt-Änderung.

Prompts gehören in die Versionsverwaltung.

Der erste und wichtigste Schritt ist banal und wird trotzdem selten gemacht: Prompts gehören aus der Anwendung heraus in versionierte Dateien. Kein hartkodierter String mitten im Python-Code, kein Prompt in einer Datenbank ohne Historie, kein Copy-Paste aus einem Notizdokument. Stattdessen liegt jeder Prompt als eigene Datei im Git-Repository, mit vollständiger Änderungshistorie.

Bewährt hat sich eine Struktur, die Prompt-Text, Parameter und Metadaten trennt:

• Prompt-Template als eigene Datei (Markdown oder Textdatei) mit klaren Platzhaltern für die einzusetzenden Daten.
• Konfiguration daneben: Modell-ID, Temperatur, maximale Token, System-Prompt-Verweis - alles, was die Ausgabe beeinflusst.
• Versionskennung, die in jedes Research-Ergebnis mitgeschrieben wird, etwa ein Commit-Hash oder eine semantische Version wie sentiment-classifier@2.3.0.

Entscheidend ist der letzte Punkt. Wenn ein Research-Output entsteht, muss er die exakte Prompt-Version mitführen, mit der er erzeugt wurde. Nur so lässt sich Monate später rekonstruieren, welche Logik hinter einer bestimmten Klassifikation stand. Diese Disziplin kostet im Aufbau wenige Tage, spart aber bei jeder späteren Frage nach dem Warum unverhältnismäßig viel Zeit.

Das Golden-Set als Prüfstein.

Versionierung allein dokumentiert nur, dass sich etwas geändert hat. Ob die Änderung gut oder schlecht war, sagt sie nicht. Dafür braucht es einen festen Referenzdatensatz - das Golden-Set. Es besteht aus einer kuratierten Sammlung von Eingaben mit bekannten, von Menschen geprüften Soll-Ausgaben.

Für einen Nachrichten-Klassifikator könnten das etwa 150 bis 400 sorgfältig ausgewählte Meldungen sein, jede mit der korrekten Einordnung versehen: das eindeutige Positive, das eindeutige Negative, die kniffligen Grenzfälle, die typischen Fallstricke wie ironische Schlagzeilen oder Meldungen mit gemischtem Signal. Gerade die Grenzfälle sind wertvoll, weil sich dort Prompt-Änderungen zuerst bemerkbar machen.

Das Golden-Set ist kein einmaliges Artefakt, sondern wächst mit. Jedes Mal, wenn das Modell in Produktion einen aufschlussreichen Fehler macht, wandert dieser Fall - korrekt annotiert - ins Set. So entsteht über die Zeit eine Sammlung, die genau die Schwächen abbildet, die im eigenen Anwendungsfall real auftreten. Der Aufwand für die initiale Kuratierung ist nicht zu unterschätzen: Ein belastbares Golden-Set zu erstellen kostet leicht mehrere Personentage, weil jede Soll-Ausgabe begründet und konsistent sein muss. Diese Investition ist aber die Grundlage für alles Weitere.

Regressionstests gegen jede Prompt-Änderung.

Mit Versionierung und Golden-Set zusammen entsteht das eigentliche Werkzeug: der Regressionstest. Vor jeder Prompt-Änderung läuft der bestehende Prompt über das Golden-Set und erzeugt einen Referenzwert. Nach der Änderung läuft der neue Prompt über dasselbe Set. Die Differenz zeigt, was die Änderung wirklich bewirkt hat - nicht an drei handverlesenen Beispielen, sondern über die gesamte Bandbreite.

Sinnvolle Kennzahlen hängen von der Aufgabe ab. Bei Klassifikation sind das Genauigkeit, Präzision und Trefferquote je Klasse sowie die Konfusionsmatrix. Bei Extraktion die Feldgenauigkeit pro extrahiertem Wert. Bei generativen Aufgaben braucht es oft einen zweiten LLM als Bewerter oder strukturierte Heuristiken. Wichtig ist, nicht nur den Gesamtwert zu betrachten, sondern die Verschiebungen pro Kategorie - denn eine Änderung kann den Durchschnitt verbessern und gleichzeitig eine wichtige Teilmenge verschlechtern.

In der Praxis bedeutet das einen einfachen Schwellenwert: Verschlechtert sich eine Kernkennzahl um mehr als einen definierten Betrag, wird die Änderung nicht übernommen oder muss bewusst freigegeben werden. Damit wird aus dem Bauchgefühl 'der Prompt fühlt sich besser an' eine überprüfbare Aussage. Eine ehrliche Einschränkung gehört dazu: Ein Golden-Set mit 300 Beispielen deckt nicht jede Realität ab. Es ist ein Sicherheitsnetz, kein Beweis. Grobe Regressionen fängt es zuverlässig, feine Verschiebungen am Rand der Verteilung können durchrutschen.

Die Kopplung an Modell-Versionen.

Ein Prompt existiert nie allein - er ist immer für ein bestimmtes Modell formuliert. Was bei einem Modell präzise funktioniert, kann bei einem anderen oder bei einer neuen Version desselben Modells anders wirken. Anbieter aktualisieren ihre Modelle, manchmal mit Versionskennung, manchmal still im Hintergrund. Genau hier entsteht eine der gefährlichsten Drift-Quellen, weil sie von außen kommt.

Die saubere Antwort ist, die Modell-Version als feste Abhängigkeit zu behandeln. In der Prompt-Konfiguration steht nicht ein generischer Alias, sondern eine konkrete, pinbare Versionskennung. Steht ein Modellwechsel an - sei es ein Upgrade oder ein erzwungener Wechsel, weil eine alte Version abgekündigt wird - läuft zuerst der komplette Regressionstest gegen das Golden-Set. Erst wenn die Ergebnisse stimmen, wird die neue Modell-Version übernommen, dokumentiert als eigene Änderung mit eigener Version.

Bei Cloud-APIs ist die Pinbarkeit eine Frage dessen, was der Anbieter anbietet - manche garantieren stabile Snapshots, andere weniger. Wer maximale Reproduzierbarkeit braucht, landet schnell bei Open-Weight-Modellen, die man selbst hostet und damit vollständig kontrolliert.

Revisionssicherheit und Nachvollziehbarkeit.

Im Finanz-Research ist Nachvollziehbarkeit kein Luxus, sondern oft eine Anforderung. Wenn ein Signal eine Entscheidung beeinflusst hat, muss im Zweifel rekonstruierbar sein, wie dieses Signal zustande kam. Bei einem regelbasierten Indikator ist das trivial. Bei einem LLM-Output ist es nur dann möglich, wenn die ganze Kette protokolliert wurde.

Vollständige Revisionssicherheit bedeutet, zu jedem Research-Ergebnis mindestens Folgendes zu speichern: die Eingangsdaten beziehungsweise einen Verweis darauf, die exakte Prompt-Version, die Modell-Version mit allen Parametern, den Zeitstempel und die rohe Modellausgabe vor jeder Nachbearbeitung. Mit diesen Angaben lässt sich der Lauf - bei deterministischen Einstellungen - reproduzieren oder zumindest exakt erklären.

Eine ehrliche Grenze: LLMs sind nicht garantiert deterministisch. Selbst bei Temperatur null können Ausgaben minimal schwanken, je nach Anbieter-Infrastruktur. Bit-für-Bit-Reproduzierbarkeit ist über Cloud-APIs oft nicht erreichbar. Was erreichbar ist, ist Nachvollziehbarkeit: Man kann jederzeit sagen, mit welchem Prompt und welchem Modell ein Ergebnis entstand, auch wenn der exakte Lauf nicht bis aufs letzte Token wiederholbar ist. Für die meisten Research- und Dokumentationszwecke reicht diese Stufe vollkommen aus.

Schlanker Einstieg ohne Überbau.

Der häufigste Fehler bei diesem Thema ist, zu groß anzufangen. Man muss nicht sofort eine vollständige Prompt-Management-Plattform mit Weboberfläche, Berechtigungen und Dashboards bauen. Der Großteil des Nutzens kommt aus drei einfachen Bausteinen, die sich in wenigen Tagen einführen lassen.

Schritt eins: Prompts in Git, mit Version in jedem Output. Das allein schafft schon Nachvollziehbarkeit. Schritt zwei: ein erstes, kleines Golden-Set für den wichtigsten Anwendungsfall, anfangs vielleicht nur 50 bis 100 Beispiele. Schritt drei: ein simples Test-Skript, das den Prompt über das Set laufen lässt und die Kennzahlen ausgibt, manuell vor jeder Änderung gestartet. Erst wenn das gelebte Praxis ist, lohnt sich die Automatisierung in der Build-Pipeline.

Der Aufwand für diesen schlanken Einstieg liegt typischerweise bei wenigen Personentagen, der laufende Mehraufwand bei einigen Minuten pro Prompt-Änderung. Dem steht der vermiedene Schaden gegenüber: Eine unbemerkte Prompt-Regression, die über Wochen falsche Signale produziert, ist im Trading-Kontext schnell ein Vielfaches teurer. Die Werkzeuge sind dieselben, die jedes Entwicklungsteam ohnehin kennt - es geht nicht um neue Technologie, sondern darum, Prompts ernst genug zu nehmen, um sie wie Code zu behandeln.

Sie betreiben LLM-gestütztes Research und wollen verhindern, dass stille Prompt-Drift Ihre Ergebnisse unvergleichbar macht? Unverbindlich anfragen — wir schauen gemeinsam auf Ihre Prompt-Landschaft, bauen ein erstes Golden-Set für Ihren wichtigsten Use-Case und richten Regressionstests ein, die jede Änderung messbar machen.