← Alle Insights
9 Min. Lesezeit · KI · März 2030

KI-Halluzinationen im Trading: warum LLMs niemals direkt traden sollten.

Ein LLM, das überzeugt etwas Falsches sagt, ist kein Bug. Es ist Architektur. Wer das verstanden hat, baut robuste KI-Trading-Workflows. Wer nicht, verliert irgendwann Geld an einen Algorithmus, der einen Ticker erfunden, eine Zahl halluziniert und eine Quelle zitiert hat, die nicht existiert.

Was eine Halluzination wirklich ist.

Ein Large Language Model sagt nicht „wahre" Dinge. Es sagt statistisch plausible Dinge — Token, die zu seinem Trainingsmaterial passen. In den meisten Fällen ist das auch korrekt, weil Trainingsmaterial überwiegend faktentreu war. Aber das Modell hat keinen Wahrheits-Sensor. Es weiß nicht, was es nicht weiß.

Eine Halluzination ist deshalb kein Fehler im Sinne eines Bugs, der gefixt werden kann. Es ist die Konsequenz daraus, dass das Modell Sprache modelliert, nicht Realität. Selbst die besten 2030er Modelle halluzinieren — seltener, subtiler, schwerer zu erkennen.

Konkrete Beispiele aus dem Trading-Kontext.

  1. Erfundene Tickers. Ich habe Modelle gesehen, die auf die Frage „Welche kleinen Lithium-Aktien gab es 2024?" überzeugt ein „LITX" oder „LMNQ" zurückgeben, das es nie gegeben hat. Stylish klingender Ticker, plausibler Sektor, keine Existenz.
  2. Falsche Zahlen. „Apple Q3 2029 EPS lag bei 2,14 USD." Klingt richtig. Ist es nicht. Eine Stelle falsch reicht, um eine Bewertungs-Tabelle zu vergiften.
  3. Erfundene Quellen. Ein Modell zitiert „Goldman Sachs Note vom 14. März 2030, Autor M. Friedman". Den Autor gibt es. Die Note nicht. Erschütternd echt klingend.
  4. Falsche Optionsketten. Strike, Expiry, Delta — alles plausibel, alles nicht existent oder nicht aktuell. Wer auf so eine Antwort einen Spread aufbaut, wird beim Ausführen unangenehm überrascht.
  5. Halbwahre Historien. „Der VIX schloss am 24. Februar 2020 bei 35." Die Zahl ist plausibel im Größenordnungs-Bereich, aber falsch im Detail. Subtil — und für Backtests tödlich.

Wie man Halluzinationen erkennt.

Self-Consistency

Fragen Sie dasselbe drei- bis fünfmal mit leichten Variationen. Wenn die Antworten voneinander abweichen — bei Faktenfragen ein Warnzeichen. Modelle „wissen" Fakten entweder oder erfinden sie; konsistente Halluzinationen sind seltener als konsistente Wahrheiten, aber nicht ausgeschlossen.

Verifikation gegen externe Quellen

Jede Zahl, jeder Ticker, jedes Datum wird gegen eine vertrauenswürdige Datenbank geprüft, bevor er in einen Trading-Workflow einfließt. Im Code: das LLM darf Vorschläge machen, die Verifikation passiert deterministisch. Beispiel-Pattern: 

def verify_ticker(symbol: str) -> bool:
    # nur Symbole, die in unserem Universe-File existieren
    return symbol in load_universe()

llm_suggestion = agent.suggest_trade(prompt)
if not verify_ticker(llm_suggestion["symbol"]):
    raise HallucinationError(f"Ticker {llm_suggestion['symbol']} unbekannt")

Confidence-Scoring

Moderne Modelle können explizit nach einer Selbsteinschätzung gefragt werden. „Wie sicher bist du, auf einer Skala von 0 bis 10?" — die Antworten sind nicht kalibriert, aber besser als nichts. Werte unter 7 sollten Verifikation erzwingen.

Output-Schema mit harten Constraints

Statt freier Textantworten verlangen Sie strukturierte JSON-Outputs mit Schema- Validierung. „Ticker muss aus erlaubter Liste sein, Datum muss YYYY-MM-DD sein, Preis muss zwischen 0 und 100000 USD liegen." Halluzinationen, die das Schema brechen, werden bei der Validierung gefangen.

Architekturen, die Halluzinationen reduzieren.

RAG (Retrieval Augmented Generation)

Statt das Modell aus dem Gedächtnis antworten zu lassen, geben Sie ihm die relevanten Dokumente im Kontext und lassen es ausschließlich auf Basis dieser Dokumente antworten. Plus expliziter Hinweis im Prompt: „Wenn die Information nicht in den gelieferten Quellen steht, sage 'unbekannt'." Reduziert Halluzinationen drastisch, aber nicht auf null.

Tool-Use für Fakten

Das Modell darf keine Zahlen aus dem Gedächtnis nennen. Es muss eine Funktion aufrufen, die die Zahl aus einer echten Quelle holt. „Was war AAPLs Q3-Umsatz?" → das Modell ruft get_earnings_data("AAPL", "Q3", 2029) auf, statt selbst zu antworten. Die Funktion gibt die echte Zahl zurück, das Modell formuliert nur den Satz drumherum.

Mehrstufige Verifikation

Ein Modell macht den Vorschlag, ein zweites prüft ihn gegen die Quellen, ein dritter deterministischer Code-Pfad validiert das Schema. Drei Schichten, jede unabhängig. Aufwändig, aber bei kritischen Entscheidungen unverzichtbar.

Warum jeder Output vor Order-Submission verifiziert werden muss.

In meinen Mandanten-Projekten gibt es eine eiserne Regel: zwischen dem LLM und dem Order-Management-System steht immer ein deterministischer Validation Layer. Diese Schicht ist klassischer Code, keine KI. Sie prüft:

Erst wenn alle Checks grün sind, geht die Order raus. Wer auf diesen Layer verzichtet, damit „der Agent autonom handeln kann", baut keine moderne Architektur. Er baut eine teure Lektion in Operational Risk.

Meine Regel.

KI für Vorbereitung. Mensch für Entscheidung. Code für Ausführung.

Die KI darf Informationen sammeln, strukturieren, hinterfragen, alternative Szenarien durchspielen, Hypothesen testen. Sie darf mir morgens 80 % der Recherche abnehmen. Sie darf mir bei Backtests die Hand führen.

Aber sie darf nicht entscheiden, welcher Trade gemacht wird. Und sie darf nicht ohne menschlich gegengezeichnete Validation den Order-Button drücken. Diese Trennung ist kein Misstrauen gegenüber der Technik. Sie ist die Konsequenz aus einem nüchternen Verständnis dessen, was LLMs sind und was sie nicht sind.

2030 ist nicht das Jahr autonomer Trading-Agents. Wer in der nächsten Generation zuverlässig Geld verdienen will, baut Workflows, in denen KI und Mensch ihre jeweiligen Stärken einbringen. Das ist langweiliger als „der Agent macht alles". Es funktioniert auch.

Sie wollen einen KI-Trading-Workflow mit sauberer Halluzinations-Kontrolle aufsetzen? Erstgespräch buchen — wir definieren die Validation-Layer, die Sie wirklich brauchen.