dsh-session-query-cjk：更适合中文会话的分词方法

[wavingleaf]

会话搜索的中文检索修复：dsh-session-query-cjk（按字切词 + 增量对账）

Show Your Plugins! · 2026-11-12 · 实测环境：Windows、dsh 0.2.1-rc.5（cordis 4.0.5）
仓库：https://github.com/wavingleaf/dsh-session-search-plugins

省流

官方 dsh-session-query-sqlite 有两个独立缺陷，让“搜历史会话”基本不可用：

1. 中文不可检索：FTS5 unicode61 不切连续汉字，查询又被整体包成短语——异步搜索/固件升级/会话插件 实测都是 0 命中；
2. 每次搜索先做全量对账：两遍持久化清单（约 85 秒/遍）+ 工具分页每页重来——一次同步搜索实测卡满 600 秒超时。

dsh-session-query-cjk 是它的 fork（MIT，保留上游 LICENSE），只改四处：按字切词、按会话增量对账、搜索不再内联对账、独立索引库。实测：会话插件 从 0 → 19 个会话，同步搜索从 600 秒超时变成当轮返回。

作者本人对分词和检索是业余沾边级别，且没有试过多种分词策略。本插件以提供思路为主。

环境与规模

项	值
dsh	0.2.1-rc.5（cordis 4.0.5）
本机会话量	622 个会话（638 个日志文件，含 v3/v4 两种格式）
官方索引	604 会话 / 185,022 文档 / 2.11 亿字 / 774 MB
本插件索引	626 会话 / 210,222 文档 / 2.41 亿字 / 约 900 MB

问题 1：unicode61 对中文不切词

dsh-session-query-sqlite 的 FTS5 表用 tokenize = 'unicode61'，而调用方的查询被 quoteFtsData() 整体包成一个短语。连续汉字在 unicode61 里是一个 token，于是短语命中要求“文档里有完全一样的整段连续汉字”。

同一批数据、同一组查询，直接对索引库执行 count(*) … MATCH：

查询	官方 unicode61	本插件（按字切）
会话插件	0	113 文档 / 19 个会话
异步搜索	0	98 文档 / 1 个会话
固件升级	0	51 文档 / 3 个会话
插件（常被标点/加粗隔开）	5,205	11,337
上下文压缩	495	751

插件 能命中只是因为它在原文里经常独立出现；句中短语（“我想做个异步的搜索会话插件”）整段搜不到。

问题 2：每次搜索都先跑全量对账

• searchSessions/searchEvents 每次都先 _reconcile：列两遍持久化清单（本机约 85 秒/遍），两遍逐条 revision 全等才提交；
• 官方工具翻页（20 条/页、上限 100）每页都重新对账；
• 对账在 ctx.sessionQuery 的串行队列里，搜索之间互相排队。

实测（官方 provider）：

场景	结果
session_search（同步，查询「插件」）	卡满 600 秒，工具超时
一次对账（两遍清单，514 会话）	约 170 秒；失败跑满两次尝试约 340 秒

更隐蔽的是：因为“整库静默”这个前提在有活动会话的机器上几乎不成立，索引会长期无法更新（本机从 11-09 起没有一次成功对账）。

本插件改了什么（与上游的四个差异）

1. 按字切词：入库前把每个 CJK 字符用 U+200B 隔开单独成 token；查询侧做同样变换再包短语。等价于子串匹配：搜索插件 能命中「……搜索插件……」里的连续四字。
   • 分隔符要同时满足两条（都是实测出来的）：unicode61 视其为分隔符（私有区 U+E000 不行，会被当成 token 字符）；且不是 JS \s 意义上的空白（否则片段变成「异 步 搜 索」）。U+200B 满足两者，渲染时抹掉即可。
   • 多词按空白切分后 AND：异步 插件 = 两个词各自命中。
2. 按会话增量对账：只列一遍清单；变化的会话并发读取，读完对该会话 stat() 复核；读期间被写的跳过、下一轮补；单会话读坏只跳过它。不再要求整库静默。
3. 搜索不再内联对账：搜索只读现成索引，对账交给后台定时器（默认 10 分钟一轮）；只有空库时首次搜索同步建一次。
4. 独立索引库：application id 1146308691、schema 版本 1、库文件与官方 session-search.db 分离；官方索引不动，回滚只改一行配置。

其余语义（过滤器、排序、游标代数、snippet 截断、openAt 生命周期、单进程单所有者）与上游逐行一致，方便随上游升级对照 diff。

耗时与覆盖（实测）

场景	结果
搜索（索引预热后，同步工具）	毫秒级，当轮返回
首次建索引（452 会话，v4 为主）	72.9 秒
重启后增量对账	60.4 秒
全量重建（626 会话，含 166 个 v3 旧日志迁移）	465.7 秒
索引覆盖	626 / 622（含实时会话），skipped: 0

覆盖缺口的修复：v3 旧日志的 revision 含“历史语料修订”，并行迁移时会互相作废（455/622）；对 v3 跳过读后复核（v3 日志不可追加）后一次收敛到 626/622。

安装

在 profile 的 cordis.patch.yml 里把 optional-session-search 组的 provider 行换成本插件（组内两行要整份重述，patch 对 config 是整体替换）：

- id: optional-session-search
  config:
    - id: optional-session-query-cjk
      name: 'dsh-session-query-cjk'
      config:
        path: !!js dshHomePath('storages/session-search-cjk.db')
        openAt: startup
        refreshInitialDelaySeconds: 5
        refreshIntervalMinutes: 10
    - id: optional-tool-session-query
      name: '@deepseek-ai/dsh-tool-session-query'
      config:
        searchTimeoutMs: 120000

包：dsh-session-query-cjk（仓库 dist/ 下有 tgz）。装完重启 dsh。

已知限制

• 子串语义：查询要求连续出现（异步搜索 不命中「异步的搜索」）；多个词用空格分开。
• 单字查询命中过宽（等价于单字子串），是刻意的取舍。
• 索引滞后：后台默认 10 分钟一轮，最新会话最坏滞后一个周期。
• 首轮对账：重启后首轮对账期间搜索会排在其后（增量约 1 分钟；全新库约 8 分钟，v3 迁移占大头）。
• fork 维护成本：上游升级时要 diff 并移植四处改动（已核对 0.2.2-rc.1 的 provider 与 rc.5 一致，尚未修改）。
• 大肥鱼协助开发（并编写该文档的98%部分），作者本人对分词和检索是业余沾边级别，且没有试过多种分词策略。本插件以提供思路为主。

许可

fork 自 @deepseek-ai/dsh-session-query-sqlite（MIT, Copyright (c) 2026 DeepSeek），包内保留上游 LICENSE 全文；改动范围为上述四处，其余代码逐行一致。