Wie Sie in 1 Tag aus Codechaos einen abfragbaren Wissensgraphen bauen: Das Graphify-Prinzip

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Ich betreibe die DennisCraft AI Studio und liefere produktive KI-Systeme für DACH-B2B-Klienten, insbesondere in regulierten Branchen. Mein Stack: Claude, Supabase, n8n, Doppler und selbst gehostetes Postgres. In einem aktuellen Projekt führte eine nicht synchronisierte Dokumentation dazu, dass ein Agent mehrfach einen veralteten API-Endpunkt im Produktivsystem ansteuerte – mit SLA-Risiko.

Code- und Wissenschaos: Tägliches Risiko für Produktivbetrieb und Compliance

Selbst in Teams mit Swagger, Confluence oder README herrscht oft Unklarheit, welche Schnittstellen wirklich im Einsatz sind. Zuletzt habe ich sechs widersprüchliche Definitionen einer API-Methode gefunden: im Python-Code, OpenAPI, Notion und einem alten PDF. Ein Agent, der auf dieser fragmentierten Wissensbasis operiert, kann DSGVO-relevante Prozesse lahmlegen – das ist realer Produktionsalltag.

Laut ACM Queue, 2004 sind 40 % aller Produktionsfehler auf veraltete oder lückenhafte Dokumentation zurückzuführen. Mit LLM-Agenten und automatisierten Pipelines steigt die Komplexität und das Fehlerpotenzial weiter – insbesondere unter BSI-Grundschutz und EU AI Act.

Wissensgraph statt Silos: Stabilität und Auditierbarkeit im Stack

Was ist ein abfragbarer Wissensgraph?

Ein Wissensgraph ist eine strukturierte Sammlung von Knoten (Funktionen, Klassen, APIs, Geschäftsregeln) und Kanten (Aufrufe, Dokumentation, Referenzen). Der Mehrwert liegt in der Abfragbarkeit: „Welche Endpunkte sind tatsächlich im Betrieb und wo dokumentiert?“

Warum ist 1 Tag realistisch?

Ich verzichte bewusst auf komplexe Graphdatenbanken wie Neo4j. Mit Supabase Postgres, pgvector für Embeddings und klassischen SQL-Tabellen für Relationen baue ich den Graph. ETL übernimmt n8n (für Code, Docstrings, Markdown); Claude Code strukturiert, semgrep analysiert statisch. Transparent, nachvollziehbar, auditierbar.

import openai
import psycopg2

def extract_functions(file_path):
    with open(file_path) as f:
        code = f.read()
    # Extraktion per semgrep oder AST
    # ... (z. B. via subprocess)
    return functions_list

def insert_to_pg(functions):
    conn = psycopg2.connect(dbname="graphify", ...)
    with conn.cursor() as cur:
        for func in functions:
            cur.execute(
                "INSERT INTO nodes (type, name, source) VALUES (%s, %s, %s)",
                ('function', func['name'], func['file'])
            )
    conn.commit()

Schritt-für-Schritt: Wissensgraph-Pipeline im Produktiveinsatz

1. Artefaktextraktion

• Code-Files: Parsing via semgrep und AST
• Dokumentation: Markdown und Docstrings via n8n
• API-Spezifikationen: OpenAPI falls vorhanden, sonst manuell

2. Normalisierung und Vereinheitlichung

Claude Code API bringt alles auf ein einheitliches Schema: Typ, Name, Beschreibung, Relationen. Für Spezialfälle nutze ich individuelle Prompts zur Extraktion von Geschäftslogik aus „menschlichen“ Texten.

3. Laden in den Graphen

Supabase (Postgres) hält Tabellen: nodes (id, type, name, source, embedding), edges (from_id, to_id, relation). Embeddings via pgvector, Modell nach OpenAI cookbook.

curl -X POST 'https://api.openai.com/v1/embeddings' \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{"input": "get_user_profile", "model": "text-embedding-ada-002"}'

4. Abfragen und Audit

In Sekunden beantworte ich: Wo ist ein Endpunkt deklariert, wirklich implementiert, und wer hat zuletzt Änderungen vorgenommen? Jeder Agent oder Mensch kann über die API aktuelle Wissensstrukturen abfragen – dokumentiert für Audit und Nachweispflichten (DSGVO, ISO 27001).

def find_conflicts(pg_conn):
    # Endpunkte aus Doku, die im Code fehlen
    with pg_conn.cursor() as cur:
        cur.execute("""
            SELECT d.name FROM nodes d
            LEFT JOIN nodes c ON d.name = c.name AND c.type='function'
            WHERE d.type='doc' AND c.id IS NULL
        """)
        return cur.fetchall()

Vergleich: Althergebrachte Methoden vs. Wissensgraph

FAQ

Wie schnell kann ein Wissensgraph produktiv sein?

Für Codebasen unter 1.000 Dateien reicht 1 Werktag für ein MVP: Supabase, n8n, semgrep, ein Claude-API-Key.

Erhöht das die Komplexität meines Stacks?

Nein. Der Graph wird zur „Single Source of Truth“. Neue Agenten oder Integrationen greifen sofort auf konsistente Strukturen zu.

Wie halte ich den Graphen aktuell?

n8n triggert Updates bei jedem Push in main. Neue Artefakte? Automatische Aktualisierung.

Sind Cloud-basierte Graphen DSGVO-konform?

Ich speichere nur Metadaten, keinen Quellcode. Für sensible Daten: Self-hosted Postgres, keine externen APIs.

Lässt sich das auf Microservices skalieren?

Ja – jedes Service wird zum Subgraph, Relationen verlaufen zwischen den Knoten.

In welchem Teil Ihres Stacks divergieren Code und Dokumentation aktuell – und wie viele Incidents hat das schon ausgelöst? Was ist Ihre tatsächliche „Source of Truth“: Doku, Code oder etwas anderes? Ich biete einen kostenfreien 30-min Stack-Audit für DACH-Unternehmen im regulierten KI-Umfeld an. Kontaktieren Sie mich auf LinkedIn oder via @ger_dennis_ai.