05b215c9f7
## ① 「關懷型 AI 命中 20 筆、只有前 3 筆相關」⇒ 閾值太寬(leo 判斷正確) 固定門檻兩頭都不對,因為每個查詢的分數尺度不同(實測 youlin 實例): 關懷型 AI 正解 0.645-0.770,雜訊起於 0.547 ← 固定 0.5 放進 6 筆雜訊 閉環機 正解 0.552-0.638,雜訊起於 0.446 ← 固定 0.6 砍到剩 2/4(=早上的 0 命中) 人力媒合系統規劃書 正解 0.842,雜訊起於 0.550 ⇒ 改**相對門檻** max(0.45, top×0.8)。五組實測:固定 0.5 混入 9 筆雜訊/ 固定 0.6 有兩組正解被砍/相對式四組雜訊 0 且正解全留。 ## 🔴 寫測試才發現的真問題:門檻不能在 Vectorize 那層算 Vectorize 的 indexed metadata 沒有 status ⇒ 那層不知道誰已下架。 若最高分是下架殘影(t24 復現案 0.971),拿它算門檻=0.777, 會把 0.6 的正解一起砍光 ⇒ **又變成 0 命中**。 ⇒ 相對門檻移到 routes/entries.ts,接在「hydrate+濾下架」之後; embed.ts 只留絕對下限。新增測試鎖住這個順序。 ## ② leo:「理論上它的向量也要刪掉,就不會有殘影了吧?」——對,補上 單筆真刪已接 deleteByIds(b7af622),但「移除整個庫」走軟刪、向量原地不動。 ⇒ deprecate-by-library 同時 deleteByIds + is_embedded 歸零(D1 與 Vectorize 不說兩套話); backfill 兩條路徑(含 reindex)都排除 deprecated,否則下次補嵌會把殘影養回來。 不違背 t135「資料保留可還原」:D1 那列原封不動,還原後跑 backfill 重嵌即可。 回應新增 vectors_deleted,刪失敗誠實回 0 不假裝清乾淨。 驗:kbdb 91/91 綠(新增 4 項相對門檻測試,含「下架殘影不得決定門檻」) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>