---
type: types/concept.md
concept_type: architecture
tags: [graph, entities, relationships, knowledge-management]
created: 2026-07-26
modified: 2026-08-29
related: [LLM Wiki Pattern, Memory Lifecycle, Entity Extraction, Typed Relationships, Graph Traversal]
sources: [Source - LLM Wiki v2]
confidence: 0.90
confidence_base: 0.90
provenance: sourced
summary: Typisierte Schicht aus Entities und Beziehungen über den Wiki-Seiten, die eine reichere Wissensdarstellung und graphbasierte Abfragen ermöglicht.
---
# Knowledge Graph

**Typ:** Architektur (Strukturierte Wissensrepräsentation)

## Definition

Ein Knowledge Graph ist eine **typisierte, strukturierte Ebene** über Wiki-Seiten, die Entities und ihre Beziehungen darstellt. Während das ursprüngliche LLM Wiki Seiten mit Wikilinks verwendet (was funktioniert), erfasst das Hinzufügen einer Knowledge-Graph-Ebene eine reichere Struktur, die bessere Abfrage und Entdeckung ermöglicht.

Dieses Konzept wird in [[LLM Wiki Pattern]] v2 als Verbesserung der ursprünglichen flachen Seitenstruktur eingeführt.

## Kernpunkte

### Was das Original richtig macht

Seiten mit Wikilinks sind:
- Menschenlesbar
- Einfach zu erstellen und zu pflegen
- Gut für Narrativ-Informationen
- Funktionieren gut für kleine bis mittlere Wikis

### Was fehlt

Wikilinks allein erfassen nicht:
- **Entity-Typen** (person, project, concept usw.)
- **Beziehungstypen** (uses, depends on, contradicts usw.)
- **Beziehungssemantik** (Richtung, Stärke, Vertrauen)
- **Strukturelle Verbindungen**, die Keyword-Suche vermisst

### Die Knowledge-Graph-Lösung

Der Graph **ergänzt** (ersetzt nicht) Wiki-Seiten durch:

**1. Entity Extraction**
Bei der Aufnahme einer Quelle strukturierte Entities extrahieren:
- **Typen:** People, projects, libraries, concepts, files, decisions, systems, tools, technologies
- **Attribute:** Für jede Entity typspezifische Metadaten speichern
- **Beispiele:** "React" (type: library), "Auth migration" (type: project), "Sarah" (type: person)

**2. Typed Relationships**
Nicht alle Verbindungen sind gleich. Typisierte Beziehungen mit semantischem Gewicht verwenden:

| Beziehung | Gewicht | Beschreibung |
|--------------|--------|-------------|
| depends on | Hoch | Funktionale Abhängigkeit |
| uses | Mittel | Tool/Library-Nutzung |
| implements | Hoch | Schnittstellen-/Spec-Implementierung |
| extends | Mittel | Vererbung/Erweiterung |
| replaces | Mittel | Austauschbeziehung |
| conflicts with | Hoch | Inkompatibilität |
| requires | Hoch | Voraussetzung |
| produces | Mittel | Ausgabe/Artefakt |
| consumes | Mittel | Eingabe/Ressource |
| owns | Mittel | Verantwortung |
| maintains | Mittel | Wartungsverantwortung |
| causes | Hoch | Kausalität |
| fixed | Hoch | Behebung |
| supersedes | Hoch | Versionskontrolle für Wissen |
| contradicts | Hoch | Gegensätzliche Aussagen |
| relates to | Niedrig | Allgemeine Beziehung |

**3. Graph-Traversal für Abfragen**
Statt nur Keyword-Suche kann das LLM:
- Bei einem Entity-Knoten beginnen (z. B. Redis)
- Durch Beziehungskanten nach außen gehen
- Alles Nachgelagerte finden (z. B. alle Services, die von Redis abhängen)
- Verbindungen erfassen, die Keyword-Suche vermisst

**Beispiel-Abfrage:** „Wie wirkt sich ein Redis-Upgrade aus?"
- Bei Redis-Knoten beginnen
- „depends on"-Kanten nach außen folgen
- Finde: Service A, Service B, Service C
- „uses"-Kanten von diesen Services folgen
- Finde: Deployment X, Deployment Y
- Ergebnis: Vollständige Auswirkungsanalyse

## Implementierung

Basierend auf [[Agent Memory]] und [[iii Engine]]:

1. **Entities extrahieren** bei Quellaufnahme
2. **Im Graph-Datenbank** oder strukturiertem Format speichern
3. **Bidirektionale Links pflegen** zwischen Graph-Knoten und Wiki-Seiten
4. **Graph-Traversal aktivieren** für komplexe Abfragen
5. **Graph visualisieren** für menschliches Verständnis

## Graph vs. Seiten

| Aspekt | Seiten | Graph |
|--------|-------|-------|
| Zweck | Lesen, Narration | Navigation, Entdeckung |
| Stärke | Menschenlesbar, reichhaltiger Kontext | Maschinenlesbar, präzise Beziehungen |
| Anwendungsfall | Ein Thema verstehen | Verbindungen finden, Auswirkungsanalyse |
| Wartung | LLM schreibt Prosa | LLM extrahiert Struktur |

**Best Practice:** Beide verwenden. Seiten zum Lesen, Graph zur Navigation und Entdeckung.

## Vorteile

- **Bessere Abfragen:** Verbindungen finden, die Keyword-Suche vermisst
- **Auswirkungsanalyse:** Abhängigkeiten und Beziehungen nachverfolgen
- **Entdeckung:** Verwandte Entities automatisch anzeigen
- **Präzision:** Typisierte Beziehungen sind aussagekräftiger als untypierte Links
- **Skalierbarkeit:** Graph-Struktur ermöglicht effizientes Traversal

## Wann zu verwenden

- Wikis mit >100 Seiten (wo Keyword-Suche zu fehlschlagen beginnt)
- Domänen mit komplexen Beziehungen (Softwaresysteme, Organisationen)
- Situationen, die Auswirkungsanalyse oder Abhängigkeitsverfolgung erfordern
- Multi-Hop-Abfragen (finde X, das sich auf Y bezieht, das sich auf Z bezieht)

## Wann NICHT zu verwenden

- Kleine Wikis (<100 Seiten) - Wikilinks könnten ausreichend sein
- Einfache, lineare Wissensbereiche
- Situationen, in denen der Overhead nicht gerechtfertigt ist

## Verwandte Concepts

- [[LLM Wiki Pattern]] - Gesamtes Muster
- [[Entity Extraction]] - Füllung des Graphen
- [[Typed Relationships]] - Die Beziehungstypen
- [[Graph Traversal]] - Abfragemechanismus
- [[Memory Lifecycle]] - Komplementäres Wissensmanagement
- [[Agent Memory]] - Produktionsimplementierung

## Siehe auch

- [[Hybrid Search]] (nutzt Graph-Traversal als einen Stream)
- [[Event-Driven Automation]] (für automatische Graph-Updates)
- [[Supersession]] (als Graph-Beziehung verfolgt)