Generated by Answer me with HTML 0.5.7 · 2026-10-23 09:51 · ★ Star on GitHub

元数据、过滤、全文检索对 hy-memory 有没用

按你库里 1911 条实测，三样只有一样在干活

sourcehy_memory · chroma.sqlite3 实测

结论

全文检索：你本来就没有。chroma 后端的 keyword_search 直接返回空列表。
元数据：必须有，但它是键值数据，sqlite 也能存。
过滤：唯一真在干的活，而且只用到 user_id 加 status 两个条件。
换 faiss 丢的是代码里的调用点，不是能力。

A

三样的真实状态

能力	chroma 侧实现	你现在用不用	证据
全文检索	空实现返回 []	不用	keyword_search 直接 return []
元数据存储	每条 25 个字段	用	1916 条全有 status、layer、tags
元数据过滤	where 原生支持	每次检索必带	每次带 status 与 is_latest
会话隔离过滤	isolation_key	仅显式传参时	传 session_ids 才生效

全文检索是死路径

代码注释写明：旧的 where_document 子串匹配命中只给 1.0，被 sigmoid 压到 0.039，反而稀释强语义结果。所以直接退化为纯向量召回。

B

你库里过滤维度的实际分布

记忆总数: 1916 条
user_id 取值数: 1
agent_id 取值数: 1
isolation_key 取值数: 336
layer 取值数: 3 层
status 取值数: 3 种

维度	取值	条数
status	active	1279
status	shadow	619
status	superseded	18
layer	l1_raw	1062
layer	l2_fact	799
layer	l7_intention	55

user_id 与 agent_id 恒为单值，身份隔离没有实际作用。
336 个 isolation_key 是写入时按会话打的标。
Hermes 日常召回不传 session_ids，所以是跨会话全库召回。
真正每次生效的条件只有两个：user_id 等于 root，status 等于 active。

C

换 faiss 要补什么

faiss 不支持 where，只能先算出 id 白名单再检索。
你实际需要的白名单就是 status 为 active 的 1279 条。
sqlite 建两个索引字段即可，改动量在存储层。
代价是全代码库 20 多处 where 调用点要改写。

D

判断

当前实际用到的过滤条件2 / max 4 个

全文检索实际可用性max 0 条通路

元数据字段数25 / max 25 个

对单人单 agent 的环境，chroma 这三样里只有带 status 过滤的向量检索在干活。
全文检索删掉你不会有任何感知，它现在是空函数。
元数据和过滤可以搬到 sqlite 加 faiss，能力不丢，改的是代码。
所以换后端省 81 MB 的代价是改造工作量，不是功能损失。

---
template: sheet
theme: shadcn
title: 元数据、过滤、全文检索对 hy-memory 有没用
subtitle: 按你库里 1911 条实测，三样只有一样在干活
cols: 3
source: hy_memory · chroma.sqlite3 实测
---

```callout info 结论
- 全文检索：你本来就没有。chroma 后端的 keyword_search 直接返回空列表。
- 元数据：必须有，但它是键值数据，sqlite 也能存。
- 过滤：唯一真在干的活，而且只用到 user_id 加 status 两个条件。
- 换 faiss 丢的是代码里的调用点，不是能力。
```

## A 三样的真实状态

| 能力 | chroma 侧实现 | 你现在用不用 | 证据 |
|---|---|---|---|
| 全文检索 | no 空实现返回 [] | no 不用 | keyword_search 直接 return [] |
| 元数据存储 | ok 每条 25 个字段 | ok 用 | 1916 条全有 status、layer、tags |
| 元数据过滤 | ok where 原生支持 | ok 每次检索必带 | 每次带 status 与 is_latest |
| 会话隔离过滤 | ok isolation_key | warn 仅显式传参时 | 传 session_ids 才生效 |

```callout warn 全文检索是死路径
代码注释写明：旧的 where_document 子串匹配命中只给 1.0，被 sigmoid 压到 0.039，反而稀释强语义结果。所以直接退化为纯向量召回。
```

## B 你库里过滤维度的实际分布

```kv
记忆总数: 1916 条
user_id 取值数: 1
agent_id 取值数: 1
isolation_key 取值数: 336
layer 取值数: 3 层
status 取值数: 3 种
```

| 维度 | 取值 | 条数 |
|---|---|---|
| status | active | 1279 |
| status | shadow | 619 |
| status | superseded | 18 |
| layer | l1_raw | 1062 |
| layer | l2_fact | 799 |
| layer | l7_intention | 55 |

- user_id 与 agent_id 恒为单值，身份隔离没有实际作用。
- 336 个 isolation_key 是写入时按会话打的标。
- Hermes 日常召回不传 session_ids，所以是跨会话全库召回。
- 真正每次生效的条件只有两个：user_id 等于 root，status 等于 active。

## C 换 faiss 要补什么

```flow LR
写入 -> (sqlite 元数据表)
(sqlite 元数据表) -> faiss 索引
查询 -> (sqlite 元数据表): 先取 active 的 id 白名单
(sqlite 元数据表) --> faiss 索引: IDSelector 带 id 进检索
faiss 索引 -> 返回结果
```

- faiss 不支持 where，只能先算出 id 白名单再检索。
- 你实际需要的白名单就是 status 为 active 的 1279 条。
- sqlite 建两个索引字段即可，改动量在存储层。
- 代价是全代码库 20 多处 where 调用点要改写。

## D 判断

```limits
当前实际用到的过滤条件 | 2 / 4 | 个
全文检索实际可用性 | 0 | 条通路
元数据字段数 | 25 / 25 | 个
```

- 对单人单 agent 的环境，chroma 这三样里只有带 status 过滤的向量检索在干活。
- 全文检索删掉你不会有任何感知，它现在是空函数。
- 元数据和过滤可以搬到 sqlite 加 faiss，能力不丢，改的是代码。
- 所以换后端省 81 MB 的代价是改造工作量，不是功能损失。