Schluss mit ständiger Kontext-Erklärung für KI: Persönliche Gedächtnisschicht für Analysten

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. Ich leite DennisCraft AI Studio und liefere produktive KI-Systeme für DACH-B2B-Kunden im Bereich Logistik, Fintech und industrielle Automatisierung. Stack: Claude, Supabase, n8n, Doppler, selbstgehostetes Postgres. In den letzten sechs Monaten habe ich 14 produktive KI-Agenten ausgeliefert. Immer wieder erlebe ich, dass Analysten ihrem KI-System denselben Kontext und Begriffserklärungen mehrfach erklären müssen – das kostet Zeit und führt zu Fehlerquellen.

Warum LLMs Ihren Arbeitskontext „vergessen“

Große Sprachmodelle (LLM) wie Claude oder GPT-4 sind zustandslos: Jeder Prompt ist unabhängig, der Kontext ist auf 128.000 (GPT-4) bzw. 200.000 (Claude) Token begrenzt. Wird der persönliche Arbeitskontext nicht bei jeder Anfrage mitgegeben, weiß das Modell nichts mehr über Ihre Datenschemata, Begrifflichkeiten oder Besonderheiten. Das ist kein KI-Problem, sondern eine Frage der Systemarchitektur.

Übliche Workarounds – und ihre Grenzen

In Projekten sehe ich zwei Muster:

• Alles in den System-Prompt „packen“. Bei mehreren Tabellen und Regeln ist schnell das Kontext-Limit erreicht.
• Manuelles Copy-Paste alter Antworten. Das ist fehleranfällig und verhindert Automatisierung.

Folge: Unklare, inkonsistente Antworten und Wissensverlust zwischen Sessions.

Erprobtes Muster: Persönliche Gedächtnisschicht zwischen Analyst und LLM

Stabile Produktionslösung: eine persönliche Gedächtnisschicht zwischen Analyst und LLM-API. Persönlicher Kontext wird strukturiert gespeichert, automatisch aktualisiert und bei jeder Anfrage selektiv in den Prompt injiziert – ohne manuelles Nachhelfen.

Technische Referenzarchitektur

Schritte zur produktiven Umsetzung

• Automatische Kontext-Extraktion: Begriffe, Definitionen und Regeln aus früheren Nutzerinteraktionen extrahieren (Mustererkennung, Kurz-Zusammenfassungen), als strukturiertes JSON (Postgres JSONB) pro Nutzer speichern.
• Kontextuelle Filterung: Bei jeder neuen Anfrage wird die Gedächtnisschicht nach Relevanz gefiltert (z. B. BM25, oder Kosinus-Ähnlichkeit via Supabase Vector/pgvector).
• Gedächtnishygiene: Veraltete oder irrelevante Fakten werden regelmäßig via n8n-Workflow entfernt. Sonst läuft das Prompt-Limit schnell voll und die Modellqualität sinkt.

Praxisbeispiel: Persönliche Gedächtnisschicht mit Supabase + Claude

Beispiel aus der Logistik: Ein Analyst erklärt dem Agenten die Bedeutung von „zone_group“ und die Struktur von „shipment_id“. Ab dann injiziert die Gedächtnisschicht diese Definitionen bei jedem Prompt automatisch – wiederholte Erklärungen entfallen.

import openai
import psycopg2
import json

def get_personal_context(user_id):
    conn = psycopg2.connect(database="contextdb", user="ai", password="****")
    cur = conn.cursor()
    cur.execute("SELECT facts FROM memory WHERE user_id=%s", (user_id,))
    rows = cur.fetchall()
    return [json.loads(row[0]) for row in rows]

def build_prompt(user_id, user_input):
    context = get_personal_context(user_id)
    prompt = "Benutzerkontext:\n"
    for fact in context:
        prompt += f"- {fact['term']}: {fact['definition']}\n"
    prompt += f"\nBenutzeranfrage: {user_input}"
    return prompt

def query_llm(prompt):
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "system", "content": prompt}]
    )
    return response.choices[0].message.content

Mit Anthropic Claude funktioniert das Muster analog über deren API.

Produktions-Erfahrungen und Compliance-Nuancen

• Kontextverschmutzung: Ohne Relevanzfilter wächst die Kontextgröße schnell – Fehler wie „context window overflow“ drohen. Vector Search oder Schlagwort-Filterung sind Pflicht.
• Datenschutz: Persönliche Fakten enthalten oft sensible Informationen. Verschlüsselung (z. B. Postgres + pgcrypto) und Supabase Row-Level Security sind essenziell. DSGVO und BSI Grundschutz verlangen diese Maßnahmen explizit (bsi.bund.de).
• Versionierung: Ändern sich Definitionen, sollten Revisionen protokolliert werden (JSON-Array oder eigene Revisionstabelle). In einem Fintech-Projekt entstand durch fehlende Versionierung Verwirrung um alte/neue „risk_tier“-Definitionen. Erst nach Einführung der Revisionen verschwanden diese Fehler.

FAQ

Kann RAG (retrieval-augmented generation) das Problem lösen?

RAG eignet sich für Dokumentenbezug, aber persönliche Gedächtnisinhalte gehen darin meist unter. Besser separat speichern und filtern.

Text oder strukturierte Gedächtnisschicht?

Strukturiertes Memory (JSONB) ist für Filter/Versionierung produktionsgeeignet. Plain Text taugt nur für MVPs.

Wie automatisiere ich das Aufräumen des Gedächtnisses?

Mit n8n lassen sich regelmäßige Workflows (z. B. nach Nutzerinaktivität) zur Bereinigung einrichten.

Funktioniert die Gedächtnisschicht auch für Teams?

Ja, wenn Sie group_id als Feld ergänzen und darauf filtern. So können Teams gemeinsam Kontext pflegen und nutzen.

Gibt es Speicherlimits in Supabase/Postgres?

Technisch sind zig Megabyte pro Record möglich, praktisch sollten maximal 100 relevante Fakten pro Nutzer gespeichert werden, um Modellfokus zu sichern.

Wo in Ihrer Pipeline verliert Ihr LLM im Produktivbetrieb am häufigsten kritischen Kontext — beim Projektwechsel, bei Terminologieänderungen oder in langen Sessions? Ich freue mich auf Ihren Erfahrungsbericht. Ich biete einen kostenlosen 30-min Stack-Audit für DACH-Unternehmen in regulierten Branchen an. Kontaktieren Sie mich auf LinkedIn oder unter @ger_dennis_ai.