Generated by Answer me with HTML 0.5.7 · 2026-10-23 18:25 · ★ Star on GitHub
YantrikDB 插件：第三个选项
三者里最贴这台 2G2C 的设计，但中文召回是个真问号
和 Mnemosyne 不同，这个是 Hermes 原生 memory provider，能直接装、直接换。设计上它是三个里最省资源的：进程内嵌引擎、无 torch、默认 embedder 只有 8MB、向量 64 维。但它默认的嵌入模型是英文的。
结论
Mnemosyne 装不上，它要 AstrBot。hy-memory 在跑，峰值 455MB。YantrikDB 是唯一装得上且设计更省的选项。代价是中文召回未知，每轮还多 1.7k token 工具 schema。
不要现在换。先做一次同语料 A/B：200 条真实中文记忆，两个 provider 各跑一遍召回和 RSS。
三个插件的真实关系
| 项 | 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 量级。
资源账
本机现状：物理内存 1708MB，已用 900MB，可用 807MB；Hermes 主进程 508MB，hy-memory 独立进程 68 到 455MB。
- 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 那样往上爬。
跟 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 追求「让记忆可解释可追溯」。矛盾时它保留双方而不是合并，这对复盘场景可能更有用——你以前吃过「旧结论覆盖新结论」的亏。
两个真实风险
默认 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。
作者自报的基准怎么读
仓库里 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 条。
要试就怎么试
不要直接切生产 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 是否已修掉队列上限。