---
template: sheet
theme: shadcn
title: YantrikDB 插件：第三个选项
subtitle: 三者里最贴这台 2G2C 的设计，但中文召回是个真问号
cols: 3
source: yantrikdb-hermes-plugin v0.27.2 · 仓库 README 与 pyproject · 本机实测
---
和 Mnemosyne 不同，这个是 Hermes 原生 memory provider，能直接装、直接换。设计上它是三个里最省资源的：进程内嵌引擎、无 torch、默认 embedder 只有 8MB、向量 64 维。但它默认的嵌入模型是英文的。

## A 结论

```callout info 一句话
Mnemosyne 装不上，它要 AstrBot。hy-memory 在跑，峰值 455MB。YantrikDB 是唯一装得上且设计更省的选项。代价是中文召回未知，每轮还多 1.7k token 工具 schema。
```

不要现在换。先做一次同语料 A/B：200 条真实中文记忆，两个 provider 各跑一遍召回和 RSS。

## B 三个插件的真实关系

| 项 | hy-memory | Mnemosyne | YantrikDB |
|---|---|---|---|
| 宿主 | Hermes provider（exclusive） | AstrBot 插件 | Hermes provider（exclusive） |
| 进程 | 独立 19527 端口 | 宿主同进程 | 进程内嵌，无服务 |
| 引擎 | 自研 SDK + Chroma | Chroma / Milvus / Qdrant / Weaviate | yantrikdb 引擎（Rust wheel） |
| 嵌入 | bge-m3，远程 API，1024 维 | 宿主 Provider，远程 | 本地 potion-2M，8MB，64 维 |
| 本机能不能装 | 已在跑 | 不能 | 能 |
| 许可证 | — | 自定义 | MIT |

YantrikDB 是本机唯一「一个 pip install 就能起、不额外占进程」的方案。它的引擎是 Rust 编的 wheel，所以 p50 写在 0.6ms 量级。

## C 资源账

本机现状：物理内存 1708MB，已用 900MB，可用 807MB；Hermes 主进程 508MB，hy-memory 独立进程 68 到 455MB。

```kv cols=2
Hermes 主进程: 508 MB（实测）
hy-memory 峰值: 455 MB（实测）
hy-memory 磁盘: venv 700MB + 数据 195MB
YantrikDB wheel: 21.9 MB（PyPI 实测）
YantrikDB 默认模型: 8 MB
向量维度: hy-memory 1024 维 / YantrikDB 64 维
工具 schema: 约 1725 token/轮（core 档 7 个工具）
```

64 维对 1024 维不是小数差别：2000 条记忆下向量本体从约 8MB 降到 0.5MB。这也是为什么它的内存曲线不会像 hy-memory 那样往上爬。

## D 跟 hy-memory 的设计分歧

| 能力 | hy-memory | YantrikDB |
|---|---|---|
| 写入时机 | 5 个 hook，含 sync_turn 每轮 | 4 个 hook：session_end / pre_compress / memory_write / delegation |
| 记忆模型 | 原子事实 + 演进链 + 实体图 | 事实 + 时间上下文图 + 生命周期（提升/降级/取代） |
| 去重 | 阈值 0.75 合并 | 规范化（canonicalisation）+ 冲突标记 |
| 矛盾处理 | 合并演进链 | `conflicts()` + `resolve_conflict()`，两方都留着 |
| 可解释性 | 无 | 每条结果带 `why_retrieved` 打分理由 |
| 压缩保护 | on_pre_compress 注入 | on_pre_compress 注入高显著度记忆 |
| 多入口隔离 | user / agent 命名空间 | owner scoping + 共享组空间 |
| 技能沉淀 | 无 | 数据库原生技能 + 结果账本 |

差异不在功能多少，在取向：hy-memory 追求「把记忆理干净」，YantrikDB 追求「让记忆可解释可追溯」。矛盾时它保留双方而不是合并，这对复盘场景可能更有用——你以前吃过「旧结论覆盖新结论」的亏。

## E 两个真实风险

```callout warn 中文召回
默认 embedder 是 `potion-base-2M`：英文静态嵌入，8MB，64 维，作者自报约 MiniLM 的 89%。

你的记忆绝大多数是中文。多语言路径要换 `minishlab/potion-multilingual-128M`，128M 参数，体积我这边核实不了（HuggingFace 不可达），按参数量估至少 250MB 级。
```

- **每轮 token**：工具 schema 每轮重发，`core` 档 7 个工具约 1725 token，`full` 档 18 个约 3606 token。你是成本敏感场景，这笔要算进日常。
- **写入队列**：作者自己的 1000 条压测里，第 257 条起撞上「ingest queue full」，只写进 256 条。作者归因于引擎 0.7.8 的队列回归，但对你意味着突发批量写入要限速。
- **成熟度**：版本 0.27.2，迭代很快（0.1 到 0.27 只用了 5 个月），意味着接口还会变。500+ 测试、CI 跑 Python 3.11 到 3.14。

## F 作者自报的基准怎么读

仓库里 `tests/comparison/findings_scale_lxc/` 有一套 1000 条事实 + 20 条查询的对比：

| Provider | 写入 | 召回 p50 | P@5 | why_retrieved |
|---|---|---|---|---|
| yantrikdb | 256/1000（队列卡住） | 3.78 ms | 0.80 | 有 |
| holographic | 1000/1000 | 0.06 ms | 0.00 | 无 |
| hindsight | 1000/1000 | 0.28 ms | 0.00 | 无 |

这两家 P@5=0 来自环境。hindsight 跑在无 key 的 local_stub，写入立即返回但召回为空；holographic 是纯关键词 FTS5。所以这不是吊打同行，是另外两家没在能工作的模式下被测。

真相是：只有 yantrikdb 这一列是有效测量，且只到 256 条。

## G 要试就怎么试

不要直接切生产 provider，按这个顺序：

- **隔离装**：`pip install yantrikdb-hermes-plugin` 装进 Hermes 同一 venv 只会多约 22MB 代码，不装模型不加载就不占内存。
- **同语料 A/B**：从 hy-memory 导出 200 条真实中文记忆，两边各导入一份。
- **量三样**：中文查询命中率（人工看前 5 条）、进程 RSS 增量、单次召回延迟。
- **只测不切**：`memory.provider` 改回去成本很低，但 hy-memory 的历史数据与 YantrikDB 的库不互通，切之前先想清楚要不要双写一段。

判定线建议：中文 P@5 不低于 0.7、RSS 增量不超过 150MB，才值得换。达不到就留在 hy-memory，把它的 455MB 峰值当独立问题治。

未核实：插件在本机的真实 RSS（模型要下 HuggingFace，本机不可达）；multilingual-128M 的实际体积与中文效果；引擎 0.23.2 是否已修掉队列上限。