Agentis Memory: Protokół Redis z natywnym wyszukiwaniem wektorowym i lokalnym wnioskowaniem
Sześć subagentów bada incydent: jeden znajduje OOMKilled w logach, drugi widzi skok CPU w Grafanie, trzeci wyciąga kontekst z Slacka. Bez wspólnej pamięci generują konkurencyjne hipotezy. Rozwiązanie — magazyn zgodny z Redis, z wbudowanym wyszukiwaniem semantycznym. Jeden plik binarny na GraalVM, lokalne osadzanie przez ONNX, każdy klient Redis łączy się bez zmian.
Dlaczego istniejące rozwiązania nie pasowały
Mem0 i Zep opierają się na REST API, zewnętrznych bazach danych wektorowych (Qdrant, Postgres) i chmurowych osadzeniach (OpenAI). Każdy MEMSAVE to trzy skoki sieciowe z opóźnieniami w milisekundach. Redis Stack obsługuje wyszukiwanie wektorowe przez RediSearch, ale wymaga zewnętrznego wnioskowania wektorów. Potrzebna jest usługa zero-dependency: protokół RESP, asynchroniczna wektoryzacja, indeksacja HNSW w jednym procesie.
Pierwsza próba — fork Redis z modułem w C i ONNX Runtime. Wynik: błędy segmentacji przy współzawodnictwie, ręczne zarządzanie pamięcią na styku alokatorów. Przejście na Java: GraalVM native-image kompiluje do 150MB pliku binarnego z wbudowanym modelem all-MiniLM-L6-v2 (384 wymiary, 2-5ms wnioskowanie).
Stos technologiczny dla wysokiej wydajności
- GraalVM native-image: uruchomienie <1s, przewidywalne opóźnienia bez rozgrzewki JIT.
- Java Vector API (Project Panama): SIMD dla podobieństwa cosinusowego w wyszukiwaniach HNSW.
- Project Loom (Virtual Threads): połączenia RESP w lekkich wątkach bez wzorca reactor.
- ONNX Runtime: lokalne wnioskowanie osadzeń.
- jvector: HNSW dla wyszukiwania ANN.
Benchmark memtier_benchmark: wersja JVM — 0.5x Redis (60k ops/s). Po native-image + Vector API — 1.36x Redis (168k ops/s) na operacjach łańcuchowych.
Architektura: KV + warstwa wektorowa
Klasyczny silnik KV (90+ komend Redis: strings, hashes, lists, sets, sorted sets, TTL, SCAN, pub/sub) + warstwa wektorowa.
redis-cli -p 6399 MEMSAVE "agent:fact:stack" "Używamy Python 3.12 z FastAPI"
# → OK (asynchronicznie: fragmenty → osadzenia → HNSW)MEMQUERY wektoryzuje zapytanie, szuka w HNSW po cosinusie, zwraca klucz+tekst+wynik:
redis-cli -p 6399 MEMQUERY "Python FastAPI problem z pamięcią" TOPK 3
# 1) "agent:fact:stack" "Używamy Python 3.12 z FastAPI" 0.92MEMDEL usuwa z HNSW+KV. MEMSIM dla wyniku podobieństwa między tekstami. Przetwarzanie asynchroniczne: KV OK natychmiast, indeksacja w tle (5-10ms/fragment).
Scenariusz: badanie incydentu
- LogsInvestigator:
MEMSAVE "logs:pod:payment" "OOMKilled pod payment-service". - MetricsInvestigator:
MEMQUERY "nacisk pamięci payment-service"→ znajduje OOM, koryguje hipotezę. - SlackContextInvestigator:
MEMQUERY "wdrożenie payment-service wczoraj"→ łączy z wdrożeniem.
Synthesizer agreguje spójny raport bez śmieci.
Benchmarki i optymalizacje
| Operacja | Redis (ops/s) | Agentis Memory (ops/s) | Przyspieszenie |
|----------|---------------|-------------------------|-----------|
| SET/GET | 120k | 168k | 1.36x |
| MEMSAVE | N/A | 12k (z wnioskowaniem) | - |
| MEMQUERY | N/A | 8k TOPK=10 | - |
Vector API przyspiesza cosinus o 2.5x vs skalarny. Virtual Threads skalują do 10k połączeń bez wyczerpania wątków.
Co jest ważne
- Zgodność: 90% API Redis + 4 komendy semantyczne (MEMSAVE, MEMQUERY, MEMDEL, MEMSIM).
- Wydajność: 1.36x Redis na KV, lokalne wnioskowanie bez sieci.
- Zero deps: plik binarny native z modelem, bez Docker/kluczy.
- Zastosowanie: operacyjna pamięć współdzielona dla systemów wieloagentowych.
- Otwartość: źródła na GitHub do eksperymentów.
— Editorial Team
Brak komentarzy.