調記憶搜尋一整天，最後卡在量測解析度
我的 AI agent 每收到一則訊息，hook 會先跑一次記憶搜尋，把最相關的幾份 journal 或筆記摘要注入 context。這套搜尋從四月的 keyword × 時間 × hall 類型三軸排序 一路長到現在：BM25（jieba 分詞）算基礎分，常駐的 EmbeddingGemma 2 服務給一份語意排名，兩份排名用加權 RRF 合併。 前天深夜到昨天下午，我讓 agent 對它做了一整輪改善，分三層：純程式調整、本機模型、LLM。每一層做完都交叉審查兩輪，總共二十來個 commit。最後採用的不多，但學到最多的部分跟搜尋演算法本身關係不大，主要在量測方法。 先修尺：bench 會被自己汙染 原本的做法是改一版程式、跑一次 recall bench、看 MRR 有沒有升。這樣跑出來的數字有兩種汙染，都是過程中實際撞到的。 語料在兩次 bench 之間變了。 dense 索引每 60 秒增量更新，cron 也會歸檔 journal。某一題的正解剛好是我正在補比較結果的那份筆記，筆記改完之後，這題的 dense 名次從 3 掉到 48，整題變 MISS。看起來像是新版退步，其實是語料不同。 筆記把題目抄進去了。 筆記裡逐字引用了題庫某題的提問，結果這份筆記自己變成 BM25 的第二名，把正解的領先倍數從 1.7 壓到 1.47，剛好低於我設的保護門檻（1.5），保護規則就失效了。修法是改筆記，門檻不動。 所以第一層先做的是量測工具： 改動 解決什麼 bench 語料快照 把 journal、notes、向量索引凍結成一份，另開一個 port 起 embed 服務，前後比較都跑同一份資料；程式一律跑 repo 現行版 看注入命中，不只看 MRR --hook 模式重現 hook 實際的注入邏輯（天數、領域加減分、同類去重、門檻、6 秒逾時），回報 inj_hit_rate dev / holdout 切分 取捨只看 dev，holdout 只在每層最後驗收；依正解檔分組切，共用正解的題目放同一側 看注入命中這點後來很關鍵。分數是依名次繼承的，注入門檻 0.7 幾乎不過濾，所以真正決定 agent 拿到什麼的是排名，MRR 小幅上升不一定代表注入變好。 ...