Mnemo: 面向 LLM 的本地优先 AI 记忆层

Mnemo 是一个本地优先的 AI 记忆层，旨在为 LLM 会话提供持久、结构化的记忆，而无需依赖云端或 Python 运行时。它作为一个 sidecar 服务运行，从对话中提取实体和关系以构建知识图谱，然后将这些信息用于在未来的提示词中注入相关的、经过评分的上下文。

核心功能与工作流程

Mnemo 通过自动化信息的提取和检索，使 LLM 应用能够在不同的会话中保持状态和知识。该系统通过两个主要端点组成的流水线运行：

1. 摄取与提取

当原始文本（例如对话轮次或文档）被发送到 /ingest 端点时，Mnemo 会使用配置好的 LLM 来识别命名实体（人、工具、地点、概念）以及它们之间的关系。这些实体按名称和类型进行去重，别名会被合并，生成的数据会被持久化到 SQLite 数据库中。同时，内存中的 petgraph 会得到更新，以维护知识图谱的结构关系。

2. 检索与上下文注入

当查询被发送到 /retrieve 端点时，Mnemo 会执行一个六阶段的检索流水线来组装 context_prompt：

1. 全文分块搜索：初步搜索相关的文本段落。
2. 实体名称搜索：搜索特定的已知实体。
3. 图谱扩展：在知识图谱上执行广度优先搜索 (BFS) 以查找相关概念。
4. 关系过滤：基于定义的逻辑关系过滤结果。
5. 评分与排序：根据相关性对结果进行排序。
6. 组装：生成最终的上下文字符串，并将其注入到 LLM 的系统提示词中。

图谱扩展后的结果会被赋予 0.5x 的评分，以确保直接匹配的结果始终比推断出的关系排名更高。

技术架构与性能

Mnemo 实现为一套由四个 Rust crates 组成的工具包，以确保高性能和极小的占用空间：

• mnemo-core：处理实体提取、图操作、检索引擎和数据库层的核心库。
• mnemo-api：基于 Axum 的 REST API，作为核心逻辑之上的轻量级处理层。
• mnemo-cli：用于与 API 进行交互的命令行界面。
• mnemo-bench：专门的基准测试套件。

性能基准测试

在配备 SQLite WAL 模式和内存 petgraph 的 Apple M2 上进行测试，系统在核心操作上表现出低延迟（以下为 debug build 数字；据报告 release builds 比其快 3-5 倍）：

操作	平均延迟	吞吐量
实体插入 (SQLite)	~0.12 ms	~8,300 ops/s
按 ID 查找实体	~0.08 ms	~12,500 ops/s
分块插入	~0.14 ms	~7,100 ops/s
全文分块搜索	~0.28 ms	~3,500 ops/s
图邻居 (depth=1)	~0.21 ms	~4,700 ops/s
图邻居 (depth=2)	~0.89 ms	~1,100 ops/s
全检索流水线	~4.2 ms	~238 ops/s

部署与集成

Mnemo 设计灵活，支持任何与 OpenAI 兼容的后端，包括像 Ollama 这样的完全本地化选项。

集成路径

• Docker：推荐使用 Docker Compose 同时部署 Mnemo 和 Ollama。
• Binary：对于单独运行 LLM 后端的用户，可通过 cargo install 进行安装。
• Python SDK：可通过 pip 获取 mnemo-sdk 包，以便集成到基于 Python 的 LLM 流水线中。

配置

配置通过环境变量或 TOML 文件进行处理。关键变量包括 MNEMO_LLM_BASE_URL（默认为 Ollama）、MNEMO_LLM_MODEL 以及 MNEMO_LLM_PROVIDER（支持 ollama、openai、anthropic 或 custom）。

社区见解与不同观点

虽然 Mnemo 为本地记忆提供了一种结构化的方法，但社区讨论也为开发者提出了几点考量：

• 上下文窗口管理：一些用户建议，用过多的记忆填充 LLM 的上下文窗口可能会降低模型性能。
• 功能对等性：讨论指向了使用 BM25 嵌入来改进检索的可能性。
• Project-level 记忆：一些开发者认为，记忆的需求正在转向项目级存储，即可以跨不同模型和框架共享的存储，而非仅仅是基于会话的记忆。
• 集成趋势：普遍观点认为，受管代理框架最终可能会原生集成这些功能，从而可能减少对独立 sidecar 服务的需求。