LLM-Interne Beobachtungsdatenbanken für Multi-Architektur-AI-Agenten

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. In meinem Studio DennisCraft AI entwickle und betreibe ich AI-Agenten für B2B-Kunden im DACH-Raum – Logistik, Finanzen, Industrieautomation. In den letzten sechs Monaten habe ich 14 produktive AI-Agenten auf Basis von Claude, Supabase, n8n, Doppler und eigenem Postgres bereitgestellt. Der größte Stolperstein: Nicht offensichtliche Fehler und Regressionen von LLMs im Produktivbetrieb zu erkennen, besonders bei gemischten Architekturen und wechselnden LLM-Anbietern.

Warum interne Beobachtungsdatenbanken für LLMs?

Bei Multi-Architektur-Pipelines – Claude mit GPT kombiniert, RAG auf eigenem Postgres, Orchestrierung via n8n – stößt klassisches Logging schnell an die Grenzen. In drei aktuellen Projekten war das Muster gleich: Ein Claude-basierter Agent arbeitet monatelang stabil, dann plötzlich toxische Antworten nach einer Prompt-Änderung in einem anderen Pipeline-Baustein. Standard-Logs erfassen nur Ein- und Ausgang, aber keine inneren Reasoning-Schritte, wo der Fehler tatsächlich entsteht.

Das Beobachtungsdatenbank-Muster meint: Jeder Zwischenschritt, Chain-of-Thought, Reasoning-Trace und Tool-Call wird strukturiert in einer zentralen Datenbank (Postgres, Supabase, TimescaleDB) abgelegt. Nicht bloß Logfiles, sondern eine systematisch abfragbare Reasoning-Historie pro Agent und LLM.

Architektur: Was wird wie gespeichert?

Welche Daten sind relevant?

• Chain-of-Thought-Prompts (Schritt-für-Schritt-Reasoning)
• Tool-Aufruf-Traces (API, Funktionen)
• Tokenisierung, Embeddings, Zwischenvektoren
• Fehler, Anomalien, “Hallucination Triggers”
• Prompt- und Parameter-Versionen (Temperature, Max Tokens etc.)

Die Speicherung erfolgt typischerweise mit einer Tabelle pro Kerndatentyp. Beispiel für eine Reasoning-Trace-Tabelle:

CREATE TABLE llm_reasoning_traces (
    id SERIAL PRIMARY KEY,
    agent_id UUID NOT NULL,
    timestamp TIMESTAMP NOT NULL DEFAULT now(),
    input_text TEXT,
    step_number INT,
    reasoning_step TEXT,
    tool_used TEXT,
    output_fragment TEXT,
    prompt_version VARCHAR(32),
    model_name VARCHAR(32)
);

Supabase eignet sich für schnelle Prototypen – TypeScript oder Python pushen Daten direkt aus dem Agenten. Für höhere Compliance-Anforderungen oder Volumen empfehle ich selbstgehostetes Postgres, ggf. mit TimescaleDB für Zeitreihen-Auswertungen.

Integration mit Agenten (minimalinvasiv)

Die Einbindung der Beobachtung ist meist ein kleiner Wrapper um LLM- und Tool-Calls. In Python (Anthropic SDK, openai) reicht etwa:

import psycopg2
def log_reasoning(agent_id, step, text, tool, output, version, model):
    conn = psycopg2.connect("dbname=aiobs user=aiwriter")
    cur = conn.cursor()
    cur.execute(
        "INSERT INTO llm_reasoning_traces (agent_id, step_number, reasoning_step, tool_used, output_fragment, prompt_version, model_name) VALUES (%s,%s,%s,%s,%s,%s,%s)",
        (agent_id, step, text, tool, output, version, model)
    )
    conn.commit()
    cur.close()
    conn.close()

In n8n lässt sich das Muster per Postgres-Node oder Supabase REST API umsetzen. Wichtig: Die Agenten-Logik bleibt sauber, kein Refactoring nötig.

Produktive Anwendungsfälle

1. Regressionen und Musterbrüche identifizieren

In einem Logistikprojekt generierte ein Claude-Agent nach Austausch eines Supplier-Moduls plötzlich Antworten, die die Corporate-Language-Vorgaben verletzten. Die Reasoning-Trace-Tabelle zeigte: Ein neuer Prompt im RAG-Teil führte zu Halluzinationen, die im Standard-Log unsichtbar wären.

2. Incident-Audit und Compliance-Dokumentation

Für einen Fintech-Kunden unter BaFin-Aufsicht musste ich nicht nur Ein-/Ausgabe, sondern auch die Entscheidungsfindung des Agenten nachweisen. Die Beobachtungsdatenbank ermöglichte eine schrittweise Rekonstruktion inkl. API-Calls und Prompt-Versionen.

3. Vergleich verschiedener LLMs und Architekturen

Beispiel aus meinem Produktivbetrieb (anonymisiert):

Solche Analysen sind ohne zentrale Reasoning-Datenbank praktisch unmöglich.

Sicherheit, Datenschutz und Regulierung

Speicherung von Nutzerdaten?

In regulierten Sektoren (Finanzen, HR, Medizin) speichere ich keine Rohdaten von Nutzern. Reasoning-Traces werden gemasked (E-Mail, Telefonnummern, Konten). Zum Maskieren nutze ich semgrep/gitleaks sowie manuelle Stichproben vor der Speicherung. DSGVO und BSI Grundschutz sind einzuhalten.

Zugriffs- und Audit-Kontrolle

Zugriff nur via Service-Accounts, alle Lese-/Schreibzugriffe werden geloggt. Bei kritischen Anwendungsfällen kommt eine Audit-Trail-Tabelle dazu, um Zugriff und Änderungen zu dokumentieren.

FAQ

Muss die Beobachtungsdatenbank direkt zum Start integriert werden?

Nein, aber bei Multi-Agent- oder dynamisch wechselnden LLM-Architekturen empfehle ich ein frühes Setup – Nachrüsten ist deutlich aufwändiger.

Darf Reasoning in der Cloud gespeichert werden?

Nur wenn Supabase/Postgres in der EU gehostet wird und keine personenbeziehbaren Daten enthalten sind. Für sensible Daten ausschließlich self-hosted Postgres auf dedizierten Servern.

Wie analysieren Sie Reasoning-Traces?

Erste Analysen: Fehlerquoten, Kettenlängen, Zeitabweichungen. Für tiefere Audits: Export nach Jupyter, manuelle Prüfung Schritt für Schritt.

Migration zwischen LLMs ohne Aufwand möglich?

Wenn das Schema einfach bleibt (agent_id, step, model), reicht SQL zur Migration zwischen Claude, GPT, Llama – kein komplexes ETL nötig.

Echtzeit-Auswertung der Reasoning-Schritte?

Ja, mit TimescaleDB oder Supabase Realtime plus Metabase oder Grafana lassen sich produktive Dashboards aufbauen.

An welcher Stelle in Ihrer LLM-Pipeline treten im Produktivsystem die meisten Reasoning-Probleme auf – Prompt Engineering, Tool-Anbindung oder API-Integration? Ich freue mich auf konkrete Erfahrungsberichte. Ich biete einen kostenlosen 30-Minuten-Stack-Audit für DACH-Entscheider im regulierten AI-Umfeld an. Kontaktieren Sie mich auf LinkedIn oder via @ger_dennis_ai.