84% 的 chunk 是零內容工具殘影（⟨tool_result ok⟩／metadata-only），照樣進向量通道擠掉實質 turn（sister concern from #62）

[kiki830621]

Problem

真實索引（2026-09-07，唯讀 sqlite3）647,408 個 chunk 裡：

形狀	數量	佔比
⟨tool …⟩ metadata-only（單行、無 text block）	270,151	41.7%
⟨tool_result ok⟩ / ⟨tool_result error⟩（只有這幾個字）	271,258	41.9%
合計	541,409	83.6%

這些 chunk 照樣被嵌入、照樣進向量通道。合成語料重現（#62 diagnosis）：查 flock inode 鎖 時 ⟨tool_result ok⟩ 排第 3、高於真正討論 flock 的 turn；⟨tool_result ok⟩ 全語料 27 萬筆文字逐字相同、向量相同，任何查詢的向量通道前 N 名都可能被它們填滿。

2026-08-26 決定收 tool_use metadata 與 tool_result 成敗（docs/measurements/2026-08-26-tool-payload-share.md）的理由是「那次跑 benchmark 的對話在哪」要搜得到——那個理由對 command=／file_path= 這類帶識別資訊的 metadata 成立，對 ⟨tool_result ok⟩ 這種零資訊 chunk 不成立。

Type

bug（檢索品質＋索引體積：84% 的 chunk 沒有可召回的內容）

Expected

先決定（需 diagnose）：

• 索引時不產出零資訊 chunk（tool_result 成敗改附到前一則 tool_use chunk 的文字尾端，不獨立成 chunk）——會改索引內容，要 --full，且是 corpus-indexing spec 的變更；
• 或檢索時不列為候選（與 查詢自身的 turn 成為第一名命中——查詢字串一進語料就把自己召回（self-hit） #62 同一條資格過濾）——不動索引，但向量檔仍養著 27 萬個相同向量；
• 或兩者。任一都要量：索引體積、build 時間、查詢延遲、以及 查詢自身的 turn 成為第一名命中——查詢字串一進語料就把自己召回（self-hit） #62 兩組查詢的前三名。

不得改寫既有 chunk 的文字（性質 5）；「不產出」是遺忘，允許。

Actual

如上表。

相關

• 查詢自身的 turn 成為第一名命中——查詢字串一進語料就把自己召回（self-hit） #62（self-hit）：本 issue 是它量到的母體；查詢自身的 turn 成為第一名命中——查詢字串一進語料就把自己召回（self-hit） #62 的資格過濾是本 issue 的一個窄子集。
• 每 build 固定項改維護式記帳——#44 閘的 Q1 逐列探查與 chunkCount() 全表 COUNT 隨索引總量成長（設計決定） #61（每 build 固定項隨索引總量成長）：84% 的 chunk 若不再產出，每 build 固定項改維護式記帳——#44 閘的 Q1 逐列探查與 chunkCount() 全表 COUNT 隨索引總量成長（設計決定） #61 的分母直接掉一半以上。
• ground truth 資料集沒有人在追——#16 把它劃出範圍後就沒有落點 #33（評估集）：「零資訊 chunk 拿掉後召回有沒有變好」仍量不到。

Source: surfaced during /idd-diagnose #62 sister concern surfacing (Step 3.6)