Redis 兼容的带有向量搜索的存储

Agentis Memory：兼容Redis协议，原生向量搜索与本地推理

六个子代理调查一起事件：一个在日志中发现OOMKilled，另一个在Grafana中捕捉到CPU峰值，第三个从Slack提取上下文。没有共享内存，它们会生成相互竞争的假设。解决方案是一个内置语义搜索的Redis兼容存储。一个GraalVM二进制文件，通过ONNX进行本地嵌入，任何Redis客户端无需修改即可连接。

现有解决方案为何不足

Mem0和Zep依赖REST API、外部向量数据库（如Qdrant、Postgres）和云端嵌入（如OpenAI）。每次MEMSAVE操作涉及三次网络跳转，带来毫秒级延迟。Redis Stack通过RediSearch支持向量搜索，但需要外部向量推理。需要一个零依赖服务：RESP协议、异步向量化、HNSW索引，全部在单个进程中完成。

首次尝试是使用C模块和ONNX Runtime的Redis分支。结果：并发下出现段错误，在分配器边界需要手动内存管理。转向Java：GraalVM native-image编译成一个150MB的二进制文件，嵌入all-MiniLM-L6-v2模型（384维，推理时间2-5毫秒）。

高性能技术栈

• GraalVM native-image：启动时间<1秒，无需JIT预热即可实现可预测延迟。
• Java Vector API（Project Panama）：在HNSW搜索中使用SIMD加速余弦相似度计算。
• Project Loom（虚拟线程）：在轻量级线程中处理RESP连接，无需反应器模式。
• ONNX Runtime：本地嵌入推理。
• jvector：用于近似最近邻搜索的HNSW算法。

使用memtier_benchmark进行基准测试：JVM版本——性能为Redis的0.5倍（6万操作/秒）。采用native-image和Vector API后——在字符串操作上性能为Redis的1.36倍（16.8万操作/秒）。

架构：KV + 向量层

经典KV引擎（支持90多个Redis命令：字符串、哈希、列表、集合、有序集合、TTL、SCAN、发布/订阅）+ 向量层。

redis-cli -p 6399 MEMSAVE "agent:fact:stack" "我们使用Python 3.12和FastAPI"
# → OK（异步处理：分块 → 嵌入 → HNSW）

MEMQUERY 向量化查询，通过余弦相似度搜索HNSW，返回键+文本+分数：

redis-cli -p 6399 MEMQUERY "Python FastAPI内存问题" TOPK 3
# 1) "agent:fact:stack" "我们使用Python 3.12和FastAPI" 0.92

MEMDEL 从HNSW和KV中移除数据。MEMSIM 用于计算文本间的相似度分数。异步处理：KV操作立即返回OK，索引在后台进行（每块5-10毫秒）。

场景：事件调查

• 日志调查员：MEMSAVE "logs:pod:payment" "OOMKilled pod payment-service"。
• 指标调查员：MEMQUERY "payment-service内存压力" → 找到OOM，调整假设。
• Slack上下文调查员：MEMQUERY "昨天部署payment-service" → 链接到部署记录。

合成器聚合生成连贯报告，无噪音干扰。

基准测试与优化

| 操作 | Redis（操作/秒） | Agentis Memory（操作/秒） | 加速比 |

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

| SET/GET | 12万 | 16.8万 | 1.36倍 |

| MEMSAVE | 不适用 | 1.2万（含推理） | - |

| MEMQUERY | 不适用 | 0.8万 TOPK=10 | - |

Vector API将余弦相似度计算速度提升2.5倍，相比标量计算。虚拟线程可扩展到1万个连接，无线程耗尽问题。

关键要点

• 兼容性：90% Redis API + 4个语义命令（MEMSAVE、MEMQUERY、MEMDEL、MEMSIM）。
• 性能：在KV操作上性能为Redis的1.36倍，本地推理无需网络。
• 零依赖：包含模型的本地二进制文件，无需Docker或密钥。
• 用例：多代理系统的实时共享内存。
• 开放性：源代码在GitHub上，供实验使用。

— Editorial Team