Mnemo：基于 Rust+SQLite+petgraph 的本地优先 LLM 记忆层架构

大多数 LLM 在对话结束的那一刻就将上下文遗忘殆尽。Mnemo 通过构建一个本地优先的记忆层来解决这一问题：它作为 sidecar 服务运行，自动提取对话中的实体与关系，构建持久化的知识图谱，并在后续对话中注入相关上下文 —— 全程无需联网，延迟控制在 50ms 以内。

架构三件套：Rust + SQLite + petgraph

Mnemo 的技术选型体现了一种务实的工程权衡。核心采用 Rust 实现，分为四个 crate：mnemo-core 负责实体提取与图谱操作，mnemo-api 提供 Axum REST 接口，mnemo-cli 为命令行工具，mnemo-bench 承载性能基准测试。这种模块化设计让开发者可以按需集成 —— 既可以将核心库嵌入现有系统，也可以直接运行独立服务。

持久化层选用 SQLite，并启用 WAL（Write-Ahead Logging）模式。WAL 的核心优势在于解耦读写操作：写操作追加到日志文件，读操作访问主数据库文件，两者无需互斥等待。对于知识图谱这种读多写少的场景，WAL 模式能显著降低并发冲突。实体和关系以结构化形式存储，同时通过 SQLite 的全文搜索扩展（FTS）支持语义检索。

内存中的图计算交给 petgraph——Rust 生态中最成熟的图数据结构库。petgraph 采用邻接表表示法，支持有向图和无向图，内置 BFS、DFS、Dijkstra 等遍历算法。Mnemo 利用 petgraph 维护实时的内存图谱，当 SQLite 中的数据更新时，内存图同步增量更新，确保检索时无需重复查询磁盘。

六阶段检索管道

Mnemo 的检索流程是一个精心设计的六阶段管道，每个阶段都有明确的职责边界：

阶段一：全文块搜索—— 在原始对话片段上执行 FTS 查询，召回语义相关的文本块。

阶段二：实体名称搜索—— 匹配查询中的命名实体（人名、工具、地点、概念等）。

阶段三：图谱扩展—— 以匹配实体为起点，在 petgraph 中执行 BFS 遍历，获取关联实体。遍历深度可配置，默认 depth=1 时延迟约 0.21ms，depth=2 时增至 0.89ms。

阶段四：关系过滤—— 根据关系类型和权重筛选扩展结果，剔除低置信度的边。

阶段五：评分排序—— 综合文本相似度、图谱距离、时间衰减等因素计算相关性分数。

阶段六：上下文组装—— 将排序后的实体和关系格式化为 context_prompt 字符串，注入 LLM 的系统提示。

整个管道的平均延迟约 4.2ms，吞吐量约 238 ops/s（Debug 构建，Release 构建可提升 3-5 倍）。

性能参数与优化要点

根据官方基准测试，Mnemo 在 Apple M2 上的关键指标如下：

几个关键的优化方向值得注意：

WAL 检查点策略：SQLite WAL 文件可能无限增长，建议通过 PRAGMA wal_autocheckpoint 或手动 CHECKPOINT 控制文件大小。对于长时间运行的服务，可在低峰期执行检查点，平衡恢复速度与磁盘占用。

图遍历深度限制：BFS 深度对延迟影响显著，depth=2 时延迟已是 depth=1 的 4 倍。建议默认 depth=1，仅在需要深层关联推理时动态提升。

实体去重机制：Mnemo 按 name+type 去重并合并别名，这要求实体提取的 LLM 提示（prompt）保持稳定。若更换模型或调整提取策略，建议评估去重逻辑的影响。

可落地配置清单

若要在生产环境部署 Mnemo，以下配置参数可供参考：

环境变量

• MNEMO_DB_PATH: SQLite 数据库路径，建议 SSD 存储
• MNEMO_PORT: API 服务端口，默认 8080
• MNEMO_LLM_BASE_URL: 兼容 OpenAI 的端点，本地 Ollama 推荐 http://localhost:11434/v1
• MNEMO_LLM_MODEL: 实体提取模型，Ollama 推荐 llama3（~4GB）
• MNEMO_LLM_TEMPERATURE: 建议 0.1 以获得稳定的实体提取结果

TOML 配置示例

db_path = "mnemo.db"
port = 8080

[llm]
provider = "ollama"
base_url = "http://localhost:11434/v1"
model = "llama3"
api_key = "ollama"
timeout_secs = 30
max_retries = 3
max_tokens = 2048
temperature = 0.1

SQLite 优化建议

PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
PRAGMA wal_autocheckpoint=1000;  -- 每1000页检查点一次

监控指标

• /health 端点返回服务状态、配置来源、LLM 连通性
• /stats 端点提供实体数、块数、图谱边数、运行时长
• 建议监控 WAL 文件大小和检查点频率

适用场景与局限

Mnemo 的定位是个人或小团队的本地知识管理，而非企业级多租户系统。其优势在于零云依赖、数据隐私可控、延迟极低；局限在于单机存储容量（SQLite 理论上限 281TB，但实际性能在 GB 级数据时开始衰减）、无分布式一致性保证、实体提取质量受限于本地 LLM 的能力。

对于需要离线工作的场景（如敏感数据处理、网络受限环境），Mnemo 提供了一个轻量且完整的解决方案。若需扩展至云端或多设备同步，可考虑在其基础上叠加 CRDT 或事件溯源层，但这已超出当前设计范畴。

资料来源

• Mnemo GitHub 仓库 - 官方文档与性能基准
• SQLite WAL 模式文档 - 写入日志与并发控制机制
• petgraph 文档 - Rust 图数据结构库

ai-systems