Behavior-learning search ranking (KNN / learning-to-rank): does it fit Synapse?
Date: 2026-07-06 Method: three specialized subagents (technical/ML, operational/systems, product/strategy), each doing repo grounding + 2026 web research, synthesized here. Question: can KNN or a learning-to-rank / online behavior model improve and personalize Synapse search over time from the user’s own signals (which results they open/accept/use), and does it fit what Synapse is?
TL;DR: Do not build behavior-LTR. The kernel of the idea already ships, the on-brand way.
All three lenses converge, independently, on the same conclusion: classical LTR (LambdaMART/
RankNet), online LTR (DBGD/interleaving), contextual bandits, and per-query KNN do not fit
Synapse: the single-user signal is 2–4 orders of magnitude too sparse, the methods need a
training pipeline or heavy Rust ML deps (fail the no-dep-without-ADR bar), and their
exploration/SGD/RNG state is incompatible with “same bytes → same index” and signed
syn verify. The only surviving sliver is a deterministic, bounded, opt-in access
reinforcement, and even that is marginal, costs a new logged-signal subsystem, widens the
unverified surface, and is expected to miss the empirical bar SYN-255 already set. Recommended:
drop it; spend the effort on SYN-292 (undo Phase 2), SYN-271 (reindex enrichment correctness),
and distribution (SYN-101/102/103), which strengthen the actual moat.
Why the heavy forms don’t fit (technical lens)
- Data scale. A heavy personal-KB user produces ~10–50 opens/day, mostly on distinct, never-repeated queries. LambdaMART/RankNet train on 10³–10⁶ judged rows; online interleaving needs thousands of impressions per ranker comparison to clear noise. Per-query models get ~1 example per context. Only low-parameter, query-independent methods are statistically honest at this scale.
- Determinism. Synapse promises a reproducible index and signed
syn verify. The discriminator is sharp: convex + batch + fixed-iteration + no RNG + logged input → a pure function of the bytes, reproducible; anything with online RNG state or non-convex SGD → not. Bandits/DBGD/GBDT-SGD land on the wrong side and also put opaque ML on the retrieval path, which the ethos forbids near governance (ADR-029). - Rust reality (2026). The available LTR/GBDT crates (
lightgbm3-rs,linfa,smartcore) are training-pipeline / native-lib deps that fail the “no heavy ML runtime” bar. A hand-rolled deterministic re-weighter is the only viable path, and it needs zero new crates. - The one narrow form that is technically sound: a per-entity familiarity prior computed
as a batch fold over a logged interaction signal, reusing ADR-029’s existing ACT-R base-level
decay, applied as a bounded
1 + λ·familiaritymultiplier at the same site and in the same spirit as the trust factor: opt-in, post-fusion, feeding neither trust nor the gate.
Why even the narrow form is a liability (operational lens)
- Signal capture is thin and noisy. No browser, no click-stream, no dwell (a
syn openblocks on$EDITOR: that is lunch time, not attention). The one usable event, “search → open same slug,” has no session binding across the CLI/MCP doors and is confounded by position bias that a single user can never de-bias. - No cheap home for the learned state. In Markdown → pollutes source of truth and breaks the
verify fixpoint. In SQLite only → not rebuildable (violates the disposable-index rule). The
only defensible home is a second append-only, audit-class log in
.synapse/: a full new durable subsystem with its own retention, rotation, crash-safety, and privacy defaults. - It widens the unverified surface. A behavior model must be excluded from the canonical
syn verifydump (like vectors andmentions:*), which means the component deciding what the user and agent see first sits permanently outside the corruption proof. A bad model can silently down-rank a true, superseding fact without tripping any invariant, a corruption of what-gets-surfaced thatverifyis constitutionally unable to detect. - Privacy. Search/open history reveals intent more than the notes do; on a Markdown+git
substrate a
git add .would publish it. It would need gitignore-by-default (opposite of the audit trail) and an ADR.
Why it dilutes the product (product lens)
- Wrong axis. The benchmark shows retrieval is already the strongest leg (recall@10 100%, e2e 100% under thousands of distractors). The demonstrated pain is insertion (pass@1 80%) and correction: write-side governance, not read-side ranking.
- Already hedged. SYN-255 (anchor reranker) shipped with an explicit “if < 2–3% MRR, make it a no-op” gate. Behavior-LTR starts from less signal than that deterministic reranker and aims at the same marginal band.
- Anti-positioning. “Search that quietly changes based on your behavior” is, definitionally, a black box that drifts: the exact property v0.10–v1.0 spent eliminating (“prove nothing changed silently”; “no opaque ML in the governed path”, ADR-029). ADR-029 already rejected a per-user ranking model in spirit (EigenTrust over one user’s facts is rank-1/trivial).
- Landscape. Behavior-LTR is a moat for aggregate, multi-user, engagement-framed tools (Glean, web search) and is absent from every local-first single-user peer (Obsidian, Logseq). The closest AI-memory rival (mem0) does retrieval fusion: which Synapse already ships, not behavior-LTR. Where behavior-tracking met a privacy brand (Rewind/Limitless) it added creepiness.
The on-brand half already exists
Synapse already expresses the true kernel of the idea: “things you touch more, more recently,
rank higher”: the verifiable way: ACT-R base-level activation over recorded write/edit
touches (x-ai-history), folded into the deterministic trust factor and shared by
blame/stale/the ranker. It is transparent, banded, and reproducible by syn verify. That is
the ceiling of what behavior-adaptivity should ever be here.
If the owner still wants something (the only acceptable shape)
An explicit, opt-in, off-by-default access-reinforcement that stamps a syn show/get_entity
open as a recorded, inspectable reinforcement event into the existing history channel, reuses
the one ACT-R decay curve, and surfaces in the banded trust display: never “search learns from
you,” always “boost what you actually use, transparently.” The hard test: if syn blame can’t
print it and syn verify can’t reproduce it from the repo alone, it does not ship. Gate it
behind the same recall/MRR precondition SYN-255 carries; expect it to fail that bar.
Recommendation
Do not add behavior-LTR/KNN ranking. It is the anti-Synapse in miniature: opaque, drifting, outside the proof, on a leaky substrate, aimed at the one axis already at 100%. Reinvest in the differentiators the same effort would cost:
- SYN-292:
syn undoPhase 2 (reversibility pillar, still half-built). - SYN-271: reindex regenerating
mentions:*enrichment (a correctness gap in the reproducible-build keystone the provability moat depends on). - SYN-101/102/103: installer / Homebrew / npm (v1.1.0’s adoption theme; for a proven tool, reach is the binding constraint, not ranking cleverness).
Addendum: “continuous learning” of the embedding model (data adapts, the model does not)
A follow-up question distinguished embedding of data from continuous learning of the model. They land on opposite sides of the moat:
- Embedding of data: already shipped and adaptive. Synapse embeds everything with BGE-M3
on-device, at passage granularity (SYN-301), and re-embeds when content changes (SYN-251
skips unchanged content;
reindex/embed --allregenerate). So the vector representation of the brain continuously tracks the data, deterministically: same text → same vector. This is the on-brand form of “learning continuously.” - Continuous learning of the model (online fine-tuning of BGE-M3 on the user’s corpus): does
NOT fit, for the same three reasons as LTR: (1) it breaks “same bytes → same index” (a note’s
vector would depend on training history, not just the note) and so
syn verifystops reproducing; (2) a few hundred single-user notes overfit any fine-tune; (3) it puts a drifting, opaque model on the retrieval path, outside the corruption proof. - The acceptable, already-designed form: ADR-008 versions vectors by the model
identifier. Adopting a better model is a discrete, versioned, deterministic choice (swap → re-embed → fully reproducible), not continuous opaque drift. A future domain-adapted model could be an opt-in, but it pays the same determinism/verify cost and is likely not worth it.
Decision: continuous learning of the embedding model: no. Deterministic re-embed of data + deliberate, versioned model upgrades: yes (already how it works).