Agentis Memory: Redis-kompatibles Protokoll mit nativer Vektorsuche und lokaler Inferenz
Sechs Subagenten untersuchen einen Vorfall: einer findet OOMKilled in Logs, ein anderer entdeckt einen CPU-Spike in Grafana, ein dritter extrahiert Kontext aus Slack. Ohne gemeinsamen Speicher generieren sie konkurrierende Hypothesen. Die Lösung ist ein Redis-kompatibler Speicher mit integrierter semantischer Suche. Eine GraalVM-Binärdatei, lokale Embeddings via ONNX, jeder Redis-Client verbindet sich ohne Änderungen.
Warum bestehende Lösungen nicht ausreichen
Mem0 und Zep setzen auf REST-APIs, externe Vektordatenbanken (Qdrant, Postgres) und Cloud-Embeddings (OpenAI). Jeder MEMSAVE-Befehl erfordert drei Netzwerk-Hops mit Millisekunden-Latenzen. Redis Stack unterstützt Vektorsuche via RediSearch, benötigt aber externe Vektorinferenz. Ein Zero-Dependency-Dienst war nötig: RESP-Protokoll, asynchrone Vektorisierung, HNSW-Indexierung in einem einzigen Prozess.
Der erste Versuch war ein Redis-Fork mit einem C-Modul und ONNX Runtime. Ergebnis: Segfaults unter Parallelität, manuelle Speicherverwaltung an der Allocator-Grenze. Wechsel zu Java: GraalVM native-image kompiliert in eine 150MB-Binärdatei mit eingebettetem all-MiniLM-L6-v2-Modell (384 Dimensionen, 2-5ms Inferenz).
Tech-Stack für hohe Leistung
- GraalVM native-image: Start <1s, vorhersehbare Latenz ohne JIT-Warmup.
- Java Vector API (Project Panama): SIMD für Kosinusähnlichkeit in HNSW-Suchen.
- Project Loom (Virtual Threads): RESP-Verbindungen in leichtgewichtigen Threads ohne Reactor-Pattern.
- ONNX Runtime: lokale Embedding-Inferenz.
- jvector: HNSW für ANN-Suche.
Benchmark mit memtier_benchmark: JVM-Version — 0,5x Redis (60k ops/s). Nach native-image + Vector API — 1,36x Redis (168k ops/s) bei String-Operationen.
Architektur: KV + Vektorschicht
Klassische KV-Engine (90+ Redis-Befehle: Strings, Hashes, Listen, Sets, Sorted Sets, TTL, SCAN, Pub/Sub) + Vektorschicht.
redis-cli -p 6399 MEMSAVE "agent:fact:stack" "Wir nutzen Python 3.12 mit FastAPI"
# → OK (asynchron: Chunks → Embeddings → HNSW)MEMQUERY vektorisiert die Abfrage, durchsucht HNSW nach Kosinus, gibt Schlüssel+Text+Score zurück:
redis-cli -p 6399 MEMQUERY "Python FastAPI Speicherproblem" TOPK 3
# 1) "agent:fact:stack" "Wir nutzen Python 3.12 mit FastAPI" 0,92MEMDEL entfernt aus HNSW+KV. MEMSIM für Ähnlichkeits-Score zwischen Texten. Asynchrone Verarbeitung: KV OK sofort, Indexierung im Hintergrund (5-10ms/Chunk).
Szenario: Vorfalluntersuchung
- LogsInvestigator:
MEMSAVE "logs:pod:payment" "OOMKilled Pod payment-service". - MetricsInvestigator:
MEMQUERY "Speicherdruck payment-service"→ findet OOM, passt Hypothese an. - SlackContextInvestigator:
MEMQUERY "Deployment payment-service gestern"→ verknüpft mit Deployment.
Synthesizer aggregiert einen kohärenten Bericht ohne Rauschen.
Benchmarks und Optimierungen
| Operation | Redis (ops/s) | Agentis Memory (ops/s) | Beschleunigung |
|-----------|---------------|------------------------|----------------|
| SET/GET | 120k | 168k | 1,36x |
| MEMSAVE | N/A | 12k (mit Inferenz) | - |
| MEMQUERY | N/A | 8k TOPK=10 | - |
Vector API beschleunigt Kosinusähnlichkeit um 2,5x vs. Skalar. Virtual Threads skalieren auf 10k Verbindungen ohne Thread-Erschöpfung.
Wichtige Erkenntnisse
- Kompatibilität: 90% Redis-API + 4 semantische Befehle (MEMSAVE, MEMQUERY, MEMDEL, MEMSIM).
- Leistung: 1,36x Redis bei KV, lokale Inferenz ohne Netzwerk.
- Zero Dependencies: native Binärdatei mit Modell, kein Docker/Schlüssel.
- Anwendungsfall: Echtzeit-Gemeinschaftsspeicher für Multi-Agenten-Systeme.
- Offenheit: Quellcode auf GitHub zum Experimentieren.
— Editorial Team
Noch keine Kommentare.