Summary

The LIKE fallback in searchKeyword returns results from unrelated files when querying with multi-character CJK strings (e.g. "飞书插件配置"). The LIKE query uses the full token as a single substring pattern, which matches files that discuss the search issue itself rather than files with relevant content.

Environment

• OpenClaw version: 2026.6.5
• FTS tokenizer: trigram
• Embedding provider: Ollama (qwen3-embedding:4b)

Root Cause

In planKeywordSearch, CJK tokens are routed to substringTerms as-is:

if (SHORT_CJK_TRIGRAM_RE.test(token)) {
    substringTerms.push(token);  // "飞书插件配置" pushed as one term
    continue;
}

This generates: WHERE text LIKE '%飞书插件配置%'

Problem: The exact substring "飞书插件配置" rarely appears in actual content. The relevant text is "飞书配置", "飞书插件", "插件配置" etc. spread across different positions. The LIKE query only matches files that literally contain the exact phrase — typically files that discuss the CJK search issue itself (e.g. memory/2026-06-12-cjk-pr-draft.md).

Reproduction

1. Configure agents.defaults.memorySearch.store.fts.tokenizer: "trigram"
2. Index memory files containing Chinese text about 飞书配置
3. Run memory_search with query "飞书插件配置"
4. Observe: keyword results come from memory/2026-06-12-cjk-*.md (issue discussion files), not from files with actual 飞书配置 content

Expected Behavior

The LIKE fallback should find results from files that contain the query terms, not just files that contain the exact phrase. Possible approaches:

1. Trigram-style splitting: Split CJK tokens into overlapping 2-3 character substrings (e.g. "飞书插", "书插件", "插件配", "件配置") and use OR matching
2. Character-level AND: Split into individual characters with AND matching (e.g. LIKE '%飞%' AND LIKE '%书%' AND LIKE '%插%' AND ...*) — tested but too broad
3. Bigram AND: Split into character pairs with AND matching (e.g. LIKE '%飞书%' AND LIKE '%书插%' AND LIKE '%插件%' AND ...) — likely best balance

Impact

• Affected: All CJK memory searches with multi-character queries
• Severity: Medium (keyword results are included but from wrong files, ranked low)
• Frequency: Always for multi-character CJK queries
• Consequence: Keyword search doesn't boost relevance for CJK queries

Related

• PR fix(memory-core): CJK textScore=0 and empty MATCH LIKE fallback #92341 (merge fix for memory-core: mergeHybridResults ignores textScore when keyword/vector chunk IDs don't overlap #92337 — addresses the merge layer, not the LIKE fallback)
• Issue memory-core: CJK text FTS5 search returns textScore=0 with trigram tokenizer #92061 (original CJK textScore=0 report)
• Issue memory-core: mergeHybridResults ignores textScore when keyword/vector chunk IDs don't overlap #92337 (mergeHybridResults discarding textScore)