feat: query intent classification for hybrid search — auto-derive --bias-type + signal weighting from the query (extends #82)

[edheltzel]

Context

From the 2026-07-13 mnemon competitive review, red-team validated (breadcrumb #3984, learning #668). STEAL LATER tier — explicitly queued behind #231/#232 and the --readonly issue; modest expected value, filed to keep the record.

Prior art: #82 shipped --bias-type (soft type bias in FTS5 ranking — present in src/commands/search.ts, src/lib/memory.ts, src/mcp-server.ts). This proposal is the auto-detection layer on top of it, NOT a new ranking model.

mnemon reference: internal/search/intent.go:80 — regex-vote intent detection (WHY/WHEN/ENTITY/GENERAL) that adapts retrieval behavior per intent. Red-team caveat carried over: mnemon's docs overstate its implementation (per-intent rerank weights are fiction; intent only steers traversal) — borrow the idea, not the implementation.

Proposal

Classify the query's intent cheaply (regex/keyword vote, no LLM call) and map it to existing knobs:

• 'why did we…', 'reason for…' → bias decisions
• 'how do I…', 'fix for…', 'wrong→right' → bias learnings
• 'when did…', 'recently…' → recency-weighted ordering
• named entity/project queries → bias breadcrumbs/LoA
• default → current behavior, unchanged

Explicit --bias-type always wins over detection. Detection result surfaced in output (intent: why → bias decisions) so ranking stays explainable.

Acceptance criteria

• Zero-cost classifier (no LLM, no latency regression on the ≤50ms hybrid SLO from Epic: Search Performance — index vectors + cache model work (≤10ms ideal / ≤50ms acceptable) #146)
• Maps only to existing ranking knobs (search: soft type bias for memory search (--bias-type) — revive orphan branch #82 bias + recency ordering) — no second scoring model (DRY)
• Explicit flags override detection; GENERAL queries behave exactly as today
• Benchmark suite F unchanged or improved; relevance spot-checks documented
• bun tests: intent mapping table, override precedence, no-regression default path

[edheltzel]

Field evidence for this issue (2026-07-15) — plus a separate finding that turned up next to it

Surfaced while diagnosing #240 (semantic tier dead 23 days). Not proposing to reprioritize — the "STEAL LATER / modest expected value" triage still looks right. Recording the reproduction so this issue has real data when it does come up.

Reproduction: a natural-language question misses the memory that answers it

With the semantic tier fully healthy (14,616 embeddings, vec index populated, semantic backend: knn):

memory_hybrid_search("do you remember when we decided how to handle graphs")

Top 10 contains: #1993 (custom SVG graph over Mermaid), #1120, #2298, #848, #693, #557 — all codegraph/graph-adjacent.

It does not contain decision #2892 — "Graph direction for Recall (Ed): build on CodeGraph rather than building a graph layer from scratch" — which is the canonical answer, is user_authored, and is ranked important enough to be injected into L1 at every SessionStart.

A richer phrasing does surface it:

memory_hybrid_search("do you remember when we decided how to handle graphs and knowledge graph direction")
-> #2892 at rank 3

So the failure is query-side, which is exactly this issue's thesis: the terse conversational phrasing a human actually types carries no signal that routes to the right record, while the record itself is a perfect match semantically. This is the concrete user-visible case for intent classification / signal weighting.

Note the asymmetry worth designing against: user_authored + high-importance + L1-injected is about as strong a "this is the answer" signal as the DB holds, and it still lost to six weakly-related rows. Whatever #234 ends up doing, provenance and importance look like cheap signals to weight on.

Separate finding: RRF k=60 flattens ranking at Recall's result-set sizes

Not the cause of the above (#2892 never enters the candidate list, so re-ranking can't rescue it) — filing it here because it's adjacent to "signal weighting" and would otherwise be lost.

reciprocalRankFusion (src/lib/embeddings.ts) uses k = 60, the TREC-era default tuned for long lists. Recall fuses ~20 candidates. The resulting separation:

rank	1/(60+rank)	spread vs rank 1		1/(10+rank)	spread vs rank 1
1	0.01639	0.0%		0.09091	0.0%
2	0.01613	−1.6%		0.08333	−8.3%
3	0.01587	−3.2%		0.07692	−15.4%
5	0.01538	−6.2%		0.06667	−26.7%
10	0.01429	−12.9%		0.05000	−45.0%
20	0.01250	−23.8%		0.03333	−63.3%

With k=60, rank 1 and rank 2 differ by 1.6%. Every result in a real query rendered as 1.6% … 1.6% … 1.6% … 1.5% — the ranking is very nearly flat, so FTS/vec agreement contributes almost nothing to final order. k=10–20 restores real separation.

Do not just change the constant. There is no relevance harness to prove a k change helps rather than regresses, and #217/#225 tuned this path for the 100k SLO. This wants a measurement loop and a small labelled query set — which is arguably a prerequisite for #234 as a whole, since "did intent classification help?" needs the same instrument.

Housekeeping

The display bug that made this table hard to read (1.6%, and -1121.0% on the degraded path) is fixed separately — RRF is now rendered as rrf=0.0328, not as a percentage. RRF scores are relative ranking signals, not confidences; the % implied a meaning they never had.

Refs #240, #82, #217.