Quelle
- GitHub: https://github.com/adoresever/graph-memory — Knowledge Graph Context Engine für OpenClaw
- Trend: Mehrere Community-Projekte (coolmanns/openclaw-memory-architecture, CortexReach/memory-lancedb-pro) konvergieren auf strukturierte Relationship-Speicherung
- Timing: Letzte 24h stark gewachsen, graph-memory-Plugin aktiv beworben
Insight
Das graph-memory-Plugin extrahiert aus Konversationen strukturierte Triples (subject → relation → object) und speichert diese als kompakten Knowledge Graph. Ergebnis: 75% Kontext-Kompression bei gleichzeitig besserer cross-session Relevanz. Der Ansatz löst ein bekanntes Problem: Bei langen Sessions gehen präzise Fakten verloren weil Embedding-Suche auf semantische Nähe setzt, nicht auf strukturierte Relationen.
Palaias aktuelles Modell: Freie Texte + BM25/Embedding-Hybrid-Suche + Significance Tags. Das findet ähnliche Entries gut, aber keine Relationship-Chains ("welche Entscheidungen haben Feature X beeinflusst?").
Vorschlag für Palaia
Relationship Index als optionales Layer über dem bestehenden Store:
- Bei
palaia write (oder Auto-Capture): Lightweight Triple-Extraktion via LLM-Prompt (klein, kein API-Overhead wenn lokal)
- Speichern als Metadaten im Entry-Frontmatter:
relations: [{from: X, rel: "causes", to: Y}]
- Neuer Query-Mode:
palaia query --graph "was hat Entscheidung X beeinflusst" — Graph-Walk statt Embedding-Lookup
palaia graph visualize (optional, CLI-ASCII oder Dot-Output)
Kein Neo4j, kein externer Dependency: Relations als YAML im Frontmatter, Index als JSON-File analog zum Embedding-Index.
Warum das Palaia besser macht
- Relationship-Queries heute: nur über Volltextsuche möglich → unzuverlässig
- ADR-Ketten ("warum haben wir X entschieden") würden sofort auffindbar
- Passt zu Palaias zero-deps Philosophie: kein Graphstore, nur strukturierte Metadaten
- Kontext-Kompression: Statt 10 ähnliche Entries → 1 Entry + Relationship-Map
- Differenzierung gegenüber mem0/memory-lancedb-pro die beide kein Graph-Layer haben
Aufwand-Schätzung
L — Triple-Extraktion + Frontmatter-Schema + Graph-Walk-Query + Tests. Kann modular gebaut werden: erst Schema (S), dann Extraktion (M), dann Query (M).
Quelle
Insight
Das graph-memory-Plugin extrahiert aus Konversationen strukturierte Triples (
subject → relation → object) und speichert diese als kompakten Knowledge Graph. Ergebnis: 75% Kontext-Kompression bei gleichzeitig besserer cross-session Relevanz. Der Ansatz löst ein bekanntes Problem: Bei langen Sessions gehen präzise Fakten verloren weil Embedding-Suche auf semantische Nähe setzt, nicht auf strukturierte Relationen.Palaias aktuelles Modell: Freie Texte + BM25/Embedding-Hybrid-Suche + Significance Tags. Das findet ähnliche Entries gut, aber keine Relationship-Chains ("welche Entscheidungen haben Feature X beeinflusst?").
Vorschlag für Palaia
Relationship Index als optionales Layer über dem bestehenden Store:
palaia write(oder Auto-Capture): Lightweight Triple-Extraktion via LLM-Prompt (klein, kein API-Overhead wenn lokal)relations: [{from: X, rel: "causes", to: Y}]palaia query --graph "was hat Entscheidung X beeinflusst"— Graph-Walk statt Embedding-Lookuppalaia graph visualize(optional, CLI-ASCII oder Dot-Output)Kein Neo4j, kein externer Dependency: Relations als YAML im Frontmatter, Index als JSON-File analog zum Embedding-Index.
Warum das Palaia besser macht
Aufwand-Schätzung
L — Triple-Extraktion + Frontmatter-Schema + Graph-Walk-Query + Tests. Kann modular gebaut werden: erst Schema (S), dann Extraktion (M), dann Query (M).