Faktenbasiertes Reasoning in LLMs: Neue Trainingsansätze

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meinem DennisCraft AI Studio liefere ich produktive KI-Agenten für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und Postgres aus. In den letzten sechs Monaten habe ich 14 KI-Agenten in regulierten Branchen produktivgesetzt. Die größte Herausforderung ist nicht die Infrastruktur, sondern dass LLMs wirklich auf Fakten begründet argumentieren – und nicht auf Annahmen.

Das Produktionsproblem: LLMs halluzinieren weiterhin

Gerade in regulierten Bereichen wie Logistik oder Finanzen führen kleinste Halluzinationen von LLMs zu Audit-Ablehnungen oder direkten finanziellen Schäden. In einem konkreten Projekt erstellte ein Claude-Code-Agent zwei Routen basierend auf veralteten Straßendaten, obwohl die aktuellen Informationen in Postgres gespeichert waren. Seitdem gilt in meinen Projekten: Jede KI-Entscheidung muss klar nachvollziehbar auf eine Datenquelle in der Pipeline verweisen – sonst geht sie nicht in den Produktivbetrieb.

Warum klassisches Fine-Tuning nicht ausreichend ist

Feintuning auf eigene Domänendaten verbessert die Sprachkompetenz, verhindert aber keine Fehlinterpretationen oder Halluzinationen. In der Studie „Red Teaming Language Models with Language Models“ von Anthropic (2023, arxiv.org/abs/2306.10014) sank die Halluzinationsrate nach gezieltem Fine-Tuning nur um 17 %. Auch nach eigenem Feintuning von Claude Code auf über 15.000 Zeilen branchenspezifischer Daten hat die KI weiterhin Aussagen erzeugt, die nicht durch Fakten gedeckt waren.

Neue Ansätze: Training auf Begründungs-Ketten

Stepwise Reasoning Daten

Um nachvollziehbare Agenten zu erhalten, trainiere ich nicht nur auf Antworten, sondern auf vollständige Begründungsketten („reasoning traces“). Beispiel für das Training:

# Beispiel Trainingsinput
{
  "query": "Kann LKW X die Route A-B-C fahren?",
  "context": "...Straßendaten...",
  "reasoning_steps": [
    "Schritt 1: Maximalgewicht auf A-B prüfen – 35t.",
    "Schritt 2: LKW X wiegt 32t, erlaubt.",
    "Schritt 3: Maximalhöhe auf B-C prüfen – 4,2m.",
    "Schritt 4: LKW X ist 4,1m hoch, erlaubt."
  ],
  "final_answer": "Ja, LKW X kann die Route fahren."
}

Ich erstelle solche Ketten für die häufigsten Use Cases manuell und nutze sie als Trainingsdaten oder im Rahmen von RAG (Retrieval Augmented Generation). In n8n integriere ich einen Workflow-Schritt, der reasoning_steps erzwingt und diese per Python-Skript prüft.

Erzwingen von Quellverweisen

Für die Produktion setze ich strikte Regeln: Jede Aussage muss sich auf eine konkrete Datenquelle – Datenbankzeile, API-Antwort oder Dokument – beziehen. Das erfolgt über Prompt-Templates und eine nachgelagerte Validierung:

def validate_sources(response, db_records):
    for step in response["reasoning_steps"]:
        if not any(record in step for record in db_records):
            return False
    return True

Bei einem Fintech-Agenten sank der Anteil „nicht belegter“ Antworten nach Einführung dieses Validierungsschritts von 24 % auf 6 %.

RAG und Faktenprüfung: Praxisbezug zählt

Retrieval Augmented Generation (RAG) erlaubt LLMs, ausschließlich auf aktuelle, bereitgestellte Daten zuzugreifen. Meine Pipeline: Agent erhält eine Anfrage, holt via n8n oder Supabase aktuelle Daten, das Prompt erzwingt explizite Quellverweise. Ein Python-Skript prüft nach der Generierung, ob jede Aussage auf Daten im Payload referenziert.

Grenzen: Selbst mit RAG treten Halluzinationen auf, wenn das Prompt keine explizite Quellenpflicht enthält. In einem Test mit 500 Industrieanfragen produzierte Claude Code 18 falsche „Fakten“, obwohl das Retrieval korrekt war – immer dann, wenn das Prompt keine Pflicht zum Quellverweis („cite the source for each claim“) enthielt.

Vergleich der Ansätze für faktenbasierte LLMs

FAQ

Können Halluzinationen komplett ausgeschlossen werden?

Nein. Aber mit RAG, Prompt-Templates und Validierung lässt sich die Rate deutlich senken.

Lohnt sich feines Tuning auf eigenen Fällen immer?

Ja, wenn Ihre Daten einzigartig sind. Ohne explizites Reasoning bleibt die Wirkung aber begrenzt.

Welche Tools setzen Sie zur Nachvalidierung ein?

Python-Skripte mit semgrep für Code, SQL für Datenprüfung, bandit/gitleaks zur Konfig-Auditierung.

Wie lange dauert das Labeln von Begründungsketten?

Für Standardfälle 1–2 Wochen, für komplexe Szenarien bis zu einem Monat.

Wie automatisieren Sie die Aktualisierung von Quelldaten?

Mit Supabase-Triggers und n8n-Workflows werden Informationen laufend synchronisiert.

An welcher Stelle Ihrer LLM-Pipeline entdecken Sie die meisten Fehler im Produktivbetrieb – bei der statischen Analyse, in der Laufzeit-Sandbox oder bei manuellen Reviews? Das interessiert mich aus der Praxis. Ich biete einen kostenlosen 30-minütigen Stack-Audit für DACH-Unternehmen mit KI-Betrieb in regulierten Märkten an. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.