Wie Sie Ausfälle reduzieren und die Zuverlässigkeit von KI-Agenten im Produktivbetrieb erhöhen: Kontrollpanel für 25+ LLMs mit Halluzinationserkennung

von Denis Shokhirev, Enterprise AI Architect aus Freiburg. In meinem Studio DennisCraft AI liefere ich KI-Agenten für B2B-Kunden im DACH-Raum aus — Logistik, Fintech, Industrieautomatisierung. Mein Stack: Claude, Supabase, n8n, Doppler, self-hosted Postgres. Nach jedem Go-Live melden Kunden dieselben Probleme: instabile Agenten, Fehler im Datenfluss, Halluzinationen. Keine Theorie, sondern Muster aus echten Produktivumgebungen.

Typische Fehlerquellen: Warum LLM-Agenten im Betrieb scheitern

Sobald Sie mehr als 25 LLMs in mehreren Workflows orchestrieren, wiederholen sich die Schwachstellen:

• Inkonsistente Antworten auf gleiche Anfragen
• Integrationsabbrüche: Timeouts, Nullwerte, fehlerhaftes JSON
• Halluzinierte Inhalte — erfundene Produkte, ungültiges SQL, potenziell riskante Empfehlungen
• n8n-Workflows brechen beim ersten unerwarteten Output der LLMs sofort ab

In drei aktuellen Rollouts meiner Agenten waren 10–15 % der kritischen Flows durch fehlerhafte oder halluzinierte LLM-Antworten betroffen. Je länger die Pipeline, desto versteckter werden diese Probleme.

Kontrollpanel-Architektur: Stabile Agenten durch systematische Überwachung

1. Zentrale Protokollierung aller LLM-Aufrufe mit Supabase

Jeder LLM-Aufruf (Prompt, Parameter, Antwort, Status, Latenz) wird in einer eigenen Postgres-Tabelle via Supabase gespeichert. Damit können Sie Fehlerquoten, Ausreißer und Latenzspitzen präzise auswerten.

import supabase
from datetime import datetime

def log_llm_call(user_id, prompt, response, status):
    data = {
        "user_id": user_id,
        "prompt": prompt,
        "response": response,
        "status": status,
        "created_at": datetime.utcnow()
    }
    supabase.table("llm_logs").insert(data).execute()

In einer Fintech-Integration zeigte sich so innerhalb einer Woche eine 7 % Instabilitätsrate — die Ursache war nur durch diese Logdaten identifizierbar.

2. Laufende Halluzinationserkennung im Betrieb

Große Sprachmodelle liefern scheinbar plausible, aber fehlerhafte Outputs: erfundene Produkt-IDs, ungültigen Code, riskante SQLs. Jeder Agenten-Output wird deshalb validiert:

• SQL-Parsing mit sqlparse, um Syntaxfehler vor der Datenbankausführung zu erkennen
• Semantische Prüfung gegen Whitelists (z. B. bekannte Produkt-IDs)
• Sanity-Checks für numerische und boolesche Felder

Ein Kontrollmuster für DB-Flows sieht so aus:

import sqlparse

def is_valid_sql(query):
    try:
        parsed = sqlparse.parse(query)
        return len(parsed) > 0
    except Exception:
        return False

def check_output(output):
    if not is_valid_sql(output):
        return False
    # Semantische Validierung ergänzen
    return True

3. Multimodell-Fallback und A/B-Validierung

Mit 25+ LLMs (Claude, GPT-4, Llama, Mistral usw.) setze ich Fallback-Routing ein: Liefert das Primärmodell Müll oder Fehler, geht die Anfrage an ein Backup-Modell. Für kritische Vorgänge führe ich A/B-Tests im Produktivbetrieb: identischer Prompt, zwei LLMs, Vergleich per Checksumme oder semantischem Diff.

Das lokale Modell-Leaderboard speichere ich in Supabase.

n8n: Schwachstelle Output-Validierung

n8n ist mein zentraler Workflow-Orchestrator. LLM-Agenten binde ich über Custom-Nodes ein, die jeden Output vor der Weitergabe validieren. Fällt ein Output durch, wird der Flow gestoppt, ein Vorfall geloggt und eine Slack-Benachrichtigung ausgelöst.

// Beispiel für eine n8n-Node zur JSON-Output-Prüfung
export function validateLLMOutput(output: string): boolean {
  try {
    const data = JSON.parse(output);
    // Akzeptiert nur, wenn order_id enthalten ist
    if (!data.hasOwnProperty('order_id')) return false;
    return true;
  } catch (e) {
    return false;
  }
}

Im Bereich Industrieautomatisierung reduzierte diese Runtime-Prüfung fehlerhafte Transaktionen von 12 auf 1 pro Monat.

Zugriffskontrolle und Nachvollziehbarkeit — Pflicht für Compliance

Für alle Workflows mit DSGVO-relevanten oder sensiblen Daten durchläuft jeder LLM-Aufruf eine Auditschicht: Wer, wann, mit welchen Parametern, welcher Output. Sensible Felder werden vor Speicherung in Supabase maskiert.

Jeder Request erhält eine eindeutige trace_id, sodass sich Vorfälle lückenlos rekonstruieren lassen — wichtig für BSI Grundschutz, ISO 27001 und EU AI Act.

FAQ

Muss man wirklich so viele Modelle betreiben?

Kein einzelnes LLM deckt alle B2B-Usecases ab: Sprache, Format, Latenz, Compliance variieren stark. Multimodell macht Systeme fehlertoleranter und flexibler.

Wie erkennen Sie Halluzinationen ohne manuellen Review?

Ich setze mehrstufige Prüfungen ein: Syntax, semantische Whitelist, Output-Vergleich. Manuelle Audits nur für Grenzfälle.

Wie lange dauert der Aufbau eines solchen Kontrollpanels?

Ein MVP (Supabase-Logging, Grundprüfungen) steht in 2–3 Tagen. Weitere Modelle und Flows werden schrittweise integriert.

Geht das auch ohne Supabase?

Mit self-hosted Postgres und REST-API ja, aber Supabase bietet Dashboards, Authentifizierung und Webhooks direkt mit an.

Wie verhindern Sie Datenabfluss über LLMs?

Sensible Felder maskiere ich, Inputs werden strikt vorvalidiert, jeder LLM-Call wird auditiert. Für Fintechs laufen Modelle in isolierten Environments.

An welcher Stelle in Ihrer LLM-Pipeline treten die meisten Fehler im Produktivbetrieb auf — Laufzeitvalidierung, Integrationstest oder manueller Review? Ich bin gespannt auf Ihre Erfahrung.

Ich biete einen kostenlosen 30-minütigen Stack-Audit für DACH-Entscheider im regulierten KI-Umfeld an. Kontaktieren Sie mich auf LinkedIn oder direkt unter @ger_dennis_ai.