refactor(searcher): hoist CLOSET_RANK_BOOSTS to module level + record ablation finding

[jphein]

Summary

• Move CLOSET_RANK_BOOSTS and CLOSET_DISTANCE_CAP from inside search_memories to module scope so they're patchable for A/B benchmarking without touching the function.
• Add a comment block alongside the constants recording an empirical ablation against a 151K-drawer corpus that found the closet boost is mostly inert on chat-heavy content.

Pure refactor + comment — no behavior change.

Why

The rank-based closet-boost has been the subject of #1129 (VecRecall: "organization-layer involvement in retrieval reduces R@5"). Before deciding whether to act on that critique, I ran a 12-probe A/B against my 151K-drawer canonical palace, default-vs-zeroed boosts. Findings (now captured in code):

• Boost fires on ~20% of result rows, concentrated in queries whose answer lives in mined files; closets are sparse on chat-transcript queries (most fork-side decisions).
• When the boost fired, it re-ordered chunks within a single source file rather than displacing right answers with wrong ones — the failure mode VecRecall describes did not reproduce on this corpus.
• Net: the hybrid degrades to effectively pure-vector for transcript queries and re-ranks within-file chunks for mined-file queries. Neither matches the failure mode VecRecall is fixing.

The hoist itself is benign and useful — it lets future tuners swap the constants from outside the function (env var, config flag, in-process patch). The ablation comment lives next to the constants so future-us doesn't have to re-run the experiment.

Scope

• mempalace/searcher.py: +21 / -6
• 27/27 searcher tests still pass; full suite green locally on Linux Py3.12.
• No new dependencies, no public API change.

Provenance

This was filed in response to @igorls's invitation in his close of `#1286` to file the closet-boost refactor as a small standalone PR. Two commits, surgical, against current develop.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR refactors the closet-boost tuning knobs in search_memories() by hoisting CLOSET_RANK_BOOSTS and CLOSET_DISTANCE_CAP to module scope, and adds an in-code comment capturing an empirical ablation result relevant to ongoing retrieval-quality discussion (#1129). The intent is to keep runtime behavior unchanged while making the boost parameters patchable for benchmarking/tuning.

Changes:

• Hoist CLOSET_RANK_BOOSTS and CLOSET_DISTANCE_CAP from inside search_memories() to module-level constants.
• Add a module-level comment block documenting an A/B ablation on a large corpus and summarizing observed impact.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jphein]

Good catch — fixed in 1474699. CLOSET_RANK_BOOSTS is now a tuple, so a stray append/__setitem__ on the imported attribute can't silently reshape global ranking. The ablation workflow that motivated the hoist still works because it rebinds the module attribute (searcher.CLOSET_RANK_BOOSTS = (0,) * 5) rather than mutating in place — see scripts/closet_boost_ablation.py.

[jphein]

Fair — fixed in 1474699 by committing scripts/closet_boost_ablation.py. Takes a palace path + optional probe set on stdin, runs the search under default boosts and zero boosts, prints a per-query delta showing whether the boost re-ordered candidates or just nudged. Lazy-imports the searcher module so --help is usable without chromadb. Comment block now points at the committed script.

[jphein]

@igorls — friendly nudge: this one is small (+21 / -6 in mempalace/searcher.py and one new scripts/closet_boost_ablation.py), all 6 CI green, Copilot review responded to. Wonders whether it'd fit in the v3.3.5 batch alongside #1370 — happy to defer to v3.3.6 if you'd rather batch the changelog this round, just flagging timing since the ablation note inside it speaks to #1129 (VecRecall's R@5 critique) and a v3.3.5 inclusion would let that conversation get the empirical anchor sooner. No rush either way; thanks for the work on #1377.

[igorls]

Thanks for this contribution, and apologies for the slow turnaround.

develop has moved a fair way since this was opened and the branch no longer merges cleanly. If you're still interested in landing it, could you rebase onto current develop? Once it merges cleanly and CI is green I'll get it reviewed for the 3.8.0 cycle.

If you'd rather not pick it back up, no problem at all — just say so and I'll close it out, and thanks either way for taking the time to send it.