Agentis Memory: Redis-kompatibilní úložiště s nativním vektorovým vyhledáváním a lokálním inferencí
Šest subagentů vyšetřuje incident: jeden najde OOMKilled v logech, druhý vidí náhlý nárůst CPU v Grafaně, třetí extrahuje kontext ze Slacku. Bez společné paměti generují konkurenční hypotézy. Řešením je Redis-kompatibilní úložiště s vestavěným sémantickým vyhledáváním. Jeden binární soubor na GraalVM, lokální embeddingy přes ONNX, jakýkoli Redis klient se připojí beze změn.
Proč stávající řešení nevyhovovala
Mem0 a Zep spoléhají na REST API, externí vektorové databáze (Qdrant, Postgres) a cloudové embeddingy (OpenAI). Každý MEMSAVE znamená tři síťové skoky se zpožděním v milisekundách. Redis Stack podporuje vektorové vyhledávání přes RediSearch, ale vyžaduje externí inferenci vektorů. Potřebujeme službu bez závislostí: RESP protokol, asynchronní vektorizace, HNSW indexace v jednom procesu.
První pokus – fork Redis s modulem v C a ONNX Runtime. Výsledek: segmentační chyby při konkurenci, ruční správa paměti na rozhraní alokátorů. Přechod na Java: GraalVM native-image kompiluje do 150MB binárního souboru s vestavěným modelem all-MiniLM-L6-v2 (384 dimenzí, 2-5ms inference).
Technologický stack pro vysoký výkon
- GraalVM native-image: start <1s, předvídatelná latence bez JIT warmupu.
- Java Vector API (Project Panama): SIMD pro kosinovou podobnost v HNSW vyhledávání.
- Project Loom (Virtual Threads): RESP spojení v lehkých vláknech bez reactor patternu.
- ONNX Runtime: lokální inference embeddingů.
- jvector: HNSW pro ANN vyhledávání.
Benchmark memtier_benchmark: JVM verze – 0.5x Redis (60k ops/s). Po native-image + Vector API – 1.36x Redis (168k ops/s) na řetězcových operacích.
Architektura: KV + vektorová vrstva
Klasický KV-engine (90+ Redis příkazů: strings, hashes, lists, sets, sorted sets, TTL, SCAN, pub/sub) + vektorová vrstva.
redis-cli -p 6399 MEMSAVE "agent:fact:stack" "Používáme Python 3.12 s FastAPI"
# → OK (asynchronně: chunk → embeddingy → HNSW)MEMQUERY vektorizuje dotaz, hledá v HNSW podle kosinu, vrací klíč+text+score:
redis-cli -p 6399 MEMQUERY "Python FastAPI problém s pamětí" TOPK 3
# 1) "agent:fact:stack" "Používáme Python 3.12 s FastAPI" 0.92MEMDEL maže z HNSW+KV. MEMSIM pro skóre podobnosti mezi texty. Asynchronní zpracování: KV OK okamžitě, indexace na pozadí (5-10ms/chunk).
Scénář: vyšetřování incidentu
- LogsInvestigator:
MEMSAVE "logs:pod:payment" "OOMKilled pod payment-service". - MetricsInvestigator:
MEMQUERY "tlak na paměť payment-service"→ najde OOM, upraví hypotézu. - SlackContextInvestigator:
MEMQUERY "deploy payment-service včera"→ spojí s deployem.
Synthesizer agreguje koherentní zprávu bez nepořádku.
Benchmarky a optimalizace
| Operace | Redis (ops/s) | Agentis Memory (ops/s) | Zrychlení |
|----------|---------------|-------------------------|-----------|
| SET/GET | 120k | 168k | 1.36x |
| MEMSAVE | N/A | 12k (s inferencí) | - |
| MEMQUERY | N/A | 8k TOPK=10 | - |
Vector API zrychluje kosinus 2.5x vs skalární. Virtual Threads škálují až na 10k spojení bez vyčerpání vláken.
Co je důležité
- Kompatibilita: 90% Redis API + 4 sémantické příkazy (MEMSAVE, MEMQUERY, MEMDEL, MEMSIM).
- Výkon: 1.36x Redis na KV, lokální inference bez sítě.
- Zero deps: native-binárka s modelem, bez Docker/klíčů.
- Použití: operační sdílená paměť pro multi-agent systémy.
- Otevřenost: zdrojové kódy na GitHubu pro experimenty.
— Editorial Team
Zatím žádné komentáře.