Query-type-aware adaptive fusion weighting (validated symbol-level lever)

[Neverdecel]

Stacked on #38 (claude/eval-harder-benchmark) — review/merge that first; this PR's base will need retargeting to master once #38 lands.

Why

PR #38's symbol-level eval surfaced the single biggest lever: fixed 1:1 dense/BM25 fusion is a compromise, not an optimum. On natural-language queries the dense retriever is much stronger, and equal-weight RRF drags it down with weak BM25 (bge-small: dense MRR 0.675 vs hybrid 0.573). This PR implements query-type-aware fusion weighting to fix that.

What

• coderag/retrieval/query_type.py: looks_like_identifier() (a cheap, conservative local heuristic) + fusion_weights(). NL queries lean dense; identifier-like queries stay neutral.
• config.adaptive_fusion (off by default) + nl_/code_ weight pairs, all env-configurable (CODERAG_ADAPTIVE_FUSION, …).
• HybridSearcher routes weights per query; compare_modes gains an adaptive row and isolates the fixed modes from it; coderag eval --adaptive, bench_embedders.py --adaptive; status() reports it.
• coderag/eval/datasets/coderag_self_identifiers.jsonl: 22 identifier-query cases (derived from the symbol set) to validate the code-side routing — not just the NL side.

Validated (bge-small, symbol level) — a Pareto improvement over fixed 1:1 hybrid

NL queries (coderag_self_symbols.jsonl)     MRR    R@1    nDCG@10
  hybrid (fixed 1:1)                         0.604  0.455  0.669
  adaptive                                   0.674  0.545  0.722   ← +0.070 MRR, +20% R@1

identifier queries (coderag_self_identifiers.jsonl)
  hybrid (fixed 1:1)                         0.685  0.545  0.741
  adaptive                                   0.685  0.545  0.741   ← unchanged (no regression)

Honest correction baked into the defaults

The literature's "BM25-up for code" intuition was refuted by the data: up-weighting BM25 for identifier queries hurt (MRR 0.685 → 0.613), because short/common identifiers (search, index) are lexically ambiguous and the embedder already matches them well. So the code-side default is neutral (1:1), not BM25-leaning — and BM25-leaning is left configurable (CODERAG_CODE_LEXICAL_WEIGHT) for larger repos where exact-string recall matters more. This is the harness preventing a plausible-but-wrong default.

Off by default pending larger-repo validation; enable with CODERAG_ADAPTIVE_FUSION=1.

Testing

New offline tests for the classifier (identifier vs NL), the weight routing (incl. validated defaults), and end-to-end adaptive search. Full pytest -m "not integration" green; ruff + mypy clean on new code.

Follow-ups

• Validate (and likely default-on) on a larger external repo.
• Reranking on a dense-weighted (adaptive) candidate pool, to stack the two levers.

🤖 Generated with Claude Code

---

Generated by Claude Code