查詢自身的 turn 成為第一名命中——查詢字串一進語料就把自己召回（self-hit）

[kiki830621]

Problem

v0.4.0 實測（2026-09-03，本機語料 639,209 chunk）：

1. MCP：ltm_query(query: "F_SETNOSIGPIPE EPIPE 測試 host SIGPIPE", limit: 3) 的第一名是這次呼叫本身——session 3a2ceb7e-41cf-41c1-ab0c-d1e197ad4beb turn 4dae970d-bd21-4a3c-89f5-653c088eedcc（2026-09-03T02:25:37Z），內容就是 ⟨tool mcp__plugin_ltm_ltm__ltm_query query=F_SETNOSIGPIPE …⟩。呼叫寫進 jsonl 的時間早於 server 查詢前的增量併入，所以它先被索引、再被自己查到。
2. CLI：ltm query 的三個基準查詢（「tokenizer 討論」「flock inode 鎖」「資格考」）第一名全部是同一則 turn（2026-09-01T04:32:12Z）——查詢穩態延遲 ~4 秒、成本大宗在查詢前增量掃描——能否降到 1 秒以內 #56 量測時那行含有全部三個字串的 Bash 命令 for q in "tokenizer 討論" "flock inode 鎖" "資格考"。

兩者是同一個形狀：查詢字串本身進了語料，之後任何相同查詢都先召回「問這個問題的那一刻」。對導航零價值（讀者要的是被問的事，不是問的動作），而且它會擠掉真正相關的 turn（例 1 裡今天實際討論 F_SETNOSIGPIPE 的 turn 沒進前三）。

LTM 類比（.claude/rules/ltm-analogy.md）：人回想一件事時，不會把「我剛才在想這件事」當成想起來的內容。

Type

bug（檢索品質；不涉及不變式——索引內容正確，是排序／呈現層的問題）

Expected

先決定在哪一層、用什麼判準排除或降權，再實作。候選（不預設答案，需 diagnose）：

• A. 排除「就是這次查詢」的 turn：判準要能機械化——例如 chunk 文字為工具呼叫且其 query= / ltm query "…" 引數與本次查詢逐字相同。最窄、最不會誤殺；擋不住例 2 那種「含有查詢字串的舊命令」。
• B. 降權「內容是 ltm 查詢／量測命令」的 turn：以 chunk 形狀（⟨tool … ltm_query / ltm query）判定，不是以查詢字串判定；涵蓋例 2。要量誤殺率——討論 ltm 本身的 session（本 repo）會大量命中。
• C. 只在呈現層標記（「這是一次查詢動作」）而不改排序——最保守，但沒有解決擠掉相關 turn 的問題。

不論選哪個：不得改寫或刪除索引內容（性質 5：可以遺忘、不可以編造）；決定要落在 MemoryStrategy seam 或檢索層的哪一側，要對照 openspec/specs/memory-strategy/spec.md 的「不得在 seam 之外重排」；前後要有 docs/measurements/ 紀錄（至少例 1／例 2 兩組查詢的前三名變化）。

Actual

如上：兩條路徑的第一名都是查詢動作本身或含查詢字串的舊命令。

相關

• 基準查詢已被語料污染——三個量測查詢字串本身進了索引，需要一組不在語料裡的查詢與一條使用規則 #63（基準查詢污染）：同根源、不同修法——那邊看查詢是否在語料裡，這邊看 turn 形狀
• ground truth 資料集沒有人在追——#16 把它劃出範圍後就沒有落點 #33（評估集）：沒有 (查詢, 應命中的 turn) 資料集，本 issue 的「有沒有變好」目前只能用少數手挑查詢看前三名

Source: surfaced during v0.4.0 post-release smoke test (2026-09-03)

---

Current Status

• Phase: diagnosed
• Updated: 2026-09-07（diagnosis 已 post；Complexity Spectra；Conflict Class C（與 基準查詢已被語料污染——三個量測查詢字串本身進了索引，需要一組不在語料裡的查詢與一條使用規則 #63 共用基準查詢集）；sister 84% 的 chunk 是零內容工具殘影（⟨tool_result ok⟩／metadata-only），照樣進向量通道擠掉實質 turn（sister concern from #62） #67 已開）
• Dashboard: (見下方 dashboard comment)

Tasks

• 1. retrieval spec：fused list 成員資格加「對本系統的查詢動作不進候選」（封閉列舉＋性質 5 推論），明寫是資格過濾非重排
• 2. RetrievalEngine.search 候選資格謂詞，與 session 排除共用 refetch 迴圈（1,000 上限照舊）
• 3. CLI／MCP 預設開，--include-query-turns escape（MCP 同名參數）
• 4. 測試：重現表四列各一條；變異拿掉謂詞 → 紅
• 5. docs/measurements/2026-09-xx-self-hit.md：例 1／例 2 前後前三名＋母體數字＋誤殺面
• 6. CHANGELOG

[kiki830621]

Diagnosis

Type

bug（檢索品質／排序層；索引內容正確，不涉及不變式）

Root Cause / Analysis

我認為 root cause 是：toolUseMetadata 把 query= / command= 欄位逐字收進 chunk 文字，於是每一次「問記憶」的動作本身變成一個極短、與查詢字串逐字相同的 chunk；exact-phrase 的兩條 lexical 通道對它給最高分，而「band ＝ 命中的通道數」再把它推到最高相關度層——真正談那件事的 turn 用的是不同措辭，只中向量通道，落在較低的 band。 這不是排序權重的問題，是 band 分層的問題，所以 MemoryStrategy seam 修不了（策略不得跨 band）。

重現（合成語料，8 筆，.build/debug/ltm，fixture 密鑰，不碰真實索引）——一則實質討論 flock/inode 的 user turn、一則 ⟨tool mcp__plugin_ltm_ltm__ltm_query query=flock inode 鎖⟩、一則 ⟨tool Bash command=for q in "tokenizer 討論" "flock inode 鎖" "資格考" …⟩、四則雜訊：

查詢	第 1 名	band／通道	實質 turn 的名次	band／通道
flock inode 鎖（例 1 形狀）	MCP ltm_query 的 tool_use chunk	0／trigram+segment+vector	5	2／vector
tokenizer 討論（例 2 形狀）	Bash 命令 chunk	0／三通道	2	2／vector
資格考	實質 turn（字串逐字出現於其中）	0／三通道	1	—
語意改寫 flock 綁 inode 原子替換讓鎖失效	實質 turn	2／vector	1	—

判讀：(a) 自我命中只在查詢字串逐字出現在工具 metadata 時發生，且發生時它在 band 0、實質 turn 在 band 2——差兩個 band；(b) 實質 turn 一旦也含逐字字串（資格考）就贏回來，所以問題是 metadata chunk 是「exact-match 磁鐵」：短、全詞命中、無其他內容稀釋 BM25；(c) 改寫查詢就不會踩到，這是為什麼「相關度主導提取」的 LTM 性質沒有被違反——被違反的是性質 5 的推論：回想的動作不是回想的內容。

同時量到一件更大的事（真實索引，唯讀 sqlite3，2026-09-07）：647,408 chunk 中，⟨tool …⟩ metadata-only 有 270,151、⟨tool_result ok|error⟩ 有 271,258——合計 83.6% 的 chunk 是零內容或近零內容的工具殘影，而它們照樣進向量通道；重現裡 ⟨tool_result ok⟩ 在 Q1 排第 3、高於實質 turn。本 issue 的 self-hit 是這個母體的一個窄子集（ltm_query tool_use 1 筆＋含 ltm query 的 Bash 命令 42 筆，全在兩個 ltm repo）；母體本身另開 issue（見 Sister Concerns）。

查法：sqlite3 "file:$HOME/.claude-ltm/derived/index.sqlite3?mode=ro" 對 chunks.text 用 LIKE '⟨tool %' AND text NOT LIKE '%'||char(10)||'%' 與 IN ('⟨tool_result ok⟩','⟨tool_result error⟩') 計數；重現腳本形狀見本 comment 的表（8 筆 fixture、--all-projects --k 5 --json）。

Impact

• 影響的檔案：Sources/LTMIndex/RetrievalEngine.swift（候選資格）、Sources/LTMService/LTMService.swift（與 --exclude-session 同一條 post-ranking 過濾＋refetch 路徑）、Sources/LTMMCP/RetrievalTool.swift／Sources/ltm/Commands.swift（是否給 escape flag）、openspec/specs/retrieval/spec.md（fused list 成員資格那句）、docs/measurements/、tests。不動 CorpusScanner／索引內容（issue 的硬約束：不得改寫或刪除索引內容；也保住不變式 2，不需 --full）。
• 影響的使用者流程：MCP ltm_query（沒有 session id 可排除，hook 的 --exclude-session 幫不到它）、CLI 基準查詢、hook 回想（同 session 已被 --exclude-session 擋掉例 1，但例 2 跨 session 擋不到）。

Strategy

決定：在檢索層、以 chunk 形狀為判準、預設排除「對本系統的查詢動作」——issue 候選 B 收窄到 ltm 自己的查詢工具（A 太窄擋不住例 2，且「metadata 含查詢逐字」會誤殺「那次跑 benchmark 的對話在哪」這個 metadata 索引的原始用途；C 不解決擠掉實質 turn）。

• retrieval spec：fused list 成員資格加一條——tool-metadata-only 且工具是本系統的查詢入口（mcp__*ltm*__ltm_query tool_use、Bash command= 含 ltm query）的 chunk 不進候選；判準寫成封閉列舉＋「性質 5 推論：回想的動作不是回想的內容」；明寫這是資格過濾不是重排（seam 之外不重排的規則不受影響）
• RetrievalEngine.search 加候選資格謂詞（與 session 排除同一個 refetch 迴圈；沿用 1,000 候選上限與其誠實邊界）
• CLI／MCP 預設開；給一個 escape（--include-query-turns）供「找那次 benchmark 命令」用，MCP 端同名參數
• 測試：合成語料重現表的四列各一條斷言（例 1／例 2 消失、資格考／改寫不變）；變異：拿掉謂詞 → 紅
• docs/measurements/2026-09-xx-self-hit.md：例 1／例 2 兩組真實查詢前後前三名（用 ~/bin/ltm 匯出密鑰，唯讀查詢），並記母體數字（1＋42／647,408）與誤殺面（兩個 ltm repo 的 Bash 命令 chunk）
• CHANGELOG；ltm-recall SKILL 不用改（區塊格式不變）

Conflict Class

C_shared_module_coord —— 共享資源：docs/measurements/ 的基準查詢集與 scripts/measure-retrieval（#63 要換一組不在語料裡的基準查詢，本 issue 的前後量測要用那組；兩張要對同一份查詢集協調，先後不可交錯）。程式碼面只動 RetrievalEngine／LTMService 的過濾路徑，與 #61（IndexBuilder 閘）、#65（鎖）、#66（RecallBlock／hook）不同檔。

Complexity

Spectra

• Layer 2：改的是 retrieval spec 的已發布行為契約（fused list 成員資格），MCP ltm_query 的所有 caller 都受影響。
• Layer 3：修改既有 published spec 的 normative 句（「fused list SHALL contain only chunks that appear in at least one channel's ranking」要加排除條件）；且是有長期維護含意的架構決定（在哪一層定義「什麼不算記憶」）。
• Layer 1 未命中（非 narrative／ad-hoc script）。
• Hard-gate: triggered — 單一概念散佈 RetrievalEngine.swift／LTMService.swift／Commands.swift／RetrievalTool.swift／retrieval/spec.md／tests／measurement ≥ 5 檔；shared abstraction：LTMService.query 的過濾＋refetch 路徑被 CLI／MCP／hook 三個 caller 共用。硬閘結論被 Spectra 涵蓋。

→ /spectra-discuss（default）
⚠ Spectra 路徑不產生任何 phase-bearing comment，所以：artifacts 完成後請貼一則 ## Implementation Complete，並跑 /idd-update #62 --tasks-file openspec/changes/<change-name>/tasks.md
→ 建議 pre-implementation staging: superpowers:brainstorming（非綁定）

Risks

• 誤殺「找那次 benchmark 的命令」：42 筆全在 ltm 的兩個 repo；escape flag 保留路徑，量測要記這個面。
• 封閉列舉會漏：未來新的查詢入口（例如 ltm mark？不是查詢）要加進列舉；判準寫成「對本系統的查詢動作」而非工具名清單，清單只是實例。
• 與 基準查詢已被語料污染——三個量測查詢字串本身進了索引，需要一組不在語料裡的查詢與一條使用規則 #63 協調失敗的形狀：本 issue 先落基準查詢、基準查詢已被語料污染——三個量測查詢字串本身進了索引，需要一組不在語料裡的查詢與一條使用規則 #63 再換一組 → 前後量測不可比。先做 基準查詢已被語料污染——三個量測查詢字串本身進了索引，需要一組不在語料裡的查詢與一條使用規則 #63 的查詢集，再量本 issue（或本 issue 只量例 1／例 2 兩組，不碰基準集）。
• 母體 83.6% 是零內容 chunk 這件事比 self-hit 大得多——本 issue 不擴 scope 去處理它，但它會讓本 issue 的「變好」在前三名裡被 ⟨tool_result ok⟩ 之類的雜訊蓋住；量測時要把這類 chunk 的名次也記下。

Residue

「查詢動作不是記憶內容」這條判準在 LTM 類比裡站得住，但**「哪些工具殘影算內容、哪些算動作」沒有量測能裁定**——沒有評估集（#33）之前，本 issue 只能對兩組手挑查詢看前三名，說不出對一般查詢的召回率影響。這層留著，不假裝本 issue 會回答。

Vagueness Pre-check

• V1: 2 — 「要做什麼」明確：排除／降權查詢動作本身的 turn，issue 列了 A/B/C 三個候選且要求 diagnose 裁定層級。
• V4: 3 — 完成定義具體到「例 1／例 2 兩組查詢前後前三名的 docs/measurements/ 紀錄」，但沒有量化門檻（前三名要變成什麼才算好），依 ground truth 資料集沒有人在追——#16 把它劃出範圍後就沒有落點 #33 缺評估集屬結構性限制。
• Triggered: no — both axes ≤ 3

Sister Concerns Filed (mid-diagnose, v2.47.0+ #528)

• Filed: 84% 的 chunk 是零內容工具殘影（⟨tool_result ok⟩／metadata-only），照樣進向量通道擠掉實質 turn（sister concern from #62） #67 — 84% 的 chunk 是零內容工具殘影（⟨tool_result ok⟩／metadata-only），照樣進向量通道；本 issue 量到的母體，比 self-hit 大兩個數量級。
• Not filed: 「MCP ltm_query 沒有 session id 可排除」——那是本 issue 選檢索層形狀判準（而非 session 判準）的理由之一，屬本 issue 範圍。

[kiki830621]

Dashboard — #62

現況：已 diagnose（2026-09-07）。root cause：工具 metadata 把查詢字串逐字收進極短 chunk → lexical 兩通道全中、band 0；實質 turn 措辭不同只中向量、band 2——差兩個 band，策略層修不了，要在檢索層做候選資格過濾。Complexity Spectra（動 retrieval spec 的已發布契約）。sister：#67（84% chunk 為零內容工具殘影）。

你該做什麼：審 diagnosis；同意的話進 /spectra-discuss（idd-all 會接）。先做 #63 的基準查詢集再量本 issue，否則前後不可比。