Almacenamiento compatible con Redis con búsqueda vectorial

Agentis Memory: Protocolo Compatible con Redis con Búsqueda Vectorial Nativa e Inferencia Local

Seis subagentes investigan un incidente: uno encuentra OOMKilled en los registros, otro detecta un pico de CPU en Grafana, un tercero extrae contexto de Slack. Sin memoria compartida, generan hipótesis contradictorias. La solución es un almacenamiento compatible con Redis con búsqueda semántica integrada. Un solo binario GraalVM, incrustaciones locales mediante ONNX, cualquier cliente de Redis se conecta sin cambios.

Por Qué las Soluciones Existentes No Bastaron

Mem0 y Zep dependen de APIs REST, bases de datos vectoriales externas (Qdrant, Postgres) e incrustaciones en la nube (OpenAI). Cada MEMSAVE implica tres saltos de red con latencias de milisegundos. Redis Stack admite búsqueda vectorial mediante RediSearch pero requiere inferencia vectorial externa. Se necesitaba un servicio sin dependencias: protocolo RESP, vectorización asíncrona, indexación HNSW en un solo proceso.

El primer intento fue un fork de Redis con un módulo en C y ONNX Runtime. Resultado: fallos de segmentación bajo concurrencia, gestión manual de memoria en el límite del asignador. Cambiando a Java: GraalVM native-image compila en un binario de 150MB con el modelo all-MiniLM-L6-v2 incrustado (384 dimensiones, inferencia de 2-5ms).

Tecnologías para Alto Rendimiento

• GraalVM native-image: arranque <1s, latencia predecible sin calentamiento JIT.
• Java Vector API (Project Panama): SIMD para similitud coseno en búsquedas HNSW.
• Project Loom (Hilos Virtuales): conexiones RESP en hilos ligeros sin patrón reactor.
• ONNX Runtime: inferencia local de incrustaciones.
• jvector: HNSW para búsqueda ANN.

Benchmark con memtier_benchmark: versión JVM — 0.5x Redis (60k ops/s). Tras native-image + Vector API — 1.36x Redis (168k ops/s) en operaciones de cadena.

Arquitectura: Capa KV + Vectorial

Motor KV clásico (90+ comandos de Redis: cadenas, hashes, listas, conjuntos, conjuntos ordenados, TTL, SCAN, pub/sub) + capa vectorial.

redis-cli -p 6399 MEMSAVE "agent:fact:stack" "Usamos Python 3.12 con FastAPI"
# → OK (asíncronamente: fragmentos → incrustaciones → HNSW)

MEMQUERY vectoriza la consulta, busca en HNSW por coseno, devuelve clave+texto+puntuación:

redis-cli -p 6399 MEMQUERY "Problema de memoria Python FastAPI" TOPK 3
# 1) "agent:fact:stack" "Usamos Python 3.12 con FastAPI" 0.92

MEMDEL elimina de HNSW+KV. MEMSIM para puntuación de similitud entre textos. Procesamiento asíncrono: KV OK al instante, indexación en segundo plano (5-10ms/fragmento).

Escenario: Investigación de Incidentes

• LogsInvestigator: MEMSAVE "logs:pod:payment" "Pod OOMKilled payment-service".
• MetricsInvestigator: MEMQUERY "presión de memoria payment-service" → encuentra OOM, ajusta hipótesis.
• SlackContextInvestigator: MEMQUERY "despliegue payment-service ayer" → vincula al despliegue.

Synthesizer agrega un informe coherente sin ruido.

Benchmarks y Optimizaciones

| Operación | Redis (ops/s) | Agentis Memory (ops/s) | Aceleración |

|-----------|---------------|------------------------|-------------|

| SET/GET | 120k | 168k | 1.36x |

| MEMSAVE | N/A | 12k (con inferencia) | - |

| MEMQUERY | N/A | 8k TOPK=10 | - |

Vector API acelera la similitud coseno 2.5x vs escalar. Hilos Virtuales escalan a 10k conexiones sin agotamiento de hilos.

Conclusiones Clave

• Compatibilidad: 90% API Redis + 4 comandos semánticos (MEMSAVE, MEMQUERY, MEMDEL, MEMSIM).
• Rendimiento: 1.36x Redis en KV, inferencia local sin red.
• Cero dependencias: binario nativo con modelo, sin Docker/llaves.
• Caso de Uso: memoria compartida en tiempo real para sistemas multiagente.
• Apertura: código fuente en GitHub para experimentación.

— Editorial Team