Memory-Architekturen im Vergleich
Lokales SQLite + FTS5, Knowledge Graph, Vector-Embeddings, Hybrid. Welches passt zu welcher Agent-Form?
Ich habe im letzten Jahr drei Memory-Systeme gebaut. Jedes für eine andere Agent-Form. Jedes mit anderen Trade-offs. Was ich gelernt habe:
System eins war reine Vector-Embeddings (pgvector + Supabase). Jeder Memory-Chunk bekam ein OpenAI-Embedding, Similarity-Search lieferte das Top-k zurück. Fühlte sich smart an. Lieferte ständig irrelevanten Kontext. Das Problem: Vector-Similarity ist ein "Vibe"-Match. Wenn der User fragt "was war der Bug den wir letzte Woche im Auth-Flow gefixt haben", liefert das Top-k allgemeine Auth-Themen, nicht den spezifischen Bug. Vector-Retrieval ist super für semantische Nachbarschaften, schlecht für spezifischen Recall.
System zwei war Full-Text-Search (SQLite FTS5). Keine Embeddings, nur BM25-Ranking auf den Wörtern in den Memories. Schneller, keine API-Calls, keine Embedding-Rechnung. Für spezifischen Recall hat es Vector-Search platt gemacht. Für semantische Queries (du weißt das Wort nicht mehr, aber das Konzept) hat es daneben gegriffen.
System drei ist Hybrid: FTS5 als erster Pass (schnell, spezifisch, kostenlos), dann ein Knowledge-Graph für Entity-Recall (Menschen, Projekte, Entscheidungen, Learnings als Knoten mit Kanten). Vector-Embeddings nur als dritter Tier wenn die ersten beiden nichts Relevantes liefern. Kosten 90 % runter, Recall-Qualität hoch. Das ist was local-memory-mcp ausliefert und was studiomeyer-memory in der Cloud nutzt.
Der Knowledge-Graph ist der unbesungene Held. Der Agent braucht für die meisten Queries gar keine Vector-Similarity. Er braucht: "diese Entity wurde erwähnt, hier sind ihre Observations, hier sind ihre Beziehungen". Ein Graph beantwortet das in einer Query. Vector-Search beantwortet es probabilistisch und der Agent muss das Rauschen rausfiltern.
Wann du Vectors nutzen solltest: deine Daten sind hauptsächlich unstrukturierter Fließtext, du hast keine Entities zum Extrahieren, die Queries sind konzeptionell. Wann nicht: du kannst Entities extrahieren, du hast spezifische Terminologie, du brauchst präzisen Recall.
Ehrlicher Vorbehalt: der beste validierte LongMemEval-Run für unser Hybrid-Memory liegt bei 86 % auf 50q stratified (GPT-4o als Judge, Anthropic Sonnet 4.6 als Answer-Generator, Run S957b am 1. Mai 2026). Der Run lief gegen Memory-Server v3.16.10, vor dem v3.16.11 Cross-Project-Search-Leak-Fix vom 2. Mai 2026, deshalb können die 86 % um 1-3 Prozentpunkte inflated sein; die realistische Range nach einem sauberen Re-Run ist 78-86 %. Vergleich: Mem0 Managed Platform ist im April 2026 auf 93,4 % gesprungen (Token-Efficient Memory Algorithm), bricht aber auf BEAM-10M Production-Scale auf 48,6 % Aggregat / 16,3 % temporal ein. Die Benchmark-Page auf studiomeyer.io trackt Methodik und Run-Logs.
Pattern das ich immer sehe: Builder picken Vectors zuerst weil das Marketing Vectors sagt. Kriegen schlechten Recall und schieben es aufs Embedding-Modell. Das Embedding-Modell ist okay. Die Architektur ist falsch. Probier FTS5 zuerst. Pack einen Graph dazu wenn du Entities hast. Vectors zuletzt.