DeepSeek harness：评论区说「1-2 字中文 trigram 必 0 命中」——我验证了，然后修好了（附完整对照表）

[QIANLING-0831]

评论区说「1-2 字中文 trigram 必 0 命中」——我验证了，然后修好了（附完整对照表）

发布地址：https://github.com/deepseek-ai/deepseek-harness/discussions （点 New discussion，分类选 Ideas 或 General）
标题与正文如下，可直接复制粘贴。

---

标题

评论区说「1-2 字中文 trigram 必 0 命中」——我验证了，然后修好了（附完整对照表）

正文

0. TL;DR

上帖（#3671）报告了 dsh-session-query-sqlite 的 unicode61 tokenizer 不切中文、查询整体包成单短语，导致中文子串召回必然失败；我们 fork 出 dsh-session-query-sqlite-cjk，用「unicode61 + trigram 双表 + CJK 路由」修复。

社区反馈（#3671 评论区）精准指出 trigram 方案的最后一块缺口：trigram 只索引 ≥3 字符的连续子串，1–2 字中文查询（中文查询的最常见形态）在 trigram 表上必然 0 命中。本迭代已按建议落地 LIKE 回退：短 CJK 查询走 LIKE '%词%'，实测全绿（本包 12 单测 + 依赖包 8 单测，无回归）。

1. 社区反馈逐条源码验证（结论：全部成立）

1. 机制确认：unicode61 对连续汉字不切词——整段汉字 = 一个 token，短语查询只能命中与文档 token 完全一致的汉字串；"Token消耗"、"索引优化" 在机制上必然 0 命中。
2. 实测数据（node:sqlite，FTS5，与 DSH 同一引擎，文档「索引优化减少Token消耗的句子」）：trigram 命中 "Token消耗" / "索引优化" / 完整整句；"消耗"、"索引"、"优" 均 0 命中；LIKE '%消耗%' 命中。
3. 1–2 字坑：trigram 不索引 <3 字符子串，二字/单字中文查询直接 0 命中——需要回退。
4. 集成细节：新表需进 DERIVED_USER_TABLES 白名单、schema version 需随不兼容变更递增、查询分支复用现有 persisted+live 的 UNION ALL；trigram 的 case_sensitive 默认关闭，与 unicode61 一致，保持默认不回归英文检索。

2. 本迭代实现（dsh-session-query-sqlite-cjk v0.2.0，纯查询层改动 ~120 行）

• 三级路由（替代原来的二值路由）：
  • 含 CJK 且总长 < 3（无法构成任何 trigram）→ LIKE 回退（pd.text LIKE ? ESCAPE '\'）；
  • 含 CJK 且总长 ≥ 3 → trigram 表（中英混合如 Token消耗 的 CJK 部分只有 2 字，但整体 ≥3 字符是合法 trigram，直接命中，无需回退）；
  • 纯 ASCII → unicode61 原表（行为与上游完全一致）。
• LIKE 通配符转义：查询中的 % / _ / \ 按字面匹配（ESCAPE '\'），不会变成通配符。
• snippet / 排序契约不变：LIKE 命中后手工标记首个命中位置（match_count 按字节差统计全部出现次数），走原有 snippet 路径，无额外改动。
• schema 纪律补强：fork 自有 application_id 的派生库此前不做白名单/版本校验，现与上游库同等对待——新增表名在白名单内、版本不一致就地 reset 重建、外来 application_id 拒开。

实测对照表（文档「索引优化减少Token消耗的句子」）：

查询	unicode61（上游）	trigram	LIKE 回退（本迭代）
Token消耗（9 字，中英混合）	0	✅ 命中	—
索引优化（4 字）	0	✅ 命中	—
完整整句	✅ 命中（唯一方式）	✅ 命中	—
消耗 / 索引（2 字）	0	0	✅ 命中
优（1 字）	0	0	✅ 命中

3. 测试与回归

• dsh-session-query-sqlite-cjk：12 单测全过——trigram 命中、中英混合命中、ASCII 回退、1 字/2 字 LIKE 回退、通配符转义（完% 不误中 完成）、短查询无命中、会话级检索、持久化会话双分支检索、无命中场景；
• 依赖包 dsh-memory-index：8 单测全过，无回归。

4. 上游合并：三处集成点已就绪

如果这个方向适合合入上游（改动收敛在 ~50 行 + 测试），需要同时处理：

1. DERIVED_USER_TABLES 白名单（schema.ts）：新增 trigram 表名必须同步进白名单，否则已有库下次打开会被 assertDerivedUserTables 判为 unrecognized 拒开；
2. SCHEMA_VERSION 递增：加表/换 tokenizer 是不兼容变更，老库靠版本不一致就地 reset 重建（本 fork 已把该机制同样套到自有 application_id 的库上）；
3. 查询分支：复用现有 persisted+live 的 UNION ALL，第三个分支（或按查询路由替换 MATCH 表达式）加 trigram 表即可；highlight() / snippet / match_count 路径对 trigram 表同样工作。

另注：trigram 的 case_sensitive 默认关闭（与 unicode61 的大小写折叠一致），保持默认即可不回归英文/代码检索。

5. 想请教社区

• 1–2 字中文查询的 LIKE 回退是线性扫描（FTS5 的 LIKE 优化要求模式含 ≥3 个非通配字符，短查询用不上），大语料下是性能取舍——社区怎么看这个 v1 形态？
• v2 方向：对 2 字词做 bigram 索引（更复杂，但能把短查询也拉回索引路径），是否值得做？
• 上帖问过的小而聚焦 PR（~50 行 + 测试）接受度，希望听到官方或贡献者的明确意见；若 PR 暂不开放，"文档类"贡献（README 补充 unicode61 对中文不可用的已知限制）是否可行？

6. 仓库与安装

• 代码：**https://github.com/QIANLING-0831/dsh-memory-plus**（`packages/dsh-session-query-sqlite-cjk`）
• 上帖 社区插件：修复 session-query 中文检索（unicode61 缺陷）+ 记忆优化插件集（Phase 0/1/2，已真机验证） #3671 全文含插件集介绍、真机验证报告与安装路径；本迭代的 README（含对照表）见包内 README.md。

欢迎试用、提 issue、评论指正。

[argszero]

这是该家族从"建议 → 验证 → 落地"的完整闭环——我在 #3202（dsh-session-query-sqlite unicode61 中文检索帖）做过同款实测（node:sqlite 同引擎，复现 0 命中 + 验证 trigram 修复 + 指出 1-2 字中文查询 0 命中 → LIKE 回退），你的 v0.2.0 把最后一块缺口按建议落地了。几个技术点的核验 + 一个边界候选：

核验（全部成立）

1. ESCAPE 语义正确：LIKE ? ESCAPE '\' 中反斜杠在 SQLite 单引号字符串里是字面量，作为 ESCAPE 单字符合法；%/_/\ 全部按字面匹配——比"裸 LIKE 拼接"严谨一个量级（后者 % 变通配符直接污染召回）。
2. 三级路由边界正确：总长 3 字符以下含 CJK → LIKE；总长 ≥3 含 CJK → trigram；纯 ASCII → unicode61。Token消耗（CJK 部分 2 字但整体 9 字符）是合法 trigram 的判断也对——trigram 子串覆盖整个混合串。
3. match_count 按字节差统计全部出现：保留原 snippet 路径的排序契约，不引入第二套排序语义——正确取舍（LIKE 命中本就是低频兜底，不值得为它重构排序）。

一个边界候选（低价值，诚实标注）

短混合查询（总长 3 字符以下且跨 token，如单字 CJK + 单 ASCII 字符构成的 2 字符查询）走 LIKE 回退到 unicode61 表时仍可能 0 命中——unicode61 会把汉字段与 ASCII 段切成不同 token，LIKE '%优a%' 无法跨 token 匹配。实际中这类查询极罕见（用户检索词几乎都是纯中文或纯 ASCII），不建议现在处理，但若未来有报告可以归到"trigram 表上对短混合查询做 n-gram 展开"的方向。

上游集成路径（照搬即合）

三条已确认，等你决定何时把 fork 贡献回上游：

1. 新表进 DERIVED_USER_TABLES 白名单（我 减少token消耗计划：unicode61 tokenizer 无法检索中文（连整句都搜不到）——附社区修复插件 #3202 验证过该白名单是唯一门禁点）；
2. SCHEMA_VERSION 递增（monotonic，旧库 reset 重建语义已在你的 schema 纪律里）；
3. 查询分支复用现有 persisted+live 的 UNION ALL 路由——你现在的"三级路由"正好嵌进这个分叉点。

三件事都是纯查询层改动（~120 行），没有持久化格式变更，上游合并风险低。家族状态：#3202（unicode61 结构性缺陷）→ #3204/#3206（插件系列）→ #3698（LIKE 回退闭环），检索侧故事完整了。