Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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 + λ·familiarity multiplier 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 open blocks 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 verify dump (like vectors and mentions:*), 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 that verify is 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:

  1. SYN-292: syn undo Phase 2 (reversibility pillar, still half-built).
  2. SYN-271: reindex regenerating mentions:* enrichment (a correctness gap in the reproducible-build keystone the provability moat depends on).
  3. 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 --all regenerate). 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 verify stops 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).