Hermes + Holographic 记忆手册🧠

🧠 Hermes + Holographic 记忆手册

结构化代数记忆系统 · HRR 向量 + FTS 全文检索 · 2026-05-29 补充中文评估

🏗️ 系统架构（实际双轨）

            +-------------------------------------+
            |  memory 工具                         |
            |  add.replace.remove                  |
            +--------+----------------------------+
                     |
          +----------+----------+
          v                     v
+------------------+   +-------------------+
| 平面文件          |   | Holographic       |
| MEMORY.md        |   | Engine (HRR+FTS)  |
| USER.md          |   | SQLite DB         |
| char_limit生效   |   | 无上限             |
| 8800 / 5500      |   |                   |
+---------+--------+   +---------+---------+
          |                       |
          | on_memory_write        | fact_store 工具
          | 自动镜像               | add.search.probe.
          |                       | reason.contradict
          v                       v
   +----------------------------------------+
   |  Agent 上下文                           |
   |  prefetch (自动检索注入)                |
   +----------------------------------------+

重要：两条线并行，不是替代关系。

memory 工具写入 -> 平面文件（受 char_limit 约束）-> 自动镜像到 holographic
fact_store 工具写入 -> 直接到 holographic（无限制）
holographic 的 prefetch 监听对话, 自动搜相关事实注入上下文

什么是 Holographic Memory？

使用 HRR 向量编码, 将事实以代数形式存储在向量空间中。相比旧版纯文本记忆, 支持：

FTS5 全文检索 - SQLite 内置全文搜索引擎, 精确关键词匹配
实体探测 - probe(entity) -> 所有该实体关联事实
关系推理 - reason(entities) -> 多实体交集推导
矛盾检测 - contradict() -> 发现事实冲突
信任评分 - fact_feedback 训练, 好的上升坏的下沉
无上限 - SQLite 后端

三路混合检索（核心机制）

用户 query
    |
    +-> FTS5 (权重 40%)  —— SQLite 全文搜索引擎
    |     +-> 精确关键词匹配, 支持前缀
    |     +-> 中文支持 ✅ (SQLite 原生处理 CJK)
    |
    +-> Jaccard (权重 30%) —— 词集重叠率
    |     +-> text.lower().split() 按空格分词取交集
    |     +-> 中文支持 ❌ (无空格, 整句当一个词)
    |
    +-> HRR (权重 30%) —— 向量代数相似度
          +-> SHA-256 哈希 → 1024dim 相位向量
          +-> 中文支持 ❌ (哈希无语义, "电脑"≠"计算机")
          +-> 仅用于精确拼写匹配

HRR 本质：不是 Embedding

核心事实：Holographic Memory 完全不调用任何 Embedding 模型。HRR 是经典符号 AI 方法 (Plate 1991), 纯代数运算：

encode_token("凯聪")
  -> f"凯聪:0" 的 SHA-256 → uint16 → 归一化到 [0, 2π)
  -> 1024 维相位向量
  -> 完全确定性, 无语义信息

encode_text("凯聪开票信息")
  -> bundle(encode_token("凯聪开票信息"))
  -> 仅 1 个 token (无空格分词)
  -> 中文写在一起 = 不被分割

对比 encode_text("Kaicong invoice info")
  -> bundle(encode_token("kaicong"),
            encode_token("invoice"),
            encode_token("info"))
  -> 3 个 token, 可部分匹配

中文支持评估

现状

策略	权重	中文	英文	原因
FTS5	40%	✅ 好	✅ 好	SQLite FTS5 原生支持 CJK
Jaccard	30%	❌ 差	✅ 好	split() 按空格分词, 中文无空格
HRR	30%	❌ 无语义	🟡 部分	SHA-256 哈希, 纯 identity 匹配

实际体验：日常中文使用主要靠 FTS5 (40% 权重) 扛。短文本（一行话）的模糊匹配, FTS5 前缀搜索已经够用。搜"凯聪开票"能命中"凯聪开票信息"。

改进方案对比

方案	改动量	中文提升	代价	建议
加 jieba 分词	~30min + pip	Jaccard/HRR 从 0→可识别同词, 整体 +~15%	词典 5MB, 低	❌ 不建议
换中文 embed 模型 (bge-small-zh)	~半天	HRR 30% 从哈希→真语义, 整体 +~30%	~100MB 模型, 需 CPU/GPU	🟡 有价值但非紧急
不动, FTS5 扛中文	0	40% 权重已够日常	0	✅ 当前推荐

不推荐 jieba 的理由：fact_store 存的全是短事实（一行话）, FTS5 对短文本的模糊匹配能力已经足够。jieba 带来的边际收益有限, 不值得多一个依赖。如果真要提升中文语义检索, 正确方向是把 HRR 30% 换成 embed 模型, 而不是优化哈希。

HRR 向量深入

操作         函数              数学             用途
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
编码词       encode_atom      SHA-256 → 相位   词→向量
编码文本     encode_text      BoW bundle      文本→向量(按空格分词)
绑定         bind             相位加法         关联两个概念
解绑         unbind           相位减法         从绑定中提取
叠加         bundle           相位均值         合并多个概念
相似度       similarity       cos(Δ相位)       [-1,1] 相似度

关键限制：HRR 没有训练过程, 没有学习, 没有语义理解。两个相关词（"净值"和"NAV"）的向量完全不相关。这是纯 hash 编码的固有缺陷, 不是调参数能解决的。

数据模型

facts 表
+-- fact_id         INTEGER  主键
+-- content         TEXT     事实内容 (FTS 索引)
+-- category        TEXT     分类: user_pref / tool / project / general
+-- tags            TEXT     逗号分隔标签
+-- trust_score     REAL     信任值 0-1, 初始 0.5
+-- retrieval_count INT     检索次数
+-- helpful_count   INT     有帮助次数
+-- created_at      DATETIME
+-- updated_at      DATETIME
+-- hrr_vector      BLOB     1024 维 HRR 相位编码 (~8KB)

entities 表       -> 知识图谱节点
fact_entities 表  -> 事实与实体多对多关联
facts_fts 虚拟表   -> FTS5 全文搜索引擎
memory_banks 表    -> 按 category 聚合的 HRR 叠加向量

当前配置

# config.yaml
memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 8800
  user_char_limit: 5500
  provider: holographic
  nudge_interval: 10
  flush_min_turns: 6

Holographic Engine 内部无独立配置项。FTS5/Jaccard/HRR 三路权重硬编码在 retrieval.py 中（fts_weight=0.4, jaccard_weight=0.3, hrr_weight=0.3），HRR 向量维度 1024。

最佳实践

善用标签 - tags 是过滤维度
合理分类 - user_pref / tool / project / general 四类
原子化事实 - 每条聚焦一个主题
定期反馈 - 用 fact_feedback 训练准确度
清理过时 - 过时事实用 update 修正或 remove 删除
技能联动 - 复杂流程存为 skill, 简单事实存 memory

变更记录

此前 - 旧系统：MEMORY.md + USER.md 纯文本, 2200 字符硬上限, 已 98% 满
配置切换 - config.yaml 启用 provider: holographic
2026-05-14 - 手动迁移 13 条到 fact_store, 旧文件备份
2026-05-18 - 扩容 4 倍：memory_char_limit=8800, user_char_limit=5500。发现 holographic 不能替代平面文件, 是并行补充
2026-05-29 - 补充中文支持评估。结论：三路检索中仅 FTS5(40%) 覆盖中文, Jaccard/HRR 因空格分词+HASH 局限对中文无效。不推荐加 jieba, 不动即最优

最后更新: 2026-05-29 · provider: holographic