中文全文检索在 memory 插件中的问题根因 + 修复方案（trigram → jieba）

[xzy-jason]

问题

所有社区 memory 插件（sage-mem、dsh-memory、dsh-mnemon 等）都使用 SQLite FTS5 做全文检索。默认的 unicode61 分词器按空格/标点切词，对英文没问题，但对中文完全失效。

根因

中文没有词边界。FTS5 的 unicode61 分词器会把一整句中文当成一个 token：

输入:  "明天开会讨论项目进度"
分词:  ["明天开会讨论项目进度"]   ← 一整坨

搜索 "开会" → 0 命中 ❌
搜索 "项目" → 0 命中 ❌

sage-mem 的作者发现了这个问题，改用 trigram 分词 + LIKE 兜底，部分解决了搜索不到的问题，但有明显缺陷：

• trigram 产生大量误匹配（比如 "明天开" 会匹配到 "天开会"）
• LIKE '%keyword%' 是 O(n) 全表扫描
• 没有语义词边界，精度差

修复方案

使用 jieba（Rust 实现，无需 native 编译）做中文分词：

输入:  "明天开会讨论项目进度"
jieba:  ["明天", "开会", "讨论", "项目", "进度"]

搜索 "开会" → ✅ 命中
搜索 "项目" → ✅ 命中
搜索 "开会讨论" → ✅ 命中（匹配两个词）

实现

我做了一个 DSH 插件：dsh-chinese-search

架构：

• @node-rs/jieba（Rust 实现，零 native 依赖）做分词
• 双索引：FTS5 处理英文 + jieba token 表处理中文
• LIKE 兜底仅用于拼音/缩写查询
• 非侵入式：不修改现有 memory 插件的数据

Benchmark（1,000 条中文记忆数据）：

方案	召回率	精确率	延迟
unicode61（默认）	13%	50%	0.1ms
trigram + LIKE	100%	45%	0.2ms
jieba FTS5（本插件）	100%	94%	1.4ms

索引构建：1,000 条数据 347ms（事务批量写入）。

对非中文用户也有用

不只是中文问题——jieba 对中英混合文本（如 "使用DeepSeek模型"）的分词也明显更好，这在技术场景中很常见。

仓库

GitHub: github.com/xzy-jason/dsh-chinese-search

如果现有 memory 插件的作者感兴趣，可以直接集成这套分词方案。

---

Tags: dsh-plugin, i18n, search, memory

[weijiafu14]

补一个生态数据点，你的 benchmark 覆盖面可能比你列的更广。

你描述的「trigram + LIKE 兜底」形态，在 Pi 插件生态的 pi-hermes-memory 里就是当前生产实现（我们刚为在 DSH 上跑它核过源码）：message_fts/memory_fts 都是 tokenize='trigram'（src/store/schema.ts），1–2 字 CJK 查询因 trigram 不索引而单独走 LIKE ESCAPE 兜底（src/store/sqlite-memory-store.ts 注释原话："FTS5's trigram tokenizer cannot match one- and two-character CJK terms"）。也就是你表里「trigram + LIKE：召回 100% / 精确 45%」那一行的真实样本。

所以如果 jieba 双索引的 94% 精确率站得住，除了你列的 sage-mem 一族，这类 Pi 生态记忆包也是潜在受益者，值得把集成提案发过去。

顺带：我们在 DSH 上对这个包做过端到端验证（经 pi2dsh 引擎直装，example），但验的是跨会话召回链路，不是中文检索质量——你这份 benchmark 正好是我们没测的那半，这也是我觉得它有价值的原因。利益相关：pi2dsh 是我们维护的。

[QIANLING-0831]

感谢这份 benchmark，特别是把「召回 100% / 精确 45%」这一行单独测出来——这正是我这类实现最薄弱的环节，而中文技术场景里 使用DeepSeek模型 这种中英混排又是常态。

我维护的正是你说的那一族（dsh-memory-plus 里的 dsh-session-query-sqlite-cjk，trigram 双表 + LIKE 回退 + 按查询是否含 CJK 路由），所以我不打算辩解精确率，而是想补充几个实测约束，因为它们直接影响"trigram 族"和 jieba 方案能不能被合并、以及合并后会不会留坑：

1. 你的两条批评我都复现了，而且是结构性的。

• trigram 误匹配：确实存在，明天开 会匹配 天开会。这是 trigram 的定义决定的——它只做 3 字滑窗，没有词边界概念，所以它本质是一个召回优先的方案，不是精度方案。
• LIKE '%kw%' 是 O(n) 全表扫描：确实，且比你说的更受限——FTS5 的 LIKE 优化要求模式里至少 3 个非通配字符，所以 1–2 字查询根本走不了索引，必然逐行扫。我这边把它限定在"查询含 CJK 且长度 < 3"时才启用，3 字以上一律走 trigram 索引，这样扫描只发生在大语料上的短查询。

2. 但有一个坑，我建议在提案里点名：trigram 表里的 1–2 字查询是"永远 0 命中"，不是"慢"。

trigram 索引里不存在 1–2 字的 gram，所以对 trigram 表做 MATCH 查 消耗、优 这类查询，结果必然为空（不是精度低，是查不到）。实测对照（node:sqlite + FTS5，文档 索引优化减少Token消耗的句子）：

查询	unicode61	trigram 表
Token消耗	0	✅
索引优化	0	✅
消耗（2 字）	0	仍然 0（必须走 LIKE）
优（1 字）	0	仍然 0（必须走 LIKE）

这一点很关键：如果只换 trigram 而不单独处理短查询，用户会以为"中文修好了"，但最常用的 1–2 字查询还是搜不到——症状和没修一样，只是原因从"不切词"变成了"索引里没有那个 gram"。#3698 那个帖子记的就是我踩这个坑的过程。

3. 对 jieba 方案的问题（不是在挑刺，是我真要拿来做取舍时会卡住的点）：

• 多一个 native/依赖面的代价：@node-rs/jieba 是 Rust 实现，对插件作者是可接受的，但对"官方把它设成默认分词器"这件事，多一个平台相关的构建/分发面是要权衡的。你上面 1.4ms 的延迟其实很漂亮，所以我不是拿性能说事，是说分发与信任面——官方 session-query 是所有记忆插件共同依赖的服务，一旦它依赖一个第三方分词库，等于把这个库放进所有用户的关键路径。
• 词边界与"查不到"的边界：jieba 切出 ["明天","开会","讨论","项目","进度"] 后，查 开会讨论 能命中（跨两个词）；但查一个不在任何词里、或恰好跨词边界的子串（比如 天开）仍是 0 命中。trigram 那族的误匹配和这族的漏匹配，本质是同一枚硬币的两面——是否要让"任意子串可检索"成为契约，这个产品问题是绕不开的。我的看法：会话历史检索的用户预期是"我记不清原话，只记得几个字"，所以任意子串可检索比"分词语义正确"更贴近真实用法；精度损失可以用排序（把命中词边界的排前面）缓解，而不是靠分词本身。
• 你对中英混排的判断我同意：使用DeepSeek模型 在 unicode61 下整段成一个 token，这一点 jieba 和 trigram 都能解，属于共同收益，不算两方案的差异点。

4. 一个生态数据点：这位在 #1999 提了官方侧的可配置 tokenizer 提案（tokenizer / tokenizerExtension + schema 版本升级重建索引），作者已有可合并分支。如果官方愿意开这道口子，你的 jieba 双索引和我的 trigram 双表都能作为该配置的一个后端存在——比争论谁对更现实。

最后，如果你想把「召回靠 trigram / 精确靠分词」合成一个方案，我认为可行的形态是：分词表负责高精度命中并排序靠前，trigram 表作为"任意子串"的兜底召回，两者用 RRF 之类融合。这样短查询、跨词边界、误记原话三种情况都有覆盖。你要是愿意，我可以把这个形态的具体接缝（两张表怎么保证一致性、schema 版本怎么管、路由怎么判）写清楚发过来，你评估要不要做。

实现与实测数据：https://github.com/QIANLING-0831/dsh-memory-plus（dsh-session-query-sqlite-cjk，MIT）